HM-CC-RT-DN mit LaCrosse virtuelle Temperatur Sensoren hat Aussetzer

[Merlin]

So, hab jetzt auch mal ein wenig Protokolle gesnifft und dabei einen RT erwischt der fast eine Stunde lang nicht funktionierte und dann plötzlich, ohne erkennbaren Grund wieder auf externen Sensor umschaltet.
Hier der entsprechende RAW Log der eigentlich nichts zeigt:

2015.12.16 18:57:51.306 4: CUL_Parse: endor.cul1 A 0F 58 8610 3B02A8 000000 0AB8F10F35003B -44.5 <--- RT meldet 24.1 von intern obwohl es nur 22.4 extern hat

2015.12.16 18:59:13.355 3: CUL_HM set vt_ez_ts virtTemp 22.4 <--- der AT schreibt die aktuelle externe Temp neu
2015.12.16 18:59:36.299 5: CUL_HM vt_ez_ts m:19 ->20 t:1450288776.29674->1450288922.54674  M:1450288776.29945 :146.25
2015.12.16 18:59:36.332 5: CUL_HM vt_ez protEvent:CMDs_pending pending:1
2015.12.16 18:59:36.334 4: CUL_send:  endor.cul1As 0B 14 8670 BF0003 000000 00E0 <--- Es werden die 22.4 übertragen
2015.12.16 18:59:36.371 5: CUL_HM vt_ez protEvent:CMDs_done

2015.12.16 19:00:22.303 4: CUL_Parse: endor.cul1 A 0F 59 8610 3B02A8 000000 0AB8F10F35003C -44 <--- RT meldet 1 Minute später trotzdem wieder 24.1

das ging gut 50 Minuten lang so. Dann plötzlich unten in der Üertragung kein Unterschied aber der RT meldet die richtige Temp vom externen Sensor

2015.12.16 19:02:02.552 5: CUL_HM vt_ez_ts m:20 ->21 t:1450288922.54945->1450289054.29945  M:1450288922.55195 :131.75
2015.12.16 19:02:02.585 5: CUL_HM vt_ez protEvent:CMDs_pending pending:1
2015.12.16 19:02:02.587 4: CUL_send:  endor.cul1As 0B 15 8670 BF0003 000000 00E0 <--- Übertrage 22.4
2015.12.16 19:02:02.631 5: CUL_HM vt_ez protEvent:CMDs_done

2015.12.16 19:02:38.800 4: CUL_Parse: endor.cul1 A 0F 5A 8610 3B02A8 000000 0A60E00F00003B -44.5 <-- plötzlich sind die richtigen Werte wieder da...

2015.12.16 19:04:14.304 5: CUL_HM vt_ez_ts m:21 ->22 t:1450289054.30195->1450289235.80195  M:1450289054.30415 :181.5
2015.12.16 19:04:14.337 5: CUL_HM vt_ez protEvent:CMDs_pending pending:1
2015.12.16 19:04:14.339 4: CUL_send:  endor.cul1As 0B 16 8670 BF0003 000000 00E0
2015.12.16 19:04:14.382 5: CUL_HM vt_ez protEvent:CMDs_done

2015.12.16 19:04:41.067 4: CUL_Parse: endor.cul1 A 0F 5B 8610 3B02A8 000000 0A60E00F00003A -45


Ich verstehs nicht ....
Was mir total schleierhaft ist: Das Timing! Wann wird dieser externe Sensorwert übertragen? Der RT schläft doch zwischendurch. Sollte diese Übertragung nicht direkt im Anschluß an einen Statusreport vom Rt erfolgen?

[Hollo]

...Wann erfolgt die Übertragung der Temperatur aus dem virtuellen Device zum RT?
...Wer kann hier aufklären?

Das ist eine gute Frage.
Wenn man den Ablauf richtig versteht, bringt das vielleicht auch Hinweise zum Problem.
Wie oft muss man den virtuellen Sensor aktualisieren bzw. gibt es beim Timing zwischen Thermostat und virtuellem Sensor etwas zu beachten?

