76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

...
Ich hoffe das ist jetzt noch etwas klarer geworden.

Ja! Ganz lieben Dank! Stand wirklich auf dem Schlauch! Künftig wird das anderen wohl auch nicht mehr passieren, wenn Du das Reading - wie in Deinen Überlegungen oben beschrieben - umbenennen wirst.

Eine Sache beschäftigt mich noch: Um ein Herabregeln der Anlage zu vermeiden, müsste man eigentlich abends die Ladung dann aussetzen, wenn - gemäß Forecast - die BAT so voll ist, dass man über die Nacht kommt und morgens einen minimalen SOC (mit einer auf Basis von Unsicherheiten zu bestimmenden Reserve) nicht unterschreitet. Neben dem oberen SOC sollte, damit das BAT-System gelegentlich auch mal die untere Grenze sieht (wichtig für dessen SOC-Kalibration), auch der BAT-Zustand "leer" hin und wieder mal erreicht werden. Wie würdest Du das auf Basis der aktuell verfügbaren SF-Readings angehen?

PS[1]: Damit ich beim gelegentlich notwendigen Anfahren des unteren SOCs niemals in einem Zustand der Energielosigkeit bin, hatte ich mich daher seinerzeit für eine aus zwei BATs bestehenden Konfiguration entschieden.
PS[2]: Eine "Emergency Ladung" wird eigentlich stets vom BAT-System ausgelöst.

[DS_Starter]

Eine Sache beschäftigt mich noch: Um ein Herabregeln der Anlage zu vermeiden, müsste man eigentlich abends die Ladung dann aussetzen, wenn - gemäß Forecast - die BAT so voll ist, dass man über die Nacht kommt und morgens einen minimalen SOC (mit einer auf Basis von Unsicherheiten zu bestimmenden Reserve) nicht unterschreitet. Neben dem oberen SOC sollte, damit das BAT-System gelegentlich auch mal die untere Grenze sieht (wichtig für dessen SOC-Kalibration), auch der BAT-Zustand "leer" hin und wieder mal erreicht werden. Wie würdest Du das auf Basis der aktuell verfügbaren SF-Readings angehen?

Ja, das ist noch ein interessanter Aspekt... allerdings könnte es sein, dass man dann heute in die Abregelung geht statt morgen, aber sei es mal dahingestellt.

Man könnte folgendermaßen vorgehen...
Es gibt das Reading special_conForecastTillNextSunrise. Vermutlich bräuchte man dazu eher ein special_conForecastSunSetTillNextSunrise (also den Verbrauch zwischen kommenden Sonnenuntergang und Sonnenaufgang was sicherlich auch machbar wäre).

Jetzt muß man nur in ctrlUserExitFn eine kleine Routine schreiben, die den vorhandenen SoC über alle Batterien (BatteryVal ($name, <Batterienummer 01, 02, ..., 'bchargewh', 0) in Wh) als Summe ermittelt.
Ist diese Summe in Wh >= special_conForecastTillNextSunrise (unter Berücksichtigung eines Sicherheitszuschlages und minimal zu verbleibenden SOC), dann könnte man einen Ladestop-Befehl an die Batterie(n) im Skript absetzen. Fällt der Soc wieder unter X, gibst du das Laden wieder frei. Das könnte man auch mittels dynamischen Setzen von ctrlBatSocManagementXX->loadAbort batteriespezifisch automatisieren.

PS[2]: Eine "Emergency Ladung" wird eigentlich stets vom BAT-System ausgelöst.

Ja, ich weiß. Möglicherweise möchte man bereits etwas vorher druckbetanken. Meine Pylons haben einen absoluten Minimal-SoC lt. Datenblatt von 5%. Die will ich nicht riskieren und will auf mindestens 10% bleiben. D.h. zw. 5-9% würde mir das Reading das Emergency Laden signalisieren. (ctrlBatSocManagementXX->lowSoc)

[ch.eick]

