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.