Expose batteryBuffered and batteryStart flags on /api/state and MQTT

[impellerturn]

Hi,
ich schreib im Folgenden auf Englisch, damit die Diksussion reibungslos vollzogen werden kann.

Hi,
i want to use 2 states for the battery supported charging inside my homeassistant automation (making the zero-feed-controller smoother by avoiding 2 separate systems trying to compete for the zero-feed value at the grid connection (Netzanschlusspunkt)).

Is your feature request related to a problem? Please describe.
For external consumers (a Home Assistant automation in my case) it would help to
know whether evcc currently considers the house battery available for EV
charging.

Describe the solution you'd like
Both booleans already exist as locals inside core/site.go → sitePower():

• batteryBuffered = bufferSoc > 0 && battery.Soc > bufferSoc
  (battery may serve loadpoints)
• batteryStart = bufferStartSoc > 0 && battery.Soc >= bufferStartSoc
  (PV-surplus charging may start)

Describe alternatives you've considered
These values are not published today, so as an alternative a consumer has to re-implement the comparison
against bufferSoc / bufferStartSoc outside evcc — which breaks as soon as
the user changes the thresholds from the battery UI.

Additional context
These values are not published today, so a consumer has to re-implement the comparison
against bufferSoc / bufferStartSoc outside evcc — which breaks as soon as
the user changes the thresholds from the battery UI.

Publishing the flags themselves would be a ~2-line change in update() plus
the symmetric initial publish in prepare(), showing up on /api/state, the
WebSocket event stream and MQTT.

Branch on my fork for reference:
https://github.com/impellerturn/evcc/tree/feature/publish-battery-flags

Can you (the maintainers) accept this request?

Thanks and BR impellerturn

[andig]

which breaks as soon as the user changes the thresholds from the battery UI.

The thresholds re also published, this seems trivial enough?

[impellerturn]

Thanks for the quick look!

My goal is to incorporate the actual (tatsächliches) result of the
battery-support algorithm as an input in the control loop. Beside the SoC of
the connected batterie(s) there are conditions in code which can not be
deduced by an external re-implementation just based on the SoC-limits.
Therefore i deem it a better SW design to work on the real computed values.

The following is AI generated evidence that a simple re-implementation of the SoC based logic will fail:

To make that concrete, sitePower() in core/site.go (around L844–L860 on
master) does:

if site.battery.Soc < site.prioritySoc && batteryPower < 0 {
    // battery priority — batteryBuffered/batteryStart stay false
} else {
    batteryBuffered = site.bufferSoc > 0 && site.battery.Soc > site.bufferSoc
    batteryStart    = site.bufferStartSoc > 0 && site.battery.Soc >= site.bufferStartSoc
}
Two cases where a naive soc > bufferSoc outside evcc diverges from this:

bufferSoc == 0 / bufferStartSoc == 0 means "feature disabled" — the internal flag stays false, but the naive compare returns true as soon as the battery has any charge.
The prioritySoc branch forces both flags to false while the battery is still charging toward priority, regardless of bufferSoc. A consumer that doesn't also track batteryPower + prioritySoc and replicate the ordering will get this wrong in exactly the situation where it matters (battery actively claiming the surplus).
Exposing the two booleans keeps the public contract stable if that ordering or those guards ever change. 

[impellerturn]

#29288 (comment)

[impellerturn]

Update: I opened a follow-up PR that fixes the current CI failures (unused imports in core/site_test.go) so the battery flag change set is mergeable again.

PR: #29451
Context PR: #29288