Das Attribut devicetopic bei MQTT2_DEVICE ist zwar nett, aber wenn man ein device verwendet, um per readingList readings aus mehreren "Quellen" zu erzeugen, kann man das über $DEVICETOPIC nur für eine Quelle umsetzen. Da vermisse ich manchmal die Möglichkeit, das Attribut devicetopic beispielsweise als kommagetrennte Liste angeben zu können.
Oder einen replace-Mechanismus, wie er ziemlich genial in 98_SVG.pm mit plotReplace umgesetzt ist. Irgendetwas in der Art wie:
attr <device> devicetopic dt1={"devicetopic1"} dt2={"devicetopic2"}
attr <device> readingList <dt1>/dev1reading1:.* myreading1\
<dt2>/dev2reading1:.* myreading2
Ja, ich weiß, es ist ein Luxusproblem. Aber ich merke mir das schonmal für meinen nächsten Weihnachtswunschzettel vor.
Die Variante mit der kommagetrennten Liste verstehe ich nicht: durch welches Element der Liste soll DEVICETOPIC ersetzt werden?
Bei der zweiten Variante: {".."} klingt nach Perl-Evaluierung: wann soll das stattfinden? DEVICETOPIC ist mAn performance-kritisch.
Nach dem ersten Blick ist der Umbau des Wertes auf eine Liste relativ aufwendig, samt Fehlerpotential.
Gibt es noch weitere Benutzer, denen das helfen wuerde?
Zitat von: rudolfkoenig am 10 März 2022, 19:23:59
Die Variante mit der kommagetrennten Liste verstehe ich nicht: durch welches Element der Liste soll DEVICETOPIC ersetzt werden?
Szenario: In meinem Carport gibt es ein abgesetztes FHEM, dort werden diverse Daten gesammelt und per MQTT verschickt. Es gibt unter anderem einen Temperatursensor (devicetopic=/sensor1/temperatur) und einen Regensensor (/sensor2/regen) die unterschiedliche Werte melden.
Auf der "Gegenseite" gibt es ein FHEM, das in einem MQTT2_DEVICE mit dem Namen "Carport" alle diese Werte empfängt und in readings darstellt.
Jeder der Sensoren sendet also mit seinem individuellen devicetopic, und auf der Empfangsseite soll readingList nachschauen, ob $DEVICETOPIC auf einen der in der Liste stehenden Werte passt. Der Regensensor wird keinen Wert "temp_aussen" liefern, umgekehrt liefert auch der Temperatursensor keine Regenmenge. Insofern sollte die Zurodnung n:1 konfliktfrei möglich sein.
attr Carport devicetopic "/sensor1/temperatur","/sensor2/regen"
attr Carport readingList $DEVICETOPIC/temp_innen:.* temp_innen\
$DEVICETOPIC/temp_aussen:.* temp_aussen\
$DEVICETOPIC/israining:.* is_raining
$DEVICETOPIC/rain_amoint:.* amount
Zitat von: rudolfkoenig am 10 März 2022, 19:23:59
Bei der zweiten Variante: {".."} klingt nach Perl-Evaluierung: wann soll das stattfinden? DEVICETOPIC ist mAn performance-kritisch.
Ob es eine perl-Evaluierung tatsächlich braucht, weiß ich nicht genau, vermutlich nicht. Die Syntax hatte ich einfach aus plotReplace kopiert.
ZitatDer Regensensor wird keinen Wert "temp_aussen" liefern, umgekehrt liefert auch der Temperatursensor keine Regenmenge. Insofern sollte die Zurodnung n:1 konfliktfrei möglich sein.
Der Haken sind Situationen, wo sie nicht konfliktfrei ist. Bedeutet weiterhin, dass man in der Optimierung fuer jede Permutation einen Eintrag anlegen muss => ich wuerde diese Variante erstmal hinten anstellen. Interessant ist sie trotzdem, ich merke sie fuer andere Faelle :)
Zitat von: rudolfkoenig am 11 März 2022, 11:02:14
Der Haken sind Situationen, wo sie nicht konfliktfrei ist.
In diesem Fall liegt die Verantwortung zur Auflösung des Konflikts aber m.E. beim Anwender.
Wenn man 10 Steckdosen hat, die alle die gleichen readings erzeugen, kann man halt nicht mit dem multiplen $DEVICETOPIC arbeiten, wenn man diese alle in einem gemeinsamen Ziel-device abbilden will.
Ungetestet: Empfangsseitig solle es als geklammerte oder-regex gehen. Das Problem beginnt beim Versenden (setList/getList). Da sollte es m.E. eindeutig sein.
Befürchte Verwirrung bei weniger erfahrenen Anwendern.
Grundsätzlich muss niemand eine Liste als devicetopic benutzen, das bisherige Verhalten mit einem eindeutigen devicetopic würde nicht verändert.
Aber als Benutzer mit jeder Menge MQTT devices, die ausschließlich Daten empfangen und weder setList noch getList brauchen/besitzen, fände ich die Möglichkeit einer Liste von devicetopics durchaus nützlich.
Zitat von: Beta-User am 11 März 2022, 17:41:31
Befürchte Verwirrung bei weniger erfahrenen Anwendern.
Du willst aber jetzt nicht ernsthaft sagen, dass FHEM in allen anderen Punkten für weniger erfahrene Anwender nicht verwirrend ist?
Eben das hier kurz angetestet (mit readingList aus deinem Post):
attr Carport devicetopic (/sensor1/temperatur|/sensor2/regen)Das scheint zu funktionieren wie gewünscht.
Zitat von: betateilchen am 11 März 2022, 19:03:42
Du willst aber jetzt nicht ernsthaft sagen, dass FHEM in allen anderen Punkten für weniger erfahrene Anwender nicht verwirrend ist?
Nein, aber man muss auch nicht "ohne Not" an den Stellen für Verwirrung sorgen, die bisher recht eindeutig waren: devicetopic ist im Kern eben "der eine Topic (-Teil)", der für dieses Device "kennzeichnend" ist. Das "kennzeichnend" würde ich als eindeutig verstehen, weil es eben universell in beide Richtungen gelten sollte. Ist aber nur meine Meinung, muss man nicht teilen.
Zitat von: Beta-User am 14 März 2022, 10:32:18
devicetopic ist im Kern eben "der eine Topic (-Teil)", der für dieses Device "kennzeichnend" ist.
devictopic wird im Kommunikationsablauf vom Absender bestimmt und nicht vom Empfänger.
Insofern kennzeichnet devicetopic in der payload die
verschickten Daten eindeutig, nicht die auf Empfangsseite auszuwertenden Daten.
Vielleicht ist auch schlicht der Attributname unglücklich gewählt, weil er auf beiden Seiten (Sender und Empfänger) unterschiedliche Bedeutungen hat und auf der Senderseite eindeutig sein sollte, dies aber auf der Empfängerseite nicht unbedingt notwendig ist.
Zitat von: Beta-User am 14 März 2022, 10:32:18
Eben das hier kurz angetestet (mit readingList aus deinem Post):
Das scheint zu funktionieren wie gewünscht.
Das weiß ich. Aber daß das funktioniert, ist eher "zufällig" und in dieser Form eigentlich nicht zur Nutzung vorgesehen.
Das setzt gedanklich voraus, dass es einen "Absender" und einen "Empfänger" gibt. Das ist aber m.E. in der MQTT-Welt nicht eindeutig zu klären, denn mal ist der eine der an der Kommunikation Beteiligten der "originäre Absender", mal ein anderer - potentiell kommen als "Absender" sogar beliebig viele Teilnehmer in Frage.
Klar kann man einwenden, dass in der Regel ein "relativ dummer Partner" (wie z.B. eine ESP-basierte Hardware) eine Art "Vorgabe" machen wird, wie es seine individuellen Topics strukturiert, an die es sendet und unter denen es empfängt, und das daher der "Sender" sei.
Wie man es dreht und wendet: "devicetopic" ist m.E. kein allgemeingültiger MQTT-Begriff und dient in FHEM einfach dazu, "harte individuelle" Bestandteile der Topic-Struktur eines Kommunikationspartners als Variable notieren zu können. Von daher ist die Angabe einer regex für rein "sendende" Gegenstellen m.E. auch kein "Zufall", regex in der readingList ist jedenfalls keine komplette Ausnahme sondern (in FHEM) relativ weit verbreitet.
Ergänzend: Dass ein Adressat die Absenderidentität kennt (CID), ist eher die komplette Ausnahme, in der Regel wird ein "Teilnehmer" durch die Topicstruktur identifizierbar.
Nach meinem Dafürhalten ist es sogar deutlich mehr innerhalb des eigentlichen Zwecks des Attributs wie der Vorschlag, mehrere Varianten per Komma oä. zu trennen. Kann man sicher auch anders sehen, aber wenn man was in Richtung mehrerer Varianten macht, müßte es m.E. in die Richtung gehen, dass getrennte Optionen für Sende- und Empfangsrichtung vorgesehen sind (ähnlich dem, was MQTT_GENERIC_BRIDGE mit den sub: und pub:-Präfixen kennt).
Zitat von: Beta-User am 15 März 2022, 10:26:00
Von daher ist die Angabe einer regex für rein "sendende" Gegenstellen m.E. auch kein "Zufall", regex in der readingList ist jedenfalls keine komplette Ausnahme
Wir reden hier nicht von regex in der readingList, sondern im Attribut devicetopic. Und in diesem Attribut ist laut Attributbeschreibung definitiv keine regex vorgesehen:
replace $DEVICETOPIC in the topic part of readingList,Hier wird also erstmal von einem eindeutigen Wert ausgegangen, denn eine regex kann man nicht als
Wert für eine Ersetzung verwenden.
Zitat von: Beta-User am 15 März 2022, 10:26:00
wenn man was in Richtung mehrerer Varianten macht, müßte es m.E. in die Richtung gehen, dass getrennte Optionen für Sende- und Empfangsrichtung vorgesehen sind
ja, man könnte auch statt devicetopic zwei Attribute verwenden, z.B. sendtopic und receivetopic, diese könnte man dann als Listen gestalten und ähnlich wie bei $EVENTPARTx verwenden.
Zitat von: Beta-User am 15 März 2022, 10:26:00
sondern (in FHEM) relativ weit verbreitet.
Auch kommagetrennte (oder leerzeichengetrennte oder mit semikolon getrennte) Listen sind in FHEM relativ weit verbreitet, wenn auch nicht einheitlich geregelt.
:) Interessant, dass da nur von readingList die Rede ist, es funktioniert generisch nämlich auch in setList und getList...
@Rudi: Magst du das in der commandref anpassen...? Oder ist das ein "undokumentiertes feature"?
Ansonsten: Wir reden auch nicht von precompiled regex im Attribut, sondern erst mal "text". Der wird erst nach der Ersetzung durch die Auswertung der readingList als regex interpretiert, was dir vermutlich schon klar ist. In die umgekehrte Richtung funktioniert es damit selbstredend nicht.
Was "noch mehr Attribute" angeht: Falls das eine Art Abstimmung ist, die hier läuft: bin dagegen, KISS.
Zitat von: Beta-User am 14 März 2022, 10:32:18
aber man muss auch nicht "ohne Not" an den Stellen für Verwirrung sorgen
Inzwischen bist Du aber hier derjenige, der Verwirrung stiftet.
Zitat von: Beta-User am 15 März 2022, 10:54:50
Interessant, dass da nur von readingList die Rede ist, es funktioniert generisch nämlich auch in setList und getList...
Da ist nicht nur von readingList die Rede...
devicetopic value
replace $DEVICETOPIC in the topic part of readingList, setList and getList with value. if not set, $DEVICETOPIC will be replaced with the name of the device.
Aber da steht explizit "value" und nicht "regex"
Und es geht hier nicht um eine Abstimmung, sondern darum, ob/wie man ein vorhandenes Verhalten/Feature flexibel nutzbar machen kann.
OK, sorry, dass ich das mit dem commandref-Link nicht vorab gegengeprüft habe ::) . Da steht also: Allgemeingültig, auch für setList und getList. Dann MUSS es eindeutig sein, wenn man es in diese Richtung verwenden will.
Und zur regex wird es erst, weil das erste Element in readingList explizit als regexp beschrieben ist. IMO: works as designed, man KANN das offiziell so machen, allerdings darf man sich nicht wundern, wenn Schrott rauskommt, wenn man so eine Ersetzung auch in setList und/oder getList verwenden wollte.
Zitatob/wie man ein vorhandenes Verhalten/Feature flexibel nutzbar machen kann.
Imo kann man es gerade wegen der allgemeinen Verwendbarkeit nicht ohne weiteres flexibler nutzbar machen. In Senderichtung braucht es Eindeutigkeit.
Gibt es eigentlich einen Grund, warum die Daten gerade in der vorliegenden Form übermittelt werden? Die ganze Diskussion wäre gar nicht entstanden, wenn entweder die "üblichen Standards" bei der Topic-Struktur eingehalten wären (irgendwas mit "garage" vorneweg) oder die ganzen Readings als JSON verpackt würden...
Zitat von: Beta-User am 15 März 2022, 11:30:23
Gibt es eigentlich einen Grund, warum die Daten gerade in der vorliegenden Form übermittelt werden?
Mehrere. Aber das ist hier nicht das Thema des Threads.
Zitat von: Beta-User am 15 März 2022, 11:30:23
wenn entweder die "üblichen Standards" bei der Topic-Struktur eingehalten wären (irgendwas mit "garage" vorneweg)
Das kannst Du als "gegeben" voraussetzen. Ändert aber nichts an meinem Anliegen.
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:
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.
Zitat von: rudolfkoenig am 15 März 2022, 14:11:31
Mein aktueller Favorit ist die folgende, an plotReplace angelehnte (zusaetzliche!) Syntax:
Das wäre auch mein Favorit.
Zitat von: rudolfkoenig am 15 März 2022, 14:11:31
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)
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
%VAR1%/LWT:.* LWT\
%VAR2%/POWER1:.* state\
bzw.
%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...
Zitat- <VAR1> und %VAR1% wie in plotreplace?
Wenn Du mir sagst, was "vorher" und "nachher" hier sein soll....
ZitatKönnte hilfreich sein, [...]
War das ein "Ja, ich will es auch"? :)
Zitat von: rudolfkoenig am 15 März 2022, 15:46:18
Wenn Du mir sagst, was "vorher" und "nachher" hier sein soll....
ZitatIn 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:
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}}Zitat
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"...
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:
Zitatdevicetopic 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.
ZitatAnders gesagt: Macht, was ihr wollt, aber wenn, dann "richtig"...
Na toll :)
funktioniert hervorragend, danke!