vorschlag: neues attribut timestamp-on-change-reading

Begonnen von justme1968, 21 April 2016, 14:54:31

Vorheriges Thema - Nächstes Thema

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 einfachenIndex: 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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gandy

fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

rudolfkoenig

Zitatfrage: 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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

#4
dann würde ich vorschlagen erst mal nur das hier: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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Komme Sonntag erst dazu, es anzuschauen/einzuchecken.

betateilchen

Zitat von: justme1968 am 21 April 2016, 15:23:04
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

CoolTux

Hallo Andre,

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


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

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: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?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dr. Boris Neubert

Zitat von: justme1968 am 22 April 2016, 15:16:53
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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968