Falsche Zeit am HM-TC-IT-WM-W-EU

[Claus]

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

[frank]

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

[Claus]

Danke frank!
Dann wäre es doch ganz nett wenn die Zeit im Display des TC stimmt 
VG
Claus

[strauch]

Hast du den HM LAN mal stromlos gemacht und dann geschaut? (Dauert vermutlich etwas)

[TomWest]

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?

[Cruiser79]

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

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.

[strauch]

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.

[MarcelK]

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

[frank]

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.

[MarcelK]

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?

[Cruiser79]

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?

[frank]

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.

[Cruiser79]

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

Muss 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?

[frank]

Code Auswählen Erweitern

    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.

Wenn 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?   

es steht die these im raum, dass der hmlan eine eigene zeit hat, und diese eventuell eigenständig verteilt.

[MarcelK]

Code Auswählen Erweitern

    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.