Autor Thema: WeekdayTimer - Status RHS bei Struktur mit HM-TC-IT-WM-W-EU nicht stabil  (Gelesen 299 mal)

Offline Lars_

  • Jr. Member
  • **
  • Beiträge: 50
Hallo zusammen,
ich habe meine HC auf weekdaytimer umgestellt und dabei ist mir aufgefallen, dass der Status der mit den RT's verbundenen RHS-Sensoren bei einer Struktur mit einem HM-TC-IT-WM-W-EU nur sehr kurz berücksichtigt wird, wenn ein Fenster geöffnet wurde. (, d.h. aber zumindest, dass die Verbindung RHS und RT funktioniert)
Nach kurzer Zeit wird die ursprüngliche, im WeekdayTimer für die Struktur mit dem Homematic Funk-Wandthermostat ( HM-TC-IT-WM-W-EU) definierte Soll-Temperatur, wieder auf die RT's übertragen, obwohl das Fenster noch geöffnet ist und das Fenster-auf-Symbol auf dem RT noch angezeigt wird, bei HeatingControl ist das so nicht passiert.
Die Konfiguration "windowSensor" aus HeatingControl wurde erfolgreich in "WDT_delayedExecutionDevices" in WeekdayTimer migriert. Bei WeekdayTimern die nur auf einen RT gehen, tritt das Problem soweit ich das in der kurzen Zeit sehe, nicht auf.
Kennt jemand das Problem und hat jemand eine Idee woher das kommt und wie ich das verhindern kann ode Rist das kein Problem  :D ?
Gruß und danke schon mal für die eure Ideen.
Lars

HeatingControl:
define HC_WEZ_hwl Heating_Control S_WEZ.Heizung de Mo-So|00:00|16.5 Mo-Mi|05:00|18.5 Do,Fr|05:25|19.5 Mo-Mi,Sa,So|06:00|18.5 Do,Fr|06:45|19.5 Sa,So|07:00|19.5 Sa,So|08:00|21.5 Mo|12:00|19.5 Di-Mi,Sa,So|12:00|20.5 Do-Fr|12:00|21.5 Di-Mi|13:30|21.5 Di,Mi|15:30|22.0 Mo|15:30|20.5 Sa,So|16:30|22.0 Di-So|18:00|22.0 Mo-Do|22:45|20.5 Fr,Sa,So|23:15|20.5 Mo-So|23:30|18.5 {if ((Value("homestatus.Parents") eq "yes") && (Value("JahresZeit") eq "Winter")) {fhem("set $NAME desired-temp $EVENT")}}
setuuid HC_WEZ_hwl 5cced199-f33f-d7a9-67cb-b947b16461b35c29
attr HC_WEZ_hwl DbLogExclude .*
attr HC_WEZ_hwl commandTemplate set $NAME desired-temp $EVENT
attr HC_WEZ_hwl verbose 2
attr HC_WEZ_hwl windowSensor wz_og_RHS
WeekdayTimer:
define HC_WEZ_hwl WeekdayTimer S_WEZ.Heizung de Mo-So|00:00|16.5 Mo-Mi|05:00|18.5 Do,Fr|05:25|19.5 Mo-Mi,Sa,So|06:00|18.5 Do,Fr|06:45|19.5 Sa,So|07:00|19.5 Sa,So|08:00|21.5 Mo|12:00|19.5 Di-Mi,Sa,So|12:00|20.5 Do-Fr|12:00|21.5 Di-Mi|13:30|21.5 Di,Mi|15:30|22.0 Mo|15:30|20.5 Sa,So|16:30|22.0 Di-So|18:00|22.0 Mo-Do|22:45|20.5 Fr,Sa,So|23:15|20.5 Mo-So|23:30|18.5 {if ((Value("homestatus.Parents") eq "yes") && (Value("JahresZeit") eq "Winter")) {fhem("set $NAME desired-temp $EVENT")}}
setuuid HC_WEZ_hwl 5e105d41-f33f-d7a9-2a40-6933174141da311b
attr HC_WEZ_hwl DbLogExclude .*
attr HC_WEZ_hwl WDT_Group former_HC
attr HC_WEZ_hwl WDT_delayedExecutionDevices wz_og_RHS
attr HC_WEZ_hwl commandTemplate set $NAME desired-temp $EVENT
attr HC_WEZ_hwl verbose 2
« Letzte Änderung: 04 Januar 2020, 18:33:10 von Lars_ »
Fhem auf rpi 3   fhem auf rpi b+
1 x CULHM/jeelink v3c   1 x CULHM
7 x HM-CC-RT-DN   3 x HM-CC-RT-DN
5 x HM-Sec-RHS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9267
  • eigentlich eher "user" wie "developer"
