Probleme mit at nach Zeitumstellung

[Navigator]

Guten Morgen,

ich hatte heute morgen ein Problem, was ich so noch nie beobachtet habe und die Vermutung nahe liegt, daß dies mit der Zeitumstellung letzte Nacht zu tun hatte. Um 24 Uhr wurde noch ein AT korrekt ausgeführt. Um 1 Uhr wurde dieses AT noch einmal ausgeführt und verfing sich in einer Schleife. Es wurde bis heute früh ununterbrochen wiederholt, bis ich FHEM neu startete. Jetzt steht dieses in der Ausführung für morgen eine Stunde zu spät.

Code Auswählen Erweitern


STATE Next: 01:00:00
TIMESPEC 00:00:00.

Eine andere FHEM Instanz, die keine AT zwischen 0 und 3 Uhr ausführt hat die Umstellung allerdings ohne Probleme vollzogen.

[betateilchen]

Schau Dich bitte mal hier im Forum um, zu der Problematik gibt es schon einige Threads seit dieser Nacht.

[Navigator]

geht klar..danke

[flurin]

Schau Dich bitte mal hier im Forum um, zu der Problematik gibt es schon einige Threads seit dieser Nacht.

In meinem Fall scheint es eher ein "at-Problem" zu sein.

Bei der Zeitumstellung in Frühling gab es bereits ein ähnliches Problem, deshalb habe ich die Perl-Funktion entsprechend
ausgebaut, evtl. ist es für andere nützlich:

Code Auswählen Erweitern


define at_tc_addLog_am at *00:01 {my_addLog();}


Code Auswählen Erweitern


sub
my_addLog()
{
  my ($sec,$min,$hour) = localtime(time);
 
  if (($hour == 0 and $min == 1) or ($hour == 23 and $min == 59)) {
    ...
}


Gruss
flurin

[Navigator]

Seltsam ist immernoch, daß "Next" immer noch eine Stunde später als eingestellt stattfindet, auch wenn ich die Zeiten für das AT jetzt ändere.

[flurin]

Seltsam ist immernoch, daß "Next" immer noch eine Stunde später als eingestellt stattfindet, auch wenn ich die Zeiten für das AT jetzt ändere.

das ist bei mir auch so, jedoch zeigt TIMESPEC 00:01

Code Auswählen Erweitern


STATE Next: 01:01:00
TIMESPEC 00:01


edit: übrigens um 00:01 wurde der "at" richtig ausgeführt, bedingt durch die Zeitumstellung wurde um 01:00 die Endlosschleife ausgelöst. Der Fehler wird irgendwann behoben aber "defensive programming" schadet nie 

[rudolfkoenig]

Das Problem mit 01:01 habe ich gefixt, und die Endlosschleife vermutlich auch.
Hoffentlich ohne Nebeneffekte.

Ich habe die Aenderungen ausnahmsweise fuer update zur Verfuegung gestellt.

[Navigator]

Kann man interessehalber ein paar Infos über die Ursache erfahren? Die Umstellung wurde doch von 3 auf 2 Uhr vollzogen. Meine AT lagen ja vor dieser "kritischen" Phase.

[flurin]

@rudolfkoenig
Vielen Dank für den "Sonntagssupport".
Update ausgeführt, List:

Code Auswählen Erweitern


   ...
   STATE      Next: 00:01:00
   TIMESPEC   00:01
   TRIGGERTIME 1445814060
   TRIGGERTIME_FMT 2015-10-26 00:01:00
   TYPE       at
   Readings:
     2015-10-25 13:27:47   state           Next: 00:01:00


[Jojo11]

Hallo,

bei mir scheint seit der Zeitumstellung auch irgendetwas anders zu laufen als vorher. Die Last meines cubietrucks fährt jetzt regelmäßig nachts zwischen 00:00 Uhr und 01:00 Uhr extrem nach oben (s. Anhang).
Apptime zeigt auf den ersten Blick nichts Besonderes. Am ehesten evtl. noch "tmr-FileLog_dailySwitch", dessen Bedeutung ich nicht kenne. Ich bin leider ratlos und weiß nicht, wo ich sochen soll. FHEM habe ich gestern aktualisiert. Woran könnte das noch liegen?

schöne Grüße
Jo

[rudolfkoenig]

Die erwaehnte Funktion hat in der Tat ein "busy loop" (wie heisst sowas auf Deutsch?) gedreht zwischen 0:00 und 1:00. Habs gefixt und eingecheckt, und fuer update zur Verfuegung gestellt.

[Jojo11]

Super, herzlichen Dank!

schöne Grüße
Jo

[snickers2k]

weiterhin Probleme..
OpenHab2 wird Zeit

[Otto123]

"busy loop" (wie heisst sowas auf Deutsch?)

Eigentlich Warteschleife? 

[rudolfkoenig]

weiterhin Probleme..

Wenn du sie nicht genau schilderst, dann kann ich es auch nicht beheben.

OpenHab2 wird Zeit (https://forum.fhem.de/Smileys/default/sad.gif)

Erpressung ist fehl am Platz, ich habe nichts dagegen, weniger Anwender zu betreuen.
Berichte uns bitte ueber deine Erfahrungen mit openhab2, ich lerne gerne dazu.