Guten Morgen,
ich bin ein wenig ratlos, denn ich wollte jetzt mein DOIF was ich so schon im letzten Jahr aktiv hatte für meine Gartenbewässerung wieder aktivieren.
Doch leider reagiert das DOIF nicht mehr so wie letztes Jahr wo ich es über den Winter deaktiviert hatte.
(([05:00-05:30]) and ([WetterFalkensee:fc0_chOfRain06] < 50) and ([WetterFalkensee:fc0_chOfRain09] < 50) and ([WetterFalkensee:fc0_chOfRain12] < 50) and ([SensorRasen:moisture] < 23))
(set RegnerTeichSeite on)
DOELSEIF (([19:00-20:00]) and ([WetterFalkensee:fc0_chOfRain21] < 60 ) and ([SensorRasen:moisture] < 23 ))
(set RegnerTeichSeite on)
DOELSE (set RegnerTeichSeite off)
das was ich raus gefunden habe ist das "[SensorRasen:moisture]" was damit zu tun hat, denn wenn ich das so
(([06:05-06:30]) and ([SensorRasen:moisture] < 22))(set Test on)
Internals:
BTMAC C4:7C:8D:6A:D5:E3
DEF C4:7C:8D:6A:D5:E3
FUUID 5cfe32b9-f33f-2a44-7b21-5e2d5cd34641a4cc
FVERSION 74_XiaomiBTLESens.pm:v2.8.2-s20924/2020-01-10
INTERVAL 300
NAME SensorRasen
NOTIFYDEV global,SensorRasen
NR 60
NTFY_ORDER 50-SensorRasen
STATE active
TYPE XiaomiBTLESens
VERSION v2.8.2
loglevel 4
READINGS:
2020-04-24 21:16:12 batteryPercent 99
2020-04-24 21:16:12 batteryState ok
2020-04-25 06:08:30 fertility 191
2020-04-24 21:16:12 firmware 3.2.1
2020-04-24 19:58:48 lastGattError charWrite faild
2020-04-25 06:08:30 lux 396
2020-04-25 06:08:30 moisture 30
2020-04-25 06:08:30 state active
2020-04-25 06:08:30 temperature 10
helper:
CallBattery 0
CallSensDataCounter 0
updateTimeCallBattery 1587755772.69462
updateTimestampCallBattery 2020-04-24 21:16:12
Attributes:
interval 1200
model flowerSens
room Garten,XiaomiBTLESens
sshHost pi@192.168.2.141
Das ist doch eigentlich total Simple aber das DOIF reagiert einfach nicht?!?
Hallo Steffen,
bin auch ratlos, deshalb müsste wohl ein Profi ran. Was mir aber auffällt - jedenfalls würde ich es anders machen -, ist die doppelte Klammerung in den Bedingungsteilen. Hier reicht eigentlich eine einzige Klammer.
Kannst du auch ein list des DOIFs anhängen? Wenn nicht das Attribut do always gesetzt wurde, wird die Ausführung nur einmal durchgeführt. Vielleicht könnte das die Ursache sein, warum es dann später nicht mehr klappt.
Viele Grüße Gisbert
Ich würde sich die doppelte klammerung raus nehmen.
Do always brauche da nicht gesetzt zu werden, da das doif durch jede Aktualisierung des Wetter Berichtes getriggert wird.
Gesendet von meinem MI 9 mit Tapatalk
Zitat(([06:05-06:30]) and ([SensorRasen:moisture] < 22))(set Test on)
teste, dann wird ein cmd 1 auch nicht ausgeführt.
Wenn moisture derzeit 30 ist, ist das Verhalten doch ok?
BTW: Es ist zwar trocken derzeit, aber am morgen Luftfeuchte unter 22? Da gibt es auch keinen Rasen mehr. :o
Gruß Otto
Vielen Dank für eure Hinweise, doch so wie der Code oben steht hat er letzten Sommer durchgehend funktioniert.
Dann über Winter auf disable gesetzt und dieses Jahr will der Code nicht mehr.
Ich hatte jede Version probiert, dann gemerkt das es am SensorRasen kein cmd gibt.
Das ist ein Boden Sensor der die Feuchtigkeit im Boden messen tut und bei unter 22% sollen die Regner angehen was auch letzten Sommer so geklappt hat. Irgendwas muss sich in Fhem oder DOIF verändert haben?!
Aber so wie es aktuell steht ist die Bedingung: ([SensorRasen:moisture] < 22) -> (30 < 22) -> falsch -> keine Ausführung.
Um es zu testen solltest Du die Schwelle hochsetzen.
Zitat von: Gisbert am 25 April 2020, 07:06:18
Kannst du auch ein list des DOIFs anhängen?
Und bitte den list noch liefern. Im "Fehlerzustand" am besten.
Gesendet von meinem S68Pro mit Tapatalk
Hallo zusammen,
anscheinend bin ich nicht der einzige mit diesem Problem - Habe schon angefangen an meinem Verstand zu zweifeln ;-)
Auch bei mir wird ein DOIF, mit dem ich ebenfalls seit längerem meine Gartenbewässerung erfolgreich steuere, plötzlich
nicht mehr ausgeführt. Auch bei mir war das DOIF über den Winter deaktiviert, hat aber nach re-initialisierung vor zwei
Wochen zumindest mal kurz funktioniert, dann nach einem Update aber auch seinen Dienst eingestellt. :-|
Gab es da evtl. eine Syntaxänderung, die ich nicht mitbekommen habe und die jetzt ggf. Ärger macht?
Hier mal ein List meines DOIF
Internals:
DEF ([{sunrise("CIVIL")}] and ($month >= 5 and $month <=8) and [NIEDERSCHLAG:statWaterHour72] <= 0.008)
(set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 1 erfüllt. Nächster Start in 48 Sunden!' '' 0 '' )
(set garten_SWC_02 on-for-timer 600)
(set garten_SWC_03 on-for-timer 600)
DOELSEIF ([{sunrise("CIVIL")}] and ($month < 5 or $month > 8) and [NIEDERSCHLAG:statWaterHour72] <= 0.004)
(set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 2 erfüllt. Nächster Start in 48 Sunden!' '' 0 '' )
(set garten_SWC_02 on-for-timer 600)
(set garten_SWC_03 on-for-timer 600)
DOELSEIF ([{sunrise("CIVIL")}] and [NIEDERSCHLAG:statWaterHour24] <= 0.002 and ([GARTEN:statTemperatureDayAvg] >= 22.0 or [GARTEN:statTemperatureDayMax] >= 28))
(set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 3 erfüllt.' '' 0 '' )
(set garten_SWC_02 on-for-timer 600)
(set garten_SWC_03 on-for-timer 600)
DOELSEIF ([NIEDERSCHLAG:basicSet] == 99 and ([garten_SWC_02:state] eq "on" or [garten_SWC_03:state] eq "on"))
(set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Beendet wegen Regen!' '' 0 '' )
(set garten_SWC_02 off, set garten_SWC_03 off)
DOELSE
FUUID 5d388d65-f33f-d5e6-45eb-952d6ef7b2b122b4
MODEL FHEM
NAME controller_BEWAESSERUNG_GARTEN
NOTIFYDEV global,garten_SWC_03,garten_SWC_02,NIEDERSCHLAG,GARTEN
NR 493
NTFY_ORDER 50-controller_BEWAESSERUNG_GARTEN
STATE cmd_5
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-04-25 23:08:08 Device GARTEN
2020-04-25 23:08:08 cmd 5
2020-04-25 23:08:08 cmd_event GARTEN
2020-04-25 23:08:08 cmd_nr 5
2020-04-25 23:08:08 e_GARTEN_statTemperatureDayAvg 19.0
2020-04-25 23:08:08 e_GARTEN_statTemperatureDayMax 26.2
2020-04-25 22:59:55 e_NIEDERSCHLAG_statWaterHour24 0.0000
2020-04-25 22:59:55 e_NIEDERSCHLAG_statWaterHour72 0.0000
2020-04-25 22:55:38 e_garten_SWC_02_state off
2020-04-25 22:55:40 e_garten_SWC_03_state off
2020-04-25 22:51:21 mode enabled
2020-04-25 23:08:08 state cmd_5
2020-04-25 22:51:21 timer_01_c01 26.04.2020 05:38:18
2020-04-25 22:51:21 timer_02_c02 26.04.2020 05:38:18
2020-04-25 22:51:21 timer_03_c03 26.04.2020 05:38:18
2020-04-25 22:52:29 wait_timer no timer
Regex:
accu:
cond:
GARTEN:
0:
1:
2:
statTemperatureDayAvg ^GARTEN$:^statTemperatureDayAvg:
statTemperatureDayMax ^GARTEN$:^statTemperatureDayMax:
3:
NIEDERSCHLAG:
0:
statWaterHour72 ^NIEDERSCHLAG$:^statWaterHour72:
1:
statWaterHour72 ^NIEDERSCHLAG$:^statWaterHour72:
2:
statWaterHour24 ^NIEDERSCHLAG$:^statWaterHour24:
3:
basicSet ^NIEDERSCHLAG$:^basicSet:
garten_SWC_02:
0:
1:
2:
3:
state ^garten_SWC_02$:^state:
garten_SWC_03:
0:
1:
2:
3:
state ^garten_SWC_03$:^state:
attr:
cmdState:
cmdpause:
86400
86400
0
0
0
wait:
0:
0
0
300
1:
0
0
300
2:
0
0
300
3:
0
0
4:
0
0
5:
0
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday) and ($month >= 5 and $month <=8) and ::ReadingValDoIf($hash,'NIEDERSCHLAG','statWaterHour72') <= 0.008
1 ::DOIF_time_once($hash,1,$wday) and ($month < 5 or $month > 8) and ::ReadingValDoIf($hash,'NIEDERSCHLAG','statWaterHour72') <= 0.004
2 ::DOIF_time_once($hash,2,$wday) and ::ReadingValDoIf($hash,'NIEDERSCHLAG','statWaterHour24') <= 0.002 and (::ReadingValDoIf($hash,'GARTEN','statTemperatureDayAvg') >= 22.0 or ::ReadingValDoIf($hash,'GARTEN','statTemperatureDayMax') >= 28)
3 ::ReadingValDoIf($hash,'NIEDERSCHLAG','basicSet') == 99 and (::ReadingValDoIf($hash,'garten_SWC_02','state') eq "on" or ::ReadingValDoIf($hash,'garten_SWC_03','state') eq "on")
days:
do:
0:
0 set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 1 erfüllt. Nächster Start in 48 Sunden!' '' 0 ''
1 set garten_SWC_02 on-for-timer 600
2 set garten_SWC_03 on-for-timer 600
1:
0 set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 2 erfüllt. Nächster Start in 48 Sunden!' '' 0 ''
1 set garten_SWC_02 on-for-timer 600
2 set garten_SWC_03 on-for-timer 600
2:
0 set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 3 erfüllt.' '' 0 ''
1 set garten_SWC_02 on-for-timer 600
2 set garten_SWC_03 on-for-timer 600
3:
0 set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Beendet wegen Regen!' '' 0 ''
1 set garten_SWC_02 off, set garten_SWC_03 off
4:
0
helper:
DEVFILTER ^global$|^garten_SWC_03$|^NIEDERSCHLAG$|^garten_SWC_02$|^GARTEN$
NOTIFYDEV global|garten_SWC_03|NIEDERSCHLAG|garten_SWC_02|GARTEN
event battery: ok,humidity: 43,T: 11.0 H: 43,temperature: 11.0,dewpoint: -1.1,D: -1.1,statTemperatureDayAvg: 19.0,statTemperatureDayMax: 26.2
globalinit 1
last_timer 3
sleepdevice set_cmd_3
sleepsubtimer 2
sleeptimer -1
timerdev GARTEN
timerevent battery: ok,humidity: 43,T: 11.0 H: 43,temperature: 11.0,dewpoint: -1.1,D: -1.1,statTemperatureDayAvg: 19.0,statTemperatureDayMax: 26.2
triggerDev GARTEN
DOIF_eventa:
cmd_nr: 5
cmd: 5
cmd_event: GARTEN
cmd_5
DOIF_eventas:
cmd_nr: 5
cmd: 5
cmd_event: GARTEN
state: cmd_5
timerevents:
battery: ok
humidity: 43
T: 11.0 H: 43
temperature: 11.0
dewpoint: -1.1
D: -1.1
statTemperatureDayAvg: 19.0
statTemperatureDayMax: 26.2
timereventsState:
battery: ok
humidity: 43
state: T: 11.0 H: 43
temperature: 11.0
dewpoint: -1.1
D: -1.1
statTemperatureDayAvg: 19.0
statTemperatureDayMax: 26.2
triggerEvents:
battery: ok
humidity: 43
T: 11.0 H: 43
temperature: 11.0
dewpoint: -1.1
D: -1.1
statTemperatureDayAvg: 19.0
statTemperatureDayMax: 26.2
triggerEventsState:
battery: ok
humidity: 43
state: T: 11.0 H: 43
temperature: 11.0
dewpoint: -1.1
D: -1.1
statTemperatureDayAvg: 19.0
statTemperatureDayMax: 26.2
internals:
intervalfunc:
localtime:
0 1587872298
1 1587872298
2 1587872298
readings:
all NIEDERSCHLAG:statWaterHour72 NIEDERSCHLAG:statWaterHour24 GARTEN:statTemperatureDayAvg GARTEN:statTemperatureDayMax NIEDERSCHLAG:basicSet garten_SWC_02:state garten_SWC_03:state
realtime:
0 05:38:18
1 05:38:18
2 05:38:18
time:
0 {sunrise("CIVIL")}
1 {sunrise("CIVIL")}
2 {sunrise("CIVIL")}
timeCond:
0 0
1 1
2 2
timer:
0 0
1 0
2 0
timers:
0 0
1 1
2 2
trigger:
triggertime:
1587872298:
localtime 1587872298
hash:
uiState:
uiTable:
Attributes:
alias BEWÄSSERUNG GARTEN
cmdpause 86400:86400:0:0:0
do always
group Gartensteuerung
room STEUERUNG
timerWithWait 1
wait 0,0,300:0,0,300:0,0,300:0,0:0,0:0
Habe übrigens ein weiteres DOIF, sehr ähnlich aufgebaut aber sonst völlig unabhängig vom ersten, und das zeigt exakt das gleiche Verhalten. Das sieht für mich schon nach einem systemischen Problem aus. Mit meinen - eingeschränkten - debugging Kenntnissen bin ich zwischenzeitlich am Ende!
P.S. Ein Sache ist mit noch aufgefallen. Villeicht hilft das ja das Problem einzugrenzen.
Ein set NameDOIF cmd_1 oder ein setNameDOIF cmd_2 zeigt KEINE Reaktion ein setNameDOIF cmd_3 aber schon!?
Soweit ich die commandref verstanden habe sollte ein set cmd_x doch alle commands ohne Prüfung der Bedingungen ausführen, oder?
Ich denke ich habe das gleiche oder zumindest sehr ähnliches Problem wie Steffen. Auch bei mir lief alles lange Zeit ohne Probleme
und ohne Änderung dann (nach dem Update) plötzlich nicht mehr.
Hat jemand noch eine Idee was die Ursache sein könnte?
Mein Garten und ich sind für jede Hilfe dankbar.
Grüße,
Ralf
EDIT: Auch das hier hört sich nach dem gleichen Problem an ???
https://forum.fhem.de/index.php/topic,110455.0.html
Hallo Ralf,
ich durchschau es nicht, aber ich würde generell folgendes empfehlen:
Es gibt für jeden Zweig den eindeutigen Trigger Sonnenaufgang - deshalb würde ich jeden anderen Trigger vermeiden. D.h. alle Ausdrücke [device:reading] würde ich ändern und damit nur abfragen [?device:reading]
Gruß Otto
Hallo Otto,
danke für Deinen Tipp! Wie immer schnell und direkt auf den Punkt :-)
Habe Deinen Vorschlag übernommen und so zumindest etwas mehr Ruhe in mein System bekommen, da nicht jeder neue Sensorwert die DOIF triggert.
Am eigentlichen Problem hat es aber leider nichts verändert - das DOIF startet nach wie vor nicht bei Sonnenaufgang, auch wenn alle anderen Bedingungen erfüllt sind.
Da im ersten und zweiten Zweig des DOIF auch set cmd_1 / cmd_2 nicht funktioniert hatte ich die Conditions and ($month >= 5 and $month <=8) bzw. ($month < 5 or $month > 8) im Verdacht, denn der Rest ist gleich zum dritten Zweig. Aber auch wenn ich die rausnehme ändert sich nix :-\
Bis zum Update vor zwei Wochen hat das aber noch zuverlässig funktioniert - daher meine Vermutung, dass es zwischenzeitlich eine
Syntax Änderung im DOIF gegegen haben könnte. Ich muss zugeben, dass ich zuvor über sehr lange Zeit (mindestens 6 Monate) keine Updates mehr gefahren habe, da alles perfekt lief und ich aus WAF Überlegungen heraus dachte: "never touch a running system" ;)
Hat sonst noch jemand eine Eingebung?
Grüße,
Ralf
... ich habe die Ursache entdeckt aber noch keine Lösung für das Problem gefunden.
Da ich die Bewässerung über die Niederschlagsmenge steuere, sollen die ersten beide Zweige meines DOIF nach Auslösung 24 Stunden pausieren und erst nach 48 Stunden neu getriggert werden.
Hierzu habe ich folgendes Attribut gesetzt
attr controller_BEWAESSERUNG_GARTEN cmdpause 86400:86400:0:0:0
Wie bereits erwähnt, hat dies über längere Zeit zuverlässig funktioniert. Setze ich das cmdpause Attribut jetzt auf "0" lässt sich das DOIF plötzlich auch wieder im ersten und zweiten Pfad manuell triggern. Soweit ich die commandref verstehe ist das syntaktisch korrekt - oder übersehe ich da was? Geändert habe ich daran aber definitiv nichts!
Hi,
ich kann nur bestätigen, dass hier DOIFs in FHEM nicht gleich auslösen wie noch vor einiger Zeit. Anders kann ich mir nicht erklären, dass hier im Forum mittlerweile 3-4 Bewässerungs-DOIFs alle zeitgesteuert plötzlich nicht mehr funktionieren. Und das noch dazu bei diesem trockenen Frühling. Meine Variante geht auch nicht mehr. Ich setze die Startzeit über einen Dummy (Startzeit_BW1).
defmod di_Bewaesserung_BW1 DOIF ([Startzeit_BW1] and [Bewaesserung1] eq "an") (set KNX_0503002 on ;; set MessageTxt Bewaesserung_1 Start ) \
DOELSEIF ([([Startzeit_BW1] + [0:20])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503001 on ;; set KNX_0503002 off) \
DOELSEIF ([([Startzeit_BW1] + [0:30])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503003 on ;; set KNX_0503001 off) \
DOELSEIF ([([Startzeit_BW1] + [01:00])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 on ;; set KNX_0503003 off) \
DOELSEIF ([([Startzeit_BW1] + [01:50])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 off ;; set KNX_0503011 off;; set MessageTxt Bewaesserung_1 Ende )
attr di_Bewaesserung_BW1 room AUSSEN,KG->Maschinenraum
Zitat von: baerm am 26 April 2020, 21:23:17
Hi,
ich kann nur bestätigen, dass hier DOIFs in FHEM nicht gleich auslösen wie noch vor einiger Zeit. Anders kann ich mir nicht erklären, dass hier im Forum mittlerweile 3-4 Bewässerungs-DOIFs alle zeitgesteuert plötzlich nicht mehr funktionieren. Und das noch dazu bei diesem trockenen Frühling. Meine Variante geht auch nicht mehr. Ich setze die Startzeit über einen Dummy (Startzeit_BW1).
defmod di_Bewaesserung_BW1 DOIF ([Startzeit_BW1] and [Bewaesserung1] eq "an") (set KNX_0503002 on ;; set MessageTxt Bewaesserung_1 Start ) \
DOELSEIF ([([Startzeit_BW1] + [0:20])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503001 on ;; set KNX_0503002 off) \
DOELSEIF ([([Startzeit_BW1] + [0:30])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503003 on ;; set KNX_0503001 off) \
DOELSEIF ([([Startzeit_BW1] + [01:00])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 on ;; set KNX_0503003 off) \
DOELSEIF ([([Startzeit_BW1] + [01:50])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 off ;; set KNX_0503011 off;; set MessageTxt Bewaesserung_1 Ende )
attr di_Bewaesserung_BW1 room AUSSEN,KG->Maschinenraum
Bitte ein List des DOIF im "Fehlerzustand"
Anhand der RAW DEF kann man nut raten was der aktuelle Zustand ist.
Gesendet von meinem S68Pro mit Tapatalk
Was mir auf Anhieb auffällt:
(set KNX_0503001 on
;; set KNX_0503002 off) ist falsch:
ZitatAngaben im Ausführungsteil (gilt nur für FHEM-Modus): back
Der Ausführungsteil wird durch runde Klammern eingeleitet. Es werden standardmäßig FHEM-Befehle angegeben, wie z. B.: ...(set lamp on)
Sollen mehrere FHEM-Befehle ausgeführt werden, so werden sie mit Komma statt mit Semikolon angegeben ... (set lamp1 on, set lamp2 off)
Edit: Das dürfte auch falsch sein: [Startzeit_BW1] siehe Doku (https://fhem.de/commandref_DE.html#DOIF_Indirekten_Zeitangaben).
Das könnte so funktionieren:[[Startzeit_BW1]]
falls das voriges Jahr noch lief: Es besteht kein Anspruch auf die Beibehaltung von Fehlern. ;)
Verschwörungen gegen Bewässerungs DOIFs in der trockenen Zeit würde ich ausschließen. ;)
Gruß Otto
Hallo Otto,
stimmt, das kann man optimieren. Warum ich mir das so angewöhnt habe mit zwei Semikolon statt einem Komma weiß ich nicht. Dies ist aber sicher nicht die Ursache für mein Problem. Ich habe ca. 50 DOIFs, die alle so aufgebaut sind und alle funktionieren prächtig. Nur das DOIF der Bewässerung sollte zu einen bestimmten Uhrzeit starten und das geht nicht mehr. Übrigens gibt es ein weiteres DOIF für den Mäher, das auch nicht läuft. Dieses sollte auch zu einer bestimmten Uhrzeit gestartet werden. Bei Betrachtung der anderen DOIFs im Forum, die angeblich auch gerade nicht mehr funktionieren, ist mir aufgefallen, dass alle zu einer fixen Uhrzeit eingeschaltet werden sollten. Hier die lists:
Internals:
FUUID 5d83ec12-f33f-e2c0-b813-d376bc0b4b27cc0f
FVERSION 98_dummy.pm:0.206650/2019-12-06
NAME Startzeit_BW1
NR 505
STATE 19:55
TYPE dummy
READINGS:
2020-04-26 19:49:39 state 19:55
Attributes:
group Bewässerung
icon time_timer
room AUSSEN
Internals:
DEF ([Startzeit_BW1] and [Bewaesserung1] eq "an") (set KNX_0503002 on ; set MessageTxt Bewaesserung_1 Start )
DOELSEIF ([([Startzeit_BW1] + [0:20])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503001 on ; set KNX_0503002 off)
DOELSEIF ([([Startzeit_BW1] + [0:30])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503003 on ; set KNX_0503001 off)
DOELSEIF ([([Startzeit_BW1] + [01:00])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 on ; set KNX_0503003 off)
DOELSEIF ([([Startzeit_BW1] + [01:50])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 off ; set KNX_0503011 off; set MessageTxt Bewaesserung_1 Ende )
FUUID 5e9f434a-f33f-e2c0-1dd9-285490e95a58c7f6
FVERSION 98_DOIF.pm:0.212240/2020-02-18
MODEL FHEM
NAME di_Bewaesserung_BW1
NOTIFYDEV Bewaesserung1,KNX_0503011,global,Startzeit_BW1
NR 906
NTFY_ORDER 50-di_Bewaesserung_BW1
STATE cmd_3
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-04-26 19:59:53 Device KNX_0503011
2020-04-26 20:25:00 cmd 3
2020-04-26 20:25:00 cmd_event timer_2
2020-04-26 20:25:00 cmd_nr 3
2020-04-26 19:59:53 e_KNX_0503011_state on
2020-04-26 19:49:39 e_Startzeit_BW1_STATE 19:55
2020-04-21 21:08:49 mode enabled
2020-04-26 20:25:00 state cmd_3
2020-04-26 20:15:00 timer_01_c02 27.04.2020 20:15:00
2020-04-26 20:25:00 timer_02_c03 27.04.2020 20:25:00
2020-04-26 19:49:39 timer_03_c04 26.04.2020 20:55:00
2020-04-26 19:49:39 timer_04_c05 26.04.2020 21:45:00
Regex:
accu:
cond:
Bewaesserung1:
0:
&STATE ^Bewaesserung1$
1:
&STATE ^Bewaesserung1$
2:
&STATE ^Bewaesserung1$
3:
&STATE ^Bewaesserung1$
4:
&STATE ^Bewaesserung1$
KNX_0503011:
0:
1:
state ^KNX_0503011$:^state:
2:
state ^KNX_0503011$:^state:
3:
state ^KNX_0503011$:^state:
4:
state ^KNX_0503011$:^state:
Startzeit_BW1:
0:
&STATE ^Startzeit_BW1$
itimer:
Startzeit_BW1:
itimer:
&STATE ^Startzeit_BW1$
attr:
cmdState:
wait:
waitdel:
condition:
0 ::InternalDoIf($hash,'Startzeit_BW1','STATE') and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an"
1 ::DOIF_time_once($hash,0,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
2 ::DOIF_time_once($hash,1,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
3 ::DOIF_time_once($hash,2,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
4 ::DOIF_time_once($hash,3,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
days:
devices:
do:
0:
0 set KNX_0503002 on ; set MessageTxt Bewaesserung_1 Start
1:
0 set KNX_0503001 on ; set KNX_0503002 off
2:
0 set KNX_0503003 on ; set KNX_0503001 off
3:
0 set KNX_0503000 on ; set KNX_0503003 off
4:
0 set KNX_0503000 off ; set KNX_0503011 off; set MessageTxt Bewaesserung_1 Ende
5:
helper:
DEVFILTER ^global$|^KNX_0503011$|^Startzeit_BW1$|^Bewaesserung1$
NOTIFYDEV global|KNX_0503011|Startzeit_BW1|Bewaesserung1
event timer_2
globalinit 1
last_timer 4
sleeptimer -1
timerdev
timerevent timer_2
triggerDev
timerevents:
timer_2
timereventsState:
timer_2
triggerEvents:
timer_2
triggerEventsState:
timer_2
internals:
all Startzeit_BW1:STATE Bewaesserung1:STATE
interval:
intervalfunc:
intervaltimer:
localtime:
0 1588011300
1 1588011900
2 1587927300
3 1587930300
perlblock:
readings:
all KNX_0503011:state
realtime:
0 20:15:00
1 20:25:00
2 20:55:00
3 21:45:00
time:
0 ([Startzeit_BW1]+[0:20])
1 ([Startzeit_BW1]+[0:30])
2 ([Startzeit_BW1]+[01:00])
3 ([Startzeit_BW1]+[01:50])
timeCond:
0 1
1 2
2 3
3 4
timer:
0 0
1 0
2 0
3 0
timers:
1 0
2 1
3 2
4 3
trigger:
triggertime:
1587927300:
localtime 1587927300
hash:
1587930300:
localtime 1587930300
hash:
1588011300:
localtime 1588011300
hash:
1588011900:
localtime 1588011900
hash:
uiState:
uiTable:
Attributes:
room AUSSEN,KG->Maschinenraum
[Startzeit_BW1] war voriges Jahr schon syntaktisch falsch und erzeugt auch keinen Timer timer_01_c01:
Zitat2020-04-26 20:25:00 state cmd_3
2020-04-26 20:15:00 timer_01_c02 27.04.2020 20:15:00
Also nun mit korrigiertem DOIF probiert. Wie vermutet machte dies keinen Unterschied.
Startzeit 07:00 und DOIF steht in "inizialized" und es tut sich um 07:00 nichts....
Internals:
FUUID 5d83ec12-f33f-e2c0-b813-d376bc0b4b27cc0f
FVERSION 98_dummy.pm:0.206650/2019-12-06
NAME Startzeit_BW1
NR 505
STATE 07:00
TYPE dummy
READINGS:
2020-04-26 22:46:10 state 07:00
Attributes:
group Bewässerung
icon time_timer
room AUSSEN
Internals:
DEF ([Startzeit_BW1] and [Bewaesserung1] eq "an") (set KNX_0503002 on, set MessageTxt Bewaesserung_1 Start )
DOELSEIF ([([Startzeit_BW1] + [0:20])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503001 on, set KNX_0503002 off)
DOELSEIF ([([Startzeit_BW1] + [0:30])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503003 on, set KNX_0503001 off)
DOELSEIF ([([Startzeit_BW1] + [01:00])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 on, set KNX_0503003 off)
DOELSEIF ([([Startzeit_BW1] + [01:50])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 off, set KNX_0503011 off, set MessageTxt Bewaesserung_1 Ende )
FUUID 5e9f434a-f33f-e2c0-1dd9-285490e95a58c7f6
FVERSION 98_DOIF.pm:0.212240/2020-02-18
MODEL FHEM
NAME di_Bewaesserung_BW1
NOTIFYDEV KNX_0503011,Bewaesserung1,global,Startzeit_BW1
NR 906
NTFY_ORDER 50-di_Bewaesserung_BW1
STATE initialized
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-04-27 02:00:00 Device KNX_0503011
2020-04-26 22:46:43 cmd 0
2020-04-26 22:46:10 cmd_event Startzeit_BW1
2020-04-26 22:46:10 cmd_nr 1
2020-04-27 02:00:00 e_KNX_0503011_state off
2020-04-26 22:46:10 e_Startzeit_BW1_STATE 07:00
2020-04-26 22:46:43 mode enabled
2020-04-26 22:46:43 state initialized
2020-04-27 07:20:00 timer_01_c02 28.04.2020 07:20:00
2020-04-27 07:30:00 timer_02_c03 28.04.2020 07:30:00
2020-04-27 08:00:00 timer_03_c04 28.04.2020 08:00:00
2020-04-26 22:46:43 timer_04_c05 27.04.2020 08:50:00
Regex:
accu:
cond:
Bewaesserung1:
0:
&STATE ^Bewaesserung1$
1:
&STATE ^Bewaesserung1$
2:
&STATE ^Bewaesserung1$
3:
&STATE ^Bewaesserung1$
4:
&STATE ^Bewaesserung1$
KNX_0503011:
0:
1:
state ^KNX_0503011$:^state:
2:
state ^KNX_0503011$:^state:
3:
state ^KNX_0503011$:^state:
4:
state ^KNX_0503011$:^state:
Startzeit_BW1:
0:
&STATE ^Startzeit_BW1$
itimer:
Startzeit_BW1:
itimer:
&STATE ^Startzeit_BW1$
attr:
cmdState:
wait:
waitdel:
condition:
0 ::InternalDoIf($hash,'Startzeit_BW1','STATE') and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an"
1 ::DOIF_time_once($hash,0,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
2 ::DOIF_time_once($hash,1,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
3 ::DOIF_time_once($hash,2,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
4 ::DOIF_time_once($hash,3,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
days:
devices:
do:
0:
0 set KNX_0503002 on, set MessageTxt Bewaesserung_1 Start
1:
0 set KNX_0503001 on, set KNX_0503002 off
2:
0 set KNX_0503003 on, set KNX_0503001 off
3:
0 set KNX_0503000 on, set KNX_0503003 off
4:
0 set KNX_0503000 off, set KNX_0503011 off, set MessageTxt Bewaesserung_1 Ende
5:
helper:
DEVFILTER ^global$|^Startzeit_BW1$|^KNX_0503011$|^Bewaesserung1$
NOTIFYDEV global|Startzeit_BW1|KNX_0503011|Bewaesserung1
event timer_3
globalinit 1
last_timer 4
sleeptimer -1
timerdev
timerevent
timerevents
timereventsState
triggerDev
triggerEvents:
timer_3
triggerEventsState:
timer_3
internals:
all Startzeit_BW1:STATE Bewaesserung1:STATE
interval:
intervalfunc:
localtime:
0 1588051200
1 1588051800
2 1588053600
3 1587970200
readings:
all KNX_0503011:state
realtime:
0 07:20:00
1 07:30:00
2 08:00:00
3 08:50:00
time:
0 ([Startzeit_BW1]+[0:20])
1 ([Startzeit_BW1]+[0:30])
2 ([Startzeit_BW1]+[01:00])
3 ([Startzeit_BW1]+[01:50])
timeCond:
0 1
1 2
2 3
3 4
timer:
0 0
1 0
2 0
3 0
timers:
1 0
2 1
3 2
4 3
trigger:
triggertime:
1587970200:
localtime 1587970200
hash:
1588051200:
localtime 1588051200
hash:
1588051800:
localtime 1588051800
hash:
1588053600:
localtime 1588053600
hash:
uiState:
uiTable:
Attributes:
room AUSSEN,KG->Maschinenraum
Du musst schon die korrekte Syntax für indirekte Timer benutzen, so wie sie Otto bereits vorgeschlagen hat, siehe https://fhem.de/commandref_DE.html#DOIF_Indirekten_Zeitangaben
Sorry, das ist jetzt wirklich mein Fehler. :o Ursprünglich hatte ich folgende Syntax für die erste Bedingung: ([([Startzeit_BW1])] and [Bewaesserung1] eq "an") und im Zuge meines Herumprobierens auf ([Startzeit_BW1] and [Bewaesserung1] eq "an") geändert, was nicht korrekt ist. Das habe ich nicht bemerkt.
Ich habe jetzt die erste Bedingung wieder korrigiert (diesmal mit ([[Startzeit_BW1]] and [Bewaesserung1] eq "an") um mich genau an die Vorgabe zu halten und ich sehe wieder alle timer_01 bis timer_05 (wie es auch schon in der Vergangenheit war - hat ja so längste Zeit funktioniert). Mit der jetzt eingebrachten Korrektur hat es aber wieder nicht funktioniert. Dummy auf 08:45 gesetzt und DOIF war auf "initialized". Was ist hier noch immer falsch?
Internals:
FUUID 5d83ec12-f33f-e2c0-b813-d376bc0b4b27cc0f
FVERSION 98_dummy.pm:0.206650/2019-12-06
NAME Startzeit_BW1
NR 505
STATE 08:45
TYPE dummy
READINGS:
2020-04-27 09:42:43 state 08:45
Attributes:
group Bewässerung
icon time_timer
room AUSSEN
Internals:
DEF ([[Startzeit_BW1]] and [Bewaesserung1] eq "an") (set KNX_0503002 on, set MessageTxt Bewaesserung_1 Start )
DOELSEIF ([([Startzeit_BW1] + [0:20])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503001 on, set KNX_0503002 off)
DOELSEIF ([([Startzeit_BW1] + [0:30])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503003 on, set KNX_0503001 off)
DOELSEIF ([([Startzeit_BW1] + [01:00])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 on, set KNX_0503003 off)
DOELSEIF ([([Startzeit_BW1] + [01:50])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 off, set KNX_0503011 off, set MessageTxt Bewaesserung_1 Ende )
FUUID 5e9f434a-f33f-e2c0-1dd9-285490e95a58c7f6
FVERSION 98_DOIF.pm:0.212240/2020-02-18
MODEL FHEM
NAME di_Bewaesserung_BW1
NOTIFYDEV Bewaesserung1,KNX_0503011,Startzeit_BW1,global
NR 906
NTFY_ORDER 50-di_Bewaesserung_BW1
STATE initialized
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-04-27 09:35:00 Device KNX_0503011
2020-04-27 09:39:10 cmd 0
2020-04-27 09:35:00 e_KNX_0503011_state off
2020-04-27 09:39:10 mode enabled
2020-04-27 09:39:10 state initialized
2020-04-27 09:42:43 timer_01_c01 28.04.2020 08:45:00
2020-04-27 09:42:43 timer_02_c02 28.04.2020 09:05:00
2020-04-27 09:42:43 timer_03_c03 28.04.2020 09:15:00
2020-04-27 09:45:00 timer_04_c04 28.04.2020 09:45:00
2020-04-27 09:42:43 timer_05_c05 27.04.2020 10:35:00
Regex:
accu:
cond:
Bewaesserung1:
0:
&STATE ^Bewaesserung1$
1:
&STATE ^Bewaesserung1$
2:
&STATE ^Bewaesserung1$
3:
&STATE ^Bewaesserung1$
4:
&STATE ^Bewaesserung1$
KNX_0503011:
1:
state ^KNX_0503011$:^state:
2:
state ^KNX_0503011$:^state:
3:
state ^KNX_0503011$:^state:
4:
state ^KNX_0503011$:^state:
itimer:
Startzeit_BW1:
itimer:
&STATE ^Startzeit_BW1$
attr:
cmdState:
wait:
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an"
1 ::DOIF_time_once($hash,1,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
2 ::DOIF_time_once($hash,2,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
3 ::DOIF_time_once($hash,3,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
4 ::DOIF_time_once($hash,4,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
days:
devices:
do:
0:
0 set KNX_0503002 on, set MessageTxt Bewaesserung_1 Start
1:
0 set KNX_0503001 on, set KNX_0503002 off
2:
0 set KNX_0503003 on, set KNX_0503001 off
3:
0 set KNX_0503000 on, set KNX_0503003 off
4:
0 set KNX_0503000 off, set KNX_0503011 off, set MessageTxt Bewaesserung_1 Ende
5:
helper:
DEVFILTER ^global$|^KNX_0503011$|^Bewaesserung1$|^Startzeit_BW1$
NOTIFYDEV global|KNX_0503011|Bewaesserung1|Startzeit_BW1
event timer_4
globalinit 1
last_timer 5
sleeptimer -1
triggerDev
triggerEvents:
timer_4
triggerEventsState:
timer_4
internals:
all Bewaesserung1:STATE
interval:
intervalfunc:
intervaltimer:
localtime:
0 1588056300
1 1588057500
2 1588058100
3 1588059900
4 1587976500
readings:
all KNX_0503011:state
realtime:
0 08:45:00
1 09:05:00
2 09:15:00
3 09:45:00
4 10:35:00
time:
0 [Startzeit_BW1]
1 ([Startzeit_BW1]+[0:20])
2 ([Startzeit_BW1]+[0:30])
3 ([Startzeit_BW1]+[01:00])
4 ([Startzeit_BW1]+[01:50])
timeCond:
0 0
1 1
2 2
3 3
4 4
timer:
0 0
1 0
2 0
3 0
4 0
timers:
0 0
1 1
2 2
3 3
4 4
triggertime:
1587976500:
localtime 1587976500
hash:
1588056300:
localtime 1588056300
hash:
1588057500:
localtime 1588057500
hash:
1588058100:
localtime 1588058100
hash:
1588059900:
localtime 1588059900
hash:
uiState:
uiTable:
Attributes:
room AUSSEN,KG->Maschinenraum
Du hast um 9.42 deinen dummy auf 8.45 gestellt?
Gesendet von meinem S68Pro mit Tapatalk
Und der entscheidende Schalter ging aus, deswegen kommen die anderen Zweige auch nicht zum Zug.
2020-04-27 09:35:00 e_KNX_0503011_state off
Ups. Ist mir schon peinlich. Werde in Zukunft erst posten, wenn ich alles genau überprüft habe.
Funktioniert jetzt wie es soll. e_KNX_0503011_state ist in der ersten Bedingung nicht relevant und wird über ein zweites DOIF gesteuert.
Danke für Eure Hilfe. Verstehen tue ich es trotzdem nicht warum es plötzlich nicht mehr funktioniert hat. Eventuell war folgende Syntax nicht mehr ok ([([Startzeit_BW1])] and [Bewaesserung1] eq "an")....
Auch bei mir gibt es neue Erkenntnisse.
Wie vermutet scheint das Attribut cmdpause der Übeltäter zu sein.
Setze ich die "Wartezeit" auf "0" ,
d.h.
attr controller_BEWAESSERUNG_GARTEN cmdpause 0:0:0:0:0
statt
attr controller_BEWAESSERUNG_GARTEN cmdpause 86400:86400:0:0:0
funktioniert auch das Triggern des DOIF bei Sonnenaufgang wie es soll.
Kann es sein, dass der Wert mit 24 Stunden = 86400 Sekunden zu groß ist?
Wurde evtl. mit einem der Updates (in den letzten Monaten 8)) der Wertebereich dieser Variablen geändert?
Hat jemand eine Idee wie sich das Problem beseitigen lässt? Oder evtl. einen Vorschlag wie ich das "Pausieren" anders abbilden könnte?
Zitat von: fast-eddy am 27 April 2020, 14:42:18
Kann es sein, dass der Wert mit 24 Stunden = 86400 Sekunden zu groß ist?
Na ja,
Momentan werden die Tage länger. d.h. der morgige SA ist weniger als 86400 Sekunden nach dem heutigen.
nach dem 21. Juni dagegen werden die Tage wieder kürzer. da ist der jeweils morgige SA mehr als 86400 Sek entfernt und das DOIF dürfte wieder funktionieren.
@Frank: AUTSCH! :-[
Das macht absolut Sinn, da kann ich den Fehler lange in der Syntax suchen falls Deine Vermutung zutrifft!
Dagegen spricht allerdings, dass das DOIF dann halt einen Tag verzögert auslösen müsste - was es aber soweit ich es beobachtet habe nicht tut.
@Frank:
Auch die Tatsache, dass sich die ersten beiden CMD Zweige nicht manuell triggern lassen wenn das ein großer Wert
in cmdpause steht spricht leider gegen Deine Theorie.
EDIT: Habe es gerade noch mal ausprobiert. Es liegt definitiv am cmdpause selbst!?
Das DOIF löst grundsätzlich nicht aus wenn das Attribut cmdpause einen zweistelligen Wert mitbekommt :o
Kann auch sein dass das deine Absicht war. Zumindest sagt deine Benachrichtigung in CMD1 und CMD2 "nächster Start in 48 Std".
Wenn Du mit "set DOIF CMD_1" den Zweig nicht manuell starten kannst ist auch bei den Befehlen was faul.
Was sagt denn das FHEM Log nach dem manuellen Versuch?
@Frank:
Du warst schneller (siehe EDIT oben)
Das DOIF löst grundsätzlich nicht aus wenn das Attribut cmdpause einen zweistelligen Wert mitbekommt Zu Deiner letzten Frage:
ZitatKann auch sein dass das deine Absicht war. Zumindest sagt deine Benachrichtigung in CMD1 und CMD2 "nächster Start in 48 Std".
Wenn das DOIF 24h aussetzt dann ist die nächste Auslösung in 48 Stunden ;)
ZitatWas sagt denn das FHEM Log nach dem manuellen Versuch?
Gar nichts! Kein Eintrag?!
Zitat von: fast-eddy am 27 April 2020, 15:25:12
@Frank:
Zu Deiner letzten Frage:Wenn das DOIF 24h aussetzt dann ist die nächste Auslösung in 48 Stunden ;)
Aber nur bis zum 21. Juni, da ist Sonnenwende und die Tage werden kürzer und das DOIF startet alle 24 Std. :)
@Frank:
Ich steh´da gerade auf dem Schlauch aber ich vermute Du hast recht.
Hast Du eine Idee wie man das anders (dynamisch?) abbilden könnte?
Das Problem das cmdpause nur Werte < 10 Sekunden verträgt hat
damit imho aber erst mal nichts tun. Konnte das Verhalten gerade auch bei
zwei anderen DOIF verifizieren :-|
Das hat bis vor kurzem definitiv in mehreren DOIF zuverlässig funktioniert.
mit 10Sek kann ich dein DOIF abfeuern. aber eben nur nach mehr als 10Sek jeweils.
Bin mir nicht ganz sicher, aber es kann auch sein dass die cmdpause erst losläuft wenn der Zweig abgearbeitet ist.
Da du aber 5 Minuten Pause wür den zweiten Wasserbefehl hast kommen die noch oben drauf.
Zitat von: Frank_Huber am 27 April 2020, 15:44:33
mit 10Sek kann ich dein DOIF abfeuern. aber eben nur nach mehr als 10Sek jeweils.
...hmmm!?
Jetzt verwirrst Du mich etwas. Bei mir funktionieren nur max 9 Sekunden - ab 10 Sekunden tut sich gar nix mehr
ZitatBin mir nicht ganz sicher, aber es kann auch sein dass die cmdpause erst losläuft wenn der Zweig abgearbeitet ist.
Da du aber 5 Minuten Pause wür den zweiten Wasserbefehl hast kommen die noch oben drauf.
Das setzen von cmdpause sollte sich m.E. nur auf die ausführung des nächsten Triggers auswirken. Das manuelle Auslösen
sollte dagegen alle Conditions ignorieren - so habe ich zumindest die commandref verstanden.
Das wait Attribut gehört zum Ausführungsteil.
ohne das wait Attribut geht dein DOIF auch mit 100Sek in cmdpause.
???
Das verstehe ich jetzt nicht!
Die 1. Frage ist doch warum lösen weder cmd_1 noch cmd_2 aus, wenn bei cmdpause x:y:0:0 mit x|y >9 ?
Wenn wait hier reinpfuscht würden ja nur 1.3 bzw 2.3 gar nicht oder verzögert auslösen
Und 2. was hat sich geändert, dass gleichzeitig mehrere DOIF mit dieser Konstruktion ohne Änderung
bei mir nicht mehr funktionieren?
Ich beharre ja nicht drauf, dass meine bisherige Konstruktion korrekt war oder um es mit Ottos Worten zu
formulieren
ZitatEs besteht kein Anspruch auf die Beibehaltung von Fehlern.
;)
Aber um es zu korrigieren, muss ich erst verstehen wo mein Fehler liegt und was ich anderes machen muss?
Wenn ich das jetzt richtig sehe läuft die Zeit der cmdpause los nachdem der ganze Zweig abgearbeitet ist.
Und das ist er erst nachdem cmd_x_3 ausgeführt wurde nach den 5 Minuten.
Zitat von: Frank_Huber am 27 April 2020, 16:38:51
Wenn ich das jetzt richtig sehe läuft die Zeit der cmdpause los nachdem der ganze Zweig abgearbeitet ist.
Und das ist er erst nachdem cmd_x_3 ausgeführt wurde nach den 5 Minuten.
Soweit kann ich Dir folgen. Aber dazu muss das DOIF halt erst mal getriggert werden was es nicht tut (weder manuell noch via sunset_el) wenn die Verzögerung bei cmdpause > 9 Sekunden ist :-\
Ich bin mit euren Tests nicht mitgekommen. ::)
Zwei Zitate aus der Doku:
Bei wait steht in der Doku:
ZitatDie Verzögerungszeit bezieht sich immer auf den vorherigen Befehl.
Bei cmdpause weiß ich nicht, ob es auch für manuell auslösen wirkt:
ZitatZwangspause für das Ausführen eines Kommandos seit der letzten Zustandsänderung back
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.
Hallo Otto,
das Problem ist ja nicht, dass cmdpause nicht greift, dh. nicht pausiert wird, sondern dass die Zweige des DOIF überhaupt nicht getriggert werden (weder manuell noch zeitgesteuert) bei denen im im Attribut cmdpause Werte >9 stehen.
Das Problem ist bei mir in mehreren DOIF reproduierbar und trat vor dem ersten Update nach langer Zeit, das ich vor zwei Wochen durchgeführt habe definitiv nicht auf. Hat das komplette letzte Jahr zuverlässig funktioniert.
Hast Du eine Idee was die Ursache sein könnte ? Hat sich da was am Wertebereich der Parameter bei cmdpause vereändert? Oder habe ich da etwa einen alten Syntaxfehler eingebaut, der sich erst jetzt auswirkt?
Bin gespannt auf dein Feedback...
Wie oft melden sich die andere Sensoren? NIEDERSCHLAG, GARTEN, garten_SWC_02 und 03?
Und wie stellst Du fest, dass "die Zweige des DOIF überhaupt nicht getriggert werden"? Wartest Du jedes Mal auf {sunrise} ?
Ich würde gerne ein "list" des DOIFs morgen früh sehen (nach sunrise)
Dass cmdpause > 9 nicht funktioniert, kann ich nicht nachvollziehen.
Gegenbeweis:
defmod di_test DOIF ([FS])
attr di_test cmdpause 10
attr di_test do always
FS ist ein Dummy, testen kann man es mit trigger FS.
Nach 10 Sekunden wird cmd_1 immer ausgeführt, wenn das Modul angetriggert wird.
Guten Morgen,
mein gestern korrigiertes DOIF, dass einmal durchgelaufen ist, funktionierte heute Früh um 07:30 wieder nicht. Habs um 08:46 nochmal versucht und ist wieder nicht gelaufen. Was stimmt hier nicht?
Internals:
DEF ([[Startzeit_BW1]] and [Bewaesserung1] eq "an") (set KNX_0503002 on, set MessageTxt Bewaesserung_1 Start )
DOELSEIF ([([Startzeit_BW1] + [0:20])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503001 on, set KNX_0503002 off)
DOELSEIF ([([Startzeit_BW1] + [0:30])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503003 on, set KNX_0503001 off)
DOELSEIF ([([Startzeit_BW1] + [01:00])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 on, set KNX_0503003 off)
DOELSEIF ([([Startzeit_BW1] + [01:50])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 off, set KNX_0503011 off, set MessageTxt Bewaesserung_1 Ende )
FUUID 5e9f434a-f33f-e2c0-1dd9-285490e95a58c7f6
FVERSION 98_DOIF.pm:0.212240/2020-02-18
MODEL FHEM
NAME di_Bewaesserung_BW1
NOTIFYDEV KNX_0503011,global,Startzeit_BW1,Bewaesserung1
NR 904
NTFY_ORDER 50-di_Bewaesserung_BW1
STATE initialized
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-04-28 08:47:43 cmd 0
2020-04-28 08:47:43 mode enabled
2020-04-28 08:47:43 state initialized
2020-04-28 08:47:43 timer_01_c01 29.04.2020 08:46:00
2020-04-28 08:47:43 timer_02_c02 28.04.2020 09:06:00
2020-04-28 08:47:43 timer_03_c03 28.04.2020 09:16:00
2020-04-28 08:47:43 timer_04_c04 28.04.2020 09:46:00
2020-04-28 08:47:43 timer_05_c05 28.04.2020 10:36:00
Regex:
accu:
cond:
Bewaesserung1:
0:
&STATE ^Bewaesserung1$
1:
&STATE ^Bewaesserung1$
2:
&STATE ^Bewaesserung1$
3:
&STATE ^Bewaesserung1$
4:
&STATE ^Bewaesserung1$
KNX_0503011:
1:
state ^KNX_0503011$:^state:
2:
state ^KNX_0503011$:^state:
3:
state ^KNX_0503011$:^state:
4:
state ^KNX_0503011$:^state:
itimer:
Startzeit_BW1:
itimer:
&STATE ^Startzeit_BW1$
attr:
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an"
1 ::DOIF_time_once($hash,1,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
2 ::DOIF_time_once($hash,2,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
3 ::DOIF_time_once($hash,3,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
4 ::DOIF_time_once($hash,4,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
days:
do:
0:
0 set KNX_0503002 on, set MessageTxt Bewaesserung_1 Start
1:
0 set KNX_0503001 on, set KNX_0503002 off
2:
0 set KNX_0503003 on, set KNX_0503001 off
3:
0 set KNX_0503000 on, set KNX_0503003 off
4:
0 set KNX_0503000 off, set KNX_0503011 off, set MessageTxt Bewaesserung_1 Ende
5:
helper:
DEVFILTER ^global$|^KNX_0503011$|^Bewaesserung1$|^Startzeit_BW1$
NOTIFYDEV global|KNX_0503011|Bewaesserung1|Startzeit_BW1
globalinit 1
last_timer 5
sleeptimer -1
internals:
all Bewaesserung1:STATE
intervalfunc:
localtime:
0 1588142760
1 1588057560
2 1588058160
3 1588059960
4 1588062960
readings:
all KNX_0503011:state
realtime:
0 08:46:00
1 09:06:00
2 09:16:00
3 09:46:00
4 10:36:00
time:
0 [Startzeit_BW1]
1 ([Startzeit_BW1]+[0:20])
2 ([Startzeit_BW1]+[0:30])
3 ([Startzeit_BW1]+[01:00])
4 ([Startzeit_BW1]+[01:50])
timeCond:
0 0
1 1
2 2
3 3
4 4
timer:
0 0
1 0
2 0
3 0
4 0
timers:
0 0
1 1
2 2
3 3
4 4
triggertime:
1588057560:
localtime 1588057560
hash:
1588058160:
localtime 1588058160
hash:
1588059960:
localtime 1588059960
hash:
1588062960:
localtime 1588062960
hash:
1588142760:
localtime 1588142760
hash:
uiState:
uiTable:
Attributes:
room AUSSEN,KG->Maschinenraum
@ amenomade
Danke für Deine Antwort.
Zitat von: amenomade am 28 April 2020, 01:23:37
Wie oft melden sich die andere Sensoren? NIEDERSCHLAG, GARTEN, garten_SWC_02 und 03?
NIEDERSCHLAG ist ein Z-Wave Device und ziemlich faul - Meldet sich wenn es nicht regnet u.U. nur alle 24 Stunden
GARTEN und garten_SWC_x sind Homatic Geräte die sich i.d.R so alle 3 Minuten melden. Die Werte angezeigten sind auch plausibel...
ZitatUnd wie stellst Du fest, dass "die Zweige des DOIF überhaupt nicht getriggert werden"? Wartest Du jedes Mal auf {sunrise} ?
Indem ich
set cmd_x absetze oder wie vermutet auf
{sunrise} warte (da steh´ ich auf dem Schlauch wie ich das manuell triggern könnte :-[ )
ZitatIch würde gerne ein "list" des DOIFs morgen früh sehen (nach sunrise)
Habe Deine Antwort gerade erst gesehen und in der Zwischenzeit war ich weiter am testen. Daher ist das "list" jetzt wohl leider nicht mehr wirklich aussagekräftig - werde gleich morgen früh eines "jungfräuliches" erstellen.
@Damian
Auch Dir danke für Deine Unterstützung!
ZitatDass cmdpause > 9 nicht funktioniert, kann ich nicht nachvollziehen.
...hmmm?
Vielleicht liegt es dann an meiner Formatierung? Ich habe ja cmdpause für mehrere commands gesetzt:
attr controller_BEWAESSERUNG_GARTEN cmdpause 86400:86400:0:0:0Habe gestern Abend zum Testen mal
attr controller_BEWAESSERUNG_GARTEN cmdpause 0:0:0:0:0 gesetzt und schon läuft alles wie es soll ?!
@Matthias Du warst mit deinem Versuch aber zu spät :)
Zitat2020-04-28 08:47:43 timer_01_c01 29.04.2020 08:46:00
Damit wird der test den Du heute morgen wolltest erst morgen :)
Warum es heute morgen nicht ging kann ich nicht sagen. Es wäre ev. gut gewesen ohne Veränderung erstmal ein list zu machen, da sieht man eventuell woran es gelegen hat.
Gruß Otto
Hallo Otto,
Das list habe ich leider erst nach einer Änderung erstellt. Ich werde morgen den selben Test machen und das List vorher und nachher erstellen.
lg,
Matthias
Sorry Matthias, ich kenne auch einen Michael Baer :)
mir fällt noch folgendes auf, ich bin aber unsicher!
Dein erster Zweig hat einen Eventtrigger (Zeit) und den Zustand von Bewaesserung1.
([[Startzeit_BW1]] and [Bewaesserung1] eq "an")
Wenn sich der Zustand von Bewaesserung1 nie ändert und die anderen DOELSEIF Zweige auch nicht wahr werden, ändert sich der Zustand des DOIF nicht. Tritt dann folgendes ein?
ZitatIm FHEM-Modus arbeitet das Modul mit Zuständen, indem es den eigenen Status auswertet. Die Ausführung erfolgt standardmäßig nur ein mal, bis ein anderer DOIF-Zweig und damit eine Ändernung des eigenen Status erfolgt.
...
Wünscht man eine Ausführung des gleichen Befehls mehrfach nacheinander bei jedem Trigger, unabhängig davon welchen Status das DOIF-Modul hat,..., dann muss man das per "do always"-Attribut angeben:
Würde das "das einmal durchgelaufen ist" erklären ;)
Gruß Otto
@Otto: eigentlich bin ich auf einer ähnliche Spur:
- entweder befindet sich der DOIF in einem Zweig woraus er nicht mehr kommt (wäre der Fall für baer: kein DOELSE und kein do always)
- oder er wird durch eine andere Triggerung (nach sunrise) in einen anderen Zustand versetzt, was die Timer abbricht. (wäre der Fall für fast-eddy). Deswegen habe ich nach einem "list" des DOIFs im "falschen" Zustand nach sunrise nachgefragt. Da war auf jeden Fall deine Empfehlung, die andere Bedingungen von [...] auf [?...] zu ändern, nicht schlecht.
Hallo Otto,
vielen Dank für den Hinweis. Do always habe ich sonst gesetzt, aber offensichtlich bei diesem nicht. hmmmm :-\
Ich habe zwei Bedingungen im ersten Zweig und die Zeitangabe trifft zumindest einmal pro Tag zu. Wenn ich dafür das Do always benötige, werde ich es hinzufügen. Übrigens setze ich Bewaesserung1 über einen Dummy (setList) um damit diese Funktion ein und ausschalten zu können. Ich werde das Doif bis morgen noch so belassen, wie es ist. Heute habe ich es manuell gestartet. Morgen 8:55 sollte es wieder laufen.
Internals:
DEF ([[Startzeit_BW1]] and [Bewaesserung1] eq "an") (set KNX_0503002 on, set MessageTxt Bewaesserung_1 Start )
DOELSEIF ([([Startzeit_BW1] + [0:20])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503001 on, set KNX_0503002 off)
DOELSEIF ([([Startzeit_BW1] + [0:30])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503003 on, set KNX_0503001 off)
DOELSEIF ([([Startzeit_BW1] + [01:00])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 on, set KNX_0503003 off)
DOELSEIF ([([Startzeit_BW1] + [01:50])] and [Bewaesserung1] eq "an" and [KNX_0503011:state] eq "on") (set KNX_0503000 off, set KNX_0503011 off, set MessageTxt Bewaesserung_1 Ende )
FUUID 5e9f434a-f33f-e2c0-1dd9-285490e95a58c7f6
FVERSION 98_DOIF.pm:0.212240/2020-02-18
MODEL FHEM
NAME di_Bewaesserung_BW1
NOTIFYDEV KNX_0503011,global,Startzeit_BW1,Bewaesserung1
NR 904
NTFY_ORDER 50-di_Bewaesserung_BW1
STATE cmd_5
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-04-28 09:11:01 Device KNX_0503011
2020-04-28 10:45:00 cmd 5
2020-04-28 10:45:00 cmd_event timer_5
2020-04-28 10:45:00 cmd_nr 5
2020-04-28 09:11:01 e_KNX_0503011_state on
2020-04-28 08:47:43 mode enabled
2020-04-28 10:45:00 state cmd_5
2020-04-28 09:10:46 timer_01_c01 29.04.2020 08:55:00
2020-04-28 09:15:00 timer_02_c02 29.04.2020 09:15:00
2020-04-28 09:25:00 timer_03_c03 29.04.2020 09:25:00
2020-04-28 09:55:00 timer_04_c04 29.04.2020 09:55:00
2020-04-28 10:45:00 timer_05_c05 29.04.2020 10:45:00
Regex:
accu:
cond:
Bewaesserung1:
0:
&STATE ^Bewaesserung1$
1:
&STATE ^Bewaesserung1$
2:
&STATE ^Bewaesserung1$
3:
&STATE ^Bewaesserung1$
4:
&STATE ^Bewaesserung1$
KNX_0503011:
0:
1:
state ^KNX_0503011$:^state:
2:
state ^KNX_0503011$:^state:
3:
state ^KNX_0503011$:^state:
4:
state ^KNX_0503011$:^state:
itimer:
Startzeit_BW1:
itimer:
&STATE ^Startzeit_BW1$
attr:
cmdState:
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an"
1 ::DOIF_time_once($hash,1,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
2 ::DOIF_time_once($hash,2,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
3 ::DOIF_time_once($hash,3,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
4 ::DOIF_time_once($hash,4,$wday) and ::InternalDoIf($hash,'Bewaesserung1','STATE') eq "an" and ::ReadingValDoIf($hash,'KNX_0503011','state') eq "on"
days:
do:
0:
0 set KNX_0503002 on, set MessageTxt Bewaesserung_1 Start
1:
0 set KNX_0503001 on, set KNX_0503002 off
2:
0 set KNX_0503003 on, set KNX_0503001 off
3:
0 set KNX_0503000 on, set KNX_0503003 off
4:
0 set KNX_0503000 off, set KNX_0503011 off, set MessageTxt Bewaesserung_1 Ende
5:
helper:
DEVFILTER ^global$|^KNX_0503011$|^Bewaesserung1$|^Startzeit_BW1$
NOTIFYDEV global|KNX_0503011|Bewaesserung1|Startzeit_BW1
event timer_5
globalinit 1
last_timer 5
sleeptimer -1
timerdev
timerevent timer_5
triggerDev
timerevents:
timer_5
timereventsState:
timer_5
internals:
all Bewaesserung1:STATE
interval:
intervalfunc:
intervaltimer:
localtime:
0 1588143300
1 1588144500
2 1588145100
3 1588146900
4 1588149900
readings:
all KNX_0503011:state
realtime:
0 08:55:00
1 09:15:00
2 09:25:00
3 09:55:00
4 10:45:00
time:
0 [Startzeit_BW1]
1 ([Startzeit_BW1]+[0:20])
2 ([Startzeit_BW1]+[0:30])
3 ([Startzeit_BW1]+[01:00])
4 ([Startzeit_BW1]+[01:50])
timeCond:
0 0
1 1
2 2
3 3
4 4
timer:
0 0
1 0
2 0
3 0
4 0
timers:
0 0
1 1
2 2
3 3
4 4
trigger:
triggertime:
1588143300:
localtime 1588143300
hash:
1588144500:
localtime 1588144500
hash:
1588145100:
localtime 1588145100
hash:
1588146900:
localtime 1588146900
hash:
1588149900:
localtime 1588149900
hash:
uiState:
uiTable:
Attributes:
room AUSSEN,KG->Maschinenraum
Ich werde dann entscheiden ob ich das DOIF umbaue und im ersten Zeig auf sunrise statt fixer Uhrzeit umstellt, bzw auch noch die Aussentemperatur als weitere Bedingung hineinnehme.
Ich werde berichten.
lg,
Matthias
@amenomade
Hier nun das List nach einem erneuten sunrise. Ausgelöst hat das DOIF aber erwartungsgemäß nicht. Na wenigstens ist der Fehler
reproduzierbar ::)
Internals:
DEF ([{sunrise("CIVIL")}] and ($month >= 5 and $month <=8) and [?NIEDERSCHLAG:statWaterHour72] <= 0.008)
(set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 1 erfüllt. Nächster Start in 48 Sunden!' '' 0 '' )
(set garten_SWC_02 on-for-timer 600)
(set garten_SWC_03 on-for-timer 600)
DOELSEIF ([{sunrise("CIVIL")}] and ($month < 5 or $month > 8) and [?NIEDERSCHLAG:statWaterHour72] <= 0.004)
(set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 2 erfüllt. Nächster Start in 48 Sunden!' '' 0 '' )
(set garten_SWC_02 on-for-timer 600)
(set garten_SWC_03 on-for-timer 600)
DOELSEIF ([{sunrise("CIVIL")}] and [?NIEDERSCHLAG:statWaterHour24] <= 0.002 and ([?GARTEN:statTemperatureDayAvg] >= 22.0 or [?GARTEN:statTemperatureDayMax] >= 28))
(set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 3 erfüllt.' '' 0 '' )
(set garten_SWC_02 on-for-timer 600)
(set garten_SWC_03 on-for-timer 600)
DOELSEIF ([NIEDERSCHLAG:basicSet] == 99 and ([?garten_SWC_02:state] eq "on" or [?garten_SWC_03:state] eq "on"))
(set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Beendet wegen Regen!' '' 0 '' )
(set garten_SWC_02 off, set garten_SWC_03 off)
DOELSE
FUUID 5d388d65-f33f-d5e6-45eb-952d6ef7b2b122b4
MODEL FHEM
NAME controller_BEWAESSERUNG_GARTEN
NOTIFYDEV NIEDERSCHLAG,global
NR 493
NTFY_ORDER 50-controller_BEWAESSERUNG_GARTEN
STATE cmd_2
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-04-28 05:39:27 cmd 2.3
2020-04-28 05:39:27 cmd_event timer_2
2020-04-28 05:39:27 cmd_nr 2
2020-04-28 05:39:27 cmd_seqnr 3
2020-04-27 15:29:56 mode enabled
2020-04-28 05:39:27 state cmd_2
2020-04-29 05:32:32 timer_01_c01 30.04.2020 05:30:39
2020-04-29 05:32:32 timer_02_c02 30.04.2020 05:30:39
2020-04-29 05:32:32 timer_03_c03 30.04.2020 05:30:39
Regex:
accu:
cond:
NIEDERSCHLAG:
3:
basicSet ^NIEDERSCHLAG$:^basicSet:
attr:
cmdpause:
87000
87000
0
0
0
wait:
0:
0
0
300
1:
0
0
300
2:
0
0
300
3:
0
0
4:
0
0
5:
0
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday) and ($month >= 5 and $month <=8) and ::ReadingValDoIf($hash,'NIEDERSCHLAG','statWaterHour72') <= 0.008
1 ::DOIF_time_once($hash,1,$wday) and ($month < 5 or $month > 8) and ::ReadingValDoIf($hash,'NIEDERSCHLAG','statWaterHour72') <= 0.004
2 ::DOIF_time_once($hash,2,$wday) and ::ReadingValDoIf($hash,'NIEDERSCHLAG','statWaterHour24') <= 0.002 and (::ReadingValDoIf($hash,'GARTEN','statTemperatureDayAvg') >= 22.0 or ::ReadingValDoIf($hash,'GARTEN','statTemperatureDayMax') >= 28)
3 ::ReadingValDoIf($hash,'NIEDERSCHLAG','basicSet') == 99 and (::ReadingValDoIf($hash,'garten_SWC_02','state') eq "on" or ::ReadingValDoIf($hash,'garten_SWC_03','state') eq "on")
days:
do:
0:
0 set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 1 erfüllt. Nächster Start in 48 Sunden!' '' 0 ''
1 set garten_SWC_02 on-for-timer 600
2 set garten_SWC_03 on-for-timer 600
1:
0 set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 2 erfüllt. Nächster Start in 48 Sunden!' '' 0 ''
1 set garten_SWC_02 on-for-timer 600
2 set garten_SWC_03 on-for-timer 600
2:
0 set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Gestartet: Bedingung 3 erfüllt.' '' 0 ''
1 set garten_SWC_02 on-for-timer 600
2 set garten_SWC_03 on-for-timer 600
3:
0 set pushmsg msg 'BEWÄSSERUNG GARTEN' 'Beendet wegen Regen!' '' 0 ''
1 set garten_SWC_02 off, set garten_SWC_03 off
4:
0
helper:
DEVFILTER ^global$|^NIEDERSCHLAG$
NOTIFYDEV global|NIEDERSCHLAG
event timer_2
globalinit 1
last_timer 3
sleeptimer -1
timerdev
timerevent timer_2
triggerDev
timerevents:
timer_2
timereventsState:
timer_2
triggerEvents:
timer_2
triggerEventsState:
timer_2
interval:
intervalfunc:
localtime:
0 1588217439
1 1588217439
2 1588217439
perlblock:
readings:
all NIEDERSCHLAG:basicSet
realtime:
0 05:30:39
1 05:30:39
2 05:30:39
time:
0 {sunrise("CIVIL")}
1 {sunrise("CIVIL")}
2 {sunrise("CIVIL")}
timeCond:
0 0
1 1
2 2
timer:
0 0
1 0
2 0
timers:
0 0
1 1
2 2
triggertime:
1588217439:
localtime 1588217439
hash:
uiState:
uiTable:
Attributes:
alias BEWÄSSERUNG GARTEN
cmdpause 87000:87000:0:0:0
do always
group Gartensteuerung
room STEUERUNG
timerWithWait 1
wait 0,0,300:0,0,300:0,0,300:0,0:0,0:0
Ich hoffe du findest darin einen Hinweis, dem ich weiter nachgehen kann. Ich konnte beim ersten Durchschauen leider keine Auffälligkeiten feststellen.
Dem doif nach wurde cmd2 gestern ausgeführt.
Heute zum trigger zeitpunkt war die cmdpause noch nicht vorbei. Also keine Auslösung ist korrekt.
Gesendet von meinem S68Pro mit Tapatalk
@Frank
Gestern wurde gar keine Pause ausgelöst!
Wie ich gestern geschrieben habe, hatte ich das Attribut zum Testen auf "0:0:0:0:0" gesetzt -> DOIF triggert wie es soll!
Dann hatte ich das Attribut zum Vergleich auf die Werte "87000:87000:0:0:0" gesetz -> DOIF triggert NICHT!
Und auch im LOG ist kein Eintrag in diesem Zusammenhang zu finden. :(
Und was ist das? cmdpause 87000:87000:0:0:0
Steht doch in deinem list?!
Hallo,
bei mir tritt ein solches Problem ebenfalls auf, seit ich FHEM vor etwa zwei Wochen zum letzten Mal aktualisiert hatte. Ich bin inzwischen soweit, dass ich festgestellt habe, dass es Ausführungen des DOIF gibt, die zwar das dort enthaltene Kommando einwandfrei ausführen, dabei aber die Readings cmd und cmd_nr nicht aktualisieren. Damit werden dann weitere Ausführungen des Kommandos in Abhängigkeit von Attributen, die die Wiederholungszahl beeinflussen unterbunden und auch Abhängigkeiten von [?$SELF:cmd] funktionieren nicht mehr.
Grüße
Stefan
Hallo Otto,
Zitat von: Otto123 am 29 April 2020, 11:30:53
Und was ist das? cmdpause 87000:87000:0:0:0
Steht doch in deinem list?!
Ja - deshalb hat das DOIF ja heute morgen auch nicht ausgelöst ;)
Als ich gestern morgen noch (testhalber)
cmdpause 0:0:0:0:0 drin hatte aber schon.
...ich lasse das DOIF jetzt mal unverändert - keine weiteren Testst
Mal sehen was morgen früh passiert?
Ich wette wieder nichts :-|
Also war es doch dann heute kein Fehler? Da hab eich deinen Post falsch verstanden.
Hallo Otto,
kurzes Update von meiner Seite. Heute morgen lief das DOIF ganz normal. Ich lasse es noch bis morgen und wenn es wieder läuft, paßt eigentlich alles. Do Always ist dann aber wie es aussieht auch nicht notwendig.
lg,
Matthias
Hallo Otto,
Zitat von: Otto123 am 29 April 2020, 19:05:27
Also war es doch dann heute kein Fehler? Da hab eich deinen Post falsch verstanden.
... leider doch - es hat nur mein Fehlerbild bestätigt:
cmd 87000:87000:0:0:0 -> DOIF löst
NICHT aus und kein Eintrag im Log
cmd 0:0:0:0:0 -> DOIF löst aus mit korrektem Eintrag im Log
Frank hatte den
state: cmd_2 von gestern fäschlicherweise als korrekte Auslösung von heute morgen interpretiert
Mal sehen was morgen früh passiert ...?
Ich verstehe es nicht. Und Frank sicher auch nicht. Wenn es Gestern ausgelöst hat und du einen Tag cmdpause hast, dann ist es doch richtig, dass er Heute nicht ausgelöst hat. Er sollte erst morgen wieder auslösen?!
Ja, ich sehe da momentan keine Probleme nach den gegebenen Angaben.
Das cmdpause Attribut wird wohl on the fly übernommen, also sobald gesetzt geht nic mehr.
Bin auf das List von morgen früh gespannt.
Gesendet von meinem S68Pro mit Tapatalk
Zitat von: Otto123 am 29 April 2020, 21:44:56
Ich verstehe es nicht. Und Frank sicher auch nicht. Wenn es Gestern ausgelöst hat und du einen Tag cmdpause hast, dann ist es doch richtig, dass er Heute nicht ausgelöst hat. Er sollte erst morgen wieder auslösen?!
...zugegeben durch die verschiedenen Threads in einem Thema ging es etwas durcheinander:
Gestern hat das DOIF ausgelöst weil zum Zeitpunkt
sunrise das attribut cmdpause die Werte
0:0:0:0:0 hatte.
Wie weiter oben geschrieben habe ich das vorgestern testhalber so gesetzt! D.h. cmdpause konnte also gestern gar nicht greifen (und somit heute eine Pause auslösen) weil nicht gesetzt!
Im zweiten Schritt habe ich das attribut cmdpause dann gestern (nach sunrise) auf
87000:87000:0:0:0 gesetzt, um zu prüfen ob meine Fehlerbeobachtung reproduzierbar ist. Das hat sich ja auch bestätigt, denn heute Morgen zu sunrise hat das DOIF ja eben nicht ausgelöst.
Da sich der Zustand des DOIF von gestern auf heute nicht geändert hat, ist der Wert auf
cmd_2 stehen geblieben.
Selbst wenn
cmdpause 0:0:0:0:0 gestern eine Verzögerung ausgelöst haben sollte, müsste das DOIF spätestens morgen früh wieder getriggert werden da
timer_02_c02 30.04.2020 05:30:39Ich bin gespannt!
Ich halte Euch auf dem Laufenden - Danke für Eure Geduld!
ZitatGestern hat das DOIF ausgelöst weil zum Zeitpunkt sunrise das attribut cmdpause die Werte 0:0:0:0:0 hatte.
Wie weiter oben geschrieben habe ich das vorgestern testhalber so gesetzt! D.h. cmdpause konnte also gestern gar nicht greifen (und somit heute eine Pause auslösen) weil nicht gesetzt!
Im zweiten Schritt habe ich das attribut cmdpause dann gestern (nach sunrise) auf 87000:87000:0:0:0 gesetzt, um zu prüfen ob meine Fehlerbeobachtung reproduzierbar ist. Das hat sich ja auch bestätigt, denn heute Morgen zu sunrise hat das DOIF ja eben nicht ausgelöst.
Es funktioniert alles, wie programmiert.
Du kannst auch morgen paar Sekunden vor sunrise 87000:87000:0:0:0 setzen und es wird nicht funktionieren.
Das Modul schaut erst beim Trigger nach dem Datum des Status, errechnet dann die Zeitdifferenz und vergleicht sie mit cmdpause. Da die Tage z. Zt. unter 600 Sekunden länger werden (87000-86400=600), ist die Zeitdifferenz unter 87000 und dadurch wird das Modul nur jeden zweiten Tag auslösen.
Hallo zusammen,
ich wollte mich ja mit einem Status zurückmelden.
Um nicht noch mehr Verwirrung zu stiften habe ich das DOIF jetzt mal drei Tage "untouched" gelassen, so dass ein kompletter Zyklus duchlaufen konnte.
Und was soll ich sagen: MEA CULPA!!! Es funktioniert!
Anscheinend hatte ich vor meinem ersten Post ein generelles Problem mit meinem FHEM da verschiedene "Regeln", ob mit oder ohne DOIF, nicht sauber funktioniert haben. Und in meinem Debugging Wahn habe ich dann zu viele Dinge in zu kurzer Zeit ausprobiert - Geduld ist nicht unbedingt meine Stärke ::)
RETRO:
Der entscheidende Tipp kam m.E. von Frank und zwar der Hinweis auf die z.Z. schnell länger werdenden Tage!
Ich habe es nicht auf Anhieb kapiert aber nachdem ich die Verzögerung über cmdpause nun auf 87000 Sekunden (d.h. 24 Stunden und 10 Minuten) gesetzt habe, sollte es auch dauerhaft klappen, da in meinen Breitengraden das maximale tägliche Delta der Tageslänge etwa 5 Minuten beträgt.
Mein Tipp an alle: Bei der Fehlersuche im Zusammenhang mit sunrise triggern hilft nur Geduld! 8)
Sorry wenn ich da etwas Chaos verursacht habe. Vielen Dank an alle Mitdenker und Fehlersucher und vor allem vielen Dank für EURE Geduld! ;)
Hier mal zur Information:
Bei Angaben der Art [{meineZeitFunktion}] braucht man sich beim DOIF keine Gedanken zum doppelten Triggern am gleichen Tag machen. DOIF erkennt den Triggertag und verschiebt den nächsten Trigger auf den nächsten Tag, auch wenn die neu errechnete Zeit noch am gleichen Tag liegen sollte. Das gilt allerdings nur für DOIF und nicht für at, dort muss die Funktion selbst dafür Sorge tragen, die Zeit auf den nächsten Tag zu verschieben.