Startzeit an die Jahreszeiten anpassen

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hatte das nicht erst später integrieren wollen und so die Grundlagen schon einmal geschaffen, auch die Anpassungen wegen der leichten Verschiebungen

Das Array müßte man nach diesem Muster weiter befüllen


Gruß

 

[Thruser]

Hallo,

Was rechnet ihr da? Fällt das schon in den Bereich "persönliche Gewohnheiten"?
Ich habe noch gar nicht verstanden, wie die Überleitung von den Jahreszeiten zu den Rollladen-Aktionen unter Berücksichtigung der persönlichen Gewohnheiten im einzelnen aussehen soll. :-(

ich bin der Meinung das war die ursprüngliche Frage. Etwas ähnliches hattest Du doch schon mit deinem Exceldiagramm gemacht. Es ging nur, glaube ich nicht direkt um den Sonnenuntergang, sondern wann die Rolläden herunterfahren sollen.

@Ratoncito
sag mal was Du noch verstehst, und wo Du dann Probleme hast

Gruß

 

[Ratoncito]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Thruser,

ja, nicht schlecht. So ähnlich hätte ich es auch gelöst - viel besser hätte ich es auch nicht hinbekommen.

Spaß beiseite. das ist genial. Ich sitze immer noch mit weit aufgerissen Augen und heruntergefallener Kinnlade vor dem PC und starre ungläubig auf die wenigen Zeilen Code.

Ich werde den Zauberkasten erst mal einbauen und verwenden. Anschließend noch meine restlichen Problemchen und Sonderwünsche lösen.

Anschließend werde ich das Ding mal auseinanderbröseln und hoffe es ein wenig mehr zu verstehen.


Vielen lieben Dank!!!

Ich wünsche allen ein schönes Wochenende

 

[Ratoncito]

Hallo,

nun habe ich das Ding ein wenig aufgebröselt und schon die erste Frage.

iTageSeit01 := FuDaysSinceJan01(DT_TO_DATE(dtZeit));
iTageJahr := FuNumDaysYear(DT_TO_DATE(dtZeit));

rX := SIN(INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1])/INT_TO_REAL(iTageJahr)*2.0*3.1415);

//y = (y2-y1)/(x2-x1)(x-x1)+y1
tdSchaltzeitMorgens := REAL_TO_TOD((TOD_TO_REAL(tdMorgensMin)-TOD_TO_REAL( tdMorgensMax))/INT_TO_REAL(1-(-1))*(rX-INT_TO_REAL(-1))+TOD_TO_REAL(tdMorgensMAX));

tdSchaltzeitAbends := REAL_TO_TOD((TOD_TO_REAL(tdAbendsMax)-TOD_TO_REAL(tdAbendsMin))/INT_TO_REAL(1-(-1))*(rX-INT_TO_REAL(-1))+TOD_TO_REAL(tdAbendsMin));

FuRolladenUnten := (DT_TO_TOD(dtZeit) <= tdSchaltzeitMorgens) OR (DT_TO_TOD(dtZeit) >= tdSchaltzeitAbends);

Außer in der Zeile

rX := SIN(INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1])/INT_TO_REAL(iTageJahr)*2.0*3.1415);

wird Array aDatum doch nirgendwo mehr aufgerufen, und immer nur der erste Wert (78 bzw 79) zum verschieben des Nulldurchgang der Sinuskurve verwendet.

Das teilweise Verschieben der Null- und Scheitelpunkte um 1 Tag spielt absolut keine Rolle. Daher könnte man doch die Zeile so ändern.

rX_WR := SIN(INT_TO_REAL(iTageSeit01-78)/INT_TO_REAL(iTageJahr)*2.0*3.1415);

Dann entfällt der Array und müsste nicht gepflegt werden.

Wenn das so richtig ist und nicht irgendwo von mir nicht erkannte Probleme verursacht werden, würde ich den Code abändern.

 

[Thruser]

Hallo,

das ist richtig.

Frage ist, ob Du extra für ein Schaltjahr auch noch durch 366 Tage teilst oder ob Dir das auch egal ist und 365 Tage reichen. Dann könntest Du INT_TO_REAL(iTageJahr) auch noch durch 365.0 ersetzen.

Gruß

 

[Ratoncito]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

