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]

Thanks @springfall2008 I'll try the .15 version.

Update on .14 through the peak period, predbat kept the battery held at 100% through to 16:30 as planned and then released it for discharging which its now doing. Interesting the "charging immediately after the peak period at unfavourable rates" I'd reported earlier has advanced backwards, almost as a rolling hour by hour window, so now at 17:40 its now not planning to start charging until 21:00.

[springfall2008]

This is probably because I change the code to ignore metric keep for the next 4 hours only, so it's part of the longer term plan but not right now

[gcoan]

Installed .15

Good things:

• addition of the £ value is useful, although I don't like the values its now telling me!
• inclusion of hold charge (does this now replace freeze charge?)
• from 22:00 the plan looks good. Its charging in the cheaper slots and discharging in the more expensive. Hold charging eg 00:30 where the rates are higher but not enough to make it worthwhile to discharge with battery losses
• pre-charging from 13:30 to 15:30 ahead of the 4pm peak tomorrow (although there still is unnecessary post-peak charging planned)

Minor issues:

• cost display over midnight. Costs are shown I believe as today's costs from now, but don't reset to zero at midnight. I know this is consistent with the way the rest of predbat works but is confusing as the cost to Tuesday 05:00 (last row of my plan) is all of Sunday's costs+all of Monday's+5 hours of Tuesday

• still something weird going on with colouring of the import rates. They've changed colour between red, yellow and green in subsequent runs of predbat. e.g. Mon 07:30-10:00 was Green in the plan at 17:55, then at 18:00 turned Yellow and at 18:05 turned back to green!

• the charging at 21:00 and 21:30 tonight isn't necessary. May be a hang-over of the rolling 'forward window after peak period' I identified above

I took a look at the debug version of the plan as well. Feel that you have to be careful how you interpret it. The "with cost" figures only of course apply if you are charging or discharging the battery. If the battery is doing nothing (either exhausted or being held) then just the normal import rate applies. So just need to read it carefully

[slopemad]

OK, so 7.3.14 vs 7.3.15

So I still can't help but think it could be choosing some slightly cheaper slots to actually fill the battery. Also, the first few slots are using multiple different states to hold the battery at 64% SOC ;-)

[DJBenson]

Agree on the point about the cost column - it would make more sense to most users if that reset at midnight and spanned the single day only, but appreciate why it works the way it does.

[gcoan]

The predbat cost just reset to zero as it clocked over midnight which is good. It's jus5 looking at the plan where it spans days the cost looks odd

Latest plan is looking pretty good, it's not perfect -the 4:30am slot at 19.4p isn't being used for charging as the battery is already full by then (and this is the cheapest slot of the night) but it's only a couple of pence difference from the slots that are being used

[springfall2008]

What do you think of this HTML where the charge slots are merged when longer and the cost is the actual cost rather than the total?

[DJBenson]

I like that the above includes something for the previously blank cells, gives confidence that it is doing something. Also like the merged cells. Not sure on the cost column - it now shows the cost of that particular slot? Might be good to have slot cost and accumulative cost to satisfy both camps.

[springfall2008]

Released here, I split the incremental cost out into a different column: https://github.com/springfall2008/batpred/releases/tag/v7.13.16

[slopemad]

7.3.15 (top) vs 7.3.16 (below)...

Interesting, it didn't combine the 21.30, 22.00 and the 22.30-07.30 charge sessions, or the 14.30-15.30 charge sessions. As mentioned before, it would be useful if when it does have adjacent charge sessions like this, that it would pick out the cheapest slots in that to actually top up the battery, rather than topping it up early on in the session and holding it there.

Also, as you can see between 15.30 and 16.30, it just has a 'FreezeChrg' session, but given that the second half hour is 8-9p more expensive than the first half hour, it would surely be better for it to top up the battery between 15.30-16.00 and just running off battery from 16.00 onwards?

[springfall2008]

I don't quite get that 32p slot at 16:00, I'd tend to agree it seems odd and I'm not even sure the freeze was required. I wonder if it goes away or sticks around. If it's staying can you capture the log?

[Philhews]

I like the merging of slots, makes things clearer, also like the cost per slot, slight issue is that on my phone the html is too wide to fit and I can't scroll it, anyone know how to resolve that? If the answer is something with card mod then I'm happy to go that route(font size change or something)

[slopemad]

It has very much stated.

