Hallo Marko,
ich kann mich erinnern, dass das bereits vor einem halben Jahr zur Umschaltung von Winter- auf Sommerzeit Thema war. Heute morgen hat ASC die Fahrbefehle 2 Mal ausgelöst. Zur Sommerzeit und zur Winterzeit. Da scheint etwas mit den Timestamps noch nicht rund zu laufen.
Gruß Reinhard
Nachtrag: In meinem Event-Log habe ich gesehen, dass die ersten Fahrten nicht nur Winterzeit bedingt eine Stunde zu früh ausgelöst wurden, sondern außerdem das Wochenende komplett ignoriert wurde.
Hallo Reinhard,
Die Zeitumstellung ist in der Tat immer noch ein aktuelles Thema dessen ich mich bei Gelegenheit gerne an nehme.
Grüße
Kann es sein, dass das Problem aus Astro kommt?
Dann (hoffentlich) => https://forum.fhem.de/index.php/topic,115255.msg1184074.html#msg1184074
Hallo,
Nein. Astro wird für die Zeitenberechnung nicht verwendet. Es wird sunrise_abs und sunset_abs aus 99_SUNRISE_EL verwendet.
Grüße
Marko
Wann berechnet ASC die täglichen Fahrtzeiten?
Im Ausgangs"modul" war das mal auf 03:05 (oder so) festgelegt. Dadurch passierte die Berechnung außerhalb der kritischen Zeit für Uhrenumstellung.
Zitat von: kjmEjfu am 02 November 2021, 11:35:45
Wann berechnet ASC die täglichen Fahrtzeiten?
Im Ausgangs"modul" war das mal auf 03:05 (oder so) festgelegt. Dadurch passierte die Berechnung außerhalb der kritischen Zeit für Uhrenumstellung.
Die Berechnung erfolgt lediglich kurz nach jeder Sunset und Sunrise Fahrt. Also immer Morgens und Abends
Zitat von: CoolTux am 02 November 2021, 11:42:40
Die Berechnung erfolgt lediglich kurz nach jeder Sunset und Sunrise Fahrt. Also immer Morgens und Abends
Bedeutet aber doch dann, wenn Abends (für die morgendliche Fahrt) berechnet wird, dann ist eine Uhrenumstellung nicht berücksichtigt. Außer natürlich sunrise_abs würde das schon machen.
Zitat von: kjmEjfu am 02 November 2021, 11:48:01
Bedeutet aber doch dann, wenn Abends (für die morgendliche Fahrt) berechnet wird, dann ist eine Uhrenumstellung nicht berücksichtigt. Außer natürlich sunrise_abs würde das schon machen.
korrekt. Und genau so ist es ja aktuell. Es wird nicht berücksichtigt. Das gilt es zu ändern.
Eventuell würde es reichen, statt sunrise_abs dann sunrise_abs_dat zu verwenden?
Muss ich mir anschauen
Moin :)
Wir haben Sommerzeit und weiterhin ein Thema. Die "Time_Up" Zeiten sind alle eine Stunde zu spät dran. Normalerweise sollte es 08:30 sein, heute morgen standen sie auf 09:30. Nach einem "renewAllTimer" war alles wieder ok. Nur zur Info, macht mich jetzt nicht nervös ;)
Gruß Reinhard
Hallo, weil ich gerade über den Thread gestolpert bin, hier ein quick&dirty hack:
define myDSThack at *03:05:00 set myASControl renewAllTimer
attr myDSThack disabledForIntervals 1@00-24
# CFGFN
# COMMAND set myASControl renewAllTimer
# DEF *03:05:00 set myASControl renewAllTimer
# FUUID 64693b4f-f33f-64c3-5718-e7594071431250ef
# NAME myDSThack
# NR 11421
# PERIODIC yes
# RELATIVE no
# REP -1
# STATE Next: 03:05:00
# TIMESPEC 03:05:00
# TRIGGERTIME 1684631100
# TRIGGERTIME_FMT 2023-05-21 03:05:00
# TYPE at
# eventCount 1
# READINGS:
# 2023-05-20 23:27:47 state Next: 03:05:00
#
setstate myDSThack Next: 03:05:00
setstate myDSThack 2023-05-20 23:27:47 state Next: 03:05:00
Wenn ich nicht gänzlich irre, wird damit Sonntags um 03:05 Uhr die Neuberechnung der Timer des ASC getriggert. Mit einem DOIF könnte man das sicherlich noch auf März/Oktober eingrenzen, aber selbst so sollte dieses kleine at "kein Brot fressen" und den restlichen Betrieb nicht weiter stören.