76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Moin,

Ich würde mir wünschen das der Battery_ChargeOptTargetPower immer wieder neu berechnet wird auf Basis des aktuellen Ladezustands und der aktuellen Prognose. So das wenn der Akku entgegen der Prognose nicht geladen wurde (hoher Verbrauch/geringe PV) die nachfolgenden Stunden eine höhere Leistung bekommen.

Genauso ist es bereits implementiert. Es schützt allerdings nicht davor am Anfang des Tages geringer als möglich zu laden (in Umsetzung des Ansatzes "so gering wie möglich") wenn die Kalkulation von genügendem Überschuß "weiter hinten" ausgeht, der dann aber nicht eintritt.

Dein Debug sieht erstmal sehr gut aus:

Code Auswählen Erweitern

2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 09, Start SoC: 3168 Wh, Surplus: 1007 Wh (9 hours), OptTargetPower: 602 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 10, Start SoC: 3168 Wh, Surplus: 918 Wh (10 hours), OptTargetPower: 541 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 11, Start SoC: 3709 Wh, Surplus: 1261 Wh (8 hours), OptTargetPower: 596 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 12, Start SoC: 4305 Wh, Surplus: 2000 Wh (6 hours), OptTargetPower: 675 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 13, Start SoC: 4980 Wh, Surplus: 2000 Wh (5 hours), OptTargetPower: 648 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 14, Start SoC: 5628 Wh, Surplus: 2000 Wh (4 hours), OptTargetPower: 616 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 15, Start SoC: 6244 Wh, Surplus: 2000 Wh (3 hours), OptTargetPower: 574 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 6818 Wh, Surplus: 2000 Wh (2 hours), OptTargetPower: 517 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: 7335 Wh, Surplus: 2000 Wh (1 hours), OptTargetPower: 414 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: 7680 Wh, Surplus: 2000 Wh (1 hours), OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: 7680 Wh, Surplus: 1911 Wh (7 hours), OptTargetPower: 500 W, safety: 20 %

Es ist sehr gut zu sehen, wie deine Batterie bis 18:00 (ca. 18:00 ist sie dann voll) recht gleichmäßig aufgeladen wird und am Ende rein kalkulatorisch voll sein wird. Das sieht gut aus. Der gleichmäßige surplus auf 2000W über eine recht lange Zeit kommt sicherlich von dem gesetzten "pinmax". Also insgesamt völlig io. Nun ist es natürlich so, dass die Kalkulation davon ausgeht die OptTargetPower von z.B. 602W wird als Minimumleistung konstant in der Stunde in die Bat geladen. In der Realität kann sie auch mal geringer ausfallen (kein PV wegen Wolken, mehr Verbrauch usw.). Da denke ich darüber nach wie ich das verbessern, Tendiere aber jetzt schon dazu den default Safety Betrag von 20% auf 50% zu heben wie bei der anderen Optimierung.

Ich hab mir nun die Grobstrategie von OptTargetPower nochmals durchgelesen. Damit sollte doch die Ladeleistung gleichmäßig über alle verfügbaren Stunden mit genügend Überschuss verteilt werden.

Ja, das zeigt das Debug auch wie zu sehen ist. Das klappt natürlich nicht immer so schön, je nach Verteilung des (prognostizierten) Überschusses über den Tag.

Warum sehe ich dann so unterschiedliche Werte wie hier? OptTargetPower ist immer deutlich niedriger wenn ChargeUnrestricted gesetzt ist!?!

Kann ich dir nicht beantworten. Beide Optimierungsstrategien werden intern durch verschiedene Subs mit unterschiedlichen Optimierungszielen berechnet.

Wann wird denn OptTargetPower bestimmt? Nur einmal am Tag, oder bei jeder Berechnung wieder neu?

Mit jedem Zyklus erneuet. D.h. die Werte im Debug werden sich ständig an die realen Gegebenheiten anpassen. Wenn du in eine für dich kritische Tageszeit kommst, kannst du das Debug erneut starten und in der Auswertung sieht man wieder die Zusammenhänge.

OptTargetPower sollte bei jeder Berechnung wieder neu bestimmt werden, so das nach aktuellen Akku Ladezustand und der Rest-Tagesprognose der Akku noch voll (inkl safety) werden kann. Falls nichtmehr möglich sollte auf pinmax gestellt werden. Damit wird er zwar am Ende des Tages immer auf pinmax stehen, da ja die safety Energie nicht reinpasst, aber da sollter er auch schon voll sein und somit eh keine Ladung mehr erfolgen.

So ist es auch implementiert, wobei pinmax ein begrenzender Faktor ist (wie im Debug zu sehen) und am Ende des Tages; wenn kein Überschuß mehr oder die Bat voll ist; OTP auf setupBatteryDevXX->pinreduced und ggf. die Fallbacks gesetzt wird wie ich schon erläuterte.

[Gisbert]

Hallo Heiko,

