Wait Timer bei DOIF wird nicht abgebrochen, wenn Bedingung wieder unwahr wird

Begonnen von edition, 02 Mai 2023, 16:54:18

Vorheriges Thema - Nächstes Thema

edition

Guten Tag zusammen

Ich habe mir ein DOIF gebaut, welches meine Gastherme ausschalten soll, wenn alle Heizkörperthermostate geschlossen sind. Wenn ein Heizkörperthermostat wieder öffnet, soll die Therme wieder anspringen. Damit die Therme morgens nicht gleich wieder ausgeschaltet wird, wenn wirklich einmal alle Thermostaten geschlossen sind, habe ich einen Wait Timer definiert, der erst nach 10 min auf cmd_1 stellt und die Therme dann ausschaltet. Für das einschalten (cmd_2) habe ich 1 min festgelegt.
Wenn die Therme jetzt morgens anspringt und erst 3 min später die Thermostaten öffnen, sollte der Timer doch abgebrochen werden, wenn die Bedingung für cmd_1 nicht mehr wahr ist. So steht es zumindest im Wiki zum DOIF. Das ist aber nicht so! Es wird trotzdem nach 10 min ausgeschaltet und nach einer weiteren min wieder eingeschaltet. Gab es da Änderungen, die im Wiki noch nicht angepasst sind, oder ist da ein Fehler drin? Oder kann man das Verhalten steuern? Wenn ja, wie?

MfG
edition

Damian

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

edition

([Therme_Status:state] eq "activ" and ([Stellantrieb_Wohnzimmer:actuator] eq "0" and [Stellantrieb_Kueche:actuator] eq "0" and [Stellantrieb_Gaesteklo:actuator] eq "0" and [Stellantrieb_Flur:actuator] eq "0" and [Stellantrieb_Buero:actuator] eq "0" and [Stellantrieb_Bad:actuator] eq "0" and [Stellantrieb_Gaestezimmer:actuator] eq "0" and [Stellantrieb_Schlafzimmer:actuator] eq "0"))(set Therme_Autoaus aus ; set Heizung_Sw off ; define tmp_time1 at +00:00:05 set Therme_Stell_Ventil initialize) DOELSEIF ([Therme_Status:state] eq "activ" and [Therme_Autoaus:state] eq "aus" and ([Stellantrieb_Wohnzimmer:actuator]>5 or [Stellantrieb_Kueche:actuator]>5 or [Stellantrieb_Gaesteklo:actuator]>5 or [Stellantrieb_Flur:actuator]>5 or [Stellantrieb_Buero:actuator]>5 or [Stellantrieb_Bad:actuator]>5 or [Stellantrieb_Gaestezimmer:actuator]>5 or [Stellantrieb_Schlafzimmer:actuator]>5))(set Therme_Autoaus ein ; set Heizung_Sw on ; define tmp_time2 at +00:00:05 set Therme_Stell_Ventil initialize)
Und

attr: Therme_Stell_Ventil wait 600:60
Reicht das?
Ich habe es "im kleinen" mit dummys nachgebaut.

([status:state] eq "activ" and ([stell1:state] eq "0" and [stell2:state] eq "0" and [stell3:state] eq "0" and [stell4:state] eq "0" ))(set akt aus ; define tmp_time1 at +00:00:05 set schalt initialize) DOELSEIF ([status:state] eq "activ" and [autoaus:state] eq "aus" and ([stell1:state]>5 or [stell2:state]>5 or [stell3:state]>5 or [stell3:state]>5 ))(set autoaus ein ; set act on ; define tmp_time2 at +00:00:05 set schalt initialize)
Wenn ich stell 1-4 auf 0 setze, beginnt der Timer. Wenn ich währenddessen z.b. stell2 auf 9 setze, läuft der Timer weiter und schaltet dann  ab.

Damian

Damit der Timer abbricht, muss eine andere Bedingung zutreffen. Das kann nur der cmd2-Fall sein, wenn der nicht zutrifft, dann wird der Timer nicht abgebrochen.

Auch wenn cmd2 zuschlägt, muss man 60 Sekunden warten, in dieser Zeit darf nicht wieder cmd1 zutreffen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

edition

Das liest sich im DOIF/Einsteigerleitfaden aber anders

wait

Das Attribut verzögert die Befehlsausführung, nach wahr werden einer Bedingung.

Laufende Wait-Timer werden bei einem eingeleiteten Statuswechsel des DOIF abgebrochen, daher werden die zu verzögernden Befehle nicht mehr ausgeführt.

