New saving sessions don't register

[danieltwagner]

Describe the bug

I got an email about an hour ago that new saving sessions are back in order and that one is starting today (2024-12-11) between 6-7pm, along with an opt-in button. I went to check if my automation had fired and noticed that the binary_sensor.octopus_energy_a_<account>_octoplus_saving_sessions sensor hadn't changed, and hence the automation didn't run.

I did see that, octopus_energy_all_octoplus_saving_sessions shows a bunch of activity, but I'm not sure how to see details for those events.

Could it be that something about the APIs has changed for the 2024 saving sessions? Any other information I can provide?

Reproduction steps

Be invited to a saving session

Expected behaviour

Saving session is detected, automation is triggered to join it.

Tariff Code

20L3168997

Integration Version

13.2.1

Home Assistant Version

2024.12.1

Fresh Install?

Not specified

Home Assistant Logs

I had not enabled debug logging at the time

Confirmation

• I confirm that I cannot find my solution within the documentation
• I confirm that I cannot find my solution within the FAQ

[darrenmckie]

I also noticed that the auto join has nor worked for this saving session. I also note that there is no octopus_energy_new_octoplus_saving_session event.

[JRascagneres]

Pretty sure this (at the moment) is because the sign up appears to be via email and is not yet on the website / API so there isn't a way for the integration to see the session. Once octopus integrate it into their website this may well work again.

See message on website:

https://octopus.energy/dashboard/new/accounts/A-ED2703DA/saving-sessions

Sounds like website will be sorted mid-January

[plord12]

Yea ... I created a calendar and updated my automations to trigger from that (as well as the API)

[BottlecapDave]

Yeah for some reason they haven't updated the API to include the upcoming event. I hope they're not building yet another set of APIs...

[JRascagneres]

@BottlecapDave I think it needs changing as they're now region specific so probably changing things on the backend for that. Its possible that the APIs will change for that.

[plord12]

I did wonder if they've gone manual to avoid us automating ....

[JRascagneres]

I did wonder if they've gone manual to avoid us automating ....

No I think its just 'at the moment' - Hence the website saying mid-Jan. I think its a combination of the move to regional and they only recently decided to even participate and these things take time to be integrated.

[BottlecapDave]

From what I could gather from their messaging, the regioning seemed like it was superficial leaderboards, but re-reading it, you might be right. Hopefully they can build the free electricity API while they're at it :p

[JRascagneres]

From what I could gather from their messaging, the regioning seemed like it was superficial leaderboards, but re-reading it, you might be right. Hopefully they can build the free electricity API while they're at it :p

Yeah its not just superficial boards this time. Last year it kinda was for stats.
Appears the region is involved in the NESO requirements too.

[plord12]

There is also a team name. I chose "Home Assistant" ... maybe if its near the top Octopus will take more notice :-)

[johnwb87]

From what I could gather from their messaging, the regioning seemed like it was superficial leaderboards, but re-reading it, you might be right. Hopefully they can build the free electricity API while they're at it :p

Yeah its not just superficial boards this time. Last year it kinda was for stats. Appears the region is involved in the NESO requirements too.

NESO are now dispatching the DFS as similarly as they can other balancing services. So I’m guessing that the price and utilisation will be better if the aggregator(Octopus for us) can guarantee the region of demand reduction.

[pjvenda]

Interestingly, ESO published documentation last year that discussed automation and people 'rigging the system' re the 2022/2023 saving session season. Their comment was that 1. there was no evidence or it wasn't a meaningful proportion and 2. it was not harmful to the purpose of shifting loads. This seemed surprisingly honest and weighted.

I think automation would actually contribute towards the goal. So realistically I wouldn't see why NESO or octopus would actively discourage automating and optimising output of saving sessions. If NESO are paying people it's because they benefit (more) from it. I haven't looked for similar documentation re: last year's activity.

Big thanks to all the devs!

[scotflieger]

For previous Saving Sessions I used a Node Red automation to react to the 'Octopus Saving Sessions' entity (binary_sensor.octopus_energy_[acct]_octopus_saving_sessions) to switch my Tesla Powerwall2s to Off Grid ensuring that I was not consuming any power during the session. Last night I had to do this manually as the entity is no longer set. As Saving Sessions are now back on it would be useful if the entity worked if still in the API. It may well be that Octopus did not set the flag as the session was announced at short notice.

[danieltwagner]

Same here, I have an automation (as I imagine many of us do) for load shedding during saving sessions which will turn off non-critical items, such as heating in the workshop. In my opinion this kind of automation is exactly what savings sessions are supposed to encourage and automating it is exactly in line with goals. Let's keep our fingers crossed that lack of API support is just an omission due to time constraints.

[maegibbons]

Yea ... I created a calendar and updated my automations to trigger from that (as well as the API)

Have you got code for this that you can post?

[gcoan]

I created some date helper entities (date, start time, end time) and an amount so I could inject those into Predbat as a manual export rate override.

Not fancy but it worked with Predbat deciding whether to discharge my battery or not

[plord12]

Yea ... I created a calendar and updated my automations to trigger from that (as well as the API)

Have you got code for this that you can post?

Its pretty easy. I've got myenergi battery so I want to charge battery before saving session starts, start export when saving session starts and stop when it ends. So 3 automations.

alias: Electricity Rule 5b - charge battery before saving session
triggers:
  - trigger: template
    value_template: >
      {% if states('sensor.myenergi_libbi_soc')|is_number and
        states('sensor.minutes_to_start_of_saving_session')|is_number
      %} {{ (states('sensor.minutes_to_start_of_saving_session')|float)*1.8 >
      (states('sensor.myenergi_libbi_soc')|float)+100 }} {% endif %}
  - trigger: calendar
    entity_id: calendar.saving_sessions
    event: start
    offset: "-01:30:00"
