Low threshold setting very high when near agile peak rates

[Philhews]

Once I've got within 4 hours of the agile peak rates, the low threshold has jumped up to equal those high rates Now I have almost all of my periods defined as possible charge periods, I don't think it will cause any problems but seems fairly odd. am on v7.13.8 if that matters

[gcoan]

I'm seeing the same behaviour, also 7.13.8

I'm wonder if this is why predbat is favouring discharging at 28p over using it to supply home demand and avoiding grid import at ~42p?

The plan at 14:31

And then plan at 15:04

And at 15:14

Quite a bit of change in the plan but in all versions there's import in peak rate and peak rate discharge as well when it would be cheaper to just supply the house from the battery

[Philhews]

It seems it's something to do with the future rates too because when I change my future rate metric down from 6 to 0 it gets better maybe? Certainly lower but only gives a handful of potential charge slots

[slopemad]

I think a recent change in Predbat involves taking into account all the slots in the next 4 hours which might cause this effect. What I did notice is that Predbat instructed my inverter to go into 'freeze charging' at 16:20 (and back to Idle at 16:30), and thus stopped running off battery and instead off mains during super peak rate for 10 minutes :-(

I also note my Low Threshold shot up at about 12:35, momentarily dropping much lower at about 13:40, 16:00 and 1630(ish), as can be seen in the below chart.

Currently running v7.13.8 since about 11am.

[gcoan]

I don't have future rate metric set to anything, just relying on the nord data and rollover of current rates.

Because the plan remained to keep charging in the peak period I had to turn predbat into read only mode and manually change the inverter settings to start supporting the house from the battery instead of the grid. It's still in read only mode but it looks like this low rate is causing predbat to continue to want to charge the battery despite the rates continuing to fall through the evening. The better plan would be to allow running off grid import until 22:30-23:30, and charge in this period to give sufficient soc to get over the following more expensive hour of import

[gcoan]

My plan has a similar pattern of the low rate threshold jumping up as we approach the peak period but having a couple of jumps up and down beforehand

On 24 Nov 2023, at 17:42, slopemad @.***> wrote:

 I think a recent change in Predbat involves taking into account all the slots in the next 4 hours which might cause this effect. What I did notice is that Predbat instructed my inverter to go into 'freeze charging' at 16:20 (and back to Idle at 16:30), and thus stopped running off battery and instead off mains during super peak rate for 10 minutes :-(

I also note my Low Threshold shot up at about 12:35, momentarily dropping much lower at about 13:40, 16:00 and 1630(ish), as can be seen in the below chart.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[slopemad]

What is your best_soc_keep set to?

[slopemad]

OK, so looking at your plan, while it says 'Charge', it isn't actually charging, the SOC is higher than the limit and so is continuing to discharge the battery down to 14% (is that where your best_soc_keep or even best_soc_min is set to?). At 19:30, it then wants to charge up at 24p so it can discharge when the rate is 27p. Similar at 20:30. I seem to recall you changed your settings to not take into account the cost of using up battery cycles, hence charge at 27 to discharge at 24.

I have the battery cycle cost set to 3p, there's not much value (to me) in charging at 24p to discharge when rates are 27p.

I think the low threshold will drop after 7pm when the peak is no longer in that 4 hour window, I guess that particular concept needs some refinement.

[springfall2008]

I'd hazard a guess that metric_keep is set to 14% or min_soc is set to this level and hence why it's holding at the battery at that level?

[slopemad]

This plan just doesn't seem right? It's now planning to do it's bulk charge now, at 22p, rather than potentially just holding the charge level now and charging at 18p or 19p later in the night. And maintaining that charge until the morning and exporting excess solar (high solar forecast for tomorrow). It just feels like the logic has messed up somehow?

[gcoan]

OK, so looking at your plan, while it says 'Charge', it isn't actually charging, the SOC is higher than the limit and so is continuing to discharge the battery down to 14% (is that where your best_soc_keep or even best_soc_min is set to?).

Yes agree, some of the labelling of "charge" slots can take some interpretation. I've seen charge slots actually being "hold charging"

My best soc keep is set to 0.3kW which on a 5.2 battery is 5.7% - only just above the 4% reserve figure. Best soc min and max is 0, so those shouldn't be influencing the battery retention.

At 19:30, it then wants to charge up at 24p so it can discharge when the rate is 27p. Similar at 20:30. I seem to recall you changed your settings to not take into account the cost of using up battery cycles, hence charge at 27 to discharge at 24.

I have the battery cycle cost set to 3p, there's not much value (to me) in charging at 24p to discharge when rates are 27p.

Agree. I've tended to manage that with the inverter charge and discharge losses (currently 4 & 4%) so it's marginal benefit at best to charge at 19:30 at 24p, bringing the soc up from 14% if the predbat plan is to then discharge that at 27p from 20:00. However the plan at 20:0 is also labelled as "charge" which didn't make sense, but looking at the soc it's shown as dropping from 38% so maybe it's mislabelled and it's discharging not charging ??

Maybe the 20:30 charge is calculated as cost effective for the same reasons; 24.26p gets rounded to 24p and the 21:00 slot is 25.74p rounded to 26p which is just on the limit of my inverter loss difference so it works out to be cost effective even though the unrounded figures wouldn't be!

I think the low threshold will drop after 7pm when the peak is no longer in that 4 hour window, I guess that particular concept needs some refinement.

Low rate threshold did indeed drop but it's still above all the immediate next slots so I'm guess why it keeps charging to 100% even though the subsequent slots are dropping in rate and grid import would be cheaper

[gcoan]

My best soc keep is 0.3kW which is 5.7% of the 5.2 battery, only just above 4% reserve

Best soc min is 0

On 24 Nov 2023, at 20:10, Trefor Southwell @.***> wrote:

 I'd hazard a guess that metric_keep is set to 14% or min_soc is set to this level and hence why it's holding at the battery at that level?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[slopemad]

So, there was the plan I posted 23 minutes ago, and it's now changed to something more sensible. But I've noticed the low and high thresholds are up and down like an... like an uppy downy thing. I can't see anything in the appdaemon logs which may suggest it is struggling to get rates from the Octopus Energy entities and everything looks consistent in there...

[gcoan]

There must be some sort of "hang-over" in setting the low rate threshold after the peak period.

On 7.13.8:

Upgraded to 7.13.9, nothing else changed:

Sometimes the import rates are shown green, sometimes pale yellow and I've seen the same rate change colour when the plan is recalculated?

I then on 7.13.9 increased the charge & discharge losses from 4 to 5% and the new plan looks better so I'll be turning predbat back off read only after 10pm

Some of the charging labels look to be incorrect if I look at the soc direction and soc limit compared to previous slot. Eg 01:00am

[slopemad]

Continuing to see fluctuating low threshold and high threshold rates (meaning that Predbat keeps choosing expensive charging slots).

[gcoan]

There was fluctuations in my high rate threshold overnight but the low rate has been pretty constant, just going up a touch at about 6am.

If predbat sticks to this plan and keeps the battery charged to 100% up to 4pm peak then I'll be happy with this

7.13.9

[gcoan]

The "looking ahead 4 hours" recently added is causing side effects.

The plan earlier which looked ok, retaining 100% soc to the start of the peak period

At 12:15 the plan was showing charging in the first 4pm peak rate slot

And at 13:25 the charging now extends to 17:30 with unnecessary peak rate discharges. I added the low rate threshold to the dashboard and can see that that's what's throwing the plan off

This may also be the cause of #309 and #357

I'll have to turn predbat off and manually back to eco mode at 4pm

[gcoan]

Hmm. Maybe not as simple as the 4 hours lookahead causing the peak period charging.

4:10 plan on 7.13.9

Updated to 7.13.10 and the low rate threshold has dropped but still retaining 100% soc through the peak 🤷‍♂️

Looks like the low rate threshold dropping was temporary because it's just gone back up again

[gcoan]

Excited to see @springfall2008 had released 7.13.11 with "changes to metric keep to avoid near term force charges"

But half good, half not good.

At the moment I've left predbat in read only through the peak and was going to leave it off until the rates drop later this evening.

Plan on 7.13.10 :

Installed 7.13.11 and good news the peak rate charging and charging this evening when it's not beneficial has disappeared

Bad news is predbat doesn't try to do any charging at all (other than a couple of slots), leaves the battery empty and running off grid tomorrow and into tomorrow's peak. I know the rates are not great overnight but charging from say 3-5am would be beneficial, and certainly need to charge before tomorrow evenings peak

[springfall2008]

Did you try setting best soc keep to 0.3 as per the new proposal?

[gcoan]

Did you try setting best soc keep to 0.3 as per the new proposal?

I already had it set to 0.3. Sorry !

Here's the logfile if it gives any help appdaemon (17).log

[springfall2008]

Can you try pushing keep up a bit and see what changes?

From what I can tell it’s on a cusp of being not worth using the battery

[gcoan]

Can you try pushing keep up a bit and see what changes?

From what I can tell it’s on a cusp of being not worth using the battery

Will do. I could see that the rates were pretty flat and with 5% charge loss % 5% discharge loss using the battery would be heading towards marginal, but still thought some overnight charging would be worthwhile

[Philhews]

What's the reason to recommend 0.3 for the keep metric?

[springfall2008]

It’s just above the reserve so you can use the whole battery but steering away from not using it

[gcoan]

best_soc_keep = 0.4 the import rates all turned to green from yellow and red (assume this means something?) bit of freeze discharging even though soc is 4%

best_soc_keep = 0.5

best_soc_keep = 0.6 bit more charging but to 4% limit?? I noticed the import colours all go amber/red and then turn green as the plan is recalculated?

[gcoan]

best_soc_keep = 1.0, still the same

best_soc_keep = 1.0, but dropped charge & discharge loss from 5% to 4%. One more charging slot has appeared but again only to 4% limit

[springfall2008]

Can you try this one? https://github.com/springfall2008/batpred/releases/tag/v7.13.13

[gcoan]

I had set battery losses back to 0.05 and best soc keep to 0.3 and turned predbat back on as I was happy with the two charges planned for this evening

Here's the latest plan on 7.13.11

Then installed 7.13.12 and positive improvement, charging again overnight

Unfortunately at the moment no recharge before the evening peak tomorrow, but this might emerge nearer the time

[gcoan]

7.13.13

Looks fairly similar to.12, charging in the slightly cheaper slots this evening, and overnight tonight and tomorrow night. Unfortunately at present no planned pre peak charge tomorrow afternoon

[springfall2008]

The pre-peak charge will come if needed based on the always include the next N hours in the calculation part

[slopemad]

I've put 7.3.13 on and here's my plan. The surprise, for me, is that it is doing it's "bulk charge" between 22:00 and 01:00 and holding at full charge overnight, and therefore charging in those 22, 23 and 24p slots, rather than maybe holding the charge in those more expensive slots (or maybe even discharging), and instead charging in that cheaper 04:00 to 07:00 slot. Still seeing threshold fluctuations also.

[springfall2008]

@slopemad I think this is as expected, you avoid charging/discharging/inverter losses when holding at 100% so it's saving maybe 15% which probably outweighs the small rate differences.

That said I'd made another release today (sorry for all the flux) which maybe worth trying: https://github.com/springfall2008/batpred/releases/tag/v7.13.14

It's really hard for me to test in all cases which is why you end up being beta-testers

[gcoan]

@slopemad mine doesn't start the charge to 100% until the rates drop at 4am. Quite different to yours

Those fluctuations in threshold are all before the dashed line so hard historical aren't they?

[gcoan]

Installed 7.13.14

For me.12 and.13 were better, they didn't charge in slightly higher slots at 2330 and 0030 for example that.14 is now continuing to charge in

[slopemad]

v 7.3.14 - I'm OK with the idea that it will hold it's charge all night in one big massive charge window as that'll likely be cheaper, but surely it should be picking the cheapest slots inside that window to actually do the increasing of battery. So if it's basically in charge mode from 21:30 until 07:30, and can do about 13% in each half hour slot (so five slots), then it could pick the 5 cheapest slots in that window to do the actual charge. (The logic for charging the car is perfect in this respect, it picks the cheapest slots to achieve the desired SOC by a certain time).

There was no fundamental difference in plan with calculate second pass on or off, or combine charge slots on or off.

[gcoan]

Installed 7.13.14

For me.12 and.13 were better, they didn't charge in slightly higher slots at 2330 and 0030 for example that.14 is now continuing to charge in

Now I look more closely I see the 2330 slot labelled as "charge" is actually (looking at the soc) not charging but holding the charge. 0030 is charging though when the rate is 24p

I still prefer.13 or 12 as the bulk of the overnight charging was planned 0300-0600 when the rates are 19/20p whereas.14 is charging the bulk at 2230-0100 when the rates are 22p

Best on.14 was 2645p

Just downgraded to.13 and best is 2615p so confirms my thoughts

[slopemad]

Also, Low/High thresholds are still fluctuating...

[slopemad]

OK, it turns out I'd managed to downgrade from 7.3.13 to 7.3.12 rather than up to 7.3.14. I've now actually upgraded to 7.3.14 - the plan looks a bit more sensible in terms of when it picks charge slots overnight. Will monitor to see if it sticks to this...

[Redding43]

Latest version running in mine. Lots of charge slots with little charge activity

[Redding43]

[gcoan]

I left .13 running last night as it was a cheaper plan than .14, but it was a bad night as there wasn't much in the way of cheap slots and it was very cold so my ASHP ran most of the night so loads of electricity used already. At least the house is warm.

Battery only got to 80% or so overnight and was 71% this morning. Function of the poor rates.

This morning's plan on .13

And as I took the screenshot it was 8:55 so predbat completed a run cycle and the red import slots changed to green - why is this that slots sometimes different colours but the plan is the same?

I then upgraded to.14 and this plan is slightly better as it's now charging in the 9:00 and 9:30 periods at 24/25p, but the charge is then held (and grid imported) through the slightly more expensive 12:00 28p slot and then soc is released from 14:30 when the rates are 26, 25p to end up with the battery completely flat by very early in the peak period.

Appreciate that with the rates being so flat and battery losses of 5+5% there's very little benefit of discharging and then recharging through the day today, but I really need the soc to be held for the peak period where the rates are 20p higher than the afternoon rates, and not have the soc released prematurely. I'll leave this running and see if the plan improves and the soc is retained for more of the peak.

Also, can "hold charging" (or is it freeze charging) be added to the plan? It's hard to read eg 11:00 through to 14:00 all say "charging" with an up arrow to 100%, but the soc column shows it's actually already on 100% so it'll be holding the charge. On first review these slots appear identical to 9:00 and 9:30 slots that actually both are charging to 100%

[Redding43]

This is what I have woken up to today, latest Predbat version

[gcoan]

The broad thrust of your plan looks reasonable @Redding43. Your battery isn't being charged during the day as there isn't any low rate slots, the battery will see you through to Monday AM when there are some cheaper charging slots to refill the battery.

But some of the detailed slot choices seem odd. Why release the charge at 11:30 when import is 25.8p but then hold the charge (and import) in the 12:00 slot when the price is 28p?

Your half hour slot consumptions are tiny so it's not going to make much £ difference but still ...

[gcoan]

I then upgraded to.14 ... but soc is released from 14:30 when the rates are 26, 25p to end up with the battery completely flat by very early in the peak period.

Appreciate that with the rates being so flat and battery losses of 5+5% there's very little benefit of discharging and then recharging through the day today, but I really need the soc to be held for the peak period where the rates are 20p higher than the afternoon rates, and not have the soc released prematurely. I'll leave this running and see if the plan improves and the soc is retained for more of the peak.

Update: 11:15 and the 100% soc is being retained now until 15:30 so now covers more of the peak import period than the plan at 9:00. So as the day advances it's looking better, though since predbat is planning for 36 hours ahead I'd have thought this would have been covered in the earlier plan?

Anyway, looking better

[Philhews]

The 4 hour forced inclusion is still making mine do stuff I don't want it to, it just set a hold charge on a 26p slot when the battery can be charged in the future at 19 (losses make it worth using the battery). Previously without the forced 4 hours and with the ability to select a number of charge windows I could control this and prevent the behaviour but now I get no choice.

[slopemad]

Looking at the plan on mine, it's holding the battery at 100% until 4pm now (If I was doing it manually, I'd probably stop at 15:30). And after the peak, it starts charging the battery back up again at some of the more expensive rates rather than the lower rates later in the night. As I suggested earlier, perhaps when Predbat has a prolonged 'hold charge' block like this, it could then use logic similar to the car charging logic which just selected the cheapest rates in that big block to do the actual charging.

At the moment though, it's very marginal whether being on Agile is worth it versus Cosy, and there's no sigh of improvement in the rates coming up. (And the Octopus Tracker rate is, for example, 21.4p today and that's without needing to factor in battery losses). So I'll probably shift to Cosy tomorrow for a while.

[gcoan]

@slopemad agree, you've got quite low load for each slot so it would look to be better to not charge until the cheaper rates overnight.

I had been wondering about whether I should change tariff off agile as well as rates are similar to the price cap and I currently only have a single 5.2 battery that is marginal to see me through the peak on a normal day, and definitely isn't enough now it's turned cold.

Looking on the Octopus Compare app though, Agile was £2 cheaper than Cosy for yesterday and £20 cheaper for the last week. Flux would have been slightly cheaper than Cosy (but only a tiny bit). Tracker would have been £3 cheaper than agile for yesterday, about the same for the last week and slightly more expensive for the last month.

I'll keep an eye on it but will stick with Agile

[gcoan]

14:23 now and the battery has been held at 100% all day which is fine and it now plans to start discharging at 16:30, which given that the battery won't last the whole peak and the 16:00 slot is cheaper to import than the 16:30, makes sense.

The soc will probably run out early anyway, but holding the soc at 18:00 when the following 18:30 slot is cheaper doesn't seem right. And charging at 19:30 and 21:00 to discharge at following periods when the rate is the same/slightly lower and certainly within the charge/discharge loss spread - looks like remnants of the 'look 4 hours ahead' in peak that is causing this behaviour??

[gcoan]

15:25 the plan up to and through the peak period is fine, but now more charging is planned for in comparatively expensive rates after the peak, eg 19:00 at 27.5p

I'll let predbat run through the peak (assuming this stays the same) and put it into read-only afterwards for the evening if it keeps wanting to charge.

I know there's lots of comments but this is an improvement over 7.13.10 yesterday where I had to stop predbat from charging through the peak period and manually change to Eco mode

[springfall2008]

I've just made a new release which is largely in place to reflect better on the plan what is going on. The HTML plan now has a cost column and the charge column has some new states (NoCharge and HoldCharge). There is also a plan debug enable toggle which will show the rates used for planning accounting for losses in brackets.

https://github.com/springfall2008/batpred/releases/tag/v7.13.15