Home battery discharge control

GrimmiMeloni commented 10 months ago

Overview

Disable home battery discharge during fast mode/planner charging. The intention is to prevent home battery draining while a car is charging. The use case arises either during winter, or when charging at night based on planner. There's prior art in multiple forms (either through messaging or mqtt). However, the general ask comes up time and again, see #5826, #7979, #9090, https://github.com/evcc-io/evcc/discussions/9301, and probably more, so I feel it makes sense to drive towards "standardization" and I am willing to donate my time to do the required groundwork.

The way to keep the battery from discharging is vendor specific. Depending on capabilities of battery hardware the behavior can be achieved either through simple enabling/disabling the battery discharge, or controlling the discharge power of the battery, or by pinning the SOC of the home battery.

For clarity: Independent from the way the discharge is prevented, it generally means that ALL power for the home will be taken from the grid , not just the car charge.

Assumptions

This feature only makes sense if the HEMS system does not provide this natively (or am I missing something?)
Battery control is applied site wide (we could allow „low energy“ load points like bike chargers to opt out in a later iteration)
Only works with 1 single battery (like the rest of evcc currently does)
Smart Charging of Batteries is considered a related but different use case and will not be covered in the initial implementation.

Deliverables

a generic interface for battery discharge control
implementation of required logic in evcc's main control flow
an example implementation of the interface based on Tesla Powerwall (as that's what I own and can test)

The intention is that ideally others can further contribute implementations of the interface for other hardware going forward.

Control Flow

Site controls the battery discharge as part of the interval
Check site has battery discharge control enabled, if not end here
Decide on required battery discharge control as follows
- for each loadpoint, check
  - If it is charging, AND
  - If the charge mode is either fast, or the planner is active 
- If all above conditions are met for at least one loadpoint, battery discharge should be disabled
- If not, battery discharge should be enabled
- perform enable/disable operation as determined  
  Configuration
  
  Site.batteryDischargeControl = true

Battery specific configuration options will differ, depending on how control is achieved, for example

Default / reset values, that represent „unlimited“ state if these are not static (e.g. Tesla power wall emergency reserve 20%)
Specific authentication options for battery control (e.g. tesla PW needs additional cloud API tokens to control battery discharge)
 other specific things that cannot be hardwired into the batteries' implementation

Config Validation

site needs to do a config sanity check on boot up, to ensure that configured battery support discharge control if the global switch for battery control is set
the battery must check for required (optional, type specific) config values if the discharge control is enabled for the site

API

BatteryDischarge // optional interface implemented by Batteries
- Enable(bool) 
- Enabled() bool //indicates if battery is currently allowed to discharge

Notes

For „simple“ batteries (like the Powerwall), any value for SetLimit() (other than -1) would equal a limit of 0, i.e. discharge is completely disabled.
We could also make the interface more speaking, by replacing the magic value -1 with a dedicated Unlimited() instead.
If helpful (for UI, or messaging?), we could also have GetLimit() int on the interface

Other considered but scratched solutions

There was an idea to control the discharge power of the battery, trying to matching home’s power consumption as closely as possible (this would limit grid usage to car charging, while home power is still covered by the battery). This was rejected for now, as it is unclear if this might lead to increased wear of the flash memory of the hardware.
The above idea was also causing a need for a slightly different interface referred to as SetLimit(limit int). This was replaced by the binary Enable(bool) shown above, as the current scope does not require more.

orthoenergy commented 10 months ago

Great idea, that‘s what I’m waiting for. Enhancement for flexible tariff like Tibber to charge home battery during cheap periods is then next step to make it perfect even for less solar energy periods (winter…). I own a Sonnenbatterie Eco 8 and can switch modes and charge/discharge or stop it manually and in time periods as well with local api.

andig commented 10 months ago

Gibt es neue Informationen zu verfügbaren Geräte-APIs? Sonst hat sich an wontfix m.E. nichts geändert.

orthoenergy commented 10 months ago

Die Sonnenbatterie-API ist z.B. hier hinterlegt falls noch nicht bekannt:sonnenBatterie APIjlunz.github.ioGrüße AndreasAm 18.10.2023 um 22:28 schrieb andig @.***>: Gibt es neue Informationen zu verfügbaren Geräte-APIs? Sonst hat sich an wontfix m.E. nichts geändert.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

deadrabbit87 commented 10 months ago

Kostal hier: https://www.kostal-solar-electric.com/de-de/produkte/solar-wechselrichter/-/media/document-library-folder---kse/2020/12/15/13/38/ba_kostal-interface-description-modbus-tcp_sunspec_hybrid.pdf

GrimmiMeloni commented 10 months ago

Tesla Powerwall: https://www.teslaapi.io/energy-sites/commands

andig commented 10 months ago

Ich hab die Apis nicht durchgeschaut, klingt aber, als hätten wir jetzt eine kritische Masse 👍🏻

/cc @premultiply

Kalie15 commented 10 months ago

SolarEdge: https://www.photovoltaikforum.com/core/attachment/88445-power-control-open-protocol-for-solaredge-inverters-pdf/

Ab Seite 17. Register F704 ist per default 1, muss auf 0, dann tut die Batterie nix mehr. Oder man kann mit Wert 4 dann mit Prozenten fein tunen, aber dass sie weder lädt noch entlädt ist nachts für mich genau das Richtige.

danmel42 commented 10 months ago

Sungrow SHxRT https://github.com/bohdan-s/SunGather/issues/36#issuecomment-1157528051

Seite 23, Register 13051. Ich meine mich zu erinnern dass dafür zusätzlich noch Register 13050 in den Forced Mode geschaltet werden muss.

TTXaser2 commented 10 months ago

Weiss auch einer was von SMA/Sunny Island?

WisManue commented 10 months ago

Für SMA / Sunny Boy Storage bin ich auf folgenden Foreneintrag mal gestoßen:

Da gab es ähnliche Versuche das mit iOBroker zu steuern.

https://openwb.de/forum/viewtopic.php?t=3342

Sieht mir so aus, als ob das schon in die Richtung geht, auch wenn ich das nicht selbst bewerten kann.

premultiply commented 10 months ago

Wir überlegen gerade wie man ein solches Feature eventuell(!) in evcc einbauen könnte. Problematisch ist nach wie vor dass da jeder Hersteller sein eigenes hochproprietäres Süppchen kocht und wie daraus erstmal eine generische und somit herstellerübergreifende, interne Schnittstelle definieren müssten welche dann angesprochen wird.

Daher ist eine möglichst konkrete Sammlung der bekannten Einflussmöglichkeiten auf die Speicherentladung an dieser Stelle natürlich sehr wertvoll.

Darüber hinaus habe ich aber bei vielen der bekannten/genutzen Schnittstellen grundsätzlich noch Bedenken was die dauernde automatisierte Betätigung bzw. Änderung der Register (=Speicherstellen) in den Wechselrichtern betrifft. Ich gehe erstmal davon aus, dass die Verwendung dieser Register zumindest in einigen Fällen nicht dafür vorgesehen ist und somit u.U. den dahinterliegenden internen Flashspeicher kaputtschreiben könnte...

Gut möglich, dass diese Bedenken unbegründet sind aber man sollte dies zumindest einmal geprüft (ggf. beim Hersteller erfragen) und berücksichtigt haben bevor die teuren Gerätschaften am Ende wegen sowas ausfallen. Auch hier sind wir voll auf eure gemeinschaftliche Zuarbeit angewiesen.

GrimmiMeloni commented 10 months ago

[...] wie daraus erstmal eine generische und somit herstellerübergreifende, interne Schnittstelle definieren müssten welche dann angesprochen wird.

Einen ersten Aufschlag dazu hoffe ich mit meinem opener Posting bereits erledigt zu haben.

Darüber hinaus habe ich aber bei vielen der bekannten/genutzen Schnittstellen grundsätzlich noch Bedenken was die dauernde automatisierte Betätigung bzw. Änderung der Register (=Speicherstellen) in den Wechselrichtern betrifft. Ich gehe erstmal davon aus, dass die Verwendung dieser Register zumindest in einigen Fällen nicht dafür vorgesehen ist und somit u.U. den dahinterliegenden internen Flashspeicher kaputtschreiben könnte...

Das ist ein richtig guter Punkt. 💡 Danke!

Zumindest für ein einfaches An/Aus würde ich erstmal keine Probleme sehen, da die Anzahl der Schreibvorgänge überschaubar bleibt. Das wäre jeweils nur am Anfang und am Ende eines Ladevorgangs ein Aufruf. Aber wenn wir auch meinen Vorschlag umsetzen das Entladelimit der Batterien dynamisch zu regeln (so fern unterstützt), würden wir mit jedem Intervall schreiben (müssen). Da kommt die Schreibrate definitiv zur Geltung, und ich wäre auch eher zurückhaltend - zumindest so lange nicht klar ist, was der Hersteller dazu sagt.

Für einen ersten Wurf wäre es aber auch ausreichend, zunächst nur den An/Aus Fall zu implementieren. Das ist zumindest en-par mit dem was wir hier aktuell alle extern durch Scripting umsetzen, hätte aber den Vorteil das es für mehr Anwender verfügbar ist. Und wir müssen nicht alle individuell die Regellogik erfinden.

Ich werde vielleicht am Wochenende mal Zeit haben für ein wenig Prototyping.

andig commented 10 months ago

Erstmal brauchts use cases. Danke.

Kalie15 commented 10 months ago

Erstmal brauchts use cases. Danke.

Hätte da einen... und ich bin nicht der Einzige mit dem "Problem" ;-)

https://github.com/evcc-io/evcc/discussions/10394#discussioncomment-7323823

GrimmiMeloni commented 10 months ago

Erstmal brauchts use cases. Danke.

Reicht das oben genannte nicht? (Keine Batterieentladung bei Fast Mode oder PV mit aktivem Planner)

andig commented 10 months ago

Wäre das immer so? Für alle Ladepunkte einschliesslich Steckdosen und Wärmepumpen? Für alle Anwender? Abhängig von irgendwas? Konfigurierbar?

deadrabbit87 commented 10 months ago

Erstmal brauchts use cases. Danke.

Reicht das oben genannte nicht? (Keine Batterieentladung bei Fast Mode oder PV mit aktivem Planner)

Und bei smartCostActive.

Mein Usecase ist, das ich das Register 1034 im Kostal WR auf 0 setze wenn planActive oder smartCostActive true ist und der SoC des Hausspeichers kleiner 50%.

andig commented 10 months ago

Und warum bei 50? Was erreichst du damit?

deadrabbit87 commented 10 months ago

Ich will, dass morgens, wenn der Strom wieder teurer wird (Tibber), der Speicher nicht leer ist.

Aber dennoch den selbst erzeugten Strom so gut wie möglich nutzen.

Wobei ich das auch mit den aktuellen Möglichkeiten von evcc auch lösen könnte mit den Einstellungen zum Stromspeicher in der UI.

