Plan discharges at a worse price while leaving better adjacent prices completely unused, right before the main high-price export window

[mbuhansen]

Description
When the battery needs more capacity than the discharge rate can deliver within the best-priced export window, Predbat pulls the extra discharge from a much cheaper, non-adjacent hour instead of from the better-priced hours immediately next to the main window. This leaves higher-priced hours completely unused while discharging at a worse price further away in time.

Environment
Predbat version: v8.45.3
Inverter: Kostal (soc_max 42.53 kWh, discharge rate 10.8 kW)
Relevant config: combine_rate_threshold(2.0), metric_min_improvement_export(3.0øre), metric_min_improvement_export_freeze(3.0øre), metric_battery_cycle(4-6øre/kWh), inverter_loss(5%), battery_loss(4%), battery_loss_discharge(4%), inverter_hybrid(True)
Evidence
Plan computed 2026-07-18 19:03:29, Export windows filtered:

18-07 19:50:00 - 18-07 20:00:00 @ 78.88øre -> target 91%
18-07 20:00:00 - 18-07 21:00:00 @ 92.28øre -> (not present, target stays 91%)
18-07 21:00:00 - 18-07 22:00:00 @ 100.80øre -> (not present, target stays 91%)
18-07 22:00:00 - 19-07 01:00:00 @ 104.01øre -> target 9%
So the battery is planned to discharge from 91% down to 9% (82 percentage points ≈ 34.9 kWh of a 42.53 kWh battery) entirely within the 22:00-01:00 (~104øre) window, while the 92.28øre (20:00-21:00) and 100.80øre (21:00-22:00) hours in between are left completely untouched (SoC held flat), and a small early discharge is instead taken at 78.88øre (19:50-20:00) — the worst price of the four candidate hours.

Analysis
The discharge rate is 10.8 kW, so the 3-hour window (22:00-01:00) can deliver at most 3 × 10.8 = 32.4 kWh — less than the 34.9 kWh the plan wants to move in that window. So it makes sense that some discharge has to happen outside the main window due to the power limit.

However, if extra time is needed, it should be taken from the best available adjacent price first (100.80øre @ 21:00, then 92.28øre @ 20:00) before resorting to a cheaper, more distant hour. Instead the plan skips both of those and discharges at 78.88øre, which is worse than both of the skipped hours. This looks like the price-level sweep in the optimiser (Optimise price set X, pass normal/trim/low) accepts a lower price threshold that happens to improve the metric, without checking whether an already-available higher-priced adjacent hour would have covered the same shortfall more cheaply.

Internal trace showing the threshold being accepted:

2026-07-18 19:03:25.362214: Optimise price set 92.2øre, pass normal, price 92.28øre ... best_metric -5023.92øre (no improvement)
2026-07-18 19:03:25.393257: Optimise price set 78.8øre, pass normal, price 78.88øre ... best_metric -5090.34øre (improves)
Expected behavior
When the discharge rate limit forces some export volume outside the primary high-price window, Predbat should fill that overflow from the highest-priced unused adjacent hours first (here: 100.80øre, then 92.28øre) before considering any cheaper hour further away.

Actual behavior
The plan leaves two better-priced hours (92.28øre, 100.80øre) completely unused and instead discharges at a worse price (78.88øre) two hours earlier to make up the shortfall.

predbat (5).log

predbat_debug.yaml (1).txt

predbat_plan (1).html

[mbuhansen]

Additional observation (recurring pattern across multiple days/configs)

Beyond the specific example above, I've observed this behaviour recurring across several days, independent of the exact combine_rate_threshold value used (tested at 0, 2, and other values):

Predbat has difficulty treating a run of consecutive, similarly-priced expensive export hours as one continuous discharge. Instead of exporting smoothly through the whole high-price block, it will sometimes pause/reduce discharge partway through the most expensive hours, and then resume exporting again later once prices have already dropped to a cheaper level.

The net effect is that some of the battery's capacity ends up being sold at a worse price later, instead of being sold during the peak-price window it was originally held back for — which defeats the purpose of holding that energy back in the first place. This isn't a one-off glitch; it shows up repeatedly across different evenings and different combine_rate_threshold settings, suggesting the underlying segmentation/optimisation of adjacent high-price hours is the common factor, rather than any single config value.

It would be good to understand whether the planner treats each priced hour as an independent optimisation unit even when adjacent hours
are part of what should logically be one continuous "sell now" opportunity, and whether that segmentation could be made more robust so a run of good export prices is handled as a whole rather than hour-by-hour.

Here are new log and screenshot off a weird export plan it just made. Load kwh is also wrong values ny normal load is not so little as planed.

predbat_debug.yaml (2).txt

predbat (7).log

predbat_plan (3).html

[mbuhansen]

Now today it has changed the export plan again in the middle of the export, and it stops the export in the middle of the most expensive slot, and later will export at a cheaper price. Here are some new logs, this is what it has been doing for the last month or more.

predbat (9).log

