Skip to content

SolisCloud: Plan Never Shows Battery SoC Drop Below 80% #3707

Description

@CraigCallender

Describe the bug
When using the SolisCloud integration, Predbat’s plan would never show my battery SoC dropping below 80%, even though I lowered input_number.predbat_set_reserve_min (e.g. to 11%). The battery would drop below 80%, but the plan would always show it holding at 80% (until the SoC was lower, then it would hold it at the lower SoC). It never froze the charge at that percentage, just wouldn't calculate it lower (screenshot attached). The plan only started behaving as expected after I manually reduced sensor.predbat_soliscloud_0_reserve from 80% to 11%.

This report is mainly a hypothesis about a possible “sticky reserve” mechanism / state mismatch between Predbat’s desired reserve minimum and the inverter’s (SolisCloud-reported) current reserve setting. I don’t yet have a reliable mechanism to reproduce/test it.

Expected behaviour

  • Changing input_number.predbat_set_reserve_min should allow Predbat to plan battery discharge below 80% (down to the configured minimum), or at least make it clear why planning is being constrained.
  • If Predbat is no longer managing reserve (due to a config change), I would expect Predbat to either:
    • reset/unset any previously-set inverter reserve when it stops using it, or
    • clearly warn that the inverter-side reserve is still set high and will constrain planning/operation.

Predbat version

Tested from 8.34.1 - 8.35.1

Environment details

  • Inverter and battery setup: Solis inverter + home battery, controlled via SolisCloud integration
  • Standard HAOS installer or Docker: Standard HAOS
  • Anything else?: I had set target_soc_used_for_discharge: false in my config.

Hypothesis / theory (not confirmed)
I suspect this happened due to a “sticky” inverter reserve value being left behind when I changed config and restarted Predbat.

Hypothesized sequence:

  1. At some point the SolisCloud reserve entity (sensor.predbat_soliscloud_0_reserve) ended up set to 80% by predbat to manage force discharge.
  2. I changed config (specifically target_soc_used_for_discharge: false) and restarted Predbat, possibly while Predbat was active / while a reserve value was already set.
  3. After restart, Predbat continued to read/respect the current inverter reserve via SolisCloud (still 80%), which effectively prevents planning below 80% even if input_number.predbat_set_reserve_min is lower.
  4. Lowering input_number.predbat_set_reserve_min did not change the behaviour.
  5. Manually reducing sensor.predbat_soliscloud_0_reserve from 80% to 11% immediately made the plan behave as expected.

So the main suspicion is: if reserve is set on the inverter (via SolisCloud), and then Predbat’s behaviour changes (e.g. target_soc_used_for_discharge toggled) and Predbat restarts, the inverter-side reserve may remain stuck at the old value and Predbat continues to respect it.

Steps I actually took / observed

  1. Noticed plan would never go below 80% SoC.
  2. Found input_number.predbat_set_reserve_min was 80% and lowered it to 11% — no change in plan behaviour.
  3. Found sensor.predbat_soliscloud_0_reserve was 80% and lowered it to 11% — plan immediately started working / showing SoC below 80%.
  4. This led me to suspect the inverter-side reserve value is the real limiting factor, and it may persist/stick across restarts/config changes.

Request / questions

  • Is sensor.predbat_soliscloud_0_reserve intended to be the “source of truth” for minimum discharge reserve in SolisCloud mode?
  • Should Predbat be synchronising the inverter reserve with input_number.predbat_set_reserve_min (or at least warning when they diverge)?
  • Could Predbat be leaving a previously-set inverter reserve behind when certain settings change (e.g. target_soc_used_for_discharge) or when it restarts mid-operation?
  • If this is expected behaviour, could the docs/UI make clearer that the inverter-side reserve must be lowered too?
  • Maybe there's a way to highlight in the plan when the battery SoC is "stuck" at a number due to a reserve being present (this took many days to troubleshoot).

Screenshots

Image

Log file

N/A

Predbat debug yaml file
N/A

Metadata

Metadata

Labels

No labels
No labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions