Hausbatterie bei Netzladen nur zu 75% - Nicht gelöst!!

[username-must-be]

Evcc bietet die Möglichkeit die Hausbatterie aus dem Netz zuladen, wenn der Strom eine Preisgrenze unterschritten hat. Dabei wird der gesamte Speicher voll geladen.

Kann eine Einstellung mit im selben Fenster erfolgen um den Speicher aus dem Netz nur zu 75% zuladen?

Große Speicher möchte ich lieber mit PV Strom voll laden und mit Netzstrom nur zu 75%.

[mfuchs1984]

Welcher Speicher ist denn im Einsatz?

[hybe2022]

Aus dem Grund lade ich meinen HVM 22.1 auch selbständig über meine HA Automatisierung. Ich würde auch gerne nur die Hochentgeltphase überwinden und dafür den Speicher auf etwa 50-60% laden, wenn es günstig ist. Das geht leider mit evcc noch nicht.

[naltatis]

Du kannst das Ladelimit für deinen Speicher beschränken. Das muss allerdings über die Konfiguration des Gerätes stattfinden. Siehe Doku:

Optional kannst du einen maximalen Ladestand festlegen, bis zu dem die Batterie aus dem Netz geladen wird. Erreicht die Batterie diesen Wert, wird das Netzladen automatisch gestoppt. Die Option Maximaler Ladestand (maxsoc) findest du in der Gerätekonfiguration deines Batteriesystems.

https://docs.evcc.io/docs/features/battery#netzladen

[hybe2022]

Du kannst das Ladelimit für deinen Speicher beschränken. Das muss allerdings über die Konfiguration des Gerätes stattfinden. Siehe Doku:

Optional kannst du einen maximalen Ladestand festlegen, bis zu dem die Batterie aus dem Netz geladen wird. Erreicht die Batterie diesen Wert, wird das Netzladen automatisch gestoppt. Die Option Maximaler Ladestand (maxsoc) findest du in der Gerätekonfiguration deines Batteriesystems.

https://docs.evcc.io/docs/features/battery#netzladen

maxsoc ist weder in der UI, noch laut Docu in der yaml für den SMA STP SE verfügbar. Ich habe ein paar Batteriekonfiguration danach bei den advanced config geschaut und auch bei keinem maxsoc gefunden.
Es geht mir aber auch um keine generelle Konfiguratoren, sondern etwas dynamisches, welches ich in der UI anpassen kann (unter Hausbatterie - Netzladen), denn je nach Temperatur braucht es mehr oder weniger Prozent um die Hochpreisphase durch Ladung zuvor zu überbrücken...

[username-must-be]

Ich habe einen SMA Home Storage im Einsatz und bin mit Allem bei Hybe2022. Er spricht mir aus der Seele. 😊

Bitte keine festen Werte irgendwo, wo danach wieder erst der evcc Server neugestartet werden muss.

So einfach gestaltet wie beim Fahrzeug laden.

[mfuchs1984]

maxSoc und weitere Eigenschaften kann man in den jeweiligen Templates ergänzen, dann ist es auch über die UI verfügbar. Beispiel siehe #25979

[hybe2022]

Auch dann sind diese Werte generell definiert und bedürfen eines Neustart, da in der Konfiguration.
Besser wäre es diese Werte über die UI im Menü Hausbatterie einstellbar zu machen und so zur Laufzeit ändern zu können ohne einen Neustart durchzuführen...

Bei der Wallbox kann man auch die Ladeleistungen min und max zur Laufzeit, sowie maxsoc zur Laufzeit anpassen über das Dashboard. Dies wäre bei der Batterie über das Menü Hausbatterie möglich, in welches man auch aus dem Dashboard durch Drücken auf die Prozent gelangt...

[andig]

Dabei wird der gesamte Speicher voll geladen.

Das ist wieder so eine Behauptung die einfach mal in den Raum gestellt wird, ohne dass relevante Informationen- wie konkrete Konfiguration, Logfiles, etc - vorliegen.

Bei definiertem maxsoc wird die Ladung abgeschlossen. Das Thema hier ist gerätespezifisch umgesetzt. Für eine zusätzliche Globale Einstellungen wäre zu definieren, wie diese mit Geräteeigenschaften, wie auch dem Optimizer zusammen spielen soll.

Große Speicher möchte ich lieber mit PV Strom voll laden und mit Netzstrom nur zu 75%.

Verstehe ich nicht. Was ist an Netzstrom anders? Was ist der Use Case dafür?

[username-must-be]

Hallo andig,

dann hole ich mal ganz weit aus. "Voll geladen" heißt zum Maximum gefüllt, 100% der Batteriekapazität.

Nun zum User-Case:
Ich habe Nachts ein Zeitfenster von 5 Stunden (0-5 Uhr) mit einem Strompreis von ca. 16 Cent. Die restliche Zeit sind es ca. 29 Cent. Von der PV Anlage kostet mich der Strom ca. 8 Cent (Einspeisevergütung).

