So abgekoppelt von der anderen Frage, hier mal eine verständnis Frage zu den zwei Events.
Ich habe ein dummy Device
define test dummy
attr test event-on-change-reading a.*
attr test timestamp-on-change-reading .*
# CFGFN
# FUUID 63ae9586-f33f-1e88-08df-4911a01bd9d4a332
# NAME test
# NR 190419
# STATE ???
# TYPE dummy
# eventCount 6
# READINGS:
# 2022-12-30 08:41:25 blubb 3
# hmccu:
#
setstate test 2022-12-30 08:41:25 blubb 3
jetzt führe ich ein primitives
setreading test blubb 5
danach hat sich das reading nicht geändert
....
setstate test 2022-12-30 08:41:25 blubb 3
mein Gedanke von der definition wäre ja, das alle readings die mit a anfangen sollte eine event/notify auslösen.
und timestamp sollte bei allen readings immer dann geschrieben werden wenn sich auch der wert ändert.
Zitat von: sn0000py am 30 Dezember 2022, 08:46:44
So abgekoppelt von der anderen Frage, hier mal eine verständnis Frage zu den zwei Events.
Ich habe ein dummy Device
define test dummy
attr test event-on-change-reading a.*
# 2022-12-30 08:41:25 blubb 3
setstate test 2022-12-30 08:41:25 blubb 3
jetzt führe ich ein primitives
setreading test blubb 5
danach hat sich das reading nicht geändert
....
setstate test 2022-12-30 08:41:25 blubb 3
mein Gedanke von der definition wäre ja, das alle readings die mit a anfangen sollte eine event/notify auslösen.
und timestamp sollte bei allen readings immer dann geschrieben werden wenn sich auch der wert ändert.
Da blubb nicht mit "a" beginnt, ist das Beispiel komisch... egal!
Ich habe mal Deinen test-dummy genommen und siehe da: timestamp-on-change-reading scheint
einen Fehler zu haben, denn das reading blubb wird ÜBERHAUPT NICHT verändert.
Lösche ich das attribut, wird das Reading wieder korrekt verändert. und mit entsprechendem
event-on-change-reading gibt es auch Events.
Grüße
naja ich möchte eigentlich bei vielen meiner devices, das nur ein oder zwei readings ein notify auslösen, der rest braucht keine events auslösen.
Aber der Wert sollte trotzdem immer aktuell sein, und generell möchte ich bei den meisten readings immer den timestamp nur geändert haben wenn sich der wert wirklich auch geändert hat.
commandref:
Zitattimestamp-on-change-reading
The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, the timestamps of the listed readings will not be changed if event-on-change-reading is also set and it would not create an event for this reading.
Zitat von: frank am 30 Dezember 2022, 10:06:39
commandref:
es geht mir hier nicht um den timestamp sondern um das reading selbst um den wert des readings
Zitat von: sn0000py am 30 Dezember 2022, 10:09:16
es geht mir hier nicht um den timestamp sondern um das reading selbst um den wert des readings
hm....
das widerspricht doch aber der vorherigen aussage:
Zitat von: sn0000py am 30 Dezember 2022, 09:32:15
naja ich möchte eigentlich bei vielen meiner devices, das nur ein oder zwei readings ein notify auslösen, der rest braucht keine events auslösen.
Aber der Wert sollte trotzdem immer aktuell sein, und generell möchte ich bei den meisten readings immer den timestamp nur geändert haben wenn sich der wert wirklich auch geändert hat.
Ich habe das bei mir jetzt mal kurz nachgebaut.
Es ist tatsächlich so, dass wenn timestamp-on-change-reading gesetzt ist (.*) und das Reading von event-on-change-reading ausgeschlossen ist, wird das Reading bei Änderung mittels setreading, gar nicht mehr geändert.
Das scheint grundsätzlich der Fall zu sein, sobald timestamp-on-change-reading auch das zu ändernde Reading einschließt. Das Problem tritt auf, sobald auf .* oder b.* gesetzt, nicht aber wenn auch auf a.* gesetzt.
Wohlgemerkt, es geht nicht um die Aktualisierung der Anzeige im Frontend, die bräuchte ja den Event, das ist schon klar, aber nach einem Reload sollte der geänderte Wert sichtbar sein. Aber der Wert des Readings ändert sich einfach nicht.
Für mich ist das auch nicht das erwartete Verhalten. Das Reading (der Wert) selbst sollte schon aktualisiert werden, egal was für die timestamps gilt.
Gruß Benni
Zitat von: sn0000py am 30 Dezember 2022, 09:32:15
naja ich möchte eigentlich bei vielen meiner devices, das nur ein oder zwei readings ein notify auslösen, der rest braucht keine events auslösen.
Da bin ich - wie viele andere hier - voll bei Dir.
Zitat
Aber der Wert sollte trotzdem immer aktuell sein, und generell möchte ich bei den meisten readings immer den timestamp nur geändert haben wenn sich der wert wirklich auch geändert hat.
Ich habe immer noch keine "Killer-Applikation" im Kopf, die ein timestamp-on-change-reading braucht.
Mache ich Licht für drei Minuten an => on-for-timer
Soll das Haus meckern, wenn ein Fenster zu lange offen ist => watchdog
... => at
...
Trotzdem sollte IMHO ein gesetztes timestamp-on-change-reading IN EGAL WELCHEN Konstellationen nicht
dazu führen, dass Werte in Readings gar nicht mehr geändert werden.
Grüße
Zitat von: Benni am 30 Dezember 2022, 10:29:49
Es ist tatsächlich so, dass wenn timestamp-on-change-reading gesetzt ist (.*) und das Reading von event-on-change-reading ausgeschlossen ist, wird das Reading bei Änderung mittels setreading, gar nicht mehr geändert.
ich habe es auch probiert.
das ist auch für mich eindeutig ein bug.
falls das reading noch nicht existiert, kann man es über setreading noch nicht einmal "anlegen".
Zitat von: frank am 30 Dezember 2022, 10:39:57
ich habe es auch probiert.
das ist auch für mich eindeutig ein bug.
falls das reading noch nicht existiert, kann man es über setreading noch nicht einmal "anlegen".
Spätestens jetzt müsste dann aber @sn0000py es wo hin schieben, wo es auch Rudi mitbekommt...
Automatisierung?
Gruß, Joachim
Dann gehört der Thread aber nach:
File Maintainer Forum
=========================================================================
fhem.pl rudolfkoenig Sonstiges
Oder?
Ich habe das auch nachgestellt mit gleichem Ergebnis. Im dem Moment wo tocr ins Spiel kommt wird das Reading nicht mehr angelegt, wenn die Events mit eocr verhindert wurden.
Zitat von: MadMax-FHEM am 30 Dezember 2022, 10:51:09
Spätestens jetzt müsste dann aber @sn0000py es wo hin schieben, wo es auch Rudi mitbekommt...
Automatisierung?
Gruß, Joachim
Oder einer, der es darf schreibt hier https://forum.fhem.de/index.php?topic=52483.0 (https://forum.fhem.de/index.php?topic=52483.0) mal eine
Antwort mit dem Verweis auf diesen Thread.
Grüße
Sehe das auch als (durchaus charmanten!) bug an.
Zitat von: alanblack am 30 Dezember 2022, 10:35:02
Ich habe immer noch keine "Killer-Applikation" im Kopf, die ein timestamp-on-change-reading braucht.
Ich will z.B. wissen, wann etwas eingeschaltet wurde. Wenn aber sowas wie ein Shelly-MQTT-Device meint, den Relay-Status immer mal wieder aktualisieren zu müssen, schalte ich (beschränkt auf dieses eine Reading "state") da auch die timestamp-Aktualisierung aus und halte das auch für "best practice". Ob das Ding noch erreichbar ist, kann man in diesem Fall über LWT-Mechanismen erfahren.
habs mal hier gepostet
https://forum.fhem.de/index.php/topic,131248.0.html