FHEM2MQTT2FHEM ... und seine Hürden

[Beta-User]

Das Problem scheinen weniger die escapes gewesen zu sein (es werden andere Trennzeichen verwendet), sondern die Umstellung auf "devicetopic": Damit ist der Schrägstrich entfallen (nur hier, in den anderen paßt es...) , sobald devicetopic vorhanden ist.

So müßte es an dieser Stelle passen:

Code Auswählen Erweitern

par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)(/.+)?, ? $1 : undef }



Was den Rest angeht, habe ich etwas weiter dran rumgebastelt, komme aber nicht so richtig auf einen grünen Zweig. Gedanklicher Ausgangspunkt ist die Prüfung, die MQTT2_SERVER hier in Zeile 461 macht:

Code Auswählen Erweitern

my $ir = AttrVal($serverName, "ignoreRegexp", undef);
461      next if(defined($ir) && "$tp:$val" =~ m/$ir/);
Also ein eigentlich simples matching. Ein paar regexe hatte wir ja, von daher hatte ich versucht, die einfach 1:1 da reinzubasteln und auch einfach die obige Prüfung so nachzubauen. (Dass gängige regex-online-Tester wie regex101.com da rummaulen, war auch vorher schon so, sollte aber hier eigentlich nicht stören. Komisch sind aber diese irgendwie - jedenfalls mit meinen noch nicht so geschärften Augen - wenig in sich konsistenten Ergebnisse:

Aktuelle Versuchsfile (Auszug):

Code Auswählen Erweitern

name:MQTT2_IO_ignoreRegexp_basic
filter:TYPE=MQTT2_DEVICE
desc:Adds a new ignoreRegexp to the courrent IO device of device it is applied to. This will prevent evaluation of incoming messages typically meant to go towards the hardware including branches with "cmnd" tasmota and "command" for shelly. <br>Additionally homeassistat discovery branch will be deactivated. <br>NOTE: early experimental version...
order:000002
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
set DEVICE attrTemplate MQTT2_IO_ignoreRegexp_shelly \IODEVNAME=IODEVNAME
set DEVICE attrTemplate MQTT2_IO_ignoreRegexp_tasmota \IODEVNAME=IODEVNAME
set DEVICE attrTemplate MQTT2_IO_ignoreRegexp_homeassistant \IODEVNAME=IODEVNAME
setreading IODEVNAME attrTemplateVersion 20200628

name:MQTT2_IO_ignoreRegexp_tasmota
filter:TYPE=MQTT2_DEVICE
desc:Adds a new ignoreRegexp to the courrent IO device of device it is applied to. This will prevent evaluation of incoming messages typically meant to go towards the hardware including branches with "cmnd" tasmota. <br>NOTE: early experimental version...
order:0000021
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
par:NEWIGNOREREGEXP;NEWIGNOREREGEXP as set if expression is already included, otherwise it will be added;{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp",'cmnd/[^/]+/');; 'cmnd/[^/]+/' =~ m/$old/ ? $old : $old.'|cmnd/[^/]+/' }
attr IODEVNAME ignoreRegexp NEWIGNOREREGEXP

name:MQTT2_IO_ignoreRegexp_shelly
filter:TYPE=MQTT2_DEVICE
desc:Adds a new ignoreRegexp to the courrent IO device of device it is applied to. This will prevent evaluation of incoming messages typically meant to go towards the hardware including branches with "command" for shelly. <br>NOTE: early experimental version...
order:0000022
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
{my $ign = AttrVal('IODEVNAME','ignoreRegexp','not_set');  if ( $ign eq 'not_set' ) { CommandAttr(undef, "IODEVNAME ignoreRegexp shellies/[^/]+/command"); return; }; if ( 'shellies/[^/]+/command' =~ m/$ign/ ) {return;} else { $ign .= '|shellies/[^/]+/command' ; CommandAttr(undef, "IODEVNAME ignoreRegexp $ign"); } }


name:MQTT2_IO_ignoreRegexp_homeassistant
filter:TYPE=MQTT2_DEVICE
desc:Expands existing or adds a ignoreRegexp to the courrent IO device of device it is applied to. This will prevent evaluation of incoming messages meant for homeassistant for auto-discovery of devices. You are strongly encouraged to not use homeassistant autodiscovery at all, but in case you need it for some reason, adding this ignoreRegexp-expression might help to avoid confusion!<br>NOTE: early experimental version...
order:000002a
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
par:NEWIGNOREREGEXP;NEWIGNOREREGEXP as set if homeassistant is included, otherwise it will be added;{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp",'homeassistant/.*/config');; 'homeassistant/.*/config' =~ m/$old/ ? $old : $old.'|homeassistant/.*/config' }
attr IODEVNAME ignoreRegexp NEWIGNOREREGEXP
{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=IODEVNAME'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
farewell:template has been applied successfully. Check further extending the ignoreRegexp by yourself!

name:do_general_mqtt_cleanup
filter:NAME=speechrecognTesting
order:000002b
desc:template to do some cleanup and set ignoreRegexp that may help in case MQTT commands may be issued from not within this FHEM server; call e.g. with ADD_TO_IO_IGNOREREGEXP=milight/0x[0-9a-fA-F]{1,4}[/].*/[0-8].
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
par:ADD_TO_IO_IGNOREREGEXP;add ignoreRegexp to be attached to the current one, defaults to "";{ "" }
deletereading -q TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList
{return if 'ADD_TO_IO_IGNOREREGEXP' eq ""; my $ign = AttrVal('IODEVNAME','ignoreRegexp','');  if ( $ign eq '' ) { CommandAttr(undef, "IODEVNAME ignoreRegexp ADD_TO_IO_IGNOREREGEXP"); return; }; if ( 'ADD_TO_IO_IGNOREREGEXP' !~ m/$ign/ ) { $ign .= '|ADD_TO_IO_IGNOREREGEXP' ; CommandAttr(undef, "IODEVNAME ignoreRegexp $ign");} }

Spielt man nur mit dem MQTT2_IO_ignoreRegexp_basic und den darin enthaltenen dreien rum, wird die ignoreRegexp immer weiter um den shelly-Anteil erweitert.
Meine Vermutung: irgendwo wird da in der shelly-Variante ein eval dazwischengeschaltet, das den reinen Perl-Weg verhindert?

@Rudi: Wenn das so ist, brauche ich dafür zwei par-Anweisungen (bzw. eine plus eine option:), und muß auf dem  denn eigentlich sollte man neuen und alten Wert vergleichen und das Attribut nur sezten, wenn was geändert wird, oder?
Aber ich brauche eigentlich den "echten Perl-Weg", weil sonst das Ersetzen der Parameter innerhalb der par:-Auswertung gar nicht klappen kann (also so, wie es jetzt in do_general_mqtt_cleanup gelöst ist)... Grübel... Muß also doch vermutlich irgendwie über die Reihenfolge gehen? Im Moment noch ratlos...

[rudolfkoenig]

Meine Vermutung: irgendwo wird da in der shelly-Variante ein eval dazwischengeschaltet, das den reinen Perl-Weg verhindert?

Seufz, Denkaufgabe am Abend. Dein Denkfehler ist, dass 'shellies/[^/]+/command' =~ m/$ign/ matcht. Wenn man $ign per "Log 1, $ign" ausgibt, dann merkt man, dass wg den anderen Templates $ign zu shellies/[^/]+/command|cmnd/[^/]+/|homeassistant/.*/config gewachsen ist => man muss die Reihenfolge tauschen: $ign =~ m/shellies.*command/.

Optionales Erweitern eines fremden Attributes, samt Umleitung des Frontends, als _TEIL_ eines weiteren Templates.
Ihr wollt es zu perfekt machen, und verkompliziert es soweit, dass keiner mehr durchblickt. Der Benutzer lernt auch nichts dazu, weil er die -zig Zeilen Text+Anweisung nicht durchliest bzw. versteht, und staunt nur (wie ich), dass die Anzeige nach Setzen von Attributen nicht wiederzuerkennen ist.

Ich (als Fan von rudimentaeren Loesungen) wuerde per farewell sagen, dass man ignoreRegexp im MQTT2_SERVER/CLIENT setzen kann (festkodiert, nur Text, kein Perl-Code, IO-Namen nicht aufgeloest).
Der Benutzer hat die Moeglichkeit beim IO-Device per attrTemplate einzelne Ignores hinzuzufuegen. Wenn er es zweimal macht, steht es Doppelt drin (selbst schuld), er hat ja die Moeglichkeit es zu entfernen.

Wenn Ihr doch auf die "perfekte Loesung" besteht, dann wuerde ich ein Hilfsmodul vorschlagen, da drin kann man passende Funktionen definieren, die Einzelheiten vom Benutzer verstecken, und man muss auch nicht um die (AttrTemplate-)Ecke denken.

[Beta-User]

Puh, also:

- Betr. der Frage, was denn jetzt bei dem Matching links und was rechts zu stehen hat, war ich auch unsicher und hatte das auch schon anders herum ausprobiert. Das Ergebnis war auch dann nicht befriedigend, soweit ich mich entsinne, und die jetzige Fassung bildet genau das nach, was das Modul auch macht. Kopfkratz...
(Ich hatte auch schon spekuliert, ob es an den Wildcards liegt, aber das erklärt nicht, warum der Tasmota-Teil sich anders verhält als der Shelly; zwischen diesen beiden besteht von den Regex-Inhalten her eigentlich kein wirklicher Unterschied...

- Über den Rest muß ich mal nachdenken. Vielleicht sollten wir hier tatsächlich nur auf das Netz zeigen, statt Fische zu liefern. Ich sehe nur zwei Probleme:
-- es gibt durchaus erfahrene Leute hier, die erst mal geneigt waren, insbesondere den Hinweis darauf, dass man den homeassistant-Zweig unbedingt verwerfen sollte, einfach nicht glauben wollten (=>sonos-Thread). Ergo vermute ich, dass das ein Dauerthema werden wird, den Leuten zu vermitteln, dass das wirklich Sinn macht. Und weiter ist es (mMn.) noch etwas schwieriger zu verstehen, dass man die set-Anweisungen aus anderen Quellen ebenfalls direkt rausfiltern sollte...
Von daher wäre die "rundum-sorglos-das-machen-wir-halt-einfach"-Variante für den Großteil der User passend, die sind halt verwöhnt , und ich hätte das "Mach's ggf. dazu"-template z.B. auch bei jeder Anwendung irgendeines Tasmota- oder Shelly-Templates intern mit aufgerufen (man kann ja nicht wissen, ob es schon gesetzt ist, bevor man es geprüft hat...), von daher ist das Argument " der user muß es ja nicht aufrufen" leider nur bedingt schlagend.
-- farewell ist eventuell teils ebenfalls schwierig umzusetzen (sorry, ja: wegen Pandora). Muß das mal intensiver beleuchten, aber wenn man bestimmte Templates (auch) intern verwenden will, kommt es da zu Konflikten, wenn ich das richtig im Kopf habe (ist mit ein Grund, warum ich davon eher spärlich Gebrauch mache).

Muß mal sehen, wie ich die Bausteinchen jetzt wieder für mich selbst sortiere. Vermutlich baue ich das erst mal aus dem MiLight- und zigbee-Ding wieder aus, bis klar ist, ob und wie es funktioniert.

[rudolfkoenig]

es gibt durchaus erfahrene Leute hier, die erst mal geneigt waren, insbesondere den Hinweis darauf, dass man den homeassistant-Zweig unbedingt verwerfen sollte, einfach nicht glauben wollten (=>sonos-Thread).

Das ist ok: wenn sie gegen die Wand laufen, dann hoeren sie das naechste Mal aufmerksamer zu.

Von daher wäre die "rundum-sorglos-das-machen-wir-halt-einfach"-Variante für den Großteil der User passend

Ich stimme dir zu, _es sei denn_ es ist nicht mehr einfach. Wenn ich damit mehr Aufwand habe, als 2-3 Antworten auf Beschwerden zu schreiben, dann ueberlege ich, ob es Wert ist. Ok, es gibt auch noch en Spieltrieb
Ich sehe AttrTemplate auch als HOWTO fuer Benutzer.
Wenn es zu kompliziert wird, dann ist dieser Effekt weg.

[Beta-User]

Das ist ok: wenn sie gegen die Wand laufen, dann hoeren sie das naechste Mal aufmerksamer zu.

(Die Hoffnung ist ja noch in der Büchse, vielleicht sollten wir die jetzt endlich mal rauslassen?)

Ich stimme dir zu, _es sei denn_ es ist nicht mehr einfach. Wenn ich damit mehr Aufwand habe, als 2-3 Antworten auf Beschwerden zu schreiben, dann ueberlege ich, ob es Wert ist. Ok, es gibt auch noch en Spieltrieb
Ich sehe AttrTemplate auch als HOWTO fuer Benutzer.
Wenn es zu kompliziert wird, dann ist dieser Effekt weg.

Bin geneigt, das auch so zu sehen, der jetzige Lösungsansatz ist auch etwas dem Spieltrieb geschuldet... Generell wäre dann eher die Frage, wie man die betreffenden Erkenntnisse konsolidiert und allg. (auch als anzupassende Beispiele) verfügbar macht. (Irgendwie: ab nach Praxisbeispiele... Ist halt nicht optimal für den englischsprachigen Teil der User... Na ja, Code ist international )
(Was die Funktion als "Howto" angeht, glaube ich, dass das relativ gut klappt. Zumindest habe ich diesen Eindruck, hoffe, der täuscht nicht .)

[pula]

Hi,

Beta-User hat in diesem Thread https://forum.fhem.de/index.php/topic,112242.0.html vorgeschlagen, hier weiterzumachen.
Ich möchte den Thread hier natürlich nicht karpern
Nach Durchlesen des gesamten Threads (das ist schon eine ganze Menge und für mich teilweise ziemlich undurchschaubar, weil ich in dieser Materie noch immer nicht drin bin) stellt sich mir die Frage, ob/wie es in der Zwischenzeit vielleicht schon möglich ist, eine MQTT_GENERIC_BRIDGE mit MQTT2 und aktiviertem autocreate zu betreiben?
Ich vermute, daß das eh irgendwo hier in dem Thread steht, aber ich konnte es nicht rauslesen.

Wenn ich irgendwie beim Testen helfen kann, mach ich natürlich gerne. Aber ich befürchte, daß ich dafür zuerst eine Anleitung brauche. Das Thema MQTT2 ist mittlerweile wirklich SEHR komplex geworden.
Danke im voraus und cheers,
Pula

[Beta-User]

stellt sich mir die Frage, ob/wie es in der Zwischenzeit vielleicht schon möglich ist, eine MQTT_GENERIC_BRIDGE mit MQTT2 und aktiviertem autocreate zu betreiben?

Ja, aber ich glaube, es stand eher in "deinem Thread" (vermutlich dort ziemlich am Anfang), wie es geht:
Einfach die bzw. eine bridgeRegexp so fassen, dass "" als "Pseudo-CID" rauskommt. Bitte melden, falls das zu kryptisch ist. Dann aber bitte möglichst mit Info über die konkreten Pfaden, die deine MGB nutzt.

[pula]

Ja, aber ich glaube, es stand eher in "deinem Thread" (vermutlich dort ziemlich am Anfang), wie es geht:
Einfach die bzw. eine bridgeRegexp so fassen, dass "" als "Pseudo-CID" rauskommt. Bitte melden, falls das zu kryptisch ist. Dann aber bitte möglichst mit Info über die konkreten Pfaden, die deine MGB nutzt.

Was ist eine Pseudo-CID? Wieder mal Bahnhof
Eigentlich ist mein "System" recht einfach. Das "Haupt"-fhem sendet mit der base fhem/ und das "Zweit"-fhem sendet mit der base fhem2/
Also die MGB auf dem Zweit-fhem sieht so aus:

Code Auswählen Erweitern

Internals:
   DEF        mqttBridge
   IODev      mqtt2
   NAME       myGenericMQTTBridge
   NTFY_ORDER 50-myGenericMQTTBridge
   STATE      dev: 3 in: 24773 out: 19361
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    .*
   prefix     mqttBridge
   READINGS:
     2020-06-30 15:58:16   device-count    3
     2020-07-01 17:35:41   incoming-count  24773
     2020-07-01 17:35:17   outgoing-count  19361
     2020-07-01 17:35:17   transmission-state outgoing publish sent
     2020-07-01 17:33:58   updated-reading-count 892
     2020-07-01 15:39:16   updated-set-count 3
   devices:
     :global:
       :defaults:
         pub:base   fhem2
         sub:base   fhem2
     SN658X06TE:
       :defaults:
         pub:base   {"$base/$device"}
         sub:base   {"$base/$device"}
       :publish:
         *:
           mode       R
           topic      {"$base/$reading"}
       :subscribe:
         HASH(0x562ebc399fd8)
     verowz:
       :defaults:
         pub:base   {"$base/$device"}
         sub:base   {"$base/$device"}
       :publish:
         *:
           mode       R
           topic      {"$base/$reading"}
       :subscribe:
         HASH(0x562ebda38480)
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
   subscribe:
Attributes:
   IODev      mqtt2
   globalDefaults base=fhem2
   icon       mqtt_bridge_2
   room       MQTT
   stateFormat dev: device-count in: incoming-count out: outgoing-count

Auf dieser Instanz müsste die regexp also irgendwas mit ^fhem/ sein, nehme ich an. Aber was das mit der Pseudo-CID heisst, ist mir nicht wirklich klar, sorry....
Cheers,
Pula

[Beta-User]

Du brauchst irgendein MQTT2_DEVICE, an das du die bridgeRegexp "hängen" kannst.
sowas sollte reichen:

Code Auswählen Erweitern

attr <das_Device> bridgeRegexp  [\b]fhem/.*:.* ""
(Das \b ist nur dazu da, dass entweder der Beginn oder eine vorhergehende "echte CID" erfaßt werden)

[pula]

Super, vielen Dank! Scheint jetzt mit autocreate simple zu funktionieren die MGB...
Cheers,
Pula

[Beta-User]

Hab's mal ins Wiki gepackt mit der bridgeRegexp und das Umfeld etwas umgestellt: https://wiki.fhem.de/wiki/MQTT#MQTT_GENERIC_BRIDGE_und_autocreate_bei_MQTT2-IO-Modulen

Wäre nett, wenn ihr (bzw. v.a. pula) mal drübersehen würdet und Rückmeldung geben, ob das so halbwegs verständlich ist bzw. einfach so nachgebaut werden kann. Weiter ist da die Rede davon, dass man auch für die MGB zwei weitere Perl-Module benötigen würde. Ich meine, das sei sachlich falsch und wir hätten das jüngst auch nochmal geklärt gehabt. Für eine entsprechende nochmalige Bestätigung wäre ich dankbar, dann verbanne ich den (berichtigten) Hinweis in eine Fußnote, damit sich nicht nochmal jemand bemüßigt fühlt, das zu "verbessern". Und ob der Text zu 00_MQTT wirklich so paßt, wäre eine weitere Frage. Denn dann könnte man auf die Auslieferung der Perl-libs unter https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/Net eigentlich verzichten, oder?