Uptime u.ä. läuft zu schnell

[michaelst]

Hallo,

ich habe die WARP1 (FW1.3.0) per MQTT mit einem Broker verbunden.
Mit meiner Haussteuerung (TwinCAT) lese ich dort diverse Werte zur Weiterverarbeitung und Visualisierung aus.

Unter anderem sind es die evse/state/uptime, .../time_since_state_change, evse/btton_state/button_press_time

Mit der aktuellen PLC-Zeit (sekundengenau), welche täglich mit einem externen Zeitserver synchronisiert wird,
bilde ich die Differenz und erhalte so die exakten Zeitpunkte, an dem die Box gestartet wurde,
der letzte Statuswechsel und Knopfdruck statt gefunden hat.

Da ich die Wallbox nicht neu starte, keinen Statuswechsel triggere und den Knopf nicht drücke,
sollten sich die drei berechneten Zeitpunkt auch nicht verändern (siehe Online-Werte).

PLC-Code:

tWallboxUptime := DINT_TO_TIME(Wallbox.diUptime);
tWallboxStart := tCurrentTimeDate - DINT_TO_TIME(Wallbox.diUptime);
tWallboxButtonPressed := tWallboxStart + DINT_TO_TIME(Wallbox.diButtonPressTime);
tWallboxLastStateChange := tCurrentTimeDate - DINT_TO_TIME(Wallbox.diTimeSinceStateChange);

Online-Werte:

Wir betrachten uns, als Beispiel, die Berechnung von tWallboxStart:
tCurrentTimeDate (aktuelle Zeit der PLC) und Wallbox.diUptime werden (theoretisch) gleichmäßig größer, daher ist die Differenz,
also tWallboxStart, konstant. Da die beiden Uhren (PLC und Wallbox) in der Praxis nicht synchron sind, sollte die Differenz mit der
Zeit etwas weglaufen. Das ist ja grundsätzlich auch OK.

Bei mir, ich vermute auch bei anderen, ist es aber so, dass ich eine Ungenauigkeit von ca. 6 Minuten pro Tag habe.
Das bedeutet, dass der oben zu sehende Online-Wert am nächsten Tag von 15:17 Uhr nach 15:11 Uhr zurückläuft.

Dies wiederum bedeutet, dass die Uhr der Wallbox zu schnell läuft, die Uptime, also zu groß ist.

Meine Frage ist jetzt: wo liegt die Ursache? Wie wird intern der Zeittakt erzeugt/gebildet?

Gruß, Michael

 

[rtrbt]

Moin,

Die Zeit wird mit dem Takt des Prozessors des Ladecontrollers gemessen, da läuft keine RTC, keine Netzwerkzeitsynchronisierung oder ähnliches. Der Anwendungsfall ist bisher nur Zeitintervalle im Bereich Minuten bis zu ein paar Stunden zu messen (lies: z.B. die Dauer eines Ladevorgangs). Deshalb können wir die 0,4% Drift verschmerzen.

Falls du das länger beobachtest: Lass dich nicht davon verwirren, dass der Zähler nach ~ 50 Tagen auf 0 zurückspringt. Der ist nur 32 Bit breit ;)

Wenn wir später Features wie z.B. verschiedene Ladeströme zu verschiedenen Tageszeiten nachlegen, brauchen wir dann natürlich eine bessere Zeitmessung und absolute Zeiten. Voraussichtlich werden wir dann NTP implementieren.

Edit: Ich habe einen entsprechenden Hinweis in die Dokumentation gepackt.

[michaelst]

Auf den Überlauf der 32-Bit habe ich schon gewartet ;-)

Alles klar, danke!

[Doncarlos]

vor 3 Stunden schrieb rtrbt:

Wenn wir später Features wie z.B. verschiedene Ladeströme zu verschiedenen Tageszeiten nachlegen, brauchen wir dann natürlich eine bessere Zeitmessung und absolute Zeiten. Voraussichtlich werden wir dann NTP implementieren.

Edit: Ich habe einen entsprechenden Hinweis in die Dokumentation gepackt.

Interessante Features. Gibt es denn eine vage Featureliste/Roadmap was noch alles kommen soll ? Vielleicht geht es auch anderesn so, dass sie nicht anfangen wollen was zu entwickeln und dann wird es drei Tage später als Update veröffentlicht :-)

[rtrbt]

Die vage Roadmap ist im Endeffekt meine TODO-Liste. Auf der steht (jetzt ganz oben, eventuell komme ich da heute/Montag dazu ;) ), die in Github-Issues zu übersetzen, damit ihr da etwas Einblick habt.

[rtrbt]

Kurzes Update: https://github.com/Tinkerforge/esp32-firmware/issues

[Doncarlos]

Ich hab die Issues jetzt gerade überflogen, konnte da jetzt aber zb keinen Issue entdecken, der "Ladestrom in Abhängigkeit der Tageszeit" o.ä. macht.

Also eher mehr Bugs als neue Features. Oder hab ich da was überlesen ?

[rtrbt]

Sprechende Namen sind schwierig ;)

https://github.com/Tinkerforge/esp32-firmware/issues/52