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

[Kottellettenhorst]

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?

[frank]

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?

verbose entsprechend einstellen.

ansonnsten starte mal apptime und poste "apptime max" nachdem fehler aufgetreten sind.

[Kottellettenhorst]

Hmm, nach starten von apptime, taucht folgendes im Log auf:

Code Auswählen Erweitern

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?

[frank]

einfach mal apptime max aufrufen, dann sollten infos kommen.

[Kottellettenhorst]

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):

Code Auswählen Erweitern


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


[Hollo]

...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

[frank]

Code Auswählen Erweitern

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.

[CoolTux]

Ein list aller at's würde mich interessieren

[Kottellettenhorst]

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

stelle für die at einen kleinen "Versatz" ein (aligntime)

gemeint ist, bzw. in wie fern das etwas ändern sollte..?

Code Auswählen Erweitern


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..

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?

[frank]

hier ist was für die weihnachtstage:
https://forum.fhem.de/index.php/topic,45735.0.html

[martinp876]

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

[Kottellettenhorst]

@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.

[Hollo]

...
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.
...

...Ein einsparen von Messages ist kritisch da der rt beim ausbleiben von Messages auf seinen internen sensor Umschaltet

...@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. 

[Kottellettenhorst]

ähm, okay... *räusper*

sorry an @martinp876, da hätte ich deine Nachricht wohl etwas aufmerksamer lesen müssen 

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..

[CoolTux]

Mach ein Notify was auf den externen Tempsensor triggert und automatisch dann den erhaltenen EVENT ins Virt Device schreibt.