Hallo Community,
seit kurzem bespiele ich meine Homematic HM-CC-RT-DN Thermostate mit externen Jeelink/LaCrosse Thermometern.
Dazu habe ich jeden Weather Kanal eines RT mit einem eigenen virtuellen HM_CUL gepeert (dessen einziger channel dann über einen at mit der Temperatur des Thermometers gefüttert wird).
Im großen und ganzen funktioniert das ganze auch, nur leider nicht immer wirklich stabil:
es passiert bei einigen RTs ab und zu, dass der Wert nicht übernommen wird und dieser dann auf die interne Temperatur zurückfällt. Da diese meist höher ist, regelt der RT das Ventil sofort runter. Oft dauert es dann 1 Stunde oder mehr, bis der RT wieder die externe Temperatur übernimmt. Dann fällt die Temperatur wieder sprunghaft ab und der RT geht in Fenster offen Modus und setzt die Solltemperatur für einige Zeit auf 12 Grad.
Dieses Verhalten ist natürlich auf Dauer sehr nervig und führt die Regelung ad absurdum..
Ich hatte bereits im Forum gelesen, dass einige in solchen Fällen mit dem (leider nirgends genauer dokumentierten) Parameter cyclicMsgOffset des virtuellen Channels Abhilfe schaffen konnten.
Ich habe mit Werten von 100, 150, 250, 500 und 1000 experimentiert, was die Situation aber eher verschlimmbessert hat.
Ich setze insgesamt 6 RTs ein, wovon 4 mit jeweils einem externen Thermometer gepeert sind (die restlichen 2 befinden sich in einem großen Raum und sind mit einem Homematic HM-TC-IT-WM-W-EU gepeert, laufen daher also eigenständig und stabil..).
Auffällig ist, dass eigentlich 3 von den 4 RTs mit externem Fühler recht stabil laufen, nur einer kommt öfters aus dem Tritt.
Es wäre super, wenn jemand noch ein paar Tipps hätte, wie man der Ursache des Problems (und damit hoffentlich auch einer Lösung) näher kommen könnte.
Danke schon mal und Grüße
Hannes
p.s.: noch eine andere Kleinigkeit: die von den at's durchgeführten set Kommandos für die virtuellen Channels laufen anscheinend ins globale Logfile; dort werden alle Einträge á la "CUL_HM set ... virtTemp ..." aufgeführt. Wo und wie kann man denn das abstellen?
Zitatp.s.: noch eine andere Kleinigkeit: die von den at's durchgeführten set Kommandos für die virtuellen Channels laufen anscheinend ins globale Logfile; dort werden alle Einträge á la "CUL_HM set ... virtTemp ..." aufgeführt. Wo und wie kann man denn das abstellen?
verbose entsprechend einstellen.
ansonnsten starte mal apptime und poste "apptime max" nachdem fehler aufgetreten sind.
Hmm, nach starten von apptime, taucht folgendes im Log auf:
2017.12.03 14:12:46 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 26.
2017.12.03 14:12:46 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 60.
Kann ich davon ausgehen, dass dies trotzdem funktioniert?
einfach mal apptime max aufrufen, dann sollten infos kommen.
So, ich habe apptime gestern um 14:12 gestartet.
Typisch Vorführeffekt ist es dann bis heute mittag komplett stabil gelaufen.
Heute gegen ca. 11:45 gab es dann wieder einen Fallback auf die interne Temperatur an besagtem RT, der sich aber recht zügig gegen 11:50 bereits wieder auf die externe eingestellt hat.
Ich habe apptime max zwar erst jetzt gerade aufgerufen, aber vielleicht kannst du ja trotzdem was erkennen (ist natürlich jetzt ein großer Erfassungszeitraum):
name function max count total average maxDly TS Max call param Max call
hmusb HMLAN_Read 5148 13895 2386869 171.78 0 03.12. 21:47:28 HASH(hmusb)
logdb DbLog_Log 4825 24499 408930 16.69 0 03.12. 21:47:28 HASH(logdb); HASH(Hannes_Thermostat_Climate)
myJeeLink JeeLink_Read 4167 154592 1406247 9.10 0 04.12. 00:41:17 HASH(myJeeLink)
WEB FW_Read 4020 236 43809 185.63 0 04.12. 21:58:28 HASH(WEB)
logdb DbLog_Get 2370 42 13278 316.14 0 03.12. 23:42:35 HASH(logdb); logdb; HISTORY; INT; 2017-12-02_00:00:00; 2017-12-03_00:00:01; Thermometer_Aussen:temperature::
WEB_192.168.3.62_7436 FW_Read 826 14 1931 137.93 0 04.12. 21:59:07 HASH(WEB_192.168.3.62_7436)
WEB_192.168.3.62_7446 FW_Read 823 3 1672 557.33 0 04.12. 21:59:12 HASH(WEB_192.168.3.62_7446)
WEB_192.168.3.62_7445 FW_Read 801 1 801 801.00 0 04.12. 21:59:09 HASH(WEB_192.168.3.62_7445)
WEB_192.168.3.62_7443 FW_Read 791 9 1052 116.89 0 04.12. 21:59:11 HASH(WEB_192.168.3.62_7443)
WEB_192.168.3.62_7444 FW_Read 756 2 774 387.00 0 04.12. 21:59:10 HASH(WEB_192.168.3.62_7444)
WEBphone FW_Read 262 27 5262 194.89 0 03.12. 23:42:40 HASH(WEBphone)
tmr-at_Exec HASH(0x2bc4dd0) 120 953 30656 32.17 2712 04.12. 06:50:43 HASH(at_Kueche_VirtualTemp)
tmr-at_Exec HASH(0x29581f8) 118 953 28716 30.13 2706 04.12. 06:50:43 HASH(at_Wohnzimmer_VirtualTemp)
tmr-CUL_HM_valvePosUpdt valvePos:3732F201 91 753 28534 37.89 442 03.12. 15:37:10 valvePos:3732F201
tmr-at_Exec HASH(0x2a62098) 87 953 27135 28.47 2681 03.12. 20:20:43 HASH(at_Schlafzimmer_VirtualTemp)
tmr-CUL_HM_valvePosUpdt valvePos:3732F101 85 753 28717 38.14 404 04.12. 18:59:21 valvePos:3732F101
tmr-CUL_HM_valvePosUpdt valvePos:3732F401 82 752 28620 38.06 380 04.12. 17:29:51 valvePos:3732F401
tmr-CUL_HM_valvePosUpdt valvePos:3732F301 79 751 28857 38.42 531 04.12. 06:52:19 valvePos:3732F301
ZE.Batterie readingsGroup_Notify 70 24499 6344 0.26 0 03.12. 20:40:52 HASH(ZE.Batterie); HASH(Kueche_Heizung)
tmr-at_Exec HASH(0x2ba1a00) 69 953 26811 28.13 2641 03.12. 16:06:43 HASH(at_Bad_VirtualTemp)
vCul_K_Temp CUL_HM_Set 65 267 9040 33.86 0 04.12. 06:52:43 HASH(vCul_K_Temp); vCul_K_Temp; virtTemp; 17
Zitat von: Kottellettenhorst am 03 Dezember 2017, 10:16:12
...Auffällig ist, dass eigentlich 3 von den 4 RTs mit externem Fühler recht stabil laufen, nur einer kommt öfters aus dem Tritt....
Damit habe ich mich auch längere Zeit "rumgeschlagen".
Die gute Nachricht vorweg... es funktioniert. :)
Die schlechte Nachricht... es ist sehr vom passenden Timing abhängig.
allgemeine Tipps (aus meiner Erfahrung, muss nicht generell so sein):
- probiere mit der angesprochenen cyclicMsgOffset rum
- stelle für die at einen kleinen "Versatz" ein (aligntime)
- nach Änderungen warten, also ruhig erst 1-2 Tage beobachten
- Updates von FHEM ändern gerne mal das Zeitverhalten des Systems, wodurch es subjektiv zwischendurch besser oder schlechter läuft
- Du kannst die Temperaturdifferenz für die Fenster-offen-Erkennung anpassen (Standard ist 1,4K oder so), wenn er nicht umschalten soll
- wenn Du einen Fensterkontakt dran hast, deaktiviere die interne Fenster-offen-Erkennung
tmr-at_Exec HASH(0x2bc4dd0) 120 953 30656 32.17 2712 04.12. 06:50:43 HASH(at_Kueche_VirtualTemp)
tmr-at_Exec HASH(0x29581f8) 118 953 28716 30.13 2706 04.12. 06:50:43 HASH(at_Wohnzimmer_VirtualTemp)
tmr-at_Exec HASH(0x2a62098) 87 953 27135 28.47 2681 03.12. 20:20:43 HASH(at_Schlafzimmer_VirtualTemp)
tmr-at_Exec HASH(0x2ba1a00) 69 953 26811 28.13 2641 03.12. 16:06:43 HASH(at_Bad_VirtualTemp)
hier sieht man die verzögerungen, die die timer erfahren haben (maxDly). da die zeiten mit deiner beobachtung nicht passen, werden sie wohl öfter verzögert. hier nur der max wert. ich denke, dass die rt nur auf intern umschalten, wenn mehrere kommunikationen hintereinander fehlschlagen.
ansonsten sind die ersten 5 zeilen "unschön", da fhem bis zu 5sek stillstand. es sind wohl aber keine regelmässigen verzögerungen, da die avg werte ziehmlich niedrig sind. läuft noch etwas anderes auf deinem server? dblog im auge behalten, auslagern, reduzieren? letztendlich gilt, je weniger verzögerungen, desto reibunggsloser der betrieb.
Ein list aller at's würde mich interessieren
Wow, vielen Dank erst einmal für die rege Beteiligung :)
Zunächst zur Klärung der at's.
Diese setzen alle 2 Minuten die virtTemp des jeweiligen virtuellen Channels - allerdings nur, wenn diese sich tatsächlich unterscheidet, um nicht unnötig weitere events zu triggern.
Daher sollten die at's meines Erachtens auch keinen negativen Einfluss auf das Verhalten der RTs haben. (das Peering ist ja nur zwischen dem Weather Channel des RTs und dem Channel des virtuellen HM CUL..)
Ich weiß deshalb auch nicht, was mit
Zitatstelle für die at einen kleinen "Versatz" ein (aligntime)
gemeint ist, bzw. in wie fern das etwas ändern sollte..?
list at_Bad_VirtualTemp
Internals:
COMMAND { my $T=(ReadingsVal("Thermometer_Bad","temperature",20.0)); my $TC = (ReadingsVal("vCul_B_Temp","temperature",20.0)); if($T ne $TC){ fhem "set vCul_B_Temp virtTemp $T" }}
DEF +*00:02 { my $T=(ReadingsVal("Thermometer_Bad","temperature",20.0)); my $TC = (ReadingsVal("vCul_B_Temp","temperature",20.0)); if($T ne $TC){ fhem "set vCul_B_Temp virtTemp $T" }}
NAME at_Bad_VirtualTemp
NR 143
NTM 20:30:39
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 20:30:39
TIMESPEC 00:02
TRIGGERTIME 1512502239.66276
TRIGGERTIME_FMT 2017-12-05 20:30:39
TYPE at
READINGS:
2017-12-05 20:28:39 state Next: 20:30:39
Attributes:
room Bad,LaCrosse
list at_Kueche_VirtualTemp
Internals:
COMMAND { my $T=(ReadingsVal("Thermometer_Kueche","temperature",20.0)); my $TC = (ReadingsVal("vCul_K_Temp","temperature",20.0)); if($T ne $TC){ fhem "set vCul_K_Temp virtTemp $T" }}
DEF +*00:02 { my $T=(ReadingsVal("Thermometer_Kueche","temperature",20.0)); my $TC = (ReadingsVal("vCul_K_Temp","temperature",20.0)); if($T ne $TC){ fhem "set vCul_K_Temp virtTemp $T" }}
NAME at_Kueche_VirtualTemp
NR 149
NTM 20:32:39
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 20:32:39
TIMESPEC 00:02
TRIGGERTIME 1512502359.75324
TRIGGERTIME_FMT 2017-12-05 20:32:39
TYPE at
READINGS:
2017-12-05 20:30:39 state Next: 20:32:39
Attributes:
room Küche,LaCrosse
list at_Kueche_VirtualTemp
Internals:
COMMAND { my $T=(ReadingsVal("Thermometer_Wohnzimmer","temperature",20.0)); my $TC = (ReadingsVal("vCul_WZ_Temp","temperature",20.0)); if($T ne $TC){ fhem "set vCul_WZ_Temp virtTemp $T" }}
DEF +*00:02 { my $T=(ReadingsVal("Thermometer_Wohnzimmer","temperature",20.0)); my $TC = (ReadingsVal("vCul_WZ_Temp","temperature",20.0)); if($T ne $TC){ fhem "set vCul_WZ_Temp virtTemp $T" }}
NAME at_Wohnzimmer_VirtualTemp
NR 137
NTM 20:34:39
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 20:34:39
TIMESPEC 00:02
TRIGGERTIME 1512502479.5724
TRIGGERTIME_FMT 2017-12-05 20:34:39
TYPE at
READINGS:
2017-12-05 20:32:39 state Next: 20:34:39
Attributes:
room LaCrosse,Wohnzimmer
list at_Schlafzimmer_VirtualTemp
Internals:
COMMAND { my $T=(ReadingsVal("Thermometer_Schlafzimmer","temperature",20.0)); my $TC = (ReadingsVal("vCul_SZ_Temp","temperature",20.0)); if($T ne $TC){ fhem "set vCul_SZ_Temp virtTemp $T" }}
DEF +*00:02 { my $T=(ReadingsVal("Thermometer_Schlafzimmer","temperature",20.0)); my $TC = (ReadingsVal("vCul_SZ_Temp","temperature",20.0)); if($T ne $TC){ fhem "set vCul_SZ_Temp virtTemp $T" }}
NAME at_Schlafzimmer_VirtualTemp
NR 156
NTM 20:34:39
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 20:34:39
TIMESPEC 00:02
TRIGGERTIME 1512502479.84676
TRIGGERTIME_FMT 2017-12-05 20:34:39
TYPE at
READINGS:
2017-12-05 20:32:39 state Next: 20:34:39
Attributes:
room Schlafzimmer,LaCrosse
Ein Blick in den (leider extrem ungenügend kommentierten) Source Code von 10_CUL_HM.pm offenbart, dass cyclicMsgOffset nur in der Funktion CUL_HM_valvePosUpdt verwendet wird. Ich denke also, dass eher die apptime Einträge für tmr-CUL_HM_valvePosUpdt interessant sind, aber ich vermag hier kein Problem zu erkennen..
Auf gut Glück mit dem cyclicMsgOffset Parameter rumzuspielen hat wie gesagt bisher nicht zum Erfolg verholfen (und ist auch müßig, ohne wirklich die Funktionsweise dahinter zu verstehen).
Ich habe mal für den einen virtuellen HM CUL das verbose level auf 5 gesetzt und werde mal die berechneten nextTimer Werte beobachten - vielleicht kann man hier einen Zusammenhang feststellen, wenn die Temperatur nicht übernommen wird.
Was mir hierbei schon auf Anhieb auffällt, ist dass die Temperatur vom Heizung_Bad_Climate mindestens noch während der ersten drei CUL_HM_valvePosUpdt Durchläufe nach dem set virtTemp 17.3 auf 17.2 stehen bleibt - der Wert wird also hier bereits nicht übernommen. Ich sehe nur nicht warum..
Zitat
2017.12.05 20:50:39 3: CUL_HM set vCul_B_Temp virtTemp 17.3
2017.12.05 20:52:53 5: CUL_HM vCul_B_Temp m:26 ->27 t:1512503573.36629->1512503715.31629 M:1512503573.37213 :141.95
2017.12.05 20:55:15 5: CUL_HM vCul_B_Temp m:27 ->28 t:1512503715.32213->1512503842.77213 M:1512503715.32585 :127.45
2017.12.05 20:57:22 5: CUL_HM vCul_B_Temp m:28 ->29 t:1512503842.77585->1512504019.97585 M:1512503842.78268 :177.2
2017.12.05 21:00:19 5: CUL_HM vCul_B_Temp m:29 ->30 t:1512504019.98268->1512504182.68268 M:1512504019.98666 :162.7
2017.12.05 21:03:02 5: CUL_HM vCul_B_Temp m:30 ->31 t:1512504182.68666->1512504330.88666 M:1512504182.69038 :148.2
Für welches device kann ich denn das verbose level erhöhen, um zu sehen, wann dem RT tatsächlich die Temperatur übergeben wird?
hier ist was für die weihnachtstage:
https://forum.fhem.de/index.php/topic,45735.0.html (https://forum.fhem.de/index.php/topic,45735.0.html)
Nach kurzen Querlesen:
Will man einen externen weathersensor mit einem RT peeren muss man ein wechselndes Timing einhalten. Ein at kann das nicht errechnen. Man sollte einen virtuellen Kanal einrichten und diesen mit dem rtweather peeren.
Die Temperatur setzt man im virtuellen Kanal welcher sich um das senden kümmert. Ein einsparen von Messages ist kritisch da der rt beim ausbleiben von Messages auf seinen internen sensor Umschaltet
@frank
Danke für den Link - da werde ich mich dann mal durchwälzen, vielleicht finde ich dort ja einen Hinweis..
@martinp876
Alles was du schreibst ist bereits bekannt und auch so umgesetzt (thread bitte aufmerksam lesen), ist also nicht weiter relevant.
Zitat von: Kottellettenhorst am 05 Dezember 2017, 21:09:35...
Zunächst zur Klärung der at's.
Diese setzen alle 2 Minuten die virtTemp des jeweiligen virtuellen Channels - allerdings nur, wenn diese sich tatsächlich unterscheidet, um nicht unnötig weitere events zu triggern.
...
Zitat von: martinp876 am 06 Dezember 2017, 06:30:34
...Ein einsparen von Messages ist kritisch da der rt beim ausbleiben von Messages auf seinen internen sensor Umschaltet
Zitat von: Kottellettenhorst am 06 Dezember 2017, 09:57:22
...@martinp876
Alles was du schreibst ist bereits bekannt und auch so umgesetzt (thread bitte aufmerksam lesen), ist also nicht weiter relevant.
Nach kurzem Querlesen könnte es noch interessant werden.
Betateilchen würde schon mal Popcorn holen. ;)
ähm, okay... *räusper*
sorry an @martinp876, da hätte ich deine Nachricht wohl etwas aufmerksamer lesen müssen ::) :-X
Okay, um das noch mal zu rekapitulieren: die auf der Doku Seite zum RT angegebene Konfiguration des at's ist auf 2 Minuten festgelegt und setzt immer den virtTemp, auch wenn diese sich nicht verändert hat. Verstehe ich das richtig, dass der virtuelle Channel KEINE neue Temperatur an den RT melden würden, wenn nicht zuvor ein neues set virtTemp erfolgt ist, auch wenn diese unverändert ist?
Dies erklärt meines Erachtens aber dennoch nicht, warum wie in meinem letzten Post geschildert auch nach einer geänderten virtTemp mehrere Zyklen benötigt werden, bis die Temperatur am RT angenommen wird..
Aber gut, ich schmeiß den Vergleich mit der Vortemperatur mal wieder raus, müsste sich ja einfach überprüfen lassen, ob es sich dann stabiler verhält..
Mach ein Notify was auf den externen Tempsensor triggert und automatisch dann den erhaltenen EVENT ins Virt Device schreibt.
Ggf. den externen Tempsensor noch mit sinnvollen Werten für "event-on-change-reading" und (https://wiki.fhem.de/wiki/Event-min-interval#Wechselwirkungen) "event-min-interval" etwas in der Gesprächigkeit bändigen ;) .
Gruß, Beta-User
ZitatGgf. 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 ;)
event-min-interval (temperature|humidity).*:600,(battery).*:86400
event-on-change-reading temperature.*:0.2,humidity.*:2
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
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..
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
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?
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.
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..)
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.
lest doch einfach den thread.
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.
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 (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.
ZitatBei 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.
Zitat von: Owesle@outlook.de am 07 Dezember 2017, 12:33:36
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 (https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperatursensoren)
Gute Idee und erledigt
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
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.