vielen Dank für die Antwort.
INT_TO_REAL(iTageJahr) habe ich erkannt, lasse ich drin. Muss ja nicht gepflegt werden.

Nächstes Problem

//rX := SIN(INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1])/INT_TO_REAL(iTageJahr)*2.0*3.1415);
rx_W := SIN(INT_TO_REAL(iTageSeit01-78)/INT_TO_REAL(iTageJahr)*2.0*3.1415);
Wrx := SIN((W)/W1);
//W := INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1]);
W := INT_TO_REAL(iTageSeit01-78);
W1 := INT_TO_REAL(iTageJahr)*2.0*3.1415;

Die ursprüngliche Berechnung von rX habe ich umbenannt in rX_W, und zum Testen in die Berechnung eingefügt, das scheint ok zu sein.

Die einzelnen Teile der Formel habe ich umbenannt und einzeln ausgeführt, die Werte sind meiner Meinung nach richtig, trotzdem liefert die Zeile mit der Berechnung Wrx ein anderes Ergebnis als rX_W.

Was ist da los?

 

[Thruser]

Hallo,

nur INT_TO_REAL(iTageJahr) muß in den Nenner bei der Division.

Entweder so

W1 := INT_TO_REAL(iTageJahr)/(2.0*3.1415);

oder

W1 := 2.0*3.1415/INT_TO_REAL(iTageJahr);
Wrx := SIN((W)*W1);

Gruß

 

[Ratoncito]

Hallo,

da war mein mathematisches Weltbild ein wenig durcheinander geraten.

W := INT_TO_REAL(iTageSeit01-78);
W1 := INT_TO_REAL(iTageJahr)

Wrx := SIN((W/W1)*2.0*3.1415);

Irgendwie habe ich die äußere Klammer immer wieder übersehen. Nun passt es wieder. Irgendwas ist wohl eingerostet, oder ich hatte ein ganz dickes Brett vor dem Kopf
Den Rest lasse ich besser mal für eine Weile liegen, habe eh noch viele andere Dinge zu erledigen - muss da was entrosten.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich melde mich hier mal ganz zaghaft wieder, obwohl ihr beide mich ganz schön "abgehängt" habt (besser gesagt, ich habe mich abhängen lassen, weil ich nicht so schnell bin).

Ich habe angefangen, mal mit konkreten Zahlen (Datum+Uhrzeit) für diverse Solstitien und Äquinoktien einiger Jahre zu experimentieren.
Im Moment habe ich den Eindruck, dass man keinen Unterschied machen muss zwischen SchaltJahr und Nicht-SchaltJahr, vorausgesetzt man rechnet grundsätzlich mit 365.2422 Tagen pro Jahr und nimmt immer das Datum und die Uhrzeit des FrühlingsAnfangs des aktuellen Jahres als NullPunkt der SinusSchwingung. Und das scheint mir auch sehr naheliegend und logisch zu sein.
Ich verstehe nicht, warum eine Tabelle mit den Daten bessere Ergebnisse liefern sollte.
Einmal im Jahr den Wert (Datum + Uhrzeit) für den FrühlingsAnfang des aktuellen Jahres eingeben und bis dahin (notfalls) einfach mit dem Wert des VorJahres (oder VorVorJahres, oder ...) weiterarbeiten finde ich gar nicht so schlimm.

Gruss, Heinileini

 

[Thruser]

Hallo,

es kommt immer darauf an, wie genau man das haben will Bei den ersten Test mit Excel kam ich nie genau auf sin(x) = 1 bzw. -1

Das jeweilige Datum für Frühlings-, Sommer-, Herbst- und Winteranfang ist jedes Jahr etwas anders. Selbst wenn der Frühlingsanfang immer der 20. März wäre, ist das in einem Schaltjahr ein Tag mehr seit dem 1. Januar.

Nun kommt dazu das diese Tage sehr markante Termine im Kalender sind. Da könnte man den Anspruch haben, daß zu diesen Daten, zumindest Sommer- und Winteranfang, die Schaltpunkte auch genau zu den angegeben Zeiten sind, also z.B. 19:45 Uhr und 22:00 Uhr. Durch die ganzen kleine Ungenauigkeiten erreicht man diese Werte aber nicht. Nur der Frühlingsanfang stimmt, da der als Bezugspunkt gewählt wurde . Das könnte man jetzt etwas korrigieren wenn man das Jahr in vier Abschnitte teilt und mit Sinus, Cosinus, -Sinus und -Cosinus rechnet, wie weiter oben schon beschrieben.
Als Umschaltpunkte sollte man die Mitte zwischen den vier Daten wählen.
Jetzt könnte man das natürlich alles dynamisch berechnen lassen, auch wann jeweils Frühlingsanfang, Sommeranfang, etc. sind, oder man berechnet das einmal für einen bestimmten Zeitraum vor und erstellt eine Tabelle in die man die ganzen Daten einträgt.

Meine Tabelle oben ist dahingehend auch noch nicht vollständig umgesetzt. Hatte es nur vorbereitet und dann erst einmal das notwendigste implementiert zur Demonstration.

Ich habe mir jetzt noch nicht die Mühe gemacht und mal nachgerechnet wie groß die Abweichungen sind. Die Anzahl der Tage hatte ich auch nur schnell durch Excel berechnet und nicht noch einmal verifiziert ob die Funktion dieselbe Anzahl an Tagen seit dem 1.1. berechnet.

Gruß

 

[Ratoncito]

Hallo zusammen,

darf ich Euch ein wenig bremsen? Es geht nur darum, das Öffnen und Schließen einiger Rolläden in etwa an die Helligkeit bzw. die damit einhergehenden Gewohnheiten anzupassen. Ob sich da irgendetwas um ein paar Tage verschiebt oder nicht...

Wenn man bei der Berechnung berücksichtigt, ob das Jahr 365 oder 366 Tage hat, halte ich das schon für Luxus. Und ob die Scheitel- bzw Nullpunkte mit den meterologischen Ereignissen genau zusammenpasst ist auch egal. An den Tagen um die Scheitelpunkte liegt die Änderung der Schaltzeiten eh in einem Bereich den man nicht wirklich warnimmt.

Ich halte es für eine sehr komfortable und elegante Lösung die ich so nicht erwartet hatte. Ich muss mich nur noch mal mit dem zweiten Teil der Berechnung beschäftigen...

Noch mal vielen Dank für Eure Bemühungen.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei den ersten Test mit Excel kam ich nie genau auf sin(x) = 1 bzw. -1

Das ist aber kein Problem von Excel sondern etwas allgemeinerer Natur, wenn man mit solchen Zahlen arbeitet. Wenn man alles "zu Fuss" rechnen müsste, käme man sicherlich schneller auf die Idee, zu runden.

darf ich Euch ein wenig bremsen?

NEIN!!!



So, jetzt darfst Du bremsen!
Habe durch Verschiebung des FrühlingsAnfangs um ca. 1,9 Tage in Richtung SommerAnfang erreicht, dass der Herbst ca. 1,9 Tage zu früh anfängt und der Sommer nur noch ca. einen halben Tag zu spät und der Winter nur noch ca. einen halben Tag zu früh. Ganz ohne Tabelle (die habe ich in Excel nur gebraucht, um Theorie und Praxis zu vergleichen), nicht wirklich genau aber recht ausgewogen, finde ich.
Für mich wäre das jetzt die Lösung, mit der ich leben könnte, ohne übertriebene Erwartungen an die Präzision der Äquinoktien-"Datümer".
Jetzt bremse ich auch.

Gruss, Heinileini

 

[ms4wago]

Hallo Zusammen,

hier mal kurz wie ich das ganze mache. Vielleicht ist es ja für den einen oder anderen eine Anregung:

Also ich fahre meine Raffstore und Rolladen ausschließlich nur noch über Sonnenwinkel. Damit habe ich Sommer wie Winter sehr gute Erfahrungen gemacht. So fahren bei mir zum Beispiel im Wohnbereich die Jalousien auf wenn: "Winkel Sonnenaufgang minus 3 Grad", und wieder zu wenn: "Winkel Sonnenuntergang minus 4,5 Grad" ist. Zwischendrin fahre ich je nach Sonnenhöhe und -Richtung unterschiedliche Zwischenpositionen an.

Mit der reinen Uhrzeit von Sonnenaufgang und Sonnenuntergang habe ich über das Jahr gesehen auch keine guten Erfahrungen gemacht

Gruß, Martin

 

[Blockmove]

Hallo Zusammen,

hier mal kurz wie ich das ganze mache. Vielleicht ist es ja für den einen oder anderen eine Anregung:

Also ich fahre meine Raffstore und Rolladen ausschließlich nur noch über Sonnenwinkel. Damit habe ich Sommer wie Winter sehr gute Erfahrungen gemacht. So fahren bei mir zum Beispiel im Wohnbereich die Jalousien auf wenn: "Winkel Sonnenaufgang minus 3 Grad", und wieder zu wenn: "Winkel Sonnenuntergang minus 4,5 Grad" ist. Zwischendrin fahre ich je nach Sonnenhöhe und -Richtung unterschiedliche Zwischenpositionen an.

Mit der reinen Uhrzeit von Sonnenaufgang und Sonnenuntergang habe ich über das Jahr gesehen auch keine guten Erfahrungen gemacht

Gruß, Martin

Sehr guter Ansatz, muss ich mal testen.
Kommt funktionell wahrscheinlich ziemlich aufs Gleiche raus wie die Funktion von Heini und Wolfgang

 

[ms4wago]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ergänzend muss ich vielleicht noch dazu sagen: Ich mache nur die Grundparametrierung über die Winkelangabe und diese rechne ich dann in eine Uhrzeit um. Somit habe ich zum Einem eine Übersicht wann was fährt und zum Anderen kann ich noch eingreifen und die Zeiten korrigieren (z.B.: im Sommer nicht vor 6 Uhr fahren oder nicht kurz hintereinander fahren). Zudem berücksichtige ich noch so Dinge wie Online-Wetter, Raumtemperatur, Außentemperatur, Lichtstatus im Raum, offene Fenster,...

 

[Blockmove]

Ergänzend muss ich vielleicht noch dazu sagen: Ich mache nur die Grundparametrierung über die Winkelangabe und diese rechne ich dann in eine Uhrzeit um.

Kannst du bitte den Code zur Umrechnung Sonnenwinkel -> Uhrzeit online stellen.
Vielen Dank und Guten Rutsch

Gruß
Blockmove

 

[ms4wago]

Eine Formel für die Umrechnung von Sonnenwinkel zu Uhrzeit habe ich leider nicht gefunden. Deshalb gehe ich den Umweg über je eine Zuordnungsliste Winkel zu Zeit für die steigende Sonnenhöhe, die fallende Sonnenhöhe und die Richtung. Dies erstreckt sich bei mir allerdings über mehrere Programme und Funktion.

Bei Bedarf und Gelegenheit kann ich ja mal versuchen dies halbwegs verständlich zusammen zu stellen

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine Formel für die Umrechnung von Sonnenwinkel zu Uhrzeit habe ich leider nicht gefunden. Deshalb gehe ich den Umweg über je eine Zuordnungsliste Winkel zu Zeit für die steigende Sonnenhöhe, die fallende Sonnenhöhe und die Richtung. Dies erstreckt sich bei mir allerdings über mehrere Programme und Funktion.

Bei Bedarf und Gelegenheit kann ich ja mal versuchen dies halbwegs verständlich zusammen zu stellen

Mir ist eingefallen, dass es in der Oscat-Lib einen Baustein Sun_Pos gibt.



Werd ich mal bei Gelegenheit testen.

 

[ms4wago]

Mit der Funktion kannst du aber auch nicht von Winkel auf die Uhrzeit zurück rechnen. Dafür müsstest du schon die Formel in der Funktion umstellen

 

[Blockmove]

Mit der Funktion kannst du aber auch nicht von Winkel auf die Uhrzeit zurück rechnen. Dafür müsstest du schon die Formel in der Funktion umstellen

Ich hatte die Sonnenstandsberechnung mal vor vielen Jahren bei einem 841-Controller im Einsatz.
Da frass das Ding heftig Zykluszeit. Deshalb hab ich sie einmal täglich nachts um 1:30 aufgerufen und mir die entsprechenden Daten berechnet.
Mal schauen wie es jetzt auf dem PFC100 aussieht.
Evtl. geht da ein zyklischer Aufruf.
Die Uhrzeit brauch ich nicht. Es reicht ja Vergleich des Winkels.