readings mit nicht aktuellen timestamp

[justme1968]

es gibt module bei denen es sinnvoll ist readings nicht mit dem aktuellen timestamp zu versehen sondern mit einem timestamp der zum tatsächlichen zeitpunkt der entstehung des wehrtest passt.

z.b.: abfrage externer dienste die zu jedem wert die original zeit liefern:
withings wage -> pollen nur alle stunde, reading hat den zeitpunkt des wiegens

netatmo modul -> wetter werte bekommen den zeitpunkt der tatsächlichen entstehung

mercedes benz mercedes me modul -> readings bekommen den zeitpunkt an dem tatsächlich tür oder fenster geöffnet/geschlossen wurden, km stand an dem er tatsächlich ausgelesen wurde. beim km stand eventuell besonders auffällig weil er nur 2 mal pro stunde abgefragt werden.

es gibt noch ein paar beispiele mehr.


aktuell wird das von fhem nur über einen workaround und auch nur unvollständig und mit problemen behaftet unterstützt: man kann .updateTimestamp vor und CHANGETIME nach dem aufruf von readingsBulkUpdate auf den richtigen wert 'verbiegen'. mit list oder aufrufen der detail seite sieht man dann den vorgesehenen timestamp. dblog hat damit auch kein problem.

aber: im event zum seiten update kommt trotzdem immer die aktuelle zeit und filelog hat ein problem weil die timestamps im log file nicht mehr monoton sind.

wie können wir das absichtliche setzen einer bestimmten zeit für ein reading in fhem besser unterstützen?

[betateilchen]

langsam werden die Wünsche echt schräg...

Mir ist eigentlich egal, wann ein Wert tatsächlich entsteht, aber im readingTimestamp möchte ich bitte den Zeitpunkt behalten, zu dem FHEM von diesem Wert erfahren und diesen in das reading geschrieben hat.

[justme1968]

nicht immer nur von dir auf andere und deren anforderungen schließen.

den wusch und das beschriebene verhalten gibt es schon viele jahre. in mehr als einem modul.

es gibt anwendungen da ist der tatsächliche zeitpunkt des wertes wichtig. nicht/nicht nur wann er in fhem angekommen ist.

[betateilchen]

Dann sollte man vielleicht einen zusätzlichen valueTimeStamp einführen und nicht den readingsTimestamp dafür mißbrauchen.

nicht immer nur von dir auf andere und deren anforderungen schließen.

Danke gleichfalls.

[justme1968]

Dann sollte man vielleicht einen zusätzlichen valueTimeStamp einführen und nicht den readingsTimestamp dafür mißbrauchen.

zum beispiel.

oder umgekehrt: einen updateTimestamp einführen und readingsTimestamp eben den zeitpunkt des readings sein lassen .

deshalb war die frage ja auch wie wir diesen anwendungsfall besser unterstützten können.

[rudolfkoenig]

Ich habe keine eindeutige Meinung, welche der Zeitstempel der Richtige oder Wichtigere ist, sicher ist, dass ohne weiteres Wissen oder explizite Kennzeichung es den Benutzer verwirrt.

Variante 1: das Reading-Zeitstempel enthaelt den Eingang des Events in FHEM.
- die "eigentliche" Zeit muss in einem separaten Reading, oder als weitere Spalte hinterlegt werden, wenn sie als wichtig erachtet wird.
- es gibt keine Funktion ReadingsTimestamp/ReadingsAge etc fuer diese Werte
- in den Plots kann man die Ereignisse nicht richtig darstellen

Variante 2: das Reading-Zeitstempel enthaelt die vom Fremdsystem uebermittelte Zeit
- FileLog hat Probleme, wenn die Events unsortiert reinkommen. Evtl reicht es, im Erzeugermodul die Events zu sortieren. Ein korrektes Einfuegen beliebiger Zeitstempel in FileLog fuehrt mAn zu weit, ich will keine DB implementieren.
- readings*Update unterstuetzt nur umstaendlich abweichende Zeitstempel
- weitere Bugs wie "seiten update" (ist damit das FHEMWEB-UPdate gemeint?)

Ich meine die readingsUpdate Probleme und die anderen Bugs bei Variante 2 sollten behoben werden, dann hat der Modulautor eine Alternative zu Variante 1. Es muss aber dokumentiert/kenntlich gemacht werden, welche Zeitstempel gemeint sind, und dass mit manchen Modulen (z.Bsp. FileLog) Probleme entstehen koennten.

Ich meine, dass langfristig diese Klasse von Problemen verschwindet, weil eine direkte Verbindung/Push normal wird.

Meinungen?

[rudolfkoenig]

Ich meine die readingsUpdate Probleme und die anderen Bugs bei Variante 2 sollten behoben werden

Ich hoffe das jetzt erledigt zu haben:
- setreading hat einen optionalen Zeitstempel: setreading name [YYYY-MM-DD HH:MM:SS] reading value
- readingsSingleUpdate, readingsBulkUpdate und addEvent haben einen optionalen letzten Parameter $timestamp (Format YYYY-MM-DD HH:MM:SS bzw. FmtDateTime())
- inform timer (in telnet) und FHEMWEB inform beruecksichtigen $hash->{CHANGETIME}

[M.Schulze]

Ich meine, dass langfristig diese Klasse von Problemen verschwindet, weil eine direkte Verbindung/Push normal wird.

Warum sollten solche Klasse von Problemen durch eine direkte Verbindung verschwinden?


Fremdsysteme werden eigene Zeitstempel haben. Da auch hier Teilsysteme synchronisiert werden müssen. Dann stellt sich schon die Frage nach Variante 1 oder Variante 2.

Der Zeitstempel dient sekundär der Speicherung des Zeitpunktes der tatsächlichen Entstehung des Wertes, und primär der Synchronisation und Verteilung des neuen Wertes, bzw. der damit verbundenen Aktivitäten.


- setreading hat einen optionalen Zeitstempel:
Meiner Meinung dürften Zeitstempel für Readings im Betrieb nicht in die Vergangenheit wandern, selbst der gleiche Zeitstempel in Folge wäre nicht zulässig, weil es ja kein neuerer Wert ist.

Das setzen eines alten Zeitstempels ist generell problematisch da der Zeitraum vielleicht schon als synchronisiert gilt. Eine Anwendung könnte im Loop gezielt nur nach neueren Zeitstempeln fragen -> long poll und würde diese Änderungen nicht mitbekommen.

MfG

[rudolfkoenig]

Warum sollten solche Klasse von Problemen durch eine direkte Verbindung verschwinden?

Wenn alle Systeme immer online sind, gibt es keinen Grund Daten versetzt zu uebermitteln.

Die aufgezeigten Probleme sehe ich auch, die Schnittstelle ist aber nicht fuers Einfuegen von Datensaetzen in beliebiger Zeitreihenfolge gedacht, sondern weiterhin monoton steigend. Das Setzen eines anderen Zeitstempels war auch bisher moeglich, nur etwas inkonsistent und weniger komfortabel.

Bei der Abfrage von neueren Datensaetzen muss dem Entwickler bewusst sein, das "neuer" nicht gleichzusetzen ist mit "nach dem Zeitstempel der letzten Synchronisation".