mdkeil commented 10 months ago

Bei Victron lässt sich das sowohl über Register als auch via MQTT (stufenlos) regeln.. Das mache ich meistens nachts, wenn ich die Autos günstig nachlade oder wenn am Tage die Auto dran hängen bei ungenügend PV Überschuss aber via smartcost schnell geladen werden.

thebrainkafka commented 10 months ago

Solarmax max.storage / max.storage ultimate https://www.solarmax.com/wp-content/uploads/MAX.STORAGE_ModbusTCP_Datenpunktliste-1.pdf

GrimmiMeloni commented 10 months ago

Und warum bei 50? Was erreichst du damit?

Hier wäre es möglich bufferSoc wiederzuverwenden. Der Schwellwert ist ja immer noch der gleiche ("bis hierhin darf mein Auto aus dem Hausakku geladen werden"), lediglich die Aktion beim Überschreiten des Werte ist anders (Auto Ladung stoppen, vs. Batterie Entladung stoppen).

andig commented 10 months ago

Es wäre super hilfreich, nicht zuerst über die Wiederverwendung von Parametern zu sprechen, sondernd darüber, was der Anwender erreichen, nicht was er einstellen will. Die Ansätzen mit „ich brauche da einen Knopf“ führen bei so einem komplexen Thema zu keinen guten Lösungen.

thebrainkafka commented 10 months ago

Erreichen. Bei mode "schnell" inkl. "smart charging" die Möglichkeit haben die Hausbatterie nicht zu nutzen. Hausbatterie also nicht entladen in diesen modes.

GrimmiMeloni commented 10 months ago

Es wäre super hilfreich, nicht zuerst über die Wiederverwendung von Parametern zu sprechen, sondernd darüber, was der Anwender erreichen, nicht was er einstellen will. Die Ansätzen mit „ich brauche da einen Knopf“ führen bei so einem komplexen Thema zu keinen guten Lösungen.

Ja, aber das haben wir doch schon. In den Situationen in denen "Schnell" (oder wegen meiner mit hohen Strömen) geladen wird, möchten Anwender nicht das Ihre Hausbatterie zum Laden des Fahrzeugs verwendet wird. Vielleicht ist mein Anwendungsfall ja auch zu 1-dimensional, und ich denke nicht weit genug. Für mich ist dieser MVP (siehe Annahmen oben, 1 Loadpoint, 1 Batterie) mehr als ausreichend definiert, und könnte basierend auf dem initialen Posting direkt umgesetzt werden. 80/20 Rule.

andig commented 10 months ago

möchten Anwender nicht das Ihre Hausbatterie zum Laden des Fahrzeugs verwendet wird.

Deshalb frage ich ja nach Use Cases. Oben gab es durchaus differenziertere Szenarien.

Mvp ist super. Aber können wir den allen Anwendern aufzwingen? Anscheinend nicht. Hinter welches Regelwerk oder Konfiguration wollen wir ihn dann stecken?

Einfach ein „lockBattery“ mit Kommentar in der Config? Ein API dazu damit es von außen aufrufbar wird? Erfreulicherweise würde das die sitePower Berechnung nicht beeinflussen :)

Randbedingung: es muss auch sicher gestellt sein, dass so eine „gesperrte“ Batterie nur gegen Entladung gesperrt ist, aber nicht gegen Ladung.

orthoenergy commented 10 months ago

Für Nutzer mit variablen Stromtarifen (diese werden perspektivisch mehr werden) wäre es hilfreich, nicht nur die Hausbatterie zu stoppen bei preisabhängigem Laden des Fahrzeugs sondern auch zusätzlich die Option zur Ladung der Hausbatterie einzubauen, insbesondere wenn der zu erwartende PV-Ertrag nicht ausreicht (Winter). Preis niedrig/Winter o. schlechte PV-Prognose: Schnellladen von Pkw und HausbatterieSommer/gute PV-Prognose: - keine Ladung/Entladung während Schnellladung- Entladen der Hausbatterie zusätzlich bis zu einem festgelegten SOC (Rest zur Hausnutzung morgens bis die Sonne wieder scheint) um den Eigenverbrauch zu optimieren Bei der Gelegenheit würde ich auch gern priorisieren, welches Kfz oder Ladepunkt von der Hausbatterie unterstützt werden darf. Szenario: Oma ist zuhause und kann tagsüber direkt laden-Speichernutzung nicht erwünscht, der Wagen der Gattin muss wegen Berufstätigkeit nachts geladen werden. Grüße AndreasAm 20.10.2023 um 08:00 schrieb andig @.***>: Mvp ist super. Aber können wir den allen Anwendern aufzwingen? Anscheinend nicht. Hinter welches Regelwerk oder Konfiguration wollen wir ihn dann stecken?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

GrimmiMeloni commented 10 months ago

Für Nutzer mit variablen Stromtarifen (diese werden perspektivisch mehr werden) wäre es hilfreich, nicht nur die Hausbatterie zu stoppen bei preisabhängigem Laden des Fahrzeugs sondern auch zusätzlich die Option zur Ladung der Hausbatterie einzubauen,...

Das ist genau der Use Case den ich hier NICHT betrachte (Hausbatterie Ladung steuern). Wie das Posting zeigt, erfordert das ganz andere Betrachtungen und ist ein gänzlich anderer Fall. Bitte separat diskutieren.

deadrabbit87 commented 10 months ago

Und warum bei 50? Was erreichst du damit?

Hier wäre es möglich bufferSoc wiederzuverwenden. Der Schwellwert ist ja immer noch der gleiche ("bis hierhin darf mein Auto aus dem Hausakku geladen werden"), lediglich die Aktion beim Überschreiten des Werte ist anders (Auto Ladung stoppen, vs. Batterie Entladung stoppen).

Ich finde diesen Vorschlag hier super. Würde genau meinem Use Case entsprechen.

Randbedingung: es muss auch sicher gestellt sein, dass so eine „gesperrte“ Batterie nur gegen Entladung gesperrt ist, aber nicht gegen Ladung.

Das wird, zumindest bei Kostal, dann nicht so einfach. weil man über das Register 1034 nur Lade- oder Entladeleistung vorgeben kann. Negative Werte für Ladung und positive für Entladung.

Mir ist aber der Einwand glaub ich schon klar, unter Umständen wäre ja der Fall, dass man will, dass der Speicher über PV geladen wird und das Auto trotzdem aus dem Netz lädt. Es wäre aber für mich zu verschmerzen, dass das nicht erfüllt wird.

Zumindest in meinem Fall tritt das kaum ein.

GrimmiMeloni commented 10 months ago

Einfach ein „lockBattery“ mit Kommentar in der Config? Ein API dazu damit es von außen aufrufbar wird?

Ja, so hatte ich es erstmal vorgeschlagen. Einfach auf Site Ebene, ganz global sagen das Batterie Entladung geregelt werden soll.

Erfreulicherweise würde das die sitePower Berechnung nicht beeinflussen :)

Ja, Berechnung muß gleich bleiben, dass sollte aber auch gegeben sein. Wäre ja eher ein Fehler im (bereits existierenden!) Battery Meter wenn dieser Leistung angibt, obwohl die Batterie "abgeklemmt" ist. So fern hier keine Fehler vorliegen, sollte eine deaktivierte Batterie sich genauso auf die Berechnungen auswirken, wie eine entladene -> 0W.

AlexJoda commented 10 months ago