Wenn der Speicher leer (also das Gegenteil vom ersten Absatz, 0%) ist wird dieser zu erst für 16 Cent gefüllt, dies dauert eine gewisse Zeit. Zusätzlich möchte auch das E Auto um 5 Uhr bei 80% gefüllt sein. Wird die Hausbatterie nun so weit erweitert, dass das E-Auto nicht mehr bis 5 Uhr auf 80% geladen werden kann habe ich 29 Cent pro kWh.

Die Hausbatterie sollte nun nur soweit gefüllt (diesen Wert geben ich manuell vor) werden, dass sie bis ca. 8 Uhr überbrücken kann. Dann ist meist die Sonne da und übernimmt.

Die Batterie kann ab 8 Uhr auf 100% (voll geladen) werden.

Lieber andig, bitte nicht immer neue Ideen mit "Phrasen" abtun, dann hätten wir nicht das Feuer bändigen können 😉

Wenn für neue Ideen Konfigurationsdateien usw. benötigt werden, habe ich dies eventuell überlesen. Allerdings sind die meiner Meinung bei dieser Anregung überflüssig.

Ich bin für Alternative Ideen gern offen. Danke 😊

[andig]

Lieber andig, bitte nicht immer neue Ideen mit "Phrasen" abtun, dann hätten wir nicht das Feuer bändigen können 😉

Bitte vollständige Issues statt aus der Luft gegriffener Behauptungen. Spart allen Beteiligten viel Zeit!

[andig]

Die Hausbatterie sollte nun nur soweit gefüllt (diesen Wert geben ich manuell vor) werden, dass sie bis ca. 8 Uhr überbrücken kann. Dann ist meist die Sonne da und übernimmt.

Das ist also der UC. Danke.

[username-must-be]

OK, das ist mein UC. Mit dieser Funktion könnten andere Nutzer andere UCs haben.

Danke 😊

[ScumbagSteve]

Der UC ist für mich nachvollziehbar und bei mir ähnlich. Vielleicht kann man das Ganze jedoch noch etwas mehr abstrahieren und auch für andere UCs anwendbar machen.

Mal angenommen man hat einen komplett dynamischen Börsenstrompreistarif, dann könnte es theoretisch Tage geben, an denen der gesamte Tag unter der eingestellten absoluten Preisgrenze fürs Laden aus Netzspeicher liegt. Es ist daher schwer die Preisgrenze und auch den maxSOC allgemeingültig sinnvoll einzustellen.

Eigentlich möchten die meisten mit dieser Funktion ja genau das erreichen, was auch der issue Ersteller wünscht: Hochpreisphasen mit günstigen Netztrompreis überbrücken. Dieses Verhalten ist auch netzdienlich.

Wenn man das jetzt allgemeingültig lösen möchte wäre folgende Funktion ideal:

_Aus Netz laden um %Preisdifferenz zu überbrücken. _

Mal angenommen ich habe habe folgende Tagespreise:

0-5 Uhr: 16 Cent
5-20 Uhr: 20 Cent
20-22 Uhr: 25 Cent
22-0 Uhr: 23 Cent

Wenn meine Batterie eine Round-Trip-Efficiency von 85% hat, und ich noch Verschleiß berücksichtige, muss ich mindestens 20% Preisdifferenz haben damit ein Netzladen Sinn mache (für jeden individuell).

Wenn ich dem System nun vorgeben könnte, dass es ab 25 Prozent Preisdifferenz die Phasen durch Netzladen abfangen soll, würde es selbstständig entscheiden wann es Sinn macht zu laden (ähnlich wie das auch im Chargepoint Plan passiert). In diesem Fall müsste es von 0-5 Uhr so viel laden, um 20-0 Uhr zu überbrücken.

Allerdings müsste dafür der erwartete Stromverbrauch eines Zeitfensters, sowie der erwartete Pv Ertrag zuvor errechnet werden.

Stromverbrauch:
Entweder durch tatsächliche historische Aufzeichnung, oder durch Eingabe eines Wertes für den anzunehmenden Grundverbrauch.

Erwarteter Pv Ertrag: den haben wir ja bereits im forecast.

Mit so einer Lösung könnten auch dynamische Strompreise abgefangen werden.

Ist vielleicht eher was für ein epic, wenn man erst noch einen Grid forecast einführen muss, wäre aber inhaltlich eine wahnsinnig praktische Funktion und gemessen an der Netzdienlichkeit auch im big picture sinnvoll.

[mfuchs1984]

Diese usecases werden wohl vom im Entwicklung befindlichen Optimizer abgedeckt werden.
#23042

Um die Effekte zu sehen, müsst ihr #26147 (comment) umsetzen und den optimizer dann bei euch installieren / aktivieren. Gesteuert wird noch nichts, aber die Visualisierung zeigt schön das "was wäre wenn".

[andig]

Diese usecases werden wohl vom im Entwicklung befindlichen Optimizer abgedeckt werden.

@naltatis an ähnlicher Stelle hatten wir neue Limits immer wieder nicht mit Verweis auf Optimizer umgesetzt.

[hybe2022]

Fronius scheint ladeleistung nur in Prozent zu erlauben und keine entladeleistung.

So kann es aussehen, wenn verfügbar mit dem jeweiligen System.

[mfuchs1984]

