Multi-inverter rework: tracking issue

[chalfontchubby]

Tracking issue for a rework of multi-inverter support. Filing this as the umbrella so the discussion happens in one place; the intent is to spin off separate sub-issues per workstream once we've agreed the shape, not to fix everything here.

Prompted by the #4842 thread, where @gcoan and I ended up agreeing that "multi-inverter support was a bit of an edge case" and worth a proper look rather than another point fix.

Full write-up: https://claude.ai/code/artifact/e91af2a5-3440-459e-8daa-a3a31d7f32d5

Everything below is verified against v8.54.2 / main 4b42b7a1 by reading the code; the numbers are computed from the formulae as written, not measured on hardware.

The shape of the problem

Predbat has three separate models of a multi-inverter system and no shared one:

1. Planner — optimises a single virtual battery made by summing the fleet. soc_kw, soc_max, rates and limits are plain sums; battery temperature is an unweighted mean; the charge curve is measured from inverter 0 and applied to everything.
2. Executor — splits that fleet-wide answer back out per inverter.
3. Balancer — an independent 60-second reactive loop that builds its own Inverter objects, knows nothing about the plan, and can only write rate 0 or rate max.

Almost every reported multi-inverter fault sits in one of the two seams. It all works correctly when every inverter is identical — which is what the test suite covers, and what real fleets grow out of.

The headline finding

Not any of the existing bug reports: the executor's target split actively manufactures imbalance from a balanced start.

adjust_battery_target_multi() (execute.py:807-808) apportions the fleet SoC delta by each inverter's share of total charge rate and never reads soc_max. On @gcoan's 9.5 + 5.2 kWh fleet, both on 2.6 kW, starting perfectly balanced at 50/50:

Fleet target	9.5 kWh ends	5.2 kWh ends	Spread	Fleet actually reaches
60%	58%	64%	6 pts	60%
80%	73%	92%	19 pts	80%
90%	81%	100%	19 pts	88%
95%	85%	100%	15 pts	90%

Rate-proportional and capacity-proportional splits optimise different things — the first makes inverters finish together, the second makes them end balanced. We currently pick the first and then run a separate subsystem to undo the consequences. Above ~90% the small battery saturates, the surplus isn't redistributed, and the fleet silently lands short of the target the plan was costed against. A capacity-proportional split hits every one of those targets exactly, with zero spread.

This is, I think, the actual mechanism behind #830.

Twelve findings

	Finding	Refs
F1	Target split is by charge rate, not capacity — creates imbalance from a balanced start	#4842, #830
F2	Once the smallest battery saturates the fleet silently undershoots its own plan	#830
F3	Planner can't model a fleet whose aggregate rate falls as members fill — under-books charge windows by ~22 min on the #830 fleet	#830
F4	Balancer's only actuator is full-off/full-on, so correcting imbalance under load forces peak-rate import	#3172
F5	Balancer's unconditional reset can overwrite a deliberate hold, breaking freeze charge on 22 of 24 inverter types	#829
F6	can_power_house is structurally unreachable during a force export	#4842
F7	Partner selection is a fixed (i+1) % n ring — arbitrary for 3+ inverters	#4842
F8	Fleet capability derived inconsistently: first-inverter-wins for freeze/reserve, fleet-AND for feed-in-first	#4690
F9	Battery temperature is an unweighted mean; charge curve measured from inverter 0 only	—
F10	Every multi-inverter test uses two identical inverters, so none of the above is covered	—
F11	Planner already chooses a fleet export power, but execution applies it uniformly instead of allocating it	#4842
F12	Imbalance has no cost anywhere in the plan, so a cheaper-but-divergent option always wins	—

F5 is worth separate attention as a live correctness bug of the same family as #4690. The balancer's reset loop is ungated by state: if an inverter's discharge rate reads zero and any other inverter is discharging, it's reset to max. But rate 0 is exactly how we express a freeze charge and how set_discharge_during_charge = off is enforced on any inverter without timed pause — and only GE and GEC declare has_timed_pause. On the other 22 types the balancer can undo a hold the executor just established and keep it undone until the next plan cycle. That matches the symptom in #829 (discharge rate observed at 2600 where it should have been 0), open since Jan 2025.

The thing that makes this tractable

F11 is the encouraging one. With set_export_low_power on, export power is already encoded in the fractional part of the export limit (export_rate_adjust = 1 - frac), and the planner already scores a ladder of 0.0 / 0.3 / 0.5 / 0.7 = 100/70/50/30% of max (plan.py:2294-2299). The lever exists and is already optimised.

What's missing is allocation: execute.py:493 multiplies every inverter's rate by the same factor. Pick 50% on a two-inverter fleet and both run at half, rather than the fullest at max and the other off. So merit-order dispatch is an execution-layer allocation of a number we already compute, not a new planning concept.

