Ich habe folgendes Problem festgestellt.
Bei mir erfolgt die regelmäßige Schaltung diverser Timer.
In der Nacht der Sommerzeitumstellung wurden alle Timer, die nach der Umstellung stattfinden sollten um eine Stunde zu spät ausgelöst. Davor und danach habe ich bisher keinerlei Probleme gehabt.
Hier die Timer und die Protokoleinträge:
define PumpeTimer at *05:40:00 {DeviceOnForTimer("Pumpe", 5120 )}
2013.03.31 06:40:00 2: DeviceOnForTimer Pumpe 90 % 999 -> 90(Aus)
#
define HeizungKuecheSync at *04:30:00 { fhem("set HeizungKueche time date") if($wday == 0) }
define HeizungWohnenSync at *04:35:00 { fhem("set HeizungWohnen time date") if($wday == 0) }
2013.03.31 05:35:00 2: FHT set HeizungWohnen hour 5 minute 35 year 13 month 3 day 31
2013.03.31 05:30:00 2: FHT set HeizungKueche hour 5 minute 30 year 13 month 3 day 31
define HifianlageAus at *03:00:00 set Hifianlage,Bassreflex,Wohnzimmer off
2013.03.31 04:00:00 2: FS20 set Wohnzimmer off
2013.03.31 04:00:00 2: FS20 set Bassreflex off
2013.03.31 04:00:00 2: FS20 set Hifianlage off
Habe nur ich das Problem?
Könnt Ihr Eure Protokolle prüfen?
ich glaube, dass es hiermit zu tun hat:
ZitatIch bin der Meinung, dass das at-Komando ein Problem hat. Es tritt dann auf, wenn zwischen dem Zeitpunkt der Erstellung des InternalTimers und der Schaltzeit ein Sommerzeitwechsel stattfindet.
Meine Timer sind heute morgen sämtlich zu spät gefeuert worden.
Aufgefallen ist das Problem bei Heating_Control.
Ich habe einen Weg gefunden Heating_Control gegen Sommerzeitumstellungen immun zum machen. Sollte beim at auch funktionieren. War gar nicht so schwer!
Könnt Ihr meine Vermutung prüfen/bestätigen.
Prüft bitte auch mal kritsch, ob der folgende Code das Problem auch für at-Komandos lösen kann - bei HC scheint es zu funktionieren:
next ist der nächste Schaltzeitpunkt(in epoch) der als InternalTimer gesetzt werden soll.
Falls ihr das bestätigen könnt, schlage ich folgenden Code als Korrektur in at vor.
In Heating_contorl werde ich den Code jedenfalls einbauen:
$next += get_SummerTimeOffset($now, $next);
...
sub get_SummerTimeOffset($$) {
my ($now, $next) = @_;
my $offset;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst_now,$isdst_next);
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst_now) = localtime($now);
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst_next) = localtime($next);
return 3600 *($isdst_now - $isdst_next);
}
habe wirklich nur ich das Problem gehabt?
ZitatZitat von: rudolfkoenig schrieb am Mo, 01 April 2013 12:15Hallo Dietmar,
eigentlich wird das in SecondsTillTomorrow() in einem optimierten Form implementiert, evtl. ist da ein Bug drin. Kannst Du diese Diskussion bitte oeffentlich fuehren, damit auch andere mithelfen koennen?
Ich entferne auch meine Privatnachrichten Option, damit sowas nicht wieder passiert.
Gruss,
Rudi
in SecondsTillTomorrow ist kein Fehler drin. Aber Wenn zwischen der aktuellen Zeit und der ermittelten Zeit ein Sommerzeitwechselt ist, bin ich der Meinung, dass man jeweils um 3600 Sekunden(ein:-3600 aus:+3600) korrigieren muss.
Falls nichts mehr kommt werde ich die Sache im Herbst beobachten.
Wie erwaehnt hat das at-Modul eigentlich Vorkehrungen dagegen getroffen. Wenn es trotzdem noch schief geht, dann sollten wir das fixen, aber dazu brauche ich mehr info. Meine At-Instanzen haben am 31.3 alle rechtzeitig reagiert, deswegen bin ich sicher das SecondsTillTomorrow() nicht grob falsch ist, sondern hoechstens in Sonderfaellen Mist baut.
Kann es sein, dass Ihr euren Rechner/fhem kurz nach Mitternacht neu startet?
Hallo,
bei mir war es auch so, dass alle Timer eine Stunde später dran waren. Danach stimmte dann wieder alles.
Besonders interessant fand ich die Log-Einträge zu meiner Neustart-Funktion
define NeuStart at *01:00 shutdown restart
2013.03.30 01:00:00 0: Server shutdown
...
2013.03.31 00:00:00 0: Server shutdown
2013.03.31 00:00:03 1: Including fhem.cfg
2013.03.31 00:00:04 3: telnetPort: port 7072 opened
2013.03.31 00:00:05 3: WEB: port 8083 opened
2013.03.31 00:00:05 3: WEBphone: port 8084 opened
2013.03.31 00:00:05 3: WEBtablet: port 8085 opened
...
2013.03.31 01:00:00 0: Server shutdown
2013.03.31 01:00:03 1: Including fhem.cfg
2013.03.31 01:00:04 3: telnetPort: port 7072 opened
2013.03.31 01:00:04 3: WEB: port 8083 opened
2013.03.31 01:00:04 3: WEBphone: port 8084 opened
2013.03.31 01:00:04 3: WEBtablet: port 8085 opened
...
2013.04.01 02:00:00 0: Server shutdown
2013.04.01 02:00:03 1: Including fhem.cfg
2013.04.01 02:00:04 3: telnetPort: port 7072 opened
2013.04.01 02:00:05 3: WEB: port 8083 opened
2013.04.01 02:00:05 3: WEBphone: port 8084 opened
2013.04.01 02:00:05 3: WEBtablet: port 8085 opened
...
2013.04.02 01:00:00 0: Server shutdown
FHEM läuft bei mir auf einer FB 7390 (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2866 2013-03-07 15:10:37Z rudolfkoenig $, pid 20761).
Grüße,
Ulf
> define NeuStart at *01:00 shutdown restart
Fuer diesen Fall ist das Problem mir auch klar, und ich habe es z.Zt. nicht vor zu fixen. Als Workaround empfehle ich den restart auf 3:30 zu legen, oder noch besser es ganz zu lassen.
Ich verstehe nicht warum das passiert. Kannst du mir das erklären?
Die Zeitumstellung wird z.Zt. nur dann beruecksichtigt, falls das Ereignis auf dem naechsten Tag faellt.
ich hatte auch eine Eindlosschleife:
2013.03.30 23:58:48 2: dummy set SonnenAufgang 06:59:24
2013.03.30 23:58:48 2: dummy set SonnenUntergang 19:49:48
2013.03.30 23:58:48 2: dummy set Heute 30.03.2013(089)
2013.03.30 23:58:48 2: strip NAS.log HeizungKueche.log HeizungWohnen.log Performance.log fhem.log Pumpe.log uptime.log
2013.03.30 23:58:48 2: CUL TRANSMIT LIMIT EXCEEDED
2013.03.30 23:58:49 2: CUL_0: unknown message LOVF
2013.03.30 23:58:49 2: FS20 set StehlampeTisch off
2013.03.30 23:58:49 2: dummy set SonnenAufgang 06:59:24
2013.03.30 23:58:49 2: dummy set SonnenUntergang 19:49:48
2013.03.30 23:58:49 2: dummy set Heute 30.03.2013(089)
2013.03.30 23:58:50 2: strip NAS.log HeizungKueche.log HeizungWohnen.log Performance.log fhem.log Pumpe.log uptime.log
2013.03.30 23:58:50 2: FS20 set StehlampeTisch off
2013.03.30 23:58:50 2: dummy set SonnenAufgang 06:59:24
2013.03.30 23:58:50 2: dummy set SonnenUntergang 19:49:48
2013.03.30 23:58:50 2: dummy set Heute 30.03.2013(089)
2013.03.30 23:58:51 2: strip NAS.log HeizungKueche.log HeizungWohnen.log Performance.log fhem.log Pumpe.log uptime.log
2013.03.30 23:58:51 2: CUL TRANSMIT LIMIT EXCEEDED
2013.03.30 23:58:51 2: CUL_0: unknown message LOVF
2013.03.30 23:58:51 2: FS20 set StehlampeTisch off
2013.03.30 23:58:51 2: dummy set SonnenAufgang 06:59:24
2013.03.30 23:58:51 2: dummy set SonnenUntergang 19:49:48
2013.03.30 23:58:51 2: dummy set Heute 30.03.2013(089)
2013.03.30 23:58:52 2: strip NAS.log HeizungKueche.log HeizungWohnen.log Performance.log fhem.log Pumpe.log uptime.log
2013.03.30 23:58:52 2: FS20 set StehlampeTisch off
2013.03.30 23:58:52 2: dummy set SonnenAufgang 06:59:24
2013.03.30 23:58:52 2: dummy set SonnenUntergang 19:49:48
2013.03.30 23:58:53 2: dummy set Heute 30.03.2013(089)
2013.03.30 23:58:53 2: strip NAS.log HeizungKueche.log HeizungWohnen.log Performance.log fhem.log Pumpe.log uptime.log
2013.03.30 23:58:53 2: CUL TRANSMIT LIMIT EXCEEDED
2013.03.30 23:58:53 2: CUL_0: unknown message LOVF
2013.03.30 23:58:53 2: FS20 set StehlampeTisch off
2013.03.30 23:58:54 2: dummy set SonnenAufgang 06:59:24
2013.03.30 23:58:54 2: dummy set SonnenUntergang 19:49:48
2013.03.30 23:58:54 2: dummy set Heute 30.03.2013(089)
2013.03.30 23:58:54 2: strip NAS.log HeizungKueche.log HeizungWohnen.log Performance.log fhem.log Pumpe.log uptime.log
2013.03.30 23:58:55 2: FS20 set StehlampeTisch off
2013.03.30 23:58:55 2: dummy set SonnenAufgang 06:59:24
2013.03.30 23:58:55 2: dummy set SonnenUntergang 19:49:48
2013.03.30 23:58:55 2: dummy set Heute 30.03.2013(089)
2013.03.30 23:58:56 2: strip NAS.log HeizungKueche.log HeizungWohnen.log Performance.log fhem.log Pumpe.log uptime.log