Hallo, zufällig habe ich gestern und heute gesehen, dass der TC eine falsche Zeit anzeigt.
Habe sie gestern am TC neu eingestellt und auch ein update gemacht (10_CUL_HM.pm 6747) - aber heut früh das gleiche Verhalten.
Hat das noch jemand beobachtet?
Aus den logs ist nichts ersichtlich und ich habe nur einen TC, sodass ich keinen Vergleich habe. Die HM-CC-RT-DN zeigen alle die korrekte Zeit.
Uwe.
Hallo Uwe,
kontrolliere mal Datum und Uhrzeit auf deinem Raspberry Pi.
LG
edank
Werde ich machen, wenn ich wieder zu Hause bin.
Wenn es daran liegt, dann müssten doch alle Geräte eine falsche Zeit haben - oder?
Uwe.
Guten Morgen zusammen,
das "Problem" habe ich auch.
Mit der Umstellung auf Winterzeit ist es wieder passiert.
Meine 3 HM-TC-IT-WM-W-EU zeigen noch immer die Sommerzeit an.
Die HM-CC-RT-DN dagegen zeigen die korrekte Uhrzeit an.
Ist aber nicht nur ein Sommer-/Winterzeit Problem.
Auch nach einem Stromausfall passiert es, das die HM-TC-IT-WM-W-EU eine
falsche Zeit haben.
Der time-request kommt, wie gewohnt einmal am Tag:
2014-10-27_02:15:45 WT.Buero_System time-request: -
2014-10-27_02:15:45 WT.Buero_System CMDs_done
Aber, er behält stur die alte Uhrzeit bei.
Ein set <device> sysTime setzt die richtige Zeit und bleibt dann auch.
FHEM ist auch aktuell:
# $Id: fhem.pl 6782 2014-10-18 06:14:57Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6794 2014-10-19 16:48:14Z martinp876 $
Habe fast das Gefühl, die Wandthermostate ignorieren das, was sie als time-request zurück bekommen ?!? :)
Gruß
Jens
Bei mir ist es ganz seltsam. Ich bin mir ziemlich sicher dass meine Thermostate gestern die Zeitumstellung mitgemacht und die richtige Uhrzeit angezeigt haben, heute morgen hatten sie aber wieder Sommerzeit ???
Uhrzeit auf dem RasPi und innerhalb FHEM habe ich schon kontrolliert, ist alles korrekt auf Winterzeit.
Zitat von: Bombjack am 27 Oktober 2014, 09:24:46
Bei mir ist es ganz seltsam. Ich bin mir ziemlich sicher dass meine Thermostate gestern die Zeitumstellung mitgemacht und die richtige Uhrzeit angezeigt haben, heute morgen hatten sie aber wieder Sommerzeit ???
Uhrzeit auf dem RasPi und innerhalb FHEM habe ich schon kontrolliert, ist alles korrekt auf Winterzeit.
Stimmt. Kann ich auch für den alten HM-CC-TC bestätigen. Gestern bei allen 10 Zeitumstellung ok.
Heute morgen alle wieder auf Sommerszeit.
Alle 10 mit set <device> sysTime auf die richtige Zeit gesetzt --> bleibt dann auch.
Erinnere mich, dass das früher schon mal war.
Gruß Billy
@Billy
Ja, ist hier das gleiche Verhalten: Gestern stimmte die Zeit, heute früh war sie falsch.
Herr
Die Uhrzeiten an RT und TC sind mir eigentlich sowas von wurscht - wozu auch?
Aber aufgrund des Threads habe ich gerade nachgesehen - hier sind die Zeiten an allen Geräten korrekt. Und ich habe weder gestern noch heute diesbezüglich manuell eingegriffen.
Hallo,
auch bei mir das selbe Verhalten. Die Wandthermostate bleiben stur auf Sommerzeit.
Selbst wenn ich mit set <device> systime die richtige Zeit einstelle, ist sie am nächsten Tag wieder flasch auf Sommerzeit.
Warum ist die Zeit am Thermostat egal? Ich steuere damit die Heizkörper und nutze fhem quasi nur als Ferneingriffmöglichkeit. Außerdem hängen die Thermostat prominent im Zimmer, da wäre die richtige Uhrzeit schon shön.
Nachtrag:
Es gibt im Wandthermostat eine Einstellung für die automatischer SOmmer-/Winterzeitumstellung (s. Anleitung, Einstellung dSt). Ist diese bei euch On oder Off?
Grüße
Dirk H
Hallo,
hm, also ich habe gestern Mittag noch die Updates eingespielt, danach nartürlich ein "shutdown restart".
Brav den time-request abgewartet, und nun ? Ja, die Uhrzeit stimmt wieder auf den TCs.
Die Uhrzeit war aber laut "{ FmtDateTime(time()) }" auch vorher schon korrekt innerhalb von FHEM.
Gruß
Jens
Zitat von: Dirk_H am 28 Oktober 2014, 07:32:41
Nachtrag:
Es gibt im Wandthermostat eine Einstellung für die automatischer SOmmer-/Winterzeitumstellung (s. Anleitung, Einstellung dSt). Ist diese bei euch On oder Off?
Steht bei mir auf "on".
Bei den RTs (die noch ohne TC sind) allerdings auch und die haben sich ja am Sonntag schon korrekt umgestellt.
Ich habe zur Zeit nur zwei von den Thermostaten im Einsatz und gestern beide manuell über die Thermostat-Einstellungen wieder auf Winterzeit gesetzt. Heute morgen stimmte bei einem die Uhrzeit und bei dem anderen war wieder Sommerzeit...doppel hä?! :o
Das mit der automatischen Sommer/Winter Umstellung werde ich nachher mal prüfen.
Zitat von: Dirk_H am 28 Oktober 2014, 07:32:41
Warum ist die Zeit am Thermostat egal? Ich steuere damit die Heizkörper
Ich auch. Aber dazu brauche ich die Uhrzeit im Thermostat nicht, dazu hab ich ja fhem.
Zitat von: Dirk_H am 28 Oktober 2014, 07:32:41
Außerdem hängen die Thermostat prominent im Zimmer, da wäre die richtige Uhrzeit schon shön.
Man muss aber schon sehr nah an die Wandregler und/oder die Antriebseinheiten rangehen, um die Uhrzeit überhaupt erkennen zu können.
Das besagte Register zur Sommerzeit steht bei mir übrigens auf ON.
Ich hatte auch das Problem , allerdings bei allen RT's. Ich habe die Zeit dann per
set [name] sysTime an allen gesetzt. Die Zeit auf dem Cubi war richtig. Ging eigentlich davon aus dass dies autom. geschieht (war zu mindets bei der Sommerzeit so).
Als Sonntag noch die Sommerzeit auf den RT's war habe ich erstmla Update gemacht, Zeit auf Cubie geprüft, fhem und Cubie neu getsartet und den Montag abgewartet. Leider ohne Erfolg. Da die RT's noch auf manu standen war es erstmal egal aber wäre der AutoMode schon aktiv gewesen hätte man eine 1h Versatz gehabt.
@betateilchen: wenn man die Templiste im RT selbst ablegt und ihn die arbeit machen lässt sollte die Uhrzeit schon stimmen ;-)
Find den Weg besser da man sich so auch ohne fhem (weil zb mal wieder hm-modul zickt oder fhem oder cubi) auf die Heizung verlassen kann, ist aber auch nicht so flexibel.
Also das Problem besteht bei mir nach wie vor. Vorgestern hatte ich mal testhalber dSt auf off gesetzt, gestern morgen waren die Zeiten dann okay. Allerdings habe ich mich zu früh gefreut, auf einem (!) der beiden Thermostate war dann heute erneut Sommer. set [device] sysTime habe ich mittlerweile schon ein paar mal durch, das hilft nur temporär bis zur nächsten Synchronisierung.
Ich mache später einfach mal alles stromlos und hoffe dass es das vielleicht bringt, langsam gehen mir die Ideen aus.
Ich habe das Problem auch: Jeden Abend muss ich die Zeit wieder zurückstellen. Ich meine, dass das immer 24 Stunden nach dem letzten sysTime-Befehl passiert. Das Dst-Register stand auf "on", gestern habe ich das am Gerät auf "off" gesetzt. In deen Internals taucht das bei FHEM gar nicht auf.
Liegt das vielleicht an der Firmware, meiner hat noch die 1.0? Kann ich das selbst mit dem HMCFG-USB updaten?
So, auch mit Einstellung "dst off" wird nach 24 Stunden die Zeit vorgestellt. Was macht Hat irgendjemand inzwischen die Lösung für das Problem oder noch besser dessen Ursache gefunden?
Als TE will ich mich auch noch mal melden (war nicht zu Hause).
Bei mir ist das Problem nicht wieder aufgetreten - auch nach der Zeitumstellung nicht.
Bei der TC-VD-Kombination hatte ich auch mal den Fall. Ich habe dann jede Nacht die Uhrzeit zu den TCs geschickt und irgendwann hat dann Martin den automatischen Abgleich eingebaut. Nach einer Übergangszeit habe ich dann die nächtliche Botschaft nicht mehr verschickt und mit den TCs keine Probleme mehr mit der Zeit gehabt.
Den neuen TC habe ich erst seit Sommer in Betrieb und bis jetzt war der Fehler nicht aufgetreten.
Wenn man alles über fhem steuert, ist die TC-Zeit ja ziemlich egal, aber bei Tages- und Wochenprogrammen im TC sollte die Zeit schon stimmen...
Uwe
Also die Zeitumstellung passiert wohl beim "Time Request"
In Meinem Log findet sich:
2014-10-31_17:03:50 TH1 time-request: -
2014-10-31_17:03:50 TH1 CMDs_done
Da diesem Zeitpunkt geht die Uhr falsch.
Das Server-OS hat definitiv die richtige Uhrzeit. Fhem auch. Also wird offenbar eine falsche Zeit übertragen oder die übertragene Zeit falsch interpretiert.
Im ELV-Forum habe ich nichts zu einer falschen Zeit gefunden. Also scheint das ein FHEM-Fehler zu sein.
Herr 3x
der rt (alle devices mit Uhr) fragen einmal täglich bei der Zentrale die Uhrzeit nach. Der log time-request wird dabei gesetzt.
Du kannst jederzeit die Uhrzeit noch einmal übertragen. Das geht mit "sysTime".
Es wird immer die Uhrzeit des Systems übertragen.
welches system hast du? Wie spät ist es dort?
Problematisch ist evtl sie Zeitzone. Wie ist die eingestellt? MEZ?
schicke ggf ein log, wenn du systime ausführst.
Hi,
ja, ich habe mir jetzt ein notify auf den time-request gebaut, der nach einer kleinen Wartezeit einen sysTime ausführt. So ist es im Bad wenigstens nicht kalt am Morgen.
Eigenartigerweise tritt das Problem nur bei den Wandthermostaten auf.
Die Urzeit des OS-X-Servers ist korrekt, fhem logt auch mit der richtigen Zeit. Zeitzone, hmmm, ja, keine Ahnung, wo ich die prüfen soll. Wenn es wichtig sein sollte google ich mal rum.
In den Systemeinstellungen steht jedenfalls Mitteleuropäische Normalzeit.
Systime erzeugt das hier:
2014.10.31 20:51:17.522 0: HMLAN_Send: HMLAN1 S:+26030C,00,01,00
2014.10.31 20:51:17.523 0: HMLAN_Send: HMLAN1 S:S67C3125B stat: 00 t:00000000 d:01 r:67C3125B m:0A 903F 121212 26030C 02041BE696A5
2014.10.31 20:51:17.906 0: HMLAN_Parse: HMLAN1 R:R67C3125B stat:0002 t:00000000 d:FF r:7FFF m:0A 903F 121212 26030C 02041BE696A5
2014.10.31 20:51:36.883 0: HMLAN_Send: HMLAN1 S:S67C35DFC stat: 00 t:00000000 d:01 r:67C35DFC m:0B 903F 121212 26030C 02041BE696B8
2014.10.31 20:51:37.265 0: HMLAN_Parse: HMLAN1 R:R67C35DFC stat:0002 t:00000000 d:FF r:7FFF m:0B 903F 121212 26030C 02041BE696B8
Der 26030C ist der Thermostat.
Hilft das weiter?
Herr 3x
schicke einmal das ergebniss von
{return time()." - ".join(":",localtime(time()))." - ".join(":",gmtime(time()))}
Zitat von: martinp876 am 01 November 2014, 08:47:18
schicke einmal das ergebniss von
{return time()." - ".join(":",localtime(time()))." - ".join(":",gmtime(time()))}
Liefert bei mir :
1414829314.87575 - 34:8:9:1:10:114:6:304:0 - 34:8:8:1:10:114:6:304:0
1414831096.31956 - 16:38:9:1:10:114:6:304:0 - 16:38:8:1:10:114:6:304:0
Vielleicht ist es ja nur Zufall, aber ich habe vor zwei Tagen dem HMLAN Adapter einmal den Stecker gezogen und neu gestartet. Seitdem ist bei mir Ruhe und die Zeiten stimmen wieder :)
hm - könnte sein, dass der HMLAN eine eigene Zeit hat und die versendet. evtl ist er nicht auf Stand. Mal sehen
Einfach mal die Gegenfrage gestellt:
Wer von den Leuten, die hier Probleme mit der Zeitanzeige haben, arbeitet mit einem HMLAN und wer mit HMUSB?
Ich arbeite mit drei HMUSB und habe keine Probleme mit der Zeitanzeige.
Zitat von: betateilchen am 02 November 2014, 11:30:51
Einfach mal die Gegenfrage gestellt:
Wer von den Leuten, die hier Probleme mit der Zeitanzeige haben, arbeitet mit einem HMLAN und wer mit HMUSB?
Ich arbeite mit drei HMUSB und habe keine Probleme mit der Zeitanzeige.
Stimmt, das wäre auch noch interessant. :)
Bei mir ist ein HMLAN.
HMLAN
HMLAN
HMLAN - kein Probem
HMLAN - mit Problem.
Habe auch bemerkt dass alle Komponenten zusätzlich zu der genannten Stunde noch 4 Minuten vorgehen, obwohl die Host Zeit (FritzBox) stimmt. Hat der HMLAN eventuell eine eigene RTC? Hab ihn mal kurz vom Strom genommen und warte auf das nächste automatische Zeit-Update.
Einen takt sicher, eine rtc wobl nicht
Ja, da hab ich mich ungenau ausgedrückt, einen RTC-Käfer erwarte ich auch nicht auf dem Board, aber schon eine eigene Zeitzählung in Software mit augenscheinlich automatischem Versand überrascht mich ein wenig.
Also, Schlaf- und Kinderzimmer sind mittlerweile wieder korrekt, Wohnzimmer noch nicht, dürfte aber auch noch passieren. Hab nur den HMLAN kurz vom Strom genommen und sonst nichts.
Bei mir sind die Zeiten nach wie vor okay, es scheint als lag es wirklich am HMLAN.
Muss man wohl regelmassig die zeit an den hmlan sende. Sein quarz ist sehr ungenau - moeglich, dass es garkeiner ist.
Zitat von: martinp876 am 03 November 2014, 20:23:58
Muss man wohl regelmassig die zeit an den hmlan sende. Sein quarz ist sehr ungenau - moeglich, dass es garkeiner ist.
Wenn ich ein Bild der Platine im Netz richtig interpretiere, dann hat er sogar 2 Quarze ;) Aber Abweichungen in der Größenordnung von ner Minute pro Monat ist leider nicht sonderlich ungewöhnlich.
Es macht den Anschein dass der HMLAN den Timestamp Request wohl autonom beantwortet, oder kannst Du Dir das sonst irgendwie erklären? Wird Dein Code in CUL_HM überhaupt ausgeführt?
Wär's möglich das "T" Kommando zumindest einmal am Tag zum HMLAN zu senden?
Danke und Grüße, Marcel
hallo,
habe hier genau das gleiche Problem mit HMLAN und zwei Raumthermostaten... HMLAN power cyclen habe ich noch nicht probiert, werde es heute abend testen.
DST im Raumthermostat auf ON oder OFF stellen hat bei mir keinen einfluss...
grüße
Ich habe am Samstag in FHEM herumprogrammiert und schließlich den Raspi neu gebootet. Der HMLAN blieb am Netz. Aber seitdem stimmt die Uhr vom Thermostat.
Zitat von: topfi am 04 November 2014, 21:58:04
Ich habe am Samstag in FHEM herumprogrammiert und schließlich den Raspi neu gebootet. Der HMLAN blieb am Netz. Aber seitdem stimmt die Uhr vom Thermostat.
Soweit ich das im Code sehe wird die Uhrzeit derzeit beim Aufbau der Verbindung einmalig übermittelt. Ob man jetzt den HMLAN oder FHEM neu startet ist daher ziemlich egal.
Hallo,
ich habe auch einen HMLAN und habe einen Wandthermostat mit DST on und einen mit off. Beide Thermostate hatten ca. 4-6 Tage nach der Zeitumstellung immer wieder die falsche Zeit (auch nach manuellen setzen war es einen Tag später wieder falsch).
Nach den 4-6 Tagen funktioniert es jetzt bei beiden Wandthermostaten ohne das ich irgendwas geändert habe?!
Ich mein ich freu mich natürlich das es funktioniert, aber grundsätzlich finde ich es schon "unschön" wenn Probleme sich von selbst beheben und man nicht weiß woran es jetzt lag...
Grüße
Dirk H.
Zitat von: Dirk_H am 05 November 2014, 19:21:58
Nach den 4-6 Tagen funktioniert es jetzt bei beiden Wandthermostaten ohne das ich irgendwas geändert habe?!
Vermutlich gab es einen Disconnect. Schau doch mal im Log nach ob es einen Timeout beim HMLAN gab.
Grüße, Marcel
hallo,
also ich habe vorgestern meinen hmlan vom strom genommen und wieder angeschlossen. seit dem scheinen die uhrzeiten an den beiden raumthermostaten wieder zu stimmen.
ich werde das weiter beobachten.
danke einstweilen für eure hilfe!
grüße peter
Zitat von: pez3 am 06 November 2014, 18:05:25
hallo,
also ich habe vorgestern meinen hmlan vom strom genommen und wieder angeschlossen. seit dem scheinen die uhrzeiten an den beiden raumthermostaten wieder zu stimmen.
ich werde das weiter beobachten.
danke einstweilen für eure hilfe!
grüße peter
Da setze ich mich doch mal hinter, auch wenn die Winterzeitumstellung schon vorüber ist. Bei mir haben die Wandthermostate seit ein paar Tagen richtig falsche Uhrzeiten. Heute morgen um kurz vor acht hat er irgendwas mit 17h angezeigt. Ein sysTime hilft dann auch wieder.
Gibt es hierzu noch neuere Erkenntnisse, oder ist die momentane Lösung FHEM-Neustart oder HMLAN-Neustart das einzige, was dieses Problem beheben kann?
Es wurde hier auch darüber gesprochen, das die TCs sich mit dem HMLAN verbinden und die Uhrzeit abfragen. Ist das korrekt? Und kann man die falsche Uhrzeit irgendwie aus dem HMLAN auslesen, oder sogar, wenn falsch, neu setzen?
Btw., ich habe einen HMLAN :-)
Zitat von: betateilchen am 28 Oktober 2014, 09:27:49
Ich auch. Aber dazu brauche ich die Uhrzeit im Thermostat nicht, dazu hab ich ja fhem.
Konfig:
RT mit TC gepeert, RT und TC mit FHEM gepaired.
Frage:
Von wem wird das Wochenprogramm das ich am TC eingegeben habe denn ausgeführt?
Bisher war ich davon ausgegangen, dass der TC steuert und das Programm von den RT's abgearbeitet wird und FHEM zwar die Readings der Devices anzeigt aber nicht steuert !?
VG
Claus
ZitatVon wem wird das Wochenprogramm das ich am TC eingegeben habe denn ausgeführt?
der tc sendet entsprechend den zeiten des tc-wochenprogramms eine desired-temp an den rt, wenn die climate channel gepeert sind.
Danke frank!
Dann wäre es doch ganz nett wenn die Zeit im Display des TC stimmt ;D
VG
Claus
Hast du den HM LAN mal stromlos gemacht und dann geschaut? (Dauert vermutlich etwas)
Bekommt man über das Device in Fhem irgendwie heraus, welche aktuelle Zeit das hat? Kann ich das also irgendwie an der Weboberfläche sehen und muss nicht zu den Thermostaten laufen?
Zitat von: strauch am 21 Januar 2015, 17:27:44
Hast du den HM LAN mal stromlos gemacht und dann geschaut? (Dauert vermutlich etwas)
Das wollte ich eigentlich vermeiden und eher versuchen den eigentlichen Fehler zu lokalisieren und zu beheben. Neustarten erinnert mich zu sehr an meine ELV-Max-Cube-Zeit, da war das auch immer die Top Support Antwort ;-)
Zitat von: TomWest am 22 Januar 2015, 08:36:05
Bekommt man über das Device in Fhem irgendwie heraus, welche aktuelle Zeit das hat? Kann ich das also irgendwie an der Weboberfläche sehen und muss nicht zu den Thermostaten laufen?
Ich habe bis jetzt nur den Internal-Wert HMLAN1_TIME im HMLAN-Device gefunden. Der ist bei mir aber richtig.
Zitat von: Cruiser79 am 22 Januar 2015, 09:55:41
Das wollte ich eigentlich vermeiden und eher versuchen den eigentlichen Fehler zu lokalisieren und zu beheben. Neustarten erinnert mich zu sehr an meine ELV-Max-Cube-Zeit, da war das auch immer die Top Support Antwort ;-)
Das kann ich verstehen, aber es würde helfen beim Fehler einkreisen, wenn damit erstmal die richtige Uhrzeit kommt, weißt du wo du suchen musst. Wenn da ein Fehler ist, wird der auch wieder kommen.
Zitat von: Cruiser79 am 22 Januar 2015, 09:55:41
Das wollte ich eigentlich vermeiden und eher versuchen den eigentlichen Fehler zu lokalisieren und zu beheben. Neustarten erinnert mich zu sehr an meine ELV-Max-Cube-Zeit, da war das auch immer die Top Support Antwort ;-)
Ich würde es bevorzugen wenn dem HMLAN zumindest einmal am Tag auch ohne Reset die korrekte Uhrzeit übermittelt wird, aber Martin hat sich hier nicht mehr eingeklingt und derzeit entwickelt anscheinend nur er den Code weiter. Wieso die Uhrzeit in Deinem Fall so extrem abgewichen ist wirst Du vermutlich kaum herausfinden können. Möglicherweise hat der HMLAN connected während die Systemzeit gerade nicht aktuell war (Fritzbox nach dem Booten und vor dem Connect zum NTP Server als Beispiel), aber das ist nur eine vage Theorie. Fakt ist, wenn die Situation einmal eintritt, dann bleibt sie bis zum nächsten Aufbau der Verbindung auch so. Evtl ist der Uhren-drift irgendwann so groß dass er wieder die reale Uhrzeit trifft, aber bei mehreren Stunden kann das ein paar Jahre oder Jahrzehnte dauern ;)
eventuell könnte man folgendermassen vorgehen:
die zeit vom tc wird ja anscheinend sowohl von fhem als auch heimlich vom hmlan gesetzt. da man keinen einfluss auf die zeit vom hmlan hat (höchstens stecker ziehen), müsste man die fhem zeit testweise verstellen. dann haben beide unterschiedliche zeiten. dann die rawmessages vom funkverkehr des tc überwachen. am besten mit einem 2. io, da der hmlan nicht alles was er funkt an fhem weitergibt. so müssten fhem und hmlan ständig versuchen, dem tc ihre zeiten aufzudrücken.
Zitat von: frank am 22 Januar 2015, 11:14:28
so müssten fhem und hmlan ständig versuchen, dem tc ihre zeiten aufzudrücken.
Also ausser auf ein explizites "set systime" wüsste ich jetzt nicht wo fhem versucht dem tc eine Zeit aufzudrücken?
Zitat von: frank am 22 Januar 2015, 11:14:28
eventuell könnte man folgendermassen vorgehen:
die zeit vom tc wird ja anscheinend sowohl von fhem als auch heimlich vom hmlan gesetzt. da man keinen einfluss auf die zeit vom hmlan hat (höchstens stecker ziehen), müsste man die fhem zeit testweise verstellen. dann haben beide unterschiedliche zeiten. dann die rawmessages vom funkverkehr des tc überwachen. am besten mit einem 2. io, da der hmlan nicht alles was er funkt an fhem weitergibt. so müssten fhem und hmlan ständig versuchen, dem tc ihre zeiten aufzudrücken.
Darauf einmal aufgesetzt noch einmal die Frage von mir: Wer fragt denn jetzt bei wem was ab? Soweit ich das verstanden habe: Der TC fragt beim HMLAN alle 24 Stunden die Zeit ab. Dieses Verhalten ist fest einprogrammiert und kann man nicht ändern. Wenn ein TC somit eine falsche Zeit hat, muss die vom HMLAN kommen, solange in fhem keine set sysTime Aufrufe programmiert sind.
Fhem zeichnet somit nur diese time-requests auf, oder spielt es doch noch irgendwie dazwischen mit rum?
Zitat von: martinp876 am 31 Oktober 2014, 20:02:33
der rt (alle devices mit Uhr) fragen einmal täglich bei der Zentrale die Uhrzeit nach. Der log time-request wird dabei gesetzt.
Du kannst jederzeit die Uhrzeit noch einmal übertragen. Das geht mit "sysTime".
Es wird immer die Uhrzeit des Systems übertragen.
welches system hast du? Wie spät ist es dort?
Problematisch ist evtl sie Zeitzone. Wie ist die eingestellt? MEZ?
schicke ggf ein log, wenn du systime ausführst.
zentrale und system => fhem, server.
Zitat von: frank am 22 Januar 2015, 11:55:10
zentrale und system => fhem, server.
Wie? Also:
der rt (alle devices mit Uhr) fragen einmal täglich bei
FHEM die Uhrzeit nach. Der log time-request wird dabei gesetzt.
Du kannst jederzeit die Uhrzeit noch einmal übertragen. Das geht mit "sysTime".
Es wird immer die Uhrzeit des
FHEM-Systems übertragen.
Würde jetzt aber mit der Aussage von martinp876 kollidieren, der schrieb
ZitatMuss man wohl regelmassig die zeit an den hmlan sende. Sein quarz ist sehr ungenau - moeglich, dass es garkeiner ist.
Wenn die TCs von FHEM die Uhrzeit bekommen, was braucht dann der HMLAN eine korrekte Uhrzeit?
elsif($mTp eq "3F" && $ioId eq $dst) { # Timestamp request
my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
push @ack,$shash,"${mNo}803F$ioId${src}0204$s2000";
push @evtEt,[$shash,1,"time-request"];
}das sollte der entsprechende code von cul_hm zum handling des tc-it sein.
ZitatWenn die TCs von FHEM die Uhrzeit bekommen, was braucht dann der HMLAN eine korrekte Uhrzeit?
diese frage enttäuscht mich nun aber. hast du den thread nicht gelesen? :o
es steht die
these im raum, dass der hmlan eine eigene zeit hat, und diese
eventuell eigenständig verteilt.
Zitat von: frank am 22 Januar 2015, 12:42:14
elsif($mTp eq "3F" && $ioId eq $dst) { # Timestamp request
my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
push @ack,$shash,"${mNo}803F$ioId${src}0204$s2000";
push @evtEt,[$shash,1,"time-request"];
}
das sollte der entsprechende code von cul_hm zum handling des tc-it sein.
Japp. Ich hab die Code Stellen mal mit einer Log Message instrumentiert, mal sehen ob der Code bei HMLAN überhaupt ausgeführt wird.
ZitatJapp. Ich hab die Code Stellen mal mit einer Log Message instrumentiert, mal sehen ob der Code bei HMLAN überhaupt ausgeführt wird.
du kannst auch über "attr <meinHMLAN> logIDs <meinTC>" beim hmlan, die zu loggenden rawmessages einstellen. dabei sieht man auch den timerequest.
das interessante wären aber "eigenständige" funksprüche des hmlan. also nicht von fhem ausgehend. diese werden dann wahrscheinlich nur durch ein zweites io, das nur am lauschen ist, wahrgenommen. vielleicht sogar idealerweise ein cul, der kein eq3-eigenleben führt.
Ich kann mal einen CUL 24h mitloggen lassen, wenn jemand anderes sich durch den Datenwust wühlen will?!
Zitat von: strauch am 22 Januar 2015, 15:25:24
Ich kann mal einen CUL 24h mitloggen lassen, wenn jemand anderes sich durch den Datenwust wühlen will?!
am besten mit verbose4 beim cul und anschliessend nach messages mit der hmid vom tc durchstöbern.
Zitat von: frank am 22 Januar 2015, 15:33:37
am besten mit verbose4 beim cul und anschliessend nach messages mit der hmid vom tc durchstöbern.
Ich werde das heute Abend mal starten und die passagen mit der ID eines tc hier posten. ok? Reichen 24h oder lieber mehr.
Zitatok? Reichen 24h oder lieber mehr.
du kannst ja erstmal 24h posten und trotzdem weiterlaufen lassen, falls nichts enthalten ist. wie gesagt, wäre es vielleicht sinnvoll, die systemzeit von fhem während des tests zu verstellen. dann läuft aber wahrscheinlich das grosse chaos bei dir. ;D
Ne das werde ich mir erstmal verkneifen ;-). Zumal die Zeit vom debian automatisch synchronisiert.
Zitat von: frank am 22 Januar 2015, 12:42:14
elsif($mTp eq "3F" && $ioId eq $dst) { # Timestamp request
my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
push @ack,$shash,"${mNo}803F$ioId${src}0204$s2000";
push @evtEt,[$shash,1,"time-request"];
}
das sollte der entsprechende code von cul_hm zum handling des tc-it sein.
diese frage enttäuscht mich nun aber. hast du den thread nicht gelesen? :o
es steht die these im raum, dass der hmlan eine eigene zeit hat, und diese eventuell eigenständig verteilt.
Klar habe ich den Thread gelesen, aber wohl die Thesen nicht als solche erkannt :-)
Bei mir ist übrigens die letzten Tage die richtige Zeit zu sehen. Ich habe aber auch vorgestern FHEM ein paar Mal neu gestartet, da ich mit dem Floorplan gebastelt habe. Wird also wohl dann der Neustart-Effekt sein.
Bist du dir denn sicher das FHEM eine korrekte Uhrzeit hatte?
Mein logging läuft, ich hab einen HM-TC-IT-WM-W-EU solo laufen, also ohne Thermostate, da dürfte sich die uninteressante Kommunikation in Grenzen halten.
Jetzt suche ich noch eine Möglichkeiten alle Zeilen die eine bestime Zahlenkombi beinhalten oder eben nicht kopieren oder löschen zu können. Vermutlich geht das am ehesten mit VI. Vielleicht hat jemand einen Tipp?
ZitatJetzt suche ich noch eine Möglichkeiten alle Zeilen die eine bestime Zahlenkombi beinhalten oder eben nicht kopieren oder löschen zu können. Vermutlich geht das am ehesten mit VI. Vielleicht hat jemand einen Tipp?
als windows-user kann ich nur raten: eventuell geht was mit grep?
Ich hab auch Windows und OSX. Aber du hast recht. grep ist eine sehr gute Idee, das sollte klappen.
Also der Code in CUL_HM wird definitiv ausgeführt, was mich jetzt doch irgendwie wundert. Wenn ich autonomes Zeit-Handling in einer Firmware implementieren würde, dann würde ich aber auch dafür sorgen dass die Anfragen nicht mehr durchgereicht werden. Bin auf die Ergebnisse vom Logging gespannt.
Ich musste gerade paar mals mein FHEM Server neustarten, das dürfte ein paar getconfig anfragen im Log nach sich ziehen... hoffe das bringt nichts durcheinander, müsst eich mal 24h die Finger von allem lassen ;-).
Hier gibt es schonmal einen Teil.... weiß überhaupt jemand wonach zu suchen ist?
Zitat2015.01.23 19:04:17.821 4: CUL_Parse: CUL_0 A 09 02 A03F 2B0AEC F11134 4C -36
2015.01.23 19:04:17.950 4: CUL_Parse: CUL_0 A 0F 02 803F F11134 2B0AEC 02041C553B920C -68
2015.01.23 19:04:18.223 4: CUL_Parse: CUL_0 A 0F 02 803F F11134 2B0AEC 02041C553B910E -67
das ist der entscheidende abschnitt. 2B0AEC (TC) sendet mit befehl A03F an F11134 (Zentrale) den time-request. daraufhin gibt es 2 antworten 803F. die zeit in sec seit 2000 ist blau dargestellt.
nach meinem verständnis unterscheiden sich die zeiten um eine sekunde. warum sollte fhem also 2 mal antworten mit 2 unterschiedlichen zeiten? ich würde sagen eine antwort ist vom hmlan direkt, die andere von fhem. auch seltsam, dass die spätere antwort eine sekunde weniger hat. und beide antworten haben trotzdem die selbe msgnummer 02.
für den nächsten test kannst du ruhig verbose=4 beim cul machen. jetzt wäre ein test mit geänderter systemzeit fällig, um das zu bestätigen. auch eine logzeile in cul_hm, die den sekundenwert ins log schreibt wäre sinnvoll. etwa so:
elsif($mTp eq "3F" && $ioId eq $dst) { # Timestamp request
my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
push @ack,$shash,"${mNo}803F$ioId${src}0204$s2000";
push @evtEt,[$shash,1,"time-request"];
####################################################
Log 1,"----- time-request----- sekunden: $s2000";
####################################################
}
Soll ich parallel auf dem haupsystem mitloggen man müsste ja den Unterschied sehen. Zeit verstellen will ich nicht unbedingt machen.
Gesendet von meinem Nexus 4 mit Tapatalk
kann nicht schaden. die logzeile für cul_hm wäre noch besser.
attr mein_hmlan logIDs mein_tc
Zitat von: strauch am 23 Januar 2015, 23:55:27
Zeit verstellen will ich nicht unbedingt machen.
Weniger invasiv und mit gleichem Lern-Effekt wäre das Einfügen der Zeile "return 0x11223344;" nach "sub CUL_HM_secSince2000() {". Sollte eigentlich auch keine weitere Nebenwirkungen haben.
@marvel und Frank euren code wurde ich im system das mitloggt einfügen. An welche Stelle?
Gesendet von meinem Nexus 4 mit Tapatalk
Zitat@marvel und Frank euren code wurde ich im system das mitloggt einfügen. An welche Stelle?
der entsprechende elsif-block ist ca in zeile 1474. marvel meint ja eine fake zeit zu senden. das könnte man ja auch in diesem block tun, hat dann auch weniger auswirkungen:
elsif($mTp eq "3F" && $ioId eq $dst) { # Timestamp request
####################################################
# my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
my $s2000 = sprintf("%02X", (CUL_HM_secSince2000() - 3600));
####################################################
push @ack,$shash,"${mNo}803F$ioId${src}0204$s2000";
push @evtEt,[$shash,1,"time-request"];
####################################################
Log 1,"----- time-request----- sekunden: $s2000";
####################################################
}also die eine zeile zur berechnung der sekunden ändern. die subtraktion mit 3600 sollte die zeit um eine stunde zurücksetzen. und den fhem.log-eintrag einfügen.
Auch das schau ich mir noch mal heute Abend in Ruhe an. Und werde dann noch mal loggen.
Zitat von: frank am 24 Januar 2015, 12:11:52
der entsprechende elsif-block ist ca in zeile 1474. marvel meint ja eine fake zeit zu senden. das könnte man ja auch in diesem block tun, hat dann auch weniger auswirkungen:
Ich weiß zwar nicht wer Marvel ist ;), aber solange man den partyMode nicht nutzt hat meine Änderung auch kaum mehr Auswirkungen. Egal, kann man so oder so machen.
Zitat von: strauch@marvel und Frank euren code wurde ich im system das mitloggt einfügen. An welche Stelle?
Ich antworte mal für Marvel: es bringt leider nichts das mitloggende System zu ändern. Die Änderung müsste schon am produktiven System erfolgen. Schlimmstenfalls geht dann der WM ne Stunde falsch, mehr passiert bei Franks Änderung defintitiv nicht. Da man am alten Log gesehen hat dass ein Sync um 19:04 passiert würde es evtl jetzt sogar reichen von 18:45 bis 19:15 zu loggen.
Grüße, Marcel
Danke, vielleicht lerne ich einen TC am Produktivsystem ab und lerne ihn an mein Testsystem an. Am Produktivsystem ist mir der eingriff zu Massiv, zumal ich ja auch die automatische Zeitanpassung im System abschalten muss.
Würde es vielleicht auch reichen die Uhrzeit am TC zu verstellen, statt am System?
Es sollte keinerlei Auswirkungen am System haben. Welche Zeitanpassung musst Du abschalten? Ausser dem gezeigten Code nichts am System ändern! System-Zeit muss mit dieser Version richtig bleiben!
Im Prinzip bewirkt die Änderung dass FHEM eine bewusst falsche Zeit sendet (und zwar NUR an die TC, nicht an die anderen Komponenten). Der ganze Grund für den Thread ist aber ja, dass die Zeit von FHEM bisher immer komplett ignoriert wurde. Insofern erwarte ich wirklich nicht dass es irgendeine Auswirkung hat, ausser dass das Log eindeutiger ausfällt. Worst case ist dass der TC danach ne Stunde falsch läuft, aber wie gesagt, der Grund für den Thread ist ja dass eben kein Zeit-Sync zwischen FHEM und TC erfolgt.
Würde es ja selbst machen, aber nach meinem Umzug ist der größte Teil der Heizungs-Steuerung noch verpackt... erst am WE könnte ich evtl mal was machen.
ZitatAm Produktivsystem ist mir der eingriff zu Massiv, zumal ich ja auch die automatische Zeitanpassung im System abschalten muss.
du brauchst nichts abschalten. nur die kleine änderung in cul_hm einfügen. dann bekommen deine tc von fhem nur eine falsche zeit übermittelt (aktuelle systemzeit minus 1 std). alles andere läuft wie bisher. wahrscheinlich werden die tc noch nicht einmal verstellt, wie dieser thread ja gezeigt hat, da der hmlan weiterhin seine zeit verteilt. die bleibt ja unangetastet und setzt sich ja anscheinend durch.
ZitatWürde es vielleicht auch reichen die Uhrzeit am TC zu verstellen, statt am System?
nee. wie gesagt du stellst erstmal keine zeit um. dafür die kleine änderung in cul_hm. wir simulieren sozusagen eine falsche systemzeit.
edit: da war ich wohl zu langsam, trotzdem hier noch mal. :(
ok hab ich gerafft. Ich werds heute Abend umsetzten. Ich hoffe ich schaffe das vor 19 Uhr :-) und mitloggen.
Zitat von: frank am 24 Januar 2015, 12:11:52
elsif($mTp eq "3F" && $ioId eq $dst) { # Timestamp request
####################################################
# my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
my $s2000 = sprintf("%02X", (CUL_HM_secSince2000() - 3600));
####################################################
push @ack,$shash,"${mNo}803F$ioId${src}0204$s2000";
push @evtEt,[$shash,1,"time-request"];
####################################################
Log 1,"----- time-request----- sekunden: $s2000";
####################################################
}
Also diese Zeilen habe ich eingefügt und werde ich tauschen+neustart, sobald der Rechner zum mitloggen läuft.
Ich hab die LogIDs auf dem Produktivsystem auf die ID des TC gestellt. Soll ich da auch Verbose auf 5 stellen für das Gerät? Oder reicht normal?
Auf dem System zum mitloggen, werde ich vom CUL Verbose auf 4 reduzieren (Habs auf 5 wegen dem Displaytaster an dem ich parallel rumfurwerke ;-).)
Ich schau das ich den ab heute mittag mitloggen lasse und dann heute Abend wenn alle kleinen im Bett sind werde ich das Ergebnis mal checken und posten.
Hab ich irgendwas vergessen?
ZitatAlso diese Zeilen habe ich eingefügt
nicht den ganzen block einfügen. der ist ja schon vorhanden. nur die änderungen. oder den ganzen elsif-block tauschen.
ZitatSoll ich da auch Verbose auf 5 stellen für das Gerät? Oder reicht normal?
ist nicht notwendig.
Zitatwerde ich vom CUL Verbose auf 4 reduzieren (Habs auf 5 wegen dem Displaytaster an dem ich parallel rumfurwerke ;-).)
wie du willst. für diesen test reicht 4.
Ich hab nur die notwendigen Zeilen hinzugefügt. Er loggt jetzt. Hoffe hab alles richtig gemacht. Ergebnis gibt es dann heute Abend.... Soll ich dann mit grep auch die Zeilen mit A03F und 803F ausfiltern?
ZitatSoll ich dann mit grep auch die Zeilen mit A03F und 803F ausfiltern?
besser du suchst so die relevanten zeitpunkte, und postest dann alles, was um diese zeitpunkte herum geloggt wurde. sonst geht vielleicht etwas wichtiges verloren.
Bisher noch keine Zeitumstellung, mal schauen wie es heute Abend ausschaut.
Mhpf bisher immer noch nichts.... Uhrzeit ist auch noch richtig.
Zitat von: strauch am 27 Januar 2015, 20:07:04
Mhpf bisher immer noch nichts.... Uhrzeit ist auch noch richtig.
Ok, dass sich die Uhrzeit nicht verändert hab ich ja
vorhergesagt. Aber es wird auch nichts im Log eingetragen? Was sagt denn das FHEM LogFile, irgendwelche Fehler?
Grüsse, Marcel
Oh da ist doch schon was ich hab immer nach A803 gesucht und nix gefunden. Hier die beiden Logs vom CUL und vom HMLAN/FHEM selber.
Also eigentlich isses recht einfach zu finden. In fhemlog.txt:
Zitat2015.01.26 15:20:21.533 1: ----- time-request----- sekunden: 1C58ED85
Und wenn man im RAW-Log bei 15:20:21 schaut sieht man das hier:
Zitat2015.01.26 15:20:21.661 4: CUL_Parse: CUL_0 A 09 05 A03F 2B0AEC F11134 02 -73
2015.01.26 15:20:21.789 4: CUL_Parse: CUL_0 A 0F 05 803F F11134 2B0AEC 02041C58FB9608 -70
2015.01.26 15:20:22.063 4: CUL_Parse: CUL_0 A 0F 05 803F F11134 2B0AEC 02041C58ED8508 -70
0x1C58FB96 - 0x1C58ED85 = 3601, das sind genau die 3600 Abstand, die wir eingebaut haben.
D.h. der HMLAN antwortet innerhalb 128ms und FHEM erst nach 402ms. FHEMs Antwort wird dann wohl verworfen, weil für das Device kein Request mehr offen ist. Das ist definitiv eine interessante Erkentnis, danke für Deine Bemühungen! Weiß nur noch nicht ganz was die Moral der Geschichte ist ;)
2015.01.26 15:20:21.531 0: HMLAN_Parse: HMLAN1 R:E2B0AEC stat:0000 t:04C57CF2 d:FF r:FFA8 m:05 A03F 2B0AEC F11134
2015.01.26 15:20:21.533 1: ----- time-request----- sekunden: 1C58ED85
2015.01.26 15:20:21.628 0: HMLAN_Send: HMLAN1 S:+2B0AEC,00,01,00
2015.01.26 15:20:21.628 0: HMLAN_Send: HMLAN1 S:S269D5BE8 stat: 00 t:00000000 d:01 r:269D5BE8 m:05 803F F11134 2B0AEC 02041C58ED85
2015.01.26 15:20:21.655 0: HMLAN_Parse: HMLAN1 R:E2B0AEC stat:0000 t:04C57CF2 d:FF r:FFA8 m:05 A03F 2B0AEC F11134
2015.01.26 15:20:21.929 0: HMLAN_Parse: HMLAN1 R:R269D5BE8 stat:0002 t:00000000 d:FF r:7FFF m:05 803F F11134 2B0AEC 02041C58ED85
2015.01.26 15:20:21.661 4: CUL_Parse: CUL_0 A 09 05 A03F 2B0AEC F11134 02 -73
2015.01.26 15:20:21.789 4: CUL_Parse: CUL_0 A 0F 05 803F F11134 2B0AEC 02041C58FB9608 -70
2015.01.26 15:20:22.063 4: CUL_Parse: CUL_0 A 0F 05 803F F11134 2B0AEC 02041C58ED8508 -70
#####################################################################################################################################
2015.01.27 14:05:43.000 0: HMLAN_Parse: HMLAN1 R:E2B0AEC stat:0000 t:09A7AAC5 d:FF r:FFB9 m:06 A03F 2B0AEC F11134
2015.01.27 14:05:43.001 1: ----- time-request----- sekunden: 1C5A2D87
2015.01.27 14:05:43.095 0: HMLAN_Send: HMLAN1 S:S2B7F61A4 stat: 00 t:00000000 d:01 r:2B7F61A4 m:06 803F F11134 2B0AEC 02041C5A2D87
2015.01.27 14:05:43.123 0: HMLAN_Parse: HMLAN1 R:E2B0AEC stat:0000 t:09A7AAC5 d:FF r:FFB9 m:06 A03F 2B0AEC F11134
2015.01.27 14:05:43.397 0: HMLAN_Parse: HMLAN1 R:R2B7F61A4 stat:0002 t:00000000 d:FF r:7FFF m:06 803F F11134 2B0AEC 02041C5A2D87
2015.01.27 14:05:43.831 4: CUL_Parse: CUL_0 A 09 06 A03F 2B0AEC F11134 47 -38.5
2015.01.27 14:05:43.960 4: CUL_Parse: CUL_0 A 0F 06 803F F11134 2B0AEC 02041C5A3BA109 -69.5
2015.01.27 14:05:44.233 4: CUL_Parse: CUL_0 A 0F 06 803F F11134 2B0AEC 02041C5A2D870A -69
da hast du den rabauken ja überführt. 8)
fhem wird vom hmlan nicht informiert und sendet heimlich seine eigene zeit, wie der cul zeigt. interessant ist ja, dass nach dem cul.log die hmlan zeit jedes mal zuerst gesendet wird, aber der tc trotzdem die hmlan zeit anzeigt (sagtest du doch?). demnach wird die 2. message gar nicht mehr vom tc angenommen/verabeitet. da ist die ganze prozedur von fhem irgendwie überflüssig. entweder ist er schon wieder eingeschlafen, oder wegen der selben msg-nummer kommt sie nicht durch. da sollte man das senden der zeit wohl verschieben.
interessant finde ich auch die vorstellung was passiert, wenn mehrere hmlan im system sind.
gruss frank
Schön das ich helfen konnte.
Interessant wäre wie es an einer CCU ist und vorallem auch der Verkehr von der CCU zum HMLAN. Woher bekommt der gute seine Zeit?!
Der TC hat bei mir immer die richtige Zeit angezeigt. Also keine Stunde versetzt. (3600s)
Zitat von: strauch am 27 Januar 2015, 23:57:41
Interessant wäre wie es an einer CCU ist und vorallem auch der Verkehr von der CCU zum HMLAN. Woher bekommt der gute seine Zeit?!
FHEM sendet die aktuelle Zeit einmal beim Connect, denke das wird ne CCU ähnlich handhaben. Evtl macht sie's auch periodisch nochmal um das Problem dieses Threads zu umschiffen.
das device fragt idR einmal täglich nach der Uhrzeit. Das sollte auch eine CCU beantworten.
Zitat von: martinp876 am 31 Januar 2015, 11:33:12
das device fragt idR einmal täglich nach der Uhrzeit. Das sollte auch eine CCU beantworten.
Es ging in dem Fall um einen HMLAN an der CCU. Da der HMLAN, wie wir hier herausgefunden haben, autonom die Zeit-Requests beantwortet ist es auch interessant ob und wie die CCU damit umgeht.
Garnicht. Die ccu setzt die zeit im hmlan. Den rest macht das hmlan, was sollte eine ccu sonst tun...
Martin, wir schreiben hier seit 7 Seiten rum weil Installationen mit HMLAN unter FHEM nach einer Zeit-Umstellung tagelang die falsche Zeit in den Devices haben. Die Frage ob die CCU das gleiche Problem hat oder eventuell regelmäßig den HMLAN mit einer aktuellen Zeit versorgt (die HMLAN Uhr triftet unter Umständen ja auch recht heftig) ist ja wohl so uninteressant nicht.
Als Entwickler startest Du dein FHEM vermutlich so oft neu dass Du von diesem Problem natürlich nie betroffen bist, Anwender mit einem System, dass in der Regel einfach läuft, aber sehr wohl.
dann ist der test einfach. ist das Problem nach einem HMLAN neustart erledigt?
Test auf was? Dass ein HMLAN Neustart hilft ist hier schon in epischer Breite geschrieben worden
ok, dann ist die Lösung wohl, dass wir zyklich die Uhrzeit an das HMLAN senden. baue ich ein, einmal täglich sollte reichen, hoffe ich
Danke Dir. Einmal am Tag wäre ok. Wenn Du es noch schaffst dieses einmal am Tag zwischen 3 und 4 Uhr morgens zu machen wär's perfekt, wenn nicht ist es aber auch nicht sonderlich wild
wäre doch eigentlich sinnvoller, die fhem zeit möglichst kurz nach dem request des tc zu senden. also nicht als antwort, sondern beim nächsten aufwachen, so dass eine eventuell falsch vergebene zeit vom hmlan möglichst direkt geändert wird. sonst gibt es zuhause 2 zeitzonen. ;)
Naja, an sich will man die Zeit einfach möglichst kurz nach der Zeitumstellung schicken. Angenommen man macht das jeden Morgen um 3:00 Uhr, dann hat jeder TC der sich die Zeit an diesem Tag holt danach die korrekte Zeit. Wenn Du nun (Extremfall) nur einen TC hast und der sich die Zeit z.B. um 19 Uhr holt, dann würde er nach Deiner Methode erst um 19 Uhr am Folgetag die neue Zeit haben. Sie hätte aber im Schnitt tatsächlich Vorteile gegenüber einem zufälligen 24-Stunden Rythmus.
Dadurch dass sich die TCs die Zeit zu nicht-deterministischen Tageszeiten holen können hat man immer das Problem von zwei unterschiedlichen Zeitzonen. Dies könnte man nur lösen indem man allen Devices explizit nach einer Umstellung ein SysTime schickt (erst nachdem der HMLAN neu parametriert wurde, natürlich).
ZitatWenn Du nun (Extremfall) nur einen TC hast und der sich die Zeit z.B. um 19 Uhr holt, dann würde er nach Deiner Methode erst um 19 Uhr am Folgetag die neue Zeit haben.
ich meinte nicht einen tag warten, sondern das zeitsetzen beim nächsten aufwachen des tc senden. in deinem beispiel also 19.00 + 2,5 min.
OK, das könnte man theoretisch machen. Vom Standpunkt der Software Architektur gefällt es mir weniger, da dadurch zwei Ebenen gemischt werden (CUL_HM und HMLAN) und CUL_HM möglichst I/O agnostisch sein sollte. Aber möglich wär's natürlich.
Ein tägliches Update für die zwei Mal im Jahr wenn die Zeit umgestellt wird würde für mich auch reichen, aber besser geht natürlich immer ;)
ZitatVom Standpunkt der Software Architektur gefällt es mir weniger, da dadurch zwei Ebenen gemischt werden (CUL_HM und HMLAN) und CUL_HM möglichst I/O agnostisch sein sollte.
na dann mal den netzverkehr zwischen hmlan und ccu sniffen, um das setzen der zeit des hmlan durch die ccu zu entdecken.
Zitat von: frank am 01 Februar 2015, 15:23:16
na dann mal den netzverkehr zwischen hmlan und ccu sniffen, um das setzen der zeit des hmlan durch die ccu zu entdecken.
Wenn jemand ne CCU hat wäre das sicher interessant, aber persönlich halte ich das Problem nicht für so gross um da noch mehr Zeit zu versenken. Hab auch kein CCU ;)
die Zeit sollte jetzt so alle 10h gesetzt werden. Möglich, dass bei sommerzeitumstellung ein Problem auftritt - das mache ich nicht besonders. aber nach 10h sollte alles klar sein