Hi all,
seit einiger Zeit schon gehen meine Lampen zu seltsamen Zeiten an, heute habe ich endlich mal reingesehen.
Ergebnis ist, dass
*{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
*{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:
*{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?
http://fhem.de/commandref.html#SUNRISE_EL
du musst sunset und sunrise natürlich für deinen ort nutzen
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:
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
Wenn in global der richtige Längen- und Breitengrad eingestellt ist, sollten die Daten stimmen.
VG
Frank
Zitat von: chris1284 am 11 April 2016, 21:43:49
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:
ZitatSoweit 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.
Zitat von: franky08 am 11 April 2016, 22:23:03
Wenn in global der richtige Längen- und Breitengrad eingestellt ist, sollten die Daten stimmen.
VG
Frank
Ja, sind sie. Ich schrieb ja:
ZitatSoweit 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.
Zitat von: KölnSolar am 11 April 2016, 22:01:29
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:
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.
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
ich habs gerade mal für Berlin mit
latitude 52.666
longitude 13.400
ausprobiert
hier noch sunrise
Da haste nen falschen Namen, müsste sonneauf heißen ;D
Zitat von: fhem-hm-knecht am 11 April 2016, 23:07:59
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.
Und jetzt bin ich noch baffer:
Alle Zeiten sind um eine stunde verschoben.
Sowas hier:
define mi_tor at *06:05:09 ...führt zu
Zitatmi_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.
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
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
Okay, wir können den Thread hier zu machen, ich habe eine neuen angelegt, da das Problem nicht sunset-spezifisch ist:
https://forum.fhem.de/index.php?topic=52074.msg438255#msg438255