FHEMWiki - Benutzerbeiträge [de]

EBUS

2020-05-04T15:25:15Z

Reinhart: Hinweis und Link für die neuen Adapter.

EBUS-MQTT2

2019-04-13T08:47:00Z

Reinhart: eBus devStateIcon + Templates selber modifizieren erweitert

== eBus - MQTT2 ==
Vorausgesetzt wird hier ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
=== eBus mit MQTT2 auswerten ===
https://forum.fhem.de/index.php/topic,91394.0.html

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte [https://forum.fhem.de/index.php/topic,91394.0.html MQTT2 DEVICE ] verwendet, damit wird als IO-Device entweder [https://forum.fhem.de/index.php/topic,91394.0.html MQTT2_SERVER ] oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.

=== Anwendung: ===
Wer eBus komfortabel in FHEM einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

[[Bild:MQTT2_MQTT2.jpg|600px|thumb|left|Uebersicht eBus MQTT]]

<div style="clear:both;"></div>
=== Welches FHEM Modul benötigt man ===
{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in FHEM.}}
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

{{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 entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden.

==== Externer Broker ====
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in FHEM anlegen ###
define MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto room MQTT2_DEVICE,System
==== FHEM-Interner Server ====
Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

==== "ebus-Bridge" ====
Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden später alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Es kann auch ein ggf. vom MQTT2_SERVER bereits automatisch angelegtes Device genutzt werden, bei Verwendung von MQTT2_CLIENT sollte das Device wie oben dargestellt manuell erstellt werden; es ist dabei darauf zu achten, dass die CID dem Basispfad des Topic-trees entspricht, der bei der Konfiguration des ebus-Dämons verwendet wurde.

Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:

[[Bild:MQTT2_1template E_00 installieren.png|400px|thumb|left|Template E_00_eBus_daemon_splitter]]
<div style="clear:both;"></div>

[[Bild:MQTT2_2splitter.png|400px|thumb|left|Eingabe im Splitter aendern]]
<div style="clear:both;"></div>

Gibt es noch keine readingList mit ebus-spezifischen Einträgen, erscheint ein Fenster. In diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und drückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

[[Bild:MQTT2_3Attribute_ebusd.png|400px|thumb|left|bridgeRegexp prüfen]]

<div style="clear:both;"></div>
(ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"

Nach der Konfiguration des bridge-Devices muß autocreate am IO-Device wieder aktiviert werden. Da hierbei die vom ebus-Dämon gesendeten JSON-Informationen in vielen Installationen nur sinnvoll genutzt werden können, wenn die Statusmeldungen jeweils getrennt dargestellt werden, setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

[[Bild:MQTT2_4autocreate-complex.png|400px|thumb|left|autocreate auf complex setzen]]

<div style="clear:both;"></div>

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird.
Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Dabei wird in der Regel sowohl die readingList am Device ''MQTT2_ebusd'' erweitert, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.

==== myUtils-Code ====
Nun benötigen wir noch etwas Code für die Balkendarstellung in FHEM. Dieser Code wird in die 99_myUtils.pm kopiert.
<syntaxhighlight lang="php">
sub Balkenanzeige($)
{
# Zuweisung der übergebenen Variablen
my ($val) = @_;
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
my $maxValue = 70;
# Normalisierung auf 100%-Wert
my $percent = $val / $maxValue * 100;
# Definition des valueStyles
my $stylestring = 'style="'.
'width: 200px; '.
'text-align:center; '.
'border: 1px solid #ccc ;'.
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
# Rückgabe des definierten Strings
return $stylestring;
}
</syntaxhighlight>

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.
define colorInit notify global:INITIALIZED {use Color}

==== Regelmäßige Werteabfrage ====

Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

+*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/FanSpeed/get;
set ebusMQTT publish ebusd/bai/WPPWMPower/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get
set ebusMQTT publish ebusd/bai/FanHours/get
set ebusMQTT publish ebusd/bai/HcHours/get
set ebusMQTT publish ebusd/bai/HwcHours/get
set ebusMQTT publish ebusd/bai/HwcStarts/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der FHEM Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

=== ebus-Spezifische weitere Templates ===
==== Installation ====

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „{{Link2Forum|Topic=79600|LinkText=mqtt2.ebus.template}}“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren.
Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

{{Randnotiz|RNTyp=r|RNText=Bitte das Template immer aus dem richtigen Device (zB: MQTT2_ebusd_430 für die Heizkurve) installieren, ansonsten wird das Reading des Device nicht gefunden bzw. falsch zugeordnet.}}

[[Bild:MQTT2_7templateinitialize.png|400px|thumb|left|vor der ersten Benutzung in der Eingabezeile eingeben]]

<div style="clear:both;"></div>
Dazu in der FHEM Eingabezeile eingeben:
{ AttrTemplate_Initialize() }

==== Anwendung der Templates ====

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D.h. in der Templateliste das gewünschte auswählen (hier MQTT2_ebusd_bai). Die eBus Templates beginnen alle mit E….

[[Bild:MQTT2_8templateselect.png|400px|thumb|left|Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein]]

<div style="clear:both;"></div>
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

<div style="clear:both;"></div>
[[Bild:MQTT2_5statustemplate.png|400px|thumb|left|Das Template hat die gewünschte Konfiguration in FHEM durchgeführt]]

[[Bild:MQTT2_6status1template.png|400px|thumb|left|Ergebnis des Template, Heizkurve und Warmwassertemperatur]]
Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

<div style="clear:both;"></div>

==== Muster Templates ====

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt.
Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Achtung: die hier gewählte Nummerierung kann sich im Laufe der Zeit ändern, da die Templates öfters erweitert/geändert werden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater
[[Bild:MQTT2_ebusset.png|250px|thumb|left|Set hcurve und HWCtemdesired]]
<div style="clear:both;"></div>

Template: E_01_eBus_bai_readingsgroup_Status01
[[Bild:MQTT2_ebustemp.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_02_eBus_bai_readingsgroup_Status01_Balken
[[Bild:MQTT2_ebustempbalken.png|400px|thumb|left|EStatusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>
Template: E_03_eBus_bai_readingsgroup_Status02
[[Bild:MQTT2_ebuswarmwasser.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_04_eBus_bai_readingsgroup_Status02_Balken
[[Bild:MQTT2_ebuswarmwasserbalken.png|400px|thumb|left|Statusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>

Template: hier noch einige Beispiel Templates die mit devStateIcon erzeugt wurden.
[[Bild:MQTT2_devStateIcon.png|400px|thumb|left|Templates auf Basis devStateIcon]]

<div style="clear:both;"></div>

==== Templates erweitern ====

Die Templates können vom User selbst leicht erweitert werden. Dies kann entweder im fertigen "define/defmod" oder aber auch im Template vorgenommen werden.

Als Beispiel erweitern wir hier die readingsgroup "eBusset" um die Temperatur zur Nachtabsenkung.

<>,<Name>,< Ist>,<      Soll>
MQTT2_ebusd_430:<%message_tendency_steady>,<Heizkurve>,Hc1HeatCurve_curve_value,<sollcurve>
MQTT2_ebusd_430:<%sani_water_hot>,<Warmwasser>,HwcTempDesired_temp1_value,<sollwater>
MQTT2_ebusd_430:<%temp_temperature_min>,<Nachtabsenkung>,Hc1NightTemp_temp1_value,<sollnight>
Dazu erweitern wir als erstes hier die letzte Zeile der Definition

{'eBusSet.sollcurve'=>'Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70',
'eBusSet.sollwater'=>'HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0',
'eBusSet.sollnight'=>'Hc1NightTemp_temp1_value:uzsuDropDown,10.0,11.0,12.0,13.0,14.0,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0'}
dann die Sollwertvorgabe um die Hc1NightTemp_temp1_value mit den Vorgaben

{'Hc1HeatCurve_curve_value' => '{"style=\"color:\x23".substr(Color::pahColor(5,10,15,$VALUE*10,0),0,6)."\""}',
'HwcTempDesired_temp1_value' => '{"style=\"color:\x23".substr(Color::pahColor(20,40,60,$VALUE,0),0,6)."\""}',
'Hc1NightTemp_temp1_value' => '{"style=\"color:\x23".substr(Color::pahColor(10,15,20,$VALUE,0),0,6)."\""}'}
und schließlich wird noch die dynamische Farbgebung des Sollwertes angepasst.

set ebusMQTT publish ebusd/430/Hc1NightTemp/get;
damit auch der Messwert abgefragt wird, muss noch ein Eintrag im EBUS.TIMER dazu gehängt werden.
[[Bild:MQTT2_Nighttemp.png|400px|thumb|left|Nachtabsenkung Sollwert über readingsgroup]]
Nach Erweiterung der 3 Zeilen sieht das dann so aus.

<div style="clear:both;"></div>

=Weiterführende Links=
Diskussionsthread aus dem Forum:
*{{Link2Forum|Topic=97989|LinkText=ebusd.mqtt2.template: Fragen, Anregungen}}
*{{Link2Forum|Topic=79600|LinkText=Läuft: MQTT2 Teil3 Realisierung mit MQTT2_Client mit oder ohne Mosquitto}}
*{{Link2Forum|Topic=91394|LinkText=zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE}}
*{{Link2Forum|Topic=97989|LinkText=ebusd.mqtt2.template: Fragen, Anregungen}}

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Interfaces]]

Datei:MQTT2 Nighttemp.png

2019-04-13T08:11:50Z

Reinhart: MQTT2

== Beschreibung ==
MQTT2

Datei:MQTT2 devStateIcon.png

2019-04-13T08:11:17Z

Reinhart: MQTT2

== Beschreibung ==
MQTT2

EBUS

2019-03-12T11:05:22Z

Reinhart: /* Visualisierung und Steuerung */

EBUS

2019-03-12T10:59:10Z

Reinhart: ECMD ausgegliedert

EBUS-ECMD

2019-03-12T10:51:45Z

Reinhart: ebus Konfiguration von ECMD zur besseren Übersicht ausgegliedert

== Ebus ECMD ==
Eine einfache aber sichere Anbindung des eBusd an FHEM kann mit [[ECMD]] durchgeführt werden. Es ist egal ob eBusd auf dem selben Raspberry wie FHEM läuft oder ein eigener Raspberry dafür verwendet wird. Die gezeigten Beispiele sind nur eine der Möglichkeiten die zum Ziel führen, sollen aber sicher und schnell zu den ersten Erfolgen führen.

===ECMD in FHEM aktivieren===
<syntaxhighlight lang="php">
# fhem.cfg
define EBUS ECMD telnet '''ip-raspi-ebusd''':8888 # IP Adresse ebusd einsetzen!!!
attr EBUS classdefs bai00.class=/opt/fhem/FHEM/bai00.cfg
attr EBUS icon usb
attr EBUS requestSeparator 000
attr EBUS room Vaillant

# Die Definition von ECMD, "ip-raspi-ebusd" muss durch die IP-Adresse ersetzt werden. Beispiel:
define EBUS ECMD telnet 192.168.0.10:8888
</syntaxhighlight>
Die Kommunikation erfolgt über Telnet und 8888 ist das Port über welches kommuniziert werden soll.

===ECMD Devices definieren===
<syntaxhighlight lang="php">
# fhem.cfg
define Vorlauf ECMDDevice bai00.class
attr Vorlauf IODev EBUS
attr Vorlauf group Vaillant
attr Vorlauf icon sani_supply_temp
attr Vorlauf room Vaillant

define Ruecklauf ECMDDevice bai00.class
attr Ruecklauf IODev EBUS
attr Ruecklauf group Vaillant
attr Ruecklauf icon sani_return_temp
attr Ruecklauf room Vaillant

define PumpeWatt ECMDDevice bai00.class
attr PumpeWatt IODev EBUS
attr PumpeWatt group Vaillant
attr PumpeWatt icon measure_power
attr PumpeWatt room Vaillant

define Fanspeed ECMDDevice bai00.class
attr Fanspeed IODev EBUS
attr Fanspeed group Vaillant
attr Fanspeed icon vent_ventilation_level_automatic
attr Fanspeed room Vaillant

define HKurve ECMDDevice bai00.class
attr HKurve IODev EBUS
attr HKurve group Vaillant
attr HKurve icon temp_control
attr HKurve room Vaillant
</syntaxhighlight>
Jeder Messwert der von eBusd abgefragt werden soll, muss dazu ein ECMDDevice erstellt werden. Hier ein paar Beispiele mit Vorlauf, Rücklauf, Leistung der Pumpe, Ventilatorgeschwindigkeit und der Heizkurve.

[[Datei:EBUS_Daten_Heizung.png|thumb|left|alt=EBUS-USB Interface]]
Zu jedem ECMDDevice muss es eine Classdefinition in der bai00.cfg geben. Der Name "bai00.cfg" ist frei gewählt und wird in diesen Beispielen verwendet.
<div style="clear:both;"></div>

===ECMD Classdefinition===

Um eine Klasse zu definieren muss der dazu benötigte Code in eine eigene Datei (hier bai00.cfg) geschrieben werden.

<syntaxhighlight lang="perl">
################## bai00.cfg ###############
#
#!/usr/bin/perl
# Aussentemperatur
get Aussentemp cmd {"r -f outsidetemp temp\n"}
get Aussentemp expect ".*\n*"
get Aussentemp postproc { $_ }
#
# vorlauftemperatur
get Vorlauf cmd {"r -m 10 status01 temp1.0\n"}
get Vorlauf expect "\d+\.\d+\n\n"
get Vorlauf postproc { sprintf("%5.1f",$_) }
#
# Ruecklauftemperatur
get Ruecklauf cmd {"r -m 10 status01 temp1.1\n"}
get Ruecklauf expect "\d+\.\d+\n\n"
get Ruecklauf postproc { sprintf("%5.1f",$_) }
#
# Pumpenleistung
get PumpeWatt cmd {"r -f PumpPower\n"}
get PumpeWatt expect "\d+\n\n"
get PumpeWatt postproc { sprintf("%5.0f",$_) }
#
# Fanspeed
get Fanspeed cmd {"r -f SDFanSpeed\n"}
get Fanspeed expect "\d+\n\n"
get Fanspeed postproc { sprintf("%5.0f",$_) }
#
# Heizkurve lesen
get HKurve cmd {"r -f Hc1HeatCurve\n"}
get HKurve expect "\d+\.\d+\n"
get HKurve postproc { sprintf("%3.1f",$_) }
#
# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"write 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_ }
</syntaxhighlight>

Für jeden Device wird hier festgelegt wie die Befehls Syntax der Abfrage auszusehen hat (cmd) und wie die Ergebnisse zu filtern sind (expect), wie soll das Ausgabeformat sein (postproc). Diese Definitionen bitte in einer neuen Datei "bai00.cfg" speichern.

===ECMD Zyklische Abfrage===
<syntaxhighlight lang="php">
# Abfrage Timersteuerung, fhem.cfg
define EBUS.Timer at +*00:15:00 get Aussentemp Aussentemp;;get Vorlauf Vorlauf;;get Ruecklauf Ruecklauf;;get PumpeWatt PumpeWatt;get Fanspeed Fanspeed;;get PumpeWatt PumpeWatt;;get HKurve HKurve
attr EBUS.Timer group VaillantControl
attr EBUS.Timer icon time_timer
attr EBUS.Timer room Vaillant
attr EBUS.Timer verbose 0
</syntaxhighlight>

Um die Daten auch zyklisch vom eBus abholen zu können, wird ein Timer gesetzt. Hier wird alle 15 Minuten abgefragt.
Tipp: unwichtige Daten wie Druck oder irgendwelche Zähler definiert man in einem zweiten Timer, welcher dann zB. auf 1 Stunde getriggert wird. So wird die Häufigkeit des Zugriffs auf den eBus entlastet.

===ECMD Solar, Warmwasser und Heizkreis===

====ECMD Beispiel Solar====
Im nachfolgenden Beispiel wird der EBUS über das Modul ECMD angebunden und mit drei Klassen von Kommandos versehen. IP Adresse ist jene des Device wo der eBusd läuft.
<syntaxhighlight lang="php">
define EBUS ECMD telnet 192.168.0.192:8888
attr EBUS classdefs HK.SOL.class=/opt/fhem/FHEM/ebus_solar.cfg:HK.WW.class=/opt/fhem/FHEM/ebus_ww.cfg:HK.Hz.class=/opt/fhem/FHEM/ebus_hz.cfg
attr EBUS room System
#--
define HK.Hz ECMDDevice HK.Hz.class
attr HK.Hz IODev EBUS
attr HK.Hz group heating
attr HK.Hz room Verbrauch
#--
define HK.WW ECMDDevice HK.WW.class
attr HK.WW IODev EBUS
attr HK.WW group heating
attr HK.WW room Verbrauch
#--
define HK.SOL ECMDDevice HK.SOL.class
attr HK.SOL IODev EBUS
attr HK.SOL group solarGenerator
attr HK.SOL room Solaranlage
#--
# Diese drei Klassen werden als separate Files mit den in der EBUS-Definition stehenden Dateinamen ''ebus_hz.cfg'', ''ebus_ww.cfg'' sowie ''ebus_solar.cfg'' angelegt. Alle drei ECMD-Devices werden nun zyklisch (z.B. jede Minute) abgefragt mit
define EBUS.Timer at +*00:01:00 get HK.Hz A.Temp;;get HK.Hz state;;get HK.WW state;;get HK.SOL state
attr EBUS.Timer group heatingControl
attr EBUS.Timer room Verbrauch
attr EBUS.Timer verbose 0
</syntaxhighlight>

====ECMD Classdefinition Heizkreis====
Die erste Datei definiert die FHEM-Readings für die Abfrage von Außentemperatur und Heizkreis:
<syntaxhighlight lang="perl">
# Außentemperatur
get A.Temp cmd {"cyc broad temp\n"}
get A.Temp expect ".*"
get A.Temp postproc { my $rval;\
if(($_ eq "")||($_ eq "no data stored") ){\
$rval = "err";\
}else{\
$rval=sprintf("%5.2f °C",$_);\
}\
$rval; }
# Heizkeis HK1
get state cmd {"cyc mv HK1_temp\n"}
get state expect ".*"
get state postproc { my ($bval,$rval,$tval,$pval,$qval,$sval,$xval,$zval);\
my $hash = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
$bval = "err";\
$rval = "err";\
$tval = "err";\
$pval = "err";\
$qval = "err";\
$sval = "err";\
$xval = "err";\
$zval = "err";\
}else{\
my @values=split(' ',$_);\
if( $values[0] < 15 ){\
$bval = "err";\
$rval = "err";\
$tval = "err";\
$pval = "err";\
$qval = "err";\
$sval = "err";\
$xval = "err";\
$zval = "err";\
} else { \
$bval = HzBedarf();\
$rval = sprintf("%5.2f °C",$values[0]);\
$tval = sprintf("%5.2f °C",$values[1]);\
if( $values[2] == 0 ){\
$pval = "OFF";\
$qval = "0 0";\
}elsif( $values[2] == 1 ){\
$pval = "ON (HK)";\
$qval = "80 0";\
}elsif( $values[2] == 2 ){\
$pval = "ON (WW)";\
$qval = "0 80";\
}else{\
$pval = "unknown";\
$qval = "err";\
}\
$sval = sprintf("%d",$values[2]);\
$xval = sprintf("%5.2f %5.2f %s %5.2f",\
$values[0],$values[1],$qval,$bval);\
$zval = sprintf("VL.T %5.2f °C, RL.T %5.2f °C, %s",\
$values[0],$values[1],$pval);\
}\
}\
readingsSingleUpdate($hash, "VL.T", $rval, 1);\
readingsSingleUpdate($hash, "RL.T", $tval, 1);\
readingsSingleUpdate($hash, "Pumpe", $pval, 1); \
readingsSingleUpdate($hash, "Pumpe.P", $qval, 1); \
readingsSingleUpdate($hash, "Bedarf", $bval, 1); \
readingsSingleUpdate($hash, "Status", $sval, 1);\
readingsSingleUpdate($hash, "reading", $xval, 1);\
$zval; }
</syntaxhighlight>

====ECMD Classdefinition Warmwasserkreis====
Die zweite Datei definiert die FHEM-Readings für den Warmwasserkreis:
<syntaxhighlight lang="perl">
# Warmwasserkreis
get state cmd {"cyc broad getstatus_WW\n"}
get state expect ".*"
get state postproc { my ($rval,$tval,$bval,$pval,$xval,$zval);\
my $hash = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
$rval = "err";\
$tval = "err";\
$bval = "err";\
$pval = "err";\
$xval = "err";\
$zval = "err";\
}else{\
my @values=split(' ',$_);\
if( $values[1] < 15 ){\
$rval = "err";\
$tval = "err";\
$bval = "err";\
$pval = "err";\
$xval = "err";\
$zval = "err";\
}else {\
$rval = sprintf("%5.2f °C",$values[0]);\
$tval = sprintf("%5.2f °C",$values[1]);\
$bval = ($values[2] == 80) ? "ON (WW)" : "OFF";\
$pval = ($values[3] == 1) ? "ON" : "OFF";\
$xval = sprintf("%5.2f %5.2f %5.2f %d %d",\
$values[0],0.0,$values[1],$values[2],$values[3]);\
$zval = sprintf("SF1.T %5.2f °C, %s",\
$values[0],$pval);\
}\
}\
$zval; }
</syntaxhighlight>

====ECMD Classdefinition Solarkreis====
Die dritte Datei definiert die FHEM-Readings für den Solarkreis:
<syntaxhighlight lang="perl">
# Solarkreis
get state cmd {"cyc broad getstatus_SOL\n"}
get state expect ".*"
get state postproc { my ($rval,$pval,$qval,$lval,$yval,$xval,$zval);\
my $hash = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
$rval = "err";\
$pval = "err";\
$qval = "err";\
$lval = "err";\
$yval = "err";\
$xval = "err";\
$zval = "err";\
}else{\
my @values=split(' ',$_);\
$rval = sprintf("%5.2f °C",$values[0]);\
$pval = ($values[1] == 1)?"ON":"OFF";\
$qval = ($values[1] == 1)?65:0;\
$lval = sprintf("%5.2f %%",$values[2]);\
$yval = sprintf("%d",$values[3]);\
$xval = sprintf("%5.2f %d %5.2f %d",\
$values[0],$qval,$values[2],$values[3]);\
$zval = sprintf("Coll.T %5.2f °C, %s",\
$values[0],$pval);\
}\
readingsSingleUpdate($hash, "Coll.T", $rval, 1);\
readingsSingleUpdate($hash, "Pumpe", $pval, 1);\
readingsSingleUpdate($hash, "Pumpe.P", $qval." W", 1);\
readingsSingleUpdate($hash, "Load", $lval, 1);\
readingsSingleUpdate($hash, "Yield", $yval, 1);\
readingsSingleUpdate($hash, "reading", $xval, 1);\
$zval; }
</syntaxhighlight>

===ECMD Classdefinition Heizkurve===

Diese Klassendefinition muss in der bai00.cfg gespeichert (angehängt) werden.
in diesem Beispiel wurde sie für die Vaillant Calormatic 430 definiert, bei einer Calormatic 470 muss der Text entsprechend geändert werden.

<syntaxhighlight lang="php">
# HeizkurveSchreiben Calormatic 430, bai00.cfg
get HeizkurveSchreiben cmd {"write -c 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_ }
</syntaxhighlight>

===Heizkurve schreiben===
<syntaxhighlight lang="php">
#fhem.cfg
define HeizkurveEinstellen dummy
attr HeizkurveEinstellen group Heizkurve_Einstellen
attr HeizkurveEinstellen icon temp_control
attr HeizkurveEinstellen room Vaillant,Heizung
attr HeizkurveEinstellen setList state:0.20,0.40,0.50,0.60,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70
attr HeizkurveEinstellen webCmd state

define HeizkurveSchreiben_Click notify HeizkurveEinstellen {\
fhem("get HeizkurveSchreiben HeizkurveSchreiben");;\
}
attr HeizkurveSchreiben_Click group heatingControl
attr HeizkurveSchreiben_Click room Vaillant

define HeizkurveSchreiben ECMDDevice bai00.class
attr HeizkurveSchreiben IODev EBUS
attr HeizkurveSchreiben group Heizkurve_Einstellen
attr HeizkurveSchreiben room Vaillant
</syntaxhighlight>

Ein kleines Demo wie man via ECMD und eBus die Daten zurück in die Register der Therme (Calormatic) schreiben kann. Hier wird die Heizkurve verstellt.
Ein Dummy wird definiert und über eine setList werden die verschiedenen Kurven vorgegeben. Dank setList kann es zu keinen unerlaubten Eingaben kommen. Über den notify wird die Heizkurve dann schließlich gesetzt.

[[Datei:EBUS_Heizkurve_Einstellen.png|thumb|left|alt=EBUS-USB Interface]]
Vorsicht: überlegt euch bitte gut was ihr zurück schreiben wollt, es kann unter Umständen gefährlich für eure Hardware oder Gesundheit werden (zB: Warmwasser auf über 60 Grad). Alles was hier durchgeführt wird, führt ihr auf eigene Verantwortung durch.
<div style="clear:both;"></div>

===Wochenprogramme===
Ein gerne benutztes Feature ist die Änderung der Zeitprogramme des Heizgerätes in FHEM. Die Visualisierung ist etwas komplexer weil alles x 7 ist und hier Steuerzeichen beim Zusammensetzen des Sendestrings vorkommen die nicht direkt übergeben werden können. Einzelne Timer können damit nicht geschrieben werden, daher wird bei jeder Timereingabe der komplette String geschrieben. Der Einfachheit halber und wegen der Übersicht sind nur 2 Tagesprogramme (Timer) im Beispielcode vorgesehen (die Calormatic kann 3).
[[Datei:EBUS_Timerprogramme.png|thumb|left|alt=Wochentimer]]
<div style="clear:both;"></div>
<syntaxhighlight lang="perl">
#####################
# Timer-Programme #
#####################
get Mo cmd {"r -f hc1Timer.Monday\n"}
get Mo expect ".*\n\n"
get Mo postproc { Vaillant_Timer($_); }
get Di cmd {"r -f hc1Timer.Tuesday\n"}
get Di expect ".*\n\n"
get Di postproc { Vaillant_Timer($_); }
get Mi cmd {"r -f hc1Timer.Wednesday\n"}
get Mi expect ".*\n\n"
get Mi postproc { Vaillant_Timer($_); }
get Do cmd {"r -f hc1Timer.Thursday\n"}
get Do expect ".*\n\n"
get Do postproc { Vaillant_Timer($_); }
get Fr cmd {"r -f hc1Timer.Friday\n"}
get Fr expect ".*\n\n"
get Fr postproc { Vaillant_Timer($_); }
get Sa cmd {"r -f hc1Timer.Saturday\n"}
get Sa expect ".*\n\n"
get Sa postproc { Vaillant_Timer($_); }
get So cmd {"r -f hc1Timer.Sunday\n"}
get So expect ".*\n\n"
get So postproc { Vaillant_Timer($_); }
get ZeitfensterSchreibenMo cmd {"write -c 430 hc1Timer.Monday ".ReadingsVal("TimeMo","HHMM1",0) . chr(59) . ReadingsVal("TimeMo","HHMM2",0) . chr(59) . ReadingsVal("TimeMo","HHMM3",0) . chr(59) . ReadingsVal("TimeMo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenMo expect ".*\n\n"
get ZeitfensterSchreibenMo postproc { $_ }
get ZeitfensterSchreibenDi cmd {"write -c 430 hc1Timer.Tuesday ".ReadingsVal("TimeDi","HHMM1",0) . chr(59) . ReadingsVal("TimeDi","HHMM2",0) . chr(59) . ReadingsVal("TimeDi","HHMM3",0) . chr(59) . ReadingsVal("TimeDi","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenDi expect ".*\n\n"
get ZeitfensterSchreibenDi postproc { $_ }
get ZeitfensterSchreibenMi cmd {"write -c 430 hc1Timer.Wednesday ".ReadingsVal("TimeMi","HHMM1",0) . chr(59) . ReadingsVal("TimeMi","HHMM2",0) . chr(59) . ReadingsVal("TimeMi","HHMM3",0) . chr(59) . ReadingsVal("TimeMi","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenMi expect ".*\n\n"
get ZeitfensterSchreibenMi postproc { $_ }
get ZeitfensterSchreibenDo cmd {"write -c 430 hc1Timer.Thursday ".ReadingsVal("TimeDo","HHMM1",0) . chr(59) . ReadingsVal("TimeDo","HHMM2",0) . chr(59) . ReadingsVal("TimeDo","HHMM3",0) . chr(59) . ReadingsVal("TimeDo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenDo expect ".*\n\n"
get ZeitfensterSchreibenDo postproc { $_ }
get ZeitfensterSchreibenFr cmd {"write -c 430 hc1Timer.Friday ".ReadingsVal("TimeFr","HHMM1",0) . chr(59) . ReadingsVal("TimeFr","HHMM2",0) . chr(59) . ReadingsVal("TimeFr","HHMM3",0) . chr(59) . ReadingsVal("TimeFr","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenFr expect ".*\n\n"
get ZeitfensterSchreibenFr postproc { $_ }
get ZeitfensterSchreibenSa cmd {"write -c 430 hc1Timer.Saturday ".ReadingsVal("TimeSa","HHMM1",0) . chr(59) . ReadingsVal("TimeSa","HHMM2",0) . chr(59) . ReadingsVal("TimeSa","HHMM3",0) . chr(59) . ReadingsVal("TimeSa","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenSa expect ".*\n\n"
get ZeitfensterSchreibenSa postproc { $_ }
get ZeitfensterSchreibenSo cmd {"write -c 430 hc1Timer.Sunday ".ReadingsVal("TimeSo","HHMM1",0) . chr(59) . ReadingsVal("TimeSo","HHMM2",0) . chr(59) . ReadingsVal("TimeSo","HHMM3",0) . chr(59) . ReadingsVal("TimeSo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenSo expect ".*\n\n"
get ZeitfensterSchreibenSo postproc { $_ }
</syntaxhighlight>

Dieses Beispiel ist für eine Vaillant Calormatic 430, bei einer Calormatic 470 müssen die entsprechenden Zeilen angepasst werden (write -c 430....) .

<syntaxhighlight lang="perl">
#########################################################
#
# Vaillant_Timer
# Datenstring = 03:30;19:30;20:00;20:00;20:00;20:00;Mo-Fr
#########################################################
# 99_myUtils.pm
sub Vaillant_Timer($)
{
my @values=split(/[; ]/,$_);
#-- suppress leading zero ?
for(my $i=0;$i<7;$i++){
$values[$i]=~s/^0//;
}
my $sval=sprintf("%s-%s",$values[0],$values[1]);
$sval .=sprintf(", %s-%s",$values[2],$values[3])
if($values[2] ne $values[3]);
$sval .=sprintf(", %s-%s",$values[4],$values[5])
if($values[4] ne $values[5]);
return $sval;
}
</syntaxhighlight>

Oben gezeigtes Beispiel benötigt den Vaillant_Timer (von Prof. Peter Henning). Dieser Code muss in die 99_myUtils.pm gespeichert werden. Unter diesem {{Link2Forum|Topic=41064|Message=336911|LinkText=Link}} gibt es weiterreichende Informationen zu diesem Thema.

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Interfaces]]

MQTT2-Module - Praxisbeispiele

2019-03-12T10:32:32Z

Reinhart: Anleitung eBus gekürzt, Kurzfassung ertstellt.

== Einführung: MQTT bzw. MQTT2 in FHEM ==
Zur Einbindung von Geräten, welche mit einem MQTT-Server (früher: Broker) kommunizieren können, 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]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] oder 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'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt setExtensions, allerdings muß dies dort per Attribut eingeschaltet werden</ref>.
{{Hinweis|Die nachfolgenden Beispiele gelingen am einfachsten mit MQTT2_SERVER als Server, für diesen sollte dabei ''autocreate'' aktiviert werden, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines autocreate-Device (TYPE=autocreate) ebenfalls aktiv ist</ref>.}}{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muß ggf. die "\" entfernen!}}

Beispiel:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server autocreate 1

== 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 muß 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.

=== 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 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 L_01_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 Meßwert) 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, muß 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äßt, 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 ==
[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. {{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}

=== 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. Hier wurden Tasmota version(en) 6.1.1 und 6.2.1 getestet, Hardware war Sonoff Touch und S20.

=== 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/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/LWT:.* LWT\
DVES_9B01BD:cmnd/sonoffkitchen/POWER:.* POWER\
DVES_9B01BD:tele/sonoffkitchen/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/sonoff/POWER on\
off cmnd/sonoff/POWER off\
reboot cmnd/sonoff/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===
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.

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

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

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

=== 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'' X_01_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 angepaßt 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_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013: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

== eBus ==
=== eBus mit MQTT2 auswerten ===

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte MQTT2 DEVICE verwendet, damit wird als IO-Device entweder MQTT2_SERVER oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!
Eine ausführliche Anleitung über die Konfiguration des [[EBUS-MQTT2|eBus MQTT2 gibt es hier]]

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.

=== Anwendung: ===
Wer eBus komfortabel in FHEM einbinden will, kann dies nun erstmals mit wenigen Mausklicks mithilfe der Templates realisieren.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Kommunikation mit dem eBus Dämon nicht mehr notwendig!

<div style="clear:both;"></div>
=== Welches FHEM Modul benötigt man ===
{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in FHEM.}}
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollte MQTT und die Topic definiert werden „ebusd/%circuit/%name“.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER.

{{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 entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden.

==== Externer Broker ====
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in FHEM anlegen ###
define MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto room MQTT2_DEVICE,System
==== FHEM-Interner Server ====
Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

==== "ebus-Bridge" ====
Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden später alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Es kann auch ein ggf. vom MQTT2_SERVER bereits automatisch angelegtes Device genutzt werden, bei Verwendung von MQTT2_CLIENT sollte das Device wie oben dargestellt manuell erstellt werden; es ist dabei darauf zu achten, dass die CID dem Basispfad des Topic-trees entspricht, der bei der Konfiguration des ebus-Dämons verwendet wurde.

Nach der Konfiguration des bridge-Devices muß autocreate am IO-Device wieder aktiviert werden. Da hierbei die vom ebus-Dämon gesendeten JSON-Informationen in vielen Installationen nur sinnvoll genutzt werden können, wenn die Statusmeldungen jeweils getrennt dargestellt werden, setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

Es werden dann nach einiger Zeit sowohl die readingList am Device ''MQTT2_ebusd'' erweitert, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.

== 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 angepaßt 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.

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''attrTemplate'' genutzt werden.
Die Anwendung ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.
== 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]]

EBUS-MQTT2

2019-03-12T10:10:39Z

Reinhart: Verlinkungen hinzugefügt

== eBus - MQTT2 ==
=== eBus mit MQTT2 auswerten ===
https://forum.fhem.de/index.php/topic,91394.0.html

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte [https://forum.fhem.de/index.php/topic,91394.0.html MQTT2 DEVICE ] verwendet, damit wird als IO-Device entweder [https://forum.fhem.de/index.php/topic,91394.0.html MQTT2_SERVER ] oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.

=== Anwendung: ===
Wer eBus komfortabel in FHEM einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

[[Bild:MQTT2_MQTT2.jpg|600px|thumb|left|Uebersicht eBus MQTT]]

<div style="clear:both;"></div>
=== Welches FHEM Modul benötigt man ===
{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in FHEM.}}
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

{{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 entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden.

==== Externer Broker ====
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in FHEM anlegen ###
define MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto room MQTT2_DEVICE,System
==== FHEM-Interner Server ====
Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

==== "ebus-Bridge" ====
Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden später alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Es kann auch ein ggf. vom MQTT2_SERVER bereits automatisch angelegtes Device genutzt werden, bei Verwendung von MQTT2_CLIENT sollte das Device wie oben dargestellt manuell erstellt werden; es ist dabei darauf zu achten, dass die CID dem Basispfad des Topic-trees entspricht, der bei der Konfiguration des ebus-Dämons verwendet wurde.

Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:

[[Bild:MQTT2_1template E_00 installieren.png|400px|thumb|left|Template E_00_eBus_daemon_splitter]]
<div style="clear:both;"></div>

[[Bild:MQTT2_2splitter.png|400px|thumb|left|Eingabe im Splitter aendern]]
<div style="clear:both;"></div>

Gibt es noch keine readingList mit ebus-spezifischen Einträgen, erscheint ein Fenster. In diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und drückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

[[Bild:MQTT2_3Attribute_ebusd.png|400px|thumb|left|bridgeRegexp prüfen]]

<div style="clear:both;"></div>
(ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"

Nach der Konfiguration des bridge-Devices muß autocreate am IO-Device wieder aktiviert werden. Da hierbei die vom ebus-Dämon gesendeten JSON-Informationen in vielen Installationen nur sinnvoll genutzt werden können, wenn die Statusmeldungen jeweils getrennt dargestellt werden, setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

[[Bild:MQTT2_4autocreate-complex.png|400px|thumb|left|autocreate auf complex setzen]]

<div style="clear:both;"></div>

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird.
Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Dabei wird in der Regel sowohl die readingList am Device ''MQTT2_ebusd'' erweitert, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.

==== myUtils-Code ====
Nun benötigen wir noch etwas Code für die Balkendarstellung in FHEM. Dieser Code wird in die 99_myUtils.pm kopiert.
<syntaxhighlight lang="php">
sub Balkenanzeige($)
{
# Zuweisung der übergebenen Variablen
my ($val) = @_;
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
my $maxValue = 70;
# Normalisierung auf 100%-Wert
my $percent = $val / $maxValue * 100;
# Definition des valueStyles
my $stylestring = 'style="'.
'width: 200px; '.
'text-align:center; '.
'border: 1px solid #ccc ;'.
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
# Rückgabe des definierten Strings
return $stylestring;
}
</syntaxhighlight>

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.
define colorInit notify global:INITIALIZED {use Color}

==== Regelmäßige Werteabfrage ====

Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

define EBUS.TIMER at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der FHEM Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

=== ebus-Spezifische weitere Templates ===
==== Installation ====

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „{{Link2Forum|Topic=79600|LinkText=mqtt2.ebus.template}}“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren.
Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

[[Bild:MQTT2_7templateinitialize.png|400px|thumb|left|vor der ersten Benutzung in der Eingabezeile eingeben]]

<div style="clear:both;"></div>
Dazu in der FHEM Eingabezeile eingeben:
{ AttrTemplate_Initialize() }

==== Anwendung der Templates ====

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D.h. in der Templateliste das gewünschte auswählen (hier MQTT2_ebusd_bai). Die eBus Templates beginnen alle mit E….

[[Bild:MQTT2_8templateselect.png|400px|thumb|left|Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein]]

<div style="clear:both;"></div>
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

<div style="clear:both;"></div>
[[Bild:MQTT2_5statustemplate.png|400px|thumb|left|Das Template hat die gewünschte Konfiguration in FHEM durchgeführt]]

[[Bild:MQTT2_6status1template.png|400px|thumb|left|Ergebnis des Template, Heizkurve und Warmwassertemperatur]]
Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

<div style="clear:both;"></div>

==== Muster Templates ====

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt.
Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater
[[Bild:MQTT2_ebusset.png|250px|thumb|left|Set hcurve und HWCtemdesired]]
<div style="clear:both;"></div>

Template: E_01_eBus_bai_readingsgroup_Status01
[[Bild:MQTT2_ebustemp.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_02_eBus_bai_readingsgroup_Status01_Balken
[[Bild:MQTT2_ebustempbalken.png|400px|thumb|left|EStatusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>
Template: E_03_eBus_bai_readingsgroup_Status02
[[Bild:MQTT2_ebuswarmwasser.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_04_eBus_bai_readingsgroup_Status02_Balken
[[Bild:MQTT2_ebuswarmwasserbalken.png|400px|thumb|left|Statusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>

=Weiterführende Links=
Diskussionsthread aus dem Forum:
*{{Link2Forum|Topic=97989|LinkText=ebusd.mqtt2.template: Fragen, Anregungen}}
*{{Link2Forum|Topic=79600|LinkText=Läuft: MQTT2 Teil3 Realisierung mit MQTT2_Client mit oder ohne Mosquitto}}
*{{Link2Forum|Topic=91394|LinkText=zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE}}
*{{Link2Forum|Topic=97989|LinkText=ebusd.mqtt2.template: Fragen, Anregungen}}

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Interfaces]]

EBUS-MQTT2

2019-03-12T08:10:12Z

Reinhart: eBUS MQTT2 Installation und Konfiguration

== eBus - MQTT2 ==
=== eBus mit MQTT2 auswerten ===

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte MQTT2 DEVICE verwendet, damit wird als IO-Device entweder MQTT2_SERVER oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.

=== Anwendung: ===
Wer eBus komfortabel in FHEM einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

[[Bild:MQTT2_MQTT2.jpg|600px|thumb|left|Uebersicht eBus MQTT]]

<div style="clear:both;"></div>
=== Welches FHEM Modul benötigt man ===
{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in FHEM.}}
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

{{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 entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden.

==== Externer Broker ====
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in FHEM anlegen ###
define MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto room MQTT2_DEVICE,System
==== FHEM-Interner Server ====
Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

==== "ebus-Bridge" ====
Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden später alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Es kann auch ein ggf. vom MQTT2_SERVER bereits automatisch angelegtes Device genutzt werden, bei Verwendung von MQTT2_CLIENT sollte das Device wie oben dargestellt manuell erstellt werden; es ist dabei darauf zu achten, dass die CID dem Basispfad des Topic-trees entspricht, der bei der Konfiguration des ebus-Dämons verwendet wurde.

Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:

[[Bild:MQTT2_1template E_00 installieren.png|400px|thumb|left|Template E_00_eBus_daemon_splitter]]
<div style="clear:both;"></div>

[[Bild:MQTT2_2splitter.png|400px|thumb|left|Eingabe im Splitter aendern]]
<div style="clear:both;"></div>

Gibt es noch keine readingList mit ebus-spezifischen Einträgen, erscheint ein Fenster. In diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und drückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

[[Bild:MQTT2_3Attribute_ebusd.png|400px|thumb|left|bridgeRegexp prüfen]]

<div style="clear:both;"></div>
(ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"

Nach der Konfiguration des bridge-Devices muß autocreate am IO-Device wieder aktiviert werden. Da hierbei die vom ebus-Dämon gesendeten JSON-Informationen in vielen Installationen nur sinnvoll genutzt werden können, wenn die Statusmeldungen jeweils getrennt dargestellt werden, setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

[[Bild:MQTT2_4autocreate-complex.png|400px|thumb|left|autocreate auf complex setzen]]

<div style="clear:both;"></div>

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird.
Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Dabei wird in der Regel sowohl die readingList am Device ''MQTT2_ebusd'' erweitert, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.

==== myUtils-Code ====
Nun benötigen wir noch etwas Code für die Balkendarstellung in FHEM. Dieser Code wird in die 99_myUtils.pm kopiert.
<syntaxhighlight lang="php">
sub Balkenanzeige($)
{
# Zuweisung der übergebenen Variablen
my ($val) = @_;
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
my $maxValue = 70;
# Normalisierung auf 100%-Wert
my $percent = $val / $maxValue * 100;
# Definition des valueStyles
my $stylestring = 'style="'.
'width: 200px; '.
'text-align:center; '.
'border: 1px solid #ccc ;'.
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
# Rückgabe des definierten Strings
return $stylestring;
}
</syntaxhighlight>

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.
define colorInit notify global:INITIALIZED {use Color}

==== Regelmäßige Werteabfrage ====

Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

define EBUS.TIMER at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der FHEM Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

=== ebus-Spezifische weitere Templates ===
==== Installation ====

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „{{Link2Forum|Topic=79600|LinkText=mqtt2.ebus.template}}“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren.
Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

[[Bild:MQTT2_7templateinitialize.png|400px|thumb|left|vor der ersten Benutzung in der Eingabezeile eingeben]]

<div style="clear:both;"></div>
Dazu in der FHEM Eingabezeile eingeben:
{ AttrTemplate_Initialize() }

==== Anwendung der Templates ====

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D.h. in der Templateliste das gewünschte auswählen (hier MQTT2_ebusd_bai). Die eBus Templates beginnen alle mit E….

[[Bild:MQTT2_8templateselect.png|400px|thumb|left|Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein]]

<div style="clear:both;"></div>
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

<div style="clear:both;"></div>
[[Bild:MQTT2_5statustemplate.png|400px|thumb|left|Das Template hat die gewünschte Konfiguration in FHEM durchgeführt]]

[[Bild:MQTT2_6status1template.png|400px|thumb|left|Ergebnis des Template, Heizkurve und Warmwassertemperatur]]
Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

<div style="clear:both;"></div>

==== Muster Templates ====

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt.
Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater
[[Bild:MQTT2_ebusset.png|250px|thumb|left|Set hcurve und HWCtemdesired]]
<div style="clear:both;"></div>

Template: E_01_eBus_bai_readingsgroup_Status01
[[Bild:MQTT2_ebustemp.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_02_eBus_bai_readingsgroup_Status01_Balken
[[Bild:MQTT2_ebustempbalken.png|400px|thumb|left|EStatusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>
Template: E_03_eBus_bai_readingsgroup_Status02
[[Bild:MQTT2_ebuswarmwasser.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_04_eBus_bai_readingsgroup_Status02_Balken
[[Bild:MQTT2_ebuswarmwasserbalken.png|400px|thumb|left|Statusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>

MQTT2-Module - Praxisbeispiele

2019-03-11T18:25:10Z

Reinhart: /* Anwendung der Templates */

== Einführung: MQTT bzw. MQTT2 in FHEM ==
Zur Einbindung von Geräten, welche mit einem MQTT-Server (früher: Broker) kommunizieren können, 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]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] oder 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'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt setExtensions, allerdings muß dies dort per Attribut eingeschaltet werden</ref>.
{{Hinweis|Die nachfolgenden Beispiele gelingen am einfachsten mit MQTT2_SERVER als Server, für diesen sollte dabei ''autocreate'' aktiviert werden, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines autocreate-Device (TYPE=autocreate) ebenfalls aktiv ist</ref>.}}{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muß ggf. die "\" entfernen!}}

Beispiel:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server autocreate 1

== 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 muß 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.

=== 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 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 L_01_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 Meßwert) 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, muß 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äßt, 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 ==
[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. {{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}

=== 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. Hier wurden Tasmota version(en) 6.1.1 und 6.2.1 getestet, Hardware war Sonoff Touch und S20.

=== 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/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/LWT:.* LWT\
DVES_9B01BD:cmnd/sonoffkitchen/POWER:.* POWER\
DVES_9B01BD:tele/sonoffkitchen/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/sonoff/POWER on\
off cmnd/sonoff/POWER off\
reboot cmnd/sonoff/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===
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.

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

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

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

=== 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'' X_01_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 angepaßt 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_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013: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

== eBus ==
=== eBus mit MQTT2 auswerten ===

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte MQTT2 DEVICE verwendet, damit wird als IO-Device entweder MQTT2_SERVER oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.

=== Anwendung: ===
Wer eBus komfortabel in FHEM einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

[[Bild:MQTT2_MQTT2.jpg|600px|thumb|left|Uebersicht eBus MQTT]]

<div style="clear:both;"></div>
=== Welches FHEM Modul benötigt man ===
{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in FHEM.}}
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

{{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 entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden.

==== Externer Broker ====
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in FHEM anlegen ###
define MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto room MQTT2_DEVICE,System
==== FHEM-Interner Server ====
Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

==== "ebus-Bridge" ====
Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden später alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Es kann auch ein ggf. vom MQTT2_SERVER bereits automatisch angelegtes Device genutzt werden, bei Verwendung von MQTT2_CLIENT sollte das Device wie oben dargestellt manuell erstellt werden; es ist dabei darauf zu achten, dass die CID dem Basispfad des Topic-trees entspricht, der bei der Konfiguration des ebus-Dämons verwendet wurde.

Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:

[[Bild:MQTT2_1template E_00 installieren.png|400px|thumb|left|Template E_00_eBus_daemon_splitter]]
<div style="clear:both;"></div>

[[Bild:MQTT2_2splitter.png|400px|thumb|left|Eingabe im Splitter aendern]]
<div style="clear:both;"></div>

Gibt es noch keine readingList mit ebus-spezifischen Einträgen, erscheint ein Fenster. In diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und drückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

[[Bild:MQTT2_3Attribute_ebusd.png|400px|thumb|left|bridgeRegexp prüfen]]

<div style="clear:both;"></div>
(ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"

Nach der Konfiguration des bridge-Devices muß autocreate am IO-Device wieder aktiviert werden. Da hierbei die vom ebus-Dämon gesendeten JSON-Informationen in vielen Installationen nur sinnvoll genutzt werden können, wenn die Statusmeldungen jeweils getrennt dargestellt werden, setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

[[Bild:MQTT2_4autocreate-complex.png|400px|thumb|left|autocreate auf complex setzen]]

<div style="clear:both;"></div>

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird.
Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Dabei wird in der Regel sowohl die readingList am Device ''MQTT2_ebusd'' erweitert, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.

==== myUtils-Code ====
Nun benötigen wir noch etwas Code für die Balkendarstellung in FHEM. Dieser Code wird in die 99_myUtils.pm kopiert.
<syntaxhighlight lang="php">
sub Balkenanzeige($)
{
# Zuweisung der übergebenen Variablen
my ($val) = @_;
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
my $maxValue = 70;
# Normalisierung auf 100%-Wert
my $percent = $val / $maxValue * 100;
# Definition des valueStyles
my $stylestring = 'style="'.
'width: 200px; '.
'text-align:center; '.
'border: 1px solid #ccc ;'.
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
# Rückgabe des definierten Strings
return $stylestring;
}
</syntaxhighlight>

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.
define colorInit notify global:INITIALIZED {use Color}

==== Regelmäßige Werteabfrage ====

Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

define EBUS.TIMER at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der FHEM Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

=== ebus-Spezifische weitere Templates ===
==== Installation ====

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „{{Link2Forum|Topic=79600|LinkText=mqtt2.ebus.template}}“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren.
Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

[[Bild:MQTT2_7templateinitialize.png|400px|thumb|left|vor der ersten Benutzung in der Eingabezeile eingeben]]

<div style="clear:both;"></div>
Dazu in der FHEM Eingabezeile eingeben:
{ AttrTemplate_Initialize() }

==== Anwendung der Templates ====

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D.h. in der Templateliste das gewünschte auswählen (hier MQTT2_ebusd_bai). Die eBus Templates beginnen alle mit E….

[[Bild:MQTT2_8templateselect.png|400px|thumb|left|Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein]]

<div style="clear:both;"></div>
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

<div style="clear:both;"></div>
[[Bild:MQTT2_5statustemplate.png|400px|thumb|left|Das Template hat die gewünschte Konfiguration in FHEM durchgeführt]]

[[Bild:MQTT2_6status1template.png|400px|thumb|left|Ergebnis des Template, Heizkurve und Warmwassertemperatur]]
Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

<div style="clear:both;"></div>

==== Muster Templates ====

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt.
Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater
[[Bild:MQTT2_ebusset.png|250px|thumb|left|Set hcurve und HWCtemdesired]]
<div style="clear:both;"></div>

Template: E_01_eBus_bai_readingsgroup_Status01
[[Bild:MQTT2_ebustemp.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_02_eBus_bai_readingsgroup_Status01_Balken
[[Bild:MQTT2_ebustempbalken.png|400px|thumb|left|EStatusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>
Template: E_03_eBus_bai_readingsgroup_Status02
[[Bild:MQTT2_ebuswarmwasser.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_04_eBus_bai_readingsgroup_Status02_Balken
[[Bild:MQTT2_ebuswarmwasserbalken.png|400px|thumb|left|Statusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>

== 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 angepaßt 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.

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''attrTemplate'' genutzt werden.
Die Anwendung ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.
== 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]]

MQTT2-Module - Praxisbeispiele

2019-03-11T18:22:47Z

Reinhart: /* Regelmäßige Werteabfrage */

== Einführung: MQTT bzw. MQTT2 in FHEM ==
Zur Einbindung von Geräten, welche mit einem MQTT-Server (früher: Broker) kommunizieren können, 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]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] oder 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'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt setExtensions, allerdings muß dies dort per Attribut eingeschaltet werden</ref>.
{{Hinweis|Die nachfolgenden Beispiele gelingen am einfachsten mit MQTT2_SERVER als Server, für diesen sollte dabei ''autocreate'' aktiviert werden, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines autocreate-Device (TYPE=autocreate) ebenfalls aktiv ist</ref>.}}{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muß ggf. die "\" entfernen!}}

Beispiel:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server autocreate 1

== 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 muß 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.

=== 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 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 L_01_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 Meßwert) 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, muß 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äßt, 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 ==
[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. {{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}

=== 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. Hier wurden Tasmota version(en) 6.1.1 und 6.2.1 getestet, Hardware war Sonoff Touch und S20.

=== 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/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/LWT:.* LWT\
DVES_9B01BD:cmnd/sonoffkitchen/POWER:.* POWER\
DVES_9B01BD:tele/sonoffkitchen/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/sonoff/POWER on\
off cmnd/sonoff/POWER off\
reboot cmnd/sonoff/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===
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.

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

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

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

=== 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'' X_01_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 angepaßt 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_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013: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

== eBus ==
=== eBus mit MQTT2 auswerten ===

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte MQTT2 DEVICE verwendet, damit wird als IO-Device entweder MQTT2_SERVER oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.

=== Anwendung: ===
Wer eBus komfortabel in FHEM einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

[[Bild:MQTT2_MQTT2.jpg|600px|thumb|left|Uebersicht eBus MQTT]]

<div style="clear:both;"></div>
=== Welches FHEM Modul benötigt man ===
{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in FHEM.}}
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

{{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 entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden.

==== Externer Broker ====
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in FHEM anlegen ###
define MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto room MQTT2_DEVICE,System
==== FHEM-Interner Server ====
Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

==== "ebus-Bridge" ====
Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden später alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Es kann auch ein ggf. vom MQTT2_SERVER bereits automatisch angelegtes Device genutzt werden, bei Verwendung von MQTT2_CLIENT sollte das Device wie oben dargestellt manuell erstellt werden; es ist dabei darauf zu achten, dass die CID dem Basispfad des Topic-trees entspricht, der bei der Konfiguration des ebus-Dämons verwendet wurde.

Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:

[[Bild:MQTT2_1template E_00 installieren.png|400px|thumb|left|Template E_00_eBus_daemon_splitter]]
<div style="clear:both;"></div>

[[Bild:MQTT2_2splitter.png|400px|thumb|left|Eingabe im Splitter aendern]]
<div style="clear:both;"></div>

Gibt es noch keine readingList mit ebus-spezifischen Einträgen, erscheint ein Fenster. In diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und drückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

[[Bild:MQTT2_3Attribute_ebusd.png|400px|thumb|left|bridgeRegexp prüfen]]

<div style="clear:both;"></div>
(ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"

Nach der Konfiguration des bridge-Devices muß autocreate am IO-Device wieder aktiviert werden. Da hierbei die vom ebus-Dämon gesendeten JSON-Informationen in vielen Installationen nur sinnvoll genutzt werden können, wenn die Statusmeldungen jeweils getrennt dargestellt werden, setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

[[Bild:MQTT2_4autocreate-complex.png|400px|thumb|left|autocreate auf complex setzen]]

<div style="clear:both;"></div>

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird.
Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Dabei wird in der Regel sowohl die readingList am Device ''MQTT2_ebusd'' erweitert, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.

==== myUtils-Code ====
Nun benötigen wir noch etwas Code für die Balkendarstellung in FHEM. Dieser Code wird in die 99_myUtils.pm kopiert.
<syntaxhighlight lang="php">
sub Balkenanzeige($)
{
# Zuweisung der übergebenen Variablen
my ($val) = @_;
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
my $maxValue = 70;
# Normalisierung auf 100%-Wert
my $percent = $val / $maxValue * 100;
# Definition des valueStyles
my $stylestring = 'style="'.
'width: 200px; '.
'text-align:center; '.
'border: 1px solid #ccc ;'.
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
# Rückgabe des definierten Strings
return $stylestring;
}
</syntaxhighlight>

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.
define colorInit notify global:INITIALIZED {use Color}

==== Regelmäßige Werteabfrage ====

Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

define EBUS.TIMER at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der FHEM Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

=== ebus-Spezifische weitere Templates ===
==== Installation ====

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „{{Link2Forum|Topic=79600|LinkText=mqtt2.ebus.template}}“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren.
Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

[[Bild:MQTT2_7templateinitialize.png|400px|thumb|left|vor der ersten Benutzung in der Eingabezeile eingeben]]

<div style="clear:both;"></div>
Dazu in der FHEM Eingabezeile eingeben:
{ AttrTemplate_Initialize() }

==== Anwendung der Templates ====

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D
In den gewünschten Stelle stellen (hier MQTT2_ebusd_bai) und ein Template wählen. Die eBus Templates beginnen alle mit E….

[[Bild:MQTT2_8templateselect.png|400px|thumb|left|Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein]]

<div style="clear:both;"></div>
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

<div style="clear:both;"></div>
[[Bild:MQTT2_5statustemplate.png|400px|thumb|left|Das Template hat die gewünschte Konfiguration in FHEM durchgeführt]]

[[Bild:MQTT2_6status1template.png|400px|thumb|left|Ergebnis des Template, Heizkurve und Warmwassertemperatur]]
Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

<div style="clear:both;"></div>
==== Muster Templates ====

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt.
Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater
[[Bild:MQTT2_ebusset.png|250px|thumb|left|Set hcurve und HWCtemdesired]]
<div style="clear:both;"></div>

Template: E_01_eBus_bai_readingsgroup_Status01
[[Bild:MQTT2_ebustemp.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_02_eBus_bai_readingsgroup_Status01_Balken
[[Bild:MQTT2_ebustempbalken.png|400px|thumb|left|EStatusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>
Template: E_03_eBus_bai_readingsgroup_Status02
[[Bild:MQTT2_ebuswarmwasser.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_04_eBus_bai_readingsgroup_Status02_Balken
[[Bild:MQTT2_ebuswarmwasserbalken.png|400px|thumb|left|Statusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>

== 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 angepaßt 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.

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''attrTemplate'' genutzt werden.
Die Anwendung ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.
== 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]]

MQTT2-Module - Praxisbeispiele

2019-03-10T20:09:54Z

Reinhart: Link für ebusTemplate hinzugefügt

== Einführung: MQTT bzw. MQTT2 in FHEM ==
Zur Einbindung von Geräten, welche mit einem MQTT-Server (früher: Broker) kommunizieren können, 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]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] oder 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'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt setExtensions, allerdings muß dies dort per Attribut eingeschaltet werden</ref>.
{{Hinweis|Die nachfolgenden Beispiele gelingen am einfachsten mit MQTT2_SERVER als Server, für diesen sollte dabei ''autocreate'' aktiviert werden, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines autocreate-Device (TYPE=autocreate) ebenfalls aktiv ist</ref>.}}{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muß ggf. die "\" entfernen!}}

Beispiel:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server autocreate 1

== 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 muß 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.

=== 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 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 L_01_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 Meßwert) 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, muß 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äßt, 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 ==
[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. {{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}

=== 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. Hier wurden Tasmota version(en) 6.1.1 und 6.2.1 getestet, Hardware war Sonoff Touch und S20.

=== 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/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/LWT:.* LWT\
DVES_9B01BD:cmnd/sonoffkitchen/POWER:.* POWER\
DVES_9B01BD:tele/sonoffkitchen/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/sonoff/POWER on\
off cmnd/sonoff/POWER off\
reboot cmnd/sonoff/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===
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.

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

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

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

=== 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'' X_01_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 angepaßt 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_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013: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

== eBus ==
=== eBus mit MQTT2 auswerten ===

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte MQTT2 DEVICE verwendet, damit wird als IO-Device entweder MQTT2_SERVER oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

=== Anwendung: ===
Wer eBus komfortabel in Fhem einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

[[Bild:MQTT2_MQTT2.jpg|600px|thumb|left|Uebersicht eBus MQTT]]

<div style="clear:both;"></div>
=== Welches Fhem Modul benötigt man ===
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in Fhem.}}

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der Fhem Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

=== Vorbereitung und Definition in Fhem ===
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in Fhem anlegen ###
define ebusMQTT MQTT 127.0.0.1:1883
attr ebusMQTT room MQTT2_DEVICE,System

Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Nun benötigen wir noch etwas Code für die Balkendarstellung in Fhem. Dieser Code wird in die 99_myUtils.pm kopiert.
<syntaxhighlight lang="php">
sub Balkenanzeige($)
{
# Zuweisung der übergebenen Variablen
my ($val) = @_;
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
my $maxValue = 70;
# Normalisierung auf 100%-Wert
my $percent = $val / $maxValue * 100;
# Definition des valueStyles
my $stylestring = 'style="'.
'width: 200px; '.
'text-align:center; '.
'border: 1px solid #ccc ;'.
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
# Rückgabe des definierten Strings
return $stylestring;
}
</syntaxhighlight>

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.
define colorInit notify global:INITIALIZED {use Color}

=== Konfiguration in Fhem ===

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.
Im wie oben beschriebenen angelegten Device MQTT2_ebusd wird nun folgendes Template installiert.

[[Bild:MQTT2_1template E_00 installieren.png|400px|thumb|left|Template E_00_eBus_daemon_splitter]]
<div style="clear:both;"></div>

[[Bild:MQTT2_2splitter.png|400px|thumb|left|Eingabe im Splitter aendern]]
<div style="clear:both;"></div>

Während der Installation erscheint ein Fenster, in diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und rückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

[[Bild:MQTT2_3Attribute_ebusd.png|400px|thumb|left|bridgeRegexp prüfen]]

<div style="clear:both;"></div>
(ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"

Nun setzen wir noch auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

[[Bild:MQTT2_4autocreate-complex.png|400px|thumb|left|autocreate auf complex setzen]]

<div style="clear:both;"></div>

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird.
Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

define EBUS.TIMER at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der Fhem Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

=== Installation der Templates ===

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „{{Link2Forum|Topic=79600|LinkText=mqtt2.ebus.template}}“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren.
Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

[[Bild:MQTT2_7templateinitialize.png|400px|thumb|left|vor der ersten Benutzung in der Eingabezeile eingeben]]

<div style="clear:both;"></div>
Dazu in der FHEM Eingabezeile eingeben:
{ AttrTemplate_Initialize() }

=== Anwendung der Templates ===

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D
In den gewünschten Stelle stellen (hier MQTT2_ebusd_bai) und ein Template wählen. Die eBus Templates beginnen alle mit E….

[[Bild:MQTT2_8templateselect.png|400px|thumb|left|Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein]]

<div style="clear:both;"></div>
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

<div style="clear:both;"></div>
[[Bild:MQTT2_5statustemplate.png|400px|thumb|left|Das Template hat die gewünschte Konfiguration in Fhem durchgeführt]]

[[Bild:MQTT2_6status1template.png|400px|thumb|left|Ergebnis des Template, Heizkurve und Warmwassertemperatur]]
Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

<div style="clear:both;"></div>
=== Muster Templates ===

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt.
Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater
[[Bild:MQTT2_ebusset.png|250px|thumb|left|Set hcurve und HWCtemdesired]]
<div style="clear:both;"></div>

Template: E_01_eBus_bai_readingsgroup_Status01
[[Bild:MQTT2_ebustemp.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_02_eBus_bai_readingsgroup_Status01_Balken
[[Bild:MQTT2_ebustempbalken.png|400px|thumb|left|EStatusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>
Template: E_03_eBus_bai_readingsgroup_Status02
[[Bild:MQTT2_ebuswarmwasser.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_04_eBus_bai_readingsgroup_Status02_Balken
[[Bild:MQTT2_ebuswarmwasserbalken.png|400px|thumb|left|Statusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>

== 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 angepaßt 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.

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''attrTemplate'' genutzt werden.
Die Anwendung ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.
== 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]]

MQTT2-Module - Praxisbeispiele

2019-03-10T14:00:25Z

Reinhart: eBus Installation, Konfiguration der Praxisbeispiele hinzugefügt

== Einführung: MQTT bzw. MQTT2 in FHEM ==
Zur Einbindung von Geräten, welche mit einem MQTT-Server (früher: Broker) kommunizieren können, 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]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] oder 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'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt setExtensions, allerdings muß dies dort per Attribut eingeschaltet werden</ref>.
{{Hinweis|Die nachfolgenden Beispiele gelingen am einfachsten mit MQTT2_SERVER als Server, für diesen sollte dabei ''autocreate'' aktiviert werden, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines autocreate-Device (TYPE=autocreate) ebenfalls aktiv ist</ref>.}}{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muß ggf. die "\" entfernen!}}

Beispiel:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server autocreate 1

== 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 muß 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.

=== 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 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 L_01_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 Meßwert) 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, muß 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äßt, 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 ==
[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. {{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}

=== 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. Hier wurden Tasmota version(en) 6.1.1 und 6.2.1 getestet, Hardware war Sonoff Touch und S20.

=== 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/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/LWT:.* LWT\
DVES_9B01BD:cmnd/sonoffkitchen/POWER:.* POWER\
DVES_9B01BD:tele/sonoffkitchen/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/sonoffkitchen/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/sonoff/POWER on\
off cmnd/sonoff/POWER off\
reboot cmnd/sonoff/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===
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.

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

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

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

=== 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'' X_01_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 angepaßt 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_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013: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

== eBus ==
=== eBus mit MQTT2 auswerten ===

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte MQTT2 DEVICE verwendet, damit wird als IO-Device entweder MQTT2_SERVER oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

=== Anwendung: ===
Wer eBus komfortabel in Fhem einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

[[Bild:MQTT2_MQTT2.jpg|600px|thumb|left|Uebersicht eBus MQTT]]

<div style="clear:both;"></div>
=== Welches Fhem Modul benötigt man ===
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in Fhem.}}

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der Fhem Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

=== Vorbereitung und Definition in Fhem ===
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in Fhem anlegen ###
define ebusMQTT MQTT 127.0.0.1:1883
attr ebusMQTT room MQTT2_DEVICE,System

Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Nun benötigen wir noch etwas Code für die Balkendarstellung in Fhem. Dieser Code wird in die 99_myUtils.pm kopiert.
<syntaxhighlight lang="php">
sub Balkenanzeige($)
{
# Zuweisung der übergebenen Variablen
my ($val) = @_;
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
my $maxValue = 70;
# Normalisierung auf 100%-Wert
my $percent = $val / $maxValue * 100;
# Definition des valueStyles
my $stylestring = 'style="'.
'width: 200px; '.
'text-align:center; '.
'border: 1px solid #ccc ;'.
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
# Rückgabe des definierten Strings
return $stylestring;
}
</syntaxhighlight>

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.
define colorInit notify global:INITIALIZED {use Color}

=== Konfiguration in Fhem ===

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.
Im wie oben beschriebenen angelegten Device MQTT2_ebusd wird nun folgendes Template installiert.

[[Bild:MQTT2_1template E_00 installieren.png|400px|thumb|left|Template E_00_eBus_daemon_splitter]]
<div style="clear:both;"></div>

[[Bild:MQTT2_2splitter.png|400px|thumb|left|Eingabe im Splitter aendern]]
<div style="clear:both;"></div>

Während der Installation erscheint ein Fenster, in diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und rückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

[[Bild:MQTT2_3Attribute_ebusd.png|400px|thumb|left|bridgeRegexp prüfen]]

<div style="clear:both;"></div>
(ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"

Nun setzen wir noch auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

[[Bild:MQTT2_4autocreate-complex.png|400px|thumb|left|autocreate auf complex setzen]]

<div style="clear:both;"></div>

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird.
Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

define EBUS.TIMER at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der Fhem Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

=== Installation der Templates ===

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „mqtt2.ebus.template“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren.
Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

[[Bild:MQTT2_7templateinitialize.png|400px|thumb|left|vor der ersten Benutzung in der Eingabezeile eingeben]]

<div style="clear:both;"></div>
Dazu in der FHEM Eingabezeile eingeben:
{ AttrTemplate_Initialize() }

=== Anwendung der Templates ===

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D
In den gewünschten Stelle stellen (hier MQTT2_ebusd_bai) und ein Template wählen. Die eBus Templates beginnen alle mit E….

[[Bild:MQTT2_8templateselect.png|400px|thumb|left|Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein]]

<div style="clear:both;"></div>
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

<div style="clear:both;"></div>
[[Bild:MQTT2_5statustemplate.png|400px|thumb|left|Das Template hat die gewünschte Konfiguration in Fhem durchgeführt]]

[[Bild:MQTT2_6status1template.png|400px|thumb|left|Ergebnis des Template, Heizkurve und Warmwassertemperatur]]
Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

<div style="clear:both;"></div>
=== Muster Templates ===

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt.
Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater
[[Bild:MQTT2_ebusset.png|250px|thumb|left|Set hcurve und HWCtemdesired]]
<div style="clear:both;"></div>

Template: E_01_eBus_bai_readingsgroup_Status01
[[Bild:MQTT2_ebustemp.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_02_eBus_bai_readingsgroup_Status01_Balken
[[Bild:MQTT2_ebustempbalken.png|400px|thumb|left|EStatusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>
Template: E_03_eBus_bai_readingsgroup_Status02
[[Bild:MQTT2_ebuswarmwasser.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_04_eBus_bai_readingsgroup_Status02_Balken
[[Bild:MQTT2_ebuswarmwasserbalken.png|400px|thumb|left|Statusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>

== 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 angepaßt 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.

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''attrTemplate'' genutzt werden.
Die Anwendung ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.
== 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]]

Datei:MQTT2 MQTT2.jpg

2019-03-10T12:53:21Z