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

[vbs]

So wie ich es verstanden habe, kennen sich die beiden ausschließlich über den gemeinsamen Algorithmus zur Berechnung des nächsten Sendezeitpunkts. Der TC sendet einfach nur plump zyklisch die Temperatur ab. Irgendwann (durch Zufall) ist der RT gerade mal auf Empfang und sieht die Nachricht und kann dann berechnen, wann die nächste Nachricht gesendet werden wird und geht zu dem Zeitpunkt wieder auf Empfang usw.
Der Punkt ist, dass beide Seiten die Berechnung des nächsten Sendezeitpunkts identisch durchführen.

[CBSnake]

hmm ok der TC ist ja auch mit Batterie, da kann ich das nachvollziehen, das Virtuelle Device muss ja nicht schlafen, könnte also abwarten bis der RT sich meldet und dann die Temperatur durchgeben.
Naja evtl meldet sich ja mal jemand zu Wort der mehr Einblick/Hintergrundwissen in das entsprechende Modul hat

[vbs]

Könnte bitte mal jemand (oder gern mehrere), der ein TC gepeert mit RT hat, die Nachrichten, die dieser zyklisch schickt für so 5-6 Stunden loggen und mir schicken? Ich würde gerne mal die Zeitintervalle nachrechnen gegen die Implementierung in FHEM und in Asksin.
Sollte ungefähr so aussehen:

Code Auswählen Erweitern

2017.01.26 22:12:52.919 0: HMLAN_Parse: HMLAN0 R:E306FC5   stat:0000 t:6359CC19 d:FF r:FFC4     m:27 8470 306FC5 000000 00AD25

Ihr müsstet nur gucken, welche HMID euer TC hat (in meinem Fall "306FC5") und dann sollten das immer die Nachrichten sein, die hinten die "8470" (nach dem "m:") haben. Außerdem bitte das Attribut mseclog bei global setzen, damit ms-genau geloggt wird.

@CBSnake
Guck dir mal die Funktion CUL_HM_valvePosUpdt in 10_CUL_HM an.

[Fredi69]

Könnte bitte mal jemand (oder gern mehrere), der ein TC gepeert mit RT hat, die Nachrichten, die dieser zyklisch schickt für so 5-6 Stunden loggen und mir schicken?

Wie erstelle ich ein Log von dem Virtual Device?

[vbs]

Im Prinzip wie hier beschrieben:
https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen

[plombe]

Hallo,

Die Berechnung des Zeitfensters wurde hier beschrieben:

https://forum.fhem.de/index.php/topic,17485.msg130378.html#msg130378

oder in 10_CUL_HM.pm nachschauen.

[vbs]

Hab noch eine Kleinigkeit gefunden: Die originalen TCs senden immer 0x84 als Control-Byte, CUL_HM sendet aber 0x86. Unterschied ist das gesetzte WAKEMEUP-Flag. Keine Ahnung, ob das was mit unserem Problem zu tun haben könnte, aber ich denke schlechter machts das nicht. Vielleicht mag das mal jemand testen (im Anhang) und berichten ob es was ändert. Ich lass es hier bei mir auch gerade laufen...

Achso: FHEM muss neu gestartet werden nach dem Einspielen des Files. Nur ein reload auf das File reicht zumindest nicht.

[vbs]

Hier mal eine Variante, bei der man über ein Attribut selbst einen zeitlichen Offset für den Versand der Nachricht einstellen kann. Damit kann man also mal versuchen, zB. 1 Sekunde drauf zu addieren wie von Linef vorgeschlagen.
Das Attribut heißt "cyclicMsgOffset" und wird in ms direkt im Channel gesetzt. Also zB "1000" für eine Sekunde. Können auch negative Werte sein.
Vielleicht mag jemand auch mal damit rumspielen.

[vbs]

Sorry, da ist was schief gelaufen. Hier nochmal im Anhang...

[vbs]

Beim RT wird der Abstand zum nächsten Zeitfenster aufgrund der Messagenummer und der Device-ID des TC berechnet und liegt irgendwo zwischen 2 und 3 Minuten. Das Zeitfenster ist dann für ca. 10 Sek. "offen". Dieses muß der TC mit seinem Sendeversuch treffen. Der RT synchronisiert sich dann daran wieder.

Ist das Zeitfenster wirklich ca. 10 Sek offen? Ich hab hier eine Seite gefunden, wo das Verhalten beschrieben wird (unter "Timing"):
https://homegear.eu/index.php/BidCoS_Packet_-_General_Information
Da ist von einem 250ms-Fenster die Rede, welches vergrößert wird, wenn Nachrichten verpasst werden. Muss natürlich auch nicht stimmen. Wäre aber super, wenn man an der Stelle an gesicherte Informationen kommen würde.

