Charts werden nicht gerendert > invalid timestamp because hours are not 0

Hallo zusammen,

ich habe ein ärgerliches Problem. Ich hatte mal einen Stromausfall und da ist wohl der Raspberry schneller hochgefahren, als die FritzBox. Das heißt, ohne Internet > kein Datum/Uhrzeit. Leider hat Symcon fleißig weitergeloggt und die Timestamps sind quasi in die Vergangenheit gerutscht. Viele Trends gehen leider deshalb nicht mehr. Hatte das auch schon mal jemand? Wäre es vielleicht nicht schlecht, wenn Symcon überprüft, ob die Timestamps auch „in der Zukunft“ liegen?

Mittlerweile habe ich eine USV und Symcon läuft auf einem PC. Da sollte es eigentlich nicht passieren, aber ich denke vielleicht wäre das trotzdem nicht schlecht.

Habt ihr eine Idee, wie ich die ganzen korrupten Dateien automatisiert reparieren kann?

Vielen Dank!

Liebe Grüße Sebastian

Wenn du im Archiv alles neu aggregierst sollte das Problem verschwinden. Wir ignorieren dann dieses Problem.

IP-Symcon wartet beim Starten tatsächlich darauf, dass die korrekte Zeit gesetzt wird (~60 Sekunden), sodass wir dort einen Failsafe drin haben.

paresy

Hi @paresy,

habe schon öfter mal die neu Aggregation angestoßen. Interessanterweise, verändern sich ab und zu die Fehlermeldungen. Bei einer anderen Variable steht nun „Timestamps need to be in the correct order“. Aber auch nur bei der Raw Darstellung. Diesen Fehler bekomme ich leider nicht weg und sehe im ersten Moment auch keine Fehler in der Rohdatei.

Hier die Rohdateien, von den Monaten, mit der Fehlermeldung (csv nach txt unbenannt):

25050DEZ.txt (63.4 KB)
25050NOV.txt (59.7 KB)

Bei welcher Stufe und welchem Zeitraum kommt diese Fehlermeldung denn? Du kannst durch ein immer weiteres „Reinzoomen“ das wahrscheinlich auf eine einzelne Stunde reduzieren. Und dann schau dir dort mal die CSV-Werte an. Da sollte die Reihenfolge dann nicht passen und die Werte nicht in chronologischer Reihenfolge stehen. Den problematischen Wert müsstest du dann entfernen.

Man kann durch reinzoomen und suchen tatsächlich den fehlerhaften Eintrag finden und entfernen. Allerdings ist mir aufgefallen, das in der Webconsole im Archive Handler die Einträge in der richtigen Reihenfolge angezeigt werden (was sie aber nicht sind) und in der Legacy Konsole die Einträge auch in der falschen Reihenfolge angezeigt werden. So kann man das auch einfacher sehen, als per Zeitstempel in der csv Datei. Scheinbar korrigiert die Webconsole die Anzeige, was aber mehr für Verwirrung sorgt.

Ich bin immer noch dafür, dass Symcon keine neuen Timestamps in der Vergangenheit setzen sollte. Bei 200 Variablen sind so Fehler extrem mühselig zu korrigieren. Und auch eine neu Aggregation schafft wie bei mir leider nicht immer Abhilfe.

Kann Symcon denn nicht die fehlerhaften Werte bei einer Reaggregation direkt löschen. Mit den Werten kann man doch eh nichts mehr anfangen.
Wenn ich jeden einzelnen manuell löschen sollte, hätte ich in den nächsten Wochen nichts anderes mehr zu tun.

Wie würdest du dir hier einen Automatismus vorstellen? Soll sortiert werden oder werden problematische Datensätze gelöscht? Welche Datensätze sind die problematischen?

Da durch die Datensätze der Graph nicht mehr nutzbar ist, wäre es sicherlich schön hier eine automatisierte Korrektur zu fahren. Ich bin mir aber aktuell unsicher, was hier das beste Vorgehen wäre. In einer der nächsten Version möchten wir allerdings das Archiv überarbeiten, ich kann mir gut vorstellen, dass eine entsprechende Erweiterung da mit kommen kann.

Ich denke, das Beste wäre sicherlich eine Neusortierung der Zeitstempel. Das heißt, es müsste analysiert werden, wo die Fehler sind und dementsprechend die Zeitstempel neu angepasst werden. Sicherlich recht aufwendig. Da normalerweise sowas eher kurz vorkommt, wäre ein Löschen der betreffende Zeitstempel natürlich eine Option. Die fehlerhaften Zeitstempel sind meiner Meinung nach die, welche auf einmal in der Vergangenheit liegen, oder auch andere Konflikte, worauf die Charts nicht mehr funktionieren. Das werden die meisten momentan auch händisch so durchführen.

Wenn die Archiv Funktion ohnehin erneuert wird, könnte man sich überlegen, ob man vielleicht ein etwas mächtigeres Tool bekommt, wo man so fehlerhafte Stellen suchen kann und händisch/automatisch korrigiert/korrigieren kann.

