MQTT2 mehrere devicetopic per Attribut definieren

[betateilchen]

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:

Code Auswählen Erweitern


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.

[rudolfkoenig]

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?

[betateilchen]

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.

Code Auswählen Erweitern


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


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.

[rudolfkoenig]

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.

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

[betateilchen]

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.

[Beta-User]

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.

[betateilchen]

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.

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?

[Beta-User]

Eben das hier kurz angetestet (mit readingList aus deinem Post):

Code Auswählen Erweitern

attr Carport devicetopic (/sensor1/temperatur|/sensor2/regen)

Das scheint zu funktionieren wie gewünscht.

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.

[betateilchen]

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.

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.

[Beta-User]

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).

[betateilchen]

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:

Code Auswählen Erweitern

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.

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.

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.

[Beta-User]

  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.

[betateilchen]

aber man muss auch nicht "ohne Not" an den Stellen für Verwirrung sorgen

Inzwischen bist Du aber hier derjenige, der Verwirrung stiftet.

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...

Code Auswählen Erweitern


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.

[Beta-User]

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.

ob/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...

[betateilchen]

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.

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.