[martinp876]

Der update kommt alle 2.5min plus minus 30sec. Das muss schwanken und wird nach komplexem algo errechnet

[Merlin]

Der update kommt alle 2.5min plus minus 30sec. Das muss schwanken und wird nach komplexem algo errechnet

Der Update vom RT? Ja klar. Aber auch vom externen Sensor? Wann antwortet die Zentrale mit der externen Sensortemperatur? Meine bescheidene Erkenntnis dazu ist:

Bei einer normalen Änderung zb der Solltemperatur im fhem geht der status auf CMD pending aber es wird nicht sofort etwas gesendet. Erst wenn der nächste Status Broadcast vom RT empfangen wurde antwortet die Zentrale mir dem Kommando, und zwar adressiert an genau den RT. Logisch und funktioniert auch.

Bei virtuellen temperatursensoren wird einfach alle ca 2,5 Min ein Broadcast generiert und sofort gesendet. Unabhängig davon ob der zu erreichende RT nicht gerade schläft. Wieso wartet der nicht auch auf das Wakeup vom RT? Wie kann das überhaupt klappen?

Schaut mal hier:Statusmeldung vom RT und Broadcast vom dazugehörigen externen Sensor. Ganz unterschiedliche Zeiten. Wie können die überhaupt zusammenfinden???

2015.12.16 18:35:02.828 4: CUL_Parse: endor.cul1 A 0F 4F 8610 3B02A8 000000 0AB8F00F350038 -46
2015.12.16 18:36:24.541 4: CUL_send:  endor.cul1As 0B 0B 8670 BF0003 000000 00DE
2015.12.16 18:37:37.874 4: CUL_Parse: endor.cul1 A 0F 50 8610 3B02A8 000000 0AB8F00F350036 -47
2015.12.16 18:38:52.544 4: CUL_send:  endor.cul1As 0B 0C 8670 BF0003 000000 00DE
2015.12.16 18:39:54.072 4: CUL_Parse: endor.cul1 A 0F 51 8610 3B02A8 000000 0AB8F00F350038 -46
2015.12.16 18:41:06.309 4: CUL_send:  endor.cul1As 0B 0D 8670 BF0003 000000 00DE
2015.12.16 18:41:58.070 4: CUL_Parse: endor.cul1 A 0F 52 8610 3B02A8 000000 0AB8F00F350036 -47
2015.12.16 18:44:09.550 4: CUL_send:  endor.cul1As 0B 0E 8670 BF0003 000000 00DE
2015.12.16 18:44:51.568 4: CUL_Parse: endor.cul1 A 0F 53 8610 3B02A8 000000 0AB8F00F350036 -47
2015.12.16 18:46:58.315 4: CUL_send:  endor.cul1As 0B 0F 8670 BF0003 000000 00DE

Wo habe ich hier den Denk/Verständnisfehler?
Bitte um Aufklärung.

[Merlin]

Hallo,

also ich finds echt schade das hier keine Antworten kommen. Ich erwarte keine fertige Lösung, sondern will ja sogar selber suchen. Nur ohne ein paar Hintergrundinfos ist das unmöglich. Für jemanden der sich schon intensiv mit dem Modul beschäftigt hat oder gar den Entwickler sollte es doch ein leichtes sein meine Fragen zu beantworten...

Eine Frage zu der Kommunikation zwischen den Teilen:

Wann erfolgt die Übertragung der Temperatur aus dem virtuellen Device zum RT?

Der RT wacht ja alle 2-3 Min auf und postet eine Statusnachricht. Wartet der CUL darauf und antwortet mit der aktuellen Temperatur? Oder kommt durch das peering mit einem externen Sensor aktiv eine Anfrage vom RT oder dessen Wetterkanal an das Device nach der aktuellen Temperatur? Oder geht das ganz anders?
Wer kann hier aufklären?

Bei einer normalen Änderung zb der Solltemperatur im fhem geht der status auf CMD pending aber es wird nicht sofort etwas gesendet. Erst wenn der nächste Status Broadcast vom RT empfangen wurde antwortet die Zentrale mir dem Kommando, und zwar adressiert an genau den RT. Logisch und funktioniert auch.

Bei virtuellen temperatursensoren wird einfach alle ca 2,5 Min ein Broadcast generiert und sofort gesendet. Unabhängig davon ob der zu erreichende RT nicht gerade schläft. Wieso wartet der nicht auch auf das Wakeup vom RT? Wie kann das überhaupt klappen?

[Gerd]

Ich würde es auch gut finden wenn es hier mit fachkundiger Hilfe weiter gehen könnte, den so ist es eigentlich nicht nutzbar und anscheinend hat ja jeder dieses Problem.
Bei mir treten diese Verbindungsprobleme sporadisch auf und verschwinden mal nach einer gewissen Zeit.
Es hat sich ja auch noch keiner gemeldet bei dem das ohne Probleme funktioniert.

Mir kommt es so vor als wenn der RT wenn er mal den Wert vom externen Sensor nicht bekommt sofort auf den internen Sensor umschaltet. Ich habe auch beobachtet das während 1 RT den externen Sensor nicht erkennt , andere ohne Probleme laufen.
Gibt es so ein Problem auch mit den HM Wandthermostaten ?
Wenn nicht dann muss es am virtuellen Sensor liegen, oder ?

[JoeALLb]

Bei mir tritt das Problem übrigens auch auf. Kann jemand vergleichen, ob ein  Wandtermostat andere Intervalle sendet?

[Merlin]

Kann ich also davon ausgehen das dieses Problem niemanden (der zur Lösung beitragen könnte) ernsthaft interessiert?

[Gerd]

Leider scheint das so zu sein. 
Ich würde auch einen Wandthermostaten kaufen wenn es zur Lösung beiträgt. Aber mein Wissen um das analysieren des Homematic Protokolls ist leider zu gering als wenn ich da wirklich was raus bekommen würde.

Ich hoffe das sich vielleicht irgendwer mit dem Fachwissen meldet um der Problematik mal auf den Grund zu gehen, wenn nicht empfehle ich den Wikieintrag um die Verwendung anderer Temperatursensoren zu löscchen da es irre führend ist wenn es nirgends reibungslos funktioniert.

[deckelsmouk]

Ich habe leider auch das gleiche Problem mit der gleichen Konfiguration wie beschrieben und so wie es aussieht gibt es keine richtige Lösung für diese spontanen
Aussetzer mit der Kommunikation zwischen virtuellem Temperatursensor und dem HM-CC-RT-DN (3x Lacrosse auf 3x HM-CC-RT-DN gepeert).
Ich habe auch ein Heizkörperthermostat HM-CC-RT-DN mit einem Innentemperatursensor HM-WDS40-TH-I-2 gepeert und dies funktionnier zu 100%.
Ebenfalls habe ich ein Heizkörperthermostat HM-CC-RT-DN mit einem Wandthermostat HM-TC-IT-WM-W-EU gepeert und dies funktionnier auch zu 100%.
So wie es aussieht bleibt nur der Weg über die teuren Homematic-Thermostate und nicht die billige Variante mit LaCrossesensoren, schade 

[Gerd]

Ich habe auch ein Heizkörperthermostat HM-CC-RT-DN mit einem Innentemperatursensor HM-WDS40-TH-I-2 gepeert und dies funktionnier zu 100%.
Ebenfalls habe ich ein Heizkörperthermostat HM-CC-RT-DN mit einem Wandthermostat HM-TC-IT-WM-W-EU gepeert und dies funktionnier auch zu 100%.

Das ist doch aber mal eine Aussage, jetzt müsste man nur raus bekommen was die Sensoren anders machen als das Virtuelle Device das mit dem HM-CC-RT-DN gepeert wird.

