[Feature] Haus Akku zum Puffern bei Bewölkung verwenden.

[s0170071]

Konfiguration: bat_mode=min_soc_bat_mode, min_bat_soc=85, max_bat_soc=95, bat_power_discharge=1000, bat_power_discharge_active=true

Beobachtetes Verhalten
Speicher bei 95 %, Fahrzeug startet im PV-Modus, Speicher wird bei nicht genug Überschuss bis 85 % entladen, Ladung endet — soweit wie vorgesehen. Danach läuft das Fahrzeug bei ~86 % jedoch erneut an, statt abzuwarten, bis der Speicher wieder bei max_bat_soc ist. Der Speicher pendelt ab da knapp oberhalb min_bat_soc und erreicht max_bat_soc nie wieder. Die Hysterese durchläuft damit genau einen Zyklus und bleibt danach dauerhaft im unteren Zustand. Die Pufferwirkung des Speichers ist futsch.

Erwartetes Verhalten
Nach dem Unterschreiten von min_bat_soc sollte der Speicher wieder bis max_bat_soc laden dürfen, bevor er erneut als Puffer für die Fahrzeugladung herangezogen wird — sonst ist die obere Schwelle wirkungslos.

Ursache
In BatAll._get_charging_power_left(), Zweig „Speicher zwischen min und max SoC":
if self.data.set.hysteresis_discharge is False: charging_power_left = self.data.get.power

hysteresis_discharge is False bedeutet an dieser Stelle „wir kommen von unterhalb min_bat_soc, der Speicher soll sich erholen". Trotzdem wird seine aktuelle Ladeleistung als für Fahrzeuge verfügbar gemeldet. Der Algorithmus zieht sie ans Fahrzeug, der Speicher wird auf ~0 W geregelt und steht still. hysteresis_discharge wird aber ausschließlich oberhalb max_bat_soc wieder gesetzt — was damit nicht mehr eintritt.

Vorschlag
In diesem Zweig dem Speicher Vorrang geben, bis max_bat_soc erreicht ist, analog zum Zweig unterhalb min_bat_soc:
if self.data.set.hysteresis_discharge is False: charging_power_left = 0 self.data.set.regulate_up = True

Das lässt den unteren Zweig und die Entladefreigabe unberührt und stellt nur den Rückweg der Hysterese her.

[seaspotter]

Das beschriebene Verhalten entspricht allerdings der dokumentierten Spezifikation für "Mindest-SoC des Speichers" (Wiki): "Wird der Mindest-SoC überschritten, wird der Überschuss ins Fahrzeug geladen." Der Speicher muss laut Doku nicht erst wieder den Maximal-SoC erreichen, bevor der Überschuss wieder dem Fahrzeug zusteht - das ist also kein Bug, sondern das aktuell so vorgesehene Verhalten (auch durch einen bestehenden Test mit dem Namen "EV-Vorrang, keine Speichernutzung" abgesichert).

Das beschriebene Symptom (Speicher pendelt dauerhaft knapp über Mindest-SoC, Pufferwirkung geht verloren) ist damit zwar real, aber eine Konsequenz des dokumentierten Designs, kein Bug. Falls das aus deiner Sicht trotzdem schlechtes Verhalten ist, wäre das eher ein Feature-Vorschlag (z. B. eine echte Hysterese bis zum Maximal-SoC als Option) statt ein Bugfix.

[s0170071]

Hatte ich mir fast schon gedacht.
Ich hab das in meinem Branch schon implementiert. Funktioniert so:

1. Fahrzeug nicht laden bis Haus Akku auf 95% und >1,4 kW Überschuss (jetzt auch schon so)
2. Wolke kommt (PV Leistung weg): Akku puffert, Auto lädt weiter mit 6A (jetzt: lädt normal weiter, saugt Akku in Rekordzeit leer)
3. Wolke weg:
   bevor der Puffer bei 85% -> Auto lädt weiter bei 6A bis der Puffer wieder auf 95% (jetzt: Akku bleibt bei ca. 85% und driftet lustlos rum)
   nachdem abgeschaltet wurde: weiter bei 1.
4. Wolke nicht weg bevor Puffer leer: Fahrzeug Ladung stoppen , weiter bei 1. (jetzt: Ladung starten bei minSoC. Kein Puffer)

85% und 95% sind Min_SoC und Max_Soc. Hat sich bewährt. Gerade an wechselhaften Tagen kommt da deutlich mehr Energie ins Fahrzeug weil nicht ständig abgeschaltet wird und dann wieder gewartet.

