Architektur¶
Schichtenmodell¶
Datenfluss¶
Über das Backend kommunizieren die Geräte bidirektional mit den Benutzeroberflächen. Die Geräte senden Telemetrie-Daten über MQTT an das Backend, ein Nutzer kann über die Oberfläche Befehle mittels REST-API an das Gerät senden. Das Backend vermittelt zwischen beiden Schichten.
Telemetrie¶
Ein Gerät publiziert seine Messwerte über MQTT. Das Backend nimmt sie entgegen und sendet die Daten sofort als ein Live-Ereignis über den WebSocket, damit ein Dashboard ohne Verzögerung aktualisiert wird. Parallel legt es die Werte in eine Queue, die die Telemetrie asynchron in die Datenbank schreibt. Auf demselben Weg prüft die Rule-Engine die eingehenden Werte gegen aktive Automationsregeln.
Befehle¶
Ein Frontend schickt einen Befehl über die REST-API. Das Backend übersetzt ihn in eine MQTT-Nachricht auf dem Command-Topic des Zielgeräts. Derselbe Weg wird genutzt, wenn eine Automationsregel eine Aktion auslöst.
sequenceDiagram
participant Geraet as Gerät
participant Backend as Backend
participant DB as Datenbank
participant UI as Oberfläche
Note over Geraet,UI: Telemetrie
Geraet->>Backend: Telemetrie (MQTT)
Backend-->>UI: Live-Update (WebSocket)
Backend->>DB: asynchron speichern (Queue)
Note over Geraet,UI: Befehl
UI->>Backend: Command (REST)
Backend->>Geraet: Command (MQTT)
Roundtrip als ACK¶
Die Plattform benötigt durch die Architketur keine direkte Rückmeldung mittels ACK vom Gerät.
Wird ein Befehl gesendet und wird dieser erfolgreich vom Gerät verarbeitet bzw. ausgeführt, sendet dieses die veränderten Werte als Telemetrie zurück. Das Backend leitet diese an die Oberfläche weiter, sodass der Nutzer die erfolgreiche Ausführung des Befehls sieht.
Services & Deployment¶
Reverse Proxy¶
Als zentraler Einstiegspunkt für alle Anfragen an die Action-Connect-Plattform wird Traefik als Reverse Proxy eingesetzt. Er leitet die Anfragen an die jeweiligen Dienste weiter und kann bei einer Skalierung des Systems zusätzlich als Load Balancer dienen.
Ein Vorteil dieses Ansatzes ist, dass der Server nach außen nur einen Port öffnen muss und die Ports der einzelnen Dienste verborgen bleiben, was die Sicherheit erhöht. Zudem kann der Proxy die TLS-Terminierung übernehmen, sodass die Dienste im Backend TLS nicht selbst implementieren müssen. In der aktuellen Konfiguration wird TLS allerdings bereits außerhalb der Action-Connect-VM durch einen vorgelagerten Apache-Proxy terminiert.
Im Action-Connect-System wird nicht ausschließlich über HTTP kommuniziert: Die MQTT-Kommunikation zwischen ESP und Backend läuft über TCP, das Traefik ebenfalls routen kann.
Konfiguration¶
Da alle Dienste in Docker-Containern desselben Docker-Daemons laufen, gestaltet sich die Konfiguration des Reverse Proxys unkompliziert: Traefik erkennt die Container automatisch und richtet die Routen entsprechend ein. Dazu müssen die Container lediglich mit den passenden Labels versehen werden.
services:
frontend:
# ...
labels:
- "traefik.enable=true"
- "traefik.http.routers.frontend.rule=Host(`finishing2026.sw2e-lab.de`)"
- "traefik.http.routers.frontend.entrypoints=web"
- "traefik.http.routers.frontend.middlewares=secure-headers@file"
- "traefik.http.services.frontend.loadbalancer.server.port=80"
Nach Abschluss der Konfiguration sind die Dienste über die zugehörigen Hostnamen erreichbar. Alle eingerichteten Routen lassen sich über das Dashboard von Traefik einsehen.
Basic Auth¶
Um die sensibleren Web-Dienste im Backend vor unbefugtem Zugriff zu schützen, wird eine Basic-Authentifizierung eingesetzt. Sie wird in der Konfiguration des Reverse Proxys hinterlegt und verlangt bei jedem Zugriff auf die geschützten Dienste die Eingabe von Benutzername und Passwort.
Derzeit sind die Dozzle-Logs und das Traefik-Dashboard mit Basic Auth geschützt. Die Zugangsdaten werden in der Konfiguration des Reverse Proxys hinterlegt.
Docker-Netzwerke¶
Um die Dienste voneinander zu isolieren, die Kommunikation zwischen bestimmten Containern – wie etwa zwischen Frontend und Backend – gezielt zu ermöglichen und die Sicherheit durch Netzwerkisolation zu erhöhen, werden Docker-Netzwerke eingesetzt. In der aktuellen Konfiguration existieren zwei zentrale Netzwerke:
edge– das Reverse-Proxy-Mesh, über das Traefik alle von außen erreichbaren Web-Dienste anbindet (Frontend, Admin-Dashboard, Grafana, Backend, Dokumentation, MQTT-over-WebSocket).backend– das interne Datennetz für die Kommunikation der Backend-Dienste untereinander (Backend, PostgreSQL, Redis, Dozzle) ohne direkten Zugriff von außen.
Einzelne Dienste wie das Backend und der Mosquitto-Broker sind in beiden Netzwerken vertreten, da sie sowohl von außen erreichbar sein als auch intern kommunizieren müssen.
Der CI-Upload der Android-Releases läuft zusätzlich in einem eigenen Netzwerk (releases_default).


