vorschlag: neues attribut timestamp-on-change-reading

[justme1968]

mit dem angehängten patch ist es mit dem neuen timestamp-on-change-reading attribut möglich einzustellen das der timestamp für ein reading bei dem event-on-change-reading gesetzt ist sich nur noch dann ändert wenn sich der wert auch tatsächlich geändert hat.

hintergrund: manchmal ist es wünschenswert nachträglich rauszufinden wann sich der wert eines readings tatsächlich das letzte mal geändert hat. das ist zur zeit auf der user ebene nicht einfach möglich da der timestamp immer aktualisiert wird und es in einem notify nur für STATE zugriff auf den alten wert gibt.

frage: sollte das nicht eigentlich der default sein das sich der timestamp nicht ändert wenn es kein event gibt? dann wäre es vermutlich auch mit einem einfachen

Code Auswählen Erweitern

Index: fhem.pl
===================================================================
--- fhem.pl (revision 11289)
+++ fhem.pl (working copy)
@@ -4103,7 +4103,7 @@
   }
   
   
-  setReadingsVal($hash, $reading, $value, $hash->{".updateTimestamp"});
+  setReadingsVal($hash, $reading, $value, $hash->{".updateTimestamp"}) if( $changed );
   
   my $rv = "$reading: $value";
   if($changed) {
erledigt.

[gandy]

+1

[rudolfkoenig]

frage: sollte das nicht eigentlich der default sein das sich der timestamp nicht ändert wenn es kein event gibt?

Ich waere auch dafuer, dass wenn ein Filter zuschlaegt, auch der timestamp sich nicht aendert, es sei denn, man setzt ein Attribut (z.Bsp. timestamp-on-change-reading). Soll ich den Patch trotzdem einchecken?

[Markus Bloch]

Ich finde dieses Verhalten ebenfalls wünschenswert (Timestamp nur setzen, wenn $changed wahr). Generell würde ich dies ebenfalls als Standardverhalten wünschen in Verbindung mit einem Attribut, welches wieder das ursprüngliche Verhalten herbeiführt.

Wobei ich mich allerdings frage, ob ein solches "Fallback"-Attribut überhaupt notwendig ist? Wo bräuchte man bei event-on-change-reading dennoch den aktuellen Timestamp des letzten Auftretens?

Gruß
Markus

[justme1968]

dann würde ich vorschlagen erst mal nur das hier:

Code Auswählen Erweitern

Index: fhem.pl
===================================================================
--- fhem.pl (revision 11289)
+++ fhem.pl (working copy)
@@ -4103,7 +4103,7 @@
   }
   
   
