Agile charge window optimisation

KevinS

On Octopus agile with a high capacity battery and PV, I want to optimise the choice of number of agile charging slots according to battery SOC at start of day. One can choose to configure non-overlapping windows to start/trigger according to SOC, and one can configure a target end SOC, but this won't deliver an optimised choice of charging slots across the whole day if the cheaper slots are later. The alternative is to edit the number of charge windows daily, but this defies much of the point of automation. Am I missing something here?

If not, then a simple approach could be to allow multiple charging windows of the same overlapping period to be active simultaneously, with the (additive) selection/activation of slots taking place dependent on the trigger (SOC) conditions of the windows at the window start time. Alternatively, one could have more complex sequencing/ prioritisation of overlapping charge windows, with an "if activated, then skip other overlapping charge windows today" option.
Either way, this would also need more than the current max of 3 charge windows.
Could we have a beta option to test such overlapping configurations?

KevinS

Hi Admin - conscious no comment so I was wondering if I could present the issue differently
I want to be able to say at Midnight:
If SOC is less than (say) 70%, then select X agile slots
If SOC is less than (say) 50% then select Y agile slots
If SOC is less than (say) 30% then select Z agile slots
with Z>Y>X
At present, I can only choose a single SOC condition per window as I can't have more than one schedule active in overlapping time slots and thus whilst I can choose whether or not to use afternoon charging based on SOC, it doesn't give me an optimised solution without daily manual intervention.
What's the right way ahead here?

admin

KevinS

KevinS I want to be able to say at Midnight:
If SOC is less than (say) 70%, then select X agile slots
If SOC is less than (say) 50% then select Y agile slots
If SOC is less than (say) 30% then select Z agile slots
with Z>Y>X

This being as dynamic as it is would also mean that the prepopulation of your Agile charge windows does not happen when you save, and custom slots for dynamic agile charge windows like you suggested wouldn't be possible, because they likely conflict with the later scenario and would get overwritten and therefore would be locked when you're in this mode.

I do wonder whether the 12 Agile charge windows you have at your disposal now could be used to achieve a similar effect.

johalareewi

I was hoping WW could do that too.
You can get close now that WW does the 'try again in 30 minutes' feature.
You can set an agile window to select Z slots if SOC < 30%.
Then if SOC is >30%, WW will skip the first slot and try again in 30 minutes.
And so on.

KevinS

Hi Johalareewi - thank you for your helpful explanation - and I see admin liked your answer too. But for me, this doesn't really address the issue; I don't see the "try again" facility as getting close, because the early slots of the day are often the lowest price, and this approach would miss them. One might do better by splitting the day into 2 or 3 windows with the trigger SOC level escalating. But it isn't automatically optimising the choice of charge slots according the SOC at the start of the day. The key seems to be facilitating rules with different trigger conditions to use overlapping periods.

I'm hoping Admin can see the value of a feature to add - and I'd be happy to engage the development team to help get the concept right because I can see it's not a simple fix.

admin

KevinS I'm not 100% sure I fully appreciate the specific problem.

The solution you suggest seems to me that you want WW to dynamically adjust the number of charge slots (for a long Agile charge window) based on a current SOC state at the start of the window?

But clearly that then won't take into account your usage...

So if you don't mind, please explain the problem you currently have and the manual steps you have to do.

KevinS

admin
Correct summary and good question.
For the morning, I have a pretty predictable usage - at least until up until the end of the afternoon charge window, I can predict and allow for this in determining how many charge slots I think I need. Late afternoon and evening usage is much more varied, all sourced from the battery.
More unpredictable is the PV contribution. If I knew the following day's charge algorithm could take account of a lower or higher starting SOC caused by PV variations, I wouldn't need to worry about PV contribution other than tweak values for the seasons. Meanwhile, I can also choose a target SOC that takes account of the likely amount of sunshine to ensure I don't inadvertently export, but at risk of losing a late low-priced slot.
So right now, I assess the likely SOC at midnight (or retrospectively check it) and use a table I have created to look up how many charge slots I think I need for the day to maximise the charge by 4pm (with a small margin to ensure the PV never exports), using optimised available charge slots. At present, that's a daily task to look up and then select in the number of slots, which I could automate if WW could offer overlapping active windows or an ITTT-type logic flow. Ideally I would also like more than 3 window options. 5 would be good.
Hopefully that explains the problem I'm trying to solve more usefully.

admin

KevinS Right, thanks for your explanation.

We will be introducing PV forecasting for Agile at some stage. It's a fair bit of work as we need to break it down per hour. So that will hopefully solve your problem eventually.

In terms of overlapping windows, that's pretty much a no-go. Would require way too much modification and be likely highly disruptive.

We are looking at upping the number of charge windows (and naming them) as well as number of custom Schedules in the short term.

johalareewi

admin We will be introducing PV forecasting for Agile at some stage

I will be very interested in this. At the moment I am manually tweaking the overnight charge slots to leave enough battery space for the predicted solar. Hopefully Agile with PV forecasting will reduce this somewhat.

KevinS

Good to see some tweaks to improve WonderWatt, but for me, the product is not sufficiently mature to justify a subscription - and certainly not at the level proposed. What I want to do is charge from different start points and exploit the best priced agile windows. The app still can't do that; it still needs daily intervention. The algorithm needs to support a simple ITTT flow option, and until it does, it's still a Beta product under development.
Three options:

Can the team work on this as priority? My earlier posts explain the problem.
Beta pricing for a Beta product.
I get a Raspberry pi and work through the Givenergy API to implement a simple ITTT algorithm to meet my needs. I would much rather see an innovative product (WW) developed to meet the need - but if needs must, is anyone else doing something similar?