Bitte beachten, dass viele Wechselrichter der Batterien erst bei erreichen der Reserveladung in den sleep gehen. Wenn man die Entladung also z.B. per Modbus blockiert und Soc > Reserveladung ist, bleibt der Wechselrichter dauerhaft aktiv und verbraucht mehr Strom.

Entladen blockiert evcc nur auf Wunsch beim Schnellladen, nicht im Normalbetrieb. minSoc ist nur eine Information für den Optimizer und sollte synchron mit den Einstellungen deines Batteriewechselrichters gehalten werden.

wo finde ich denn maxChargePower bzw maxDischargePower

Im nächsten release bei allen Batterien. Wenn es aktuell bei deiner Batterie nicht existiert, wird es keine Auswirkungen auf das Verhalten haben, sondern auch nur als Information für den Optimizer dienen, der wissen muss, mit welches Geschwindigkeit deine Batterie laden oder entladen kann.

[ScumbagSteve]

Verstehe, danke.
Genau, die Werte wären bei mir nur statistischer Natur für den optimizer. Den minSOC der Batterie gibt es in der aktuellen Version noch nicht in MQTT, richtig?

Im Winter wird meine Entladegrenze per ioBroker automatisch höher gesetzt, um den Akku zu schonen.

Sobald ich Grenze anpasse, muss ich also auch evcc mit den Infos versorgen - daher auch meine Frage zu MQTT.

[ansgarherkert]

Ich will socmin synchron mit meinen Stromkosten im Tagesverlauf variieren. Ich gehe davon aus, dass das nur über evcc.yaml geht. Gibt es dazu ein Beispiel/eine Beschreibung, die ich mir ansehen kann (Syntax etc.)?

Mir schwebt eine Konfiguration der Art vor:
months: Oct-Mar
days: Mon-Sun
hours: 0.00-6.30
socmin: 100
days: Mon-Sun
hours: 6.30-21.00
socmin: 40
days: Mon-Sun
hours: 21:00-00:00
socmin: 10
months: Apr-Sep
socmin: 20

[jkpr2qq42b-boop]

Hallo zusammen,
vorweg, ich bin neu hier und erst seit ca. 2 Monaten mit evcc unterwegs. Ich finde das tool und alles darum herum so GEIL!!!! großartige Leistung!!!!!

Ich habe die gleiche Herausforderung.

Ich habe auch einen zeitvariablen Stromtarif mit dynamischen Netzentgelt wo sich 5 Phasen unterschiedlicher Strompreise ergeben.
Deshalb würde, ich insbesondere im Winter, meine Hausakku in der günstigsten Preisphase gerne Zwangsladen und nur in der teuersten Phase entladen, die restlichen Phasen soll die Entladung gesperrt sein.
Für den Sommer schwebt mir vor, dass ich den Hausakku prognosenbasiert lade und entlade ... dies aber im zweiten Schritt ;-)

Wie setze ich die Entladesperre gut um?

Anlagenkonfiguration: SMA Tripower 10.0 SE Wechselrichter, SMA Homemanger 2.0, BYD HVM Hausakku

Aus meiner Sicht kann es mit "socmin" funktionieren, falls mein Wechselrichter dies zulässt. Dann möchte ich diese Werte aber nicht statisch vorgeben sondern über eine Berechnung immer den Wert für "socmin" schreiben, welche sich am Ende der einzelnen Stromphasen ergibt, oder? Die Entladungkapazität kann ja je nach Verbraucher unterschiedlich sein in den einzelnen Phasen.

Hat jemand hierfür schon eine funktionierende Lösung?

Liebe Grüße

[andig]

Converted to discussion since the actual request is no longer clear.

[premultiply]

Wie @mfuchs1984 schon schrieb beeinflusst minsoc derzeit in der Regel nicht die interne Konfiguration des Batterie-WR/Speichers, sondern ist rein informativ für evcc.

Theoretisch könnte man die in evcc eingestellten Werte aber auch bei aktiver Batteriekontrolle bei vielen Wechselrichtern in die entsprechenden Register schreiben.

Das Bedarf aber auch erstmal eines genauen Konzepts und Kenntnis der richtigen Register jedes einzelnen Modells und Anpassung aller entsprechenden Templates.

Da wäre ein Proposal der wahrscheinlich sinnvollste Anfang in dem der Zweck, Abgrenzungen, Limitierungen, notwendige Änderungen, Use cases usw. zunächst erfasst und zusammengefasst werden.

[ScumbagSteve]

Ich habe da schon eine gute Vorstellung wie sowas integriert werden könnte. Kann ich heute Abend mal in Ruhe dokumentieren.

Wie erstelle ich so ein Proposal? Als Feature Request? Oder erst mal hier zusammenfassen und diskutieren?

[ansgarherkert]

Ich bin auch neu hier, kann mich aber gerne auch bei der Erstellung eines Konzepts beteiligen (oder auch etwas anderes machen, das hilft).

Bzgl. der Register hat der von den meisten in der aktuellen Diskussion genutze Hybridwechselrichter (SMA SE) ein entsprechendes Register. Mir ist aber nicht klar, ob das ein Register ist, das auch hochfrequent geschrieben werden darf oder ob dann der Speicher schnell kaputt ist (gemäß SMA Doku gibt es 2 Arten von Registern). Wäre also ein neues und potentiell riskantes Feature, das für alle relevanten Systeme zu implementieren ist.

