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

[vbs]

Also eure Vermutung ist, dass die Temperatur vom virt.Sensor gesendet wird, aber der RT gerade nicht lauscht? Und eigentlich sollten die beiden beim ersten Kontakt ein (wiederkehrendes?) Zeitfenster in der Zukunft (paar Minuten) vereinbaren, in dem der RT sich empfangsbereit hält und der TC dann sendet?
Ist das soweit schon gesichertes Wissen oder erstmal eine Annahme?

Erste Frage: Warum wird die Temperatur nicht einfach als Burst gesendet?

Ich könnte bestimmt den grundlegenden Nachrichtenaustausch ausforschen und rausfinden, wer wann sendet. Aber ich fürchte, wenn da wirklich Synchronisationsmechanismen in FHEM fehlen, dann werde ich da nicht helfen können. Ist die Frage, ob das jemand außer Martin kann :/

[vbs]

So sieht das bei mir aus, wenn der virt.Sensor aufwacht und die Temperatur abschickt:

Code Auswählen Erweitern


2017-01-24 17:05:56.588 CUL_HM bd_hmVirtualWeather temperature: -17.0
2017-01-24 17:05:56.591 CUL_HM bd_hmVirtualWeather set_virtTemp -17.0
...
2017-01-24 17:08:43.304 CUL_HM bd_hmVirtual CMDs_pending
2017.01.24 17:08:43.304 0 : HMLAN_Send:  HMLAN0 S:+000000,00,00,002017.01.24 17:08:43.305 0 : HMLAN_Send:  HMLAN0 S:SD13C8D81 stat:  00 t:00000000 d:01 r:D13C8D81 m:D1 8670 F16789 000000 7F562017-01-24 17:08:43.310 CUL_HM bd_hmVirtual CMDs_done
2017.01.24 17:08:43.436 0 : HMLAN_Parse: HMLAN0 R:RD13C8D81 stat:0002 t:00000000 d:FF r:7FFF m:D1 8670 F16789 000000 7F56
2017.01.24 17:08:52.585 0 : HMLAN_Send: HMLAN0 I:K

Sprich: Er schickt um 17:08:43.304 die Nachricht ab (ich denke mal die Temp-Nachricht), aber er bekommt dann daraufhin um 17:08:43.436, also ca. 100 ms später, auch eine Antwort. Wenn das die Antwort vom RT ist, dann würde das ja bedeuten, dass der RT doch empfangen hat.
Leider sagen mir die Nachrichten sehr wenig. "F16789" ist auf jeden Fall die HM-ID meines virt. Devices, ist auch in der ersten Nachricht zu sehen. In der Antwort kann ich leider keine ID finden, die auf den Absender hindeutet, nur wieder die "F16789".

Bedeutet für mich entweder:
- jemand anders als RT hat geantwortet (aber sollte nicht so sein, oder?)
- der RT hat zwar geantwortet (und daher auch empfangen), aber die Temperatur trotzdem nicht übernommen.

[frank]

hier hat kein device geantwortet. das ist die bestätigung vom hmusb über das senden.
da es eine msg an broadcast (0x000000) ist, wird sie auch keiner bestätigen. das ist ja sicherlich auch die schwierigkeit bei dieser kommunikation. fhem kann nicht erkennen, dass der rt empfangen hat.

wie gesagt, ich habe weder rt noch tc.
ich nutze allerdings einen virtuellen tc, um damit ventile (hm-cc-vd) zu steuern. hierbei ist die berechnung des nächsten kommunikationsfenster identisch. aber der vd antwortet hierbei, wenn das fenster korrekt getroffen wurde. bei jedem nichttreffen vergrössert der vd das fenster etwas und synchronisiert sich entsprechend bei erneutem treffen. da fhem dadurch eine synchronisation des vd erkennen kann, kann sich fhem auch entsprechen darauf einstellen. nach 6 erfolglosen versuchen hintereinander schläft der vd für eine ganze stunde komplett ein. danach ist er ein paar minuten dauerwach, um auf jeden fall wieder eine kommunikation zu schaffen. fhem ist bei mir aber in der lage eigentlich dauerhaft die kommunikation zu ermöglichen. ein fhem ohne verzögerungen ist natürlich voraussetzung.

beim rt/tc muss das etwas anders ablaufen. da ich aber noch nie davon gehört habe, dass es bei dieser kombination fälle gab, wo der rt auf seine eigene temp umgeschaltet hat, müsste es hier eigentlich auch einen synchronisations mechanismus geben. ich kann mir nicht vorstellen, dass die "uhren" beider devices, so genau gehen, dass es über wochen oder monate keine aussetzer gibt. unterscheiden muss man sicherlich noch, welche channel gepeert sind. im unterschied zum vd, meldet sich der rt sogar zyklisch von selbst und wäre auch über burst erreichbar. daher denke ich, dass nur eine kleinigkeit fehlt, damit es auch dauerhaft funktionieren sollte.

[martinp876]

Nur soviel dazu:
Mein RT funktioniert ohne Aussetzer mit einem TC, ein anderer mit einem eigenbau sensor (Dirk!).
Mit burst hat es in keinem Fall etwas zu tun .
Evtl bei Dirk nach der Berechnungsmethode fragen.
Ich gehe davon aus, dass sich der Empfänger bei jeder mesage neu synchronisiert. Ist aber unbewiesen.

[Linef]

So sieht das bei mir aus, wenn der virt.Sensor aufwacht und die Temperatur abschickt:

Code Auswählen Erweitern


2017.01.24 17:08:43.304 0 : HMLAN_Send:  HMLAN0 S:+000000,00,00,002017.01.24 17:08:43.305 0 : HMLAN_Send:  HMLAN0 S:SD13C8D81 stat:  00 t:00000000 d:01 r:D13C8D81 m:D1 8670 F16789 000000 7F562017-01-24 17:08:43.310 CUL_HM bd_hmVirtual CMDs_done
2017.01.24 17:08:43.436 0 : HMLAN_Parse: HMLAN0 R:RD13C8D81 stat:0002 t:00000000 d:FF r:7FFF m:D1 8670 F16789 000000 7F56
2017.01.24 17:08:52.585 0 : HMLAN_Send: HMLAN0 I:K


Sprich: Er schickt um 17:08:43.304 die Nachricht ab (ich denke mal die Temp-Nachricht), aber er bekommt dann daraufhin um 17:08:43.436, also ca. 100 ms später, auch eine Antwort. Wenn das die Antwort vom RT ist, dann würde das ja bedeuten, dass der RT doch empfangen hat.
Leider sagen mir die Nachrichten sehr wenig. "F16789" ist auf jeden Fall die HM-ID meines virt. Devices, ist auch in der ersten Nachricht zu sehen. In der Antwort kann ich leider keine ID finden, die auf den Absender hindeutet, nur wieder die "F16789".

Bedeutet für mich entweder:
- jemand anders als RT hat geantwortet (aber sollte nicht so sein, oder?)
- der RT hat zwar geantwortet (und daher auch empfangen), aber die Temperatur trotzdem nicht übernommen.

Für mich sieht's so aus als ob beides die selbe Message ist:
In beiden Zeilen beginnt die Message mit D1 (Messagenummer), dann gefolgt von 86 (Flags - die sagen aus, daß kein ACK auf diese Nachricht folgen soll), dann das Src-Device (F16789), dann Dest (000000, also Broadcast - kein spezielles Zieldevice), dann die Payload.

Sieht also nicht so aus, als ob jemand geantwortet hätte - eher zwei Verarbeitungssteps innerhalb fhem...

Martin

[Linef]

beim rt/tc muss das etwas anders ablaufen. da ich aber noch nie davon gehört habe, dass es bei dieser kombination fälle gab, wo der rt auf seine eigene temp umgeschaltet hat, müsste es hier eigentlich auch einen synchronisations mechanismus geben. ich kann mir nicht vorstellen, dass die "uhren" beider devices, so genau gehen, dass es über wochen oder monate keine aussetzer gibt. unterscheiden muss man sicherlich noch, welche channel gepeert sind. im unterschied zum vd, meldet sich der rt sogar zyklisch von selbst und wäre auch über burst erreichbar. daher denke ich, dass nur eine kleinigkeit fehlt, damit es auch dauerhaft funktionieren sollte.

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.