Im Ergebnis wird der Haus Akku zwischen min und max gehalten aber so, dass man Wolken wegpuffern kann ohne die Ladung zu stoppen oder Phasen zu schalten. Damit fallen auch Wartezeiten weg.

[seaspotter]

Ich hab mir das nochmal genauer angeschaut (Code + Wiki-Doku, siehe oben) und einen Gegenvorschlag auf einem eigenen Branch gebaut: master...seaspotter:core:bat-hysteresis-recovery

Die Grundidee ist deine: regulate_up = True auch im Zweig hysteresis_discharge is False zwischen Mindest- und Maximal-SoC setzen, damit der Speicher nach einem Unterschreiten des Mindest-SoC wieder bis zum Maximal-SoC laden darf, bevor das Fahrzeug erneut Vorrang bekommt.

Umgesetzt hab ich das über eine neue Methode _charging_power_left_while_recovering(), statt die Zeilen direkt zu duplizieren - aus einem konkreten Grund: Der bestehende Code unterhalb des Mindest-SoC berücksichtigt bereits die Einstellung "Nur eine bestimmte Ladeleistung reservieren" (power_reserve/power_reserve_active) - wer die reservierte Ladeleistung nutzt, bekommt schon unterhalb des Mindest-SoC verbleibenden Überschuss fürs Fahrzeug. Mit einer reinen Kopie von charging_power_left = 0 hätte das für die neue Erholungsphase zwischen Mindest- und Maximal-SoC nicht gegolten - der Speicher hätte dort plötzlich alles bekommen, obwohl der Nutzer explizit eine reservierte Ladeleistung eingestellt hat. Durch die gemeinsame Methode verhält sich die gesamte Erholungsphase (von 0% bis zum Maximal-SoC) konsistent, egal ob man gerade unterhalb oder oberhalb des Mindest-SoC ist.

Da du deine Version schon im echten Betrieb getestet hast: passt das so mit deiner Erfahrung zusammen, oder gibt's da einen Unterschied zu dem, was du gebaut hast?

[s0170071]

Meine version basierte auf 2.1.9 und war ein wenig anders gestrickt. Ich hatte das Ladeende bzw. Phaasenumschaltung bei Hausakku > min_soc einfach unterdrückt. Nicht ganz sauber aber der Effekt war da und sehr deutlich. Gerade bei lockerer Bewölkung .

power_reserve ist der Punkt, den ich in meiner Fassung nicht sauber hatte. Die gemeinsame Methode ist richtig. Unterschiede gibt es, aber nur im Umfang: dein Branch ist Schritt 3 meiner Liste vom post oben (Erholung bis Maximal-SoC). Bei mir hängt daran noch:

• Schritt 2, das Halten: bei fehlendem Überschuss läuft das Fahrzeug auf Mindeststrom weiter statt abzuschalten — inkl. Unterdrückung der 3>1 Phasenumschaltung
• Schritt 4, Sofort-Stopp bei Unterschreiten des Mindest-SoC statt Abschaltverzögerung.
• Schritt 1, kein Neustart unterhalb Maximal-SoC — sonst zapft ein später eingesteckter Ladepunkt den Speicher an, der gerade erst am Erholen ist.

Das ist die Verhaltensänderung, über die zu reden ist; dein Branch ist die Vorbedingung dafür und für sich genommen schon die halbe Wirkung.

Eine Sache noch, unabhängig davon: der zweite Bandzweig (hysteresis_discharge is True, mit konfigurierter Entladeleistung) hat dasselbe Problem — bei ladendem Speicher wird + base_power addiert und die Ladeleistung ans Fahrzeug weitergereicht. Das ist #3985, ein Einzeiler. Beide fassen dieselben Zeilen in bat_all_test.py an, wer später merged rebased.

[seaspotter]

PR ist offen: #3986

Zu den anderen 3 Punkten aus deiner Liste, nachdem ich das nochmal genauer durchverfolgt habe:

Punkt 1 (kein Neustart unterhalb Maximal-SoC während der Erholung): ist mit #3986 bereits automatisch mit abgedeckt, kein zusätzlicher Code nötig. charging_power_left fließt über power_for_bat_charging() in Counter.calc_surplus()/calc_raw_surplus() - einen einzigen, gemeinsamen Überschuss-Topf, den Algorithm.calc_current() jeden Zyklus gleichförmig für alle Ladepunkte durchläuft (for cp in data.data.cp_data.values(): ...). Es gibt keinen Sonderpfad für einen neu angesteckten Ladepunkt, der diesen gemeinsamen Topf umgeht - er ist einfach ein weiterer Verbraucher desselben, während der Erholung bereits unterdrückten Werts.