Für Nutzer mit variablen Stromtarifen (diese werden perspektivisch mehr werden) wäre es hilfreich, nicht nur die Hausbatterie zu stoppen bei preisabhängigem Laden des Fahrzeugs sondern auch zusätzlich die Option zur Ladung der Hausbatterie einzubauen, insbesondere wenn der zu erwartende PV-Ertrag nicht ausreicht (Winter). Preis niedrig/Winter o. schlechte PV-Prognose: Schnellladen von Pkw und HausbatterieSommer/gute PV-Prognose: - keine Ladung/Entladung während Schnellladung- Entladen der Hausbatterie zusätzlich bis zu einem festgelegten SOC (Rest zur Hausnutzung morgens bis die Sonne wieder scheint) um den Eigenverbrauch zu optimieren Bei der Gelegenheit würde ich auch gern priorisieren, welches Kfz oder Ladepunkt von der Hausbatterie unterstützt werden darf. Szenario: Oma ist zuhause und kann tagsüber direkt laden-Speichernutzung nicht erwünscht, der Wagen der Gattin muss wegen Berufstätigkeit nachts geladen werden. Grüße AndreasAm 20.10.2023 um 08:00 schrieb andig @.>: Mvp ist super. Aber können wir den allen Anwendern aufzwingen? Anscheinend nicht. Hinter welches Regelwerk oder Konfiguration wollen wir ihn dann stecken? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.>

Für Nutzer mit variablen Stromtarifen (diese werden perspektivisch mehr werden) wäre es hilfreich, nicht nur die Hausbatterie zu stoppen bei preisabhängigem Laden des Fahrzeugs sondern auch zusätzlich die Option zur Ladung der Hausbatterie einzubauen,...

Das ist genau der Use Case den ich hier NICHT betrachte (Hausbatterie Ladung steuern). Wie das Posting zeigt, erfordert das ganz andere Betrachtungen und ist ein gänzlich anderer Fall. Bitte separat diskutieren.

Sehe ich nicht so! Wenn die Ladung der Hausbatterie gestartet wird verhindert das auch automatisch das Entladen von dieser. Ich mache das z.Z. alles sehr umständlich manuell weil EVCC das nicht kann und deshalb im Winter nur sehr eingeschränkt nutzbar ist.

Die beste "Tibber-Zeit" ist zwischen 3-5 Uhr nachts. Da schalte ich die Hausbatterie (Huawei Luna) per Scheduler auf "Laden". Zusätzlich nutze ich diese Zeit um das BEV aufzuladen. Dazu muss man dann den API Zugriff von EVCC auf die Wallbox sperren und auch dort einen Scheduler in der Wallbox-Software (go-E) programmieren, weil es keine Scheduler in EVCC gibt.

Wäre alles lösbar wenn EVCC per API auf den Wechselrichter/Hausbatterie zugreifen und das aktiv steuern würde. Dann wäre EVCC wirklich eine vollumfänglich Lösung für das Home-Energiemanagement...

mdkeil commented 10 months ago

Dazu muss man dann den API Zugriff von EVCC auf die Wallbox sperren und auch dort einen Scheduler in der Wallbox-Software (go-E) programmieren, weil es keine Scheduler in EVCC gibt.

Du kannst doch evcc via API auf "schnell" stellen in diesem Fall oder das SmartCostLimit so einstellen, dass das Auto ebenfalls in den "günstigen" Zeiten automatisch lädt.

andig commented 10 months ago

a generic interface for battery discharge control

Können wir das trotzdem für force-charge mit denken? Wie würde das API dafür aussehen?

BatteryMode(normal/lock/charge)

aber wie bekämen wir das in das custom meter rein? Oder

BatteryLock(bool)

aber was wäre dann mit Laden?

andig commented 10 months ago

Das ist genau der Use Case den ich hier NICHT betrachte (Hausbatterie Ladung steuern). Wie das Posting zeigt, erfordert das ganz andere Betrachtungen und ist ein gänzlich anderer Fall. Bitte separat diskutieren.

Sehe ich nicht so! Wenn die Ladung der Hausbatterie gestartet wird verhindert das auch automatisch das Entladen von dieser. Ich mache das z.Z. alles sehr umständlich manuell weil EVCC das nicht kann und deshalb im Winter nur sehr eingeschränkt nutzbar ist.

@AlexJoda welchen use case er hier betrachtet muss @GrimmiMeloni entscheiden ;)

Die beste "Tibber-Zeit" ist zwischen 3-5 Uhr nachts. Da schalte ich die Hausbatterie (Huawei Luna) per Scheduler auf "Laden".

Gibts dazu eine API-Info? Luna fehlt hier noch komplett in der Auflistung.

thebrainkafka commented 10 months ago

