Um die Idee des "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:
### Allgemeine Informationen
Zur Implementierung des MVP wurde verschiedene Standardsoftware verwendet. Auf Hardware-Ebene wird ein Raspberry Pi 3 und 4 verwendet, auf denen 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, Frontend für Reactor und Interactor
-**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 übermitteln kann. 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.
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 UUID 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
## Technisches Setup
In unten stehender Grafik wird die oben beschriebene Systemarchitektur vereinfacht dargestellt. Der auf der linken Seite dargestellte Stack deckt alle Komponenten der Architektur ab. Die Linien stellen einen Nachrichtenfluss im genannten Protokoll dar. Auf der rechten Seite ist ein Nebengerät abgebildet, welches über keinen eigenen MQTT-Broker verfügt und somit allein keine Funktion bereitstellt.
Auf diesem Gerät läuft der MQTT-Broker (Mosquitto Container). Damit bildet dieses Device den zentralen Punkt in der Systemarchitektur. Auf dem Hauptgerät kann ebenfalls ein Reactor laufen, sofern die Kapazität des Raspi dies zulässt.
Auf diesen Raspis läuft ausschließlich ein separates Node-Red Backend. Dieses ist nötig, damit die jeder Reactor eine eigene Instanz mit lokaler UUID darstellt. Die UUID wird verwendet um den Reactor zu wählen, der die Nachricht anzeigen soll. Hierbei gewinnt immer die höchste UUID.
Unten stehende Sequenzdiagramme zeigen den exemplarischen Vorgang der Election des "Lead-Reactors". Dieser Lead subscribed sich durch die Wahl auf den Endpoint des Interactors. Danach ist er für neu hinzukommende Studierende erst wieder wählbar, wenn der Interactor die Verbindung durch das Senden des Befehls ```Disconnected``` schließt. Verliert ein Reactor die Wahl, wartet er auf neue Nachrichten im Hauptchannel. Sobald ein neuer Interactor eine Nachricht sendet, beginnt die Wahl erneut.
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: Sequenzdiagramme oben einfügen
### Kommunikation zwischen Services
Auf unten stehender Grafik wird die Kommunikation zwischen den verschiedenen Instanzen dargestellt. Generell laufen alle GUIs, die Studierende aufrufen auf dem Hauptgerät (auf ```192.168.178.75:1880```) und werden aus einer zentralen Node-Red Instanz zur Verfügung gestellt. In der Darstellung der Reactors sind die verschiedenen Hosts zu erkennen, auf denen diese laufen. Theoretisch ist es auch möglich alle Instanzen auf dem gleichen Raspi unter verschiedenen Portnummern zu starten. Da ein Raspi allerdings nur einen Display-Anschluss hat, kann nur ein Reactor gleichzeitig angezeigt werden.
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
Implementierung auf die Funktion(en), die zur Demonstration von IoT Konzepten wesentlich sind.
Das ist das MVP Ihres Prototypen. Begründen Sie Ihre Auswahlentscheidung.
Aufgrund der Aufgabenstellung ist die Kommunikation über MQTT obligatorisch. Ihr MVP Prototyp
muss diese Kommunikation demonstrieren.
Berichten Sie über
- das technische Setup des MVP einschl. der Begründung für die Gestaltung des MVP
- die eingesetzten Technologien und Services,
- sowie deren Zusammenspiel, z.B. Datenfluss.
Bearbeite die autostart Datei des Raspis
```cmd
sudo nano /etc/xdg/lxsession/LXDE-pi/autostart
```
Fügen den folgenden Code ein, wobei ```YOUR_LOCAL_IP``` die Netzwerkadresse des Pi und ```YOUR_PORT``` der exponierte Port des Node Red Containers ist:
