HMUARTLGW: Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway

[mcfly71]

Guten Tag zusammen,

da ich jetzt gesehen habe, dass noch einige diesen Thread lesen, und direkt geantwortet haben, gehe ich davon aus, dass meine Frage zu dumm war oder zu schwer, oder dass niemand solche Phänomene hat.... richtig ?

Wenn dem der Fall ist, so close ich mein device und benutze es nur noch für firmware updates...

Oder habe ich beim aufsetzen meiner Nachricht was falsch gemacht ?!


VG
mcfly

[ph1959de]

Bei Dir ging es um die "Attack"-Meldungen?

Dazu fällt mir spontan nur ein: VCCU ist definiert? Das neue I/O hast Du der VCCU zugefügt?

[Otto123]

Guten Tag zusammen,

da ich jetzt gesehen habe, dass noch einige diesen Thread lesen, und direkt geantwortet haben, gehe ich davon aus, dass meine Frage zu dumm war oder zu schwer, oder dass niemand solche Phänomene hat.... richtig ?

Wenn dem der Fall ist, so close ich mein device und benutze es nur noch für firmware updates...

Oder habe ich beim aufsetzen meiner Nachricht was falsch gemacht ?!


VG
mcfly

Hi,

also Du hast nix falsch gemacht. 
Ich habe Deine Frage gelesen und verstanden. Habe aber null Idee was diese attack Meldungen auslösen kann. Normalerweise kommen die wenn man einen weiteren IO mit anderer HMID betreibt.

Gruß Otto

[mcfly71]

Hallo ph1959de und Otto,

Hi,

also Du hast nix falsch gemacht. 
Ich habe Deine Frage gelesen und verstanden. Habe aber null Idee was diese attack Meldungen auslösen kann. Normalerweise kommen die wenn man einen weiteren IO mit anderer HMID betreibt.

Gruß Otto

Bei Dir ging es um die "Attack"-Meldungen?

Dazu fällt mir spontan nur ein: VCCU ist definiert? Das neue I/O hast Du der VCCU zugefügt?

Danke erstmal für die Rückmeldungen. Ich habe eine VCCU und durch den state:
STATE     STEUERUNG_HM:ok,STEUERUNG_HM_2:ok,STEUERUNG_HM_3:ok

gehe ich mal davon aus, dass alles rechtens ist.
Ich experimentiere nochwas....
Trotzdem schonmal Danke für eure Meldungen...

VG

[frank]

ich hatte letztens auch eine attack meldung. allerdings denke ich nicht, dass bei mir der hmuart schuld ist, denn sonst würde ich die meldungen ja sicherlich reproduzierbar und regelmässig erhalten.
der hmuart ist prefered io bei diesem device und mit den beiden anderen io's ebenfalls mit einer vccu assigned.

Code Auswählen Erweitern

2017.01.10 19:18:46.667 0: HMUARTLGW hmuart1 recv: 01 04 03 00 53 msg: 03 80 02 1DFDA5 1ACE1F 00
2017.01.10 19:18:46.678 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:B99EAC6B d:FF r:FFC6     m:03 8002 1DFDA5 1ACE1F 00
2017.01.10 19:18:46.701 0: HMLAN_Parse: hmusb1 R:E1DFDA5   stat:0000 t:59BDFDD6 d:FF r:FFC9     m:03 8002 1DFDA5 1ACE1F 00
2017.01.10 19:18:46.764 0: HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 04 A0 01 1ACE1F 1DFDA5 02050000000005
2017.01.10 19:18:46.822 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:B99EACFB d:FF r:FFBA     m:04 A001 1ACE1F 1DFDA5 02050000000005
2017.01.10 19:18:46.826 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:59BDFE65 d:FF r:FFB0     m:04 A001 1ACE1F 1DFDA5 02050000000005
2017.01.10 19:18:46.939 0: HMUARTLGW hmuart1 recv: 01 04 03 00 54 msg: 04 80 02 1DFDA5 1ACE1F 00
2017.01.10 19:18:46.950 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:B99EAD7B d:FF r:FFC6     m:04 8002 1DFDA5 1ACE1F 00
2017.01.10 19:18:46.954 0: HMLAN_Parse: hmusb1 R:E1DFDA5   stat:0000 t:59BDFEE5 d:FF r:FFC9     m:04 8002 1DFDA5 1ACE1F 00
2017.01.10 19:18:47.036 0: HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 05 A0 01 1ACE1F 1DFDA5 02080110
2017.01.10 19:18:47.090 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:B99EAE08 d:FF r:FFBB     m:05 A001 1ACE1F 1DFDA5 02080110
2017.01.10 19:18:47.091 2: CUL_HM Thermostat.SZ attack:011ACE1F1DFDA50206,011ACE1F1DFDA502050000000005:11ACE1F1DFDA502080110
2017.01.10 19:18:47.147 1: ------ ATTACK-ALARM ----- Thermostat.SZ(1DFDA5) sabotageAttack_ErrIoAttack cnt: 1
2017.01.10 19:18:47.150 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:59BDFF73 d:FF r:FFB0     m:05 A001 1ACE1F 1DFDA5 02080110
2017.01.10 19:18:47.151 2: CUL_HM Thermostat.SZ attack:011ACE1F1DFDA50206,011ACE1F1DFDA502050000000005:11ACE1F1DFDA502080110
2017.01.10 19:18:47.210 0: HMUARTLGW hmuart1 recv: 01 04 03 00 54 msg: 05 80 02 1DFDA5 1ACE1F 00
2017.01.10 19:18:47.221 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:B99EAE8B d:FF r:FFC6     m:05 8002 1DFDA5 1ACE1F 00
2017.01.10 19:18:47.246 0: HMLAN_Parse: hmusb1 R:E1DFDA5   stat:0000 t:59BDFFF5 d:FF r:FFC9     m:05 8002 1DFDA5 1ACE1F 00
2017.01.10 19:18:47.307 0: HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 06 A0 01 1ACE1F 1DFDA5 0206
2017.01.10 19:18:47.361 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:B99EAF17 d:FF r:FFBA     m:06 A001 1ACE1F 1DFDA5 0206
2017.01.10 19:18:47.370 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:59BE0080 d:FF r:FFB0     m:06 A001 1ACE1F 1DFDA5 0206
2017.01.10 19:18:47.482 0: HMUARTLGW hmuart1 recv: 01 04 03 00 53 msg: 06 80 02 1DFDA5 1ACE1F 00
2017.01.10 19:18:47.493 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:B99EAF9B d:FF r:FFC6     m:06 8002 1DFDA5 1ACE1F 00
2017.01.10 19:18:47.498 0: HMLAN_Parse: hmusb1 R:E1DFDA5   stat:0000 t:59BE0104 d:FF r:FFC9     m:06 8002 1DFDA5 1ACE1F 00
2017.01.10 19:18:47.579 0: HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 07 80 3F 1ACE1F 1DFDA5 02042007D3F4
2017.01.10 19:18:47.622 0: HMUARTLGW hmuart1 recv: 01 0402, state 101
2017.01.10 19:18:47.623 0: HMUARTLGW hmuart1 Ack: 02
2017.01.10 19:18:47.623 0: HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 08 A0 01 1ACE1F 1DFDA5 02050000000005
2017.01.10 19:18:47.637 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:B99EB02B d:FF r:FFBA     m:07 803F 1ACE1F 1DFDA5 02042007D3F4
2017.01.10 19:18:47.658 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:59BE0194 d:FF r:FFB0     m:07 803F 1ACE1F 1DFDA5 02042007D3F4
2017.01.10 19:18:47.779 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:B99EB0B9 d:FF r:FFBA     m:08 A001 1ACE1F 1DFDA5 02050000000005
2017.01.10 19:18:47.786 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:59BE0223 d:FF r:FFB0     m:08 A001 1ACE1F 1DFDA5 02050000000005


[mgernoth]

Hallo,

das hier sendet der HMUART:

Code Auswählen Erweitern


2017.01.10 19:18:46.764 0: HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 04 A0 01 1ACE1F 1DFDA5 02050000000005
2017.01.10 19:18:47.036 0: HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 05 A0 01 1ACE1F 1DFDA5 02080110


Das letzte Frame löst die Attack-Meldung aus:

Code Auswählen Erweitern


2017.01.10 19:18:47.151 2: CUL_HM Thermostat.SZ attack:011ACE1F1DFDA50206,011ACE1F1DFDA502050000000005:11ACE1F1DFDA502080110


Hier denkte CUL_HM, dass es nur "01 1ACE1F 1DFDA5 0206" (wohl vor dem Logausschnitt) und "01 1ACE1F 1DFDA5 02050000000005" gesendet hat, jetzt aber auf einmal ein "1ACE1F 1DFDA5 02080110" sieht (was es ja tatsächlich auch als letztes gesendet hat).

Ich nehme an, dass hier Martins Code irgendwie vergisst, sich manche gesendeten Nachrichten zu merken.

Am besten zu den Attack-Meldungen ein neues Topic mit entsprechenden Logs aufmachen, damit Martin das auch sieht. Das ist nicht IO-spezifisch.

Viele Grüße
  Michael

[frank]

Am besten zu den Attack-Meldungen ein neues Topic mit entsprechenden Logs aufmachen, damit Martin das auch sieht. Das ist nicht IO-spezifisch.

ok, hier gehts mit etwas mehr log weiter:  https://forum.fhem.de/index.php/topic,65019.0.html

[frank]

hallo michael,

kurz nach mitternacht fordern meine thermostate (hm-cc-tc) immer die aktuelle uhrzeit, um sich zu synchronisieren:

Code Auswählen Erweitern

2017.01.19 00:01:15.674 0: HMUARTLGW hmuart1 recv: 01 05 00 00 35 msg: B7 86 70 206278 000000 00B538
2017.01.19 00:01:15.685 0: HMLAN_Parse: hmlan1 R:E206278   stat:0000 t:0E8EBAD4 d:FF r:FFB6     m:B7 8670 206278 000000 00B538
2017.01.19 00:01:15.695 0: HMLAN_Parse: hmusb1 R:E206278   stat:0000 t:83F3570E d:FF r:FFB6     m:B7 8670 206278 000000 00B538
2017.01.19 00:01:15.871 0: HMUARTLGW hmuart1 recv: 01 05 01 00 35 msg: B8 A0 3F 206278 1ACE1F
2017.01.19 00:01:15.883 0: HMLAN_Parse: hmlan1 R:E206278   stat:0000 t:0E8EBB9A d:FF r:FFB6     m:B8 A03F 206278 1ACE1F
2017.01.19 00:01:15.887 0: HMLAN_Parse: hmusb1 R:E206278   stat:0000 t:83F357D4 d:FF r:FFB7     m:B8 A03F 206278 1ACE1F
2017.01.19 00:01:16.012 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:0E8EBC1B d:FF r:FFB7     m:B8 803F 1ACE1F 206278 02022012B06C  # 538095724s
2017.01.19 00:01:16.015 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:83F35855 d:FF r:FFB4     m:B8 803F 1ACE1F 206278 02022012B06C
2017.01.19 00:01:16.169 0: HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: B8 80 3F 1ACE1F 206278 02042012A22B
2017.01.19 00:01:16.213 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:0E8EBCE5 d:FF r:FFB7     m:B8 803F 1ACE1F 206278 02042012A22B  # 538092075s (dif: 3649s)
2017.01.19 00:01:16.242 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:83F3591F d:FF r:FFB4     m:B8 803F 1ACE1F 206278 02042012A22B

anscheinend macht der hmuart die synchronisierung zuerst von selbst und anschliessend noch einmal durch cul_hm initiert. ich denke, eine der beiden aktionen sollte man einsparen, zumal sich die übermittelten zeiten deutlich unterscheiden. vielleicht kannst du es dem hmuart "abgewöhnen"?

ausserdem gibt es einen kleinen unterschied beim 2. byte der payload. hmuart sendet hier 0x02 und cul_hm immer 0x04, egal zu welchem device. worin besteht hier wohl der unterschied?

könnte es sein, dass die zeit im hmuart falsch initiert wird? der unterschied von 3649 sekunden lässt mich vermuten, dass hier eventuell ein zeitzonenproblem existiert. zum testen habe ich die zeitfunktionen vom modul mal über die fhemeingabe ermittelt, wobei zwischen den einzelnen zeilen ein paar sekunden/minuten abstand gewesen sind. localtime war zu diesem zeitpunkt richtig:

Code Auswählen Erweitern

