Weekdaytimer nach Delay wegen geöffnetem Fenster kein neuer Wert im FHT-Thermost

Begonnen von dlehmann69, 05 Oktober 2019, 12:22:49

Vorheriges Thema - Nächstes Thema

dlehmann69

Hallo,
ich habe jetzt für die startende Heizperiode mal die WeekdayTimer für die Thermostate nutzen wollen. Soweit so gut. Leider bekommt ein Thermostat nach dem Delay wegen einem geöffnetem Fenster keine aktuell gültige Temperatur. Hier die Auszüge aus der Config und dem Log.
defmod HZT_Schlafen WeekdayTimer sz_heizung 7|05:45|20.0 7|20:15|16.0 8|05:45|20.0 8|06:55|16.0 8|16:00|20.0 8|20:15|16.0
attr HZT_Schlafen WDT_Group Heizung_Eco
attr HZT_Schlafen WDT_delayedExecutionDevices sz_fenster
attr HZT_Schlafen commandTemplate set $NAME desired-temp $EVENT
attr HZT_Schlafen group Heizplan
attr HZT_Schlafen room Heizung
attr HZT_Schlafen sortby 4
attr HZT_Schlafen switchInThePast 1

setstate HZT_Schlafen open window
setstate HZT_Schlafen 2019-10-05 09:50:00 currValue 20.0
setstate HZT_Schlafen 2019-10-05 09:50:00 nextUpdate 2019-10-05 20:15:00
setstate HZT_Schlafen 2019-10-05 09:50:00 nextValue 16.0
setstate HZT_Schlafen 2019-10-05 09:49:00 state open window

2019.10.05 09:50:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.05 06:55:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 06:55
2019.10.05 05:45:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 05:45
2019.10.05 05:45:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'


Der state ist immer noch auf "Window open", obwohl dies geschlossen ist. Dies wurde um 9:55 Uhr ja auch erkannt. Nur steht die Heizung immer noch auf 16°C. Mit einem set HZT_Schlafen WDT_Params single wird die Temperatur dann übertragen. Das switchInThePasthabe ich mal gesetzt, ändert sich aber nichts. Sollte ja bei einem Thermostat auch bereits so sein. sz_heizung ist ein FHT80B Thermostat.
Habe ich etwas überlesen in der commandref?

Wenn noch mehr Infos benötigt werden, bitte melden.

Vielen Dank und Grüße
Dirk
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

amenomade

Das ist merkwürdig:2019.10.05 06:55:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 06:55
da der 6:55 Uhr Timer eigentlich nur an Wochentage greifen sollte.

Es sei denn, Du nutzt die noWeekEnd Funktionalität: was sagt { IsWe("today") } im Kommandofeld von Fhem?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

dlehmann69

Ergebnis von { IsWe("today") } ist 1. Demnach sollte also Wochenende sein. Alle anderen Timer arbeiten auch nach dem Programm für das Wochenende.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

amenomade

Hmm vielleicht muss Beta-User mal schauen
Ich würde verbose 5 setzen, und auch eine Log von sz_fenster erstellen. Und Morgen früh gucken...
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Beta-User

Hallo zusammen,

ich habe den Verdacht, dass das mit dem hier eng verwandt ist: https://forum.fhem.de/index.php/topic,104167.0.html. Wird etwas dauern, aber es würde mir sehr helfen, wenn du als workaround mal noch einen "gedoppelten" Schaltzeitpunkt einfügen könntest, nämlich 23:59 Uhr - 16.0°C.

Damit könnte ich besser lokalisieren, ob das Thema tatsächlich auf den letzten Schaltzeitpunkt beschränkt ist oder nicht. Danke vorab und sorry für die Unannehmlichkeiten...

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dlehmann69

Hallo,
ist eingefügt. Und da ich morgen zuhause bin ist morgen laut Plan auch wieder Wochenende. Sollte also morgen wieder so laufen. Melde mich morgen mit den Ergebnissen.
GrüßeDirk
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

dlehmann69

Guten Morgen,

so das Fenster ist geschlossen. Leider keine Änderungen mit dem zusätzlichen Timer. Hier die zugehörigen Meldungen aus dem FHEM Log.

Zu sehen ist auch, dass er beide Timer um 5:45 Uhr berücksichtigt, den fürs Wochenende und den für Nicht-Wochenende. Müsste ja eigentlich auch nicht sein. Passt hier vielleicht etwas nicht? 6:55 Uhr ist ja auch für Nicht-Wochenende. { IsWe("today") } liefert heute auch wieder 1.


2019.10.07 07:38:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.07 06:55:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 06:55
2019.10.07 05:45:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 05:45
2019.10.07 05:45:00 3: [HZT_Schlafen] timer at 23:59 skiped by new timer at 05:45
2019.10.06 23:59:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
2019.10.06 20:15:00 2: FHT set sz_heizung desired-temp 16.0
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Beta-User

Hallo zusammen,

nachdem ich jetzt zugegebenermaßen einige Zeit ratlos auf den Code von WDT (bzw. meine letzten Änderungen daran) geschaut habe: Bist du sicher, dass
a) der Befehl nicht an das Device versendet wurde (und dort evtl. nur nicht ankam), und (wenn das sicher ist)
b) das jemals funktioniert hat?

Ich kann an den Codeänderungen (Vergleich zwischen Versionen 19806 und 19043) nichts erkennen, was diese Art Auswirkung haben dürfte. Da ist zwar v.a. einiges umgestellt wegen IsWe() und ein dummy-Fensterkontakt sollte jetzt auch gehen, aber die grundsätzliche Logik usw. wurde nicht angefaßt.
Wenn du einen abgesicherten Test mit einer Vorversion machen willst, müßte 19043 eigentlich ausreichen, ansonsten wäre mindestens auf 18591 zurückzugehen (die kann aber nur ein holiday2we-Device, und die Änderungen zwischen diesen beiden Versionen sind (programmiertechnisch) nichts gravierendes).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dlehmann69

Hallo,
a) Ganz sicher bin ich mir mit dem Timer nicht. Generell funktioniert der Timer, da er ja 20:15 Uhr auf 16°C zurück stellt. Das funktioniert. Auch die anderen Timer funktionieren soweit bei den anderen Thermostaten, nur gibt es hier bisher nicht den Fall mit dem geöffneten Fenster zum Schaltzeitpunkt. Ich habe die Timer erst letzte Woche am Mittwoch eingerichtet. Vorher gab es noch keine Timer.

b) Ich teste morgen früh noch eine andere Konstellation. Ich werde das Fenster zwischen 5:45 und 6:55 schließen. Dann werden wir sehen was dann funktioniert.

Danach kann ich ja immer noch eine ältere Version testen.

Eine Frage für mein Verständnis. Ich habe den Delay bisher so verstanden, das der Befehl erst gesendet wird, wenn das Fenster geschlossen wird. Nicht das bei geöffnetem Fenster der Thermostat eine neue Temperatur bekommt und beginnt zu heizen.

Grüße
Dirk
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Beta-User

Dann noch zwei Anmerkungen:

- die beiden Morgendlichen Timer zu trennen nach 7+8 macht wenig Sinn, wenn die für $we und !$we auf demselben Zeitpunkt liegen (das _scheint_ aber nicht das Problem zu sein)
- Das offene Fenster sollte eine Verzögerung bewirken, der Befehl geht also erst raus, wenn das Fenster zu ist. Das allerdings nicht Event-basiert, sondern durch eine Timer-Funktion, die jede Minute prüft, ob das Fenster noch offen ist. Von daher ist eine Ausgabe wie
Zitat2019.10.07 07:38:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
mMn. eigentlich i.O., da der Zustand korrekt ausgewertet wurde. Leider ist an der Stelle der Code (für meine Begriffe) etwas eigenwillig geschrieben, aber wie gesagt: an sich unverändert, aber man würde erwarten, dass vorher oder kurz danach auch die Meldung kommt, dass das ausgeführt wurde...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dlehmann69

