[erledigt] MQTT_GENERIC_BRIDGE - Optimierungen für MQTT2-IO-Module

[Beta-User]

Hallo zusammen,

ich fange hier mal einen neuen Thread an, nachdem das Thema Kompabilität von MQTT2-IO's mit der MQTT_GENERIC_BRIDGE die Tage hier ein Thema war, was dankenswerterweise dazu geführt hat, dass man libmodule-pluggable-perl nicht mehr benötigt: https://forum.fhem.de/index.php/topic,117423.msg1121207.html#msg1121207.

Es gibt aber ein paar weitere Themen, die man in dem Zusammenhang ggf. nochmal aufgreifen bzw. verbessern könnte (prio aufsteigend!).
a) den patch von Nestor hier: https://forum.fhem.de/index.php/topic,117659.0.html
b) die interne Abfrage, welcher IO-Typ verwendet wird, kommt mir nicht optimiert vor:

Was mir bei der Durchsicht noch aufgefallen war: die Prüfung auf die IO-Type wird jedesmal in der "Vollversion" durchlaufen; evtl. könnten wir überlegen, ob es Sinn macht, das zu beschleunigen (z.B. indem man ein Internal oder einen helper-hash setzt)?

(müßte man wohl löschen, wenn das IODev-Attribut nach $init_done angefasst wird).

c) (v.a. auch an @Rudi):
"Konflikte" zwischen MQTT2_DEVICE und MQTT_GENERIC_BRIDGE - das "autocreate"-(+)-Problem...

Soweit ich es richtig verstanden habe, was wir vor einiger Zeit diskutiert hatten, ist es immer kritisch, wenn potentiell zwei Client-Module (dieselben?) Informationen im Rahmen von dispatch erhalten sollen:

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.

Im Moment gibt es da zwar die "workarounds", entweder autocreate am IO abzuschalten, oder via bridgeRegex dafür zu sorgen, dass CID leer ist (und MQTT2_DEVICE die Kette daher nicht abbricht). ABER: hat der user - warum auch immer - ein MQTT2_DEVICE mit "passendem" (oder besser unpassendem) readingList-Eintrag, greift sich MQTT2_DEVICE die message und MGB ist "raus".
Das ist eine Sache, die uns mittelfristig vermutlich beschäftigen wird.
Frage (es ist mir bewußt, dass eine "Sonderbehandlung" einzelner Module durch andere Module nicht unbedingt das Architektenherz höher schlagen lassen...): Wäre es nicht sinnvoll/möglich, wenn MQTT2_DEVICE am Ende ggf. prüft, ob MGB geladen ist und der Topic in den dortigen subscriptions drin ist und die betreffende Nachricht dann (nur) in diesen Fällen weiterleitet?

Denn es gibt ein anderes Thema, das auch damit zusammenhängen dürfte:
MQTT_GENERIC_BRIDGE generiert massenhaft incoming-count Events. Rekursion?Meine Vermutung: 00_MQTT.pm gibt nur weiter, was auch abonniert ist (und "weiß", was zu wem gehört), MQTT2-IO's geben weiter, was bekannt ist und keinen anderen "bevorrechtigten" Abnehmer hat. Letzteres kann deutlich mehr sein. Es muss also sowieso an irgendeiner Stelle geprüft werden, ob die Nachricht überhaupt relevant ist (wäre natürlich gut, wenn man das nicht doppelt macht). Zumindest, was die Event-Generierung angeht, setzte an dieser Stelle mein patch-Versuch von gestern an, aber das kann auch Unsinn sein.

Soweit erst mal mein Sachstand...

Grüße, Beta-User

[rudolfkoenig]

Wäre es nicht sinnvoll/möglich, wenn MQTT2_DEVICE am Ende ggf. prüft, ob MGB geladen ist und der Topic in den dortigen subscriptions drin ist und die betreffende Nachricht dann (nur) in diesen Fällen weiterleitet?

Moeglich ja, aber sowas baue ich erst ein, wenn der Weltuntergang unmittelbar bevorsteht. Eher kurz danach.