time() => 1484831479.53236
localtime(time()) => Thu Jan 19 14:14:04 2017
timegm(localtime(time())) => 1484835470
timelocal(localtime(time())) => 1484832016
(timegm(localtime(time()))-timelocal(localtime(time()))) => 3600
(timegm(localtime(time()))-timelocal(localtime(time())))/1800 => 2

die restlichen 49 sekunden sind dann wahrscheinlich seit dem letzten fhemstart vor knapp 9 tagen zusammen gekommen. fast 6 sekunden pro tag.

gruss frank

[sig10680]

Hallo,
warum wird eigentlich der LGW Lan Adapter zweimal angelegt? Der normale zb. HMLGW und ein HMLGW:keepAlive in dem Hidden Room?

Mfg Sig10680

Gesendet von meinem SM-G800F mit Tapatalk

[mgernoth]

Hallo,

kurz nach mitternacht fordern meine thermostate (hm-cc-tc) immer die aktuelle uhrzeit, um sich zu synchronisieren:

Code Auswählen Erweitern


2017.01.19 00:01:16.012 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:0E8EBC1B d:FF r:FFB7     m:B8 803F 1ACE1F 206278 02022012B06C  # 538095724s
2017.01.19 00:01:16.213 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:0E8EBCE5 d:FF r:FFB7     m:B8 803F 1ACE1F 206278 02042012A22B  # 538092075s (dif: 3649s)


anscheinend macht der hmuart die synchronisierung zuerst von selbst und anschliessend noch einmal durch cul_hm initiert. ich denke, eine der beiden aktionen sollte man einsparen, zumal sich die übermittelten zeiten deutlich unterscheiden. vielleicht kannst du es dem hmuart "abgewöhnen"?

Nein, das macht er selbsttätig. Ausserdem ist seine Zeit "richtiger" als die von CUL_HM.

ausserdem gibt es einen kleinen unterschied beim 2. byte der payload. hmuart sendet hier 0x02 und cul_hm immer 0x04, egal zu welchem device. worin besteht hier wohl der unterschied?

Das Byte gibt den aktuellen Offset in 30m zu UTC an. Bei CUL_HM sind es immer 2h (4), der HMUART bekommt den aktuellen Offset der Systemzeit zu UTC (im Augenblick 2, da Winterzeit) mitgeteilt. CUL_HM zieht dann intern fest 2h ab...

könnte es sein, dass die zeit im hmuart falsch initiert wird? der unterschied von 3649 sekunden lässt mich vermuten, dass hier eventuell ein zeitzonenproblem existiert.

Der HMUART bekommt einen Unix-Timestamp und den UTC-Offset und berechnet daraus dann die HM-Payload. Die aktuelle Zeit/Offset wird alle 2 Stunden im Modul gesetzt.

CUL_HM berechnet intern die Sekunden seit dem 1.1.2000, wobei ich mir nicht ganz sicher bin, ob das ganz korrekt ist.

die restlichen 49 sekunden sind dann wahrscheinlich seit dem letzten fhemstart vor knapp 9 tagen zusammen gekommen. fast 6 sekunden pro tag.

Nein, das ist der Unterschied in der Berechnung durch die Firmware des HMUART und der Berechnung durch CUL_HM_secSince2000().

warum wird eigentlich der LGW Lan Adapter zweimal angelegt? Der normale zb. HMLGW und ein HMLGW:keepAlive in dem Hidden Room?

Weil das LGW zwei TCP-Verbindungen braucht (eine für Daten, eine für KeepAlive) und DevIo in Fhem pro Verbindung ein eigenes Gerät benötigt.

Viele Grüße
  Michael

[frank]

Nein, das macht er selbsttätig. Ausserdem ist seine Zeit "richtiger" als die von CUL_HM.

umso ärgerlicher, dass die "richtige" zeit gleich wieder überschrieben wird.

Das Byte gibt den aktuellen Offset in 30m zu UTC an. Bei CUL_HM sind es immer 2h (4), der HMUART bekommt den aktuellen Offset der Systemzeit zu UTC (im Augenblick 2, da Winterzeit) mitgeteilt. CUL_HM zieht dann intern fest 2h ab...

Der HMUART bekommt einen Unix-Timestamp und den UTC-Offset und berechnet daraus dann die HM-Payload. Die aktuelle Zeit/Offset wird alle 2 Stunden im Modul gesetzt.