Es gibt in meinen Augen aber eine viel einfachere Möglichkeit. Ich hatte mir folgende Implementierung vorgestellt:
evcc bietet die Möglichkeit beim EV-Laden die Nutzung des Speichers zu unterbinden. Diese bestehende Funktion könnte genutzt werden, um bei Unterschreiten eines socmin eine weitere Entladung zu unterbinden.
Damit wären keine neuen Features bei der Steuerung der Hybridwechselrichter/Batteriesysteme zu implementieren und - so hoffe ich - die Funktion eines socmin leicht zu implementieren.

Ist das ein Weg, den wir gehen können?

[ansgarherkert]

Hallo,

hier ein Spezifikationsvorschlag.

@premultiply
Ich denke, die bisherige Variable socmin ist nicht unbedingt mit der hier vorgeschlagenen identisch. Diese könnte unverändert als Information vorliegen und widerspiegeln, was im Wechselrichter/BMS hinterlegt ist. Hier wird dann eine neue socmin (könnte man z.B. "socminControl" nennen) vorgeschlagen/implementiert. Der Einfachheit halber habe ich hier aber auch das Wort socmin verwendet.

Vorraussetzung/Annahme
evcc kann jetzt schon das Entladen vom Speicher beim Schnelladen unterbinden. des Weiteren ist bei einigen Wechselrichtern auch das Laden aus dem Netz über evcc steuerbar. Diese Funktionalitäten möchte ich im Folgenden nutzen.
Ich gehe davon aus, dass das Laden der Hausbatterie bei Solarüberschuss immer funktioniert und durch evcc nicht unterbunden wird.

Spezifikation als Pseudocode

boolean allowBatteryDischarge # angenommene Variable in evcc für die Hausakku-Entladesperre beim Schnelladen des Fahrzeuges
boolean allowBatteryGridCharge # angenommene Variable in evcc für die Steuerung des Netzladens der Batterie
integer BatterySOC # SOC der Batterie

Bei jedem Interval (also z.B. alle 30 Sek., bei denen evcc alle Stati prüft und Aktionen ausführt) auszuführen:

#socmin
if (BatterySOC <= socmin) or (allowBatteryDischarge = false) then
         --bestehender Code, um Entladen der Batterie zu verhindern
else
         --bestehender Code, um Entladen der Batterie zulassen
end if

#socmax
if (BatterySOC >= socmax) or (allowBatteryGridCharge = false) then   
        --bestehender Code, um Laden der Batterie aus dem Netz zu verhindern 
else
        --bestehender Code, um Batterie aus dem Netz zu laden
end if 

Für die Konfiguration wird allgemein gewünscht, dass socmin und socmax im Tagesverlauf automatisch geändert werden können. Die Konfiguration sollte also analog zu der Konfiguration der Stromtarife erfolgen können. Wäre dann analog so etwas:

battery:
    zones:
      - months: Oct-Mar
        days: Mo-So
        hours: 0-6 # Niederpreisphase
        socmin: 100 # Speicher kann in der Zeit nur geladen werden
        socmax: 80 # Falls der Speicher doch nicht ganz voll geladen werden soll
      - months: Oct-Mar
        days: Mo-So
        hours: 6-17.30 # Normalpreisphase
        socmin: 40 # Speicher kann zwischen 40% und 100% SOC liegen, je nach Verbrauch und PV Produktion 
      - months: Oct-Mar
      - days: Mo-So
        hours: 17:30 - 24 # Hochpreisphase von 17:30-21:00 und Normalpreisphase von 21:00-24:00
     -  socmin: 10 # Speicher kann bis auf die Notstromreserve genutzt werden und wird erst in der Niederpreisphase wieder geladen

Eine Erweiterung wäre, das auch an variable Strompreise koppeln zu können. Das ist aber dann eine komplizierte Optimierungslogik, die erst im 2. oder 3. Schritt überlegt werden sollte, wenn auch ein Optimierter vorliegt. Für viele Use Cases ist das auch nicht nötig oder eher kontraproduktiv.

Use Cases
Für meinen Use Case benötige ich nur ein socmin aber andere benötigen auch ein socmax.

Die Steuerung mit socmin/socmax ist bei stark variablen Strompreisen (insb. EWG §14a Modul 3, Tibber etc.) und einer großen Batterie sowie großen Verbrauchern im Laufe des Tages sinnvoll (insb. Wärmepumpen).
Sollte der Speicher zu klein sein, um garantiert bis zur nächsten Niederpreisphase den gesamten Bedarf aus der Hausbatterie decken zu können, dann ist Nutzung von socmin sinnvoll.
Sollte der Speicher so groß sein, dass beim Netzladen noch Kapazität für PV-Laden vorgehalten werden soll, dann ist die Nutzung von socmax sinnvoll.

