[Featurewunsch] sunset... und sunrise... des nächsten Tages

[saft6luck]

Hallo Michael,

dank der neuen Funktionen läuft die Sonnenauf- und -untergangsanzeige nun schon ein paar Tage. Da hätte ich allerdings gleich noch einen Verbesserungsvorschlag. Da die Daten nur alle 5 Minuten berechnet werde, ist es evtl. keine Kleinigkeit ...

Problem:
Momentan stellen sunset...() und sunrise...() "nur" die entsprechenden Daten des aktuellen Tages zur Verfügung.

Änderungswunsch:
Die entsprechenden Daten für den nächsten Tag sollten auch auswählbar sein.

Priorität:
niedrig

Hintergrund:
Für die Anzeige von Sonnenaufgangs- und Sonnenuntergangszeit verwende ich den eibPC Da die entsprechenden Zeitfunktionen Daten des aktuellen Tages liefern, ändert sich die entsprechende Anzeige frühestens um Mitternacht auf die Daten des nächsten bzw. neuen Tages.

Die Anzeige soll aber schon am Abend die Zeiten für den nächsten Tag darstellen, da ich nicht immer bis Mitternacht wach bin.

Wenn die Funktionen, z.B. über einen Parameter bestimmt, auch die Daten für den nächsten Tag liefern können, kann ich schon kurz nach Sonnenaufgang bzw. -untergang die Daten aktualisieren.

Workaround hätte ich auch:
Umständlich: Man könnte alle Zeitfunktionen stoppen (Freigabevariable), die Zeit umstellen, 5 Minuten warten, die Daten in die GAs schreiben und die richtige Zeit wieder einstellen. Gibt es evtl. eine einfachere Alternative?

[bmx]

Gibt es evtl. eine einfachere Alternative?

Ja. Hier die Formeln umsetzen in den EibPC (sin+cos im EibPC unterstützt?) und einfach den nächsten Tag nehmen.

Alternativ: Bei einem Standort sind die Unterschiede von einem auf den nächsten Tag minimal. Nimm einfach mal für Deinen Standort die Differenz von einem auf den anderen Tag je Tag. Und dann bastelst Du Dir eine Formel, die abhängig vom Datum ein wenig dazuaddiert oder abzieht. Fertig ist die Laube.

Je nachdem in welcher Höhe ü.NN. Du Dich befindest, stimmt die Zeit nämlich sowieso nicht exakt.

Mut zum Fehler ;-)

Gruß,
Bernd

[saft6luck]

...

Danke für den Tip. Manchmal sieht man einfach den Wald vor lauter Bäumen nicht.

[Tessi]

Die Formel ist schon etwas aufwendiger und trotzdem nicht sonderlich genau, wobei ich nicht weiß, wie genau die des EibPCs ist. Daher dürfte die Methode morgen=2*heute-gestern auch nicht ungenauer sein, aber deutlich einfacher zu implementieren.

PS: Wie kann ich den den EibPC seine Systemzeit per Programm verstellen lassen? Soweit ich das sehe, funktioniert der entsprechende Befehl nur mit einer 3-Byte-GA und genau diesen Typ kann der EibPC nur aus seiner Uhr auslesen, aber nicht manipulieren. Ich habe da noch keinen Weg gefunden.

[enertegus]

PS: Wie kann ich den den EibPC seine Systemzeit per Programm verstellen lassen? Soweit ich das sehe, funktioniert der entsprechende Befehl nur mit einer 3-Byte-GA und genau diesen Typ kann der EibPC nur aus seiner Uhr auslesen, aber nicht manipulieren. Ich habe da noch keinen Weg gefunden.

Das geht nicht, ich habe es aber als Feature aufgeommen.

[saft6luck]

Daher dürfte die Methode morgen=2*heute-gestern auch nicht ungenauer sein, aber deutlich einfacher zu implementieren.

Ja, das klingt einfach, allerdings ...

1. Die Berechnung des Sonnenstandes ist Jahreszeitabhängig, d.h. die Unterschiede werden von einer Sonnenwende zur nächsten erst größer, dann wieder kleiner, ähnlich einer Sinus Funktion. Auch eine entsprechend vereinfachte Formel richtig im eibPC zu implementieren ist eine nicht ganz triviale Aufgabe, da ich also die Sonnenwenden (entweder über das Datum oder das Vorzeichen der Differenz) und die ganzen Überläufe, da ich mit der Uhrzeit nicht rechnen kann, sondern nur mit Stunden/Minuten, beachten muss. Trotzdem ist das einfacher, als die richtige Formel für die Sonnenstansberechnung, da hast du sicher recht.

2. Ich verwende den Sonnenstand um die helligkeitsabhängige Schaltung einiger BWMs zu de-/aktivieren (die blöden Dinger checken das Kunstlicht nicht). Wenn ich hierfür eine Funktion des eibPCs verwende, eben sun(), dann macht es wenig Sinn, die Anzeige des Wertes nur zu schätzen.

[Tessi]

1. Ja, aber der Unterschied der Differenzen von gestern zu heute und von heute zu morgen ist selbst zur Zeit der größten Änderungsgeschwindigkeit nicht so groß als das witterungsabhängige Einflüsse nicht bedeutsamer währen. Der Fehler dürfte kleiner als eine Minute sein - ich habe das jetzt nicht genau nachgeprüft, aber der Unterschied in der Zeit von einen Tag auf den anderen liegt unter 3 Minuten, der Unterschied zwischen zwei aufeianderfolgenden Unterschieden ist deutlich kleiner. Da eh nur auf die Minute genau gerechnet wird, dürfte der Fehler nicht wirklich bedeutsam sein. Außer vielleicht für Astronomen.

[saft6luck]

1. Ja, aber der Unterschied der Differenzen von gestern zu heute und von heute zu morgen ist
...
der Fehler nicht wirklich bedeutsam sein. Außer vielleicht für Astronomen.

Selbst wenn es so wäre, ändert das doch nichts an meiner Aussage.
Wenn du einen eibPC hast, versuch deinen Ansatz doch einmal umzusetzen.

Ps. Wenn möglich würde ich gerne die Zeit, die sun() verwendet auch in der Anzeige sehen.

[anlo007]

Warum arbeitst du nicht mit elevation()? Sonnenaufgang müßte doch eigendlich elevation =0 sein.

[saft6luck]

Warum arbeitst du nicht mit elevation()? Sonnenaufgang müßte doch eigendlich elevation =0 sein.

Hm, elevation() gibt mir den Sonnenstand vom aktuellen Zeitpunkt, sprich ich kann auf den Sonnenstand des Sonnenaufgangs warten.

Aber ist das besser als sun()? Ich glaube es wird noch umständlicher, das dann auf den nächsten Tag zu mappen oder übersehe ich da was?

[enertegus]

Hm, elevation() gibt mir den Sonnenstand vom aktuellen Zeitpunkt, sprich ich kann auf den Sonnenstand des Sonnenaufgangs warten.

Man müsste eben nicht auf 0 sondern auf das Inkrement der Sonnenverstellung zum nächsten Tag warten. Und das das doch sin(x) Funktionen sind, und die Taylorreihenentwicklung der sin-Funktion um den Nullpunkt in sehr guter Näherung mit der linearean Approximation übereinstimmt, könnte man hier schon extrem genau die Zeit finden.

[saft6luck]

Man müsste eben nicht auf 0 sondern auf das Inkrement der Sonnenverstellung zum nächsten Tag warten. Und das das doch sin(x) Funktionen sind, und die Taylorreihenentwicklung der sin-Funktion um den Nullpunkt in sehr guter Näherung mit der linearean Approximation übereinstimmt, könnte man hier schon extrem genau die Zeit finden.

D.h. du willst den optionalen Parameter als Datum. Eigentlich dachte ich ja nur an "Morgen". Aber wie berechnet man "den nächsten Tag"?

Führt zum nächsten Featurewunsch:
Rechnen mit den Datentypen "Datum", "Zeit" und "Datum und Zeit" (ist übrigens y64 und nicht y24) inkl. Convert() (Wochentag nicht vergessen!), Increment(), Decrement(), GetHour(),GetMinute(), GetYear(), etc. etc..

Evtl. ist es für dich ja einfacher erst einmal nur "Morgen" zu implementieren, oder?