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

[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":

Code Auswählen Erweitern

define myGenericBridge MQTT_GENERIC_BRIDGE mqttBridge
attr myGenericBridge IODev MQTT2_FHEM_Server

- "Master":

Code Auswählen Erweitern

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)

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

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

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

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

[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?

[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!

[hexenmeister]

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.

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.

[rudolfkoenig]

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

Oder 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]

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)

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

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

[hexenmeister]

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

[Beta-User]

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

[hexenmeister]

Angesichts der Tatsache, dass es (ganz gut) funktioniert, war mir der Aufwand, dies im MQTT zu ändern, zu hoch.

[hexenmeister]

Machbar ist das natürlich trotzdem, wenn Du das machen willst, kann ich dich (in Rahmen meiner Fähigkeiten) unterstützen.

[Beta-User]

Machbar ist das natürlich trotzdem, wenn Du das machen willst, kann ich dich (in Rahmen meiner Fähigkeiten) unterstützen.

Angesichts der Tatsache, dass es (ganz gut) funktioniert, war mir der Aufwand, dies im MQTT zu ändern, zu hoch.

Wenn nicht mittelfristig irgendwelche Probleme zu erwarten sind (außer dem Umstand, dass Rudi der Code offensichtlich nicht behagt), sehe ich im Moment auch keine Veranlassung, da (ggf. abgesehen vom im anderen Thread angerissenen setExtensions-Thema) nachzubessern; Danke trotzdem für das Angebot!

[hexenmeister]

setExtensions haben mit dem dispatch-Mechanismus nichts zu tun. Die bekommen wir ggf. unabhängig von der Umstellung hin.

[Beta-User]

Thx.
Im Moment sind es bei MySensors zwei Baustellen:
a) zum einen funktioniert die "Rückwärtssuche für das Chanenl76-IO" in MYSENSORS (noch) nicht.
b) das mit setExtensions.

Da Rudi die Art und Weise in GPUtils für die Client-Suche nicht zu gefallen scheint, würde mich zum Punkt a) interessieren, wie das am "FHEM-konformsten" zu lösen wäre? Vermutung: Besser devspec2Array nutzen statt den GPUtils-Code verändert in MYSENSORS einzubauen?

Zu b) (und ggf., sofern erforderlich auch zu a)) würde ich vorschlagen, das nicht hier weiter zu diskutieren, sondern in (je) einem eigenen Thread im MySensors-Bereich?

[rudolfkoenig]

a) zum einen funktioniert die "Rückwärtssuche für das Chanenl76-IO" in MYSENSORS (noch) nicht.

Ich weiss nicht genau, was du meinst, ich Rate
Wenn ein Modul ein device-id nach Geraet-Mapping haben will, dann kann er das mit

Code Auswählen Erweitern

$modules{<MyModeleName>}{defptr}{device-id} = $defs{deviceName}
machen, da dieser defptr auch bei rereadcfg gerettet wird.

b) das mit setExtensions.

Wenn das Modul in SetFn feststellt, dass es mit dem Befehl nichts anfangen kann, dann wird nicht das Usage zurueckgeliefert (Unknown argument XX, choose one of $list")  sondern SetExtensions($hash, $list, @a), wobei $hash das "eigene" $defs-Eintrag ist (erstes Parameter zu SetFn), $list die Leerzeichen separierte Liste der moeglichen Befehle, und @a Parameter 2...X zu SetFn.

[Beta-User]

Sorry Leute,

für sowas (und zwar je einzeln) benötige ich leider immer eine gefühlte Ewigkeit, um es zu verstehen.
zu a) weiß ich noch nicht so recht, ob man sowas braucht wie von Rudi vorgeschlagen. Der Ablauf, um den es konkret geht, ist der:

Normalerweise kommen MySensors-Nachrichten _von_ einer Node immer über dasselbe GW rein, über das auch später wieder gesendet werden soll. Dabei ist in einer Message immer eine ID enthalten (0-255), die entweder eindeutig ist (0-254) oder eine Anfrage zur Vergabe einer Nummer (255). Der vorhandene Code für das IO (00_MYSENSORS.pm) sucht jetzt also das (10_MYSENSORS_DEVICE-) Client-Device, dessen Konfigurationsdaten _den eigenen Namen als IO_ und die ID enthält und reicht die Message dann an das betreffende Client-Device weiter, das dann selber entscheidet, was damit passieren soll (bzw. erstellt bei aktivem autocreate ein neues, wenn noch nicht vorhanden).

