MQTT2-Module - Praxisbeispiele: Unterschied zwischen den Versionen
(Hinweis zu autocreate wg. irreführendem Anker in cref geändert.) |
(Hinweise aus Forum #97303 #msg907545 ergänzt) |
||
Zeile 48: | Zeile 48: | ||
Beispiele: | Beispiele: | ||
==== IKEA-Tradfri-Birne ==== | ==== IKEA-Tradfri-Birne ==== | ||
{{Randnotiz|RNTyp=g|RNText=Wie wähle ich nun das richtige Template für mein Leuchtmittel aus? | |||
-> Es wird nicht zwischen einer Birne/Bulb/Lampe und einem LED-Controller unterschieden sondern anhand der möglichen Lichtdarstellung des Gerätes: | |||
light_dimmer: | |||
Das anzusteuernde Geräte besitzt ausschließlich eine feste Lichtfarbe welche gedimmt werden kann. | |||
light_cct: | |||
Das anzusteuernde Gerät besitzt eine warmweiße sowie kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann. | |||
light_rgb_xxx: | |||
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und kann gedimmt werden. | |||
light_rgbw_xxx: | |||
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße ODER kaltweiße Lichtfarbe welche eingestellt sowie gedimmt werden kann. | |||
light_rgbcct_xxx: | |||
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße UND kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann. | |||
xxx: | |||
hex: Farbänderung mit hex | |||
rgb: Farbänderung mit r g b | |||
xy: Farbänderung mit x sowie y | |||
hue: Farbänderung mit hue und saturation | |||
Warum diese Einteilung in "hex", "rgb", "xy" sowie "hue"? | |||
-> Zigbee2MQTT unterstützt das Übermitteln aller dieser Werte, allerdings unterscheiden sich hier die Geräte. Manche "verstehen" nur z.B. Hex-Farbänderungen, andere halt nur eine Farbänderung mit rgb-Werten. | |||
-> Aus diesem Grund muss an dieser Stelle probiert werden mit welchem der 4 Templates sich die Farbveränderung des Gerätes steuern lässt! | |||
HINWEIS: Templates für Farbänderungen mithilfe von XY- sowie HUE-Werten wurden bis heute nicht angelegt! | |||
}} | |||
Beispiel eines dimmbaren Tradfri-Leuchtmittels | Beispiel eines dimmbaren Tradfri-Leuchtmittels | ||
defmod IKEA_Bulb2 MQTT2_DEVICE | defmod IKEA_Bulb2 MQTT2_DEVICE |
Version vom 17. Februar 2019, 16:34 Uhr
Einführung: MQTT bzw. MQTT2 in FHEM
Zur Einbindung von Geräten, welche mit einem MQTT-Server (früher: Broker) kommunizieren können, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser Ü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 oder 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 sowie attrTemplate[2].
![Info blue.png](/w/images/thumb/7/7e/Info_blue.png/40px-Info_blue.png)
![Info blue.png](/w/images/thumb/7/7e/Info_blue.png/40px-Info_blue.png)
Beispiel:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global attr MQTT2_FHEM_Server autocreate 1
zigbee2mqtt
zigbee2mqtt ist ein open-source Projekt, mit dem zigbee-Geräte über MQTT direkt angesprochen werden können, ohne dass hierfür eine Bridge eines Herstellers benötigt wird.
Installation von zigbee2mqtt
Die Installation des zigbee2mqtt-Diensts ist auf der Homepage des Projekts beschrieben. Ergänzend muß in der configuration.yaml eine client_id unter mqtt (z.B. zigbee_pi) vergeben werden[4].
mqtt: client_id: 'zigbee_pi'
Da der Dienst auch später in den Anlernmodus versetzt werden kann, kann man auch gleich permit_join: false
setzen, um das versehentliche Einbinden neuer oder fremder Geräte zu unterbinden.
Define eines MQTT2-Devices als "Bridge"
Dann kann eine Art "Grund-Device" angelegt werden, das für die Ansteuerung des eigentlichen Server-Dienstes genutzt wird, der bereits unmittelbar nach der erfolgreichen Konfiguration von zigbee2mqtt zur Verfügung steht. In der Regel sollte dieses automatisch erstellt werden, wenn der zigbee2mqtt-Dienst (oder der betreffende Rechner) neu gestartet wird (oder FHEM oder dort ein Sensor einen Messwert sendet). Beispiel[5]:
defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/state:.* state\ zigbee_pi:zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, ) }\ zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT, ) }\ zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT, 'log_') } attr MQTT2_zigbee_pi room MQTT2_DEVICE
Für die Funktion einer zigbee2mqtt-Bridge steht ein template bereit, das direkt die passenden Attribute vergibt, um dem zigbee2mqtt-Dienst passende Anweisungen geben zu können und weitere Geräte für die eigentlichen Aktoren und Sensoren anzulegen:
set MQTT2_zigbee_pi attrTemplate L_01_zigbee2mqtt_bridge
Ist dieses angelegt, kann zigbee2mqtt mit set MQTT2_zigbee_pi permit_join true
in den Anlernmodus versetzt werden, anzulernende Geräte müssen anschließend jeweils nach Bedienungsanleitung in den Anlernmodus gebracht werden.
Vereinzeln der eigentlichen Geräte
Über das mit dem template vergebene bridgeRegexp-Attribut
attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
werden anschließend neue MQTT2_DEVICE-Geräte automatisch angelegt, sobald ein bisher unbekanntes Zigbee-Gerät einen neuen Status (z.B. einen Meßwert) meldet. Um zu erfragen, welche Geräte dem zigbee-Deinst bekannt sind, kann via get MQTT2_zigbee_pi devicelist true
eine Liste abgefragt werden, die weitere Informationen zu den bereits angelernten Geräten enthält.
Geräte, die nicht automatisch etwas senden, kann man mit Hilfe des MQTT2_SERVER-Geräts einmalig schalten, damit diese ihren Status bzw. das erfolgreiche Schalten zurückmelden, Beispiel[6]:
set MQTT2_FHEM_Server publish zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON","brightness":60}
Für Gerätetypen, für die bereits templates vorhanden sind, ist es am einfachsten, diese einmalig auf die Geräte anzuwenden. Das Vorgehen entspricht dabei dem oben für die Bridge beschriebenen. Dafür wird immer vorausgesetzt, dass ein neues Device mit autocreate (ggf. über die bridgeRegexp) angelegt wurde[7]
Beispiele:
IKEA-Tradfri-Birne
![Info green.png](/w/images/thumb/0/02/Info_green.png/20px-Info_green.png)
-> Es wird nicht zwischen einer Birne/Bulb/Lampe und einem LED-Controller unterschieden sondern anhand der möglichen Lichtdarstellung des Gerätes:
light_dimmer: Das anzusteuernde Geräte besitzt ausschließlich eine feste Lichtfarbe welche gedimmt werden kann.
light_cct: Das anzusteuernde Gerät besitzt eine warmweiße sowie kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann.
light_rgb_xxx: Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und kann gedimmt werden.
light_rgbw_xxx: Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße ODER kaltweiße Lichtfarbe welche eingestellt sowie gedimmt werden kann.
light_rgbcct_xxx: Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße UND kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann.
xxx: hex: Farbänderung mit hex rgb: Farbänderung mit r g b xy: Farbänderung mit x sowie y hue: Farbänderung mit hue und saturation
Warum diese Einteilung in "hex", "rgb", "xy" sowie "hue"? -> Zigbee2MQTT unterstützt das Übermitteln aller dieser Werte, allerdings unterscheiden sich hier die Geräte. Manche "verstehen" nur z.B. Hex-Farbänderungen, andere halt nur eine Farbänderung mit rgb-Werten. -> Aus diesem Grund muss an dieser Stelle probiert werden mit welchem der 4 Templates sich die Farbveränderung des Gerätes steuern lässt!
HINWEIS: Templates für Farbänderungen mithilfe von XY- sowie HUE-Werten wurden bis heute nicht angelegt!Beispiel eines dimmbaren Tradfri-Leuchtmittels
defmod IKEA_Bulb2 MQTT2_DEVICE attr IKEA_Bulb2 IODev MQTT2_FHEM_Server attr IKEA_Bulb2 icon light_control attr IKEA_Bulb2 devStateIcon {zigbee2mqtt_devStateIcon255($name)} attr IKEA_Bulb2 readingList zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT) } attr IKEA_Bulb2 setList on:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON"}\ off:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"OFF"}\ brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"on","$EVTPART0":"$EVTPART1"} attr IKEA_Bulb2 webCmd toggle:on:off:brightness attr IKEA_Bulb2 model L_02a_zigbee2mqtt_bulb
Kann man auch die Farbtemperatur einstellen, wird die setList wie folgt erweitert oder das entsprechende template[8] anwendet:
... color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"$EVTPART0":"$EVTPART1"}
Die templates sind dabei in der Regel so gestaltet, dass eventuell mehr Optionen in FHEMWEB erscheinen, als tatsächlich vorhanden oder erwünscht sind. Da sich obige einfarbige dimmbare Lampe durch Klicken auf das devStateIcon schalten läßt, ist für die vollständige Ansteuerung bereits dieses webCmd hinreichend:
attr IKEA_Bulb2 webCmd brightness
Temp/Hum. Sensor
tbd
Motion Sensor
Als MQTT-Server wird hier mosquitto verwendet, als IO-Device wird daher ein MQTT2_CLIENT-Gerät definiert:
defmod mqtt2_client MQTT2_CLIENT 192.168.2.4:1883 attr mqtt2_client autocreate 1 attr mqtt2_client rawEvents zigbee2mqtt/GB_Bewegungsmelder:.* attr mqtt2_client room test attr mqtt2_client subscriptions #
Das eigentliche Device sieht dann so aus:
defmod GB_Bewegungsmelder_MQTT2 MQTT2_DEVICE zigbee_158d0001f9d030 attr GB_Bewegungsmelder_MQTT2 IODev mqtt2_client attr GB_Bewegungsmelder_MQTT2 devStateIcon motion:motion_detector@red off:motion_detector@green no_motion:motion_detector@green attr GB_Bewegungsmelder_MQTT2 icon motion_detector@blue attr GB_Bewegungsmelder_MQTT2 readingList mqtt2client:zigbee2mqtt/GB_Bewegungsmelder:.* { json2nameValue($EVENT) } attr GB_Bewegungsmelder_MQTT2 room MQTT2_DEVICE attr GB_Bewegungsmelder_MQTT2 stateFormat {\ if(ReadingsVal("$name","occupancy",0) eq "true") {\ sprintf("motion");;\ } else {\ sprintf("no_motion");; \ }\ }
Tasmota
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.
![X mark.svg](/w/images/thumb/a/a2/X_mark.svg/20px-X_mark.svg.png)
MQTT2_DEVICE
Dieses sollte bei aktiviertem autocreate am MQTT2_SERVER-Device automatisch angelegt werden, sobald das betreffende Gerät eingesteckt oder neu gestartet oder an einem evtl. vorhandenen Taster geschalten wird. Hier wurden Tasmota version(en) 6.1.1 und 6.2.1 getestet, Hardware war Sonoff Touch und S20.
Manuelle Anpassungen
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD attr MQTT2_DVES_9B01BD IODev m2server attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\ DVES_9B01BD:tele/sonoffkitchen/LWT:.* LWT\ DVES_9B01BD:cmnd/sonoffkitchen/POWER:.* POWER\ DVES_9B01BD:tele/sonoffkitchen/UPTIME:.* { json2nameValue($EVENT) }\ DVES_9B01BD:tele/sonoffkitchen/SENSOR:.* { json2nameValue($EVENT) }\ DVES_9B01BD:tele/sonoffkitchen/INFO1:.* { json2nameValue($EVENT) }\ DVES_9B01BD:tele/sonoffkitchen/INFO2:.* { json2nameValue($EVENT) }\ DVES_9B01BD:tele/sonoffkitchen/INFO3:.* { json2nameValue($EVENT) }\ DVES_9B01BD:stat/sonoffkitchen/RESULT:.* { json2nameValue($EVENT) }\ DVES_9B01BD:stat/sonoffkitchen/STATE:.* { json2nameValue($EVENT) } attr MQTT2_DVES_9B01BD room MQTT2_DEVICE attr MQTT2_DVES_9B01BD setList on cmnd/sonoff/POWER on\ off cmnd/sonoff/POWER off\ reboot cmnd/sonoff/Restart 1 attr MQTT2_DVES_9B01BD webCmd on:off:reboot
attrTemplate
Für gängige Tasmota-Geräte stehen templates bereit, mit denen sich diese schnell konfigurieren lassen. Beachten Sie dazu den Abschnitt attrTemplate in MQTT2_DEVICE. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.
Shelly
Vorbemerkung
Auch für Shelly-Geräte steht eine Auswahl an templates bereit. Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.
Shelly1
Shellybulb
Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
Internals: CFGFN CID shellybulb_3CC533 DEF shellybulb_3CC533 DEVICETOPIC MQTT2_shellybulb_3CC533 IODev MQTT2_FHEM_Server NAME MQTT2_shellybulb_3CC533 NR 246 STATE ??? TYPE MQTT2_DEVICE READINGS: 2018-12-12 19:28:08 status_blue 0 2018-12-12 19:28:08 status_brightness 61 2018-12-12 19:28:08 status_effect 0 2018-12-12 19:28:08 status_gain 26 2018-12-12 19:28:08 status_green 0 2018-12-12 19:28:08 status_ison true 2018-12-12 19:28:08 status_mode color 2018-12-12 19:28:08 status_red 255 2018-12-12 19:28:08 status_temp 3250 2018-12-12 19:28:08 status_white 0 Attributes: IODev MQTT2_FHEM_Server readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') } room MQTT2_DEVICE
Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.
Milight-Bridge
Vorbemerkung
Der esp8266_milight_hub ist ein open source- Projekt, mit dem auf Basis von openmili eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel. Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway[9]. Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist. Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.
Einstellungen am MiLight-Hub
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an.
FHEM-Devices
Bridge
Wird nun über den Hub oder eine von diesem erkannte Fernbedienung ein vorhandenes Leuchtmittel geschaltet, wird bei eingeschaltetem autocreate ein erstes Device erstellt, die zunächst erstellte Definition sieht typischerweise etwa so aus:
defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325 attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) } attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE
Auf dieses Device wird nun das template X_01_esp_milight_hub_bridge angewandt.
Einzelne Leuchtmittel
Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:
defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1 attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) } attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE
Auf dieses wird nun eines der Bulb-templates angewendet. Wählt man das template X_01_esp_milight_hub_rgbw_bulb, wird eine einfache Variante erstellt, die neben einem toggelnden Icon nur Regler für Helligkeit, die Farbe und zwei Schaltflächen für den Weiß- und Nachtmodus enthält. Wer mehr oder andere Steuerelemente erhalten möchte, verwendet ein anderes template. Nicht benötigte Elemente kann man dabei einfach aus der Definition löschen.
Alle weiteren Devices werden genauso erstellt.
Um ein Device zu erhalten, mit dem sich alle Kanäle gleichzeitig steuern lassen, kann das template X_01a_esp_milight_hub_make_rgbw_group verwendet werden. Dieses verändert nicht das aktuelle Device, sondern erstellt eine Kopie, die dann modifiziert wird. Diese Kopie ist unter dem Namen milight_<RemoteID>_0 im selben Raum zu finden wie das Ausgangsgerät und kann ebenfalls an die eigenen Wünsche angepaßt werden.
Weitere Beispiele: Beispiel für ein RGB-CCT-Device:
defmod Licht_Wz_all MQTT2_DEVICE attr Licht_Wz_all IODev MQTT2_Broker attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/ attr Licht_Wz_all group Licht attr Licht_Wz_all icon light_control attr Licht_Wz_all readingList milight_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\ milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\ milight_hub_10693013:milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\ attr Licht_Wz_all room Wohnzimmer attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\ off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\ level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\ commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"} attr Licht_Wz_all sortby 1 attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue attr Licht_Wz_all webCmdLabel command\ :brightness:saturation\ :color_temp:hue
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.
attrTemplate
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion attrTemplate genutzt werden. Die Anwendung ist hier beschrieben.
Links
- Thread, aus dem diese Anleitung ursprünglich entstanden ist
- Thread zum Tasmota-Device
- Neue templates einreichen
- Fragen, Wünsche und Kritik zu mqtt2.template
Hinweise
- ↑ Allerdings können die Konfigurationen in der Regel recht einfach auf die bisherige MQTT-Implementierung übertragen werden
- ↑ Auch MQTT_DEVICE unterstützt setExtensions, allerdings muß dies dort per Attribut eingeschaltet werden
- ↑ Dabei wird vorausgesetzt, dass ein allgemeines autocreate-Device (TYPE=autocreate) ebenfalls aktiv ist
- ↑ Die Anführungszeichen sowie genau zwei Leerzeichen sind hier erforderlich!
- ↑ Hier waren bereits zwei Zigbee-Geräte angelernt
- ↑ Die mit 0x... beginnende Angabe entspricht dabei dem friendly_name.
- ↑ Dieses befindet sich dann im Raum MQTT2_DEVICE. Um diesen sichtbar zu machen, muß ggf. die Browser-Seite neu geladen werden.
- ↑ Durch die model-Angabe kann nachvollzogen werden, welches template angewendet wurde.
- ↑ Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.
- ↑ z.B.
attr MQTT2_FHEM_Server rawEvents .*
, der regex-Filter kann wie üblich angepaßt werden