-  setReadingsVal($hash, $reading, $value, $hash->{".updateTimestamp"});
+  setReadingsVal($hash, $reading, $value, $hash->{".updateTimestamp"}) if( $changed );
   
   my $rv = "$reading: $value";
   if($changed) {zu ändern und ein timestamp-on-update-reading attribut erst einzubauen wenn tatsächlich ein anwendungsfall auftaucht für den man aktualisierte timestamps auch ohne event braucht.

ps: ein mögliches szenario bei dem es unter umständen nützlich wäre ist das erkennen von ausgefallenen (funk-) sensoren. aber ich vermute mal das hier das event-on-change intervall immer noch reicht.

ein weiteres szenario wären vielleicht watchdogs für allarm anlagen oder ähnliches. aber hier sollte man event-on-change garnicht erst verwenden.

[justme1968]

kommando etwas zurück...

die oben vorgeschlagene einfache variante reicht doch nicht weil $changed nicht nur beim filtern gesetzt wird sondern auch beim aufruf von readingsBulkUpdate vorgegeben wird.

der timestamp sollte immer dann aktualisiert werden wenn das event nicht einem der event-on- filter zum opfer fallen würde. wenn keinen filter zuschlägt sollte der timestamp immer aktualisiert werden.

das heisst aber das man die filter auch dann ausgewerten muss wenn readingsBulkUpdate mit changed=0 aufgerufen wird.

ich mache einen neuen vorschlag.

[justme1968]

anbei ein neuer vorschlag.

der readings timestamp wird dabei nicht mehr aktualisiert wenn normalerweise ein event erzeugt werden würde, dieses aber über die readingFnAttributes unterdrückt wird. dazu war es nötig das bisherige $changed in ein $trigger und $filtered aufzuteilen.

ein mögliches timestamp-on-update-reading attribut um das alte verhalten wieder zu bekommen habe ich noch nicht mit drin. brauchen wir das wirklich?

ich habe diverse kombinationen aus readingFnAttributes getestet bin mir aber nicht sicher ob ich alle erwischte habe. es wäre also gut wenn noch andere mal drüber schauen.

[rudolfkoenig]

Komme Sonntag erst dazu, es anzuschauen/einzuchecken.

[betateilchen]

ps: ein mögliches szenario bei dem es unter umständen nützlich wäre ist das erkennen von ausgefallenen (funk-) sensoren. aber ich vermute mal das hier das event-on-change intervall immer noch reicht.

ein weiteres szenario wären vielleicht watchdogs für allarm anlagen oder ähnliches. aber hier sollte man event-on-change garnicht erst verwenden.

Einen ausgefallenen Sensor am Alter eines Readings zu erkennen, geht doch auch einfacher. Dazu wurde doch vor kurzem die Funktion ReadingsAge() oder so ähnlich eingebaut.

Und bei Homematic Komponenten wird beispielsweise ein ausgefallenes device im ActiomDetector erkannt.

Dass der Timestamp eines Readings wirklich ein zuverlässiges Kriterium ist, wage ich sehr zu bezweifeln. An Problematiken wie Sommer-/Winterzeitumstellung wage ich da gar nicht zu denken.

[justme1968]

ReadingsAge greift über ReadingsTimestamp genau auf den timestamp zu um den es geht. der ist zur zeit für readings die mit event-on-change gefiltert werden unbrauchbar weil sich der timestamp auch ändert wenn das event raus gefiltert wird.

mit der vorgeschlagenen änderung sind ReadingsAge und ReadingsTimestamp auch mit event-on-change sinnvoll zu verwenden weil der timestamp dann auf dem zeitpunkt des tatsächlich letzen updates der nicht raus gefiltert wurde stehen bleibt.


so weit ich das sehe greift der ActionDetector nicht auf die readings timestamps zu. d.h. er sollte weiter funktionieren.

der DeviceMonitor würde aber probleme bekommen wenn ein sensor immer exakt das gleiche sendet und alles mit  event-on-change ohne event-min-interval zu verwenden. das könnte man mit dem zusätzlichen attribut beheben.

bei beidem wäre es sinnvoll wenn das noch andere testen.


probleme bei der zeitumstellung werden wir so lange nicht wirklich in den griff bekommen wie intern mit der lokalen zweit gearbeitet wird. aber das ist ja auch garnicht ziel der änderung. und selbst dann würden manche die 'doppelten' zeiten bei der umstellung auf die winterzeit als problem sehen. dabei ist es einfach das was wirklich passiert.

[CoolTux]

Hallo Andre,

Hier gibt es einen kleinen Hinweis für Deinen Patch. Ich lasse das mal unkommentiert so hier stehen.


Grüße

[justme1968]

mir ist noch etwas ganz anderes aufgefallen. im code wird das filtern nur dann gemacht wenn es das reading schon gab.

das passt aber nicht genau zum wortlaut von event-on-change-reading. wenn event-on-change gesetzt ist (und nichts anderes) wird für readings die nicht in der liste stehen niemals ein event erzeugt. d.h. es sollte auch bei neu hinzugekommen readings so sein die das erste mal gesetzt werden. das ist aber nicht so da die komplette filterung wegen:

Code Auswählen Erweitern

4004   # check for changes only if reading already exists
4005   if($trigger && defined($readings)) {
... übersprungen wird.

d.h. für ein neu hinzugekommenes reading wird immer ein event erzeugt egal was die filter dazu sagen würden.

sollten wir das auch ändern?

[Dr. Boris Neubert]

mir ist noch etwas ganz anderes aufgefallen. im code wird das filtern nur dann gemacht wenn es das reading schon gab.

...

d.h. für ein neu hinzugekommenes reading wird immer ein event erzeugt egal was die filter dazu sagen würden.

sollten wir das auch ändern?

Ja. Wenn es ist, wie Du es sagst, ist es ein Bug.

Viele Grüße
Boris

[Dr. Boris Neubert]

Zum Setzen des Timestamp i.V.m. der Event-Filterung folgende Gedanken:

Mit event-on-update-reading kann man ja die Event-Generierung für nicht gelistete Readings unterbinden.

Wenn die Default-Logik aber diejenige ist, dass Timestamp nur gesetzt wird, wenn Event erzeugt wird, dann führt das zu irgendeinem Verhalten, das ich nicht mehr überblicken kann.

Wir sollten die Event-Logik und die Timestamp-Logik separieren. Ich votiere dafür, die Default-Timestamp-Logik so zu belassen, wie sie ist, also den Timestamp zu setzen, wenn das Reading gesetzt wird. Über ein zusätzliches Attribut timestamp-on-change-reading kann man bestimmen, für welche Readings der Timestamp nur gesetzt wird, wenn sich der Wert des gesetzten Readings ändert.

Bzgl. der Nutzung des Attributs timestamp-on-change-reading sehe ich Anwendungsfälle sowohl dafür, es für ein Reading zu setzen als es auch nicht zu setzen:
- Ich sehe gerne, ob noch grundsätzlich Werte kommen, also ob kürzlich eine Messung stattgefunden hat/regelmäßig Messungen stattfinden.
- Ich würde auch gerne sehen, seit wann der Wert unverändert ist.

M.E. spricht das eher dafür, zwei Timestamps zu haben, einen für die letzte Aktualisierung und einen für die letzte Änderung. Das ist zwar vermutlich nur eine Zeile Code aber keines der Frontends kann damit umgehen.

Viele Grüße
Boris

[justme1968]

die idee mit zwei timestanps hatte ich am anfang auch. und eine version die die flanken in eigenen readings steckt auch.

beim weiter nachdenken ist mir aber aufgefallen das es zwar beide anwendungsfälle gibt, es aber zumindest bei mir so ist das entweder der eine oder der andere ist und nicht beide gleichzeitig.

ein aspekt der für die anderen frontends zu berücksichtigen ist das alles was nicht in einem reading bzw. dem 'normalen' timestanp steht dort erst mal nicht zu verwenden ist.

bei cul, jeelink und panstanp basierten sensoren steht die zeit der letzten empfangenen daten auch in ..._TIME internal.

bei der 'kleinen' variante bleibt jetzt die frage was der default sein soll. so wie bisher oder nur wenn es auch ein event gab. ich denke beides ist in sich konsistent aber letzteres ist der häufigere anwendungsfall. deshalb sollte das der default sein.

events die gefiltert werden 'verschwinden' dann sozusagen komplett.

gruss
  andre

[Dr. Boris Neubert]

bei der 'kleinen' variante bleibt jetzt die frage was der default sein soll. so wie bisher oder nur wenn es auch ein event gab. ich denke beides ist in sich konsistent aber letzteres ist der häufigere anwendungsfall. deshalb sollte das der default sein.

events die gefiltert werden 'verschwinden' dann sozusagen komplett.

Bin mir nicht sicher, ob Du das meinst, was ich herauslese. Unabhängig davon, ob der Default ist, den Timestamp nur bei einer Änderung des Readings oder bei einem Setzen des Readings zu aktualisieren, sollte der Mechanismus unabhängig davon sein, wie event-on-update-reading und event-on-change-reading gesetzt sind. Ich glaube, dass eine Kopplung der Mechanismen zu nicht mehr durchschaubarem Verhalten und noch schwerer wartbaren Code führt als jetzt schon.

Das Attribut würde wie folgt aufgerufen (ich schreibe das so, dass das gleich in die Commandref aufgenommen werden könnte):

Code Auswählen Erweitern

attr <name> timestamp-on-change-reading reading1,reading2,reading3,...

The attribute takes a comma-separated list of readings. You may use regular expressions in that list.
For the listed readings of the device <name>, the timestamp is updated if and only if the value of the reading has changed. In other words: for a reading in the list, the timestamp of the reading is unchanged and remains at the time of the most recent change of the reading when the reading is updated but the new value is identical to the previous value. The list of readings can be empty.

Jetzt zur Frage des Defaults:

Variante 1: der Timestamp wird nur gesetzt, wenn sich der Wert des Readings geändert hat.

When the attribute is not set, the default behavior is to change the timestamp for all readings of the given device <name> if and only if the value of the reading has changed. To achieve the opposite behavior, i.e. to always set the timestamp of any reading no matter if an update of the reading has changed its value or not, you have to set the attribute with an empty list:

Code Auswählen Erweitern

attr <name> timestamp-on-change-reading

Variante 2: der Timestamp wird immer gesetzt, wenn der Wert des Readings ein Update erfahren hat.

When the attribute is not set, the default behavior is to change the timestamp for all readings of the given device <name> whenever the reading is updated, no matter if its value has changed or not.

To achieve the opposite behavior, i.e. to only set the timestamp of any reading if an update of the reading has changed its value, you have to set the attribute:

Code Auswählen Erweitern

attr <name> timestamp-on-change-reading .*

Variante 2 ist abwärtskompatibel und in sich schlüssig/intuitiv: ich muss das Attribut setzen und die Readings angeben, für die ich das erreichen will, was die Bezeichnung des Attributs aussagt: timestamp-on-change-reading. Ich kann das Default-Verhalten für alle Geräte mit

Code Auswählen Erweitern

attr .* timestamp-on-change-reading .*

leicht umkehren.

Ich plädiere für Variante 2.

Viele Grüße
Boris



EDIT: es soll überall timestamp-on-change-reading heißen

[rudolfkoenig]

sollte der Mechanismus unabhängig davon sein, wie event-on-update-reading und event-on-change-reading gesetzt sind.

Ich bin auch dafuer. Die nachfolgenden Texte haben mich verwirrt, weil da von einem timestamp-on-update-reading die Rede war. Ich wuerde bei "timestamp-on-changed-reading" bleiben, und falls jemand sowas braucht, der soll es setzen. Falls ich was einchecken soll, bitte explizit sagen.

[justme1968]

timestamp-on-update-reading wäre die variants gewesen bei der der timestamp als default nur noch bei einem event aktualisiert wird und man mit dem attribut das bisherige verhalten wieder herstellen möchte. das scheinen wir inzwischen verworfen zu haben.

wenn das default verhalten bleibt und man die timestamps abschalten will wenn es kein event gibt wäre das attribut timestamp-on-change-reading.

das wäre dann der patch aus dem ersten post. ich schaue mir den patch noch mal und ob alles was diskutiert wurde schon drin steckt und auch ob man den weiter oben beschrieben fehler beim ersten anlegen nicht auch gleich weg bekommt.

[Dr. Boris Neubert]

Ich bin auch dafuer. Die nachfolgenden Texte haben mich verwirrt, weil da von einem timestamp-on-update-reading die Rede war. Ich wuerde bei "timestamp-on-changed-reading" bleiben, und falls jemand sowas braucht, der soll es setzen. Falls ich was einchecken soll, bitte explizit sagen.

Ich war beim Schreiben verwirrt. Es sollte "timestamp-on-change-reading" heißen. Ich habe meinen Beitrag angepasst. Ich hoffe, dass es jetzt verständlich ist.

[justme1968]

anbei ein patch der den fehler beim filtern behebt wenn ein reading das erste mal angelegt wird, ansonsten das default verhalten beibehält und ein timestamp-on-change-reading attribut einführt.

[rudolfkoenig]

Habs eingecheckt (bis auf das Entfernen der quiet Option von cancel in commandref_frame.html)

[Sidey]

Hallo allerseits,

bitte entschuldigt, das sich diesen 120 Tage alten Thread wieder reaktiviere.
Bringt aber meiner Meinung nach nichts, die Unklarheit in einem neuen Beitrag zu beantworten.

Ich habe mir den Thread durchgelesen und hatte dann ein gewisses Bild:

Unabhängig davon, ob der Default ist, den Timestamp nur bei einer Änderung des Readings oder bei einem Setzen des Readings zu aktualisieren, sollte der Mechanismus unabhängig davon sein, wie event-on-update-reading und event-on-change-reading gesetzt sind. Ich glaube, dass eine Kopplung der Mechanismen zu nicht mehr durchschaubarem Verhalten und noch schwerer wartbaren Code führt als jetzt schon.

Variante 2: der Timestamp wird immer gesetzt, wenn der Wert des Readings ein Update erfahren hat.

Variante 2 ist abwärtskompatibel und in sich schlüssig/intuitiv: ich muss das Attribut setzen und die Readings angeben, für die ich das erreichen will, was die Bezeichnung des Attributs aussagt: timestamp-on-change-reading. Ich kann das Default-Verhalten für alle Geräte mit

Code Auswählen Erweitern

attr .* timestamp-on-change-reading .*

leicht umkehren.

Ich plädiere für Variante 2.

Ich bin auch dafuer. Die nachfolgenden Texte haben mich verwirrt, weil da von einem timestamp-on-update-reading die Rede war. Ich wuerde bei "timestamp-on-changed-reading" bleiben, und falls jemand sowas braucht, der soll es setzen. Falls ich was einchecken soll, bitte explizit sagen.

Vielleicht habe ich Tomaten auf den Augen, dann helft mir bitte. Wenn ich die Beitrag richtig verstehe, dann hat man doch sehr stark argumentiert, dass das Setzen eines Readings und das Auslösen eines Events unabhängig voneinander sein soll.

Als ich auf die Commandref aufmerksam gemacht wurde, habe ich gestaunt:

timestamp-on-change-reading
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings". 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.

timestamp-on-change-reading ist nicht unabhängig von event-on-change-reading implementiert.
Genauer gesagt, das Attribut alleine kann nicht verwendet werden.
Es wurde nicht Variante 2 implementiert und man kann es auch nicht leicht für alle Readings umkehren.

Bestimmt habe ich etwas übersehen oder etwas falsch interpretiert?
Wenn nicht, war das ein Versehen und keiner hat es gemerkt oder gab es noch einen weiteren Thread in dem die Funktionsweise des Attributes diskutiert wurde?

Gibt es irgendeinen sinnvollen Anwendungsfall, wofür man das eine Attribut mit dem anderen koppeln sollte?
Auf Anhieb ist mir nichts eingefallen, wieso man das nicht unabhängig voneinander setzen können sollte. Das wäre doch viel einfacher, als überall event-on-change-reading .* setzen zu müssen, wo man den timestamp nicht aktualisieren möchte.


Grüße Sidey