FHEM Forum

Im Zusammenhang mit einigen Seltsamigkeiten die besonders meine Holde moniert hat, bin ich zuerst darauf gestossen, das sunset und sunrise Zeiten bei mir falsch berechnet werden, siehe hier

https://forum.fhem.de/index.php?topic=52063.msg438250

Bei nähere Untersuchung und Diskussion bin ich aber darauf gekommen, das in meinem System ALLE Zeiten eine Stunde zu spät sind. Und zwar mit einem Twist...

1. Die Uhr des Rechners geht richtig.

Zitatxyz@zyx:~# date
Tue Apr 12 00:58:22 CEST 2016

Zitatxyz@zyx:~# hwclock
Tue Apr 12  00:58:23 2016  0.000000 seconds

zeigten die zu dem Zeitpunkt richtige Uhrzeit an.

2. Wenn ich irgendwas anlege, was eine absolute Zeit ergibt, sei es mit
at 01:00:00
oder
{sunset()}
ergibt sich immer eine Ausführungszeit die eine Stunde zu spät ist.

Das hier:
define Licht_Test at 01:17:44 set Licht_StehlampeC_WZ_U off
führt dazu, dass Fhem meint die nächste Ausführung sei um 02:17:44

Jetzt kommt der Twist:
Es ist nicht etwa so, dass der Befehl aufgrund eines Uhrzeitproblem eine Stunde zu spät angelegt wird und dann auch eine Stunde früher - also doch zur richtigen Zeit ausgeführt wird - man das Problem also lösen könnte in dem man die Zeitzone verbiegt.

Vielmehr wird der Befehl tatsächlich zur falsch berechneten Uhrzeit aber dann korrekt ausgeführt.
define Licht_Test at 01:17:44 set Licht_StehlampeC_WZ_U off
führt dazu, dass Fhem meint, die nächste Ausführung sei um 02:17:44
und es wird dan auch tatsächlich um 02:17:44 geschaltet.

Ich hab das eben quasi ins extrem getrieben:

Ich habe um 01:31 folgenden Befehl eingegeben.
define Licht_Test2 at 00:33:30 set Licht_StehlampeC_WZ_U off

Eigentlich ist die Uhrzeit in der Vergangenheit, die nächste Auslösung sollte also MORGEN sein.
Tatsächlich aber zeigen die readings:

ZitatReadings
state
Next: 01:33:30
2016-04-12 01:31:46

D.h. die Uhrzeit wann ich den Befehl eingegeben habe wird korrekt erkannt, dann wird das nächste Event FALSCH berechnet und knapp 2 Minuten später geht genau zur falsch berechneten Uhrzeit das Licht aus.

define Licht_Test2 at +00:01:30 set Licht_StehlampeC_WZ_U off
hingegen ergibt die RICHTIGE Zeit:

ZitatReadings
state
Next: 01:48:19
2016-04-12 01:46:49

Kapier ich nicht.
Irgendjemand eine Idee?

Ich weiss leider nicht wie lange das so schon geht, da die die meisten Schaltungen passieren wenn ich nicht da bin.

Im ersten Moment ist das auf jeden Fall rätselhaft.
Kann es vielleicht sein, dass es unterschiedliche timezone Einstellungen für FHEM bzw. den FHEM Benutzer und Deine shell-Benutzer (also die interaktive Session in der Du Date eingibst)?

Was steht denn im Log file, wenn ein solcher trigger kommt? Wenn da dieselbe Urhzeit steht wie im at angegeben, dann ist vermutlich obige Vermutung richtig. Wenn da etwas anderes steht, ist etwas sehr komisch...

Johannes

Hm... sicherheitshalber gleich noch mal getestet:
define Licht_Test at 01:24:30 set Licht_StehlampeC_WZ_U off

ZitatReadings
state
Next: 02:24:30
2016-04-12 02:23:24

Lampe geht tatsächlich um 2:24:30, also ca. eine Minute später aus
Logfile sagt:

Zitat2016.04.12 02:24:30 2: IT set Licht_StehlampeC_WZ_U off

ZitatKann es vielleicht sein, dass es unterschiedliche timezone Einstellungen für FHEM bzw. den FHEM Benutzer und Deine shell-Benutzer (also die interaktive Session in der Du Date eingibst)?

Klingt als Idee nicht schlecht, nur: Ob das sein kann oder nicht kann ich nicht beurteilen.
Ich bin jetzt nicht der Über-LINUX-Crack um es vorsichtig zu formulieren und hätte keine Ahnung wie man die Zeit von FHEM bzw FHEMs user verstellen könnte.