Vielleicht muss man für den Start mal damit leben dass es dann eben kein laden der Hausbatterie gibt. Die Hauptnutzung Tibber ist ja eh bei Nacht, da können die wenigsten ihre Batterie auch parallel laden. Als quick win und dann weiter ausbauen wenn möglich (laden).

GrimmiMeloni commented 10 months ago

a generic interface for battery discharge control

Können wir das trotzdem für force-charge mit denken? Wie würde das API dafür aussehen?

Klar, mitdenken ja. Ich möchte es halt nur nicht auch sofort im ersten Schritt bauen. Ich glaube das macht das ganze übelst kompliziert. #boilTheOcean usw....

aber wie bekämen wir das in das custom meter rein?

Bis jetzt ist meine Vorstellung mit dem Meter, daß über eine Interface Definition und entsprechende Abfrage am Meter ob das Interface implementiert ist zu lösen. Analog zu den Chargern und den verschiedenen Varianten. Ich habe das aber noch nicht näher angeschaut.

BatteryLock(bool)

So hatte ich es initial für mich auch mal skizziert. Ich hatte ursprünglich 2 Interfaces vorgesehen. Ein einfaches wie Dein Vorschlag (Discharge true/false), und dann eins mit der Möglichkeit die Entnahme zu regeln. Ich habe dann nur letzteres oben veröffentlicht, weil ein Entnahmelimit 0 einem Disable/Lock entspricht.

BatteryMode(normal/lock/charge)
[...]
aber was wäre dann mit Laden?

Netzladung impliziert ein Entladestop für die Batterie, bzw. eine Entladung macht eine Netzladung sinnfrei. Geht es vielleicht mit einem Limit das bei 0 sowohl Netzladung als auch Entladung verbietet. (Entspricht Lock). Bei negativen Limit Werten ist Netzladung bis zu dieser Leistung erlaubt. (Heute ist ja PV Ladung der Batterie auch negativ.) (Enspricht Charge) Bei positivem Limit wird mit bis zu dieser Leistung entladen erlaubt. (Entspricht normal) Wenn wir die Dynamik erstmal rauslassen, müßte Dein Vorschlag oben bereits ausreichen. Mein MVP Vorschlag deckt erstmal nur umschalten zwischen normal und lock ab.

Beim Laden müßten wir die Hausbatterie analog zu einem Vehicle behandeln. Auch hier würde dann ja gemäß Planner die Batterie geladen. Brauchen wir hier vielleicht einen neuen "top level" entity type?

andig commented 10 months ago

Beim Laden müßten wir die Hausbatterie analog zu einem Vehicle behandeln.

Hier: entladen, also erstmal ignorieren. Fürs Laden müsste das in der Tat sowas wie ein integrateddevice werden?

premultiply commented 10 months ago

Ich würde gerne bei der Batterie sämtliche direkte Leistungssteuerung grundsätzlich weglassen und dies dem Batteriewechselrichter überlassen.

Also wenn dann nur mit "Boolean-Steuerung" machen.

Max. Entladeleistung 0 (= "Entladesperre"): ja/nein Zwangsladen: ja/nein (später!)

Hintergrund: Macht das Interface und die Logik einfacher (auch über unterschiedliche Geräte/Hersteller hinweg), vermeidet falsche Benutzerangaben, schont Flashspeicher, ist hoffentlich maximal fehlertolerant.

bjoern-lehmann commented 10 months ago

Victron kann auch via MQTT angesteuert werden. Da kann man die wechselrichterleistung begrenzen um den akku nicht zu entladen, z.B. wenn nachts das Auto billig geladen wird und der Strom für das haus am nächsten Tag teurer sein wird. Dann hat man noch was im Akku und kann immer den günstigsten Strom nutzen, soweit man das mit Solar forecast und Börsenstrom vorraussagen kann.

VolkerK62 commented 10 months ago

Eine Info, die nicht direkt mit dem Issue, aber mit dem Thema zu tun hat. Meine Batterie (geschlossenes System) ist 1p an L1 angeschlossen. Meine Wallbox ist 1p an L3 angeschlossen. Wenn kein Überschuss vorhanden ist und ich mit 20A lade, wird meine Batterie NICHT entladen. Der Grund ist, dass das System die Schieflastgrenze im Auge hat und diese bei einer gleichzeitigen Entladung der Batterie überschritten werden würde. Nur als Randnotiz. Keine Ahnung, ob/wie das hier evtl. von Interesse ist.

premultiply commented 10 months ago

Du bist ein Fuchs 🦊 😉

Optic00 commented 10 months ago

bei SMA Tripower SE kann man über zwei Modbus Register a) die manuelle Ladesteuerung aktivieren/deaktivierne b) die Lade- und Entladeleistung steuern.

