Hallo zusammen,
angeregt durch eine
Frage von lucca111 in diesem Thread, habe ich mal versucht, ob es möglich ist, statt structure und/oder notify die MQTT_GENERIC_BRIDGE zu verwenden, um Gerätegruppen zu schalten bzw. weitere Geräte an ein Master-Gerät "zu hängen". Irgendwie will das aber noch nicht so recht, vermutlich hängt es an meinem Unverständnis von MQTT_GENERIC_BRIDGE...
Testsetup, alles innerhalb derselben FHEM-Installation unter Verwendung von MQTT2_SERVER:
Vorhanden sind zwei dimmbare zigbee-Devices, angelegt als MQTT2_DEVICE. Wenn ich den "Master" schalte, will ich, dass genau dasselbe mit dem "Slave" geschieht (wie gesagt, dass das auf anderem Weg auch zu erreichen ist, es ging mir aber um Machbarkeit und Verständnis dessen, was da passiert und was ggf. die beste Lösung für so ein Problemchen ist):
Erst mal die "Basis-Lists":- "Generic_BRIDGE":
define myGenericBridge MQTT_GENERIC_BRIDGE mqttBridge
attr myGenericBridge IODev MQTT2_FHEM_Server- "Master":
define MQTT2_zigbee_0x90fd9ffffe65db16 MQTT2_DEVICE zigbee_0x90fd9ffffe65db16
attr MQTT2_zigbee_0x90fd9ffffe65db16 IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_0x90fd9ffffe65db16 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_0x90fd9ffffe65db16 group Licht
attr MQTT2_zigbee_0x90fd9ffffe65db16 icon light_control
attr MQTT2_zigbee_0x90fd9ffffe65db16 readingList zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, '') }
attr MQTT2_zigbee_0x90fd9ffffe65db16 room Esszimmer
attr MQTT2_zigbee_0x90fd9ffffe65db16 setList on:noArg zigbee2mqtt/0x90fd9ffffe65db16/set {"state":"ON"}\
off:noArg zigbee2mqtt/0x90fd9ffffe65db16/set {"state":"OFF"}\
brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x90fd9ffffe65db16/set {"state":"on","$EVTPART0":"$EVTPART1"}\
attr MQTT2_zigbee_0x90fd9ffffe65db16 webCmd brightness-"Slave" (setList bereits erweitert um die Großschreibung für ON/OFF)
define MQTT2_zigbee_0x90fd9ffffe0bcd51 MQTT2_DEVICE zigbee_0x90fd9ffffe0bcd51
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 group Licht
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 icon light_control
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 model L_02a_zigbee2mqtt_bulb
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 readingList zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT, '') }
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 room Esszimmer
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 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"}\
ON zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON"}\
OFF zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"OFF"}
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 setStateList on off
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 webCmd brightnessmqtt-Verkehr mit mosquitto_sub:
zigbee2mqtt/0x90fd9ffffe65db16/set {"state":"ON"}
zigbee2mqtt/0x90fd9ffffe65db16 {"state":"ON","brightness":90}
zigbee2mqtt/0x90fd9ffffe65db16 {"state":"ON","brightness":90}
zigbee2mqtt/0x90fd9ffffe65db16/set {"state":"OFF"}
zigbee2mqtt/0x90fd9ffffe65db16 {"state":"OFF","brightness":90}
zigbee2mqtt/0x90fd9ffffe65db16 {"state":"OFF","brightness":90}
So, war der Gedanke, jetzt müßte es doch eigentlich möglich sein, dem Slave-Gerät einfach eine weitere Subscription unterzuschieben, und das war's... Gesagt getan, aber irgendwie will das eben nicht. Mein Verdacht ist, dass es an der JSON-Auswertung der Generic-Bridge hängt.
Ausprobiert habe ich diverse Varianten mit und ohne geschweifte Klammern, mit und ohne "/" am Anfang usw.. Am vielversprechendsten sieht folgendes aus:
attr MQTT2_zigbee_0x90fd9ffffe0bcd51 mqttBridgeSubscribe *:stopic=/zigbee2mqtt/0x90fd9ffffe65db16 *:expression={json2nameValue($message)}
Dann habe ich nämlich im mosquitto_sub eine dritte Rückmeldung, also so:
zigbee2mqtt/0x90fd9ffffe65db16/set {"state":"ON"}
zigbee2mqtt/0x90fd9ffffe65db16 {"state":"ON","brightness":150}
zigbee2mqtt/0x90fd9ffffe65db16 {"state":"ON","brightness":150}
zigbee2mqtt/0x90fd9ffffe65db16 {"state":"ON","brightness":150}
(Nochmal: mit "*:stopic=zigbee2mqtt/0x90fd9ffffe65db16" bekomme ich nur 2 "lange Rückmeldungen", nicht 3).
Daher gehe ich davon aus, dass die Subscription so an sich klappt, aber irgendwas an der JSON-Auswertung nicht will. Leider sind weder die Generic-Bridge noch MQTT2_DEVICE zu diesen Themen bei verbose 5 besonders gesprächig, da steht im log scheinbar nichts brauchbares.
Den anderen Weg, den set-Befehl über ein publish am Master zu lösen, hatte ich auch versucht. Das geht zwar mit einiger Frickelei im richtigen Format raus und schaltet auch "gelegentlich", allerdings scheint sich dann entweder zigbee2mqtt aufzuhängen oder die zigbee-Kommunikation ist so schlecht, dass das nach ein paar wenigen Schaltvorgängen im digitalen Nirvana endet; jedenfalls kommt ziemlich schnell keine Rückmeldungen mehr vom zigbee2mqtt-Dienst, es geht erst wieder irgendwas, wenn ich den zigbee-Dienst neu starte
.Aber dennoch zur Vervollständigung:
attr MQTT2_zigbee_0x90fd9ffffe65db16 mqttBridgePublish *:topic=zigbee2mqtt/0x90fd9ffffe0bcd51/set \
state:expression={"\{\"state\":\"".uc($value)."\"\}"}\
brightness:expression={"\{\"brightness\":$value\}"}Da das Ziel aber eigentlich wäre, systemübergreifend (MiLight=>zigbee2mqtt) zu schalten, wäre m.E. der Weg über die subscription sehr viel eleganter...
Vielleicht hat jemand eine Idee und kann mir verraten, wie es geht bzw. warum nicht?
Gruß,
Beta-User
