MQTT2-Module - Praxisbeispiele: Unterschied zwischen den Versionen

Aus FHEMWiki
(Typo korrigiert)
 
(150 dazwischenliegende Versionen von 17 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== Einführung: MQTT2 vs. MQTT ==
== 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 zwei Optionen zur Verfügung: Man kann entweder einen dedizierten Server (wie z.B. mosquitto) nutzen, der dann über das Modul [[MQTT]] eingebunden wird und zu dem die Module [[MQTT_DEVICE]] und {{Link2CmdRef|Anker=MQTT_BRIDGE|Lang=en|Label=MQTT_BRIDGE}} gehören (bzw. noch MQTT_GENERIC_BRIDGE), oder man kann mit Hilfe des Moduls {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} FHEM selbst zum MQTT-Server machen.
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT verwenden, beachten Sie bitte, dass der MQTT2_CLIENT die ursprüngliche Herkunft der über MQTT verteilten Informationen nicht kennt. Daher ergeben sich in der Anwendung kleinere Unterschiede, zu deren Verständnis die diesbezüglichen [[MQTT2_CLIENT#Anwendung|Hinweise zu MQTT2_CLIENT]] bekannt sein sollten.}}Zur Einbindung von Geräten, welche zur Nutzung des MQTT-Protokols konfiguriert werden können und darüber mit einem MQTT-Server (früher: Broker) kommunizieren, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser [[MQTT|Übersicht]] zu entnehmen.  
{{Hinweis|Man kann auch beide Ansätze gleichzeitig nutzen, sollte dann aber darauf achten, dass man an dem MQTT-Device eine ''client-ID'' vergibt.}}


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


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


== zigbee2mqtt ==
Beispiel<ref>MQTT2_SERVER verwendet als default-Einstellung für ''autocreate'' ''simple'', ohne dass ein entsprechendes Attribut gesetzt werden müsste. Die Einstellung ''complex'' empfiehlt sich in der Regel nicht; diese ist jedoch dann zu empfehlen, wenn das Device entweder verschachtelte JSON-Array-Strukturen liefert oder bestimmte Readings nicht gefüllt werden sollen.</ref>:
[[Bild:MQTT2_zigbee2mqtt_Bulbs.png|400px|thumb|Darstellung in FHEMWEB]]
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
[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 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.  


=== Define eines MQTT2-Devices als "Bridge" ===
Falls der MQTT Broker mit Hilfe von [[allowed]] abgesichert wurde, muss in den Geräten ebenfalls User bzw. Passwort eingetragen werden, damit eine MQTT Kommunikation möglich ist.
Dann kann eine Art "Grund-Device" angelegt werden, über das die gesamte Kommunikation zu allen angeschlossenen Zigbee-Geräten dann läuft. In der Regel sollte dieses automatisch erstellt werden, wenn der zigbee2mqtt-Dienst (oder der betreffende Rechner) neu gestartet wird:
defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_pi setList permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1
remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1
log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1
rename:textField zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}
network_map:raw,graphviz zigbee2mqtt/bridge/networkmap  $EVTPART1
devicelist:noArg zigbee2mqtt/bridge/config/devices


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 dann nach Bedienungsanleitung in den Anlernmodus gebracht werden.
{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muss ggf. die "\" entfernen!}}


Nach einem Browser-refresh sollte das neue Device zusätzliche Readings in MQTT2_zigbee_pi erzeugt haben.
=== MQTT-Einstellungen in den Geräten ===
Wer möchte, kann die Devices dann umbenennen; da diese in FHEM aber nachfolgend sowieso eigene Namen erhalten, kann dieses auch unterbleiben.
Die Beispiele gehen davon aus, dass die einzubindenden Geräte '''''mit den default-Einstellungen''''' für MQTT betrieben werden, wenn man von den Angaben zum Server und ggf. der Gerätekennung absieht. Es sollten also insbesondere '''keine Veränderungen der topic-Pfade''' vorgenommen werden.


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


Anschließend kann man - am einfachsten über die Anpassung der RAW-Definition des "Bridge"-Devices - neue MQTT2_DEVICE-Geräte ableiten (also manuell anlegen), die dann jeweils nur den Teil der readingList abbilden, der zu einem einzelnen pysischen Gerät gehört.  
=== auto-Konfigurations-features ===
Viele firmwares und Dienste bieten Möglichkeiten an, einer Controller-Software (insbesondere homeassistant) Hilfsdaten zur automatisierten Konfiguration bereitzustellen. Da FHEM diese Daten nicht zu ihrem ursprünglichen Zweck verwenden kann, werden hierdurch lediglich zusätzliche Readings erzeugt, mit denen man als User in der Regel wenig anfangen kann. Es wird daher empfohlen, derartige features '''abzuschalten'''. Wo dies nicht möglich ist, sollte man eine passende [[MQTT2_CLIENT#ignoreRegexp|ignoreRegexp]] setzen bzw. diese passend erweitern!


Beispiele:
=== Schritt für Schritt ===
==== IKEA-Tradfri-Birne ====
Hier werden in der Regel fertige Konfigurationen für häufige Anwendungsfälle (beispielhaft) dargestellt. In [[MQTT2_DEVICE - Schritt für Schritt]] ist etwas mehr über die Vorgehensweise bei der Zusammenstellung der verschiedenen Attribute und deren Zusammenwirken zu erfahren.
Beispiel eines dimmbaren Tradfri-Leuchtmittels
defmod IKEA_Bulb2 MQTT2_DEVICE
attr IKEA_Bulb2 IODev MQTT2_FHEM_Server
attr IKEA_Bulb2 eventMap on:ON:off off:OFF:on
attr IKEA_Bulb2 icon light_control
attr IKEA_Bulb2 readingList zigbee_pi:zigbee2mqtt/Kueche_Durchgang_A2:.* { json2nameValue($EVENT) }
attr IKEA_Bulb2 setList on zigbee2mqtt/Kueche_Durchgang_A2/set {"state":"ON"}\
off zigbee2mqtt/Kueche_Durchgang_A2/set {"state":"OFF"}\
brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/Kueche_Durchgang_A2/set {"state":"on","$EVTPART0":"$EVTPART1"}


attr IKEA_Bulb2 webCmd brightness
== zigbee2mqtt ==
 
[[Bild:MQTT2_zigbee2mqtt_Bulbs.png|400px|thumb|Darstellung in FHEMWEB]]
Kann man auch die Farbtemperatur einstellen, wird die setList wie folgt erweitert:
[https://www.zigbee2mqtt.io 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.
...
color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/ikea_flur_oben/set {"$EVTPART0":"$EVTPART1"}
webCmd muß dann ebenfalls noch ergänzt werden.


Für ein dynamisches Icon, das die Helligkeit wiedergibt, kann man folgenden Code in [[99 myUtils anlegen|myUtils]] verwenden und mit <code>attr IKEA_Bulb2 devStateIcon {devStateIcon255($name)}</code> einbinden:
Einzelheiten zur Vorgehensweise sind auf der Detailseite [[Zigbee2mqtt|zigbee2mqtt]] zu finden.
 
##############################################
# $Id: myUtils_Color.pm 08-15 2018-10-08 18:31:44Z Beta-User $
#
package main;
use strict;
use warnings;
use POSIX;
sub
myUtils_Color_Initialize($$)
{
  my ($hash) = @_;
}
# Enter you functions below _this_ line.
sub devStateIcon255($) {
my $name = shift(@_);
return ".*:off:toggle" if( ReadingsVal($name,"state","ON") eq "OFF" );
my %dim_values = (
  0 => "dim06%",
  1 => "dim12%",
  2 => "dim18%",
  3 => "dim25%",
  4 => "dim31%",
  5 => "dim37%",
  6 => "dim43%",
  7 => "dim50%",
  8 => "dim56%",
  9 => "dim62%",
  10 => "dim68%",
  11 => "dim75%",
  12 => "dim81%",
  13 => "dim87%",
  14 => "dim93%",
);
my $pct = ReadingsVal($name,"brightness","255");
my $s = $dim_values{int($pct/18)};
$s="on" if( $pct > 253 );
return ".*:$s:off";
}
1;
 
==== Temp/Hum. Sensor ====
tbd


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


=== Anpassungen ===
=== Manuelle Anpassungen - Schalter ===
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:   
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:   
<syntaxhighlight lang="perl">
  defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
  defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
  attr MQTT2_DVES_9B01BD IODev m2server
  attr MQTT2_DVES_9B01BD IODev m2server
  attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
attr MQTT2_DVES_9B01BD devStateIcon on:FS20.on:off off:FS20.off:on
DVES_9B01BD:tele/sonoffkitchen/LWT:.* LWT\
  attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:cmnd/sonoffkitchen/POWER:.* POWER\
    DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
DVES_9B01BD:tele/sonoffkitchen/UPTIME:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/RESULT:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/sonoffkitchen/POWER:.* POWER
    DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
    DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
  attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
  attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
  attr MQTT2_DVES_9B01BD setList on cmnd/sonoff/POWER on\
  attr MQTT2_DVES_9B01BD setList on cmnd/DVES_9B01BD/POWER on\
off cmnd/sonoff/POWER off\
    off cmnd/DVES_9B01BD/POWER off\
reboot cmnd/sonoff/Restart 1
    reboot cmnd/DVES_9B01BD/Restart 1
  attr MQTT2_DVES_9B01BD webCmd on:off:reboot
  attr MQTT2_DVES_9B01BD webCmd on:off:reboot
</syntaxhighlight>
=== Manuelle Anpassungen - Dimmer ===
{{Randnotiz|RNTyp=r|RNText=Dieses Beispiel ist nur bedingt zur Nachahmung zu empfehlen: Prinzipiell kann man Readings und setter in MQTT2_DEVICE fast nach Belieben benennen. Wählt man allerdings <i>FHEM-typische</i> Namen, kann dies sehr zur Vereinfachung beitragen. Z.B. wird eine Sprachssteuerung bei einem Dimmer üblicherweise automatisch korrekt eingestellt werden, wenn der für die Helligkeit zuständige setter z.B. <i>pct</i> (oder <i>brightness</i>) heißt, oder eine abzufragende Temperatur <i>temperature</i>. Entsprechendes gilt im Rahmen von <i>devspec-Abfragen</i>.}}Bei einem Dimmer sind einige zusätzliche Anpassungen vorzunehmen. Ein Dimmer wird über '''POWER''' geschaltet und über '''Dimmer''' gedimmt. Damit das funktioniert, müssen ein stateFormat und devStateIcon zusammenarbeiten:
<syntaxhighlight lang="perl">
attr MQTT2_DVES_2DF34D devStateIcon 10\d.*:dim100%@orange:off 1\d.*:dim12%@orange:off 2\d.*:dim18%@orange:off 3\d.*:dim31%@orange:off 4\d.*:dim43%@orange:off 5\d.*:dim50%@orange:off 6\d.*:dim62%@orange:off 7\d.*:dim68%@orange:off 8\d.*:dim81%@orange:off 9\d.*:dim93%@orange:off 0:FS20.off:on .*:FS20.off@orange:off
attr MQTT2_DVES_2DF34D stateFormat {if(ReadingsVal($name,"POWER",0)eq"off"){0}else{ReadingsVal($name,"Dimmer",0)}}
</syntaxhighlight>
Nun kann man über das Icon ein- und ausschalten und der Zustand des Dimmers wird korrekt angezeigt.
Es fehlt noch ein Slider, um auch dimmen zu können. Zusätzlich muss setList noch um Dimmer erweitert werden:
<syntaxhighlight lang="text">
attr MQTT2_DVES_2DF34D setList on cmnd/dimmer/POWER on\
off cmnd/dimmer/POWER off\
Dimmer cmnd/dimmer/Dimmer
attr MQTT2_DVES_2DF34D webCmd Dimmer
attr MQTT2_DVES_2DF34D widgetOverride Dimmer:slider,0,1,100
</syntaxhighlight>
=== attrTemplate ===
===== Allgemeines =====
Für gängige Tasmota-Geräte stehen ''templates'' bereit, mit denen sich diese schnell konfigurieren lassen.
Beachten Sie dazu den Abschnitt ''attrTemplate'' in [[MQTT2 DEVICE#attrTemplate|MQTT2_DEVICE]]. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.{{Hinweis|Bitte attrTemplates nicht verwechseln mit templates, die auf den Tasmota- bzw. Blackadder-Seiten angeboten werden, welche zur Konfiguration der firmware genutzt werden können! Es sollte zunächst die firmware korrekt eingerichtet werden, so dass das Gerät selbst direkt auf dessen Web-Interface korrekt bedient werden kann.}}
===== Kein passendes attrTemplate vorhanden? =====
Exisitert (noch) kein passendes attrTemplate, ist zu empfehlen, zunächst das "''tasmota_basic''" anzuwenden. Dieses führt einige Basiskonfigurationen durch, die für FHEM hilfreich sind, z.B. wird die firmware so eingestellt, dass Schaltzustände in Kleinschreibung übermittelt werden, statt der defaults "ON" bzw. "OFF".
Allerdings stellt dieses das ''autocreate'' an dem MQTT2_DEVICE auf 0, was dann nicht optimal ist, wenn man weitere Readings aus dem Gerät erwartet, etwa, weil zusätzliche Sensoren vorhanden sind. In diesem Fall empfiehlt es sich, das ''autocreate''-Attribut an dem MQTT2_DEVICE zu löschen, damit alle weiteren Informationen verarbeitet werden und ggf. im ''jsonMap''-Attribut nur die Angabe "''POWER1:state''" zu belassen.
=== on-for-timer ===
Um z.B. ein Relais nur für einen Zeitraum anzuschalten, kann man bei Tasmota-Geräten zwischen mehrere Varianten wählen. Ohne speziellen ''setter'' in der ''setList'' werden die '''SetExtensions''' verwendet. Timer laufen damit innerhalb FHEM. Da diese intern als temporäres [[at]] ausgeführt werden, sind diese auch noch nach einem FHEM-Neustart vorhanden, sofern FHEM ordnungsgemäß beendet und neu gestartet wird.
Die Tasmota-firmware bietet ergänzend dazu zwei Möglichkeiten an, bei denen der Timer direkt auf dem ESP-Microcontroller verwaltet wird:
==== delay ====
Zeile zur Erweiterung der ''setList'' (Attributeingabe via FHEMWEB!):
on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}
Ohne Auswirkungen auf alles, was danach kommt, hat aber den Nachteil, dass die möglichen Zeitspannen auf 3600 1/10 Sekunden begrenzt sind (siehe [https://tasmota.github.io/docs/Commands/#delay Commands - Tasmota Delay]), also 6 Minuten.
====pulseTime ====
Zeile zur Erweiterung der ''setList'' (s.o.):
on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}
Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit ''delay''. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites ''save'' nur bis zum nächsten reboot des Microcontrollers.
Da nach dem ersten pulseTime setzten, diese immer benutzt wird, kann man mit einem kleine Workaround das Device normal arbeiten lassen. Dafür wird bei jedem anderem Befehl, aus der PulseTime, der Timer deaktiviert.
Hierfür machen wir uns zu nutzen, dass man mehrere Befehle gleichzeitig an Tasmota senden kann (backlog). Ob diese Lösung auch mit anderen MQTT Firmwares funktioniert, kann ich nicht sagen. Es wurde lediglich mit Tasmota getestet.
Wir senden also, bevor wir den eigentlich Tasmota Befehl zum Ein- oder Ausschalten schicken, einen Befehl zum deaktivieren des Timers: "pulseTime 0"
Hier ein Beispiel: (das entsprechende device "DEV_611F3E" muss gegen das eigene ersetzt werden)
off:noArg    cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 0
on:noArg    cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 1
toggle:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 2
=== zigbee2tasmota ===
[https://tasmota.github.io/docs/Zigbee/ zigbee2tasmota] ist eine Erweiterung der Tasmota-firmware für Microcontroller, insbesondere dem ESP8266 (und ESP32)(link), über die einige ZigBee-Chipsätze (insbesondere TI CC2530) als [[ZigBee#Koordinator_.28ZigBee_coordinator.2C_ZC.29|Coordinator]] eingebunden werden können, um ein ZigBee-Netzwerk aufzubauen.
{{Hinweis|Stand 08/2020 war die Einbindung anderer Chipsätze erst in einem Alpha-Stadium; die Zahl der über einen CC2530 einbindbaren ZigBee-Geräte ist daher derzeit relativ begrenzt (ca. 16)!}}
Auch für diese Lösung stehen einige ''attrTemplate'' zur Verfügung. Nähere Informationen hierzu sind dem Artikel [[Zigbee2Tasmota-MQTT]] zu entnehmen.
== ESPurna ==
ESPurna ist eine weitere alternative firmware für ESP8266-basierte Geräte, Details sind der [https://github.com/xoseperez/espurna/wiki Projektseite] zu entnehmen.
Das Format, in dem ESPurna Daten sendet, unterscheidet sich v.a. darin, dass bool'sche Werte als 0 oder 1 gesendet werden, und nicht wie sonst üblich als "on" oder "off" oä.. Es stehen einige Mustertemplates zur Verfügung, um diese Art der Payload in FHEM-konforme Werte zu überführen.
== Shelly ==
=== Vorbemerkung ===
Auch für Shelly-Geräte steht eine Auswahl an [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|templates]] bereit.
Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.
Standardmäßig senden die Shelly-Geräte ihren kompletten Status alle 30 Sekunden. Dies kann man über den Parameter ''mqtt_update_period'' in den ''settings'' ändern, allerdings ist dieser nur über die HTTP-Schnittstelle des Shelly verfügbar. Um diese Statusupdates abzustellen, kann über den Browser folgender Befehl verwendet werden:
http://<ip-des-shelly>/settings?mqtt_update_period=0,
Soweit bekannt, werden dann nur statische updates ausgeschaltet, z.B. für das Relay bzw. angeschlossene Taster oder Schalter; insbesondere Verbrauchswerte werden dennoch aktualisiert.
=== Shelly1 ===
=== Shellybulb ===
Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate  angelegt wird. Dies sieht zunächst so aus:
Internals:
  CFGFN   
  CID        shellybulb_3CC533
  DEF        shellybulb_3CC533
  DEVICETOPIC MQTT2_shellybulb_3CC533
  IODev      MQTT2_FHEM_Server
  NAME      MQTT2_shellybulb_3CC533
  NR        246
  STATE      ???
  TYPE      MQTT2_DEVICE
  READINGS:
    2018-12-12 19:28:08  status_blue    0
    2018-12-12 19:28:08  status_brightness 61
    2018-12-12 19:28:08  status_effect  0
    2018-12-12 19:28:08  status_gain    26
    2018-12-12 19:28:08  status_green    0
    2018-12-12 19:28:08  status_ison    true
    2018-12-12 19:28:08  status_mode    color
    2018-12-12 19:28:08  status_red      255
    2018-12-12 19:28:08  status_temp    3250
    2018-12-12 19:28:08  status_white    0
Attributes:
  IODev      MQTT2_FHEM_Server
  readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
  room      MQTT2_DEVICE
[[Bild:MQTT2 Shellybulb.png|400px|thumb|Darstellung in FHEMWEB nach Anwendung des template]]Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.
=== Shelly Plug S ===
Über die Leistungsmessung des Shelly Plug S lässt sich sehr einfach auch eine Erkennung des Betriebszustandes des angeschlossenen Gerätes realisieren. Dazu stellt man zuerst fest, wieviel Leistung das Gerät in jedem Betriebszustand verbraucht und kann dann z.B. für einen angeschlossenen Fernseher, der im Standby 1 Watt und im Betrieb > 100 Watt verbraucht, den Zustand erkennen und als on/off Status anzeigen. Dazu wird das state Reading wie folgt definiert:
  attr readingList shellies/shellyplug-s-123456/relay/0/power:.* { { state => $EVTPART0<100?"off":"on" } }
Der Status des MQTT2 Devices zeigt dann bei <100W "off" und sonst "on" an.
=== HTTP-Commands ===
In diesem {{Link2Forum|Topic=102369|LinkText=Forumsbeitrag}} wird eine Lösung vorgestellt, um über [[99 myUtils anlegen|myUtils-Code]] weitere Kommandos bereitzustellen, die sonst nur direkt über das Web-Interface zu erreichen sind.
== Shelly Gen2 ==
=== Vorbereitung ===
Shelly mit dem WLAN verbinden, entweder über die Shelly APP oder per Laptop auf den Offenen AP des Shelly verbinden und dann übers WebUI des Shelly mit dem Heimischen WLAN verbinden. Über die APP geht dies meist etwas einfach und schneller, besonders wenn man mehrere Shelly Geräte hinzufügen möchte. Durch die BT Unterstützung der Gen2 Geräte, klappt dies meist auch deutlich schneller und zuverlässiger als noch bei Gen 1 Geräten.
Nachdem der Shelly mit dem WLAN verbunden ist, sollte die Firmware überprüft und gegebenenfalls aktualisiert werden (Stand Anfang 2022 scheint die firmware noch nicht voll ausgereift gewesen zu sein, da dass insbesondere die MQTT-Schnittstelle immer wieder überarbeitet wurde). Bitte KEINE BETA Versionen installieren, wenn nicht dazu aufgefordert wurde.
Nach dem, durch das Update ausgelösten, Neustart kurz Prüfen ob die Uhrzeit passt, wenn trotz richtiger Zeitzone die Uhrzeit nicht stimmt hilft ein weiterer Neustart.
Nun auf Networks| Internet (leider in APP und WebUI unterschiedlich), hier auf MQTT und die Einstellungen für den verwendeten MQTT Server treffen. Diese Einstellungen werden auch wieder durch Neustart übernommen.
=== Shelly Plus 1 ===
Zunächst muss man einen Statusupdate des Shelly erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
<syntaxhighlight lang="text">
defmod MQTT2_shellyplus1_441793a34044 MQTT2_DEVICE shellyplus1_441793a34044
attr MQTT2_shellyplus1_441793a34044 readingList shellyplus1_441793a34044:shellyplus1-441793a34044/online:.* online\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/mqtt:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/events/rpc:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/sys:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/switch_0:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1_441793a34044 room MQTT2_DEVICE
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 IODev m2s
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 cfg_rev 7
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 connected true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 dst shellyplus1-441793a34044/events
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 fs_free 237568
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 fs_size 458752
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 id 0
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 mac 441793A34044
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 method NotifyStatus
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 online true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 output false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_output false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_source WS_in
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_switch_0_temperature_tC 39.88
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_switch_0_temperature_tF 103.78
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_ts 1646474952.66
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_rssi -57
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_sta_ip 192.168.177.167
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 ram_free 179764
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 ram_size 249456
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 restart_required false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 source WS_in
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 src shellyplus1-441793a34044
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 temperature_tC 39.9
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 temperature_tF 103.9
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 time 11:08
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 unixtime 1646474911
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 uptime 7
</syntaxhighlight>
Über die set Anweisung unterhalb der Device Übersicht können wir ein attrTemplate wählen; shellyPlus_1
Es erscheint eine kurze Übersicht was im Template enthalten ist, dieses befindet sich noch im Aufbau und wird aktuell von der Community aufgebaut und weiterentwickelt. Mit einem Klick auf „set“ laden wir das Template und übernehmen die Einstellungen für den Shelly Plus 1.
Damit ist der Shelly bereit, im Status wird neben dem Namen auch der Onlinestatus des Shellys (grüner | roter Punkt) so wie eine Lampe mit Toggle (on | off) Funktion und die Temperatur des Shellys angezeigt. Darüber hinaus verschwindet die Lampe und wird durch einen klickbaren Hinweis ersetzt, wenn ein Neustart des Shellys nötig ist.
=== Tipps ===
{{Randnotiz|RNTyp=g|RNText=So nimmt man bei Verwendung eines normalen Schalters (eine Stellung EIN eine AUS) gerne den „Flip“ Mode – damit wird der Shelly IMMER umgeschaltet, egal in welche Stellung der Schalter sich bewegt („Kreuzschaltung“). Diese Einstellungen trifft man grundlegend im WebUI des Shelly (oder  APP) unter „Channel settings“.
Für den „Flip“ müssen wir die Grundeinstellung des „Power on default“ auch ändern (gleiche Seite) - persönlich wähle ich „Restore last“, also: nach Stromausfall wird der letzte Zustand wieder hergestellt; grundsätzlich gehen alle Modi außer „Match input“.
}}
Das aktuelle Template wurde um die Funktion erweitert, den Button Mode umzuschalten. In den meisten Fällen legt man sich auf eine Schaltmethode fest, welche zum Hardware Setup passt.
Manchmal will man aber vielleicht den Hardware Schalter deaktivieren, nennen wir es „Kindersicherung“. Bei Shelly heißt das „detached“.
Diese Funktion wurde ins Template als „in_mode“ Übernommen. Mögliche set Befehle sind „flip“, „detached“ „toggle“. Bedingung zur Verwendung ist: „relay power on default“ darf NICHT „Match input“ sein. Sollte Follow statt Flip bevorzugt werden, müsste entsprechende Zeile in der setList von „flip“ auf „follow“ angepasst werden.
Der Befehlt lässt sich mit dem webCmd in_mode auch schnell zugänglich in die Übersicht vom Shelly setzen, so erhält man neben dem Status ein Dropdown mit flip detached  und toggle zum schnellen umschalten. Mit webCmdLabel kann man noch einen Namen für das Dropdown setzen.
== OpenMQTTGateway ==
Um verschiedene Systeme wie BLE usw. auf MQTT zu bringen bietet sich [https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] an, z.B. wird für das Auslesen vieler BLE-Seonsoren lediglich ein ESP32-Board ohne Zusatzhardware (ab ca. 5,- Euro in Fernost erhältlich) benötigt, auf das dann eine vorkompilierte firmware geflasht wird (hierfür wird ein USB-seriell-Wandler benötigt).
Nähere Details sind im Artikel [[OpenMQTTGateway]] zu finden.
== 8-Port-Ethernet Board ==
<gallery>
datei:8-relais-ethernetboard closed.jpg|mit Gehäuse
datei:8-Port-MQTT-Relais-Board.jpg|ohne Gehäuse
</gallery>
In diesem {{Link2Forum|Topic=107536|Message=1016379|LinkText=Forenbeitrag}} bzw. dem betreffenden Thread wurde ein Relais-Board vorgestellt, mit dem 8 Relais über Ethernetkabel verbunden werden, die Kommunikation erfolgt dann über MQTT. Über die verwendete Software ist wenig bekannt, es könnte jedoch sein, dass diese Art der Einbindung auch bei weiteren Boards funktioniert, die einen bestimmten Ethernet-Chipset von TI (DP83848) und eine Cortex M3 MCU verwenden.


== Milight-Bridge ==
== Milight-Bridge ==
[[Bild:MQTT2 MiLight.png|400px|thumb|Darstellung in FHEMWEB]]
=== Vorbemerkung ===
=== 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.
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. Allerdings lassen sich manche MiLight-Geräte nicht an die Bridge anlernen, und es werden auch nicht alle Fernbedienungs-Typen voll unterstützt.
Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspriche dabei im Wesentlichen einem MySensors-Wifi-Gateway, es wird lediglich ein anderer CS-PIN genutzt, was allerdings in der Web-Oberfläche auch so umgestellt werden kann.
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.
Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist und die zu steuernden Leuchtmittel mit dem Hub bereits verbunden (gepairt) sind bzw. entsprechende Fernbedienungs-Signale empfangen werden können (bei vorhandenem pairing eines Leuchtmittels an die Fernbedienung).
Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit diesen ausgelöst werden.
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 ===
=== Einstellungen am MiLight-Hub ===
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Einstellungen sind im Web-Interface des Hub einzustellen. Um auch %-Werte für die Helligkeit zu erhalten, sollten diese ebenfalls als zu sendendes Element ausgewählt werden.
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an.
Die Einstellungen für ''MQTT topic pattern'' usw. können auf den default-Werten<ref>Diese sind: <br>''milight/:device_id/:device_type/:group_id'' für "topic pattern"<br>''milight/updates/:hex_device_id/:device_type/:group_id'' für "update topic pattern"<br>''milight/states/:hex_device_id/:device_type/:group_id'' für "state topic pattern". Der Autor hat derzeit folgende Infotypen zum Senden markiert: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (enthält eventuell zu viele Angaben. Bei einem Eventhandler muss man uU. darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).</ref> belassen werden, für die seit Mitte 2019 vorhandene Option, eine LWT-Message zu senden (''MQTT Client Status Topic''), tragen Sie ''milight/LWT'' ein und aktivieren ''Detailed''.


=== FHEM-Devices ===
=== FHEM-Devices ===
[[Bild:MQTT2 MiLight.png|400px|thumb|Milight: Darstellung in FHEMWEB]]
==== Bridge ====
==== Bridge ====
Danach wird ein zentrales "Bridge-Device" definiert, über das später alle Informationen aller MiLight-Kanäle laufen bzw. zurückgemeldet werden.
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:
  define Milight_Bridge MQTT2_DEVICE milight_hub_1370325
  defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325
  attr Milight_Bridge IODev MQTT2_FHEM_Server
  attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server
  attr Milight_Bridge readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/0:.* { json2nameValue($EVENT) }\
  attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
  milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT) }\
  attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE
...
 
milight_hub_1370325:milight/states/0x..../rgb_cct/1:.* { json2nameValue($EVENT) }
Auf dieses Device wird nun das ''template'' '''esp_milight_hub_bridge''' angewandt.


==== Einzelne Leuchtmittel ====
==== Einzelne Leuchtmittel ====
Um dann einzelne Geräte für jedes Leuchtmittel bzw. jede zu schaltende Gruppe zu erhalten, kopiert man dann (am besten über die RAW-Definition) die relevanten Teile aus dem Bridge-Device. Beispiel:
define Licht_Essen MQTT2_DEVICE
attr Licht_Essen IODev MQTT2_FHEM_Server
attr Licht_Essen eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/
attr Licht_Essen icon light_control
attr Licht_Essen readingList milight_hub_1370325:milight/states/0xBE59/rgbw/0:.* { json2nameValue($EVENT) }\
milight_hub_1370325:milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT) }
attr Licht_Essen room Esszimmer
attr Licht_Essen setList on milight/0xBE59/rgbw/1 {"status":"ON"}\
off milight/0xBE59/rgbw/1 {"status":"OFF"}\
level:colorpicker,BRI,0,1,100 milight/0xBE59/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0xBE59/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
command milight/0xBE59/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
brightness milight/0xBE59/rgbw/1 {"$EVTPART0":"$EVTPART1"}\


  attr Licht_Essen webCmd level:hue:command
Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:
  attr Licht_Essen widgetOverride state command:uzsuSelectRadio,Weiss,Nacht  
defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1
attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE
 
Auf dieses wird nun eines der Bulb-templates angewendet. Wählt man das template X_01_esp_milight_hub_rgbw_bulb, wird eine einfache Variante erstellt, die neben einem toggelnden Icon nur Regler für Helligkeit, die Farbe und zwei Schaltflächen für den Weiß- und Nachtmodus enthält. Wer mehr oder andere Steuerelemente erhalten möchte, verwendet ein anderes template. Nicht benötigte Elemente kann man dabei einfach aus der Definition löschen.
 
Alle weiteren Devices werden genauso erstellt.
 
Um ein Device zu erhalten, mit dem sich alle Kanäle gleichzeitig steuern lassen, kann das template ''X_01a_esp_milight_hub_make_rgbw_group'' verwendet werden. Dieses verändert nicht das aktuelle Device, sondern erstellt '''eine Kopie''', die dann modifiziert wird. Diese Kopie ist unter dem Namen ''milight_<RemoteID>_0'' im selben Raum zu finden wie das Ausgangsgerät und kann ebenfalls an die eigenen Wünsche angepasst werden.
 
Weitere Beispiele:
Beispiel für ein RGB-CCT-Device:
defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
  attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
  command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\
:brightness:saturation\
:color_temp:hue
==== Ein Leuchtmittel, mehrere Fernbedienungen ====
Pairt man mehrere Fernbedienungen mit einem Leuchtmittel, sollten auch alle entsprechenden Fernbedienungscodes in das readingList-Attribut übernommen werden. Dazu übernimmt man am einfachsten die Einträge aus den zusätzlichen MQTT2_DEVICEs. Benötigt man das zusätzliche Device nicht separat, um z.B. eine getrennte Gruppenschaltung zu realisieren, kann man dieses löschen. Beispiel-readingList für ein Device, das auf zwei Fernbedienungscodes und zwei Gruppen "hört":
 
attr Licht_Wz_all readingList milight/states/0x1234/rgbw/2:.* {json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/2:.* { json2nameValue($EVENT) }\
milight/states/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }
 
==== Fernbedienung als Input-Device nutzen ====
In diesem {{Link2Forum|Topic=103493|LinkText=Thread}} ist dargestellt, wie man eine Fernbedingung des Typs FUT089 dazu verwenden kann, einen [[MPD]] oder Rollladenaktoren zu steuern, oder diese Fernbedienung für [[Hue#HUE-Device|HUEDevice]]-Leuchtmittel zu nutzen.
Um hier nur Differenz-Meldungen direkt an die betreffende myUtils-Funktion zu übergeben und doppelte Events zu verhindern, sollte hier die readingList so angepasst werden, dass nur Messages aus dem "updates"-Zweig ausgewertet werden:
defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
attr MiLight_RC1_0 readingList milight/states/0xABCD/fut089/[0-8]:.* {}
milight/updates/0xABCD/fut089/0:.* { FHEM::attrT_MiLight_Utils::MPDcontrol('myMPD',$EVENT, 'Yamaha_Main') }\
milight/updates/0x5D47/fut089/1:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_links',$EVENT) }\
milight/updates/0x5D47/fut089/2:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_rechts',$EVENT) }\
milight/updates/0x5D47/fut089/3:.* { FHEM::attrT_MiLight_Utils::four_Lights_matrix($EVENT, 'Licht_WoZi_Vorn_Aussen', 'Licht_WoZi_Vorn_Mitte', 'Licht_WoZi_Hinten_Aussen', 'Licht_WoZi_Hinten_Mitte') }\
milight/updates/0x5D47/fut089/4:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Jalousie_WZ',$EVENT) }\
milight/updates/0x5D47/fut089/5:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSO',$EVENT) }\
milight/updates/0x5D47/fut089/6:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSW',$EVENT) }\
milight/updates/0x5D47/fut089/7:.* {}\
milight/updates/0x5D47/fut089/8:.* {}
attr MiLight_RC_WZ stateFormat CommandSet
 
 
== eBus ==
An dieser Stelle sollen lediglich die Grundzüge erläutert werden, eine ausführliche Anleitung über die Konfiguration des [[EBUS-MQTT2|eBus mit MQTT2 gibt es hier]].
 
=== Vorbereitung und Definition am eBus ===
Vorausgesetzt wird ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
In der Konfiguration des Dämons ( /etc/default/ebusd ) ist die Kommunikation über MQTT zu aktivieren und die Topic-Struktur festzulegen, z.B. ''ebusd/%circuit/%name''.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
{{Hinweis|Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ''ebusd'' verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ''ebus...'' zu beginnen!}}
 
=== Vorbereitung und Definition  in FHEM ===
Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem '''''vor''''' den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der ''readingList'' enthalten, die vom ebus stammen. Da wir die ''readingList'' anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen zumindest sämtliche ''readingList''-Attribute entsprechend bereinigt oder gelöscht werden; in der Regel ist es einfacher, diese Geräte nach dem Deaktivieren des autocreate am IO zu löschen.
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT als IO nutzen, sollte für das weitere Vorgehen eine Kopie des MQTT2-"Sammeldevices" genutzt werden, und dessen ''CID'' auf ''ebusd'' geändert werden. Nach Anwendung des ebusd-splitter-templates müssen dann alle den ebus betreffenden Einträge aus der ''readingList'' des "Sammeldevices" gelöscht werden oder diese ganz gelöscht.}}Ist der ebus-Dämon lauffähig und für MQTT konfiguriert, sendet dieser regelmäßige Messages.
 
Sind die Vorbereitungen abgeschlossen, aktivieren wir ''autocreate'' wieder, allerdings wählen wir als autocreate-Methode ''complex'' aus, da der eBus-Dämon teilweise<ref>Dies betrifft vorrangig die Statusmeldungen</ref> eine weiter verschachtelte JSON-Struktur zum Versenden der Informationen verwendet als üblich. Danach wird wie bei den anderen o.g. Geräten automatisch ein neues MQTT2_DEVICE angelegt<ref>Bei Verwendung des MQTT2_CLIENT wird dann die ''readingList'' am bereits definierten MQTT2_DEVICE aus der Kopie des "Sammeldevice" automatisch wieder erstellt bzw. gefüllt.</ref>
 
==== "ebus-Bridge" ====
Auf das von ''autocreate'' erstellte MQTT2_DEVICE wird nunmehr das template ''eBus_daemon_splitter'' angewendet. Nach einiger Zeit sollte sowohl die readingList an diesem Device erweitert worden sein, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.
Dieses Device liefert zukünftig Readings zum Dämon selbst, wie dessen ''uptime'', alle weiteren am eBus angeschlossenen Teilnehmer werden dagegen zweckmäßigerweise durch ein oder mehrere weitere MQTT2_DEVICE-Geräte dargestellt.
 
Das ''attrTemplate'' läd eine weitere ''attrTemplate''-file und [[99 myUtils anlegen|99_myUtils-Code]] vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung.
==== "ebusd_bai" und weitere Geräte ====
{{Hinweis|Der eBus-Dämon sendet nicht alle Informationen zu allen am eBus angeschlossenen Geräte automatisch. Diese müssen teilweise erst aktiv angefragt werden. Wie das im einzelnen erfolgen kann, ist dem o.g. Detailartikel zu entnehmen.}}
Funktioniert die Kommunikation zwischen dem eBus-Dämon und FHEM, sollte nach einigen Minuten zumindest ein weiteres Gerät namens ''MQTT2_ebus_bai'' angelegt worden sein.
 
== Sonos2Mqtt ==
Aus einem Versuch heraus ist ein {{Link2Forum|Topic=111711|LinkText=kleines Projekt}} geworden: Die Sonos Umgebung mit Hilfe von sonos2mqtt als generisches MQTT2_DEVICE komfortabel in FHEM einzubinden.
 
Mit Hilfe von ein paar Templates ist die grundlegende Einbindung in FHEM nach einer kleinen Installation auf Systemebene schnell erledigt. Es läuft derzeit noch zahlreiche Entwicklung und Ideenfindung, die Fortschritte sind live im Thread oder [[Sonos2mqtt|konsolidiert im Wiki]] zu finden.
 
=== Setup im System ===
Für dies Funktion wird der nodejs Server [https://github.com/svrooij/sonos2mqtt sonos2mqtt] benötigt. Entweder installiert man den lokal, irgendwo im Netzwerk oder nutzt den [[MQTT2-Module - Praxisbeispiele#Verwendung des Docker Containers|Docker Container.]]
 
Der nodejs Server sonos2mqtt kann aus Sicht von FHEM irgendwo im Netzwerk stehen - aber er muss im gleichen Netzwerk wie die Sonosplayer stehen. Das UPNP Sonosnetzwerk funktioniert nicht über Netzwerksegmente hinweg.
 
Eine Beschreibung aller Startparameter für sonos2mqtt findet man [https://svrooij.github.io/sonos2mqtt in der offiziellen Doku].
 
Erreicht der nodejs Server sonos2mqtt den MQTT Server nicht über - default: localhost, Port 1883, keine Anmeldung" - muss der Parameter --mqtt  gesetzt werden!
 
Beispiele:
:<code>--mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800</code>            # alles gesetzt
:<code>--mqtt mqtt://192.168.0.3:1800</code>                                                                # IP Adresse und Port gesetzt, keine Anmeldung am MQTT Server
:<code>--mqtt mqtt://192.168.0.3</code>                                                                          # IP Adresse gesetzt, Port ist Standard 1883
 
Erfolgt der Start mit pm2, werden die Parameter mit einem ''zusätzlichen'' doppelten Bindestrich (--) hinter dem nodejs Modul übergeben.
 
Beispiel:
<syntaxhighlight lang="perl">
pm2 start sonos2mqtt -- --mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800
</syntaxhighlight>
 
'''Lokales Setup'''
 
Voraussetzung: nodejs und pm2 ist installiert und für alle Benutzer verfügbar. <syntaxhighlight lang="bash">
sudo npm install -g sonos2mqtt
</syntaxhighlight>
Je nach Entwicklungsstand sind auch Betaversionen verfügbar. Für aktuelle Betaversionen wird dieser Zusatz beim Setup verwendet. -> sonosmqtt@3.1.0-beta.1
 
Wird der sonos2mqtt Server auf einer anderen Maschine eingerichtet, ist der Start entsprechend diesem Absatz [[MQTT2-Module - Praxisbeispiele#Autostart von sonos2mqtt im System mit pm2 .28Alternative.29|Autostart von Sonos2mqtt im System mit pm2]] einzurichten.
 
=== Setup in FHEM ===
Man definiert lediglich ein Bridge Device, der Rest wird automatisch erledigt.
 
Voraussetzung:
* autocreate im System ist aktiv.
* Der verwendete MQTT2_SERVER steht auf '''autocreate simple''' (default/Standard).
* Templates aktuell - FHEM uptodate oder bei Bedarf in der FHEM Kommandozeile aktualisieren:
<pre>
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
</pre>
Bei der Anwendung des Templates für die Bridge wird das Attribut devicetopic ausgelesen oder auf default sonos gesetzt!
 
Wird ein anderer Devicetopic verwendet, muss der bei der Anlage der Bridge gesetzt werden!
 
Diese Zeilen einzeln in der FHEM Kommandozeile oder als Block in der Raw Definition. <syntaxhighlight lang="perl">
define SonosBridge MQTT2_DEVICE
attr SonosBridge room MQTT2_DEVICE
set SonosBridge attrTemplate sonos2mqtt_bridge_comfort
</syntaxhighlight>
Das Template sonos2mqtt_bridge_comfort:
* setzt das Template sonos2mqtt_bridge auf das Device,
* lädt die Datei 99_sonos2mqttUtils.pm aus dem contrib Ordner nach,
* definiert ein notify, dies erledigt im weiteren Betrieb die automatische Konfiguration der automatisch erzeugten MQTT2_DEVICEs.
** mit dem Template sonos2mqtt_speaker (das Template kann auch manuell auf vorhandene Player angewendet werden, die automatische Erzeugung der Player wird aber empfohlen)
** Ermittelt Detailinformation des jeweiligen Players (vor allem IP Adresse und Modelnumber)
** Lädt die Sonosgeräte Icons von den UPNP Devices herunter
** erweitert das setList input Kommando um den TV Eingang (HDMI, spdif) bzw. Line_IN Eingang falls vorhanden (Modelnumber)
* Die Player werden automatisch einzeln erzeugt wenn sie mqtt Nachrichten senden (Play/Stop) oder (alle sofort) wenn der sonos2mqtt Server gestartet wird.
 
==== Wozu dient die Bridge? ====
Sie stellt ein paar wesentliche Funktionen zu Verfügung
# Auffangen von nicht benötigten MQTT Nachrichten.
# Erzeugung/Weiterleitung von Nachrichten für die einzelnen Player - damit auch die Erzeugung von separaten Playern nach dem Schema MQTT2_RINCON12345678901234567.
# Statusanzeige sonos2mqtt als Reading connected (0 offline, 1 connected, 2 Player connected).
Sie kann zusätzlich als zentrales Device verwendet werden, um die Sonos Umgebung abzubilden, z.B. Readings für Favoriten  u.ä.
 
==== Start sonos2mqtt lokal ====
Der Start / Stop des sonos2mqtt Servers innerhalb von FHEM ist nur lokal simpel möglich. Ist der Server irgendwo im Netzwerk oder im Docker Container, muss man andere Möglichkeiten finden. Der Neustart aus FHEM ist zwar praktisch, aber nicht erforderlich.
 
Wird eine existierenden Sonos Landschaft inhaltlich verändert (Player dazu/weg), muss der Server neu gestartet werden. Werden Player temporär abgeschaltet, merkt das der Server nach einer Zeit selbst, oder man forciert dies mit einem CheckSubscription an der Bridge.
 
Soll das Modul sonos2mqtt mit seinen default Einstellungen gestartet werden, genügt dieser kurze Befehl (in der FHEM Kommandozeile):
<syntaxhighlight lang="bash">
"pm2 start sonos2mqtt"
</syntaxhighlight>
Tipp: Verwendet man anstatt "Befehl" den Syntax {qx(Befehl)} in der FHEM Kommandozeile, wirkt der Befehl zwar blockierend aber die Ausgabe erfolgt im Browser und nicht im Logfile. Mit dem Parameter -s erfolgt keine Ausgabe.
 
==== Autostart von sonos2mqtt mit FHEM ====
Der Code startet sowohl das sonso2mqtt Modul sofort und implementiert ein notify für den zukünftigen automatischen Start beim Start von FHEM.
<syntaxhighlight lang="perl">
define n_pm2_sonos notify global:INITIALIZED|n_pm2_sonos:start "pm2 -s start sonos2mqtt"
trigger n_pm2_sonos start
</syntaxhighlight>
 
=== Autostart von sonos2mqtt im System mit pm2 (Alternative) ===
Der obige Code startet das sonos2mqtt nodejs Modul mit pm2 beim Start von FHEM. Sollte das nicht funktionieren oder nicht ins gesamte Konzept passen (weil z.B. mehrere nodejs Module geladen werden) kann der automatische Start direkt im System erfolgen. Zunächst dafür das oben eventuell schon definierte notify löschen!<syntaxhighlight lang="perl">
delete n_pm2_sonos
</syntaxhighlight>Der Start des Modul muss nicht mit erhöhten Rechten geschehen! Im Terminal folgendes eingeben (unter dem angemeldeten Benutzer wird sonos2mqtt später immer gestartet):<syntaxhighlight lang="bash">
pm2 start sonos2mqtt
pm2 startup
</syntaxhighlight>
Der letzte Befehl "redet", d.h. es gibt eine Ausgabe in der Art:
<syntaxhighlight lang="bash">
[PM2] To setup the Startup Script, copy/paste the following command:
sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u pi --hp /home/pi
</syntaxhighlight>
Man tut einfach genau das, was dasteht: die letzte Zeile kopieren und wieder einfügen und ausführen. Danach muss man die Konfiguration von pm2 noch sichern:
<syntaxhighlight lang="bash">
pm2 save
</syntaxhighlight>
 
=== Verwendung des Docker Containers ===
Ergänzend zur [https://svrooij.io/sonos2mqtt/getting-started.html#run-sonos2mqtt-in-docker Original Doku:]
 
Beim Container findet die Konfiguration der Verbindung zum FHEM in den Environment Variablen statt:
<syntaxhighlight lang="perl">
environment:
  - SONOS2MQTT_DEVICE=192.168.56.207 # hier muss einer der Sonos Lautsprecher stehen
  - SONOS2MQTT_MQTT=mqtt://192.168.56.121:1883 # mqtt2_server FHEM, erweiterter Syntax siehe oben
  - SONOS_LISTENER_HOST=192.168.56.121 # Docker host IP
</syntaxhighlight>
 
=== Sonos2mqtt mit mehr Komfort ===
Im Wiki Artikel [[Sonos2mqtt]] geht es weiter.
 
== Owntracks GPS Tracking in FHEM über MQTT - Cloud ==
Das hier gezeiget Beispiel verwendet eine MQTT Instanz im Internet, die mit einem MQTT2_CLIENT angebunden wird. Da wenig Traffic benötigt wird, genügt z.B. eine kostenfreie Instanz z.B. bei myqtthub (Stand. Dezember 2020)
 
Alternativ kann man einen MQTT2_SERVER auch direkt verfügbar machen, wenn man sich sicher ist was man da tut! Siehe {{Link2Forum|Topic=99666|Message=1028576|LinkText=diesen Forenbeitrag}}. Das Bridge Device wird dabei genau so benötigt, nur der IODev ist dann der MQTT2_SERVER.
 
=== owntracks auf dem Smartphone konfigurieren ===
Menü / Einstellung / Verbindung
 
Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):
* Modus -> MQTT
* Hostname  ->
** Hostnamen: host.cloud.com
** Port: 8883
** ClientID: ID vom Provider
** WebSockets (nicht nutzen)
* Identifikation ->
** Benutzername: user-name
** Passwort: user-password
** GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
** TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte)
* Sicherheit ->
** TLS aktivieren
=== Definition in FHEM ===
Der MQTT2_CLIENT wird so eingerichtet, man braucht eine andere ClientID als auf dem Smartphone! Stimmt alles sollte das Gerät sofort open anzeigen.<syntaxhighlight lang="perl">
MQTT2_CLIENT einrichten, autocreate simpel
define mqtt2Cloud MQTT2_CLIENT host.cloud.com:8883
attr mqtt2Cloud SSL 1
attr mqtt2Cloud autocreate simple
attr mqtt2Cloud clientId fhem1
attr mqtt2Cloud room MQTT2_IO
attr mqtt2Cloud username user-name
set mqtt2Cloud password user-password
</syntaxhighlight>Für die automatische Erzeugung der Trackergeräte in FHEM richtig man zuerst ein Bridge Device ein:<syntaxhighlight lang="perl">
define MQTT2_Cloud_bridge MQTT2_DEVICE
attr MQTT2_Cloud_bridge IODev mqtt2Cloud
attr MQTT2_Cloud_bridge autocreate 1
attr MQTT2_Cloud_bridge room MQTT2_DEVICE
</syntaxhighlight>Dies wird entweder mit dem Template allgemein  konfiguriert<syntaxhighlight lang="perl">
set MQTT2_Cloud_bridge attrTemplate MQTT2_CLIENT_general_bridge
</syntaxhighlight>oder manuell nur für owntracks eingerichtet<syntaxhighlight lang="perl">
attr MQTT2_Cloud_bridge bridgeRegexp owntracks/[^/]+/([^/:]+).* "owntracks_$1"
</syntaxhighlight>MQTT2 Geräte für owntracks werden jetzt automatisch mit dem Namen MQTT2_owntracks_<GeräteID> erzeugt. Diese werden einfach mit dem Template owntracks_device fertig konfiguriert. Bei einem IOS Gerät kann man danach noch das Template owntracks_device_IOS als Erweiterung anwenden.
 
==== Anwesenheitserkennung ====
Die Anwesenheit kann im owntracks Device direkt für die selbst definierten Plätze abgelesen werden: entweder steht im reading place der jeweilige Ort oder away. Um hier noch eine gewisse Einheitlichkeit in der Verwendung zu bekommen kann man ein PRESENCE Device verwenden: <syntaxhighlight lang="perl">
define OT_Mi6 PRESENCE event MQTT2_owntracks_mi6:place:.away MQTT2_owntracks_mi6:place:.<Home>
</syntaxhighlight>Im Move Modus erfolgt die Erkennung sehr schnell und damit einige Sekunden eher als eine BT Erkennung im Haus - der Akkuverbrauch steigt enorm. Im Significant Modus kann es schon mal ein paar Minuten dauern - ein relevanter Akku Verbrauch ist nicht erkennbar.
 
== Owntracks GPS Tracking in FHEM direkt an den eigenen Fhem-Server ==
Dieses Beispiel beschreibt den direkten MQTT2 Zugang wobei das IODev dann der MQTT2_SERVER ist. Hierzu bitte {{Link2Forum|Topic=99666|Message=1028576|LinkText=diesen Forenbeitrag}} lesen.
 
=== SSL - Zertifikate fuer fhem erstellen. ===
Zunächst erstellen wir fuer den MQTT - Server CA zertifizierte SSL Zertifikate. Diese sind identisch mit den SSL - Zertifikaten, welche man evtl. schon fuer den SSL - Zugang seines FHEMWEB - Device erstellt hat.
 
Hat man den FHEMWEB schon mit eiem SSL Zertifikat (http'''<u>s</u>'''://) abgesichert, muss man daraus nur noch den .p12 - Container erstellen.
 
Hat man den FHEMWEB noch nicht abgesichert (http://), dann wir es höchste Zeit!
 
Für die Erstellung dieser SSL Zertifikate folgt dem Wiki-Beitrag [[FHEM mit HTTPS SSL-Zertifikat und eine eigene Zertifizierungsstelle]].
 
Die darin beschriebenen Dateien, das cacert.pem sowie den server.p12 - Container müsst ihr nun an euer Mobiltelefon senden.
 
=== Definition in FHEM ===
Der MQTT2_Server wird wie folgt eingerichtet.<syntaxhighlight lang="perl">
define myMQTT2Server_extern MQTT2_SERVER IPV6:1884 global
attr MQTTBroker_extern SSL 1
attr MQTTBroker_extern autocreate complex
attr MQTTBroker_extern event-on-change-reading .*
attr MQTTBroker_extern group MQTT2
attr MQTTBroker_extern icon mqtt_broker
attr MQTTBroker_extern room MQTT2
</syntaxhighlight>
 
Der MQTT2_Server wird zusätzlich über "allowed" abgesichert:<syntaxhighlight lang="perl">
define allowed_MQTT2Server_extern allowed
attr allowed_MQTT2Server_extern DbLogExclude .*
attr allowed_MQTT2Server_extern group MQTT2
attr allowed_MQTT2Server_extern room  MQTT2
attr allowed_MQTT2Server_extern validFor myMQTT2Server_extern
</syntaxhighlight>Jetzt vergeben wir noch einen Usernamen und ein Passwort für dieses "allowed" - Device<syntaxhighlight lang="perl">
set allowed_MQTT2Server_extern basicAuth MyMQTT2Username MyMQTT2Password
 
</syntaxhighlight>Denkt bitte daran einen eigenen Usernamen und ein eigenes langes, kompliziertes Passwort zu verwenden. Vorsicht bei Sonderzeichen!
 
=== Port-Freigaben im Router ===
An dieser Stelle müssen wir den Port 1884 in den Internet - Freigaben eures Routers freigeben.
 
Bei der Fritz!Box wird dies beispielsweise unter Internet -> Freigaben -> Port-Freigaben gemacht. Die Details hierzu entnehmt bitte der Bedienungsanleitung eures Routers.
 
Wichtig ist dabei, das ihr das Protokol "TCP" verwendet und der Port 1884 extern nach Port 1884 intern an die IP - Adresse des jeweiligen fhem-Servers übermittelt wird.
 
=== owntracks auf dem Smartphone konfigurieren ===
Menü / Einstellung / Verbindung
 
Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):
* Modus -> MQTT
* Hostname  ->
** Hostnamen: subdomain.dyndns.com
** Port: 1884
** ClientID: Vorname_Nachname
** WebSockets (nicht nutzen)
* Identifikation ->
** Benutzername: MyMQTT2Username
** Passwort: MyMQTT2Password
** GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
** TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte. Empfehlung: Die Initialien verwenden.)
* Sicherheit ->
** TLS aktivieren
** CA-Zertifikat: cacert.pem
** Client-Zertifikat: server.p12
** Passwort fuer Client-Zertifikat: Passwort für den server.p12 - Container
 
Wenn alles richtig gemacht wurde, dann erstellt das myMQTT2Server_extern - Device automatisch ein neues Device für jede owntracks-App, die sich an dem myMQTT2Server_extern - Device meldet.
 
Übrigens: Will man seine gesamte Familie ebenfalls über owntracks tracken, so muss man in den jeweiligen APPs nur die Werte für ClientID, GeräteID und TrackerID individuell gestalten.
 
An den fhem- Einstellungen müssen keine weiteren Änderungen vorgenommen werden.
== Allgemeine Hinweise ==
=== MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen ===
Nutzt man das rawEvents-Attribut am MQTT2-IO<ref>z.B. <code>attr MQTT2_FHEM_Server rawEvents .*</code>, der regex-Filter kann wie üblich angepasst werden</ref>, kann man den Datenverkehr des Servers am Event-Monitor mitschneiden. Dies ist insbesondere für unbekannte Geräte nützlich, deren Topic- und Payload-Struktur noch nicht bekannt ist.
Um den kompletten MQTT Datenaustausch mitzuschneiden, kann man mit <code>attr mqtt2_server verbose 5</code> auch alles ins FHEM-Log schreiben lassen.
 
=== autocreate funktioniert anscheinend nicht? ===
In der Regel wird bei neu eingehenden MQTT-Messages über ''autocreate'' ein neues Device erstellt, wenn Nachrichten von einem bisher unbekannten Gerät kommen. Geschieht dies nicht, sollten folgende Punkte geprüft werden:
# (nur bei MQTT2_SERVER:) Der Client muss eine ClientID angeben, diese darf nicht den defaults von ''mosquito_sub'' entsprechen.
# Ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') muss vorhanden und aktiv sein.
# ''autocreate'' am IO muss eingeschaltet sein, was für MQTT2_SERVER bedeutet, dass es nicht auf "0" stehen darf (hier ist dann ''simple'' die aktive Voreinstellung), für MQTT2_CLIENT sollte ebenfalls ''simple'' verwendet werden; dies muss hier allerdings explizit gesetzt werden.
 
Wird dann immer noch kein Device erstellt, gibt es in aller Regel ein Device, das bereits einen entsprechenden Eintrag in der readingList enthält, oder es sind keine Nachrichten eingegangen. Überprüfen Sie daher dann ggf. die Einstellungen am Client-Gerät (z.B. im Web-Interface des Shelly oder Tasmota-geflashten ESP8266).
 
Das ''autocreate'' am Device schließlich bestimmt, ob die ''readingsList'' erweitert werden darf, wenn Informationen über bisher nicht über die readingList abgedeckte Topics empfangen werden und vom MQTT2-IO als zu diesem Device/ClientID gehörend identifiziert wurden.
 
=== attrTemplate ===
{{Randnotiz|RNTyp=Info|RNText=Die per attrTemplate jeweils erzeugten Konfigurationen sind Einrichtungsbeispiele, die v.a. eine in sich konsistenze Zusammenstellung der verschiedenen Attribute enthalten. Es steht jedem User frei, diese Ausgangsbasis dann nach seinem Belieben zu ändern. Spätere Änderungen des verwendeten attrTemplate wirken sich nicht automatisch auf die durch frühere Versionen oder den User nachkonfigurierte Geräte aus! Da es vorkommen kann, dass sich die per MQTT übermittelten Daten und Topics ändern, wenn z.B. eine firmware aktualisiert wurden, kann dies Anpassungen am jeweiligen Template erforderlich machen. Grundsätzlich sollen die per attrTemplate für MQTT2_DEVICE verfügbaren attrTemplate jeweils für die aktuellste verfügbare stabile firmware-Version passen.}}
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''[[AttrTemplate|attrTemplate]]'' genutzt werden.
Die Anwendung für MQTT2_DEVICE ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.
 
 
{{Hinweis|In einigen Fällen kann es vorkommen, dass die template-Bezeichnung zwischenzeitlich geändert wurde. Seit 21.09.2019 erfolgt die Sortierung der auswählbaren templates nicht mehr nur nach den Namen, so dass die entsprechenden Namensbestandteile entfallen sind, die einer besseren Sortierung dienten.}}
 
=== attrTemplate: Es werden nicht alle templates angezeigt ===
Siehe Beitrag [[AttrTemplate#Warum finde ich das Template xyz nicht.3F|AttrTemplate: Warum finde ich das Template xyz nicht.]]
 
=== attrTemplate und Sprachsteuerung ===
Konfiguriert man MQTT2_DEVICE-Geräte mit attrTemplate, werden in der Regel auch direkt die für die Sprachsteuerung der Geräte erforderlichen Attribute mit gesetzt. Weiterführende Hinweise sind auch zu diesem Teilaspekt von ''[[AttrTemplate|attrTemplate]]'' dem betreffenden Hauptartikel zu entnehmen.
 
=== bridgeRegexp ===
[[Datei:Mqtt2 server.png|300px|thumb|left|Logische Verortung der bridgeRegexp-Angaben]]{{Randnotiz|RNTyp=y|RNText=Beachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.}}Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch '''''einem''''' ''MQTT2_DEVICE'' zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. In dem nebenstehenden Schaubild wären dies die Geräte ''A'' bis ''D''. Das '''Attribut''' ''bridgeRegexp'' kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem '''anderen Device''' (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als ''newClientId'' hinterlegte Angabe verwendet. In nebenstehendem Schaubild ist dies exemplarisch für die Gerätegruppe ''D'' mit dem ''bridge''-Device ''D'' und dessen ''Satelliten'' ''D1'' bis ''D4'' dargestellt.
Dementsprechend sind in den hier aufgeführten Beispielen ''bridgeRegexp''-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren, wie z.B. für über hier dargestellten ''zigbee2mqtt'' oder ''zigbee2tasmota''. Ein Sonderfall hierbei ist das template ''MQTT2_CLIENT_general_bridge'' zur Verwendung mit dem [[MQTT2_CLIENT#Anwendung|MQTT2_CLIENT]], denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem ''mosquitto''-Server und würden sonst alle ein und demselben MQTT2_DEVICE zugewiesen.
 
=== Ständig neue Devices? ===
MQTT2_SERVER kann zwischen verschiedenen Geräten auch anhand der ClientID unterscheiden. Für jedes neu erkannte Gerät wird auch ein eigenes MQTT2_DEVICE angelegt. Abhilfemaßnahmen:
==== Vergabe einer ClientID ====
Die meisten MQTT-fähigen Geräte enthalten Optionen zur Vergabe einer eindeutigen ClientID (siehe das Beispiel des zigbee2mqtt-Dienstes oben).
Wird keine ClientID vergeben, verwenden manche Clients für jede Verbindung wieder neue ID's. Es wird empfohlen, möglichst von diesen Einstelloptionen Gebrauch zu machen.
 
==== Löschen der ClientID aus der readingList usw. ====
Ist dies nicht möglich oder erwünscht, kann man auch die ClientID aus den readingList-, setList- und getList-Attributen entfernen. Dies ist jedenfalls solange unschädlich als nicht mehrere Geräte identische Topic-Pfade verwenden (daher die Empfehlung, insbesondere bei Tasmota-Geräten den ''default'' "sonoff" zu ändern).
Beispielsweise wäre <code>attr Milight_Bridge readingList milight_hub_1370325:milight/LWT:.* {json2nameValue($EVENT) }</code> zu ändern in <code>attr Milight_Bridge readingList milight/LWT:.* {json2nameValue($EVENT) }</code>
Die über ''attrTemplate'' verfügbaren Konfigurationen verwenden in der Regel keine ClientID's bzw. entfernen diese.
 
=== Wildcards in readingList und setList ===
Auch in readingList und in setList sollten sich sog. wildcards verwenden lassen. Die Vorgehensweise ist jedoch unterschiedlich:
 
In ''readingList'' werden normale regex-Ausdrücke verwendet. Ein Punkt steht daher z.B. für ein beliebiges Zeichen, alles zwischen zwei Topic-Tree-Elementen (getrennt typischerweise durch einen "/") kann man so schreiben: "[^/]+" (entspricht: "Mindestens ein Zeichen, das kein Schrägstrich ist"). Ergänzender Hinweis: Will man z.B. Informationen aus einem beliebigen Teil des Topic-trees extrahieren und als Reading-Namen verwenden, kann dies im Rahmen eines Perl-Aufrufs geschehen. Beispiele aus der mqtt2.template-file: OpenMQTTGateway_BT_scanner und OpenMQTTGateway_BT_gtag (letzteres überführt die Information, über welches Gateway bestimmte Informationen eingegangen ist jeweils in eigene Readings pro Gateway).
 
In ''setList'' gelten dagegen die wildcard-Konventionen aus der MQTT-Welt. Dort steht "+" für einen austauschbaren Teil des Topic-Trees (zwischen zwei Schrägstrichen). Anmerkung: Bitte vorher prüfen, ob es wirklich sinnvoll ist, derart unspezifische Publishes vorzunehmen. Meist gibt es "Gruppen-Topics", auf die mehrere Geräte eines bestimmten Typs hören bzw. man kann dies dort (in der firmware bzw. auf den Konfigurationsseiten der Geräte) einstellen.
 
=== Die JSON-Daten sollen ausnahmsweise nicht ausgepackt werden ===
In manchen Fällen ist das automatische Auspacken der JSON-Payload nicht erwünscht. In diesen Fällen kann man einfach den gewünschten Reading-Namen in die readingList eintragen, statt der Anweisung, den JSON an json2NameValue() zu übergeben. Aus
<pre>
attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/waypoints:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/event:.* { json2nameValue($EVENT) }
</pre>
wird dann:
<pre>
attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* json_mi6\
owntracks/clouduser/mi6/waypoints:.* json_waypoints\
owntracks/clouduser/mi6/event:.* json_event
</pre>
Erforderlichenfalls kann man die Einträge auch doppelt erstellen, um sowohl den JSON wie auch die ausgepackten Readings zu erhalten.
 
=== Die JSON-Daten vor dem auspacken manipulieren ===
Aus diversen Gründen kann es zweckmäßig sein, einen bestimmten Wert der JSON-Payload zu ignorieren.
Z.B. sendet ein Client statt eines Messwertes die Info "bad". Dieser Fehlerwert soll aus der JSON-Payload "ausgefiltert" werden:
<pre>
attr DEVICE readingList <your topic>:.* { my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { 'bad' ne $rets->{$_} } keys %{$rets};; return \%cleaned }
</pre>
 
Oder auch einen Wert umzubenennen wenn die JSON-Payload nur ein Objekt beinhaltet:
<pre>
attr DEVICE readingList <your topic>:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}
</pre>
 
=== Unnötige Konfigurationsinformationen verwerfen ===
Siehe Einleitung und den [[MQTT2_CLIENT#ignoreRegexp|ignoreRegexp-Abschnitt zu MQTT2_CLIENT]].
 
=== Weiterführende Themen ===
==== Verbinden mehrerer FHEM-Instanzen über MQTT ====
Wie im Hauptartikel zu [[MQTT#Kommunikation zu sonstigen FHEM-Geräten über MQTT|MQTT]] erläutert, gibt es mehrere Varianten, wie man mit Hilfe von FHEM aus Events an beliebigen Geräten MQTT-Messages erzeugen kann. So kann man z.B. Messdaten eines Systems über ein ''notify'' iVm. einer einfachen ''publish''-Anweisung an ein zweites FHEM schicken, das diese Daten dann z.B. mit Hilfe der MQTT2-Module auswerten kann.
Damit dabei Nachrichten unterschiedlicher Quellen auch als getrennte Readings bzw. ggf. auch gesonderten MQTT2_DEVICE-Instanzen zugeordnet werden, sollte man entsprechende Topic-Strukturen wählen, die dann auch mit Hilfe einer geeigneten ''bridgeRegexp'' automatisiert ausgewertet werden kann, siehe z.B. dieser {{Link2Forum|Topic=107145|LinkText=Forumsthread}}:
attr MQTT2_myMqttServer bridgeRegexp \
  SmartHome/MqttGenericBridge2/([A-Za-z0-9]*)/.*:.* "mgb2_$1"
Dabei werden die betreffenden Informationen der entfernten FHEM-Instanz alle nach dem Schema ''SmartHome/MqttGenericBridge2/<Device-Name>/<Reading-Name>'' versendet.


Indem man in der ''readingList'' sowohl den einzelnen Kanal wie die Gruppenadresse (''0'') angibt, erhält man auch Rückmeldungen über Schaltvorgänge, die die Gruppe betreffen.
==== Umstellung von MQTT_DEVICE (und Derivaten wie XiaomiMQTTDevice) zu MQTT2_DEVICE ====
Wer mag, kann dann noch ein Device anlegen, das nur den ''0''-Kanal abbildet; über dieses werden dann alle Leuchtmittel geschaltet, die zu der betreffenden Gruppenadresse gehören (im obigen Beispiel: 0xBE59).
Wer beabsichtigt, von der Implementierung MQTT+MQTT_DEVICE zu MQTT2-IO und MQTT2_DEVICE zu wechseln, sollte einige Punkte beachten. Viele diesbezügliche Fragen sind vor allem in  {{Link2Forum|Topic=103762|LinkText=diesem Foren-Thread}}


Für ein dynamisches Icon kann derselbe code verwendet werden wir bei Tradfri beschrieben, dazu muss in der MQTT-Konfiguration des Milight-Hub auch "brightness" mit als zu sendendes Element eingestellt bleiben.  
näher erläutert.


== Links ==
== Links ==
* {{Link2Forum|Topic=91394|LinkText=Thread, aus dem diese Anleitung ursprünglich entstanden ist}}
* {{Link2Forum|Topic=91394|LinkText=Thread, aus dem diese Anleitung ursprünglich entstanden ist}}
* {{Link2Forum|Topic=91807|LinkText=Thread zum Tasmota-Device}}
* {{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}}
* {{Link2Forum|Topic=116162|LinkText=Der MQTT-Workshop für MQTT2-Module}}


== Hinweise ==
== Hinweise ==
Zeile 180: Zeile 712:
[[Kategorie:HOWTOS]]
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]
[[Kategorie:MQTT]]
[[Kategorie:Zigbee]]
[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]
[[Kategorie:Interfaces]]

Aktuelle Version vom 27. Oktober 2024, 07:23 Uhr

Einführung: MQTT bzw. MQTT2 in FHEM

Emblem-question-yellow.svgSollten Sie MQTT2_CLIENT verwenden, beachten Sie bitte, dass der MQTT2_CLIENT die ursprüngliche Herkunft der über MQTT verteilten Informationen nicht kennt. Daher ergeben sich in der Anwendung kleinere Unterschiede, zu deren Verständnis die diesbezüglichen Hinweise zu MQTT2_CLIENT bekannt sein sollten.

Zur Einbindung von Geräten, welche zur Nutzung des MQTT-Protokols konfiguriert werden können und darüber mit einem MQTT-Server (früher: Broker) kommunizieren, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser Übersicht zu entnehmen.

Im Rahmen dieses Artikels wird für die eigentlichen Geräte MQTT2_DEVICE verwendet, damit wird als IO-Device entweder MQTT2_SERVER oder MQTT2_CLIENT benötigt, mit einem IO-Device des Typs MQTT funktioniert die nachfolgende Darstellung dagegen nicht[1]. MQTT2_DEVICE unterstützt u.a. auch die setExtensions direkt, also z.B. on-for-timer[2] sowie attrTemplate[3].

Allgemeine Einstellungen und Hinweise

X mark.svgBeachten Sie, dass für autocreate in Verbindung mit MQTT2_SERVER zwingend jeder über MQTT kommunizierende Client eine ClientID angeben muss. Passen Sie daher ggf. die Einstellungen Ihres Geräts an. Manche Geräte verwenden auch "Wegwerf"-ClientID's. Für diese empfiehlt es sich, ggf. dann die durch autocreate erstellten Geräte nachzubearbeiten und die ClientID-Angabe v.a. aus den Inhalten des readingList-Attributs zu entfernen.

Die nachfolgenden Beispiele gelingen am einfachsten mit MQTT2_SERVER als Server ("Broker"), für diesen sollte dabei autocreate nicht deaktiviert sein, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden[4] .

Beispiel[5]:

define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

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


Info blue.png
Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum Import von Code Snippets. Wer die Attribute direkt und einzeln bearbeitet, muss ggf. die "\" entfernen!


MQTT-Einstellungen in den Geräten

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


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


auto-Konfigurations-features

Viele firmwares und Dienste bieten Möglichkeiten an, einer Controller-Software (insbesondere homeassistant) Hilfsdaten zur automatisierten Konfiguration bereitzustellen. Da FHEM diese Daten nicht zu ihrem ursprünglichen Zweck verwenden kann, werden hierdurch lediglich zusätzliche Readings erzeugt, mit denen man als User in der Regel wenig anfangen kann. Es wird daher empfohlen, derartige features abzuschalten. Wo dies nicht möglich ist, sollte man eine passende ignoreRegexp setzen bzw. diese passend erweitern!

Schritt für Schritt

Hier werden in der Regel fertige Konfigurationen für häufige Anwendungsfälle (beispielhaft) dargestellt. In MQTT2_DEVICE - Schritt für Schritt ist etwas mehr über die Vorgehensweise bei der Zusammenstellung der verschiedenen Attribute und deren Zusammenwirken zu erfahren.

zigbee2mqtt

Darstellung in FHEMWEB

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.

Einzelheiten zur Vorgehensweise sind auf der Detailseite zigbee2mqtt zu finden.

Tasmota

X mark.svgBitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!

Tasmota (Theo Arends Sonoff MQTT Over The Air - einer offenen Firmware von 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.

Info blue.png
Tasmota mqtt config.png
Vor allem, aber nicht nur bei Verwendung des MQTT2_CLIENT als IO, ist es empfehlenswert, in der MQTT-Konfiguration der tasmota-Geräte für den Parameter topic = %topic% (tasmota) ebenfalls die dynamisch aus der Chip-ID erzeugte Kennung DVES_%06X zu verwenden. (Kopieren Sie einfach diese Zeichenkette aus dem Eingabefeld für "client ...", siehe nebenstehende Abbildung). Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels rename oder ggf. mit einem alias - erfolgen.


MQTT2_DEVICE

Dieses sollte bei aktiviertem autocreate am MQTT2_SERVER-Device automatisch angelegt werden, sobald das betreffende Gerät eingesteckt oder neu gestartet oder an einem evtl. vorhandenen Taster geschalten wird. Bislang wurden Tasmota version(en) ab 6.1.1 bis min. 8.1.0 getestet, dies auf verschiedener Hardware, zunächst mit Sonoff Touch und S20, zwischenzeitlich mit einer Vielzahl von Geräten, die per USB-Adapter oder mit der Methode aus dem Tuya-Convert-Projekt des heise-Verlags auf Tasmota umgeflasht wurden.

Manuelle Anpassungen - Schalter

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

Manuelle Anpassungen - Dimmer

X mark.svgDieses Beispiel ist nur bedingt zur Nachahmung zu empfehlen: Prinzipiell kann man Readings und setter in MQTT2_DEVICE fast nach Belieben benennen. Wählt man allerdings FHEM-typische Namen, kann dies sehr zur Vereinfachung beitragen. Z.B. wird eine Sprachssteuerung bei einem Dimmer üblicherweise automatisch korrekt eingestellt werden, wenn der für die Helligkeit zuständige setter z.B. pct (oder brightness) heißt, oder eine abzufragende Temperatur temperature. Entsprechendes gilt im Rahmen von devspec-Abfragen.

Bei einem Dimmer sind einige zusätzliche Anpassungen vorzunehmen. Ein Dimmer wird über POWER geschaltet und über Dimmer gedimmt. Damit das funktioniert, müssen ein stateFormat und devStateIcon zusammenarbeiten:

attr MQTT2_DVES_2DF34D devStateIcon 10\d.*:dim100%@orange:off 1\d.*:dim12%@orange:off 2\d.*:dim18%@orange:off 3\d.*:dim31%@orange:off 4\d.*:dim43%@orange:off 5\d.*:dim50%@orange:off 6\d.*:dim62%@orange:off 7\d.*:dim68%@orange:off 8\d.*:dim81%@orange:off 9\d.*:dim93%@orange:off 0:FS20.off:on .*:FS20.off@orange:off
 attr MQTT2_DVES_2DF34D stateFormat {if(ReadingsVal($name,"POWER",0)eq"off"){0}else{ReadingsVal($name,"Dimmer",0)}}

Nun kann man über das Icon ein- und ausschalten und der Zustand des Dimmers wird korrekt angezeigt.

Es fehlt noch ein Slider, um auch dimmen zu können. Zusätzlich muss setList noch um Dimmer erweitert werden:

 attr MQTT2_DVES_2DF34D setList on cmnd/dimmer/POWER on\
 off cmnd/dimmer/POWER off\
 Dimmer cmnd/dimmer/Dimmer
 attr MQTT2_DVES_2DF34D webCmd Dimmer
 attr MQTT2_DVES_2DF34D widgetOverride Dimmer:slider,0,1,100

attrTemplate

Allgemeines

Für gängige Tasmota-Geräte stehen templates bereit, mit denen sich diese schnell konfigurieren lassen. Beachten Sie dazu den Abschnitt attrTemplate in MQTT2_DEVICE. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.

Info blue.png
Bitte attrTemplates nicht verwechseln mit templates, die auf den Tasmota- bzw. Blackadder-Seiten angeboten werden, welche zur Konfiguration der firmware genutzt werden können! Es sollte zunächst die firmware korrekt eingerichtet werden, so dass das Gerät selbst direkt auf dessen Web-Interface korrekt bedient werden kann.


Kein passendes attrTemplate vorhanden?

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

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

on-for-timer

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

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

delay

Zeile zur Erweiterung der setList (Attributeingabe via FHEMWEB!):

on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}

Ohne Auswirkungen auf alles, was danach kommt, hat aber den Nachteil, dass die möglichen Zeitspannen auf 3600 1/10 Sekunden begrenzt sind (siehe Commands - Tasmota Delay), also 6 Minuten.

pulseTime

Zeile zur Erweiterung der setList (s.o.):

on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}

Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit delay. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites save nur bis zum nächsten reboot des Microcontrollers.

Da nach dem ersten pulseTime setzten, diese immer benutzt wird, kann man mit einem kleine Workaround das Device normal arbeiten lassen. Dafür wird bei jedem anderem Befehl, aus der PulseTime, der Timer deaktiviert. Hierfür machen wir uns zu nutzen, dass man mehrere Befehle gleichzeitig an Tasmota senden kann (backlog). Ob diese Lösung auch mit anderen MQTT Firmwares funktioniert, kann ich nicht sagen. Es wurde lediglich mit Tasmota getestet. Wir senden also, bevor wir den eigentlich Tasmota Befehl zum Ein- oder Ausschalten schicken, einen Befehl zum deaktivieren des Timers: "pulseTime 0" Hier ein Beispiel: (das entsprechende device "DEV_611F3E" muss gegen das eigene ersetzt werden)

off:noArg    cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 0
on:noArg     cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 1 
toggle:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 2

zigbee2tasmota

zigbee2tasmota ist eine Erweiterung der Tasmota-firmware für Microcontroller, insbesondere dem ESP8266 (und ESP32)(link), über die einige ZigBee-Chipsätze (insbesondere TI CC2530) als Coordinator eingebunden werden können, um ein ZigBee-Netzwerk aufzubauen.

Info blue.png
Stand 08/2020 war die Einbindung anderer Chipsätze erst in einem Alpha-Stadium; die Zahl der über einen CC2530 einbindbaren ZigBee-Geräte ist daher derzeit relativ begrenzt (ca. 16)!


Auch für diese Lösung stehen einige attrTemplate zur Verfügung. Nähere Informationen hierzu sind dem Artikel Zigbee2Tasmota-MQTT zu entnehmen.

ESPurna

ESPurna ist eine weitere alternative firmware für ESP8266-basierte Geräte, Details sind der Projektseite zu entnehmen.

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

Shelly

Vorbemerkung

Auch für Shelly-Geräte steht eine Auswahl an templates bereit. Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.

Standardmäßig senden die Shelly-Geräte ihren kompletten Status alle 30 Sekunden. Dies kann man über den Parameter mqtt_update_period in den settings ändern, allerdings ist dieser nur über die HTTP-Schnittstelle des Shelly verfügbar. Um diese Statusupdates abzustellen, kann über den Browser folgender Befehl verwendet werden:

http://<ip-des-shelly>/settings?mqtt_update_period=0, 

Soweit bekannt, werden dann nur statische updates ausgeschaltet, z.B. für das Relay bzw. angeschlossene Taster oder Schalter; insbesondere Verbrauchswerte werden dennoch aktualisiert.

Shelly1

Shellybulb

Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:

Internals:
  CFGFN     
  CID        shellybulb_3CC533
  DEF        shellybulb_3CC533
  DEVICETOPIC MQTT2_shellybulb_3CC533
  IODev      MQTT2_FHEM_Server
  NAME       MQTT2_shellybulb_3CC533
  NR         246
  STATE      ???
  TYPE       MQTT2_DEVICE
  READINGS:
    2018-12-12 19:28:08   status_blue     0
    2018-12-12 19:28:08   status_brightness 61
    2018-12-12 19:28:08   status_effect   0
    2018-12-12 19:28:08   status_gain     26
    2018-12-12 19:28:08   status_green    0
    2018-12-12 19:28:08   status_ison     true
    2018-12-12 19:28:08   status_mode     color
    2018-12-12 19:28:08   status_red      255
    2018-12-12 19:28:08   status_temp     3250
    2018-12-12 19:28:08   status_white    0
Attributes:
  IODev      MQTT2_FHEM_Server
  readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
  room       MQTT2_DEVICE
Darstellung in FHEMWEB nach Anwendung des template

Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.

Shelly Plug S

Über die Leistungsmessung des Shelly Plug S lässt sich sehr einfach auch eine Erkennung des Betriebszustandes des angeschlossenen Gerätes realisieren. Dazu stellt man zuerst fest, wieviel Leistung das Gerät in jedem Betriebszustand verbraucht und kann dann z.B. für einen angeschlossenen Fernseher, der im Standby 1 Watt und im Betrieb > 100 Watt verbraucht, den Zustand erkennen und als on/off Status anzeigen. Dazu wird das state Reading wie folgt definiert:

 attr readingList shellies/shellyplug-s-123456/relay/0/power:.* { { state => $EVTPART0<100?"off":"on" } }

Der Status des MQTT2 Devices zeigt dann bei <100W "off" und sonst "on" an.

HTTP-Commands

In diesem Forumsbeitrag wird eine Lösung vorgestellt, um über myUtils-Code weitere Kommandos bereitzustellen, die sonst nur direkt über das Web-Interface zu erreichen sind.

Shelly Gen2

Vorbereitung

Shelly mit dem WLAN verbinden, entweder über die Shelly APP oder per Laptop auf den Offenen AP des Shelly verbinden und dann übers WebUI des Shelly mit dem Heimischen WLAN verbinden. Über die APP geht dies meist etwas einfach und schneller, besonders wenn man mehrere Shelly Geräte hinzufügen möchte. Durch die BT Unterstützung der Gen2 Geräte, klappt dies meist auch deutlich schneller und zuverlässiger als noch bei Gen 1 Geräten. Nachdem der Shelly mit dem WLAN verbunden ist, sollte die Firmware überprüft und gegebenenfalls aktualisiert werden (Stand Anfang 2022 scheint die firmware noch nicht voll ausgereift gewesen zu sein, da dass insbesondere die MQTT-Schnittstelle immer wieder überarbeitet wurde). Bitte KEINE BETA Versionen installieren, wenn nicht dazu aufgefordert wurde. Nach dem, durch das Update ausgelösten, Neustart kurz Prüfen ob die Uhrzeit passt, wenn trotz richtiger Zeitzone die Uhrzeit nicht stimmt hilft ein weiterer Neustart. Nun auf Networks| Internet (leider in APP und WebUI unterschiedlich), hier auf MQTT und die Einstellungen für den verwendeten MQTT Server treffen. Diese Einstellungen werden auch wieder durch Neustart übernommen.

Shelly Plus 1

Zunächst muss man einen Statusupdate des Shelly erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:

defmod MQTT2_shellyplus1_441793a34044 MQTT2_DEVICE shellyplus1_441793a34044
attr MQTT2_shellyplus1_441793a34044 readingList shellyplus1_441793a34044:shellyplus1-441793a34044/online:.* online\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/mqtt:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/events/rpc:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/sys:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/switch_0:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1_441793a34044 room MQTT2_DEVICE

setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 IODev m2s
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 cfg_rev 7
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 connected true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 dst shellyplus1-441793a34044/events
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 fs_free 237568
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 fs_size 458752
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 id 0
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 mac 441793A34044
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 method NotifyStatus
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 online true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 output false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_output false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_source WS_in
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_switch_0_temperature_tC 39.88
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_switch_0_temperature_tF 103.78
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_ts 1646474952.66
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_rssi -57
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_sta_ip 192.168.177.167
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 ram_free 179764
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 ram_size 249456
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 restart_required false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 source WS_in
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 src shellyplus1-441793a34044
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 temperature_tC 39.9
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 temperature_tF 103.9
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 time 11:08
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 unixtime 1646474911
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 uptime 7

Über die set Anweisung unterhalb der Device Übersicht können wir ein attrTemplate wählen; shellyPlus_1 Es erscheint eine kurze Übersicht was im Template enthalten ist, dieses befindet sich noch im Aufbau und wird aktuell von der Community aufgebaut und weiterentwickelt. Mit einem Klick auf „set“ laden wir das Template und übernehmen die Einstellungen für den Shelly Plus 1. Damit ist der Shelly bereit, im Status wird neben dem Namen auch der Onlinestatus des Shellys (grüner | roter Punkt) so wie eine Lampe mit Toggle (on | off) Funktion und die Temperatur des Shellys angezeigt. Darüber hinaus verschwindet die Lampe und wird durch einen klickbaren Hinweis ersetzt, wenn ein Neustart des Shellys nötig ist.

Tipps

Info green.pngSo nimmt man bei Verwendung eines normalen Schalters (eine Stellung EIN eine AUS) gerne den „Flip“ Mode – damit wird der Shelly IMMER umgeschaltet, egal in welche Stellung der Schalter sich bewegt („Kreuzschaltung“). Diese Einstellungen trifft man grundlegend im WebUI des Shelly (oder APP) unter „Channel settings“. Für den „Flip“ müssen wir die Grundeinstellung des „Power on default“ auch ändern (gleiche Seite) - persönlich wähle ich „Restore last“, also: nach Stromausfall wird der letzte Zustand wieder hergestellt; grundsätzlich gehen alle Modi außer „Match input“.

Das aktuelle Template wurde um die Funktion erweitert, den Button Mode umzuschalten. In den meisten Fällen legt man sich auf eine Schaltmethode fest, welche zum Hardware Setup passt.

Manchmal will man aber vielleicht den Hardware Schalter deaktivieren, nennen wir es „Kindersicherung“. Bei Shelly heißt das „detached“. Diese Funktion wurde ins Template als „in_mode“ Übernommen. Mögliche set Befehle sind „flip“, „detached“ „toggle“. Bedingung zur Verwendung ist: „relay power on default“ darf NICHT „Match input“ sein. Sollte Follow statt Flip bevorzugt werden, müsste entsprechende Zeile in der setList von „flip“ auf „follow“ angepasst werden.

Der Befehlt lässt sich mit dem webCmd in_mode auch schnell zugänglich in die Übersicht vom Shelly setzen, so erhält man neben dem Status ein Dropdown mit flip detached und toggle zum schnellen umschalten. Mit webCmdLabel kann man noch einen Namen für das Dropdown setzen.

OpenMQTTGateway

Um verschiedene Systeme wie BLE usw. auf MQTT zu bringen bietet sich OpenMQTTGateway an, z.B. wird für das Auslesen vieler BLE-Seonsoren lediglich ein ESP32-Board ohne Zusatzhardware (ab ca. 5,- Euro in Fernost erhältlich) benötigt, auf das dann eine vorkompilierte firmware geflasht wird (hierfür wird ein USB-seriell-Wandler benötigt).

Nähere Details sind im Artikel OpenMQTTGateway zu finden.

8-Port-Ethernet Board

In diesem Forenbeitrag bzw. dem betreffenden Thread wurde ein Relais-Board vorgestellt, mit dem 8 Relais über Ethernetkabel verbunden werden, die Kommunikation erfolgt dann über MQTT. Über die verwendete Software ist wenig bekannt, es könnte jedoch sein, dass diese Art der Einbindung auch bei weiteren Boards funktioniert, die einen bestimmten Ethernet-Chipset von TI (DP83848) und eine Cortex M3 MCU verwenden.

Milight-Bridge

Vorbemerkung

Der 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. Allerdings lassen sich manche MiLight-Geräte nicht an die Bridge anlernen, und es werden auch nicht alle Fernbedienungs-Typen voll unterstützt. 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[6]. Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist und die zu steuernden Leuchtmittel mit dem Hub bereits verbunden (gepairt) sind bzw. entsprechende Fernbedienungs-Signale empfangen werden können (bei vorhandenem pairing eines Leuchtmittels an die Fernbedienung). Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.

Einstellungen am MiLight-Hub

Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an. Die Einstellungen für MQTT topic pattern usw. können auf den default-Werten[7] belassen werden, für die seit Mitte 2019 vorhandene Option, eine LWT-Message zu senden (MQTT Client Status Topic), tragen Sie milight/LWT ein und aktivieren Detailed.

FHEM-Devices

Milight: Darstellung in FHEMWEB

Bridge

Wird nun über den Hub oder eine von diesem erkannte Fernbedienung ein vorhandenes Leuchtmittel geschaltet, wird bei eingeschaltetem autocreate ein erstes Device erstellt, die zunächst erstellte Definition sieht typischerweise etwa so aus:

defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325
attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE

Auf dieses Device wird nun das template esp_milight_hub_bridge angewandt.

Einzelne Leuchtmittel

Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:

defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1
attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE

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

Alle weiteren Devices werden genauso erstellt.

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

Weitere Beispiele: Beispiel für ein RGB-CCT-Device:

defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\ 
:brightness:saturation\
:color_temp:hue

Ein Leuchtmittel, mehrere Fernbedienungen

Pairt man mehrere Fernbedienungen mit einem Leuchtmittel, sollten auch alle entsprechenden Fernbedienungscodes in das readingList-Attribut übernommen werden. Dazu übernimmt man am einfachsten die Einträge aus den zusätzlichen MQTT2_DEVICEs. Benötigt man das zusätzliche Device nicht separat, um z.B. eine getrennte Gruppenschaltung zu realisieren, kann man dieses löschen. Beispiel-readingList für ein Device, das auf zwei Fernbedienungscodes und zwei Gruppen "hört":

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

Fernbedienung als Input-Device nutzen

In diesem Thread ist dargestellt, wie man eine Fernbedingung des Typs FUT089 dazu verwenden kann, einen MPD oder Rollladenaktoren zu steuern, oder diese Fernbedienung für HUEDevice-Leuchtmittel zu nutzen. Um hier nur Differenz-Meldungen direkt an die betreffende myUtils-Funktion zu übergeben und doppelte Events zu verhindern, sollte hier die readingList so angepasst werden, dass nur Messages aus dem "updates"-Zweig ausgewertet werden:

defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
attr MiLight_RC1_0 readingList milight/states/0xABCD/fut089/[0-8]:.* {}
milight/updates/0xABCD/fut089/0:.* { FHEM::attrT_MiLight_Utils::MPDcontrol('myMPD',$EVENT, 'Yamaha_Main') }\
milight/updates/0x5D47/fut089/1:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_links',$EVENT) }\
milight/updates/0x5D47/fut089/2:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_rechts',$EVENT) }\
milight/updates/0x5D47/fut089/3:.* { FHEM::attrT_MiLight_Utils::four_Lights_matrix($EVENT, 'Licht_WoZi_Vorn_Aussen', 'Licht_WoZi_Vorn_Mitte', 'Licht_WoZi_Hinten_Aussen', 'Licht_WoZi_Hinten_Mitte') }\
milight/updates/0x5D47/fut089/4:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Jalousie_WZ',$EVENT) }\
milight/updates/0x5D47/fut089/5:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSO',$EVENT) }\
milight/updates/0x5D47/fut089/6:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSW',$EVENT) }\
milight/updates/0x5D47/fut089/7:.* {}\
milight/updates/0x5D47/fut089/8:.* {}
attr MiLight_RC_WZ stateFormat CommandSet


eBus

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

Vorbereitung und Definition am eBus

Vorausgesetzt wird ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel EBUS beschrieben. In der Konfiguration des Dämons ( /etc/default/ebusd ) ist die Kommunikation über MQTT zu aktivieren und die Topic-Struktur festzulegen, z.B. ebusd/%circuit/%name.

--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Info blue.png
Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ebusd verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ebus... zu beginnen!


Vorbereitung und Definition in FHEM

Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem vor den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der readingList enthalten, die vom ebus stammen. Da wir die readingList anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen zumindest sämtliche readingList-Attribute entsprechend bereinigt oder gelöscht werden; in der Regel ist es einfacher, diese Geräte nach dem Deaktivieren des autocreate am IO zu löschen.

Emblem-question-yellow.svgSollten Sie MQTT2_CLIENT als IO nutzen, sollte für das weitere Vorgehen eine Kopie des MQTT2-"Sammeldevices" genutzt werden, und dessen CID auf ebusd geändert werden. Nach Anwendung des ebusd-splitter-templates müssen dann alle den ebus betreffenden Einträge aus der readingList des "Sammeldevices" gelöscht werden oder diese ganz gelöscht.

Ist der ebus-Dämon lauffähig und für MQTT konfiguriert, sendet dieser regelmäßige Messages.

Sind die Vorbereitungen abgeschlossen, aktivieren wir autocreate wieder, allerdings wählen wir als autocreate-Methode complex aus, da der eBus-Dämon teilweise[8] eine weiter verschachtelte JSON-Struktur zum Versenden der Informationen verwendet als üblich. Danach wird wie bei den anderen o.g. Geräten automatisch ein neues MQTT2_DEVICE angelegt[9]

"ebus-Bridge"

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

Das attrTemplate läd eine weitere attrTemplate-file und 99_myUtils-Code vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung.

"ebusd_bai" und weitere Geräte

Info blue.png
Der eBus-Dämon sendet nicht alle Informationen zu allen am eBus angeschlossenen Geräte automatisch. Diese müssen teilweise erst aktiv angefragt werden. Wie das im einzelnen erfolgen kann, ist dem o.g. Detailartikel zu entnehmen.


Funktioniert die Kommunikation zwischen dem eBus-Dämon und FHEM, sollte nach einigen Minuten zumindest ein weiteres Gerät namens MQTT2_ebus_bai angelegt worden sein.

Sonos2Mqtt

Aus einem Versuch heraus ist ein kleines Projekt geworden: Die Sonos Umgebung mit Hilfe von sonos2mqtt als generisches MQTT2_DEVICE komfortabel in FHEM einzubinden.

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

Setup im System

Für dies Funktion wird der nodejs Server sonos2mqtt benötigt. Entweder installiert man den lokal, irgendwo im Netzwerk oder nutzt den Docker Container.

Der nodejs Server sonos2mqtt kann aus Sicht von FHEM irgendwo im Netzwerk stehen - aber er muss im gleichen Netzwerk wie die Sonosplayer stehen. Das UPNP Sonosnetzwerk funktioniert nicht über Netzwerksegmente hinweg.

Eine Beschreibung aller Startparameter für sonos2mqtt findet man in der offiziellen Doku.

Erreicht der nodejs Server sonos2mqtt den MQTT Server nicht über - default: localhost, Port 1883, keine Anmeldung" - muss der Parameter --mqtt gesetzt werden!

Beispiele:

--mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800 # alles gesetzt
--mqtt mqtt://192.168.0.3:1800 # IP Adresse und Port gesetzt, keine Anmeldung am MQTT Server
--mqtt mqtt://192.168.0.3 # IP Adresse gesetzt, Port ist Standard 1883

Erfolgt der Start mit pm2, werden die Parameter mit einem zusätzlichen doppelten Bindestrich (--) hinter dem nodejs Modul übergeben.

Beispiel:

pm2 start sonos2mqtt -- --mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800

Lokales Setup

Voraussetzung: nodejs und pm2 ist installiert und für alle Benutzer verfügbar.

sudo npm install -g sonos2mqtt

Je nach Entwicklungsstand sind auch Betaversionen verfügbar. Für aktuelle Betaversionen wird dieser Zusatz beim Setup verwendet. -> sonosmqtt@3.1.0-beta.1

Wird der sonos2mqtt Server auf einer anderen Maschine eingerichtet, ist der Start entsprechend diesem Absatz Autostart von Sonos2mqtt im System mit pm2 einzurichten.

Setup in FHEM

Man definiert lediglich ein Bridge Device, der Rest wird automatisch erledigt.

Voraussetzung:

  • autocreate im System ist aktiv.
  • Der verwendete MQTT2_SERVER steht auf autocreate simple (default/Standard).
  • Templates aktuell - FHEM uptodate oder bei Bedarf in der FHEM Kommandozeile aktualisieren:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }

Bei der Anwendung des Templates für die Bridge wird das Attribut devicetopic ausgelesen oder auf default sonos gesetzt!

Wird ein anderer Devicetopic verwendet, muss der bei der Anlage der Bridge gesetzt werden!

Diese Zeilen einzeln in der FHEM Kommandozeile oder als Block in der Raw Definition.

define SonosBridge MQTT2_DEVICE
attr SonosBridge room MQTT2_DEVICE
set SonosBridge attrTemplate sonos2mqtt_bridge_comfort

Das Template sonos2mqtt_bridge_comfort:

  • setzt das Template sonos2mqtt_bridge auf das Device,
  • lädt die Datei 99_sonos2mqttUtils.pm aus dem contrib Ordner nach,
  • definiert ein notify, dies erledigt im weiteren Betrieb die automatische Konfiguration der automatisch erzeugten MQTT2_DEVICEs.
    • mit dem Template sonos2mqtt_speaker (das Template kann auch manuell auf vorhandene Player angewendet werden, die automatische Erzeugung der Player wird aber empfohlen)
    • Ermittelt Detailinformation des jeweiligen Players (vor allem IP Adresse und Modelnumber)
    • Lädt die Sonosgeräte Icons von den UPNP Devices herunter
    • erweitert das setList input Kommando um den TV Eingang (HDMI, spdif) bzw. Line_IN Eingang falls vorhanden (Modelnumber)
  • Die Player werden automatisch einzeln erzeugt wenn sie mqtt Nachrichten senden (Play/Stop) oder (alle sofort) wenn der sonos2mqtt Server gestartet wird.

Wozu dient die Bridge?

Sie stellt ein paar wesentliche Funktionen zu Verfügung

  1. Auffangen von nicht benötigten MQTT Nachrichten.
  2. Erzeugung/Weiterleitung von Nachrichten für die einzelnen Player - damit auch die Erzeugung von separaten Playern nach dem Schema MQTT2_RINCON12345678901234567.
  3. Statusanzeige sonos2mqtt als Reading connected (0 offline, 1 connected, 2 Player connected).

Sie kann zusätzlich als zentrales Device verwendet werden, um die Sonos Umgebung abzubilden, z.B. Readings für Favoriten u.ä.

Start sonos2mqtt lokal

Der Start / Stop des sonos2mqtt Servers innerhalb von FHEM ist nur lokal simpel möglich. Ist der Server irgendwo im Netzwerk oder im Docker Container, muss man andere Möglichkeiten finden. Der Neustart aus FHEM ist zwar praktisch, aber nicht erforderlich.

Wird eine existierenden Sonos Landschaft inhaltlich verändert (Player dazu/weg), muss der Server neu gestartet werden. Werden Player temporär abgeschaltet, merkt das der Server nach einer Zeit selbst, oder man forciert dies mit einem CheckSubscription an der Bridge.

Soll das Modul sonos2mqtt mit seinen default Einstellungen gestartet werden, genügt dieser kurze Befehl (in der FHEM Kommandozeile):

"pm2 start sonos2mqtt"

Tipp: Verwendet man anstatt "Befehl" den Syntax {qx(Befehl)} in der FHEM Kommandozeile, wirkt der Befehl zwar blockierend aber die Ausgabe erfolgt im Browser und nicht im Logfile. Mit dem Parameter -s erfolgt keine Ausgabe.

Autostart von sonos2mqtt mit FHEM

Der Code startet sowohl das sonso2mqtt Modul sofort und implementiert ein notify für den zukünftigen automatischen Start beim Start von FHEM.

define n_pm2_sonos notify global:INITIALIZED|n_pm2_sonos:start "pm2 -s start sonos2mqtt"
trigger n_pm2_sonos start

Autostart von sonos2mqtt im System mit pm2 (Alternative)

Der obige Code startet das sonos2mqtt nodejs Modul mit pm2 beim Start von FHEM. Sollte das nicht funktionieren oder nicht ins gesamte Konzept passen (weil z.B. mehrere nodejs Module geladen werden) kann der automatische Start direkt im System erfolgen. Zunächst dafür das oben eventuell schon definierte notify löschen!

delete n_pm2_sonos

Der Start des Modul muss nicht mit erhöhten Rechten geschehen! Im Terminal folgendes eingeben (unter dem angemeldeten Benutzer wird sonos2mqtt später immer gestartet):

pm2 start sonos2mqtt
pm2 startup

Der letzte Befehl "redet", d.h. es gibt eine Ausgabe in der Art:

[PM2] To setup the Startup Script, copy/paste the following command:
sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u pi --hp /home/pi

Man tut einfach genau das, was dasteht: die letzte Zeile kopieren und wieder einfügen und ausführen. Danach muss man die Konfiguration von pm2 noch sichern:

pm2 save

Verwendung des Docker Containers

Ergänzend zur Original Doku:

Beim Container findet die Konfiguration der Verbindung zum FHEM in den Environment Variablen statt:

environment:
  - SONOS2MQTT_DEVICE=192.168.56.207 # hier muss einer der Sonos Lautsprecher stehen
  - SONOS2MQTT_MQTT=mqtt://192.168.56.121:1883 # mqtt2_server FHEM, erweiterter Syntax siehe oben
  - SONOS_LISTENER_HOST=192.168.56.121 # Docker host IP

Sonos2mqtt mit mehr Komfort

Im Wiki Artikel Sonos2mqtt geht es weiter.

Owntracks GPS Tracking in FHEM über MQTT - Cloud

Das hier gezeiget Beispiel verwendet eine MQTT Instanz im Internet, die mit einem MQTT2_CLIENT angebunden wird. Da wenig Traffic benötigt wird, genügt z.B. eine kostenfreie Instanz z.B. bei myqtthub (Stand. Dezember 2020)

Alternativ kann man einen MQTT2_SERVER auch direkt verfügbar machen, wenn man sich sicher ist was man da tut! Siehe diesen Forenbeitrag. Das Bridge Device wird dabei genau so benötigt, nur der IODev ist dann der MQTT2_SERVER.

owntracks auf dem Smartphone konfigurieren

Menü / Einstellung / Verbindung

Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):

  • Modus -> MQTT
  • Hostname ->
    • Hostnamen: host.cloud.com
    • Port: 8883
    • ClientID: ID vom Provider
    • WebSockets (nicht nutzen)
  • Identifikation ->
    • Benutzername: user-name
    • Passwort: user-password
    • GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
    • TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte)
  • Sicherheit ->
    • TLS aktivieren

Definition in FHEM

Der MQTT2_CLIENT wird so eingerichtet, man braucht eine andere ClientID als auf dem Smartphone! Stimmt alles sollte das Gerät sofort open anzeigen.

MQTT2_CLIENT einrichten, autocreate simpel
define mqtt2Cloud MQTT2_CLIENT host.cloud.com:8883
attr mqtt2Cloud SSL 1
attr mqtt2Cloud autocreate simple
attr mqtt2Cloud clientId fhem1
attr mqtt2Cloud room MQTT2_IO
attr mqtt2Cloud username user-name
set mqtt2Cloud password user-password

Für die automatische Erzeugung der Trackergeräte in FHEM richtig man zuerst ein Bridge Device ein:

define MQTT2_Cloud_bridge MQTT2_DEVICE
attr MQTT2_Cloud_bridge IODev mqtt2Cloud
attr MQTT2_Cloud_bridge autocreate 1
attr MQTT2_Cloud_bridge room MQTT2_DEVICE

Dies wird entweder mit dem Template allgemein konfiguriert

set MQTT2_Cloud_bridge attrTemplate MQTT2_CLIENT_general_bridge

oder manuell nur für owntracks eingerichtet

attr MQTT2_Cloud_bridge bridgeRegexp owntracks/[^/]+/([^/:]+).* "owntracks_$1"

MQTT2 Geräte für owntracks werden jetzt automatisch mit dem Namen MQTT2_owntracks_<GeräteID> erzeugt. Diese werden einfach mit dem Template owntracks_device fertig konfiguriert. Bei einem IOS Gerät kann man danach noch das Template owntracks_device_IOS als Erweiterung anwenden.

Anwesenheitserkennung

Die Anwesenheit kann im owntracks Device direkt für die selbst definierten Plätze abgelesen werden: entweder steht im reading place der jeweilige Ort oder away. Um hier noch eine gewisse Einheitlichkeit in der Verwendung zu bekommen kann man ein PRESENCE Device verwenden:

define OT_Mi6 PRESENCE event MQTT2_owntracks_mi6:place:.away MQTT2_owntracks_mi6:place:.<Home>

Im Move Modus erfolgt die Erkennung sehr schnell und damit einige Sekunden eher als eine BT Erkennung im Haus - der Akkuverbrauch steigt enorm. Im Significant Modus kann es schon mal ein paar Minuten dauern - ein relevanter Akku Verbrauch ist nicht erkennbar.

Owntracks GPS Tracking in FHEM direkt an den eigenen Fhem-Server

Dieses Beispiel beschreibt den direkten MQTT2 Zugang wobei das IODev dann der MQTT2_SERVER ist. Hierzu bitte diesen Forenbeitrag lesen.

SSL - Zertifikate fuer fhem erstellen.

Zunächst erstellen wir fuer den MQTT - Server CA zertifizierte SSL Zertifikate. Diese sind identisch mit den SSL - Zertifikaten, welche man evtl. schon fuer den SSL - Zugang seines FHEMWEB - Device erstellt hat.

Hat man den FHEMWEB schon mit eiem SSL Zertifikat (https://) abgesichert, muss man daraus nur noch den .p12 - Container erstellen.

Hat man den FHEMWEB noch nicht abgesichert (http://), dann wir es höchste Zeit!

Für die Erstellung dieser SSL Zertifikate folgt dem Wiki-Beitrag FHEM mit HTTPS SSL-Zertifikat und eine eigene Zertifizierungsstelle.

Die darin beschriebenen Dateien, das cacert.pem sowie den server.p12 - Container müsst ihr nun an euer Mobiltelefon senden.

Definition in FHEM

Der MQTT2_Server wird wie folgt eingerichtet.

define myMQTT2Server_extern MQTT2_SERVER IPV6:1884 global
attr MQTTBroker_extern SSL 1
attr MQTTBroker_extern autocreate complex
attr MQTTBroker_extern event-on-change-reading .*
attr MQTTBroker_extern group MQTT2
attr MQTTBroker_extern icon mqtt_broker
attr MQTTBroker_extern room MQTT2

Der MQTT2_Server wird zusätzlich über "allowed" abgesichert:

define allowed_MQTT2Server_extern allowed
attr allowed_MQTT2Server_extern DbLogExclude .*
attr allowed_MQTT2Server_extern group MQTT2
attr allowed_MQTT2Server_extern room  MQTT2
attr allowed_MQTT2Server_extern validFor myMQTT2Server_extern

Jetzt vergeben wir noch einen Usernamen und ein Passwort für dieses "allowed" - Device

set allowed_MQTT2Server_extern basicAuth MyMQTT2Username MyMQTT2Password

Denkt bitte daran einen eigenen Usernamen und ein eigenes langes, kompliziertes Passwort zu verwenden. Vorsicht bei Sonderzeichen!

Port-Freigaben im Router

An dieser Stelle müssen wir den Port 1884 in den Internet - Freigaben eures Routers freigeben.

Bei der Fritz!Box wird dies beispielsweise unter Internet -> Freigaben -> Port-Freigaben gemacht. Die Details hierzu entnehmt bitte der Bedienungsanleitung eures Routers.

Wichtig ist dabei, das ihr das Protokol "TCP" verwendet und der Port 1884 extern nach Port 1884 intern an die IP - Adresse des jeweiligen fhem-Servers übermittelt wird.

owntracks auf dem Smartphone konfigurieren

Menü / Einstellung / Verbindung

Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):

  • Modus -> MQTT
  • Hostname ->
    • Hostnamen: subdomain.dyndns.com
    • Port: 1884
    • ClientID: Vorname_Nachname
    • WebSockets (nicht nutzen)
  • Identifikation ->
    • Benutzername: MyMQTT2Username
    • Passwort: MyMQTT2Password
    • GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
    • TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte. Empfehlung: Die Initialien verwenden.)
  • Sicherheit ->
    • TLS aktivieren
    • CA-Zertifikat: cacert.pem
    • Client-Zertifikat: server.p12
    • Passwort fuer Client-Zertifikat: Passwort für den server.p12 - Container

Wenn alles richtig gemacht wurde, dann erstellt das myMQTT2Server_extern - Device automatisch ein neues Device für jede owntracks-App, die sich an dem myMQTT2Server_extern - Device meldet.

Übrigens: Will man seine gesamte Familie ebenfalls über owntracks tracken, so muss man in den jeweiligen APPs nur die Werte für ClientID, GeräteID und TrackerID individuell gestalten.

An den fhem- Einstellungen müssen keine weiteren Änderungen vorgenommen werden.

Allgemeine Hinweise

MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen

Nutzt man das rawEvents-Attribut am MQTT2-IO[10], 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 attr mqtt2_server verbose 5 auch alles ins FHEM-Log schreiben lassen.

autocreate funktioniert anscheinend nicht?

In der Regel wird bei neu eingehenden MQTT-Messages über autocreate ein neues Device erstellt, wenn Nachrichten von einem bisher unbekannten Gerät kommen. Geschieht dies nicht, sollten folgende Punkte geprüft werden:

  1. (nur bei MQTT2_SERVER:) Der Client muss eine ClientID angeben, diese darf nicht den defaults von mosquito_sub entsprechen.
  2. Ein allgemeines autocreate-Device (TYPE=autocreate) muss vorhanden und aktiv sein.
  3. autocreate am IO muss eingeschaltet sein, was für MQTT2_SERVER bedeutet, dass es nicht auf "0" stehen darf (hier ist dann simple die aktive Voreinstellung), für MQTT2_CLIENT sollte ebenfalls simple verwendet werden; dies muss hier allerdings explizit gesetzt werden.

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

Das autocreate am Device schließlich bestimmt, ob die readingsList erweitert werden darf, wenn Informationen über bisher nicht über die readingList abgedeckte Topics empfangen werden und vom MQTT2-IO als zu diesem Device/ClientID gehörend identifiziert wurden.

attrTemplate

Info green.pngDie per attrTemplate jeweils erzeugten Konfigurationen sind Einrichtungsbeispiele, die v.a. eine in sich konsistenze Zusammenstellung der verschiedenen Attribute enthalten. Es steht jedem User frei, diese Ausgangsbasis dann nach seinem Belieben zu ändern. Spätere Änderungen des verwendeten attrTemplate wirken sich nicht automatisch auf die durch frühere Versionen oder den User nachkonfigurierte Geräte aus! Da es vorkommen kann, dass sich die per MQTT übermittelten Daten und Topics ändern, wenn z.B. eine firmware aktualisiert wurden, kann dies Anpassungen am jeweiligen Template erforderlich machen. Grundsätzlich sollen die per attrTemplate für MQTT2_DEVICE verfügbaren attrTemplate jeweils für die aktuellste verfügbare stabile firmware-Version passen.

Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion attrTemplate genutzt werden. Die Anwendung für MQTT2_DEVICE ist hier beschrieben.


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


attrTemplate: Es werden nicht alle templates angezeigt

Siehe Beitrag AttrTemplate: Warum finde ich das Template xyz nicht.

attrTemplate und Sprachsteuerung

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

bridgeRegexp

Logische Verortung der bridgeRegexp-Angaben
Emblem-question-yellow.svgBeachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.

Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch einem MQTT2_DEVICE zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. In dem nebenstehenden Schaubild wären dies die Geräte A bis D. Das Attribut bridgeRegexp kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem anderen Device (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als newClientId hinterlegte Angabe verwendet. In nebenstehendem Schaubild ist dies exemplarisch für die Gerätegruppe D mit dem bridge-Device D und dessen Satelliten D1 bis D4 dargestellt. Dementsprechend sind in den hier aufgeführten Beispielen bridgeRegexp-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren, wie z.B. für über hier dargestellten zigbee2mqtt oder zigbee2tasmota. Ein Sonderfall hierbei ist das template MQTT2_CLIENT_general_bridge zur Verwendung mit dem MQTT2_CLIENT, denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem mosquitto-Server und würden sonst alle ein und demselben MQTT2_DEVICE zugewiesen.

Ständig neue Devices?

MQTT2_SERVER kann zwischen verschiedenen Geräten auch anhand der ClientID unterscheiden. Für jedes neu erkannte Gerät wird auch ein eigenes MQTT2_DEVICE angelegt. Abhilfemaßnahmen:

Vergabe einer ClientID

Die meisten MQTT-fähigen Geräte enthalten Optionen zur Vergabe einer eindeutigen ClientID (siehe das Beispiel des zigbee2mqtt-Dienstes oben). Wird keine ClientID vergeben, verwenden manche Clients für jede Verbindung wieder neue ID's. Es wird empfohlen, möglichst von diesen Einstelloptionen Gebrauch zu machen.

Löschen der ClientID aus der readingList usw.

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

Wildcards in readingList und setList

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

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

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

Die JSON-Daten sollen ausnahmsweise nicht ausgepackt werden

In manchen Fällen ist das automatische Auspacken der JSON-Payload nicht erwünscht. In diesen Fällen kann man einfach den gewünschten Reading-Namen in die readingList eintragen, statt der Anweisung, den JSON an json2NameValue() zu übergeben. Aus

attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/waypoints:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/event:.* { json2nameValue($EVENT) }

wird dann:

attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* json_mi6\
owntracks/clouduser/mi6/waypoints:.* json_waypoints\
owntracks/clouduser/mi6/event:.* json_event

Erforderlichenfalls kann man die Einträge auch doppelt erstellen, um sowohl den JSON wie auch die ausgepackten Readings zu erhalten.

Die JSON-Daten vor dem auspacken manipulieren

Aus diversen Gründen kann es zweckmäßig sein, einen bestimmten Wert der JSON-Payload zu ignorieren. Z.B. sendet ein Client statt eines Messwertes die Info "bad". Dieser Fehlerwert soll aus der JSON-Payload "ausgefiltert" werden:

attr DEVICE readingList <your topic>:.* { my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { 'bad' ne $rets->{$_} } keys %{$rets};; return \%cleaned }

Oder auch einen Wert umzubenennen wenn die JSON-Payload nur ein Objekt beinhaltet:

attr DEVICE readingList <your topic>:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}

Unnötige Konfigurationsinformationen verwerfen

Siehe Einleitung und den ignoreRegexp-Abschnitt zu MQTT2_CLIENT.

Weiterführende Themen

Verbinden mehrerer FHEM-Instanzen über MQTT

Wie im Hauptartikel zu MQTT erläutert, gibt es mehrere Varianten, wie man mit Hilfe von FHEM aus Events an beliebigen Geräten MQTT-Messages erzeugen kann. So kann man z.B. Messdaten eines Systems über ein notify iVm. einer einfachen publish-Anweisung an ein zweites FHEM schicken, das diese Daten dann z.B. mit Hilfe der MQTT2-Module auswerten kann. Damit dabei Nachrichten unterschiedlicher Quellen auch als getrennte Readings bzw. ggf. auch gesonderten MQTT2_DEVICE-Instanzen zugeordnet werden, sollte man entsprechende Topic-Strukturen wählen, die dann auch mit Hilfe einer geeigneten bridgeRegexp automatisiert ausgewertet werden kann, siehe z.B. dieser Forumsthread:

attr MQTT2_myMqttServer bridgeRegexp \
  SmartHome/MqttGenericBridge2/([A-Za-z0-9]*)/.*:.* "mgb2_$1"

Dabei werden die betreffenden Informationen der entfernten FHEM-Instanz alle nach dem Schema SmartHome/MqttGenericBridge2/<Device-Name>/<Reading-Name> versendet.

Umstellung von MQTT_DEVICE (und Derivaten wie XiaomiMQTTDevice) zu MQTT2_DEVICE

Wer beabsichtigt, von der Implementierung MQTT+MQTT_DEVICE zu MQTT2-IO und MQTT2_DEVICE zu wechseln, sollte einige Punkte beachten. Viele diesbezügliche Fragen sind vor allem in diesem Foren-Thread

näher erläutert.

Links

Hinweise

  1. Allerdings können die Konfigurationen in der Regel recht einfach auf die bisherige MQTT-Implementierung übertragen werden
  2. Beachten Sie bei mehrkanaligen Geräten, dass jeweils nur ein Hauptkanal mittels setExtensions verwaltet werden kann! U.a. aus diesen Grund ist es meist sinnvoller, die split-Varianten der attrTemplate-Einrichtung zu verwenden.
  3. Auch MQTT_DEVICE unterstützt SetExtensions, allerdings muss dies dort per Attribut eingeschaltet werden
  4. Dabei wird vorausgesetzt, dass ein allgemeines autocreate-Device (TYPE=autocreate) ebenfalls aktiv ist.
  5. MQTT2_SERVER verwendet als default-Einstellung für autocreate simple, ohne dass ein entsprechendes Attribut gesetzt werden müsste. Die Einstellung complex empfiehlt sich in der Regel nicht; diese ist jedoch dann zu empfehlen, wenn das Device entweder verschachtelte JSON-Array-Strukturen liefert oder bestimmte Readings nicht gefüllt werden sollen.
  6. Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.
  7. Diese sind:
    milight/:device_id/:device_type/:group_id für "topic pattern"
    milight/updates/:hex_device_id/:device_type/:group_id für "update topic pattern"
    milight/states/:hex_device_id/:device_type/:group_id für "state topic pattern". Der Autor hat derzeit folgende Infotypen zum Senden markiert: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (enthält eventuell zu viele Angaben. Bei einem Eventhandler muss man uU. darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).
  8. Dies betrifft vorrangig die Statusmeldungen
  9. Bei Verwendung des MQTT2_CLIENT wird dann die readingList am bereits definierten MQTT2_DEVICE aus der Kopie des "Sammeldevice" automatisch wieder erstellt bzw. gefüllt.
  10. z.B. attr MQTT2_FHEM_Server rawEvents .*, der regex-Filter kann wie üblich angepasst werden