Sonnenauf/untergang und Zeit verknüpfen?

[saft6luck]

Das Verhältnis von Winkeldifferenz zu Zeitdifferenz ändert sich nun mal mit der Jahreszeit - wenn auch nur so um die 20% in unseren Breiten, so das man neben den geografischen Koordinaten immer auch noch das Datum braucht, außerdem ist die Funktion für eine genaue Berechnung relativ umfangreich und kompliziert.

Was meinst du denn mit den 20%?
Die Elevation braucht doch auch das Datum, um den Winkel zu berechnen?!
Meinst du man berechnet Elevation selbständig und rechnet dann auf die Zeit um und umgekehrt?

[Bodo]

Äh, anders herum wird ein Schuh draus: im Winter ist es spontan dunkel, im Sommer ist es ein schleichender Prozess.

Hoi

Wir haben beide nicht recht:

Auf 50° nördliche Breite
Die längsten Dämmerungszeiten werden in diesem Fall jeweils zur Sommersonnenwende erreicht.
Die kürzesten Dämmerungszeiten treten hier folgendermaßen nahe den Tagundnachtgleichen ein

Wikipedia: Dämmerung

[bmx]

Moin Frank,

GA soll bei Sonnenaufgang plus 1h und 1h vor Sonnenuntergang schalten.

wir hatten von Marc hier schonmal das Thema.

Elevation und Azimuth sind vor allem für Beschattung ohne Lichtmessung wichtig.

Wenn Du eine Lichtmessung außen hast, ist das sicher die beste Variante. Du solltest aber hier eine Plausibilitätsprüfung machen: Nicht, das da einer Deinen Lichtmesser mit der Taschenlampe anleuchtet und nachts um 1:20 gehen alle Rolläden hoch, weil es ja hell ist

Gruß,
Bernd

[Tessi]

Was meinst du denn mit den 20%?

Ich meinte mit 20% den Zeitunterschied, den die Zeitdifferenz zwischen zwei Elevationswinkeln an unterschiedlichen Tagen im Jahr hat. Also das beispielsweise die Zeit zwischen Sonne auf 0° und Sonne auf +9° über das Jahr gesehen um maximal 20% schwankt.
Allerdings habe ich dabei die falschen Tage verglichen, tatsächlich sind es in unseren Breiten mehr, um die 30% wenn man den Quotienten aus kürzester Zeit und längster Zeit bildet, über 40%, wenn man den Quotienten aus längster Zeit und kürzester Zeit bildet...
Also irgendwie nicht sehr aussagefähig...
Vergesst das einfach.

Die Elevation braucht doch auch das Datum, um den Winkel zu berechnen?!
Meinst du man berechnet Elevation selbständig und rechnet dann auf die Zeit um und umgekehrt?

Ich meine, solange ich die fertigen Funktionen des EibPCs verwende, brauche ich mich um Datum und Koordinaten nicht zu kümmern, egal ob ich nun elevation() oder sunrisehour() und sunriseminute() verwende.
Will ich aber berechnen, wie viele Minuten heute die Sonne für den Weg von z.B. -9° bis 0° braucht, oder wie viel Grad unter dem Horizont sie heute z.B. 30min vor Sonnenaufgang steht, dann muss ich die Funktion dafür selbst codieren und alle notwendigen Parameter zur Verfügung stellen. Viel Aufwand gegenüber der Nutzung der schon vorhandenen Funktionen.
Ich habe das nur angemerkt, weil die Nutzung von elevation() einfacher ist, als die Berechnung von Sonnenaufgang - 30min, und es kurz mal angesprochen wurde, wie man denn von einer gewünschten Zeit auf die Elevation kommt. Das aber wäre ein unsinniger Weg, weil das wesentlich aufwändiger zu berechnen ist, als mit Hilfe von sunrisehour() und sunriseminute() den Zeitpunkt 30min vor Sonnenaufgang zu bestimmen.

Das bei Fragen der Helligkeit besser elevation() als irgendwelche Zeitfunktionen verwendet werden, wurde nun ja schon geklärt, ebenso, das das Wetter einen großen Einfluß auf die tatsächliche Helligkeit hat, und daher eine Lichtmessung am ehesten das Gewünschte leistet, diese zur Sicherheit gegen Fremdlicht aber über die Zeit/Elevation plausibilisiert werden sollte.

[saft6luck]

Ich habe das nur angemerkt, weil die Nutzung von elevation() einfacher ist, als die Berechnung von Sonnenaufgang - 30min, und es kurz mal angesprochen wurde, wie man denn von einer gewünschten Zeit auf die Elevation kommt. Das aber wäre ein unsinniger Weg, weil das wesentlich aufwändiger zu berechnen ist, als mit Hilfe von sunrisehour() und sunriseminute() den Zeitpunkt 30min vor Sonnenaufgang zu bestimmen.

Yep, dann hatte ich dich schon richtig verstanden.

[saft6luck]

Hoi

Wir haben beide nicht recht:
Wikipedia: Dämmerung

Hm, ok, hast recht ... aber im Winter ist sie in unseren Breiten etwas kürzer als im Sommer

[Tessi]

Und genau dadurch bin ich auf die falschen 20% gekommen...

[frankthegreat]

Nachschlag

So, habe die Sache jetzt mal mit dem Code von Tessi 2 Tage getestet.
Funktioniert super, sowohl mit versch. Zeiten vorher als auch nachher.
Die Zeiten sind einfach zu ändern. Genauso hab ich mir das vorgestellt.

Grüße Frank

[Tessi]

Der Code war nicht getestet, sondern nur als Konzept aufgeschrieben...
Das der auf Anhieb funktioniert hat...

Nur so aus Neugier: Welche Version hast Du den genommen (also welche ist jetzt getestet), die mit Stunden und Minuten oder die nur mit Minuten?


Nachtrag:
ich habe im Code htime() verwendet, das funktioniert normalerweise, aber nicht garantiert immer, daher wird meist die Verwendung von chtime() empfohlen. Dann sollte man den aber Code so erweitern:
[highlight=epc]
// Sonnenaufgang
...
if (chtime(Einschaltstunde, Einschaltminute, 00) and !chtime(Ausschaltstunde, Ausschaltminute, 00)) then ...

//Sonnenuntergang
...
if (!chtime(Einschaltstunde, Einschaltminute, 00) or chtime(Ausschaltstunde, Ausschaltminute, 00)) then ...
[/highlight]
Würde man es so lassen:
[highlight=epc]
// Sonnenaufgang
...
if chtime(Einschaltstunde, Einschaltminute, 00) then ...

//Sonnenuntergang
...
if chtime(Ausschaltstunde, Ausschaltminute, 00) then ...
[/highlight]
könnten bei einem Neustart zu später Stunde beide Bedingungen gleichzeitig wahr werden und triggern und das ist nicht erwünscht.
(Vor allem weiß ich nicht in welcher Reihenfolge die then-Zweige dann ausgeführt werden.)

[frankthegreat]

Ich hab die nur mit den Minuten genommen.
Dein Pech natürlich, das du mich jetzt ständig an der Backe hast wenn ich wieder mal ein paar Tipps brauche.

Gruß Frank

[Tessi]

Ich glaube, damit kann ich leben, so wie Du aber damit wirst leben müssen, das ich manchmal längere Zeit keine Gelegenheit finde, hier Beiträge zu schreiben.