76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[tpm88]

Hallo Heiko,

aus gegebenen Anlass - werden die stündlichen und von der AI optimierten Korrekturfaktoren bezüglich der erwarteten PV Erzeugung an die Winterzeit angepasst?

Ich habe eine Verschattung durch einen Baum, die jetzt quasi eine Stunde früher zuschlägt...

VG, Tobias

[DS_Starter]

Die jeweiligen Medianwerte als Grundlage für die Faktoren verschieben sich, somit auch die Korrekturen. Aber das dauert etwas. Wie sich das konkret bei einer Baumverschattung ausspielt, ist interessant zu erfahren. Bei einer solchen Verschattung kommen als Einflußfaktoren ja nicht nur die Stundenverschiebung, sondern auch die jahreszeitliche Sonnenstandänderung zum Tragen. Dieser Prozess ist natürlich nicht so abrupt wie die Stundenverschiebung.

Ich hoffe die EU schafft diesen Unsinn irgendwann ab ... hoffen darf man ja. 

[Parallix]

Habe mir die Tage nochmal Gedanken gemacht, wie man die Volatiliät der solaren Leistung über den Tag in SF auch in der Ladestrategie "optPower" geeignet berücksichtigen könnte, wenn man die von SF angelieferte optimale Ladeleistung als durchgängig gesetzten Maximalwert eines Hybridwechselrichters ansieht.

Mein vorläufiges Ergebnis ist, dass hierzu die RMS-Leistung in einem zeitlich gleitenden Fenster, das nicht zu klein aber auch nicht zu groß sein darf (Fensterbreite ca. 1h), herangezogen werden könnte. Über die zeitlich gemittelte Abweichung dieser RMS-Leistung von der von SF berechneten optimalen Ladeleistung könnte dann letztere dynamisch angepasst werden. Vorliegend führt die zeitliche Mittellung zu einem sanften Anheben der Leistung, was ganz in Linie mit der "optPower"-Strategie ist.

@Heiko & all: Was haltet Ihr davon?

Edit: Noch eine Frage am Rande: Nach meinem Verständnis müsste ein in SF registrierter Verbraucher mit einer per default eingestellten mintime von 120 Minuten nach dessen Einschalten für mindestens 120 Minuten in der Verbrauchsvorausschau erscheinen, wenn interruptable auf dem Default-Wert (0) belassen wird, oder?

[Hadl]

Meine Berechnung für 14:00 würde erwarten: Bedarf 3279 Wh auf 3 Stunden aufgeteilt sind 1093 W
Stunde2: Bedarf 3279 Wh in 3 Stunden. Surplus: 997 Wh => 997W Laden + 20% Margin = 1196 W
Stunde1: Bedarf 2282 Wh in 2 Stunden. Surplus: 1736 => 1141W Laden  + 20% Margin = 1369 W
Stunde0: Bedarf 1141 Wh in 1 Stunden. Surplus: 4306 => 1141W Laden + 20% Margin =  1369 W

Das ist nur die halbe Wahrheit, denn smartPower benutzt eine Ratio gewichtete Margin aus (Rest)Tagesüberschuß und Ladebedarf, die du in #4248 ins Spiel gebracht hast und die ich in #4259 beschrieben habe.

Hallo Heiko, ja danke das habe ich mir ja selbst gewünscht, aber in dem Fall sollte es keine Bedeutung haben, da bei einem Bedarf von 3279Wh und einen Überschuss von
14:00: 4306Wh+1736Wh+997Wh=7039Wh; 7039/3279=214% das ist deutlich größer als 120% von 3279Wh => keine Auswirkung
14:51: 718Wh+1736Wh+997Wh=3451Wh; 3451/2035=170% das ist deutlich größer als 120% von 2035 => keine Auswirkung
15:00: 1736Wh+997Wh=2733Wh ; 2733/1843=148%, das ist deutlich größer als 120% von 1843Wh => keine Auswirkung
Übersehe ich hier was?

ABER...dank deines Anschubses habe ich mir die Routine nochmal angeschaut und festgestellt, dass ich leider statt des (Rest)Tagesüberschusses die (Rest)Tages-PV-Erzeugung eingebracht habe.
Das habe ich korrigiert.

Das Modulupdate liegt im Contrib.

Vielen Dank, ich probiers gleich aus!

Generell hab ich mir nochmal Gedanken gemacht und die aktuelle Implementierung angesehen.
Ich denke wir könnten eine deutlich gleichmäßigere Leistung erzielen wenn wir weniger auf die aktuelle Stunde als Zeitfenster schauen, was zum Ende der Stunde manchmal zu Abweichungen führt, sondern immer den Rest-Tag als Fenster hernehmen.
Für den Rest-Tag berechnen wir eine Durchschnitts-Leistung die notwendig ist. Diese Durchschnitts Leistung wird dann erhöht durch die Begrenzug der Leistung in Stunden die diesen Durchnitt nicht erbringen können.
Die Erhöhungen durch die ganzen Margin/OptPower/Efficiency Aufschläge machen wird dann im Anschluss mit der errechneten Optimal-Leistung

Im Code müsste man dann $spls warscheinlich durch $total/RestOfDay ersetzen. Den Wert dann in der Schleife von den schwächsten Surplus zu den stärkeren Surplus Stunden erhöhen wie oben beschrieben

Mein vorläufiges Ergebnis ist, dass hierzu die RMS-Leistung in einem zeitlich gleitenden Fenster, das nicht zu klein aber auch nicht zu groß sein darf (Fensterbreite ca. 1h), herangezogen werden könnte. Über die zeitlich gemittelte Abweichung dieser RMS-Leistung von der von SF berechneten optimalen Ladeleistung könnte dann letztere dynamisch angepasst werden. Vorliegend führt die zeitliche Mittellung zu einem sanften Anheben der Leistung, was ganz in Linie mit der "optPower"-Strategie ist.

Den RMS halte ich nicht für sinnvoll, da wir damit ja kurze Ausreiser eher aufwerten, in der Praxis aber nicht nutzen wollen.
Für die Zukunft/Prognose hätten wir ja nur Stundenwerte, das heißt ein Ausreiser wäre ja eine Stunde. Warum sollten wir den Quadratisch in ein Mittel einbeziehen?
Ich würde auch versuchen garkeine künstliche Fensterbreite zu definieren, denn wir wollen ja den Rest-Tag möglichst gleichmäßig haben, dann sollten wir auch diesen Zeitraum betrachten.

[Parallix]

Mein vorläufiges Ergebnis ist, dass hierzu die RMS-Leistung in einem zeitlich gleitenden Fenster, das nicht zu klein aber auch nicht zu groß sein darf (Fensterbreite ca. 1h), herangezogen werden könnte.
...

Den RMS halte ich nicht für sinnvoll, da wir damit ja kurze Ausreiser eher aufwerten, in der Praxis aber nicht nutzen wollen.
...

Nein! Sie führen keinesfalls zu keinem RMS-Anstieg, da die Leistung ja (gemäß Annahme) gedeckelt ist! 

[Hadl]

Nein! Sie führen keinesfalls zu keinem RMS-Anstieg, da die Leistung ja (gemäß Annahme) gedeckelt ist! 

Dann hab ich da was falsch verstanden. Kannst du bitte nochmals erklären über welche Werte du den RMS rechnen willst?

[Parallix]

Nein! Sie führen keinesfalls zu keinem RMS-Anstieg, da die Leistung ja (gemäß Annahme) gedeckelt ist! 

Dann hab ich da was falsch verstanden. Kannst du bitte nochmals erklären über welche Werte du den RMS rechnen willst?

Die tatsächliche RMS-Leistung (von WR zum Speicher), die pro SF-Zyklus aus der in den Akku verbrachten Energie (typischerweise in Wh angegeben) und der SF-Zykluszeit (Default: 90s) berechnet wird.

[Hadl]

Die tatsächliche RMS-Leistung (von WR zum Speicher), die pro SF-Zyklus aus der in den Akku verbrachten Energie (typischerweise in Wh angegeben) und der SF-Zykluszeit (Default: 90s) berechnet wird.

Aber das ist doch dann ne Analyse der Vergangenheit. Was hilft uns das für die Prognose bzw. Leistungsvorgabe?
Welches Ziel soll diese Berechnung haben?


Ich hab mal meine Vorstellung der Strategie in zwei Bilder gegossen.
Du darfst diesen Dateianhang nicht ansehen.Du darfst diesen Dateianhang nicht ansehen.

