Twilight/Sunrise_EL - Zeitangaben passen nicht

Begonnen von cotecmania, 03 Januar 2014, 12:44:11

Vorheriges Thema - Nächstes Thema

cotecmania

Hallo Zusammen,

warum stimmen die Zeitangaben von Twilight/Sunrise_EL (beide gleich) nicht mit den Zeiten z.B. aus dem Internet ueberein ?
Die Internetzeiten passen bei mir auch besser mit der Realität zusammen.

Hier am Beispiel Ulm: 48.4 10 0 677807
Heute : 03.01.2014

Twilight ss/sr : 08:16 - 16:32
sunset/rise_abs : 08:15 - 16:33

Internet : 08:11 - 16:38
http://www.sunrise-and-sunset.com/de/deutschland/ulm/2014/januar/3
http://www.mondkalender-online.de/sonnenuntergang.asp?ort_de=Deutschland&ort_a=%D6sterreich&ort_ch=Schweiz&ort=Ulm&fLandesKuerzel=DE&Tagzahl=3&Monat=1&Jahr=2014&zeitzone=1

Also morgens 5-6 Minuten zu spät und abends 5-6 Minuten zu früh !
Da dies reine Berechnungen sind, muesste das doch auf 1 Minute hin oder her genau gleich sein (ausser Rundungsfehler) ?
Es ist auch kein Offsetfehler sondern der Tag wird morgens/abends zu kurz berechnet. Vielleicht wird das falsche Datum verwendet ?

Ich will ja nicht kleinlich sein aber mir geht's hier einfach ums Prinzip und bei Twilight werden die anderen Zeiten ja von diesen als Ausgangsbasis weiterberechnet, oder ?

Ausserdem versuche ich gerade mit Twilight, wenns dunkel wird, meine Rolläden runter zu fahren und da komm ich mit den Zeiten bei mir einfach nicht hin !
Mit indoor_horizon kann ich nur in die "falsche" Richtung korrigieren und kleiner Null geht hier nicht.

Also muesste ich mit den Längen und Breitenangaben spielen, das ist aber doch nicht Sinn der Sache und ich weiss nicht ob das im Laufe der Jahreszeiten dann noch stimmt ?
Bleiben also nur die Werte twilight und twilight_weather, welche es aber wieder unnötig kompliziert machen das mit einem at-Befehl zu automatisieren.

Gruss
Joe
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

Dietmar63

Twilight, sunrise, sunset nutzen unterschiedliche Algorithmen. Deshalb die Unterschiede. Im Internet werden meiner Recherche nach die besten Algorithmen verwendet.

Jeder Horizont wird für sich berechnet.

Rollos lassen sich mit sunrise am besten steuern. Dort kann man ja jede beliebige Horizontlinie angeben.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

rudolfkoenig

Weil Sonnenaufgang nicht mathematisch exakt definiert ist: welcher Teil der Sonne (oben/mitte/unten) soll wie (mit oder ohne Lichtbrechung) sichtbar sein. Fuer manche (und FHEM) ist die Sonne unten, wenn man nicht mehr lesen kann, fuer andere erst, wenn man den Weg nicht mehr erkennt, in beiden Faellen ist die Sonne aber schon laengst komplett verdeckt.

Sollte einem kar werden, wenn man die Doku dazu liest: http://fhem.de/commandref.html#SUNRISE_EL

P.S.: ich kann nur fuer SUNRISE_EL reden, Twilight kenne ich nicht wirklich.

cotecmania

#3
Aber Twilight und sunrise liefern doch die selben Ergebnisse, obwohl unterschiedliche Algorithmen verwendet werden ?
Auf die Minute kommts mir nicht an aber deren Ergebniss ist (im Vergleich zu allen seiten im Internet) falsch.

Aber zu den 5 Minuten Unterschied zu den Internet-Werten, das kann doch nur ein grober Fehler sein.

Schau selbst mal mit diesem einfachen Excel-Sheet im Anhang kommt das richtige raus ! Ich hab das im Internet gefunden und kurz eingehackt ...
Dahinter verstecken sich nur 2 längere Formeln mit ein paar Konstanten und die liefern das richtige Ergebnis.

Gruss
Joe
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

rudolfkoenig

Ok, ich gebe zu: wenn es Excel ist, und aus dem Internet kommt, dann muss es richtig sein.

Dietmar63

#5
Twilight ist abgekupfert aus einer Version für die Homematic Zentraleinheit - Wurde ursprünglich von unimatrix hier für uns bereit gestellt.

ZitatAber zu den 5 Minuten Unterschied zu den Internet-Werten, das kann doch nur ein grober Fehler sein.

In TW kommt diese Formel zum Einsatz:
http://lexikon.astronomie.info/zeitgleichung/
Im unteren Bereich findest du auch Anmerkungen zum Thema Genauigkeit. Meiner Ansicht nach scheint die Erdkugel mehr wie ein Brummkreisel zu taumeln als sich exakt wie eine Atomuhr zu verhalten. Vom Prinzip her wird es sich um überlagernde Sinuskurven handeln zu denen man so etwas wie den Nullpunkt berechnen muss - nur dass man die Koeffizienten nicht so genau kennt und mit Annahmen arbeiten muss.

Dies soll eine sehr genaue Berchnungsformel sein:
http://de.wikipedia.org/wiki/Sonnenstand
Aber auch hier hat der Verfasser des Artikels beschrieben, dass es mit aufwendigeren Verfahren noch genauer geht und verweist auf Astronomieprogramme bzw. das Internet. Ich würde da  mehr auf Astronomieprogamme setzen.

Ich habe es nicht geschafft die Formel abzubilden. Ich meine es ist irgendwie an folgendem gescheitert:
ZitatAls Zeitvariable n wird die Anzahl der Tage seit dem Standardäquinoktium J2000.0 (1. Januar 2000, 12 Uhr TT ≈ 12 Uhr UT) verwendet (gegebenenfalls inklusive Tagesbruchteil in UT) .
Ist JD die Julianische Tageszahl des gewünschten Zeitpunkts, so gilt ...

Wenn die Formeln in Excel existieren braucht du sie ja nur nach Perl zu verwandeln.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

cotecmania

#6
Hallo Dietmar63,

genau die erste Seite im Internet habe ich auch verwendet und damit Du mir nun glaubst dass es nix mit Genauigkeit zu tun hat sondern ein Fehler in den Berechnungen drin ist, habe ich genau diese Rechenschritte (Beispiel im Internet) in Excel eingehackt.
- Einmal das gegebene Beispiel Berlin 30. Januar. Ergebnis passt !
- Dann mein Beispiel Ulm, 3 Januar

und Du siehst es kommt für Ulm am Tag 3 der Sonnenaufgang 08:10:31 raus und nicht wie in Twilight 08:16

Excel-Berechnung findest Du im Anhang.

Gruss
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

Dietmar63

Die Formel für die Zeitdifferenz ist fasch in Excel eingetippt:

=12*ARCCOS((SIN(B38)-SIN(B34)*SIN(B36))/(COS(B34)*COS(B36)))/B31
muss geändert werden in
=12*ARCCOS((SIN(B33)-SIN(B34)*SIN(B36))/(COS(B34)*COS(B36)))/B31

Wobei die b33 den horizon annehmen muss: 0°.

Nach den Änderungen stimmen die Werte immer noch nicht 1000%-tig. Aber eine Abweichung von einer Sekunde sollten wir vernachlässigen.

Ich habe die geänderte Excel angehängt und Zwischenergebnisse eingefügt - mit meinem Heimatort berechnet. In rot markierten Zellen habe ich Änderungen vorgenommen.

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

cotecmania

Hallo Dietmar,

falsch eingetippt lasse ich nicht gelten, sondern exakt so wie im Internet und da kommt bei mir für Berlin exakt die Zeit raus wie im Beispiel im Internet nämlich 7:50 Uhr.
Mit horizon=0 kommt dann 7:56 raus. Das ist genau die Differenz die wir suchen.
Dann wäre ja auch das Beispiel auf der Inet-Seite falsch ?
Du verwendest den Wert "Sonnenaufgang Bogen (-0.0145 rad)" überhaupt nicht in deiner Berechnung sondern setzt dafuer einfach horizon=0 ein.

Zitat :
"Das Licht der Sonne wird in der Atmosphäre gebeugt. Es läuft besonders in Horizontnähe auf einer leicht zum Boden hin gekrümmten Bahn. Deshalb kann man die Sonne auch noch sehen, wenn sie rein geometrisch schon untergegangen ist. Deshalb wird der Untergang und auch der Aufgang der Sonne für eine geometrische Horizonthöhe h von -50 Bogenminuten berechnet (-50 Bogenminuten sind -50/60°=-0.833° und -50/60/57.29578 rad=-0.0145 rad)".

Versteh das hier bitte nicht falsch, ich will keinem einen Fehler unterjubeln, ich will lediglich verstehen ob oder warum eine Differenz der FHEM-Berechnung zu allen anderen Berechnungen im Internet sein muss/kann/darf oder nicht.

PS : Alle Internetseiten berechnen für dein Beispiel (Bu am Tag 4) somit Sonnenaufgang 08:29  anstatt 08:35  ;)

Gruss
Joe
 
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

rudolfkoenig

Zitatich will lediglich verstehen ob oder warum eine Differenz...

Einfach zu verstehen, wenn man meinen Beitrag liest:
FHEM waehlt einen anderen der vielen willkuerlichen Sonnenuntergang/-Aufgang Zeitpunkte, als die anderen Programme aus dem Internet.

Dietmar63

Zitat"Das Licht der Sonne wird in der Atmosphäre gebeugt. Es läuft besonders in Horizontnähe auf einer leicht zum Boden hin gekrümmten Bahn. Deshalb kann man die Sonne auch noch sehen, wenn sie rein geometrisch schon untergegangen ist. Deshalb wird der Untergang und auch der Aufgang der Sonne für eine geometrische Horizonthöhe h von -50 Bogenminuten berechnet (-50 Bogenminuten sind -50/60°=-0.833° und -50/60/57.29578 rad=-0.0145 rad)".

Dieser Effekt wurde in fhem weder in sunrise noch in TW umgesetzt.
In sunrise kann man den Wert per horizon Parameter mitgeben. In TW leider nicht.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm