Future Agile rates suggestion

[slopemad]

At the moment, Predbat assumes unpublished Agile rates are the same as today's rates, and there is an offset function to calculate tomorrow. Trying to think of how it might be better to do this based on Octopus Watch or the agilepredict twitter account suggestions.

I can see that the overnight rates tonight could be about 18p (whereas last night they were down to 0.5p), so I have created a rates_import_override to deal with this: rates_import_override:

• date: '2023-10-31' start: '00:00:00' end: '07:00:00' rate: 18

But I'll need to remember to delete this at 4pm when tomorrow's Agile rates are out. The rates offset would be a very crude tool, because the rates beyond overnight will be broadly similar to today anyway, hence creating an override. If I used the rate offset to add 18p, it would likely hike the Low Threshold very high.

But... I only want this override to apply as long as the real Octopus rates are unpublished. Perhaps there could be an alternative to rates_import_override which only applies until the actual Agile rates are published, and then the actual rates override the override? The 'date' field is also probably important, as I wouldn't necessarily want my assumed rates for tomorrow to apply for the day after also?

This will help in situations where you have rates tomorrow which differ wildly from today.

[gcoan]

Less configuration options is clearly preferable for new users

I have mine set to 96 even thought I’ve dropped the forecast hours down to 28 now as I cycle the battery every day, often twice, so a longer forecast wasn’t adding anything.

Why not make the number of windows twice the forecast hours automatically?

On 17 Nov 2023, at 13:52, Trefor Southwell @.***> wrote:

 In a 48 hour plan there can only be 96 windows at the most.

I'm actually wondering if I can get rid of the windows setting soon and just hard-wire it back to 96. It was done for performance reasons but I'm not sure if it's still needed.

That said I can see the value in having higher rate windows in the near term, rather than just the N lowest ones, I'll think about that too.

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

[slopemad]

In a 48 hour plan, where prices are consistently trending down over that period, then all charging is skewed towards the end, and not the near future.

So I put Predbat into read only to have a little play.

48 windows : best price, with second pass enabled, best cost =1320.3 48 windows : best price, with second pass disabled, best cost = 1330.92, soc keep = 2

96 windows : best price, with second pass disabled, soc keep = 2 : best cost = 1391.56

96 windows, changed soc keep to 1 : best cost = 1379.4p

96 windows, soc keep = 1, second pass calcs enabled again : best cost = 1346p (but the run took 119 seconds and that's in read only mode, so it isn't even setting the inverter in that time!)

So with more 96 windows, it's clearly trying to charge too much and the cost goes up (although I'm probably not taking into account how much energy is in the battery at the end of the 96 hours...)

[slopemad]

Incidentally, I have charted the Predbat forecast calculated prices for tomorrow (blue), versus the actual prices (red), versus the prices you get by simply applying the magic formula to the hourly wholesale prices (yellow). The forecast rates that Predbat calculated after the Nordpool prices came out this morning were pretty close.

[springfall2008]

Interestingly the Predbat ones seem a little further out than the wholesale. What I did with Predbat is use it to make adjustments to the previous days rates, maybe that isn't helping?

[springfall2008]

Completed