FHEM2MQTT2FHEM ... und seine Hürden

[TomLee]

zum letzten update:


Wende ich das MQTT2_IO_ignoreRegexp_tasmota-Template an wird immer der regex

Code Auswählen Erweitern

cmnd/[^/]+/ in ignoreRegexp geschrieben egal ob vorher was drin stand.
Wenn ich{ InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) } über die Befehlszeile prüfe ist alles korrekt.
Wenn ich{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",'cmnd/[^/]+/');; $old = $old.'|cmnd/[^/]+/' if $old !~ m,cmnd/[^/]+/, ;; return $old } prüfe, dann seh ich das immer der Ersatzwert genommen wird, komm nicht drauf hab mit ' und " schon gespielt.


Am besten schaust dir den Rest selbst nochmal an irgendwas musst ja grundlegend geändert haben, das nichts so richtig klappt:

Wende ich das MQTT2_IO_ignoreRegexp_shelly-Template an wird immer der regex zweimal

Code Auswählen Erweitern

shellies/[^/]+/command|shellies/[^/]+/command in ignoreRegexp geschrieben egal ob vorher was drin stand, also praktisch immer dem Ersatzwert nochmal der regex angehängt.

Wende ich das MQTT2_IO_ignoreRegexp_homeassistant an kommt das Dialogfeld

Code Auswählen Erweitern

ERROR executing perl-code { my $old =  AttrVal("IODEVNAME","ignoreRegexp",undef);; !defined $old ? 'homeassistant/.*/config:.*' : homeassistant/.*/config =~ m,$old, ? $old : $old.'|homeassistant/.*/config'  } for param NEWIGNOREREGEXP: syntax error at (eval 6282) line 1, near "/."
Im Log steht

Code Auswählen Erweitern

2020.06.28 08:49:00 1: PERL WARNING: Bareword found where operator expected at (eval 6282) line 1, near "*/config"
2020.06.28 08:49:00 1: PERL WARNING: (Missing operator before config?)

weder bei der zigbee2mqtt noch der milight-Bridge wird jetzt die BASE_ID/BASE_TOPIC ausgelesen, kommt das Dialogfeld.

Wende ich das milight-Bridge Template an wird der korrekte regex

Code Auswählen Erweitern

milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]  in ignoreRegexp eingetragen, aber nicht angehängt wenn ein alter Wert vorhanden war.

Wende ich das z2m-Bridge Template an wird  ADD_TO_IO_IGNOREREGEXP in ignoreRegexp eingetragen.

[Beta-User]

Stimmt im Prinzip, nur im Detail nicht
Die Zuordnung macht fhem.pl in AssignIoPort, was ueblicherweise aus dem Modul-eigenen DefineFn aufgerufen wird. Falls $proposed nicht gesetzt ist, wird die zuletzt definierte "passende" IO-Geraet zugewiesen, auch wenn sie noch nicht in fhem.cfg steht.

Danke für die Klarstellung.

Da wir es zunehmend mit Installationen zu tun haben, die nicht nur (einen) MQTT2_SERVER nutzen, sondern ggf. mehrere (z.B. aktuelles Stichwort "bumper") und Mischungen auch mit MQTT2_CLIENT für externe Server/Broker: Wäre es ein großer Aufwand, bei autocreate das $proposed sinnvoll zu setzen?

@Beta-User: wg. dem "Kopfzerbrechen": kannst Du mir bitte das Problem nochmal schildern, gerne mit einem konkreten Beispiel?

Als hartes "Problem" kann man das mAn. nicht bezeichnen, das ist mehr ein "atmosphärisches" Thema. Du hast einige features gebastelt, damit der User möglichst vorher sieht, was ein bestimmtes Template macht, ohne in den Quelltext sehen zu müssen. Die teils indirekten Aufrufe, die ich (vor allem zur Vermeidung allzugroßer Redundanzen und zur Verringerung möglicher Fehlerquellen) reingebaut habe, hast du (zurecht) als (im Sinne der Transparenz) zweischneidig angesehen.

Im Ergebnis war das ok, denn der Anwender hat spätestens nach Anwendung der Templates gesehen, was eigentlich passiert ist, er hatte das fertige Device ja gesehen. Die Auswirkungen waren (fast) immer auf das eigentliche Device begrenzt.