predbat_plan (4).html

predbat_debug.yaml (3).txt

apps.yaml.txt

[springfall2008]

I reproduced this locally from the attached debug YAML using unit_test.py and traced it through the optimiser. The conclusion is that this is plan stickiness from your metric_min_improvement_plan setting, not a fault in the export/discharge placement logic.

What I found

Feeding your exact rate data into a fresh calculate_plan (on both v8.45.3 and current main) produces the correct plan: it holds the battery and exports the pre-peak overflow into the 100.80øre window (21:50→01:00), leaving the cheap 78.88øre slot alone — exactly what you'd expect. So the optimiser already knows the right answer, and the export window-sizing logic already tries partial windows.

The catch: that correct plan is only about 10øre better across the whole 48h horizon than the plan you were running (the difference is ~2kWh shifted from 78.88 to 100.80, largely offset by battery-cycle cost). You have metric_min_improvement_plan = 10 (default is 2.0). Each cycle, Predbat compares the freshly-computed plan against the previous plan and, per plan.py L1182, keeps the previous plan unless the new one is better by more than that threshold. Your own log shows this gate firing almost every cycle:

Previous plan best metric is -3211.21 … new plan best metric is -3205.87
New plan metric is not significantly better (metric_min_improvement_plan 10.0) … using previous plan

So a once-computed, slightly-worse plan gets carried forward indefinitely because no recompute beats it by >10øre.

Recommendation

Lower metric_min_improvement_plan back toward the default (try 2). That lets Predbat adopt the better plan when it finds it. metric_min_improvement_plan is a deliberate anti-churn control, so a high value trading a little optimality for plan stability is working as designed — this isn't a bug in the discharge logic.

I'll close this as configuration-related, but please re-open if lowering the threshold doesn't resolve it. Thanks for the excellent debug data — the log trace made this straightforward to pin down.

[mbuhansen]

Hi again.

I'm sorry to say this but it has nothing to do with the metric_min_improvement_plan setting. I changed it back to 2 and it didn't help my problem. However, in this log you get now it is 3 øre.
Predbat can calculate a perfect export plan, early in the day when the battery is charging the plan is perfect, it was also today with very high export prices. It made a perfect plan starting export at 18:50 and ending at 22:00.
It started as it should and discharged the battery until 20:00, then it stopped because it wanted to wait until 20:40 to start discharging again, right in the most expensive hour, and it made a plan that you can see in html_plan( i now see i not get download html correct). This is my problem and it actually does it daily, at the beginning of the day great export plan, but when export is underway it fails with bad plans, and it misses the high export prices.

20:05 it calculate the bad plan.

In log 11 here 15 minutes later it actually made a good plan again, but we'll see if it holds up until it finishes discharging.
I've tried many different settings but haven't solved the problem.

apps.yaml (1).txt

predbat_debug.yaml (4).txt

predbat (10).log

predbat (11).log

[mbuhansen]

predbat_plan (6).html

predbat (12).log

[mbuhansen]

2026-07-29 20:05:04.673881: - Your estimated bill for today is Kr-65.38 and tomorrow is Kr-59.60

2026-07-29 20:05:12.462490: Previous plan best metric is -15602.7 (cost -16145.1) and new plan best metric is -15817.11 (cost -16308.52)
2026-07-29 20:05:12.462557: New plan metric is significantly better from previous plan, using new plan
2026-07-29 20:05:14.428307: - Your estimated bill for today is Kr-61.01 and tomorrow is Kr-59.72

Here i found some logs where it think -61 kr is better than -65 kr. this is not correct.

2026-07-29 20:05:14.428395: - Your next export slot will be in 35 minutes where export rates will be very good (196.5øre).
It was good from 20:00

2026-07-29 20:05:14.710693: Adjust idle time, charge 00:00:00-00:00:00 discharge 18:50:00-22:01:00
2026-07-29 20:05:14.710809: Adjust demand (idle) time computed is 22:01:00-23:59:00
2026-07-29 20:05:14.710878: Next export window will be: 2026-07-29 20:40:00+02:00 - 2026-07-29 21:01:00+02:00 at reserve 55.0
2026-07-29 20:05:14.710912: Not setting export as we are not yet within the export window - next time is 07-29 20:40:00 - 07-29 21:00:00

i cant see what the real problem is. Hope you can help.

[mbuhansen]

Claude code have looked at the log, are you agree.
I run test now, and can make pr if it work.

BUG-export-flapping-tweak-plan.md

[mbuhansen]

Test is run today with change in plan.py it make a perfect plan and dont break export plan anymore.

PR is made with change.
#4398

[chalfontchubby]

Fixed and merged — PR #4402 supersedes the earlier #4398 (your original diagnosis and field logs, refined by springfall2008 into a smaller/better-measured fix targeting tweak_plan/second-pass regressing an in-progress export). You confirmed the precursor fix worked cleanly on your case. Closing this out - thanks for the detailed reports and the patience through a wrong first theory.