Import is asymmetric — find_charge_rate() is already per-inverter and capacity-aware, so the charge side needs no allocator, just F1 fixed.

A dispatch rule that covers the whole range

Expressing output as C-rate (C = P/E, per hour) makes the invariant exact: every inverter at the same C-rate loses SoC% at the same speed, whatever their capacities. Power proportional to capacity is equal C.

That gives a fleet property we have no concept of today — the highest power deliverable while staying balanced, set by the member with the lowest C ceiling:

P_balance = min(P_i / E_i) × ΣE_j

Fleet	P_balance	P_max	ceiling
#830 — 9.5 + 5.2 kWh	4.02 kW	5.20 kW	77%
#4842 — 12.4 + 9.52 + 8.19	6.31 kW	8.20 kW	77%
#3172 — 19.0 + 9.5	4.50 kW	6.00 kW	75%
matched 9.5 + 9.5	5.20 kW	5.20 kW	100%

Every real mixed fleet lands at 75–77% — which falls between the existing ladder's 70% and 100% rungs, so the most useful point on the curve is currently unreachable. On a matched fleet it lands at 100% and collapses harmlessly, which is also why none of this surfaces in testing.

Balanced and unbalanced don't need separate logic. Water-fill to a common projected end-of-interval SoC, clamped by each inverter's rate limit. On the #830 fleet over 15 minutes:

Fleet state	Required	Allocated 9.5 / 5.2	Spread before → after
balanced 50/50	3.0 kW	1.94 / 1.06 kW	0.0 → 0.0 pts
balanced 50/50	5.2 kW	2.60 / 2.60	0.0 → 5.7 pts
out of balance 45/75	3.0 kW	0.40 / 2.60	30.0 → 18.6 pts
out of balance 45/75	5.2 kW	2.60 / 2.60	30.0 → 24.3 pts

One formula: capacity-proportional when balanced, merit-order draw from the fullest when not, graceful degradation to today's behaviour at full power. No modes, no thresholds.

Super power, and what it costs

P_balance is an envelope, not a cap — when the house wants 6 kW the fleet must deliver 6 kW. #3172 is the fault of treating it as a limit: that fleet holds balance to 4.5 kW of a 6.0 kW max, and our only response to exceeding it today is to zero an inverter and import the difference at peak.

Exceeding it should be freely available and simply accounted for, and the accounting has two tiers:

How the imbalance is undone	Marginal cost
Ride on planned throughput — skew allocation of load, a planned charge, or a planned export. Same energy at the same price; only which battery does the work changes.	≈ 0
Cross-charge — A into B with no grid purpose	13.3% of everything moved, for nothing

So the cost of super power isn't the imbalance. It's the risk of being left with no planned throughput to fix it on. And that risk is small because recovery is fast: 15 min at full 5.2 kW opens a 5.7-point spread, and 25 min of ordinary 1 kW demand closes it at zero cost. From a full 30-point spread — 90 min at 1 kW, 45 min at 2 kW, 295 min at 0.3 kW.

The load-bearing detail: rebalancing needs throughput, not time. An idle or frozen fleet can't rebalance at all. That's the real hazard, and the only condition under which cross-charging ever looks tempting.

Which leaves us with an inversion worth naming: cross-charging, the only rebalancing path that costs anything, ships today as a user-facing feature (balance_inverters_crosscharge). Free rebalancing on planned throughput doesn't exist at all.

Proposed workstreams

Ordered by dependency, not severity. Suggest these become the sub-issues.

• 0 — Heterogeneous fleet test rig (F10). Nothing else is safe without it. Parameterise capacity/rate/count/starting SoC; fixtures for the Predbat takes account of dissimilar battery capacities in the plan #830 pair and the Multi-inverter balancing cannot act during a force export, and the target split worsens imbalance #4842 three-way; a force-export scenario to make F6 reachable; an assertion that a balanced fleet stays balanced across a full charge.
• 1 — Capacity-proportional target split with rate feasibility and saturation redistribution (F1, F2). Highest value-to-risk change available, ~40 lines.
• 2 — Merit-order power allocator (F4, F11). One water-filling function serving both the export throttle and the balancer. Hard invariant currently held by nothing: allocated fleet power must still meet the requirement in total.
• 3 — Plan-aware balancer (F5, F6, F7). Never overwrite a deliberate zero; use the right predicate per state; pick the best partner, not the next index.
• 4 — Fleet capability resolution (F8, F9). Apply the inv_support_feedin_first reasoning consistently. Probably where the INVERTER_DEF freeze-mechanism declaration parked on Freeze hold isn't always guaranteed by execution, even when the plan assumes it (multiple instances) #4690 belongs.
• 4b — Fleet-derived ladder rung + balance tie-break (F12). Add a rung at P_balance / P_max; break ties on balance, weighted by remaining throughput.
• 5 — Per-inverter feasibility in the planner (F3). The only one touching the optimiser. Two shapes: a post-plan deliverability check (cheap, contained) or a piecewise fleet rate (faithful, but reaches into the per-minute loop and the C++ kernel). Full per-inverter planning is not recommended.
• Ongoing — observability. Publish SoC spread and cumulative cross-charged energy as entities, so any of the above can be shown to have helped.

