Sunset führt zu seltsamen Zeiten

[Zrrronggg!]

Hi all,

seit einiger Zeit schon gehen meine Lampen zu seltsamen Zeiten an, heute habe ich endlich mal reingesehen.

Ergebnis ist, dass

Code Auswählen Erweitern

*{sunset()} ohne weiteres offset bei mir zu einer Schaltzeit von
21:36:16 führt.

Tatsächlicher sunset in Berlin heute aber 19:59.

Genauso führt

Code Auswählen Erweitern

*{sunset(-100)}
zu einer Ausführung um 21:34:36 was vom offset her konsistent falsch ist: 100 Sekunden vor 21:26:16


Soweit so schlecht, die Koordinaten stimmen und die Uhr des Rechners geht richtig, Datum auch.

Aber jetzt wird's noch komischer:

Code Auswählen Erweitern

*{sunrise(+600)}

führt zu einer Auslösung um
06:47:23
tatsächlicher Sonnenaufgang ist um
06:15 Uhr
D.H. +600 sollte um
06:25 Uhr
auslösen.

D.H. beide Zeiten sind falsch und beide sind ANDERS falsch.
Hab gesucht, aber auf die Schnelle nichts gefunden wo jemand was Ähnliches berichtet hat.

Hat einer Ideen?  Ist das Problem bekannt und ich hab nur nix gefunden?

[chris1284]

http://fhem.de/commandref.html#SUNRISE_EL

du musst sunset und sunrise natürlich für deinen ort nutzen 

[KölnSolar]

Ich hab keine Probleme. 21:36 klingt für mich gar nicht verkehrt im Vergleich zu 20:57 in Köln. sicher, dass Du die richtigen Daten(Civil Twilight) verglichen hast ?

commandref:

Code Auswählen Erweitern

The default altitude ($defaultaltit in SUNRISE_EL.pm) defines the sunrise/sunset for Civil twilight (i.e. one can no longer read outside without artificial illumination), which differs from sunrise/sunset times found on different websites

Check doch mal gegen das Twilight modul. Dort bekommt man die verschiedenen sunsets als reading.

Grüße
Markus

[franky08]

Wenn in global der richtige Längen- und Breitengrad eingestellt ist, sollten die Daten stimmen.

VG
Frank

[Zrrronggg!]

http://fhem.de/commandref.html#SUNRISE_EL

du musst sunset und sunrise natürlich für deinen ort nutzen

Natürlich sind die Koordinaten von Berlin eingestellt, da wohne ich nämlich. Daher schrieb ich ja auch:

Soweit so schlecht, die Koordinaten stimmen und die Uhr des Rechners geht richtig, Datum auch.

Und ich benutze sunset und sunrise seit 6 Jahren, ich kenn die syntax etc.
BISHER (TM) hat das auch immer funktioniert.

[Zrrronggg!]

Wenn in global der richtige Längen- und Breitengrad eingestellt ist, sollten die Daten stimmen.

VG
Frank

Ja, sind sie. Ich schrieb ja:

Soweit so schlecht, die Koordinaten stimmen und die Uhr des Rechners geht richtig, Datum auch.

Ich benutzte das so seit Jahren und bisher ging das auch, also zu richtigen Zeiten.

[Zrrronggg!]

Ich hab keine Probleme. 21:36 klingt für mich gar nicht verkehrt im Vergleich zu 20:57 in Köln. sicher, dass Du die richtigen Daten(Civil Twilight) verglichen hast ?

commandref:

Code Auswählen Erweitern

The default altitude ($defaultaltit in SUNRISE_EL.pm) defines the sunrise/sunset for Civil twilight (i.e. one can no longer read outside without artificial illumination), which differs from sunrise/sunset times found on different websites

Check doch mal gegen das Twilight modul. Dort bekommt man die verschiedenen sunsets als reading.

Grüße
Markus

Okay, ich fang noch mal anders an.

Ich benutze sunset und sunrise seit 6 Jahren, bisher hat das geklappt, seit einiger Zeit nicht mehr. Fällt vielleicht mit meinem Update auf 5.7 zusammen, ich weiss es leider nicht, weil ich es nicht sofort bemerkt habe.

Es ist zur Auslösezeit hier stockfinster, weit hinter Civil twilight (bürgerliche Dämmerung), egal wie viel sunset nun tatsächlich nach Sonnenuntergang ist, faktisch ist bisher das Aussenlicht "so in etwa richtig" angegangen, nämlich wenn es so dunkel wurde das man gerade das Licht anmachen wollte. Und JETZT geht das Licht erst an, wenn es draussen schon richtig finster ist.

Kurzum: das Licht geht mindestens zu spät an.

Das Twighlite Modul kenne ich, ich brauche das eigentlich nicht, sunset macht alles was ich brauche. Was ich sage wollte ist: Das hat bisher immer geklappt und jetzt nicht mehr, ohne das ich die Zeiten geändert hätte. Geändert hat sich die FHEM-Version allerdings, bestenfalls kommt noch in Frage, dass das seit der Zeitumstellung nicht mehr richtig ist, natürlich ist die Uhrzeit des FHEM Hosts aber korrekt.


Aber ich entnehme euren Antworten, dass nichts bekannt ist über so einen Fehler.

[franky08]

Bei mir funktioniert das Ganze wie immer, ohne falsche Schaltsequenzen. Nutze das auch schon seit Ewigkeiten und auch mit fhem 5.7 ohne Probleme!

VG
Frank

[LuckyDay]

ich habs gerade mal für Berlin mit
latitude 52.666
longitude 13.400
ausprobiert

[LuckyDay]

hier noch sunrise

[franky08]

Da haste nen falschen Namen, müsste sonneauf heißen 

[Zrrronggg!]

ich habs gerade mal für Berlin mit
latitude 52.666
longitude 13.400
ausprobiert

Ja danke: Man sieht das die Zeiten viel früher sind als meine. Dabei habe ich exact die selben Koordinaten eingestellt.


Update: Und zwar ist meine genau EINE STUNDE später. Meine SUNRISE Auslösung ist nämlich morgen um 21:38:10, deine um (richtig) 20:38:10



Verstehe ich nicht. Nicht nur dass der Hostrechner die richtige Uhrzeit hat, vielmehr würde, wenn die falsch wäre, ja die angezeigte Zeit die richtige sein, nur die tatsächlich geschaltete falsch. Hier aber wird die Zeit falsch berechnet , dann aber exact zur falsch berechneten Zeit ausgeführt.


Jetzt bin ich baff.

[Zrrronggg!]

Und jetzt bin ich noch baffer:

Alle Zeiten sind um eine stunde verschoben.

Sowas hier:

Code Auswählen Erweitern

define mi_tor at *06:05:09 ...
führt zu

mi_tor    Next: 07:05:09

mit sunset hats also nichts zu tun.

Wie lange das schon so ist kann ich nicht sagen.
Kapier ich absolut nicht, ich werd erstmal die Büchse resetten.

[LuckyDay]

Code Auswählen Erweitern

root@bananapi:~# dpkg-reconfigure tzdata

Current default time zone: 'Europe/Berlin'
Local time is now:      Tue Apr 12 00:50:08 CEST 2016.
Universal Time is now:  Mon Apr 11 22:50:08 UTC 2016.


Vielleicht hilft es dir deine richtige Uhrzeit zu finden

[Zrrronggg!]

ja, danke, ich vermute auch eine Zeitzonen/Sommerzeit Verwirrung.


Hm:

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

Das ist eigentlich korrekt

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