UNSOLVED Phoscon Zeitstempel
-
Hallo zusammen,
ich habe das Problem, dass die von Phoscon geloggten Daten im Zeitstempel zwei Stunden Versatz haben. Ich habe das Thema auch hier (https://forum.iobroker.net/post/254354) schon gefunden, konnte dort aber irgendwie nicht antworten.
Iobroker selbst und Phoscon GW ist in der richtigen Zeit. Nur eben nicht die Datenlogs, die vom Phoscon Adapter im ioBroker ankommen.
Hat jemand zwischenzeitlich eine Lösung oder einen Workaround für das Problem?
Grüße
Scotty -
@scotty wrlche version des Adapters läuft bei dir? Das Thema ist mit 1.3.x behoben worden.
-
Ich benutze deConz Version: 2.5.71 & API Version: 1.16.0
-
@scotty ich wollte die Adapter version wissen.
-
1.3.10
-
@scotty hast du mal die Zeitzone auf deinem ioBroker host geprüft? Phoscon spuckt drn Zeitstempel als UTC Zeit aus und der Adapter passt es dann auf die Lokale Zeitzone an.
-
iouser@iobroker:~$ date
Tue 18 Aug 2020 09:06:06 PM CEST -
hab noch schnell ein testscript laufen lassen:
log(new Date());
gibt im log
(931) script.js.JStestscript: Tue Aug 18 2020 21:09:58 GMT+0200 (Central European Summer Time) -
Dann weis ich nicht woher das kommt. Gibt es irgendwelche Fehler im Log?
-
leider (?) nicht
-
die Zeitzone auf dem phoscon GW zu ändern, hat keinerlei Auswirkung auf die Zeitstempel der geloggten Daten der Datenpunkte über deconz..... hier also leider kein einfacher Workaround ;(
-
nur nochmal zur Klarstellung:
mit den falschen Zeitstempeln meine ich nicht den iobroker Log, hier stimmen die Daten. Es geht um die Historie, welche über "Objekte-> deconz -> DatenpunktXY -> Einstellungen -> Tabelle" abzurufen ist.
Ich geb für heute auf.... weitere Tips sind willkommen.
-
hat noch wer einen Tip? Ich stelle auch gern noch Informationen zur Verfügung, wenn mit jemand sagt was zur Lösung hilfreich sein könnte.
-
Problem gelöst
Bei zufälligem "rumspielen" von meinem Windows PC aus, stelle ich fest, dass plötzlich korrekte Zeiten geloggt werden. Der Versuch den Zeitpunkt des Beginns des korrekten Loggings über einen Zeitsprung in den Daten zu finden blieb erfolglos. Als ich mich zur näheren Analyse an den Laptop setzte, in welchem ich sonst üblicherweise in einer LinuxVM "rumspiele", war das korrekte Logging wieder weg.
Der Fehler, dass die Daten in der Tabelle und selbst im FLOT um 2 Stunden versetzt angezeigt werden lag bei mir also an einer falschen Systemzeit des browsenden Rechners!? Dass die Clientzeit sogar die Tabellenansicht umschreibt, hätte ich nicht gedacht, sondern erwartet, dass das statische Werte aus SQL sind.
Vllt. hilfts wem...
-
@scotty Danke für deine Rückmeldung. Das ist ja super Kurios.