Ich bin nicht sicher, ob wir bei einer Neusortierung der Zeitstempel das gleiche meinen. Du schreibst etwas vom anpassen der Zeitstempel. Das sehe ich dort nicht. So wie ich mir eine Neusortierung vorstelle, würden alle Zeitstempel gleich bleiben, aber in die richtige Reihenfolge gebracht werden. Habe ich also beispielsweise Datensätze von 9:00, 11:00, 12:00, 10:00, würden diese danach in Reihenfolge sein, also 9:00, 10:00, 11:00, 12:00. Jeder Datensatz würde seinen gleichen Zeitstempel und Wert behalten. Dafür wäre dann auch irrelevant, ob der Fehler die 10:00 Uhr sind, die zu spät kamen oder die 11:00 und 12:00 die zu früh kamen. Sollte natürlich nur die Uhr zwischenzeitlich einen Schluckauf gehabt haben und die Werte eigentlich in der ursprünglichen Reihenfolge korrekt waren und nur die Zeitstempel verdreht waren, könnte natürlich insbesondere eine Zähleraggregation damit kaputt gehen. Wäre das eine Lösung in deinem Sinne?

Da der Fehler eher in der Uhrzeit steckt (wir haben ja die Daten immer nur angefügt und nie dazwischen sortiert) halte ich ein Umsortieren für nicht wirklich zielführend. Und korrigieren kann man diese auch nicht, da man den echten Zeitstempel zum Wert nie wieder herausbekommt.

Meiner Meinung nach hilft nur Löschen - und dadurch verdeckt man, dass es Fehler gab. Aktuell kann man beim Aggregieren nämlich nachvollziehen wann Fehler aufgetreten sind. (Für Endanwender sicherlich wenig notwendig. Im professionellen Einsatz werden Fehler ernster genommen und analysiert warum die Uhrzeit falsch war mit der geloggt wurde. Und dafür muss man zumindest wissen, wann es Fehler gab)

Trotzdem kann ich mir ein „Löschen“ gut vorstellen, damit man als normaler Anwender die doofen Fehlermeldungen los wird :smiley:

paresy

Bei mir tauchen diese Fehler auch ab und zu auf. Wobei ich meine, die Ursache in Zeitabweichungen von PC-Zeit und Zeitserver gefunden zu haben.

Beispiel: der Symcon PC geht täglich 5 Sekunden vor und eine Variable wird sekündlich geloggt. Wird dann die Uhrzeit vom Betriebssystem anhand des Zeitservers irgendwann korrigiert (also zurückgesetzt), dann sind die nachfolgenden Einträge in der falschen Reihenfolge.

Ich fände es am besten, wenn schon beim Einfügen eines Eintrages geprüft würde, dass der neue Zeitstempel nicht kleiner ist als der letzte. Ist das der Fall, sollte das Einfügen unterbleiben. Keine Ahnung, ob das performant möglich ist.

Burkhard

Dies sollte eigentlich auf Linux Systemen welche NTP nutzen nicht passieren, da NTP die Zeit nach und nach korrigiert.

Ich fände es am besten, wenn schon beim Einfügen eines Eintrages geprüft würde, dass der neue Zeitstempel nicht kleiner ist als der letzte. Ist das der Fall, sollte das Einfügen unterbleiben. Keine Ahnung, ob das performant möglich ist.

Burkhard

Das wäre sicherlich möglich. (Würde aber wie oben beschrieben Fehler verdecken)

paresy

Ich nutze Windows und die Fritzbox ist als Zeitserver eingetragen. Die wiederum holt sich die Zeit von „2.europe.pool.ntp.org“.

Das war bislang mein Erklärungsansatz, aber vielleicht liege ich da ja auch falsch.

Heute hatte ich wieder Inkonsistenzen im Archiv und meine Prüfroutine meldete Archiveinträge in der falschen Reihenfolge bei Variablen, die sekündlich geloggt werden (die Daten kommen vom Energiezähler):

Variable: #35568, Eintrag 2020.05.06 15:05:00 liegt hinter 2020.05.06 15:04:59
Variable: #47491, Eintrag 2020.05.06 15:05:00 liegt hinter 2020.05.06 15:04:59
Variable: #32048, Eintrag 2020.05.06 15:05:00 liegt hinter 2020.05.06 15:04:59

In der Windows Ereignisanzeige gibt es dafür auch einen Hinweis:

Die Systemzeit wurde von ‎2020‎-‎05‎-‎06T13:04:59.620152500Z in ‎2020‎-‎05‎-‎06T13:04:59.619380100Z geändert.

Änderungsgrund: An application or system component changed the time.
Prozess: '\Device\HarddiskVolume4\Windows\System32\svchost.exe' (PID 6564).

Es wurde die Systemzeit also minimalst (um 8 Millisekunden) zurückgesetzt. Seltsam, dass sich diese minimale Korrektur im Archiv in einer ganzen Sekunde bemerkbar macht.

Ich denke das ist die Erklärung für die Inkonsistenz. Vielleicht könnte man doch zumindest bei einer Verschiebung bis zu einer Sekunde den zeitlich falsch liegenden Datensatz gar nicht erst einfügen. Vielleicht mit einem Logfile Eintrag verbunden.