Eine kleine Aunahme waren schon lange die Tasmota-templates, die auch Änderungen in der Konfiguration auf dem Microcontroller bewirken. Aber auch das ist  über die desc: vorab kommuniziert und scheint allg. akzeptiert zu sein. Und auch das beschränkt sich auf das eigentliche Device und die zugehörige Hardware.

Bei den zwischendurch aufgerufenen ("indirekten") templates war es meistens auch so, dass man die gesondert über FHEMWEB ansehen konnte, wenn man wollte. Auch noch transparent, wenn auch nicht mehr komfortabel oder "übersichtlich".

Mit verarbeitet werden aber seit einiger Zeit auch die templates aus  speechcontrol.template und general_use.template - und die sieht man normalerweise nicht, weil der filter: sehr speziell ist. Ist zwar nicht dramatisch, was da passiert, und aus dem Aufruf kann man schon in etwa erraten, was da passiert.
Wenn du ein Beispiel für diese Kaskade suchst, kannst du ja mal dem Pfad von shelly25_split folgen.

Jetzt kommt aber mit diesen automatischen ignoreRegepx-Erweiterungen was hinzu, was sich auf ein ganz anderes Device auswirkt, nämlich das IO. Auch das dürfte sinnvoll sein (die Frage ist mMn. noch nicht abschließend beantwortet, aber das ist was, was sich eher an die User richtet), aber transparent ist es nicht (da via filter: ebenso versteckt wie die aus den anderen files). Diese Art template auch per default anzuzeigen dürfte aber die Mehrzahl der user verwirren; die interessieren sich eigentlich nicht für die Feinheiten, und ohne Parameter kann man die (überwiegend) auch nicht sinnvoll verwenden.

Hinterher für Transparenz zu sorgen, indem man z.B. mit show auch das IO mit anzeigt, ginge zwar prinzipiell, aber eben nicht in allen Fällen (bei mehrkanaligen müßte man sonst immer das IO mit ermitteln, kann aber nicht wissen, ob ignoreRegexp geändert wurde), und der geneigte "Normaluser" wird auch nicht verstehen, wieso er auch das IO angezeigt bekommt.

Ergo überlege ich eben grade, wie man die betreffenden, heute mit dem "filter:NAME=speechrecognTesting" ausgeblendeten Templates irgendwie transparenter machen könnte, ohne den User auf den Quelltext (in welcher Datei...?) zu verweisen. Eine Lösung könnte eben in einer Art Expertenmodus bestehen, in dem diese auch ganz normal über FHEMWEB bzw. das attrTemplate-Auswahl-dropDown angezeigt würden?

Nein.

Danke für die Rückmeldung, dann ist insoweit keine "action required" .


Das mit den ignoreRegexpes muß ich mir gesondert nochmal ansehen, vermute, ich habe da irgendwas durcheinandergewürfelt ; Danke erst mal für die Rückmeldung!

[TomLee]

