Dynamischer Tarif: nicht verstanden, Idee oder Request?

[hackfred64]

Mein Szenario:

• SMA PV Anlage (STP mit SHM 2, BYD Speicher)
• Zaptec Go Wallbox
• dyn. Tarif (Tibber)
• evcc perfekt am laufen!

Mein Problem (?): ich kann mein Auto nur während der Nacht laden

Aktuell:

• der Speicher wird über den Tag mit PV geladen
• nachts (geplant über den Tibber Preis) wird das Auto geladen
• ich kann in evcc wählen ob der Speicher dabei gesperrt, oder aber entladen wird

Mein Wunsch:

• auch der Speicher wird in der Nacht für das Laden vom Auto genutzt, aber nur bis xyz % entladen damit der das Haus, bis ich genügend PV Überschuss habe, weiter aus dem Speicher versorgt wird (weil morgens der Strom im Bezug gerade teuer ist).

Die Frage von mir:
bin ich zu blöd und habe einfach die Einstellungen zur Batterienutzung nicht verstanden?
Oder ist das tatsächlich ein Use Case der von evcc noch nicht abgedeckt ist?

Aktuell kann ich entweder den Speicher sperren, dann gehe ich mit 35% SoC vom Speicher in den Tag und fange mittags an einzuspeisen.
Oder ich gebe den Speicher während der Nacht zum Laden vom Auto frei. Der Speicher wird dann aber komplett entladen und das Haus geht, bis genügend PV vom Dach verfügbar ist, in den Bezug.

Daher als Zusammenfassung für meinen Wunsch: ich kann vorgeben bis zu welchem SoC vom Speicher das Auto geladen werden kann, damit ich mit dem Rest das Haus versorgen kann bis genug PV Überschuss vorhanden ist.

Und am Ende: hab ich es einfach nicht verstanden (wie in evcc die Konfiguration für den Speicher dann sein muss), ist das eine Idee (die noch niemand hatte) oder sollte das ein Request werden?

Oder ist das ein evcc Bug, dass der Speicher (obwohl ich 10% fürs Haus reserviert habe), komplett entladen wird...

[mdkeil]

So wie Du das haben möchtest, ist es noch nicht möglich.. wird aber bereits diskutiert. Die Batterieeinstellungen gelten halt nicht beim "schnell-laden" oder für den Planer, wo dann ebenfalls "schnell-laden" genutzt wird. Die aktive Batteriesteuerung (wenn aktiviert) verhindert hierbei das Entladen der Batterie.

[hackfred64]

Alles klar, Danke für die Klarstellung denn dann muss ich nicht weiter spekulieren!
Was mir als temporäre Lösung durch den Kopf geht: ich kann doch über das API zwischen den beiden Modi (Batterieunterstützung aus/ein) umschalten. Wenn ich mir den aktuellen SoC vom Speicher hole kann ich doch bei < xyz% den Speicher sperren!? Nur so als Idee ...

[VolkerK62]

Die Batteriesperre von extern per API bedarfsgerecht ein/aus schalten. Könnte funktionieren.
Wobei du das evtl vorher ausprobieren solltest.
Was passiert, wenn die Sperre ein und aktiv (hold) ist und du die Option dann ausschaltest?
Hoffentlich wird dann alles auf normal zurückgestellt.

[hackfred64]

Das ist genau das was ich mich frage, probieren, und sehen möchte was dann passiert.
Wenns klappt: Bingo!
Ich werde berichten ;-)

[hackfred64]

Also der erste Versuch (mit NodeRed auf das API zugegriffen) heute Nacht hat problemlos funktioniert. "Für kleines Tibber Geld" über evcc gesteuert den Ladevorgang gestartet. Dann aber bis herunter auf 25% SoC den Speicher entladen, dann in den Netzbezug gegangen, und nachdem die Autobatterie geladen war das Haus weiter über den Speicher gespeist.

[mdkeil]

witzigerweise sieht meine Node-Red Steuerung im Ergebnis sehr ähnlich aus, nur dass ich ausschließlich parametergesteuert die Entladeleistung der Batterie regle.. ich geh z.B. in der Nacht bis max 30% SOC runter und gebe den Rest in den teuren Stunden (meist ab 06:00) frei..

[hackfred64]

Tatsächlich, das ist lustig! Jetzt war ich schon stolz den Speicher überhaupt geschaltet zu bekommen (hat auch die zweite Nacht ohne erkennbare "Seiteneffekte" funktioniert). Und nun legst Du die Latte direkt noch einmal höher ;-)
Wie steuerst Du die Entladeleistung, über welches Interface?
Da ich immer noch sehr mit dem Wirkungsgrad meines Inverters hadere wäre das ein sehr spannendes Thema. Wobei der Algorithmus dahinter, also die Kombination mit dem dynamischen Tarif zur Steuerung der Entladeleistung, die nächste Stufe in der Komplexität wäre!

[hackfred64]

Man könnte ja phantasieren: PV prognosebasiert und den Tibber Tarif für den Morgen einbeziehend, den Rest-SoC auf minimalen Bezug zu berechnen. Dafür braucht es eigentlich nur zwei der vier Grundrechenarten, komplex wird es aber trotzdem! ;-)

[mdkeil]

Victron MP lässt sich halt wunderbar via mqtt steuern bzw. über vorgefertigte node red flows, die bereits im large image von venusOS enthalten sind.