Entladesperre Hausbatterie solange dynamischer Tarif kleiner als Schwellwert ist

[chris-ka1]

ich nutze die Funktion Netzladen der Hausbatterie. Dies funktioniert einwandfrei und ist im Winter sehr hilfreich.
Ich setzte eine untere Schwelle und lade die Hausbatterie wenn der Tarif unter dem Schwellwert liegt.

Nachdem der Tarif über dem Schwellwert liegt fängt die Batterie sofort an ihre Energie wieder abzugeben.

Optimal wäre es hier zusätzlich eine obere Schwelle zu definieren um die geladene Energie erst dann bereitzustellen wenn der dynamische Tarif oberhalb einer Schwelle liegt.

Beispielszenario Dunkelflaute: (Ist so passiert am 12.12.2024)
in der Nacht geht der dynamische Tarif für 4h auf 30ct/kWh runter. Für den nächsten Tag ist ein Tarif von über 1€/kWh ab 15Uhr angekündigt.

Ich würde nun gerne ein Intervall definieren mit einer unteren und oberen Schwelle. Liegt der Tarif under der unteren Schwelle wird die Hausbatterie über das Netz geladen (das funktioniert aktuell bereits bestens). Solange der Tarif zwischen der unteren und oberen Schwelle liegt ist eine Entladesperre der Hausbatterie aktiv (das wäre die neue Funktion) die Batterie gibt dann erst ihre Energie ab wenn die obere Schwelle überschritten ist.

Dadurch kann sichergestellt werden, dass die Batterie noch Ladung hat wenn der Peak kommt.

[andig]

Ich bin nicht sicher ob es diese Logik braucht da die Ansteuerung der Schwelle ohnehin dynamisch passieren müsste. Stattdessen- und das würde viel mehr use cases ermöglichen- könnten wir auch den Battery Mode (hold/charge) direkt von extern ansteuerbar machen?

/cc @naltatis

[naltatis]

könnten wir auch den Battery Mode (hold/charge) direkt von extern ansteuerbar machen?

Damit wäre ich vorsichtig. Würde ein einmaliges Setzen von außen dann jegliche Logik in evcc blockieren? Starten einer Schnellladung. Unterschreiten eines Preislimits? Würdest du einen "manuellen Modus" einführen bei dem unserer Automatismen alle aus sind?

Ich verstehe den Usecase, aber für mich gehört das in die Diskussion #16364 und die konkrete Lösung wäre für mich abhängig davon wie wir uns für den nächsten Schritt "Netzladen der Batterie" Entscheiden.

[VolkerK62]

@chris-ka1 unabhängig einer internen Lösung, gibt es jetzt schon einen workaround
https://github.com/evcc-io/evcc/wiki/aaa-Lifehacks#entladung-eines-steuerbaren-hausspeicher-preisgesteuert-oder-manuell-sperren

[andig]

Würdest du einen "manuellen Modus" einführen bei dem unserer Automatismen alle aus sind?

Ja. Das wäre Wiederverwendung der Battery-APIs. Alternativ zum "manuellen" Modus: der (externe) Modus bleibt einmalig so lange stehen bis evcc eine Modusänderung durchführen möchte (Preisschwelle über/unterschritten, Fahrzeugladung gestartet/beendet, Neustart).

Es gab schon mehrere Themen die sich über ein API lösen liessen.

[naltatis]

Aus meiner Sicht können wir gerne eine "manuelle Steuerung" einführen. Ich würd die dann aber von unseren jetztigen Regeln/Automatismen (Preislimit, Schnelladen) trennen. Sonst können wir das in der UI nicht sauber kommunizieren.

Wir könnten /batterymode/[auto|charge|hold] machen. Default wäre auto (wie jetzt). Wenn charge oder hold gesetzt ist übersteuert das die Preislimit und Schnellade-Regeln. In der UI würde ich an den entsprechenden Stellen dann einen Hinweis einblenden.

[iseeberg79]

Ich finde eine Implementierung interessant und habe mir in den letzten Wochen dazu einige Gedanken gemacht, viele davon sind auch in der Diskussion zum weiteren Vorgehen der Netzladungsfunktion diskutiert worden.

Vielleicht kann man "auto" umgehen, indem man die externen Vorgabe zeitlich befristet, ähnlich wie bei der Batteriesperre vieler Wechselrichter. Dann würde das externe System regelmäßig den Zustand auffrischen und evcc muss nur prüfen, ob ein Zustand innerhalb eines Zeitintervalles vorgegeben wurde, ansonsten kann der externe Modus vernachlässigt werden (entspricht "auto").
Das hätte m.E. zwei Vorteile:

1. die in der API gültigen Zustände für den Batteriemodus brauchen keine Erweiterung und
2. ein extern gesetzter Zustand gilt nicht "ewig" und würde externen Steuerungen weniger "Vertrauen" aussprechen

Die Vorgabe von "charge" braucht es nicht zwingend, schadet aber m.E. auch nicht. Meist hat man bei der externen Berechnung, welcher Zustand gerade richtiger ist, den Preis berücksichtigt und kann den leicht für die bestehende API nutzen. Die zeitliche Befristung des externen Zustandes macht eine Rücksetzung des Netzladelimits unnötig, was praktisch wäre. Extern braucht dann nur hold und charge gesetzt werden.

Die Steuerung sollte per HTTP und MQTT API möglich sein.

Eine weitere Anmerkung am Rande:
Einige Wechselrichter ermöglichen im "hold" keine PV-Ladung, da die Ladungsleistung für die Netzladungsfunktion gesteuert werden muss. Das ist unproblematisch für die Schnellladung ("now"), da die überschüssige Leistung meist verwendet werden wird. Für die "Wintersperre" bei günstigem Netzstrom, bzw. um die gespeicherte Energie der Batterie zeitverzögert wirtschaftlich zu nutzen, ist es gelegentlich von Nachteil. Meist ist die Wintersonne unzureichend, sodass es selten zu Einspeisungen kommen wird. Ich hatte jetzt jedoch schon mehrfach die Situation, die Batterie tagsüber günstig mit PV laden (ca. 2/3 der maximalen Kapazität) und zeitversetzt entladen zu können. Ich denke, das muss hier vernachlässigt werden...

[andig]

Das ist unproblematisch für die Schnellladung ("now"), da die überschüssige Leistung meist verwendet werden wird. Für die "Wintersperre" bei günstigem Netzstrom, bzw. um die gespeicherte Energie der Batterie zeitverzögert wirtschaftlich zu nutzen, ist es gelegentlich von Nachteil.

Wenn das eine Einschränkung der Möglichkeiten des Geräts ist dann bleibt als Alternative nur die Entladesperre nicht zu verwenden.

Vielleicht kann man "auto" umgehen, indem man die externen Vorgabe zeitlich befristet,

@naltatis hatte bereits vorgeschlagen, entweder extern gesteuert oder auto. Das ist klar und eindeutig.

[iseeberg79]

Vielleicht kann man "auto" umgehen, indem man die externen Vorgabe zeitlich befristet,

@naltatis hatte bereits vorgeschlagen, entweder extern gesteuert oder auto. Das ist klar und eindeutig.

Klar und gut, versteht es bitte als Anregung zu vermeiden, das ein extern gesetzter Zustand verwaist/veraltet und ich es bevorzugen würde, diesen irgendwann seitens evcc ungültig zu machen. Bei der Implementierung würde dies "auto" dann zu einem internen Zustand von evcc machen, denn es ist nur relevant, ob von extern gesteuert wurde.