Wenn ich{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",'cmnd/[^/]+/');; $old = $old.'|cmnd/[^/]+/' if $old !~ m,cmnd/[^/]+/, ;; return $old } prüfe, dann seh ich das immer der Ersatzwert genommen wird, komm nicht drauf hab mit ' und " schon gespielt.

Falsch.

Code Auswählen Erweitern

{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",'cmnd/[^/]+/');; $old = $old.'|cmnd/[^/]+/' if $old !~ m,cmnd/[^/]+/, ;; return $old }
gibt in der Befehlszeile genau das zurück was es soll.
Wenn zuvor bspw. shellies/[^/]+/command (händisch eingetragen) in ignoreregexp drin stand dann shellies/[^/]+/command|cmnd/[^/]+/ sonst nur cmnd/[^/]+/

Nur wenn man das Template anwendet dann landet immer nur cmnd/[^/]+/ ohne dem alten Wert in ignoreregexp, also habe ich den Verdacht das der Ersatzwert genommen wird.
Trotz das

Code Auswählen Erweitern

{ InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) } über die Befehlzeile korrekt den Namen des MQTT2_CLIENT ausgibt.


oder noch anders dargestellt :

Code Auswählen Erweitern

{ my $ioc =  InternalVal("MQTT2_mygateway1","LASTInputDev",AttrVal("MQTT2_mygateway1","IODev",undef));; my $old =  AttrVal("$ioc","ignoreRegexp",'cmnd/[^/]+/');; $old = $old.'|cmnd/[^/]+/' if $old !~ m,cmnd/[^/]+/, ;; return $old }

aus der Befehlszeile ergibt shellies/[^/]+/command|cmnd/[^/]+/

das gleiche aus dem Template cmnd/[^/]+/

[rudolfkoenig]

Wenn du ein Beispiel für diese Kaskade suchst, kannst du ja mal dem Pfad von shelly25_split folgen.

Ab sofort werden beim gesetzten "attr global showInternalValues 1" in FHEMWEB die attrTemplate Inhalte rekursiv angezeigt. Nach dem Anblick des Inhalts bei shelly25_split wollte ich mich in Pandora umbennen

[TomLee]

Die basic/tasmota/shelly/homeassistant-ignoreregexp-Template tun jetzt ihren Dienst.

Bei den beiden Bridge-Templates bleibts beim Dialogfeld und bei beiden bleibt ignoreregexp unangetastet, es passiert nichts.

[Beta-User]

Ab sofort werden beim gesetzten "attr global showInternalValues 1" in FHEMWEB die attrTemplate Inhalte rekursiv angezeigt. Nach dem Anblick des Inhalts bei shelly25_split wollte ich mich in Pandora umbennen

Na ja, ich hatte ein etwas extremes Beispiel gewählt, aber es gibt den Energy-messenden Shelly auch noch in 4-fach ...

Die Idee mit der rekursiven Anzeige gefällt mir jedenfalls gut!


Ansonsten habe ich jetzt nochmal die mqtt2.template aktualisiert, damit sollten die meisten der seltsamen Effekte weg sein, leider nicht alle (irgendwie wollte kommt es immer noch zu Doppeleinträgen beim Versuch, die MiLight-ignoreRegexp zu prüfen, aber immerhin scheint der Rest zu funktionieren...).
(Da gab es bei mir @MiLight einen Fehler, der auch im Log steht; hatte mit den übergebenen Quotes zu tun; jetzt ist "Saft alle", mache ggf. irgendwann später weiter; evtl. hat ja bis dahin noch jemand eine zündende Idee, an was es liegt? Die "/" in den Pfaden sind es eher nicht? Evtl. bei MiLight die {} bei den Wiederholungen? (Könnte man in [] packen...)).

[TomLee]

So klappts bei mir beim do_general_mqtt_cleanup Template bei dem ADD_TO_IO_IGNOREREGEXP vor dem match mussten die ' weg.

Code Auswählen Erweitern

{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp",'ADD_TO_IO_IGNOREREGEXP');;ADD_TO_IO_IGNOREREGEXP =~ m{($old)} ? $ old : $old.'|ADD_TO_IO_IGNOREREGEXP' }

Bei Milight wird plötzlich kein Dialogfeld mehr angezeigt, ignoreregexp passt auch.
Bei z2m kommt noch das Dialogfeld.

Man kann das basic/tasmota/homeassistant-ignoreregexp-Template noch mal anwenden das kein Problem wenn der regex schon vorhanden war wird das erkannt.
shelly und die zwei Bridge-Templates fügen dann nochmal den regex an (ohne alten Wert)

[Beta-User]

Hmm, irgendwie irritierend mit dem zigbee2mqtt-Ding. Evtl. müssen wir da noch Leerzeichen abfangen?
(Zeile 113):

Code Auswählen Erweitern

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

Bie MiLight konnte ich das testen, da habe ich die regex angepaßt, daher sollte das "eigentlich" jetzt passen (es fügte allerdings immer die regex nochmal zu ignoreregex dazu, aber evtl. ist das dasselbe Problem mit den Quotes, s.u.)


Ansonsten bin ich etwas unsicher: Bezieht sich deine Rückmeldung auf 22296 oder die Version davor? Bei der vorherigen Version hatte ich auch die Anführungszeichen mit übergeben, was in Kombination mit diesen weiteren Quotes in der von dir geposteten Zeile zu Problemen geführt hatte. Aber wenn das mit dem Weglassen des Rätsels Lösung wäre, wären wir einen großen Schritt weiter!

[TomLee]

Ja das war auf 22296 bezogen, aber auch wieder hinfällig.

Es stimmt doch irgendwas grundsätzlich nicht.

Zum Test lösche mal immer nachdem du das Milight-Bridge Template mit dem u. a.  Code in Zeile 100 aufrufst (ans Ende des Template hab ich zum testen ein save angehängt) die ignoreregexp im MQTT2_CLIENT, das Template also immer nur anwenden wenn nichts in ignoreregexp steht.
Du bekommst willkürlich immer was anderes zurück, mal ist es ADD_TO_IO_IGNOREREGEXP mal der regex selbst milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]

{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp",'ADD_TO_IO_IGNOREREGEXP');; 'ADD_TO_IO_IGNOREREGEXP' =~ m{($old)} ? $old : $old.'|ADD_TO_IO_IGNOREREGEXP' }

Sry so

Code Auswählen Erweitern

{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp","ADD_TO_IO_IGNOREREGEXP");; "ADD_TO_IO_IGNOREREGEXP" =~ m{($old)} ? $old : $old.'|ADD_TO_IO_IGNOREREGEXP' }

[Beta-User]

Du bekommst willkürlich immer was anderes zurück, mal [...]

@Rudi: wenn ich was von einem zufälligen Verhalten lese, klingt bei mir immer die Frage nach, ob irgendwo ein Hash durchgegangen wird. Das ist zwar der Fall, aber alle substitutions, die ich auf die Schnelle in AttrTemplate.pm gefunden habe, waren mit dem /g modifier. Hmm, aber:
Es kann dann vorkommen, dass der eine par: noch nicht aufgelöst wurde, wenn er innerhalb der nächsten par:- Anweisung benötigt würde...?!? Dann bleibt einfach der Text "as is" intern gespeichert?

Wenn das so ist, müssen wir uns was anderes überlegen und diese Art der Ergänzung ggf. über eine option:-Kaskade abfangen...?

Und die regex mit den geschweiften Klammern: Ist die ok, oder sollte man zur Sicherheit was einfacheres nehmen? Z.B.

Code Auswählen Erweitern

milight/0x[0-9a-fA-F]+/.*/[0-8]

[rudolfkoenig]

Die Parameter sind in einem Array gespeichert, da ist die Reihenfolge konstant.
Kannst Du bitte ein "Howto zum Nachstellen" liefern?

[Beta-User]

Zum Test lösche mal immer nachdem du das Milight-Bridge Template mit dem u. a.  Code in Zeile 100 aufrufst (ans Ende des Template hab ich zum testen ein save angehängt) die ignoreregexp im MQTT2_CLIENT, das Template also immer nur anwenden wenn nichts in ignoreregexp steht.
Du bekommst willkürlich immer was anderes zurück, mal ist es ADD_TO_IO_IGNOREREGEXP mal der regex selbst milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]

Sry so

Code Auswählen Erweitern

{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp","ADD_TO_IO_IGNOREREGEXP");; "ADD_TO_IO_IGNOREREGEXP" =~ m{($old)} ? $old : $old.'|ADD_TO_IO_IGNOREREGEXP' }

Kann ich auf folgender Basis bestätigen:

FHEM@Win nach update neu gestartet (=alle Module+templates aktuell)

Start mit:

Code Auswählen Erweitern

defmod MQTT2_FHEM_Server MQTT2_SERVER 1883 global
(kein ignoreRegexp) und

Code Auswählen Erweitern

define Milight_Bridge MQTT2_DEVICE milight_hub_1370325
attr Milight_Bridge IODev MQTT2_FHEM_Server
attr Milight_Bridge autocreate 1
attr Milight_Bridge bridgeRegexp milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr Milight_Bridge devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr Milight_Bridge group Interfaces
attr Milight_Bridge icon mqtt
attr Milight_Bridge model esp_milight_hub_bridge
attr Milight_Bridge readingList milight/LWT:.* { json2nameValue($EVENT) }
attr Milight_Bridge room Steuerung->Interfaces
attr Milight_Bridge setStateList on off
attr Milight_Bridge stateFormat <a href="http://ip_address" target="_blank">\\nstatus\\n</a>Version: \\nversion

setstate Milight_Bridge <a href="http://192.168.2.96" target="_blank">\\nconnected\\n</a>Version: \\n1.10.6
setstate Milight_Bridge 2020-06-28 15:56:02 attrTemplateVersion 20200628
setstate Milight_Bridge 2020-06-28 17:20:18 firmware milight-hub
setstate Milight_Bridge 2020-06-28 17:20:18 ip_address 192.168.2.96
setstate Milight_Bridge 2020-06-28 17:20:18 reset_reason Software/System restart
setstate Milight_Bridge 2020-06-28 17:20:18 status connected
setstate Milight_Bridge 2020-06-28 17:20:18 version 1.10.6

darauf dann

Code Auswählen Erweitern

set Milight_Bridge attrTemplate esp_milight_hub_bridge

ergibt:

Code Auswählen Erweitern

attr MQTT2_FHEM_Server ignoreRegexp ADD_TO_IO_IGNOREREGEXP

template nochmal angewendet ergibt:

Code Auswählen Erweitern

attr MQTT2_FHEM_Server ignoreRegexp milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]

attr@MQTT2_FHEM_Server gelöscht, nochmal angewendet ergibt wieder

Code Auswählen Erweitern

attr MQTT2_FHEM_Server ignoreRegexp milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]
Ergo: sehe auch keine wirkliche Regel...

EDIT: Hab's noch ein paar Mal durchgespielt und es dabei wirklich auf völlig willkürlich scheinende Ergebnisse gebracht: U.A. bis auf 4x die gewollte regexp am Stück, Wechsel zwischen ADD_TO_IO_IGNOREREGEXP und dem eigentlichen Ziel, Kobinationen davon, nach löschen mal das eine, mal das andere... Wirklich keinerlei Regel zu erkennen.

[rudolfkoenig]

- Parameter werden in Parameter nicht ersetzt.
- die Ersetzung der Parameter in Befehlen passiert in einer nicht deterministischer Reihenfolge (keys %repl)

In Eurem Beispiel definiert ihr (u.a.) die Parameter

ADD_TO_IO_IGNOREREGEXP = milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]
NEWIGNOREREGEXP = ADD_TO_IO_IGNOREREGEXP