Links würde man die OTP Berechnung um 12:30 sehen. Alle Stunden haben die gleiche Leistung, außer die bei denen die Leistung nicht ausreicht. Die Berechnung ist so, das die Energiemenge plus Zuschläge zum Laden des Akkus ausreicht.

Das zweite Beispiel wäre um 14:30, wenn im Akku dann schon wie geplant voller ist.
Auch wenn dann nur geringere Leistung erwartet wird, würde ich die Leistung anfordern, die ich auch in den stärkeren Stunden anfordere. Falls dann die Wolkenlücke von Stunde 15 doch früher kommt, dann nehmen wir die Leistung mit.

[Hadl]

So, nun ist der heutige Solar-Tag fast am Ende und ich möchte euch die Ergebnisse das Tages zeigen.
Ich hab das neuste Contrib am laufen.
Du darfst diesen Dateianhang nicht ansehen.

Die Strategie hat heute nicht gut funktioniert.
Der Akku war früh bei ca. 50% also relativ gut gefüllt. Es mussten 3648 Wh in den Akku geladen werden und 10822 Wh Überschuss wurden erwartet.
Die Stunden von 10 bis 16 hätten alle genügend prognostizierten Überschuss gehabt um den Akku in diesen 7 Stunden mit konstant 521W vollzuladen.
521W * 120%(margin) / 87%(efficiency)  = 719W
Kein weiterer Aufschlag wegen SmartPower da genügend Energie da ist.

Aber was ist wirklich passiert:
Bis 11:00 hat er bis auf 3 kurze Einbrücke durchgehend mit pinmax=3000W laden wollen, obwohl ein Tag mit genügend Überschuss prognostiziert war.
Um 11:00 ist der OTP dann auf unter 800W gesprungen. Dann kamen ein paar Momente mit negativen Überschuss.
Um 12:00 kletterte er dann wieder auf 2500W hoch. Bis 12:20 ging er dann wieder langsam auf 1200W runter. Den Rest der Stunde sprang er aus unbekannten Gründen zwischen 800W und 1100W hin und her. Überschuss war zur der Zeit genügend vorhanden, so das die Leistung auch wirklich erfüllt wurde.
Von 13:00-14:00 hat er dann schön konstant und niedrig mit 630W geladen.
Um 14:00 sprang er kurz auf pinmax=3000W, dann aber gleich wieder runter.
Um 14:25 sprang er dann wieder auf pinmax=3000W, wodurch der Akku um 14:50 voll war.

Code Auswählen Erweitern

2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ######################### Start Battery Management DebugLog #########################
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging raw: 14990 Wh
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging after application Share factor: 14990 Wh
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 35 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 14990 Wh, need until maxsoc: 3648 Wh
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 35 %, use preliminary Target: 35 % (new care SoC calc & act postponed to after 27.10.2025 11:55:00)
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> cantarget: -95 %, newtarget: -95 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 0, Target: 35 % (new target < current Target SoC 40)
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - basics -> docare: 0, lowSoc: 40 %, upSoc: 60 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 40 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 40 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> SoC Step6 Bat 01 - force charging request: no (Battery is sufficiently charged)
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo1' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo2' cap: 12000 W, Power limit: 100 % -> Pmax eff: 12000 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 22000 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt - The limit for grid feed-in is: 18800 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - General load termination condition: 0
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 87 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - charging target: 100 % / 7680 Wh
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - OtpRaw: 574.712643678161 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 3648 Wh -> target likely achievable? yes
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/09 - hod: 10/00, lr/lc: 1/1, SoC S/E: 4032/4494 Wh, Surp h/d: 531/10822 Wh, OTP: 600 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/10 - hod: 11/01, lr/lc: 1/1, SoC S/E: 4494/5022 Wh, Surp h/d: 1045/9777 Wh, OTP: 607 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/11 - hod: 12/02, lr/lc: 1/1, SoC S/E: 5022/5546 Wh, Surp h/d: 2459/7318 Wh, OTP: 602 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/12 - hod: 13/03, lr/lc: 1/1, SoC S/E: 5546/6068 Wh, Surp h/d: 2461/4857 Wh, OTP: 600 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/13 - hod: 14/04, lr/lc: 1/1, SoC S/E: 6068/6590 Wh, Surp h/d: 2481/2376 Wh, OTP: 600 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/14 - hod: 15/05, lr/lc: 1/1, SoC S/E: 6590/7680 Wh, Surp h/d: 1918/458 Wh, OTP: 3000 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/15 - hod: 16/06, lr/lc: 0/1, SoC S/E: 7680/7680 Wh, Surp h/d: 731/0 Wh, OTP: 3000 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/16 - hod: 17/07, lr/lc: 0/1, SoC S/E: 7680/7680 Wh, Surp h/d: 149/0 Wh, OTP: 3000 W
2025.10.27 09:26:31 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/17 - hod: 18/08, lr/lc: 0/1, SoC S/E: 7680/7680 Wh, Surp h/d: 0/0 Wh, OTP: 0 W
hier mal ein paar Auszüge für die aktuelle Stunde an interessanten Stellen des Tages:

