UK: Axle Grid Event Support

[WhatIsThisAllAboutSilly]

A company is paying people to use their batteries to stabilise the local grid when it's needed, paying £1/kWh. https://vpp.axle.energy/landing/grid

However, they take control of the battery via in my case, the FoxESS website.

However they do provide a REST API (https://vpp.axle.energy/landing/home-assistant) which provides:

ATTRIBUTE TYPE DESCRIPTION
start_time ISO 8601 datetime When the next grid event starts
end_time ISO 8601 datetime When the grid event ends
import_export string: "import" | "export" Whether to import from or export to the grid
updated_at ISO 8601 datetime When the event data was last updated

Predbat obviously needs to be aware of this to ensure that it knows that the battery during these periods will be charging/discharging at max rate.

Presumably the £1/kWh may change so I'm going to ask Axle if they could also as part of this API set a £/kWh rate so Predbat can use that as part of its calculations.

So I think the basic idea would be that predbat checks the entity with the axle event info in, and adds £1p to those slot(s).

Not sure how the charge slot thing would work, but lets start with having export functionality there..!

[gcoan]

I have joined the Axle scheme. I did wonder about a FR for Predbat to take account of this, but wondered if the number of users is quite small.

At the moment I have just created an automation to alert me to the event so I can see what happens and what notice I get.

Possible options then are:

• put predbat into read only mode so Axle can control the inverter
• put in some force exports to match the Axle plan
• put in a rate override so Predbat takes account of it in its plan

all of these can be done via automations without predbat enhancements so that was the way I was thinking of going for now.

Since we have given Axle control of our inverter they will send the remote commands to our inverter, as well as Predbat instructing it, so there is a potential for clash unless we put predbat into read only, but RO has to be done sufficiently far in advance for Axle to then take control.
So no perfect solution.

[Nilogax]

Any chance you could share what you've built @gcoan? First I've heard of Axle but it looks like it's worth further exploration.

Ah - ignore that! Just going through the signup and they've supplied config for the HA sensors - nice!

[gcoan]

No problem, if you want to sign up, here's my referral code https://vpp.axle.energy/landing/grid?ref=R-VNNIZUYO - we both get a bonus

What I have at the moment is:

1. A REST sensor in configuration.yaml to capture Axle events:

  # Axle VPP import/export event details
  - platform: rest
    name: Axle Event
    resource: https://api.axle.energy/vpp/home-assistant/event
    scan_interval: 600
    headers:
      Authorization: "XXXX"
    json_attributes:
      - start_time
      - end_time
      - import_export
      - updated_at
    value_template: >-
      {% if value_json is defined and value_json.start_time is defined %}
        {{ value_json.start_time }}
      {% else %}
        {{ none }}
      {% endif %}

2. An extension of my existing alert for saving session and free electricity events:

alias: Octopus/Axle New Alert
description: Alert when new Octopus Power up, Free Electricity or Axle VPP event
triggers:
  - trigger: state
    entity_id:
      - sensor.octopus_free_electricity_times
    from: "[{\"start\":null,\"end\":null}]"
    variables:
      alert_title: Octopus Electricity session
      alert_text: New Free Electricity times
      date: >-
        {% set dt=state_attr('sensor.octopus_free_electricity_times','start') %}
        {% if dt != None %}
          {{ as_timestamp(dt)|timestamp_custom('%a %-I:%M %p') }}
        {% else %}
          unknown date
        {% endif %}
  - trigger: state
    entity_id:
      - sensor.octopus_power_up_times
    from: "[{\"start\":null,\"end\":null}]"
    variables:
      alert_title: Octopus Electricity session
      alert_text: New Power up electricity times
      date: >-
        {% set dt=state_attr('sensor.octopus_power_up_times','start') %} {% if
        dt != None %}
          {{ as_timestamp(dt)|timestamp_custom('%a %-I:%M %p') }}
        {% else %}
          unknown date
        {% endif %}
  - trigger: state
    entity_id:
      - sensor.axle_event
    variables:
      alert_title: Axle session
      date: >-
        {% set dt=state_attr('sensor.axle_event','start_time') %} {% if dt !=
        None %}
          {{ as_timestamp(dt)|timestamp_custom('%a %-I:%M %p') }}
        {% else %}
          unknown date
        {% endif %}
      session_type: >-
        {% set st=state_attr('sensor.axle_event','import_export') %} {% if st !=
        None %}
          {{ st }}
        {% else %}
          unknown session
        {% endif %}
      alert_text: New Axle VPP {{ session_type }} event
conditions:
  - condition: template
    value_template: "{{ date }} <> \"unknown date\""
actions:
  - data:
      title: "{{ alert_title }}"
      message: "INFO: {{ alert_text }} starting at {{ date }}"
      url: /dashboard-givenergy/powerup
    action: script.notify_all_devices
mode: single

Once I get an event I will then look at how best to handle it, probably an automation to set Predbat price overrides will be best

It's been suggested that its when the spot day ahead auction price exceeds £1 that Axle can offer a VPP activity:

https://www.epexspot.com/en/market-results?market_area=GB&auction=30-call-GB&trading_date=2025-12-09&delivery_date=2025-12-10&underlying_year=&modality=Auction&sub_modality=DayAhead&technology=&data_mode=graph&period=&production_period=

[Nilogax]

Thanks - and sorry I jumped too soon for the referral code 😞

[gcoan]

Here's the automation I have written to send Axle VPP export events into Predbat. Last line sends a mobile alert to me, so omit that or replace with a call to notify.devicename

The code includes rounding Axle session start and end times to a 30 minute boundary - I think that's not needed, but to be sure, to be sure

Converts the Axle start and end times to 30 minute predbat slot times

Only handles export events, not import and will handle sessions up to 48 hours in advance

Tested so far with dummy data, need to see Axle REST for real to confirm it 100%

alias: Axle VPP export
description: Set Predbat Manual Discharge for Axle VPP
triggers:
  - entity_id: sensor.axle_event
    trigger: state
conditions:
  - condition: template
    value_template: "{{ import_export == 'export' }}"
  - condition: template
    value_template: "{{ start_dt is not none and end_dt is not none and end_dt > start_dt }}"
actions:
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ start_dt is none or end_dt is none or end_dt <= start_dt }}"
        sequence:
          - data:
              message: >
                Axle session skipped: start_time or end_time missing/invalid.
                start_dt={{ start_dt }}, end_dt={{ end_dt }}
              level: warning
            action: system_log.write
    default:
      - alias: Round start to nearest 30 min
        variables:
          start_rounded: >
            {{ start_dt.replace(minute=(start_dt.minute // 30) * 30, second=0,
            microsecond=0) }}
      - alias: Round end to nearest 30 min
        variables:
          end_rounded: >
            {% set end_minute = ((end_dt.minute + 29) // 30) * 30 %} {% set
            new_hour = end_dt.hour + (end_minute // 60) %} {{
            end_dt.replace(hour=new_hour, minute=end_minute % 60, second=0,
            microsecond=0) }}
      - alias: Generate slots
        variables:
          slot_count: "{{ ((end_rounded - start_rounded).total_seconds() // 1800) | int }}"
          slots: |
            {% set ns = namespace(slots=[]) %} {% for i in range(slot_count) %}
              {% set slot_time = start_rounded + timedelta(minutes=30*i) %}
              {% set ns.slots = ns.slots + [slot_time.strftime('%a %H:%M')] %}
            {% endfor %} {{ ns.slots }}
      - alias: Set Predbat Manual Discharge
        target:
          entity_id:
            - select.predbat_manual_export
        data:
          option: "{{ slots | join(',') }}"
        action: select.select_option
      - alias: Debug log
        data:
          message: >
            Axle session detected: Original Start: {{ start_dt }}, Original End:
            {{ end_dt }}, Rounded Start: {{ start_rounded }}, Rounded End: {{
            end_rounded }}, Slot count: {{ slot_count }}, Slot list sent to
            predbat: {{ slots | join(',') }}
          level: info
        action: system_log.write
      - action: script.notify_all_devices
        metadata: {}
        data:
          title: “Axle Export Session "
          critical: "N"
          url: " /dashboard-givenergy/plan"
          message: From {{ start_dt }} to {{ end_dt }}
variables:
  start_dt: "{{ state_attr('sensor.axle_event','start_time') | as_datetime | as_local }}"
  end_dt: "{{ state_attr('sensor.axle_event','end_time') | as_datetime | as_local }}"
  import_export: "{{ state_attr('sensor.axle_event','import_export') }}"
mode: single

[LeeFarm11]

Hi @gcoan I signed up with your link late this morning. I've set it to use full automation. I have very little confidence that it will successfully control the 3 phase Inverter, but never say never.

I guess I won't be able to monitor anything until just after midnight when in theory I will be able to see actions in 'Remote Control'. Is that also your understanding? Thanks

[gcoan]

Thanks @LeeFarm11

I would imagine Axle programs your inverter for the day ahead based upon when your rates and grid demand is known, so things should start appearing sooner than midnight; if only to take advantage of any cheap overnight grid charging.

Be interesting to see what Axle do in full automation mode. I opted for events only to wrap them into Predbat

[Nilogax]

There's now a HACS integration to retrieve Axle VPP event info into sensors. Haven't explored it yet to see what benefits it has over the YAML setup option.

https://github.com/deanhalllincoln/ha-axle-vpp

[gcoan]

There's now a HACS integration to retrieve Axle VPP event info into sensors. Haven't explored it yet to see what benefits it has over the YAML setup option.

https://github.com/deanhalllincoln/ha-axle-vpp

Yes I found the HACS integration when trying to find the Axle VPP website again.

As far as I could see it offered no advantages over the REST entry in configuration.yaml. I suppose for people who are less familiar with HA and don't want to edit the config file then that could be useful, but if you want this data in HA then you're likely to be experienced enough to write automations with it.

And on the converse, it's another integration being added to HA from a third party versus the out of the box HA option so to me that feels like a disadvantage?

Anyway, always good to have options

[LeeFarm11]

I've now been up and running with Axle account for more than 24 hours.

However - Nothing has happened to my Inverter. No commands from Axle.

In the HACS integration notes there is mention of getting an API token from Axle, but I cannot find any way to get one in my Axle account. All I can do is modify my tarrifs, view payments, or switch between full automation and events only automation.

I have emailed axle regarding lack of activity at the Inverter but no response yet.

[gcoan]

For me, its under account settings:

then Home Assistant and you get the option to generate a token

View setup instructions takes you to the page that describes how to setup the REST sensor in configuration.yaml using the Axle token (or use the HACS integration)

[LeeFarm11]

Ah. Found it. The Home Assistant box only appears with 'Events Only' selected. If 'Fully Managed Optimisation' is selected, the Home Assistant box does not appear. Makes sense I suppose.
Thanks.

[LeeFarm11]

I have very little confidence that it will successfully control the 3 phase Inverter, but never say never.

I have received a response from Axle which is very good. Much quicker response than from GivEnergy.

But as expected they are currently unable to control my inverter -

"we are having issues setting schedules on your inverter.
In particular, it seems we are unable to set eco-mode - this is causing our dispatches to fail. Are you able to set eco-mode as a preset in your GivEnergy app ? "

As you probably recall, 3 phase inverters do not use 'modes'. Hence why GivTCP and Predbat don't work properly. I will try to work with Axle to try to help them understand how to control the 3 phase inverter.....

In the meantime they proposed I switch to events-only mode, but I strongly suspect that that would not work either.