HOLD CHARGE ---- Predbat stopping battery from discharging despite high unit rate

[mpartington]

Describe the bug Currently in the peak period of Octopus agile and the unit rate is high. Predbat has chosen to HoldChrg for the first hour of the period (16.00 to 17:00). This is probably because my predicted load is well below my PV generation, so it believes it is adequately covered. However this approach is ### unnecessarily risky:

1. If load is unexpectedly high and exceeds the solar, I will be charged at a high rate - in fact this would have happened if I hadn't forced to ECO, as we were cooking earlier than usual with high usage
2. If the PV generation is lower than predicted, I will be charged at a high rate

Additionally the battery is sat at 100% and will easily reach times where more effective rates are available to charge, so no need to hold.

EDIT... this will affect logic for both Hold charge and Charge Freeze. There also appears to be a case where the battery is at 100%, but the plan and status just says 'charge', so I think that would also need review.

Expected behavior Predbat to allow battery discharge at high rates, in case of unexpectedly high usage, loads or poorer solar generation There is really no risk in this approach, either:

1. The solar exceeds load, in which case the battery continues to charge (or in my case export excess solar), as per todays logic, or
2. Load exceeds solar generation (for whatever reason) and the battery covers the extra load. This is more cost effective than paying 28p/kWh

Predbat version

v7.16.10

Screenshots

Log file

Relevant part of the log will be 16:00 onwards (30-March). I used the override to force the battery to eco mode once I spotted the behaviour appdaemon.log

Second log file to include the third occurrence during 6pm slot appdaemon.log

[mpartington]

Not sure about that

Charge window will be: 2024-04-22 16:30:00+01:00 - 2024-04-22 17:00:00+01:00 - current soc 85 target 82 Inverter 0 Current charge limit is 100 % and new target is 82 %

So its actually like a 'no charge' unless the SOC would fall below 82%?

Looks like it would have done, I end the slot on 78% so would have had peak usage. I guess it would given the chance, allowed it down to 82%, but my automation is deliberately sensitive to any import in those slots. Is this something else that needs a tweak to stop happening at high unit prices?

Can confirm it also set the charge period and enabled charge:

[springfall2008]

It's really odd, the difference is 0.01 which exactly matches the weighting to 100% and 0% but the target here is something in the middle (82%).

Debug would be really helpful to track it down.

BTW: Charge freezes are rarer as they are weighted against....

I might give you another version to try on a branch

[springfall2008]

Can you try the predbat.py from here please? https://github.com/springfall2008/batpred/blob/weight/apps/predbat/predbat.py Keep debug enabled

[mpartington]

As discussed appdaemon.log

[gcoan]

Think I'm seeing the same issue

7pm, Predbat wanting to hold the Soc fully charged at 100% despite rates being 19.4p and dropping down to 14p overnight - which should be enough differential normally to use the battery instead of grid import.

Dropped the metric_min_discharge_improvement down from8 to 5 to 3 to 0.2 but still the same plan

Only by putting a couple of force idle's in did it start releasing the charge.

9pm and 10pm should have run off the battery but by 9:12pm the plan had changed to again fully charging the battery when import rates were 16.98p but yet 14, 13p overnight

I upgraded to the version on main and the plan improved, 9pm and 10pm now back to running off battery but 9:30pm still importing

Putting a force idle in for 9:30pm changes the plan to now run entirely off battery until midnight which seems more sensible

[mpartington]

Some more variable runs, do seem to be improving

appdaemon.log

[D3RON]

Hi, I've been asked to add a comment here from the Givenergy forums, as this morning I noticed hold charge behaviour that I thought was odd. I know there was an update last night relating to hold charge, and I have auto updates turned on.

I noticed it was holding charge, and the house was using the grid when there wasn't enough solar to cover the predicted house load. Usually in the more expensive slots predbat switches me to house load and the battery covers demand.

[gcoan]

Personally I am slightly unsure about the new release and the number of Freeze Charges I'm getting overnight. All of these are overnight so no solar, in reality are just freezing the SoC.

In general the plan looks OK with the SOC being released in higher rate import slots, and for slots that are around the day-time export rate (15p - losses), Predbat is holding the charge - i.e. its better to import from the grid and keep the SoC held, so will start grid exporting earlier in the day tomorrow, rather than using the SoC that then has to be replenished at the expense of losing out on export tomorrow.

And the slots being Freeze Charged are the lower price slots

BUT

Having said that, the very lowest priced slots are NOT chosen to be freeze charged, i.e. Predbat is in Idle/Eco mode, which doesn't make sense.

That was the plan at 16:21 with the three lowest priced slots letting the battery discharge when it shouldn't.

By 17:15 the plan had changed to only one of those 3 slots (the lowest price one) now letting the battery discharge:

And at 19:24 the plan has changed again to now none of these lowest price slots are letting the battery discharge:

So I think there is a bug in determining to let the lowest price slots discharge rather than freeze charge, but there's some forward time basis to this bug that's causing the plan to change over time.

EDIT: 21:04 the lowest price slot at 5:30am is once again showing as Eco not Freeze Charge

[mpartington]

Fixes.seem.to.have worked. Not had this happen for a long time