MQTT und Shelly Plus I4

Begonnen von Jens_0001, 28 Januar 2022, 08:52:29

Vorheriges Thema - Nächstes Thema

Jens_0001

Hallo zusammen,

ich bin seit gestern Besitzer von 2 der neuen Shelly Plus I4.
Ich habe bereits unzählige der alten Shellys integriert, dies sind meine ersten der 2. Generation, bei der, so musste ich jetzt feststellen, doch einiges in der MQTT Struktur geändert wurde.

Der Shelly sendet in das Topic Shelly-ID/events/rpc in folgendem Format:

{"src":"shellyplusi4-083af2009f58","dst":"shelly_spizi_wandschalter/events","method":"NotifyEvent","params":{"ts":1643355788.36,"events":[{"component":"input:2", "id":2, "event":"single_push", "ts":1643355788.36}]}}

Die readingslist meines Devices in Fhem sieht so aus:

attr Shelly_Spizi_Wandschalter readingList shelly_spizi_wandschalter/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }

Damit bekommt das Device auch automatische Readings, die einen Knopfdruck erkennen, alles super.
Jetzt zu meiner Frage:

Jedes Element aus "params" bekommt sein eigenes Reading. Damit habe ich ID (Knopf 1-4) und Event (Kurz drücken, doppelt oder lang) in zwei unterschiedlichen Readings.
Wie kann ich mir ein Reading zusammenbauen, dass ID.Event enthält?

Jens_0001

Konnte mir über ein Userreading selbst helfen...  ;D

Beta-User

Zitat von: Jens_0001 am 28 Januar 2022, 09:20:58
Konnte mir über ein Userreading selbst helfen...  ;D
Toll. Kann man gut kopieren, deine hier vorgestellte Lösung... Und auch der Input entspricht dem, was hier genannt war: https://forum.fhem.de/index.php/topic,112327.0.html

Für alle, die an dem Thema für alle verwertbar weiterarbeiten wollen:

Es gibt zum einen erste Ansätze für die "2. Generation". Die sind leider deutlich schwieriger wie die für die alten, man muss die Payload analysieren, bevor man was damit anfangen kann. Beispiel:
$\DEVICETOPIC/events/rpc:.* { return if $EVENT =~ m{switch:[1-3]}; $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT,'',$JSONMAP) }

Für die gezeigte Payload wäre diese regex passend, um ein id/value-Paar zu extrahieren:
params...*id..(\d).*event...([^"]+).

Aktuelles Beispiel für "wenn es passt, mach das eine, wenn nicht, das andere..." (Sonoff NSPanel):
  STATTOPIC/RESULT:.* { $EVENT =~ m,\A..NSPanel.+id...(\d+).+params..(.+)..\z, ? json2nameValue($2,"Pan_${1}_",$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }

Ins Blaue würde ich das daher in etwa so zusammenbasteln:
$\DEVICETOPIC/events/rpc:.* { $EVENT =~ m{params...*id..(\d).*event...([^"]+).} ? { id_$1 => $2 } : json2nameValue($EVENT,'',$JSONMAP) }
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Jens_0001

Zuerst einmal vielen Dank für die Antwort!
Meine Lösung hätte ich natürlich auch teilen können. Ich habe folgendes Userreading angelegt:

attr Shelly_Spizi_Wandschalter userReadings Action {ReadingsVal("Shelly_Spizi_Wandschalter","params_events_1_id","").":".ReadingsVal("Shelly_Spizi_Wandschalter","params_events_1_event","")}

Mein Input entsprach nicht den im Wiki bereitgestellten Informationen, das stimmt. Ich bin davon ausgegangen, dass die Informationen für das beschriebene Problem ausreichend waren. Sollten sie das nicht gewesen sein, gibts beim nächsten Mal mehr, sorry dafür.


Nun aber der von dir vorgeschlagenen Lösung. Ich muss gestehen, sie übersteigt ein wenig meinen Horizont. Wenn ich stumpf deinen Vorschlag so umsetze

attr Shelly_Spizi_Wandschalter readingList shelly_spizi_wandschalter/events/rpc:.* { $EVENT =~ m{.id..(\d).*event...([^"]+).} ? { id_$1 => $2 } :  json2nameValue($EVENT,'',$JSONMAP) }

Dann bekomme ich keine Readings mehr. Tue mir offen gestanden gerade schwer mit dem Debugging.
Die Regex kann ich soweit nachvollziehen, der Teil danach ist mir leider unklar.

Beta-User

 :) Wenn gar nichts kommt, ist das natürlich doof...

Folgender Alternativvorschlag für den Perl-Teil:
{ $EVENT =~ m{params...*id..(\d).*event...([^"]+).} ? { state => "$1_$2" } : json2nameValue($EVENT,'',$JSONMAP) }

Erklärung: Es handelt sich um eine "ternärer Operator" -Konstruktion. Wenn die Payload ($EVENT) einem bestimmten Schema entspricht, soll ein Hash zurückgegeben werden, wenn nicht, "ganz normal" json2nameValue() aufgerufen werden.

Wenn also nichts kommt, wird der Hash nicht so gebildet wie erwartet, vermutlich war diese verdeckte concatenation (Zeichenverkettung) das Problem. Der Änderungsvorschlag befüllt jetzt (hoffentlich) das Reading "state" (dann kann das Problem scho mal nicht im ersten Teil auftreten und es verhält sich ähnlich wie z.B. eine HUE-Fernbedienung, bei der auch alles in state landet), und zwar mit einem Wert aus id-Nummer ($1 aus dem match) und dem "Taster-Event" (in Sprache).

Bin mal gespannt, ob das so klappt.

Dein userReading ist aus mehreren Gründen "grausam", aber dazu ggf. ein andermal...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files