Allgemein kann das FT32 Projekt in 3 Hauptteile unterteilt werden, auf diese hier kurz eingagangen wird, um den derzeitigen Stand des Projektes zusammen zu fassen. Neben dem Boardlayout, der C++ Software auf dem ESP32 ist auch die Codypp Weboberfläche in Betracht zu ziehen. Die Funktion dieser drei Bestandteile lässt sich folgendermaßen beschreiben:

1) Um die Sensoren sowie die Aktoren von Fischertechnik über den EP32 ansprechen zu können, ist für diesen Zweck eine selbst erstellte Leiterplatte entwickelt worden. In diesem Zusammenhang wurde auch ein 3D Druck Gehäuse gefertigt, damit die Leiterplatte in bestehende Fischertechnikprojekte integriert werden kann. Derzeit existieren zwei Leiterplattendesigns; eine große und eine kleine Version des Boards, auch in Anlehnung an den Fischertechnik TXT-Controller (vgl. Leiterplattendesign groß) und das Fischertechnik Discovery Set (vgl. Leiterplattendesign klein).

2) Damit die Hardware angesprochen werden kann, sind auf Mikrocontrollerebene C++ Bibliotheken notwendig. Außerdem ist die Netzwerkkommunikation, die Ressourcenverwaltung sowie die Visualisierung und Steuerung durch graphische Blöcke durch den Benutzer umzusetzen. Hierfür wurden ein Networkhandler (stellt die Netzwerkfunktionalität bereit), ein Assethandler (übernimmt die Bereitstellung der Daten zum Anzeigen der Weboberfläche aus dem internen Speicher im Browser) sowie ein Websockethandler, welcher die Kommunikation zwischen ESP32 Controller und der Codypp-Webbrowseroberfläche übernimmt, implementiert (vgl. Implemetierungen in ft32.ino und Blockschaltbild des Gesamtsystems).

3) Um die Programmierung und Steuerung der Hardware möglichst intuitiv und einfach für den Endanwender zu gestalten, wurde auf das Blockly-Framework von Google aufgesetzt. Dieses wurde im Design und in der Basisfuktionalität an die Anforderungen des FT32 Projektes angepasst. Die dadurch entstandene Webentwicklungsumgebung Codypp kann zum einen für die Programmierung des FT32-ESP32 Controllers verwendet werden, zum anderen bietet sie die Möglichkeit, C++ Arduino Quellcode zu erzeugen, um native Applikaionen basierend auf den Bibliotheken für die FT32-Hardware zu erstellen (vgl. Demoversion Stand WS2017/18; Stand WS2018/19).

Wie schon bereits in der Problemstellung erwähnt, gibt es zwei Boot-Möglichkeiten für den FT32-ESP32 Controller (Erstellung eines eigenen, "internen" Netzwerks mit lokaler Codypp Oberfläche aus dem Spiffsspeicher; Verbindungsaufbau mit einem bestehenden Netzwerk und Laden der Codypp Oberfläche aus dem internen Speicher (vgl. Abbildung unten)). Zu erkennen ist, dass in der zweiten Möglichkeit gleich mehrere Probleme liegen. Zum einen ist die Netzwerkkonfiguration nicht modular, d.h. nicht ohne weiteres durch den Benutzer anpassbar, und zum anderen wird die Weboberfläche immernoch aus dem internen Speicher des ESP32 Controllers geladen.

Bei der ersten Verbindungsmöglichkeit hingegen gibt es von Seiten des ESP32 verschiedene Restriktionen: Mit einem ESP32 können sich nach Erstellung eines WLAN Netzwerkes nur bis zu vier Endgeräte koppeln (vgl. Linkliste Quellen [7]-[9]), da weitere Verbindungsmöglichkeiten Hardwareseitig nichtmehr verabeitet werden können. Damit ist das Projekt, gerade wenn es um die Möglichkeit der erweiterten Kommunikation zwischen ESP32 Controllern oder weiteren Netzwerkresourcen begrenzt (mögliche Szenarien einer modularen Netzwerktopologie sind hier zu finden). Darüber hinaus ist der interne Speicher des ESP32 begrenzt. Dies hat für den Entwicklungsprozess der Codypp Weboberfläche gleiche mehrere Einschränkungen zur Folge. Neben der Gesamtgröße und damit einem begrentzen Funktionsumfang ist auch die Umsetzung von Neuerungen begrenzt, da für jede neue Version jeder Controller neu eingerichtet (vgl. Einrichtung des Spiffsspeichers) werden muss, um den Stand Controllerunabhängig aktuell zu halten.
Ein großen Einfluss auf die Usability und das Benutzererlebnis hat auch die Ladezeit der Codypp Oberfläche. Mit zunehmendem Funktionsumfang muss auf ESP32 Ebene mithilfe von optimierten Lesealgorithmen die notwendigen Inhalte gepackt an den Webbrowser des Endanwenders übermittelt werden. Dies ist ein sehr anfälliger Prozess und in nicht selten Fällen führt dies zu Problemen; entweder das Netzwerk des ESP32 "versagt" aufgrund von zu vielen Verbindungen oder die Weboberfläche wird nicht richtig dargestellt.

