Uhrzeit verstellt sich bei HM-CC-RT-DN

[touscd]

Guten Abend,

Ich habe ein vergleichbares Problem wie hier beschrieben: viewtopic.php?f=27&t=34111&start=20

Im Detail:

Es sind 3 HM-CC-RT-DN (Firmware 1.4) verbaut und an eine CCU2 angelernt. Irgendwann, leider nicht mehr nachvollziehbar, während der Nicht-Heizphase muss "etwas" passiert sein.
Zz. habe ich den Effekt, dass im Laufe des Tages die Uhrzeit der Regler von dem richtigen Wert auf (vermutlich) 00:00 springt; die falschen Zeiten sind unterscheiden sich nicht nur bei den Stunden, sondern auch in den Minuten. Vermutlich deshalb, weil ich das natürlich nie direkt beobachtet habe und weil die Zeiten, die ich dann später entdecke im kleineren Bereich (< 6 Uhr) sind.
Der Regler selbst, verhält sich dann korrekt, in dem er die für den Zeitpunkt programmierte Temperatur einstellt. Leider führt das dazu, dass schon mal abends um 22:00 Realzeit ordentlich geheizt wird (beim Regler ist es dann 5:00 morgens) oder morgens um 5:30 das Bad kalt ist, weil der Regler meint es sei erst 2 Uhr nachts.
Ich kann im WebUI die Temperatur des Reglers manuell verstellen, kann auch eine Änderung der Programmierung machen und diese übertragen - die Uhrzeit ändert sich dadurch nicht (was wohl auch normal ist).
Einzig durch Übernehmen der aktuellen Uhrzeit aus dem Rechner oder NTP Server über die WebUI wird eine neue Übertragung der korrekten Zeit eingeleitet (wahrscheinlich auch normal).
Die falsche Uhrzeit auf den Regler ist übrigens auf allen dreien identisch, d.h. ich gehe davon aus, dass die CCU2 irgendwann mal als neue Uhrzeit 00:00 rumschickt.
Soweit ich das verstanden habe, synced die CCU2 ja auch einmal täglich die Uhrzeit auf allen angeschlossenen Gerätschaften. Die CCU2 zeigt übrigens immer die richtige Zeit an.

Im oben angegebenen Thread war die Lösung die (damals) aktuelle Firmware auf die CCU2 zu spielen. Ich habe die Version 2.29.18 draufgehabt, als ich das Problem entdeckte. Update auf 2.29.23 brachte keine Änderung.
Ich hatte auch einmal im Februar ein Backup als "alles läuft" gekennzeichnet und dieses sogar mit der damalig bei mir im Einsatz befindlichen 2.25.15 wieder zurückgespielt - keine Besserung.

Da ich jetzt allmählich wahnsinnig werde, der ganzen Familie morgens kalt ist, Forderung nach einem einfachen Heimeier-Ventil immer lauter werden (klappt im Bad gut: Abends voll aufdrehen, morgens kommt die Heizungsanlage aus der Nachtabsenkung, schon wird es warm und der letzte im Bad dreht das Ventil zu - wozu braucht man schon ein smartes Home ), frage ich nach HILFE!!

Was ich als nächste ausprobieren würde, wäre, da ich fast schon einen Hardware-Defekt der CCU2 vermute, RaspberryMatic oder FHEM auf einem unterbeschäftigten Pi zu installieren.

Oder hat jemand eine rettende Idee??

Danke für Lesen schon mal und schönen Gruß

Tousc

[touscd]

Niemand mit einer Idee, woran es liegen könnte?

[Bratmaxe]

Nein leider keine Idee,
du könntest mal die Uhrzeit loggen und mal gucken, ob diese irgendwann plötzlich auf 0Uhr springt. Dann hättest du zumindest die Ursache.

Als test könntest du auch einen anderen Zeitserver in den Einstellungen eintragen.

[Xel66]

Nach meiner Erinnerung, fragt die CCU regelmäßig externe Zeitserver ab und stellt die eigene Uhr dementsprechend. Mir ist aber schon mal aufgefallen, dass die Linuxuhr und die Zeitanzeige im Webinterface unterschiedliche Uhrzeiten aufwiesen. Und hier meine ich nicht den Unterscheid UTC/ME(S)Z. Vielleicht läuft eine der Uhren bei Dir falsch und gerade auf diese syncen sich die Thermostate. Es gab diesbezüglich auch schon mal einen Thread, in dem der Cron-Job für den externen Zeitsync editiert (verkürzt) wurde und das Problem m.W. damit verschwand. EDIT: gefunden

Gruß Xel66

[touscd]

Als Zeitserver hab ich schon einige ausprobiert - nützt nix.
Die Zeit im Web-Interface ist auch richtig, nur die Thermostate kriegen, wie ich inzwischen rausgefunden habe, mehrmals täglich als Datum + Uhrzeit, den 1.1.2000 00:00 übertragen. Irgendwann kommt auch wieder die korrekte Zeit. Der Thermostat schaltet nach seinem Programm korrekt - nur verläuft die Zeit nicht-linear und zuweilen mit Rücksprung (ich habe eine ZEITMASCHINE! Mir war auch grad 17 Jahre jünger...)

