Update 04. Prototyp – Vorgehen & Implementierung authored by Jonas Pfaff's avatar Jonas Pfaff
Content follows
# Prototyp - Vorgehen und Implementierung
## Vorgehen
Um die Idee eines "Physischen Zwillings" eines Remote-Studis umzusetzen wurde in der Konzeptionsphase der Lösungsarchitektur Wert auf die Einhaltung der Designprinzipien für IoT Anwendungen gelegt (Siehe Kap. 5). Hierbei sah das ursprüngliche Konzept den Einsatz von Scrollbots vor. Aufgrund der aktuellen Knappheit der Scrollbots, haben wir uns entschieden, 7"-Displays mit handelsüblichen Raspberry Pi 3 und 4 zu verwenden. Der Kerngedanke der Lösung, den Studierenden im Vorlesungsraum zu Präsenz zu verhelfen, wird somit abgedeckt und prototypisch umgesetzt.
## Implementierung
Zur Implementierung des MVP wurde verschiedene Standardsoftware verwendet. Auf Hardware-Ebene wird ein Raspberry Pi 4 verwendet, auf dem eine Docker-Umgebung aufgesetzt wurde. Um eine möglichst hohe Portabilität zu gewährleisten werden die verschiedenen Lösungsbestandteile in getrennten Containern deployed:
- **Portainer** zur Verwaltung der Container
- **Node-RED** als Backend für jeden Reactor
- **Mosquitto** als MQTT-Broker
Der Kern der Lösung beinhaltet die Trennung von Sender (Interactor) und Receiver (Reactor) auf programmatischer Ebene. Hierbei wird dem Studierenden eine Website zur Verfügung gestellt, in der er Reaktionen (über Emojis) und Fragen an den MQTT-Broker übermittelt werden. Dieser publiziert alle eingehenden Nachrichten auf die Endpoint ```IoTHackathonHHZ/# ```. Die RaspberryPi sind über das Node-RED Backend auf diesen Endpoint subscribed. Hierbei fungiert ein Pi zeitgleich als Broker und als Reactor. Alle anderen Pis übernehmen lediglich die Rolle des Reactors und subscriben auf den genannten Endpoint.
Damit jede Nachricht nur auf einem Pi angezeigt wird, wurde im Backend eine Channel Kommunikation zwischen den Reaktoren aufgebaut, die über den MQTT-Broker abläuft. Dabei wird auf Grundlage der ID des Backends die Wahl getroffen, welcher Pi die Nachricht anzeigt. Hierbei wird die Wahl durch den Vergleich der IDs gelöst, bei dem die höhere, numerische ID gewählt wird.
Der Studierende liefert als **Input** seine Reaktionen oder Fragen über die Web-Anwendung. Diese werden in einem strukturieren Format an den MQTT-Broker **gesendet** und von diesem auf einen vordefinierten Endpoint übertragen. Einige Nachrichten erhalten Code-Wörter, die vom Reactor interpretiert werden. Ein Beispiel hierfür ist das Keyword ```Disconnected```. Auf diesen Befehl hin (egal ob über das "Frage"-Feld gesendet oder über das Schließen der Seite, löst der Reactor die Subscribtion auf den Endpoint des Studierenden auf und wartet auf neue Subscriptions. Der **Output** ist ein für den Professor gut erkennbares Bild eines Emojis oder die Einblendung einer Nachricht/Frage auf einem 7"-Full-HD-Display im direkten Blickfeld.
## Ausblick
Die Endlösung sieht die Verwendung des QoS-Level 1 vor, um dem Studierenden eine Rückmeldung zu geben, ob seine Nachricht von einem Reactor abgeholt wurde. Diese Rückmeldung ist nach aktuellem Stand noch nicht implementiert. Somit ist der MVP in der aktuellen Version eher für das Übertragen von Reaktionen, als für Fragen geeignet. Bei erstgenannten ist es weniger Wichtig den Erhalt der Nachricht zu bestätigen, da eine Reaktion keinen unmittelbaren Einfluss auf den Lernerfolg des Studierenden hat.
# --------------------------------------------
# TODO: Delete Block below
Beschreiben Sie das technische Konzept in seiner Gesamtheit. Was sind Input, Verarbeitung, Output.
Das Konzept darf größer sein als die folgende Implementierung. Beschränken Sie Ihre
......
......