I don't quite get that 32p slot at 16:00, I'd tend to agree it seems odd and I'm not even sure the freeze was required. I wonder if it goes away or sticks around. If it's staying can you capture the log?

It was still there at 2pm, and it still there now, although it's now split between Freeze Charge and Hold Charge... https://pastebin.com/DxRsJ8HH

[gcoan]

I have noticed that there's a tendency for predbat to plan things that "don't look right" but when it gets to them, the plan changes for the better

Eg this morning 6am, the 7:30 and 8:30 slots were both planned to hold the soc at 100% despite these being more expensive and there were cheaper slots later on where the battery could be recharged

But by 8:30 the plan had changed and the battery was discharging in this higher price slot

I've just upgraded to.15 and the plan looks pretty good apart from it should b3 discharging at 18:30 not holding the charge. But this may change when we actually get there

I like the combined blocks and the explicit down arrow for battery discharging. I'd still like to see the cost today resetting to zero at midnight in the forward plan.

@Philhews I find that if I rotate my phone to horizontal I can see the multiple columns of the predbat plan better

[Philhews]

The problem then is my phone thinks the dashboard has space for 2 columns and so the plan doesn't get any more space. Time to play with a vertical stack card maybe, last time that didn't display the plan card at all though.

[gcoan]

I’m using the grid layout of the layout-card HACS front end integration. I found this displays the charts best on my iPad & phone

On 27 Nov 2023, at 15:36, Philhews @.***> wrote:

 The problem then is my phone thinks the dashboard has space for 2 columns and so the plan doesn't get any more space. Time to play with a vertical stack card maybe, last time that didn't display the plan card at all though.

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

[JonathanLew1s]

I've set Low Rate Threshold to 0.8 and see a more acceptable low rate band.

[gcoan]

Couple more examples of the plan planned changing to something more sensible as it gets nearer to the execution time

At 14:40 shouldn't hold the charge at 18:30 or charge at 19:00

At 15:45 the 18:30 charge hold now isn't there and the battery is discharging, but the 19:00 charge still present

At 16:55, 18:30 is discharging and the charge at 19:00 has gone as well, giving a sensible plan

[gcoan]

@JonathanLew1s I tried my own experiments with changing rate low threshold and (at the moment) 0.8 does seem to be the sweet spot. My only concern is whether (as per above) predbat changes the plan when it gets to execute it and we end up with a worse plan as a result? Certainly in terms of predicted forward activity it looks much more sensible than the default 0 plan.

Rate low threshold on the default of 0, best is 2341

Changing rate low threshold to 0.9, best is slightly reduced to 2308

Reduced rate low threshold to 0.8, best is reduced further to 2252

Rate low threshold changed to 0.7, only one charging slot overnight now, and best increases to 2329

[Philhews]

With experiments around the low rate threshold (rather than leaving on auto) I wonder if the max charge windows parameter needs to come back in auto mode, that way you can control the number of slots rather than guessing what the rate spread is vs the average to pick a low threshold.

[Redding43]

Minor comment but the accumulative cost does not work with dark mode. Text colour means it can’t be read

[gcoan]

Hmm, just realised that rate low threshold set to 0.8 is NOT charging the battery before tomorrow's peak (at ouch, 53pkW rates)

And neither does setting rate low threshold to 0 either

So gonna have to hope that this is another one where predbat works out what the right thing really is nearer the time ...

[gcoan]

@JonathanLew1s rate low threshold=0.8 is starting to cause some strange updates to the plan. At 5pm it had identified to start charging tonight at 22:30pm which is the cheapest slot of the night

But now at 21:00, those early cheap slots are now "hold charge" and the charging is being done from 23:30 when the rates are higher!

Putting it back to rate low threshold=0 because although the long term plan doesn't always look right, predbat has (so far) sorted itself out and charged at the right times when it is near to the slot

[slopemad]

Predbat has, for me, come up with a decent overnight charging plan (I think I'd only change one thing, and have it charging the battery at 05.30 in one of the cheap rates, but I think that would save me approximately 1p in total, but also what I find is that when it's 'holding' a charge, the inverter is actually regularly cycling through charging and discharging small amounts, so actually it's probably better in this scenario to get to 100% and keep it there. I'm not sure Predbat is thinking like that though ;-)

