GivBack Event via GivEnergy inverter in unison with Axel Energy

[TheSargey]

Is your feature request related to a problem? Please describe. Firstly, thank you @springfall2008 for all your hard work and dedication bring us the Bat, I've only had it installed a couple of days and really looking forward to tinkering with it.

My issue is (as per the title), is how best to make batpred work alongside the GivBack events that are sponsored via Axel Energy. Unfortunately I'm not able to export via the SEG, therefore these events are my only way of earning during a short export window. We had one today (they usually run in tandem with the Octopus saving events) and, if signed up, Axel Energy automatically set the inverter to charge prior to and then export during the window. Axel Energy pay a huge premium to standard SEG during such events so it's well worth the export (today was only 50p per kWh but in the past they paid £1.50+).

Sadly I wasn't at home when this occured, but obvious to me now as I had octopus_saving_session in app.yaml set, batpred overrode the commands and instead of exporting, the home ran on battery to reduce import from the grid (as it should during an Octopus saving event). My question is, in this scenario, what is the best method to allow Axel Energy to manage the inverter? Is it simply to set batpred to read-only when I receive notice of an upcoming event? This can be difficult as generally you only get a couple hours warning prior to the event, hence it's "automated" via Axel Energy. I noted in the batpred plan that the import rate went awry for this period but the export rate (on my system at least) remained zero (as again, I'm not able to export for a fee).

Describe the solution you'd like Ideally it would be great for batpred to interpret the GivBack/Axel Energy events as it does for the Octopus Saving events and incorporate into the batpred plan/calculations.

Describe alternatives you've considered I'd be happy to have a work around suggested.

Many thanks once again for your time developing and any assistance you're able to provide. If you'd like any further information please let me know.

Cheers,

Sarge

[gcoan]

The difficulty in Predbat interpreting the Axle/Givback events is I don't think they have any API that Predbat could read to determine if there is an event planned or not, its all done by email ?

One option could be that you just let Predbat manage the event for you based on the Octopus saving session notification. Axle will send their commands to the inverter and then Predbat will over-write them.

There's two issues I can see with that:

1. Each energy provider has to bid for the DFS sessions and the recent winning bid threshold has been quite low and not every supplier is successful. In this latest event Axle were successful and Octopus were not, but there have been others where Octopus was successful and Axle wasn't. Even though Octopus was successful they still put the event on and are paying their customers from their own profits (presumably from previous events). Axle haven't been as generous. So if you let Predbat schedule the events for you based on Octopus saving sessions, you might be doing a saving event at the wrong time.

2. You said you can't get SEG payments so presumably you normally have Predbat mode set to Charge only and not Charge and Discharge. Which is why all that Predbat did was to reduce grid import. And you want to export during this event - which requires Predbat mode to be set differently.

I think the safest way is NOT to set the Octopus saving session details in apps.yaml because of point 1 above. When you know there is an Axle saving session you either:

a) set Predbat to read only a period of time before the session so Axle can send the commands (and Predbat won't over-write them), and then turn read only off afterwards

or

b) setup three helper entities in Home Assistant with saving session start, end and date values, then create an automation that will trigger at the start time to set Predbat to read only and set your inverter to Force Export, then at the end set read only off

or

c) setup helper entities as per b, then in an automation set Predbat mode to Charge and Discharge so that Predbat manages the export for you

With b and c you'd be advised to set the helper entity start time to being a little bit before the actual saving session start time, e.g. 5 minutes before to allow your automation the chance to run

If there is an API for Axle or you can write a script to read the Axle email then you could automate a bit more of this

Hope this helps !

[RobinCu]

@gcoan I guess the DFS API could work. If "Axle Energy Limited" had a bid accepted on the DFS Utilisation Report, then it could be assumed they will run a session, and an automation could switch PB to read-only.

The API includes the start and end times and the £/MWh.

It would need to be "user beware" as: a) there's an unlikely chance Axle have a bid accepted but doesn't run a session; b) the price per kWh would be inaccurate but it would be indicative (and without a baseline, all overall costs, regardless of Participant is inaccurate). c) we're very near the end of the Winter 23/24 tests and ESO might change the API, GivEnergy might change Participant from Axle, etc., so I don't think it's worth investing too much time now but something to consider for November when GivEnergy announces GiveBack 2.0.

[gcoan]

Good idea @RobinCu I hadn't thought of using the DFS API's which do enable you to interrogate the DFS session database.

I agree we are coming to the end of the saving session period for this winter so possibly not worth investigating too much. Of course it would be good if these things were run at other times of the year, but no sign of that happening and maybe people (without battery automation) will get fatigued if its a regular activity with minimal benefit. As it was, 50p benefit in the last event isn't going to excite most people, but maybe that was the purpose, to find out how effective they can be (or not) at low participant £ rates.

Rather than an Axle-only lookup it could be possible to interrogate the DFS database for any named DFS-id so Predbat could then be used for any non-Octopus electricity provider. One additional issue with that is that some large providers have multiple DFS id's to cover their customer base.

[TheSargey]

Good morning gentlemen,

Thanks for your quick responses and I agree the best foot forward in this circumstance would simply be to set as read only as soon as an event is announced to allow Axle (or whichever provider is intending to pay for the exported energy) to manipulate the inverter and then set predbat "live" afterwards.

One thing I did notice was the import rate in my batpred plan changed to a very high value for the particular period, sadly I didn't get a screenshot (which I'll remember to next time), perhaps that could be used as an indicator of an upcoming event.

Anyway, as you've rightly suggested its unlikely there'll be many more events like this for another six months or so it's unnecessary to invest time/development. I was really just looking for advice on how to deal with it and I think you've answered this perfectly.

Thanks again for all your help, very much appreciated.

Cheers

Sarge

[gcoan]

One thing I did notice was the import rate in my batpred plan changed to a very high value for the particular period

Yes this is part of the way Predbat manages the saving session, it increases the import and export rates by what the saving session amount is to ensure the plan reduces import and maximises export as much as possible

https://springfall2008.github.io/batpred/energy-rates/#octopus-saving-sessions

[TheSargey]

One thing I did notice was the import rate in my batpred plan changed to a very high value for the particular period

Yes this is part of the way Predbat manages the saving session, it increases the import and export rates by what the saving session amount is to ensure the plan reduces import and maximises export as much as possible

https://springfall2008.github.io/batpred/energy-rates/#octopus-saving-sessions

Ah, that makes sense - thank you. Going back to your earlier post, I've actually got batpred set as charge and discharge however as I'm not exporting anything (other than these such events) is it wiser to set to charge only? Would it alter the batplan in a significant way?

[gcoan]

Ah, that makes sense - thank you. Going back to your earlier post, I've actually got batpred set as charge and discharge however as I'm not exporting anything (other than these such events) is it wiser to set to charge only?

If you don't get paid to export then there's no point in Predbat being set to Charge and Discharge mode as it will (where it thinks its profitable) discharge the battery to generate you export income although what rate it uses, I don't know.

It may be that the lack of export rate is why it hasn't discharged up to now, or it may just be that Predbat thinks you need all the solar and grid charging to cover your house load so its not bothering to discharge.

I would change it to just Charge mode

[TheSargey]

Thanks for all your help Geoff, very much appreciated.