Code Auswählen Erweitern

2025.10.27 10:59:59 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/10 - hod: 11/00, lr/lc: 1/1, SoC S/E: 4815/4806 Wh, Surp h/d: 0/6598 Wh, OTP: 3000 W
2025.10.27 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/11 - hod: 12/00, lr/lc: 1/1, SoC S/E: 4815/5641 Wh, Surp h/d: 949/5184 Wh, OTP: 820 W
2025.10.27 11:01:09 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/11 - hod: 12/00, lr/lc: 1/1, SoC S/E: 4831/6271 Wh, Surp h/d: 1655/4422 Wh, OTP: 792 W

2025.10.27 11:59:50 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/11 - hod: 12/00, lr/lc: 1/1, SoC S/E: 5169/5187 Wh, Surp h/d: 22/2631 Wh, OTP: 2456 W
2025.10.27 12:00:05 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/12 - hod: 13/00, lr/lc: 1/1, SoC S/E: 5169/6511 Wh, Surp h/d: 1543/2380 Wh, OTP: 3000 W
2025.10.27 12:00:41 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/12 - hod: 13/00, lr/lc: 1/1, SoC S/E: 5169/6276 Wh, Surp h/d: 1273/2628 Wh, OTP: 2471 W

2025.10.27 12:55:32 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/12 - hod: 13/00, lr/lc: 1/1, SoC S/E: 6390/6482 Wh, Surp h/d: 106/1483 Wh, OTP: 1133 W
2025.10.27 12:56:42 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/12 - hod: 13/00, lr/lc: 1/1, SoC S/E: 6413/6487 Wh, Surp h/d: 85/1462 Wh, OTP: 1078 W
2025.10.27 12:57:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/12 - hod: 13/00, lr/lc: 1/1, SoC S/E: 6459/6514 Wh, Surp h/d: 64/1440 Wh, OTP: 759 W
2025.10.27 12:59:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/12 - hod: 13/00, lr/lc: 1/1, SoC S/E: 6474/6493 Wh, Surp h/d: 21/1419 Wh, OTP: 789 W
2025.10.27 12:59:50 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/12 - hod: 13/00, lr/lc: 1/1, SoC S/E: 6482/6500 Wh, Surp h/d: 21/1377 Wh, OTP: 1133 W
2025.10.27 13:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/13 - hod: 14/00, lr/lc: 1/1, SoC S/E: 6482/7283 Wh, Surp h/d: 921/1729 Wh, OTP: 718 W
2025.10.27 13:00:12 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/13 - hod: 14/00, lr/lc: 1/1, SoC S/E: 6482/7199 Wh, Surp h/d: 824/1812 Wh, OTP: 600 W
2025.10.27 13:01:22 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/13 - hod: 14/00, lr/lc: 1/1, SoC S/E: 6497/7202 Wh, Surp h/d: 810/1812 Wh, OTP: 600 W

2025.10.27 14:25:23 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/14 - hod: 15/00, lr/lc: 1/1, SoC S/E: 7127/7300 Wh, Surp h/d: 198/1344 Wh, OTP: 600 W
2025.10.27 14:26:33 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/14 - hod: 15/00, lr/lc: 1/1, SoC S/E: 7127/7680 Wh, Surp h/d: 1037/0 Wh, OTP: 3000 W
2025.10.27 14:27:43 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/14 - hod: 15/00, lr/lc: 1/1, SoC S/E: 7135/7680 Wh, Surp h/d: 1006/331 Wh, OTP: 3000 W