Update 04. Prototyp – Vorgehen & Implementierung authored by Jonas Pfaff's avatar Jonas Pfaff
...@@ -15,7 +15,7 @@ Zur Implementierung des MVP wurde verschiedene Standardsoftware verwendet. Auf H ...@@ -15,7 +15,7 @@ Zur Implementierung des MVP wurde verschiedene Standardsoftware verwendet. Auf H
- **Mosquitto** als MQTT-Broker - **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. 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 UUID 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 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. 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.
...@@ -29,15 +29,18 @@ Auf diesem Gerät läuft der MQTT-Broker (Mosquitto Container). Damit bildet die ...@@ -29,15 +29,18 @@ Auf diesem Gerät läuft der MQTT-Broker (Mosquitto Container). Damit bildet die
![InteractorStep_Main_device](uploads/a3c8128cea8f298390445657e0fc0f30/InteractorStep_Main_device.png) ![InteractorStep_Main_device](uploads/a3c8128cea8f298390445657e0fc0f30/InteractorStep_Main_device.png)
### Aufbau Reactor (auf Nebengeräten) ### Aufbau Reactor (auf Nebengeräten)
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. 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 ID darstellt. Die ID wird verwendet um den Reactor zu wählen, der die Nachricht anzeigen soll. Hierbei gewinnt immer die numerisch höchste ID.
![reactor_Stack_secondary](uploads/06c600925aaed15f457493067e59d580/reactor_Stack_secondary.png) ![reactor_Stack_secondary](uploads/06c600925aaed15f457493067e59d580/reactor_Stack_secondary.png)
#### Reactor Management #### Reactor Management
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. 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.
# TODO: Sequenzdiagramme oben einfügen ![Flow has the highest ID](uploads/da88d7d4fbd3f76e896ca4082a77fc36/Flow_has_highest_UUID.svg)
Highest ID
![Flow_has_lower_ID.svg](uploads/3bf6586bcc18fd88d40bb872930d8bf6/Flow_has_lower_ID.svg)
Lower ID
### Kommunikation zwischen Services ### 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. 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.
![Communication](uploads/cc24fb7a0badc116bdd27873f97fd00f/Communication.png) ![Communication](uploads/cc24fb7a0badc116bdd27873f97fd00f/Communication.png)
... ...
......