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

[strauch]

Mhpf bisher immer noch nichts.... Uhrzeit ist auch noch richtig.

[MarcelK]

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

[strauch]

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.

[MarcelK]

Also eigentlich isses recht einfach zu finden. In fhemlog.txt:

2015.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:

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

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

[frank]

Code Auswählen Erweitern

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. 

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

[strauch]

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)

[MarcelK]

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.

[martinp876]

das device fragt idR einmal täglich nach der Uhrzeit. Das sollte auch eine CCU beantworten.

[MarcelK]

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.

[martinp876]

Garnicht. Die ccu setzt die zeit im hmlan. Den rest macht das hmlan, was sollte eine ccu sonst tun...

[MarcelK]

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.

[martinp876]

dann ist der test einfach. ist das Problem nach einem HMLAN neustart erledigt?

[MarcelK]

Test auf was? Dass ein HMLAN Neustart hilft ist hier schon in epischer Breite geschrieben worden

[martinp876]

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

[MarcelK]

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