add cost for increased battery life depletion when sitting at very high or low SOC

[ekkea]

added feature that allows to specify a cost for batteries sitting at very high or very low SOC for longer time.

added optional cost parameters to battery API:

• prc_dpl_soc_high:
  Price in €/h for higher battery life depletion when sitting at high SOC.
  A linear cost model is applied, starting at 80% SOC, applying full price at 100% SOC
  The battery capacity is assumed to be s_capacity or s_max if s_capacity is not specified.

• prc_dpl_soc_low:
  Price in €/h for higher battery life depletion when sitting at low SOC.
  A linear cost model is applied, starting at 20% SOC, applying full price at 0% SOC
  The battery capacity is assumed to be s_capacity or s_max if s_capacity is not specified.

The feature is tested and works as expected, however, it is not clear how useful it is as the optimization time horizon is short in relation to time duration needed to create noticeable life time depletion.

[andig]

@ekkea I think there are two conflicting goals here: keep battery and lowest possible (but still sufficient) soc and flattening grid feed-in curve. Both seem at least potentially contradictory.

Do you think you could add another PR for grid-aware battery charging where charging happens preferably during peak production? I think this should be configurable per battery as to not apply this to vehicles but only to home batteries. I've closed #70 which was trying to do something similar.

[andig]

Opened #71 for the approach.

[ekkea]

@andig This feature does already exist. There is a strategy called something with "attenuation" which incentifies charging at solar peak hours.
You can also limit the export power if you want to force it.
Sorry, cannot look into code right now.

[ekkea]

Also, I don't think that the feature here contradicts any other goal. It is just assinging costs to "extreme" SOCs which becomes a target function contribution. Whether these costs exist in reality (increased aging) is a different discussion.

[iseeberg79]

I think this feature is also useful as a buffer for unplanned home consumption. At the very least, it ensures the battery is charged above the home consumption level. The cost for being below 20% should be very low, so that only PV is stored there, and home consumption is preferred from the battery over the grid in the morning.
I was looking for an option to allow grid feed-in reduction while still keeping enough battery energy stored for unplanned home usage. Otherwise, the battery is charged right at the consumption level, leaving no buffer against forecasting errors.

[iseeberg79]

Follow-up from operating this in production (evcc, rolling 15–30 min re-optimization, daily price horizon reset ~14:00 CET): in practice the high-SOC term (prc_dpl_soc_high) rarely has any executed effect — its influence on the plan almost always falls on next days slots >20h out that get re-optimized away before they're ever acted on.

The low-SOC term is the one that matters operationally, because it shapes near-term charging decisions that are executed (reserve for tonight can only be built up today, not deferred). Worth splitting the framing: low-SOC as a forecast-deviation buffer (not aging, as you note), high-SOC as an optional/lower-priority aging guard whose value depends heavily.

[iseeberg79]

After several weeks of testing, I'd like to reiterate the preference for low-SoC cost weighting.

Without it, the optimizer frequently sits right at minSoc, leaving no buffer for household loads. Keeping costs low at the lower SoC band creates that buffer — and this mainly matters in the morning. High-SoC costs are comparatively unimportant; the real value is having extra SoC available right before PV kicks in, which avoids drawing from the grid and directly saves money.

[andig]

Without it, the optimizer frequently sits right at minSoc, leaving no buffer for household loads

I don‘t see why with a battery-first strategy?

[iseeberg79]

"battery_first" only applies at exact cost ties, while even a very low prc_dpl_soc_low is a real price that wins whenever the gap is smaller — which is exactly the margin that matters here. It preferentially keeps above/restores battery SoC to around 20% (but allows discharge to minsoc).

I need to collect some samples?

[iseeberg79]

Another practical but maybe less important reason is seasonal. In winter mode, the battery would stay operational only if the SoC is above about 15 percent, though in practice the effective (should not stay at) minSoC ends up somewhere between 5 and 15 percent even in winter. This ensures the battery stays responsive for storing surplus and grid charging, which requires a higher operational SoC, especially when there’s less PV to rely on.