MQTT2 mehrere devicetopic per Attribut definieren

[rudolfkoenig]

Ich fasse zusammen:
DEVICETOPIC wird beim Empfang (readingList) und Senden (setList/getList) ersetzt.
Beim readingList kann DEVICETOPIC ein Regex sein, aber dann faellt die Optimierung der Topic-Suche flach. Beim Senden funktioniert Regex nicht (so, wie man denkt).
Beim readingList koennte man eine einfache Liste verwenden, das bedeutet je nach Fall mehr an Regex-Testen beim Empfang, beim Senden geht das nicht.

Mein aktueller Favorit ist die folgende, an plotReplace angelehnte (zusaetzliche!) Syntax:

Code Auswählen Erweitern

attr XX devicetopic VAR1=text1 VAR2=text2 ...
damit wuerde das Modul in den *List Attributen VAR1, VAR2, etc ersetzen.
Ob  bzw. wann text1 als perl-Skript evaluiert wird, weiss ich noch nicht.

Vorausgesetzt es gibt mindestens zwei Leute, die dafuer sind, und die Sinnhaftigkeit mit einem praktischen Beispiel belegen.

[betateilchen]

Mein aktueller Favorit ist die folgende, an plotReplace angelehnte (zusaetzliche!) Syntax:

Das wäre auch mein Favorit.

damit wuerde das Modul in den *List Attributen VAR1, VAR2, etc ersetzen.
Ob  bzw. wann text1 als perl-Skript evaluiert wird, weiss ich noch nicht.

Eine perl Evaluierung ist m.E. nicht notwendig, aber eine Evaluierung als String auf jeden Fall, da mqtt grundsätzlich Leerzeichen im topic erlaubt (ob das sinnvoll ist oder nicht, sei jetzt dahingestellt)

[Beta-User]

Detailfragen:
- <VAR1> und %VAR1% wie in plotreplace?
(Ich denke an die Shelly 2nd Gen., da muss uU. der "Sendekenner" individualisiert werden, wobei die "Startsequenz" für die zu versendenden JSON bis auf diesen Kenner identisch ist).

Also: in den .*List steht dann sowas wie

Code Auswählen Erweitern

%VAR1%/LWT:.* LWT\
%VAR2%/POWER1:.* state\

bzw.

Code Auswählen Erweitern

%tele%/LWT:.* LWT\
%stat%/POWER1:.* state\

- Die key/Value-Auswertung erfolgt mit parseParams?

Könnte hilfreich sein, kann andererseits aber dazu führen, dass eine Device-Beschreibung in MQTT2_DEVICE dann nochmal eine Ecke abstrakter wird und es dann z.B. dazu kommen kann, dass die öffnende Klammer zu einem JSON in VAR1 steckt und die schließende Klammer am Ende des verbleibenden Strings...

[rudolfkoenig]

- <VAR1> und %VAR1% wie in plotreplace?

Wenn Du mir sagst, was "vorher" und "nachher" hier sein soll....

Könnte hilfreich sein, [...]

War das ein "Ja, ich will es auch"?

[Beta-User]

Wenn Du mir sagst, was "vorher" und "nachher" hier sein soll....

In der .gplot Datei wird <Name> und %Name% durch den zugehörigen Wert ersetzt, wobei <Name> nach der Extraktion der Logdaten ersetzt wird, damit man auf Werte wie $data{min1} zugreifen kann, und %Name% davor, damit man die Regeln in der .gplot Datei für die Extraktion anpassen kann.

"Vorher" = Ersetzung von %Name% in einem ersten Durchlauf, "nachher" = Ersetzung von <Name> in einem zweiten Durchlauf.

Dann sähe das aktuelle "shellyPlus_1"-attrTemplate in etwa so aus:

Code Auswählen Erweitern

attr DEVICE devicetopic BASE=DEV_TPC SRC=fhem2shelly CMD='{"id":0,"src":"<SRC>","method":"Switch.' CMD1='","params": {"id":0'
attr DEVICE setList\
  toggle:noArg %BASE%/rpc %CMD%Toggle%CMD1%}}\
  off:noArg %BASE%/rpc %CMD%Set%CMD1%,"on":false}}\
  on:noArg %BASE%/rpc %CMD%Set%CMD1%,"on":true}}\
  on-for-timer %BASE%/rpc %CMD%Set%CMD1%,"on":true,"toggle_after":$EVTPART1}}

War das ein "Ja, ich will es auch"?

a) habe ich den Eindruck, dass das Ganze längst beschlossene Sache ist
b) will ich rechtzeitig darauf hingewiesen haben, welche (vermutlich für die allermeisten User schlicht unleserlichen!) Ergebnisse man dann am Ende erwarten darf...

An sich finde ich es ja hilfreich, wenn Schreibarbeit gespart wird, ggf. weniger Änderungen an einer zentralen Stelle ausreichen (auch für attrTemplate) und die Darstellung kompakt ist, aber wenn die Nachvollziehbarkeit dann komplett auf der Strecke bleibt, ist mir andererseits überhaupt nicht wohl... Das animiert eventuelle Helfer auch nicht unbedingt zum "Mitmachen".
Klar "muss" man das nicht auf diese Weise machen, CMDTOPIC etc. bei Tasmota wären ggf. auch einfachere Beispiele, wo dann an einer zentralen Stelle die "Klartext"-Varianten stehen könnten und sich das "vorher/nachher"-Thema nicht stellt. Andererseits handelt es sich m.E. auch nur um "Einmal-Tippereien", die einem attrTemplate auch weitestgehend abnehmen kann. Das minimiert die "Dringlichkeit" auch deutlich.

Anders gesagt: Macht, was ihr wollt, aber wenn, dann "richtig"...

[rudolfkoenig]

Ich habe jetzt eine Version eingecheckt. Ersetzt wird $XXX, damit es zu $DEVICETOPIC "kompatibel" bleibt, ohne eine Vorher-Nachher Logik, da ich die Vorteile nicht sehe, dafuer aber die Verwirrung.
Ich hoffe, dass diese Aenderung nicht zu solch unverstaendlichen Code fuehren wird, wie im vorherigen Beispiel.

Die Doku:

devicetopic value

• if value does not contain an equal sign (, replace $DEVICETOPIC in the topic part of the readingList, setList and getList attributes with value.
  
• if the value does contain an equal sign (, then it is interpreted as
  Var1=Var1Value Var2="Value with space" Var3=...
  and $Var1,$Var2,$Var3 are replaced in the readingList, setList and getList attributes with the corresponding value.
  Note: the name Var1,etc must only contain the letters A-Za-z0-9_.
• If the attribute is not set, $DEVICETOPIC will be replaced with the name of the device in the attributes mentioned above.

Anders gesagt: Macht, was ihr wollt, aber wenn, dann "richtig"...

Na toll

[betateilchen]

funktioniert hervorragend, danke!