Best plan lets midday PV surplus export at ~20-40gr while same-day evening rates hit 79-100gr — is there a way to reserve capacity for the peak?

[lesiuu91-droid]

Setup: FoxESS H3 Smart 12kW, 3x EP6 (17.28kWh), Solcast forecast,
Poland G12w import tariff + real RCE export rates via metric_octopus_export.
Predbat v8.53.1, currently in Monitor mode (waiting on grid export approval),
so this is all from the simulated Best plan.

I have consistent daily PV production around 20-25kWh, while daily house
load is only about 10-14kWh. Looking at tomorrow's Best plan, the battery
reaches 100% SoC by ~11:30 and sits flat until ~17:30, while genuine PV
surplus (PV output minus load, roughly 0.5-2kWh per 30-min slot) flows
straight to export during that whole window — at raw export rates of only
20-48gr/kWh.

The same day's evening rates (18:00-21:00) hit 79-100gr/kWh — 2-4x higher.
Evening house load is modest (~0.2-0.4kWh per slot), so self-consumption
alone doesn't account for holding that midday surplus back; there appears
to be genuine spare capacity (roughly 7-9kWh/day) that could be timed to
the evening peak instead of being exported immediately at the low midday
rate — with no round-trip/rebuy risk involved, since this is same-day
surplus PV, not grid-bought energy.

I understand why cross-day arbitrage (buy cheap at night, sell high later)
correctly gets rejected once losses are accounted for (I checked
export_rate_adjusted vs import_rate_adjusted in my plan data and the
margin is negative there, which makes sense). But this midday-surplus
timing question seems different, since it's not about buying anything back.

I've already tried lowering pv_metric10_weight (0.03) and setting
rate_high_threshold (1.0) with combine_export_slots off, but the plan
behaviour is unchanged — the battery still just tops out early and
passively exports the rest of the day's surplus at whatever the current
rate is.

Is there a setting or mechanism that makes the planner intentionally hold
back some SoC headroom during a period of surplus PV, in order to shift
that stored surplus to a later, more valuable export window the same day?
Or is this a genuine planning limitation? Happy to share the full plan
JSON/debug export if useful.

[lesiuu91-droid]

Found a related open issue that describes the same underlying problem:
#1937 (Grid friendly mode - Solar charging and export). Same pattern:
battery tops up early in the solar production window, then any further
surplus exports immediately at whatever the current (often low midday)
rate is, rather than the planner deliberately holding some SoC headroom
to redirect that surplus toward the day's best export window later.

For context on the scale of the gap: a neighbour of mine (same country/
market, similar setup) apparently has some kind of black-box optimisation
from their installer that does account for this, and reportedly averages
around 52gr/kWh on exported energy across peak-priced hours, versus ~16gr/
kWh for a comparable setup without it — which lines up closely with the
~20-30gr midday dump vs ~80-100gr evening peak I'm seeing in my own plan.
So this isn't a marginal optimisation, it looks like a meaningful fraction
of potential export revenue being left on the table for anyone with
production well in excess of load.

Happy to provide my plan data/debug export if it's useful for prioritising
this.

[gcoan]

currently in Monitor mode (waiting on grid export approval),
so this is all from the simulated Best plan.

If you are in Monitor mode then predbat will NOT be planning any activity it is simply reporting what your current inverter settings are https://springfall2008.github.io/batpred/customisation/#predbat-mode

If you want Predbat to start planning and optimising your battery you need to set it to one of the Control modes. And turn set_read_only on if you don't want Predbat to actually control your inverter.

[lesiuu91-droid]

Thanks for the clarification — that explains a lot, I was analysing Monitor
mode output thinking it was already the optimiser's real plan.

Switched to Control charge & discharge with Set Read Only on, and now see
real forced charge/export windows. One new question this raised: the plan
now aggressively exports down to near the reserve floor (e.g. 94%→~15% SoC
in a single evening high-rate window), then only tops up minimally overnight
to cover immediate load — it isn't buying back what it sold, which is good.

But I'm not fully comfortable with how thin the resulting overnight safety
margin is (only a few % above the hard reserve). I understand
pv_metric10_weight controls general PV-forecast risk aversion — is that
the right lever to make the planner keep a more generous overnight buffer,
or is there a more direct "minimum overnight reserve" type setting I'm
missing?

Separately — worth flagging for anyone on Poland's net-billing scheme
(depozyt prosumencki): exported energy value only offsets the bare
commodity portion of a future bill, not the distribution charge, so
roughly 30-40% of a future kWh's retail price still has to be paid in cash
regardless of deposit balance. That makes any sell-now/rebuy-later cycle
worse than the raw import/export rate comparison suggests. Not sure if
that's already reflected anywhere in the loss/cost model, just flagging
it as a market-specific quirk that might catch other Polish users out too.

Thanks again for the help!

[gcoan]

real forced charge/export windows. One new question this raised: the plan
now aggressively exports down to near the reserve floor (e.g. 94%→~15% SoC
in a single evening high-rate window), then only tops up minimally overnight
to cover immediate load — it isn't buying back what it sold, which is good.