ok, der unterschiedliche offset "kompensiert" dann quasi den zeitunterschied im payload, bis auf die verbleibenden 49 sek.

dann sollte ich wohl martin überzeugen, das setzen der zeit bei den thermostaten je nach io-typ zu unterdrücken.
"bessere" zeit, weniger funklast, entlastung von cul_hm und eventuell weniger zeitumstellungs anomalien.

das lgw verhält sich gleichermassen?

gruss frank

[sig10680]

Weil das LGW zwei TCP-Verbindungen braucht (eine für Daten, eine für KeepAlive) und DevIo in Fhem pro Verbindung ein eigenes Gerät benötigt.

Viele Grüße
  Michael

Danke für die Antwort,
irgendwiesowas konnte ich mir fast denken.
Ich hatte nur gedacht/gehofft das man das irgenwie in ein Gerät basteln könnte!

mfg Sig10680

[mgernoth]

Hallo,

umso ärgerlicher, dass die "richtige" zeit gleich wieder überschrieben wird.
ok, der unterschiedliche offset "kompensiert" dann quasi den zeitunterschied im payload, bis auf die verbleibenden 49 sek.

Wobei sich bei mir beide Zeitstempel nur um 1s unterscheiden. Also wahrscheinlich driftet Dein Modul tatsächlich 49s innerhalb von 2h, sehr merkwürdig!

dann sollte ich wohl martin überzeugen, das setzen der zeit bei den thermostaten je nach io-typ zu unterdrücken.
"bessere" zeit, weniger funklast, entlastung von cul_hm und eventuell weniger zeitumstellungs anomalien.

Das würde ich auf keinen Fall machen, da es verschiedene Arten der Anfrage für Zeitstempel gibt und nicht unbedingt alle vom Modul direkt beantwortet werden. Wenn überhaupt sollte ich die Nachricht von CUL_HM in HMUARTLGW verwerfen.

Ein Empfänger sollte übrigens die erste Antwort nehmen und die zweite verwerfen.
Zur Funklast: Die ist minimal, auch bei vielen Thermostaten. Die Firmware sendet die Zeit übrigens auch immer mal wieder per Broadcast an 000000.

Ich hatte nur gedacht/gehofft das man das irgenwie in ein Gerät basteln könnte!

Warum? Was ist das Problem mit dem temporären versteckten Gerät?
Jede HTTP-Verbindung zu FHEMWEB erzeugt übrigens genau so ein (sehr kurzlebiges) Gerät.

Viele Grüße
  Michael

[frank]

Zur Funklast: Die ist minimal, auch bei vielen Thermostaten.

mir geht es in erster linie um eine "saubere" kommunikation mit diesen thermostaten, die marginal geringere funklast hatte ich in diesem zusammenhang nur als zusätzlichen vorteil mit aufgeführt.

vorgeschichte:
ganz selten kommt es vor, dass diese thermostate in einem "seltsamen" zustand sind. dabei ist das display wie ausgeschaltet, kein pixel wird dargestellt. nur durch kurzzeitiges entfernen der batterie (reboot) kann dieser zustand beendet werden. die weatherevents kommen aber weiterhin regelmässig und in fhem ist eigentlich nichts auffälliges zu bemerken. seit sommer kommunizieren sie nun über den hmuart und der zustand ist seitdem vielleicht 3-5 mal bei unterschiedlichen devices aufgetreten.

vor über 2 jahren waren sie mit einem hmlan assigned, der ab und zu ausgerechnet bei dieser automatischen zeitsynchronisierung rebootet wurde. siehe hier: https://forum.fhem.de/index.php/topic,22509.0.html. der spuk hörte erst auf, als die kommunikation über einen hmusb lief.
mit dem cul als monitor konnte ich damals keine selbstständigen zeitframes vom hmlan erkennen, obwohl das log bereits anzeichen dafür enthielt. der hmlan sendet wohl aber doch selbstständig, wie das log von heute zeigt. das wird dann vermutlich die ursache der reboots gewesen sein. allerdings hatte der hmlan damals fw0.961 und heute 0.965.

Code Auswählen Erweitern

2017.01.21 00:02:17.768 0: HMUARTLGW hmuart1 recv: 01 05 00 00 32 msg: 26 A0 3F 206278 1ACE1F
2017.01.21 00:02:17.871 0: HMLAN_Send:  hmlan1 S:SBE1DC104 stat:  00 t:00000000 d:01 r:BE1DC104 m:26 803F 1ACE1F 206278 020420154569
2017.01.21 00:02:17.874 0: HMLAN_Parse: hmlan1 R:E206278   stat:0000 t:18DCC000 d:FF r:FFB4     m:26 A03F 206278 1ACE1F
2017.01.21 00:02:17.877 0: HMLAN_Parse: hmusb1 R:E206278   stat:0000 t:8E40F81D d:FF r:FFB6     m:26 A03F 206278 1ACE1F
2017.01.21 00:02:17.898 0: HMUARTLGW hmuart1 recv: 01 05 00 00 44 msg: 26 80 3F 1ACE1F 206278 02042015456B
2017.01.21 00:02:17.901 0: HMLAN_Parse: hmlan1 R:E206278   stat:0000 t:18DCC000 d:FF r:FFB4     m:26 A03F 206278 1ACE1F
2017.01.21 00:02:17.918 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:8E40F89D d:FF r:FFE3     m:26 803F 1ACE1F 206278 02042015456B
2017.01.21 00:02:18.168 0: HMUARTLGW hmuart1 recv: 01 05 00 00 44 msg: 26 80 3F 1ACE1F 206278 020420154569
2017.01.21 00:02:18.172 0: HMLAN_Parse: hmlan1 R:RBE1DC104 stat:0002 t:00000000 d:FF r:7FFF     m:26 803F 1ACE1F 206278 020420154569
2017.01.21 00:02:18.206 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:8E40F9AC d:FF r:FFE4     m:26 803F 1ACE1F 206278 020420154569

Wenn überhaupt sollte ich die Nachricht von CUL_HM in HMUARTLGW verwerfen.

daran wäre ich interressiert, eventuell über attribut schaltbar.
ich kann leider nicht sagen, ob es das display-phänomen schon vor der hmuart-zeit gab. da die fw der thermostate aber auch sonst nicht wirklich überzeugt, hatte ich nun die hoffnung, dass diese 2 unterschiedlichen messages zur zeitsynchronisierung unter bestimmten umständen eventuell der auslöser sein könnten. zudem solche messages einen hmlan zum rebooten bringen können.

Wobei sich bei mir beide Zeitstempel nur um 1s unterscheiden. Also wahrscheinlich driftet Dein Modul tatsächlich 49s innerhalb von 2h, sehr merkwürdig!

ich betreibe den hmuart auf einem pi3 bei 1200MHz.
in der folgenden nacht waren es ebenfalls 49s. um ca 16:00 uhr 7s und gegen 19:00 uhr 22s. jeweils nach einem reboot des thermostats angefordert. ich werde wohl mal nach dem aktualisieren der zeit beim hmuart schauen.

gruss frank

[LuckyDay]

vorgeschichte:
ganz selten kommt es vor, dass diese thermostate in einem "seltsamen" zustand sind. dabei ist das display wie ausgeschaltet, kein pixel wird dargestellt. nur durch kurzzeitiges entfernen der batterie (reboot) kann dieser zustand beendet werden. die weatherevents kommen aber weiterhin regelmässig und in fhem ist eigentlich nichts auffälliges zu bemerken. seit sommer kommunizieren sie nun über den hmuart und der zustand ist seitdem vielleicht 3-5 mal bei unterschiedlichen devices aufgetreten.

Das Problem kenne ich auch mit dem leeren Display bei den HM-CC-TC
tritt bei mir auf , wenn der Cubi oder BananaPI neu startet und Fhem mit der Uhrzeit von 2010 ,
dann kommt neue Uhrzeit über ntp, und die Timers holen alle Schaltzustände nach.

das sieht dann so aus

Code Auswählen Erweitern

2016.12.25 20:45:07.391 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.425 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.459 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.485 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.519 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.694 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.724 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.758 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.793 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.828 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.862 3: CUL_HM set eg_Halle_Hz1 statusRequest
2016.12.25 20:45:07.904 3: CUL_HM set eg_Halle_Hz1 statusRequest
...... fortlaufend

das war es dann mit dem Display