Punkt 4 (Sofort-Stopp statt Abschaltverzögerung): hiervon würde ich bewusst abraten. switch_off_delay ist eine allgemeine, durchgängig aktive Einstellung für sämtliches PV-geführtes Laden (Ladeeinstellungen -> Überschuss), nicht Speicher-spezifisch, und genau dieselbe Verzögerung entscheidet in jedem anderen "Überschuss reicht kurzzeitig nicht"-Fall (Wolke, anderer Verbraucher startet, etc.), ob abgeschaltet wird. Würde man für den Speicher-Erholungsfall eine Ausnahme einbauen, die sofort statt verzögert abschaltet, wäre das Verhalten plötzlich uneinheitlich - je nachdem, WARUM der Überschuss gerade fehlt, würde unterschiedlich schnell abgeschaltet, obwohl für den Nutzer beide Fälle identisch aussehen ("kein Überschuss mehr da"). Das wäre schwer nachvollziehbar und inkonsistent zur sonstigen Abschaltlogik. Aus meiner Sicht ist die bestehende, bereits konfigurierbare switch_off_delay hier der richtige Hebel, nicht ein Sonderfall nur für diese eine Konstellation.

Punkt 2 (Halten auf Mindeststrom statt Abschalten/Phasenumschaltung): switch_off_check_threshold() prüft die Abschaltschwelle jeden Zyklus erneut, auch während die Verzögerung bereits läuft, und bricht die geplante Abschaltung ab, sobald wieder genug Überschuss da ist:

if control_parameter.state == ChargepointState.SWITCH_OFF_DELAY:
    if power_in_use + load.data.set.required_power < threshold:
        ...
        control_parameter.state = ChargepointState.CHARGING_ALLOWED

Eine 2-minütige Wolke bei ausreichend lang eingestellter switch_off_delay würde also nie zu einer tatsächlichen Abschaltung führen - keine Unterbrechung, kein Neustart, keine dadurch ausgelöste Phasenumschaltung.

Aber: das ist kein "je länger, desto besser"-Regler, sondern ein echter Zielkonflikt, der mit Punkt 4 zusammenhängt. Zu kurz eingestellt: genau dein beobachtetes Problem, häufiges Abschalten/Neustarten bei kurzen Schwankungen. Zu lang eingestellt: bei einem echten, länger anhaltenden Einbruch (nicht nur eine kurze Wolke, sondern zB durchgehend bedeckter Himmel für längere Zeit oder Abenddämmerung) zieht das Fahrzeug die komplette Verzögerung über Netzstrom, bevor überhaupt erkannt wird, dass kein Überschuss mehr da ist - das kostet unnötig Netzbezug und verzögert die korrekte Reaktion auf einen echten, nicht nur kurzfristigen Zustand. Der Sweet Spot liegt irgendwo bei "länger als die typische Wolkendauer bei dir, aber kurz genug, um auf einen echten Einbruch noch zeitnah zu reagieren" - eher ein Wert, den man an das eigene Wetter/die eigene Anlage anpasst, als eine allgemeingültige Zahl.

Mein Vorschlag: erstmal #3986 + #3985 laufen lassen und switch_off_delay gezielt auf die bei dir typische kurzfristige Schwankungsdauer abstimmen, bevor über einen fest programmierten Mindeststrom-Halte-Mechanismus nachgedacht wird - der wäre eine deutlich größere, allgemeinere Änderung (betrifft jede PV-Ladung, nicht nur den Speicher-Fall) und sollte eher eigenständig diskutiert werden, falls sich zeigt, dass eine gut abgestimmte Verzögerung allein nicht reicht.

[s0170071]

Switch on/off delay braucht. man mit der Akku Hysterese zum glück gar nicht mehr. Ich stell das auf 0.
Hat den angenehmen Nebeneffekt, dass Du bei voller Sonne anstecken kannst und es fängt direkt an zu laden. Also fast direkt. ;-)
Kann also drin bleiben, stört nicht.
Was ich so aus dem FF nicht beurteilen kann ist ob die Änderungen #3986 + #3985 das Auto bei höchstens 6A halten und die 3p->1p Umschaltung unterdrücken solange die Hausbatterie puffert. Das wäre noch zu prüfen.