You will find the predbat plan changes through the day and night as the plan rolls forward and predbat "sees" more future load demand.

But I'm not fully comfortable with how thin the resulting overnight safety
margin is (only a few % above the hard reserve). I understand
pv_metric10_weight controls general PV-forecast risk aversion — is that
the right lever to make the planner keep a more generous overnight buffer,
or is there a more direct "minimum overnight reserve" type setting I'm
missing?

Predbat optimises your cost so uses up as much of your battery as it can do. Worth you asking why you would not want to use the whole battery and why keep some back in reserve unused?
pv metric 10 weight takes a more pessimistic view of solar generation, so you can change that, but better to get your generation as accurate as possible first.
If you want to keep more in the battery the adjust input_number.prdbat_best_soc_keep

[lesiuu91-droid]

Thanks for pushing on this, it's a fair challenge — let me answer the "why keep anything back" question with an actual number instead of a vague safety instinct.

I'm not trying to preserve a fixed cushion. I built a small Home Assistant sensor that calculates, every day, exactly how much energy the house will need overnight before tomorrow's PV production restarts. It takes tomorrow's forecasted sunrise-equivalent PV start time from Solcast, subtracts my predicted load between now and then using Predbat's own load_energy results, and adds a margin scaled to the spread between Solcast's p50 and p10 estimates, since a cloudier-than-forecast tomorrow morning is the actual risk I'm hedging against, not grid unreliability or anything else. That number gets converted to a target SoC percentage and updates through the day as the forecast changes. So the answer to "why not use the whole battery" is: I do want to use the whole battery, right down to my 10% hardware floor, on every single day — I just want the target for how much stays untouched tonight to be a real, forecast-driven number rather than zero or an arbitrary constant.

That's actually why I keep landing back on wanting something other than best_soc_keep. In my own testing, setting best_soc_keep to that calculated target didn't behave like a "stop selling below this point, but still let ordinary house load drain it overnight" rule. It behaved like a hard floor the planner actively defends with grid imports, even overnight when there's no export happening at all and nothing to gain from holding the level artificially. On my tariff that means paying 65gr/kWh to defend a level that would otherwise have drained for free on house load, which is a straightforwardly worse outcome than just letting it drain.

So the specific question I have for you or springfall2008: is defending the level via grid import the intended design for best_soc_keep, or is it supposed to only suppress additional selling below the target while still permitting normal discharge on load? If the former is intended, then best_soc_keep is solving a different problem than mine (a hard minimum reserve enforced at all costs, useful for backup-power scenarios) and I should stop reaching for it. If the latter is intended and what I saw was a bug or a config issue on my end, I'd like to know what I got wrong, because right now my only working substitute is computing the target externally and using per-slot rate overrides to cap sold volume, which works but feels like it's reinventing something that should exist natively.

On pv_metric10_weight — understood that it's the general forecast-risk lever, and I agree improving actual generation accuracy comes first. But it applies globally across the whole plan horizon rather than specifically to the overnight-reserve calculation, so even with it tuned well I don't think it replaces a day-specific "keep enough for tonight, sell everything else" target the way the calculation above does.

[gcoan]

best soc keep sets a soft limit to encourage predbat to not let the battery drop below this level, there is a weight factor you can set as well to reduce how hard/strong predbat does this 'keeping'

best soc min sets a hard minimum level that the battery won't drop below, and will definitely charge on higher rates to maintain this

in my experience though I would avoid using either as it can distort the plan in ways you may not want to occur (as you note).

Predbat will plan to use all the battery based on solar and load forecast. If you want to be more pessimistic on the solar forecast then do increase pv metric 10 weight. Also don't forget the load scaling factors which by default will increase your load by 1.05 to allow for unexpected additional load. Your sensor is probably not doing that so hence the discrepancy

[lesiuu91-droid]

Thanks for the pointers so far. Let me describe exactly what I'm trying to
achieve, since I think I've been asking for pieces of it rather than the
whole picture.

I have high daily PV production (20-25kWh) relative to load (10-14kWh),
so on most days there's a genuine surplus. What I want is for the planner
to actively manage a daily cycle like this:

• Evening (e.g. today, Tuesday, battery at 74%/12.8kWh): at the day's
  highest-price window (e.g. 20:00), calculate how much I'll need to get
  through the night based on typical usage (e.g. ~5kWh), add a safety
  margin (e.g. +2kWh) for tomorrow's solar being late or weak, and sell
  the rest (~30% of the battery in this example).
• Overnight: run entirely off the battery, no grid import at all — I have
  the stored capacity, buying anything defeats the purpose even at the
  cheap rate.
• Early morning once solar starts (e.g. 7:00): top up the safety margin
  slightly first (in case of a sudden weather change), then self-consume
  and sell any further surplus as it's generated.
• Mid-morning (e.g. 11:00), once import hits its cheapest point: stop
  selling, switch to charging hard toward 100% to be ready to cover the
  rest of the day plus build reserve.