Hallo,
vielleicht ist das mit den beiden Timern zur gleichen Zeit für $we und !$we doch ein Problem. Ich habe die beiden Timer jetzt mal zu einem Timer für jeden Tag zusammen gefasst. Mal sehen was nun morgen passiert. Ich kann ja morgen noch einmal mit geöffnetem Fenster testen und übermorgen mit Fenster geschlossen.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

dlehmann69

Guten Morgen,
mit geändertem Timer sieht es leider immer noch so aus. Kein aktueller Sollwert an das Thermostat. Immer noch der Eintrag um 6:55 Uhr, das der Timer geskiped wurde.

Meine aktuelle Definition
defmod HZT_Schlafen WeekdayTimer sz_heizung 05:30|20.0 7|20:25|16.0 8|06:55|16.0 8|16:00|20.0 8|20:15|16.0
attr HZT_Schlafen WDT_Group Heizung_Eco
attr HZT_Schlafen WDT_delayedExecutionDevices sz_fenster
attr HZT_Schlafen commandTemplate set $NAME desired-temp $EVENT
attr HZT_Schlafen group Heizplan
attr HZT_Schlafen room Heizung
attr HZT_Schlafen sortby 4
attr HZT_Schlafen switchInThePast 1

setstate HZT_Schlafen open window
setstate HZT_Schlafen 2019-10-08 07:58:00 currValue 20.0
setstate HZT_Schlafen 2019-10-08 07:58:00 nextUpdate 2019-10-08 20:25:00
setstate HZT_Schlafen 2019-10-08 07:58:00 nextValue 16.0
setstate HZT_Schlafen 2019-10-08 07:57:00 state open window


Die Einträge im Log
2019.10.0807:58:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.0806:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.0805:30:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'


Aktuell ist auf jeden Fall Wochenende, das habe ich geprüft. Und da ich die Woche zuhause bin, ist die gesamte Woche in der zugehörigen holiday Datei eingetragen. Das kommt wohl auch im Timer an, wie man an den Profileinträgen erkennt.
Profil 0: Sonntag    05:30:00 20.0, 20:25:00 16.0
Profil 1: Montag    05:30:00 20.0, 20:25:00 16.0
Profil 2: Dienstag    05:30:00 20.0, 20:25:00 16.0
Profil 3: Mittwoch    05:30:00 20.0, 20:25:00 16.0
Profil 4: Donnerstag    05:30:00 20.0, 20:25:00 16.0
Profil 5: Freitag    05:30:00 20.0, 20:25:00 16.0
Profil 6: Samstag    05:30:00 20.0, 20:25:00 16.0
Profil 7: Wochenende    20:25:00 16.0
Profil 8: Werktags    06:55:00 16.0, 16:00:00 20.0, 20:15:00 16.0


Ich werde morgen früh nun noch einmal testen, wenn ich das Fenster vor 6:55 Uhr schließe. Dann berichte ich morgen wieder.

Grüße
Dirk
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Beta-User

Hmm, das scheint eventuell wirklich mit der Wochenendbehandlung zusammenzuhängen. Bin mal auf morgen gespannt, vielleicht komme ich auch dazu, mir den Code dazu nochmal näher anzusehen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dlehmann69

Guten Morgen,

so der Test ist gelaufen. Heute ist alles so wie es soll. Fenster zwischen den beiden Zeiten geschlossen. Thermostat geht auf neue Temperatur und bleibt dort auch.

2019.10.09 06:19:00 2: FHT set sz_heizung desired-temp 20.0
2019.10.09 06:19:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.09 05:30:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'


Scheint auch aus meiner bescheidenen Sicht auf die Dinge ein Thema mit der Wochenendbehandlung zu sein. Aber nur, wenn das Fenster offen ist und dann ein neuer Timer kommt. Sonst funktioniert ja das Ganze.

Grüße
Dirk
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Beta-User

Hast du eigentlich die weekEnd-Datei auch als holiday-Device definiert oder nur in das holiday2we-Attribut eingetragen?

(Wenn nicht definiert, bitte nachdefinieren und dann den Test wiederholen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files