Sommerzeitumstellung HM-CC-TC

[Billy]

@Billy: hast du beim 10ten tc versucht die zeit noch einmal zu uebertragen? sysTime

Wenn dann nur gestern zum testen, da dieser TC mein Test TC ist.
Nach sysTime heute morgen hat er sich dann wieder um eine Stunde zurückgestellt.

Ansonsten ist die Frage, ob die TCs sich unterscheiden oder etwas einstellbat haben.
Wie sind die FWversionen der TCs?

FW Version bei allen ist 2.1 sonst keine Unterscheidung

kannst du einmal alle register auslesen und das roh-format schicken, von den Unterschiedlichen. Manche Register sind mangels info nicht dekodiert, aber alle werden gelesen!

Meinst du die Register aller meiner 10 TC's mit aktiviertem Log und mit set getRegRaw?
Ich werde mal die nächsten Tage abwarten was passiert, da ich vermute dass das vielleicht bei meinem Test TC durch die vielen Kommandos nicht mehr sauber nachvollziehbar ist.

Gruss Billy

[martinp876]

Hi Billy,

wenn sie alle gleich reagieren ist es kein Problem. Evtl war der Abfragezeitpunkt ein anderer.

Seltsam ist die Zeiteinstellung immer noch. Meiner hat im 2:50 nach der Zeit gefragt, 2 mal. Leider habe ich die Angaben der FB nicht. Hier werden die systemzeit, die gmt und eine localtime verarbeitet. Um das Problem zu erkennen sollte man alle Zeiten haben.
Mein TC hatte am ersten Tag die korrekte Zeit und am Tag darauf eine Stunde zu viel.
Demnach gab es ein Problem im Umschaltzeitpunkt. In der Art, dass die Lokale Zeit noch nicht umgestellt war, die local zeit schon plus die eine extra Stunde.

Parameter die hineinspielen sind
- wann bekommt die Platform ihren zeit-update
- arbeitet die Platfom auf sommerzeit oder wird dies ignoriert?

Wenn der TC upgedated wird bevor der Sprung im System war kann es naturlich ein Problem geben. Das behebt sich dann erst nach 1 Tag, wenn der TC wieder Nachfragt.

Es waere demnach sinnvoll den TC wegen der sommerzeit so um 4:00 upzudaten. dann sollte das system stabil sein... und zwischen 2:00 und 4:00 gibt es wenig schaltbefehle (meistens).

Was passiert, wenn ein schaltzeitpunkt der automatischen Tabelle uebersprungen würde...
es sind doch noch eine Menge Sonderfaelle offen.
Vorstellen kann ich mit eine automatisches setzen dr TC uhrzeit um 5:00 wenn eine aenderung von Sommer nach Winterzeit erfolgt. ... mal sehen

Gruss
Martin

[Carsten]

@Carsten: wie Billy schon gefragt hat: welchen Platform benutzt du? Die 7200 korrektor hast du belassen?
Die Vorversion addiert eine Stunde in der Sommerzeit- und das eigentlich 2-mal. Localtime ist schon die korrekte Zeit...., da ist die 2. Korrektur nicht notwendig.

Hallo,

sorry für meine zu knappe Meldung. Ich sollte es eigentlich besser wissen.

FHEM läuft auf FB 7390 mit HMLAN.
Versionsnummer kann ich gerade nicht schauen, aber (Komplett-)Update habe ich gestern gegen 18:00 Uhr durchgeführt.
Ich habe nur das "+ $l[8]" gelöscht. Die Magic-Consts habe ich nicht angefasst.

Gruß

Carsten

[martinp876]

hm, das ist jetzt seltsam. meine FB7390 arbeitet in diesem Mode und Billy hat wohl auch eine.
Ich habe an der FB nie Einstellungen der Zeit vorgenommen(glaube ich). Stellt man da irgendwo die Zeitzone ein?

Das entfernen des $l[8] schiebt die zeit bei sommerzeit um 1h zurueck.
Anbei eine testload die die 2 Zeiten loggt, wenn sie gesetzt werden.
 Einfach einmal sysTime setzen und die reale Uhrzeit mitprotokolieren

Gruss
Martin

[Billy]

Hi Martin,

mein FHEM läuft auf einer Siverstone DC01 Nas.
Das Log sieht so aus.Abgesetzt um 16:45
2013.04.02 16:45:56
1: General set time t:1364913956 tout:418229156 Local:56-45-16-2-3-113-2-91-1 gmt:56-45-14-2-3-113-2-91-0

Ich vermute mal das bedeutet Local: 16:45:56 und GMT oder UTC 14:45:56 was ja richtig wäre!

Gruss Billy

[Billy]

Hallo Martin
anbei noch meine Überlegungen zur Sommerzeitumstellung TC.

