Loadpoint: allow fine-grained battery boost

[andig]

Fix #19845

Currently, battery boost draw at least 1A per phase from grid, regardless if mA charging is available. This PR honors mA charging.

[premultiply]

Da ich es momentan mangels Zeit nicht genauer analysieren kann hier meine Gedanken dazu:

Es braucht gewisse Toleranzen, da hier verschiedene Dinge gleichzeitig einwirken.

• Die Regelung des Batteriespeichers muss stets ausreichend Bezug sehen (Offset) um seine die Boost-Leistung hochzufahren. Sonst ist er ja nur bestrebt ein Gleichgewicht herzustellen. Je geringer der Fehlbetrag Offset desto langsamer die Ausregelung durch den Batteriespeicher, manchmal wirken dabei sogar Totbereiche die nicht ausgeglichen werden.
• Im Extremfall müssen 4,2 kW auf 22 kW hochgefahren werden. Mit 100W-Offset und 30 Sekunden Intervall würde das ein sehr langes Vorhaben - wenn keine sonstigen Störungen durch Verbrauchsschwankungen hinzukommen.
• Nicht nur Ladepunkte müssen stufenlos regelbar sein, auch die Fahrzeuge. Wenn das angeschlossene Fahrzeug nur 1A-Sprünge macht oder anderweitig nicht gänzlich stufenlos steuerbar ist oder nichtlinearitäten auftreten muss das auch funktionieren. Über das genaue Verhalten der angeschlossenen Fahrzeuge wissen im Zweifelsfall zu wenig.

In meinem Test (Wallbe mit 0,1A Schritten, ZOE, SMA SBS) funktioniert dieser PR mit diesem Stand nicht.
Der Speicher regelt nicht (mehr) hoch.

Vielleicht haben @mfuchs1984 und @VolkerK62 auch noch eine Idee dazu.

Irgendwo hatten wir das schon mal analysiert und diskutiert woraus dann die aktuelle (funktionierende) Lösung entstand. Da ging es speziell auch um die Abhängigkeit mit der Phasenanzahl. Leider finde ich das nicht mehr.

[andig]

Im Extremfall müssen 4,2 kW auf 22 kW hochgefahren werden. Mit 100W-Offset und 30 Sekunden Intervall würde das ein sehr langes Vorhaben - wenn keine sonstigen Störungen durch Verbrauchsschwankungen hinzukommen.

Das Hochfahren passiert ja schon vorher. Hier gehts nur ums nachsteuern.

Je geringer der Fehlbetrag Offset desto langsamer die Ausregelung durch den Batteriespeicher, manchmal wirken dabei sogar Totbereiche die nicht ausgeglichen werden.

Dann müssten wir ja jetzt einen plausiblem Totbereich raus finden. Schaffen wir das? Zumindest bei 3p sind 690W schon sehr heftig.

Wäre großartig wenn das jemand mit Akku testen könnte- ich kanns mangels Gerät leider nicht.

[VolkerK62]

Der Totbereich spielst doch im normalen Betrieb auch eine Rolle?
Könnte man dafür nicht den Wert von residualpower nehmen?

[andig]

Klingt plausibel. ...dann sollten die 100W aus diesem PR ja reichen. Egal wie man es dreht: es muss jemand schauen was da gerechnet wird und warum es nicht funktioniert.

[VolkerK62]

Hier ist ein Fall, wo trotz boost, die Ladeleistung kontinuierlich sinkt
#19492 (reply in thread)

Welche residualpower Einstellung war dabei aktiv? Ich würde tippen 401W.

[site  ] DEBUG 2025/03/08 13:07:33 ----
[lp-1  ] DEBUG 2025/03/08 13:07:33 charge power: 5249W
[site  ] DEBUG 2025/03/08 13:07:33 grid power: 20W
[site  ] DEBUG 2025/03/08 13:07:33 battery 1 power: 1412W
[site  ] DEBUG 2025/03/08 13:07:33 site power: 1833W
[lp-1  ] DEBUG 2025/03/08 13:07:33 pv charge battery boost: -1642W = -1412W battery - 230W boost
[lp-1  ] DEBUG 2025/03/08 13:07:33 pv charge current: 21.6A = 22.4A + -0.83A (191W @ 1p)
[lp-1  ] DEBUG 2025/03/08 13:07:33 max charge current: 21.6A
[site  ] DEBUG 2025/03/08 13:07:48 ----

Auf die Batterieleistung wird 1A Ladeleistung aufgeschlagen (230W boost).
Der Wert battery boost wird mit site power verrechnet und ergibt das Regelungs-Delta.
site power = battery power + grid power + residualpower ergibt 1412W + 20W + 401W = 1833W
1833W + (-1642W) = 191W Regelungs-Delta. Um diesen Wert wird die Ladeleistung angepasst.

