Ich habe folgendes DOIF welches mir einen Rolladen steuert:
define Rolladen.UG DOIF ([{sunrise_abs("HORIZON=-1.0",0,"07:00","09:00")}]) (set UG_ROL_Bastel on) DOELSEIF ([{sunset_abs("HORIZON=-1.0",0,"16:30","21:45")}]) (set UG_ROL_Bastel off)
attr Rolladen.UG cmdState auf|zu
attr Rolladen.UG disable 0
attr Rolladen.UG do always
attr Rolladen.UG stateFormat timer_02_c02
Am 22.2.2018 habe ich einen FHEM update durchgeführt, jetzt (gestern) habe ich festgestellt, dass der "off" Befehl innerhalb von 92 Sekunden zweimal ausgeführt wird. In der Log Datei steht folgendes:
2018.04.02 19:57:48 3: CUL_HM set UG_ROL_Bastel off
2018.04.02 19:59:20 3: CUL_HM set UG_ROL_Bastel off
An dem DOIF wurde nichts verändert, was läuft da falsch?
Hier noch ein List von Rolladen.UG:
Internals:
DEF ([{sunrise_abs("HORIZON=-1.0",0,"07:00","09:00")}]) (set UG_ROL_Bastel on) DOELSEIF ([{sunset_abs("HORIZON=-1.0",0,"16:30","21:45")}]) (set UG_ROL_Bastel off)
MODEL FHEM
NAME Rolladen.UG
NR 41
NTFY_ORDER 50-Rolladen.UG
STATE 03.04.2018 19:59:20
TYPE DOIF
READINGS:
2018-04-03 07:01:50 cmd 1
2018-04-03 07:01:50 cmd_event timer_1
2018-04-03 07:01:50 cmd_nr 1
2018-03-19 12:06:49 mode enabled
2018-04-03 07:01:50 state auf
2018-04-03 07:01:50 timer_01_c01 04.04.2018 07:00:00
2018-04-02 19:59:20 timer_02_c02 03.04.2018 19:59:20
Regex:
condition:
0 DOIF_time_once($hash,0,$wday)
1 DOIF_time_once($hash,1,$wday)
days:
devices:
do:
0:
0 set UG_ROL_Bastel on
1:
0 set UG_ROL_Bastel off
2:
helper:
DOIF_Readings_events
DOIF_eventas
event timer_1
globalinit 1
last_timer 2
sleeptimer -1
timerdev
timerevent timer_1
timereventsState
triggerDev
timerevents:
timer_1
triggerEvents:
timer_1
internals:
interval:
itimer:
localtime:
0 1522818000
1 1522778360
perlblock:
readings:
realtime:
0 07:00:00
1 19:59:20
time:
0 {sunrise_abs("HORIZON=-1.0",0,"07:00","09:00")}
1 {sunset_abs("HORIZON=-1.0",0,"16:30","21:45")}
timeCond:
0 0
1 1
timer:
0 0
1 0
timers:
0 0 0
1 1 1
triggertime:
1522778360:
localtime 1522778360
hash:
1522818000:
localtime 1522818000
hash:
uiState:
uiTable:
Attributes:
cmdState auf|zu
disable 0
do always
group Sonstiges
stateFormat timer_02_c02
Kein anderes Ding (notify, doif, at, usw...), das die Rollos auch steuert?
Zitat von: kurtix am 03 April 2018, 18:05:05
An dem DOIF wurde nichts verändert, was läuft da falsch?
Wie jedes Jahr nichts, die Tage werden länger, der nächste Sonnenuntergang liegt später als der erste Triggerzeitpunkt.
Das Problem kenne ich schon, seitdem ich DOIF mit dem Twilight-Modul nutze. Für die Rolladensteuerung werden am gleichen Tag immer drei Zeiten gebildet:
- die erste Konfiguration vom Vortag
- diese wird dann idR nochmals nach hinten (=später) korrigiert
- und nachdem das DOIF durch ist, wird der Rolladen nochmals getriggert (auch hier wird nochmals eine neue Zeit aus dem Twilight-Modul definiert)
Bisher habe ich mir nichts dabei gedacht. Ist schon kurios, aber grundsätzlich funktioniert es.
Ich überlege eine Funktion zu programmieren, die den nächsten Schaltzeitpunkt auf den nächsten Tag verschiebt, wenn er am gleichen Tag stattfinden sollte.
z. B. [{next_day(sunrise_abs("HORIZON=-1.0",0,"07:00","09:00"))}]
soweit ich weiß, macht sunrise() das im Gegensatz zu sunrise_abs() schon von alleine.
Hier noch etwas mehr Details. Log von gestern Abend:
2018.04.03 19:48:20 3: CUL_HM set KU_RoLi on
2018.04.03 19:57:01 3: CUL_HM set KU_RoLi on
2018.04.03 20:03:55 3: CUL_HM set KU_RoLi on
2018.04.03 20:05:06 3: CUL_HM set KU_RoLi on
2018.04.03 20:05:13 3: CUL_HM set KU_RoLi on
Und hier noch mein DEF des DOIFs:
([({twilight("TwilightHome","ss_weather","16:00","21:00")}+600+int(rand(600)))]
and [KU_FeLi:state] eq "closed")
(set KU_RoLi on)
(KU_FeLi ist das Fenster)
Möglicherweise hängt dies auch mit meinem +600+int(rand(600)) zusammen. ???
Zitat von: yersinia am 04 April 2018, 17:13:36
Hier noch etwas mehr Details. Log von gestern Abend:
2018.04.03 19:48:20 3: CUL_HM set KU_RoLi on
2018.04.03 19:57:01 3: CUL_HM set KU_RoLi on
2018.04.03 20:03:55 3: CUL_HM set KU_RoLi on
2018.04.03 20:05:06 3: CUL_HM set KU_RoLi on
2018.04.03 20:05:13 3: CUL_HM set KU_RoLi on
Und hier noch mein DEF des DOIFs:
([({twilight("TwilightHome","ss_weather","16:00","21:00")}+600+int(rand(600)))]
and [KU_FeLi:state] eq "closed")
(set KU_RoLi on)
(KU_FeLi ist das Fenster)
Möglicherweise hängt dies auch mit meinem +600+int(rand(600)) zusammen. ???
ja, siehe https://forum.fhem.de/index.php/topic,85831.msg790257.html#msg790257
Danke, ich stelle die Funktion mal auf sunrise/sunset um.
Ich habe eine abwärtskompatible DOIF-Version gebaut, die Timer-Wiederholungen am gleichen Tag verhindert.
Damit schalten Timerdefinitionen z. B. mit sunset..., sunrise..., twilight oder Berechnungen mit rand nur noch einmal am Tag.
z. B.
([({twilight("TwilightHome","ss_weather","16:00","21:00")}+600+int(rand(600)))]
Das gilt auch für Zeitintervalle.
Relative Zeitangaben mit vorangestelltem Plus-Zeichen funktionieren natürlich weiterhin wie gewohnt.
Bitte testen, damit es nach dem Einchecken keine bösen Überraschungen gibt.
Hi Damian,
oh super. Ich teste es mal. Hab jetzt deine DOIF-Version eingebunden und schauen wir mal. :)
Ich frage mich allerdings, ob man das noch optionalisieren sollte. Möglicherweise gibt es Gründe, ein DOIF Zweig mehrfach am Tag auszuführen (allerdings fällt mir derzeit kein Szenario ein).
Eventuell könnte man die Option für die Wochentage dafür missbrauchen - 8 wäre dann nur einmal täglich oder so (0 bis 6 wären die Wochentage).
[({twilight("TwilightHome","ss_weather","16:00","21:00")}+600+int(rand(600)))]|8
Zitat von: yersinia am 07 April 2018, 10:40:23
Hi Damian,
oh super. Ich teste es mal. Hab jetzt deine DOIF-Version eingebunden und schauen wir mal. :)
Ich frage mich allerdings, ob man das noch optionalisieren sollte. Möglicherweise gibt es Gründe, ein DOIF Zweig mehrfach am Tag auszuführen (allerdings fällt mir derzeit kein Szenario ein).
Eventuell könnte man die Option für die Wochentage dafür missbrauchen - 8 wäre dann nur einmal täglich oder so (0 bis 6 wären die Wochentage).
[({twilight("TwilightHome","ss_weather","16:00","21:00")}+600+int(rand(600)))]|8
Bei mir funktioniert alles wie bisher, eine optionale Angabe sollte überflüssig sein. Das mehrfache Schalten am Tage ist ein unerwünschter Nebeneffekt.
Die einzige Inkompabilität wäre gegeben, wenn jemand eine selbstprogrammierte Zeitfunktion nutzen würde, die periodisch mehrfach am Tag Zeiten berechnen würde. So etwas ist mir aber nicht bekannt, in diesem Fall sollte man relative Zeitangaben nutzen.
Das kann ich bestätigen. Die Rolladen funktionierten gestern abend und heute morgen wie gewünscht - und nur mit einem Log-eintrag pro Rolladen (daher gehe ich davon aus, dass die DOIFs auch gut funktionieren). Andere DOIFs scheinen auch zu funktionieren. Sieht gut aus. Danke. :)
Ach, edith hat noch folgende Fehlermeldung im Log gefunden (kam nach dem neustart mit der Aktualisierung):
2018.04.07 10:34:54 1: PERL WARNING: "my" variable $align masks earlier declaration in same scope at ./FHEM/98_DOIF.pm line 2650, <$fh> line 673.
Zitat von: yersinia am 08 April 2018, 09:22:47
Das kann ich bestätigen. Die Rolladen funktionierten gestern abend und heute morgen wie gewünscht - und nur mit einem Log-eintrag pro Rolladen (daher gehe ich davon aus, dass die DOIFs auch gut funktionieren). Andere DOIFs scheinen auch zu funktionieren. Sieht gut aus. Danke. :)
Ach, edith hat noch folgende Fehlermeldung im Log gefunden (kam nach dem neustart mit der Aktualisierung):
2018.04.07 10:34:54 1: PERL WARNING: "my" variable $align masks earlier declaration in same scope at ./FHEM/98_DOIF.pm line 2650, <$fh> line 673.
Danke für die Rückmeldung, die Warnung habe ich eliminiert.
Danke. ;D
Heute Morgen wurde der Rolladen nicht geöffnet, mit # $Id: 98_DOIF.pm v0.1 Damian $ und nach FHEM Restart..
set cmd_2 hat funktioniert. Events habe ich nicht aufgezeichnet.
Mit diesem DOIF:
(["^sleeping_di$:^cmd_1$"] or [23:15]) (set HM_56F3E3 off)
DOELSEIF ([{sunrise(0,"06:30","08:00")}] or ["^sleeping_di$:^(cmd_2|cmd_3)$"]) (set HM_56F3E3 on)
## RolloFlur_di
Es gibt weitere DOIF mit sunrise/sunset, die nicht funktioniert haben, die sind komplexer.
Hier das Listing
Internals:
DEF (["^sleeping_di$:^cmd_1$"] or [23:15]) (set HM_56F3E3 off)
DOELSEIF ([{sunrise(0,"06:30","08:00")}] or ["^sleeping_di$:^(cmd_2|cmd_3)$"]) (set HM_56F3E3 on)
## RolloFlur_di
MODEL FHEM
NAME RolloArb_di
NR 415
NTFY_ORDER 50-RolloArb_di
STATE cmd_2
TYPE DOIF
READINGS:
2018-04-08 23:28:18 Device sleeping_di
2018-04-09 07:28:40 cmd 2
2018-04-09 07:28:40 cmd_event set_cmd_2
2018-04-09 07:28:40 cmd_nr 2
2018-01-11 06:27:36 mode enabled
2018-04-09 07:28:40 state cmd_2
2018-04-08 23:15:00 timer_01_c01 09.04.2018 23:15:00
2018-04-08 06:30:00 timer_02_c02 10.04.2018 06:30:00
Regex:
cond:
:
0:
"^sleeping_di$:^cmd_1$" ^sleeping_di$:^cmd_1$
1:
"^sleeping_di$:^(cmd_2|cmd_3)$" ^sleeping_di$:^(cmd_2|cmd_3)$
condition:
0 EventDoIf('^sleeping_di$',$hash,'^cmd_1$',0) or DOIF_time_once($hash,0,$wday)
1 DOIF_time_once($hash,1,$wday) or EventDoIf('^sleeping_di$',$hash,'^(cmd_2|cmd_3)$',0)
days:
devices:
do:
0:
0 set HM_56F3E3 off
1:
0 set HM_56F3E3 on
2:
helper:
DOIF_Readings_events
DOIF_eventas
event cmd_1
globalinit 1
last_timer 2
sleeptimer -1
timerdev sleeping_di
timerevent cmd_1
triggerDev sleeping_di
timerevents:
cmd_nr: 1
cmd: 1
cmd_event: timer_1
cmd_1
timereventsState:
cmd_nr: 1
cmd: 1
cmd_event: timer_1
state: cmd_1
triggerEvents:
cmd_nr: 1
cmd: 1
cmd_event: timer_1
cmd_1
triggerEventsState:
cmd_nr: 1
cmd: 1
cmd_event: timer_1
state: cmd_1
internals:
interval:
itimer:
localtime:
0 1523308500
1 1523334600
perlblock:
readings:
realtime:
0 23:15:00
1 06:30:00
time:
0 23:15:00
1 {sunrise(0,"06:30","08:00")}
timeCond:
0 0
1 1
timer:
0 0
1 0
timers:
0 0
1 1
trigger:
triggertime:
1523308500:
localtime 1523308500
hash:
1523334600:
localtime 1523334600
hash:
uiState:
uiTable:
Attributes:
alias 00_Rolladen_Arbz
group Rolladen
icon helper_doif
room 1_Rolladen
Zitat von: Ellert am 09 April 2018, 07:38:15
Heute Morgen wurde der Rolladen nicht geöffnet, mit # $Id: 98_DOIF.pm v0.1 Damian $ und nach FHEM Restart..
set cmd_2 hat funktioniert. Events habe ich nicht aufgezeichnet.
Mit diesem DOIF:
(["^sleeping_di$:^cmd_1$"] or [23:15]) (set HM_56F3E3 off)
DOELSEIF ([{sunrise(0,"06:30","08:00")}] or ["^sleeping_di$:^(cmd_2|cmd_3)$"]) (set HM_56F3E3 on)
## RolloFlur_di
Es gibt weitere DOIF mit sunrise/sunset, die nicht funktioniert haben, die sind komplexer.
Hier das Listing
Internals:
DEF (["^sleeping_di$:^cmd_1$"] or [23:15]) (set HM_56F3E3 off)
DOELSEIF ([{sunrise(0,"06:30","08:00")}] or ["^sleeping_di$:^(cmd_2|cmd_3)$"]) (set HM_56F3E3 on)
## RolloFlur_di
MODEL FHEM
NAME RolloArb_di
NR 415
NTFY_ORDER 50-RolloArb_di
STATE cmd_2
TYPE DOIF
READINGS:
2018-04-08 23:28:18 Device sleeping_di
2018-04-09 07:28:40 cmd 2
2018-04-09 07:28:40 cmd_event set_cmd_2
2018-04-09 07:28:40 cmd_nr 2
2018-01-11 06:27:36 mode enabled
2018-04-09 07:28:40 state cmd_2
2018-04-08 23:15:00 timer_01_c01 09.04.2018 23:15:00
2018-04-08 06:30:00 timer_02_c02 10.04.2018 06:30:00
Regex:
cond:
:
0:
"^sleeping_di$:^cmd_1$" ^sleeping_di$:^cmd_1$
1:
"^sleeping_di$:^(cmd_2|cmd_3)$" ^sleeping_di$:^(cmd_2|cmd_3)$
condition:
0 EventDoIf('^sleeping_di$',$hash,'^cmd_1$',0) or DOIF_time_once($hash,0,$wday)
1 DOIF_time_once($hash,1,$wday) or EventDoIf('^sleeping_di$',$hash,'^(cmd_2|cmd_3)$',0)
days:
devices:
do:
0:
0 set HM_56F3E3 off
1:
0 set HM_56F3E3 on
2:
helper:
DOIF_Readings_events
DOIF_eventas
event cmd_1
globalinit 1
last_timer 2
sleeptimer -1
timerdev sleeping_di
timerevent cmd_1
triggerDev sleeping_di
timerevents:
cmd_nr: 1
cmd: 1
cmd_event: timer_1
cmd_1
timereventsState:
cmd_nr: 1
cmd: 1
cmd_event: timer_1
state: cmd_1
triggerEvents:
cmd_nr: 1
cmd: 1
cmd_event: timer_1
cmd_1
triggerEventsState:
cmd_nr: 1
cmd: 1
cmd_event: timer_1
state: cmd_1
internals:
interval:
itimer:
localtime:
0 1523308500
1 1523334600
perlblock:
readings:
realtime:
0 23:15:00
1 06:30:00
time:
0 23:15:00
1 {sunrise(0,"06:30","08:00")}
timeCond:
0 0
1 1
timer:
0 0
1 0
timers:
0 0
1 1
trigger:
triggertime:
1523308500:
localtime 1523308500
hash:
1523334600:
localtime 1523334600
hash:
uiState:
uiTable:
Attributes:
alias 00_Rolladen_Arbz
group Rolladen
icon helper_doif
room 1_Rolladen
ok, sollte jetzt mit Version v0.2 funktionieren
Mit v0.2 hat sunset/sunrise bisher wieder funktioniert, es kann aber sein, dass der ursprüngliche Fehler erst beim 2. Mal aufgetreten ist, ich werde es weiter beobachten.
Zitat von: Ellert am 10 April 2018, 12:53:13
Mit v0.2 hat sunset/sunrise bisher wieder funktioniert, es kann aber sein, dass der ursprüngliche Fehler erst beim 2. Mal aufgetreten ist, ich werde es weiter beobachten.
Das wird nicht passieren. Du kannst gerne noch testen, aber der Fehler war eindeutig zu finden, ich habe die falsche Variable abgefragt, damit wurden auch alle Zeiten um einen Tag geschoben, die über 24h haben, wie z. B. sunset und sunrise.
Dann wollen wir mal die Version langsam einchecken :)
Nicht soo schnell ;)
Das folgende DOIF schaltet nicht mehr stündlich 7 Minuten nach, sondern nur noch einmal am Tag um 1 Uhr 7.
([+[1]:07]) ({BenzinPreise})und das Listing
ZitatInternals:
DEF ([+[1]:07]) ({BenzinPreise})
## duBenzin
MODEL FHEM
NAME Benzin_di
NR 213
NTFY_ORDER 50-Benzin_di
STATE cmd_1
TYPE DOIF
READINGS:
2018-04-16 00:07:00 cmd 1
2018-04-16 00:07:00 cmd_event timer_1
2018-04-16 00:07:00 cmd_nr 1
2018-04-16 00:07:00 state cmd_1
2018-04-16 00:07:00 timer_01_c01 17.04.2018 01:07:00
Regex:
condition:
0 DOIF_time_once($hash,0,$wday)
days:
devices:
do:
0:
0 {BenzinPreise}
1:
helper:
DOIF_Readings_events
DOIF_eventas
event timer_1
globalinit 1
last_timer 1
sleeptimer -1
timerdev
timerevent timer_1
timereventsState
triggerDev
timerevents:
timer_1
triggerEvents:
timer_1
internals:
interval:
itimer:
localtime:
0 1523920020
perlblock:
readings:
realtime:
0 01:07:00
time:
0 +[1]:07
timeCond:
0 0
timer:
0 0
timers:
0 0
triggertime:
1523920020:
localtime 1523920020
hash:
uiState:
uiTable:
Attributes:
do always
group 5_Benzin
icon helper_doif
room 1_Alles
Zitat von: Ellert am 16 April 2018, 16:05:37
Nicht soo schnell ;)
Das folgende DOIF schaltet nicht mehr stündlich 7 Minuten nach, sondern nur noch einmal am Tag um 1 Uhr 7.
([+[1]:07]) ({BenzinPreise})
und das Listing
Fehler war auch diesmal eindeutig und damit leicht zu finden.
Version v.03
Ich habe noch bei fehlender DOIF-Definition, ## als Definition eingestellt.
damit entspricht
define test DOIF
define test DOIF ##
Damit gibt es jetzt bei fehlenden Definitionen den DEF-Button. ## ist zudem ein harmloser Kommentar, den ich intern nicht abfangen muss, weil er eine erlaubte Definition darstellt.
v.04
Zitat von: Damian am 16 April 2018, 18:09:13
Fehler war auch diesmal eindeutig und damit leicht zu finden.
Version v.03
Es funktioniert wieder, bisher sind mir keine weiteren Abweichungen aufgefallen.
Neue Version eingecheckt.