In meinem Fall (Nutzung EWG §14a Modul 3) ist die Preisdifferenz zwischen Hoch- und Niedrigpreis 16 ct. Somit ist Laden der Batterie in der Niedrigpreisphase und Verbrauch in der Hochpreisphase immer sinnvoll. Entsprechend soll die Batterie in der Niedrigpreisphase auf 100% geladen werden und bei Bedarf in der Normalpreisphase noch Netzstrom bezogen werden, um sicherstellen zu können, dass die Hochpreisphase immer aus der Batterie überbrückt werden kann.

Offen:
Mir ist nicht klar, wie bei mehreren Batterien zu verfahren ist (für mich nicht relevant, habe nur 1 Batterie).
Mein Ansatz wäre den von evcc gerechneten Durchschnitts-SOC zu verwenden und alle steuerbaren Batterien bei Erreichen des socmin zu blockieren bzw. bis socmax die steuerbaren zu laden. Die nicht steuerbaren würden dann aber potentiell weiter entladen oder geladen werden können und der Durchschnitts-SOC sich dann weiter verändern.
Alternativ könnten socmin/socmax je Batterie individuell definiert und gesteuert werden. Die nicht steuerbaren wären dann außen vor.

[premultiply]

Wir möchten eigentlich nicht unnötig weitere Variablen/Optionen einfügen.

[ansgarherkert]

Klar. Wenn das mit der bestehenden Variablen geht, ist das natürlich die beste Lösung. Wollte nur anmerken, dass es nicht die bestehende sein muss, falls das zu Problemen führen sollte.

Ich hoffe, der Vorschlag ist verständlich und nicht zu kompliziert zu implementieren. Wenn ich noch irgendwas beitragen/tun kann, gerne.

[ScumbagSteve]

Ich finde den Vorschlag ganz interessant. Ich hatte mir den Tag über auch mal Gedanken gemacht, jedoch eher hin zu einer Optimierungslogik, nicht hauptsächlich der Datenstruktur. Ich habe dabei jedoch gemerkt wie schwierig es ist da mit einer Struktur alle Use-Cases abzufangen.
Schon alleine der Unterschied zwischen Börsenstrompreis und Fixed-Tarif (wie bei dir) ist so groß, weil man beim einen gut mit festen Werten arbeiten kann und beim anderen eigentlich nur relative Vorgaben geben kann.

Ich mache etwas ähnliches wie du aktuell über ioBroker. Da ist es recht simpel umzusetzen.
Was mir bei deinem Entwurf aufgefallen ist:

1. Was bringt es im Zeitfenster 1 SocMin auf 100 zu setzen, und max auf 80?
   Wenn man die Wechselrichter mit SocMin per Modbus auf 100 ansteuern würde, würden diese sofort mit dem Zwangsladen beginnen, solange der SOC < ca. 98 ist. Zwangsladung dann bis 100% erreicht wäre.
   Welchen Effekt hat das SocMax dabei?

2. Direkte Nutzung in Zeitfenster 2
   Wenn ich deinen Fall richtig verstanden habe, würde das System im Zeitfenster 2 sofort anfangen von 100 -> 40% zu entladen. Ich kenne deine individuellen Preise nicht, aber meist ist eine NT Netzladung nur sinnvoll, wenn man sie zu HT Zeiten entlädt (in deinem Beispiel 17:30 - 24:00 Uhr) sinnvoll. Der Unterschied NT - ST ist nicht groß genug um die Round-Trip Effizienz und Akku-Degradation zu kompensieren.

3. PV Ertrag innerhalb des Tages
   Wenn man davon ausgeht, dass NT Ladung nur für HT Zeiten vorgehalten wird, müsste man eigentlich einfließen lassen ob der Akku nicht ohnehin bis 17:30 durch PV Ertrag den benötigten Ladestand erreicht. Dann würde wieder der Optimizer in Spiel kommen.

Wenn man einfach immer zur NT Zeit (nachts) den Akku auf 100% lädt und dann bis Abends vorhält, hat man an bewölkten Tagen überhaupt nichts vom Akku. Man muss eigentlich immer noch die erwartete Rest-Akkuladung in die Rechnung miteinbeziehen, um festzustellen ob eine vorausschauende Zwangsladung Nachts/Morgens überhaupt Sinn macht.

Oder wie siehst du das?

@premultiply eventuell macht es Sinn, so wie ihr verschiedene Device-Templates anbietet, auch verschiedene Optimizer-Templates anzubieten. Dann könnte sich jeder User das für ihn geeigneteste Template zur Optimierung raus suchen und ihr seid flexibel jederzeit neue/komplexere Optimierungsalgorithmen zu ergänzen.
Die Basis sollte immer der Optimizer-Forecast sein, die Templates würden sich dann nur darin unterscheiden, welche Action daraus abgeleitet wird, bzw. inwiefern der Optimizer überhaupt zur Aktion berücksichtigt wird. Nutzer von ioBroker oder HASS könnten sich dann z.B. ein Template zur externen Steuerung (z.B. ähnlich wie das @ansgarherkert vorgeschlagen hat) raus picken und verwenden.

[ansgarherkert]

Hi Steve,

klar Börsenstrom vs. feste Sprünge macht einen Riesenunterschied. Ich denke, eine einfache Logik (für feste Sprünge) lässt sich erstmal leicht implementieren und man kann damit auch experimentieren. Die komplexe Lösung kann dann im Nachgang kommen, denn da kann die implementierte Steuerung dann vom Optimierer genutzt werden.