Wenn der Sender exakt zu Beginn des Zeitfensters sendet, kann es kritisch werden, falls die Quarze der beiden Devices nicht exakt stimmen. Ist dann der vom TC schneller, so sendet er, noch bevor der RT auf Empfang ist. Das ist mir z.B. bei einem virtuellen Sensor in fhem so passiert - der RT schaltete immer wieder auf seinen internen Messfühler.

Ich sende deshalb bei meinen Sensoren (Abwandlung von Dirks Universalsensor) 1 Sek. später und treffe damit das Fenster.

Ich hätte erwartet, dass der RT den erwarteten Sendezeitpunkt in die Mitte seines Empfangsfenster legt, so dass zu beiden Seiten ein Puffer besteht. D.h. bei einem 10 Sek. Fenster hätte man zu beiden Seiten 5 Sek Toleranz. Ist das wirklich denkbar, dass die beiden Quarze so dermaßen unterschiedlichen laufen, dass sich da innerhalb von 2,5 Minuten ein Versatz von >5 Sek zwischen den beiden ergibt?

[frank]

Ich hab hier eine Seite gefunden, wo das Verhalten beschrieben wird (unter "Timing"):

das ist das erwähnte timing vom cc-vd.

funktioniert es denn nun bei dir?

[fhainz]

Bei mir läuft es seit 14:00 Uhr, mit cyclicMsgOffset auf 1000, ohne Aussetzer. Solange hat das schon lange nicht mehr funktioniert 
Sieht gut aus!

[vbs]

Also vorweg: Ich denke es geht. Zumindest wesentlich stabiler als vorher.

Es ist nicht so ganz einfach herauszufinden, wie stabil der RT die Temperatur empfängt. Wenn man nur beobachtet, ob er auf die interne Temp zurückfällt oder nicht, dann sieht man nur ob er ungefähr 5 Nachrichten am Stück nicht empfangen. Wenn man nun einen Zustand hat, dass er zB nur jede 4. Nachricht sieht, dann wirkt es zwar stabil, da er nicht auf die interne Temp zurückfällt, jedoch erhöht er sehr oft sein Empfangsfenster, was permanent zu erhöhtem Batterieverbrauch führt.

Anderer Ansatz: Ich hab CUL_HM so umgebaut, dass er immer eine "gefakte" Temperatur zwischen 30°C und 40°C sendet, die er nach jeder Nachricht um 0.5°C erhöht. Sprich: Jede verschickte Nachricht enthält eine andere Temperatur. Anhand der zyklisch gemeldeten measure-temp des RT kann man dann recht genau sehen, welche Nachrichten er empfangen hat und welche nicht. Wenn er eine Nachricht nicht empfangen hat, dann meldet er die gleiche Temperatur wie im vorherigen Zyklus.

Gute Ergebnisse habe ich im Moment mit cyclicMsgOffset von 250 (geloggten measured-temp Werte vom RT):

Code Auswählen Erweitern

"timestamp" "value"
"2017-01-29 22:25:32" "36.5"
"2017-01-29 22:23:27" "36.0"
"2017-01-29 22:21:08" "35.5"
"2017-01-29 22:18:35" "35.0"
"2017-01-29 22:15:47" "34.5"
"2017-01-29 22:12:45" "34.0"
"2017-01-29 22:10:32" "33.5"
"2017-01-29 22:08:05" "33.0"
"2017-01-29 22:05:23" "32.5"
"2017-01-29 22:02:27" "32.0"
"2017-01-29 22:00:21" "31.5"
"2017-01-29 21:58:00" "31.0"
"2017-01-29 21:55:25" "30.5"


Mit 1000 ms hatte ich schon ein paar doppelte. (*ich seh gerade mit 250 ms hab ich jetzt auch doppelte)

Ohne Offset hatte ich permanent mehrfache Temperaturen, oft 3-4 Zyklen die gleiche (-> sehr instabil).
Ungefähr so (also in der Zeit hat der RT offenbar keine Temp-Nachrichten gesehen):

Code Auswählen Erweitern


"timestamp" "value"
"2017-01-29 22:53:51"   "30.0"
"2017-01-29 22:51:13" "30.0"
"2017-01-29 22:48:20" "30.0"
"2017-01-29 22:46:18" "30.0"


Also offenbar hilft es deutlich, die Intervalle künstlich zu erhöhen. In meinem Fall scheint der ideale Wert irgendwo zwischen 250 und 1000 ms liegen. Also so weit so gut, ich denke man bekommt damit einen stabilen Betrieb hin mit nur vereinzelt verpassten Nachrichten.

