michaelst Geschrieben November 10, 2021 at 14:00 Share Geschrieben November 10, 2021 at 14:00 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 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben November 10, 2021 at 14:19 Share Geschrieben November 10, 2021 at 14:19 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
michaelst Geschrieben November 10, 2021 at 15:29 Autor Share Geschrieben November 10, 2021 at 15:29 Auf den Überlauf der 32-Bit habe ich schon gewartet ;-) Alles klar, danke! Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Doncarlos Geschrieben November 10, 2021 at 18:13 Share Geschrieben November 10, 2021 at 18:13 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 :-) Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben November 12, 2021 at 13:42 Share Geschrieben November 12, 2021 at 13:42 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben November 16, 2021 at 08:33 Share Geschrieben November 16, 2021 at 08:33 Kurzes Update: https://github.com/Tinkerforge/esp32-firmware/issues Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Doncarlos Geschrieben November 16, 2021 at 10:34 Share Geschrieben November 16, 2021 at 10:34 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 ? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben November 16, 2021 at 10:45 Share Geschrieben November 16, 2021 at 10:45 Sprechende Namen sind schwierig ;) https://github.com/Tinkerforge/esp32-firmware/issues/52 1 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.