Für die Weiterentwicklung an dem Projekt sind verschiedene Tools und deren richtige Konfiguration notwendig. Um diesen Prozess zu verinfachen, wurde in vorangegangenen Projekten unterschiedlichste Hilfsskripte und Tools erstellt (vgl. makeSpiffs.sh, Python-Spiffs-Tool, ft32-simple_install oder Spiffs-Batch-Skripte für Windows). Als Vorbereitung für dieses Projekt wurde eine Virtuelle Machine erstellt, in der alle Tools eingerichtet und getestet wurden. Da dies nicht umbedingt Teil der Aufgabenstellung war, wird dies nun im Stand der Technik behandelt.

Die Virtuelle Machine umfasst ein Linux Mint 19 Betriebssystem und darin enthalten die Atom IDE (mit npm) zur Weiterentwicklung von Codypp, die Arduino IDE die C++ Programmierung des ESP32 Controllers sowie das makeSpiffs.sh Skript zum Schreiben der notwnedigen Dateien für die Codypp-Version für den internen Speicher. Diese kann unter diesem Link heruntergeladen werden. Eine ausführliche Dokumentation der Einrichtung und Verwendung der VM findet sich im Unterordner /docs in der *.zip Datei. Zu beachten ist, dass die Setup.txt nicht den aktuellsten Stand repräsentiert:

Der TXT-Controller von Fischertechnik war sowohl von Seiten der Hardware als auch von der Software im Rahmen des ursprünglichen Projektes Vorbild. Dementsprechend ist es sinnvoll diesen hinsichtlich der Problem- und Aufgabenstellung (kurz: Eine modulare WLAN-Konfigurationsmöglichkeit) im Rahmen des "Stand der Technik" zu untersuchen. Außerdem sind andere Umsetzungsmöglichkeiten untersucht worden, die dann in die Lösungsfindung mit eingeflossen sind.  

Fischertechnik selbst bietet mit dem TXT-Controller die Möglichkeit, diesen in ein bestehendes Netzwerk zu verbinden oder selbst eins zu erstellen (vgl. Linkliste Quelle [2]). In beiden Fällen dient die Netzwerkverbindung für die Remote-Programmierung und Steuerung, vergleichbar mit der Umsetzung des FT32 Projektes. Die unten angeführten Abbildungen verdeutlichen die in diesem Zusammenhang einzustellenden Konfigurationsmöglichkeiten des TXT-Controllers:

Auch auf Seiten des ESP32 und der Community existieren schon erste Ansätze und Umsetzungen, um zur Laufzeit des Mikrocontrollers die WLAN Einstellungen modular konfigurieren zu können, ohne den ESP32 und dessen Speicher neu flashen zu müssen. In diesem Zusammenhang bin ich auf das "INI WiFIManager" Projekt gestoßen (vgl. Linkliste Quelle [14]). Hinsichtlich meiner geplanten Umsetzung bietet es schon enorm viele Lösungsansätze, genauso aber auch Differenzen und Probleme, die ich im folgenden Abschnitt ausarbeiten möchte.

Das Funktionsprinzip des Projektes lässt sich leicht zusammenfassen: Nach Systemstart wird, falls noch keine Konfiguration hinterlegt ist und ein Verbindungsaufbau zu einem bestehenden Netzwerk nicht möglich ist, ein Access Point erstellt und der Benutzer kann sichdurch das Netzwerk auf den ESP32 einloggen und die Konfigurationswebsite im Browser über "http://192.168.4.1" aufrufen. Auf dieser wird die Möglichkeit geboten, in einem Textfeld eine neue Konfiguration zu hinterlegen oder eine vom Rechner hochzuladen. Hierbei können, neben den Basiseinstellungen zum Passwort oder der SSID, auch Einstellungen zu MQTT- oder NTP-Server vorgenommen werden. Die Funktionalität ist aber in diesem Projekt nicht umgesetzt worden. Nach dem Abspeichern kann der ESP32 über einen Button neugestarten werden und sollte sich nun mit dem neuen Netzwerk verbinden.