Vmtl. muesste man erst einen Schritt zuruecktreten, und ueberlegen, was ein Benutzer will bzw. potentiell welche Szenarien sinnvoll sind: MQTT2_DEVICE (MD) alleine, MQTT_GENERIC_BRIDGE (MGB) alleine, MD fuer A,B,C,.. und MGB fuer X,Y,Z oder beide fuer alle.
Danach ueberlegen, wie wir das implementieren.

[Beta-User]

 
Sehe im Moment folgende Szenarien:

A) User kommt von "extern" und hat FHEM gefunden, weil er seine Lieblings- (oder Problem-) Hardware damit eingebunden bekommt. Betreibt FHEM also nur als Abstraktionslayer für einen sehr begrenzten Anwendungfall und will so schnell es geht zurück "in seine Welt" und sich möglichst wenig mit den (Un-) Tiefen von FHEM befassen; Broker ist dann typischerweise extern.
Kann stressfrei MGB mit M2C ohne autocreate verwenden, M2D wird ihn in der Regel nicht interessieren, diesen Teil macht er sowieso extern. (fyi: M2C in Interaktion mit MGB ist im Moment mein "blinder Fleck").

Mögliches Problem: Er findet FHEM irgendwann toll und will die Automatisierung nach FHEM verlagern. M2D wird dann zur "no-go-zone", weil er dann wissen muss, wie man es händisch konfiguriert. Geht auch, ist aber schwierig, v.a., wenn er rausfinden will, welchen topic er in rL angeben muss, damit attrTemplate durchläuft...
(Um diesen User-Typ sollte man sich bemühen, denn er kennt die große weite Welt und kommt nicht zu FHEM, weil er ein großes deutschsprachiges Forum sucht, sondern weil FHEM stabil und flexibel ist!).

B) FHEM-User, der ein "schnelles shiny frontend" haben will und daher die relevanten Daten schnell mal nach MQTT bringt, um sie z.B. in NodeRed zu visualisieren (siehe verlinkten Thread). Die, die das bisher gemacht haben, waren bisher mangels Alternativen mehr oder weniger alle auf mosquitto+MQTT+MGB, aber künftig wird das eher M2S+MGB sein; der "neue" User dieses Typs kommt von M2D her und hat seine shelly/tasmota/zigbee2mqtt-Devices alle schon in FHEM am Laufen. (Evtl. teste ich das mal aus, nachdem ich mich ja sowieso in das Thema eingedacht habe).

Problem: M2D soll auf autocreate bleiben, dieser User-Typus schätzt den Komfort und will keine komplizierte "autocreate-hell", die ihm in einem Moment der Unaufmerksamkeit die externe Anbindung zerschießt...

C) Der "Multi-System-User", der mehrere FHEM betreibt, Daten zwecks Standardisierung via MQTT austauscht und manche "andere" Hardware-Systeme ggf. auch auf dem MQTT-Weg anbindet (zigbee2mqtt ist afaik nur ein Vertreter dieser .*2mqtt-Generation; das Fibaro-HCL, das ich für die update-Geschichte verwendet habe, hat z.B. auch eine gecrackte firmware, auf der direkt auch ein mosquitto läuft, und es gibt afaik auch eine HMCCU2mqtt-Anbindung). Schätzt an FHEM die hohe Flexibilität und ist auch mit Perl soweit vertraut, dass er die Automatisierungen irgendwo in einem Zentralsystem oder auch verteilt abbildet und "irgendwo" das logging erledigt

MAn. nicht unser Problem; dieser Usertyp kennt die vielfältigen Fallsticke bzw. wird sie finden und erfolgreich umschiffen...

[rudolfkoenig]

Ich nehme mit: man will MGB und M2D (mit oder ohne autocreate), wahlweise einzeln oder beide zusammen.
Als Bonus: M2D autocreate nicht fuer bestimmte Topics.

Z.Zt. geht MGB oder M2D, auch beides zusammen, aber dann nicht mit M2D autocreate.
D.h. es fehlt MGB + M2D mit autocreate, und ein Autocreate-Topic-Filter.

Uebersehe ich etwas?

[Beta-User]

Ich nehme mit: man will MGB und M2D (mit oder ohne autocreate), wahlweise einzeln oder beide zusammen.

"man" will ich nicht für mich in Anpruch nehmen, aber grundsätzlich sehe ich schon Bedarf für eine Koexistenz von "MGB und M2D (mit oder ohne autocreate)".

Wäre interessant, wie andere das sehen...

Als Bonus: M2D autocreate nicht fuer bestimmte Topics.

Jein: _automatisches Ausschalten_ von M2D autocreate fuer bestimmte Topics.
Der Bonus geht heute schon: Man definiere ein M2D mit passender bridgeRegexp und hinterlege "" als CID.
Das Problem ist nur, dass es auf diese Weise ein verstecktes und für immer unverstandenes feature bleiben wird, auch wenn es seit einiger Zeit im Wiki steht...

Z.Zt. geht MGB oder M2D, auch beides zusammen, aber dann nicht mit M2D autocreate.
D.h. es fehlt MGB + M2D mit autocreate, und ein Autocreate-Topic-Filter.

Uebersehe ich etwas?

Das Schlagwort vom "Autocreate-Topic-Filter" gefällt mir gut, der Rest geht (mit den genannten Einschränkungen) eigentlich heute schon, und das mit dem Ausschalten von "autocreate" ist - wenn ich es richtig verstanden habe - auch nur die halbe Miete: Es verhindert nämlich nicht, dass "falsche" readingList-Einträge in M2D im Ergebnis dann MGB "abklemmen", oder? Auch das noch abzufangen wäre ggf. die "Luxusvariante".

Zusammengefasst: "Autocreate-Topic-Filter" wäre als (Arbeitstitel) "bridge_2MGB_regexp" für die M2-IO's eventuell eine auch halbwegs vermittelbare Konstruktion?

[hexenmeister]

Hallo allerseits,

ich denke, es ist schwer zu sagen, welche User-Typen alles existierren. Die genannten gibt es sicher, aber vermutlich auch eine Reihe Mischformen.

Ich selbst gehöre vermutlich zum Typ C. Habe 7 FHEM-Instanzen laufen (incl. Test), 2 mal NodeRED (eine davon Test), zigbee2mqtt, ein kleines Zoo Mqtt-fähige Geräte und diverse Testinstallationen von Automation-Software (IOBrocker, HAS) die in Docker-Containern leben und meistens 'down' sind. Die sind per MQTT miteinander verbunden, den Server macht Mosquitto (auch in Container, wie die meisten Sachen hier).

Alle Instanzen haben ihre Aufgabe und sollen nach möglichkeit nicht mehrere Dinge tun. Daher ist ein MQTT2_SERVER nicht meine Wahl.
M2D nutze ich nicht, alles macht die MGB. Dennoch halte ich die saubere Zusammenarbeit von MGB und M2D für sehr wichtig.
Die Gründe für den Verzicht sind diverse.
Zunächst mag ich autocreate nicht - ich mache gerne die Definitionen selbst, wie ich sie verstehe und brauche (sehe dennoch ein, dass für einen durchschnittlichen User autocreate ein Segen ist).
Dann ist mir auch Syntax für M2D nicht geläufig (bin faul - Bridge kann ja auch alles und die kenne ich etwas besser ).
Dazu kommt die Tatsache, dass man mit M2D ein Topic wohl nicht für mehrere Devices 'wiederverwenden' kann. Das ist für mich aber ein valides Anwendungsfall - z.B. aus einem komplexeren (json) Wert in einem Topic mehrere unterschiedliche Geräte zu befüttern. Da die Bridge und M2D sich hier in die Quere kommen können, verwende ich sie gat nicht erst. Es ist mir wichtig, solche unerwartete Seiteneffekte (ich lege ein M2D und an anderen Stellen verschwinden Daten) unbedingt zu vermeiden.

Also bin ich vermutlich was das betrifft eher ein Exot und orientiere mich bei der Entwicklung lieber an Meinungen aus dem Forum (ohne natürlich eigene Interessen zu vergessen ).

