76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Hadl]

Gerade so voll ... dann hat das Verfahren gut funktioniert

Ja, bin auch sehr zufrieden damit. Heute wurden eben die Sicherheiten alle ausgenutzt.

Diese Größe ist wichtig für die iterative Festlegung der Ladeleistung. Es gibt nur das Raster von 1h. Der Überschuß ist eine Rechengröße. Selbst wenn man den Aufwand treiben würde den Überschuß rein rechnerisch z.B. in 5 Minuten-Raster aufzuteilen sagt es nichts aus, denn 90% des kalkulierten Überschuß können sich je nach Situation in den ersten 15 Minuten niederschlagen, die restliche 10% in den 45 Minuten danach. Nur als Beispiel, kann man beliebig ändern.

Ja, diese Unsicherheit wird uns immer bleiben, dafür brauchen wir Sicherheitszuschläge oder unerwartete Überschüsse später am Tag. Das Raster von 1h ist denke ich schon gut im Anbetracht dessen wie groß die Unsicherheiten bei PV und Verbrauchsprognose sind.

Die Zielleistung wird abfallend proportional zum linearen Rest-Überschuss des Tages berechnet.
In #4259 hatte ich schonmal die sich ergebende Kennlinie der Logik gezeigt.
Den dafür verwendeten Berechnungsvorschlag hast du übrigens selbst eingebracht. 

Ja, ich bin auch Überzeugt das der Ansatz gut und richtig ist. Nur bei den Eingangswerten sehe ich das wir aktuelle minutengenaue Werte mit den Stundengenauen Werten vermischen. Dadurch entstehen dann Fehler innerhalb einer Stunde.

Code Auswählen Erweitern

2025.10.22 16:00:13 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 1375 Wh -> target likely achievable? yes
2025.10.22 16:00:13 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/16 - hod: 17 / 00, lr/lc: 1/1, SoC S/E: 6305 / 7680 Wh, Surplus: 2673 Wh, OTP: 1931 W
2025.10.22 16:00:13 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/17 - hod: 18 / 01, lr/lc: 0/1, SoC S/E: 7680 / 7680 Wh, Surplus: 32 Wh, OTP: 2000 W

2025.10.22 16:57:24 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 530 Wh -> target likely achievable? yes
2025.10.22 16:57:24 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/16 - hod: 17 / 00, lr/lc: 1/1, SoC S/E: 7150 / 7266 Wh, Surplus: 2673 Wh, OTP: 720 W
2025.10.22 16:57:24 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/17 - hod: 18 / 01, lr/lc: 1/1, SoC S/E: 7266 / 7294 Wh, Surplus: 32 Wh, OTP: 600 WZ.b. wurde um 16:00 ein Überschuss von 2637Wh in der aktuellen + 32Wh in der nächsten Stunde erwartet und es mussten noch 1375Wh in den Akku geladen werden.
Es stand aber quasi (bis auf 32Wh) nur die aktuelle Stunde zur Verfügung. Also mit 1375W +20% (margin) = 1650 W Laden. Weiterer Aufschlag von knapp 20%, weil der Überschuss so knapp ist => 1931W
Soweit alles in Ordnung.

Um 16:57 wurde dann immer noch ein Überschuss von 2637Wh in der aktuellen + 32Wh in der nächsten Stunde erwartet, es mussten aber nur noch 530Wh in den Akku geladen werden.
Auch hier stand quasi (bis auf 32Wh) nur die aktuelle Stunde zum Laden zur Verfügung und die 530Wh konnten also nach implementierung in der aktuellen Stunde leicht geladen werden. 530W + 20% = 636W. Überschuss ist ja jetzt reichlich vorhanden da weniger Bedarf vorhanden ist, daher geringer Aufschlag => 720W OTP
=> Das ist aber Falsch und viel zu gering. Von der Stunde in der 2637Wh Überschuss erwartet wurden sind nur noch 3 Minuten übrig. Daher sollte man bei dieser Berechnung von 2637Wh*3/60 = 220Wh in der aktuellen Stunde und 32Wh in der nächsten Stunde ausgehen. Beim Ladebedarf gehen wir ja auch vom aktuellen Wert 530Wh basiedernd auf dem aktuellen SOC aus.
Also not achievable! Das merken wir aber mit aktueller Logik erst in der nächsten Stunde.

Hätte man immer mit den aktuellen Restwerten gerechnet wäre man auf einen relativ konstanten OTP gekommen und man hätte deutlich weniger Sicherheitszuschlag gebraucht um den Akku voll zu bekommen.

Viele Grüße

Hadl

[DS_Starter]

Ja ich weiß was du meinst. Bei loadRelease ist die Restzeit der aktuellen Stunde auch verformelt.
Hier ist das nicht so einfach. Vllt. habe ich eine Lösung, die muß ich aber erst noch evaluieren und testen.