MQTT2 CLIENT

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. Es 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.

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

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>

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, in der Regel als MQTT2_DEVICE. Dabei kann ein physikalisches Device (Sensor oder Aktor), das über mqtt kommuniziert (z.B. ein ESP8266- oder ESP32-basiertes Gerät), ein oder mehrere Devices des Typs MQTT2_DEVICE entsprechen.

autocreate und bridgeRegexp

Für weitere bridge-Geräte wird bei Verwendung des MQTT2_CLIENT empfohlen, die betreffenden templates jeweils auf eine Kopie des "Sammeldevices" MQTT2_CLIENT_general_bridge anzuwenden und dabei vorab die CID auf einen anderen Wert festzulegen als die ClientID des MQTT2_CLIENT-Geräts! 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" (bzw. der MQTT2_CLIENT_general_bridge) 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 anschließend bestimmte eingehenden MQTT-Messages für eine Anzahl häufig anzutreffender Gerätetypen in separate, automatisch angelegte MQTT2_DEVICE-Geräte umgeleitet.

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 ergänzt das Device mit der beschriebenen bridgeRegexp. 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, dort findet sich auch ein Abschnitt zum Attribut bridgeRegexp allgemein.

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.

ignoreRegexp

Da ein externer MQTT-Server auch alle ausgehenden Anweisungen wieder an alle Clients zurückliefert, führt dies iVm. autocreate dazu, dass in vielen Fälle Events doppelt - und überdies in Teilen sachlich falsch - erzeugt werden. Um nur die Rückmeldung des Geräts über den Vollzug der Anweisung auszuwerten und die ausgehenden Informationen zu verwerfen, kann man am Interface ein ignoreRegexp setzen. Für typische Befehlsstrukturen von Tasmota, Shelly und zigbee2mqtt sowie das Auswerten von - für HomeAssistant gedachten - autodiscovery-Meldungen wäre z.B. folgendes ignoreRegexp zu verwenden:

attr MQTT2_Mosquitto_Client ignoreRegexp cmnd/[^:"]+:|homeassistant/[^:"]+/config:|shellies/[^:"]+/command:|zigbee2mqtt/[^/]+/set:|milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]:|tasmota/discovery/

Dieses Attribut wäre auch an einem MQTT2_SERVER sinnvollerweise entsprechend zu setzen, wenn über diesen andere (Software-)Client-Systeme angebunden werden, die ebenfalls direkt MQTT-Anweisungen an die anderen Clients senden können sollen. Beispiele wären verteilte Systeme mit MQTT2_CLIENT auf entfernten FHEM-Installationen oder die Verwendung von MQTT-basierten User-Interfaces (NodeRed oä).