Klappt super, nur eben dann nicht, wenn man eigentlich einen anderen Kanal nutzt, jetzt aber der Bootloader (der auf OTA-Daten wartet) den Kanal verstellt - dann kommen die Messages _über ein anderes IO_ rein und dieses Matching klappt nicht, da ja der Name des IO's nicht paßt. Im Ergebnis wird die message dann verworfen (statt über das "spezielle" IO eine Antwort zu senden).

Es muß also (im speziellen Fall bestimmter Nachrichtentypen) ein elsif-Zweig her, der prüft, ob es "zufällig" ein Device gibt, das (per Attribut) als "OTA_Chan76_IODev" den aktuellen IO-Namen festgelegt hat und dann die Nachricht an dieses weitergibt (das Client-Device sollte dann die Antwort auch bereits über das richtige IO auf Kanal 76 antworten). Da das ein absoluter Spezialfall ist, ist vermutlich eine Abfrage mit devspec2Array die simpelste Lösung.

zu b) So wie ich das verstehe, ist der setExtensions-Aufruf immer der letzte in so einer Kette.
Das "Problem" ist, dass man das an den genannten Stellen irgendwie harmonisieren muß mit einem GPUtils-Aufruf, der sich ebenfalls für den letzten in der Kette hält und mit "return ..." beginnt, was dann wohl nicht so bleiben kann.
Vermutlich müßte ich den dortigen Rückgabewert in eine Variable ("my $GPUtilsReturnvalue = ") packen und dann mal sehen, ob ich das anschließend zuletzt in den setExtensions Aufruf irgendwie reinwurstle?
(Teste ich demnächst mal , aber erst kommt a)).

[hexenmeister]

Zu a)
Du kannst hier (vermuttlich) den 'normalen' Dispatch-Mechanismus gar nicht normal verwende, aber das Modul tut das eh nicht. Du kannst aber auch nicht dafür die GP_ForallClients nehmen, da diese IODev-Name prüft. Du ´brauchst eine ähnliche eigene Methode, die über alle bekannten Module(Instanzen) durchgeht, den Typ des Moduls und ein bestimmtes spezielles IODev-Attribut vergleicht. Dann eine speziel dafür zu erstellende Methode im Client aurufen. Irgendwie so.

[hexenmeister]

Zu b)
Auf den ersten Blick sieht es richtig aus. Der Aufrug GP_Catch sollte gar nicht aufgerufen werden, wenn 'on-for-timer' gerufen wird, das dies nicht in 'sets' enthalten ist (sein darf). Man muss Debug-Ausgaben einbauen und testen, was da wirklich passiert.

[LudgerR]

Habe ich das richtig verstanden?

Wenn man innerhalb von Fhem, d.h. via MQTT mittels publish und subscribe  zwischen verschiedenen devices (innerhalb von Fhem) Bedingungen prüfen und Aktionen triggern will kann man dies (zur Zeit ?) nicht   mit MTTQ2 Server realisieren und muss auf einen externen Broker (z.B. mosquitto ) ausweichen?
Ich bin auf diesen Thread gestoßen, weil ich das Verhalten der MQTT2 Bridge im Zusammenspiel mit MQTT2 Server trotz Einschaltung aller Debug Optionen nicht erklären konnte.
In meinen konkreten Fall steuere ich meine Sony TV (modul BRAVIA) und den SonosPlayer im Wohnzimmer mittels einer MQTT dashboard App.  Das Publishing des ,,on" states vom (Sony) BRAVIA device ans MQTT Frontend wollte ich dazu nutzen um im SonosPlayer device  per set-topic den Player auf ,,Pause" zu setzen.
Um nicht ein zusätzliches notify  zu bemühen und um die Logik am device selbst zu binden habe ich für mich  als ,,dirty workaround" folgende Lösung gefunden:

Code Auswählen Erweitern


define Sony BRAVIA 192.168.69.209 10
      :
  :
