[gelöst] mqtt-JSON-String als Trigger für Userreading

Begonnen von dirk.k, 16 Mai 2021, 21:09:54

Vorheriges Thema - Nächstes Thema

dirk.k

Hallo zusammen,
ich bekomme per MQTT folgenden JSON-String in das Reading Result: {"Button1":{"Action":"DOUBLE"}}
Das möchte ich als Trigger in den UserReadings verwenden.
Der Wert "DOUBLE" kann ich für den Button1 extrahieren, bekomme aber keinen Trigger in den UserRadings zustande wenn
Reading Button1 = "DOUBLE" ist .... ok, das könnte daran liegen, dass Userreadings keine Userreadings triggern ...?
Reading Result Enthält Button1 und DOUBLE 
versucht habe ich das mit folgenden Definitionen in UserReadings:
in_Button1:Result:.* {decode_json(ReadingsVal($NAME,"Result",0))->{Button1}{Action}},
tmp1:Result:.*Button1.*DOUBLE {return "Double erkannt" ;},
tmp:in_Button1.* { return "Gruppe angefangen" ;  },


hier ein leicht gekürztes list vom device ...
Internals:
   .autoSubscribeExpr ^fhem\/sensors\/LEDKueche1.*$
   .autoSubscribeTopic fhem/sensors/LEDKueche1/#
   DEF       
   FUUID      6071da8a-f33f-cdbc-fee5-810eeff25ed7a7a4
   IODev      mqtt_local
   NAME       LEDKueche1
   NR         392
   STATE      BABABABA
   TYPE       MQTT_DEVICE
   qos        *:0
   retain     *:0
   .attraggr:
   .attreocr:
     .*
   .attreour:
     in_Button1
     Result
   .attrminint:
   .qos:
     *          0
   .retain:
     *          0
   .userReadings:
     HASH(0x564a68b734b0)
     HASH(0x564a68a6b928)
     HASH(0x564a682e0ae0)
     HASH(0x564a68423140)
     HASH(0x564a67e984c0)
     HASH(0x564a67c353d0)
     HASH(0x564a68261538)
     HASH(0x564a68d4eec0)
     HASH(0x564a68f07478)
     HASH(0x564a68c31458)
     HASH(0x564a67ce21e0)
     HASH(0x564a664456c8)
     HASH(0x564a68c5d860)
     HASH(0x564a681f5818)
     HASH(0x564a687f71d0)
     HASH(0x564a688e2ae8)
   Helper:
     DBLOG:
       uptime:
         logdb:
           TIME       1621190308.15046
           VALUE      611
   READINGS:
     2021-05-16 20:28:16   DevGroupName1   
     2021-05-10 20:01:53   Firmware        9.3.1(tasmota)
     2021-05-16 20:28:23   INFO1           {"Info1":{"Module":"Generic","Version":"9.4.0(tasmota)","FallbackTopic":"cmnd/DVES_457E73_fb/","GroupTopic":"fhem/sensors/tasmotas/cmnd/"}}
     2021-05-16 20:28:23   INFO2           {"Info2":{"WebServerMode":"Admin","Hostname":"LEDKueche1-7795","IPAddress":"192.168.11.34"}}
     2021-05-16 20:28:23   INFO3           {"Info3":{"RestartReason":"Software/System restart"}}
     2021-05-16 20:38:28   INFO4           {"Time":"2021-05-16T20:38:28","Uptime":"0T00:10:11","UptimeSec":611,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":26,"MqttCount":1,"POWER":"OFF","Dimmer":73,"Color":"BABABABA","HSBColor":"0,0,73","White":73,"Channel":[73,73,73,73],"Scheme":0,"Fade":"ON","Speed":5,"LedTable":"ON","Wifi":{"AP":1,"SSId":"iD8myIoT","BSSId":"00:1A:8C:7E:19:0D","Channel":6,"RSSI":94,"Signal":-53,"LinkCount":1,"Downtime":"0T00:00:05"}}
     2021-05-16 19:08:33   IODev           mqtt_local
     2021-05-16 20:28:23   LWT             Online
     2021-05-10 20:01:53   OTA-IP          192.168.11.30
     2021-05-16 20:38:28   Power           OFF
     2021-05-16 20:38:28   RSSI            94
     2021-05-16 20:40:23   Result          {"Button1":{"Action":"DOUBLE"}}
     2021-05-16 19:38:54   Result2         {"Time":"2021-05-16T19:38:53","IrReceived":{"Protocol":"NEC","Bits":32,"Data":"0x00FFB847"}}
     2021-05-01 21:24:33   UPGRADE         {"Upgrade":"Successful. Restarting"}
     2021-05-16 20:40:23   color           22222211
     2021-05-16 19:38:47   command         color 00000044
     2021-05-16 20:40:23   in_Button1      DOUBLE
     2021-05-16 20:27:39   in_Dimmer       73
     2021-05-16 20:27:39   in_RGB          BABABABA
     2021-05-16 20:27:39   in_WHITE        73
     2021-05-16 20:28:23   in_cmndPower   
     2021-05-16 19:38:47   in_cmndbacklog  color 00000044
     2021-05-16 20:38:28   state           OFF
     2021-05-16 20:40:23   transmission-state incoming publish received
     2021-05-16 20:38:28   uptime          611
     2021-05-16 20:40:23   xxxRGB          222222
     2021-05-16 20:40:23   xxxxRGB         123456
   message_ids:
   publishSets:
     RGB:
       topic      fhem/sensors/LEDKueche1/dummy/ColorRGB
       values:
     WHITE:
       topic      fhem/sensors/LEDKueche1/dummy/ColorWHITE
       values:
     color:
       topic      fhem/sensors/LEDKueche1/disabled/cmnd/Color
       values:
     command:
       topic      fhem/sensors/LEDKueche1/cmnd/backlog
       values:
     speed:
       topic      fhem/sensors/LEDKueche1/cmnd/speed
       values:
   sets:
     RGB       
     WHITE     
     color     
     command   
     speed     
   subscribe:
     fhem/sensors/LEDKueche1/#
     fhem/sensors/LEDKueche1/tele/INFO1
     fhem/sensors/LEDKueche1/tele/INFO2
     fhem/sensors/LEDKueche1/tele/INFO3
     fhem/sensors/LEDKueche1/tele/STATE
     fhem/sensors/LEDKueche1/tele/LWT
     fhem/sensors/LEDKueche1/stat/POWER1
     fhem/sensors/LEDKueche1/stat/POWER2
     fhem/sensors/LEDKueche1/stat/RESULT
     fhem/sensors/LEDKueche1/tele/RESULT
     fhem/sensors/LEDKueche1/stat/UPGRADE
     fhem/sensors/LEDKueche1/cmnd/backlog
     fhem/sensors/LEDKueche1/cmnd/POWER
     fhem/sensors/LEDKueche1/dummy/ColorWHITE
     fhem/sensors/LEDKueche1/cmnd/Color
     fhem/sensors/LEDKueche1/stat/POWER
   subscribeExpr:
     ^fhem\/sensors\/LEDKueche1.*$
     ^fhem\/sensors\/LEDKueche1\/tele\/INFO1$
     ^fhem\/sensors\/LEDKueche1\/tele\/INFO2$
     ^fhem\/sensors\/LEDKueche1\/tele\/INFO3$
     ^fhem\/sensors\/LEDKueche1\/tele\/STATE$
     ^fhem\/sensors\/LEDKueche1\/tele\/LWT$
     ^fhem\/sensors\/LEDKueche1\/stat\/POWER1$
     ^fhem\/sensors\/LEDKueche1\/stat\/POWER2$
     ^fhem\/sensors\/LEDKueche1\/stat\/RESULT$
     ^fhem\/sensors\/LEDKueche1\/tele\/RESULT$
     ^fhem\/sensors\/LEDKueche1\/stat\/UPGRADE$
     ^fhem\/sensors\/LEDKueche1\/cmnd\/backlog$
     ^fhem\/sensors\/LEDKueche1\/cmnd\/POWER$
     ^fhem\/sensors\/LEDKueche1\/dummy\/ColorWHITE$
     ^fhem\/sensors\/LEDKueche1\/cmnd\/Color$
     ^fhem\/sensors\/LEDKueche1\/stat\/POWER$
   subscribeQos:
     fhem/sensors/LEDKueche1/#
     fhem/sensors/LEDKueche1/cmnd/Color 0
     fhem/sensors/LEDKueche1/cmnd/POWER 0
     fhem/sensors/LEDKueche1/cmnd/backlog 0
     fhem/sensors/LEDKueche1/dummy/ColorWHITE 0
     fhem/sensors/LEDKueche1/stat/POWER 0
     fhem/sensors/LEDKueche1/stat/POWER1 0
     fhem/sensors/LEDKueche1/stat/POWER2 0
     fhem/sensors/LEDKueche1/stat/RESULT 0
     fhem/sensors/LEDKueche1/stat/UPGRADE 0
     fhem/sensors/LEDKueche1/tele/INFO1 0
     fhem/sensors/LEDKueche1/tele/INFO2 0
     fhem/sensors/LEDKueche1/tele/INFO3 0
     fhem/sensors/LEDKueche1/tele/LWT 0
     fhem/sensors/LEDKueche1/tele/RESULT 0
     fhem/sensors/LEDKueche1/tele/STATE 0
   subscribeReadings:
....
     fhem/sensors/LEDKueche1/stat/RESULT:
       cmd       
       name       Result
....
     fhem/sensors/LEDKueche2/stat/RESULT:
       cmd       
       name       Result
     fhem/sensors/LEDKueche2/stat/UPGRADE:
       cmd       
....
Attributes:
   DbLogInclude uptime
   IODev      mqtt_local
   autoSubscribeReadings fhem/sensors/LEDKueche1/#
   comment    https://forum.fhem.de/index.php/topic,90220.45.html
stateFormat
{ReadingsVal($name,"precence","") eq "offline" ? "offline" : ReadingsVal($name,"state","")}
widgetoverride RGB:colorpicker,RGB:RGB WHITE:colorpicker,BRI,0,1,100 RGBin:colorpicker,RGB:RGB

   event-on-change-reading .*
   event-on-update-reading in_Button1,Result
   group      LED
   icon       light_led_stripe_rgb
   publishSet_RGB fhem/sensors/LEDKueche1/dummy/ColorRGB
   publishSet_WHITE fhem/sensors/LEDKueche1/dummy/ColorWHITE
   publishSet_color fhem/sensors/LEDKueche1/disabled/cmnd/Color
   publishSet_command fhem/sensors/LEDKueche1/cmnd/backlog
   publishSet_speed fhem/sensors/LEDKueche1/cmnd/speed
   qos        0
   retain     0
   room       1.3_Kueche,8.2_ESP
   stateFormat in_RGB
   subscribeReading_ fhem/sensors/LEDKueche1/stat/LOGGING
   subscribeReading_INFO1 fhem/sensors/LEDKueche1/tele/INFO1
   subscribeReading_INFO2 fhem/sensors/LEDKueche1/tele/INFO2
   subscribeReading_INFO3 fhem/sensors/LEDKueche1/tele/INFO3
...
   subscribeReading_Result fhem/sensors/LEDKueche1/stat/RESULT
   subscribeReading_Result2 fhem/sensors/LEDKueche1/tele/RESULT
   subscribeReading_UPGRADE fhem/sensors/LEDKueche1/stat/UPGRADE
   subscribeReading_backlog fhem/sensors/LEDKueche1/cmnd/backlog

   userReadings DevGroupName1:Result:.* {decode_json(ReadingsVal($NAME,"Result",0))->{DevGroupName1}},
OTA-IP:INFO2:.* {decode_json(ReadingsVal($NAME,"INFO2",0))->{IPAddress}},
...
in_Button1:Result:.* {decode_json(ReadingsVal($NAME,"Result",0))->{Button1}{Action}},
...
tmp1:Result:.*Button1.*DOUBLE {return "Double erkannt" ;},
tmp:in_Button1.* { return "Gruppe angefangen" ;  },

   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
   webCmd     RGBin
   widgetOverride RGBin:colorpicker,RGB:RGB


Kann mir bitte jemand helfen?

PS: ich glaubte ".*" falsch gesetzt zu haben und habe "tmp1:Result:Action.*DOUBLE.* {return "Double erkannt" ;}," versucht ... ebenfalls ohne Erfolg

Beta-User

Na ja, irgendwie kein "schönes" Device, wenn man MQTT2_DEVICE kennt...

Das Problem dürfte hier der unpassende trigger sein, versuch's mal mit:
tmp1:Result:.*Button1.*DOUBLE.* {return "Double erkannt" ;},
Und ja, userReadings als "Ausgangsmaterial" für weitere userReadings ist mAn. eher keine so gute Idee.
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

dirk.k

Ok, danke. Die Kombi werde ich sobald wie möglich testen.

Wie viel schöner würde das device mit MQTT2_Device denn werden?
Und wie Sicher ist MQTT2?
Ich verwende MQTT für die Dateneinlieferung aus dem Internet auf einem separaten / isolierten Server.
Ich habe Mosquitto lange vor MQTT2 schätzen gelernt und kann mir für einen Umstieg nicht genügend Vorteile vorstellen.

Beta-User

Zitat von: dirk.k am 17 Mai 2021, 20:29:51
Wie viel schöner würde das device mit MQTT2_Device denn werden?
Na ja, wenn ich das auf die Schnelle richtig überblickt habe, verwendest du eine ganze Anzahl userReadings, um dasselbe zu erreichen, was mit json2nameValue() (in MQTT2_DEVICE) direkt ginge - auspacken, filtern und umbenennen. (Und dann im Anschluss ggf. noch ein "echtes userReading" anflanschen, wenn man das noch braucht).

Zitat
Und wie Sicher ist MQTT2?
Ich verwende MQTT für die Dateneinlieferung aus dem Internet auf einem separaten / isolierten Server.
Ich habe Mosquitto lange vor MQTT2 schätzen gelernt und kann mir für einen Umstieg nicht genügend Vorteile vorstellen.
Prinzipiell ist "MQTT2" kein eigenes Protokoll, und es bleibt dem Anwender überlassen, ob er einen externen Server wie Mosquitto einsetzen will oder den internen MQTT2_SERVER. Soweit ich das im Kopf habe, kann das alte Client-Modul (00_MQTT.pm) kein SSL, beide MQTT2-IO's dagegen sehr wohl. Gerade der Sicherheitsaspekt spräche dann also eher für die neuen Module (falls du nicht auf der Mosquitto-Ebene unterschiedliche Sichheitslevel nach intern und extern realisiert hast).

Generell war mein Eindruck, dass du mit der Handhabung der Messages in deiner jetzigen Konstruktion am Rande des Möglichen bist (genauer gesagt ist das das "heftigste" an userReadings, das ich bisher in MQTT_DEVICE gesehen habe), und von daher gewisse Schwierigkeiten rühren, diesen "Drachen zu reiten". Vermutlich gibt es zwischenzeitlich mehr Helfer, die bei MQTT2_DEVICE weiterhelfen hätten können (genauer: wollen, denn es geht eigentlich ja nicht um was MQTT_DEVICE-spezifisches).

Aber das ganze eilt ja nicht, und du kannst ja auch einfach (parallel oder von einem Testsystem aus) mal einen MQTT2_CLIENT auf den Mosquitto loslassen, wenn's dich interessiert (und hier das rgbw-Tasmota-attrTemplate austesten)...
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

dirk.k

#4
Danke, der Trigger funktioniert.
Die ersten (flüchtigen) Versuche mit MQTT2_Device waren nicht sonderlich erfolgreich.
Ich kann die templates nicht finden ... besonders fehlt das rgbw-Tasmota-attrTemplate ... da sind aber 3 andere Tasmota-tenplates zur Auswahl die nur bedingt passen.
Auch habe ich zwei (manuell angelegte) MQTT2_DEVICEs zwar an den MQTT2_CLIENT angebunden, habe aber keine Idee wie ich die Zuordnung MQTT Topics und Werte steuern kann.
Das erste Gerät bekommt (lernt) alle MQTT-Werte aller Geräte, das Zweite keines.
In den Dokus habe ich dazu bisher nichts gefunden.

Beta-User

Mobiler Kurztipp: wiki zu m2-client (bridgeRegexp-Device).
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

dirk.k

ok, die Zuordnung der Topics zu den Geräten (oder besser das automatische Erstellen der Geräte über das Bridge-device) funktioniert.
Danke für den Tip.