MQTT Readinglist Topic auswerten

Begonnen von Juelo, 01 Januar 2022, 23:28:45

Vorheriges Thema - Nächstes Thema

Juelo

Hallo zusammen,

ich habe ein neues MQTT Gerät. Leider macht es mir die Auswertung etwas schwer. Es gibt verschiedene Topics leider ist die ID "IDX" nicht im Topic enthalten.


PLUG/in{"idx":"1","temp":"000.0","p0":"0.0","p1":"0.0","status":"true","energy":"0.0"}
PLUG/in{"idx":"2","temp":"000.0","p0":"0.0","p1":"0.0","status":"true","energy":"0.0"}
PLUG/in{"idx":"3","temp":"000.0","p0":"0.0","p1":"0.0","status":"true","energy":"0.0"}




Natürlich bekomme ich die Readings mit folgedener Eintrag

10315333:PLUG/in:.* { json2nameValue($EVENT) }

integriert. Leider kann ich so nicht die ID unterscheiden. Jemand eine Idee wie ich die Eintrag IDX mit in das Reading integrieren kann?

Super wäre es so:

Zitatsetstate mqttclient 2022-01-01 23:13:53 idx_1_p0 0.0
setstate mqttclient 2022-01-01 23:13:53 idx_2_p0 0.0
setstate mqttclient 2022-01-01 23:13:53 idx_3_p0 0.0
...

Danke und Gruß

OdfFhem

Zitat
10315333:PLUG/in:.* { json2nameValue($EVENT) }

Der linke Teil ist ein regulärer Ausdruck und entspricht topic:message.
.* muss also genauer auf die idx-Angabe der message formuliert werden.

json2nameValue im rechten Teil erlaubt einen zweiten Parameter, der ein Präfix festlegt - passend zum gefilterten idx-Wert der message.

Eine Lösung könnte folgendem Muster (für idx=1) entsprechen:

PLUG/in:.*\"idx\":\"1\",.* { json2nameValue($EVENT,"idx_1_") }

supernova1963

Mögliche Erweiterung des Vorschlags von @OdfFhem (damit sollten alle readings in einem device, wie gewünscht, erstellt werden):


PLUG/in:.*\"idx\":\"(.)\",.* { json2nameValue($EVENT,"idx_$1_") }


Achtung nur als Idee bzw. Prinzip, nicht testet!

OdfFhem

@supernova1963

Die $1-Idee hatte ich auch, da diese Theorie bei bridgeRegexp äußerst hilfreich ist.
Bei readingList habe ich es so noch nie verwendet bzw. gesehen und ist auch nicht dokumentiert; daher erst einmal "unerwähnt" gelassen.

Heute morgen bei einem Testgerät die Theorie angewendet und festgestellt, dass $1 nicht zum geklammerten Ergebnis führt, sondern zu _1. "_" als Ersatz für $ und 1 halt für 1.

Wäre entweder was für eine (mögliche) Modulerweiterung oder wird nicht gebraucht, da beim Präfix sowieso eher sprechendere Namen verwendet werden ...

Beta-User

$1 wird nicht an die Perl-Funktion über geben, da muss (und kann) man von vorn anfangen, wobei es hier m.E. um die Auswertung der Payload geht. Es gibt ein paar Beispiele dafür in attrTemplate. Würde spontan an tasmota-DS18B20 denken (ungeprüft).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

OdfFhem

@Beta-User

Zitat von: Beta-User am 02 Januar 2022, 09:28:34
$1 wird nicht an die Perl-Funktion über geben, da muss (und kann) man von vorn anfangen, wobei es hier m.E. um die Auswertung der Payload geht.

Klar, $1 aus dem linken Teil dürfte eigentlich nie als $1 im rechten Teil verwendet werden; ansonsten schränkt man die gern genutzten Möglichkeiten von Perl massiv ein.

Gäbe es denn eine (mit geringem Aufwand verbundene) Möglichkeit, $1 aus dem linken Teil ähnlich zu $EVTPART1 als Platzhalter bereitzustellen: $PAYLOAD1 oder $REGEXP1 oder ... ?

Beta-User

...müßtest du Rudi fragen, bin aber spontan nicht der Ansicht, dass es das braucht:
- Payload-Analyse gehört eigentlich sowieso "nach rechts", dort gibt es $EVTPARTx (schon klar, dass es was anderes ist), hier ist es übrigens eigentlich sowieso Payload und nicht Topic (!)!
- $TOPIC wird übergeben. Wenn man also wirklich ausnahmsweise den Topic braucht (kannst ja mal zählen, wie oft das in mqtt2.template vorkommt), muss man halt nochmal selbst regexen. In dem (sehr seltenen Fall) mehr Aufwand, aber das ist m.E. kein Vergleich zu dem, was an Aufwand für das "vorsorgliche" Bereitstellen von Eventualitäten entsteht.
- sehr vielleicht könnte es mit einem "named capture" klappen. Da weiß ich nicht, wie lange sowas erhalten bleibt. Geht vermutlich eher nicht, weil außerhalb der ursprünglichen Funktion (andere sub).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

OdfFhem

@Beta-User

Rudi stolpert hier evtl. nur zufällig drüber ... ich würde mich aber auch gerne wiederholen:
Zitat von: OdfFhem am 02 Januar 2022, 09:06:50
... wird nicht gebraucht ...

Denn beim genaueren Betrachten scheint es tatsächlich schon mit heutigen Mitteln problemlos umsetzbar:
- im linken Teil weiterhin .* verwenden
- im rechten Teil $1 bzgl. idx-Key aus $EVENT ermitteln und als prefix für json2nameValue verwenden

Aus

PLUG/in:.*\"idx\":\"1\",.* { json2nameValue($EVENT,"idx_1_") }


würde dann

PLUG/in:.* { $EVENT =~ m/"idx":"(\d)"/; json2nameValue($EVENT, "idx_$1_", $JSONMAP) }

Nicht viel länger, klappt aber schon mal für idx im Bereich 0..9