Ich habe schon heute morgen im Forum gelesen, das es ettliche gibt, die um diesen Zeitraum herum endlose Schaltvorgänge im LOG registrieren konnten. Da dort wo die Beiträge heute stehen, ist ein Hinweis zu finden, diese Beiträge doch in "Automatisierung" zu stellen:
Ich schalte immer nachts um 0:00 Uhr einfach zwei FS20 Schalter aus (heißen nur Laptop+Weihnachtsbaum), für den Fall das sie vergessen wurden. Ist nix tolles, hat aber bei der Zeitumstellung, tolles ausgelöst.
define Weihnachtsbaum_Aus at *00:00:00 define WB_Aus at +*{3}00:00:02 set Weihnachtsbaum off
define Laptop_Aus at *00:00:00 define LT_Aus at +*{3}00:00:02 set Laptop off
und das steht dann ab 23.00 Uhr 100-derte mal im Log
2015.03.28 23:01:05 3: Weihnachtsbaum_Aus: WB_Aus already defined, delete it first
2015.03.28 23:01:05 3: Laptop_Aus: LT_Aus already defined, delete it first
2015.03.28 23:01:05 3: Laptop_Aus: LT_Aus already defined, delete it first
2015.03.28 23:01:05 3: Weihnachtsbaum_Aus: WB_Aus already defined, delete it first
2015.03.28 23:01:05 3: Laptop_Aus: LT_Aus already defined, delete it first
2015.03.28 23:01:05 3: Weihnachtsbaum_Aus: WB_Aus already defined, delete it first
2015.03.28 23:01:05 3: Weihnachtsbaum_Aus: WB_Aus already defined, delete it first
2015.03.28 23:01:05 3: Laptop_Aus: LT_Aus already defined, delete it first
2015.03.28 23:01:05 3: Weihnachtsbaum_Aus: WB_Aus already defined, delete it first
2015.03.28 23:01:05 3: Laptop_Aus: LT_Aus already defined, delete it first
2015.03.28 23:01:05 3: FS20 set Weihnachtsbaum off
2015.03.28 23:01:05 2: CUL: unknown message LOVF
bis LOVF kommt, und nach einiger Zeit das gleiche wieder los geht.
Ist das ein Bug oder muß man die Zeiten verändern?
Gruß
aus Köln
nobbi
Äh, was hat das mit der Zeitumstellung zu tun. Die ist um 02:00 und nicht um 00:00.
Grüße Jörg
Deswegen fragen wir ja hier. Ich hatte den gleichen Spuk. Um 23:20 stand ich im Dunkeln (sollte erst 00:20 auslösen) und ununterbrochen funkte der CUL set Lampe off. Um 0:00 Uhr war von allein wieder Ruhe, zum Glück, da hat mein BananaPi schon gekocht. Dafür gingen meine Rollos heute eine Stunde zu spät auf, das Bad war kalt und eine Vielzahl von Timern ist wie von Geisterhand verstellt.
Das wird ja wohl die Zeitumstellung gewesen sein. Nicht meine erste mit FHEM und nein, auch nicht die Zweite. Ich habe den Kanal jetzt voll und spiele meine FHEM-Version vom November 2014 auf. Die lief noch richtig stabil, danke Jungs, da habt ihr was wirklich Gutes hinbekommen.
Die ganzen Verschlimmbesserungen danach sind aber nur noch eine Katastrophe. Lasst doch einfach laufen, was gut läuft.
Bist Du sicher, dass Fhem das Problem ist und nicht vielleicht Dein Zeitserver. Ich habe keinerlei Probleme gehabt. Benutze allerdings auch die Zeitserver der PTB von Braunschweig.
Grüße Jörg
Nein, bin ich nicht, danke für den tip.
Ich habe den ntp-Server, der standardmäßig im Raspi eingetragen ist, nicht verändert. Wo steht das denn?
Welchen haben die anderen mit dem Problem denn eingetragen?
Du kannst die Einträge in /etc/ntp.conf ändern. Nach der Änderung den Dienst ntpd neu starten oder den RPi neu booten.
Grüße Jörg
Bei mir steht da:
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
Zitatserver 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
...habe ich bei mir auskommentiert und dafür diese eingetragen vom Physikalisch-Technische Bundesanstalt (PTB), Braunschweig eingetragen..
server ptbtime1.ptb.de
server ptbtime2.ptb.de
Ich werde das mal probieren und ein Jahr warten. Hoffentlich bin ich da nicht verreist. :D :D :D
Muss man da das "iburst" dazuschreiben?
Ich bin mir nicht sicher, woran es wirklich liegt, aber die Zeitumstellung kann schon damit zu tun haben.
Vor zwei Jahren hatte auch ich einen solchen Effekt: Endlosschleife. Ich hatte damals auch das at im Verdacht und auch eine Vermutung wie es passieren kann.
Wenn der Timer für den nächsten Tag neu gesetzt wird, wird ggf dst-Korrektur durchgeführt und dabei kann als nächsten Ausführungszeitpunkt ein Wert der Vergangenheit gesetzt werden. Das geht dann für längere Zeit so weiter.
Ich vermeide at zwischen Mitternacht und 4:00 Uhr.
Die alte Version verhält sich nicht anders.
Hallo,
hier eine Erklärung von heise.de
ZitatEin hinter die Serveradresse gestelltes iburst beschleunigt die anfängliche Synchronisation, da ntpd so gekennzeichnete Server anfangs mit mehr NTP-Paketen abfragt als üblich und so schneller die zur Bewertung erforderlichen Daten sammelt. Die Option prefer auf einer Serverzeile veranlasst ntpd, diesen Server zu bevorzugen, wenn mehrere Server als gleich gute Quellen zur Synchronisation bewertet werden.
Grüße Jörg
Danke. Ich glaube, das ist beim BananaPi wichtig. Ich habe hier mal gelesen, dass der mitunter schneller hochgefahren ist als die Zeitinformation da ist. Dieses Problem hatte ich bislang nicht. Ich werde mal auf de.pool.ntp.org umsteigen.
Ich habe mich inzwischen belesen, was ntp.pool ist. Das könnte natürlich eine Ursache sein, allerdings beschreibt Dietmar genau das, was hier passiert ist. Und dann wäre es doch wieder eine FHEM-Geschichte. Auf die AT-Befehle nach 00:00 Uhr kann ich nicht verzichten, ohne meinen Tagesablauf umzustellen. :D Ich muss nachdenken, wie man das anders lösen kann.
Siehe http://forum.fhem.de/index.php/topic,35586.msg279381.html#msg279381
Ich berechne die nächste Schaltzeit immer so.
Sommerzeitumstellungen werden automatisch berücksichtigt:
use Time::Local 'timelocal_nocheck';
sub WeekdayTimer_zeitErmitteln ($$$$$) {
my ($now, $hour, $min, $sec, $days) = @_;
my @jetzt_arr = localtime($now);
#Stunden Minuten Sekunden
$jetzt_arr[2] = $hour; $jetzt_arr[1] = $min; $jetzt_arr[0] = $sec;
$jetzt_arr[3] += $days;
my $next = timelocal_nocheck(@jetzt_arr);
return $next;
}