[s0170071]

Problem

Im Mindest-SoC-Modus, im Band zwischen min_soc und max_soc, bei aktiver Hysterese und konfigurierter Entladeleistung:

charging_power_left = min(required_absolut_discharge_power + base_power,
                          absolute_bat_discharge_power)

base_power ist die vorzeichenbehaftete Speicherleistung.

Für base_power < 0 ist die Zeile richtig, und der Kommentar darüber beschreibt genau diesen Fall: wird der Speicher stärker entladen als freigegeben, muss die Differenz vom Überschuss abgezogen werden.

Für base_power > 0 — der Speicher lädt — addiert dieselbe Zeile seine Ladeleistung zum Überschuss und gibt sie an die Fahrzeuge weiter.

Warum das den Modus um seine Zusage bringt

hysteresis_discharge wird im Zweig soc >= max_soc gesetzt und erst im Zweig soc < min_soc wieder gelöscht; im Band bleibt der Zustand unverändert. Der Speicher soll dort also bis maximal min_soc entladen werden dürfen — begrenzt auf die Leistung, die der Nutzer unter „erlaubte Entladeleistung" eingetragen hat.

Tatsächlich bekommt das Fahrzeug diese Freigabe plus die gesamte Ladeleistung des Speichers. Solange ein Fahrzeug lädt und die Leistung aufnehmen kann, kann der Speicher im Band also gar nicht mehr laden. Er läuft in Richtung min_soc und bleibt dort, auch wenn mittags wieder Überschuss da ist.

Beobachtbar an einem wechselhaften Tag: eine Wolke zieht den Speicher einmal ins Band, danach steigt der SoC nicht mehr — er driftet an min_soc entlang, bis das Fahrzeug fertig ist.

Der vorhandene min(…, absolute_bat_discharge_power) fängt das nicht ab: er begrenzt auf die freie AC-Ausgangsleistung des Wechselrichters und ist bei einem nicht hybriden Speicher float("inf") (siehe _absolute_bat_discharge_power()).

Der Nachbarzweig is False hat ein eigenes, gleichartiges Problem — bewusst nicht Teil dieses PRs, folgt separat.

Änderung

charging_power_left = min(required_absolut_discharge_power + min(0, base_power),
                          absolute_bat_discharge_power)

Nur der entladende Anteil zählt. Für base_power <= 0 ändert sich nichts.

Der Zweig oberhalb max_soc bleibt bewusst unangetastet: dort ist die Weitergabe gewollt, der Speicher soll über seine Grenze hinaus nichts horten.

Test

Ein bestehender Fall ändert seine Erwartung — das ist die eigentliche Verhaltensänderung, bitte gezielt draufschauen:

Fall (min_soc=50, max_soc=70, power_discharge=500)	soc	power	vorher	jetzt
Hysterese aktiv, Speicher lädt mit 400 W	60	+400	900	500

Dazu drei neue Fälle, die das Band vollständig abdecken:

Fall	soc	power	erwartet
Speicher ruht	60	0	500
entlädt innerhalb der Freigabe	60	−300	200
entlädt mehr als freigegeben	60	−700	−200

Die letzten beiden verhalten sich unverändert gegenüber master und sichern ab, dass der Fix nur den Ladefall trifft.

python -m pytest packages/control -q
  master:      17 failed, 467 passed
  dieser PR:   17 failed, 470 passed

Dieselben 17 Fehlschläge (ocpp_test.py, charge_template_test.py), sie bestehen auf master unverändert. flake8 sauber.

[seaspotter]

Issue dazu: #3980

Hab da aber einen besseren Vorschlag bereits zur Diskussion gestellt.

[s0170071]

@seaspotter Der Zweig ist ein anderer: dein Branch ändert hysteresis_discharge is False, dieser PR is True. Nach deinem Merge bleibt in is True bei ladendem Speicher + base_power stehen.

Praktisch heißt das: der Speicher kann im Abstieg nicht wieder steigen. Kommt die Sonne bei 90 % zurück, driftet er trotzdem auf 85 %, weil seine Ladeleistung ans Fahrzeug geht. Erst dort kippt das Flag und dein Code holt ihn zurück. Der Speicher wird also bei jeder Wolke garantiert bis zum Mindest-SoC leergefahren, auch wenn die Wolke nach fünf Minuten weg ist.

