Hallo
ich habe ein funktionierendes MQTT2_device "BrunnenWasserZaehler" (esp8266, tasmota)
Internals:
CFGFN
CID brunnen
DEF brunnen
DEVICETOPIC BrunnenWasserZaehler
FUUID 61af9966-f33f-2a7c-6cc4-b5206a9bdea997f3
IODev mqttServer
LASTInputDev mqttServer
MSGCNT 972
NAME BrunnenWasserZaehler
NR 1961
STATE 290.28 l ( 122352 )
TYPE MQTT2_DEVICE
mqttServer_CONN mqttServer_10.0.0.163_55885
mqttServer_MSGCNT 972
mqttServer_TIME 2021-12-08 08:12:19
OLDREADINGS:
READINGS:
2021-12-08 08:12:19 COUNTER_C1 122352
2021-12-08 07:44:04 Time 2021-12-08T07:44:04
2021-12-08 08:12:19 liter 290.28
2021-12-08 08:12:19 literPerMin 0.00
helper:
_98_statistics BrunnenWasserZaehlerStatDev
Attributes:
autocreate 0
comment 421.5 impulse = 1 liter
event-min-interval .*:3600
event-on-change-reading COUNTER_C1,.tmp_literPerMin,literPerMin,liter
group Wasser
icon measure_water_meter
readingList brunnen:tele/tasmota_CE94EE/LWT:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/INFO1:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/INFO2:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/SENSOR:.* { json2nameValue($EVENT) }
room Technik-Wasser
stateFormat liter l ( COUNTER_C1 )
timestamp-on-change-reading .*
userReadings .tmp_literPerMin:COUNTER_C1:.* differential {ReadingsVal($NAME,"COUNTER_C1",0)/421.5*60;;},
statLiter:dummy:.* {"versuch, das reading upgedatebar zu machen";;},
literPerMin:.tmp_literPerMin:.* {sprintf("%.2f",ReadingsVal($NAME,".tmp_literPerMin",0));;},
liter:COUNTER_C1:.* {sprintf("%.2f",ReadingsVal($NAME,"COUNTER_C1",0)/421.5);;}
verbose 5
nun möchte ich mit dem statistics-device "BrunnenWasserZaehlerStatDev" ein reading ("statLiter") am MQTT2_device setzen.
Internals:
CFGFN
DEF BrunnenWasserZaehler
DEV_REGEXP BrunnenWasserZaehler
FUUID 61af9b0d-f33f-2a7c-0a3c-d2cd24415ab54fdc
NAME BrunnenWasserZaehlerStatDev
NOTIFYDEV global,BrunnenWasserZaehler
NR 2032
NTFY_ORDER 10-BrunnenWasserZaehlerStatDev
PREFIX stat
STATE Updated stats for: BrunnenWasserZaehler
TYPE statistics
OLDREADINGS:
READINGS:
2021-12-07 19:36:02 monitoredDevicesMQTT2_DEVICE BrunnenWasserZaehler
2021-12-08 07:59:55 nextPeriodChangeCalc 2021-12-08 08:59:55
2021-12-08 08:17:49 state Updated stats for: BrunnenWasserZaehler
fhem:
modulVersion $Date: 2019-12-24 00:07:57 +0100 (Tue, 24 Dec 2019) $
nextPeriodChangeTime 1638950395
Attributes:
deltaReadings liter
event-min-interval .*:3600
event-on-change-reading .*
group Wasser
icon rc_HELP
ignoreDefaultAssignments 1
room Technik-Wasser
singularReadings BrunnenWasserZaehler:liter:Delta:(Hour|Day|Month|Year)
verbose 5
das statistics-device wird getriggert, aber im MQTT2_device wird das reading "statLiter" nicht erzeugt (einmal war es mit dem Wert 0 angelegt).
im Log sehe ich:
2021.12.08 08:20:49 4: MQTT2_DEVICE_Parse: BrunnenWasserZaehler tele/tasmota_CE94EE/SENSOR => { json2nameValue($EVENT) }
2021.12.08 08:20:49 5: statistics BrunnenWasserZaehlerStatDev: DoStatistics.446 Assigned reading 'liter' from attribute 'deltaReadings' to statistic type 2.
2021.12.08 08:20:49 4: statistics BrunnenWasserZaehlerStatDev: doStatisticDelta.703 Calculating delta statistics for 'BrunnenWasserZaehler:liter = 290.28'
2021.12.08 08:20:49 5: statistics BrunnenWasserZaehlerStatDev: doStatisticDelta.794 Set '.BrunnenWasserZaehler:liter'='LastValue: 290.28 ShowDate: 7 DecPlaces: 2'
2021.12.08 08:20:49 5: statistics BrunnenWasserZaehlerStatDev: doStatisticDelta.800 Set 'statLiter'='Hour: 0.00 Day: 0.00 Month: 0.00 Year: 0.00 (since: )'
2021.12.08 08:20:49 5: statistics BrunnenWasserZaehlerStatDev: storeSingularReadings.1089 Set statLiterHour = 0.00
2021.12.08 08:20:49 5: statistics BrunnenWasserZaehlerStatDev: storeSingularReadings.1089 Set statLiterDay = 0.00
2021.12.08 08:20:49 5: statistics BrunnenWasserZaehlerStatDev: storeSingularReadings.1089 Set statLiterMonth = 0.00
2021.12.08 08:20:49 5: statistics BrunnenWasserZaehlerStatDev: storeSingularReadings.1089 Set statLiterYear = 0.00
2021.12.08 08:20:49 5: statistics BrunnenWasserZaehlerStatDev: Notify.296 Notification of 'BrunnenWasserZaehler' received. Update statistics.
nach längerem Debuggen habe ich versucht, mit "setreading BrunnenWasserZaehler testreading test" ein neues Reading anzulegen, aber es wird nicht erzeugt. Versuche, es mit userreadings zu initialisieren, sind auch gescheitert.
ein bestehendes Reading (z.B. "literPerMin") kann jedoch mit setreading ohne Probleme überschrieben werden.
ich bin ratlos ...
Didi
Zu den statistics Experimenten kann ich nichts sagen, aber dass ein setreading mit einem MQTT2_DEVICE nicht funktionieren soll finde ich sehr unwahrscheinlich, ich hatte gerade kein Problem bei Testen.
funktioniert leider bei mir nicht
# nc 127.0.0.1 7072
FHEM> list BrunnenWasserZaehler
Internals:
CFGFN
CID brunnen
DEF brunnen
DEVICETOPIC BrunnenWasserZaehler
FUUID 61af9966-f33f-2a7c-6cc4-b5206a9bdea997f3
IODev mqttServer
LASTInputDev mqttServer
MSGCNT 1072
NAME BrunnenWasserZaehler
NR 1961
STATE 297.56 l ( 125423 )
TYPE MQTT2_DEVICE
mqttServer_CONN mqttServer_10.0.0.163_55885
mqttServer_MSGCNT 1072
mqttServer_TIME 2021-12-08 09:18:33
OLDREADINGS:
READINGS:
2021-12-08 09:15:33 COUNTER_C1 125423
2021-12-08 07:44:04 Time 2021-12-08T07:44:04
2021-12-08 09:15:33 liter 297.56
2021-12-08 09:15:33 literPerMin 0.40
helper:
_98_statistics BrunnenWasserZaehlerStatDev
Attributes:
autocreate 0
comment 421.5 impulse = 1 liter
event-min-interval .*:3600
event-on-change-reading COUNTER_C1,.tmp_literPerMin,literPerMin,liter
group Wasser
icon measure_water_meter
readingList brunnen:tele/tasmota_CE94EE/LWT:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/INFO1:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/INFO2:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/SENSOR:.* { json2nameValue($EVENT) }
room Technik-Wasser
stateFormat liter l ( COUNTER_C1 )
timestamp-on-change-reading .*
userReadings .tmp_literPerMin:COUNTER_C1:.* differential {ReadingsVal($NAME,"COUNTER_C1",0)/421.5*60;;},
statLiter:dummy:.* {"versuch, das reading updatebar zu machen";;},
literPerMin:.tmp_literPerMin:.* {sprintf("%.2f",ReadingsVal($NAME,".tmp_literPerMin",0));;},
liter:COUNTER_C1:.* {sprintf("%.2f",ReadingsVal($NAME,"COUNTER_C1",0)/421.5);;}
verbose 2
FHEM>
FHEM>
FHEM> setreading BrunnenWasserZaehler testreading test
FHEM> setreading BrunnenWasserZaehler literPerMin 0.40000000000000000000000000
FHEM>
FHEM>
FHEM> list BrunnenWasserZaehler
Internals:
CFGFN
CID brunnen
DEF brunnen
DEVICETOPIC BrunnenWasserZaehler
FUUID 61af9966-f33f-2a7c-6cc4-b5206a9bdea997f3
IODev mqttServer
LASTInputDev mqttServer
MSGCNT 1072
NAME BrunnenWasserZaehler
NR 1961
STATE 297.56 l ( 125423 )
TYPE MQTT2_DEVICE
mqttServer_CONN mqttServer_10.0.0.163_55885
mqttServer_MSGCNT 1072
mqttServer_TIME 2021-12-08 09:18:33
OLDREADINGS:
READINGS:
2021-12-08 09:15:33 COUNTER_C1 125423
2021-12-08 07:44:04 Time 2021-12-08T07:44:04
2021-12-08 09:15:33 liter 297.56
2021-12-08 09:20:50 literPerMin 0.40000000000000000000000000
helper:
_98_statistics BrunnenWasserZaehlerStatDev
Attributes:
autocreate 0
comment 421.5 impulse = 1 liter
event-min-interval .*:3600
event-on-change-reading COUNTER_C1,.tmp_literPerMin,literPerMin,liter
group Wasser
icon measure_water_meter
readingList brunnen:tele/tasmota_CE94EE/LWT:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/INFO1:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/INFO2:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/SENSOR:.* { json2nameValue($EVENT) }
room Technik-Wasser
stateFormat liter l ( COUNTER_C1 )
timestamp-on-change-reading .*
userReadings .tmp_literPerMin:COUNTER_C1:.* differential {ReadingsVal($NAME,"COUNTER_C1",0)/421.5*60;;},
statLiter:dummy:.* {"versuch, das reading updatebar zu machen";;},
literPerMin:.tmp_literPerMin:.* {sprintf("%.2f",ReadingsVal($NAME,".tmp_literPerMin",0));;},
liter:COUNTER_C1:.* {sprintf("%.2f",ReadingsVal($NAME,"COUNTER_C1",0)/421.5);;}
verbose 2
FHEM>
"testreading" fehlt,
"literPerMin" wurde geändert
Ich lese und staune. Funktioniert das ohne statistics?
Ich gehe z.Zt. davon aus, dass das ein statistics Artefakt ist.
nun hab ich es gefunden - reproduzierbare Ursache ist das Attribute "timestamp-on-change-reading .*" am MQTT2_DEVICE
ohne timestamp-on-change-reading klappts:
Internals:
CFGFN
CID brunnen
DEF brunnen
DEVICETOPIC BrunnenWasserZaehler
FUUID 61b07fa4-f33f-2a7c-1cb6-4061762f711d2a9b
IODev mqttServer
LASTInputDev mqttServer
MSGCNT 39
NAME BrunnenWasserZaehler
NR 1768
STATE 310.76 l ( 130987 )
TYPE MQTT2_DEVICE
mqttServer_CONN mqttServer_10.0.0.163_54243
mqttServer_MSGCNT 39
mqttServer_TIME 2021-12-08 11:15:32
OLDREADINGS:
READINGS:
2021-12-08 11:15:32 COUNTER_C1 130987
2021-12-08 11:15:32 Time 2021-12-08T11:15:32
2021-12-08 11:12:32 liter 310.76
2021-12-08 11:12:32 literPerMin 0.53
2021-12-08 11:12:32 statLiter Hour: 0.89 Day: 0.89 Month: 0.89 Year: 0.89 (since: 2021-12-08_11:11:14 )
helper:
_98_statistics BrunnenWasserZaehlerStatDev
Attributes:
autocreate 0
comment 421.5 impulse = 1 liter
event-min-interval .*:3600
event-on-change-reading COUNTER_C1,.tmp_literPerMin,literPerMin,liter
group Wasser
icon measure_water_meter
readingList brunnen:tele/tasmota_CE94EE/LWT:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/INFO1:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/INFO2:.* { json2nameValue($EVENT) }
brunnen:tele/tasmota_CE94EE/SENSOR:.* { json2nameValue($EVENT) }
room Technik-Wasser
stateFormat liter l ( COUNTER_C1 )
userReadings .tmp_literPerMin:COUNTER_C1:.* differential {ReadingsVal($NAME,"COUNTER_C1",0)/421.5*60;;},
literPerMin:.tmp_literPerMin:.* {sprintf("%.2f",ReadingsVal($NAME,".tmp_literPerMin",0));;},
liter:COUNTER_C1:.* {sprintf("%.2f",ReadingsVal($NAME,"COUNTER_C1",0)/421.5);;}
kann mir da wer bitte den Zusammenhang erklären
Das hab ich bei mir auch schon festgestellt gehabt, jetzt nicht mit setreading, aber mit gesetztem timestamp-on-change-reading werden keine neuen Readings vom Modul angelegt.
Zitatohne timestamp-on-change-reading klappts:
Ich tippe eher auf event-on-change-reading. Aus der Doku:
If set, only changes of the listed readings create events. Ich frage mich, wieso "jeder" dieses Attribut setzen muss.
Ich komme seit 10+ Jahren sehr gut ohne die event-* Attribute klar.
ich verwende beide Attribute gerne, da
- ich an hand des Timestamps schnell die Zeit der letzen Änderung sehe
- ich (meiner Meinung) die Eventlast reduziere
das "event-on-change-reading" steuert ja nur, ob events generiert werden oder nicht.
doku:Wenn gesetzt, erzeugen nur Veränderungen der gelisteten "readings" ein Ereignis. Wenn die aktualiserten Werte der gelisteten "readings" identisch sind, wird kein Ereignis generiert.
das "timestamp-on-change-reading" sollte beim schreiben von readings nur dann den timestamp updaten, wenn sich der wert geändert hat.
doku:Wenn gesetzt, werden die Zeitstempel der gelisteten "readings" nicht aktualisiert wenn durch ein ebenfalls gesetztes event-on-change-reading für dieses "reading" kein Ereignis erzeugen würde.