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

[Beta-User]

OK, Danke für die Einschätzung!

@hexenmeister: Kann gerne einen patch vorbereiten (für die beiden Themen AnalyzePerlCommand und AttrTemplate_Initialize), falls Interesse besteht?

[Beta-User]

Ich muss mir das Verfahren noch genauer angucken, weiß noch nicht, ob ich mir das richtig vorstelle. Was ich gerne hätte, wäre eine Möglichkeit, quasi per Knopfdruck ein bestimmten Device/DeviceTyp gebrauchsfertig einzurichten, in diesem Fall mit Attribute wie "mqttDefaults", "mqttPublish"; "mqttSubscribe" (bzw. können diese je nach Prefix auch anders heißen).

Aktuellste Version/Einführung: MQTT_GENERIC_BRIDGE - sinnvolle defaults (für attrTemplate)

[Beta-User]

Nachdem ich jetzt ein wenig rumgespielt habe, werfe ich mal eine These in den Raum:

Wer MGB nutzt, will (nur) für matchende Topics (in der Regel) kein autocreate!

Zum Setup: ein Sytem, M2S mit autocreate auf simple, zwei MGB, als externe MQTT-clients dann mosquitto_sub und mosquitto_pub (von einem anderen System aus, was aber egal ist). clientOrder ist (noch) nicht gesetzt (hier aber ebenfalls erst mal irrelevant).

Folge: jeder publish, der eigentlich an die MGB gehen soll, landet in einem M2D (entsprechend der ClientID aus "-i").

Das ist dann super, wenn man "Irrläufer" detektieren will. Für "gute" Kommandos hat man aber in der Regel genau einen Abnehmer, nämlich die MGB (bzw. eine davon).

Würde daraus folgende Schlüsse ziehen:
- clientOrder sollte automatisch auf MGB M2D umgestellt werden, wenn es eine solche gibt (Annahme: dabei die Last ist identisch, egal, welche Reihenfolge gesetzt ist);
- MGB sollte als (änderbaren!) default NICHT [NEXT] zurückgeben, wenn es einen match hatte (=> Attribut dafür einbauen?)

Damit würde auch die Notwendigkeit entfallen, entweder die Infos doppelt auszuwerten (indem man eben das M2D bestehen läßt), oder den User auf diese "bridgeRegexp nach leer"-Lösung zu verweisen...

Aber vermutlich übersehe ich mal wieder was wichtiges?

[rudolfkoenig]

Mit der Aenderung wird auch das autoload-Verfahren geaendert, d.h. das erste M2D wird nie automatisch angelegt (meine ich, habs aber nicht getestet).

Ich warte mit der Aenderung in M2C, bis MGB fertig ist.

[hexenmeister]

Ich warte mit der Aenderung in M2C, bis MGB fertig ist.

Gerne. Wie genau soll die Änderung aussehen?
- Soll MGB, falls IODefv ein MQTT2_CLIENT ist, automatisch clientOrder Attribut setzen (falls nicht bereits vorhanden)? Oder macht das besser M2C?
- Neuen Attribut (Namensvorschläge?) unterstützen, damit kein [NEXT] zurückgegeben wird, im Falle MGB ein Abnehmer-Device gefunden hat?

Korrekt so?

[Beta-User]

Moin zusammen,

habe mal das mit der clientOrder in das allgemeine MGB-attrTemplate reingenommen (sollte zur RADIO-Auswahl stehen, falls IODev nicht TYPE MQTT ist), update ist im svn.
Habe eigentlich Skrupel, in "fremden Devices" automatisiert was zu ändern, und finde ich es ok, wenn der User auch Infos hat, was "seine" Attribute eigentlich sollen ("Attribute gehören den Usern...").
Von daher neige ich dazu, den Teil so zu lassen, wie er ist. Nach den ersten Rückmeldungen zu dieser attrTemplate-Geschichte gehe ich davon aus, dass sich das hinreichend verbreiten wird, um auf ausreichend breiter Basis support leisten zu können.

Was NEXT angeht, dieser Vorschlag:

forceNEXT: Only relevant for MQTT2_CLIENT or MQTT2_SERVER as IODev. If set to 1, MQTT_GENERIC_BRIDGE will forward incoming messages also to further client modules like MQTT2_DEVICE, even if the topic matches to one of the subscriptions of the controlled devices. By default, these messages will not be forwarded for better compability with autocreate feature on MQTT2_DEVICE. See also clientOrder attribute in MQTT2 IO-type commandref (link); setting this in one instance of MQTT_GENERIC _BRIDGE might affect all.

[rudolfkoenig]