Eine Sache beschäftigt mich noch: Um ein Herabregeln der Anlage zu vermeiden, müsste man eigentlich abends die Ladung dann aussetzen, wenn - gemäß Forecast - die BAT so voll ist, dass man über die Nacht kommt und morgens einen minimalen SOC (mit einer auf Basis von Unsicherheiten zu bestimmenden Reserve) nicht unterschreitet. Neben dem oberen SOC sollte, damit das BAT-System gelegentlich auch mal die untere Grenze sieht (wichtig für dessen SOC-Kalibration), auch der BAT-Zustand "leer" hin und wieder mal erreicht werden. Wie würdest Du das auf Basis der aktuell verfügbaren SF-Readings angehen?

Ja, das ist noch ein interessanter Aspekt... allerdings könnte es sein, dass man dann heute in die Abregelung geht statt morgen, aber sei es mal dahingestellt.

Hallo zusammen,
das hatte ich auch schon mal geschrieben, bei mir nenne ich das MaxSOC Limitierung.

- Morgens ermittle ich den SOC beim Übergang vom Speicherbetrieb zur PV Übernahme durch die Module.
- Den SOC am Abend, wenn der Speicher vollständig übernimmt, verwende ich in der Berechnung des geplanten SOCs ebenfalls.
- Sollte der Speicher bei der MaxSOC Limitierung am Nachmittag z.B. wegen des E-Auto ladens verwendet werden, wird die Limitierung ausgesetzt.
- Wenn bei uns dann nachmittags geplant wurde den Wirlpool am Abend zu nutzen, dann setze ich die MaxSOC Limitierung manuell auf 100%.

Es ist also wichtig, wenn man dynamisch limitieren möchte, dass man auch manuell umplanen kann, denn das kann die Steuerung nicht erahnen

Mein Code wäre in diesem DOIF zufinden. Block 7_SOC_Calculation reagiert auf den Übergang morgens und im 8_Reset werden die Merker gesichert.

VG   Christian

[Parallix]

...
Man könnte folgendermaßen vorgehen...
Es gibt das Reading special_conForecastTillNextSunrise. Vermutlich bräuchte man dazu eher ein special_conForecastSunSetTillNextSunrise (also den Verbrauch zwischen kommenden Sonnenuntergang und Sonnenaufgang was sicherlich auch machbar wäre).
...

Aufgrund der bereits diskutierten Ladeschlussbedingung und einer stets existierenden Grundlast, wäre es wohl eher ein special_consFcastFromChgTermTillNextChg, oder?

[ch.eick]

Eine Sache beschäftigt mich noch: Um ein Herabregeln der Anlage zu vermeiden, müsste man eigentlich abends die Ladung dann aussetzen, wenn - gemäß Forecast - die BAT so voll ist, dass man über die Nacht kommt und morgens einen minimalen SOC (mit einer auf Basis von Unsicherheiten zu bestimmenden Reserve) nicht unterschreitet. Neben dem oberen SOC sollte, damit das BAT-System gelegentlich auch mal die untere Grenze sieht (wichtig für dessen SOC-Kalibration), auch der BAT-Zustand "leer" hin und wieder mal erreicht werden. Wie würdest Du das auf Basis der aktuell verfügbaren SF-Readings angehen?

Ja, das ist noch ein interessanter Aspekt... allerdings könnte es sein, dass man dann heute in die Abregelung geht statt morgen, aber sei es mal dahingestellt.

Ich unterliege ja noch der 70% Regelung und versuche diese so gut es geht zu vermeiden. Durch Ost/West und etwas Süd hält sich das Abregeln sehr in Grenzen, da ich einige Geräte in die Zeit schieben kann.
- WP mit WW ab 12 Uhr für 30-45 Minuten
- Wirlpool ab 12:30 Uhr für ca 2-3 Stunden
- Speicherladen nach dem Mittagshoch aus der Leistungsprognose. Da kommt dann die Ladezeitberechnung mit dem Delta SOC zum Tragen, was besagten Keil zur Folge hat.

