Predbat takes account of dissimilar battery capacities in the plan

[gcoan]

Is your feature request related to a problem? Please describe.
Predbat currently assumes that the batteries and inverters in multi-battery/inverter setups are identical and will charge and discharge at a consistent rate. In reality this is not always the case and is resulting in Predbat calculating plans that it then cannot deliver.

Describe the solution you'd like
Example of a 'can't deliver' plan:

I have a 9.5 and a 5.2 battery on two different inverters. Charge rate for both is 2.6kWh (in reality its actually more like 2.4kWh, but ignore that for now). The 5.2 (80% DoD so actually 4.2kWh usable capacity) will charge from empty to full therefore in 2 hours but the 9.5 will take about 3 and a half.

There is another zero rate power up event tomorrow and Predbat's plan is to charge from 4% to 100% in 3 hours (which as per above charging rates cannot be achieved):

Ideal solution would be that Predbat plans and manages both inverters separately and optimally whilst still avoiding cross charging.

A step back from that would be that Predbat recognises the different capacities and charge rates of different inverters and takes account of them in the plan.
For example, tomorrow, start the charging of the inverter with the 9.5 at 12:30 so its fully complete by 16:00, but for the 5.2, leave it holding soc at 4% and exporting PV until 13:00 or 13:30 which still gives enough time to fully charge the 5.2 from 13:30-15:30.

Describe alternatives you've considered

1. Do nothing.
   Results in (a) cross charging when Predbat realises it can't fully charge the batteries in time and starts reducing the target soc (see Cross charging during charging event #829), and (b) battery not being fully charged before the peak period.

2. Manually set force charge slots to ensure the larger battery is charged sufficiently.
   In this example I could force charge at 12:30 but doing this in Predbat will cause both batteries to be force charged, which is wasteful as the smaller battery can be fully charged at 0p.

3. Manually control the inverters to achieve what I want. set predbat to read only, initiate manual charge on just the 9.5 at say 12:30, then at 13:00 turn read only off to let Predbat take over the charging.
   Not really what I want to be doing.

Additional context
The power up zero rate event illustrates the issue very well but clearly it is a bigger issue than just these events. Any overnight charging risks not delivering the plan because the inverter/battery sizing isn't currently taken account of in the Predbat plan.

[springfall2008]

Did the later changes to account for unbalanced SOC help?

[gcoan]

The change for multi-inverter setups to set the target soc for each inverter based on the current soc has definitely helped, point 1 (predbat reduces the target soc when it can't achieve the desired soc) happens less.

But I still have the issue (especially visible in power up events) that the Predbat plan isn't achievable because Predbat doesn't take account of the battery capacities per inverter and assumes that it can charge at 2x individual inverter charge rate.

Tonight's agile rates are (for once) reasonable so I can't show the issue, but I'll find a more recent example of it happening

[gcoan]

OK @springfall2008 here's an example from today of where Predbat's plan isn't achievable because it isn't taking account of the battery capacities and charge rates correctly:

Battery is empty at the start of the charge period, 2 hours of charging, Predbat predicts it will get to 73% by the end of the 2 hour charging period.

Best case scenario is charging at 2.6kWh, in reality it's 2.5kWh at best and I have set battery_rate_max_scaling to 0.96 (2.6x0.96 = 2.5) to reflect this.

I have a 9.5 and 5.2 (4.2 usable) battery = 13.7kWh across two inverters.

The 5.2 (4.2 usable) will fully charge in 2 hours.

The 9.5 will charge 2.5 per hour (best case) = 5kWh total charge.

Total charge across the two batteries is therefore 5+4.2 = 9.2kWh

9.2/13.7 = 67% maximum possible SoC at the end of the charge period, lower than the Predbat prediction

[springfall2008]

I think this was implemented, please open a new ticket if not

[gcoan]

Hi Trefor, no this isn't implemented. What has been done is to change the target SoC across the multiple inverters so I don't get the problem of batteries not charging when one battery reaches the overall target SoC.

The problem remains that Predbat assumes that because I have 2 inverters each with a charge rate of 2.4kWh then both batteries can be charged equally.

An example from today where the plan isn't achievable:

Apart from the 9:30 slot, every slot the load is higher than the PV so any increase in SoC can only be from grid charging.

Both inverters have a charge rate of 2.4kWh

3 charge slots in the plan (2 of them forced by me), so therefore each inverter will add 3.6kW to its connected battery.

Battery G 9.5, currently 52% of 9.5kW so 4.94kWh
4.94 + 3.6 =8.54kWh or 89% SoC

Battery H 5.2 (4.2 usable), currently 63% of 5.2kW so 3.76kWh
adding 3.6 kW will fill this battery to 100%

So overall SoC will be (8.54+4.2)/(9.5+4.2) = 93% not the 100% that Predbat thinks it will be at by 14:00

I think what Predbat is doing is to do the planning on the overall SoC % and the combined charge rate rather than taking the individual capacities and % full into account. This is an issue in winter when I need all the battery to get through the peak and if I don't put force charges or freeze charges in Predbat can put the battery into Demand mode and fail to fill them during the day

As Predbat recalculates it of course realises that the batteries are not at target and the plan gets adjusted, but that can be too late and the cheapest slots have already gone.

Yesterday a slightly different example, G never got to 100%, it was set to freeze charges at 14:00 then Demand mode at 14:30, a freeze charge at 15:00 slot, then Demand from 15:30. Both batteries exhausted at around 18:30.
I think would have been better if the batteries had been on charge until 16:00 when the real peak rates hit

[gcoan]

@springfall2008 yesterday I swapped from Agile to Cosy and today I see another example of Predbat plans that are not achievable.

Cosy gives a 3 hour charging window in the afternoon. Charging at 2.4kWh I can add about 75% to the 9.5 battery on one inverter, and completely fill the 5.2 battery on the other inverter.

However as I have two inverters that can charge at 2.4kWh, Predbat assumes I will be able to totally fill the batteries in the 3 hour period:

As the rates spike considerably in the peak period immediately afterwards the better plan is to let the 9.5 discharge to 25% and the 5.2 to totally empty, then freeze charge and run off grid import until the start of the 1pm charging.

Ultimately may need separate plans for each inverter as commented in #1863. I know this will take longer but is a desired option for those of us with dissimilar battery sizes

[springfall2008]

It's quite hard to get much better without modelling two inverters, something that could be possible but would slow down the planning stage

[chalfontchubby]

Adding more detail to this from a recent investigation into #4440 (🤖-assisted) - confirms the mechanism behind the "can't deliver" plans described here, plus a concrete illustration and a first-draft proposal.

Confirmed mechanism: adjust_battery_target_multi (execute.py) computes one blended SoC/target for the whole fleet, then divides the shortfall across inverters by charge-rate share - not by each inverter's own headroom to the target:

target_kwh = self.soc_max * (soc / 100.0)          # % of the COMBINED capacity
add_kwh = target_kwh - self.soc_kw                  # combined shortfall vs the blended target
add_this = add_kwh * (inverter.battery_rate_max_charge / self.battery_rate_max_charge)   # this inverter's share, by charge-rate ratio

add_this depends only on the fleet-wide deficit and this inverter's rate share - never on how much headroom this specific inverter actually has. So an inverter already above the target can still get a positive allocation and be driven further, while an inverter that will hit its own ceiling before the fleet target is reached gets no special treatment either - hence plans that can't be delivered as calculated, exactly as described in this issue.

Illustration of how far this can go: two equal-capacity batteries at 50% and 100%, fleet average 75%, target 80% (genuinely above the average, so real need exists) - the shortfall still gets split by rate share regardless of individual headroom, so the already-full battery gets pushed toward an impossible ~105% target.

On "just balance them instead": not a free alternative - physically shifting charge between two batteries means discharging one into the other, paying battery/inverter losses twice rather than importing directly. Lossy, not just a redistribution.

First-draft proposal, not fully resolved: when the target is above the fleet average, compute the total kWh that needs to be added, then apportion it only across inverters that are actually below the target - either in proportion to each one's individual shortfall, or in proportion to max charge rate (so they all reach target in sync). Open complication: if two batteries both have physical headroom below 100% but only one is below the target, restricting the charge to just that one gives up the chance to use a good import rate on the other's spare capacity too - needs more thought before this is a concrete spec.

Full context/log evidence in #4440. Two related but separately-scoped bugs also split out from that investigation: #4445 (Hold Charge label bug) and #4446 (status text reflecting only one inverter).

[gcoan]

Thanks for the investigation and thinking about this.

Agree the 'just balance them' is not a viable solution. Not only because of the losses that will be incurred but also because the multi-inverters don't pick up load consistently and will become a never ending chasing game.

When I had two hybrid inverters G and H, G always picked up house load ahead of H. Not that H wouldn't discharge, it would, but G would always get the lions share of any discharge. G had the bigger battery and I would often in the morning find G's battery near empty and H almost full.
Since adding inverter I which is an AC coupled inverter, that inverter takes the lions share. At the moment I have a summer automation that drops the discharge rate on I overnight so that the batteries don't become too unbalanced.

First-draft proposal, not fully resolved: when the target is above the fleet average, compute the total kWh that needs to be added, then apportion it only across inverters that are actually below the target - either in proportion to each one's individual shortfall, or in proportion to max charge rate (so they all reach target in sync).

I see how this could work, but I'm not sure it solves the fundamental problem of plans being created that can't be delivered.

If I understand it correctly, Predbat calculates the plan based on global/fleet SoC, predicted load and PV. In the calculation it determines charging and discharging activity based on import and export rates, fleet SoC and aggregate charging and discharging rates.

This is what leads to plans that can't be delivered as the initial planning is all done in the aggregate, taking no account of individual inverter SoC levels, capacity and charging rates.

Its then a subsequent phase, the plan execution where predbat then allocates the charge targets to the inverters, and its this phase where the suggestion is to change the SoC target allocation.

Is that a correct understanding of the proposal?

The change could deliver a better plan execution, holding inverters from charging where they don't need to, but it either needs a feedback loop in plan execution to rework the plan if it has to be curtailed, or the original plan needs to take account of individual inverter headroom and charge rates to resolve the issue.

Taking your example, two equal-capacity batteries at 50% and 100%, fleet average 75%, target 80%

what needs to happen is for the plan to recognise that to achieve 80% overall with the current SoC levels, only one inverter has any headroom so the charge rate can only be from that single inverter (so it may need a longer charge period) and the target SoC for that single inverter will need to be 60%. The second inverter will need to be put into charge mode as well (with a 100% target) even though it is not actually going to charge, in order to stop it discharging (cross charging) into the first inverter.
[Or as a minimum put into freeze charge mode]