Ende der Zeitumstellung

[alanblack]

Moin zusammen!

Es ist zwar noch nicht in trockenen Tüchern, aber ich wollte mir nicht erst am 30.03.2019 einen Kopf machen.
Wenn sich die Großkopferten der EU und der Mitgliedstaaten einig werden sollten, wie gehen die HM-Geräte mit dem AUSBLEIBEN der Zeitumstellung um? Habe ich dann den umgekehrten "Mikrowellen-Effekt", die ja nur im Winter die richtige Uhrzeit anzeigt? 
Die Frage beziehe ich auch nur auf die "alten" HM-Geräte, weil ich denke, dass eQ3 für HM-IP sicher schon nötigenfalls Firmwareupdates in der Schublade liegen hat, für die alten sich die Mühe aber vielleicht sparen möchte - man würde ja endlich mal wieder mehr verkaufen.

[frank]

ich denke, wenn das betriebssystem von deinem fhem server damit klar kommt, sollten auch alle gepairten devices kein problem haben.

[alanblack]

ich denke, ...

Worauf stützt sich Deine Ansicht?
Bei meinen FS20-Komponenten habe ich wegen des Zeitumstellungs-Bugs mich mal mit der Thematik dort auseinandersetzen müssen. Die Infos zu HM sind hier dürftig bis nicht vorhanden.

wenn das betriebssystem von deinem fhem server damit klar kommt, sollten auch alle gepairten devices kein problem haben.

Raspian wird sicher zeitnah auf den Wegfall angepasst. Da mache ich mir keine Sorgen. Hängen die HM-Geräte als lokale Zeit 1:1 an der Systemzeit der gepairten Zentrale?

[frank]

ich kenne nur 3 thermostate, die eine "uhr/kalender" haben. diese werden jeden tag von fhem synchronisiert.
der hmuart macht es sogar zusätzlich noch von sich aus.
hm io haben auch eine uhr, die fhem initialisiert.

probleme kann es beim wegfall der zeitumstellung eigentlich nur geben, wenn ein gerät eine interne, automatische und nicht abschaltbare zeitumstellung vornimmt. beim cc-tc jedenfalls nicht.
beim rt und/oder tc-it habe ich schon mal ein register (sommerzeit?/daylight saving?) gesehen, wenn ich mich nicht täusche.

[frank]

beim cc-tc zeigt mir das reading time-request die letzte synchronisierung an.

[alanblack]

beim cc-tc zeigt mir das reading time-request die letzte synchronisierung an.

Wenn das so sein muss, frage ich mich, warum bei allen Geräten die Zeit richtig zu sein scheint, aber ein

Code Auswählen Erweitern

list TYPE=CUL_HM time-request
bei allen ein "-" liefert. Und: nein, ich habe die nicht erst seit heute/gestern... laufen. Der älteste powerOn-Eintrag ist von Mitte 2017.

Ist aber eigentlich gerade egal geworden. Ich bin in einem anderen Thread über dSt gestolpert. Hatte ich nicht mehr im Kopf, dass es diese gibt. Das sollte das Problem lösen.

Danke!

[zap]

Üblicherweise werden die meisten Komponenten zentral synchronisiert. Das Problem ist dann eher die Zentrale (also FHEM, die CCU oder die HueBridge oder ...).

Nach den jährlichen Erfahrungen mit der CCU muss man da schon ein Auge drauf haben, wenn das nächstes Jahr wirklich kommt.

[frank]

du must auf den timestamp vom reading time-request schauen. der value ist bei mir auch "-".
eventuell stand dort auch schon mal etwas sinnvolleres drin. 

[alanblack]

du must auf den timestamp vom reading time-request schauen. der value ist bei mir auch "-".
eventuell stand dort auch schon mal etwas sinnvolleres drin. 

Grmpf! "Ich verstecke jetzt die Information in der Meta-Information!" [IronieOff]
(Jetzt müsste ich nur warten, dass einer sagt, dass dann im Reading und in dessen TimeStamp das Gleiche stünde. Blöderweise ist Konsequenz in der Programmierung selten optimal - Effizienz aber leider auch nicht. Bdt!)

