Hallo Damian,
mit Umstellung auf die Sommerzeit wurden zwei DOIF's nicht richtig ausgeführt.
Am Tag vor der Umstellung und am Tag danach funktionierten die DOIFs wie gewohnt seit Jahren, nicht aber am Tag der Zeitumstellung.
Ein DOIF sieht so aus:
Internals:
CFGFN ./FHEM/Aussenbeleuchtung.cfg
DEF ([{sunset_abs(-360)}]) (set Terrasse.Licht on-till {sunset_abs(2400,"22:27:35","23:02:19")})
DOELSEIF ([{sunrise_abs(1230)}-{sunset_abs(-600)}] and [Terrasse.Licht:state] eq "on")
(set Terrasse.Licht off)
DOELSEIF ([{sunset_abs(2700,"22:32:35","23:07:19")}-{sunrise_abs(1230)}] and [Terrasse.Licht:state] eq "on" and [?CamWatchAlarm:cmd_nr] == 3)
(set Terrasse.Licht off)
FUUID 5c430dc7-f33f-b139-a8fd-6deba875f6dfc6b1
MODEL FHEM
NAME Terrasse.Licht.Schaltzeit
NOTIFYDEV Terrasse.Licht,global
NR 727
NTFY_ORDER 50-Terrasse.Licht.Schaltzeit
STATE cmd_1
TYPE DOIF
VERSION 24095 2021-03-26 21:58:04
READINGS:
2021-03-30 22:27:41 Device Terrasse.Licht
2021-03-30 20:26:33 cmd 1
2021-03-30 20:26:33 cmd_event timer_1
2021-03-30 20:26:33 cmd_nr 1
2021-03-30 22:27:41 e_Terrasse.Licht_state off
2020-04-04 10:30:43 mode enabled
2021-03-30 20:26:33 state cmd_1
2021-03-30 20:26:33 timer_01_c01 31.03.2021 20:28:15
2021-03-30 20:22:33 timer_02_c02 31.03.2021 07:00:11
2021-03-30 20:22:33 timer_03_c02 31.03.2021 20:24:15
2021-03-31 07:00:11 timer_04_c03 31.03.2021 22:32:35
2021-03-31 07:00:11 timer_05_c03 01.04.2021 06:57:52
2021-03-28 19:23:13 wait_timer no timer
Regex:
accu:
cond:
Terrasse.Licht:
0:
1:
state ^Terrasse.Licht$:^state:
2:
state ^Terrasse.Licht$:^state:
attr:
cmdState:
wait:
0:
0
1:
5
2:
150
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday)
1 ::DOIF_time($hash,1,2,$wday,$hms) and ::ReadingValDoIf($hash,'Terrasse.Licht','state') eq "on"
2 ::DOIF_time($hash,3,4,$wday,$hms) and ::ReadingValDoIf($hash,'Terrasse.Licht','state') eq "on" and ::ReadingValDoIf($hash,'CamWatchAlarm','cmd_nr') == 3
days:
do:
0:
0 set Terrasse.Licht on-till {sunset_abs(2400,"22:27:35","23:02:19")}
1:
0 set Terrasse.Licht off
2:
0 set Terrasse.Licht off
3:
helper:
DEVFILTER ^global$|^Terrasse.Licht$
NOTIFYDEV global|Terrasse.Licht
event timer_5
globalinit 1
last_timer 5
sleepdevice Terrasse.Licht
sleepsubtimer -1
sleeptimer -1
timerdev
timerevent timer_1
triggerDev
bm:
DOIF_Get:
cnt 3
dmx -1000
dtot 0
dtotcnt 0
mTS 31.03. 12:34:15
max 6.103515625e-05
tot 0.000108957290649414
mAr:
HASH(0x557df0f60328)
Terrasse.Licht.Schaltzeit
?
DOIF_Notify:
cnt 212
dmx -1000
dtot 0
dtotcnt 0
mTS 28.03. 19:23:08
max 0.0188210010528564
tot 0.283185243606567
mAr:
HASH(0x557df0f60328)
HASH(0x557de865d840)
DOIF_Set:
cnt 23
dmx -1000
dtot 0
dtotcnt 0
mTS 28.03. 21:04:27
max 0.104116916656494
tot 0.106162548065186
mAr:
HASH(0x557df0f60328)
Terrasse.Licht.Schaltzeit
cmd_1
timerevents:
timer_1
timereventsState:
timer_1
triggerEvents:
timer_5
triggerEventsState:
timer_5
internals:
interval:
1 -1
2 1
3 -1
4 3
intervalfunc:
intervaltimer:
localtime:
0 1617215295
1 1617166811
2 1617215055
3 1617222755
4 1617253072
perlblock:
readings:
all Terrasse.Licht:state
realtime:
0 20:28:15
1 07:00:11
2 20:24:15
3 22:32:35
4 06:57:52
time:
0 {sunset_abs(-360)}
1 {sunrise_abs(1230)}
2 {sunset_abs(-600)}
3 {sunset_abs(2700,"22:32:35","23:07:19")}
4 {sunrise_abs(1230)}
timeCond:
0 0
1 1
2 1
3 2
4 2
timer:
0 0
1 0
2 0
3 0
4 0
timers:
0 0
1 1 2
2 3 4
trigger:
triggertime:
1617215055:
localtime 1617215055
hash:
1617215295:
localtime 1617215295
hash:
1617222755:
localtime 1617222755
hash:
1617253072:
localtime 1617253072
hash:
uiState:
uiTable:
Attributes:
devStateIcon .*:fts_shutter_1w_0
do always
icon FS20.off
room CUL_HM
wait 0:5:150
Der log-Auszug:
2021.03.28 19:23:08 3: CUL_HM set Terrasse.Licht on-till {sunset_abs(2400,"22:27:35","23:02:19")}
2021.03.28 19:23:13 3: CUL_HM set Terrasse.Licht off noArg
Es wurde wie erwartet eingeschaltet, aber gleich nach 5 Sekunden wieder ausgeschaltet, was eigentlich nur tagsüber greifen soll, falls jemand aus Versehen den mechanischen Schalter betätigt hat.
Ich vermute, dass es deshalb etwas mit den Timern bei der Umstellung auf die Sommerzeitzeit zu tun hat.
Viele Grüße
Gisbert
Es ist schwierig etwas dazu im Nachhinein zu sagen. Dabei müsste man wissen, was die Funktion sunset_abs geliefert hat.
Hallo Damian,
verstehe, dann ist nur die Auswirkung im DOIF aufgeschlagen, die an anderer Stelle verursacht wurde.
Es scheint wohl nicht so einfach mit der Zeitumstellung zu sein.
Viele Grüße Gisbert
bei mir war es auch so. Rollos abends eine Stunde zu früh am 28.3.
Ich vermute das in etwa hier: ob ich eine Zeit oder eine "zeit-liefernde" Funktion in die Bedingung schreibe spielt keine Rolle, bei Übernahme der Def werden die Timer erzeugt (z.B. timer_01_c01). Wird der errechnete Zeitpunkt erreicht, wird z.B. bei einer Zeitangabe [12:48] der Timer neu gesetzt, mit Datum vom nächsten Tag. Ich vermute bei Angabe einer Funktion wird bei erreichen der Zeit die Funktion erneut ausgeführt und der Timer gesetzt: für den nächsten Tag, Uhrzeit entsprechend etwas anders. Die Zeit, die da im Timer hinterlegt ist, kennt aber keine Sommer/Winterzeitumstellung, weshalb sie eine Stunde "falsch" ist. Am Tag der Zeitumstellung, wenn der "falsche" Zeitpunkt erreicht ist, wird die Funktion erneut gerechnet und am darauffolgenden Tag ist alles wieder in Ordnung.
Es fehlt etwas, was an den Tagen der Zeitumstellung morgens, wenn das gelaufen ist, die Timer auffrischt. Vielleicht liegt es aber auch mit am "abs" in der Funktion:
Zitatsunrise_abs() and sunset_abs() return the absolute time of the corresponding event today (no 24 hours added).
vs
Zitatsunrise() and sunset() return the absolute time of the next sunrise/sunset, adding 24 hours if the next event is tomorrow, to use it in the timespec of an at device or for the on-till command for FS20 devices.
Evtl. wäre die Angabe der Funktion ohne abs richtig, wenn diese dann die "24h" richtig addiert für das Ereignis am nächsten Tag (also unter Berücksichtigung der Zeitumstellung).
Na ja, bald ist Oktober, werde da mal genau zuschauen was passiert ;)
Zitat von: Sany am 01 April 2021, 13:04:24
bei mir war es auch so. Rollos abends eine Stunde zu früh am 28.3.
Ich vermute das in etwa hier: ob ich eine Zeit oder eine "zeit-liefernde" Funktion in die Bedingung schreibe spielt keine Rolle, bei Übernahme der Def werden die Timer erzeugt (z.B. timer_01_c01). Wird der errechnete Zeitpunkt erreicht, wird z.B. bei einer Zeitangabe [12:48] der Timer neu gesetzt, mit Datum vom nächsten Tag. Ich vermute bei Angabe einer Funktion wird bei erreichen der Zeit die Funktion erneut ausgeführt und der Timer gesetzt: für den nächsten Tag, Uhrzeit entsprechend etwas anders. Die Zeit, die da im Timer hinterlegt ist, kennt aber keine Sommer/Winterzeitumstellung, weshalb sie eine Stunde "falsch" ist. Am Tag der Zeitumstellung, wenn der "falsche" Zeitpunkt erreicht ist, wird die Funktion erneut gerechnet und am darauffolgenden Tag ist alles wieder in Ordnung.
Es fehlt etwas, was an den Tagen der Zeitumstellung morgens, wenn das gelaufen ist, die Timer auffrischt. Vielleicht liegt es aber auch mit am "abs" in der Funktion:vsEvtl. wäre die Angabe der Funktion ohne abs richtig, wenn diese dann die "24h" richtig addiert für das Ereignis am nächsten Tag (also unter Berücksichtigung der Zeitumstellung).
Na ja, bald ist Oktober, werde da mal genau zuschauen was passiert ;)
Also im DOIF ist die Zeitumstellung einprogrammiert. Es wird geschaut, ob der zu setzende Timer durch einen Sommer/Winterzeitwechsel durch muss. Dem Wechsel entsprechend wird eine Stunde drauf addiert oder abgezogen.
Gut zu wissen!
Ich hab das bei mir noch nicht genau nachgesehen, aber bei der Rollo-Mimik ist auch sunset_abs im Spiel.
Bin auf Oktober gespannt....