Meine Sicht darauf, was zu tun wäre, ist ungefähr folgende:
- Lösung des Problems des Zusammenspiels von MGB und M2D (Prio 1)
- Überarbeitung der Dokumentation (Anwender- unf vor Allem Einsteiger-freundlich) (Prio 1)
- Erstellung einer Anleitung mit Vorschlägen zur Standardisierung (Syntax, Topics, etc.) (Prio 2)
- neue Features (Prio 99, mir fehlt aktuell praktisch nichts, aber vlt. kommt noch was wichtiges)
- Fehlerfixes, soweit Fehler gemeldet werden (laufend)
- Optimierungen, wenn Performance-Probleme auftreten (bei Bedarf)

[rudolfkoenig]

Ich habe schonmal das clientOrder Attribut fuer MQTT2_SERVER und  MQTT2_CLIENT implementiert:

clientOrder [MQTT2_DEVICE] [MQTT_GENERIC_BRIDGE]
      set the notification order for client modules. This is relevant when autocreate is active, and the default order (MQTT2_DEVICE MQTT_GENERIC_BRIDGE) is not adequate. Note: Changing the attribute affects _all_ MQTT2_SERVER instances.

Damit kann man z.Bsp. MQTT2_DEVICE komplett ignorieren, oder es erst, wenn MQTT2_GENERIC_BRIDGE nichts findet, aktivieren.
Fuer Letzteres muss MQTT2_GENERIC_BRIDGE aber mitspielen, und im ParseFn als erstes [NEXT] zurueckliefern.

[hexenmeister]

Damit kann man z.Bsp. MQTT2_DEVICE komplett ignorieren, oder es erst, wenn MQTT2_GENERIC_BRIDGE nichts findet, aktivieren.
Fuer Letzteres muss MQTT2_GENERIC_BRIDGE aber mitspielen, und im ParseFn als erstes [NEXT] zurueckliefern.

Danke, ich denke, damit kann man das Problem zumindest umschiffen.
Spricht eigentlich etwas dagegen, wenn die MQTT_GENERIC_BRIDGE immer [NEXT] zurückgebt? Dann würden ja (bei order (MQTT_GENERIC_BRIDGE MQTT2_DEVICE )) immer die passenden MQTT2_DEVICE-Instanzen gesucht?

[rudolfkoenig]

In diesem Fall [NEXT] zurueckzuliefern ist unproblematisch, MQTT2_DEVICE macht es bereits, ohne "wenn und aber" => bitte in MQTT_GENERIC_BRIDGE auch einbauen.

[NEXT] ist ein Problem z.Bsp. bei FS20: FS20V, USF1000 und BS sind Spezialfaelle, die alle FS20 Signale senden, mit bestimmten Muster. Wenn diese Module [NEXT] zurueckliefern wuerden, wuerde FHEM das Signal auch als "normales" FS20 interpretieren, was nicht zielfuehrend ist.

[Beta-User]

@hexenmeister:
Habe mal versucht, den Code von MGB an der Stelle zu verstehen (Parse() und onmessage()), um ggf. unterstützen zu können.

Irgendwie habe ich aber zwei gedankliche Hänger, v.a. im gedanklichen Kontext, dass mehrere MGB aktiv sind:
- wenn bei der ersten MGB kein topic matched, gibt Parse() direkt leer ("") zurück, oder ist das ein Mißverständnis?
- Wenn ein topic matched, wird das erforderliche Array incl. "[NEXT]" zurückgegeben, aber es wird nie geschaut, ob es ggf. noch einen zweiten Match gibt?

