External control of battery charge power (experimental)

[jeremiahpslewis]

Is your feature request related to a problem? Please describe.

The optimizer's load-smoothing recommendations create situations where the home battery should keep charging, but at reduced power — e.g. to flatten grid load peaks or follow a smoothed charging plan. evcc currently offers no way for an external system to express this:

• The external battery mode API (POST /api/batterymode/{mode}) is all-or-nothing: normal charges at full device power, hold blocks charging entirely. There is no "charge, but at most X W".
• batterygridchargelimit is a price threshold, not a power cap.

So a HEMS acting on load-smoothing recommendations has to either give up on the smoothing or write to the inverter directly behind evcc's back, which conflicts with evcc's own battery mode register writes.

Describe the solution you'd like

An experimental, external battery charge power limit that mirrors the existing external battery mode API:

• New optional device capability api.BatteryChargePowerLimiter with SetBatteryChargePowerLimit(power *float64) error; nil releases the limit and restores the device's maximum charge power. Separate from BatteryController, because the limit is orthogonal to mode (a cap can be active while the mode stays normal).
• POST /api/batterychargepowerlimit/{watts} and DELETE /api/batterychargepowerlimit, plus an MQTT setter batteryChargePowerLimit. Runtime only, never persisted.
• The same 60 s refresh-or-revert watchdog as the external battery mode: if the external controller stops refreshing, evcc restores the device maximum. Release on shutdown, and a forced write on the first update cycle so device state is known after a restart.
• Custom meters implement it via a limitchargepower setter plugin; the value stays in watts and is clamped to [0, maxchargepower] (with maxchargepower required). Device templates (e.g. Fronius GEN24 via sunspec model 124 InWRte) can then wire it up in follow-ups.

Describe alternatives you've considered

• Battery mode hold pulses: duty-cycling hold/normal to approximate a power cap — imprecise, chatty on the inverter registers, and fights the mode watchdog.
• Device-side revert timers (e.g. sunspec InOutWRte_RvrtTms) instead of an evcc-side watchdog: a device-side revert would also undo evcc's own hold/charge writes, which are change-triggered rather than refreshed. The evcc-side watchdog matches the existing battery mode design.
• Direct Modbus writes from the HEMS: conflicts with evcc's register ownership (StorCtl_Mod is written by mode changes) and bypasses evcc's state.

[github-actions]

Thanks for the detailed proposal. I confirmed the existing patterns you're referencing are accurate: api.BatteryController (api/api.go), the external battery mode HTTP handler updateBatteryMode in server/http_site_handler.go, and the refresh/revert watchdog in plugin/watchdog.go. The proposed api.BatteryChargePowerLimiter interface would fit alongside BatteryController the same way.

This is a substantial, well-scoped feature request rather than a bug, so I won't attempt an automatic implementation — it touches several areas (new api interface, core/site_battery.go state/watchdog logic, new REST routes in server/http_site_handler.go, MQTT setter in server/mqtt.go, and eventually template wiring for specific devices). It would benefit from maintainer input on the exact API surface (e.g. naming, whether the limit lives on BatteryController vs. a separate interface as you suggest) before implementation.

🤖 Generated with Claude Code

[andig]

The battery model doesn‘t support power adjustments at the moment. This might happen at a later stage, but not any time soon.

[jeremiahpslewis]

Ok, thank you for the feedback. The necessary consequence of this is that the optimizer plans, esp. 'reduce feed-in peaks', cannot be implemented as proposed by the algorithm.

[andig]

Yes, not atm 😢. Acceptable for experimental feature.

[jeremiahpslewis]

Easy enough to wire up a workaround via modbus and hass, so no sweat on timeline, but obviously my personal gold standard would be to see this kind of feature incorporated into evcc at some future date. Just gets under one's skin a bit to see Fronius offer a closed source optimizer which has a more solid battery control offering 😁.

[andig]

Just gets under one's skin a bit to see Fronius offer a closed source optimizer which has a more solid optimization offering 😁

Indeed! Is that just a claim or is it any good? Always good incentive to beat the competition!

[jeremiahpslewis]

I'm much happier paying for the sponsor token than for the Fronius subscription, so I don't have any hands on experience, but here's the claim (equivalent feature to what I've implemented with the evcc optimizer plus hass / modbus). It's been driving me up the wall that holdcharge isn't a sufficient API to implement this on the evcc-side successfully.

https://www.fronius.com/de-de/germany/solarenergie/eigenheim/produkte-und-loesungen/anlagen-ueberwachung/energiekosten-assistent

[andig]

Closing for time being, will revisit later. Let's see who far #32881 can take us without doing this.