Solis: confirm whether GS_fb00 + charge_limit still micromanages charging #5127

Activity

1. chalfontchubby

   added

   bugSomething isn't workingSomething isn't working

   solis

   on Sep 17, 2026
2. springfall2008 commented on Sep 17, 2026

   

   springfall2008

   on Sep 17, 2026

   Owner

   More actions

   Automated first-pass triage (a maintainer will review before any action is taken).

   Classification: bug (unconfirmed) — this is an evidence request more than a defect report, as the body says. Labelled waiting_for_user, priority_low (single unconfirmed reporter; two of the underlying every-cycle write causes were already fixed).

   What I checked against current main (002f6b86, v9.0.3-35):

   1. The target-SoC write itself is change-gated. adjust_battery_target() (inverter.py:2042) reads the current charge_limit first and only writes when it differs — the else branch logs "already at target" and writes nothing. GS_fb00 has has_target_soc: True (config.py:1907), so on current main a stable plan target should not produce repeated SoC writes.

   2. The every-cycle write volume that does exist is the H M time-format rewrites, not the SoC hold. adjust_charge_window() deliberately rewrites the charge start/end time entities on every cycle for H M/"H:M-H:M" formats (the Workaround for writing to HH:MM not being reliable #1529 write-reliability workaround — "always write to this as it is the GE default"), which on GS_fb00 (charge_time_format: "H M") means up to 6 option writes + a notify per 5-minute cycle while a window is programmed — i.e. hundreds of writes a day. This is asserted as intended by the regression test force_export_unchanged_times_HM_format (tests/test_inverter.py:4541). The redundant update-button press part of this (the Unneccessay updates to inverter causing eeprom wear #2328/GH#4709/Inverter update button pressed on every idle cycle when no export is scheduled #4712 complaints) is fixed on main — PRs fix(inverter): stop re-committing a stable export window every cycle (Solis) #4711 and fix(inverter): don't press the update button on idle non-export cycles #4713 are merged, and their regression tests pass.

   3. The hold path writes only on transitions. When SoC ≥ target−1%, execute.py holds by disabling the charge window / adjusting reserve (execute.py:343-380); disable_charge_window() (inverter.py:2833) only writes when the enable switch was on.

   4. Config trap that may explain "went through all the hoops, it didn't help": Solis auto-config binds charge_limit to Predbat's own slot-1 SoC entity (solis.py:1670) via set_arg_auto() with overwrite=True — so an apps.yaml charge_limit: number.solis8_timed_charge_soc set per the Unneccessay updates to inverter causing eeprom wear #2328 guidance is replaced by auto-discovery whenever the Solis API component is enabled, with a one-time log note: Note: apps.yaml sets 'charge_limit: ...' but auto-discovery is using '...' instead. If the reporter had the Solis API component active, the hoop they jumped through was silently undone.

   Test run: inverter test suite passes on main (includes the GS_fb00 H M unchanged-times and stable-window press regressions).

   Possibly related: #5129 (making GS_fb00 charge_limit enabled by default rather than requiring the manual uncomment).

   To close this out we still need, as the body asks: a predbat.log spanning several consecutive cycles, masked apps.yaml (inverter_type, charge_limit, and whether the Solis API component is enabled), and a predbat_debug.yaml. With the log in hand the first thing to grep is the auto-discovery note above — that alone would confirm or kill the config-override explanation.
3. springfall2008

   added

   BOT_TRIAGEDHas been through the triage botHas been through the triage bot

   waiting_for_user

   priority_low

   on Sep 17, 2026
4. springfall2008

   closed this as completedin #5126on Sep 26, 2026