HM-CC-RT-DN: wie erhalte ich ein störungsfreies Weather Peering?

[Beta-User]

Ggf. den externen Tempsensor noch mit sinnvollen Werten für "event-on-change-reading" und "event-min-interval" etwas in der Gesprächigkeit bändigen .

Gruß, Beta-User

[Kottellettenhorst]

Ggf. den externen Tempsensor noch mit sinnvollen Werten für "event-on-change-reading" und "event-min-interval" etwas in der Gesprächigkeit bändigen .

Das hab ich schon von Anfang an

Code Auswählen Erweitern


event-min-interval (temperature|humidity).*:600,(battery).*:86400
event-on-change-reading temperature.*:0.2,humidity.*:2


[Beta-User]

Ok, aber war das aus dem bisherigen Thread zu erkennen?

Irgendwie hat mich in dem Zusammenhang dann das "at" auf eine falsche Fährte gelockt bzw. der Hinweis von CoolTux auf die Weitergabe per notify (was evtl. zu Sendungen im 30-Sek.-Takt (oder was auch immer die Update-Frequenz der Temp-Sensoren ist) führen würde).

Wenn es nicht klappt: 10 min. für das min-interval sind evtl. zu lang (siehe Hinweis von Martin). Ein WT sendet z.B. ca. alle 2,5 Minuten, den timeout für den Übergang zum internen Temp-Sensor kenne ich nicht, würde aber auf etwas kürzeres tippen, aber das kannst du ja selbst herausfinden.

Gruß, Beta-User

[Kottellettenhorst]

Wieso sollten 10 min. für das min-interval zu lang sein?
Der virtuelle Channel wird doch NUR vom at befüllt und dieser feuert doch nun (nachdem ich den Temperaturvergleich herausgenommen habe) definitiv alle 2 Minuten.
das min-interval dient vor allem zum schmälern der log dateien..

[Beta-User]

Alles klar,

meine Anmerkung bezog sich - wie indirekt bereits angemerkt - auf den Vorschlag von CoolTux, den Kanal mit einem notify zu füllen. Wenn es weiterhin per at (alle 2 Min.) sein soll, ist das was anderes.

Das ganze Vorgehen wäre m.E.  mit dem vorgeschlagenen notify (und eben einem min-interval einschl. loggen der Werte alle 2,5 Min) mehr "straigt forward", aber das mußt du wissen.

Gruß, Beta-User

[Kottellettenhorst]

Achso, na dann sind wir ja auf einem Nenner.
Ich hatte schon vor längerer Zeit gemerkt, dass das Log zu umfangreich bzw. das Plotten von Graphen zu langsam wurde, wenn man zu viele Datenpunkte loggt. Eine Verlängerung des min-intervals auf 10 Minuten hat dabei für mich einen guten Kompromiss zwischen Performance und noch darstellbaren Plotdaten bei gleichbleibenden Werten dargestellt, den ich deshalb auch gerne beibehalten würde.

Auch wenn ich dir in Punkto "straight forward" mit notify recht geben würde, so haben at's doch den Vorteil, dass diese keine zusätzlichen log Daten erzeugen..

Irgendwie verzettelt sich das hier etwas.
Vielleicht sollte ich deshalb an dieser Stelle noch mal einen Schritt zurück gehen und folgende grundsätzliche Fragen zu diesem Thema klären:

• Wie und nach welchem Schema erfolgt die Datenübertragung zwischen dem RT Weather channel und gepeerten virtuellem HM CUL channel?
• Wer ist Initiator der Datenübertragung?
• Fragt der RT explizit beim peer die Daten an?
• Woher weiß der virtuelle Channel, wann er senden kann?

[Beta-User]

Soweit ich das verstanden habe, sendet das zugehörige IO die Daten baldmöglichst nachdem sie in den virtuellen Kanal geschrieben wurden. Das ist mind. bei virtuellen Türkontakten so. Die volle Kontrolle liegt also auf der FHEM-Seite (aus Sicht des RT als: des Sensors).