Sind die beiden Devices "außer Tritt", dann geht der RT öfter mal auf Empfang (dann wohl auch mit einem längeren Zeitfenster), um wieder eine Meldung des TC einzufangen und sich damit aufzusynchronisieren.

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.

Martin

[fhainz]

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

Wie kann man das einstellen?

Grüße

[Linef]

Wie kann man das einstellen?

Im Falle Device: Firmware umprogrammieren (nur bei Eigenbauten möglich, aber wahrscheinlich auch nur da nötig),
im Falle fhem (virt. Sensor): entsprechende Stelle (die den Abstand zum nächsten Zeitfenster berechnet) im Code suchen und 1000ms dazu addieren (oder wie auch immer das dort realisiert ist - ich habe noch nicht danach gesucht...)

Martin

[fhainz]

Ah, das ist ein HM-Eigenbau Sensor, das hatte ich erst nicht überrissen.

Danke, dann werde ich mal danach suchen.

[vbs]

Ich such das gerade... würde das erstmal plump auf alle 5 Sekunden senden stellen, um erstmal zu beweisen, dass das das Problem ist.

[Linef]

Ich such das gerade... würde das erstmal plump auf alle 5 Sekunden senden stellen, um erstmal zu beweisen, dass das das Problem ist.

Dann geht Dein HMLAN (ö.ä.) aber vermutlich in Overload und sendet ein Weilchen gar nix mehr...

Martin

[vbs]

Echt meinst du? Alle 5 Sekunden sind ja 720 Nachrichten pro Stunde. Gemäß 1%-Regel hat man 36 Sekunden Sendezeit. D.h. jede Nachricht darf 50 ms lang sein wenn ich mich nicht verrechnet habe. Klingt erstmal viel.
Zur Not kann ich den HMCFG auch kurz abstecken. Sollte zu Testzwecken ok sein.

[Linef]

Echt meinst du? Alle 5 Sekunden sind ja 720 Nachrichten pro Stunde. Gemäß 1%-Regel hat man 36 Sekunden Sendezeit. D.h. jede Nachricht darf 50 ms lang sein wenn ich mich nicht verrechnet habe. Klingt erstmal viel.
Zur Not kann ich den HMCFG auch kurz abstecken. Sollte zu Testzwecken ok sein.

ok, sollte reichen. Ich glaube eine Nachricht dauert so um die 5ms (je nach Länge)

Martin

[Fredi69]

Im Falle Device: Firmware umprogrammieren (nur bei Eigenbauten möglich, aber wahrscheinlich auch nur da nötig),
im Falle fhem (virt. Sensor): entsprechende Stelle (die den Abstand zum nächsten Zeitfenster berechnet) im Code suchen und 1000ms dazu addieren (oder wie auch immer das dort realisiert ist - ich habe noch nicht danach gesucht...)

Hat sich jemand damit mal beschäftigt, gibt es Neuigkeiten?

[CBSnake]

Moin zusammen,

ich hab das jetzt an verschiedenen Tagen in verschiedenen Räumen mal getestet, kurz nach dem Aufwachen und Senden vom RT hab ich am virtuellen Device die Temperatur von Hand verstellt (und damit meinen LaCrosse Sensor Wert überschrieben) und immer hat sich der RT Weather Kanal 2,5 Minuten später diesen Wert quasi abgeholt. Ist das nun Zufall, das es bei mir so gut funktioniert? Läuft das wirklich so ab, das beide Synchron laufen müssen? Sollte nicht das Virtuelle Device erkennen, dass sich der RT eben gemeldet hat und dann die neue Temperatur schicken während der RT noch lauscht? Oder ist dazu das Zeitfenster zu knapp bzw schläft das virtuelle Device`und ist dann nicht wach und ich bin total auf dem Holzweg?

Grüße
Achim