Unpredictable behaviour with low power mode

[BuhJuhWuh]

Describe the bug
Not quite sure if this is a bug, a feature request, or expected behaviour which I'm not understanding properly. This morning (of all mornings with its horrific agile prices!) woke to a half-charged battery, as Predbat had set it to charge at only 760W instead of the usual 3.3kW.

Expected behaviour
Charge to 100% before some time slots deemed expensive (how is this set...?)

Predbat version
Different behaviour under 8.10.1 (slow):

And 8.9.3 (which looked much more normal after I changed to this):

After a bit of discussion on the GE forum, @gcoan pointed out the low power mode. Sure enough, this was switched on; switching it off gets me back to the higher rate charge I was expecting, even under V8.10.1.

However, it's not a consistent picture, with tomorrow's plan (8.10.1, low power mode ON) still proposing fast charging, even though there's no need for it to be at 100% before 1600. (As opposed to today when there was every reason to be full by 0700!):

So: I really like the idea of the low power charge mode, but I don't understand how it chooses it's target time to be at 100%, and therefore the rate it charges at - this seems very inconsistent at the moment, leading to nasty surprises like this morning. I wondered if whatever algorithm is used to select the target full time was perhaps thrown by today's exceptional/weird Agile price profile...?

Would there be any way to add some more control to this? E.g. set a min charging rate, or manually set a target full time?

Anyway, love Predbat more generally - thanks for all the hard work - but it does spring a surprise every now and then!

Environment details

• GE 5kE Hybrid Gen 3, 9.5kWh battery
• Standard HAOS installer

Log file
Can you capture a log file from the time of the issue, debug mode is not normally required.
logs-3.txt

[gcoan]

A guess as to why Predbat is 'fast charging' more tonight is that the rates tonight are most favourable for charging from the 3:30 through to 5:30 slots, to predbat plans the charge rate sufficient to fully charge the battery during this time period.

Whereas last night the rates were much more consistent over a much longer period so Predbat would plan a slower lower charge over that period

My battery was at 80% by 7am which is the end of the 'cheaper run', then 96% by 8am. So it would have been preferable for me if the battery hadn't had been charging so much in the 7-8am slot, but most of the charging was done at the lower rate.

@BuhJuhWuh looking at your plan, the battery was at 75% by 8am, so a bit lower than mine but not dissimilar

[BuhJuhWuh]

Yes, but why not 100% by 7am? Could still have charged at a much lower rate than normal overnight (say 2kW or something) and finished before the higher rates kicked in.

Here's one further guess: I've marked on the trajectory if I hadn't intervened, which would have hit 100% at 1300, which was my first 99.99p slot today. So I wonder if perhaps the target-time-slot-picking algorithm was thrown by that, and selected that slot, ignoring all the earlier still-horrific-but-not-quite-as-horrific slots though the morning.

[johnwb87]

I also really like using lower power mode and also see some interesting choices being made.
My assumption is that predbat plans as usual and then looks for the low power opportunities that only have a limited impact on the cost outcome.
So I do wonder what other metrics are taken into account that we could tune to get the behaviour we expect.

[springfall2008]

If you can capture a YAML Debug file for a 'bad' plan I can review it.

It would also help if you post the battery chart and the Predbat HTML plan as the one you are using isn't very clear

[BuhJuhWuh]

Okay, will keep an eye out, though I guess it may need to wait until another suitably unusual Agile day. Do I need to leave debug mode on permanently, or is it enough to switch it on when I spot a suitable plan instance? (I.e. do you get enough retrospective data?)

Yes, apologies, all of that happened in the midst of school run and getting to work, so wasn't really in a position at the time to grab anything beyond those screenshots.

To be honest, I have only noticed a couple of instances of it doing anything other than just charging at full rate - so then instances like yesterday where it throttled right back stick out all the more. In other words, I don't recall ever seeing a plan that charged at say half rate or 2/3 rate.

[BuhJuhWuh]

Actually, thinking back to the evening before yesterday, I certainly would have checked the plan ahead of yesterday's prices, and didn't notice anything untoward - pretty sure that at that point it was predicting its usual full rate charge in the cheap slots overnight. It was only when I had a quick peek in the morning and saw the long block of low rate charging that got me investigating. I.e. at some point overnight the plan revaluation hit a threshold somewhere which made it switch tracks.

How far ahead does the low power mode calculation take account of? Is it the full 24 hours (or whatever one has set)? Or a shorter period?

[gcoan]

Okay, will keep an eye out, though I guess it may need to wait until another suitably unusual Agile day

just as a suggestion you could manually set up a bunch of import rate overrides to re-create a poor set of agile rates for a day. Bit laborious but could enable the issue to be seen earlier ?

[gcoan]

@springfall2008 here’s an example of Predbat charging I believe for too long with low power mode turned on:

Predbat 8.10.2.

18_25.txt

Predbat plans a low power charge from 01:30 to 10:30. I can see it is a low power charge due to the slow rate that SoC is increasing by in each slot.
I’m quite happy with there being a low slow charge overnight from 01:30 to say 06:30 when the rates are 20/21p, but then in the 6:30 slot onwards the rates start increasing substantially, and Predbat is still charging with rates at 30p at 8:00 onwards.

Turning low rate charging off show that a normal fast rate is complete by 05:00, but strangely Predbat continues to charge in this plan with SoC at 100% and rates increasing:

18_35.txt

Predbat should have started releasing the SoC at 07:00 when the rates were highest, not at 10:30 after the morning peak

[gcoan]

Putting in a manual force demand at 07:30 with low power charge mode turned back on gives me the plan I’d expect, charging overnight on the cheaper rates that reaches 100% at 07:30, then demand mode for that and the next few slots when morning peak rates at 30p are occurring, then a series of charges and freeze charges ahead of the evening peak rates (although Predbat doesn’t charge back to 100%, I’ll probably put a force charge in at 13:30 to give more contingency against running out at 19:00)

Uploading 19_15.txt…
19_15.txt