Probleme mit at nach Zeitumstellung

[dero]

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

[rudolfkoenig]

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...

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

[snickers2k]

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

[rudolfkoenig]

Was ist mit openhab?
Und mit der genauen Schilderung der Probleme?

[ht]

Hi Rudi,

ich hänge mich hier mal mit rein. Ich hatte gestern folgendes Problem mit at bzw. vermutlich mit der verwendeten Funktion sunset:

Code Auswählen Erweitern

   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

[Dietmar63]

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.

Code Auswählen Erweitern


################################################################################
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;
}


[Dietmar63]

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...

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.

[satprofi]

Hi Rudi,

ich hänge mich hier mal mit rein. Ich hatte gestern folgendes Problem mit at bzw. vermutlich mit der verwendeten Funktion sunset:

Code Auswählen Erweitern

   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?

[volschin]

Das problem ist, dass danach

Code Auswählen Erweitern

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

Code Auswählen Erweitern

    $nt += 86400;
    @lt = localtime($nt);

Da hier mit Ticks gearbeitet wird, bleibt die TZ-Umstellung der Nacht außen vor.

[Dietmar63]

wenn das so umgebaut wird klappt es:
https://forum.fhem.de/index.php/topic,42920.msg513255.html#msg513255
Im at gibt es eine Logik, die daylightsavingtime erkennt, aber nicht 100%ig.

[rudolfkoenig]

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.

[volschin]

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?

[rudolfkoenig]

Funktionieren 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

[Damian]

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