Our second Home Assistant automation used spare solar generation to boost the domestic hot-water cylinder after the Powerwall was full.
At the time, we were still waiting for an export MPAN and received nothing for electricity sent to the grid. Diverting genuine surplus into hot water therefore had an obvious value.
The automation worked as a practical exercise in coordinating the solar array and Tesla Powerwall 3 with a Mitsubishi Ecodan heat pump.
July 2026 update: we now receive 24p per kWh for exported solar through EDF Export Exclusive. Export is no longer waste. We have not yet rebuilt this automation around the new economics; instead, we disabled the relevant boost actions so the old logic cannot keep making a decision that may now be financially wrong. The redesigned version will be covered in a new article after it has been built and tested.
The original problem
Our energy flow follows a natural order:
- Solar powers the house.
- Remaining solar charges the Powerwall.
- Any further surplus is exported.
Before the export account was active, that final step produced no income.
The Mitsubishi Ecodan already heated a domestic hot-water cylinder on a schedule. We wanted Home Assistant to trigger an additional hot-water boost only when solar was genuinely surplus, rather than importing electricity later to heat the same water.
Our later six-month solar and Powerwall data shows how much of the system’s spring generation ultimately went to the home, battery and grid.
What Home Assistant could see
The automation combined information from the Tesla energy system and MELCloud.
Home Assistant could monitor:
- current solar generation
- Powerwall state of charge
- grid import or export
- hot-water operating mode
- cylinder temperature
- whether a previous boost had recently ended
MELCloud also exposed the command needed to switch the system into a forced hot-water mode and then return it to normal operation.
The original trigger logic
We deliberately made the start conditions cautious.
The automation could begin a boost when:
- the Powerwall was at least 98% charged
- solar generation remained above 1,500W for five minutes
- the home was exporting electricity
- the hot-water system was not already boosting
- the cylinder temperature was below the chosen skip threshold
- the cooldown timer was not active
The temperature check prevented a boost when the cylinder was already at or above approximately 48°C.
Stop logic and hysteresis
Solar output changes quickly as clouds pass.
If the same threshold were used for starting and stopping, the heat pump could repeatedly switch modes around 1,500W. To reduce that behaviour, the automation stopped the boost only after solar fell below 1,200W for three minutes.
Using different start and stop thresholds creates hysteresis. It gives the system a stable operating band instead of reacting to every small fluctuation.
The cooldown timer
After a boost stopped, the automation waited one hour before it could start again.
That prevented a cycle such as:
- Sun appears and starts the boost.
- A cloud stops it.
- Sun returns two minutes later and starts it again.
- The cycle repeats through the afternoon.
The cooldown made the automation calmer and easier to trust.
Why we tested the action first
Before building the full automation, we manually called the MELCloud control from Home Assistant’s developer tools.
That confirmed three things:
- Home Assistant could start the hot-water boost
- the heat pump responded as expected
- returning to normal mode restored the original schedule
Testing the individual action before adding triggers and conditions made troubleshooting much easier.
What the first version taught us
The automation was considerably easier to build than our first Powerwall-protection automation.
By then, we understood how to:
- find entity IDs
- inspect state changes
- separate triggers from conditions
- test service calls
- create helper timers
- plan the restore action
AI helped with parts of the configuration, but the useful progress came from understanding the desired behaviour and testing each stage rather than copying a block of YAML without context.
Why EDF changes the financial decision
When export earned nothing, using a surplus unit of solar at home was usually better than giving it away.
At 24p per kWh export, that same unit can now earn money.
A hot-water boost therefore needs to be compared with what it displaces:
- If the boost avoids buying peak-rate electricity later, it may still be attractive.
- If the cylinder would otherwise heat overnight at 6.99p per kWh, exporting the solar and heating later may be financially stronger.
- If the heat pump is already scheduled efficiently and the cylinder is hot enough, boosting can simply create unnecessary heat loss.
- If hot water is genuinely needed before the next cheap period, comfort may matter more than the smallest possible cost.
The automation should not treat every export as failure. Export has become one of the valid outcomes the home can choose.
The wider tariff calculation is explained in Why we moved from Octopus to EDF.
Current status
We have not implemented a revised EDF-aware version yet.
Rather than leave the original automation actively requesting hot-water boosts under outdated assumptions, we disabled the relevant actions. The rest of the setup remains useful as a record of how the original logic worked, but it should not be read as our current live energy strategy.
The replacement will need to decide whether a boost is worthwhile using current prices, current demand and the state of the system at that moment.
What the future replacement needs to consider
A more economically aware version may need to consider:
- current export rate
- current and next import rate
- cylinder temperature
- expected hot-water demand
- time until the next scheduled heat cycle
- Powerwall state of charge
- expected solar generation for the rest of the day
- whether the heat pump is already running efficiently
It could then boost only when the avoided future cost or immediate need justifies giving up the export payment.
That is a more complicated decision than the original “export is unpaid, so use it” rule, but it better reflects the home we have now.
This is design work still to be completed, not a description of an automation already running. We will publish a separate article once the new version has been built, tested and used in real conditions.
Safety and comfort limits
Home Assistant should not replace the heat pump’s own safety controls.
Any automation should retain:
- the manufacturer’s temperature limits
- legionella-protection cycles
- normal thermostat and cylinder controls
- a maximum boost duration
- a reliable return to scheduled operation
- sensible behaviour if an entity becomes unavailable
The automation changes when the system requests heat. It should not bypass the controls that make water heating safe.
Is the original automation still useful?
Yes, as a historical example and as a lesson in automation design.
The original version showed how Home Assistant could use real-time energy conditions to coordinate equipment that otherwise worked independently.
What is no longer valid is the assumption that self-consumption should always beat export. A high export rate means the best decision may be to do nothing and let the electricity leave the house.
That change is a useful lesson in itself: an automation can remain technically perfect while becoming economically outdated. The measured effect of the wider energy system is covered in Six months with solar and a Tesla Powerwall 3.