und das fragliche Befehl ist "attr IODEVNAME ignoreRegexp NEWIGNOREREGEXP"
Wenn als erstes im Befehl NEWIGNOREREGEXP ersetzt wird (durch ADD_TO_IO_IGNOREREGEXP), dann wird daraus im naechsten Schritt milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]. Falls die Reihenfolge andersrum ist, dann bleibt es bei ADD_TO_IO_IGNOREREGEXP.

Ich habe jetzt die Ersetzung deterministisch gemacht (per sort), damit koennte man bei geeigneten Namenswahl sowas aehnliches wie Parameterersetzung betreiben.
Ich frage mich aber, wieso ihr das Problem nicht mit einem (mehrzeiligen?) Perl-Code-Abschnitt loest, anstelle von 3 par: und eine option: Zeile.

[Beta-User]

Nun ja, bisher war mir nicht so ganz bewußt gewesen, dass das ein Problem darstellt, weil eben das meiste linear von oben nach unten abläuft, und sowas verschachteltes auf der anderen Seite bisher eher selten "gebraucht" wurde.

Vermutlich ist es tatsächlich das einfachste, das meiste bzw. den eigentlichen CommandAttr() direkt in Perl mit echten Variablen abzubilden. Ist dann zwar noch weniger attrTemplate-like, aber das ist sowieso eine sehr spezielle Ecke, oder...? Dass da die Parameter-Namen auch eine Rolle spielen könnten, habe ich nämlich vermutlich in einer Woche vergessen .

(Vielleicht kommt am Ende doch noch die Hoffnung aus der Büchse?)

(Wird ein bißchen dauern, bis ich das betreffende update dann im Kasten haben werde).

@TomLee: irgendwelche Rückmeldungen zu dem Leerzeichen bei zigbee2mqtt?

[TomLee]

Ich komm nicht mit wo welche Leerzeichen abgefangen werden sollten, es gibt mMn keine.

Mir kommts so vor als sollte das eine Prüfung sein ob ich mitdenke 

Dir muss doch klar sein das die / escaped gehören 

22296 Zeile 113

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 }

hab keine Zeit, eine ignorregexp wird noch nicht eingetragen.