MQTT

	An dieser Seite wird momentan noch gearbeitet.

Ein systematischer Gesamtüberblick, der alle einsetzbaren Module berücksichtigt, ist seit kurzem in MQTT_Einführung zu finden. Der final hier zu findende Artikel soll dann die dortigen Informationen mit den hier vorhandenen kombinieren.

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 Serverdienst, 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

MQTT wird ausführlich auf diesen diesen Wikiseiten erklärt. Eine FHEM-orientierte Einführung findet man auf dieser Seite.

FHEM und MQTT

MQTT benötigt für den Betrieb (mindestens) einen zentralen Serverdienst, der früher Broker genannt wurde. Ein solcher Server kann extern (also außerhalb von FHEM, zum Beispiel mosquitto) als auch durch FHEM selbst bereitgestellt werden.

Damit FHEM als Server für MQTT funktioniert, muss ein Modul aktiviert werden, das die Aufgabe des zentralen Serverdienst ("Brokers") übernimmt. Es handelt sich um das Modul MQTT2_SERVER.^[1] Dieser FHEM-eigene Server bietet weniger Optionen als ein vollwertiger MQTT-Server wie mosquitto, ist jedoch für kleinere Installationen völlig ausreichend. Ein MQTT-Server kann mehrere FHEM-Installationen bedienen^[2].

Einbindung mit externem Broker

Wird in der MQTT Einführung beschrieben:

Für die Kommunikation zwischen einem MQTT-fähigen Objekt und dem Broker ist der Broker zuständig (außerhalb von FHEM). Die Kommunikation zwischen Broker und FHEM geschieht via dem IO-Modul 00_MQTT.pm oder dem IO-Modul MQTT2_CLIENT(so genannte physikalische Stufe, siehe dazu Erläuterung zum Zwei-Stufen-Modell). Damit innerhalb von FHEM das Objekt angesprochen werden kann, muss es weiter in FHEM ein Gerät vom Typ MQTT_DEVICE geben, das die Befehle vom Objekt entgegennimmt bzw. an das Objekt sendet.

Einbindung mit MQTT2 von FHEM

Hier gilt das oben gesagte, wobei nun die Kommunikation zwischen dem MQTT-fähigen Objekt und dem Broker durch FHEM selbst bereitgestellt wird. Dazu muss in FHEM ein Gerät z.B. mit dem Namen myBroker

defmod mybroker MQTT2_SERVER 1883 global

angelegt werden (die Zahl 1883 bezieht sich auf den Port, auf dem MQTT arbeitet).

Seit November 2018 ist es mit MQTT2_CLIENT^[3] 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.

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 - passwort- und SSL- geschütze Datenübertragungen zwischen den einzelnen Komponenten.

Kommunikation zu sonstigen FHEM-Geräten über MQTT

Möchte man Daten von einem Gerät (im FHEM-Sinn), das nicht vom Typ MQTT2_DEVICE oder MQTT_DEVICE (je nach IO-Modul) ist, per MQTT versenden (z.B. für eine andere Visualisierungslösung als FHEMWEB, oder als FHEM2FHEM-Ersatzlösung), oder diese sonstigen Geräte über MQTT-Anweisungen von außen steuern können, hat man mehrere Möglichkeiten:

MQTT_GENERIC_BRIDGE

Das Modul MQTT_GENERIC_BRIDGE ermöglicht es, sein jeweiliges IO-Modul-Gerät zu nutzen, um diesen Kommunikationsweg für beliebig viele andere FHEM-Geräte bereitzustellen. Dabei erfolgt am MQTT_GENERIC_BRIDGE-Gerät selbst nur eine Basiskonfiguration, im Übrigen durch Attribute an dem jeweiligen Gerät selbst. So kann z.B. ein Aktor des Typs CUL_HM an- oder ausgeschaltet werden oder auch einfach nur seinen aktuellen Schaltzustand per MQTT publizieren.

Dieses Modul kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit MQTT2_SERVER bzw. MQTT2_CLIENT oder MQTT (00_MQTT.pm).

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^[4]! Weiter wird das Perl-Modul libmodule-pluggable-perl benötigt^[5], damit im Hintergrund auch das Modul MQTT geladen werden kann.

Anwendungsfälle und -beispiele für das Modul sind diesem Thread zu entnehmen.

MQTT_BRIDGE

Dieses Modul kann nur zusammen mit einem IO-Gerät des Typs MQTT verwendet werden. Dabei wird pro weiterzuleitendem anderen FHEM-Gerät eine eigene Instanz dieses Moduls verwendet. Auf den Einsatz dieser Option sollte in neuen Installationen zugunsten von MQTT_GENERIC_BRIDGE verzichtet werden.

Per publish-Befehl am IO-Gerät

Alle drei IO-Module kennen direkte publish-Anweisungen, mit deren Hilfe beliebige payloads an beliebige topics gesendet werden können. Dies kann man z.B. in einem notify nutzen, um einzelne Events zu publishen.

RAW-Events am IO-Gerät (MQTT2.*)

Bei beiden MQTT2-IO-Modulen (MQTT2_SERVER und MQTT2_CLIENT) kann per regulärem Ausdruck festgelegt werden, welche Nachrichten ein Event erzeugen sollen, auf das dann wieder z.B. mit einem notify reagiert werden kann, z.B. um beliebige Schaltaktionen auszulösen.

Performancefragen...

...oder was sollte man als Lösung wählen, wenn man in die MQTT-Welt einsteigt^[6]? 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 in Verbindung mit einem anderen Broker wechseln. Dagegen ist der Weg von MQTT_DEVICE zu MQTT2_DEVICE mit erheblich mehr Aufwand verbunden.

Probleme

- asynchrone Kommunikation: Rückgemeldetes Ergebnis kann von der gesendeten Anweisung abweichen - unbeabsichtigte Loops durch Fehler in der topic-Struktur

Links

Hinweise

↑ Die Zahl 2 an FHEM bedeutet nicht, dass es sich um eine neuere Protokollversion für FHEM handelt (also nicht so etwas wie MQTT 2.0), sondern das erst kürzlich MQTT in FHEM integriert wurde.
↑ Dies gilt sowohl für einen klassischen Broker wie für einen MQTT2_SERVER.
↑ commandref
↑ siehe dazu diesen Thread zu den technischen Hintergründen
↑ Dieses kann über apt-get install libmodule-pluggable-perl installiert werden
↑ vgl. hierzu diesen Beitrag von Rudolf König

[1] Die Zahl 2 an FHEM bedeutet nicht, dass es sich um eine neuere Protokollversion für FHEM handelt (also nicht so etwas wie MQTT 2.0), sondern das erst kürzlich MQTT in FHEM integriert wurde.

[2] Dies gilt sowohl für einen klassischen Broker wie für einen MQTT2_SERVER.

[3] ref

[4] siehe dazu diesen Thread zu den technischen Hintergründen

[5] Dieses kann über apt-get install libmodule-pluggable-perl installiert werden

[6] vgl. hierzu diesen Beitrag von Rudolf König

[1]

[2]

[3]

[4]

[5]

[6]