[geklärt] MQTT_GENERIC_BRIDGE per subscription nutzen, um slave-Geräte...

Begonnen von Beta-User, 05 Januar 2019, 11:45:04

Vorheriges Thema - Nächstes Thema

Beta-User

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 brightness


mqtt-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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Ich habe gerade einen (aus meier Sicht) Bug in MQTT2_SERVER gefunden und gemeldet: https://forum.fhem.de/index.php/topic,95446.0.html
Kann sehr gut sein, dass das auch hier das Problem damit zusammen hängt.
Probiere mal testweise autocreate abzuschalten.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Beta-User

Also:
autocreate am MQTT2_SERVER war aktiv, das habe ich ausgeschaltet - keine Reaktion mit der Subscription (mit oder ohne einleitendem "/").
Dann FHEM neu gestartet - selbes Spiel => keine Reaktion des 51-er Devices auf Änderungen des 16-er Devices (on/off und brightness getestet, wieder mit und ohne dem "/" vorneweg. :(
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Dann muss ich mir zuhause nachstellen und genauer ansehen.
An diese Art Anwendung (Datenübertragung innerhalb einer FHEM-Instanz) hatte ich bei der Modulerstelleung nicht gedacht. ABer warum auch nicht...
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Beta-User

Danke schon mal vorab!

Aber so richtig verstehe ich  nicht, warum das nicht funktioniert. Im Prinzip ist es doch eigentlich egal, um welche Art Zieldevice es sich bei der Subscription handelt - die Empfangs- und Reaktionsseite sind doch zwei Paar Schuhe, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

In FHEM gibt es mW keine Moeglichkeit, die gleichen Daten von zwei logischen Modulen zu bearbeiten.
Dispatch ruft der Reihe nach alle logischen Module auf (erst die bereits definierten/geladenen, danach die noch nicht geladenen).
Wenn einer der Module "hab was gefunden" meldet, hoert die Schleife auf.
MQTT2_SERVER ruft Dispatch so auf, dass kein Nachladen ungeladener Module stattfindet, falls kein autocreate spezifiziert ist.

Ich habe im Moment keine Idee, wie ich ohne Nebeneffekte mehrere Module aufrufen soll.
MQTT_GENERIC_BRIDGE und MQTT2_DEVICE Parallel zu betreiben sollte gehen (ungetestet), aber nur fuer unterschiedliche Topics, und mit abgeschalteten MQTT2_SERVER bzw. MQTT2_CLIENT autocreate. Falls das nicht der Fall ist, bitte um Beispiel zum Nachstellen.


Beta-User

Ah, ok, das ist nachvollziehbar.

Damit wäre - neben einem schlichten notify - die einzige Lösung, erst die Bridge am "Master" für ein Forwarding auf einen anderen Topic zu nutzen um das dann da wieder mit dem "Slave" abzuholen...

Ich teste das bei Gelegenheit mal aus, aber damit dürfte es im Ergebnis tatsächlich einfacher sein, innerhalb von FHEM zu bleiben.

Danke euch!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Zitat von: rudolfkoenig am 07 Januar 2019, 09:19:28
In FHEM gibt es mW keine Moeglichkeit, die gleichen Daten von zwei logischen Modulen zu bearbeiten.
Dispatch ruft der Reihe nach alle logischen Module auf (erst die bereits definierten/geladenen, danach die noch nicht geladenen).
Wenn einer der Module "hab was gefunden" meldet, hoert die Schleife auf.

Verstehe. Verstehe ich es richtig, wenn zwei Devices passen würde, ist es undefiniert, wer den Zuschlag bekommt? Etwas unglücklich, aber ok.

Zitat von: Beta-User am 07 Januar 2019, 09:42:21
Damit wäre - neben einem schlichten notify - die einzige Lösung, erst die Bridge am "Master" für ein Forwarding auf einen anderen Topic zu nutzen um das dann da wieder mit dem "Slave" abzuholen...
Oder alternativ das alte MQTT-IODev verwenden. Dort wird kein Dispatch verwendet und die Zahl der gleichzeitig 'passenden' Ziels nicht beschränkt.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

ZitatVerstehe ich es richtig, wenn zwei Devices passen würde, ist es undefiniert, wer den Zuschlag bekommt?
Nein. Erst werden die bereits geladenen Module gefragt, dann die noch nicht geladenen.
Wenn beide geladen sind, dann wird wegen $hash->{Clients} erst MQTT2_DEVICE gefragt, dann MQTT_GENERIC_BRIDGE.
Fuer die ungelagenen Module zaehlt $hash->{MatchList}, da ist die Reichenfolge aber gleich.

ZitatOder alternativ das alte MQTT-IODev verwenden. Dort wird kein Dispatch verwendet und die Zahl der gleichzeitig 'passenden' Ziels nicht beschränkt.
Das MQTT Modul verwendet eine eigene und primitive Variante von Dispatch (GP_ForallClients), das solte eigentlich verboten werden.

Beta-User

Zitat von: rudolfkoenig am 07 Januar 2019, 10:03:38
Das MQTT Modul verwendet eine eigene und primitive Variante von Dispatch (GP_ForallClients), das solte eigentlich verboten werden.

[OT]
Über das bin ich auch "grade" gestolpert im Zusammenhang mit MySensors.
Leider sind meine Perl-"Kenntnisse" zu beschränkt, um da nachzubessern. An was sollte ich mich orientieren, um es "erlaubt" zu machen? (Irgend ein Änderungsbeispiel aus der Vergangenheit könnte evtl. schon reichen, ich denke ansatzweise verstanden zu haben, was diese Matchingfunktionen da grob tun)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Deckt sich nicht mit meinen gestrigen Tests. Mit Autocreate=0 bekam die Bridge den Zuschlag, mit autocreate=1 wurde die MQTT2_DEVICE aktualisiert. Ich konnte mehfach hin und her schalten.

ZitatDas MQTT Modul verwendet eine eigene und primitive Variante von Dispatch (GP_ForallClients), das solte eigentlich verboten werden.
Sehe ich zwar ähnlich, aber der Vorteil, mehrere Clients anzusprechen, ist mMn durchaus vorhanden und in einigen Fällen sinnvoll.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Zitat von: Beta-User am 07 Januar 2019, 10:10:08
[OT]
Über das bin ich auch "grade" gestolpert im Zusammenhang mit MySensors.
Leider sind meine Perl-"Kenntnisse" zu beschränkt, um da nachzubessern. An was sollte ich mich orientieren, um es "erlaubt" zu machen? (Irgend ein Änderungsbeispiel aus der Vergangenheit könnte evtl. schon reichen, ich denke ansatzweise verstanden zu haben, was diese Matchingfunktionen da grob tun)
Beide Module (MQTT und MY_SENSORS) wurden unrsprünglich vom selben Entwickler entwickelt. Ich habe mir das an MQTT-Beispiel ganz gut angeschaut. Es ist nicht einfacht zu ändern und braucht umfangreiche Tests danach.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Beta-User

Zitat von: hexenmeister am 07 Januar 2019, 10:14:21
Beide Module (MQTT und MY_SENSORS) wurden unrsprünglich vom selben Entwickler entwickelt. Ich habe mir das an MQTT-Beispiel ganz gut angeschaut. Es ist nicht einfacht zu ändern und braucht umfangreiche Tests danach.
Das mit dem selben Autor war mir soweit fast klar, daher auch die Frage in diesem Zusammenhang ;) .
Aber wenn das mit hohen Risiken und Nebenwirkungen verbunden ist, dann übersteigt das ziemlich sicher meine Möglichkeiten (jedenfalls ohne massive Hilfe). Da der Code ja funktioniert, ist das m.E. auch nicht so dringend, aber wenn es das irgendwann werden sollte, wäre es auch gut, rechtzeitig darauf vorbereitet zu sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Angesichts der Tatsache, dass es (ganz gut) funktioniert, war mir der Aufwand, dies im MQTT zu ändern, zu hoch. :o
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Machbar ist das natürlich trotzdem, wenn Du das machen willst, kann ich dich (in Rahmen meiner Fähigkeiten) unterstützen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy