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

[noansi]

Hallo Rudolf,

in fhem.pl Zeile 4006

Code Auswählen Erweitern

    next if(!$dmsg !~ m/$modules{$m}{Match}/s);

Sieht das '!' am if Anfang beim delete unnötigerweise (fatalerweise) übrig geblieben aus.

So war es wohl gedacht

Code Auswählen Erweitern

    next if($dmsg !~ m/$modules{$m}{Match}/s);


Gruß,

Ansgar

[rudolfkoenig]

Danke, habs gefixt.

[Beta-User]

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

Mach' ich, vielleicht klären sich dann auch meine Verständnisprobleme betr. clientOrder vs. forceNEXT.
Im Moment bin ich noch nicht überzeugt, dass es keinen Sinn macht, da clientOrder ja global (für den jeweiligen IO-TYPE) wirkt. Rückmeldung folgt, wird aber etwas dauern, vielleicht brauche ich erst noch eine weitere Spielwiese....

@hexenmeister:
Falls du dich mit dem Hinweis auf my $foo = $bar if $baz; # UNDEFINED! beschäftigen willst: In https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/6fd40496772d7f2d3046c953409698193aadbd23 wäre mein noch nicht intensiv getesteter Versuch zu finden, die betreffenden Stellen auf "offiziell zulässige" Weise zu notieren.

[rudolfkoenig]

Im Moment bin ich noch nicht überzeugt, dass es keinen Sinn macht, da clientOrder ja global (für den jeweiligen IO-TYPE) wirkt.

Nicht mehr, es ist Instanz spezifisch geworden.

[Beta-User]

Danke für die Info, dann kann ich einfach mit meinem "User will einfach eine shiny MQTT-based-UI haben"-Szenarium weitermachen.

Da gibt es mAn. einen M2S, MGB und eine beliebige Anzahl von M2D, und der User will autocreate für M2D aktiv halten.
Dann sollte er die Reihenfolge in clientOrder umdrehen, also "MGB M2D", und er will (so meine These) weder ein M2D für Topics, die zu MGB passen, noch will er Events an einem "Sammel-M2D" generiert haben.

Habe jetzt nochmal in den aktuellen Code in fhem.pl geschaut (ab #4004 bzw. 4017), und glaube, dass es (zumindest in diesem Szenarium)
a) sinnvoll ist, in MGB konfigurierbar zu machen, ob bei einem Match "[NEXT]" zurückgeliefert wird, und
b) die in +99% gewünschte/erwartete Voreinstellung für forceNEXT "0" ist.

Ad a) nochmal: Es geht ausschließlich um den Fall, dass es einen Topic-Match in MGB gibt, alles andere soll/muss selbstredend an M2D weitergegeben werden!

Im Moment glaube ich auch nicht, dass es ein Problem in anderen User-Szenarien gäbe; der einzige Sonderfall der mir grade vor Augen steht, bei dem das problematisch sein kann wäre, wenn jemand bewußt einen Topic nutzen will, um sowohl eine MGB wie auch M2D zu beliefern. Sowas kann vorkommen, wenn jemand Gruppenschaltungen oä. vornehmen will, aber dann ist er zum einen Fortgeschrittener, und zum anderen findet er dann über forceNEXT bzw. clientOrder auch die erforderliche Doku, um das umzusetzen; dann halt mit dem "Nachteil", dass er Ideen entwickeln muss, um den unbeabsichtigten Rest zu verwerfen.

[ToKa]

Hallo zusammen,

kann es sein, dass auf Grund der Optimierungen (MGB, M2C) das retain Flag nicht mehr richtig an den Broker (mosquitto) weitergegeben wird?

Verbose 5 MGB:

Code Auswählen Erweitern

2021.01.25 15:47:51 5: MQTT_GENERIC_BRIDGE:DEBUG:> [ZS_zs_CO_MQTT_Generic_Bridge] publish: scada/haus/E4/az/THKV_Heizkoerper_Wand/desired-temp => 22.0 (qos: 0, retain: 1)

