Optimizer: empty minsoc/maxsoc battery fields silently apply a 20 %/95 % limit that caps the optimizer

[xMatzeDE]

What I observed

On evcc 0.315.0 with the experimental battery optimizer enabled, I noticed the home battery was being held over night instead of discharging, even though the Solcast solar forecast for the next day guaranteed a full recharge.

Tracing the optimizer request/response (evopt in /api/state, captured every 15 min over several nights) showed the optimizer was working against a 20 % lower / 95 % upper SoC bound for the home battery:

Home battery (SMA STP 10.0 SE, BYD HVS 10.6 kWh), battery config fields LEFT BLANK:
  s_min = 2120 Wh  (20 %)
  s_max = 10070 Wh (95 %)

The optimizer therefore stopped discharging as SoC approached 20 %, and recommended hold for the rest of the night.

Where the 20 %/95 % does NOT come from

I initially assumed these limits were read from the inverter. They are not. From the SMA parameter export of the same inverter:

SMA parameter	Object ID	Value
Deep-discharge protection min width (BatUsDm.DschProDmMin)	6802_00895000	2 %
External discharge limit, lower (BatChaSttMin)	6802_00895600	0 %
External discharge limit, upper (BatChaSttMax)	6802_00895700	100 %

So the inverter allows external (Modbus) battery control across the full 0–100 % range and only hardware-protects the bottom 2 %. There is no 20 % or 95 % anywhere in the inverter configuration. The sma-hybrid template only reads the SoC register (30845); minsoc/maxsoc are pure evcc config params, not Modbus reads.

Conclusion: the 20 %/95 % is an evcc-side default that applies when the battery minsoc/maxsoc fields are left blank — it is not derived from the battery system.

The fix (and proof it is the cause)

I set the battery config fields explicitly to minsoc = 0, maxsoc = 100. The optimizer request changed immediately:

Same battery, fields set to 0 / 100:
  s_min = 0 Wh     (0 %)
  s_max = 10600 Wh (100 %)

The inverter's own 2 % deep-discharge protection remains the real hardware floor, so nothing is at risk — but the optimizer can now use the full usable range.

Why this is easy to miss (the actual point)

1. Both fields are marked optional and show a placeholder of 25 (min) / 95 (max).
2. The help text reads: "Lower limit as configured on the battery system. Used by optimizer."
3. A user therefore reasonably reads a blank field as "no extra limit — use what the battery allows."
4. In practice, blank yields an effective 20 %/95 % cap on the optimizer that is not shown by the placeholder (25 ≠ 20) and not stated in the help text.

For a battery whose hardware already protects itself (SMA: 2 %), this silently leaves a meaningful slice of usable capacity unused overnight and pushes the house onto grid import earlier than necessary.

Suggestion

Small, non-breaking improvements, any of these would help:

• Make the effective default visible in the UI when the field is blank (e.g. show 20/95 as the actual default value rather than a 25/95 placeholder), or
• Extend the help text: "If left blank, the optimizer assumes 20 % / 95 %.", or
• Where the inverter exposes a hardware deep-discharge limit (SMA DschProDmMin), consider using that as the default lower bound instead of a fixed 20 %.

Question to maintainers

Could you confirm the exact source of the blank-field default (20 %/95 %)? I could trace the optimizer mapping (core/site_optimizer.go batteryRequest, minSoc/maxSoc → SMin/SMax, with maxSoc == 0 → 100) and the decorator (meter/usage_battery.go, batterySocLimits.Decorator returns nil when both are 0), but I could not pin down where the literal 20 %/95 % is injected when the fields are blank. Understanding that would let me document it correctly for other SMA/BYD users.

---

Evidence attached / available

• evopt request snapshots before (blank → 20/95) and after (0/100) — captured via /api/state
• SMA STP 10.0 SE full parameter export (relevant rows quoted above)
• evcc version 0.315.0

[xMatzeDE]

Note on repo choice:
I posted this here on evcc-io/optimizer, but I realize the minsoc/maxsoc handling actually lives in the main evcc-io/evcc projec.
Since the optimizer service only receives the already-computed s_min/s_max values.
Please move this to evcc-io/evcc/discussions if that's the better home 🙏

[andig]

showed the optimizer was working against a 20 % lower / 95 % upper SoC bound for the home battery:

That has been fixed in nightly.