event|timestamp-on-change-reading

[sn0000py]

So abgekoppelt von der anderen Frage, hier mal eine verständnis Frage zu den zwei Events.

Ich habe ein dummy Device

Code Auswählen Erweitern

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

Code Auswählen Erweitern

setreading test blubb 5

danach hat sich das reading nicht geändert

Code Auswählen Erweitern

....
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.

[alanblack]

So abgekoppelt von der anderen Frage, hier mal eine verständnis Frage zu den zwei Events.

Ich habe ein dummy Device

Code Auswählen Erweitern

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

Code Auswählen Erweitern

setreading test blubb 5

danach hat sich das reading nicht geändert

Code Auswählen Erweitern

....
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

[sn0000py]

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.

[frank]

commandref:

timestamp-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.

[sn0000py]

commandref:

es geht mir hier nicht um den timestamp sondern um das reading selbst um den wert des readings

[frank]

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:

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.

[Benni]

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

[alanblack]

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.

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

[frank]

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".

[MadMax-FHEM]

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

[Otto123]

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.

[alanblack]

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 mal eine
Antwort mit dem Verweis auf diesen Thread.

Grüße

[Beta-User]

Sehe das auch als (durchaus charmanten!) bug an.

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.

[sn0000py]

habs mal hier gepostet
https://forum.fhem.de/index.php/topic,131248.0.html