Hi Billy,
Seltsam ist die Zeiteinstellung immer noch. Meiner hat im 2:50 nach der Zeit gefragt, 2 mal. Leider habe ich die Angaben der FB nicht. Hier werden die systemzeit, die gmt und eine localtime verarbeitet.

Da der TC mit dem VD auch unabhängig von einer Zentrale eingesetzt werden kann, glaube ich dass EQ3 den TC so programmiert hat, dass er unabhängig von einer Zentrale die Sommerzeiteinstellung durchführt. Einfach bisherige Zeit + 1h. Das würde erklären wieso am Umstellungsmorgen alle TC's die richtige Zeit hatten. (Bei time request um 00:00 hatte ja FHEM noch die alte Zeit)
Am nächsten Tag 00:00 neuer Time request wird dann +1h durch das inzwischen umgestellte FHEM draufgepackt.
Ich habe hier noch einen original verpackten TC liegen und werde versuchen das nachzuvollziehen.

Gruss Billy

[martinp876]

Hallo Billy,

was habe ich auch in betracht gezogen hat mich einige Tests gekostet, ohne Erfolg.
Sprich ich konnte nicht feststellen, dass der TC seine Zeit um eine Stunde korrigiert, wenn ich eine Zeit vor oder nach der Umstellung einflösse.
Vorstellen kann ich mir, dass wenn der TC nicht an einer Zentrale angelernt ist er sich die Zeit selbst generiert und auch Sommerzeit "macht". Im gepairten Mode macht dies keinen Sinn und ich konnte es nicht nachvollziehen.

Fakt ist, dass wenn ich die "time" nach "local" wandle bekomme ich "sommerzeit" also +1h UND die Kennung "sommerzeit-darstellung". Macht auch sinn. Dumm nur, dass die "sommerzeit-darstellung" eine weitere Stunde addiert hat. Ich bekam also eine Sprung von 2h, jetzt aber nicht mehr.
Offen ist dann schon eher, was mir "time" meldet, die Systemzeit. Die koennte bei verscheidenen Systemen unterscheidlich gedeutet werden. Grössere Unix-systeme rechnen intern gerne mit GMT, keine Sommerzeit, keine localtime. Das verhindert Probleme bei file-datum und doppelte Uhrzeiten.
"time" sollte immer 'durchlaufen' und fuer den User mittels "localtime" darstellbar gemacht werden.
"localtime" ist also die Umrechnung der sys-time auf die Ortszeit. Hier sollte irgendwo im System die Zeitzone und die Behandlung der Sommerzeit eingetragen sein, damit localtime weiß, was es machen soll.

Bin auf die Logs gespannt

Gruss
Martin

[Billy]

Hi Martin
Hattest du das gesehen?

Hi Martin,
mein FHEM läuft auf einer Siverstone DC01 Nas.
Das Log sieht so aus.Abgesetzt um 16:45
2013.04.02 16:45:56
1: General set time t:1364913956 tout:418229156 Local:56-45-16-2-3-113-2-91-1 gmt:56-45-14-2-3-113-2-91-0
Ich vermute mal das bedeutet Local: 16:45:56 und GMT oder UTC 14:45:56 was ja richtig wäre!

Gruss Billy

[Billy]

Hallo Martin,

erstes Ergebnis mit neuem TC ohne pairing an der Zentrale.

Habe den TC auf 31.03.2013 01:00 manuall eingestellt und laufen lassen.

Jetzt nach gut einer Stunde zeigt er 31.03. 03:10 an!

d.h. der TC stellt wie vermutet sebsttätig auf die Sommerzeit um.

Werde jetzt dasselbe mit meinem Test TC an FHEM gepairt nachvollziehen!
1. Änderung
Test mit TC an FHEM gepairt durchgeführt!
Ergebnis: Punkt 02:00 wird TC auf 3:00 umgestellt!

Und nun?

Hilft es am Tag nach der Zeitumstellung automatisch um 00:10 ein sysTime absetzen?

Gruss Billy

[martinp876]

Hi Billy,
dein Test war besser als meiner. Der TC aendert die Zeit also doch selbstaendig.
Der TC macht aber keine Umrechnung, nur einen Sprung.

Hat er, wenn gepairt, irgendwann einen time-update angefordert? so im Rahmen +-1h vor und nach 3:00?

Wie ich es sehe ist der Ablauf (zeiten gerundet):
01:00 => TC holt die aktuellen Zeit, hier noch Winterzeit /MEZ
02:00 => TC schaltet auf 03:00 /MESZ
????? => TC fragt nach update?
23:55 => TC erhält neue Zeit von FHEM, interne Zeiten sind hinfällig.

Nach meinen Untersuchungen korrigiert der TC die Zeit nicht, nach deinen tests macht er aber eine selbständigen Sprung

