[gelöst] Zeitumstellung und Zeitberechnung

maci · 29 Oktober 2018, 20:14:28

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?

CoolTux · 29 Oktober 2018, 20:18:03

Meinst Du das Homematic FHEM Modul mit Deiner Aussage zur Berechnung? Wusste gar nicht das das Homematic Modul Automatisiert Rolläden steuert.

martinp876 · 29 Oktober 2018, 20:42:46

Ist wohl ein problem der fhem timer. bitte das thema verschieben.

CoolTux · 30 Oktober 2018, 04:51:05

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.

maci · 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.

CoolTux · 31 Oktober 2018, 08:45:13

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.

maci · 31 Oktober 2018, 11:57:16

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:

Code Auswählen



 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)

CoolTux · 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.

Damian · 31 Oktober 2018, 13:37:32

Das Thema hatten wir schon vor Kurzem: https://forum.fhem.de/index.php/topic,92555.0.html

maci · 31 Oktober 2018, 19:23:50

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.

Damian · 31 Oktober 2018, 19:57:11

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.

maci · 31 Oktober 2018, 20:48:05

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
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:

Code Auswählen

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

Damian · 31 Oktober 2018, 21:26:21

geht im Prinzip genauso:

Code Auswählen

DOIF ([04:00])(setreading $SELF sunrise {(sunrise(0,'06:00','09:00'))})
DOELSEIF ([[$SELF:sunrise]])(...)

Ellert · 31 Oktober 2018, 23:03:44

sunrise_abs sollte direkt funktionieren, da nicht der Wert des nächsten Tages berechnet wird.

Damian · 31 Oktober 2018, 23:19:44

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).