die letzte Änderung, die shiftx im Energy flow Diagram betrifft, hat funktioniert.

Mir ist jetzt aber aufgefallen, dass im Attribut

Code Auswählen Erweitern

graphicControl
beamWidth=100 hourCount=20 energyUnit=kWh spaceSize=10 headerDetail=allbeamWidth nicht so funktioniert, wie ich es erwarte. Die Balkenbreite ändert sich nicht, egal ob ich 20 oder 100 eingebe, oder diesen Part lösche. Die Breite der Balken ist dabei unterschiedlich breit, demnach also dynamisch.
Hab ich was übersehen?

Viele Grüße Gisbert

[DS_Starter]

beamWidth nicht so funktioniert, wie ich es erwarte. Die Balkenbreite ändert sich nicht, egal ob ich 20 oder 100 eingebe, oder diesen Part lösche.

Kann ich so nicht bestätigen. Klappt bei mir im Browser einwandfrei. Anbei ein Beispiel mit beamWidth=80.

[DS_Starter]

@Hadl, Parallix,

ich habe einen Fehler in der Berechnungslogik von Battery_ChargeOptTargetPower_XX erkannt und beseitigt.
Ich habe zwar sehr kontinuierlich den PV-Überschuß neu berechnet, aber bzgl. SoC fehlte der Abgleich von Prognose und Ist-SoC.
Das habbe ich jetzt korrigiert und ins contrib geladen.

Morgen wird man mehr sehen, aber das Log zeigt schon die Verbesserung. Damit dürfte sich das Problem von Hadl auch weitgehend erledigt haben.

Code Auswählen Erweitern

2025.09.12 15:44:28.058 1: SolCast DEBUG> ChargeOTP - maximum OptTargetPower Bat 01: 3706 W, number relevant values: 1
2025.09.12 15:44:28.058 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.09.12 15:44:28.059 1: SolCast DEBUG> ChargeOTP - NOTE: The hours printed below are the estimated number of hours on the current day with at least the respective PV surplus.
2025.09.12 15:44:28.059 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 25290 Wh, Surplus: 3706 Wh (1 hours), OptTargetPower: 3706 W, safety: 20 %
2025.09.12 15:44:28.059 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: 28416 Wh, Surplus: 986 Wh (1 hours), OptTargetPower: 1000 W, safety: 20 %
2025.09.12 15:44:28.060 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: 28416 Wh, Surplus: 400 Wh (2 hours), OptTargetPower: 1000 W, safety: 20 %
2025.09.12 15:44:28.060 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.12 15:44:28.060 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 20, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.12 15:44:28.061 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 21, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.12 15:44:28.061 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 22, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.12 15:44:28.061 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 23, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.12 15:44:28.062 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 24, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
LG,
Heiko

[DS_Starter]

Hallo Chris,

das ist aber auch kein Problem mit DWD OpenData, sondern soweit ich sehen kann beide Dinge eine Sache für den SVG Thread.
Bitte poste es dort nochmal, gehört wirklich nicht hierher. Bitte um Verständnis.

LG,
Heiko

[Burny4600]

das ist aber auch kein Problem mit DWD OpenData, sondern soweit ich sehen kann beide Dinge eine Sache für den SVG Thread.
Bitte poste es dort nochmal, gehört wirklich nicht hierher. Bitte um Verständnis.

Kein Problem. Werde ich gleich machen.

[Gisbert]

beamWidth nicht so funktioniert, wie ich es erwarte. Die Balkenbreite ändert sich nicht, egal ob ich 20 oder 100 eingebe, oder diesen Part lösche.

Kann ich so nicht bestätigen. Klappt bei mir im Browser einwandfrei. Anbei ein Beispiel mit beamWidth=80.

Hallo Heiko,
dachte ich mir schon, danke fürs Nachschauen. Vermutlich grätscht der an und für sich schöne flex Style dazwischen, der leider nicht mehr maintdained wird.

Viele Grüße Gisbert

[Heatseeker]

Moin,

Bei mir läuft der forecast schon seit langer Zeit sehr zuverlässig und nutze diesen z.B. um meinen Akku schonend prognosebasiert zu laden.

Nun bekomme ich demnächst einen neuen Zählermodul eingebaut (Huawei Emma) wegen einer Installation der wallbox, und ich weiß noch nicht ob ich die Kommunikation zu diesem ebenfalls so schnell aufgebaut bekomme.
Kann ich den forecast auch ohne lernen etc laufen lassen? Die Daten stimmen ja inzwischen sehr gut. Aber ich befürchte wenn ich dann dauerhaft null Einspeisung habe, geht mir meine ganzen angelernten Korrektur faktoren flöten....

[DS_Starter]

Kann ich den forecast auch ohne lernen etc laufen lassen?

Ja, das geht natürlich:

Code Auswählen Erweitern

set ... pvCorrectionFactor_Auto noLearning

LG,
Heiko