Open questions for discussion

1. Is equal SoC% the right balance target? It makes equal C the invariant. For batteries of different age or chemistry, equal headroom or equal DoD might serve the hardware better. Water-filling supports either, but the choice propagates into the target split.
2. Should the planner deliberately choose a slower rate to preserve balance? Recommend a tie-break among options already within metric_min_improvement_export rather than a real imbalance term — the latter needs F3's model change first.
3. How much extra register traffic is acceptable? A proportional actuator writes more often than on/off. Needs an explicit deadband and minimum write interval, not just a threshold — the flash-wear caution in the docs already applies to balancing.
4. Should cross-charging remain an offered strategy? Once workstream 2 lands it's the only path that costs anything. Demoting or removing it is a visible behaviour change and wants a decision rather than a quiet deprecation.
5. Should balancing still be off by default and marked Beta? The users who most need it are turning it off because of F4.

Related: #4842, #830, #829, #3172, #4844, #3303, #4690, #2514.

@springfall2008 @gcoan — nothing here is implemented, and the phasing and the five questions are proposals rather than conclusions. Happy to start on workstream 0 whenever, since it's inert on its own.

[springfall2008]

🤖 This is an automated first-pass triage. A maintainer will review before any labels/priority drive further action.

Classification: enhancement (tracking issue) — already correctly labeled enhancement + balancing by the reporter; leaving those as-is.

Priority: skipped, per the usual rule for feature-request/tracking issues. Two of the twelve findings (F1, F5) describe live correctness bugs rather than proposed enhancements — flagging those for maintainer attention below.

Duplicates: none found. Searched for existing "multi-inverter rework" / heterogeneous-fleet tracking issues; nothing matches. This issue explicitly supersedes/consolidates #4842, #830, #829, #3172, #4844, #3303, #4690, #2514 as related reading rather than duplicating them.

Investigation: synced to current main (v8.53.5-212-gdc0793de), 5 commits ahead of the 4b42b7a1 the write-up cites — no drift in the relevant code. Spot-checked the most load-bearing claims against source rather than taking the write-up at face value:

