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

Begonnen von Merlin, 15 Dezember 2015, 19:10:39

Vorheriges Thema - Nächstes Thema

vbs

Zitat von: Linef am 29 Januar 2017, 23:37:33
Also wer da nochmals testen will - einfach ACK vom RT-DN anfordern...
Das ist ein super Tipp danke!

Zitat von: Linef am 29 Januar 2017, 23:37:33
Ich betreibe mein Peering schon seit vielen Monaten mit einem Offset von 1000ms - ich kann ja mal noch mit weniger testen...
Ich hab im Moment 500 ms laufen und bisher jede Nachricht angekommen. Waren aber auch erst ~20. Also noch nix belastbares.

Zitat von: Linef am 29 Januar 2017, 23:37:33
Nein - kannst ja mal mit negativem Offset probieren - bereits bei 100 oder 200ms kürzer als die Formel vorgibt, klappt praktisch kein Übertragungsversuch mehr...
Das heißt der RT legt sein Empfangsfenster so, dass der erwartete Sendezeitpunkt am Anfang des Fenster liegt? Bei einem Fenster von 10 Sek müsste man dann theoretisch mit einem Offset von 5 Sek die besten Chancen haben? Evtl. erhöhter Batterieverbrauch weil der RT immer 5 Sek warten muss bis die Nachricht kommt...

Erklärt für mich aber irgendwo immer noch nicht so recht, warum der originale TC ohne Offset funktioniert und wir ca. 1 Sek (eine Ewigkeit!!) brauchen, damits stabil ist.

Linef

Zitat von: vbs am 29 Januar 2017, 23:51:27
Das heißt der RT legt sein Empfangsfenster so, dass der erwartete Sendezeitpunkt am Anfang des Fenster liegt? Bei einem Fenster von 10 Sek müsste man dann theoretisch mit einem Offset von 5 Sek die besten Chancen haben? Evtl. erhöhter Batterieverbrauch weil der RT immer 5 Sek warten muss bis die Nachricht kommt...
Genau.

Zitat von: vbs
Erklärt für mich aber irgendwo immer noch nicht so recht, warum der originale TC ohne Offset funktioniert und wir ca. 1 Sek (eine Ewigkeit!!) brauchen, damits stabil ist.
Das stimmt.

Wissen wir aber, ob bei einem TC der RT-DN alles sauber empfängt und NIE auf seinen internen Sensor umspringt?
Hat das ein TC-Besitzer schon mal verifiziert?

Martin
fhem auf cubietruck, HM-USB-CFG-2, CUL-V3, 6x HM-CC-RT-DN, 5x HM-SEC-SD, 2x HM-SEC-SCo, 5x HM Eigenbausensoren, AVR-Heizungsgateway

vbs

Zitat von: Linef am 29 Januar 2017, 23:48:59
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.
Ist vielleicht zu früh am morgen, aber der TC sendet 0x84, CUL_HM sendet 0x86. Das 0x84 ist korrekterweise (denk ich) _ohne_ das Flag.

vbs

Zitat von: Linef am 29 Januar 2017, 23:37:33
Also wer da nochmals testen will - einfach ACK vom RT-DN anfordern...
Hm, also einfach nur das Flag setzen (BIDI-Flag, richtig?) klappt bei mir so erstmal nicht. Sieht dann so aus:
2017.01.30 08:26:13.591 0: HMLAN_Send:  HMLAN0 S:+000000,00,00,00
2017.01.30 08:26:13.592 0: HMLAN_Send:  HMLAN0 S:SEE4459B0 stat:  00 t:00000000 d:01 r:EE4459B0 m:06 A470 F16789 000000 0145
2017.01.30 08:26:14.295 0: HMLAN_Parse: HMLAN0 R:REE4459B0 stat:0008 t:00000000 d:FF r:7FFF     m:06 A470 F16789 000000 0145
2017.01.30 08:26:14.295 0: HMLAN_Parse: HMLAN0 no ACK from 000000


Also gibt offenbar keine Antwort. Es ist ja weiterhin noch das Broadcast-Flag gesetzt und die Broadcast Adresse "0000000" als Empfänger eingetragen. Müsste man das Flag noch löschen und den RT konkret als Empfänger eintragen? Kann ich sonst einfach mal probieren, aber dann erst heute abend.

vbs

Nächste Erkenntnis: Mit einem Offset von 4000 kommen praktisch keine Nachrichten mehr an. Diese Beobachtung passt natürlich auch wieder nicht zu bisherigen Annahmen...  :-\ Bei einem 10 Sek Fenster mit Sendezeitpunkt am Anfang sollte man eigentlich mitten drin liegen.

Linef

Zitat von: vbs am 30 Januar 2017, 08:29:26
Also gibt offenbar keine Antwort. Es ist ja weiterhin noch das Broadcast-Flag gesetzt und die Broadcast Adresse "0000000" als Empfänger eingetragen. Müsste man das Flag noch löschen und den RT konkret als Empfänger eintragen?
Die Messages bei wir waren auf jeden Fall an den Peer (RT-DN) gerichtet, also kein Broadcast.
Als Control-Byte hatte ich dann 0xA0 oder 0xA2 ("Broadcast"-Flag nicht gesetzt)

Apropos Broadcast-Flag: in NewAskSin ist das mit CFG (Device in Config Mode) betitelt und ist meines Wissens nach wirklich nur während eines Configs gesetzt. Dem widerspricht jetzt wieder daß der TC ständig mit gesetztem Bit sendet... Eine weitere Unklarheit...

Martin
fhem auf cubietruck, HM-USB-CFG-2, CUL-V3, 6x HM-CC-RT-DN, 5x HM-SEC-SD, 2x HM-SEC-SCo, 5x HM Eigenbausensoren, AVR-Heizungsgateway

vbs

Zitat von: Linef am 30 Januar 2017, 16:28:52
Apropos Broadcast-Flag: in NewAskSin ist das mit CFG (Device in Config Mode) betitelt und ist meines Wissens nach wirklich nur während eines Configs gesetzt. Dem widerspricht jetzt wieder daß der TC ständig mit gesetztem Bit sendet... Eine weitere Unklarheit...
Wir haben hier irgendwie ein Missverständnis: mMn sendet CUL_HM (nicht der TC!) mit einem Flag mehr:
CULHM: 0x86 -> 10000110
      TC: 0x84 -> 10000100

Ich denke aber, dass wir dasselbe Bit meinen. Wird im Homegear Wiki beschrieben mit "1   WAKEMEUP   Makes the central send configuration parameters after receiving the packet.". Aber TC sendet das nicht, sonder CULHM.

Linef

Zitat von: vbs am 30 Januar 2017, 16:48:42
Ich denke aber, dass wir dasselbe Bit meinen. Wird im Homegear Wiki beschrieben mit "1   WAKEMEUP   Makes the central send configuration parameters after receiving the packet.". Aber TC sendet das nicht, sonder CULHM.
Nein, ich sprach von Bit 2 (hex:0x04): Das ist in NewAskSin mit CFG betitelt, während hier (und in dem Dokument weiter oben) von "Broadcast"-Flag gesprochen wird.
Dieses Bit ist bei mir eigentlich nur beim Pairing gesetzt.

Und dann gibt es Bit 1 (hex: 0x02), das ist das WKMEUP-Flag.
D.h. CULHM sendet bei Dir mit WKMEUP-Flag, der TC ohne Flag.
Da stellt sich die Frage, wann denn der TC mal MIT WKMEUP sendet - oder muß man bei jeder Änderung an den TC an selbigem den Konfig-Taster drücken?

So, und dann noch Bit 5 (hex: 0x20): das ist das BIDI-Flag. Das fordert ein ACK an.
D.h. mein Sensor müsste damals ein 0xA0 (nur ACK-Request) und/oder 0xA2 (ACK-Request + WKMEUP-Flag) gesendet haben (ist schon ein Jahr her, und Protokolle dazu habe ich auch nicht mehr).

