Our first proper Home Assistant automation solved a very specific problem: a cheap daytime EV charging session could empty the Tesla Powerwall into the car.
The supplier intended the car to use discounted grid electricity. The Powerwall only saw a sudden household load of roughly 7kW and tried to support it.
The result was technically correct behaviour from every individual system and the wrong outcome for the home as a whole.
July 2026 update: this article documents the original Intelligent Octopus Go version. We have not yet rebuilt the automation for EDF. After changing supplier, we disabled the supplier-dependent actions that could now make the wrong decision. We will publish the redesigned and tested EDF version as a new article when that work is complete.
The problem
Our Powerwall normally powers the house from stored solar energy when generation is not enough.
During an ordinary household load, that is exactly what we want. During a supplier-managed cheap EV charging session, it can be wasteful.
A charging session through the Hypervolt Pro 3 can draw approximately 7kW. If the Powerwall responds normally, a large part of its usable capacity can move into the car within a relatively short period.
That leaves less stored energy for the expensive part of the day, even though the car could have been charged from discounted grid electricity.
The control idea
The Powerwall has a backup-reserve setting. Raising the reserve tells the battery to retain more of its stored energy rather than discharging it into the home.
Our original logic was:
- Detect that a smart EV charging session is active outside the normal overnight period.
- Record the Powerwall’s current state and usual reserve setting.
- Raise the reserve so the battery stops supporting the charger.
- Allow the car to continue charging under the supplier’s control.
- Restore the normal reserve after charging ends.
The automation did not stop or reschedule the car charge. It changed the behaviour of the battery around that charge.
Why this needed Home Assistant
The charger, tariff and Powerwall each understood their own part of the situation:
- the supplier knew the EV session was discounted
- the Hypervolt knew the car was charging
- the Powerwall knew the house had a large load
None of them independently understood the complete objective: charge the car cheaply without sacrificing the battery energy reserved for later.
Home Assistant provided the coordination layer.
The integrations involved
The original version used information from:
- the supplier integration, to identify an Intelligent Octopus dispatch
- the Hypervolt integration, to confirm charging state and power draw
- the Tesla energy integration, to read the Powerwall and change backup reserve
Integrations, authentication methods and entity names change. Use the current official documentation for each integration and avoid websites that ask you to submit account credentials or security tokens outside the provider’s normal authentication process.
That is one lesson I would state more strongly now than when we first built this.
Important safeguards
An automation that changes battery settings should not rely on a single optimistic trigger.
A more robust version should consider:
- whether charging power is genuinely present
- whether the session is inside a discounted period
- whether solar generation is already covering some or all of the charge
- the current battery state of charge
- the normal reserve value that must be restored
- what happens after a Home Assistant restart
- what happens if the supplier or charger entity becomes unavailable
- a maximum duration after which the automation safely resets
The restore step is as important as the initial action. Leaving the reserve at an unintended level could materially change how the battery serves the home.
A Powerwall limitation we encountered
Our original implementation could not always raise the reserve to the exact state of charge we wanted. At some battery levels, the control available through the integration imposed a lower ceiling.
That meant the battery could still discharge partially during some sessions.
The lesson was not to assume that a service call accepted by Home Assistant will produce unlimited control in the connected product. The manufacturer, firmware and integration may all impose constraints.
Did it work?
Yes. During the Octopus period, the automation successfully prevented or reduced unintended battery discharge during the daytime charging sessions it detected.
The car continued charging. The supplier remained in control of the schedule. The Powerwall retained more energy for the house.
That was exactly the outcome we wanted.
Our six-month solar and Powerwall results show the wider energy flows this automation was trying to protect, including the interaction between battery charging, EV demand, household use and export.
What we learned from building it
The automation logic was simpler than the surrounding work.
The time went into:
- installing and understanding integrations
- identifying reliable entities
- testing state changes
- handling unavailable data
- understanding the difference between a trigger, condition and action
- confirming that every temporary setting was restored
It also taught us to define the desired outcome before writing any YAML or clicking through the automation editor.
The useful sequence was:
- Describe the real-world problem in plain English.
- Identify which system knows each part of the situation.
- Decide which action changes the outcome without fighting the supplier.
- Add safeguards and recovery behaviour.
- Test with supervision before trusting it unattended.
AI helped us translate parts of that logic into Home Assistant configuration, but it did not replace testing or understanding the equipment being controlled.
Current status after moving to EDF
We have not yet redesigned this automation for EDF.
The original Octopus-specific entities and dispatch triggers no longer describe our current setup. Rather than allow old logic to keep changing the Powerwall under different tariff assumptions, we disabled the relevant supplier-dependent actions.
The replacement still needs to determine how to identify EDF-controlled charging using the information genuinely available from the Hypervolt, tariff times and any EDF data exposed to Home Assistant.
The economic assumptions have changed as well. Our current EDF export rate can make solar export more valuable than diverting every spare unit into the car.
A future version therefore needs to compare:
- discounted grid import
- the value of exported solar
- Powerwall state of charge
- expected household demand later in the day
- whether the car actually needs charging
The tariff reasoning is explained in Why we moved from Octopus to EDF.
We will document the redesign, testing and final behaviour in a separate article rather than quietly rewriting this historical account as though the new automation already exists.
Should other Powerwall owners copy this?
The problem is worth checking for, but the implementation must match the individual home.
A useful first test is to watch the Tesla app during an off-peak EV charging session. If the Powerwall begins discharging heavily into the car when discounted grid power should be available, there may be something to solve.
Do not copy old entity names, tokens or service calls blindly. Confirm the current behaviour of your charger, supplier tariff, battery firmware and Home Assistant integrations.
For us, this automation was valuable for more than the energy it protected. It showed what Home Assistant is best at: coordinating systems that work correctly on their own but do not understand one another. Our second example, using excess solar for hot water, applied the same principle to the heat pump and hot-water cylinder.