Das erstere wäre in unserem Kontext schädlich, oder? Und mehrere MGB würden dann auch (zumindest von MQTT2-IO's) auch nicht "korrekt" beliefert werden, oder?
Und ist das letztere (erster match => raus) wirklich (aus Effizienzgründen?) so beabsichtigt? Weiß im Moment nicht, für was man eine 1:n-Zuordnung praktisch benötigt, aber als "Gruppenschaltung" ist sowas ähnliches z.B. auch in der Tasmota-Firmware vercodet. Will sagen: früher oder später wird ggf. jemand drüber stolpern, man sollte es also wenigstens in der Doku erwähnen...?

[rudolfkoenig]

Bin nicht sicher, ob ich deinen Gedankengang richtig verstehe, aber ParseFn wird nur einmal pro Modul aufgerufen, und nicht pro Instanz.

[Beta-User]

Davon WR ich ausgegangen.

[Beta-User]

...ist jetzt alles nicht so einfach, weil sich manches überschnitten hatte...

Also: Unter https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/e2b565deffc5c9d98140f0115cfdb3fd9bfe0d80 ist ein patch zu finden, leider passen die Zeilennummern vermutlich nicht 100% zur svn-Fassung und ggf. muss man auch einen Blick auf das Umfeld werfen.

Diese (gesamte) Fassung läuft jedenfalls bei mir hier im Hauptsystem seit ein paar Minuten, bringt aber dann noch zusätzlich diverse perlcritic-Änderungen und den 1. cref-Vorschlag (noch ohne Hinweis auf das mit dem 2-er-IO-Attribut).

Die wesentlichen Ideen:
- IO-TYPE-Bestimmung etwas optimiert;
- Die Zählung ist jetzt abhängig vom IO-TYPE. Sollte für die neuen IO's die Event-Flut eindämmen und für 00_MQTT.pm 100% kompatibel sein;
- Die Schleife zum Durchlaufen aller MGB-Instanzen ist umgebaut, es sollte jetzt immer NEXT zurückkommen. Da bin ich aber nicht sicher, ob das noch kompatibel zu 00_MQTT.pm ist, weil da das GP_Catch verwendet wird und ggf. jede MGB-Instanz separat aufgerufen wurde (?). Unklar ist mir aber warum dann für 00_MQTT.pm überhaupt das Array verwendet wurde, da hätte eigentlich dann nur die eine Instanz "durchlaufen" werden dürfen und dann macht es ggf. auch Sinn, das return "" zwischendurch zu lassen, aber eben dann mit der Prüfung, ob es 00_MQTT.pm war, das die ParseFn aufgerufen hat.
Den NEXT-Teil habe ich bisher nicht getestet...

Bitte fragen, wenn was offen ist, und sorry für den Telegramm-Stil grade.

[hexenmeister]

In diesem Fall [NEXT] zurueckzuliefern ist unproblematisch, MQTT2_DEVICE macht es bereits, ohne "wenn und aber" => bitte in MQTT_GENERIC_BRIDGE auch einbauen.

done

[hexenmeister]

@hexenmeister:
Habe mal versucht, den Code von MGB an der Stelle zu verstehen (Parse() und onmessage()), um ggf. unterstützen zu können.

Irgendwie habe ich aber zwei gedankliche Hänger, v.a. im gedanklichen Kontext, dass mehrere MGB aktiv sind:
- wenn bei der ersten MGB kein topic matched, gibt Parse() direkt leer ("") zurück, oder ist das ein Mißverständnis?
- Wenn ein topic matched, wird das erforderliche Array incl. "[NEXT]" zurückgegeben, aber es wird nie geschaut, ob es ggf. noch einen zweiten Match gibt?

Das erstere wäre in unserem Kontext schädlich, oder? Und mehrere MGB würden dann auch (zumindest von MQTT2-IO's) auch nicht "korrekt" beliefert werden, oder?
Und ist das letztere (erster match => raus) wirklich (aus Effizienzgründen?) so beabsichtigt? Weiß im Moment nicht, für was man eine 1:n-Zuordnung praktisch benötigt, aber als "Gruppenschaltung" ist sowas ähnliches z.B. auch in der Tasmota-Firmware vercodet. Will sagen: früher oder später wird ggf. jemand drüber stolpern, man sollte es also wenigstens in der Doku erwähnen...?

Habe auch versucht nachzuvollziehen, was mein Gedankengang damals gewesen ist, ist auch schon etwas her...
Irgendwie sehe ich auch keinen Sinn "" zurückzugeben. Habe jetzt hier return ("[NEXT]");
So wie ich das sehe, ist aktuell nicht möglich, mehrere Bridges für den selben(!) IO zu haben - die zweite bekommt nichts.
Es macht eigentlich auch nicht viel Sinn - im Gegensatz zu mehreren Bridges mit verschiedenen IODev.
Ich werde es vermutlich umbauen, um für alle Fälle unerwartete Effekte auszuschliessen.