Home battery discharge control

[GrimmiMeloni]

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, #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

1. a generic interface for battery discharge control
2. implementation of required logic in evcc's main control flow
3. 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]

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]

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

[orthoenergy]

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]

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]

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

[andig]

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

/cc @premultiply

[Kalie15]

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]

Sungrow SHxRT bohdan-s/SunGather#36 (comment)

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]

Weiss auch einer was von SMA/Sunny Island?

[WisManue]

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]

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]

[...] 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]

Erstmal brauchts use cases. Danke.

[Kalie15]

Erstmal brauchts use cases. Danke.

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

#10394 (comment)

[GrimmiMeloni]

Erstmal brauchts use cases. Danke.

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