Dein Wiki-Argument („oberhalb Mindest-SoC hat das Fahrzeug Vorrang") trifft diesen Zweig allerdings genauso - insofern nehme ich das „Bugfix" im Titel zurück. Die Frage, die ich stattdessen stellen würde: ist es gewollt, dass nach deinem Fix im Aufstieg der Speicher Vorrang hat und im Abstieg das Fahrzeug? Wenn ja, schließe ich den PR und wir führen das in #3980 als Feature weiter. Wenn nein, ist das hier der symmetrische Gegenpart zu deinem Branch und sollte danach rein.

[seaspotter]

@s0170071 Ich würde für die symmetrische Variante plädieren - also #3985 nicht schließen, sondern als echten Gegenpart zu #3986 verstehen und mitnehmen. Ohne #3985 führt jede noch so kurze Wolke automatisch zum vollständigen Rundgang (runter bis Mindest-SoC, dann mit #3986 wieder komplett hoch bis Maximal-SoC), statt dass der Speicher mitten im Puffern kurz durchatmen und wieder steigen kann, sobald die Sonne zurück ist. Ein Design, bei dem der Speicher nur an den beiden Enden (unterhalb Mindest-SoC, oberhalb Maximal-SoC) Schutz hat und dazwischen bedingungslos ans Fahrzeug verliert, widerspricht meines Erachtens dem eigentlichen Zweck der Pufferfunktion.

Ehrlich gesagt habe ich dazu aber keine aus eigener Erfahrung fundierte Meinung - ich nutze "Entladung des Speichers erlauben" selbst nicht und kann daher nur aus der Code-/Konsistenz-Perspektive argumentieren, nicht aus echter Nutzung. Das ist am Ende auch eine Produktentscheidung, keine reine "Bugfix"-Frage - dafür würde ich gerne @LKuemmel und @ndrsnhs um eine Einschätzung bitten: Ist die asymmetrische Variante (Speicher gewinnt nur beim Aufstieg, Fahrzeug gewinnt immer beim Abstieg dazwischen) so gewollt, oder soll der Speicher auch mitten im Band vor kurzen Einbrüchen geschützt sein?

[s0170071]

Nur mal so als preview... hier fehlt noch ne PR, in der dann das Auto auf dem Mindeststrom gehalten wird und die Phasenumschaltung 3->1 unterdrückt wird wenn der (Haus) Akku puffert.
Dann noch eine Einschaltsperre unterhalb max_soc falls puffern nicht gereicht hat und doch ladestop war.

[seaspotter]

Nur mal so als preview... hier fehlt noch ne PR, in der dann das Auto auf dem Mindeststrom gehalten wird und die Phasenumschaltung 3->1 unterdrückt wird wenn der (Haus) Akku puffert. Dann noch eine Einschaltsperre unterhalb max_soc falls puffern nicht gereicht hat und doch ladestop war.

Meiner Meinung nach nicht, hab dir aber hier meine EInschätzung gegeben: #3980 (comment)

[ndrsnhs]

Um ehrlich zu sein kann ich der Argumentation noch nicht ganz folgen. Ich versuche mal das aufzudröseln.

hysteresis_discharge wird im Zweig soc >= max_soc gesetzt und erst im Zweig soc < min_soc wieder gelöscht; im Band bleibt der Zustand unverändert. Der Speicher soll dort also bis maximal min_soc entladen werden dürfen — begrenzt auf die Leistung, die der Nutzer unter „erlaubte Entladeleistung" eingetragen hat.

Der Nutzer gibt eine Entladeleistung des Speichers an. Also die Leistung mit der der Speicher entladen werden soll.

Tatsächlich bekommt das Fahrzeug diese Freigabe plus die gesamte Ladeleistung des Speichers.

Woraufhin er mit der eingestellten erlaubten Entladeleistung entlädt, richtig? Er wird also genau auf den erlaubten Wert "festgenagelt".
Man muss sich vergegenwärtigen, dass Ladeleistung des Speichers in diesem Szenario schlicht PV-Ertrag ist. Oberhalb des Max-SoC wird dem Speicher die Ladeleistung schon "geklaut" und dem Fahrzeug zugeschoben (EV-Vorrang). Damit regelt der Speicher ja im Idealfall auf 0 aus. Eine Entladeleistung zu erlauben verstärkt den Effekt indem der konfigurierte Wert, genau wie du sagst, zusätzlich aufaddiert wird.

Solange ein Fahrzeug lädt und die Leistung aufnehmen kann, kann der Speicher im Band also gar nicht mehr laden. Er läuft in Richtung min_soc und bleibt dort, auch wenn mittags wieder Überschuss da ist.

Genau, er darf bis zum minimalen SoC mitbenutzt werden. Wenn dieser Wert zu niedrig ist, kann er höher eingestellt werden.
Es kommt auch immer ein bisschen darauf an ob man das aus Fahrzeug oder Speichersicht betrachtet. Bisher hatte das Fahrzeug Vorrang, da wir eine Ladeintention unterstellen wenn es angeschlossen wird. Daher wurde von unten kommen zuerst ins EV geladen. Speichervorrang ist an der Stelle vielleicht etwas verständlicher auch wenn man über die Sinnhaftigkeit streiten kann das erst in den Speicher zu laden und von dort wieder ins Fahrzeug (Umwandlungsverluste).

Aber ja, das führt bei mittleren PV-Anlagen zu dem beschriebenen Verhalten:
Von oben kommend wird bis zum Min SoC entladen, Danach wird das Fahrzeug (bisher) im EV-Vorrang geladen, Speicher SoC steigt in der Zeit nicht. Nach Beendigung der Fahrzeugladung wird der Speicher geladen. Der Min SoC ist hier also die Garantie.

Mit dem PR von @seaspotter ändert sich die Logik dahingehend, dass der Speicher von unten kommen Vorrang erhält.

[s0170071]

So sah das bei mir heute aus. Man kann schön sehen, wie der Akku unterstützt, auch wenn kurze Verbrauchspitzen da sind. Dannach wird er wieder voll geladen (max_soc) und das Auto auf 6A gehalten.
Zum Abend hin bleibt er auch etwas länger auf 3p.
Keine 1p Umschaltung heute.