As for the daytime tomorrow, virtually no charging at all which is OK because I'm expecting wall to wall sunshine and about 10kWh of solar. Only comment in this is that the battery will be fully charged overnight at 18-20p, and then exporting solar at 15p, which I don't think it necessarily optimal, but again it'll probably be OK. Solar power exported straight out at 15p rather than put into the battery and then discharged from the battery with the losses involved in that, probably irons it all out.

Yes, I still haven't pulled the trigger to switch to Cosy ;-)

[springfall2008]

Can someone else please test out changing 'plan_forecast_hours' to 24 in the HA GUI (expert mode required)? I think it maybe more sensible to only count the next 24 hours.

[JonathanLew1s]

@gcoan interesting, maybe it's the metric future rate offset import. I have this set higher than zero, intentionally trying to have the system take advantage of known current rates rather than gamble on estimated future rates.

Here are all my settings for comparison.

@slopemad I've also experienced this. The PV model in predbat is fairly pessimistic, which is correct most of the time, but leaves no wiggle room if predbat determines that it needs to maintain a high battery charge. I think we have a current edge condition where the energy market is resulting in fewer low rate slots and predbat is maximising those, occasionally PV is going to over generate and lead to some unexpected export. This is happening to me today, I switched on the washing machine.

[gcoan]

I left 7.13.16 running last night (with rate low threshold =0) and battery was fully charged overnight. Similar pattern today of the forward plan not looking optimal in terms of charging, but as the day progresses and i5 gets nearer to the charge slots, the plan corrects itself

9am the plan was to hold the battery until 2pm, then start releasing it, resulting in the battery being exhausted in the middle of the peak period

12:45, the hold charging retains the battery now to 17:00, meaning importing for the most expensive peak rate slot at 16:30 and the battery still having charge at the end of the peak period

And now at 14:25, predbat has now correctly identified 16:30 as being where the battery needs to be releasing charge to avoid peak peak import. I think 16:00 ought to be the same, releasing charge, trading this for retaining charge to support the 18:30 slot, but at least it's only 4p difference in rate

@JonathanLew1s I'll compare settings. I know my metric future rate offset is zero though. @springfall2008 Ill try changing plan forecast hours from 36 to 24. I was thinking of doing this anyway as my battery isn't enough to support a whole day anyway.

Tomorrow's peak forecast prices 56, 58 and 63p. Argh !

[gcoan]

14:37, plan was the same as 14:25, retaining the charge through 16:00 slot, only starting discharging at 16:30

By 14:49 though the plan had changed so 16:00 is now the start of discharging which is what I'd expect it to be. Not sure what "no charge" is as there's no PV at 17:00 and the soc is shown as dropping still

Changed Plan forecast hours from 36 to 24 and TBH looks much the same

19:00-20:30 is marked as charge but soc limit of 14 means it's holding flat whereas with a 36 hour plan it was shown as idle but with a 14% limit so effectively the same

Best soc keep is 0.3 so don't know why it's retained at 14%

[JonathanLew1s]

@gcoan I do not understand why you get 46p as a low rate cost. My low rate threshold is calculated at 20.2p

48 Hour. Future costs based on nordpool with a metric future rate offset in addition. Charge is held on low rate slots where charging is not required, avoiding conversion losses over next day and half. Only have to start questioning past 10pm tomorrow when choice of charge slots is dubious, expect that to firm up before those slots.

24 hour. Does have a positive impact in cost, the system is less aggressive with it's charge tonight, maintaining a lower battery target.

24 hours - risk if tomorrows rates are higher 48 hours - risk if tomorrows rates are lower Trying 36 :D

[slopemad]

Don't worry about the peak prices, there's a savings session paying £4/kWh saved ;-)

[gcoan]

@gcoan interesting, maybe it's the metric future rate offset import. I have this set higher than zero, intentionally trying to have the system take advantage of known current rates rather than gamble on estimated future rates.

Here are all my settings for comparison.

@JonathanLew1s I've compared my settings to yours, they are pretty much the same.

Only differences being:

• metric battery cycle cost you have 1, I have zero
• best soc keep you have 1.5, I currently only have a 5.2 battery so have it set to 0.3
• metric 10% weight you have 0.15, I have 0.3
• metric future offset rate import you have 1.5, I have zero
• plan forecast hours you have 48, I was running on 36 and its now 24
• rate low threshold you have 0.8, I tried that but found whilst the plan was better when it came to the charging slots it was tending to avoid them so set it back to 0

