Not-always-online NTP synced Clock

[LeFish (Gast)]

Hallo allerseits,

ich habe folgendes auf einem ESP32-C3 umgesetzt und bitte um eure 
Meinung, ob das so funktioniert:

Es geht um eine Uhr, die nur unregelmäßig mit dem Internet verbunden 
werden kann, aber bei bestehender Verbindung einen NTP-sync machen soll. 
Die Genauigkeit der Uhr soll +/- 1 Minute betragen. Vorallem soll die 
Sommer/Winterzeit-Umstellung automatisch passieren.

Für Zeit-Belange (Zeitzone, NTP-sync) habe ich ezTime benutzt 
(Bibliothek: https://github.com/ropg/ezTime)
Ich glaube die Lib verlangt nur, dass dessen events() Methode innerhalb 
von void loop() aufgerufen wird.

Das Programm ruft alle 60 Minuten WiFi.reconnect(); auf, die WiFi-Daten 
sind persistent mittels WiFiManager (Bibliothek: 
https://github.com/tzapu/WiFiManager) gespeichert.

Was sich nun schwer überprüfen lässt ist, ob ein Sync auch in folgendem 
Fall funktioniert:

(1) ESP war offline.
(2) ESP kann durch WiFi.reconnect(); wieder ins Internet.
(3) NTP-Sync nach Bibliotheksinterner Logik möglich?

Hat jemand mit ezTime Erfahrung und kann mir sagen, ob das so 
funktioniert.

Danke!

Beste Grüße
LeFish

[Thomas S. (thomas_s72)]

Hallo,
ich habe eine NTP Uhr mit einem ESP32 (nicht C3) realisiert, den 
Quellcode gibts hier:
https://www.hackster.io/thomasschattat/yet-another-dot-matrix-clock-20af5c
Eventuell ist da etwas interessantes für dich dabei.
Gruß
Thomas

[Christian B. (casandro)]

LeFish schrieb:
> Die Genauigkeit der Uhr soll +/- 1 Minute betragen.

Bei den Anforderungen reicht es, wenn Du Dir jedes Monat oder so die 
Zeit holst. Sommer und Winterzeit ist eine etwas knifflige Sache, aber 
auch machbar, wenn Du nur die aktuellen Regeln für ein Land brauchst.

Im Prinzip kannst Du SNTP verwenden. Dabei schickst Du ein UDP-Paket an 
einen NTP-Server und bekommst die Zeit in UNIX Epochen. Du sprichst da 
nicht das ganze NTP und kriegst somit nicht mit wie lange das Paket 
gebraucht hat. Das ist aber in der Regel im Festnetzinternet deutlich 
unter einer Minute.

Die Zeit in UNIX-Epochen zählt einfach jede Sekunde eine Sekunde weiter. 
Somit ist es sehr einfach damit zu arbeiten. Dafür gibts auch tausende 
von Bibliotheken die damit umgehen können. Ganz wichtig: Niemals die Uhr 
umstellen, immer nur bei der Anzeige einen Offset dazu rechnen.

[Georg (Gast)]

Christian B. schrieb:
> Ganz wichtig: Niemals die Uhr
> umstellen, immer nur bei der Anzeige einen Offset dazu rechnen.

Jede Uhr muss irgendwann gestellt werden, zumindest bei der 
Inbetriebnahme.

Georg

[Walter K. (walter_k488)]

Christian B. schrieb:
>
> Die Zeit in UNIX-Epochen zählt einfach jede Sekunde eine Sekunde weiter.
> Somit ist es sehr einfach damit zu arbeiten. Dafür gibts auch tausende
> von Bibliotheken die damit umgehen können.

Aber oftmals wahrscheinlich nur bis zum 7.02.2036 06:28:16Uhr UTC
;-)

[Christian B. (casandro)]

Wenn man vorzeichenlose Ganzzahlen verwendet, dann noch viel länger.

Ich hab das Problem ja mal in einem System dadurch gelöst in dem ich den 
Epochenanfang auf das Jahr 2010 oder so verlegt habe. Das war in einem 
Assemblerprojekt bei dem ich aber keine Zeitzonen beachten musste. Das 
Projekt war so 18 Kilobyte oder so groß, der Rest vom Flash wurde als 
Dateisystem verwendet.

[Christian B. (casandro)]

Georg schrieb:
> Jede Uhr muss irgendwann gestellt werden, zumindest bei der
> Inbetriebnahme.

Sorry ich meinte in Verbindung mit Sommer- und Normalzeit, das hätte ich 
wohl klarer machen sollen. Manche Leute kommen auf die Idee die Ortszeit 
als Sommer- oder Winterzeit zu führen und haben dann das Problem, dass 
Uhrumstellungen übersprungen oder mehrfach ausgeführt werden. Das sauber 
hin zu bekommen ist sehr schwierig.