Sommerzeitumstellung HM-CC-TC

[Billy]

Durch Änderung in der heutigen 10_CUL_HM.pm, (Zeile 3347) & 00_HMLAN.pm (Zeile 452)
von "- 7200;# HM Special"
auf "- 10800;# HM Special"
wird wieder die korrekte Zeit mit sysTime eingestellt.

Stimmt, also war meine Vermutung richtig, dass immer noch das alte Umstellungsproblem besteht!
Wäre gut wenn das Martin so gestalten könnte, dass es eine automatische Lösung gibt.
Ansonsten daran denken, dass bei jedem update von 10_CUL_HM.pm, (Zeile 3347) & 00_HMLAN.pm (Zeile 452)
die Änderung verloren geht. Ausserdem müsste das bei Umstellung auf die Winterzeit wieder auf den alten Wert
zurückgesetzt werden!

Billy

[Markus]

Warum hat es dann bei meiner Fritzbox und allen 4 TC's Funktioniert?

Gruß Markus

[Billy]

Warum hat es dann bei meiner Fritzbox und allen 4 TC's Funktioniert?

Weil es wie um  09:05 erwähnt Plattform abhängig ist?

Ich vermute da kommt jetzt das altbekannte Sommerzeitproblem auf verschiedenen FHEM Plattformen zum tragen.

Billy

[snoop]

Hallo zusammen,

ich nutze FritzBox (uninteressant) mit HMLAN (Für Zeitumstellung das interessante Device - denke ich) und meine TCs laufen seit heute Nacht eine weitere Stunde vor (also 12Uhr statt 11Uhr).

Mein Vorschlag (nicht schön aber):
- Attr An CULs/HMLAN hängen "Time" 0=Winter 1=Sommer oder sogar unter global?
- 10_CUL_HM.pm, 00_HMLAN.pm fragt Attr ab
- Notify bauen (eigenbau) der den Wert von 0 auf 1 oder 1 auf 0 setzt
Nur so ins blaue geschossen. ;o)
Martin wird sich da was einfallen lassen.

Viele Grüße
Arthur

[Markus]

@ Billy
Das hab ich überlesen Sorry

Gruß Markus

[martinp876]

Hi,

jetzt habe ich lange mit dem TC experimentiert. Das test-geraet hatte gestern die Korrekte Zeit, heute war sie auch falsch.
Ich hatte die Berechnung schon das letzte mal getest, die ist eigentlich ok. Aber der Finale test ist eben die Systemzeit zu setzen.

Ich denke das Problem bei der FB ist, dass die Sommerzeit von der FB berücksichtigt wird. Anders kann ich es mir nicht erklaeren, die Berechnung muesste ok sein .
Der Punkt ist also, die Sommerzeit in der Berechnung nicht noch einmal zu addieren.

Somit ist in CUL_HM in der Zeile zu löschen
  my $t2 = $t + 60*(($l[2]-$g[2] + ((($l[5]<<9)|$l[7]) <=> (($g[5]<<9)|$g[7])) * 24 + $l[8]) * 60 + $l[1]-$g[1])

somit:
  my $t2 = $t + 60*(($l[2]-$g[2] + ((($l[5]<<9)|$l[7]) <=> (($g[5]<<9)|$g[7])) * 24) * 60 + $l[1]-$g[1])

Es kann Systeme geben, die bei time einen anderen Wert zurückliefern. Das muesste man system-abhaengig loesen...

Funktioniert die Aenderung soweit bei allen? Testen kann man das setzen mit " set sysTime", dann wird es neu uebertragen.
Gruss
Martin

[snoop]

Hallo Martin,

wie sieht es bei HMLAN aus?
Muss der string dann so aussehen?

Code Auswählen Erweitern

 $t += 60*(($l[2]-$g[2] + ((($l[5]<<9)|$l[7]) <=> (($g[5]<<9)|$g[7])) * 24) * 60 + $l[1]-$g[1])

- TC neu angelernt (gepairt)
- set sysTime
- anlerntaste
= keine Änderung zu sehen, TC geht immer noch eine Stunde vor.

Viele Grüße
Arthur

[snoop]

Hallo Martin,

ok, kommando zurück - ich habe es in die CUL_HM gepackt und ein "set sysTime" ausgeführt
= Zeit stimmt nun.
Verifiziert an 3 TCs

Viele Grüße
Arthur

[ulbr2000]

Hallo Martin,

ich habe die selbe Änderung auch in 00_HMLAN.pm eingebaut

Testergebnis: bei mir funktioniert es jetzt, die Zeit wird jetzt mit "sysTime" richtig eingestellt

Ulrich

[Billy]

Hallo Martin,

funktioniert soweit.
Hatte bei dieser Gelegenheit auch gleich die HMConfig.pm.3006 und 10_CUL_HM.pm.3006 installiert
und Probleme mit MISSING ACK bekommen wenn ich bei meinem Test TC den controlMode ändern wollte.
Zurück zu HMConfig.pm.3001 und 10_CUL_HM.pm.3001 und alles war wieder ok.

Nur zur Info, vielleicht nicht wichtig.

Gruss Billy

[martinp876]

Hi Billy,
Sollte sich nichts geaendert haben.
hast du einen log? Ich schaue einmal, ob ich was sehe.
Gruss Martin

[Billy]

Hi Martin,
Log habe ich bisher leider nicht.
Komme heute nicht mehr dazu und werde morgen in Ruhe nochmal testen und berichten.
Gruss Billy

[Carsten]

Hallo,

danke für deine Mühe, Martin!

Nach obiger Änderung gehen meine TCs nun eine Stunde vor statt nach. Zumindest ist es jetzt morgens warm, wenn auch eine Stunde zu früh. :)

Leider muss ich zugeben, dass mein bescheidenes Perl-Verständnis nicht ausreicht, um die betr. Codezeile zu verstehen. Daher weiß ich auch nicht, was jetzt schiefläuft.


Gruß

Carsten

[Billy]

Hallo,
danke für deine Mühe, Martin!
Nach obiger Änderung gehen meine TCs nun eine Stunde vor statt nach. Zumindest ist es jetzt morgens warm, wenn auch eine Stunde zu früh. :)
Leider muss ich zugeben, dass mein bescheidenes Perl-Verständnis nicht ausreicht, um die betr. Codezeile zu verstehen. Daher weiß ich auch nicht, was jetzt schiefläuft.

Auch wenn es an Martin geht, zum weiteren Verständnis: Mit welcher 10_CUL_HM.pm Version arbeitest du und auf welcher Plattform?
Bei mir waren übrigens von 10 TC's 9 richtig und einer seltsamerweise 1 Stunde vor.
Ich vermute deshalb noch andere Probleme.

Billy

[martinp876]

@Billy: hast du beim 10ten tc versucht die zeit noch einmal zu uebertragen? sysTime
Ansonsten ist die Frage, ob die TCs sich unterscheiden oder etwas einstellbat haben.
Wie sind die FWversionen der TCs?
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!

@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.

Gruss
Martin