Darüber hinaus habe ich eine openWB, die von hause aus ein Mittagshoch als Regelpunkt beachten kann. Diesen regelpunkt berechne ich ebenfalls dynamisch und verschiebe ihn, um das E-Auto auch mal über mehrere Tage als Speicher in der Mittagszeit zu verwenden. Das ganze ist jedoch noch eher experimentell zu betrachten. Die mögliche Ladeleistung wird zusätzlich durch die anderen Starkverbraucher dynamisch reduziert, um das Ladefenster möglichst in die Länge zu ziehen. Natürlich kann man das vereinfacht auch mit einer starren Ladeleistung machen, die müsste man dann aber auch noch über ein Zeitfenster begrenzen. Ich mag es halt gerne dynamisch und automatisch  

[DS_Starter]

Ich berechne jetzt den Readingswert für special_remainingSurplsHrsMinPwrBat_XX auf 2 Stellen nach dem Komma. Ist eingecheckt und auch in meinem contrib verfügbar.

[Parallix]

Ich berechne jetzt den Readingswert für special_remainingSurplsHrsMinPwrBat_XX auf 2 Stellen nach dem Komma. Ist eingecheckt und auch in meinem contrib verfügbar.

Suppi!

[DS_Starter]

Aufgrund der bereits diskutierten Ladeschlussbedingung und einer stets existierenden Grundlast, wäre es wohl eher ein special_consFcastFromChgTermTillNextChg, oder?

Naja, dieses in den Raum geworfene Reading special_conForecastSunSetTillNextSunrise ist inhaltlich der prognostizierte Verbrauch zwischen kommenden Sonnenuntergang und kommenden Sonnenaufgang, also der Nachtverbrauch. Das ist zunächst einmal völlig losgelöst von der Verwendung in der Bat-Ladesteuerung -> deswegen passt der Name schon.

[Parallix]

...
Natürlich kann man das vereinfacht auch mit einer starren Ladeleistung machen, die müsste man dann aber auch noch über ein Zeitfenster begrenzen. Ich mag es halt gerne dynamisch und automatisch

Möglichst viel dynamisch hinzubekommen, dürfte auch in erheblichem Maße den Komfort und damit auch die Akzeptanz durch weniger technisch interessierte Menschen erhöhen. Alles zusammen macht SF zu einem immer leistungsfähigeren Modul, was schon unglaublich nahe an einem EMS ist. Toll!

[Parallix]

Aufgrund der bereits diskutierten Ladeschlussbedingung und einer stets existierenden Grundlast, wäre es wohl eher ein special_consFcastFromChgTermTillNextChg, oder?

Naja, dieses in den Raum geworfene Reading special_conForecastSunSetTillNextSunrise ist inhaltlich der prognostizierte Verbrauch zwischen kommenden Sonnenuntergang und kommenden Sonnenaufgang, also der Nachtverbrauch. Das ist zunächst einmal völlig losgelöst von der Verwendung in der Bat-Ladesteuerung -> deswegen passt der Name schon.

Von welchem Sunrise bzw. Sunset sprechen wir eigentlich, wenn wir mal von den im Modul  SUNRISE_EL genannten Definitionen (real, civil, nautic oder astronmic) ausgehen? Im SF-Wiki habe ich hierzu zumindest nichts gefunden. Eine saubere Definition ist jedoch wichtig, denn selbst bei der Annahme "real" bin ich sicher nicht der einzige, bei dem der Verbrauch (im Akku) konservierter Energie schon einige Zeit vor dem Sonnenuntergang beginnt und am kommenden Tag erst einige Zeit nach dem Sonnenaufgang endet!

[DS_Starter]

Von welchem Sunrise bzw. Sunset sprechen wir eigentlich

Sofern die lokalen Koordinaten gesetzt sind (wird geprüft und sollte dadurch immer gwährleistet sein) wird der Standard aus https://metacpan.org/release/JFORGET/DateTime-Event-Sunrise-0.0505/view/lib/DateTime/Event/Sunrise.pm (HORIZON=-0.833) verwendet.
Ansonsten gibt es ein Fall-Back auf die durch die gewählte Wetter-API gelieferten Werte.

[Parallix]

