MQTT¶
Als Protokoll für die Kommunikation zwischen den Geräten und dem Backend wird MQTT verwendet. Durch seinen geringen Overhead ist das Protokoll leichtgewichtig und eignet sich gut für IoT-Umgebungen – im Action-Connect-Kontext, insbesondere für kleine Mikrocontroller in schwachen WLAN-Verbindungen.
Dabei kommunizieren die Geräte als Clients nie direkt miteinander, sondern immer über einen Broker. Clients können Daten an bestimmte Topics publizieren (publish) oder bestimmte Topics lesen (subscribe), um Nachrichten zu empfangen.
Broker¶
Als zentraler Broker der MQTT-Kommunikation wird Mosquitto verwendet, ein quelloffener MQTT-Broker, der in einem Docker-Container betrieben wird. Er ist leichtgewichtig und einfach zu konfigurieren.
Topics¶
Die Action-Connect-Plattform verwendet folgende Topics für die Kommunikation zwischen den Geräten und dem Backend:
devices/register: Topic für die Registrierung eines Geräts; das Gerät sendet hierüber sein Thing Model an das Backend.devices/<mac>/telemetry: Topic für Telemetrie-Daten, die von den Geräten an das Backend gesendet werden.devices/<mac>/command: Topic für Befehle, die vom Backend an die Geräte gesendet werden.devices/<mac>/status: Topic für den Verbindungsstatus des Geräts (online/offline), der vom Gerät bzw. per LWT gesetzt wird.
Last Will and Testament (LWT)¶
MQTT bietet die Möglichkeit, eine Last-Will-and-Testament-Nachricht (LWT) zu definieren, die der Broker veröffentlicht, wenn ein Client die Verbindung unerwartet verliert. Durch das ESP-Framework wird die LWT-Nachricht automatisch so konfiguriert, dass bei einem Verbindungsverlust zum Broker auf dem Status-Topic der Wert „offline" veröffentlicht wird.
Payloads¶
Telemetrie-Daten¶
Möchte ein Gerät Telemetrie-Daten an das Backend senden, so werden diese in Form eines JSON-Objekts an das Topic devices/<mac>/telemetry publiziert. Das JSON-Objekt folgt dabei dem nachfolgenden Schema:
Timestamps
Wird das Feld timestamp nicht gesetzt, ergänzt das Backend automatisch den aktuellen Zeitpunkt.
Das Feld data enthält die Telemetrie-Werte der Capabilities, die das Gerät an das Backend sendet. Dabei können ein einzelner oder mehrere Capability-Werte im JSON-Objekt enthalten sein.
Command-Daten¶
Möchte ein User über das Backend einen Befehl an ein Gerät senden, kann das Frontend per REST-API einen POST-Request an das Backend senden.
Das Backend erstellt daraufhin ein Command-Objekt und publiziert dieses an das Topicdevices/<mac>/command.
{
"command_id": "9f1c2e7a-4b1d-4e2a-8f3c-1a2b3c4d5e6f",
"capability": "brightness",
"value": 80,
"timestamp": "2026-07-15T12:00:00.000Z"
}
command_id ermöglicht es einem Gerät, den Befehl eindeutig zu identifizieren und doppelte Ausführungen zu vermeiden.
Das Feld timestamp enthält den Zeitpunkt, zu dem das Backend den Befehl erstellt hat. Ein Gerät kann darüber prüfen, ob ein Befehl noch aktuell ist.
Die geräteseitige Auswertung von command_id und timestamp ist derzeit noch nicht implementiert.
ACL & Security¶
Damit nicht jedes Gerät – insbesondere keine fremden Geräte außerhalb des Action-Connect-Systems – auf die Topics zugreifen kann, werden die Zugriffe über eine Access Control List (ACL) geregelt. Die ACL wird in der Konfigurationsdatei des Mosquitto-Brokers definiert und stellt sicher, dass nur authentifizierte Geräte auf die Topics zugreifen. Auf eine Offenlegung der konkreten Konfiguration wird an dieser Stelle aus betrieblichen Gründen verzichtet; sie ist in der technischen Präsentation beschrieben.
Das Backend bekommt jegliche Lese- und Schreibrechte auf alle Topics, um die Telemetrie-Daten der Geräte zu empfangen und Befehle an die Geräte zu senden.
Die Geräte bekommen nur Lese- und Schreibrechte auf die Topics, die für sie relevant sind.
Das Frontend besitzt für die MQTT-Kommunikation als Gateway im Bluetooth-Fallback erweiterte Lese- und Schreibrechte auf die Geräte-Topics, um mehrere Geräte gleichzeitig steuern zu können.