Hmm,

ich kann mir noch nicht so recht vorstellen, dass das mit der Umstellung zu tun haben soll - intern wurde seit langem praktisch derselbe Code genutzt (nämlich der aus WDT).

Muß ich mir ggf. mal in Ruhe ansehen, sollte aber wissen, ob mit "Struktur" gemeint ist, dass eine structure geschaltet wird. Hilfreich wäre weiter ein Event-Monitor-Auszug, der nur die beteiligten Devices erfaßt (nicht als screenshot, bitte!). War das im Regelbetrieb oder im Zusammenhang mit einem Neustart?

Bitte kontrolliere auch zur Sicherheit nochmal die Peerings vom RHS.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Lars_

  • Jr. Member
  • **
  • Beiträge: 50
Der Fehler tritt im Normalbetrieb auf, also nicht direkt nach dem Update.
Ich schaue mir die Peerings morgen nochmal an, danke schon mal!
Jup, mit Struktur meinte ich structure :)
Fhem auf rpi 3   fhem auf rpi b+
1 x CULHM/jeelink v3c   1 x CULHM
7 x HM-CC-RT-DN   3 x HM-CC-RT-DN
5 x HM-Sec-RHS

Offline Lars_

  • Jr. Member
  • **
  • Beiträge: 50
moin Beta-User,
ich habe mir die Peerings (RT's <-> RHS) angeschaut, die passen soweit.
Zusätzlich zu den Peerings zwischen dem RHS und den RT's, habe ich (per peerchan) noch den RHS mit dem Homematic Funk-Wandthermostat ( HM-TC-IT-WM-W-EU) verbunden. Jetzt wird der Fenster-Auf Status auch vom Wandthermostat erkannt und auf die Fenster-auf-Temperatur auch im HM-TC-IT-WM-W-EU gesetzt (in meinem Fall 12 Grad), damit wird die Fenster-Auf-Temperatur der RT's nicht mehr überschrieben und bleibt wie geplant auf dem Fenster-auf-Wert 12 Grad.

Sollte ich mich so vertan haben und das ging früher ohne das Peering RHS <-> HM-TC-IT-WM-W-EU auch schon schief?

Wie auch immer, das scheint mir gelöst zu sein.

Gruß und danke für die Denkanstösse
Lars
Fhem auf rpi 3   fhem auf rpi b+
1 x CULHM/jeelink v3c   1 x CULHM
7 x HM-CC-RT-DN   3 x HM-CC-RT-DN
5 x HM-Sec-RHS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9267
  • eigentlich eher "user" wie "developer"
Solche Umstellungen sind immer Anlaß, mal das setup zu hinterfragen.
Was die Frage angeht, was man sinnvollerweise mit was peert, hatte ich im Kopf, dass einige Experten dazu neigen, nur den WT mit dem FK zu peeren. Ich selbst mache das sowieso verzögert mit einem virtuellen Kontakt - kurzfristige Öffnungen werden rausgefiltert und es wird nur gesendet, wenn überhaupt Heizperiode angesagt ist, gepeert ist nur der WT (wo vorhanden)...

Setzt du das dann noch bei Gelegenheit auf [gelöst]?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}