Gestern konnte ich es wieder mal beobachten:
Meine Rolläden mit Homematic schaltern bestückt und über VCCU+HMLAN in Fhem gesteuert, fuhren gestern alle zur gewohnten Zeit, also der Sommerzeit.
Am Morgen um eine Stunden zu früh hoch und am Abend um 1 Stunden zu früh runter.
Ich denke mir dass die Zeiten im FHEM Modul vorab berechnet werden und diese werden bei der Umstellung nicht neu berechnet.
Wenn ich mir meine Steuerdefinitionen jetzt ansehe, stehen dort bereits alles Zeiten für Morgen drinnen.
Dieser werden dann auch so ausgeführt. Das ist mein Eindruck davon.
Auch wenn man hört, dass sich die Umstellung aufhören wird, ich glaube erst daran, wenn es wahr wird. Derzeit wird nur viel herumgeredet.
Ist das Verhalten noch keinem von euch aufgefallen?
Oder habe ich einen Fehler in meiner Konfig?
Meinst Du das Homematic FHEM Modul mit Deiner Aussage zur Berechnung? Wusste gar nicht das das Homematic Modul Automatisiert Rolläden steuert.
Ist wohl ein problem der fhem timer. bitte das thema verschieben.
Genau das wollte ich wissen, denn dann hätte er Recht. Timer die am Samstag für Sonntag nach 3 Uhr berechnet werden sollten wurden in der Tat um eine Stunde zurück berechnet. Also statt 8 Uhr auf 7 Uhr, ist mir auch aufgefallen.
Habe das ganze jetzt nachverfolgt. Es hat nichts mit Homematic zu tun. Darum habe ich das Thema auch verschoben und umbenannt.
Meine Berechnungen der Zeit finden ja in einem DOIF Konstrukt statt.
Da ja die Zeit für den nächsten Tag immer gleich nach dem Ausführen berechnet werden, ändern sich diese ja nicht mehr bei der Zeitumstellung.
Jetzt stellt sich die Frage wie kann das Problem gelöst werden?
Ich habe in meiner Testinstallation auch tests gemacht. Die Zeiten werden nur neu berechnet, wenn ich zB. in der DOIF Definition etwas ändere, dann werden auch die Zeiten neu berechnet.
Einen anderen Weg habe ich noch nicht gefunden.
Zitat von: maci am 31 Oktober 2018, 08:25:52
Habe das ganze jetzt nachverfolgt. Es hat nichts mit Homematic zu tun. Darum habe ich das Thema auch verschoben und umbenannt.
Meine Berechnungen der Zeit finden ja in einem DOIF Konstrukt statt.
Da ja die Zeit für den nächsten Tag immer gleich nach dem Ausführen berechnet werden, ändern sich diese ja nicht mehr bei der Zeitumstellung.
Jetzt stellt sich die Frage wie kann das Problem gelöst werden?
Ich habe in meiner Testinstallation auch tests gemacht. Die Zeiten werden nur neu berechnet, wenn ich zB. in der DOIF Definition etwas ändere, dann werden auch die Zeiten neu berechnet.
Einen anderen Weg habe ich noch nicht gefunden.
Als erstes muß in Deinem speziellen Fall geklärt werden wie DOIF die Zeiten berechnet. Wie ich Damian kenne wird er da etwas eigenes für geschrieben haben. Ich selbst verwende die FHEM Funktion dafür.
Du solltest das Thema besser ins DOIF Forum verschieben.
Ich glaub nicht dass sunrise und sunset etwas mit DOIF zu tun haben. Das ist FHEM.
Das ganze wird nur einem DOIF verwendet.
Hier das List meiner Definition:
Internals:
DEF ([Rolladenautomatik_Wohnzimmer] eq "on" and [{sunrise("REAL",+2380,"07:55","09:45")}|7])
(set WohnzimmerTuereRechts auf-Tag, set RolladenWohnzimmer auf)
DOELSEIF ([Rolladenautomatik_Wohnzimmer] eq "on" and [{sunrise("REAL",+580,"06:35","08:45")}|8])
(set WohnzimmerTuereRechts auf-Tag, set RolladenWohnzimmer auf)
DOELSEIF ([Rolladenautomatik_Wohnzimmer] eq "on" and [{sunset("REAL",+800,"16:00","21:30")}])
(set WohnzimmerTuereRechts zu-Nacht, set RolladenWohnzimmer zu)
MODEL FHEM
NAME di_RolladenWohnzimmer
NR 179
NTFY_ORDER 50-di_RolladenWohnzimmer
STATE cmd_2
TYPE DOIF
READINGS:
2018-10-31 07:01:31 cmd 2
2018-10-31 07:01:31 cmd_event timer_2
2018-10-31 07:01:31 cmd_nr 2
2018-10-29 20:57:46 mode enabled
2018-10-31 07:01:31 state cmd_2
2018-10-31 07:55:00 timer_01_c01 01.11.2018 07:55:00|7
2018-10-31 07:01:31 timer_02_c02 01.11.2018 07:03:05|8
2018-10-30 16:56:46 timer_03_c03 31.10.2018 16:55:06
Regex:
attr:
cmdState:
wait:
0:
rand(600)
waitdel:
condition:
0 InternalDoIf($hash,'Rolladenautomatik_Wohnzimmer','STATE') eq "on" and DOIF_time_once($hash,0,$wday,"7")
1 InternalDoIf($hash,'Rolladenautomatik_Wohnzimmer','STATE') eq "on" and DOIF_time_once($hash,1,$wday,"8")
2 InternalDoIf($hash,'Rolladenautomatik_Wohnzimmer','STATE') eq "on" and DOIF_time_once($hash,2,$wday)
days:
0 7
1 8
devices:
0 Rolladenautomatik_Wohnzimmer
1 Rolladenautomatik_Wohnzimmer
2 Rolladenautomatik_Wohnzimmer
all Rolladenautomatik_Wohnzimmer
do:
0:
0 set WohnzimmerTuereRechts auf-Tag, set RolladenWohnzimmer auf
1:
0 set WohnzimmerTuereRechts auf-Tag, set RolladenWohnzimmer auf
2:
0 set WohnzimmerTuereRechts zu-Nacht, set RolladenWohnzimmer zu
3:
helper:
event timer_2
globalinit 1
last_timer 3
sleeptimer -1
timerdev
timerevent timer_2
timereventsState
triggerDev
DOIF_eventas:
cmd_nr: 2
cmd: 2
cmd_event: timer_2
state: cmd_2
timerevents:
timer_2
triggerEvents:
timer_2
internals:
0 Rolladenautomatik_Wohnzimmer:STATE
1 Rolladenautomatik_Wohnzimmer:STATE
2 Rolladenautomatik_Wohnzimmer:STATE
all Rolladenautomatik_Wohnzimmer:STATE
interval:
intervalfunc:
itimer:
localtime:
0 1541055300
1 1541052185
2 1541001306
perlblock:
readings:
realtime:
0 07:55:00
1 07:03:05
2 16:55:06
time:
0 {sunrise("REAL",+2380,"07:55","09:45")}
1 {sunrise("REAL",+580,"06:35","08:45")}
2 {sunset("REAL",+800,"16:00","21:30")}
timeCond:
0 0
1 1
2 2
timer:
0 0
1 0
2 0
timers:
0 0
1 1
2 2
triggertime:
1541001306:
localtime 1541001306
hash:
1541052185:
localtime 1541052185
hash:
1541055300:
localtime 1541055300
hash:
uiState:
uiTable:
Attributes:
DbLogExclude .*
do always
group Steuerung Rolladen
room 5.03_Rolladen_Schalter
wait rand(600)
Es geht dabei nicht um Sunrise oder Sunset sondern darum welche Funktion verwendet wird um Zeiten zu berechnen. Sunrise oder Sunset ist da nur ein Beispiel wo man das braucht.
Das Thema hatten wir schon vor Kurzem: https://forum.fhem.de/index.php/topic,92555.0.html
Zitat von: CoolTux am 31 Oktober 2018, 12:05:29
Es geht dabei nicht um Sunrise oder Sunset sondern darum welche Funktion verwendet wird um Zeiten zu berechnen. Sunrise oder Sunset ist da nur ein Beispiel wo man das braucht.
Da versteh ich jetzt nicht ganz.
Für mich ist Sunrise oder Sunset eine Funktion?
Jedenfalls ist es so, dass bei der Definition die ich oben beschreiben habe, jetzt die Zeiten für morgen drinnenstehen.
timer_01_c01 01.11.2018 07:55:00|7
timer_02_c02 01.11.2018 07:03:05|8
timer_03_c03 01.11.2018 16:53:27
Wenn heute Nacht aber eine Zeitumstellung, wie letzten Sonntag wäre, dann würde die Rolladen um 6:55 nach oben fahren und nicht um 7:55 Uhr
Dann wird ja neu berechnet für den neuen Tag. Dann passt es wieder.
Also keine Rede davon dass Sunrise oder DOIF usw. weiß, dass eine Zeitumstellung ist.
Zitat von: maci am 31 Oktober 2018, 19:23:50
Da versteh ich jetzt nicht ganz.
Für mich ist Sunrise oder Sunset eine Funktion?
Jedenfalls ist es so, dass bei der Definition die ich oben beschreiben habe, jetzt die Zeiten für morgen drinnenstehen.
timer_01_c01 01.11.2018 07:55:00|7
timer_02_c02 01.11.2018 07:03:05|8
timer_03_c03 01.11.2018 16:53:27
Wenn heute Nacht aber eine Zeitumstellung, wie letzten Sonntag wäre, dann würde die Rolladen um 6:55 nach oben fahren und nicht um 7:55 Uhr
Dann wird ja neu berechnet für den neuen Tag. Dann passt es wieder.
Also keine Rede davon dass Sunrise oder DOIF usw. weiß, dass eine Zeitumstellung ist.
DOIF weiß sehr wohl, wann eine Zeitumstellung ist und berücksichtigt das auch.
Wenn du am Tage vor der Zeitumstellung definierst: DOIF ([08:00])..., dann wird auch am Tage nach der Zeitumstellung genau um 08:00 Uhr geschaltet.
Das ist gut zu wissen.
Dann kann DOIF mal ausgeschlossen werden.
Bei meiner Definition werden die Zeiten aber nicht in DOIF direkt angegeben, sondern über Sunrise bzw Sunset berechnet.
Also muss hier angesetzt werden.
Habe dazu einen Beitrag von Ende März 2018 gefunden, also auch zur Zeitumstellung. https://forum.fhem.de/index.php?topic=51436.0 (https://forum.fhem.de/index.php?topic=51436.0)
Im letzten Beitrag ist da eine Möglichkeit beschrieben die Zeiten von Sunrise bzw. Sunset erst immer kurz davor zu berechnen.
Mir ist die Funktion klar, aber nicht wie das Konstrukt in DOIF einbaue.
Hier der Auszug aus dem letzten Beitrag:
Warum neu rechnen? Erst rechnen, wenn es gilt:
alter Code:
Code: [Auswählen]
define WZ_Rollladen_S_up_at at *{sunrise(0,'06:00','09:00')} set WZ_Rollladen_S up
neuer Code:
Code: [Auswählen]
define WZ_R_S_up_def at *04:00:00 {fhem ("define WZ_Rollladen_S_up_at at {sunrise(0,'06:00','09:00')} set WZ_Rollladen_S up")}
Man beachte, dass das Sternchen nach vorne gewandert ist.
Ich könnte auch meine vier at's in einem gesamten at/define machen, allerdings komme ich da mit der Klammerung bzw. den Semikola nicht so ganz klar 8)
Gruß PeMue
geht im Prinzip genauso:
DOIF ([04:00])(setreading $SELF sunrise {(sunrise(0,'06:00','09:00'))})
DOELSEIF ([[$SELF:sunrise]])(...)
sunrise_abs sollte direkt funktionieren, da nicht der Wert des nächsten Tages berechnet wird.
Zitat von: Ellert am 31 Oktober 2018, 23:03:44
sunrise_abs sollte direkt funktionieren, da nicht der Wert des nächsten Tages berechnet wird.
na ja, dadurch wird es nicht besser, wenn also sunrise_abs am Tage vor der Umstellung (noch Sommerzeit) z. B. 7:55 Uhr liefert und diese Zeit an DOIF weiter gibt, dann wird DOIF ja auch am Tage nach der Zeitumstellung um 7:55 Uhr schalten, aber eigentlich geht die Sonne nach der Winterzeit eine Stunde früher auf, also um 6:55 Uhr. Dagegen hilft die Maßnahme, wenn der "Spuk" vorbei ist, noch mal z. B. um 4:00 Uhr die Zeit neu berechnen lassen. Das Gleiche DOIF reagiert dann sofort darauf und setzt die Zeit neu (ich habe es vorhin sogar ausprobiert).
Ich bin davon ausgegangen, dass sunrise am Tag vor der Zeitumstellung den Sonnenaufgang für den nächsten Tag auf x - 1h legt, also 6:55 und DOIF behält das bei, während sunrise_abs den Sonnenaufgang x liefert für den Tag vor der Umstellung, also 7:54. Testen konnte ich das nicht und den Quellcode dazu habe ich mir auch nicht angesehen.
Zitat von: Damian am 31 Oktober 2018, 21:26:21
geht im Prinzip genauso:
DOIF ([04:00])(setreading $SELF sunrise {(sunrise(0,'06:00','09:00'))})
DOELSEIF ([[$SELF:sunrise]])(...)
Danke!
Habe das mal auf meinem Testserver umgesetzt. Beobachte das jetzt mal einige Zeit, bevor ich es in das Lifesystem einbaue.
sunrise_abs liefert jetzt bei mir 06:51:02, das ist offenbar der Sonnenaufgang von heute.
sunrise liefert jetzt 30:52:39
sunrise ist, weil der Zeitpunkt jetzt um 10:34 Uhr vorbei ist, der Sonnenaufgang von morgen plus 24h. Nach Berichten der User wird in der Zeitumstellungsnacht allerdings nicht plus/minus eine Stunde Differenz berücksichtigt. Das hätte aber passieren müssen, wenn DOIF am Vortag die korrekte Zeit für den nächsten Tag berechnen und setzen muss.
Zitat von: maci am 01 November 2018, 10:43:49
Danke!
Habe das mal auf meinem Testserver umgesetzt. Beobachte das jetzt mal einige Zeit, bevor ich es in das Lifesystem einbaue.
Lange genug beobachtet. Funktioniert einwandfrei.
Habe die Definition jetzt ins LifeSystem übertragen.
Somit markierte ich das als gelöst
Gruß
Georg