...
Sofern die lokalen Koordinaten gesetzt sind (wird geprüft und sollte dadurch immer gwährleistet sein) wird der Standard aus https://metacpan.org/release/JFORGET/DateTime-Event-Sunrise-0.0505/view/lib/DateTime/Event/Sunrise.pm (HORIZON=-0.833) verwendet.
Ansonsten gibt es ein Fall-Back auf die durch die gewählte Wetter-API gelieferten Werte.

Und zur Bestimmung der Zeiten wird SUNRISE_EL genutzt? Fände ich - auch unter dem Gesichtspunkt der Softwarekonsolidierung - gut!

Den Fallback auf die von der Wetter-API gelieferten Werte finde ich hingegen unschön, da die Wahl (Fallback) bei nicht gesetzten lokalen Koordinaten nicht auffällt und es für den Fall, dass die Wetter-API mal nicht genutzt werden kann (Ausfall Internet, Störung des Dienstleistungsanbieters) kein Fallback mehr gibt.

Vorschlag: Gesetzte Station-Koordinaten bei in SF fordern und Fallback auf Wetter-API rausnehmen.

[DS_Starter]

Und zur Bestimmung der Zeiten wird SUNRISE_EL genutzt? Fände ich - auch unter dem Gesichtspunkt der Softwarekonsolidierung - gut!

Ja, so ist es.

Den Fallback auf die von der Wetter-API gelieferten Werte finde ich hingegen unschön, da die Wahl (Fallback) bei nicht gesetzten lokalen Koordinaten nicht auffällt und es für den Fall, dass die Wetter-API mal nicht genutzt werden kann (Ausfall Internet, Störung des Dienstleistungsanbieters) kein Fallback mehr gibt.

Vorschlag: Gesetzte Station-Koordinaten bei in SF fordern und Fallback auf Wetter-API rausnehmen.

Wird gefordert und geprüft. Fall-Back bleibt sicherheitshalber zum Schutz vor diversen Nebenwirkungen drin, auch auf die unwahrscheinliche Gefahr hin, dass es ein paar Minuten Unterschied geben könnte. Der Nutzer kann ja theoretisch diese Daten im global Device irgenwann löschen wobei sie zum Zeitpunkt der SF-EInrichtung vorhanden waren. 

Dafür gibt es den Config-Check. Da kann der User solche Dinge auch nochmal manuell prüfen.
Diesen Check sollte man ab und zu mal durchlaufen lassen. Soviel Mitwirkung darf ich schon erwarten.

[Parallix]

Ich berechne jetzt den Readingswert für special_remainingSurplsHrsMinPwrBat_XX auf 2 Stellen nach dem Komma. Ist eingecheckt und auch in meinem contrib verfügbar.

Aktuell (8:11) erhalte ich für <special_remainingSurplsHrsMinPwrBat_XX> einen höheren Wert (13.82) als für <special_SunHours_Remain> (13.62), was meiner Ansicht nach nicht stimmen kann, da <SunSet> in SF mit 21:49 angegeben wird und da sicher keinen nennenswerten solaren Ertrag, wohl aber einen höheren Verbrauch habe. Oder erfolgt die Berechnung von <special_remainingSurplsHrsMinPwrBat_XX> ausschließlich auf Basis des 1h-Mittelwerts und nicht, wie seinerzeit von mir vorgeschlagen, auf Basis eines linearen Ansatzes, mit Stützpunkten, die jeweils in der Mitte eines 1h-Intervalls liegen?

[Parallix]

Mal was ganz anderes: Künftig wird es wohl immer mehr Anlagen geben, die dynamisch abgeregelt werden können. In der Konsequenz bedeutet das, dass die Leistung, die lokal nicht genutzt wird und daher in das öffentliche Netz eingespeist werden kann (vereinfachend meist PV-Überschuss genannt), nur noch prognostiziert, aber nicht mehr gemessen werden kann.

Insofern wird es zunehmend extrem wichtig sein, sehr gute Prognosedaten zu haben. Hierfür wird es mittelfristig erforderlich sein, das Zeitfenster und die Stärke einer vorgesehenen Abregelung im Vorfeld zu kennen, um diese vorausschauend in SF berücksichtigen zu können. Gibt es hierfür öffentlich zugängige Datenbanken und APIs, die von uns genutzt werden können?