DOIF neues Feature: Wiederholende Ausführung mit Zeitangabe

Begonnen von Damian, 06 November 2015, 22:05:57

Vorheriges Thema - Nächstes Thema

Per

Zitat von: Tueftler1983 am 12 Februar 2017, 23:35:10Würde gerne ein Event 8 mal wiederholen.
([was auch immer])(Befehl_1,set $SELF cmd_2)
DOELSEIF (false)(Befehl_2)
attrib XXX repeatcmd 0:20
attrib XXX repeatsame 1:8


Tueftler1983

Das Problem ist das in meinem DOIF 4 Events ausgeführt werden sollen von den das 4. Neun mal wiederholt werden muss mit jeweils 1 sek verzögerung. Derzeit sieht es so aus
([d_Wecker] eq "on" and [[d_Weckzeit:state]]) (set d_HitRadio on) (set d_Soundbar POWER) (set ledstrip GREEN) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER)(set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER)
Mit dem Attribut wait 0,0,0,1,1,1,1,1,1,1,1

Per

Wo ist das Problem?
([d_Wecker] eq "on" and [[d_Weckzeit:state]]) (set d_HitRadio on,set d_Soundbar POWER,set ledstrip GREEN,set $SELF cmd_2)
DOELSEIF (0) (set ledstrip BRIGHTER)

repeatcmd 0:1
repeatsame 1:8

chq

Hm. Wenn ich jetzt nur das einzelne Kommando set nasBackupHD on (und nur dieses) mehrmals hintereinander senden wollen würde, müsste ich ihm (also nur diesem Kommando) ein eigenes DOELSEIF spendieren, richtig?

([14:59|Do]) (setreading $SELF doifState reset)

DOELSEIF ([15:00-24:00|Do] and [Bewohner:"home"]) (setreading $SELF doifState hd_startup, set nasBackupHD on, set doif_NAS disable)

DOELSEIF ([?$SELF:doifState] eq "hd_startup") (set doif_NAS enable, setreading $SELF doifState hd_finished, set nasBackupHD off)


Gruß Chris
So einfach wie möglich, so kompliziert wie nötig

Per

Ja, aber du musst auch selftrigger anschalten mit ? wird dein dritter Fall nie (!) angetriggert.
Wenn du das ? hingegen wegnimmst, musst du hoffen, dass auch "set nasBackupHD on, set doif_NAS disable" irgendwann mal ausgeführt wird, denn du verlässt ja den zweiten Fall, bevor er zu Ende ist.

fhemjan

#95
Ich möchte die Abfrage der Luftfeuchtigkeit realisieren und eine Warnung geben wenn sie über einem bestimmten Wert ist. Es funktioniert einigermaßen mit:
([TH_Variabel:humidity] > "60") ({
       my $hum = ReadingsVal("TH_Variabel","humidity","");;
       Log 1, "Hohe Luftfeuchtigkeit im Schlafzimmer";;
       fhem("set pushmsg msg title='Schlafzimmer' message='$hum% Luftfeuchtigkeit!'");;
       })
DOELSE)

Der Lacrosse Sensor TH_Variabel gibt die Luftfeuchtigkeit ziemlich häufig aus, daher wird man sehr zugespamt mit Nachrichten. Ich habe es nun mit
attr xxx repeatcmd 3600
probiert, mit dem Gedanken, dass ich bei Auslösung des DOIF eine Nachricht bekomme und falls nach einer Stunde immer noch hum > 60 % noch eine.
Es will aber noch nicht richtig klappen. Es wirkt eher so als wenn die DOIF Abfrage jede Stunde durch geführt wird und schaut ob die Bedingung korrekt ist.
Ist das so richtig und ich hab lediglich den Befehl flasch verstanden? Oder ist irgendwo ein Fehler drin?
Ich habe auch
attr xxx do always
mit eingebaut, auch wenn ich mir nicht 100% sicher bin ob das notwendig ist (hatte es in einem Beispiel in der commandref so gesehen)

Edit: Irgendwie ist definitiv der Wurm drin. Wenn ich repeatcmd lösche löst er jetzt gar nicht mehr aus, auch wenn ich die Bedingung auf einen wahren Wert wie z.b. > "40" setze

fhemjan

 Es scheint irgendwie die Befehlsausführung jede Stunde gespeichert zu sein. Es kam jetzt nochmal eine Meldung. Also scheint repeatcmd dafür zu sorgen, das DOIF alle in repeatcmd angegebenen Sekunden zu prüfen ob die Bedingung stimmt.

Eine Funktion mit der er direkt bei Erüllung der DOIF-Bedingung auslöst und dann aber frühestens wieder in z.B. einer Std., falls die Bedingung immer noch erfüllt ist, gibt es nicht, oder?

Damian

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

fhemjan

#98
Hm, ja das hatte ich anfangs probiert, war jedoch nicht erfolgreich. Ich bekomme grade nicht mehr ganz zusammen was dabei passiert ist.

Aktuell verstehe ich aber generell nicht was los ist. Ich habe alle betreffenden Attribute wieder gelöscht, aber das DOIF reagiert nicht (s. Screenshot). Wenn ich FHEM neustarte wird es einmal ausgelöst, aber das war es dann.

