More configurable (ie per-slot) options for load during negative energy periods, option to have predbat intelligently discharge battery prior to negative energy periods.

[grey-area001]

Is your feature request related to a problem? Please describe. When enegry rates are negative (ie I earn money for using electricity) predbat will make predictions based on "normal" load. This means, for me, it does multiple charge and discharge cycles. This is a problem because I tend to run, often via automation, several power hungry devices. When predbat starts discharging it feeds those devices and limits or elimates grid import and the benefit is gone.

Describe the solution you'd like I have two things I would like

1. I would like a way of making predbat aware of potentially increased load during negative energy periods and only those slots on the plan.
2. I would like to be able to tell predbat to prioritise battery discharge prior to blocks of negative pricing so the battery is optimally discharged for the negative pricing period.

Michael also described a similar problem this way:

"I’d love a “never discharge” when price below toggle inside predbat. Forcing predbat to either charge or freeze discharge.

Because I turn on power hungry things when the price is negative and occasionally predbat will choose to force discharge in those slots because the price is getting even cheaper later"

This feel like a solution I could live with too.

Describe alternatives you've considered I was looking into methods of doing this via HA automation but it seems very complex to set up something that reads the future rates and then tries to set future predbat behaviour based on this. Trefor suggested this could be an an added feature to me on the general facebook chat

[gcoan]

One possible solution to this could be resolution of the bug I noticed in #1255 - there is the ability to do a rate override in apps.yaml and include with that a load scaling factor for the rate override time period. At the moment though Predbat requires that the rate be supplied, and if it's not, a zero rate is assumed.

If the rate were optional (default to current rate) then this would provide an easy mechanism via apps.yaml to provide a load override to Predbat (it is possible to write automations to write to apps.yaml, I have done this for the Octopus power up events)

[grey-area001]

Thanks @gcoan that will be worth a look. It would definitely be preferable to have this handled within predbat and the UI if possible. I do appreciate @springfall2008 is but one person so this is definitely a request and not a demand :D

[mpartington]

I think the 'do not discharge if price is below X' would be a good addition.to UI. So another vote from me.

I would certainly use this, as I've the same issue of telling Predbat when I'm going to use low price slots for high drain periods during the day (where it sets to Idle by default). I know you can manually set slots, but this could be easier linked to external automations

[gcoan]

Agreed, input number and thresholds (e.g. 'do not discharge' threshold) are a lot easier to automate/control than manually change apps.yaml

part of the request was the ability to configure additional load in certain time periods. I don't think this is something particularly easy to do via the UI as it requires a time period (start/stop or select multiple time periods from a selector) and one/many load adjustments. Another dropdown selector to choose the slots and a single input number would give partial answer. Or my suggestion about apps.yaml.

I've had experiences of Predbat choosing to discharge the battery ahead of low rate periods that look doubtful as to whether they are going to be worthwhile or not. I found in https://github.com/springfall2008/batpred/issues/1235 that turning switch.predbat_metric_cloud_enable off made quite a difference to the discharge choice. If solar was anything like the PV forecast then I'd be generating so much solar that I'd be exporting, and not able to import, but with this switch on Predbat was modulating between the PV and PV10 forecasts, coming up with a conclusion that 'worst case' I would be importing so it was worth discharging beforehand.

[grey-area001]

Thanks @gcoan - These are good points. I was think more along the lines of a dropdown like force charge/discharge that increases load by an input number you se independently. The increased load will be fairly consistent across the period so a single figure to increase by would be sufficient (in my use case at least)

I'm going to give turning off switch.predbat_metric_cloud_enable a try.

[springfall2008]

Okay I've kind of re-worked the iboost, you can now set import and export rate thresholds, you can have smart iboost which selects just the cheapest slots of import and you can filter on gas import and export rates also. Documentation also updated. All on main for testing/review

[gcoan]

Okay I've kind of re-worked the iboost, you can now set import and export rate thresholds, you can have smart iboost which selects just the cheapest slots of import and you can filter on gas import and export rates also. Documentation also updated. All on main for testing/review

@springfall2008 did you reference the wrong Github issue?

1283 was about iboost

[springfall2008]