WKMEUP an den RT-DN zu senden scheint zunächst mal keinen Sinn zu machen, aber die Zentrale bekommt das Paket auch und die reagiert dann, falls sie was an den Sensor zu senden hat.

Martin
fhem auf cubietruck, HM-USB-CFG-2, CUL-V3, 6x HM-CC-RT-DN, 5x HM-SEC-SD, 2x HM-SEC-SCo, 5x HM Eigenbausensoren, AVR-Heizungsgateway

Steiner0815

Ich bin schlichtweg begeistert.  ;D
Das festlegen der Offsetzeit auf 500ms hat bei mir alle Probleme mit den virtuellen Sensoren und meinen 8 HM-CC-RT-DN gelöst. In den letzten 12 Stunden konnte ich keine Temperatursprünge zwischen einem LaCrosse Sensor und der measured-temp mehr feststellen.

Danke dafür!

Nobody69

Hallo zusammen,

Ich hab auch mit Zwave einen virtuellen Temperatussensor unter HM realisiert, und dies Mit meinen HH_CC_RT_DN verbunden.
Ich habe mich schon gewundert, dass meine Regler ab und zu eine abweichende measured temp anzeigen, und nun hab ich gesehen ich bin nicht alein !!

Ich sprecht hier von einem "Offset cyclicMsgOffset"  ich kann dieses Attribut weder beim HM-Regelr noch Weather Canel oder beim Virtuellen Tempsensor finden.

Wo sollte er sein !??? dammit ich dies auch mal testen kann !!!

Danke

Gruß Ralf !!


andi11

ich kann ebenfalls fehlerfreiheit seit 24h vermelden mit einem Offset von 500ms.

vbs

@martin876
Liest du hier eigentlich mit?
Ich würde gerne den Patch im Anhang vorschlagen. Ändert einerseits das Control-Byte für die Wetter-Nachrichten von 0x86 auf 0x84 (wie beim echten TC). Andererseits führt es ein Attribut cyclicMsgOffset ein, das als Zeit in ms zum Sendezeitpunkt addiert wird.
Ich gehe davon aus, dass das ideale Offset von System zu System variieren könnte und denke daher, dass der User das selbst verändern können sollte.

Ich hab noch ziemlich viel getestet und tatsächlich hatte ich bisher mit kleinen Offsets zwischen 50 und 100 ms die besten Ergebnisse. Als default würde ich 50 ms vorschlagen (wie im Patch). Ich poste nochmal die kompletten Ergebnisse wenn ich damit durch bin.

EDIT:
Mit 50 ms kamen bei meinem Test mit über 400 Nachrichten ca. 99,5% an (2 nicht). Also ich denke, das liegt schon recht nah am Optimum.

vbs

Hab in den letzten Tage mal verschiedene Offset-Werte durchprobiert und dann ausgewertet, wie viele Nachrichten gesendet und wie viele davon verloren gegangen sind. Das sieht dann so aus:
https://docs.google.com/spreadsheets/d/1IG1Db8jTECoCP36WL4X-2M7ioUa9sCqwKa4fI1vzquU/edit?usp=sharing

Also mit Werten zwischen 50 und 100 ms hatte ich die besten Ergebnisse. Bei höheren Offsets nahm dann die Erfolgsquote nach und nach ab. Ich bin unsicher, ob die Daten 1:1 auf andere Installationen übertragbar sind. Wäre auf jeden Fall mal interessant zu sehen, wie sowas bei einer anderen Installation aussieht.

Es fehlt leider immer noch eine gute Erklärung zu dem beobachteten Verhalten. Ich denke mittlerweile nicht mehr, dass der RT für 10 Sekunden durchgängig auf Empfang ist. Ich könnte jetzt etwas spekulieren, aber das wird wohl nicht viel bringen :)

Steiner0815

Ich habe bei mir mal testweise auf 50ms & 100ms gestellt. Das funktionierte bei meinem "Problem-Thermostat" im Badezimmer überhaupt nicht. Zur Zeit bin ich auf 250ms, das läuft zur Zeit stabil. Ich werde in den nächsten Tagen mal weiter testen.