Quelltext der Seite MQTT2-Module - Praxisbeispiele

== Einführung: MQTT bzw. MQTT2 in FHEM ==
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT verwenden, beachten Sie bitte, dass der MQTT2_CLIENT die ursprüngliche Herkunft der über MQTT verteilten Informationen nicht kennt. Daher ergeben sich in der Anwendung kleinere Unterschiede, zu deren Verständnis die diesbezüglichen [[MQTT2_CLIENT#Anwendung|Hinweise zu MQTT2_CLIENT]] bekannt sein sollten.}}Zur Einbindung von Geräten, welche zur Nutzung des MQTT-Protokols konfiguriert werden können und darüber mit einem MQTT-Server (früher: Broker) kommunizieren, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser [[MQTT|Übersicht]] zu entnehmen. 

Im Rahmen dieses Artikels wird für die eigentlichen Geräte [[MQTT2 DEVICE|MQTT2_DEVICE]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] benötigt, mit einem IO-Device des Typs [[MQTT (Modul)|MQTT]] funktioniert die nachfolgende Darstellung dagegen nicht<ref>Allerdings können die Konfigurationen in der Regel recht einfach auf die bisherige MQTT-Implementierung übertragen werden</ref>. MQTT2_DEVICE unterstützt u.a. auch die ''setExtensions'' direkt, also z.B. ''on-for-timer<ref>Beachten Sie bei mehrkanaligen Geräten, dass jeweils nur ein Hauptkanal mittels setExtensions verwaltet werden kann! U.a. aus diesen Grund ist es meist sinnvoller, die ''split''-Varianten der attrTemplate-Einrichtung zu verwenden.</ref>'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt SetExtensions, allerdings muss dies dort per Attribut eingeschaltet werden</ref>.

=== Allgemeine Einstellungen und Hinweise ===
{{Randnotiz|RNTyp=r|RNText=Beachten Sie, dass für [[autocreate]] in Verbindung mit MQTT2_SERVER '''zwingend''' jeder über MQTT kommunizierende Client eine ClientID angeben muss. Passen Sie daher ggf. die Einstellungen Ihres Geräts an. Manche Geräte verwenden auch "Wegwerf"-ClientID's. Für diese empfiehlt es sich, ggf. dann die durch autocreate erstellten Geräte nachzubearbeiten und die ClientID-Angabe v.a. aus den Inhalten des readingList-Attributs zu entfernen.}}Die nachfolgenden Beispiele gelingen am einfachsten mit '''MQTT2_SERVER als Server ("Broker")''', für diesen sollte dabei ''autocreate'' nicht deaktiviert sein, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') ebenfalls aktiv ist.</ref> . 

Beispiel<ref>MQTT2_SERVER verwendet als default-Einstellung für ''autocreate'' ''simple'', ohne dass ein entsprechendes Attribut gesetzt werden müsste. Die Einstellung ''complex'' empfiehlt sich in der Regel nicht; diese ist jedoch dann zu empfehlen, wenn das Device entweder verschachtelte JSON-Array-Strukturen liefert oder bestimmte Readings nicht gefüllt werden sollen.</ref>:
 define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

Falls der MQTT Broker mit Hilfe von [[allowed]] abgesichert wurde, muss in den Geräten ebenfalls User bzw. Passwort eingetragen werden, damit eine MQTT Kommunikation möglich ist.

{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muss ggf. die "\" entfernen!}}

=== MQTT-Einstellungen in den Geräten ===
Die Beispiele gehen davon aus, dass die einzubindenden Geräte '''''mit den default-Einstellungen''''' für MQTT betrieben werden, wenn man von den Angaben zum Server und ggf. der Gerätekennung absieht. Es sollten also insbesondere '''keine Veränderungen der topic-Pfade''' vorgenommen werden.

{{Hinweis|Einige der hier beschriebenen Einstellungen haben Änderungen der sich durch die jeweiligen Automatismen eigentlich jeweils ergebenden Standard-Werte zur Folge, insbesondere, was Reading-Namen und von den Geräten gesendete Werte angeht. Sie sollten daher zunächst die Konfiguration des jeweiligen MQTT2-DEVICE-Geräts abschließen, und erst anschließend die weitere Integration mit Event-Handlern, logging usw. vornehmen.  }}

== zigbee2mqtt ==
[[Bild:MQTT2_zigbee2mqtt_Bulbs.png|400px|thumb|Darstellung in FHEMWEB]]
[https://github.com/Koenkk/zigbee2mqtt zigbee2mqtt] ist ein open-source Projekt, mit dem zigbee-Geräte über MQTT direkt angesprochen werden können, ohne dass hierfür eine Bridge eines Herstellers benötigt wird.
=== Installation von zigbee2mqtt ===
Die Installation des zigbee2mqtt-Diensts ist auf der Homepage des Projekts beschrieben. Ergänzend muss in der configuration.yaml eine ''client_id'' unter ''mqtt'' (z.B. zigbee_pi) vergeben werden<ref>Die Anführungszeichen sowie genau zwei Leerzeichen sind hier erforderlich!</ref>.
 mqtt:
   client_id: 'zigbee_pi'
Da der Dienst auch später in den Anlernmodus versetzt werden kann, kann man auch gleich <code>permit_join: false</code> setzen, um das versehentliche Einbinden neuer oder fremder Geräte zu unterbinden.
{{Hinweis|Wird ein CC2531 auf demselben Linux-Computer verwendet, auf dem auch FHEM installiert ist, kann es vorkommen, dass FHEM diesen mit einem CUL verwechselt und durch ''initialUsbCheck'' in FHEM einbindet, wodurch er für den zigbee2mqtt-Dienst nicht mehr verfügbar ist. Dann sollte ''initialUsbCheck'' deaktiviert und das automatisch angelegte CUL-Device wieder gelöscht werden. Weiter sollte der CC2531 auch in FHEM '''und''' zigbee2mqtt ''[[Mehrere USB-Geräte einbinden|by-id]]'' eingebunden werden, um Probleme beim gleichzeitigen Einsatz anderer Geräte, die ''/dev/ttyACMx'' belegen können, zu vermeiden (betrifft z.B. CUL/MapleCUL ).}}

=== Define eines MQTT2-Devices als "Bridge" === 
Dann kann eine Art "Grund-Device" angelegt werden, das für die Ansteuerung des eigentlichen Server-Dienstes genutzt wird, der bereits unmittelbar nach der erfolgreichen Konfiguration von zigbee2mqtt zur Verfügung steht. In der Regel sollte dieses automatisch erstellt werden, wenn der zigbee2mqtt-Dienst (oder der betreffende Rechner) neu gestartet wird (oder FHEM oder dort ein Sensor einen Messwert sendet). Beispiel<ref>Hier waren bereits zwei Zigbee-Geräte angelernt</ref>:

 defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
 attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
 attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/state:.* state\
   zigbee_pi:zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, '') }\''
   zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT, '') }\''
   zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT, 'log_') }
 attr MQTT2_zigbee_pi room MQTT2_DEVICE

Für die Funktion einer zigbee2mqtt-Bridge steht ein {{Link2CmdRef|Anker=set|Lang=en|Label=template}} bereit, das direkt die passenden Attribute vergibt, um dem zigbee2mqtt-Dienst passende Anweisungen geben zu können und weitere Geräte für die eigentlichen Aktoren und Sensoren anzulegen:

 set MQTT2_zigbee_pi attrTemplate zigbee2mqtt_bridge

Ist dieses angelegt, kann zigbee2mqtt mit <code>set MQTT2_zigbee_pi permit_join true</code> in den Anlernmodus versetzt werden, anzulernende Geräte müssen anschließend jeweils nach Bedienungsanleitung in den Anlernmodus gebracht werden.

=== Vereinzeln der eigentlichen Geräte ===

Über das mit dem template vergebene bridgeRegexp-Attribut  
 attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1" 
werden anschließend neue MQTT2_DEVICE-Geräte automatisch angelegt, sobald ein bisher unbekanntes Zigbee-Gerät einen neuen Status (z.B. einen Messwert) meldet. Um zu erfragen, welche Geräte dem zigbee-Deinst bekannt sind, kann via <code>get MQTT2_zigbee_pi devicelist true</code> eine Liste abgefragt werden, die weitere Informationen zu den bereits angelernten Geräten enthält.
Geräte, die nicht automatisch etwas senden, kann man mit Hilfe des MQTT2_SERVER-Geräts einmalig schalten, damit diese ihren Status bzw. das erfolgreiche Schalten zurückmelden, Beispiel<ref>Die mit 0x... beginnende Angabe entspricht dabei dem ''friendly_name''.</ref>:
 set MQTT2_FHEM_Server publish zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON","brightness":60}

Für Gerätetypen, für die bereits templates vorhanden sind, ist es am einfachsten, diese einmalig auf die Geräte anzuwenden. Das Vorgehen entspricht dabei dem oben für die Bridge beschriebenen. Dafür wird immer vorausgesetzt, dass ein neues Device mit autocreate (ggf. über die bridgeRegexp) angelegt wurde<ref>Dieses befindet sich dann im Raum MQTT2_DEVICE. Um diesen sichtbar zu machen, muss ggf. die Browser-Seite neu geladen werden.</ref>  

Beispiele:
==== IKEA-Tradfri-Birne ====
{{Randnotiz|RNTyp=g|RNText=Wie wähle ich nun das richtige Template für mein Leuchtmittel aus?
-> Es wird nicht zwischen einer Birne/Bulb/Lampe und einem LED-Controller unterschieden sondern anhand der möglichen Lichtdarstellung des Gerätes:

light_dimmer:
Das anzusteuernde Geräte besitzt ausschließlich eine feste Lichtfarbe welche gedimmt werden kann.

light_cct:
Das anzusteuernde Gerät besitzt eine warmweiße sowie kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann.

light_rgb_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und kann gedimmt werden.

light_rgbw_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße ODER kaltweiße Lichtfarbe welche eingestellt sowie gedimmt werden kann.

light_rgbcct_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße UND kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann.
   
   xxx:
      hex:   Farbänderung mit hex
      rgb:   Farbänderung mit r g b
      xy:   Farbänderung mit x sowie y
      hue:   Farbänderung mit hue und saturation

Warum diese Einteilung in "hex", "rgb", "xy" sowie "hue"?
-> Zigbee2MQTT unterstützt das Übermitteln aller dieser Werte, allerdings unterscheiden sich hier die Geräte. Manche "verstehen" nur z.B. Hex-Farbänderungen, andere halt nur eine Farbänderung mit rgb-Werten.
-> Aus diesem Grund muss an dieser Stelle probiert werden mit welchem der 4 Templates sich die Farbveränderung des Gerätes steuern lässt!

HINWEIS: Templates für Farbänderungen mithilfe von XY- sowie HUE-Werten wurden bis heute nicht angelegt!
}}
Beispiel eines dimmbaren Tradfri-Leuchtmittels
 defmod IKEA_Bulb2 MQTT2_DEVICE
 attr IKEA_Bulb2 IODev MQTT2_FHEM_Server
 attr IKEA_Bulb2 icon light_control
 attr IKEA_Bulb2 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
 attr IKEA_Bulb2 readingList zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT) }
 attr IKEA_Bulb2 setList on:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON"}\
     off:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"OFF"}\
     brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"on","$EVTPART0":"$EVTPART1"}
 attr IKEA_Bulb2 webCmd toggle:on:off:brightness
 attr IKEA_Bulb2 model L_02a_zigbee2mqtt_bulb

Kann man auch die Farbtemperatur einstellen, wird die setList wie folgt erweitert oder das entsprechende template<ref>Durch die ''model''-Angabe kann nachvollzogen werden, welches template angewendet wurde.</ref> anwendet:
 ...
 color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"$EVTPART0":"$EVTPART1"}

Die templates sind dabei in der Regel so gestaltet, dass eventuell mehr Optionen in FHEMWEB erscheinen, als tatsächlich vorhanden oder erwünscht sind. 
Da sich obige einfarbige dimmbare Lampe durch Klicken auf das devStateIcon schalten lässt, ist für die vollständige Ansteuerung bereits dieses webCmd hinreichend:
 attr IKEA_Bulb2 webCmd brightness

==== Temp/Hum. Sensor ====
tbd

==== Motion Sensor ====
Als MQTT-Server wird hier ''mosquitto'' verwendet, als IO-Device wird daher ein {{Link2CmdRef|Anker=MQTT2_CLIENT|Lang=en|Label=MQTT2_CLIENT}}-Gerät definiert: 

 defmod mqtt2_client MQTT2_CLIENT 192.168.2.4:1883
 attr mqtt2_client autocreate 1
 attr mqtt2_client rawEvents zigbee2mqtt/GB_Bewegungsmelder:.*
 attr mqtt2_client room test
 attr mqtt2_client subscriptions #

Das eigentliche Device sieht dann so aus:
 defmod GB_Bewegungsmelder_MQTT2 MQTT2_DEVICE zigbee_158d0001f9d030
 attr GB_Bewegungsmelder_MQTT2 IODev mqtt2_client
 attr GB_Bewegungsmelder_MQTT2 devStateIcon motion:motion_detector@red off:motion_detector@green no_motion:motion_detector@green
 attr GB_Bewegungsmelder_MQTT2 icon motion_detector@blue
 attr GB_Bewegungsmelder_MQTT2 readingList mqtt2client:zigbee2mqtt/GB_Bewegungsmelder:.* { json2nameValue($EVENT) }
 attr GB_Bewegungsmelder_MQTT2 room MQTT2_DEVICE
 attr GB_Bewegungsmelder_MQTT2 stateFormat {\
 if(ReadingsVal("$name","occupancy",0) eq "true") {\
 	sprintf("motion");;\
 	} else {\
 	sprintf("no_motion");;	\
 	}\
 }
==== Anlegen von Zigbee2MQTT-Gruppen in FHEM ====
{{Hinweis|Die nachfolgende Darstellung ist vorläufig!}}
{{Hinweis|Bevor man eine Gruppe mithilfe von Zigbee2MQTT anlegen kann, sollte man sicherstellen, dass man über die aktuelleste Version von Zigbee2MQTT verfügt (min. vom 15. Februar 2019). Außerdem sollte auch der Koordinator (zumeist CC2531) die aktuellste Firmware besitzen (min. vom 15. Februar 2019). Falls ein flashen des Koordinators mit der neusten Firmware erfolgen soll, ist darauf zu achten, dass nach einem flashen alle Geräte neu angelernt werden müssen! (Hinweise zum flashen ohne erneutem anlernen sind hier zu finden: https://www.zigbee2mqtt.io/information/flashing_without_re-pairing.html)}}

=====Erstellen einer Zigbee2MQTT-Gruppe=====
Bevor das Ganze in FHEM funktioniert, muss eine Gruppe in der "configuration.yaml" angelegt werden, dieser Vorgang ist auf folgender Seite beschrieben: https://www.zigbee2mqtt.io/information/groups.html
Wenn die Geräte anschließend über den FHEM MQTT2-Server der Gruppe hinzugefügen werden sollen, kann dies mit folgendem Befehl erfolgen:
 set <MQTT2-Server> publish zigbee2mqtt/bridge/group/<Zigbee2MQTT Friendly-Gruppenname>/add <Zigbee2MQTT Friendly-Gerätename>

Beispiel:
 set MQTT2_FHEM_Server publish zigbee2mqtt/bridge/group/Wohnzimmer/add Stehlampe

Dieser Befehl kann so oft verwendet werden, wie man Geräte zu einer Gruppe hinzufügen möchte.

Zum Entfernen eines Gerätes aus einer Gruppe kann folgender Befehl verwendet werden:
 set <MQTT2-Server> publish zigbee2mqtt/bridge/group/<Zigbee2MQTT Friendly-Gruppenname>/remove <Zigbee2MQTT Friendly-Gerätename>
Beispiel:
 set MQTT2_FHEM_Server publish zigbee2mqtt/bridge/group/Wohnzimmer/remove Kuechenlampe

=====Anlegen der Gruppe in FHEM=====
Da Gruppen in Zigbee2MQTT aktuell keine Rückmeldung über ihren Status geben, wird auch beim einmaligen Schalten kein Gerät automatisch in FHEM angelegt. Aus diesem Grund muss dies mit folgendem Befehl noch manuell erfolgen:
 defmod <FHEM NAME> MQTT2_DEVICE
Beispiel
 defmod lichtWohnzimmer MQTT2_DEVICE
Anschließend wird auch für dieses Gerät wieder ein passendes template ausgewählt, wie als wäre es ein normales Zigbee2MQTT-Gerät.
Im anschließenden Dialog-Fenster welches sich nach dem Setzen des templates öffnet, müssen die folgenden Werte durch passendes ersetzt werden:
 BASE_TOPIC -> zigbee2mqtt
 DEV_ID -> <Zigbee2MQTT Friendly-Gruppenname>

Danach sollte sich die Gruppe wie ein normales Zigbee2MQTT Gerät steuern lassen.

== Tasmota ==
{{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}[https://github.com/arendst/Sonoff-Tasmota Tasmota] ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) ist eine open-source Software für ESP8266-Geräte, die z.B. statt der originalen Firmware für Sonoff-Geräte und andere ESP8266-basierte WLAN-Steckdosen usw. verwendet werden kann. 
{{Hinweis|[[Datei:Tasmota mqtt config.png|120px|thumb|right]]Vor allem, aber nicht nur bei Verwendung des MQTT2_CLIENT als IO, ist es empfehlenswert, in der MQTT-Konfiguration der tasmota-Geräte für den Parameter ''<nowiki>topic = %topic% (tasmota)</nowiki>'' ebenfalls die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' zu verwenden. (Kopieren Sie einfach diese Zeichenkette aus dem  Eingabefeld für ''"client ..."'', siehe nebenstehende Abbildung). Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}
=== MQTT2_DEVICE ===
Dieses sollte bei aktiviertem ''autocreate'' am MQTT2_SERVER-Device automatisch angelegt werden, sobald das betreffende Gerät eingesteckt oder neu gestartet oder an einem evtl. vorhandenen Taster geschalten wird. Bislang wurden Tasmota version(en) ab 6.1.1 bis min. 8.1.0 getestet, dies auf verschiedener Hardware, zunächst mit Sonoff Touch und S20, zwischenzeitlich mit einer Vielzahl von Geräten, die per USB-Adapter oder mit der Methode aus dem [https://www.heise.de/ct/artikel/Tuya-Convert-IoT-Geraete-ohne-Loeten-vom-Cloud-Zwang-befreien-4283623.html Tuya-Convert]-Projekt des heise-Verlags auf Tasmota umgeflasht wurden.

=== Manuelle Anpassungen ===
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:  
 defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
 attr MQTT2_DVES_9B01BD IODev m2server
 attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
    DVES_9B01BD:cmnd/DVES_9B01BD/POWER:.* POWER\
    DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
 attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
 attr MQTT2_DVES_9B01BD setList on cmnd/DVES_9B01BD/POWER on\
    off cmnd/DVES_9B01BD/POWER off\
    reboot cmnd/DVES_9B01BD/Restart 1
 attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===

===== Allgemeines =====
Für gängige Tasmota-Geräte stehen ''templates'' bereit, mit denen sich diese schnell konfigurieren lassen. 
Beachten Sie dazu den Abschnitt ''attrTemplate'' in [[MQTT2 DEVICE#attrTemplate|MQTT2_DEVICE]]. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.{{Hinweis|Bitte attrTemplates nicht verwechseln mit templates, die auf den Tasmota- bzw. Blackadder-Seiten angeboten werden, welche zur Konfiguration der firmware genutzt werden können! Es sollte zunächst die firmware korrekt eingerichtet werden, so dass das Gerät selbst direkt auf dessen Web-Interface korrekt bedient werden kann.}}

===== Kein passendes attrTemplate vorhanden? =====
Exisitert (noch) kein passendes attrTemplate, ist zu empfehlen, zunächst das "''tasmota_basic''" anzuwenden. Dieses führt einige Basiskonfigurationen durch, die für FHEM hilfreich sind, z.B. wird die firmware so eingestellt, dass Schaltzustände in Kleinschreibung übermittelt werden, statt der defaults "ON" bzw. "OFF".

Allerdings stellt dieses das ''autocreate'' an dem MQTT2_DEVICE auf 0, was dann nicht optimal ist, wenn man weitere Readings aus dem Gerät erwartet, etwa, weil zusätzliche Sensoren vorhanden sind. In diesem Fall empfiehlt es sich, das ''autocreate''-Attribut an dem MQTT2_DEVICE zu löschen, damit alle weiteren Informationen verarbeitet werden und ggf. im ''jsonMap''-Attribut nur die Angabe "''POWER1:state''" zu belassen.

=== on-for-timer ===
Um z.B. ein Relais nur für einen Zeitraum anzuschalten, kann man bei Tasmota-Geräten zwischen mehrere Varianten wählen. Ohne speziellen ''setter'' in der ''setList'' werden die '''SetExtensions''' verwendet. Timer laufen damit innerhalb FHEM. Da diese intern als temporäres [[at]] ausgeführt werden, sind diese auch noch nach einem FHEM-Neustart vorhanden, sofern FHEM ordnungsgemäß beendet und neu gestartet wird.

Die Tasmota-firmware bietet ergänzend dazu zwei Möglichkeiten an, bei denen der Timer direkt auf dem ESP-Microcontroller verwaltet wird:

==== delay ==== 
Zeile zur Erweiterung der ''setList'' (Attributeingabe via FHEMWEB!):
 on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}

Ohne Auswirkungen auf alles, was danach kommt, hat aber den Nachteil, dass die möglichen Zeitspannen auf 3600 1/10 Sekunden begrenzt sind (siehe https://github.com/arendst/Tasmota/wiki/Commands#delay), also eine Stunde.

====pulseTime ====
Zeile zur Erweiterung der ''setList'' (s.o.):
 on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}
Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit ''delay''. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites ''save'' nur bis zum nächsten reboot des Microcontrollers.

=== zigbee2tasmota ===
[https://tasmota.github.io/docs/Zigbee/ zigbee2tasmota] ist eine Erweiterung der Tasmota-firmware für Microcontroller, insbesondere dem ESP8266 (und ESP32)(link), über die einige ZigBee-Chipsätze (insbesondere TI CC2530) als [[ZigBee#Koordinator_.28ZigBee_coordinator.2C_ZC.29|Coordinator]] eingebunden werden können, um ein ZigBee-Netzwerk aufzubauen.
{{Hinweis|Stand 08/2020 war die Einbindung anderer Chipsätze erst in einem Alpha-Stadium; die Zahl der über einen CC2530 einbindbaren ZigBee-Geräte ist daher derzeit relativ begrenzt (ca. 16)!}}
Auch für diese Lösung stehen einige ''attrTemplate'' zur Verfügung. Nähere Informationen hierzu sind dem Artikel [[Zigbee2Tasmota-MQTT]] zu entnehmen.

== ESPurna ==
ESPurna ist eine weitere alternative firmware für ESP8266-basierte Geräte, Details sind der [https://github.com/xoseperez/espurna/wiki Projektseite] zu entnehmen.

Das Format, in dem ESPurna Daten sendet, unterscheidet sich v.a. darin, dass bool'sche Werte als 0 oder 1 gesendet werden, und nicht wie sonst üblich als "on" oder "off" oä.. Es stehen einige Mustertemplates zur Verfügung, um diese Art der Payload in FHEM-konforme Werte zu überführen.

== Shelly ==
=== Vorbemerkung ===
Auch für Shelly-Geräte steht eine Auswahl an [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|templates]] bereit.
Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.

Standardmäßig senden die Shelly-Geräte ihren kompletten Status alle 30 Sekunden. Dies kann man über den Parameter ''mqtt_update_period'' in den ''settings'' ändern, allerdings ist dieser nur über die HTTP-Schnittstelle des Shelly verfügbar. Um diese Statusupdates abzustellen, kann über den Browser folgender Befehl verwendet werden:
 http://<ip-des-shelly>/settings?mqtt_update_period=0, 
Soweit bekannt, werden dann nur statische updates ausgeschaltet, z.B. für das Relay bzw. angeschlossene Taster oder Schalter; insbesondere Verbrauchswerte werden dennoch aktualisiert.

=== Shelly1 ===

=== Shellybulb ===
Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate  angelegt wird. Dies sieht zunächst so aus:
 Internals:
   CFGFN     
   CID        shellybulb_3CC533
   DEF        shellybulb_3CC533
   DEVICETOPIC MQTT2_shellybulb_3CC533
   IODev      MQTT2_FHEM_Server
   NAME       MQTT2_shellybulb_3CC533
   NR         246
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-12 19:28:08   status_blue     0
     2018-12-12 19:28:08   status_brightness 61
     2018-12-12 19:28:08   status_effect   0
     2018-12-12 19:28:08   status_gain     26
     2018-12-12 19:28:08   status_green    0
     2018-12-12 19:28:08   status_ison     true
     2018-12-12 19:28:08   status_mode     color
     2018-12-12 19:28:08   status_red      255
     2018-12-12 19:28:08   status_temp     3250
     2018-12-12 19:28:08   status_white    0
 Attributes:
   IODev      MQTT2_FHEM_Server
   readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
   room       MQTT2_DEVICE
[[Bild:MQTT2 Shellybulb.png|400px|thumb|Darstellung in FHEMWEB nach Anwendung des template]]Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.

=== Shelly Plug S ===
Über die Leistungsmessung des Shelly Plug S lässt sich sehr einfach auch eine Erkennung des Betriebszustandes des angeschlossenen Gerätes realisieren. Dazu stellt man zuerst fest, wieviel Leistung das Gerät in jedem Betriebszustand verbraucht und kann dann z.B. für einen angeschlossenen Fernseher, der im Standby 1 Watt und im Betrieb > 100 Watt verbraucht, den Zustand erkennen und als on/off Status anzeigen. Dazu wird das state Reading wie folgt definiert:
  attr readingList shellies/shellyplug-s-123456/relay/0/power:.* { { state => $EVTPART0<100?"off":"on" } }
Der Status des MQTT2 Devices zeigt dann bei <100W "off" und sonst "on" an.

=== HTTP-Commands ===
In diesem {{Link2Forum|Topic=102369|LinkText=Forumsbeitrag}} wird eine Lösung vorgestellt, um über [[99 myUtils anlegen|myUtils-Code]] weitere Kommandos bereitzustellen, die sonst nur direkt über das Web-Interface zu erreichen sind.

== 8-Port-Ethernet Board ==
<gallery>
datei:8-relais-ethernetboard closed.jpg|mit Gehäuse
datei:8-Port-MQTT-Relais-Board.jpg|ohne Gehäuse
</gallery>
In diesem {{Link2Forum|Topic=107536|Message=1016379|LinkText=Forenbeitrag}} bzw. dem betreffenden Thread wurde ein Relais-Board vorgestellt, mit dem 8 Relais über Ethernetkabel verbunden werden, die Kommunikation erfolgt dann über MQTT. Über die verwendete Software ist wenig bekannt, es könnte jedoch sein, dass diese Art der Einbindung auch bei weiteren Boards funktioniert, die einen bestimmten Ethernet-Chipset von TI (DP83848) und eine Cortex M3 MCU verwenden.

== Milight-Bridge ==
=== Vorbemerkung ===
Der [https://github.com/sidoh/esp8266_milight_hub esp8266_milight_hub] ist ein open source- Projekt, mit dem auf Basis von ''openmili'' eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel.
Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway<ref>Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.</ref>.
Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist.
Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.

=== Einstellungen am MiLight-Hub ===
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an.
Die Einstellungen für ''MQTT topic pattern'' usw. können auf den default-Werten<ref>Diese sind: <br>''milight/:device_id/:device_type/:group_id'' für "topic pattern"<br>''milight/updates/:hex_device_id/:device_type/:group_id'' für "update topic pattern"<br>''milight/states/:hex_device_id/:device_type/:group_id'' für "state topic pattern". Der Autor hat derzeit folgende Infotypen zum Senden markiert: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (enthält eventuell zu viele Angaben. Bei einem Eventhandler muss man uU. darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).</ref> belassen werden, für die seit Mitte 2019 vorhandene Option, eine LWT-Message zu senden (''MQTT Client Status Topic''), tragen Sie ''milight/LWT'' ein und aktivieren ''Detailed''.

=== FHEM-Devices ===
[[Bild:MQTT2 MiLight.png|400px|thumb|Milight: Darstellung in FHEMWEB]]
==== Bridge ====
Wird nun über den Hub oder eine von diesem erkannte Fernbedienung ein vorhandenes Leuchtmittel geschaltet, wird bei eingeschaltetem autocreate ein erstes Device erstellt, die zunächst erstellte Definition sieht typischerweise etwa so aus:
 defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325
 attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server
 attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
 attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE

Auf dieses Device wird nun das ''template'' '''esp_milight_hub_bridge''' angewandt.

==== Einzelne Leuchtmittel ====

Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:
 defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1
 attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server
 attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
 attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE

Auf dieses wird nun eines der Bulb-templates angewendet. Wählt man das template X_01_esp_milight_hub_rgbw_bulb, wird eine einfache Variante erstellt, die neben einem toggelnden Icon nur Regler für Helligkeit, die Farbe und zwei Schaltflächen für den Weiß- und Nachtmodus enthält. Wer mehr oder andere Steuerelemente erhalten möchte, verwendet ein anderes template. Nicht benötigte Elemente kann man dabei einfach aus der Definition löschen.

Alle weiteren Devices werden genauso erstellt. 

Um ein Device zu erhalten, mit dem sich alle Kanäle gleichzeitig steuern lassen, kann das template ''X_01a_esp_milight_hub_make_rgbw_group'' verwendet werden. Dieses verändert nicht das aktuelle Device, sondern erstellt '''eine Kopie''', die dann modifiziert wird. Diese Kopie ist unter dem Namen ''milight_<RemoteID>_0'' im selben Raum zu finden wie das Ausgangsgerät und kann ebenfalls an die eigenen Wünsche angepasst werden. 

Weitere Beispiele:
Beispiel für ein RGB-CCT-Device:
 defmod Licht_Wz_all MQTT2_DEVICE
 attr Licht_Wz_all IODev MQTT2_Broker
 attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
 attr Licht_Wz_all group Licht
 attr Licht_Wz_all icon light_control
 attr Licht_Wz_all readingList milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
 milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
 milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
 
 attr Licht_Wz_all room Wohnzimmer
 attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
 off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
 level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
 commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
 attr Licht_Wz_all sortby 1
 attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
 attr Licht_Wz_all webCmdLabel command\ 
 :brightness:saturation\
 :color_temp:hue
==== Ein Leuchtmittel, mehrere Fernbedienungen ====
Pairt man mehrere Fernbedienungen mit einem Leuchtmittel, sollten auch alle entsprechenden Fernbedienungscodes in das readingList-Attribut übernommen werden. Dazu übernimmt man am einfachsten die Einträge aus den zusätzlichen MQTT2_DEVICEs. Benötigt man das zusätzliche Device nicht separat, um z.B. eine getrennte Gruppenschaltung zu realisieren, kann man dieses löschen. Beispiel-readingList für ein Device, das auf zwei Fernbedienungscodes und zwei Gruppen "hört":

 attr Licht_Wz_all readingList milight/states/0x1234/rgbw/2:.* {json2nameValue($EVENT) }\
 milight/updates/0x1234/rgbw/2:.* { json2nameValue($EVENT) }\
 milight/states/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
 milight/updates/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
 milight/states/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
 milight/updates/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
 milight/states/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }\
 milight/updates/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }

==== Fernbedienung als Input-Device nutzen ====
In diesem {{Link2Forum|Topic=103493|LinkText=Thread}} ist dargestellt, wie man eine Fernbedingung des Typs FUT089 dazu verwenden kann, einen [[MPD]] oder Rollladenaktoren zu steuern, oder diese Fernbedienung für [[Hue#HUE-Device|HUEDevice]]-Leuchtmittel zu nutzen.
Um hier nur Differenz-Meldungen zu erhalten und doppelte Events zu verhindern, sollte hier die readingList so angepasst werden, dass nur Messages aus dem "updates"-Zweig ausgewertet werden: 
 defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
 attr MiLight_RC1_0 readingList milight/updates/0xABCD/fut089/0:.* { json2nameValue($EVENT) }\
 milight/states/0xABCD/fut089/0:.* {}

== eBus ==
An dieser Stelle sollen lediglich die Grundzüge erläutert werden, eine ausführliche Anleitung über die Konfiguration des [[EBUS-MQTT2|eBus mit MQTT2 gibt es hier]].

=== Vorbereitung und Definition am eBus ===
Vorausgesetzt wird ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
In der Konfiguration des Dämons ( /etc/default/ebusd ) ist die Kommunikation über MQTT zu aktivieren und die Topic-Struktur festzulegen, z.B. ''ebusd/%circuit/%name''.
 --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
{{Hinweis|Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ''ebusd'' verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ''ebus...'' zu beginnen!}}

=== Vorbereitung und Definition  in FHEM ===
Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem '''''vor''''' den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der ''readingList'' enthalten, die vom ebus stammen. Da wir die ''readingList'' anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen zumindest sämtliche ''readingList''-Attribute entsprechend bereinigt oder gelöscht werden; in der Regel ist es einfacher, diese Geräte nach dem Deaktivieren des autocreate am IO zu löschen.
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT als IO nutzen, sollte für das weitere Vorgehen eine Kopie des MQTT2-"Sammeldevices" genutzt werden, und dessen ''CID'' auf ''ebusd'' geändert werden. Nach Anwendung des ebusd-splitter-templates müssen dann alle den ebus betreffenden Einträge aus der ''readingList'' des "Sammeldevices" gelöscht werden oder diese ganz gelöscht.}}Ist der ebus-Dämon lauffähig und für MQTT konfiguriert, sendet dieser regelmäßige Messages. 

Sind die Vorbereitungen abgeschlossen, aktivieren wir ''autocreate'' wieder, allerdings wählen wir als autocreate-Methode ''complex'' aus, da der eBus-Dämon teilweise<ref>Dies betrifft vorrangig die Statusmeldungen</ref> eine weiter verschachtelte JSON-Struktur zum Versenden der Informationen verwendet als üblich. Danach wird wie bei den anderen o.g. Geräten automatisch ein neues MQTT2_DEVICE angelegt<ref>Bei Verwendung des MQTT2_CLIENT wird dann die ''readingList'' am bereits definierten MQTT2_DEVICE aus der Kopie des "Sammeldevice" automatisch wieder erstellt bzw. gefüllt.</ref>

==== "ebus-Bridge" ====
Auf das von ''autocreate'' erstellte MQTT2_DEVICE wird nunmehr das template ''eBus_daemon_splitter'' angewendet. Nach einiger Zeit sollte sowohl die readingList an diesem Device erweitert worden sein, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt. 
Dieses Device liefert zukünftig Readings zum Dämon selbst, wie dessen ''uptime'', alle weiteren am eBus angeschlossenen Teilnehmer werden dagegen zweckmäßigerweise durch ein oder mehrere weitere MQTT2_DEVICE-Geräte dargestellt. 

Das ''attrTemplate'' läd eine weitere ''attrTemplate''-file und [[99 myUtils anlegen|99_myUtils-Code]] vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung. 
==== "ebusd_bai" und weitere Geräte ====
{{Hinweis|Der eBus-Dämon sendet nicht alle Informationen zu allen am eBus angeschlossenen Geräte automatisch. Diese müssen teilweise erst aktiv angefragt werden. Wie das im einzelnen erfolgen kann, ist dem o.g. Detailartikel zu entnehmen.}}
Funktioniert die Kommunikation zwischen dem eBus-Dämon und FHEM, sollte nach einigen Minuten zumindest ein weiteres Gerät namens ''MQTT2_ebus_bai'' angelegt worden sein.

== Sonos2Mqtt ==
Aus einem Versuch heraus ist ein {{Link2Forum|Topic=111711|LinkText=kleines Projekt}} geworden: Die Sonos Umgebung mit Hilfe von sonos2mqtt als generisches MQTT2_DEVICE komfortabel in FHEM einzubinden.

Mit Hilfe von ein paar Templates ist die grundlegende Einbindung in FHEM nach einer kleinen Installation auf Systemebene schnell erledigt. Es läuft derzeit noch zahlreiche Entwicklung und Ideenfindung, die Fortschritte sind live im Thread oder [[Sonos2mqtt|konsolidiert im Wiki]] zu finden.

=== Setup im System ===
Voraussetzung: nodejs und pm2 ist installiert und für alle Benutzer verfügbar. Je nach Entwicklungsstand sind auch Betaversionen verfügbar. Für aktuelle Beta einfach anstatt sonos2mqtt -> sonosmqtt@3.1.0-beta.1 beim Setup verwenden.<syntaxhighlight lang="bash">
sudo npm install -g sonos2mqtt
</syntaxhighlight>

=== Setup in FHEM ===
Man definiert lediglich ein Bridge Device, der Rest wird automatisch erledigt.

Voraussetzung: 
* autocreate im System ist aktiv. 
* Der verwendete MQTT2_SERVER steht auf '''autocreate simple''' (default/Standard).
Bei der Anwendung des Template für die Bridge wird der Topic (default: sonos) abgefragt! Einfach eintippen und ok drücken. 

Der folgende Code muss modifiziert werden! Den Abschnitt [[MQTT2-Module - Praxisbeispiele#Start sonos2mqtt|Start sonos2mqtt]] beachten!

'''Achtung dieser Code muss "am Block" in der Raw Def ausgeführt werden!''' 
# man kopiert diesen Codeblock, 
# drückt im Webinterface das große + ,
# und fügt den Code ins Editorfenster ein. 
# Dort muss/kann man die persönlichen Anpassungen machen. 
# Zum Abschluss execute - fertig
<syntaxhighlight lang="perl">
define SonosBridge MQTT2_DEVICE
attr SonosBridge IODev NameDesVorhandenenMQTT2Servers
attr SonosBridge room MQTT2_DEVICE
define n_pm2_sonos notify global:INITIALIZED|n_pm2_sonos:start "pm2 -s start sonos2mqtt -- --mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800"
sleep global:ATTR.SonosBridge.stateFormat.connected;trigger n_pm2_sonos start
set SonosBridge attrTemplate sonos2mqtt_bridge_comfort
</syntaxhighlight>Der obige Code startet sowohl das sonso2mqtt Modul sofort und implentiert ein notify für den zukünftigen automatischen Start beim Start von FHEM.

Das hier verwendete Template sonos2mqtt_bridge_comfort: 
* setzt das Template sonos2mqtt_bridge auf das Device SonosBridge
* definiert zwei notify, diese erledigen im weiteren Betrieb die automatische Konfiguration der automatisch erzeugten MQTT2_DEVICEs 
** mit dem Template sonos2mqtt_speaker.
** Ermitteln Detailinformation des jeweiligen Players (vor allem IP Adresse und Modelnumber)
** Laden die Sonosgeräte Icons von den UPNP Devices herunter
** erweitern das setList input Kommando um den TV Eingang (HDMI, spdif) bzw. Line_IN Eingang falls vorhanden (Modelnumber)

==== Wozu dient die Bridge? ====
Sie stellt ein paar wesentliche Funktionen zu Verfügung
# Auffangen von nicht benötigten MQTT Nachrichten
# Erzeugung/Weiterleitung von Nachrichten für die einzelnen Player - damit auch die Erzeugung von separaten Playern nach dem Schema MQTT2_RINCON12345678901234567
# Status sonos2mqtt als Reading connected (0 offline, 1 connected, 2 Player connected)
Sie kann auch als zentrales Device verwendet werden um die Sonos Umgebung abzubilden, z.B. Readings für Favoriten  u.ä.

==== Start sonos2mqtt ====
Soll das Modul sonos2mqtt mit seinen default Einstellungen gestartet werden genügt dieser kurze Befehl:<syntaxhighlight lang="bash">
"pm2 start sonos2mqtt"
</syntaxhighlight>Ist der MQTT2_SERVER in FHEM nicht "einfach so" sondern mit anderen Einstellungen erstellt und mit allowed abgesichert, müssen weiter Parameter übergeben werden. Dies erfolgt mit dem doppelten Bindestrich -- hinter dem nodejs Modul.

Beispiel:<syntaxhighlight lang="perl">
"pm2 start sonos2mqtt -- --mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800"
</syntaxhighlight>Tipp: Verwendet man anstatt "Befehl" den Syntax {qx(Befehl)} in der FHEM Kommandozeile, wirkt der Befehl zwar blockierend aber die Ausgabe erfolgt im Browser und nicht im Logfile. Mit dem Parameter -s erfolgt keine Ausgabe.

==== Autostart von sonos2mqtt mit pm2 (Alternative) ====
Der obige Code startet das sonos2mqtt nodejs Modul mit pm2 beim Start von FHEM. Sollte das nicht funktionieren oder nicht ins gesamte Konzept passen (weil z.B. mehrere nodejs Module geladen werden) kann der automatische Start direkt im System erfolgen. Zunächst dafür das oben eventuell schon definierte notify löschen!<syntaxhighlight lang="perl">
delete n_pm2_sonos
</syntaxhighlight>Der Start des Modul muss nicht mit erhöhten Rechten geschehen! Im Terminal folgendes eingeben (unter dem angemeldeten Benutzer wird sonos2mqtt später immer gestartet):<syntaxhighlight lang="bash">
pm2 start sonos2mqtt
pm2 startup
</syntaxhighlight>Der letzte Befehl "redet", d.h. es gibt eine Ausgabe in der Art:<syntaxhighlight lang="bash">
[PM2] To setup the Startup Script, copy/paste the following command:
sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u pi --hp /home/pi
</syntaxhighlight>Man tut einfach genau das, was dasteht: die letzte Zeile kopieren und wieder einfügen und ausführen. Danach muss man die Konfiguration von pm2 noch sichern:<syntaxhighlight lang="bash">
pm2 save
</syntaxhighlight>

=== Sonos2mqtt mit mehr Komfort ===
Im Wiki Artikel [[Sonos2mqtt]] geht es weiter.

== Allgemeine Hinweise ==
=== MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen ===
Nutzt man das rawEvents-Attribut am MQTT2-IO<ref>z.B. <code>attr MQTT2_FHEM_Server rawEvents .*</code>, der regex-Filter kann wie üblich angepasst werden</ref>, kann man den Datenverkehr des Servers am Event-Monitor mitschneiden. Dies ist insbesondere für unbekannte Geräte nützlich, deren Topic- und Payload-Struktur noch nicht bekannt ist.
Um den kompletten MQTT Datenaustausch mitzuschneiden, kann man mit <code>attr mqtt2_server verbose 5</code> auch alles ins FHEM-Log schreiben lassen.

=== autocreate funktioniert anscheinend nicht? ===
In der Regel wird bei neu eingehenden MQTT-Messages über ''autocreate'' ein neues Device erstellt, wenn Nachrichten von einem bisher unbekannten Gerät kommen. Geschieht dies nicht, sollten folgende Punkte geprüft werden:
# Ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') muss vorhanden und aktiv sein.
# ''autocreate'' am IO muss eingeschaltet sein, was für MQTT2_SERVER bedeutet, dass es nicht auf "0" stehen darf (hier ist dann ''simple'' die aktive Voreinstellung), für MQTT2_CLIENT sollte ebenfalls ''simple'' verwendet werden; dies muss hier allerdings explizit gesetzt werden.

Wird dann immer noch kein Device erstellt, gibt es in aller Regel ein Device, das bereits einen entsprechenden Eintrag in der readingList enthält, oder es sind keine Nachrichten eingegangen. Überprüfen Sie daher dann ggf. die Einstellungen am Client-Gerät (z.B. im Web-Interface des Shelly oder Tasmota-geflashten ESP8266).

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''[[AttrTemplate|attrTemplate]]'' genutzt werden. 
Die Anwendung für MQTT2_DEVICE ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.

{{Hinweis|In einigen Fällen kann es vorkommen, dass die template-Bezeichnung zwischenzeitlich geändert wurde. Seit 21.09.2019 erfolgt die Sortierung der auswählbaren templates nicht mehr nur nach den Namen, so dass die entsprechenden Namensbestandteile entfallen sind, die einer besseren Sortierung dienten.}}

=== attrTemplate: Es werden nicht alle templates angezeigt ===
Siehe Beitrag [[AttrTemplate#Warum finde ich das Template xyz nicht.3F|AttrTemplate: Warum finde ich das Template xyz nicht.]]

=== attrTemplate und Sprachsteuerung ===
Konfiguriert man MQTT2_DEVICE-Geräte mit attrTemplate, werden in der Regel auch direkt die für die Sprachsteuerung der Geräte erforderlichen Attribute mit gesetzt. Weiterführende Hinweise sind auch zu diesem Teilaspekt von ''[[AttrTemplate|attrTemplate]]'' dem betreffenden Hauptartikel zu entnehmen.

=== bridgeRegexp ===
[[Datei:Mqtt2 server.png|300px|thumb|left|Logische Verortung der bridgeRegexp-Angaben]]{{Randnotiz|RNTyp=y|RNText=Beachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.}}Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch '''''einem''''' ''MQTT2_DEVICE'' zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. In dem nebenstehenden Schaubild wären dies die Geräte ''A'' bis ''D''. Das '''Attribut''' ''bridgeRegexp'' kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem '''anderen Device''' (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als ''newClientId'' hinterlegte Angabe verwendet. In nebenstehendem Schaubild ist dies exemplarisch für die Gerätegruppe ''D'' mit dem ''bridge''-Device ''D'' und dessen ''Satelliten'' ''D1'' bis ''D4'' dargestellt.
Dementsprechend sind in den hier aufgeführten Beispielen ''bridgeRegexp''-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren, wie z.B. für über hier dargestellten ''zigbee2mqtt'' oder ''zigbee2tasmota''. Ein Sonderfall hierbei ist das template ''MQTT2_CLIENT_general_bridge'' zur Verwendung mit dem [[MQTT2_CLIENT#Anwendung|MQTT2_CLIENT]], denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem ''mosquitto''-Server und würden sonst alle einem einem MQTT2_DEVICE zugewiesen.

=== Ständig neue Devices? ===
MQTT2_SERVER kann zwischen verschiedenen Geräten auch anhand der ClientID unterscheiden. Für jedes neu erkannte Gerät wird auch ein eigenes MQTT2_DEVICE angelegt. Abhilfemaßnahmen:
==== Vergabe einer ClientID ====
Die meisten MQTT-fähigen Geräte enthalten Optionen zur Vergabe einer eindeutigen ClientID (siehe das Beispiel des zigbee2mqtt-Dienstes oben). 
Wird keine ClientID vergeben, verwenden manche Clients für jede Verbindung wieder neue ID's. Es wird empfohlen, möglichst von diesen Einstelloptionen Gebrauch zu machen.

==== Löschen der ClientID aus der readingList usw. ====
Ist dies nicht möglich oder erwünscht, kann man auch die ClientID aus den readingList-, setList- und getList-Attributen entfernen. Dies ist jedenfalls solange unschädlich als nicht mehrere Geräte identische Topic-Pfade verwenden (daher die Empfehlung, insbesondere bei Tasmota-Geräten den ''default'' "sonoff" zu ändern).
Beispielsweise wäre <code>attr Milight_Bridge readingList milight_hub_1370325:milight/LWT:.* {json2nameValue($EVENT) }</code> zu ändern in <code>attr Milight_Bridge readingList milight/LWT:.* {json2nameValue($EVENT) }</code>
Die über ''attrTemplate'' verfügbaren Konfigurationen verwenden in der Regel keine ClientID's bzw. entfernen diese.

=== Wildcards in readingList und setList ===
Auch in readingList und in setList sollten sich sog. wildcards verwenden lassen. Die Vorgehensweise ist jedoch unterschiedlich:

In ''readingList'' werden normale regex-Ausdrücke verwendet. Ein Punkt steht daher z.B. für ein beliebiges Zeichen, alles zwischen zwei Topic-Tree-Elementen (getrennt typischerweise durch einen "/") kann man so schreiben: "[^/]+" (entspricht: "Mindestens ein Zeichen, das kein Schrägstrich ist"). Ergänzender Hinweis: Will man z.B. Informationen aus einem beliebigen Teil des Topic-trees extrahieren und als Reading-Namen verwenden, kann dies im Rahmen eines Perl-Aufrufs geschehen. Beispiele aus der mqtt2.template-file: OpenMQTTGateway_BT_scanner und OpenMQTTGateway_BT_gtag (letzteres überführt die Information, über welches Gateway bestimmte Informationen eingegangen ist jeweils in eigene Readings pro Gateway).

In ''setList'' gelten dagegen die wildcard-Konventionen aus der MQTT-Welt. Dort steht "+" für einen austauschbaren Teil des Topic-Trees (zwischen zwei Schrägstrichen). Anmerkung: Bitte vorher prüfen, ob es wirklich sinnvoll ist, derart unspezifische Publishes vorzunehmen. Meist gibt es "Gruppen-Topics", auf die mehrere Geräte eines bestimmten Typs hören bzw. man kann dies dort (in der firmware bzw. auf den Konfigurationsseiten der Geräte) einstellen.

=== Weiterführende Themen ===
==== Verbinden mehrerer FHEM-Instanzen über MQTT ====
Wie im Hauptartikel zu [[MQTT#Kommunikation zu sonstigen FHEM-Geräten über MQTT|MQTT]] erläutert, gibt es mehrere Varianten, wie man mit Hilfe von FHEM aus Events an beliebigen Geräten MQTT-Messages erzeugen kann. So kann man z.B. Messdaten eines Systems über ein ''notify'' iVm. einer einfachen ''publish''-Anweisung an ein zweites FHEM schicken, das diese Daten dann z.B. mit Hilfe der MQTT2-Module auswerten kann.
Damit dabei Nachrichten unterschiedlicher Quellen auch als getrennte Readings bzw. ggf. auch gesonderten MQTT2_DEVICE-Instanzen zugeordnet werden, sollte man entsprechende Topic-Strukturen wählen, die dann auch mit Hilfe einer geeigneten ''bridgeRegexp'' automatisiert ausgewertet werden kann, siehe z.B. dieser {{Link2Forum|Topic=107145|LinkText=Forumsthread}}:
 attr MQTT2_myMqttServer bridgeRegexp \
   SmartHome/MqttGenericBridge2/([A-Za-z0-9]*)/.*:.* "mgb2_$1"
Dabei werden die betreffenden Informationen der entfernten FHEM-Instanz alle nach dem Schema ''SmartHome/MqttGenericBridge2/<Device-Name>/<Reading-Name>'' versendet.

==== Umstellung von MQTT_DEVICE (und Derivaten wie XiaomiMQTTDevice) zu MQTT2_DEVICE ====
Wer beabsichtigt, von der Implementierung MQTT+MQTT_DEVICE zu MQTT2-IO und MQTT2_DEVICE zu wechseln, sollte einige Punkte beachten. Viele diesbezügliche Fragen sind vor allem in  {{Link2Forum|Topic=103762|LinkText=diesem Foren-Thread}}

näher erläutert.

== Links ==
* {{Link2Forum|Topic=91394|LinkText=Thread, aus dem diese Anleitung ursprünglich entstanden ist}}
* {{Link2Forum|Topic=91807|LinkText=Thread zum Tasmota-Device}}
* {{Link2Forum|Topic=97989|LinkText=Thread, aus dem diese Anleitung für den eBus ursprünglich entstanden ist}}
* {{Link2Forum|Topic=94495|LinkText=Neue templates einreichen}}
* {{Link2Forum|Topic=94494|LinkText=Fragen, Wünsche und Kritik zu mqtt2.template}}

== Hinweise ==
<references />
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]
[[Kategorie:ZigBee]]
[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]