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

Begonnen von locodriver, 19 Oktober 2014, 15:18:37

Vorheriges Thema - Nächstes Thema

frank

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.  ;)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MarcelK

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

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MarcelK

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 ;)

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MarcelK


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 ;)

martinp876

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