Ausserdem: so richtig logisch ist das nicht, denn das würde bedeuten das FHEM zum Errechnen einer Uhrzeit seine eigene Zeit verwendet, zur Auslösung eines Events aber nicht. Das klingt mir nicht sehr wahrscheinlich.



Übrigens zeigt ein INFO TIMER in telnet auf FHEM alle Events mit der richtigen Uhrzeit.

Das sieht für mich nicht so aus, also ob FHEM ne andere Uhrzeit hat.

Was liefert FHEM beim Ausführen von {$isdst} in der Eingabezeile?

Nochmals die Frage: Was steht denn im FHEM-Logfile (u.U. musst Du das Attribute verbose noch hochstellen), da aber die Einträge im Log mit einem Zeitstempel versehen werden, kannst Du da erkennen was für eine Zeit FHEM glaubt zu haben...

(Alternativ kannst Du auch einfach mal den Event Monitor anwerfen)

Johannes

was sagt den
{localtime}

Gruß Markus

{$isdst}  liefert "1"
Was sagt das aus?

ZitatNochmals die Frage: Was steht denn im FHEM-Logfile

Hm. Das Logfile zeigt alle Operationen richtig aber mit einer Stunde zu spät an.


define Licht_Test at 01:24:30 set Licht_StehlampeC_WZ_U off

Ergibt readings

ZitatReadings
state
Next: 02:24:30
2016-04-12 02:23:24

Lampe ging tatsächlich um 2:24:30, also ca. eine Minute später aus
und im Logfile stand dann:

Zitat2016.04.12 02:24:30 2: IT set Licht_StehlampeC_WZ_U off

D.H. die Logfile-Uhrzeiten sehen unauffällig aus. Sie korospondieren mit der tatsächlichen Uhrzeit.

Oder was meinst du?

Auch Telnet und INFO TIMER zeigt alle Events mit der tatsächlichen Uhrzeit an.  Soweit sichtbar stimmt alles im System - überall ist die richtige Uhrzeit - egal was ich frage, in welche Logs ich sehe oder ob ich events mit Telnet beobachte. Nur alle absoluten "at" Commandos werden für eine Stunde später als "befohlen" angelegt.

{localtime}
gibt die tatsächliche aktuelle Uhrzeit aus. Als jetzt gerade:

ZitatTue Apr 12 22:51:24 2016

und es ist jetzt auch 22:51 Uhr

Eben nochmal neu probiert:

Eingabe von

Zitatdefine Licht_Test2 at 23:01:00 set Licht_StehlampeC_WZ_U off

führt laut telnet inform timer zu diesem:

Zitat
2016-04-12 22:59:41 at Licht_Test2 Next: 00:01:00
2016-04-12 22:59:41 Global global DEFINED Licht_Test2

Aktuell Uhrzeit des Rechner bzw der Timer Ausgabe RICHTIG, errechnete Ausführungsuhrzeit eine Stunde zu spät.

:o


Internals

ZitatCFGFN
COMMAND
set Licht_StehlampeC_WZ_U off
DEF   
2016-04-13T00:01:00 set Licht_StehlampeC_WZ_U off
NAME
Licht_Test2
NR
2060
PERIODIC
no
RELATIVE
no
STATE
Next: 00:01:00
TIMESPEC
23:01:00
TRIGGERTIME
1460498460
TRIGGERTIME_FMT
2016-04-13 00:01:00
TYPE
at
VOLATILE
1

Timespec steht auf die eigentlich richtige Zeit 23:01, Triggertime (beide) und "next" aber nicht.

Kapier ich nicht.

Ich muss zugeben ich bin ratlos, denn meine Vermutung war, dass fhem intern irgendwie von einer falschen Zeit ausging. Die Zeit intern in fhem scheint aber richtig zu sein (inkl Sommerzeit --> isdst).

Beim Anlegen des at's wird aber eine falsche Zeit gesetzt, mir fällt dazu aber keine Ursache ein.
Sorry

Tja, wen frag ich? Rudolf König?

Ich würde mir mal auf Systemebene die Zeitzone ansehen.

LG

pah

Klarstellung: andere Installation haben das Problem nicht, sonst haette ich mehr darueber gehoert. Auch ich konnte das bei mir nicht reproduzieren. Nach analysieren der Daten (bitte die Internals demnaechst besser formatieren), gehe ich davon aus, dass dein mktime() oder localtime() Funktion kaputt (oder nicht FHEM-Kompatibel :) ) ist.
Kannst du bitte folgendes nachstellen, und hier berichten?
fhem> { join(",", localtime(1460498460)) }
0,1,0,13,3,116,3,103,1
fhem> { mktime(0,1,0,13,3,116) }
1460498460
fhem> { mktime(0,1,23,12,3,116) }
1460494860
fhem> { localtime(1460494860) }
Tue Apr 12 23:01:00 2016
fhem> { join(",", localtime(1460494860)) }
0,1,23,12,3,116,2,102,1


Hi Rudi,

Ja, generell kaputt ist Fhem sicher nicht, ich hab ja vorher auch gesucht und offenbar hat das ausser mir keiner.


Hier die Ergebnisse:
fhem> { join(",", localtime(1460498460)) }
0,1,0,13,3,116,3,103,1
fhem> { mktime(0,1,0,13,3,116) }
1460502060
fhem> { mktime(0,1,23,12,3,116) }
1460498460
fhem> { localtime(1460494860) }
Tue Apr 12 23:01:00 2016
fhem> { join(",", localtime(1460494860)) }
0,1,23,12,3,116,2,102,1

mktime() Wert sieht anders aus. Hm. Aber wieso? (Gut, das ist dann vermutlich keine Fhem-spezifische Frage)

Versuch mal mktime mit allen Werten localtime, also mit insg. 9 Werten.

Welches OS und Perl Version hast du?

Vergib mir, wenn ich ich mir hier als Linux Noob oute:

ZitatVersuch mal mktime mit allen Werten localtime, also mit insg. 9 Werten.

Äh.. verstehe ich so noch nicht... sorry.



Linux <...> 2.6.16.16-arm1 #383 Mon Nov 10 13:33:20 JST 2008 armv5tejl
This is perl, v5.8.8 built for armv5tejl-linux


Das Ganze läuft bei mir auf einer LinkStation und ich habe wenig Möglichkeit da einfach mal upzudaten. Jedenfalls nicht mit meinem Kenntnislevel.
Vieleicht muss ich mal mit einem Raspi oder so befassen.

Vlt. wirst du hier fündig: http://www.perl-community.de/bat/poard/thread/15824

VG
Frank

fhem> { mktime(0,1,0,13,3,116,3,103,1) }
fhem> { mktime(0,1,23,12,3,116,2,102,1) }

fhem> { mktime(0,1,0,13,3,116,3,103,1) }
1460498460
fhem> { mktime(0,1,23,12,3,116,2,102,1) }
1460494860

ZitatVlt. wirst du hier fündig: http://www.perl-community.de/bat/poard/thread/15824

Der Inhalt des Threads is leider klar jenseits meiner Fähigkeiten.

Ist doch gar nicht kompliziert.

Es geht nur darum, dass eine der Timezone-Variablen auf CET statt CEST eingestellt ist - also keine Sommerzeit kennt.

LG

pah

Zitatdass eine der Timezone-Variablen auf CET statt CEST eingestellt ist - also keine Sommerzeit kennt.

1. Woran erkenn ich das? oder anders: Wieviele Stellen hat so ein LINUX wo das eingestellt werden muss?
2. Wieso sind dann alle sonstigen Zeiten richtig?
3. Wo stelle ich das ein
4. Wieso hat das System in den letzten Jahren die Sommerzeit automatisch übernommen und diesmal nicht?
Oder anders: die die Kiste benutzt NTP -   (Okay, das ist die grosse Frage ich weiss.)

Da es sich um eine Bufallo-Linkstation handelt, hat die eigentlich eine Oberfläche wo man das alles einstellen kann und da steht natürlich alles richtig

NTP sorgt "nur" fuer die genaue UTC-Uhrzeit. Das systemweite Offset steht ueblicherweise in /etc/localtime, was je nach Distribution ein Link nach /usr/share/zoneinfo/XX/YY ist (Beispiel fuer XX/YY ist Europe/Berlin), oder eine Kopie dieser (binaeren) Datei. Fuer einzelne Prozesse kann man den Offset durch die Umgebungsvariable TZ setzen, wie man das Systemweit setzt, ist je nach Distribution unterschiedlich. Das alles ist aber eigentlich kein Thema fuer dieses Forum.

Ich schaffe mit einem "falsch" gesetzten TZ (z.Bsp. GMT-1, da CET/MET, laut wiki (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) beide gueltig, die Sommerzeit liefern) keine Abweichung zwischen localtime und mktime, d.h. die in der Log angezeigte Uhrzeit und die per at definierte passen zusammen.