Zu den Punkten:

1. Ich schlage nicht vor, dass im Wechselrichter irgendwelche Zielwerte geändert werden sollen. Es soll mit SocMin nur ein ENTLADEN unter diesen Wert verhindert werden. Somit bedeutet SocMin von 100 nur, dass nicht entladen werden soll. Das schafft evcc ja auch beim Schnellladen ohne eine Akkuladung auszulösen. Das Netzladen kann bei mein Wechselrichter (SMA SE) nicht von evcc gesteuert werden (warum, weiss ich nicht). Ich kann das aber über das SMA Portal konfigurieren. Der Wechselrichter wird also nachts Netzladen starten und bei einem gesetzten SocMax (für mich nicht relevant, gehe auf 100%) würde dieser Ladevorgang dann von evcc gestoppt werden - das geht aber ggf. auch nur bei Wechselrichtern, die evcc komplett steuern kann. Generell ist SocMax für mich keine relevante Funktion. Aber wenn andere das haben wollen, warum nicht.

2. Meine Preise sind so, dass die Niedrigphase ca. 9 ct günstiger ist als normal und die Hochphase noch mal ca. 6 ct teuer. Für mich ist also ein Entladen der Batterie auch in der Normalphase sinnvoll. Daher will ich mit einem SocMin arbeiten und teilweise in der Normalphase die Batterie verwenden. Ich will aber verhindern, dass in der Normalphase geladen werden muss, um die Hochphase zu überbrücken. Das macht ökonomisch keinen Sinn. Daher der gewünschte Mindestladestand zu Beginn der Hochphase.

3. Das ganze gilt nur für die Monate Oktober bis März. Ich habe zwar eine große PV und Batterie aber mein Verbrauch ist im Winter hoch. Da läuft die Wärmepumpe die ganze Zeit und auch sonst habe ich viele Verbraucher (IT etc.). Sind um die 2-3kWh tagsüber (je nach Temperatur). Da die Niedrigphase um 6:00 endet habe ich garantiert 3 Stunden Verbrauch habe bevor die PV überhaupt starten kann (also schon 6-10kw aus dem Akku). Und im Winter habe ich eh selten eine Produktion über 2/3kWh (vielleicht ein paar Stunde mittags). Ein Laden des Akkus kommt daher nur in Ausnahmefällen vor und ist nicht planbar, da auch der Hausverbrauch täglich/stündlich stark schwankt. Das könnte auch ein Optimierer nicht hinbekommen. April bis September sieht das ganz anders aus. Da habe ich sowieso keinen Netzbezug und es ist auch nichts zu optimieren. Ich weiss nicht wie es bei dir ist aber bei mir in der Nähe von Frankfurt/Main habe ich im Winter meist sehr trübe Tage und trotz 33 kWP auf dem Dach viel zu wenig Ertrag.

Bin generell skeptisch, ob sich das mit variablen Strompreisen wirklich lohnt. Zumindest diesen Winter waren die Preisschwankungen meist nicht so groß wie bei meinen variablen Netzentgelten und da spielen die Speicherverluste eine größere Rolle. Auch muss dann dein Verbrauch sehr planbar sein. Bei mir müsste ich mit Wetterdaten etc. einen komplexen Algorithmus für die Wärmepumpe entwickeln sowie das unstete Verhalten der Bewohner (sehr flexible Nutzung von home office und Büro) irgendwie als große Unbekannte abpuffern. Habe da lieber eine einfache Lösung, bei der ich ausnahmsweise auch mal ein paar kWh einspeise.

[ansgarherkert]

@premultiply

Als Neuling kenne ich evcc noch nicht so gut... Ich bin beim Lesen der Doku auf ein paar Punkte gestoßen, die darauf hindeuten, das bereits bestehende Funktionalität für meinen Use Case genutzt werden könnte.

Habe verstanden, dass Parameter limitsoc von evcc auf den aktuellen SOC gesetzt wird, um beim Autoladen ein Entladen des Speichers zu verhindern. Was passiert, wenn limitsoc auf einen Wert unterhalb des aktuellen SOC gesetzt wird? Wird dann ein Entladen bis zum Erreichen des Werts erlaubt? Was passiert, wenn kein Ladevorgang läuft? Wirkt dann limitsoc auch und unterbindet generell die Entladung?
Je nach Implementierung wäre limitsoc bereits die Lösung oder es könnte auf dieser Basis wahrscheinlich relativ leicht eine Steuermöglichkeit erstellt werden, die den Use Case abdeckt.

des Weiteren gibt es den Parameter batterymode mit "normal", "hold" und "charge". Wie ist das genaue Verhalten der Hausbatterie bei diesen Modi? Ich kann das aus der Doku nicht erkennen. Meine Vermutung:
"hold": kein Entladen der Batterie (egal ob durch Autoladen oder Hausverbrauch)? PV-Laden vom Wechselrichter geht?
"normal": Batterie wird vom Wechselrichter gesteuert und würde sowohl Hausverbrauch wie Autoladen mit Batterie bedienen?
"charge": das gleiche wie "normal"? Oder was ist der Unterschied?
In MQTTExplorer wird bei mir derzeit batterymode als "unknown" angezeigt. Batterie ist gerade am im Wechselrichter festgelegten Minimum. Ist das daher ein weiterer Zustand für den Parameter? BatteryDischargeControl ist "true".

