batpred
batpred copied to clipboard
Grid friendly mode - Solar charging and export
Is your feature request related to a problem? Please describe. We know that on a good solar day generation will peak around noon (or 1pm during daylight savings). This isn't that helpful for most electricity grids that tend to have a flat daytime demand up even a dip in the mid afternoon. Home batteries now compound this issue by charging up at the start of the solar generation period, providing no support to the grid earlier in the day and then suddenly starting exporting potentially several kW several hours into the day.
Describe the solution you'd like Informed by the solar forecast on days with enough solar to fully charge the batteries Predbat would delay charging and prioritise charging during the peak of solar generation. The intention being to flatten the daily export curve. Potentially even using lower charge rates to achieve this so batteries are charged and export is smoothed across generating hours.
Describe alternatives you've considered Last summer before finding predbat I was pausing battery charging until mid-morning. At the time I was doing this manually. Could potentially achieve similar with automations into predbat.
Additional context https://youtu.be/4loz5EAHVUY?feature=shared
If we want to continue getting good export rates into the future to protect the rate of return from our solar and battery investments we need to be considerate of the impacts they have on the grid and not allow them to become a burden to the grid.
Suggest that any solution enhancement also incorporates solar clipping requirements as there's quite a bit of overlap
See https://github.com/springfall2008/batpred/issues/1206
Yes. I expect the logic required for the calculations would be the same for this and an enhanced clipping model.
I had the same concern, so I did an automation to force-discharge the battery in the morning if the forecast PV is over a threshold, put the inverter into feed-in mode outside the peak pv hours, and then store the peak PV power into the battery via self-use mode (this is a Fox inverter so the terminology is different to predbat's).
Note that this is highly non-optimal from predbat's viewpoint because putting the peak PV into the battery incurs both conversion losses and also battery degradation. But in my case, I haven't managed to get predbat to directly use feed-in mode in any case, so overall it's an improvement since I'm at least forcing feed-in mode outside the peak hours.
Another solution might be to pick up the wholesale prices (from nordpool or whereever), and then just use those figures to adjust the rates up and down to encourage predbat to store the export when the wholesale prices are very low, and export when the prices are higher. I believe the functionality to do that is already built-in.
This has been bubbling through my brain since opening this earlier.
I think the planning logic would be similar to car charging. We have an SOC we want to achieve, a charge rate and an input metric to optimise against. Only instead of minimising price we are maximising solar forecast. That feels like a good MVP. Subsequnt improvements would be to make the charge rate variable and optimised by the model also.
I’ll leave that thought there. Always better to be able to borrow from somewhere else and adapt than start from zero.
Would you not want to use the carbon optimisation to kind of achieve this?
I use a lot of carbon metric. That means any excess export is not just held to the end of the peak rate period. Which I like. Currently at 25 and have been at 50 in the past.
I think only at 50 did I see behaviour even remotely like I’m describing and it had other unfavourable effects. I hardly ever see freeze export early in the day.
This enhancement suggestion is about how to more considerately handle days of excess solar based on the solar forecast. I believe to remain profitable over the long term battery storage needs to flatten the demand/export in normal operation and then be able to respond to excess generation and DFS events
With the last few sunny days I have been playing with some of the concepts using the manual API.
I'm slowly working towards an automation that will set manual freeze exports. Having lots of fun generating the correct string to provide when using the select action.
What I do have working is if the solar forecast is over a certain threshold it fires an automation to use the manual API to set a lower inverter_limit_charge.
An hour after the solar peak I'm then clearing it.
What is confusing predbat is of course it can't know I'm going to clear it later in the day.
Is it be possible and if so onerous, to have the concept of inverter_limit_charge override? That being it is time bound in the same way as rate overrides are. Possibly a few other of the manual API calls would benefit as well.
I think this would provide an awful lot of flexibility for those of us trying to optimise our installations without needing to make assumptions about what works best for the average scenario.
Is it be possible and if so onerous, to have the concept of inverter_limit_charge override? That being it is time bound in the same way as rate overrides are. Possibly a few other of the manual API calls would benefit as well.
that sounds like a good idea and if we are to do some of this 'smarter clipping control' in automations that can sit alongside predbat then its needed otherwise predbat will plan wrongly
I'd also like to put in a request for #1974 a FR I put in for per-inverter battery reserve limits to have similar time range limits. I need this to be able to stop Predbat discharging the battery too far in the day that I can't charge the batteries back up in the afternoon Cosy period, but same problem, only want to apply this for a limited part of the day
be interested to see how your automation comes together. At the moment I am putting predbat into read only every morning and managing the discharge to reserve limits so I can recharge in the afternoon. As it gets sunny though I have the opposite problem of emptying the batteries to a 'discharge to' limit as we keep on getting Octopus Power up events and I want to fully recharge in the free period.