MQTT2 CLIENT

Aus FHEMWiki
Wechseln zu: Navigation, Suche
MQTT2_CLIENT
Zweck / Funktion
Stellt als Gateway die Verbindung zu einem MQTT-Broker her
Allgemein
Typ Gerätemodul
Details
Dokumentation EN / DE
Support (Forum) MQTT
Modulname 10_MQTT2_CLIENT.pm
Ersteller rudolfkoenig (Forum / Wiki)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Das Modul MQTT2_CLIENT ermöglicht es, Geräte einzubinden, die über eine MQTT-Schnittstelle verfügen.

Das Modul MQTT2_CLIENT fungiert als Verbindung zwischen FHEM und einem externen MQTT Server (z.B. mosquitto) und repräsentiert ein MQTT Gateway. Die durch die Module MQTT2_DEVICE oder MQTT_GENERIC_BRIDGE repräsentierten Client-Geräte sind gesondert anzulegen.

Voraussetzungen

Es muss für jedes MQTT-Gateway ein MQTT-Server eingerichtet und erreichbar sein. Eine Anleitung zur Einrichtung eines Mosquitto-Brokers finden Sie z.B. im Artikel MQTT Einführung.

Info blue.png
FHEM selbst kann ebenfalls mit MQTT2_SERVER als MQTT-Server eingesetzt werden. In diesem Fall ist innerhalb dieser FHEM-Instanz kein MQTT2_CLIENT-Gerät erforderlich. Befindet sich ein MQTT2_SERVER in einer anderen FHEM-Instanz, kann dieser von dort aus mit MQTT2_CLIENT verbunden werden.


Kurzübersicht

Info blue.png
Eine Übersicht über die verschiedenen Möglichkeiten, MQTT in FHEM zu nutzen, ist in MQTT#FHEM und MQTT zu finden.


Define

Das MQTT Gateway wird angelegt mit define 'meinMQTT2Client MQTT2_CLIENT <host>:<port>


Info blue.png
Sofern der MQTT-Server mit FEHM über localhost kommunizieren kann, sollte als IP 127.0.0.1 verwendet werden.


Anwendung

Danach können entsprechende Client-Devices angelegt werden, MQTT2_DEVICE wird verwendet, wenn das physikalische Device (Sensor oder Aktor) über mqtt kommuniziert, wie dieses z.B. bei vielen ESP8266-basierten Geräten der Fall ist.

Info green.png Für weitere bridge-Geräte wird bei Verwendung des MQTT2_CLIENT empfohlen, die betreffenden templates jeweils auf eine Kopie des "Sammeldevices" anzuwenden und dabei vorab die CID auf einen anderen Wert festzulegen als die ClientID des MQTT2_CLIENT-Geräts[1]! Hat man neue Geräte mit bridgeRegexp-Einträgen erstellt oder die bridgeRegexp-Einträge verändert, kann in der Regel gefahrlos zunächst die readingList am "Sammeldevice" gelöscht werden, so dass dann eingehende Nachrichten auch tatsächlich gegen die bridgeRegexp geprüft werden müssen.

Möchte man autocreate verwenden, um automatisiert MQTT2_DEVICE-Geräte anlegen zu lassen, empfiehlt es sich, auf das erste automatisch angelegte Gerät das template MQTT2_CLIENT_general_bridge anzuwenden. Dadurch werden bestimmte eingehenden MQTT-Messages für eine Anzahl häufig anzutreffender Gerätetypen in separate, automatisch angelegte MQTT2_DEVICE-Geräte umgeleitet[2].

Info blue.png
Da hierzu die typischen Topicstrukturen und Benennungen genutzt werden, sollten die MQTT-Einstellungen hinsichtlich des topictrees auf den Geräten auf den jeweiligen defaults belassen werden.


Das attrTemplate MQTT2_CLIENT_general_bridge löscht die readingList des Geräts, auf das es angewendet wird und erstellt ein neues Device, das dann die beschriebene bridgeRegexp enthält. Dies muß nur einmalig erfolgen, für alle weiteren - mittels bridgeRegexp erstellten - Geräte gilt dann - mit o.g. Einschränkungen bei der Erstellung von weiteren bridge-Geräten - das allgemeine Vorgehen für MQTT2_DEVICE, z.B. auch die Festlegung weiterer Geräten mit bridgeRegexp-Attributen wie in den Praxisbeispielen beschrieben.

Will man Geräte unterscheiden, die sich nur z.B im ersten Teil der Topic-Struktur unterscheiden, kann man dies durch Anpassung der bridgeRegexp erreichen oder dadurch, dass man die betreffenden Geräte manuell anlegt. Dabei sollte man jedoch tendenziell sehr restriktive bridgeRegexp-Ausdrücke verwenden[3].

Anmerkungen

  1. Um eine Kopie des MQTT2_CLIENT_general_bridge-Geräts zu erstellen, empfielt sich der RAW-Editor, beachten Sie hierzu aber die Hinweise zur Änderung der CID!
  2. Näheres zur Entstehung der derzeitigen bridgeRegexp des templates MQTT2_CLIENT_general_bridge sind diesem Forenthread zu entnehmen.
  3. Zum Hintergrund siehe diese Forendiskussion