Damian

Zitat von: edition am 02 Mai 2023, 20:06:08Das liest sich im DOIF/Einsteigerleitfaden aber anders

wait

Das Attribut verzögert die Befehlsausführung, nach wahr werden einer Bedingung.

Laufende Wait-Timer werden bei einem eingeleiteten Statuswechsel des DOIF abgebrochen, daher werden die zu verzögernden Befehle nicht mehr ausgeführt.

Das ist schon richtig, es muss ein Statuswechsel erfolgen. Und in den beiden von mir beschriebenen Fällen hat ja noch kein Status gewechselt.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

edition

Hmmm, dann muss ich das wohl irgendwie anders aufbauen. Aber wie?

Das eigentliche Einschalten der Therme kommt ja von einem Notify, welches auf einen Google Kalender reagiert. Das setzt auch den dummy Therme_Status auf activ.
Wenn ich nur den dummy setze, würde die Therme erst einschalten, wenn die Ventile öffnen und wieder ausschalten, wenn sie geschlossen sind.

Damian

Du kannst dir einen weiteren DOELSEIF-Fall bauen, der zum Abbruch führt oder ein einfaches DOELSE am Ende. In beiden Fällen brauchst du nichts ausführen, sondern nur den Zustandswechsel provozieren.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

edition

Ich versuche es einfach mal mit meiner Dummykonstruktion. Mal sehen, wie das geht. Ist vielleicht auch de bessere Lösung, die Therme gar nicht erst einzuschalten, wenn keine Wärme benötigt wird statt erst mal einzuschalten und 10 min später wieder aus!

Ich habe hier wieder einmal einen Denkanstoß bekommen. Schön, dass es dieses Forum gibt. Danke dafür!

edition

sash.sc

Versuche es mal mit den Attribut resetwait
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

edition

Zitat von: sash.sc am 04 Mai 2023, 10:18:47Besuche es mal mit den Attribut resetwait

Wo finde ich das denn? In der Auswahlliste jedenfalls nicht!

Thema hat sich erst mal erledigt. Ich schalte jetzt gemäß Zeitplan nicht mehr direkt die Therme, sondern setze den dummy Therme_Status auf activ, bzw. inactiv. Dann greift das DOIF (ohne wait) und schaltet nach Bedarf die Therme ein, oder aus. Läuft seit zwei Tagen ohne Probleme.

Gruß
edition

Damian

Mit attr do resetwait wird ein Timer verlängert, aber das wäre eher das Gegenteil von dem, was du willst.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

edition

Genau! do resetwait bewirkt genau das Gegenteil.

Aber mal eine grundsätzliche Frage: Hat sich da mal was geändert? Das würde nämlich das Verhalten meiner Beschattung im letzten Sommer erklären. Ich hatte die Markiese mittels DOIF in Abhängigkeit von Helligkeit und Temperatur zur Beschattung gesteuert. Damit sie nicht bei jeder Wolke einfährt, habe ich den wait Timer gesetzt.
Trotzdem ist die Markiese ständig eingefahren! Im Jahr davor hat das noch problemlos funktioniert, meine ich.

edition

Damian

Zitat von: edition am 08 Mai 2023, 09:21:25Genau! do resetwait bewirkt genau das Gegenteil.

Aber mal eine grundsätzliche Frage: Hat sich da mal was geändert? Das würde nämlich das Verhalten meiner Beschattung im letzten Sommer erklären. Ich hatte die Markiese mittels DOIF in Abhängigkeit von Helligkeit und Temperatur zur Beschattung gesteuert. Damit sie nicht bei jeder Wolke einfährt, habe ich den wait Timer gesetzt.
Trotzdem ist die Markiese ständig eingefahren! Im Jahr davor hat das noch problemlos funktioniert, meine ich.

edition

Nein, es hat sich an dieser Stelle seit Jahren im DOIF nichts geändert. Wenn sich etwas anders verhält, dann eher durch äußere Faktoren.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

edition

Ich habe gestern gesehen, dass es ein Update für DOIF gibt. Nach der Installation und Neustart verhält sich der wait Timer jetzt so, wie beschrieben. Wird also abgebrochen, wenn die Bedingung nicht mehr wahr ist. Ob das nun am Update oder am Neustart lag, vermeg ich nicht zu sagen.
Wie auch immer, ich bleibe bei meiner jetzigen Steuerung.

Gruß
edition