• Once full (e.g. 18:00) and solar tapering off: repeat the evening
  decision, but scale the amount sold based on tomorrow's forecast — e.g.
  if tomorrow's sun doesn't start until 9-10am (later than today), sell
  less than today; if tomorrow looks like a poor production day overall
  (e.g. ~30% of a good day), sell very little or nothing.

So the target amount sold each evening should vary day to day based on
the next day's solar forecast, not be a fixed percentage or fixed kWh.

I've tried best_soc_keep (fixed kWh floor) — it stopped selling below the
floor, but the plan still imports at the cheap overnight rate to cover
load rather than draining the kept buffer, which isn't what I want when
I have surplus production. I'm about to try metric_self_sufficiency,
which looks like it should bias the plan away from importing in general.

Is metric_self_sufficiency + best_soc_keep together the right combination
for this, or is there a more direct way to get Predbat to size the daily
"keep" amount dynamically from tomorrow's PV forecast rather than using a
fixed number? Happy to be pointed at relevant code/settings if this needs
a more custom approach (e.g. a template sensor feeding into best_soc_keep
daily) — just want to make sure I'm not missing a built-in way to do this
first.

[lesiuu91-droid]

Ran three concrete experiments, results below. None reproduce the target
behaviour (sell down to a dynamically-computed daily safety margin at the
day's peak price, then hold and refill from solar).

1. Baseline (no self-sufficiency/keep settings): sells aggressively down
   to ~13-15% SoC at the evening peak, then imports at the cheap overnight
   rate rather than draining the reserved margin — ends up paying cash for
   grid power it didn't need to buy.

2. best_soc_keep=3.1kWh: correctly stops selling below the floor, but
   still imports at the cheap rate to cover load instead of drawing down
   the kept buffer — same problem, just at a higher floor.

3. metric_self_sufficiency=70gr/kWh (with best_soc_keep back to 0):
   overcorrected — barely force-exports at all now, even at clearly good
   prices. E.g. today's plan shows plain Demand (no Exp state) through a
   94gr/80gr evening window, the battery just drains passively overnight,
   then a small forced export finally triggers the next morning at 84gr
   (a worse price, from a smaller remaining pool). Same pattern repeats
   the next evening: battery hits 100% by 15:00, sits idle, then a
   100gr/96gr evening window passes with no export at all.

What I'm actually trying to get: each evening, at the best price window,
sell everything above (predicted overnight load + a safety margin sized
from tomorrow's solar forecast) — not a fixed kWh/percentage, and not
"avoid import at almost any cost" either. Is there a documented way to
get this specific shape of behaviour, or does this need a custom
automation driving best_soc_keep dynamically day to day (which is where
I'll head next if there's no simpler built-in option)? Happy to share
the three plan exports if useful.

[lesiuu91-droid]

Fourth data point, and I think this settles it. best_soc_min (2.5kWh)
produces the same pattern as best_soc_keep and metric_self_sufficiency:
the plan enters a "HoldChrg" state and holds SoC completely flat overnight,
importing at the cheap rate to cover load rather than draining toward the
floor — I now understand this is documented behaviour (the battery holds
once at/above a planned future charge target), not a bug, but it means
none of these settings produce "sell down to a computed daily buffer, then
freely self-consume from what remains, only importing as a last resort."

Also confirms the same evening-sale gap persists independent of settings:
battery reaches 100% early afternoon (14:30 today), sits idle through the
best price window (100gr at 19:00) with no forced export.

Given four different lever combinations reproduce the same shape of
result, I'm fairly confident this specific behaviour isn't achievable
through existing config alone. Planning to build a small daily automation
that computes tonight's needed reserve from tomorrow's Solcast forecast
and sets best_soc_keep dynamically each evening, rather than a static
value. If there's a reason this is harder than it sounds, or a setting
I've still missed, I'd genuinely appreciate the pointer before I start
building — otherwise will report back once it's running.

[lesiuu91-droid]

Apologies for the string of updates — I've been iterating through
combinations live and reporting as I go, rather than batching this into
one clean report. For anyone following along, here's where it landed.

Found real progress: switch.predbat_set_export_freeze had somehow been
toggled off (default is True) during my earlier resets. Restoring it to
True, combined with switch.predbat_export_more_solar = True, produced the
first genuine forced export at the best evening price I've seen across
all these tests — the plan now shows an actual "Exp" state at today's
94gr peak, selling down to a defined 50% floor rather than either not
selling at all or draining to the hard reserve.

Remaining gaps: overnight still shows "FrzChrg" — holding the floor and
importing at the cheap rate to cover load rather than draining the
reserved capacity — and tomorrow evening's peak (100gr) still shows plain
Demand with no forced export. So it's landing correctly on day 1 but not
day 2 of the plan, and still prefers import over self-consumption from
the held buffer overnight.

Given this is much closer than my earlier reports suggested, is there a
further setting that affects how confidently Predbat acts on the second
day of the forecast vs the first, or that governs preferring drain-from-
reserve over cheap import specifically (as opposed to the general self-
sufficiency dial)? Happy to share the current full settings dump if
useful at this point.