Ich will noch rauskriegen, ob ich beim mktime Aufruf noch was machen kann. Laut "man mktime"

ZitatThe value specified in the tm_isdst field informs mktime()  whether  or
       not  daylight  saving  time (DST) is in effect for the time supplied in
       the tm structure: a positive value means DST is in effect;  zero  means
       that  DST  is  not  in effect; and a negative value means that mktime()
       should (use timezone information and system databases  to)  attempt  to
       determine whether DST is in effect at the specified time.

Kannst du bitte folgendes probieren:

Zitatfhem> { mktime(0,1,0,13,3,116,0,0,-1) }
fhem> { mktime(0,1,0,13,3,116,0,0, 1) }
fhem> { mktime(0,1,0,13,3,116,0,0, 0) }

Falls bei dir die erste Variante 1460498460 anzeigt, dann stelle ich FHEM um.
Sonst bleibt es bei dir das Problem irgendwo im OS zu suchen.

Hi Rudolf,

fhem> { mktime(0,1,0,13,3,116,0,0,-1) }
1460498460
fhem> { mktime(0,1,0,13,3,116,0,0, 1) }
1460498460
fhem> { mktime(0,1,0,13,3,116,0,0, 0) }
1460502060

D.H. beide Methoden liefern das selbe Ergebnis,.

ZitatIch schaffe mit einem "falsch" gesetzten TZ (z.Bsp. GMT-1, da CET/MET, laut wiki beide gueltig, die Sommerzeit liefern) keine Abweichung zwischen localtime und mktime, d.h. die in der Log angezeigte Uhrzeit und die per at definierte passen zusammen.

Das habe ich quais umgekehrt probiert, nämlich das Problem damit zu lösen. Was aber nicht geklappt hat, es passten immer die Zeiten nicht zusammen.

ZitatNTP sorgt "nur" fuer die genaue UTC-Uhrzeit. Das systemweite Offset steht ueblicherweise in /etc/localtime, was je nach Distribution ein Link nach /usr/share/zoneinfo/XX/YY ist (Beispiel fuer XX/YY ist Europe/Berlin), oder eine Kopie dieser (binaeren) Datei. Fuer einzelne Prozesse kann man den Offset durch die Umgebungsvariable TZ setzen, wie man das Systemweit setzt, ist je nach Distribution unterschiedlich. Das alles ist aber eigentlich kein Thema fuer dieses Forum.

Ja, ich habe mich auch ausprobiert und symlinks auf diverse XX/YY gesetzt (habe mir vorher angesehen, was die Linkstation da alles hat). Das hat aber keinen erkennbaren Erfolg. localtime durch eine richtige Kopie ersetzen habe ich noch nicht gemacht.

Das das alles auf dem Level keine Thema für dieses Forum ist, ist mir klar.

Zitatand a negative value means that mktime()
       should (use timezone information and system databases  to)  attempt  to
       determine whether DST is in effect at the specified time.

Ich dachte eine Zeitlang, da könnte der Hase im Pfeffer liegen: Da das OS schon was älter ist, gehen die system databases ebentuell nur bis 2015 oder so. Diese Auffassung vertrat eine Kollege von mir, als ich ihm das Problem schilderte.
Aber wenn
[code]fhem> { mktime(0,1,0,13,3,116,0,0,-1) }
1460498460
fhem> { mktime(0,1,0,13,3,116,0,0, 1) }
1460498460

kann das ja auch nicht sein oder?

Ich werde jedenfalls kaum in der Lage sein, den Fehler im OS zu finden, dazu hab ich einfach nicht genug LINUX Kenntnsisse. Eher werd ich meine config so umschreiben, dass sie selbst weiss wann Sommerzeit ist und dann alle "at" um eine Stunde vorverschiebt.

Ist natürlich ne Grusellösung.

Ich habe 90_at.pm so geaendert, dass mktime explizit mit -1 aufgerufen wird.
Das sollte default sein, ist bei deinem Perl oder POSIX Modul wohl nicht der Fall.

Okay, mal sehen.

Warum das bei mir nicht so ist ... Tja, keine Ahnung.
Das lief bisher eigentlich und
Ich hab nichts verändert (TM)

Müsste die 90_at.pm über Update zu ziehen sein?

War heute früh im update
90_at.pm                 11273 2016-04-17 18:16:12Z rudolfkoenig

VG
Frank

Ok, thx!