Dates, use Datetime consistently

[drbacke]

Aktuell wird als Input immer Lokalzeit angenommen und als Output 0-48 Werte ausgegeben (von 0:00 bis 2 Tage in die Zukunft. Hier sollte man die Zeitinfos komplett übergeben und durchschleifen. Zudem prüfen, ob alles zusammenpasst.

[sandboxcode]

Ich kommentiere mal im Sinne von "needs clarification".

Im Grund genommen gehört zu der Einbindung von Datum & Zeit abweichend von Lokalzeit ja auch die Location für die simuliert werden soll. Hier könnte man als Basis erstmal über Timezones arbeiten, welche als ENV-Variable definiert werden sollte (z.B. mit Nutzung von pytz & die schönere Github Docu)

Etwas komplexer zu lösen, aber aus meiner Sicht langfristig noch sinnvoller, wäre es, wenn wir eine Ortsangabe zulassen. Zum Beispiel per Länge und Breitengrad.

Freue mich auf euer Feedback!

[Lasall]

Aus aktuellem Anlass, da es zur Zeit einen Bug am Sommerzeitwechseltag gibt (bei der Visualisierung wird die Zeitachse manchmal am Wechseltag um eins verringert #185), würde ich Folgendes vorschlagen:

Beim Input akzeptieren wir Startzeit (insb. inkl. Stunde) und bei der Simulation arbeiten wir nur mit t0 (Startzeit) bis tn (n = prediction hours), also bei der Simulation arbeiten wir nur mit relativen Stunden. Selbst wenn wir das später vielleicht mal erweitern wollen, um z.B. manche Vorgänge zu bestrafen, wenn sie zu bestimmten Uhrzeiten ausgeführt würden, könnte man das ja beim Verarbeiten des Inputs in relative Stunden rechnen.
Bei der Ausgabe könnte man (wie hier ursprünglich beschrieben) dann wieder die relative Zeit in ein Datum umrechnen.

Wenn wir intern nur relativ arbeiten, reduzieren wir Probleme mit einem echten Datum (Zeitzonen, Sommerzeit) nur auf initiale und finale Umrechnung, sind also bei der Optimierung frei von möglichen Datumfehlern.

Ich habe mir das schon etwas angeschaut, wollte aber nochmal Feedback bekommen, da das Verhalten momentan etwas anders ist: Z.B. wenn start_hour = 10 und prediction_hours = 48, dann wird nur eine Vorhersage für 48-10=38 Stunden ermittelt. Wenn ich das entkoppeln würde, dann würde man heute 10 Uhr anfangen und weiterhin 48h Vorhersage bekommen (entsprechend erwartet man dann beim Input auch Werte relativ zum Startdatum).

[NormannK]

Grundsätzlich finde ich das einen guten Ansatz.
Welchen praktischen Grund gibt es eigentlich mit einer anderen Startzeit zu arbeiten als 0?
Aber ich sehe auch keinen Anwendungsfall mehr oder weniger als die 48h voraus zu berechnen, oder?

[b0661]

Wenn wir intern nur relativ arbeiten, reduzieren wir Probleme mit einem echten Datum (Zeitzonen, Sommerzeit) nur auf initiale und finale Umrechnung, sind also bei der Optimierung frei von möglichen Datumfehlern.

Einige Vorhersagen gibt es nur absolut (z.B. pro Tag auf Stundenbasis) und nicht relativ zum jetzigen Optimierungsstart. Man müsste bei der Umwandlung in relative Zeiten vor jedem Optimierungslauf wieder eine Anpassung vornehmen und evtl. fehlende Werte zu 48 Werten mit geeigneten Ersatzwerten pauschal ersetzen.

Ich finde da die grundsätzliche Verwendung von Wertereihen bei denen die einzelnen Werte mit einem Zeitstempel (Datum, Uhrzeit, Zeitzone) versehen sind einfacher.

Das Anfügen von neuen Werten oder der Austausch bestehender Werte ist damit m.E. besser möglich. Fehlende Werte sind sofort erkennbar und können von der Optimierungsmethode passend zur Methode ergänzt werden. Das Filtern auf gültige Werte (der passende Zeitraum für die Optimierung) aus einer evtl. gecachten längeren Wertereihe ist ohne komplizierte Umrechnungen möglich. Auch die Interpolation von Zwischenwerten, falls diese benötigt werden, hängt nicht am starren Einstundenraster.

[sandboxcode]

Wir werden nicht darum herum kommen mit Zeitzonen zu arbeiten. Ich habe da in mehreren Projekten gerne mit pytz gearbeitet.
Davon ausgehend kann selbstverständlich völlig frei mit relativen oder absoluten Zeiten gearbeitet werden.
Üblicherweise wird im Docker-Compose oder in den Einstellungen der Applikation die Zeitzone fix bzw. änderbar definiert (default ist dann häufig einfach UTC).

[NormannK]

Das klingt also für mich so, als wenn wir ein Objekt erzeugen sollten, das ein volles Datum bis Stundenebene entsprechend pytz enthält, zu den dann jeweils die einzelnen Werte zugeordnet werden können.
Das Objekt würde dann mit den Daten befüllt die wir haben und am Ende auch die Ergebnisse enthalten.
In der Config müsste man dann seine Zeitzone einstellen und wenn man die Simulation starten will, fordert man now()+Zeitdauer in h an.
Wenn man mit start_hour arbeiten möchte, erzeugt das aus meiner Sicht jede menge Probleme. z.B. den Soc vom PV akku oder Auto den ich übermittle ist von genau jetzt und nicht erst in start_hour. Man müsste eine bereits berechnete Simulation verwenden um den zustand der Geräte bei start_hour zu ermitteln was dann als Eingangswert funktioniert.
Aber wieso der Aufwand, wenn man einfach gleich ab now() simuliert.
Sehe ich das falsch?

[b0661]

Ich verstehe das Problem nicht. Eine Simulation muss die Werte zusammensammeln die sie für das Simulieren benötigt (Temperaturvorhersage, Ertragsvorhersage, Lastvorhersage, ...). Diese Vorhersagewerte benötigt sie ab Simulationsbeginn. Deswegen sollten diese Vorhersagen so abgelegt sein, dass man leicht ermitteln kann welche Werte denn ab Simulationsbeginn gelten. Vorhersagen werden ja nicht unbedingt bei zu jedem Simulationsbeginn neu erzeugt. Für diese Werte bietet sich deswegen m.E. an sie mit einem Zeitstempel versehen parat zu haben. Das gleiche gilt für historische Daten (Temperaturverlauf der letzten Stunden, SoC Verlauf, ...). Die Simulation erzeugt dann auf Basis dieser Vorhersagen und von Startwerten ein Optimerungsergebnis dessen Daten selbst wieder Zeitstempel enthalten (Spülmaschine anschalten heute um 12:00 Uhr, UTC +2.00).

Was hat das mit Simulationsbeginn now() oder start_hour() zu tun?

War die Frage nicht ob alle Daten (Vorhersagen, Optimierungsergebnis) relativ zum Simulationsbeginn in 48 Werte-Reihen verwaltet werden sollen? Also Ertragsvorhersage zu Simulationsbeginn, +1h, +2h, ... -> Spülmaschine anschalten 6 Stunden nach Simulationsbeginn.

[Lasall]

Partly done in feature/config-overhaul (providers handle datetime correctly, optimization still uses relative hours)