MQTT2 CLIENT: Unterschied zwischen den Versionen

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!

Aktuelle Version vom 24. November 2022, 17:51 Uhr

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 <meinMQTT2ClientName> MQTT2_CLIENT <host>:<port> [<username>] [<password>]

Sofern der MQTT-Server mit FHEM ü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^[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" (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^[2].

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^[3].

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ä).

Anmerkungen

↑ Dabei empfielt sich der RAW-Editor, beachten Sie hierzu aber die Hinweise zur Änderung der CID!
↑ Näheres zur Entstehung der derzeitigen bridgeRegexp des templates MQTT2_CLIENT_general_bridge sind diesem Forenthread zu entnehmen.
↑ Zum Hintergrund siehe diese Forendiskussion

[1] Dabei 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

[1]

[2]

[3]

@@ Zeile 6: / Zeile 6: @@
 |ModTechName=10_MQTT2_CLIENT.pm
 |ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])}}
-Das Modul {{Link2CmdRef|Anker=MQTT2_CLIENT|Lang=en|Label=MQTT2_CLIENT}} ermöglicht es, Geräte einzubinden, die über eine MQTT-Schnittstelle verfügen.
+Das Modul [[MQTT2_CLIENT]] ermöglicht es, Geräte einzubinden, die über eine MQTT-Schnittstelle verfügen. Es fungiert als [[Interface|Verbindung]] zwischen FHEM und einem externen MQTT Server (z.B. ''mosquitto'') und repräsentiert ein  '''''MQTT Gateway'''''. Die durch die Module [[MQTT2_DEVICE]] oder {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} repräsentierten Client-Geräte sind gesondert anzulegen.
-Das Modul {{Link2CmdRef|Anker=MQTT2_CLIENT|Lang=en|Label=MQTT2_CLIENT}} fungiert als [[Interface|Verbindung]] zwischen FHEM und einem externen MQTT Server (z.B. ''mosquitto'') und repräsentiert ein  '''''MQTT Gateway'''''. Die durch die Module [[MQTT2_DEVICE]] oder {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} repräsentierten Client-Geräte sind gesondert anzulegen.
 == Voraussetzungen ==
@@ Zeile 20: / Zeile 18: @@
 == Define ==
 Das MQTT Gateway wird angelegt mit
-<code>define '''meinMQTT2Client'' MQTT2_CLIENT <host>:<port></code>
+<code>define <meinMQTT2ClientName> MQTT2_CLIENT <host>:<port> [<username>] [<password>]</code>
-{{Hinweis|Sofern der MQTT-Server mit FEHM über localhost kommunizieren kann, sollte als IP 127.0.0.1 verwendet werden.}}
+{{Hinweis|Sofern der MQTT-Server mit FHEM über localhost kommunizieren kann, sollte als IP 127.0.0.1 verwendet werden.}}
 == Anwendung ==
-Danach können entsprechende Client-Devices angelegt werden,
+Danach können entsprechende Client-Devices angelegt werden, in der Regel als [[MQTT2 DEVICE|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.
-[[MQTT2 DEVICE|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.
-{{Randnotiz|RNTyp=g|RNText=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<ref>Um eine Kopie des MQTT2_CLIENT_general_bridge-Geräts zu erstellen, empfielt sich der [[Import von Code Snippets|RAW-Editor]], beachten Sie hierzu aber die Hinweise zur Änderung der CID!</ref>! 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 [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|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<ref>Näheres zur Entstehung der derzeitigen bridgeRegexp des templates ''MQTT2_CLIENT_general_bridge'' sind diesem {{Link2Forum|Topic=98126|LinkText=Forenthread}} zu entnehmen.</ref>.
+=== autocreate und bridgeRegexp ===
+{{Randnotiz|RNTyp=g|RNText=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<ref>Dabei empfielt sich der [[Import von Code Snippets|RAW-Editor]], beachten Sie hierzu aber die Hinweise zur Änderung der CID!</ref>! 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 [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|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<ref>Näheres zur Entstehung der derzeitigen bridgeRegexp des templates ''MQTT2_CLIENT_general_bridge'' sind diesem {{Link2Forum|Topic=98126|LinkText=Forenthread}} zu entnehmen.</ref>.
 {{Hinweis|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 [[MQTT2-Module - Praxisbeispiele|Praxisbeispielen]] beschrieben, dorft findet sich auch ein Abschnitt zum Attribut [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]] allgemein.
+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 [[MQTT2-Module - Praxisbeispiele|Praxisbeispielen]] beschrieben, dort findet sich auch ein Abschnitt zum Attribut [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|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<ref>Zum Hintergrund siehe diese {{Link2Forum|Topic=98206|LinkText=Forendiskussion}}</ref>.
+=== 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:
+<code>attr MQTT2_Mosquitto_Client ignoreRegexp cmnd/[^:"]+:|homeassistant/[^:"]+/config:|shellies/[^:"]+/command:|zigbee2mqtt/[^/]+/set:|milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]:|tasmota/discovery/</code>
+{{Hinweis|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ä).}}
 == Anmerkungen ==