@Bratmaxe: Wie kann man die Uhr der CCU loggen?

[Familienvater]

Hi,

ich glaube zwar nicht wirklich daran, das die Rega-Version was damit zu tun hat, aber welche Version der Rega ist bei Dir Aktiv? Legacy, Standard, oder Community?

Soweit ich das verstanden habe, wird aus der Crontab um 4:14 das folgende gemacht:

Code: Alles auswählen

14 4 * * * /bin/SetInterfaceClock 127.0.0.1:2001

2 Minuten vorher ist eigentlich ein Aufruf, um die "Hardware-Uhr" zu stellen

Code: Alles auswählen

12 4 * * * /bin/setHWClock.sh

Ich weiß nicht, wie oft (out-of-the-Box) die Uhrzeit per ntp-Client vom ntp-Server geholt wird, ich habe bei mir die crontab modifziert/erweitert, so das stündlich ein "einmaliger" ntpclient-Aufruf die Zeit mit meinem ntp-Server im lokalen Netz abgleicht, und durch weiteres "Pimpen" im Dateisystem wird auch ein Drift-File geschrieben.

Wieder zurück:
Durch das SetInterfaceClock wird dem rfd die "aktuelle" Uhrzeit mitgeteilt, und der rfd verteilt die Uhrzeit ca. alle 6h, das kann man ggf. im Syslog "sehen":

Code: Alles auswählen

Nov 20 04:29:27 ccu2 multimac: Bidcos RX: #4C[BC|WOR|Ren] 164DA3->000000 TimeInfo: 02 02 21 A5 08 96
Nov 20 04:29:27 ccu2 multimac: A<: #233 HmBidcos RxTelegram AuthNone #4C[BC|WOR|Ren] 164DA3->000000 TimeInfo: 0

Das ist ein "Broadcast" (->000000), der mit WakeOnRadio ausgesendet wird, bitte keine Frage zum Unterschied WakeOnRadio und Burst (ist IIRC in einem ELV-Journal beschrieben).

Ich habe jetzt gerade mal noch im Log einer anderen CCU im Haus geschaut:

Code: Alles auswählen

Nov 24 10:05:47 rccu multimac: Bidcos RX: #62[BC|WOR|Ren] 164DA3->000000 TimeInfo: 02 02 21 AA 9D 62
Nov 24 10:05:47 rccu multimac: A<: #253 HmBidcos RxTelegram AuthNone #62[BC|WOR|Ren] 164DA3->000000 TimeInfo: 02 02 21 AA 9D 62
Nov 24 10:07:09 rccu multimac: Bidcos RX: #66[BC|WOR|Ren] 164DA3->000000 TimeInfo: 02 02 21 AA 9D B5
Nov 24 10:07:09 rccu multimac: A<: #79 HmBidcos RxTelegram AuthNone #66[BC|WOR|Ren] 164DA3->000000 TimeInfo: 02 02 21 AA 9D B5
Nov 24 10:18:46 rccu multimac: Bidcos RX: #8C[BC|WOR|Ren] 164DA3->000000 TimeInfo: 02 02 21 AA A0 76
Nov 24 10:18:46 rccu multimac: A<: #85 HmBidcos RxTelegram AuthNone #8C[BC|WOR|Ren] 164DA3->000000 TimeInfo: 02 02 21 AA A0 76

Da die TimeInfo von einer "fremden" CCU 3x Empfangen wird, senden auch die 2 Lan-Rf-Gateways in meinem Haus jeder für sich die Info aus.

Aus den paar Hexzahl hintendran müsste man wahrscheinlich relativ einfach die Sekunden? nach dem 1.1.1970 00:00 (?) rausbekommen, und könnte so ggf. auch noch schauen, ob da eine falsche Uhrzeit verfunkt wird.

Der Familienvater

[touscd]

Guten Morgen!

Nach langem Rumprobieren und Experimentieren ist der Verursacher der Probleme gefunden. Es war das Funk-LAN-Gateway.
Sobald dieses eingeschaltet war, wurde reproduzierbar immer wieder Datum/Uhrzeit der Thermostaten auf 1.1.2000/0:00 gesetzt - war es aus, war der Fehler weg.

Etwas lästig war, dass bei der Fehlersuche immer eine Wartezeit von 12-18 Stunden nötig war, da die Uhrzeit wohl ca. alle 6 Stunden verteilt wurde und das nicht immer nicht klappte.

Warum und wie das Teil jetzt diesen Effekt verursacht hat, habe ich nicht rausbekommen - sei's drum. Eine neues Gateway ist auf dem Weg und dann hoff ich mal, dass dann der Fehler nicht wieder auftritt.

Ich danke allen, die sich hier mit dem Thema befasst und Tipps gegeben haben!

Schöne Weihnachtszeit noch!

Touscd