Das würde bedeuten, dass die aktuelle Implemetierung passt:
1) Im Winter war es korrekt.
2) Nach der Aenderung ist es im Sommer Korrekt, im Winter hat sich nichts geaendert
3) der Zeitsprung in der Nacht wird vom TC gemacht.

Offene Fragen:
a) Gibt es jetzt immer noch Systeme, die mit der Aktuellen Implementierung Probleme haben? Habe keine Rückmeldung mehr.
b) Fragt der TC in der Nacht der Nächte bei der Zentrale nach? Wenn ja wann? Kurz vor oder nach der Umstellung?

Gruss
Martin

[snoop]

Hallo Martin,

Offene Fragen:
a) Gibt es jetzt immer noch Systeme, die mit der Aktuellen Implementierung Probleme haben? Habe keine Rückmeldung mehr.
b) Fragt der TC in der Nacht der Nächte bei der Zentrale nach? Wenn ja wann? Kurz vor oder nach der Umstellung?

zu a)
Seit der Implementierung

Code Auswählen Erweitern

my $t2 = $t + 60*(($l[2]-$g[2] + ((($l[5]<<9)|$l[7]) <=> (($g[5]<<9)|$g[7])) * 24) * 60 + $l[1]-$g[1])
läuft bei mir alles (3 x TCs)

zu b) Vielleicht hilft das hier

Viele Grüße
Arthur

[Billy]

Der TC macht aber keine Umrechnung, nur einen Sprung.

Stimmt!

Hat er, wenn gepairt, irgendwann einen time-update angefordert? so im Rahmen +-1h vor und nach 3:00?

Nein, auch wenn gepairt setzt er Punkt 2:00 auf 3:00 um.

Wie ich es sehe ist der Ablauf (zeiten gerundet):
01:00 => TC holt die aktuellen Zeit, hier noch Winterzeit /MEZ
02:00 => TC schaltet auf 03:00 /MESZ
23:55 => TC erhält neue Zeit von FHEM, interne Zeiten sind hinfällig.
Nach meinen Untersuchungen korrigiert der TC die Zeit nicht, nach deinen tests macht er aber eine selbständigen Sprung

Richtig, hat sich mit dem gepairten bestätigt! --> zwischen 2:00 und 23:55/00:00 passiert nichts!!!

Das würde bedeuten, dass die aktuelle Implemetierung passt:
1) Im Winter war es korrekt.
2) Nach der Aenderung ist es im Sommer Korrekt, im Winter hat sich nichts geaendert
3) der Zeitsprung in der Nacht wird vom TC gemacht.

Korrekt

b) Fragt der TC in der Nacht der Nächte bei der Zentrale nach? Wenn ja wann? Kurz vor oder nach der Umstellung?

Nein, siehe oben.
Gruss Billy

[Carsten]

Hallo,

sorry für fehlende Rückmeldung meinerseits.

Ich hab bisher schlicht nicht die Zeit gefunden, das weiter zu testen und bin ein bißchen verwirrt.
Heute morgen gingen die Uhren eine Stunde vor. Nach set systime aber korrekt. Nach meinem Verständnis sollte TimeRequest und Systime aber doch auf jeden Fall zum selben Ergebnis führen, unabhänig davon, ob es richtig oder falsch ist.

Im Moment zweifle ich eher an mir selbst als am System und beobachte erstmal weiter.

[Carsten]

Hallo,

nachdem die Uhr an den TCs heute wieder eine Stunde vorging, habe ich nochmal mit der Version hier aus dem Thread rumprobiert.

TC auf 23:59 gestellt und gewartet:

Code Auswählen Erweitern

2013.04.04 07:52:35 1: General set time t:1365054755 tout:418369955 Local:35-52-7-4-3-113-4-93-1 gmt:35-52-5-4-3-113-4-93-0

Ergebnis: TC zeigt 8:52.

Anschließend set systime:

Code Auswählen Erweitern

2013.04.04 07:54:29 1: General set time t:1365054869 tout:418370069 Local:29-54-7-4-3-113-4-93-1 gmt:29-54-5-4-3-113-4-93-0
2013.04.04 07:54:29 2: CUL_HM set bd_Heizung sysTime rxt:12
Ergebnis: TC zeigt 7:55.

Sehr seltsam...
Ich hatte eigentlich auch hmProtocolEvents aktiviert, aber irgendwie scheint der Eventmonitor bei mir derzeit nicht mehr zu funktionieren.

Gruß

Carsten

[martinp876]

Hallo Carsten,

das ist jetzt schon seltsam. Nach abholen der Uhrzeit und beim setzen durch die Zentrale gibt es 1h unterschied, obwohl quasi der gleiche Wert übertragen wird, nur mit ~2min differenz...

werde ich wohl noch einmal testen.
Gruss
Martin