DOIF mit Ausschaltverzögerung?

Begonnen von Dracolein, 18 November 2021, 21:10:57

Vorheriges Thema - Nächstes Thema

Dracolein

Hallo zusammen,
ich möchte einen Luftentfeuchter nur starten lassen, wenn tagsüber genug Strom von meiner PV-Anlage erzeugt wird (oder alternativ bei sehr hoher Luftfeuchtigkeit). Um das Ganze zu überwachen, lasse ich momentan Logeinträge erzeugen. Das Ganze Konstrukt funktioniert soweit und sieht so aus:

define doif_Luftentfeuchter ([SMATripower6:SPOT_PACTOT] > 150 and [ESPEasy_ESP_Easy1_am2302_sensor:humidity] > 58)(set ShellyPlug1 on) { Log 1, "Luftentfeuchter Keller ON wg PV Ueberschuss" }
DOELSEIF ([ESPEasy_ESP_Easy1_am2302_sensor:humidity] > 63)(set ShellyPlug1 on) { Log 1, "Luftentfeuchter Keller ON wg Feuchtigkeit" }
DOELSE (set ShellyPlug1 off){ Log 1, "Luftentfeuchter Keller OFF" }


Erwartungsgemäß mit dem Problemchen, dass bei Unterschreitung der Startbedingungen durch Wegfall der Sonne bzw. schwankendem PV_Ertrag der Entfeuchter im Minutentakt ein- und ausgeschaltet wird:
Zitat
2021.11.18 12:38:09 1: Luftentfeuchter Keller ON wg PV Ueberschuss
2021.11.18 12:39:09 1: Luftentfeuchter Keller OFF
2021.11.18 12:40:09 1: Luftentfeuchter Keller ON wg PV Ueberschuss
2021.11.18 14:05:09 1: Luftentfeuchter Keller OFF
2021.11.18 14:06:09 1: Luftentfeuchter Keller ON wg PV Ueberschuss
2021.11.18 14:24:09 1: Luftentfeuchter Keller OFF
2021.11.18 14:26:09 1: Luftentfeuchter Keller ON wg PV Ueberschuss
2021.11.18 14:34:09 1: Luftentfeuchter Keller OFF

Nun möchte ich eine Art Ausschaltverzögerung dazubauen, sodass der Entfeuchter mindestens 60 Minuten aktiv ist, bevor er frühestens durch das letzte DOELSE abgeschaltet wird.
Leider finde ich keinen Anhaltspunkt, wie ich das konkret umsetzen muss. Theoretisch würde ich gemeinsam mit dem Startbefehl auch einen vordefinierten 60-min Timer starten wollen, dessen Status ich im letzten DOELSE zusätzlich abfrage. Aber mir ist völlig unklar wie das möglich ist.

Alternativ habe ich versucht die funktion "watchdog" zu begreifen
Zitat
define <name> watchdog <regexp1> <timespec> <regexp2> <command>
Startet einen beliebigen FHEM Befehl wenn nach dem Empfang des Ereignisses <regexp1> nicht innerhalb von <timespec> ein <regexp2> Ereignis empfangen wird.
bin jedoch unsicher, welche Ereignisse in meinem Fall regexp1 bzw. regexp2 sein müssten oder ob dies ein Holzweg ist?
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

Otto123

Hi,

Du kannst die Zweige mit dem wait Attribute verzögern - mach ich so bei meiner Beschattung damit der Rollladen nicht bei kurzen Sonnenwechsel hoch und runter fährt.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Dracolein

ach stimmt ja, genau  ::)  ;)
Problem hoffentlich behoben, danke. Werde es beobachten.

Wenn ich den Thread dennoch kurz vergewaltigen darf: Wie würde man einen solchen Timer umsetzen, wofür auch immer?
Ich hänge gedanklich aufgrund meiner Erfahrung im Bereich Steuerungstechnik häufig in Ablaufketten fest und versuche dies Muster auf FHEM anzuwenden. Timer gehören dort zum Standardwerkzeugkasten, die ich einfach vordefiniere wie Variablen, um sie bei Bedarf irgendwo zu starten, anderweitig abzufragen und durch andere Events zu resetten.
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