attr Sony mqttDefaults base={"SH/EG/E3/MEDIA/$device/$reading"} pub:qos=0 sub:qos=2 retain=1
attr Sony mqttPublish *:topic={"$base"}\
       state:topic={"$base"} state:expression={fhem("set Sonos_Wohnzimmer pause") if $value eq on";;$value=$value}
attr Sony mqttSubscribe channel:set-topic={"SH/EG/E3/MEDIA/Sony/channel/cmd"}\
                          volume:set-topic={"SH/EG/E3/MEDIA/Sony/volume/cmd"}\
                          mute:set-topic={"SH/EG/E3/MEDIA/Sony/mute/cmd"}\
                          state:set-topic={"SH/EG/E3/MEDIA/Sony/state/cmd"}


Ich mißbrauche die expression im mqttPublish um ein fhem set on den SONOSPLAYER abzusetzen.

Auf die Dauer betrachte ich diese fehlende Funktionalität von MQTT2 Bridge im Zusammenspiel mit MQTT2 Server jedoch als ein Manko.

[Beta-User]

M.E. sind da ein paar Unsauberkeiten drin:
"Eigentlich" ist es nur so, dass man nicht gleichzeitig mit einem MQTT2-Interface aus demselben topic ein MQTT2_DEVICE und ein MQTT_GENERIC_BRIDGE beliefern kann.

Ob das bei dir der Fall ist? (Gibt es ein (per autocreate erstelltes) MQTT2_DEVICE, in dem die für den SonosPlayer gedachten Befehle gelandet sind?)

Daneben: MQTT_GENERIC_BRIDGE gibt es nur in der "V1+", das ist aber (bei ausgeschaltetem autocreate!) kompatibel mit allen verfügbaren MQTT-IO-Modulen, aber eben nur für unterschiedliche subscriptions.

Ob der MQTT2_SERVER überhaupt "interne" Messages so verteilt, kann ich nicht sagen, das ergab sich aus meinen Tests nicht eindeutig; aber eventuell ist es auch bei mosquitto so, dass ein Client, der was reinsendet dasselbe nicht gleichzeitig als subscription wieder bekommt (sowas ist m.E. sehr gefährlich: man baut damit schnell mal eine unbeabsichtigte Schleife).

Weiter könnte es sein, dass die ursprüngliche Konfiguration nicht ging, weil in der GenericBridge auch eine Funktion drin ist, um solche Schleifen zu vermeiden (da gab es neulich einen Beitrag im GenericBridge-Thread, bei dem es um sowas ähnliches ging, wenn ich das richtig interpretiert habe); also selbst wenn der jeweilige Broker das mitmacht.

An sich ist der Fall bei dir auch anders: Es geht nicht eigentlich um die "doppelte" subscription unter dasselbe topic, sondern eine logische Reaktion, oder? Sowas ist eigentlich wirklich klassisches Event-Handling, da finde ich es ok, wenn es nicht funktioniert (mittelfristig sollte es da ggf. sowas wie do's and don'ts rund um MQTT+FHEM geben).

Viele Fragen, aber ob man deswegen schon die Flinte ins Korn werfen darf?

(Der Ansatz, die Reaktion in die expression zu schreiben ist aber interessant, behalte ich im Hinterkopf ).

[LudgerR]

Ob das bei dir der Fall ist? (Gibt es ein (per autocreate erstelltes) MQTT2_DEVICE, in dem die für den SonosPlayer gedachten Befehle gelandet sind?)

Nein,  außerdem wenn ich mit (mosquitto_sub)  das topic von extern publishe wird am SonosPlayer der set-topc Befehl wie erwartet erkannt und ausgeführt.

Ob der MQTT2_SERVER überhaupt "interne" Messages so verteilt, kann ich nicht sagen, das ergab sich aus meinen Tests nicht eindeutig; aber eventuell ist es auch bei mosquitto so, dass ein Client, der was reinsendet dasselbe nicht gleichzeitig als subscription wieder bekommt (sowas ist m.E. sehr gefährlich: man baut damit schnell mal eine unbeabsichtigte Schleife).

Das mit der "infinite loop" ist mir schon bewußt.  Dennoch würde mich interessieren ob bei mosquitto eine deratige Restriktion ebenfalls vorhanden ist. Da ich dabei bin als Frontend  dasboards auf MQTT Basis  einzusetzten und die interne Kommunikation in erster Linie über MQTT erfolgt, präferiere ich Lösungen/ Steuerungen auf MQTT Basis.

Selbstverständlich kann man mit notify und DOIF sehr gute / komplexe Ereignissteuerung machen. Für die einfachen Dinge bevorzuge ich jedoch Lösungen, die man in der Device Konfiguration direkt ablesen kann. (Siehe mein Beispiel Sony-TV und SonosPlayer).

(Der Ansatz, die Reaktion in die expression zu schreiben ist aber interessant, behalte ich im Hinterkopf ).

Genau deshalb habe ich dies public gemacht.

Wegen meiner Ausrichtung auf MQTT Frontends, wird die Mehrzahl meiner Devices eh von der MQTT2 GenericBridge überwacht.
Damit könnte ich mit dem expression Konstrukt jegliches "Reading-Event" des Devices in solch einer  expression behandeln und auf ein separates notify bzw. DOIF in vielen Fällen verzichten.
Da ich durch ein Finales setzen auf undef letzendlich eine Publikation verhindern kann,steht dem "Mißbrauch" nichts mehr im Wege.

Das gleiche gilt in ähnlicher Form auch für mqttSubscribe.

[Beta-User]

Hm,

also irgendwie stehe ich entweder immer noch auf dem Schlauch oder die Lösung hat doch einen Haken (was ich glaube, siehe nachfolgendes).

Was die Bridge macht (btw: was soll nochmal eine MQTT2 Bridge sein?), ist bei stopics _das Zielgerät_ zu schalten, also das, bei dem das Attribut auch steht. Gedacht ist das mit den stopics m.E. nie für ein ganz anderes Zielgerät. Wenn man das will, müßte man nach meinem Verständnis dort (!) eine eigene set-subscription haben und dieselbe Info dort dann ggf. gesondert auswerten.

Hier hast/hättest du das weitere Problem, dass es dann einen Unterschied macht, wenn du das von der MQTT-Seite über die App schaltest oder innerhalb FHEM (Erwartung: dieselbe Reaktion; Ergebnis: abweichend, da nicht über MQTT ausgelöst).

Und ob es übersichtlicher ist, das in ein eigenes 3. Device (notify etc) zu schreiben, oder direkt innerhalb des Zieldevice (Sonos_Wohnzimmer)abzubilden sei dahingestellt, aber diese Lösung, Teile der dieses Device betreffenden Logik innerhalb eines ganz anderen Devices (Sony) abzubilden, ist m.E. nicht wirklich dauerhaft transparent. In einem notify sieht man wenigstens noch die beteiligten Devices vice versa...

Just my2ct.

[LudgerR]

Was die Bridge macht (btw: was soll nochmal eine MQTT2 Bridge sein?), ist bei stopics _das Zielgerät_ zu schalten, also das, bei dem das Attribut auch steht. Gedacht ist das mit den stopics m.E. nie für ein ganz anderes Zielgerät. Wenn man das will, müßte man nach meinem Verständnis dort (!) eine eigene set-subscription haben und dieselbe Info dort dann ggf. gesondert auswerten.

Bei der MQTT Bridge meine ich natürlich "MQTT_GENERIC_BRIDGE". 

Selbstverständlich habe ich das set-topic  am Zielgerät dem SONOSPLAYER device definiert. (Die Definition hätte ich möglicher  mitliefern müssen).
Nur weil es am Destination-Device per mqttSubscribe widererwarten nicht funktioniert, habe ich dies am Quell-Device mit fhem("set ......") im expression erfolgreich eingebaut.

Inzwischen hatte ich  set-topic auf topic geändert, um das unterschiedliche Verhalten beim in- und externen publishing zu dokumentieren.

Code Auswählen Erweitern


defmod Sonos_Wohnzimmer SONOSPLAYER RINCON_949F3E1410FC01400_MR
        :
attr Sonos_Wohnzimmer mqttSubscribe Sony:topic={"SH/EG/E3/MEDIA/Sony/state"}
        :


Das Reading "Sony" im device Sonos_Wohnzimmer wird beim publishing durch mqttPublish in Sony  nicht upgedated.

Nutze ich jedoch mosquitto_pub   und schneide mittels mosquitto_sub mit, so erhalte ich in beiden Fällen das identische Protokoll.  Der wesentliche Unterschied ist jedoch, dass diesmal das Reading "Sony" im device Sonos_Wohnzimmer (SONOSPLAYER)  upgedated wird. 

Es ist somit das Zusammenspiel von "MQTT2_Server" mit "MQTT_GENERIC_BRIDGE", das dieses inkonsistente Verhalten an den Tag legt.

Für mich stellt sich die Frage ob in der Kombination

        MQTT_GENERIC_BRIDGE <---> MQTT2_Client <---> Externer Broker

dieses inkonsistente Verhalten verschwindet.
 

[Beta-User]

Vorab mal Danke für die Erläuterungen, wie das ursprünglich war, dann sind wir uns scheinbar einig, wie das - von der Empfangsseite her gedacht - "sauber" aussehen sollte...

Für mich stellt sich die Frage ob in der Kombination

        MQTT_GENERIC_BRIDGE <---> MQTT2_Client <---> Externer Broker

dieses inkonsistente Verhalten verschwindet.

Ich weiß nicht, ob die Bezeichnung "inkonsitstent" paßt: Nach dem Verständnis, das ich bis dato entwickelt habe, hat eben jedes in MQTT teilnehmende "Gerät" eine Kennung, die eindeutig sein sollte (CID). Aus Sicht des MQTT-Verkehrs sind alle FHEM-internen Devices, (also alles, was "eigentlich" nicht nativ MQTT spricht und von außen kommt) vermutlich "ein" Gerät in diesem Sinne, weil sie alle die CID des MQTT2-Servers haben. Für interne Zwecke auf einem (also innerhalb eines) Device ist das ganze Protokoll eigentlich nicht gemacht, es ging bei der Entwicklung ja gerade drum, leichtgewichtig zu sein... Dass die Nachrichten daher nicht auf diesem Weg FHEM-MQTT2-intern weiter verteilt werden, leuchtet mir ein, und zu mosquitto hatte ich das hier schon ausgeführt:

[...] aber eventuell ist es auch bei mosquitto so, dass ein Client, der was reinsendet dasselbe nicht gleichzeitig als subscription wieder bekommt (sowas ist m.E. sehr gefährlich: man baut damit schnell mal eine unbeabsichtigte Schleife).

Käme also auf einen Test an, ob mosquitto das anders macht undzurückdispatcht... Wenn ja, wäre das ggf. wirklich ein Argument für mosquitto (wenn man unbedingt auf Event-Handler verzichten will, was ich - trotz meiner Tendenz, möglichst Geräte einzusparen - immer noch für in diesem Fall angemessener halte).

Aber mal schauen, was ggf. deine Tests bringen und die wirklichen Experten dazu meinen...

[LudgerR]

Moin,

In der Kombination

     MQTT_GENERIC_BRIDGE <---> MQTT2_CLIENT <---> Externer Broker

funktioniert das Publish and Subscribing genau so, wie ich MQTT verstanden habe.

Die augenblicklichen Stand der Implementierung mittels
 
   MQTT_GENERIC_BRIDGE <---> MQTT2_SERVER

ist wegen dem fehlenden dispatch der outbound message auch in inbound Richtung (bei enstsprechender Subskription) jedoch noch inkonsistent.


Zu deinem Hinweis
   

Ob der MQTT2_SERVER überhaupt "interne" Messages so verteilt, kann ich nicht sagen, das ergab sich aus meinen Tests nicht eindeutig; aber eventuell ist es auch bei mosquitto so, dass ein Client, der was reinsendet dasselbe nicht gleichzeitig als subscription wieder bekommt (sowas ist m.E. sehr gefährlich: man baut damit schnell mal eine unbeabsichtigte Schleife).

möchte ich nur anmerken, dass das Empfangen eines Topics und anschließendem Dispatchen des Topics an den selben Client nichts Ungewöhnliches ist.  Sowohl  MQTT2_SERVER als auch mosquitto unterstützt meinen Tests nach diese Funktionalität. 

Nur halt in der Kombination

  MQTT_GENERIC_BRIDGE <---> MQTT2_SERVER

fehlt (noch ?) diese Funktionalität.

[rudolfkoenig]

Ich habe das rePublish Attribute in MQTT2_SERVER implementiert:

rePublish
  if a topic is published from a source inside of FHEM (e.g. MQTT2_DEVICE), it
  is only sent to real MQTT clients, and it will not internally republished. By
  setting this attribute the topic will also be dispatched to the FHEM internal
  clients.

[Beta-User]

Kurz zu meinem ursprünglichen Ansatz:
Mit den aktuellen Versionen der Module sollte das doch jetzt funktionieren, oder?
(So wie ich das in dem anderen Thread verstanden habe, müßte die von außen kommende Message doch eigentlich nicht nur beim MQTT2_DEVICE  -db16 auch bei der Generic-Bridge landen und dann dort an deren Client weitergegeben werden).

Klappt leider in der Praxis bisher nicht. Hängt das an der Reihenfolge in der cfg oder ist es "nur noch" ein Konfigruationsproblem? (die diversen Schreibvarianten mit und ohne "/" vorneweg hatte ich ausprobiert).
Gerne hänge ich noch lists an, wenn das erforderlich sein sollte. Was die Reihenfolge angeht: MQTT2_SERVER ist Nr. 378, MQTT2_zigbee_0x90fd9ffffe65db16 NR 380, zigbee_0x90fd9ffffe0bcd51 NR 381 und die Generic-Bridge Nr. 407 (ein Client wird angezeigt).

Wollte nur kurz fragen, ob das grundsätzlich gehen kann, bevor ich da tiefer einsteige...

[rudolfkoenig]

Mit MQTT2_DEVICE alleine sollte es funktionieren (wenn nicht, mir melden).
Mit MQTT_GENERIC_DEVICE tippe ich auf nein, weil hexenmeister es auf die neue Verteilungsmethode anpassen muss, und evtl. noch mehr pruefen/fixen darf.
Und er meinte, er kommt erst in eine Woche dazu.

[Beta-User]

Danke für die Rückmeldung, das hilft mir erst mal, hatte fast vermutet, dass es da noch einer Anpassung bedarf, das eilt nicht.

Und klar: das "Master"-MQTT2_DEVICE funktioniert ordnungsgemäß. Auch das andere MQTT2-"Slave"-Device ist ok, wenn ich es direkt schalte.
Nur der zusätzliche "Slave"-Pfad über die MQTT_GENERIC_BRIDGE am "Slave-Device" will nicht.

Dann warte ich mal, bis hexenmeister das gefixt hat .

@Beide: Klasse Sache, dass ihr da zusammen jetzt einen Weg gefunden habt!

[LudgerR]

ad #29

Schön, dass dies nun implementiert und freigeschaltet werden kann.  Zunächst werde ich auf MQTT2_CLIENT und mosquitto bleiben, um auch Dateien z.B. IP-Cam  snapshots ans MQTT Frontend schicken zu können.

Eine Frage noch.

Ich publishe alle Readings meiner 13 FHTs per MQTT.  Im ersten Anlauf hatte ich den Eindruck das mit dem Republishing (MQTT2 client und mosquitto) Response time Probleme auftauchten, d.h. Das Schalten meiner Shelly/Sonoff und ESP Geräte mittels mqttSubscripe und mqttPublish (Rückkanal) dauerte wesentlich länger, als direkt vom mgtt Dasboard über den Broker und somit ohne Fhem . Da nun eine sehr große Anzahl an inbound-counts in der MQTT_Generic-Bridge auftauchte  vermutete ich hier die Ursache.

Und nun die Frage:   

Wie stark belastet das ungefilterte Republishing von Sensorenwerten die Performance. In der Mehrzahl der Fälle kann die MQTT2_GENERIC_BRIDGE mit diesen topics ja nichts anfangen?

Im MQTT2_CLIENT hatte ich gehofft mit setByTheProgram  im subscriptions Attribute nur die Topics zu subscriben,  die tatsächlich von den MQTT_Devices einschließlich MQTT_GENERIC_BRIDGE aktuell verwendet werden zu begrenzen.
Dies ist mir  jedoch nicht gelungen. 

[rudolfkoenig]

Wie stark belastet das ungefilterte Republishing von Sensorenwerten die Performance.

Ist halt ein Event mehr, was durch FHEM wandert. Da man nicht so haeufig ein Set ausloest, duerfte das vernachlaessigbar sein.

Weiterhin werden die Events erst nach der Benachrichtigung der "richtigen" MQTT-Clients generiert => rePublish wird bei einem einzigen Schalt-Befehl keine Auswirkung haben.