Müsste man zum delta nicht auch noch residualpower dazurechnen (damit es im Endeffekt unberücksichtigt bleibt)?

evcc/core/loadpoint.go

Line 1317 in 69bfa6d

delta := lp.EffectiveStepPower()

[premultiply]

Klingt logisch. Bei mir steht residualPower auf 100W und vermutlich deshalb funktioniert es damit bei mir gar nicht.
Da müssen wir also vorher noch an die Berechnung ran.

Vielleicht letztendlich mit + und - |residualPower| als Gesamtoffset arbeiten?

[andig]

Night schön, aber probehalber umgesetzt

[VolkerK62]

Das wirkt dann aber nur (passend zum PR) bei mA-Regelung.
Könnte man das nicht auch gleich auch noch für die LP anpassen, die nur in ganzen A geregelt werden können?
Wenn da residualpower zu hoch (positiv) eingestellt ist, funktioniert der boost auch nicht richtig.

[andig]

Das wirkt dann aber nur (passend zum PR) bei mA-Regelung.

Bei ganzen A sind es soweiso mindestens 230W. Da damit bisher kein Problem bekannt ist auch keine Änderung- oder worauf willst du hinaus?

Wenn da residualpower zu hoch (positiv) eingestellt ist, funktioniert der boost auch nicht richtig.

Was schlägst Du vor?

[VolkerK62]

siehe oben #19385 (comment)
Da waren 400W residualpower eingestellt, deshalb hat boost nicht richtig funktioniert. Die Ladeleistung wurde in jedem Intervall reduziert.
Idee ist, delta := lp.EffectiveStepPower() + residualpower
Damit wäre beim anschließenden Vergleich mit site Power der Einfluss von residualpower praktisch aufgehoben.

[andig]

Verstehe ich nicht. Im normalen fall (nicht mA) werden zum "richtigen" Leistungsbedarf ja schon 1A drauf gerechnet. Wieso sollte man da residual Power nochmal rein rechnen? Die ist ja schon drin!

[andig]

Im Zweifel: gerne PR direkt anpassen und ausprobieren.

[VolkerK62]

[site  ] DEBUG 2025/03/08 13:07:33 site power: 1833W
[lp-1  ] DEBUG 2025/03/08 13:07:33 pv charge battery boost: -1642W = -1412W battery - 230W boost
[lp-1  ] DEBUG 2025/03/08 13:07:33 pv charge current: 21.6A = 22.4A + -0.83A (191W @ 1p)

pv charge battery boost wird mit site power verrechnet.
In site power sind 401W residualpower enthalten, deshalb wird die Ladeleistung reduziert.

Mit meine Idee wäre die Änderung bei pv charge current nicht +191W sondern -210W

[andig]

Im Zweifel: gerne PR direkt anpassen und ausprobieren.

Ich verstehe nur bahnhof.

[VolkerK62]

Wenn es mal wieder Sonne gibt und in meiner Batterie etwas drin ist, dann werde ich es mal ausprobieren.

[VolkerK62]

da ich nur einen 1A-Charger habe, passt es nciht in diesen PR.
Ich mache zum Thema "residualpower & battery boost" ein neues Issue auf.

[premultiply]

Anm: Hier wird (ggf. nochmals) residualPower addiert um dessen Offset an der site zu neutralisieren (sonst verschobener Arbeitspunkt, #19845).

[andig]

Ich kann dir nicht folgen. Ist das so jetzt richtig? Dann müsste es noch getestet werden :O

[premultiply]

Ja, sollte nun so richtig sein.
Gestern war leider für mich keine Testmöglichkeit in der Praxis mehr.

[premultiply]

Ich habe einen neuen Commit zur kritischen Diskussion gemacht.
Glaube wir hatten da vorher schlicht einen kleinen Denkfehler drin und zusätzlich auch den Einfluss von residualPower auf die Boost-Funktion an der site nicht bedacht.

[andig]

Gabs schon eine Chance, das zu testen?

[andig]

Friendly ping

[Copilot]

Pull Request Overview

This PR enables fine-grained battery boost by considering mA charging and adjusting the boost power calculation accordingly. In summary, the PR updates the Prepare API for loadpoints to pass a site parameter, adjusts boost power computation in the Loadpoint, and revises tests to create a Site instance.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
core/site.go	Updated the Prepare invocation to pass the Site instance.
core/loadpoint_test.go	Modified test calls to use a new Site instance for the Prepare call.
core/loadpoint.go	Added a site field, modified Prepare signature, and updated boostPower calculation to incorporate residual power.

Comments suppressed due to low confidence (1)

core/loadpoint_test.go:85

• [nitpick] Ensure that using new(Site) in tests provides a fully functional or properly mocked site.API implementation. Inadequate initialization may affect the validity of the test outcomes.

lp.Prepare(new(Site), uiChan, pushChan, lpChan)