Also: 40151 = 802 (an) und 803 (aus) 40149 den Watt-Wert schreiben zum Entladen bzw. als negativer Wert zum Laden aus dem netz.

Den 40149 zu schreiben war etwas tricky weil die Adresse aus zwei 16bit Adressen(oder so ähnlich) besteht. In HA erst 0, 1000 zum Entladen mit 1000W bzw. 65535, 55000 zum Laden mit 10kW. oder einfach 0, 0 für Akku Pause!

lt. diversen Foreneinträgen handelt es sich hier explizit um Adressen die zum häufigen Schreiben gedacht sind. Ich meine mich zu erinnern, dass SMA das auch per E-Mail bestätigt hätte (PV Forum Eintrag)

Usecase:

Auto wird aufgrund eines niedrigen Tibber Preises geladen. Akku sollte dann pausiert werden oder sogar geladen werden. Schlecht wäre es, wenn der Akku dann entladen würde und später kein Strom mehr für das Haus bereit stehen würde wenn die Preise wieder anziehen.

Bei dem Usecase den Akku aus dem Netz zu laden, müsste der derzeitige SoC berücksichtigt werden sowie das Delta und ggf. eine PV-Prognose. Solange es keine PV-Prognose in EVCC gibt, bin ich persönlich nicht sicher, ob es Sinn macht. Außerdem müsste der Systemwirkungsgrad berücksichtigt werden. Bei 70-80% spart man halt nichts, selbst wenn der Strompreis über Tag 20-30% steigt.

AlexJoda commented 10 months ago

Bei dem Usecase den Akku aus dem Netz zu laden, müsste der derzeitige SoC berücksichtigt werden sowie das Delta und ggf. eine PV-Prognose. Solange es keine PV-Prognose in EVCC gibt, bin ich persönlich nicht sicher, ob es Sinn macht. Außerdem müsste der Systemwirkungsgrad berücksichtigt werden. Bei 70-80% spart man halt nichts, selbst wenn der Strompreis über Tag 20-30% steigt.

Beim AC-Laden über Grid (Huawei Luna) habe ich einen Wirkungsgrad von 92%-93%. Gehe davon aus das es beim Entladen genauso ist. Der Systemwirkungsgrad wäre dann 84%-86%. Der Unterschied zwischen günstig und teuer liegt bei Tibber zuweilen zwischen 18-36 Cent also 100%. Deshalb macht dieser Usecase durchaus Sinn...

AlexJoda commented 10 months ago

Gibts dazu eine API-Info? Luna fehlt hier noch komplett in der Auflistung.

Ja, gibt es. HA schient die LUNA steuern zu können...

AlexJoda commented 10 months ago

Dazu muss man dann den API Zugriff von EVCC auf die Wallbox sperren und auch dort einen Scheduler in der Wallbox-Software (go-E) programmieren, weil es keine Scheduler in EVCC gibt.

Du kannst doch evcc via API auf "schnell" stellen in diesem Fall oder das SmartCostLimit so einstellen, dass das Auto ebenfalls in den "günstigen" Zeiten automatisch lädt.

Ich kann aber die LUNA nicht über Tibber steuern da ich kein HA einsetze, sondern nur den Scheduler der LUNA. Deshalb muss ich exakte Anfangs- und Endzeiten zum Laden des BEVs in EVCC programmieren können.

kfussmann commented 10 months ago

Ich hätte auch großes Interesse da Tibber Kunde mit SMA Anlage und derzeit kann ich das nur manuell über das Sunny Portal.

lt. diversen Foreneinträgen handelt es sich hier explizit um Adressen die zum häufigen Schreiben gedacht sind. Ich meine mich zu erinnern, dass SMA das auch per E-Mail bestätigt hätte (PV Forum Eintrag)

Hier der Link zum genannten PV Forum Eintrag https://www.photovoltaikforum.com/thread/156613-sbs-manuelle-steuerung-durch-modbus/

Dort steht auch das die Werte kontinuierlich gesendet/geschrieben werden müssen.

Grüße

thebrainkafka commented 10 months ago

@GrimmiMeloni . Bist du mit dem Prototyping schon weiter gekommen ?

Viele Grüße Jogi

GrimmiMeloni commented 10 months ago

Bist du mit dem Prototyping schon weiter gekommen ?

Nein, noch nicht. Ich kann aber schonmal sagen, daß für michder Input von @premultiply ziemlich überzeugend ist. Sowohl die Intention es einfach zu halten (on/off only), sowie auch der Hinweis das komplexere Steuerungen wenn überhaupt nur nach Prüfung von möglicher "flash-wear" zu erzeugen sind.