forceNext ist equivalent zu "clientOrder MGB". Das als Voreinstellung waere mAn einfacher, damit spart man sich das Schrauben an zwei Stellen.

Da ich aber inzwischen den Faden komplett verloren habe: welches Problem loesen wir hier gerade?

[Beta-User]

Vermutlich lösen wir grade Verständnisschwierigkeiten bei einem einzelnen User...

Also zur Aufschlauung desselben:
Wenn clientOrder MGB M2D gesetzt ist und ein match gefunden wird, kommt derzeit nach [NEXT] eine Liste der Devices, die bereits beliefert wurden, oder? Wenn ich deine Rückfrage jetzt richtig deute, wird dann (und nur dann) kein weiterer Dispatch-Aufruf an M2D getätigt und das Problem, das ich versuche zu lösen existiert gar nicht....?

Muss ich austesten, aber wenn das so wäre, würde es m.E. entweder reichen, das attrTemplate so zu belassen, wie es ist, oder (für die "volle Nutzerführung") es bei Setzen des IO-Attributs (nur nach $init_done) automatisch aufzurufen?

[Beta-User]

Ähm, also:

Testumgebung immer noch, update von eben:

Code Auswählen Erweitern

defmod MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE

(autocreate ist nicht gesetzt, also default). Eine "umleitende bridgeRegexp" ist afaik nicht gesetzt.

version MQTT.* liefert:

Code Auswählen Erweitern


10_MQTT2_DEVICE.pm 23596 2021-01-23 17:25:12Z rudolfkoenig

00_MQTT2_SERVER.pm        23538 2021-01-17 13:02:24Z rudolfkoenig
10_MQTT_GENERIC_BRIDGE.pm 23561 2021-01-19 23:13:31Z hexenmeister



Setzt man an einen Topic, den MGB kennt eine message ab, wird autocreate aktiv und erstellt erst mal ein M2D, MGB bekommt davon nichts mit. Erst die zweite Message führt dann dazu, dass MGB aktiv wird.
Löscht man das M2D wieder, beginnt das Spielchen von vorne.

Kommt mir seltsam vor, aber vermutlich übersehe ich auch hier mal wieder was...?

[rudolfkoenig]

Danke fuers Testen.
Ich habe was uebersehen, fhem.pl ueberschreibt teilweise die clientOrder Reihenfolge, das muss ich noch fixen.
Ich kann aber dein Testergebnis nur so erklaeren, dass bereits am Anfang sowohl eine MGB wie auch eine M2D Definition vorhanden war.
Stimmt das?

[Beta-User]

Sorry , das sich da unpräzise war. Test war mit dem Haupt-System, und da sind einige M2D definiert.
Ist m.E. in etwa das "User Typ A)"-Szenario.

[rudolfkoenig]

Ich habe jetzt einige Bugs im Zusammenhang mit clientOrder gefixt.
Kannst du es bitte erneut testen?

[hexenmeister]

forceNext ist equivalent zu "clientOrder MGB". Das als Voreinstellung waere mAn einfacher, damit spart man sich das Schrauben an zwei Stellen.

Wenn diese zwei Einstellungen equivalent sind, dann habe ich etwas nicht verstanden.
Die Order bestimmt doch, damit die MGB (wenn sie vorne erwähnt wird) trotz autocreate und auch wenn es zu dem Topic passende Geräte existieren noch etwas mitbekommnt.
Und forceNEXT würde die Bridge anweisen, den "Ball" weiter zu werfen, auch wenn sie was passendes gefunden hat. Bei forceNEXT=0 würde ja in diesem Fall kein M2D mehr was bekommen.
Habe ich das richtig wiedergegeben?

Falls ja, würde ich das so implementieren und den Doku-Text von Beta-User auch so übernehmen (finde ich sehr gut, vielen Dank!).
Voreinistellung (also falls kein Attribut definiert) wäre 1?

[rudolfkoenig]

clientOrder bestimmt, welche Module was bekommen, in welcher Reihenfolge. Wenn clientOrder=MGB ist, dann kommt M2D nicht dran, egal ob ein M2D definiert ist oder nicht, und was MGB zurueckliefert => forceNext ist ueberfluessig.
Das bisherige Verhalten (immer [NEXT] zurueckliefern) wird benoetigt fuer clientOrder=MGB M2D.

[hexenmeister]

Ok, danke für die Erklärung. Ich bin davon ausgegangen, dass immer beides (M2D, MGB) angegeben werden sollen, nur die Reihenfolge halt anders.
So stimmt das aber. forceNext=0 wäre überflüssig, das das selbe Effekt mit clientOrder = MGB erreiht wird.

Ok, dann brauchen wir fordeNext nicht.