Funktioniert die Sommerzeit Umstellung am HM-CC-TC automatisch?
Oder verzögert erst um 00:00 Uhr Sonntag auf Montag?
Im mode auto würde sich das ja auswirken.
Gruss Billy
Wenn ich es richtig sehe holt sich der TC taeglich um Mitternacht einen neuen Zeitstempel.
Der Zeitstempel wird von der Systemzeit abgeleitet und sollte die Sommerzeit beinhalten.
Also erwarte ich: update automtisch laeuft, aber erst um Mitternacht des nächsten Tages.
Berichte doch einmal
Ich werden ein Kommando einbauen, dass man beim TC das setzen der Uhrzeit erzwingen kann, mal sehen, ob es heute noch kommt
Gruss
Martin
Zitat von: martinp876 schrieb am Sa, 30 März 2013 19:43Wenn ich es richtig sehe holt sich der TC taeglich um Mitternacht einen neuen Zeitstempel.
Der Zeitstempel wird von der Systemzeit abgeleitet und sollte die Sommerzeit beinhalten.
Also erwarte ich: update automtisch laeuft, aber erst um Mitternacht des nächsten Tages.
Sehe ich genauso!ZitatBerichte doch einmal
Selbstverständlich! Werde ich auf meinem Test-TC beobachten. Allerdings muss ich meine Referenz TC's von Hand umstellen, sonst gibts Probleme mit der Heizung.
ZitatIch werden ein Kommando einbauen, dass man beim TC das setzen der Uhrzeit erzwingen kann, mal sehen, ob es heute noch kommt
Das wäre natürlich spitze! Gibt es eigentlich schon ein "at" für Sommer/Winterzeit Umstellung? Dann könnte man das ja zukünftig automatisieren.?
Mich hatte gewundert, dass nicht mehr Usern das Problem aufgefallen ist!
Gruss und vielen Dank für deine Arbeit.
Billy
Version 3001
Kommando
set <tc_Climate> sysTime
geht auch
set <tc> sysTime
aber eigentlich wird der climate-channel bearbeitet.
Den timer musst du extern bauen...
HMConfig musst du auch!
Gruss
Martin
Danke super wie immer. Gesendet von meinem Nexus.
Billy
@Martin und alle Interessierten!
Hier die versprochene Rückmeldung!!!
Alle 10x HM-CC-TC waren als ich um 05:00 aufgestanden bin bereits automatisch auf die
Sommerzeit umgestellt!
Ob das der HM-Lan macht, oder ob die sich über FHEM die Zeit geholt haben, oder ob das der TC
eigenständig macht wäre zu klären?
Frohe Ostern
Billy
Hi Billy,
ich habe nur einen test-TC hier liegen.
Der hat sich auch umgestellt. Er hat um 2:50 nach der neuen Uhrzeit gefragt...
muss ich mir noch einmal ansehen. Sonst kam es nur um Mitternacht.
Gruss
Martin
Hallo zusammen,
bei mir sehen die TCs auch gut aus.
Es gab von 01:59:01 auf 03:01:09 einen Zeitsprung.
TC Message:
2013-03-31_01:59:01 WZ_Thermostat T: 17.6 H: 52
2013-03-31_01:59:01 WZ_Thermostat measured-temp: 17.6
2013-03-31_01:59:01 WZ_Thermostat humidity: 52
2013-03-31_03:01:09 WZ_Thermostat T: 17.6 H: 52
2013-03-31_03:01:09 WZ_Thermostat measured-temp: 17.6
2013-03-31_03:01:09 WZ_Thermostat humidity: 52
RAW Messages:
2013.03.31 01:59:01 5: HMLAN/RAW: /E1D2AE8,0000,107EE320,FF,FFBE,5886701D2AE800000000B034
2013.03.31 01:59:01 5: HMLAN_Parse: HMLANAMA S:E1D2AE8 stat:0000 t:107EE320 d:FF r:FFBE m:5886701D2AE800000000B034
2013.03.31 01:59:01 5: HMLANAMA dispatch A0C5886701D2AE800000000B034::-66:HMLANAMA
2013.03.31 01:59:01 5: Triggering WZ_Thermostat_Weather (3 changes)
2013.03.31 01:59:01 5: Notify loop for WZ_Thermostat_Weather T: 17.6 H: 52
2013.03.31 01:59:01 5: Triggering WZ_Thermostat (3 changes)
2013.03.31 01:59:01 5: Notify loop for WZ_Thermostat T: 17.6 H: 52
2013.03.31 01:59:15 5: HMLAN_Send: K
2013.03.31 01:59:15 5: HMLAN/RAW: /HHM-LAN-IF,03C1,0987654321,1ACA40,123456,107F192A,0009
2013.03.31 01:59:15 5: HMLAN_Parse: HMLANAMA V:03C1 sNo:0987654321 d:1ACA40 O:123456 m:107F192A IDcnt:0009
2013.03.31 01:59:40 5: HMLAN_Send: K
2013.03.31 01:59:40 5: HMLAN/RAW: /HHM-LAN-IF,03C1,0987654321,1ACA40,123456,107F7AF0,0009
2013.03.31 01:59:40 5: HMLAN_Parse: HMLANAMA V:03C1 sNo:0987654321 d:1ACA40 O:123456 m:107F7AF0 IDcnt:0009
2013.03.31 03:00:05 5: HMLAN_Send: K
2013.03.31 03:00:05 5: HMLAN/RAW: /HHM-LAN-IF,03C1,0987654321,1ACA40,123456,107FDCA3,0009
2013.03.31 03:00:05 5: HMLAN_Parse: HMLANAMA V:03C1 sNo:0987654321 d:1ACA40 O:123456 m:107FDCA3 IDcnt:0009
2013.03.31 03:00:06 5: HMLAN/RAW: /E1D2D44,0000,107FE0CF,FF,FFB9,D686701D2D4400000000AE3A
Viele Grüße
Arthur
Hi,
klar ist also, dass der TC immer nach Datumwechsel nach der Uhrzeit fragt.
Ausserdem kam die Frage am 31.3. 2 mal so um 3 uhr in der Nacht.
Ein externer trigger ist nicht auszumachen, also macht es das device selbstaendig. eQ3 hat dies evtl schon vorgesehen und hart einprogrammiert
Man kann die Zeit einfach setzen und einmal warten. Wer will kann jedes Datum ausprobieren.
set <TC> raw ++803F<tcID><IOid>020418EA3F28 #ergibt 2013.03.31 02:27
Gruss
Martin
bei mir hatten heute früh alle die richtige Uhrzeit eingestellt :-D
gestern update gemacht weiß nicht was Martin programmiert hat aber es klappt :-D
Danke
Gruß Markus
Hallo,
ich war gestern nicht viel zu Hause, hatte aber gestern morgen extra geschaut, ob die Zeit an den TCs stimmt, und bin der Meinung, dass dies der Fall war.
Heute hat meine Freundin Frühschicht, weshalb ich gestern noch die Templist angepasst habe, damit ab 4:00 geheizt wird. Wurde aber nicht, weil, wie ich dann feststellte, die TCs jetzt wieder auf Winterzeit ( also eine Stunde nach ) laufen. Auch, nachdem ich die Zeit manuell auf 23:59 gestellt habe, holen Sie sich die falsche Uhrzeit.
Die Uhrzeit innerhalb fhems wird korrekt angezeigt. Laut Log haben die TCs einmal um 0:00 Uhr und einmal um 1:00 Uhr einen time-request geschickt. Scheinbar wurden sie beim ersten fälschlicherweise eine Stunde zurückgestellt.
Ideen?
Gruß
Carsten
Hallo Martin,
Haben wir ein Osterei im Nest?
Bei mir waren heute Morgen alle 10 TC's eine weitere Stunde vorgestellt!
Mit dem Befehl " set sysTime " konnte ich keine Veränderung erreichen!
Ich vermute da kommt jetzt das altbekannte Sommerzeitproblem auf verschiedenen FHEM Platformen zum tragen.
Wurde früher in Google Groops länglich durchgekaut.
Ich hatte mir letztes Jahr damit geholfen, dass
Zitathttps://groups.google.com/forum/#!topic/fhem-users/5HNaMEx3GQw%5B26-50%5D (//groups.google.com/forum/#!topic/fhem-users/5HNaMEx3GQw%5B26-50%5D)
Bei datumswechsel , also in den ersten 3 Minuten frägt das TC Fhem nach der Uhrzeit!
Bei Iconnect + BB-Debian zumindest in Sommerzeit manchmal falsch!
habe mir geholfen mit folgendem Workaround:
10_CUL_HM.pm, (Zeile 1964) & 00_HMLAN.pm (Zeile 387)
$t -= 7200; # HM Special
durch
$t -= 3600; # HM Special
ersetzen
Müsste man in der heutigen 10_CUL_HM.pm, (Zeile 3347) & 00_HMLAN.pm (Zeile 452)
"- 7200;# HM Special mit - 3600;# HM Special" ersetzen?
Gruss Billy
Die neuerliche Zeitverschiebung kann ich bestätigen. Dabei hatte gestern es so hoffnungsvoll ausgesehen.
Christian
Hallo,
auch die Zeit meiner TC's wird seit heute um eine weitere Stunde vorgestellt.
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.
Aufruf von "date" am SuSE-Rechner zeigt folgende Ausgabe:
Mon Apr 1 10:25:25 CEST 2013
Ulrich
Auf meinem FHT80B stimmt die Uhrzeit aber auf meinen HM-CC-TC bin ich jetzt eine Stunde voraus.
Also es ist 10:25 Uhr aber auf dem HM-CC-TC ist es 11:25 Uhr
Der set sysTime Befehl bringt nichts.
Bin auch ratlos. Habe auch den neusten FHEM installiert. Den halte ich per update immer aktuell.
Benutze FB7390 + HMLAN für die Kommunikation mit den HM-CC-TCs.
Gruss
Frank
Zitat von: ulbr2000 schrieb am Mo, 01 April 2013 10:23Durch Ä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
Warum hat es dann bei meiner Fritzbox und allen 4 TC's Funktioniert?
Gruß Markus
ZitatWarum hat es dann bei meiner Fritzbox und allen 4 TC's Funktioniert?
Weil es wie um 09:05 erwähnt Plattform abhängig ist?
ZitatIch vermute da kommt jetzt das altbekannte Sommerzeitproblem auf verschiedenen FHEM Plattformen zum tragen.
Billy
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
@ Billy
Das hab ich überlesen Sorry
Gruß Markus
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
Hallo Martin,
wie sieht es bei HMLAN aus?
Muss der string dann so aussehen?
$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
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
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
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
Hi Billy,
Sollte sich nichts geaendert haben.
hast du einen log? Ich schaue einmal, ob ich was sehe.
Gruss Martin
Hi Martin,
Log habe ich bisher leider nicht.
Komme heute nicht mehr dazu und werde morgen in Ruhe nochmal testen und berichten.
Gruss 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.
Gruß
Carsten
Zitat von: Carsten schrieb am Di, 02 April 2013 09:54Hallo,
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
@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
Zitat von: martinp876 schrieb am Di, 02 April 2013 10:35@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.
ZitatAnsonsten 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
Zitatkannst 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
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
Zitat von: martinp876 schrieb am Di, 02 April 2013 10:35@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
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
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
Hallo Martin
anbei noch meine Überlegungen zur Sommerzeitumstellung TC.
Zitat von: martinp876 schrieb am Di, 02 April 2013 13:26Hi 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
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
Hi Martin
Hattest du das gesehen?
Zitat von: Billy schrieb am Di, 02 April 2013 16:53Hi 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
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
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
Hallo Martin,
ZitatOffene 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
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 (http://forum.fhem.de/index.php?topic=11993.msg71095#msg71095)
Viele Grüße
Arthur
Zitat von: martinp876 schrieb am Mi, 03 April 2013 17:31Der TC macht aber keine Umrechnung, nur einen Sprung.
Stimmt!
ZitatHat 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.
ZitatWie 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!!!
ZitatDas 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
Zitatb) 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
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.
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:
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:
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
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
Hallo Martin,
wenn ich mein Ergebnis noch beitragen darf.
Von 10 TC's gingen heute Morgen 2 eine Stunde vor. Das ist seltsam?
Gruss
Billy
Hallo!
Zitat von: martinp876 schrieb am Do, 04 April 2013 08:49Nach abholen der Uhrzeit und beim setzen durch die Zentrale gibt es 1h unterschied, obwohl quasi der gleiche Wert übertragen wird, nur mit ~2min differenz...
Ja, und zwar reproduzierbar. Jedesmal, wenn ich die Uhr manuell auf 23:59 stelle, geht sie 2 Minuten später 1h vor. Jedesmal nach systime stimmt sie.
Wie gesagt, funktioniert bei mir derzeit der Eventmonitor nicht ( da wäre ich auch für Ideen dankbar ), daher weiß ich nicht, was tatsächlich rausgeschickt wird, aber soweit ich den Source verstehe, sollte das doch mehr oder weniger identisch sein.
Ist es evtl. möglich, dass der HMLAN da wieder zu intelligent ist und evtl. selbst den TimeRequest beantwortet? Das könnte ich heute Abend mal testen, indem ich mutwillig eine komplett falsche Zeit generiere und den TC dann auf 23:59 stelle. Es sei denn, du kannst das definitiv ausschließen, dass der HMLAN da reinpfuscht.
Gruß
Carsten
Hallo,
Ich kann die Beobachtung auch nachvollziehen: Wenn der TC die Zeit anfordert ist es 1h später als wenn die Zeit unaufgefordert gesetzt wird.
Das halte ich erst einmal fuer einen Bug im TC. Aber damit müssen wir wohl leben.
Die Beobachtung gilt fuer die Sommerzeit. Jetzt muss ich dem TC noch die Winterzeit simulieren, evtl ist es hier nicht so...
hmProtokolEvents funktioniert bei mir.Zu beachten ist, dass es passieren kann, dass der TC nicht mehr bearbeitet werden kann, da es zu starken Verzögerungen kommen kann.
Du solltest level 3 nehmen, da ist die komplette show eingebaut
Gruss
Martin
Hi,
da muss man erst mal draufkommen...
Ich habe immer an der falschen Stelle gesucht. HMLAN ist sehr zuvorkommend. Die Anfrage vom TC wird von HMLAN beantwortet - und da ist die Zeit noch nicht korrekt.
Also alles nicht so kompliziert, der TC ist auch nicht so intelligent. Man muss nur HMLAN die Zeit beibiegen. Und der hat die gleiche Berechnung wie CUL_HM.
Also alles garnicht so kompliziert, wenn man es nur richtig macht.
uff...
Version 3033, incl 00_HMLAN
Gruss
Martin
Super!
Das war ja schon 2 Posts vorher meine Vermutung/Befürchtung.
Vielen Dank für deine Mühe!
Hallo zusammen,
kurzer Zwischenfunk - meine TCs sind heute in Sommerzeit Modus gelaufen :o(
Spiele mal die neue Version ein, mal schauen wie sich diese nun verhalten.
Viele Grüße
Arthur
EDIT: P.S: sind alle mit HMLAN gepairt.
Ich werde morgen berichten ob alle 10 TC die gleiche richtige Zeit anzeigen.
Billy
Hallo zusammen,
zunächst kleine aber wichtige Korrektur:
Zitatkurzer Zwischenfunk - meine TCs sind heute in Sommerzeit Modus gelaufen :o(
...meine TCs sind heute
"nicht" im Sommerzeit Modus gelaufen :o(
Habe gestern ein Update auf 3033 (CUL_HM/HMLAN)inkl. Reload/Restart durchgeführt - Stand aktuell: immer noch keine Sommerzeit bzw. die TCs haben immer noch die Winterzeit.
Viele Grüße
Arthur
Hallo,
unangenehme Geschichte,
Haus war kalt, hatte die 3033 eingespielt. Zumindest 1 TC hatte eine Stunde vorgestellt.
Beide HMLans waren aus der Config gelöscht? Damit war meine Heizungssteuerung tot.
Keine Grafik plots, da auch keine Log mehr.
In der Konfig stand nur noch
# HMLAN Konfiguration HMLAN1
# HMLAN Konfiguration HMLAN2
Statt
# HMLAN Konfiguration HMLAN1
define HMLAN1 HMLAN 192.168.XXX.30:1000
attr HMLAN1 hmId 4543CC
attr HMLAN1 room CUL_HM
# HMLAN Konfiguration HMLAN2
define HMLAN2 HMLAN 192.168.XXX.23:1000
attr HMLAN2 hmId 3743CC
attr HMLAN2 room CUL_HM
Seltsam?
Gruss Billy
Hallo Billy,
hmmmmm ok bei mir ist HMLAN auf weg. :o(
Viele Grüße
Arthur
P.S: Meldung: Cannot load module HMLAN
Hallo zusammen,
1) HMLAN weg... wie ist die Fehlermeldung? Ich kann es leider nicht direkt nachvollziehen. Habe die Aenderungen noch einmal geprüft, da ist nur eine Aenderung in der Berechnung. Das sollte nicht zu einem Load-problem führen.
Im Logfile sollte eine Meldung stehen, was nicht funktioniert hat.
2) Bei wem war die Sommerzeit vor der Aenderung ok und ist jetzt falsch? Das sollte dann die Ursache in der Platform haben. Daher
- welche Platform benutzt ihr?
- falls ihr mit 3025 ein set sysTime macht wird die Uhrzeit auch wieder auf Winterzeit gestellt?
- Wisst ihr, auf welcher Zeit euer Basissystem läuft? Im Besonderen - ist es auf Sommerzeit eingestellt?
Gruss
Martin
Hallo Martin,
schnell vorab, muss erst wieder alles zum Laufen bringen.
Habe die 00_HMLAN.3033 um 21:59 eingespielt.
Sofort danach wurden wohl beide HMLANS aus der Config entfernt.
Deshalb ab diesem Zeitraum auch kein Logeintrag mehr.
Heute Morgen konnte ich keine Befehle mehr absetzten.
Grund: Alle TC sind bei mir mit HMLAN1 gepairt.
Die attr TC_XX IODev HMLAN1 war auch aus der Config verschwunden.
Deswegen konnte ich natürlich auch keine set sysTime absetzen.
d.h. Alle Geräte waren vom HMLAN1 abgeklemmt.
Ich muss jetzt erst mal die Heizung (2 Familienhaus) wieder zum laufen bringen.
Vermutlich steige ich auf eine stabile Version von vor 2 Wochen zurück.
Gruss
Billy
Hallo Martin,
nur so aus der Ferne - bin nicht @Home.
zu 1)
2013.04.04 21:12:29 1: Including ./FHEM/LanInterface.cfg
2013.04.04 21:12:29 5: Cmd: >define HMLANAMA HMLAN x.x.x.x:1000<
2013.04.04 21:12:29 5: Loading ./FHEM/00_HMLAN.pm
2013.04.04 21:12:29 1: reload: Error:Modul 00_HMLAN deactivated:
Can't modify constant item in predecrement (--) at ./FHEM/00_HMLAN.pm line 6, near "ViewVC :: http"
syntax error at ./FHEM/00_HMLAN.pm line 6, near "ViewVC :: http"
"no" not allowed in expression at ./FHEM/00_HMLAN.pm line 19, at end of line
syntax error at ./FHEM/00_HMLAN.pm line 22, near "36px"
Unmatched right curly bracket at ./FHEM/00_HMLAN.pm line 23, at end of line
syntax error at ./FHEM/00_HMLAN.pm line 37, near "-->"
syntax error at ./FHEM/00_HMLAN.pm line 43, near "END:"
Type of arg 1 to push must be array (not anonymous list ([])) at ./FHEM/00_HMLAN.pm line 47, near "])"
Type of arg 1 to push must be array (not anonymous list ([])) at ./FHEM/00_HMLAN.pm line 48, near "])"
Type of arg 1 to push must be array (not anonymous list ([])) at ./FHEM/00_HMLAN.pm line 49, near "])"
./FHEM/00_HMLAN.pm has too many errors.
2013.04.04 21:12:29 0: Can't modify constant item in predecrement (--) at ./FHEM/00_HMLAN.pm line 6, near "ViewVC :: http"
syntax error at ./FHEM/00_HMLAN.pm line 6, near "ViewVC :: http"
"no" not allowed in expression at ./FHEM/00_HMLAN.pm line 19, at end of line
syntax error at ./FHEM/00_HMLAN.pm line 22, near "36px"
Unmatched right curly bracket at ./FHEM/00_HMLAN.pm line 23, at end of line
syntax error at ./FHEM/00_HMLAN.pm line 37, near "-->"
syntax error at ./FHEM/00_HMLAN.pm line 43, near "END:"
Type of arg 1 to push must be array (not anonymous list ([])) at ./FHEM/00_HMLAN.pm line 47, near "])"
Type of arg 1 to push must be array (not anonymous list ([])) at ./FHEM/00_HMLAN.pm line 48, near "])"
Type of arg 1 to push must be array (not anonymous list ([])) at ./FHEM/00_HMLAN.pm line 49, near "])"
./FHEM/00_HMLAN.pm has too many errors.
zu 2)
Zitat- welche Platform benutzt ihr?
FritzBox 7390 / HMLAN
Zitat- falls ihr mit 3025 ein set sysTime macht wird die Uhrzeit auch wieder auf Winterzeit gestellt?
kann ich später testen.
Zitat- Wisst ihr, auf welcher Zeit euer Basissystem läuft? Im Besonderen - ist es auf Sommerzeit eingestellt?
Bei mir ist default NTP aktiv: "0.europe.pool.ntp.org"
Genaueres kann ich im Moment leider nicht sagen.
Viele Grüße
Arthur
@Billy: im standard logfile steht evtl eine Nachricht zum update...???
Irgend einen Hinweis brauche ich, um das Problem zu suchen.
@Arthur
kannst du auf deiner 7390 einmal ein
date
machen? Bei mir kommt dann
Fri Apr 5 09:33:04 CEST 2013
also sommerzeit. Wie ist deine eingestellt? Zeitzone CET oder CEST?
Hallo Martin,
bei mir steht:
Fri Apr 5 09:37:32 CEST 2013
Die Zeit scheint also ok zu sein bzw. zu stimmen.
Viele Grüße
Arthur
Hi Arthur,
ich gehe davon aus,dass die Aenderung in HMLAN das Sommerzeitproblem lösen würden.
Die Frage ist nur, warum es bei euch zu Problemen kam.
Wie habt ihr upgedated? Ist da nur HMLAN und CUL_HM dazugekommen? Die CUL_HM version braucht ihr nicht, da ist nur ein Kommentar verschwunden.
Sind noch anderen files upgedated worden?
Gruss
Martin
Hallo Martin,
ich habe die beiden Dateien hier (http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/ (//fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/)) runtergeladen -
und in das entsprechende Verzeichnis kopiert -> FHEM rebootet.
Viele Grüße
Arthur
P.S: Hat der Auszug aus dem Log nicht geholfen?
Hallo Martin,
du hast recht wie immer.
Im Standard Logfile kommt eine Meldung die ich übersehen hatte.
2013.04.04 21:56:59 1: configfile: Unknown module HMLAN, choose one of ALL3076 ALL4000T ALL4027 BS CM11 CUL CUL_EM CUL_FHTTK CUL_HM CUL_HOERMANN CUL_IR CUL_MAX CUL_RFR CUL_TX CUL_WS CULflash Calendar DbLog ECMD ECMDDevice EIB EM EMEM EMGZ EMWZ ESA2000 EnOcean FBAHA FBDECT FB_CALLMONITOR FHEM2FHEM FHEMWEB FHT FHT8V FHZ FLOORPLAN FRM FRM_AD FRM_I2C FRM_IN FRM_LCD FRM_OUT FRM_PWM FRM_SERVO FS20 FileLog HCS HMS HMinfo HTTPSRV HUEBridge HUEDevice Heating_Control IPCAM IPWE IT Itach_Relay JsonList KM271 KS300 LGTV LIRC LUXTRONIK2 LightScene M232 M232Counter M232Voltage MAX MAXLAN MSG MSGFile MSGMail NetIO230B OREGON OWAD OWCOUNT OWDevice OWFS OWID OWLCD OWMULTI OWSWITCH OWServer OWTEMP OWTHERM OWX PID POKEYS PRESENCE PachLog RFXCOM RFXMETER RFXX10REC RSS SCIVT SISPM SIS_PMS SML STV SVG SYSSTAT SrvGGUtils TCM THRESHOLD TRX TRX_ELSE TRX_LIGHT TRX_SECURITY TRX_WEATHER TUL TellStick Twilight USBWX USF1000 VIERA VantagePro2 WEBCOUNT WEBIO WEBIO_12DIGITAL WEBTHERM WOL WS2000 WS300 WS3600 Weather X10 YAMAHA_AVR ZWDongle ZWave at autocreate average backup dewpoint dummy fheminfo getstate holiday notice notify sequence structure telnet update watchdog weblink xxLG7000
Please define HMLAN1 first
Please define HMLAN1 first
Unknown module HMLAN, choose one of ALL3076 ALL4000T ALL4027 BS CM11 CUL CUL_EM CUL_FHTTK CUL_HM CUL_HOERMANN CUL_IR CUL_MAX CUL_RFR CUL_TX CUL_WS CULflash Calendar DbLog ECMD ECMDDevice EIB EM EMEM EMGZ EMWZ ESA2000 EnOcean FBAHA FBDECT FB_CALLMONITOR FHEM2FHEM FHEMWEB FHT FHT8V FHZ FLOORPLAN FRM FRM_AD FRM_I2C FRM_IN FRM_LCD FRM_OUT FRM_PWM FRM_SERVO FS20 FileLog HCS HMS HMinfo HTTPSRV HUEBridge HUEDevice Heating_Control IPCAM IPWE IT Itach_Relay JsonList KM271 KS300 LGTV LIRC LUXTRONIK2 LightScene M232 M232Counter M232Voltage MAX MAXLAN MSG MSGFile MSGMail NetIO230B OREGON OWAD OWCOUNT OWDevice OWFS OWID OWLCD OWMULTI OWSWITCH OWServer OWTEMP OWTHERM OWX PID POKEYS PRESENCE PachLog RFXCOM RFXMETER RFXX10REC RSS SCIVT SISPM SIS_PMS SML STV SVG SYSSTAT SrvGGUtils TCM THRESHOLD TRX TRX_ELSE TRX_LIGHT TRX_SECURITY TRX_WEATHER TUL TellStick Twilight USBWX USF1000 VIERA VantagePro2 WEBCOUNT WEBIO WEBIO_12DIGITAL WEBTHERM WOL WS2000 WS300 WS3600 Weather X10 YAMAHA_AVR ZWDongle ZWave at autocreate average backup dewpoint dummy fheminfo getstate holiday notice notify sequence structure telnet update watchdog weblink xxLG7000
Please define HMLAN2 first
Please define HMLAN2 first
EG_WZ: unknown IODev specified
EG_SZ: unknown IODev specified
EG_BA: unknown IODev specified
EG_BU: unknown IODev specified
OG_WZ: unknown IODev specified
OG_KU: unknown IODev specified
OG_BA: unknown IODev specified
UG_GZ: unknown IODev specified
UG_WS: unknown IODev specified
LED16_1E014A: unknown IODev specified
KFM100: unknown IODev specified
Schalter_1BEA79: unknown IODev specified
Schalter_1BEAE8: unknown IODev specified
Testschalter: unknown IODev specified
2013.04.04 21:56:59 1: Including /data/fhem/fhem.save
2013.04.04 21:57:00 1: statefile: Please define HMLAN1 first
Please define HMLAN2 first
2013.04.04 21:57:00 0: Server started with 152 defined entities (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2866 2013-03-07 15:10:37Z rudolfkoenig $, pid 13219)
Ich vemute mal, da wurde dann alles bezüglich der HMLANs aus der config geschmissen.
Hat vermutlich mit HMLAN nichts zu tun.
Noch ne Frage: Sieht man die am TC am Display angezeigte Zeit wenn sie z.B eine Std. vorgeht auch in FHEM?
Wie kann ich mit HM info eine Liste erstellen wo ich sehe welche Devices mit welchem HMLAN gepairt sind?
Gruss Billy
Mahlzeit
Ich bastele derzeit an meiner Heizungsregelung und habe den netten Effekt, das sich meine 4 TCs jede Nacht um 12Uhr (da fragen die wohl die Zentrale nach der Zeit) um eine Stunde vorstellen. Morgens mache ich dann für jeden ein "set sysTime" und die Welt ist wieder in Ordnung.
Wenn ich keinerlei Neustarts von fhem mache, dann haben die TCs die eingestellte Zeit auch über Mitternacht hinaus gehalten.
Jedoch arbeite ich gerade wie gesagt an der Heizungssteuerung und fahre täglich updates, ändere die config usw.
Also gibt es recht häufig "shutdown restart"
Der date Befehl von meiner NAS ist immer auf der richtigen Zeit, also unterstelle ich mal, dass dieses Verhalten irgendwie mit den zuständigen Modulen zu tun hat.
Bevor die ganze Sommerzeit Umstellungssache hier angelaufen ist, habe ich diesen Effekt nie gehabt.
Ich habe jetzt schon Angst vor der Winterzeitumstellung, wenn dann meine TCs jeden Tag eine Stunde zurück gestellt werden, dann ist es Morgens zu kalt und ich bekomme Stress mit meiner besseren Hälfte ;-)
Also, lieber an einem Tag (ende März) von Hand mal die Zeiten am TC einstellen als jeden Tag fummeln zu müssen...
Ansonsten bin ich soweit ganz glücklich.
Gruß Uwe
ich habe
10_CUL_HM.pm 3017
00_HMLAN.pm 2946 2013-03-18
auf dem RPi mit richtiger zoneneinstellung Berlin
und es stimmt die Uhrzeit jeden tag
TC mit 2.0 SW
Hallo Zusammen
mal abarbeiten
a) der spoiler hatte ich nicht geöffnet, sorry.
=> zu sehen sind jede menge Meldungen,die ich nicht deuten kann. Evtl hast du das file nicht mit download geladen? Es sieht nach einer web-darstellung des files aus.
=> könnt ihr eine update probieren? Mittlerweile sollte die version über normalen bereitstehen. Ihr könnt auch das File nach dem Download einmal ansehen
??> bitte bescheid geben, ob dies das Problem war
b) @Uwe: Du hast offensichtlich das Problem wie vor in diesem Thread beschrieben, dass HMLAN die Uhrzeit selbst liefert (die es vorher von FHEM bekommen hat). FHEM stellt die Zeit 2-mal bereit, ich hatte nur eines korrigiert. => mache einen update, die Korrektur sollte seit gestern Abend bereitstehen. Und Bitte vorsicht, Arthur und Billy hatten das in a) beschriebene Problem. Ich vermute einen Download fehler. Sicherheitshalber die Konfiguration sichern, schadet nie
c) @Billy: Wer mit der Zentrale gepairt ist, steht im Reading PairedTo, was identisch ist zu R-pairCentral. Evtl sollte ich PairedTo entfernen....
Für Auswertungen über die HM installation benutze ich HMInfo. Ich werde es einmal nach SVN stellen, wenn es mehr nutzen wollen. Evtl hast du schon die Anleitung gesehen: man muss eine entity define hm HMinfo definieren und kann dann die kommandos nutzen
set hm param PairedTo
besser gefiltert, da channels eh nicht paired sind:
set hm param -d PairedTo
Gruss
Martin
Hallo Martin,
Zitatmal abarbeiten
a) der spoiler hatte ich nicht geöffnet, sorry.
=> zu sehen sind jede menge Meldungen,die ich nicht deuten kann. Evtl hast du das file nicht mit download geladen? Es sieht nach einer web-darstellung des files aus.
=> könnt ihr eine update probieren? Mittlerweile sollte die version über normalen bereitstehen. Ihr könnt auch das File nach dem Download einmal ansehen
??> bitte bescheid geben, ob dies das Problem war
Grrrr und peinlich *schäm*, ja das wars (bei mir zumindest)! Danke.
Viele Grüße
Arthur
Zitat von: martinp876 schrieb am Fr, 05 April 2013 14:06c) @Billy: HMInfo.
set hm param PairedTo
besser gefiltert, da channels eh nicht paired sind:
set hm param -d PairedTo
Vielen Dank Martin, HMInfo nutze ich schon seit der ersten Stunde. Nur set hm param -d PairedTo habe ich gesucht.
Mir ist immer noch nicht klar wieso im Schnitt 8 TC die Zeit sauber umstellen und 2 (unterschiedlich) 1h vorgehen.?
Billy
Hi Billy,
was ist der Unterschied der TCs? Wo sind sie gepairt? Welches HMLAN?
Arbeiten alle gleich wenn du ein sysTime machst? Dann bekommen sie die Zeit direkt von FHEM, nicht vom HMLAN
Gruss
Martin
Zitat von: martinp876 schrieb am Fr, 05 April 2013 17:34Hi Billy,
was ist der Unterschied der TCs? Wo sind sie gepairt? Welches HMLAN?
Arbeiten alle gleich wenn du ein sysTime machst? Dann bekommen sie die Zeit direkt von FHEM, nicht vom HMLAN
Alle TC's haben die selbe Firmware 2.1, hängen am selben HMLAN1 sysTime mache ich natürlich nur bei denen die falsch laufen, dann sind sie wieder richtig!
Gruss Billy
die beiden "Speziellen" haben also in der Nacht eine andere Uhrzeit vom HMLAN bekommen? Haben sie einen Update in der Nacht gemacht?
Gruss
Martin
Hallo zusammen,
habe nun bei meine TCs ein set sysTime gemacht - einen lasse ich über Nacht laufen -> dieser ist mit HMLAN gepairt - schauen wir mal, ob er sich die Sommerzeit zieht ;o).
Viele Grüße
Arthur
Hi,
um sicher zu gehen solltest du den HMLAN einmal resetten.
Habe gerade einmal nachgesehen, die Uhrzeit wird beim Init gesendet. Meist passiert dies immer wieder... aber sicher ist sicher.
Bei einem FHEM restart passiert dies nicht.
Gruss
Martin
Hallo Martin,
kannst du mir bitte noch einen Tipp geben, was genau ich machen muss, um den HMLAn zu resten?
Danke.
Viele Grüße
Arthur
Hallo Martin,
wollte nur mal kurz Erfolgsmeldung verkünden:
3 x TCs gestern mit "set sysTime" umgestellt - Uhrzeit heute: "OK" (immer noch Sommerzeit)
1 x TC hat sich über Nacht auf Sommerzeit umgestellt (ohne HMLAN Reset)
An dieser Stelle, vielen vielen Dank für deinen Einsatz in den letzten Tagen.
Viele Grüße
Arthur
Hallo Martin,
ich kann erst Montag Abend ein Feedback zu meinen voreilenden TCs geben.
Habe leider keine webcam die auf die TCs ausgerichtet ist. ;-)
Ich habe aber von unterwegs fleißig alle updates und die damit verbundenen Neustarts gemacht.
Die Häufigkeit mit der die HomeMatic Module hier aktualisiert werden, lässt die Kollegen von eQ3/elv sicherlich vor neid erblassen...
7 file(s) have been updated:
==> 2013-04-06 07:45:17 FHEM/00_HMLAN.pm
==> 2013-04-06 07:45:17 FHEM/10_CUL_HM.pm
==> 2013-04-06 07:45:17 FHEM/21_OWCOUNT.pm
==> 2013-04-06 07:45:17 FHEM/46_TRX_LIGHT.pm
==> 2013-04-06 07:45:17 FHEM/70_SML.pm
==> 2013-04-06 07:45:17 FHEM/HMConfig.pm
==> 2013-04-06 07:45:19 docs/commandref.html
A new version of one or more module(s) was installed, 'shutdown restart' is required!
Update completed!
Alles wird gut!
Schönes Wochenende
Gruß Uwe
Hallo,
ich habe auch Positives zu vermelden. Meine TCs bekommen sowohl nachts als auch nach mutwilligem Verstellen der Uhrzeit auf 23:59 automatisch die korrekte Uhrzeit.
Danke für den schnellen Fix!
Gruß
Carsten
Kurzfassung:
ich hab auch das Problem, das alle meine TCs eine Stunde vor gehen.
Hab heute morgen ein Update gemacht und seit dem permanent mit dem Verschwinden des HMLAN zu kämpfen.
2013.04.07 08:51:42 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 08:51:47 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 08:51:47 1: HMLAN setting owner to F10000 from 6117B1
2013.04.07 08:55:27 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 08:55:37 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 08:59:35 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 08:59:40 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 09:00:00 3: Bad ist zu kalt. (43 )
2013.04.07 09:00:00 3: Flur_Unten ist zu kalt. (43 )
2013.04.07 09:03:44 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 09:03:54 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 09:07:52 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 09:08:02 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 09:11:59 3: Flur_Unten ist zu kalt. (43 )
2013.04.07 09:12:00 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 09:12:10 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 09:16:08 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 09:16:18 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 09:20:16 3: Flur_Unten ist zu kalt. (43 )
2013.04.07 09:20:16 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 09:20:26 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 09:24:24 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 09:24:34 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 09:28:32 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 09:28:42 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
2013.04.07 09:32:33 3: Flur_Unten ist zu kalt. (43 )
2013.04.07 09:32:40 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.04.07 09:32:45 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)
Meine gingen auch eine Stunde vor, das habe ich gestern durch Zufall mal gesehen, aber ich habs manuell schnell umgestellt und gut ist ;-)
Zitat von: ext23 schrieb am So, 07 April 2013 09:53Meine gingen auch eine Stunde vor, das habe ich gestern durch Zufall mal gesehen, aber ich habs manuell schnell umgestellt und gut ist ;-)
Ich denke, gut ist es nur, wenn du die HMLAN upgedated hast. Sonst ziehen die TCs um Mitternacht evtl. wieder die falsche Zeit.
@dougie: Hast du mal versucht, das Attribut repTime vom HMLAN hochzudrehen?
Nein. repTime ist mir und meiner Commandref unbekannt. :-/
das Attribut ist respTime (response-time)
ZitatIch denke, gut ist es nur, wenn du die HMLAN upgedated hast. Sonst ziehen die TCs um Mitternacht evtl. wieder die falsche Zeit.
Puh noch stimmt alles, und ich habe es gestern geändert ;-)
An alle,deren Zeit jetzt NICHT stimmt: Bitte Angaben zur Platform und speziell zur SystemZeit. Evtl ein date machen
Danke
Martin
Hallo,
ich habe auch das Problem, dass die Zeit auf allen HM-CC-TC nicht stimmt. Es wird +1 Stunde angezeigt. Also statt 14:00 Uhr > 15:00 Uhr.
Ich vermute das Problem steht seit der Sommerzeitumstellung.
Ich verwende eine:
- FritzBox mit FW 84.05.50
- 5 Stück HM-CC-TC incl. HM-CC-VC
- HMLAN Adapter FW: 0.961
- alle Update FHEM vom Stand Samstag 07.04.13
Kann es sein das der HM-CC-TC selber noch mal eine Stunde zurechnet auf Grund der Sommerzeiteinstellung und nicht mitbekommt dass die Zeitbasis schon mit Sommerzeit ist welche von FHEM gemeldet wird und von der Fritzbox kommt welche die Zeit wiederum bei einen Zeitserver bekommt.
Gruss Udo
...Verwende eine FritzBox 7390 und ein 'date' in der Konsole gibt die korrekte Zeit aus.
HM-LAN Adapter
12x TC
13x VD
Hallo Udo,
dass der TC selbst 1h addiert glaube ich nicht (mehr). Ich habe einige Tests gemacht,es wird immer die Zeit genommen, die ich übertrage. Und die ist von der Platform abgeleitet.
Klar ist, dass der TC die Zeit vom 00_HMLAN bekommt bei CUL aus CUL_HM. Beide sind mittlerweile gleich.
HMLAN bekommt seine Zeit beim reconnect von FHEM.
1) hast du einen reset des HMLAN gemacht? Einfach einmal power down.
Da sie Zeit immer nur um Mitternacht übertragen wird kannst du 2 tests Machen
2a) set name sysTime => fhem überträgt die Uhrzeit. Kann bis zu 4 min dauern, also wenn der TC das "wetter" meldet
2b) du setzt die Uhrzeit im TC manuell auf 23:59 und wartest ein paar minuten, Der TC holt sich die Zeit aus HMLAN.
==> was ist das Ergebnis?
kannst du nachsehen, welche Zeit in der FB herrscht? auf der Console ein "date" machen, dass sollte helfen
@Dougie, deine FB zeigt also auch "CEST". Deb LAN adapter hast du reseted?
Gruss
Martin
Hallo Martin,
ich habe jetzt folgendes gemacht:
1. HMLAN stromlos und somit neu gestartet
2. "date" bei der Fritzbox hat aktuelle Uhrzeit mit CEST angezeigt
3. die Temperatur in FHEM bei einem Thermostaten geändert > im LOG erschein ein Eintrag mit richtiger Uhrzeit
4. mit "set name sysTime" bei einigen HM-CC-TC_Climate die Übertragung angeschoben > Uhr geht immer noch eine Stunde vor
5. Uhrzeit beim TC auf 23:59 gestellt > die Uhrzeit wurde aktualisiert ab mit +1 Stunde statt 18:30 wieder 19:30
Gruss udo
Meine FB hat irgendwie nicht das CEST angezeigt. Sollte sie?
Ich hab mir mal eben ein Makro geschrieben und das aufgerufen. Seit dem alle Uhrzeiten an den TCs okay!
#
sub
prg_set_systime()
{
my @HMCCTC=devspec2array("model=HM-CC-TC");
foreach(@HMCCTC) {
fhem("set $_ sysTime");
}
}
Zur Sicherheit: Ihr habt beide CUL_HM und HMLAN auf dem neusten Stand.
meine FB zeigt
# date
Sun Apr 7 20:33:16 CEST 2013
Wenn die FB nicht auf Sommerzeit läuft, bin ich mir nicht sicher, was passiert.
Dougie, mit dem neuen 00_HMLAN sollte dies nicht mehr notwendig sein.
Udo, wenn du alles eingestellt hast... keine Ahnung. Muss ich einmal eine loggende Version bauen. Dauert aber, habe gerade keine Zeit... sorry
Gruss
Martin
Also mein HMLAN hat die FW 0.961 und was neueres abe ich nicht gefunden bzw. die Homematic Software zum Update durchführen hat nichts aktuelleres geladen.
Meine Fritzbox zeigt auch bei "date" CEST an, habe es zur Sicherheit nochmal geprüft.
Gruss Udo
Zitat von: UdoG schrieb am So, 07 April 2013 20:57Also mein HMLAN hat die FW 0.961 und was neueres abe ich nicht gefunden bzw. die Homematic Software zum Update durchführen hat nichts aktuelleres geladen.
Meine Fritzbox zeigt auch bei "date" CEST an, habe es zur Sicherheit nochmal geprüft.
Gruss Udo
Es geht um die 00_HMLAN.pm von FHEM. Nicht um die FW des Geräts.
Hallo Udo,
ist dein TC sauber mit der zentrale gepairt?
Viele Grüße
Arthur
P.S. Ich habe nahezu gleiche Konfiguration HMLAN und FritzBox bei mir funktioniert alles.
Edit: Sorry meinte Udo und nicht Carsten.
Hallo Arthur,
Update bei FHEM noch mal geprüft. Alles aktuell.
Ob mein TC sauber gepairt ist, habe ich jetzt langsam auch Zweifel dran. Ich glaube auch das ganze mit den pairen habe ich noch nicht richtig verstanden.
Also ich habe es wie folgt durchgeführt:
1. HMLAN Adapter Netzwerkkabel abgezogen damit dieser keine Verbindung zu FHEM hat
2. TC und VC Batterien eingelegt, TC Datum/Uhrzeit eingestellt
3. VC an Heizung installiert, Knopf gedrückt gewartet bis fertig
4. TC in den Anlernmodus versetzt und VC Knopf gedrückt bis "20" kommt > TC sagt "OK"
5. wenn ich noch einen Fensterkontakt hatte ebenfalls angelernt am TC
6. HMLAN Adaper wieder angesteckt und eine Moment gewartet
7. jetzt "set CUL hmPairForSec 300" in FHEM eingegeben
8. TC in Anlernmodus versetzt > "OK"
9. VC Knopf gedrückt bis "20" kommt auch OK
Jetzt sollte es funktionieren oder liegt hier schon ein Fehler vor?
Frage wenn man das Pairen nochmal machen muss wie sollte ich vorgehen? TC und VC Reseten und neu Pairen untereinander + FEHEM (FHEM vorher von diesen Geräten bereinigen?)
Bei mir funktionieren die Temperatur-Zeit-Listen auch nicht richtig, bzw. werden trotz im Gerät gespeichert nicht abgearbeitet (TC steht auf AUTO) aber das kann auch noch ein anderes Problem sein. Erstmal muss die Zeit stimmen.
Gruss Udo
PS. 00_HMLAN.pm ist vom 6.4.13 13:17
...heute Morgen leider wieder alle TCs eine Stunde vorraus.
Also noch mal:
Ausgabe von der FB:
BusyBox v1.18.5 (2012-03-27 15:06:45 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
# date
Mon Apr 8 06:52:42 CEST 2013
#
Verwendete 00_HMLAN:
$Id: 00_HMLAN.pm 2946 2013-03-18 19:09:07Z martinp876
Ich werde noch mal ein Update versuchen. Gestern hatte ich danach wie gesagt Probleme mit HM_Lan.pm und meinem HMLAN Device.
Edit: Hab jetzt upgedated auf:
$Id: 00_HMLAN.pm 3034 2013-04-05 06:28:53Z martinp876
Und noch mal ein set systime angestossen. Ich werde berichten.... morgen :-)
VG
Ralf
@Ralf, 2943 war sicher zu alt
@Udo
wenn das anlernen der VDs an den TC funktioniert hat war dieser wohl nicht gepairt.
Ausserdem sind dein VD und Fensterkontakt nicht gepairt
Also:
pairen - mit Zentrale
peeren - mit anderen channels
Ich empfehle ALLE devices mit FHEM zu pairen (auch VDs). Sie koennen dann immer noch mit dem TC gepeert werden.
Im Prinzip ist dein pairen ok. Du solltest es aber immer pruefen. Das geht immer gleich:
1) getConfig, warten bis Fertig
2) Readings ansehen: pairedTo muss die HMID der entrale haben.
Wenn du dies bei allen devices gemacht hast kannst du die channels peeren, von FHEM aus mit peerChan.
Nur wenn pairedTo nach einem getConfig korrekt ist hat das pairen funktioniert.
Alle peers siehst du auch nach getConfig in peerList. Beachten musst du, dass peeren eine Kanal-aktion ist. Im Climate-channel stehen die VDs, im window channel die Fensterkontakte. In den VDs der TC_Climate channel und im Fensterkontakt der TC-window.
Gruss
Martin
Hallo Martin,
irgendwie raffe ich das scheinbar noch nicht ganz.
Ich dachte immer erst alle Geräte TC, VC, SC vor Verwendung mit FHEM "pairen" also untereinander anlernen,
da es sonst nach Anmeldung am FHEM nicht mehr geht. Und nachher mit FHEM "pairen".
Wo finde " pairedTo" in der Readings-Liste mir nicht.
Das "peeren" muss ich erst noch durchführen bzw. Überprüfen.
Gruss Udo
PS. habe pairedTo gefunden im Thermostat im Climakanal gibts das nicht, ist das so?
Hallo Martin,
mein Montagabend Feedback wie versprochen...
Alle meine 4 TCs zeigen jetzt trotz diverser Neustarts und allen updates beim Übergang auf den neuen Tag die richtige Uhrzeit an.
Besten Dank für den schnellen Fix.
Gruß Uwe
Hallo Udo,
Zitatirgendwie raffe ich das scheinbar noch nicht ganz.
Ich dachte immer erst alle Geräte TC, VC, SC vor Verwendung mit FHEM "pairen" also untereinander anlernen,
da es sonst nach Anmeldung am FHEM nicht mehr geht. Und nachher mit FHEM "pairen".
In diesem Fall sprechen wir von peeren (peerChan) "du peerst dein SC mit dem entsprechenden Channel des TCs".
Also - hat Martin aber auch schon erwähnt:
Peeren = Channels (peerChen)- Kontrolle über reading: "peerList" (Achtung erst nach ein: getConfig sichtbar)
Pairen = Device mit zentrale -(pair) Kontrolle über reading: "PairedTo" (Achtung erst nach ein: getConfig)
Der TC (Thermostat) hat 3 Channels:
XX_Thermostat = Device
Chen 1: XX_Thermostat_Weather = Temp und Luftfeuchtigkeit
Chen 2: XX_Thermostat_Climate = VDs
Chen 3: XX_Thermostat_WindowRec = SC (Fensterkontakte)
Du kannst die VDs und SCs vorher peeren und dann dein Device mit der zentrale pairen.
Ferner\Alternativ(je nach Vorliebe) ist es möglich die devices direkt mit der Zentrale zu pairen, dann kannst du channels jedoch nur über FHEM peeren.
(Hoffe ich erzähle nichts falsches = hier müsste Martin vielleicht korrigieren.)
ZitatWo finde " pairedTo" in der Readings-Liste mir nicht.
Mach bitte vorher ein getConfig.
Viele Grüße
Arthur
Feedback:
Heute alle TCs mit der korrekten Zeit unterwegs. Vielen Dank Martin!! Saubere Arbeit!
Frage:
In der Vergangenheit hatte ich eine "parallel fhem Installation" auf einem RPi. Wenn RPi und FB mit der gleichen FHTID unterwegs waren, hatten die TCs auch schon mal eine Stunde Versatz, nachdem wer nach Mitternacht schneller war (RPi oder FB) auf den Time request zu antworten. Kann ich annehmen, das dieses Problem jetzt auch der Vergangenheit angehört?
VG
Ralf
@Ralf,
Die naechste Zeitumstellung kommt bestimmt.
Ich bin zuverschtlich. Die Berechnung bringt fuer CET keine Aenderung, MUSS also stimmen.
Was ich nicht sehen kann ist, was am Tag der Umstellung stattfindet. Ich kann mir zu viele Scenarien vorstellen:
Wann holt die Platform die Zeit von der NTR?
Wie oft wird die Zeit von der NTR geholt?
Fragt der TC vorher nach oder nachher ab
Sommer- und Winterzeitumstellung sind unterschiedlich. Eine Stund vor oder Zurueck koennen einen Unterschied in der Ueberlappung machen.
Die gute Nachricht: mein test-TC haette mit der aktuellen Implementierung die winter-> Sommer Umstellung korrekt durchgefuehrt.
Sollte bei der Umstellung Sommer->Winter eines der obigen Probleme zuschlagen kann man mit sysTime nachstellen, fuer den ersten Tag. Danach oder spaetestens in der naechsten Nacht sollte alles automatisch korrigieren.
@ Udo, Arthur
Arthur hat es schon beschrieben:
Pairen: Device mit Zentrale => pairedTo gibt es NUR in einem Device
Peeren: Channel mit Channel => peerList gibt es NUR in Channels
Viele Wege fuehren nach Rom (evtl. nicht alle)
Mein Weg:
1) IMMER ALLE PAIREN
2) peeren nach Bedarf durch FHEM, nie 'direkt'
man kann....
- auch vorher peeren, peers bleiben nach pairen erhalten
- die peering-vorgehensweise aendert sich , je nachdem ob das Device gepairt ist
=> da es viele Moeglichkeiten gibt,wenn.. dann... gibt es von mir immer nur ein Beschreibung. Die geht vorwaerts und rueckwaerts. Es gibt Moeglichkeinten es anders zu machen aber keinen Grund.
Viele kaempfen schon mit der einen Loesung, meine Empfehlung: vergesst die Anderen sowie die HM-anleitung zum direkten peeren (oder Anlernen, wie sie es hier nennen)
peerChan loest alle peering-Anforderungen!!!!!!!!
Gruss
Martin
Hallo alle zusammen,
bin erst vor kurzem in das Thema FHEM/HomeMatic eingestiegen. Dieses Forum hat mir schon oft weiter geholfen. Dafür erstmal vielen Dank an euch alle.
Nun aber zum Thema Sommerzeit.
Ich habe einen Ubuntu-Server, an dem ein HMLAN hängt, der wiederum den Wandthermostat und den daran gekoppelten Stellantrieb belauscht.
Seit der Sommerzeitumstellung schaltet der Wandthermostat in der Nacht regelmäßig eine Stunde vor (von 0:03 auf 1:03). Und dies auch noch nach dem gestrigen Update.
Die Systemzeit des Servers ist korrekt. Ein "set Wandthermostat sysTime" übermittelt dann wieder die korrekte Zeit.
Vorerst habe ich mich mit folgendem Eintrag in der fhem.cfg beholfen:
define Sommerzeit at *00:15 set Wandthermostat sysTime
Ich habe die bisherigen Beiträge zu diesem Thema hier gelesen und gedacht, mit dem Update gestern könnte es laufen. Tut es aber leider nicht.
Ich würde gern behilflich sein, kenne mich aber leider mit Perl überhaupt nicht aus. Außerdem bringt es ja nichts, wenn ich in irgend einer Datei was ändere und dann nach dem Update ist alles wieder überschrieben.
Sehe ich das so richtig? Oder gibt es doch eine endgültige Lösungsmöglichkeit?
Vielen Dank schon mal im Voraus.
Gruß
HaMuBot
Hi HaMuBot,
sehr seltsam.
Wenn sysTime geht sollte es auch in der Nacht kein Problem geben.
Sanity-questions:
- dein 00_HMLAN ist auf dem neusten Stand
- HMLAN einmal reseted (sicherheitshalber...)
Wenn sysTime funktioniert ist die Zeitrechnung ok. HMLAN benutzt die Prozedur aus eine 2. Funktion..., aber die Berechnung ist identisch.
Gruss
Martin
Hi Martin,
danke für die schnelle Antwort. Zurückgesetzt habe ich den HMLAN schon mal, kann ich nachher aber nochmal versuchen. Was meinst du mit "auf dem neuesten Stand"? Habe gestern Abend erst das Update gemacht.
Ist da nicht alles bei? Muss ich mir noch irgendwo etwas aktuelleres herunterladen?
Mir kommt das auch etwas komisch vor, aber es ist reproduzierbar. Bei der nächtlichen Zeitsynchronisation verstellt sich die Uhr des Wandthermostats.
Habe ich das richtig verstanden: der Wandthermostat fragt jede Nacht den HMLAN nach der Uhrzeit und dieser übermittelt ihm die Systemzeit des Grundsystems (hier Ubuntu)?
Oder hat der HMLAN eine eigene Datums-/Zeit-Verwaltung? Oder interpretiert er die Systemzeit vielleicht anders?
Wie gesagt, ich versuch nochmal einen Reset des HMLAN, sobald ich zuhause bin.
Besten Dank.
Gruß
HaMuBot
Hallo Martin,
der Reset des HMLAN hat es tatsächlich gebracht. Habe die Zeit am Wandthermostat auf gestern abend 23:59 gestellt und siehe da, nach kurzer Zeit wurde korrekt synchronisiert.
Meine Vermutung:
Der HMLAN hatte noch die Winterzeit vom System in sich. Wäre mal interessant, wann dieser vom System die Zeit abfragt.
Ich werde das mal im Auge behalten. Sollten die Minuten weglaufen (gegenüber Server) dann funktioniert die HMLAN-Zeit-Synchronisation mit dem Server nicht richtig.
Ich danke dir vielmals.
Gruß
HaMuBot
Hi HaMuBot,
nein, update sollte reichen. Da sollte alles dabei sein.
HMLAN bekommt die Uhrzeit von FHEM, und FHEM von Ubuntu.
der TC fragt jede Nacht nach (Mitternacht). Die Anfrage beantwortet HMLAN ohne Nachfrage (hat die Zeit ja schon).
HMLAN kann die Zeit nicht selbst holen, bekommt sie aber.
FHEM muss die Systemzeit umrechnen nach HM standard - Deren Zeitrechnung beginnt ~ 2000, nicht 1970. Ist eine Konstante.
Wenn du die Zeit im TC manuell auf 23:59 setzt wird dieser sich die Zeit vom HMLAN in den nächsten 3 min holen, kannst du einmal testen.
Gruss
Martin
Gestern erst bemerkt das die Zeit nicht auf Sommerzeit sich umgestellt hat.
Ab ins Forum um nachzulesen und hier gelandet.
Also FHEM Update gemacht und alle TC's mit set systime umgestellt.
Heute in der Früh kontrolliert und alles Korrekt.
- Qnap 439 PRO II +
- HMLAN Adapter FW 0.961
- 3 Stück HM-CC-TC + HM-CC-VC
- Update FHEM von 09.04.13
Hallo Martin,
hatte bis jetzt noch keine Zeit mich mit der Problematik zu beschäftigen. Hier eine kurze Zusammenfassung was bei mir passiert ist:
Hardware: Fritzbox 7390, HMLAN, 2xTCs, usw.
1. 30. März alles OK
2. 31. März, beide TCs auf Sommerzeit umgestellt
3. 1. April, beide TCs gehen eine Stunde vor
4. in regelmäßigen Abständen die TCs um eine Stunde zurückgestellt, am nächsten Tag gingen sie wieder eine Stunde vor
5. 9. April, update FHEM durchgeführt
6. 10. April, Geräte gehen wieder eine Stunde vor
Frage: Muss ich die Zeile in der CUL_HM noch anpassen oder ist diese im aktuellen Update schon eingepflegt?
Was mache ich ansonsten falsch das ich immer noch Nachts die falsche Uhrzeit eingestellt bekomme? WAF sinkt, ist morgens kalt im Bad!
Gruss,
Karsten
Hallo Karsten,
der Update "soll" natuerlich alles erledigen.
Bei einigen funktioniert es aber nicht.
Die Zeit wird in 00_HMLAN vorgegeben.
Die Zeile am Ende des codes ist verantwortlich - ist die identisch?
$t += 60*(($l[2]-$g[2] + ((($l[5]<<9)|$l[7]) <=> (($g[5]<<9)|$g[7])) * 24) * 60 + $l[1]-$g[1])
kannst du logs aufzeichnen mit
attr global verbose 1
attr <hmlan> loglevel 1
dann ein disconnect/connect, mir schicken
Gruss
Martin
Hallo Martin,
ich hoffe ich habe das so richtig eingestellt, wusste nicht wie das mit dem Disconnect geht, habe einfach die IP geändert und wieder richtig gestellt, ich hoffe das reicht!
Ach übrigens, hervorragende Arbeit die Ihr da leistet!!!!
Gruss,
Karsten
Hi,
eine Erfolgsmeldung:
"Aufgeschreckt" durch diesen Thread gestern Abend festgestellt, dass meine TCs auch alle eine Stunde vorliefen.
"date" auf meinem BeagleBoard-xM brachte die richtige CEST. Update gemacht (nebenbei dadurch auch gleich Fhem 5.4 installiert), shutdown restart, HMLAN vom Strom getrennt und wieder angeschlossen. Nebenbei: Der letzte Reset von Board und HMLAN war am 2.4.13.
2 TCs konnte ich dann per (mehrfachem) sysTime-Befehl umstellen, aber die anderen TCs wollten nicht so richtig (kamen Missing Acks). Also ab in die Waagerechte und heute Morgen festgestellt, dass alle TCs jetzt die richtige Uhrzeit haben.
Danke Martin.
Gruß
Thomas
@ Thomas,
muss ja auch einmal was klappen. Hoffe es bleibt so.
@Karsten: in deinen Logs kann ich keinen reconnect der HMLAN sehen, waehrend die traces eingeschaltet sind.
Kannst du es einmal wiederholen?
Traces einschalten, HMLAN strom ziehen.
logs schicken (nur der letzte Teil)
Danke
Martin
Hallo Martin,
sorry das ich mich jetzt erst wieder melde, ging nicht früher, aber meine Thermostate gehen immer noch im 1 Std vor. Hier mein Log, ich hoffe das es jetzt alle Informationen erhält die Du benötigst.
Gruß, Karsten
Hi Karsten,
die Uhrzeit, die an HMLAN gesetzt wird ist eine Stunde weniger als bei mir:
2013.04.10 22:05:34 1: HMLAN_Send: T18F8909E,04,00,00000000
Also der Vergleich logtime zu HMLAN time.
Demnach stimmt mit der Berechnung etwas nicht.
Ich habe ein HMLAN angehängt. kannst du das einspielen und testen? Da sind logs drin, leider noch einmal...
Gruss
Martin
Hallo Martin,
habe die Datei gestern Abend eingespielt, heute noch mal den HMLAN de/aktiviert.
Benötigst Du noch mehr als den folgenden Log?
Gruss, Karsten
da fehlt der Log.
hast du das File genutzt, das ich geschickt hatte?
der log sollte etwa so aussehen
General timecheck 1365972251 419280251 l:1-2-3-4-5 .....
Evtl nutzt du doch das falsche HMLAN?
Gruss
Martin
Hallo Martin,
ja hatte ich eigentlich, zumindest bin ich der Meinung, Datei liegt auch im FHEM Ordner. Shutdown Restart habe ich auch noch mal ausgeführt!
Mal schauen, werde es heute Abend noch mal ausprobieren!
Gruss Karsten
Hallo Martin,
habe gestern noch mal einen dis/connect durchgeführt, aber die Zeile Timecheck ist im LOG nicht zu finden, obwohl ich den Level auf 1 stehen habe. Hast Du eine Idee warum das so ist, was mache ich falsch? Kann ich ein dis/connect auch anders, z.b. über einen VPN-Zugang durchführen!
Gruss, Karsten
Ich werde heute Abend noch einmal testen, ob die Logs kommen. Eigentich sollten die immer kommen, da hart Level 1 sind. Eigentlich kann es nur heissen, dass das File nicht das ist, was verarbeitet wird.
Ein remove forced reconnect habe ich jetzt nicht bei der Hand. FHEM stoppen und nach 30sec starten sollte immer gehen
Gruss
Martin
Hallo Martin,
ich befürchte bei mir ist etwas mit dem "Shutdown Restart" falsch gelaufen und der FHEM hat nicht mit deiner bzw. der aktuellen HMLAN gearbeitet. Es scheint auch so das der letzte Update den ich am 10.04. durchgeführt habe nicht vollständig war, kopiert ja aber nicht gestartet. Ist das Möglich?
Mir ist nämlich erst heute Morgen der neue Button "Save config" aufgefallen und ich bin mir sicher der war gestern noch nicht da. Also nun im Anhang die Log-Datei mit der gewünschten Timecheck Ausgabe!
Aber vielleicht hat sich aber das ganze morgen auch erledigt und die Uhren stimmen?! Möchtest Du die Log Datei vom gesamten April noch mal haben um die Update prozedure zu nachzuvollziehen?
Viele Grüße, Karsten
Zitat von: Krol schrieb am Di, 16 April 2013 17:06Es scheint auch so das der letzte Update den ich am 10.04. durchgeführt habe nicht vollständig war, kopiert ja aber nicht gestartet. Ist das Möglich?
Ist definitiv möglich. Ist mir anfangs auch passiert.
Datei austauschen reicht nicht. Sie muss mindestens mit "reload <Datei>" neu geladen werden. Sonst werkelt die alte Version weiter. Besser ist shutdown restart.
Hi Karl,
ich bin einmal guter Dinge, das die Zeit stimmt - warten auf Morgen.
Beim Update bin ich nicht der Spezialist. Musst du bei Rudi nachfragen, wer das macht.
Gruss, bis Morgen
Martin
Hallo Martin,
heute Morgen ging die Uhrzeit von einem Gerät richtig, von dem anderen war die Uhrzeit gar nicht verstellt, sie ging um mehr als 1h falsch. Habe das Gerät auf 23.55Uhr gestellt, darauf ist aber auch nichts passiert, werde noch mal eine Nacht abwarten, war vielleicht auch ein bischen zu ungeduldig!
Im Log habe ich folgende Zeile gefunden:
2013.04.17 06:34:51 1: General timecheck 1366173291 419488491 l:9 gmt:51-34-4-17-3-113-3-106-0
Hast Du eine Idee warum die Lokaltime nicht richtig angzeigt wird? Wieso wird für das Jahr 113 angezeigt? Was bedeutet der Rest hinter dem Jahr?
Codezeile für diese Ausgabe:
Log 1,"General timecheck $t $t2 l:".join"-",@l." gmt:".join"-",@g;
Viele Grüße, Karsten
Hi Karl,
ist dein 2. Geraet mit der Zentrale gepairt? Wenn nicht wird es wohl auch nicht die Uhrzeit abholen.
FHEM schickt die Zeit nicht, der TC holt sie.
schau mal hier
http://perldoc.perl.org/functions/localtime.html (//perldoc.perl.org/functions/localtime.html)
wegen der Zeit
bei der Localtime habe ich einen Fehler gemacht, haette klammern muessen, kein Problem mehr.
Gruss
Martin
Hallo Martin,
nach einem erneuten pairen funktioniert jetzt auch der zweite TC.
Danke noch mal für die Ünterstützung!
Und von meiner Seite auch noch mal meinen Lob für Eure geleistete Arbeit!!!! Echt eine super Software!!!!
Viele Grüße,
Karsten