Mein Batteriewechselrichter ist ein SMA 10.0 SE.

Vielen Dank.

[ansgarherkert]

Hallo,

ich habe jetzt mein "Problem" per homeassistant gelöst. Das setzen des evcc batterymode über MQTT hat bei mir nicht funktioniert (liegt wahrscheinlich an meinem Unwissen...). Ich nutze jetzt eine Dummy-Wallbox in evcc, mit der homeassistant die Batterie auf "hold" stellen kann, wenn nicht entladen werden soll. Funktioniert, ist aber unschön. Jedenfalls kann homeassistant so die Hausbatterie in einem SOC-Fenster, das über den Tag variiert, halten.

Ich denke aber, dass eine Funktionalität in evcc, mit der die Hausbatterie zeitabhängig in einem bestimmten SOC-Rahmen gehalten wird, wirklich sehr hilfreich wäre. Sobald bidirektionales Laden unterstützt wird, wird eine solche Funktionalität sicher auch angefragt werden.

Beim bidirektionales Laden würde ich für mein Auto auch einen SOC-Rahmen definieren wollen, innerhalb dessen eine Nutzung des Speichers zum Laden und Entladen erlaubt ist. Diesen SOC-Rahmen würde ich abhängig von Tag und Zeit variieren wollen. Zum Beispiel wäre es für mich werktags OK, wenn das Auto von 17:00-24:00 auf einen SOC von 20% entladen werden darf. Ab 6:00 will ich aber mindestens 50% haben.

Innerhalb diesen zeitvariablen Rahmens kann dann automatisch von evcc ein optimiertes Laden/Entladen in Abhängigkeit von den Strompreisen realisiert werden.

Aus meiner Sicht ist eine Hausbatterie genauso zu behandeln und zu steuern wie eine Autobatterie, die für bidirektionales Laden genutzt wird und es wäre toll, wenn evcc das unterstützen würde.

[andig]

Laden bis soc ist umgesetzt.

[username-must-be]

Hallo, laden bis SOC gilt nun für das Laden aus dem Netz und dem Laden von der eigenen PV-Anlage?
Das wäre falsch, denn an der eigenen Anlage soll der Speicher immer zu 100% geladen werden!!!

Der Use-Case bezieht sich nur auf die Einrichtung eines SOC für das Netzladen!!!

[hybe2022]

Maxsoc wird allerdings als Parameter in der Konfiguration der Batterie/Inverter gesetzt und erwartet dann einen Neustart.
Besser wäre man könnte den Parameter unter Hausbatterie zur Laufzeit verändern ohne Neustart oder dann eben von außen...

[andig]

Und zu welchem Zweck brauchts das?

[hybe2022]

Die use cases wurden bereits mehrfach hier erläutert.
Dynamische Netzentgelte oder Tarife und somit Überbrückung der Hochtarifphase mit der Batterie durch zu voriges Laden während der Niedertarifphase...

Ich steuere das Batterieladen und - entladen über Homeassistent. Das kommt sich nun halt mit de Sperre während des Schnellladens oder Plans in die Quere oder man kann dies nicht in evcc nutzen. Die Batteriesteuerung sollte halt nur von einer entity erfolgen.
Das geht aber aktuell nicht...

[hybe2022]

Das wurde auch schon zuvor erklärt. Man muss nur soviel aus dem Netz laden, um die Hochphase zu überwinden und das ist natürlich dynamisch aufgrund der Entladung (z.B. WP/Außentemperatur) und des PV Überschuss, da dieser vorrangig in die Batterie soll.

[andig]

Wunderbarer Anwendungsfall für den Optimizer. Wir möchten zwischendurch keine weiterem Knöpfe einbauen die sich später erübrigen oder per API ohnehin umgesetzt werden können.

[ansgarherkert]

Gibt es eine Anleitung, wie man den Optimizer installieren und konfigurieren kann? Ich würde den natürlich gerne verwenden, wenn er passende Funktionalitäten bereitstellt.

Ich habe leider nicht viel (für mich als Endanwender nutzbarer) Doku gefunden, nur ein paar Github chats. Habe ihn zwar in Docker auf meiner Synology prinzipiell zum Laufen gebracht (bekomme mit Port 7050 die Spezifikation der Schnittstelle angezeigt), kann ihn aber nicht ansprechen und der Optimizer ist im evcc Menü nicht auswählbar. (Tariffs habe ich in evcc angelegt, experimental ist an.)

[ScumbagSteve]

Den optimizer docker brauchst du gar nicht unbedingt. Evcc hat das auch gehostet.

Wichtig ist, dass die optimizer url (die von evcc oder deine lokal gehostete im Docker) im evcc Docker mit der Umgebungsvariablen hinzugefügt wird.

Die variable heißt EVOPT_URI und dort muss dann deine optimizer Adresse rein. Z.B. http://192.168.1.7:7050

