Update 04. Prototyp – Vorgehen & Implementierung authored by Philipp Straub's avatar Philipp Straub
......@@ -4,7 +4,11 @@
## Vorgehen
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.
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 dessen, dass voraussichtlich keine Scrollbots zur Verfügung stehen würden, haben wir uns frühzeitig dazu entschieden, auf 7"-Displays zu wechseln.
Diese Entscheidung beeinflusste die entworfene Architektur/das Konzept insoweit, dass von einem Python-Script zu einer Webpage für die Darstellung der Reaktionen gewechselt wurde. Ursprünglich war geplant, für das Senden der Reaktionen eine Webpage bereitzustellen, welche über Websockets mit dem MQTT-Broker HiveMQ kommuniziert. Diese Reaktionen sollten anschließend über das Script ausgelesen werden. Da sich unser Team mit dem Wechsel auf 7"-Displays ebenfalls dazu entschlossen hat, auf einen lokalen MQTT-Broker zur Förderung der Unabhängigkeit und Sicherheit der Lösung umzusteigen, beeinflusste diese Entscheidung ebenfalls die Lösungsarchitektur für das Senden von Reaktionen. Um zusätzlichen Implementationsaufwand der Websockets zu vermeiden und eine einheitliche Architektur auf beiden Seiten zu entwickeln, wurde die Funktionalität hinter der Webpage verworfen. Aufgrund der Vielseitigkeit bei gleichzeitig einfacher Implementierung wurde daher auf Node-RED zurückgegriffen und die Funktionalität für das Senden von MQTT-Nachrichten in ein **Backend** eingelagert, welches über HTTP-Schnittstellen nach außen erreichbar ist. Über diese Schnittstellen ist sowohl das **Frontend**, als auch weitere Informationen zugänglich, auf welche das Frontend wiederum selbst zugreift.
Hierbei stellte es sich als **Herausforderung** dar, die Problematik von zustandsloser (HTTP) zu zustandsbasierter Kommunikation (MQTT) zu überwinden. Dies ist insofern ein Problem, als das bei einer zustandslosen Kommunikation kein physischer Zwilling erzeugt werden kann. So wurden verschiedene Lösungsansätze implementiert, um bspw. zu erkennen, dass die Verbindung für das Senden von Reaktionen beendet wurde, um nicht die Anzeige für das Darstellen von Reaktionen unnötig zu belegen und diese Problematik zu überwinden. Antrieb war dabei vor allem die **Technologie-Unabhängigkeit** von Webanwendungen, um den Prototypen auf so vielen Endgeräten wie möglich einsatzfähig zu machen. So wird mit dem neuen Ansatz der Kerngedanke der Lösung, den Studierenden im Vorlesungsraum zu Präsenz zu verhelfen, abgedeckt, indem dieser durch ein 7"-Display repräsentiert wird, und prototypisch umgesetzt.
## Implementierung
### Allgemeine Informationen
......
......