HI Ian
I was wondering if I could pick your brain about your automations using the Poervault integration - I have got a few set up but have found that, looking back at the device history, when I ask it to change charge status it does so but reverts back within 30s (never having actually changed status). Same happens when I use the drop down menu that is available on the status in the device details. ie I request it to go from normal to force-charge, and it sits there for 20 secs or so, then just pops back to normal.
Do I need to specify a time I need it to go there for?
Many thanks for any light you can shed!
Hi Luke, do you have a Pwowervault 3 by any chance? When I had one, the web portal only showed SOC in bands of 20%, and I only got API access after I moved to a Powervault 4, so unfortunately I don’t know if the API is any more specific for a P3.
Hi Andy,
I don’t think I have had that problem. I don’t believe I have used the drop-down picker to change status, I have only really changed the status by using the restful command option, which I tested using the Developer Tools. I may have been missing the “right” way of using the Integration, but this has worked for me. Let me know if you are interested in the Restful command option, and I’ll happily share some details, although I am away at the moment and the VPN isn’t playing ball on the laptop so screen shots could be a challenge until I can resolve that!
Many thanks Ian, that would be a huge help.
I’ve never used restful, so will go and investigate that in the meantime.
Looking forward to hearing more when you get back into comms!
Cheers and thanks for the help
Andy
Hi Andy,
Apologies I didn’t get any notification that you had replied. I’ve got home today and found my HA Supervisor tried to update whilst I was away and failed, and re-trying the update manually as per the recommendation has broken it so now HA won’t start, hence me coming back to the forum! I’ll need to fix this first, then will describe my setup.
Thanks Ian, much appreciated. Looking forward to it.
Hi Andy, sorry again for the delay in responding. Before explaining how I have been managing my Powervault 4, I tested the method that I thinkk you are using, to see if I can repeat the isue you are having, and I am sorry to say I couldn’t.
Here is what I did - I still have the “Overview” Dashboard which contains all of the integrations I have added in HA, and it includes the drop-down pick-list for setting the status of the P4.
It was in Normal mode, and I selected Only-Charge from the list, and wateched and it remained in Only-Charge state. When I looked at the Powervault portal, it displayed an Only-charge override status, which would last for a day. I left it like this for at least 2 minutes, and the Powervault portal continued to show the override, and the HA drop-down pick-list also showed it was in Only-Charge.
I then updated the HA pick list and selected Normal mode and immediatley switched to the Powervault portal, and it took about 8 seconds before the portal updated to show “Normal Override” which also ends in a day.
I appreciate this is not working for you, but thought I would share in case you can see any difference.
Have you tried using the over-ride buttons in the Powervault portal, just to prove that you can change the status of your P4 ? That thought makes me wonder if there are two types of users for the portal, i.e. an admin level and a read only level, where the read-only user can view but not set the over-rides? I don’t know of such an option, but I have exactly that functionality on our ZEB heat battery so maybe Powervault has that ability too?
I’ll create another reply to include how I have been controling my P4
Hi Andy, As above, here is how I have been managing my P4…
I previously had a P3 since 2019, and was frustrated that I couldn’t control it through software. I didn’t trust the Powervault Smartstor function, because when I originally tried it, although it would charge the P3, if I had the EV plugged in and charging, the P3 just saw that as a household load, and drained the P3 to charge the EV. At that time, Powervault didn’t have a solution so I gave up on Smartstor and manually set the schedule in the Powervault portal every day. As you will remember, the P3 SOC was shown in bands of 20%, which made for a lot of guess work trying to decide how much to charge. After 5 years and various hardware problems Powervault eventually agreed to swap the P3 for a P4 which shows a detailed SOC and like you, I wangled the API access for free. Somehow I managed to miss the existing HA integration for Powervault, but having dabbled with a few AP’s, I was happy to have a go.
I had previously developed a Python script (outside of HA) that could retrieve the SOC from Powervault, using the Powervault API documentation , and then calculated how much charge to add, but simply sent the results to me in an email for manual action. So I tried to use this script from within HA, but learned that the Python requests module (that does the HTTP stuff) wasn’t supported from within a HA script, so I looked for a way within HA to ‘just call an API’.
This lead me to the RESTful command, which took a lot of trial and error, but I eventually got it working to retrieve the status of my P4. As the guide states, you have to create a section in your configuration.yaml file that contains all the important stuff, and then you can ‘call’ that from an automation (or script).
This was my API to query the current status:
> # Powervault: Get the override status via Powervault API
> rest_command:
> powervault_get_override_status:
> url: "https://api.p3.powervault.co.uk/v3/unit/P3-XXXX/stateOverride"
> method: get
> timeout: 60
> headers:
> User-Agent: "Home Assistant"
> x-api-key: !secret powervault # ony way I could get API key to work was using the secret file
> Content-Type: application/json
So this is creating a command / function called “powervault_get_override_status” that can be called from elsewhere, obviously the name is free-format.
The url line contains the ID of my Powervault (which I have redacted) and issues the ‘stateOverride’ command to retrieve the current charging state. (Powervault also re-used the same unit ID even though I now have a P4).
I think I changed the timeout to 60 as it once took a while to respond.
The headers section was a challenge. I chose to set a User-Agent of “Home Assistant” although I think it worked fine with whatever the default was (don’t quote me!). The x-api-key was the biggest pain, as the RESTful documentation didn’t mention how to use x-api. I found that for the GET operation, I could specify the API key within the header in the YAML, but I could not get this to work for a PUT operation to actually set the status. of the battery. Instead I found that moving the API key into the Secrets file, and referencing it within the YAML worked. I am sure this was down to my primitive coding / HA skills, but once I got it working, I haven’t felt the desire to change, and it’s probably better having the key in a secrets file anyway.
Initially I specified the new charge status in the YAML, and then worked out how to use templates so I can pass the desired status as a parameter from within Developer Tools, and eventually from an automation.
Rightly or wrongly, and probably influenced by what I saw in the Powervault API documentaton, I decided to include a start time and end time when setting the Powervault to a force charge, so I needed to include those two parameters as well.
The entry in Configuration.yaml to set the status looks like this:
# Powervault: Set the override status via Powervault API
# Set an override of the schedule
# Requires a start date, end date, and status to be passed when calling this function
# status can be: only-charge, force-charge, only-discharge, force-discharge, normal or disable
# status must be set by the action that is calling this function
powervault_set_override_status:
url: "https://api.p3.powervault.co.uk/v3/unit/P3-XXXX/stateOverride"
method: post
timeout: 60
headers:
x-api-key: !secret powervault # ony way I could get API key to work was using the secret file
accept: "application/json"
# content_type: 'application/json; charset=utf-8'
payload: '{
"stateOverrides": [
{
"start": "{{ start_time }}",
"end": "{{ end_time }}",
"state": "{{ new_state }}"
}
]
}'
And then I can ‘call’ this command either from Developer Tools:
action: rest_command.powervault_set_override_status
data:
new_state: only-charge
start_time: "2025-03-06 04:00:00"
end_time: "2025-03-06 07:00:00"
And finally from within an automation that is triggered to run at a set time:
action: rest_command.powervault_set_override_status
alias: >-
added continue_on_error after a timeout failure on API call that meant the
email notification did not run.
continue_on_error: true
data:
new_state: "{{override_new_status}}"
start_time: "{{start_time}}"
end_time: "{{end_time}}"
response_variable: override_response
enabled: true
Some of the lessons I learned:
- As the restful command is stored in configuration.yaml, each tweak meant reloading the YAML via Developer Tools, but sometimes this didn’t work, and my updates were not re-loaded, so then I had to restart HA.
- The Powervault API only uses UTC timing, so you need to account for clock changes. I just changed my script manually, and as clocks only twice per year, I suspect this will stay on my to-do list for a while!
- I probably should have ignored setting the start and end time, and just had two automations, one to start the force-charge, and another to go back to normal status, once I work out how to schedule the 2nd automation to run at a time that would vary each day based on PV energy etc
Sorry for the long post, I hope this makes sense - let me know if you have any questions.
Good Luck
Ian
That’s brilliant Ian, thanks so much for your time!
Yes, when I use the override in the portal it does work fine for the requested time, but when I use the drop down picker in HA it lasts about 30s and reverts to whatever it was before.
Can I ask are you running a manual schedule? I have tried mine in all sorts of modes assuming it was overriding the status change, but nothing seems to make a difference.
Did you have to activate or give some permission when you started using the API?
I have made a few automations that do exactly as your are suggesting, one to start the force charge and one to go back to normal once it has reached the desired percentage of charge (based on the solar forecast integration). It does work, according to the state history, even if it is for only 30s or so!
I have just left on a fortnight holiday, but this is cracking information to get stuck into when I return. As soon as I’m back I’ll have a go and report back.
Thanks again!
HI Ian just home from holiday and going to get stuck in to your kind advice now. Just tinkering there though, and after an update to the integration it all seems to be working! I can select from the status pull down menu and it now sticks rather than instantly reverting. Nothing else changed, so whatever was in that update seems to have done the trick. I’ll still be looking through your examples though, so huge thanks again for your time on this, much appreciated.
Cheers, Andy
Hi Andy, glad to hear it’s working.
Hi Adam
with all the recent Octopus Free Electricity session I changed how I control my P4 to charge during the free session. I moved away from a manual schedule using the Powervault portal, and looked at using this Integration to put the P4 into force-charge mode, which works perfectly.
At the end of the free electricty session I used the “Change Powervault Charge Status to previous option” to switch it back, but on the two occassions I used it, the P4 did not switch back to Normal status. First time it was switched to only-charge, and today it was switched to only-discharge. I do not have the “cycle” box ticked.
Is this what you would expect?
There is another free session tomorrow, so I can enable debug if you want (although the session is 2 hours so I guess the log will be pretty big, and I can trim it down).
Ian
Hi @adammcdonagh,
The two hours of free electricity have just finished, and at the end it changed status to ‘only-discharge’ mode just like yesterday. I manually changed it back to Normal. I did capture a debug log, but there isn’t anything in it in terms of additional messages relating to the “Change Powervault Charge Status to previous option” action. I can upload if you would like.
I will update my automation and use the option to set to a specific status (Normal) at the end of the free electricity session, which will hopefully work just as reliably as it does when it switches to force-charge at the start of the session.
Hi all,
I’m trying to follow the thread but it’s a little tricky since I’m not in the weeds if it right now.
I’m thinking about investing in some of these batteries. I’m wondering to what extent this integration works?
Thanks in advance and to the people developing this!
@blingblongblah
Hi, sorry I don’t monitor this… I really should though…
Anyway the integration lets you take full control of the battery state. It also pulls down all of the energy metrics in realtime for you to visualise on your dashboard.
Shane from PowerVault is aware of this integration now, so hopefully they have said about it being compatible.
Let me know if you have any more questions
@Ian_D1
Hey, sorry for my delay in coming back. Probably best off asking questions on my GitHub via issue if you want to guarantee I’ll see something.
Anyway, I’m not sure what you’re referring to regarding “Change Powervault Charge Status to previous option”. I don’t know of anything like that, and in my automations I only ever explicitly set the battery state.
Here’s some details about my own config for anyone that’s interested
Sorry for the spam…
As mentioned above, here’s a post explaining my current setup.
Be aware that I use EMHASS. This is primarily for forecasting solar generation, but it also knows about the off-peak periods for Octopus. This is called every few minutes to refresh it’s forecast. I then have templated variables that feed off of the forecast inserted by EMHASS populated a “desired state” and a forecast for the next 24hrs.
This is my Power dashboard:
The graphs are as follows:
- Power Flow Card Plus integration to give me the realtime status.
- Battery Schedule - Derived using the schedule from EMHASS plus any overrides that my templating adds
- Battery - This is the state of charge forecast along with the actual value since midnight
- EMHASS Daily Forecast - Visualises the power allocation for the rest of the day, as well as showing the actual values once the time has passed
- PV Generation - Pretty obvious, reads the forecast and shows actual generation
- Solar Generation - This isn’t much use, it just shows the numbers for solar.
- Power Usage - This is a replica of the graph in the powervault portal showing where the power has been sent throughout the day
Templates:
Battery State Forecast
This is the core logic that is used to set the state of the battery. It doesn’t take into account Octopus free sessions, that is controlled in the automation. As such this can probably be improved to pull the logic into this template, but it’s complex enough as is.
I have hardcoded the off-peak hours as 23:30 to 05:30 and set a variable called off_peak to be used later on.
First I look at the EMHASS forecast (the value_template block determines the realtime values, and the attribute_templates -> forecast are used for showing the forecast for the day). If EMHASS is showing the p_batt_forecast (the power that should be going to the battery as negative - i.e it’s expecting to be charging), and p_pv_forecast (solar production is not currently expected, and it’s off peak, then set Grid Charge as the desired state.
Then, I look at the solar schedule, sometimes EMHASS is a little too conservative with it’s predictions. If I the solar prediction is less than 8.5KWh for the day, and it’s off peak, then also set Grid Charge
Also, if the battery is currently below 50% charge, and the forecast is less than 9KWh, and it’s off peak, set Grid Charge
Now, if the battery is not being asked to charge, yet EMHASS shows we should be pulling from the grid, and it’s off-peak, we set the battery to Grid Import. This is primarily during the summer when the battery will either get charged enough during the day, or has is already charged enough and the end of the day.
EMHASS has predicted that the battery can be used (most likely to take most advantage of the sun to charge the battery the next day), it will show p_batt_forecast as a positive value. If this happens during off peak hours, I set the battery to Normal rather than pulling from the grid.
Next is Grid Export, which is actually ignore in my automation, but, if EMHASS shows the p_grid_forecast as a negative number, as well as the battery forecast, then it’s suggesting the battery should be force discharged. Here we set Grid Export state.
If the grid forecast is negative and the pv forecast is positive, then the battery is at a suitable level, so we can set the battery to Discharge Only, so any excess solar gets sent to the grid.
Finally, as a catch all, if the battery state isn’t manually set to Grid Charge, then we just set it to Normal
Then there’s condition around the EV to stop the battery from draining the car. My CT clamps are not set up in a way that the Powervault would not see the EV charging, as such I have to handle it in the automation - as I have the Ohme integration.
If the EV is showing as currently charging and the battery isn’t being asked to charge, then set the desired state to Grid Import. Adding - EV allows me to differentiate in the automation if I need to.
Here’s all the YML that defines that. (some of the comments might not match exactly to what I said above).
battery_state_forecast:
unique_id: battery_state_forecast
friendly_name: "Battery State Forecast"
value_template: >-
{# Battery forecast to charge and PV is not charging #}
{%- set override = "None" %}
{%- set battery_state = "Normal" %}
{%- set battery_soc = states('sensor.powervault_charge') | float(0) %}
{%- set ev_charging = True if states('input_boolean.ev_charging') == "on" else False %}
{%- set current_hour = now().hour %}
{%- set current_min = now().minute %}
{% set off_peak = 0 %}
{%- if current_hour < 5 or (current_hour == 5 and current_min < 30) %}
{% set off_peak = 1 %}
{%- endif %}
{%- if current_hour == 23 and current_min >= 30 %}
{% set off_peak = 1 %}
{%- endif %}
{% if states("sensor.p_batt_forecast")|float(0) < 0
and states("sensor.p_pv_forecast")|float(0) <= 0
and off_peak
%}
{%- set battery_state = "Grid Charge" %}
{% endif %}
{# if its offpeak and the predicted solar for today is < 5KWh, then force charge #}
{% if off_peak and states("sensor.emhass_pv_forecast_24hrs")|float(0)*1000 <= 8500 %}
{%- set battery_state = "Grid Charge" %}
{# else if its offpeak and the battery is < 50% and the prediction is < 6kwH, then force charge #}
{% elif off_peak and states("sensor.powervault_charge")|float(0) < 50 and states("sensor.emhass_pv_forecast_24hrs")|float(0)*1000 < 9000 %}
{%- set battery_state = "Grid Charge" %}
{% elif off_peak and states("sensor.p_grid_forecast")|float(0) > 100 and battery_state != "Grid Charge" %}
{%- set battery_state = "Grid Import" %}
{% elif off_peak and states("sensor.p_batt_forecast")|float(0) > 0 %}
{%- set battery_state = "Normal" %}
{% elif states("sensor.p_grid_forecast")|float(0) < -400 and states("sensor.p_batt_forecast")|float(0) > 400 %}
{%- set battery_state = "Grid Export" %}
{% elif states("sensor.p_grid_forecast")|float(0) < -500 and states("sensor.p_pv_forecast")|float(0) > 500 %}
{%- set battery_state = "Discharge Only" %}
{% elif battery_state != "Grid Charge" %}
{%- set battery_state = "Normal" %}
{% endif %}
{# ############ #}
{# This prevents the battery from charging the car #}
{# ############ #}
{% if ev_charging and battery_state != "Grid Charge" %}
{%- set battery_state = "Grid Import - EV" %}
{% endif %}
{% if not off_peak and battery_state == "Grid Import" %}
{%- set battery_state = "Normal" %}
{% endif %}
{{ battery_state }}
attribute_templates:
forecast: >-
{%- set battery_forecast = state_attr('sensor.p_batt_forecast', 'battery_scheduled_power') | map(attribute='p_batt_forecast') | list %}
{%- set pv_forecast = state_attr('sensor.p_pv_forecast', 'forecasts') | map(attribute='p_pv_forecast') | list %}
{%- set grid_forecast = state_attr('sensor.p_grid_forecast', 'forecasts') | map(attribute='p_grid_forecast') | list %}
{%- set time_vals = state_attr('sensor.p_pv_forecast', 'forecasts') | map(attribute='date') | list %}
{%- set solar_forecast_total_kwh = states("sensor.emhass_pv_forecast_24hrs") | float(0) * 1000 %}
{%- set battery_percentage_forecast = state_attr('sensor.soc_batt_forecast', 'battery_scheduled_soc') | map(attribute='soc_batt_forecast') | list %}
{%- set values_all = namespace(all=[]) %}
{% for i in range(battery_forecast | length) %}
{%- set battery_w = battery_forecast[i] | int(0) %}
{%- set grid_w = grid_forecast[i] | int(0) %}
{%- set pv_w = pv_forecast[i] | int(0) %}
{%- set date_ = time_vals[i][11:16] %}
{#- set off peak variable #}
{%- if date_ >= '23:30' or date_ < '05:30' -%}
{%- set off_peak = 1 -%}
{%- else -%}
{%- set off_peak = 0 -%}
{%- endif -%}
{%- set grid_charging = 0 -%}
{%- set normal = 0 %}
{%- set grid_import_only = 0 %}
{%- set grid_export_only = 0 %}
{%- set discharge_only = 0 %}
{#- if EMHASS prediction says battery should be negative watts, then show as charging #}
{%- if battery_w|float < 0
and pv_w|float <= 0 %}
{%- set v="Grid Charge" %}
{%- set grid_charging = 1 %}
{%- set grid_import_only = 0 %}
{%- set grid_export_only = 0 %}
{%- set discharge_only = 0 %}
{%- endif %}
{#- if the solar from today is < 8.5KWh, then force charge #}
{%- if off_peak and solar_forecast_total_kwh < 8500 -%}
{%- set v="Grid Charge" %}
{%- set grid_charging = 1 %}
{#- if its offpeak and the battery % is below 50% or the solar from today is < 9KWh, then force charge #}
{%- elif off_peak and (battery_percentage_forecast[i]|float(0) < 50 and solar_forecast_total_kwh < 9000) %}
{%- set v="Grid Charge" %}
{%- set grid_charging = 1 %}
{#- else if its offpeak and its showing usage from the grid, then just pull from grid #}
{%- elif off_peak and grid_w|float(0) > 100 and not grid_charging %}
{%- set v="Grid Import" %}
{%- set grid_import_only = 1 %}
{%- set grid_charging = 0 %}
{#- else if its offpeak and battery watts is positive, then show as normal #}
{%- elif off_peak and battery_w|float(0) > 0 %}
{%- set v="Normal" %}
{%- set normal = 1 %}
{#- else if the grid is negative and the battery is positive, then show as grid export #}
{%- elif grid_w|float(0) < -400 and battery_w|float(0) > 400 %}
{%- set v="Grid Export" %}
{%- set grid_export_only = 1 %}
{#- else if the grid is negative and the battery is positive, then show as discharge only #}
{%- elif grid_w|float(0) < -500 and pv_w|float(0) > 500 %}
{%- set v="Discharge Only" %}
{%- set discharge_only = 1 %}
{#- otherwise battery is normal state #}
{%- elif not grid_charging and not grid_import_only %}
{%- set v="Normal" %}
{%- set normal = 1 %}
{% endif %}
{# {{ date_ }}, {{ off_peak }}, Battery {{ battery_w }}, Grid {{ grid_w }}, {{ v }} #}
{%- set v={"date": time_vals[i], "battery_state": v, "grid_charging": grid_charging, "normal": normal, "grid_import_only": grid_import_only, "grid_export_only": grid_export_only, "discharge_only": discharge_only} %}
{%- set values_all.all = values_all.all + [ v ] %}
{%- endfor %} {{ (values_all.all)[:48] }}}
Battery State Change automation
This is where the battery actually gets set to the various states by setting the select.powervault_charge_status entity to the desired value. There’s a lot of logic around it, and this is where I force charging if there is a free electricity session. Like above it could probably be streamlined, but it’s working and I don’t want to break it 
It triggers whenever the templated forecast variable changes due to some change from EMHASS, if the car starts charging (which is a simple check whether the Ohme is pulling > 500W), or if the free session calendar event starts or ends.
I won’t go into detail about this, as I think if you import it into HA then it’s readable and you can follow the logic. There’s obviously specifics to my situation, e.g, if the car is charging (e.g. in the middle of the day) and there’s not already a forecast planned, and if the battery is low already, then take advantage of the cheaper power and also charge the house battery.
alias: Battery State Change
description: Updates the battery status based on the sensor.battery_state_forecast entity
triggers:
- entity_id:
- sensor.battery_state_forecast
trigger: state
- entity_id:
- input_boolean.ev_charging
trigger: state
- trigger: state
entity_id:
- sensor.powervault_charge
- trigger: state
entity_id:
- calendar.octopus_energy_a_31ba3b35_octoplus_free_electricity_session
conditions: []
actions:
- choose:
- conditions:
- condition: state
entity_id: >-
calendar.octopus_energy_a_31ba3b35_octoplus_free_electricity_session
state: "on"
sequence:
- device_id: 08c1c3078ac9c9cf417a466cb4b39950
domain: select
entity_id: select.powervault_charge_status
type: select_option
option: force-charge
- conditions:
- condition: or
conditions:
- condition: state
entity_id: sensor.battery_state_forecast
state: Grid Import - EV
- condition: state
entity_id: sensor.battery_state_forecast
state: Grid Import
sequence:
- choose:
- conditions:
- condition: or
conditions:
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.powervault_charge
below: 50
- condition: time
after: "23:00:00"
- condition: numeric_state
entity_id: sensor.total_kwh_forecast_tomorrow
below: 8.5
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.powervault_charge
below: 80
- condition: numeric_state
entity_id: sensor.total_pv_estimate
below: 8.5
- condition: time
before: "20:00:00"
sequence:
- device_id: 08c1c3078ac9c9cf417a466cb4b39950
domain: select
entity_id: select.powervault_charge_status
type: select_option
option: force-charge
- conditions:
- condition: numeric_state
entity_id: sensor.powervault_charge
below: 100
- condition: numeric_state
entity_id: sensor.energy_production_today
below: 3
sequence:
- device_id: 08c1c3078ac9c9cf417a466cb4b39950
domain: select
entity_id: select.powervault_charge_status
type: select_option
option: force-charge
default:
- device_id: 08c1c3078ac9c9cf417a466cb4b39950
domain: select
entity_id: select.powervault_charge_status
type: select_option
option: only-charge
- conditions:
- condition: or
conditions:
- condition: state
entity_id: sensor.battery_state_forecast
state: Discharge Only
sequence:
- device_id: 08c1c3078ac9c9cf417a466cb4b39950
domain: select
entity_id: select.powervault_charge_status
type: select_option
option: only-discharge
- conditions:
- condition: or
conditions:
- condition: state
entity_id: sensor.battery_state_forecast
state: Normal
sequence:
- device_id: 08c1c3078ac9c9cf417a466cb4b39950
domain: select
entity_id: select.powervault_charge_status
type: select_option
option: normal
- conditions:
- condition: or
conditions:
- condition: state
entity_id: sensor.battery_state_forecast
state: Grid Charge
sequence:
- device_id: 08c1c3078ac9c9cf417a466cb4b39950
domain: select
entity_id: select.powervault_charge_status
type: select_option
option: force-charge
- conditions:
- condition: or
conditions:
- condition: state
entity_id: sensor.battery_state_forecast
state: Grid Export
sequence:
- device_id: 08c1c3078ac9c9cf417a466cb4b39950
domain: select
entity_id: select.powervault_charge_status
type: select_option
option: force-discharge
mode: queued
max: 10
There’s obviously a lot of info there, so if you have any questions, please feel free to ask and I’ll help if I can.
Adam
Thanks for your response. This is what I was referring to… I have an automation that sets the Powervault to force-charge when “binary_sensor.octopus_energy_a_xxxxxx_octoplus_free_electricity_session” changes to On, at
the start of an Octopus free electricity session, and needed another automation to change it back when the status is changed to Off. I used the Powervault integration in the GUI to change the status, and noticed there is an option called “Change Powervault Charge Status to previous option”, as shown in this screenshot, and below is the YAML.
device_id: xxxxxxx
domain: select
entity_id: 6f1b9aa19c54497ea3ce3f22636e6097
type: select_previous
I assumed this was something you had created as part of the integration? This is the list of options that appear:
If these options are not part of your integration and just part of HA, then I apologise for the confusion.
Thanks for all your work on developing this integration, and for sharing the above images and explanation, it gives me lots to think about that I could add to my setup!
Ian
Hi, no worries. I think that’s just part of HA, It’s not something I added
Just found out that Powervault has gone into administration. Has anyone been in contact with them in the past couple of weeks?
I wonder what this means for the future of the battery and the API. I guess we can pray for local control, but feels unlikely