Ich würde in den kommenden Tagen das "Design" oben nochmal aktualisieren, um klarer herauszuarbeiten was jetzt genau im Scope ist und was nicht, und dann auch die Interfaces entsprechend anpassen. Dann denke ich kann es losgehen.

Wir können aber das Issue trotzdem weiter als Sammelbecken für APIs der verschiedenen Batteriespeicher verwenden.

thebrainkafka commented 10 months ago

Danke für deine Ausführungen und Input um dieses für viele "brennende Thema" zu ermöglichen.

Kann man dies dann als generischen Ansatz sehen oder muss es für jeden Batteriespeicher/ Hersteller einzeln gemacht werden? Ich glaube mein Solarmax Ultimate hat laut pdf (oben verlinkt) nur mqtt read. Geht das da dann überhaupt ?Aber bin da thematisch eh raus bei diesen API usw. topics. 😉

Danke Jogi

micw commented 10 months ago

Hallo zusammen,

ich finde die Diskussion super spannend. Bin leider erst durch einen Hinweis darauf gestoßen, ich hatte kürzlich in einem anderen Thread eine Idee skizziert, die diesem hier sehr ähnlich ist. Ich kopier's mal hier rein:

neuer Gerätetyp "Batterie-Ladesteuerung"

diese bekommt generell Ereignisse, auf die sie reagieren kann:

smartCostActive On / Off

Maximaler aktiver Lademodus über alle Ladepunkte: aus, PV, PV+Min, Schnell

aktueller Strompreis

Konfiguriert wird eine Liste mit Bedingungen mit je einer Aktion, welche Abhängig von der Batterie ist

Beispiel. Victron kann dynamisch entladen, laden, halten über den Mindest-Ziel-SOC abbilden. Mögliche Aktionen wären dann "discharge", "charge", "hold". Meine Wunschkonfiguration der Aktionen wäre dann:

price < 0: charge

Wenn der Preis <0 Cent ist wird immer geladen

smartCostActive = On: hold

Wenn mind. 1 Auto mit billigen Netzstrom geladen wird, wird der Akku nicht entladen

maxActiveMode = Schnell: hold

Wenn mins. 1 Auto auf "schnell" steht und tatsächlich geladen wird, wird der Akku nicht entladen

default: discharge

Wenn keine der obigen Regeln zutrifft, wird der Akku dynamisch entladen

Die unterschiedlichen Implementierungen der Batterien enthalten dann nur noch die dort möglichen Aktionen und deren konkrete Implementierung. Bei Victron wäre das z.B. ModBus als Schnittstelle und die Logik dass "discharge" den Min-SoC auf einen Mindestwert setzt, "charge" den Min-SoC auf einen Maximalwert setzt und "hold" den Min-SoC auf den aktuellen Batteriewert setzt.

Das deckt sich weitgehend mit dem initial beschriebenen Ablauf, nur dass es noch einen weiteren "Hooks" beim Preis gibt. Und der der (könnte auch eine spätere Erweiterung sein).

Für eine Logik "Das Haus wird aus der Batterie versorgt, die Autos aus dem Grid", wie oben nachgefragt wurde, ergibt sich für mich keine sinnvolle Anwendung. Entweder ist der Strom billig. Dann würde ich das Auto laden und auch das Haus aus dem Grid versorgen. Oder er ist teuer, dann lade ich das Auto nicht und versorge das Haus aus dem Akku. Oder er ist teuer, ich muss aber das Auto laden. Dann nehme ich den Strom aus dem Akku und gut ist. Alle anderen Szenarien, die mir einfallen, würden eine deutlich komplexere Ladesteuerung mit Vorausplanung benötigen.

Bezüglich der API bin ich nicht sicher, ob ein "SetLimit()" ausreicht. Die Batteriesysteme sind ja recht heterogen. Bei einigen kann man ein Ladelimit oder ein Entladelimit (oder beides) setzten. Bei meinem Victron ist mir als Steuermöglichkeit nur die Min-SOC bekannt (ist er kleiner dem SOC, wird bei Bedarf entladen, ist er gleich, wird gehalten, ist er höher, wird mit maximaler Leistung geladen). Eventuell wäre es flexibler, der Batterie-Implementierung nur den Status (lädt nach Plan, lädt schnell, lädt nicht) mitzuteilen und den Rest der Implementierung zu überlassen. Das ist zwar mehr Arbeit in der jeweiligen Implementierung, am Ende aber am flexibelsten und mit der bestmöglichen Ausnutzung der Batterie-Features.

Edit: für die einzelnen Batteriesysteme und deren APIs/Features wäre es meiner Meinung nach sinnvoll, je ein Ticket aufzumachen und auf dieses hier zu verweisen.

evcc-io / evcc