Damit sollten eigentlich die Fragen 2-4 beantwortet sein. Frage 1 verstehe ich nicht.

[Kottellettenhorst]

Frage 1 zielt darauf ab, etwas mehr grundlegendes Verständnis dafür zu bekommen, was intern überhaupt abläuft, nachdem ein RT Weather mit einem virtuellen HM CUL channel gepeert wurde: wie genau gelangt der Temperaturwert vom virtuellen in den Weather channel? Wann bzw. zu welchen Zeitpunkten und wie häufig geschieht dies? Etc...

Wenn ich manuell z.B. die desiredTemp eines RTs setze, dann sehe ich auf dem zugehörigen device den Status "CMDs pending", bis das Kommando an den RT übermittelt wurde.
Wird dies beim übertragen der externen Temperatur genauso abgearbeitet und müsste ich also zu irgendeinem Zeitpunkt ein solches "CMDs pending" auf dem RT device sehen können? (ist mir bisher jedenfalls nie aufgefallen..)

Und die zentrale Frage 4 hast du leider nicht wirklich beantwortet. Falls es so sein sollte, dass der virtuelle channel die Übertragung nur alle x Minuten für y Sekunden versucht, dann muss der RT ja genau in diesem Zeitfenster auf Empfang sein. Woher weiß der virtuelle channel nun also, wann er senden darf/muss?

Alle schreiben, dass Timing hier der neuralgische Punkt sei. Deshalb versuche ich die Vorgänge ein bisschen besser zu verstehen..

(Was mir bei der ganzen Sache etwas schleierhaft ist: der RT wacht doch eh alle 2,5 Minuten oder so auf und übermittelt seine readings an FHEM. Dies funktioniert ja auch gut und stabil. Ganz naiv würde ich doch erst einmal denken: FHEM weiß doch eigentlich, dass dieser RT gerade "wach" ist und könnte die Daten gepeerter channels direkt übermitteln..)

[Beta-User]

Dann also nochmal der Versuch, Frage 1 zu beantworten:

Es wird direkt ein Sendebefehl ausgelöst, wenn ein virtueller Kanal befüllt wird, also der aktualisierte Wert von FHEM da reingeschrieben. (Das stand doch eigentlich schon in meinem letzten Beitrag, oder?) Jedenfalls bei Fensterkontakten und simulierten Tastendrücken ist das sicher so, der Temp-Wert düfte sich hier nicht wesentlich anders verhalten, siehe nachfolgend zu burst.

