MQTT

MQTT ist ein Protokoll ("Message Queue Telemetry Transport"), mit dem Daten und Befehle zwischen verschiedenen Geräten ausgetauscht werden. Die Kommunikation erfolgt dabei über einen Broker, den so genannten MQTT-Broker.

MQTT wurde entwickelt, um möglichst effizient, sicher und mit wenig Datenlast zu kommunizieren.

Eine sehr kurze Einführung in MQTT

...ist auf dieser Seite hier zu finden.

FHEM und MQTT

Bitte allgemein beachten: Bei Verwendung von MQTT ist unbedingt darauf zu achten, dass die Topic-Struktur in Sende- und Empfangsrichtung unterschiedlich ausgestaltet ist. Andernfalls kommt es ggf. zu unbeabsichtigten Schleifen!

Für die Nutzung von MQTT muss ein zentraler MQTT-Server (Broker in alter Nomenklatur) verfügbar sein. Dies kann ein separater Serverdienst wie mosquitto sein, FHEM selbst kann mit Hilfe des Moduls MQTT2_SERVER selbst die Funktion des Brokers übernehmen. Dieser bietet zwar weniger Optionen als ein vollwertiger MQTT-Server, ist jedoch für kleinere Installationen völlig ausreichend. Ein MQTT-Server kann eine Vielzahl von FHEM-Installationen bedienen.

MQTT2

Seit November 2018 ist es mit MQTT2_CLIENT möglich, MQTT2_DEVICE-Geräte einzurichten, ohne dass MQTT2_SERVER auf derselben Installation vorhanden sein muss. MQTT2_CLIENT kann auch mit einem klassischen Broker wie mosquitto betrieben werden.

Kurzübersicht:

a) MQTT-Gerät, z.B. ein Shelly oder Sonoff <=> MQTT2_SERVER <=> MQTT2_DEVICE

b) MQTT-Gerät, z.B. ein Shelly oder Sonoff <=> (externer) MQTT-Server, z.B. mosquitto <=> MQTT2_CLIENT <=> MQTT2_DEVICE

Weitere Hinweise zur Verwendung der MQTT2-Module sind in den Praxisbeispielen zu finden.

MQTT2_SERVER und MQTT2_CLIENT ermöglichen - im Unterschied zur klassischen Einbindung - passwortgeschütze Datenübertragungen zwischen den einzelnen Komponenten.

Klassische Einbindung

Wird in obiger MQTT Einführung beschrieben, Kurzübersicht: MQTT-Gerät, z.B. ein Sonoff <=> (externer) MQTT-Server, z.B. mosquitto <=> MQTT <=> MQTT_DEVICE

MQTT_GENERIC_BRIDGE

Das Modul MQTT_GENERIC_BRIDGE kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit MQTT2_SERVER bzw. MQTT2_CLIENT oder MQTT.

Dabei sollte man jedoch beachten, dass zur Verwendung mit den MQTT2-IO's unbedingt die autocreate-Funktion des betreffenden IOs ausgeschaltet wird und dies auch bleibt! Weiter wird das Perl-Modul libmodule-pluggable-perl benötigt, damit im Hintergrund auch das Modul MQTT geladen werden kann.

Performancefragen...

...oder was sollte man als Lösung wählen, wenn man in die MQTT-Welt einsteigt? Grundsätzlich sollte man davon ausgehen, dass innerhalb von FHEM die Verarbeitung derselben Daten näherungsweise denselben Aufwand bedeuten, unabhängig davon, welche der Implementierungen (MQTT2_CLIENT, MQTT oder MQTT2_SERVER) man konkret wählt. Ein externer Broker hat daher vor allem dann Vorteile, wenn die MQTT Daten überwiegend für was anderes (nicht FHEM) verwendet werden, oder MQTT zweckentfremdet wird (wie z.Bsp. für Musikübertragung). Nutzt man das MQTT-Protokoll dagegen vorwiegend innerhalb von FHEM, ist eher der Einsatz von MQTT2_SERVER in Betracht zu ziehen. Dieser soll Anfängern die Anbindung von MQTT Geraeten in FHEM einfacher machen. Wer später merkt, dass er doch einen externen Broker benötigt, kann dann immer noch auf MQTT2_CLIENT iVm. einem anderen Broker wechseln. Dagegen ist der Weg von MQTT_DEVICE zu MQTT2_DEVICE mit erheblich mehr Aufwand verbunden.

Links

• Thread, zur Entstehungsgeschichte von MQTT2_CLIENT
• Ankündigungsthread zur MQTT2-Erweiterung der MQTT_GENERIC_BRIDGE