[LuckyDay]

Grmpf! "Ich verstecke jetzt die Information in der Meta-Information!" [IronieOff]
(Jetzt müsste ich nur warten, dass einer sagt, dass dann im Reading und in dessen TimeStamp das Gleiche stünde. Blöderweise ist Konsequenz in der Programmierung selten optimal - Effizienz aber leider auch nicht. Bdt!)

Die Geräte (TC)fordern selber die Uhrzeit an,und z.B. Hmlan, Hmuart, die beantworten auch noch selber angefragte die Uhrzeit, beim Cul und co, macht Fhem die UhrzeitAntwort.
mit set <device> sysTime kann man manuel (Fhemzeit)  ans Gerät schicken . Uhrzeit bei HM war schon immer tricky

[martinp876]

Also erst einmal habe ich in 2019 noch garkein Problem. die EU weiss noch nicht einmal ob es sommerzeit oder Winterzeit werden soll. Die Randländer der eu bekommen jeweils ein problem bei der einen oder anderen Variante. Abgestimmt haben primär nur die Deutschen. Mit Staaten wie Schweiz ist noch nicht verhandelt.
Warte erst einmal ab, wie viele Jahre das noch dauert. Da fliesst noch viel Wasser den Fluss runter.
Und korrekt, die Zeit kommt aus der Zentrale. Oder hast du die Uhr schon einmal manuell eingegeben? Nach jedem bat wechsel? Also auch dann kein prombel der rts

[alanblack]

Also erst einmal habe ich in 2019 noch garkein Problem. die EU weiss noch nicht einmal ob es sommerzeit oder Winterzeit werden soll.

Naja, Bezug nehmend auf https://www.tagesschau.de/ausland/zeitumstellung-159.html von gestern könnte es auch schnell gehen:

An diesem Wochenende ist es wieder soweit: In der Nacht von Samstag auf Sonntag werden die Uhren auf Winterzeit gestellt, also die Zeiger um eine Stunde zurückgedreht. Geht es nach der EU-Kommission, könnte es das letzte Mal sein.

Aber ich schieb auch anfangs, dass es noch nicht in trockenen Tüchern ist.

Und korrekt, die Zeit kommt aus der Zentrale. Oder hast du die Uhr schon einmal manuell eingegeben? Nach jedem bat wechsel? Also auch dann kein prombel der rts

Nö, ich habe meine Zeit noch nicht manuell eingegeben. Allerdings habe ich das bei meinen Computern auch seit Ewigkeiten nicht. XP fragte noch nach der Umstellung, ob alles okay sei. Win7 habe ich nicht im Kopf, ob es auch eine Meldung nach der Umstellung gibt. Und gegen Win10 wehre ich mich noch. 
NTP-Server liefern die GMT-Zeit und Linux, Windows und Co. machen aus der Zeitzone "Berlin" o.ä. da ein

Code Auswählen Erweitern

If Date => 01.01. and Date < "letzter Sonntag im März" or Date => "letzter Samstag im Oktober" and Date <= 31.12.
{
Zeit = GMT+1
}
else
Zeit = GMT+2
}

draus.
In den Linux-Code habe ich nicht reingeschaut. WinXP kann auf die Zeitzone "Windhoek" oder "Damaskus" gestellt werden wird und Win7 wird ggf. ein Update bekommen (liegt bei MS bereit).
Mein Auto (Baujahr 2009) wird im Funkuhr-Modus ein halbes Jahr die falsche Zeit anzeigen, im "Quarzuhr"-Modus richtig laufen. usw.
Es kann auch alles wieder im Sande verlaufen, aber ich habe keine Lust, dass bspw. meine TC-IT-WM-W-EU mit Firmware 1.3 eine andere Uhrzeit anzeigen als die TC-IT-WM-W-EU mit Firmware 1.31 weil irgendwo ein "Zeitzonenbyte" flachs ist. Daher meine ursprüngliche Frage.