Feature Request: Delayed 100% charge (battery health)

[madmat17]

Hi @woopstar ,

It's an awesome integration you developed - chapeau!

I was wondering, if you have any plans for adding some kind for "battery care" mode.
Right now, I'm working on an HA automation (not an integration) that is charging the battery to 20% in the morning (little buffer) - as of then export the surplus to the grid (as long as hourly prices are still at a good level). Continue charging to 80% at a later point of time (usually noon - production peaks, hourly electricity price drops); finalize charging to 100% during the last sunny hours of the day.
Target is, to export to grid when it's most beneficial (for the grid itself as well as for my bank account) and to avoid cranking the PV battery's SoC to 100% for a almost a whole day (in summer batteries get fully charged in no time) to slow down the battery's degeneration.

I'm quite stupid when it comes to Python. Therefore, I won't be able to provide any PR for the mentioned features.
However, in case you plan anything in that direction, I'd be happy to help with testing (and/or writing the documentation for them) at least.

Best
Mat

[woopstar]

Hi,

It is an interesting topic, and we'll pursue it. The issue you need to consider here is battery cycles and degradation. What you are alluding to is a BESS system approach, but charge your battery, discharge it, and "hopefully" earn money on it. At the same time, you look at price, cycles, battery degradation, and your investment costs.

Hence, this becomes a bit trickier.

[madmat17]

Hi,

Sounds great!
However, it seems that I have not been quite clear. My intention is to counter the degradation.
BESS: Well, not quite. I don't think that it'd be a good idea to charge the battery from grid to sell it at a higher price - that could drastically impact the battery lifespan in a negative way.

Let's assume one has a 10 kWh battery and a 10 kWp panel/inverter setup. On sunny days the battery would be fully charged quite early (let's say 9:00 o'clock).
Let's assume that usual base power consumption can be covered with PV energy until 16:00 o'clock. Only as of then battery begins to drain again.
That means, that the battery held the maximum voltage for 7 hours in vain. Keeping batteries constantly at 100% SoC is said to be unhealthy, even for LFP batteries.

Hence, my idea is the following:

• Charge the battery only to 20% (to have a little buffer for peaks in power consumption / dips in PV production) in the morning. As soon as 20% are reached, the excess from PV production should be fed to the grid, as long as prices are still high. → sell excess at "good" prices.
• As soon as prices are at the lowest level (usually at noon, when "too" much energy is available) battery should be charged to 80% (not to 100%, as we want to conserve battery life) → fill the battery at a very low price
• Load the last 20%pts SoC as soon as sunny hours come to an end (taking into account the PV forecast as well as average consumption + a little buffer). That would keep the time the battery is between 80% and 100% SoC at a minimum.

PV produciton vs. prices:

[woopstar]

Oh, but I do believe HSEM already takes that into account and will export, so you wont see the battery get filled as first thing during the day.

[madmat17]

Uh - does it? My bad.
In that case I didn't read the documentation carefully enough. Sorry 'bout that!

[woopstar]

Hi @madmat17,

I've analyzed the current HSEM battery charging logic and evaluated whether implementing staged charging (20% → export → 80% → 100%) would maybe be beneficial.

Analysis of Current Battery Logic

The current system already implements sophisticated battery charging optimization:

1. Priority-based charging: Negative prices → Solar surplus → Cheapest grid charging
2. Schedule-aware charging: Only charges what's needed for upcoming discharge periods
3. Economic optimization: Charges during optimal price periods with minimum price difference checks

Assessment: Not Worth Implementing

After reviewing the _async_calculate_batteries_schedules_best_charge_time and _async_find_best_time_to_charge_battery_schedule methods, I believe this feature would add significant complexity without proportional benefits:

Economic Trade-offs

• Missed revenue: The staged approach would skip charging during peak export price periods
• Complex timing logic: Requires tracking charge stages and implementing time-based restrictions
• Override user preferences: Forces battery health logic over economic optimization

Existing Solutions

Users concerned about battery health can already achieve similar results through:

• Battery schedule configuration: Set specific charge limits and timing
• Seasonal wait modes: Winter logic already prevents unnecessary charging
• Price-based controls: Minimum price difference requirements prevent uneconomic charging

Technical Considerations

• Modern LFP batteries handle 100% SoC much better than older chemistries
• The economic cost of delayed charging likely outweighs battery longevity benefits
• Implementation would require complex state management and override existing optimization logic

Recommended Alternative

Instead of core implementation, I'd suggest enhancing the existing battery schedule features to give users more granular control:

• Add configurable maximum charge levels per schedule (e.g., "Charge to 80% max")
• Add "Battery Care" mode as a schedule option
• Document battery health best practices in the README

The current system already provides the foundation for battery health management through user configuration, making a core implementation unnecessary.

What are your thoughts on this approach? Would enhanced schedule controls meet your needs without the complexity of automatic staged charging?