• F1 confirmed exact: execute.py:807-808 — add_this = add_kwh * (inverter.battery_rate_max_charge / self.battery_rate_max_charge). The split is by charge-rate share only; soc_max never enters the ratio (only used later to clamp). git log -L on this block shows the only recent touch (Multi-inverter support for holds, fix hold charge blocking solar issue #4164) changed the freeze-charge branch, not this ratio — so no in-flight fix.
• F5 confirmed: execute.py:1395-1401 resets any inverter whose rate reads 0 back to max whenever the fleet total is nonzero, gated only on whether that inverter was the one this same cycle just zeroed for balance — not on whether the zero was a deliberate hold/freeze from the executor.
• F7 confirmed exact: execute.py:1355 — other_inverter = (this_inverter + 1) % num_inverters.
• F9 (has_timed_pause count) confirmed: has_timed_pause: True on exactly 2 of the 24 INVERTER_DEF entries (GE, GEC); the rest are False, matching the "22 of 24" figure.
• F10 confirmed: test_balance_inverters.py:136-138,171-172 sets soc_max/soc_max_2 both to 10.0 and both inverters' battery_rate_max to the same sensor — the balance test fixture is genuinely two identical inverters, so F5-style deliberate-hold-vs-imbalance scenarios and any capacity asymmetry are structurally untested.
• F11 confirmed: execute.py:493 applies one fleet-wide export_rate_adjust scalar to every inverter's own max rate in the same loop iteration; the ladder at plan.py:2294-2299 is exactly [0.0, 0.3, 0.5, 0.7] (as 1 - export_rate_adjust), confirming the "unreachable ~75-77% rung" observation.

Did not independently re-derive F2/F3/F4/F6/F8/F12 or the numeric balance-recovery-time table — the six findings checked all matched the write-up exactly at the cited file:line, which is a reasonable basis for trusting the rest pending maintainer review of the actual proposal.

No missing information — this is a design write-up backed by static code reading, not a runtime bug report, so the usual version/log/debug-yaml checklist doesn't apply.

Suggestion for maintainers: F1 and F5 read as narrow, independently fixable bugs (not gated on the wider rework) if a quick win is wanted before workstream planning lands — both are demonstrated above with an exact current-main line reference.

[chalfontchubby]

F4 follow-up: the balancer's deadband is structurally zero at default settings

While building the workstream 0 rig I went looking for why F4 fires as readily as it does in practice, and the answer is narrower and more fixable than "the actuator is on/off". The deadband that is supposed to stop trivial imbalances from triggering a full-rate correction cannot express a value smaller than the quantisation step of the thing it is measuring.

soc_percent is an integer. Inverter.update_status() sets it via calc_percent_limit() (inverter.py:1433), which returns min(int(x + 0.5), 100) (utils.py:1418). So the smallest non-zero imbalance the balancer can observe is exactly 1 point. Incidentally the class docstring documents it as float (inverter.py:1380) — worth correcting whichever way this lands.

The good news is that this rules out a float-equality hazard in out_of_balance, which is a bare inequality:

if inverter.soc_percent != inverters[0].soc_percent:
    out_of_balance = True

execute.py:1290-1291

The bad news is what it leaves. out_of_balance is trivially true for any difference at all, so the only real gate is the per-inverter soc_low / soc_high pair:

soc_low.append(inverter.soc_percent < soc_max and (abs(inverter.soc_percent - soc_max) >= self.balance_inverters_threshold_discharge))
soc_high.append(inverter.soc_percent > soc_min and (abs(inverter.soc_percent - soc_min) >= self.balance_inverters_threshold_charge))

execute.py:1332-1333

Both thresholds default to 1.0 (config.py:1188-1210), the config min is 1, and fetch.py:2920-2921 clamps with max(get_arg(...), 1.0) — so 1 is also the floor. The comparison is >=. A 1-point difference therefore satisfies 1 >= 1 and passes.

That means at the default — and at every configurable value at or below the floor — the threshold provides no leeway whatsoever. It is set equal to the quantisation step, so the balancer acts on the smallest imbalance it is physically capable of perceiving. The knob only starts doing anything at 2, and the docs give no reason to move it.

What this costs on a real fleet. On the #3172 fleet (~19 kWh) one point is 0.19 kWh. That is enough to zero an inverter's discharge rate for a whole 60s cycle and hand its share of the house load to the grid at whatever the current import rate is. The imbalance being corrected is smaller than the measurement error on most of the sensors feeding it. This is F4, but the trigger is the missing deadband rather than the coarse actuator — and unlike the actuator, the deadband is fixable without the workstream 2 allocator.

I have pinned the behaviour as a characterisation test (test_balance_hair_trigger) in the workstream 0 rig, so whatever we decide has to move the number deliberately.

Deadband, and why it should not just be "raise the default"

This is really open question 3 arriving early. Raising the default to 2 or 3 would take the edge off, but I do not think a single symmetric threshold is the right shape, for three reasons:

1. Percent is the wrong unit. One point means 0.19 kWh on the Grid use during peak import time when trying to keep batteries balanced #3172 fleet and 0.052 kWh on the Predbat takes account of dissimilar battery capacities in the plan #830 pair's small battery. A threshold in percent silently means something different on every fleet, and on mixed-capacity fleets it means two different things within the same fleet — which is precisely the class of bug this rework exists to remove. Measuring the imbalance in kWh, or in the projected end-SoC terms the water-filling allocator already needs, makes it comparable.

2. One threshold cannot both start and stop an action. With a single value the balancer engages the moment it is exceeded and disengages the moment it is not, which at the boundary is per-cycle chatter — and every transition is a register write. It wants asymmetric hysteresis: engage above X, and keep going until below Y where Y is meaningfully less than X, so a correction runs to a genuinely balanced state instead of to the edge of the threshold. That also directly serves the flash-wear caution in question 3, and pairs naturally with the minimum write interval mentioned there.

3. The deadband should scale with what the correction costs. Zeroing a rate under heavy house load imports at peak; doing the same during a planned charge costs approximately nothing, because the throughput is happening anyway. A fixed threshold cannot express that, and it is the same observation as the P_balance-is-an-envelope-not-a-cap point above: rebalancing wants throughput, not time, so the tolerance for acting should be much tighter when there is throughput going spare.

So my suggestion is that workstream 3 carries a small deadband change rather than treating it as config tuning: imbalance measured in energy, separate engage/disengage points, minimum write interval, and the existing percent thresholds either rescaled or deprecated in favour of it. That does not need the allocator and could reasonably go before workstream 2 — though the acting is still full-off until workstream 2 lands, so a deadband alone reduces how often F4 bites without removing it.

One question that decides the shape: should the deadband be a user-facing setting at all, or derived from the fleet — the smallest imbalance worth an import cycle is calculable from capacity and current rates, and one fewer knob is one fewer thing set wrong. I lean derived with an override, but that is a preference rather than a finding.

Nothing here is implemented beyond the pinning test.

---

Written by Claude Code on my behalf; findings verified against current main and the numbers replayed locally.

[chalfontchubby]

Written by Claude Code on behalf of @chalfontchubby.

Two notes from working on the export limit encoding: the ladder can't express a fleet, and balance isn't always the goal

These came out of splitting the packed export limit into named fields (target / power / mode), which runs straight into F11.

1. The export ladder is fleet-scalar, and uniform scaling reaches the wrong points

F11 says the lever exists and is already optimised, which is right — but the ladder's shape is the problem, not just where the value is applied. export_rate_adjust is one fraction applied uniformly to every inverter (execute.py:493: inverter.battery_rate_max_export * export_rate_adjust), so the ladder can only ever say "every inverter at the same fraction". It cannot say "A off, B full".

Those reach almost disjoint sets. For a 3.6 + 5.0 + 2.6 kW fleet:

Uniform fraction (what the ladder can express)	On/off combinations (what it can't)
11200 W (100%)	11200 W (all on)
7840 W (70%)	8600, 7600, 6200 W
5600 W (50%)	5000, 3600, 2600 W
3360 W (30%)	—

Only full power appears in both. And the combinations are usually the better half of the pair: inverters are inefficient at low load, so three units at 30% delivers roughly the same fleet power as one unit at 100% while wasting materially more. Illustrative efficiency numbers, but the direction is not controversial.

So a (mode, power) rung — which is what I've reshaped the ladder into locally, replacing the list of floats that mixed modes and power levels — is still the wrong type for a fleet. The eventual field is an allocation, not a scalar. Worth noting the cost before anyone builds it: 4 power rungs becomes 4 × (combinations per rung), and the optimiser is already ~40% of plan time with the kernel taking the other 60%.

2. Equal SoC is the wrong objective in a case people are advised to build

@chalfontchubby's example, and it is a better argument than any of the asymmetric-fleet ones: two identical inverters, identical arrays, one east one west.

East fills by mid-morning, west by mid-afternoon. Left alone both end the day full and nothing is lost. The divergence between them is not imbalance — it is two arrays doing their job at different times, and it self-corrects by evening.

The balancer sees only that SoC percentages differ. soc_low/soc_high (execute.py:1329-1331) are computed purely from percentage spread against a threshold, so during a charge it sets the leading inverter's charge rate to 0 (execute.py:1369) to let the other catch up. If the PV is DC-coupled that generation is clipped — it cannot be redirected, because it only reaches that battery. Both batteries end the day part-full, having thrown away PV to stay level with each other.

Modelling it crudely (holding the throttle on, so it overstates — the real balancer re-evaluates each cycle and would oscillate rather than clamp), two 5 kWp arrays and 10 kWh batteries end at ~5.0 and ~7.9 kWh instead of 10 and 10. The magnitude is wrong; the mechanism isn't.

What makes it damning is that the hardware is identical. There is no asymmetry for a heuristic to spot, no unusual config — just an ordinary east/west install, a layout people are recommended to build because it flattens the generation curve. The feature works worst on a setup that is actively encouraged.

The rule this suggests: balancing must never throttle charging from a battery's own DC-coupled PV. The energy has nowhere else to go, so the cost of correcting the imbalance is total loss of that generation, while the imbalance itself usually costs nothing. Grid charging is the opposite — fully fungible, throttle freely. Today can_store_pv (execute.py:1345) asks whether the other inverters could absorb the total PV; it never asks whether this inverter's PV is DC-coupled and would simply vanish.

The broader version, which is really a comment on F12: imbalance is treated as a continuous error to minimise, when it is closer to a constraint that binds only near the extremes. Spread in the middle of the range costs nothing and often reflects reality (east/west, differing shade, one array behind cloud). It starts to matter when it strands capacity — one battery full while another is empty and the full one's PV is still coming. F12 proposes giving imbalance a cost in the plan; this is the argument that the cost function should be roughly flat in the middle and steep at the edges, rather than proportional to spread.

Worth saying explicitly: #829 (F5), which is now merged, works entirely inside the existing equal-SoC objective. It stops the balancer overwriting a rate the plan deliberately holds at zero. It does not question whether the balancing should be happening, and nothing here changes that fix.

Neither of these needs action now — flagging them while they're fresh, since both bear on how the C-rate dispatch design lands.

[chalfontchubby]

Written by Claude Code on behalf of @chalfontchubby.

Correction to my previous comment — the claim that balancing clips DC-coupled PV is wrong, and @chalfontchubby was right to push back on it.

execute.py:1345 already guards exactly this:

can_store_pv.append(total_pv_power <= (total_charge_rates - charge_rates[id]))

The charge-balancing branch only fires when the remaining inverters' charge capacity can absorb the total fleet PV. So it will not zero an inverter's charge rate if that leaves the generation with nowhere to go. I said that check was missing; it is the first thing the branch tests. I had read can_store_pv as asking a narrower question than it does.

What actually happens on an AC-coupled fleet in the east/west case is what he described: the leading inverter's surplus goes DC→AC onto the house bus and the lagging inverter charges from it. That is cross-charging with round-trip conversion losses, not curtailment — a real cost, but an efficiency one, and roughly an order of magnitude smaller than losing the generation outright.

So the east/west example still stands as an argument that equal SoC is the wrong objective — spending conversion losses to suppress a divergence that would self-resolve by evening is work for no benefit, and the divergence is correct behaviour rather than a fault. But it is not the "PV thrown away" case I described, and the numbers I quoted (~5.0 and ~7.9 kWh instead of 10 and 10) were modelling curtailment that would not occur. Please disregard those.

The one case where the loss could be total rather than conversion is a genuinely DC-coupled inverter whose surplus cannot reach the other battery at all. I have not established that Predbat can distinguish that topology, or that can_store_pv's fleet-level view would catch it — worth checking before anyone treats it as a real gap rather than a hypothetical one.

Apologies for the noise. The ladder observation in the same comment is unaffected.

[chalfontchubby]

Written by Claude Code on behalf of @chalfontchubby.

Framing: three possible architectures, and why most of the twelve findings are the same finding

Thinking out loud rather than proposing work — collecting this here so it is available when the design doc gets revisited.

What Predbat is today

execute.py:986-1000 sums the fleet into one virtual battery: soc_max, soc_kw, reserve, every rate, pv_power, load_power. The planner then optimises that single aggregate against one house-and-grid cost regime.

The code already knows this is a limitation — execute.py:980-982, on feed-in-first support:

Unlike the first-inverter-only settings above this is a fleet-wide capability: the prediction models one combined battery, so a single inverter that just disables charging during Freeze Export means the fleet as a whole cannot recapture PV.

Everything per-inverter — differing capacities, C-rates, DC-coupled PV, efficiency curves — is invisible to the component actually making decisions, and has to be recovered downstream by the executor's target split and the balancer. That is why F1, F4, F5, F11 and F12 keep reading like the same finding in different clothes. They are all "a decision was made on an aggregate, and something afterwards has to reconstruct what it meant per inverter". The aggregate is upstream of all of them.

Three architectures

1. One Predbat, aggregate battery (today). Tractable, and correct whenever the fleet genuinely behaves like one battery. Fails exactly where the members differ.

2. Two Predbats, which some users with multiple systems already run. Each inverter gets a real optimiser, so per-inverter constraints are respected. But they are blind to each other while seeing the same house load and grid prices, so they will tend to make the same decision at the same moment — both charging the cheap hour, both exporting the peak — with no coordination on genuinely shared constraints (grid connection limit, who covers the house). It trades "one model that cannot see inverters" for "two models that cannot see each other".

3. Inverters considered separately against a shared house/grid regime. One optimisation, one set of prices and one load, but per-inverter decision variables and constraints. This is the shape the problem actually has — multi-asset dispatch against a common price signal.

The tractability objection, honestly

(3) is the right shape and it is not obviously the right move. Predbat's optimiser searches over charge/export windows for one battery; making the decision variable per-inverter multiplies that search. The plan search already dominates runtime (measured on the debug cases: ~60% inside the C++ kernel, ~40% Python).

The C-rate dispatch design proposed above is essentially a way of avoiding that: derive the allocation analytically from a fleet-level decision instead of searching over allocations. That is a sound trade and probably the right near-term move — it keeps the planner as-is and addresses most of the findings. But it is a trade, and worth naming as one: a water-fill rule gives one allocation per fleet-level decision, so it can never pick "A off, B at full" when that is the better operating point (see the ladder note above — uniform fractions and on/off combinations reach almost disjoint power sets, and inverters are inefficient at low load).

So the honest framing is: a dispatch layer that is told fleet power and computes allocation fixes most of what is on this list without touching the planner. Making the planner itself multi-asset is a different and much larger question, and multi-inverter users are a minority of the user base. Not a call to make casually, and not one that has to be made now — but the findings above will keep accumulating as long as the planner optimises an aggregate, because that is where they come from.

Correction carried forward

Per my previous comment: the balancer does not curtail PV — can_store_pv (execute.py:1345) prevents that. The east/west case costs round-trip DC→AC→DC conversion losses rather than lost generation. Real waste, an order of magnitude smaller than I first claimed, and it does not change the argument that suppressing a self-resolving divergence is work for no benefit.

[chalfontchubby]

Written by Claude Code on behalf of @chalfontchubby.

Fleet-level plans can be undeliverable — which qualifies my "dispatch layer fixes most of it" comment above

Continuing to think out loud. This one changes my previous conclusion, so flagging it rather than leaving that standing.

The aggregate model overstates deliverable power

execute.py:986-1000 sums the fleet into one battery: capacity added, rates added. The simulator then applies the summed rate as if it were available for the whole charge. It is not, whenever members differ in energy-to-power ratio.

@gcoan's fleet from the top of this issue — 9.5 kWh and 5.2 kWh, both at 2.6 kW:

Aggregate model sees	14.7 kWh at 5.2 kW → 2.83 h to fill
5.2 kWh unit at 2.6 kW	full after 2.00 h, then stops drawing
Fleet rate for the remainder	2.6 kW, not 5.2 kW
Actual time to fleet-full	3.65 h

A 29% error, in the optimistic direction. The planner can cost a 3-hour cheap window as sufficient when it is not, and the shortfall lands as unplanned import at whatever rate follows.

There is a charge power curve in the simulator, but it is applied to the aggregate SoC and aggregate rate — it models one large battery tapering near full, not two batteries where the small one saturates while the large one is still at 55%.

This is upstream of every finding on the list so far. F1/F4/F5/F11 are executor problems: the plan was sound, the split or the balancer mishandled it. This one is different — the plan was never achievable and was costed as if it were. No dispatch layer can rescue it, because the energy genuinely cannot move that fast. It would faithfully execute an impossible instruction, and the symptom is "Predbat's plan didn't happen", which is the hardest class of report to diagnose.

So my earlier claim — that a dispatch layer told fleet power fixes most of this without touching the planner — only holds where fleet power is deliverable. Where it is not, the dispatch layer is downstream of the mistake.

PV is aggregated too

fetch_pv_forecast produces one summed pv_forecast_minute series with no per-array attribution. So the simulator cannot know which battery a given kW can actually reach. In @chalfontchubby's east/west example, 5 kW at 09:00 looks identical whether it is all on the east array — chargeable only into the east battery without a round trip — or split evenly. Which battery has space for which array's generation is not a representable concept today.

On the O(n!) worry — it is not factorial, but it is exponential

Searching allocations per export window, with the current 4-rung ladder:

Inverters	k^n combinations	with on/off subsets (2^n × k)
1	4	8
2	16	16
3	64	32
4	256	64

Factorial would need inverter order to matter; it does not, since dispatch is simultaneous. But O(k^n) per window, multiplied by window count and the existing pass structure, is bad enough — the plan search already dominates runtime (~60% kernel, ~40% Python on the debug cases). n=2 is tolerable, n=4 is not.

The way out: solve the allocation, don't search it

The constraints listed above — per-inverter power limits against the import/export window, which battery has space for which array's PV, clipping avoidance — are feasibility constraints, not things a search needs to explore. Given a fleet-level decision plus per-inverter SoC and per-array PV, the allocation satisfying them is largely determined: a small assignment/water-fill problem with a greedy or closed-form answer in O(n log n), not O(k^n).

That suggests:

• Planner stays fleet-level. Same search space as today. No exponential growth.
• Simulator becomes per-inverter. Track n SoCs rather than 1, route per-array PV, compute the allocation each timestep under the real constraints.
• Plans are then scored against deliverable fleet power. The undeliverable 3-hour window above scores as insufficient and the search rejects it on its own, without ever searching allocations.

This is P_balance used as a simulation constraint rather than a dispatch rule.

The cost is honest and not small: per-inverter state in the kernel's hot inner loop, per-array PV series through the ABI, and it must be mirrored in the Python engine (prediction.py) to keep kernel_parity meaningful. Effectively a rewrite of the simulator's inner loop. But it scales linearly in n rather than exponentially, and it is the only version of this that makes the aggregate honest rather than optimistic.

Worth weighing against how many users have mixed fleets, and whether the simpler dispatch layer plus a documented "fleets with very different E/P ratios may under-deliver" is the better trade for now.

[chalfontchubby]

Written by Claude Code on behalf of @chalfontchubby.

Correction: "solve the allocation in O(n log n)" was too glib

@chalfontchubby pushed on this and he is right. Retracting the load-bearing claim of my previous comment.

What O(n log n) actually covers. Water-fill solves one narrow shape: a single scalar to allocate (fleet charge power) across n units with per-unit caps. Sort by headroom, fill greedily. That much is genuinely solved.

That is not the shape of the real problem. With more than one array and a house load servable from either or both, each timestep is a small flow problem — sources (array 1, array 2, grid), sinks (battery 1, battery 2, house, export), edges that exist or not depending on topology, and per-edge conversion losses. DC-coupled generation reaches only its own battery; anything else pays a round trip.

Serving the house from array 1 rather than array 2 changes what remains to charge each battery, which changes each battery's headroom, which changes the power achievable next step. So it is min-cost flow on a small graph — still polynomial, still a solve rather than a search, but not n log n and not water-fill.

The part that genuinely does need search

Two things were being conflated, and separating them matters:

• Within a timestep — given prices, load and states, the best flow has a definite answer. A solve. This can live in the simulator and stay out of the planner.
• Across timesteps — whether to hold charge in battery 1 now so it has headroom for the east array at 09:00, rather than discharging it to serve the house. That couples timesteps and is a decision about the future, not a feasibility question about the present. That needs search.

This breaks the clean split I proposed. I said the planner stays fleet-level and only the simulator becomes per-inverter. But reserving headroom in a specific battery for a specific array is a planning decision a fleet-level plan cannot express — the fleet has ample headroom while the one battery that array can reach does not.

So the exponential does not disappear; it moves to where it actually lives. Only some per-inverter decisions can be delegated to a solve:

• E/P deliverability (the 2.83 h vs 3.65 h problem above) — yes, a per-inverter simulator fixes this without any new search.
• Per-array headroom reservation — no. It needs to be a planner decision, and the fleet-level plan has no vocabulary for it.

Still thinking out loud rather than proposing anything. Recording the correction so the earlier comment is not taken at face value when this gets pulled together into something concrete.

[gcoan]

@chalfontchubby I'm sorry I have been remiss in contributing to the thought processes you have been going through. I have read through them, and don't pretend I follow every word of the discussion, but I get a number of the points you are making,

I thought it would be worthwhile to chip in some more thoughts of my own, and practical experiences of where multi-inverter setup isn't working for me. Maybe these are the 'most important things to fix' list.

1. An easy one, I thought it was fixed, but I'm still seeing it (in 8.55.0, so apologies if this is fixed in a later release I haven't gone to).
   In forced export I am seeing the fleet target expressed as the export-to target for all inverters, not the actual per inverter. targets:

2. Another Predbat limitation not captured in the 12 above, so maybe this is number 13, is that switch.predbat_inverter_hybrid is a single global switch. There is no capability to define it individually for multiple inverters, so in mixed estates it's always going to be wrong and is always going to thus have wrong conversion loss calculations in the plan.
   Maybe a minor point, but thought it needed adding. TBH this really shouldn't be a switch, it should be an apps.yaml config item as you define it as part of inverter setup and don't need/want to change it during ongoing operation.

3. Predbat producing undeliverable plans, my original issue raised in Predbat takes account of dissimilar battery capacities in the plan #830 and as mused above in Multi-inverter rework: tracking issue #4856 (comment) continues to be a problem.

As the weather turns and I need to use the batteries more this will become even more of an issue.

You've given some examples of this above, and the way I've had to tackle this before is with automations to set input_number.predbat_set_reserve_min at different times of the day. This is to prevent batteries discharging too much and the inverter not being able to recharge them in a cheap rate (in my case Octopus Cosy) period.

4. Another concept not modelled is "inverter priority order". In a multi-inverter setup the inverters do not evenly share the house load. One will almost certainly lead and so when planning target SoC's across the inverters, to get maximum discharge capability I'd suggest that the leading inverter should be prioritised in terms of charge rate/target SoC.

Expanding on this further. I now have three inverters, two hybrids (inverter 0 and 1) and an AC coupled (inverter 2). When I only had the hybrids, inverter 0 would always take the lead in supplying house load, and since this had the bigger battery I had (point 3) to set the reserve minimum to stop it discharging too far at certain times of the day.

Now I have the AC coupled as well, this now takes the lead in discharging first. It unfortunately has the smallest battery, and as it is AC coupled it will only charge off PV when there is excess PV being exported by the hybrids.

So for example, in the morning inverter 2 will be empty as it's taken the lead in discharging for house load, and all PV generation goes to inverter 0 and 1. I have to tackle this today by constraining the inverter battery charge rates so more DC gets put onto the house AC so inverter 2 has a chance to start charging.

Why Important? Well for an Axle or Octopus power down event I'd like all three inverter/batteries to be charged to maximise my discharge capability, and of course for high house load (heat pump, electric shower) I"d also like to be running that off batteries rather than partial grid import caused by one inverter battery being empty.

I realise that by constraining the hybrid inverter charge rate I am incurring the additional DC->AC->DC losses, but that is a price I have to pay with AC coupled inverters.
If Predbat were able to dynamically control the individual inverter charge rates then this would then this would make a huge difference.

The question was asked about whether Predbat should be trying to balance to same SoC or same kWh, I'd say kWh, but I'd like to be able to set preferences to weight the kWh targets to take account of inverter priority order.

[chalfontchubby]

@mgazza

[chalfontchubby]

"The question was asked about whether Predbat should be trying to balance to same SoC or same kWh, I'd say kWh, but I'd like to be able to set preferences to weight the kWh targets to take account of inverter priority order."

My thoughts have evolved a bit - and subject to ideally balancing passively by choosing which to charge/discharge rather than moving energy as much as possible - I think an approach is to balance for the next event - so if you are going to be grid charging at cheap rate - leave balanced space in the batteries subject to their charging rates. If you are going to be exporting or otherwise driving a high load - balance in kWh in proportion to their inverter power - so they can all export full whack for longest.

Note that as ever giving more individual control does fight against getting a reasonable algorithm.