Okay I've kind of re-worked the iboost, you can now set import and export rate thresholds, you can have smart iboost which selects just the cheapest slots of import and you can filter on gas import and export rates also. Documentation also updated. All on main for testing/review

@springfall2008 did you reference the wrong Github issue? #1283 was about iboost

Well sort of, but you can now configure iboost on negative rates which would model the posters request

[grey-area001]

Thank you. I'll take a look and see if it'll do what I'm hoping for.

[dochtie]

I don’t use iBoost so it’s not helpful for my purposes. Ie negative agile rates. My automations kick in but predbat could be on idle or even worse on force discharge during a negative rate.

could the function ‘no battery discharge below X(pence)’ be added?

Alternative I wonder whether your saving session function could be altered which models higher usage during negative rates. When rate below X increase load by Y. Something like that? Treating rates below x(pence) like a saving session.

[gcoan]

Alternative I wonder whether your saving session function could be altered which models higher usage during negative rates. When rate below X increase load by Y. Something like that? Treating rates below x(pence) like a saving session.

The saving session doesn't at the moment do any detection of negative rates, it pulls the specific date, start and end times and bonus rate for the saving session from an Octopus API and adjusts the normal export rate for that time period. It also has the ability to increase the predicted load for the saving session period.

I think its a different function you need, but definitely could be done.

[dochtie]

It’s the ability to adjust the load I was referring to. Perhaps this new function could work in the same way.

Eg When rates are negative expect 50%/100% more load. This would then change the behaviour appropriately.

Obviously with the saving sessions it was the inverse - I was just highlighting that this solution worked great to help predbat account for my reduction in load during saving sessions.

[gcoan]

I was just trying to highlight how the saving session function worked and where it didn't quite match what's needed.

Thinking about it just now, I'm not sure a "when rates are negative expect X% more load" pattern is going to meet all the needs:

If its a negative/very low rate overnight then yes, I too try to maximise consumption, I put the washing on, tumble dryer, I even have an automation that turns a couple of electric radiators on in outside sheds!

But during the day when there's solar generation, it all depends on the solar generation. Quite often if its a sunny day and the rates are negative or zero (we get the Octopus power up events in our area), I've got so much solar being generated that I'm unlikely to be able to use it all up on home load. I've got two inverters so can import about 2.4kWh in a half hour slot, but if the predicted solar generation is 3 or even 4kWh in the slot then I just don't bother because I know I won't be able to consume all the solar generation, let alone import, and even if I did it would be for such marginal benefit.

Obviously different people will have different size solar arrays so this kind of thought process isn't always needed, but I'm still leaning towards needing a more general purpose way to tell predbat when there will be extra planned load at certain time periods.

[dochtie]

Makes sense - I completely agree. So to summarise I think we are requesting 2 different solutions for this negative agile rates issue.

1) a ‘don’t allow discharge below Xp’ in the UI which limits the choices predbat can make. It’s fairly broad but still allows predbat to do some optimisation on its own.

2) “a way to tell predbat of increase load predications at certain times”. This is more user driven but much more useful for a wide range of different scenarios.

And it’s worth pointing out we already have a workaround for the issue which is to override slots manually. We just have to do a lot of overrides.

Also worth saying I’ve got an automation which uses the very useful ‘predbat is charging’ entity. If it changes to off then so do my switches, immersion heater etc. If it changes to ‘on’ then they come back on. It’s not perfect but a decent temp workaround for the devices that are easy to switch on and off again.

[Jorthax]

I would also use/appreciate a function like:

a ‘don’t allow discharge below Xp’ in the UI which limits the choices predbat can make. It’s fairly broad but still allows predbat to do some optimisation on its own.

Ideally if elec is below 0 I would never want to use my battery, as I will switch on lots of devices in my home (cooling/heating) to use this energy to raise/lower temps to better control the overall day.

[mpartington]

As above, +1 for do not allow discharge below x

Example for today, put washing machine on and it drew from battery as Predbat obviously didn't expect the load. Nature of agile is usage will be intrinsically linked to slot cost. If you start getting really low cost slots then you want to use grid as much as possible

The other option is to override every slot, but a single input number (that could be changed via automation) would be a good solution