event-on-change-reading - .* wird bei Liste von Readings ignoriert

Begonnen von PatrickR, 21 August 2023, 20:27:51

Vorheriges Thema - Nächstes Thema

PatrickR

Hallo zusammen,

ich habe aktuell ein merkwürdiges Problem mit event-on-change-reading mit folgendem Device:
defmod UG.KE.NETIO MQTT2_DEVICE
attr UG.KE.NETIO userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr UG.KE.NETIO DbLogInclude output\d_(state|consumption|energy|energy_fhem),total_(consumption|energy|energy_fhem)
attr UG.KE.NETIO IODev MQTTBroker2
attr UG.KE.NETIO alias PDU
attr UG.KE.NETIO devicetopic house/cellar/netio
attr UG.KE.NETIO event-on-change-reading total_consumption:5,output[12]_consumption:5,output[34]_consumption:1,total_current:100,output[1234]_current:100,.*_powerfactor:50,input_voltage:1000,.*_energy:10,.*_energy_fhem:10,.*
attr UG.KE.NETIO group Verbrauch
attr UG.KE.NETIO readingList $DEVICETOPIC/.*:.* {PRUtils::mqttevent2readingdt($DEVICETOPIC, $TOPIC,$EVENT)}
attr UG.KE.NETIO room Keller
attr UG.KE.NETIO setList output1:on,off $DEVICETOPIC/output1/set\
output2:on,off $DEVICETOPIC/output2/set\
output3:on,off $DEVICETOPIC/output3/set\
output4:on,off $DEVICETOPIC/output4/set
attr UG.KE.NETIO sortby 05
attr UG.KE.NETIO stateFormat {\
sprintf("<table>\
<tr><td>USV1:</td><td style=\"text-align:right\">%.0fW</td></tr><tr><td>USV2:</td><td style=\"text-align:right\">%.0fW</td></tr><tr><td>Schuko:</td><td style=\"text-align:right\">%.0fW</td></tr><tr><td>Lüfter:</td><td style=\"text-align:right\">%.0fW</td></tr><tr><td>Gesamt:</td><td style=\"text-align:right\">%.0fW</td></tr></table>",\
ReadingsVal($name, 'output1_consumption', 0),\
ReadingsVal($name, 'output2_consumption', 0),\
ReadingsVal($name, 'output3_consumption', 0),\
ReadingsVal($name, 'output4_consumption', 0),\
ReadingsVal($name, 'total_consumption', 0)\
)\
}
attr UG.KE.NETIO userReadings output1_energy_fhem monotonic {ReadingsVal($name, 'output1_energy', 0)},\
output2_energy_fhem monotonic {ReadingsVal($name, 'output2_energy', 0)},\
output3_energy_fhem monotonic {ReadingsVal($name, 'output3_energy', 0)},\
output4_energy_fhem monotonic {ReadingsVal($name, 'output4_energy', 0)},\
total_energy_fhem {\
ReadingsVal($name, 'output1_energy_fhem', 0) +\
ReadingsVal($name, 'output2_energy_fhem', 0) +\
ReadingsVal($name, 'output3_energy_fhem', 0) +\
ReadingsVal($name, 'output4_energy_fhem', 0)\
}\
Nun fiel mir auf, dass ein Großteil der Readings wie gewünscht Events erzeugen, output4_state aber nicht. Das sollte eigentlich durch das ,.* am Ende abgefangen werden.

Setze ich event-on-change-reading auf
.*
dann funktioniert es und output4_state erzeugt ein Event.

Bei
.*,total_consumption:5
wird aber kein Event erzeugt.

Ich stehe auf dem Schlauch.

Hat jemand einen Tipp?

Patrick

lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

Beta-User

event-on-change-reading ERZEUGT keine Events! Es unterdrückt sie...
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

PatrickR

Zitat von: Beta-User am 22 August 2023, 08:05:18event-on-change-reading ERZEUGT keine Events! Es unterdrückt sie...
Nichts anderes habe ich behauptet. Hast Du eine Idee zum o.g. Problem?
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

Beta-User

Vielleicht zeigst du, welche Nachrichten (vielleicht bezogen auf einen Schaltvorgang in output4) reinkommen und welche Events dann durchgelassen werden? So sieht es nämlich eigentlich "ok" aus...
Es ist übrigens auch unklar, was dein Code macht, ich vermute mal, dass das nur eine spezielle Variante von json2nameValue() ist?
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

JoWiemann

Zitat von: PatrickR am 22 August 2023, 09:09:38
Zitat von: Beta-User am 22 August 2023, 08:05:18event-on-change-reading ERZEUGT keine Events! Es unterdrückt sie...
Nichts anderes habe ich behauptet. Hast Du eine Idee zum o.g. Problem?

Bei .* handelt es sich wohl um einen Sonderfall. Auszug aus dem Wiki:

Falls ein Reading namens "unwanted" KEINE Events erzeugen soll, lässt sich das mit

attr <device> event-on-change-reading (?!unwanted).*

unterdrücken.


Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

PatrickR

Hallo Jörg,

Zitat von: JoWiemann am 22 August 2023, 09:22:30Bei .* handelt es sich wohl um einen Sonderfall. Auszug aus dem Wiki:

Falls ein Reading namens "unwanted" KEINE Events erzeugen soll, lässt sich das mit

attr <device> event-on-change-reading (?!unwanted).*
unterdrücken.
Hmm, der negative Lookahead (?!) ist streng genommen ein Sonderfall einer RegEx, genau wie '.*'. Da sehe ich offen gestanden keine Verbindung zu meinem Problem.

.* wirkt schließlich, aber scheinbar nicht, wenn es in EOCR eine weitere RegEx (mit Threshold) gibt.

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

PatrickR

#6
Großartig, nachdem ich gestern das Problem zuverlässig rekonstruieren konnte, tritt es heute nicht mehr auf.
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook