CCU Firmware 1.504: Automatische Umstellung auf Sommerzeit

[proph]

OK, dann versuche ich es mal - vielleicht bis nächste Jahr dann...

[ayngush]

Buempi, was für eine Datenbank? Die DST, also die Sommerzeit, wird berechnet und ist nirgendwo fest eingetragen und bei der Berechnung trat in der uClibc, also einer Kernbibliothek, die gerne von eingebetteten *ixoiden wie Busybox verwendet wird, ein Fehler auf, der damit zu tun hat, dass bei Schaltjahren bei der Berechnung ab Januar ein Tag pro Monat dazu addiert wird (das soll die Abbildung des Schaltjahres sein...), also auch für März und nicht nur für den Februar, was dazu führt, dass der letzte Sonntag im März, was angenommen wird, wenn man 3.5.0 in der TZ Variable verwendet, nicht der 25.3. (das wäre richtig) ist, sondern der 32.3. (31 Tage + 1 Tag addiert - das war falsch) sei, was dann einfach auf den 1.4. weiterspringt.

hier der OP dazu:

libc: fix daylight saving time handling
The algorithm computing daylight saving time incorrectly adds a day for each month after January for leap years. The clock shift from/to DST can be delayed if the last Sunday of a transition month is exactly seven days before the first of the following month.

Der Fehler wurde übrigens am 12. Oktober 2011 behoben und wurde kurz danach dann auch in die aktuelle Busybox Version aufgenommen. Peinlich daran ist also, dass Busybox mit den Firmwareupdates für die CCU nicht aktualisiert wird und man da weiterhin eine veraltete Version mit Fehlern verwendet und das den Kunden aber mit als "Aktuelle Firmware" unterjubelt.

und wer wissen will wie der Fehler in uClibc aussah:

Code: Alles auswählen

if (isleap && (r->month > 1)) {

und der Bugfix in uClibc sieht so aus:

Code: Alles auswählen

if (isleap && (r->month == 2)) {

Jegliche Veränderung an der TZ Variable ist also kein Patch oder gar eine Fehlerbehebung sondern nur ein "dirty hack" um das Problem temporär zu umgehen. Wenn man an TZ etwas verändert muss man übrigens neu starten, da diese beim booten eingelesen wird. Wenn die TZ Variable auf 3.4.0 steht ist alles Verkehrt, das galt nur für die eine Woche letztes Jahr und wieder nur für eine Woche im Jahr 2040, wenn die "Böse Kombination" erneut das nächste mal auftritt.
3 steht dabei für den Monat März, 4 für die vierte Woche im Monat und 0 für Sonntag, wohingegen 3.5.0 für März, "letzte Woche im Monat in der der gesuchte Tag (0 = Sonntag) vorkommt" steht. Das kann eine vierte oder aber eine fünfte Woche sein und nur so ist es für die korrekte Zeitumstellung richtig, der letzte Sonntag im März, und der März kann vier oder fünf Sonntage haben, deswegen ist alles andere außer 3.5.0 falsch und führt in der Folge zu fehlerhaften Umstellungen und zwar jedes Jahr.

Das Beste ist es also, die TZ variable wieder auf ihren Originalzustand zurückzusetzen, damit hat man dann, trotz fehlerhafter Busybox-Version bis 2040 Ruhe, ich versichere euch: Das ist ausreichend für die CCU1

Grüße

[buempi]

Das Beste ist es also, die TZ variable wieder auf ihren Originalzustand zurückzusetzen, damit hat man dann, trotz fehlerhafter Busybox-Version bis 2040 Ruhe

... und genau das passiert, wenn man die Zeitzone hin und her ändert. Übrigens ohne Neustart der CCU, es sei denn, der Patch hat auch die Datei mit den weltweiten Angaben zu den Zeitzonen ("Datenbank") manipuliert (nicht nur die TZ-Datei).

Viele Grüsse
Bümpi

[ayngush]

Die Einträge in /etc/TZ werden dadurch auch verändert? Mag ja sein, dass die TZ Variable Sitzungsbasiert geändert wird. Wenn man dann aber neu Startet werden wieder die Benutzerwerte aus /etc/TZ heran gezogen, wenn da also weiterhin der Fehlerhafte Eintrag mit M3.4.0... drinnen steht ...

[buempi]

Die Einträge in /etc/TZ werden dadurch auch verändert? Mag ja sein, dass die TZ Variable Sitzungsbasiert geändert wird. Wenn man dann aber neu Startet werden wieder die Benutzerwerte aus /etc/TZ heran gezogen, wenn da also weiterhin der Fehlerhafte Eintrag mit M3.4.0... drinnen steht ...

... warum denn? Wenn jemand nach Australien zieht, muss doch die in der Systemsteuerung vorgenommene Änderung dauerhaft übernommen werden! - Und wenn er wieder zurückkommt, auch wieder!

Viele Grüsse
Bümpi

[Sammy]

Ich meine, das Problem liegt an einem Fehler in der verwendeten (relativ alten) Busybox.
Auch AVM war/ist betroffen: http://www.tutsi.de/fritzbox-uhr-geht-e ... g-aktuell/

[meins0273]

Gemacht und funktioniert.
Vielen Dank für den Tipp.

GRuß

Das Beste ist es also, die TZ variable wieder auf ihren Originalzustand zurückzusetzen, damit hat man dann, trotz fehlerhafter Busybox-Version bis 2040 Ruhe

... und genau das passiert, wenn man die Zeitzone hin und her ändert. Übrigens ohne Neustart der CCU, es sei denn, der Patch hat auch die Datei mit den weltweiten Angaben zu den Zeitzonen ("Datenbank") manipuliert (nicht nur die TZ-Datei).

Viele Grüsse
Bümpi

[ayngush]

Das ist korrekt und der Fehler ist in der alten Busybox-Version drinnen, da dafür die fehlerhafte uClibc verwendet wurde

[HackFox]

Ich hab die 1.508 drauf und meine Uhrzeit ist gerade auf 21.52 - also stimmig...

[IT-Grufti]

Frohe Ostern!
Bei mir hat die Sommerzeitumstellung (Firmware 1.508) perfekt geklappt:
- CCU und Thermostate zeigen die richtige Zeit an.
- Visuwin dto.
- alle Zeitsteuerungen arbeiten korrekt

Dafür hat meine Fritzbox die Zeitumstellung verschlafen und mein WLAN eine Stunde zu spät aktiviert. Na ja, man kann nicht alles haben

Noch schöne Feiertage!
Rolf