Predbat charging battery from grid when solar forecast is enough to charge it

[itm1960]

apps copy.yaml

Over the last couple of days my new predbat install has decided to charge my battery from the grid in the morning when there is more than enough solar generation forecast to charge the battery to 100% by 13:00.
For example, at 11:10 yesterday (07-July-2026) I noticed that predbat was in HoldChrg mode and drawing 3.3kW from the grid. The battery SoC was 76% and the load was 0.76kW. Solar generation was 4.4kW, and forecast to stay at least as high for the next 4 hours. As the solar forecast was great for the day I couldn't understand why it would need to draw any power from the grid to recharge it - according to the plan there would have been enough excess solar generated to fully recharge the battery by 13:00.
When I checked the mode in the FoxCloud app it had been set to "Backup" (presumably by predbat, as I had not selected a mode myself).

I would have expected predbat to exclusively use the available excess solar power between 06:30 and 13:00 to charge the battery to 100%. This would have allowed powering the house from the battery when the import rates were highest (from 16:00) and optionally exporting to the grid when export rates were highest at 18:30.

I put prebat into read-only mode at 11:22 to stop the charging from the grid while I investigated, and re-enabled predbat some time later (I can't remember what time).

Predbat version: 8.40.15

Inverter: FoxESS KH7
Battery: FoxESS EP12 (11.52kWh)
Standard HAOS install

predbat.4.log
predbat_debug.yaml.txt

[springfall2008]

It's not about if you have enough battery without charging, but if the import rates are lower than the export rates then you might as well take advantage and export more later. Here you have some 17-18p export rates with 15p import.

[itm1960]

Thanks for the feedback. I guess I'm still coming to terms with how predbat makes its decisions.
What I can't work out is: if there had been no force charging of the battery from the grid from 11am, the battery would have charged to 100% before midday anyway, using the excess solar alone. It would still then have been possible to take advantage of the 17-18p export rates from 16:00, but without having incurred the expense of the force charging from 11am.
I guess there must be a flaw in my logic but I just can't see it at the moment!

Another thing I don't understand is: what happened to the excess solar energy being generated at 11am if it wasn't being used to charge the battery? I noticed at the time that the inverter was in "Backup" mode - is what would have been expected?

EDIT: I think I've managed to track down the problem. The fact that predbat was putting the inverter into Backup mode caused it to draw from the grid (at 15.2p) while simultaneously exporting to the grid (at 8.7p) - hence making a net loss. I needed to set support_charge_freeze and support_discharge_freeze to FALSE to stop this happening.
Does this sound right?
EDIT2: It looks more complicated than I thought. Predbat is continuing to put my KH7 inverter into Backup mode when the state is HoldChrg or Chrg, and while the inverter draws power from the grid it does not export any of the excess solar being generated at the time. So for example right now it is importing at 18.71p and discarding all of the excess solar being generated.
I verified this behaviour by looking at my Octopus account data for Tuesday at 10-11:30am. It was showing imports >1kW and exports <0.02kW, even though there was >2kW of excess solar being generated. Could this be a bug in the inverter firmware?

[chalfontchubby]

🤖 Claude Code again - dug into this properly, including the reporter's later EDIT/EDIT2 observations. Summary for @springfall2008 since I think there's a real, fixable bug underneath the confusion.

The reporter's "Backup mode" theory doesn't hold up

Checked both FoxESS control paths in the codebase:

• The cloud service-API path (fox.py) only ever writes workMode: 'SelfUse' in its schedules - 'Backup' appears exactly once, inside a metadata list of what the underlying select entity can hold, never something Predbat chooses to write.
• This reporter's actual path (has_service_api: false, confirmed from his apps.yaml) - adjust_inverter_mode() (inverter.py:2221-2223) has an explicit branch: if self.inv_has_fox_inverter_mode: new_inverter_mode = "SelfUse", comment "for fox we only use selfuse as the rest is done by schedule". No branch anywhere produces "Backup".
• Cross-checked his actual predbat.log: zero occurrences of "backup", case-insensitive, in ~24k lines.

So whatever set his inverter's display to "Backup" wasn't Predbat. Also, his EDIT theory ("drawing from the grid at 15.2p while simultaneously exporting at 8.7p") isn't physically possible over a single grid connection at a single instant - that's almost certainly two different moments within the same half-hour settlement window (solar/load both fluctuate) being read as concurrent.

EDIT2 is real, though, and I think I found the actual mechanism

His EDIT2 claim - import >1kW, export <0.02kW, over 90 minutes, despite >2kW of solar surplus, checked against Octopus's own meter data - lines up with the same event as the original report (11:10am, 7 July 2026, which was a Tuesday - matches "Tuesday 10-11:30am" in EDIT2), so the attached debug.yaml/log actually cover it.

Walking the log from 10:00 (freeze charging kicks in, target = current SoC 13%):

10:00:07 Wrote 2600 to charge_rate, successfully now 2600.0
10:00:17 Wrote 0 to discharge_rate, successfully now 0.0
10:00:19 Calling charge_start_service -> select.foxess_kh7_work_mode = 'Force Charge'

This is the fallback path in adjust_charge_immediate() (inverter.py:2787-2789):

if target_soc == self.soc_percent or freeze:
    if not self.call_service_template("charge_freeze_service", ...):
        self.call_service_template("charge_start_service", ...)  # fallback

For a genuine freeze, Predbat wants a dedicated charge_freeze_service. If that's not configured for this FoxESS Modbus integration (call_service_template returns False when it can't resolve the service, per the mechanism discussed on #4329), it silently falls back to charge_start_service - the exact same call used for a real, active charge - with target_soc set to whatever SoC happens to be right now, and power at the full configured rate (2600W here).

The SoC in the log across three consecutive 5-minute cycles: 13% -> 17% -> 21%. That's not a held-flat freeze - it's a real, substantial charge (roughly 8 percentage points in 10 minutes on his battery), re-anchored upward every cycle because the "freeze" target is just "current SoC, whatever that now is" rather than a fixed line. PV (~2kW) can't fully cover a genuine ~2600W charge target, so the shortfall gets pulled from grid - which is exactly the "importing while ample solar sits unused" pattern he measured independently via his Octopus account.

This is the same visible shape as the Sigenergy freeze-charging ratchet, but a structurally different (and riskier) mechanism

We did related work recently on Sigenergy's Freeze Charging (#4392, plus an ongoing personal ratchet refinement on top of it): SoC is allowed to climb step-wise during a freeze there too, but that mechanism is passive - it watches SoC (which, with discharge genuinely blocked, can only rise from real solar surplus) and nudges the discharge_cut_off_state_of_charge floor upward to match what already happened. It never issues an active "go charge at X watts" command, so it can't pull grid power by construction.

What's happening here for FoxESS is the opposite: an active charge_start_service call, re-issued every cycle with a moving target and a real power figure. Same visible symptom (SoC ratcheting up during a labelled "freeze"), fundamentally different risk profile - one can't cause unwanted grid import, the other demonstrably does.

Suggested fix direction

When there's no charge_freeze_service available for an inverter type, falling back to a genuine charge_start_service call seems like the risky choice specifically because it's an active, rate-based command with no guarantee the underlying integration enforces the target tightly within a cycle. A passive/monitor-and-cap approach closer to the Sigenergy ratchet pattern - update a ceiling/target based on observed SoC rather than repeatedly commanding an active charge - would avoid this failure mode entirely for any inverter type lacking a real freeze service, not just FoxESS.

Happy to help prototype this if it's a direction you want to take, but wanted to get the actual root cause and a concrete comparison point in front of you first rather than just proposing code.

[chalfontchubby]

Split the freeze-charge/grid-import finding out into its own issue, since it's a distinct, structural bug rather than part of the original arbitrage question: #4424