Verbose 5 M2C:

Code Auswählen Erweitern

2021.01.25 15:52:12 5: ZS_zs_CO_SCADA_MQTT_Client: sending PUBLISH 19(0)3scada/haus/E4/az/THKV_Heizkoerper_Wand/desired-temp22.0
2021.01.25 15:52:23 5: ZS_zs_CO_SCADA_MQTT_Client: sending PINGREQ (192)(0)
2021.01.25 15:52:23 5: ZS_zs_CO_SCADA_MQTT_Client: received PINGRESP

Debug Mosquitto:

Code Auswählen Erweitern

Client (null) received PUBLISH (d0, q0, r0, m0, 'scada/haus/E4/az/THKV_Heizkoerper_Wand/desired-temp', ... (4 bytes))
scada/haus/E4/az/THKV_Heizkoerper_Wand/desired-temp 22.0


Sieht für mich so aus, als würde das retain=1 aus MGB globalDefaults verwendet, aber nicht an den Broker weitergegeben. Was M2C damit macht, kann ich nicht erkennen.

Bitte nicht durch die Zeitstempel irritieren lassen, ich habe den Fall zweimal ausrprobiert

VG
Torsten

[rudolfkoenig]

Fuer MGB kann ich nicht reden, aber M2C scheint noch zu tun, abgesehen davon dass ich an dieser Stelle nichts geaendert habe.
Folgendes sind abwechselnd die Befehle aus FHEM und die mosquitto debug Ausgabe:

Code Auswählen Erweitern

fhem> set m2c publish -r a b
1611593233: Received PUBLISH from m2c (d0, q0, r1, m0, 'a', ... (1 bytes))

fhem> { IOWrite($defs{m2d}, "publish", "c:r d") }
1611593510: Received PUBLISH from m2c (d0, q0, r1, m0, 'c', ... (1 bytes))

fhem> attr m2c qosMaxQueueLength 50
fhem> set m2c publish -r e f
1611593812: Received PUBLISH from m2c (d0, q1, r1, m1, 'e', ... (1 bytes))

fhem> set m2c publish  g h
1611593887: Received PUBLISH from m2c (d0, q1, r0, m2, 'g', ... (1 bytes))


[Beta-User]

@ToKa:
Habe den Verdacht, dass retain ggf. @M2.* schon länger nicht klappt; kannst du mal testweise # 2456 so ändern:

Code Auswählen Erweitern

    $topic ="-r $topic" if $retain;
Kann das nicht so recht nachvollziehen, weil da IOWrite aufgerufen wird, kann also auch falsch sein, da kann ggf. Rudi auch was dazu sagen, in der folgenden Zeile steht dann nämlich:

Code Auswählen Erweitern

    IOWrite($hash, "publish", $topic.' '.$message);

[ToKa]

Hallo Beta-User,

bei mir ist die

Code Auswählen Erweitern

10_MQTT_GENERIC_BRIDGE.pm 23561 2021-01-19 23:13:31Z hexenmeister installiert - letztes Update heute morgen gemacht. Bei mir ist es die Zeile 2455, die ich jetzt aber auf Deinen Vorschlag abgeändert und fhem neu gestartet habe.

Danach wird der Wert gar nicht mehr an den Broker übertragen. Aus dem Beispiel von Rudi, sieht das auch eher nach :r statt -r aus.

VG
Torsten

[Beta-User]

Danke für die Info, dann kann ich einfach mit meinem "User will einfach eine shiny MQTT-based-UI haben"-Szenarium weitermachen.

[...] glaube, dass es (zumindest in diesem Szenarium)
a) sinnvoll ist, in MGB konfigurierbar zu machen, ob bei einem Match "[NEXT]" zurückgeliefert wird, und
b) die in +99% gewünschte/erwartete Voreinstellung für forceNEXT "0" ist.
[...]

Hab's jetzt nochmal praktisch durchgespielt. Zumindest in dem o.g. setup wäre es sinnvoll, bei positiven Matches in der MGB [NEXT] _nicht_ zurückzugeben, sonst wird autocreate auch in den Fällen aktiv, in denen die eigentlich gewünschte Aktion bereits erledigt sein sollte.

Anbei daher ein patch, der das Verhalten konfigurierbar macht; mit drin sind diese "my $foo = ... if"-Geschichten. Läuft testweise noch nicht lange, aber es läuft ...

[rudolfkoenig]

Anbei daher ein patch, der das Verhalten konfigurierbar macht; mit drin sind diese "my $foo = ... if"-Geschichten.

Konstrukte der Art "my $xx = yy if(zz);" sind problematisch, weil $xx den Wert der letzten Schleife behaelt, falls zz nicht zutrifft.
Das hat mich zwar auch schon gebissen, ich habe meine Module aber noch nicht aufgeraeumt, ist TODO.
jw9 hat netterweise auch schon darauf hingewiesen, leider im komplett falschen Forumsbereich.

[Beta-User]

jw9 hat netterweise auch schon darauf hingewiesen, leider im komplett falschen Forumsbereich.

...vielleicht sollte man ihm sagen, dass er "nur" Tester werden muss, um im Developer-Bereich posten zu können?

Na jedenfalls sollte der besagte Patch auch eventuellen Bissverletzungen vorbeugen (auch wenn der eigentliche Code hier zwar "nicht regelkonform" ist/war, aber am Ende eigentlich auch so relativ unproblematisch aussieht).

Zurück zum "eigentlichen Programm":

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)

- Das Zusammenspiel sollte (bis auf die Frage, wo das retain abgeblieben ist?) soweit gelöst sein;
- Doku:
-- cref zu MGB - Vorschlag für die (seitherige) DE-Version existiert, Rückmeldung steht noch aus;
-- cref zu MQTT_BRIDGE (neu): https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/537e8e149feb4dbfa48361d334326d298ffc597d
-- attrTemplate-feature fehlt in der Doku noch, Vorschlag folgt, wenn die Strukturierung vollends durch ist und die Benennungen für's erste aufgegleist sind;
-- bei Gelegenheit fange ich (oder ein Freiwilliger?) dann einen Wiki-Artikel dazu an, der die Reihenfolge/Basics und das Zusammenspiel ggf. etwas näher erläutert;
- features: da fällt mir im Moment nur die AnalyzePerlCommand-Frage ein. Kann/soll ich da was liefern?

Sonst:
Den TARGETTYPE könnte man auch in option:{} prüfen, vermutlich baue ich das so um. Hat halt den "Nachteil", dass man dann nichts mehr "cross-verwenden" kann (also z.B. nicht mehr mit einem dummy testen), aber wer da was vermisst, ist dann ggf. eher geneigt, uns Baumaterial zu liefern?

Kurz hatte ich die Idee, die MGB-attrTemplate-Aufrufe an die Sprachsteuerungs-attrTemplate dranzuhängen, aber das birgt v.a. bei mehrkanaligen Devices das Risiko, dass der User zwischendurch abbricht und dann Teile unkonfiguriert bleiben. Folglich habe ich das verworfen. Oder gibt's da andere Meinungen?

[Beta-User]

Nachtrag noch zum Patch-Vorschlag betr. der direkten Initialisierung der attrTemplate:

Am Ende von sub Define() noch folgendes einfügen:

Code Auswählen Erweitern

  ::AttrTemplate_Initialize() if $::init_done;