Optimizer ist aber derzeit read only und führt noch keine Aktionen durch.

[ansgarherkert]

Vielen Dank. Ich habe die Umgebungsvariable in Docker angelegt (getestet mit lokalem evopt und mit dem bei evcc und sowohl mit als auch ohne 7050). Bekomme aber dennoch keinen Optimizer im evcc Menü angezeigt.
Hier meine Docker Konfiguration:

Hier meine Konfiguration der Tarife in evcc:

tariffs:
  currency: EUR # (default EUR)
  grid: # Preis für Netzbezug
    type: fixed
    price: 0.31 # EUR/kWh
    zones:
    - days: Mon-Sun
      hours: 0-6
      price: 0.31
    - days: Mon-Sun
      hours: 17-21
      price: 0.30
  feedin: # Einspeisevergütung
    type: fixed
    price: 0.08 # EUR/kWh (positive Werte = Einnahme)
  solar:
    - type: template
      template: forecast-solar
      lat: 48.4
      lon: 12.7
      dec: 30
      kwp: 24.5
      az: 180

Die Konfiguration der Tarife ist nicht meine "echte" Anlage. Das werde ich ändern, wenn es läuft...

[ansgarherkert]

@andig

Ich habe jetzt den Optimizer zum Laufen gebracht und etwas experimentiert. Ganz interessant aber natürlich fehlt noch die Steuerungsmöglichkeit. Bisher sehe ich auch nur ein Optimieren des Autoladens und nicht der Hausbatterie (liegt aber vielleicht auch an meinen Testeinstellungen).

Wann plant ihr voraussichtlich eine erste Version mit Steuermöglichkeit zum Testen zur Verfügung zu stellen? (Nur als ganz grobe Idee; mir ist klar, dass ihr sicher nichts versprechen wollt, was dann vielleicht doch nicht haltbar ist und ich will auch niemanden festnageln oder mich beschweren, wenn es später wird oder vielleicht sogar nie kommt.)

[loeffelpan]

Ich klinke mich hier mal ein.
Hab die letzten Tage viel über den Optimizer gelesen und hab das Feature bei mir jetzt aktiviert und sehe den "Vorschlag". Heute Nacht zum Beispiel würde der Optimizer den Hausspeicher auf 50% laden wollen, um morgen tagsüber mit ein wenig Solarertrag über den Tag und die folgende Nacht bis zum nächsten NT-Zeitfenster zu kommen. Auto ist nicht angeschlossen und hat keinen Ladeplan.
Insofern optimiert der Optimizer sehr wohl auch das Laden der Hausbatterie unabhängig vom E-Auto.

Ich freu mich drauf, wenn das einen produktiven Stand erreicht hat und wirklich zum Einsatz kommen kann.

[ansgarherkert]

Hallo Loeffelpan,

ja, finde ich auch super interessant und bin freudig gespannt. Ich hoffe aber sehr, dass man (wie hier erbeten) einen SOC "Sicherheitsrahmen" (min/max) festlegen kann, in dem der Optimizer arbeiten darf, und der über den Tag variiert werden kann, um schwankende Strompreise abzubilden.

Zumindest bei mir ist der Verbrauch vielfältig und schwer vorhersehbar. Wir haben eine große PV mit Speicher, 3 E-Autos mit 3 Wallboxen, Wärmepumpe, viele IT Systeme und eine sich spontan ändernde home office Nutzung/Kochverhalten. Damit ist der tägliche Stromverbrauch schwer vorhersehbar. Somit ist es bei uns (und wahrscheinlich auch bei vielen anderen) wichtig, dass man einen SOC "Sicherheitsrahmen" festlegen kann.

Final geht es bei mir als Optimierungsziel vor allem darum, dass ich vor Zeiten hoher Strompreise genug Strom aus einer Niedrigpreisphase oder von der PV in der Hausbatterie habe, um die teure Zeit zu überbrücken. Ob ich in Zeiten moderat schwankender, normaler Strompreise etwas mehr oder weniger verbrauche, macht keinen großen Unterschied und ein Speichern des Netzstroms in der Hausbatterie ist dann auch nicht ökonomisch. Wenn aber bei einer zu aggressiven Optimierung doch teurer Strom bezogen werden muss, weil ein ungeplanter Verbrauch notwendig ist, dann ist die ganze Mühe wieder verpufft oder es wird sogar teurer als ohne Optimierung.

Wie sieht es eigentlich mit der Güte der PV-Vorhersage aus? Zumindest bei uns habe ich diesen Winter feststellen müssen, dass Wetterbericht und das tatsächliche Wetter durchaus unterschiedlich waren (viele nicht vorhergesagte Wolken und Nebel).

[username-must-be]

Hallo,
der Optimizer soll wahrscheinlich später die gesamte Steuerung übernehmen.

Ist eventuelle eine einfache manuelle Übersteuerung der vom Optimizer vorgegebenen Werte vorgesehen?

Scheinbar kann der Optimizer gut 95% der Anwendungsfälle abdecken.

Für die restlichen 5% wäre der Programmieraufwand zu groß und ein händisches Eingreifen einfacher und sinnvoller.