Für "schlafende" Devices (wie den RT) wird dabei ein burst genutzt, der Empfänger also aufgeweckt. Es wird im Ergebnis nichts anderes getan, wie wenn du z.B. einen Taster an einem "normalen" physischen HM-Device drückst (oder eben ein WT statt des virtuellen Kanals einen Temperaturwert sendet). Also: der Sensor entscheidet, wann gesendet wird (ein "normaler WT" würde sich nach dem Senden ja auch wieder schlafen legen und nicht auf Empfangsbereitschaft aller gekoppelter RT's bis zu 2,5 Min. warten) und weckt dazu den/die RT auf (deswegen sind 2,5 Min auch besser wie 2 Min => Batterielebensdauer, ein burst weckt immer alle burst-Devices auf, nicht nur die gepeerten...).

Ergo: der virtuelle Kanal kann allenfalls wissen, ob das IO verfügbar ist, und ob und an welche Empfänger-Devices der Befehl ggf. wiederholt werden muß (kein ACK).

Was das timing angeht, sollte eben nicht alles quasi gleichzeitig gesendet werden, weil sich sonst die Infos und von den RT's gesendeten ACKs etc. ins Gehege kommen. Daher ist ein "wildes timing" besser, wie es sich aus den per notify verarbeiteten Empfangszeitpunkten der Temperaturwerte ergibt, wie wenn Punkt ::00 alle virtuellen Kanäle neu befüllt werden.

[frank]

lest doch einfach den thread.

[Linef]

Sender und Peer berechnen den nächsten Zeitpunkt anhand einer fixen Formel - Sendeabstände liegen zwischen 2 und 3 Minuten. Der Peer (RT-DN) geht dann für 10 Sek. auf Empfang.
Ist der Peer out of Sync, dann geht er öfter auf Empfang.

[Owesle@outlook.de]

Erst einmal vielen Dank für die Anpasung des Moduls.
Mit Delaywerten zwichen 300 und 500 ms funktioniert bei mir jetzt alles wunderbar.
Vorher ging der WAF gegen 0, weil das Wohnzimmr bei Störungen dann einfach nicht geheizt hat (Differenz von 3 Grad zur aktuellen Temperatur im Zimmer).

Bei mir ist das Problem extrem aufgetreten, nachdem ich vom NanoCul auf dem mapleCUN umgestiegen bin.
Vielleicht wird das unterschiedliche Timing also auch durch die verschoedene Hardware hervorgerufen?

Noch eine Bitte:
Könnte jemand den Hinweis auf cyclicMsgOffset in das Wiki einbauen?
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperatursensoren

Ich habe tagelang nur alle Threads gefunden, in denen Stand, das man eben nichts machen kann, bis ich durch Zufall diesen Thread fand.

[frank]

Bei mir ist das Problem extrem aufgetreten, nachdem ich vom NanoCul auf dem mapleCUN umgestiegen bin.
Vielleicht wird das unterschiedliche Timing also auch durch die verschoedene Hardware hervorgerufen?

die cul's können nur mit der ts_culfw ein "brauchbares" timing für homematic realisieren.

[Amenophis86]

Noch eine Bitte:
Könnte jemand den Hinweis auf cyclicMsgOffset in das Wiki einbauen?
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperatursensoren

Gute Idee und erledigt

[Kottellettenhorst]

So, nun melde ich mich auch noch einmal zu Wort.

Ich habe mir den gesamten von Frank nahegelegten Thread durchgelesen und hatte natürlich ein Dejavu, da dort die exakt gleiche Problematik diskutiert wird.

Äußerst aussagekräftig fand ich dabei, dass selbst unter den anscheinend sehr versierten Diskussionsteilnehmern zwei komplett unterschiedliche Meinungen vertreten wurden, wie denn nun genau die Kommunikation des externen Sensors über den virtuellen Cul mit dem RT funktioniert (wie auch anfänglich in diesem Thread, was meine Verwirrung und das rege Thread Interesse erklärt): einerseits wurde behauptet, diese würden via burst unmittelbar an den RT gesendet, anderseits wurde behauptet, diese würden nach einer vorgegebenen (sowohl RT als auch Cul bekannten) Formel zu bestimmten Zeitpunkten an den RT gesendet, in denen dieser empfangsbereit ist.

Letzteres scheint aber korrekt zu sein, da schließlich besagtes Attribut cyclicMsgOffset eingeführt wurde, mit dem viele der User mit dem selben Problem eine Besserung erreichen konnten.
Deshalb erscheinen mit die Hinweise auf die at's als Problemursache bzw. die vorgeschlagenen Maßnahmen (egal ob nun Auslassen der set Befehle bei gleichbleibender Temperatur oder Spreizung mittels alignTime) als hinfällig. (ich habe sie aber beide dennoch vorerst umgesetzt, stört ja auch nicht weiter)

Da das Temperaturupdate als Broadcast gesendet wird und das gepeerte device den Empfang nicht zu quittieren scheint, hat man leider keine wirkliche Handhabe, den korrekten Empfang zu prüfen - außer die gesendete Temperatur des nächsten normalen Readings des RTs zu kontrollieren.
Dafür fehlt (mir) aber eine vernünftige Beschreibung der HMLAN Log-Syntax. Deshalb die Bitte an den/die Entwickler vom HMLAN: bitte erweitert doch den Wiki Eintrag https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen um eine vollständige Beschreibung der Nachrichten, damit man diese auch entziffern kann (oder zumindest einen Verweis auf die Protokoll Definition, white papers, etc...).
Konkret für z.B. folgendes Logging

Code Auswählen Erweitern


2017.12.10 09:14:43.954 0: HMLAN_Send:  hmusb I:K
2017.12.10 09:14:43.967 0: HMLAN_Parse: hmusb V:03C7 sNo:MEQ0231480 d:37325E O:37325E t:962CDE45 IDcnt:0007 L:5 %
2017.12.10 09:14:50.895 0: HMLAN_Send:  hmusb S:+000000,00,00,00
2017.12.10 09:14:50.898 0: HMLAN_Send:  hmusb S:S3F7DB56E stat:  00 t:00000000 d:01 r:3F7DB56E m:20 8470 3732F1 000000 0097
2017.12.10 09:14:50.975 0: HMLAN_Parse: hmusb R:R3F7DB56E stat:0002 t:00000000 d:FF r:7FFF     m:20 8470 3732F1 000000 0097
2017.12.10 09:14:54.047 0: HMLAN_Parse: hmusb R:E38A99D   stat:0000 t:962D05A2 d:FF r:FFC1     m:37 8610 38A99D 000000 0A88980E6400
2017.12.10 09:15:01.903 0: HMLAN_Send:  hmusb S:+000000,00,00,00
2017.12.10 09:15:01.906 0: HMLAN_Send:  hmusb S:S3F7DE06E stat:  00 t:00000000 d:01 r:3F7DE06E m:22 8470 3732F2 000000 00A4
2017.12.10 09:15:01.984 0: HMLAN_Parse: hmusb R:R3F7DE06E stat:0002 t:00000000 d:FF r:7FFF     m:22 8470 3732F2 000000 00A4
2017.12.10 09:15:03.269 0: HMLAN_Parse: hmusb R:E36701E   stat:0000 t:962D2996 d:FF r:FFCB     m:DC 865A 36701E 000000 889935

konnte ich zwar die letzten 3 Werte als Absender-ID, Empfänger-ID und Wert identifizieren, aber

• wofür stehen die einzelnen Parameter I, V, d, O, t, S, stat, m, etc...?
• wie sind die einzelnen Informationen genau kodiert? (besonders der Wert?)

Und bitte nehmt es nicht persönlich oder als Wink mit dem moralischen Zeigefinger, sondern als konstruktive Kritik und Feedback zum Verständnis des Codes, aber die Code-Qualität von 00_HMLAN.pm ist wirklich schlecht im Sinne der Lesbarkeit und Wartbarkeit - ich konnte nur anhand des Codes nicht wirklich die benötigten Informationen erhalten:

• Es werden oft absolut unverständliche Variablenkürzel verwendet ($p, $r, $t, etc...); siehe hierzu div. clean code guidelines z.B. http://www.itiseezee.com/?p=83
• Fehlende Kommentare. Ja ich weiß, wir Entwickler (und da schließe ich mich gar nicht aus) wollen immer gerne alles direkt durch coden und Kommentare halten einfach auf  ; außerdem gibt es im software engineering durchaus kontroverse Ansichten darüber, ob guter Code noch Kommentare benötigt. Ist der Code aber nicht selbstdeskriptiv, so sind sie wohl oder übel unerlässlich, um anderen Entwicklern, die nicht unmittelbar daran beteiligt sind, das Verständnis der Funktion erleichtern.

Warum schreibe ich das ganze? Weil ich Dinge im Allgemeinen (und Probleme im Besonderen) gerne verstehe (und Probleme wenn möglich behebe). Und solange ich nicht wirklich nachvollziehen kann, wieso es (in meinem Fall) zu genannten Problemen kommt bzw. wie diese zu reproduzieren und ggf. zu Beheben sind, möchte ich mir gerne selbst ein Bild der Situation erschließen.
Dazu muss ich wohl doch tiefer in die Beobachtung und Deutung der HMLAN raw messages einsteigen und um diese mit einem vertretbaren Aufwand zu verstehen, wäre eine gute Dokumentation erforderlich.