The metric future offset rate import only affects the pricing of tomorrow's unpublished rates, so the only thing that I can see relevant is the 1p metric battery cycle cost.

Just seen the new saving session, thanks for the tip-off @slopemad, serious £. The rates were so high tomorrow I was going to turn off the heat pump, now I'll see if I can export a bit from my tiny battery as well

[JonathanLew1s]

@gcoan it's strange how we have such varying outcomes from similar settings, only significant points are your usage is much higher due to ASHP and I have more storage. The way I understand your settings, your PV is more optimistic, your future import rates are equal to todays' rates, you plan for a shorter window. If battery sizes were equal I'd expect your settings to charge less.

As an aside, do you know you can automatically join the Octoplus sessions via the Bottlecapdave Octopus integration? Sends a nice notification in HA also.

[gcoan]

@JonathanLew1s thanks, I knew that I could see the saving session info through the integration, but didn't realise that there was event triggers and API's to auto-join the sessions https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/blob/develop/_docs/services.md

I hadn't updated to the v9 version of the integration either. Upgraded now and have setup the automations

[gcoan]

It's still not forward planning right, plans to charge the battery up ok overnight but then let's the charge release during the day leaving me empty for the peak period (and tomorrow's saving session)

Here's the plan at 22:45

I then uninstalled predbat, restarted HA and all the addons, manually made all the required changes to apps.yaml and the new plan looks much the same except weirdly the cost today is much lower (last column)

I had an issue that despite predbat recognises saving sessions it wasn't planning for them in the import and export rates. Deleting and setting predbat up again has fixed the saving session issue but not the wider forward planning problems. I did notice that despite uninstalling and restarting everything, all of the predbat control entities such as best soc keep were retained and I didn't have to populate those again??

my current settings:

[slopemad]

I think it's kind of expected, I'm seeing similar now. Here's my plan from 06:30 until 18:30 - it isn't planned to pre-charge the battery, and therefore there wont be so much to discharge, and the battery SOC will actually be reasonably high prior to the 'red' prices. But i'm fairly confident that it'll sort it itself out when the time comes. (That said, I'll keep an eye on it and charge manually between 1500 and 1530 if I think it needs it. Better to boost at 34.4p and try and avoid all those nasty red prices.)

[gcoan]

My predbat plan just isn't taking account of the higher rates and I've had to set it to read only and initiate a force charge whilst the rates are still comparatively low

1am plan last night, charge up overnight, discharge a bit in the breakfast price slots, then charge back up again in the morning - all good But then let the battery discharge before the evening peak and the saving session- not good but like @slopemad I was prepared to see it develop

8:40; plan much the same, battery charged overnight, coming up to recharging from 9am - good Afternoon discharge and nothing for the peak - still not good

9:02; predbat has decided against charging the battery at 29.5 and 28.6 which are the cheapest slots, instead letting the battery discharge to empty and recharge a bit at 31/32 before leaving empty for the peak - all bad

9:17; installed the newest version released this morning Double checked calculate best discharge is enabled and set discharge freeze only is disabled as per the updated docs - they're both correctly set Predbat now deciding to hold the charge at 23% but soc is 49% so it's actually still discharging in this cheaper slot - all bad

Since I would prefer to be recharging the battery at these 29/30 rates rather than the 33's just before the peak, I set predbat into read only mode and started a charge. Predbat still sticking to its same plan

[slopemad]

Obviously you are seeing different results to me, mine wasn't forecasting to charge at the 'lower' rates this morning, because it was expecting the solar to take care of the load and keep the battery full anyway. As it happens, because it's so cold, the heat pump has used quite a lot more power than it has been doing and with in day adjustment, it now expects a higher house load so it has now picked up on more charging options and sorted out a reasonable plan to make sure there is enough to discharge in all three slots. The plan it has come up with for me is actually really pleasing.

I use a pretty aggressive In Day Adjustment damping factor of 1.3 which i find does a good job of working out when my heat pump is going to pull more power (after all, if it's pulling more power overnight, then it'll probably pull more power all day). In-Day adjustment chart below for reference.

Also, if you think today's rates are bad, just wait until you see tomorrow. Expecting the low price between breakfast and teatime to not go below about 36p. It's a good job the sun is shining. And there might not be a DFS tomorrow to compensate.

[springfall2008]

@gcoan can you share a log?

[gcoan]

@springfall2008 Here's the logfile from around 9am appdaemon.log.1 (2).txt

Latest plan is now looking better after I manually took over and charged the battery up.

Latest logfile: appdaemon (19).log

I've just had a mare of the last 2 hours. GivTCP was working fine, and then at about 9:30 just stopped reading from inverter 2 which is the one with the battery connected. Repeated errors reading from the inverter. Inverter was online in the portal, givenergy app, but GivTCP wasn't populating MQTT. Tried everything, restarted mosquitto, givtcp, the inverter, HA and all the add-on's, physically turned the inverter off and on again, but still same issue. Restoring from the GivTCP 2.4.1 backup fixed the issue but why would it work fine for a week and then suddenly not work any more?

[slopemad]

@springfall2008 There's a bug in a calculation somewhere, have a look at 16:30

The cost column says -28p which is going to be incorrect for the plan - there's no discharging scheduled for that slot (and I doubt I'll be exporting a couple of kWh in half an hour from a 2.6kWh inverter, when it's dark).

[springfall2008]

@springfall2008 There's a bug in a calculation somewhere, have a look at 16:30

The cost column says -28p which is going to be incorrect for the plan - there's no discharging scheduled for that slot (and I doubt I'll be exporting a couple of kWh in half an hour from a 2.6kWh inverter, when it's dark).

I think you are right in that the cost is 5 minutes skewed, it doesn't change the outcome however. I'll fix that in the next version

[springfall2008]

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

[slopemad]

Looking good on 7.13.19.

I assume that it's current plan to charge throughout the evening will go away closer to the time, when it starts disregarding the best soc keep, and just run off the grid with a flat battery.

[gcoan]

Plan on 7.13.18. Spurious charge at 18:30 at a high rate, only to discharge in the following (cheaper) slot

7.13.19 is better, it's got rid of that charge at 18:30

16:30 slot is odd, it says "hold charging" but the soc limit is 81% and the soc is dropping over the period so it looks more like it's actually discharging? I'd have thought it would be better to hold 100% charge at 16:30, even though it's a high import rate, and keep the 1.54kW of predicted load so that it can be exported in the saving session period?

[gcoan]

15 minutes later and predbat is now back to predicting that it'll charge at 18:30 and 19:00 when the rates drop immediately afterwards !

Here's the logfile appdaemon (20).log

For now I'm leaving it in read only mode

[springfall2008]

15 minutes later and predbat is now back to predicting that it'll charge at 18:30 and 19:00 when the rates drop immediately afterwards !

Here's the logfile appdaemon (20).log

For now I'm leaving it in read only mode

Why no force export?

[slopemad]

I expect that those seemingly unnecessary 'Charge' windows disappeared once 4 hours out from them, like they did here. Predbat puts in a charge to maintain best_soc_keep, even if expensive, but once it is 4 hours out from a slot, it ignores best_soc_keep and so wont do that charge. All looking good, haven't had to override Predbat via Read Only mode for a couple of days now.

[gcoan]

To clarify: I left predbat in read only mode as it wasn’t devising an optimal plan. It wanted to start discharging to house load before the saving session, thus leaving less available to support me through the saving session or for a forced export.

Just before the saving session started I turned the ASHP off and enabled predbat again. We’re sitting in darkness with candles (Mrs’s idea not mine!) and predbat is behaving fine now, we’re using very little for house load which the battery is supporting and as we are under the predicted load predbat has started planning for a forced discharge of the excess battery charge.

My issues above were all about the predbat planning this morning and in the run up to the peak period.

[gcoan]

The saving session went reasonably well, predbat changed us to Eco mode at the start and then a force discharge part way through.

But after the saving session had ended at 19:15, predbat started charging the battery up despite it being a 32p slot, there being soc in the battery (no min soc) and the following slots all being in decreasing rates. I had to turn predbat back into read only mode and change the unnecessary charge to being a discharge.

It really seems that predbat struggles to plan with my 5.2 battery and high load of >1kW/half hour slot. Even within the 4 hour period of min soc not being applied, predbat is doing strange things and I have to intervene.

I think I'll stop posting screenshots and log files and give @springfall2008 a chance to look at what I've posted already

On the positive front we've got a 2 hour octopus power up event tomorrow; free electricity from 11-1pm. And then the rates go up again

[springfall2008]

@gcoan I think you need to set your soc keep to 0 as your battery is just too small to keep a charge level and be optimal in terms of costs. Have you tried that and does it work?