(Vor   

Code Auswählen Erweitern

  # noetig hier beim Anlegen im laufendem Betrieb
  InternalTimer(1, \&firstInit, $hash);

[Beta-User]

@hexenmeister:
Hab's jetzt alles nochmal zusammengeschoben, patch anbei, jetzt sollten auch die <li>-Elemente in der commandref wieder ausgeglichen sein .
Bei der Gelegenheit: Ist es nach wie vor richtig, dass mqttAlias nur in publish-Richtung funktioniert? (Ist/war mir bisher entgangen...)

Dann habe ich mal einen Wiki-Artikel angefangen, der das eher in eine "wie gehe ich das als Einsteiger an?"-Form bringt; wäre nett, wenn ihr da Rückmeldung geben könntet, ob das auch aus eurer Sicht in die richtige Richtung geht.

Weiter gibt's jetzt zu den Thermostaten/attrTemplate auch noch (teilweise) "actuator", das ist btw. auch ein gutes Beispiel für's "zur-Zahl-machen".

[herr.vorragend]

Hallo,

es ist ganz schön kompliziert geworden, in FHEM eine MQTT-Schnittstellen in beiden Richtungen zu implementieren.
Ich weiß nicht mehr, was plötzlich anders ist, aber nun kommen meine Publishs nicht mehr am Gerät an, sondern werden in einem MQTT2_fhem-Device gesammelt.

IODev

Code Auswählen Erweitern

defmod mosquitto MQTT2_CLIENT mosquitto:1883
attr mosquitto autocreate complex
attr mosquitto clientId fhem
attr mosquitto clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr mosquitto ignoreRegexp fhem/(?!set/)
attr mosquitto keepaliveTimeout 60
attr mosquitto msgAfterConnect -r fhem/connection/status connected
attr mosquitto msgBeforeDisconnect -r fhem/connection/status disconnected
attr mosquitto qosMaxQueueLength 100
attr mosquitto username mqtt

Bridge

Code Auswählen Erweitern

defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=System->MQTT-Bridge
attr mqttGeneric IODev mosquitto
attr mqttGeneric globalDefaults sub:base={"fhem/set"} pub:base={"fhem"} pub:qos=0 sub:qos=2 retain=0
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count

Das FHEM-Device

Code Auswählen Erweitern

attr hmdevice mqttPublish *:topic={"$base/$device/$name"}
attr hmdevice mqttSubscribe :stopic={"$base/$device/$name"}

Publish-Test

Code Auswählen Erweitern

fhem/set/hmdevice/state on


M2D-Bridge-Device
Hier kommt das State-Reading mit dem "on" an.

Code Auswählen Erweitern

defmod MQTT2_fhem MQTT2_DEVICE fhem
attr MQTT2_fhem IODev mosquitto
attr MQTT2_fhem autocreate 1
attr MQTT2_fhem bridgeRegexp (tele|stat|shellies|valetudo|Advantech)/([^/]+)/.*:.* "$2"\
  zigbee2mqtt/bridge/.*:.* "zigbee2mqtt"\
  sonos/connected.* "sonos"\
  tvheadend/[^/:]+.* "tvheadend"\
  milight/LWT:.* "milight"\
  (ESPClient_[^/]+)/.*:.* "$1"\
  (ebusd[^/]*)/global/.*:.* "$1"\
  [^/]+/(ems-esp[^/]+)/start:.* "$1"\
  (mygateway[\d]+)-(in|out)/.* "$1"\
  (wallpanel|wled)/([^/]+)/.*:.* "$1_$2"\
  go-eCharger/([^/]+)/.*:.* "go_eCharger_$1"\
  owntracks/[^/]+/([^/:]+).* "owntracks_$1"\
  home/(O[^/]*M[^/]*G[^/]*)/LWT:.* "$1"\
  homeassistant/.*/config:.* ""
attr MQTT2_fhem model MQTT2_CLIENT_general_bridge
attr MQTT2_fhem readingList fhem:fhem/set/hmdevice/state:.* state\
fhem:homeassistant/status:.* status
attr MQTT2_fhem setList clear_all:noArg {fhem("deleteattr $NAME readingList;; deletereading -q $NAME (?!associatedWith).*");;return undef}
attr MQTT2_fhem setStateList on off

Hat jemand einen Tipp, woran das liegen kann?