Damian

Zitat von: Dracolein am 19 November 2021, 06:42:11
ach stimmt ja, genau  ::)  ;)
Problem hoffentlich behoben, danke. Werde es beobachten.

Wenn ich den Thread dennoch kurz vergewaltigen darf: Wie würde man einen solchen Timer umsetzen, wofür auch immer?
Ich hänge gedanklich aufgrund meiner Erfahrung im Bereich Steuerungstechnik häufig in Ablaufketten fest und versuche dies Muster auf FHEM anzuwenden. Timer gehören dort zum Standardwerkzeugkasten, die ich einfach vordefiniere wie Variablen, um sie bei Bedarf irgendwo zu starten, anderweitig abzufragen und durch andere Events zu resetten.

Im Nachbar-Thread wurde bereits der passende Link gepostet: https://forum.fhem.de/index.php/topic,124211.msg1187987.html#msg1187987

Wenn du aus der Programmierwelt kommst, dann sollte dir der DOIF-Perlmodus besser liegen. Dort wird, im Gegensatz zu DOIF-FHEM-Modus, eher programmiert, als definiert.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Dracolein

#4
Ich muss doch nochmal nachfragen, weil meine Experimente die vergangenen Tage nicht von Erfolg gekrönt waren. Ich will analytisch das Problem lösen, anstatt planlos zu probieren.

Zur Diskussion hier das Beispiel aus der Commandref:

ZitatAnwendungsbeispiel: Beschattungssteuerung abhängig von der Temperatur. Der Rollladen soll runter von 11:00 Uhr bis Sonnenuntergang, wenn die Temperatur über 26 Grad ist. Temperaturschwankungen um 26 Grad werden mit Hilfe des wait-Attributes durch eine 15 minutige Verzögerung ausgeglichen.

define di_shutters DOIF ([sensor:temperature] > 26 and [11:00-{sunset_abs()}] (set shutters down) DOELSE (set shutters up)
attr di_shutters wait 900:900


Hier meine Verständnisfrage zum genannten Bsp.:
Ab dem Moment, wenn die Bedingungen zutreffen, wird dann erst 900 Sekunden abgewartet, bevor der erste Befehlssatz ausgeführt wird? Oder wird der Befehl SOFORT ausgeführt und DANACH 900 Sekunden  gewartet, bis die Bedingungen erneut geprüft werden?

Also bezogen auf mein ursprüngliches Problem im 1. Posting - dessen Bedingungen und Befehle einwandfrei funktionieren, hat

attr wait 0:0:3600

dazu geführt, dass sich der Entfeuchter nicht mehr abgeschaltet hat. Warum auch immer. Ich habe nun

attr wait 3600:3600:0

eingetragen in der Hoffnung, dass NACH Ausführen einer der ersten beiden Befehlssätze erstmal 1 Std gewartet wird, bevor die dritte Bedingung überprüft und ggf. ausgeführt wird.
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

Otto123

soweit ich das weiß, wird die Zeit (wait) gewartet bis der jeweilige Ausführungsteil ausgeführt wird. Ändert sich die Bedingung innerhalb dieser Zeit, wird nichts ausgeführt. Also in dem commandref Beispiel:
steigt die Temperatur über 26 grad wird 900 sec gewartet, fällt die Temperatur in dieser Zeit wieder unter 26 grad passiert nichts, bleibt sie über 26 wird der Rollladen runter gefahren. sinkt sie dann unter 26 wird 900 sec gewartet, steigt sie in der Zeit passiert wieder nicht, bleibt sie unter 26 wird der Rolladen wieder hochgefahren.

Ich bin mir bei deinem DOIF nicht sicher ob die Mischung aus FHEM Ausführungsteil und Perl Ausführungsteil überhaupt funktioniert  ::) aber es sind auf alle Fälle zwei Befehle, die ein unterschiedliches wait haben könnten.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz