Hallo zusammen,
mir ist aufgefallen, dass meine ReadingsTimestamps meine AQARA Sensoren nicht mehr stimmen.
Wird ein Event ausgelöst, steht im ersten Moment noch die korrekte Zeit. Anschließend wird eine Stunde abgezogen.
Auch im Internal von jedem beliebigen AQARA Sensor stimmt der Wert "lastupdated_local" nicht. Es ist die Umrechnung in Winterzeit angegeben.
Die REST API liefert den UTC Wert. D.h. es ist vermutlich die Konvertierung in FHEM nicht in Ordnung.
Kann das jemand von euch bestätigen? Hat jemand das gleiche Problem?
In der Phoscon GUI werden die Zeiten korrekt angezeigt.
ein {qx(date)} liefert auch den korrekten Winterzeit Datumswert.
Hier noch ein screenshot.
bitte schau mal ob es nach einem
fhem neustart stimmt.
dann liegt das problem darin das der offset nur ein mal beim starten berechnet wird. das muss ich reparieren.
hi ein neustart von FHEM hat das Problem nicht behoben :(
liegt es vielleicht auch daran, dass ich nicht auf deiner letzten Version bin?
# $Id: 31_HUEDevice.pm 18457 2019-01-30 13:34:22Z justme1968 $
Ich hatte mir diese Version von dir genommen und die Rauchmelder eingefügt. Wollte unbedingt die % Zahlen als Batteriestatus bekommen.
kann alles sein :)
ich habe die hardware nicht. deshalb müsstest du das selber testen.
Jupp ist bei mir genau das selbe Problem.
Ich schaue mal etwas genauer.
Also der Timestamp vom Event wird als Readingstimestamp noch korrekt gesetzt. Danach scheint der Readingstimestamp neu gesetzt zu werden. Nach einem reload der Detailansichtsseite ist der Readingstimestamp genau um eine Stunde nach hinten versetzt.
für Sensoren wird nicht der zeitpunkt des pollens verwendet sondern der zeitstempel wird auf den wert gesetzt den der sensor meldet.
dazu gibt es in fhem einen selten verwendeten mechanismus über CHANGETIME im device hash.
da die bridge die zeit aber (meist) in utc liefert muss der offset im modul selber berechnet werden.
wegen dem 'meist' oben hat popi einen patch geliefert (siehe hier: https://forum.fhem.de/index.php/topic,95322.msg886142.html#msg886142). ich vermute das dort der offset nur ein mal berechnet wird und das dies bei der zeit umstellung dann schief geht. deshalb die frage ob ein neustart hilft.
Zitat von: justme1968 am 09 April 2019, 13:07:49
für Sensoren wird nicht der zeitpunkt des pollens verwendet sondern der zeitstempel wird auf den wert gesetzt den der sensor meldet.
dazu gibt es in fhem einen selten verwendeten mechanismus über CHANGETIME im device hash.
da die bridge die zeit aber (meist) in utc liefert muss der offset im modul selber berechnet werden.
wegen dem 'meist' oben hat popi einen patch geliefert (siehe hier: https://forum.fhem.de/index.php/topic,95322.msg886142.html#msg886142). ich vermute das dort der offset nur ein mal berechnet wird und das dies bei der zeit umstellung dann schief geht. deshalb die frage ob ein neustart hilft.
Neustart generell oder nach der Zeitumstellung?
Wenn nach der Zeitumstellung, dann kann ich das definitiv beneinen. Es bleibt das Problem bestehen.
beim ersten neustart nah der umstellung sollte es wieder ok sein.
wenn nicht: schauen ob die zeit in der bridge ok und richtig konfiguriert ist.
Die Zeit in der Bridge ist korrekt. Sie zeigt genau die Zeit vom System an. Also die aktuelle.
Neustart von FHEM mache ich morgen im Laufe des Vormittags.
Ein neustart half mir nicht.
Bin ich ja froh, dass ich nicht alleine das Problem habe ;)
Grüße
Ups sorry verpennt.
Neustart von FHEM half bei mir.
Allerdings war ich gestern Abend bereits gezwungen die deconz Software neu zu starten.
Also vielleicht mal beides starten.
Ok, aktuelle 31_HUEDevice.pm, reboot deCONZ und reboot FHEM haben geholfen.
Gut das es bald keine Zeitumstellung mehr gibt :P
Grüße,
yamaha1983