conditions: []
actions:
  - action: retry.action
    target:
      entity_id: select.myenergi_libbi_operating_mode
    data:
      action: select.select_option
      option: Normal
      on_error:
        - service: script.debug
          data:
            message: Rule 5b:Failed to set libbi to Normal
  - action: retry.action
    target:
      entity_id: switch.myenergi_libbi_charge_from_grid
    data:
      action: switch.turn_on
      on_error:
        - data:
            message: Rule 5b:Failed to set libbi to charge from grid
          action: script.debug
  - action: script.info
    data:
      message: >
        Saving session starting in {{
        states('sensor.minutes_to_start_of_saving_session') }} minutes.  SOC is
        {{ states('sensor.myenergi_libbi_soc') }}.  Start charging ready for
        discharge in saving session.
mode: single

alias: Electricity Rule 5c - export when saving sessions start
description: ""
triggers:
  - entity_id:
      - binary_sensor.octopus_energy_a_xxxxxxxx_octoplus_saving_sessions
    from: "off"
    to: "on"
    trigger: state
  - trigger: calendar
    entity_id: calendar.saving_sessions
    event: start
    offset: "0:0:0"
conditions:
  - condition: not
    conditions:
      - condition: state
        entity_id: sensor.myenergi_zappi_xxxxxxxx_plug_status
        state: EV Connected
      - condition: state
        entity_id: sensor.myenergi_zappi_xxxxxxxx_plug_status
        state: Charging
actions:
  - data:
      message: Octopus saving sessions start - start exporting battery
    action: script.info
  - action: retry.action
    target:
      entity_id: switch.myenergi_libbi_charge_from_grid
    data:
      action: switch.turn_off
      on_error:
        - data:
            message: Rule 5c:Failed to set libbi to stop charging from grid
          action: script.debug
  - action: retry.action
    target:
      entity_id: select.myenergi_libbi_operating_mode
    data:
      action: select.select_option
      option: Export
      on_error:
        - service: script.debug
          data:
            message: Rule 5c:Failed to set libbi to Export
mode: single

alias: Electricity Rule 5d - stop export at end of saving session
description: ""
triggers:
  - entity_id:
      - binary_sensor.octopus_energy_a_xxxxxxxx_octoplus_saving_sessions
    from: "on"
    to: "off"
    trigger: state
  - trigger: calendar
    entity_id: calendar.saving_sessions
    event: end
    offset: "0:0:0"
conditions: []
actions:
  - data:
      message: Octopus saving sessions stop - stop exporting battery
    action: script.info
  - target:
      entity_id: select.myenergi_libbi_operating_mode
    data:
      action: select.select_option
      option: Normal
      on_error:
        - service: script.debug
          data:
            message: Rule 5d:Failed to set libbi to Normal
    action: retry.action
mode: single

So triggering from both calendar and api.

Oh, I use a sensor minutes_to_start_of_saving_session so that charge start time depends on the current state of charge (if its near full, start charging late, if its near empty, start charging early).

This is WIP.

[maegibbons]

Many thanks!

[deltamelter]

I wasn't expecting the autojoin or baselines to work at the moment because OE don't seem to be fully back to using the API.
I had expected to see the latest event in the saving session events entity though. It only seems to show all the events up until March. I see this using graphql. How is the integration fetching SS events? Why can't it see this one?

            {
               "id" : 1324,
               "code" : "EVENT_16_111224",
               "startAt" : "2024-12-11T18:00:00+00:00",
               "endAt" : "2024-12-11T19:00:00+00:00",
               "totalParticipants" : 403847,
               "rewardPerKwhInOctoPoints" : 480,
               "devEvent" : false,
               "targetGsp" : [ ],
               "status" : "DONE"
            }

[BottlecapDave]

I'm seeing the saving session in the attributes of octoplus_saving_session_events. The saving sessions are only refetched every 30 minutes and just reports whatever the API reports. I'm hoping the new API isn't too different so that the transition can be quick.

[gcoan]

I'm seeing the saving session in the attributes of octoplus_saving_session_events. The saving sessions are only refetched every 30 minutes and just reports whatever the API reports. I'm hoping the new API isn't too different so that the transition can be quick.

I'm seeing the event that was on 11th December now in the joined_events part of the events. I am pretty sure it wasn't in the list earlier, and it definitely wasn't in the available_events before the session - I could see it wasn't in the event list, and if it was, Predbat would have tried to auto-join it.

Maybe populating the API has only just started?
🤞for the next session

[deltamelter]

I'm seeing the saving session in the attributes of octoplus_saving_session_events. The saving sessions are only refetched every 30 minutes and just reports whatever the API reports. I'm hoping the new API isn't too different so that the transition can be quick.

I am still not seeing the event from December in my list. This is 13.2.1

[deltamelter]

Oh, this is just showing joined events? I thought it was the complete list of previous events as returned by

query savingsessions($accountNumber: String!){
  savingSessions(accountNumber:  $accountNumber) {
    account(accountNumber: $accountNumber) {
    events 
...

I didn't join the event on 11th.

[gcoan]

Oh, this is just showing joined events? I thought it was the complete list of previous events

its titled 'joined events' in my event sensor:

and the session (which I did join) is showing in the list:

Am sure it wasn't earlier.

I exported about 3kWh in the session, so £2 profit or so and the agile rates afterwards were not too bad

[deltamelter]

The lists have been reset and only show this season's events now.
so for mein the API, joined_events = [] and events list only shows the 1 event from 11th.
The integration is now just empty so there is no history to show and obviously no future events on the horizon.