Edit: Irgendwie werden die readings nicht geupdated, obwohl der Sensor alle paar Sekunde  neue Werte liefert (deutlich über 40% humidity)

jhohmann

Eventuell ein neues Userreading definieren, was unterhalb des Werts z.B. auf false und oberhalb von 60 auf true gesetzt wird.
Und dieses Userreading sollte bei event-on-change mit enthalten sein.
Das sollte sich dann nicht mehr ändern, auch wenn der Wert auf 70 oder 80 steigt.
Dann kannst du auf diesem Userreading das DOIF ansetzen und bekommst nur eine Meldung.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

sash.sc

Ich würde bei dem sensor schon mit event-on-change arbeiten, um die Ebene Flut einzudämmen. Bei Daten die regelmäßig kommen brauchst eigentlich kein do always.

Gruß Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

fhemjan

Besten Dank an alle!

Zitat von: jhohmann am 01 Februar 2023, 18:13:25
Eventuell ein neues Userreading definieren, was unterhalb des Werts z.B. auf false und oberhalb von 60 auf true gesetzt wird.

Dieser Tipp hat letztlich zum Erfolg geführt.

fhemjan

Tatsächlich hab ich aktuell nun noch das Problem, das die Sensorausgabe tendenziell etwas schwankt. Das heißt, dass er beim Übergang von 59,9% auf 60% ab und zu hin und her springt. Das bringt mir dann jedes Mal eine Push-Nachricht aufs Handy.
Ich hätte nun gedacht, dass der cmdpause Befehl genau das Problem lösen sollte. Wenn ich aber z.B. cmdpause mit 600 Sek. nutze löst das DOIF überhaupt nicht mehr aus. Auch wenn ich den Schwellwert in meinem Userreading händisch ein paar mal ändere, 30% --> 60% --> 30% usw.
Das Reading springt dann von true auf false usw. aber das DOIF bleibt stumm.

Habe ich da einen Denkfehler?

sash.sc

Nimm event-on-change-reading. Da kannst du auch festlegen, wann ein Event ausverkauft werden soll. Z.b. Wenn sich das angegebene reading um 0.2 oder 0.4 ändert, wie bei Temperatur oder was auch immer
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

fhemjan

#104
Hatte jetzt erst gedacht das es nicht funktioniert weil ich
attr DOIF_hum do always
nicht gesetzt hatte. Aber das hat auch nicht wirklich was geändert. Das DOIF hat einmal ausgelöst, aber wenn ich Schwellwert wieder rauf und nach Ablauf des Werts von cmdpause wieder runter gesetzt habe hat das DOIF nicht mehr ausgelöst.

Zitat von: sash.sc am 08 Februar 2023, 14:50:54
Nimm event-on-change-reading. Da kannst du auch festlegen, wann ein Event ausverkauft werden soll. Z.b. Wenn sich das angegebene reading um 0.2 oder 0.4 ändert, wie bei Temperatur oder was auch immer
Interessanter Ansatz, ich denke ich versteh erst jetzt was du meinst, sorry, du hattest den Hinweis ja schon vorher gegeben. Tatsächlich wird die Luftfeuchtigkeit nur in ganzen Zahlen ausgegeben (das hatte ich falsch im Kopf). Also wäre jetzt der Ansatz beim Sensor das Attribut zu setzen
attr DTH_Sensor event-on-change-reading humidity:1,.*
Ich habe event-on-change-reading bei den meisten Geräten standardmäßig auf .*

Nachteil wäre jetzt, dass ich nun künstlich die Genauigkeit des Sensors für Luftfeuchtigkeit verschlechtert habe, oder? So richtig ideal wäre das ja auch noch nicht, oder hab ich da noch was falsch verstanden? Und noch eine Verständnisfrage, die meines Erachtens nicht aus der Referenz hervorgeht: Muss eine einzelne Änderung größer sein als der Schwellwert in event-on-change-reading? Dann würde er bei nie auslösen wenn nur Änderungen < Schwellwert auftreten? Oder summiert er? Aber ab wann zählt er dann?

Prinzipiell vestehe ich aber auch immer noch nicht wieso es mit cmdpause nicht funktioniert, da es laut commandref ja genau meine Anwendung abbilden sollte (https://fhem.de/commandref_DE.html#DOIF_cmdpause):
Zwangspause für das Ausführen eines Kommandos seit der letzten Zustandsänderung

Mit dem Attribut cmdpause <Sekunden für cmd_1>:<Sekunden für cmd_2>:... wird die Zeitspanne in Sekunden angegeben für eine Zwangspause seit der letzten Zustandsänderung. In der angegebenen Zeitspanne wird ein Kommando nicht ausgeführt, auch wenn die dazugehörige Bedingung wahr wird.

Anwendungsbeispiel: Meldung über Frostgefahr alle 60 Minuten

define di_frost DOIF ([outdoor:temperature] < 0) (set pushmsg "danger of frost")
attr di_frost cmdpause 3600
attr di_frost do always