[Merlin]

Das ist doch aber mal eine Aussage, jetzt müsste man nur raus bekommen was die Sensoren anders machen als das Virtuelle Device das mit dem HM-CC-RT-DN gepeert wird.

Ich hab hier sogar schon einen Verdacht.
Das Ärgerlich an der Sache ist halt das ich schon gut 30-50 Stunden an Zeit mit Aufbau einer Testumgebung, einlesen in einen völlig fremden und unbekannten Sourcecode usw verbracht habe und noch immer in der Forschungsphase bin für Fragen die vom Entwickler oder jemanden der den Code kennt in 5 Minuten beantwortet wären.
Trotzdem denke ich es gibt noch Hoffnung.

[martinp876]

Wo ist das Problem?
Wenn man einen externen Sensor nutzt um die temp an den virtuellen Sensor zu schicken und der virtuelle Sensor schließlich die temp an den realen aktor uebermittelt sollte das timing identisch sein. Kann man testen. Wenn es mit dem rein virtuellen Sensor klappt, klappt es auch wie oben.
Wenn damit dem virtuellen nicht klappt ist es auch für die Entwickler eine entsprechend lange Untersuchung.

Also: klappt schritt 1?

[Merlin]

Wo ist das Problem?
Wenn man einen externen Sensor nutzt um die temp an den virtuellen Sensor zu schicken und der virtuelle Sensor schließlich die temp an den realen aktor uebermittelt sollte das timing identisch sein. Kann man testen. Wenn es mit dem rein virtuellen Sensor klappt, klappt es auch wie oben.
Wenn damit dem virtuellen nicht klappt ist es auch für die Entwickler eine entsprechend lange Untersuchung.

Also: klappt schritt 1?

Ok ich versuchs nochmal:
Der viruelle Sensor wird mit Temp Daten befüllt. Mittels at ,notifiy, von mir aus auch per Hand. Wüsste nicht wo ich hier ein timing Problem haben könnte, denn die Daten sind ja dann im virtuellen Device vorhanden.
Aber:
Das virtuelle Device sendet dann seine Temp Daten an den RT weiter. Und zwar alle 2,5-3 min aber halt irgendwann, und in keiner Abhängigkeit davon wann die Daten eintreffen(zb eben alle 2 Min per at). Unabhängig davon ob der empfangende RT gerade wach ist oder nicht. Somit geht diese Übertragung vermutlich oftmals ins Leere.
Hierzu habe ich weiter oben auch schon Logs gepostet.

Meine Vorstellung wie es sein könnte/sollte: (Bitte um Korrektur wenn ich das System falsch verstanden habe)
Der RT wacht alle 2,5 bis 3 min auf und sendet seinen Statusbericht. Genau dann, nach Empfang dieser Statusnachricht, sollte die Übertragung der Temp Sensor Daten erfolgen. Genau so wie es zb bei einer Übertragung der Solltemperatur oder eine Zeitliste passiert wenn man ohne Burst schickt und die Zentrale die Nachricht aufhebt bis der nächste Statusbericht eintrifft und dann sendet.

Wäre es nicht möglich die Übertragung an oben beschriebene Logik anzupassen?

Kann ich irgendwie weiter was zu Lösung betragen? Tests, Logs , usw? Falls ja bitte um Info.

Danke

[martinp876]

Klar geht das ins leere. Der virtuelle aktor macht das timing.
Du Schreiber in den virtuellen aktor. Wenn die Zeit gekommen ist, schreibt der in den RT.
Das timing ist asynchron - und kann nicht geändert werden.
Wenn der Sensor sendetkann es bis zu 3min dauern, bis es beim RT ist.
Wo ist das Problem?
Die Zeit wird  nach einem algo errechnet. Der algo kommt von eq3.
Lass es einfach so arbeiten. Rechnen musst du nichts. Eigentlich doch einfach.

Das senden des RT status hat nichts mit den Wetterdaten zu tun.