Predbat Exports too Early. Min_Improvement_Swap Ignored

[willspring]

Describe the bug
Predbat schedules export too early in the day, lesving me short of battery in the evening if I want to use the hot tub or air conditioning. predbat_metric_min_improvement_swap is set up to -3.0p and it still occurs. The plan seems sensible early in the day, with all export scheduled for the evening to run the battery down to minimum ahead of the 2330-0530 cheap rate charging period on IOG. As the day progresses predbat changes the plan and it exports throughout the afternoon.

Expected behaviour
Given my config I'd expect Prebat to not export and maintain as high battery SOC as possible until as close to the 2330 cheap rate period as possible.

Predbat version

8.46.1

Environment details

• Givenergy Gen 2 5kw inverter and 9.5kwh battery
• HA running on Synology NAS

Screenshots
If applicable, add screenshots to help explain your problem. The most useful ones can be your battery chart, the Predbat HTML plan and your current settings in HA.

predbat-4.log

predbat_plan-3.bin.txt

[chalfontchubby]

(Posting as Claude, an AI assistant helping investigate this, working with @chalfontchubby)

Took a look at the attached log. A couple of things worth checking on your end:

best_soc_keep: every "Calculate Best options" line in predbat-4.log shows best_soc_keep(0.0 kWh). That's likely relevant to what you're describing - worth reading the docs section on best_soc_keep and checking whether it's configured the way you'd expect.

metric_min_improvement_swap: this one isn't actually being ignored - the log shows it applied correctly at -3.0p on every "Swap export optimisation" line, matching what you set. The 0.1p value you may also have spotted in the log belongs to a different pass (optimise_swap_charge, charge-window swaps, not export) - that one intentionally uses its own small fixed threshold rather than your configured value, since the negative bias in metric_min_improvement_swap is deliberately there to favour later export windows on close calls, which would cause harmful churn if reused for charge swaps. So both settings are behaving as intended here, just perhaps not as expected.

Worth trying best_soc_keep and seeing if that resolves it before digging further - if it does, feel free to close this out as configuration rather than a code bug.

[willspring]

(Posting as Claude, an AI assistant helping investigate this, working with @chalfontchubby)

Took a look at the attached log. A couple of things worth checking on your end:

best_soc_keep: every "Calculate Best options" line in predbat-4.log shows best_soc_keep(0.0 kWh). That's likely relevant to what you're describing - worth reading the docs section on best_soc_keep and checking whether it's configured the way you'd expect.

metric_min_improvement_swap: this one isn't actually being ignored - the log shows it applied correctly at -3.0p on every "Swap export optimisation" line, matching what you set. The 0.1p value you may also have spotted in the log belongs to a different pass (optimise_swap_charge, charge-window swaps, not export) - that one intentionally uses its own small fixed threshold rather than your configured value, since the negative bias in metric_min_improvement_swap is deliberately there to favour later export windows on close calls, which would cause harmful churn if reused for charge swaps. So both settings are behaving as intended here, just perhaps not as expected.

Worth trying best_soc_keep and seeing if that resolves it before digging further - if it does, feel free to close this out as configuration rather than a code bug.

This doesn't describe the issue properly. I want Predbat to use all the battery capacity and export down to empty, but it should do that at the end of the day rather than exporting early in the day and leaving me short of battery power so a soc_keep of 0 seems correct after reading the predbat documentation and even though a improvement_swap of -3.0p is set it seems not to be working or exports would be pushed later in the plan but they are not.

Today the planning is even more nonsensical. It's exporting before a planned saving session but not for the complete duration of the session.

predbat_plan-4.bin.txt

predbat-5.log

[chalfontchubby]

(Posting as Claude, an AI assistant helping investigate this, working with @chalfontchubby)

Thanks for the extra detail, and the plan image - that's a clearer picture. To be precise about what's happening: it's not that min_improvement_swap/best_soc_keep are being ignored, and it's not about how much gets exported - both look correct. What might be off is where within a run of same-priced slots the export lands - i.e. whether a later slot at the same price gets used to its full capacity before an earlier one at that price gets touched at all, rather than spreading across both.

To check that properly I need to see the actual export window boundaries the optimiser is working with before it makes that decision (whether adjacent same-price half-hours are being treated as one window or several) - which isn't visible in the log or the plan table, only in a full predbat_debug.yaml capture. Would you be able to attach one from a run where this shows up? The web UI has a "Create predbat_debug.yaml" link for this.

[willspring]

predbat_debug-1.bin.txt

Here is the debug yaml

[chalfontchubby]

(Posting as Claude, an AI assistant helping investigate this, working with @chalfontchubby)

Traced through your debug.yaml properly. To be clear about what we did and didn't confirm: best_soc_keep and metric_min_improvement_swap are both working correctly, not the cause. We found a possible mechanism instead, but the debug.yaml you attached was captured at a different moment than your screenshot (a plain continuous drain at one flat rate, not the flat-then-high-rate pattern in the screenshot), so we can't yet confirm it's actually what's happening in your case.

The possible mechanism: with combine_export_slots off (your setting), export windows get deliberately capped at ~30 minutes each even across a completely flat, unbroken rate - it's intentional (lets the optimiser use "some, not all" of a long cheap period), but the side effect is a long flat-rate span can get chopped into several separate windows with real gaps between them. Separately, the pass that tries to push export into a later, equally-priced window only compares a limited number of windows at a time, not the whole day. Combined, a very fragmented day could mean an early window and a same-priced later one just never get compared - which would match what you're describing.

Two things that would help nail this down:

1. Next time you see this happen, could you grab both a predbat_debug.yaml and a screenshot of the plan at the same time? That lets us match the visual pattern to the actual window data behind it, rather than guessing from a debug.yaml that turned out to be a different scenario.
2. Separately, could you try turning on switch.predbat_combine_export_slots and letting Predbat replan (this can take a little while to fully settle)? If that changes the early-export behaviour, that's a strong pointer confirming the mechanism above - and if it doesn't, that rules it out and points us elsewhere. Either result is useful.

No need to do anything else for now - just those two, whenever it next reproduces.