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.
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.
Schau Dich bitte mal hier im Forum um, zu der Problematik gibt es schon einige Threads seit dieser Nacht.
geht klar..danke
Zitat von: betateilchen am 25 Oktober 2015, 10:51:34
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:
define at_tc_addLog_am at *00:01 {my_addLog();}
sub
my_addLog()
{
my ($sec,$min,$hour) = localtime(time);
if (($hour == 0 and $min == 1) or ($hour == 23 and $min == 59)) {
...
}
Gruss
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.
Zitat von: Dittel am 25 Oktober 2015, 11:36:27
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
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 ;)
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.
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.
@rudolfkoenig
Vielen Dank für den "Sonntagssupport".
Update ausgeführt, List:
...
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
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
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.
Super, herzlichen Dank!
schöne Grüße
Jo
weiterhin Probleme..
OpenHab2 wird Zeit :(
Zitat von: rudolfkoenig am 28 Oktober 2015, 09:48:44
"busy loop" (wie heisst sowas auf Deutsch?)
Eigentlich Warteschleife? 8)
Zitatweiterhin Probleme..
Wenn du sie nicht genau schilderst, dann kann ich es auch nicht beheben.
ZitatOpenHab2 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.
Ich habe openhab ausprobiert und auch den Code mal gereviewed...
Fazit: FINGER WEG! Absolut overengineered, buggy, langsam und unflexibel. FHEM ist um längen besser!
Das einzige, was mich persönlich an FHEM stört, ist, dass Fehler in at/notify etc erst beim Ausführen und nicht schon beim Laden der Configs erkannt werden. Wäre gut, wenn FHEM die beim Laden precompilen würde...
Dero
ZitatDas einzige, was mich persönlich an FHEM stört, ist, dass Fehler in at/notify etc erst beim Ausführen und nicht schon beim Laden der Configs erkannt werden. Wäre gut, wenn FHEM die beim Laden precompilen würde...
Siehe https://forum.fhem.de/index.php?topic=51744
Funktioniert z.Zt. nur bei einem define/modify im laufenden Betrieb, d.h. nix fuer Leute, die fhem.cfg direkt editieren :)
Wieder eine Zeitumstellung und leider wird diese wieder nicht respektiert.
FHEM zeigt die richtige Uhrzeit an. Also wird es vermutlich morgen wieder übernommen?
Was genau kann/soll man hier tun, damit die Zeitumstellung zukünftig direkt am "Umstellungs-Tag" berücksichtigt wird?
Danke
Was ist mit openhab?
Und mit der genauen Schilderung der Probleme?
Hi Rudi,
ich hänge mich hier mal mit rein. Ich hatte gestern folgendes Problem mit at bzw. vermutlich mit der verwendeten Funktion sunset:
COMMAND set sz_Rolladen 10
DEF *{sunset("REAL",0,"16:00","21:15")} set sz_Rolladen 10
NAME at_sz_Rolladen_Down
NR 474
NTM 16:39:40
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 16:39:40
TIMESPEC {sunset("REAL",0,"16:00","21:15")}
TRIGGERTIME 1478014780
TRIGGERTIME_FMT 2016-11-01 16:39:40
TYPE at
Readings:
2016-10-31 16:41:38 state Next: 16:39:40
Mein Problem war gestern, dass das at eine Stunde zu spät geschaltet hat, also ca. 17:40, richtig wäre aber auch gestern schon ca. 16:40 gewesen.
Grüße, Volker
Ich errechne die Zeit plus n Tage in WeekdayTimer so. Klappt auch bei Sommerzeit/Winterzeit immer.
Funktioniert sogar bei der Addition mehrerer Tage korrekt, selbst wenn es bis zum Tag der Umstellung noch Tage hin ist.
Bis zu dieser Lösung hatte ich auch immer Probleme: Von einer Endlosschleife bis zu falschen Zeiten bei Sommerzeit oder Winterzeitumstellungen war immer alles dabei.
################################################################################
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;
}
ZitatDas einzige, was mich persönlich an FHEM stört, ist, dass Fehler in at/notify etc erst beim Ausführen und nicht schon beim Laden der Configs erkannt werden. Wäre gut, wenn FHEM die beim Laden precompilen würde...
Vielleicht wäre es eine Möglichkeit den PerlCode von at/notify ... grundsätzlich in 99_utils abzulegen. Als Perlcode ist dann nur noch ein Funktionsaufruf zu codieren. Die blöden / wären dann auch nicht mehr notwendig.
Dann würden Fehler überhaupt und früher als jetzt erkannt. Vielleicht kann man das über die Oberfläche irgendwie unterstützen, ähnlich dem RegEx Editor.
Zitat von: ht am 31 Oktober 2016, 20:28:42
Hi Rudi,
ich hänge mich hier mal mit rein. Ich hatte gestern folgendes Problem mit at bzw. vermutlich mit der verwendeten Funktion sunset:
COMMAND set sz_Rolladen 10
DEF *{sunset("REAL",0,"16:00","21:15")} set sz_Rolladen 10
NAME at_sz_Rolladen_Down
NR 474
NTM 16:39:40
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 16:39:40
TIMESPEC {sunset("REAL",0,"16:00","21:15")}
TRIGGERTIME 1478014780
TRIGGERTIME_FMT 2016-11-01 16:39:40
TYPE at
Readings:
2016-10-31 16:41:38 state Next: 16:39:40
Mein Problem war gestern, dass das at eine Stunde zu spät geschaltet hat, also ca. 17:40, richtig wäre aber auch gestern schon ca. 16:40 gewesen.
Grüße, Volker
mein problem ist jetzt , das alles eine stunde zu früh triggert, denn es wird ja früher dunkel. wie löst man das eigentlich, ohne neue zeilen zu schreiben?
Das problem ist, dass danach
TRIGGERTIME 1478014780
getriggert wird.
Das kennt keine Zeitzone. Sollte sich eigentlich nach einem Fehlversuch erledigt haben.
Aus meiner Sicht liegt das Problem in 99_SUNRISE_EL.pm in Zeile 116ff
$nt += 86400;
@lt = localtime($nt);
Da hier mit Ticks gearbeitet wird, bleibt die TZ-Umstellung der Nacht außen vor.
wenn das so umgebaut wird klappt es:
https://forum.fhem.de/index.php/topic,42920.msg513255.html#msg513255 (https://forum.fhem.de/index.php/topic,42920.msg513255.html#msg513255)
Im at gibt es eine Logik, die daylightsavingtime erkennt, aber nicht 100%ig.
Das Problem war, dass sowohl SUNRISE, wie auch at die Uhrzeit wg. Zeitumstellung korrigiert hat, was wg. doppelter Korrektur schiefging. Ich habe die Korrektur in 99_SUNRISE_EL.pm ausgebaut, in einem Linux-VM Datum auf 29.10.2016 bzw. 25.3.2017 gestellt, und mit sunset(), sunset_abs() und "defmod myAt {sunset()} hallo" herumexperimentiert: ich meine jetzt funktioniert es richtig.
Dabei ist mir aufgefallen, dass sun*_abs() nach dem entsprechenden Zeitpunkt die Zeit fuer den naechsten Tag gerechnet hat, das habe ich auch gefixt.
@volschin/Dietmar63: bitte Verbesserungen nur dann posten, wenn ihr das auch getestet habt, sonst entstehen nur Geruechte.
Ich habe keine Verbesserung gepostet, nur eine Vermutung zur fehlerhaften Routine geäußert.
Aber mal zu Deiner geplanten Korrektur: 99_SUNRISE_EL.pm wird doch nicht nur durch at genutzt, oder?
Funktionieren denn andere Module dann noch sauber?
ZitatFunktionieren denn andere Module dann noch sauber?
Keine Ahnung, haengt vom Modul ab.
Ich finde die aktuelle Loesung sauber, das kann ich notfalls auch mit Argumenten unterlegen :)
Zitat von: rudolfkoenig am 01 November 2016, 17:13:33
Keine Ahnung, haengt vom Modul ab.
Ich finde die aktuelle Loesung sauber, das kann ich notfalls auch mit Argumenten unterlegen :)
DOIF-Modul z. B. korrigiert die Zeit selbst, unabhängig davon von wo die Zeit kommt. Alles andere ist wenig sinnvoll. Sollte also mit dem Update kein Problem sein.
Gruß
Damian