Jetzt bitte die Preisfrage: Bitte erkläre mir jemand, warum das mit Offset funktioniert!! Nach allem was ich in den letzten Tagen gelesen und dachte verstanden zu haben, macht das für mich keinen Sinn. Der originale TC sendet genau in den Intervallen, die FHEM auch ausrechnet (habs nachgerechnet . Wenn man selbst in diesen Intervallen sendet, dann ist es jedoch instabil (!?!?!?).

Wenn der RT wirklich nur für 250 ms auf Empfang geht, dann müsste man doch mit einem Offset von 1000 ms das Fenster völlig verfehlen. Ich hätte es verstanden, wenn man mit kleinen Werte von max. +/- 50 ms Laufzeiten im OS o.ä. ausgleichen würde, aber nach meinem Verständnis müsste man doch mit einem Wert von 1000 ms sämtliche Timings völlig versauen und es dürfte gar nix mehr gehen (bis der RT nach einigen Nachrichten sein Fenster dermaßen vergrößert bis er wieder eine fängt)

Wäre klasse, wenn mich jemand erleuchten könnte, ich würde es wirklich gerne verstehen

(Im Anhang nochmal die CUL_HM-Variante die immer durchrotierende Temperaturen zwischen 30 und 40 °C sendet. Falls das jemand nachturnen möchte...)

[Linef]

Ist das Zeitfenster wirklich ca. 10 Sek offen? Ich hab hier eine Seite gefunden, wo das Verhalten beschrieben wird (unter "Timing"):
https://homegear.eu/index.php/BidCoS_Packet_-_General_Information

Die Information ist sehr interessant - widerspricht aber den von mir gemachten Beobachtungen.

Ich hatte von meinem Temperatursensor aus mal versehentlich das ACK-Flag bei den Temperaturmeldungen versendet. Der RT-DN hat daraufhin den Empfang eines Pakets bestätigt. So konnte ich recht gut beobachten, wann er ein Paket bestätigt und wann nicht.
Zudem habe ich in FHEM alles ms-genau mitprotokollieren lassen, und dann mithilfe der "Formel" die Sendeabstände nachgerechnet.
So bin ich eben darauf gekommen, daß das Empfangsfenster die 10 Sekunden offen ist, und daß das neue Zeitfenster basierend auf dem letzten Empfangszeitpunkt berechnet wird.

Testweise hatte ich dann auch mal mehrere Messages pro Sekunde verschickt und dabei noch gesehen, daß der RT-DN auch zwischen diesen Zeitfenstern immer mal wieder kurz auf Empfang ist (eine Regel dahinter konnte ich aber nicht erkennen). Diese zusätzlichen Fenster hatte er auch, obwohl er "in sync" mit dem Temperatursensor war...

Also wer da nochmals testen will - einfach ACK vom RT-DN anfordern...

Ich betreibe mein Peering schon seit vielen Monaten mit einem Offset von 1000ms - ich kann ja mal noch mit weniger testen...
Ich denke, je kürzer der RT-DN auf das Datenpaket warten muß, desto batterisparender wird das Ganze...

Aber selbst mit 1000ms habe ich gelegentliche Aussetzer (alle paar Tage mal).

Bei den Tests mit den ACKs ist mir aufgefallen, daß der RT-DN immer mal wieder eine oder mehrere Übertragungen einfach nicht bestätigt hat - obwohl ich hundertprozentig IM Zeitfenster war. Entweder kam das Datenpaket bei ihm nicht richtig an, oder Firmwarebug. Zerstörte Datenpakete sind ja möglich (wenn zwei Homematic-Devices gleichzeitig senden), aber FHEM hat in diesem Falle die Pakete empfangen, der RT-DN jedoch nicht...

Ich hätte erwartet, dass der RT den erwarteten Sendezeitpunkt in die Mitte seines Empfangsfenster legt, so dass zu beiden Seiten ein Puffer besteht. D.h. bei einem 10 Sek. Fenster hätte man zu beiden Seiten 5 Sek Toleranz.

Nein - kannst ja mal mit negativem Offset probieren - bereits bei 100 oder 200ms kürzer als die Formel vorgibt, klappt praktisch kein Übertragungsversuch mehr...

Ist das wirklich denkbar, dass die beiden Quarze so dermaßen unterschiedlichen laufen, dass sich da innerhalb von 2,5 Minuten ein Versatz von >5 Sek zwischen den beiden ergibt?

Nein, ich formuliere das Problem mal anders:
Wenn der Sensor (Sender) ohne den Offset sendet, und beide Quarze exakt sind, dann sendet der Sensor genau dann, wenn der RT-DN das Fenster gerade geöffnet hat. Wenn jedoch der Quarz im Sensor nur ein klein bisschen schneller taktet, dann sendet der Sensor ein klein bisschen früher - vielleicht 100ms, und das ganze Telegramm ist damit futsch...

Martin

[Linef]

Hab noch eine Kleinigkeit gefunden: Die originalen TCs senden immer 0x84 als Control-Byte, CUL_HM sendet aber 0x86. Unterschied ist das gesetzte WAKEMEUP-Flag.

0x84 ? Was will der TC mit dem Flag "DEVICE_IN_CONFIG_MODE"? Das verstehe ich nicht.
Ich sende bei mir mit 0x82, also nur das WKMEUP-Flag gesetzt.

Martin