You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature] Haus Akku zum Puffern bei Bewölkung verwenden. #3980
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.
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.
Hatte ich mir fast schon gedacht.
Ich hab das in meinem Branch schon implementiert. Funktioniert so:
Fahrzeug nicht laden bis Haus Akku auf 95% und >1,4 kW Überschuss (jetzt auch schon so)
Wolke kommt (PV Leistung weg): Akku puffert, Auto lädt weiter mit 6A (jetzt: lädt normal weiter, saugt Akku in Rekordzeit leer)
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.
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.
changed the title [-][BUG] min_soc_bat_mode: Speicher erreicht max_bat_soc nicht mehr, sobald ein Fahrzeug lädt — Hysterese läuft nur einmal[/-][+][Feature] Haus Akku zum Puffern bei Bewölkung verwenden. [/+]on Sep 20, 2026
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?
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.
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.
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.
Activity
seaspotter commentedon Sep 19, 2026
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 commentedon Sep 20, 2026
Hatte ich mir fast schon gedacht.
Ich hab das in meinem Branch schon implementiert. Funktioniert so:
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.
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.
[-][BUG] min_soc_bat_mode: Speicher erreicht max_bat_soc nicht mehr, sobald ein Fahrzeug lädt — Hysterese läuft nur einmal[/-][+][Feature] Haus Akku zum Puffern bei Bewölkung verwenden. [/+]seaspotter commentedon Sep 20, 2026
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 = Trueauch im Zweighysteresis_discharge is Falsezwischen 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 voncharging_power_left = 0hä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 commentedon Sep 20, 2026
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:
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 commentedon Sep 20, 2026
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_leftfließt überpower_for_bat_charging()inCounter.calc_surplus()/calc_raw_surplus()- einen einzigen, gemeinsamen Überschuss-Topf, denAlgorithm.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_delayist 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 konfigurierbareswitch_off_delayhier 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:Eine 2-minütige Wolke bei ausreichend lang eingestellter
switch_off_delaywü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_delaygezielt 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 commentedon Sep 21, 2026
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.