@drei - that is a classic example of the HA approach, why make things simple when you can make them complicated? That is 152 lines in total of near impenetrable code when only a few lines are needed!

Going back to absolute basics, what raw variables (HA will probably call them entities with names like sensor.sun_shining_outof_myxxxx) do you have available and stored in the database? I can't really make these out in the code above, but at a minimum you need valve position (for space/DHW detection) plus energy in and energy out. Because a DHW run typically lasts less than hour, this needs to be minute data, ie collected every minute, if you use hourly data, then an hour said to be DHW heating will usually also include some space heating. The energy in and out may already be energy (ie kWh) or it may be power (W or kW), in which case it will need multiplying by time (which may be what the integrations at the top do, but it is not clear whether those values are power/energy in or energy out).

But, all in all, if you are not bothered with this, then I suggest putting it on one side. Learning the HA dialect of python is a very steep learning curve for a beginner, so much so that I gave up, and started with my own basic python, which I really could learn from the ground up, and more importantly, understand. No more blurring of the vision caused by HA code like this:

state: >
  {% set t = states('sensor.hp_tank_temperature')|float(default=state_attr('water_heater.heat_pump','current_temperature')|float(0)) %}
  {% set sp = states('sensor.hp_dhw_setpoint')|float(default=state_attr('water_heater.heat_pump','temperature')|float(0)) %}
  {% if sp > 0 %}
    {{ (100 * t / sp) | round(0) | int }}
  {% else %}
    0
  {% endif %}

Or to put it code, {% endof %}

Posted by: @cathoderay

↑

@drei - that is a classic example of the HA approach, why make things simple when you can make them complicated? That is 152 lines in total of near impenetrable code when only a few lines are needed!

...

But, all in all, if you are not bothered with this, then I suggest putting it on one side. Learning the HA dialect of python is a very steep learning curve for a beginner, so much so that I gave up, and started with my own basic python, which I really could learn from the ground up, and more importantly, understand. No more blurring of the vision caused by HA code like this:

state: >
  {% set t = states('sensor.hp_tank_temperature')|float(default=state_attr('water_heater.heat_pump','current_temperature')|float(0)) %}
  {% set sp = states('sensor.hp_dhw_setpoint')|float(default=state_attr('water_heater.heat_pump','temperature')|float(0)) %}
  {% if sp > 0 %}
    {{ (100 * t / sp) | round(0) | int }}
  {% else %}
    0
  {% endif %}

Or to put it code, {% endof %}

😂😂 It is all opensource, anyone can propose improvements, etc. 

Yes, steep learning curve on the HA code and even if the development environment is pretty easy to use, there are serious hurdles with testing.

I would use it to automate setting high level programs in components like inverter, but make sure they can run even if an HA update knocks it offline for a while. 😉

Posted by: @batpred

↑

...

I would use it to automate setting high level programs in components like inverter, but make sure they can run even if an HA update knocks it offline for a while.

...

No components need HA to be running any more than they need @cathoderay's python box to be running or, indeed, the Internet connection to be available. They will continue running in their current configuration until something makes a change.

An inverter, typically, will communicate over the Internet connection to the manufacturer's cloud. If set up appropriately, HA will also talk either with the inverter or with the manufacturer's cloud. As a result, the inverter will keep doing what it's configured to do until:

1. You make a change using the manufacturer's app, which communicates with the manufacturer's cloud and then changes the setting on the inverter when it next calls in or
2. You make a change using HA in which case:
   1. If the HA integration links to the manufacturer's cloud, that change is propagated exactly as if the change had been made by the manufacturer's app
   2. If the HA integration communicates directly to inverter, the change is made directly to the inverter and then the inverter passes that change on to the manufacturer's cloud.

In all cases, the inverter is able to continue if HA drops off, if the local network goes down, if the broadband goes down, if the manufacturer's cloud systems go down etc. This same principle applies to EV chargers, heat pumps, smart plugs and any other IoT devices you may care to think of.

Posted by: @batpred

↑

Posted by: @cathoderay

↑

😂😂 It is all opensource, anyone can propose improvements, etc. 

Yes, steep learning curve on the HA code and even if the development environment is pretty easy to use, there are serious hurdles with testing.

I would use it to automate setting high level programs in components like inverter, but make sure they can run even if an HA update knocks it offline for a while. 😉

 

Yep, and this happens daily on my side, as my routers are set to go offline over night a few hours. Give us a bit of WiFi free environment, no unnecessary radiation when sleeping. So my sensor will never be 100% accurate, especially since the Heat Pump heating will most likely be higher over night than during the day. Loosing a few hours of 2kw will cause some errors:))

I am not too bothered with the accuracy and doesn't matter much, for me it is just a basic idea, to understand how the system uses electricity and what it generates. I know I can heat my hot water close to 68c if I need to, I managed to go from 40c to 63c in 1 hour of Octopus Free Electricity session. I think the pump was pulling nearly 6kW... but hey, if Octopus gives me the electricity, I will use it.

I have a HA schedule, which I can set in advance, and during the free session HA will push the Desired Tank Temperature to 68c and Forced Hot Water Mode (High Output), then when the session has ended, it will put it back to 50c and ECO mode.

I will look into the advice, see if I can improve the code. Bear in mind, my HA is running in Docker Desktop, so I have limitations.

This is my current set-up, with some experimental things running in other views:

And this is my Heat Pump experimental part:

Posted by: @majordennisbloodnok

↑

Posted by: @batpred

↑

...

I would use it to automate setting high level programs in components like inverter, but make sure they can run even if an HA update knocks it offline for a while.

...

No components need HA to be running any more than they need @cathoderay's python box to be running or, indeed, the Internet connection to be available. They will continue running in their current configuration until something makes a change.

That sounds about what could be reliable in most cases. 

But something as simple as getting HA to charge an EV (where the charger and the car may be both communicating to HA via cloud solutions) at particular times can be much trickier to achieve and not recommended. 

Say HA stops the charger and then something fails in the comms. 

Two alternative scenarios:

1- you notice and correct it manually. say you switch it on. 

2- you do nothing and HA etc comes back up at some later point and switches it on. 

In the first, when HA is working again with the comms etc in place, it may have to not just carry on from before but reassess. It could be that it will instead need to switch off, since you switched it on.

In the second, HA switched it on. But it could be that when HA came back (or the comms came back), it should be off.

By carefully adjusting various HA automation settings and/or increasing the robustness of the code, it may work well enough.. but it may be too much effort for the benefit. 

Posted by: @batpred

↑

Posted by: @majordennisbloodnok

↑

Posted by: @batpred

↑

...

I would use it to automate setting high level programs in components like inverter, but make sure they can run even if an HA update knocks it offline for a while.

...

No components need HA to be running any more than they need @cathoderay's python box to be running or, indeed, the Internet connection to be available. They will continue running in their current configuration until something makes a change.

That sounds about what could be reliable in most cases. 

But something as simple as getting HA to charge an EV (where the charger and the car may be both communicating to HA via cloud solutions) at particular times can be much trickier to achieve and not recommended. 

Say HA stops the charger and then something fails in the comms. 

Two alternative scenarios:

1- you notice and correct it manually. say you switch it on. 

2- you do nothing and HA etc comes back up at some later point and switches it on. 

In the first, when HA is working again with the comms etc in place, it may have to not just carry on from before but reassess. It could be that it will instead need to switch off, since you switched it on.

In the second, HA switched it on. But it could be that when HA came back (or the comms came back), it should be off.

By carefully adjusting various HA automation settings and/or increasing the robustness of the code, it may work well enough.. but it may be too much effort for the benefit. 

 

 

One thing I have been doing, is creating watchdogs for my automations, listening for 2 minutes, so if something hasn't changed, it will retry. Honestly, the amount of automations, scripts and helpers I went through, is nuts. I also tend to do a HA backup every time I change something. Just in case, but I am also saving everything to relevant text files, then backing stuff up in the archive folder:)) So I always have a previous version I can go to.

Going back on the subject of our heat pump, in the spirit of keeping everything transparent and documented. In mid-September 2025 I submitted a Subject Access Request (SAR) to EPC Improvements to obtain all data and internal communications relating to my installation. Last week they replied:

Morning A.

I hope that you are well.

I’m writing to formally request a 30-day extension. Given the level of communication across several members of our team since your initial engagement with us around 27 June 2023, it’s proving to be no simple task to coordinate the data extraction to the standard we want to deliver.

We are working with Google, using their Google Vault platform, to extract the relevant data. This process has proven slightly difficult, as some of the team members you communicated with over the years have since left and their accounts are deactivated or deleted. That said, we are continuing to work through it as thoroughly as possible.

It’s a shame, reading back through some of the correspondence, how we’ve ended up in this situation. That said, it goes without saying that I will do my best to work with you and provide what you have requested within the revised time frame.

I also want to acknowledge that both myself and the wider team have read the articles and online reviews you’ve posted. To be completely candid, this was disheartening for us to see. We work hard to help and keep our customers happy, and we don’t feel the article paints a true picture of the project. In fact, there are some inaccuracies in it. That said, we are where we are, and our focus is on moving forward and resolving matters constructively.

Thank you for your understanding, and I look forward to working with you towards a resolution.

Best regards,

C M

Co-Founder

I kept my response civil, because at this point I genuinely wish EPC had simply listened and carried out a proper assessment of my system when I first raised concerns. Had they done so, the situation could have been resolved long before it reached this stage.

EPC also had opportunities to seek support from Heat Geek, or at the very least acknowledge that the radiator data they relied upon was based on the 2022 Kartell Designer Heating brochure, which overstated radiator outputs by roughly 33 % compared with the 2023 and 2025 versions. That single discrepancy alone would have had a major effect on a low-flow heat-pump system’s ability to reach design performance.

Hi C,

Thank you for your response and for clarifying the steps being taken to retrieve my data.

I acknowledge your request for a 30-day extension. While I understand the challenges of coordinating data from multiple team members and deactivated accounts, the statutory time-frame under Article 12(3) of the UK GDPR allows an extension only where necessary due to the complexity or number of requests, and this must be communicated before the expiry of the original 30-day deadline.

As my SAR was submitted on 15 September 2025, your request dated 9 October 2025 falls within approximately 25 days of receipt, therefore still inside the permitted window. I will agree to your 30-day extension on the condition that you:

1. Confirm a specific completion date for delivery of the full dataset (emails, texts, WhatsApp messages, call recordings, internal communications, and any other personal data held about me).

2. Provide a partial disclosure of all readily available data by that date, particularly from active accounts.

---

While I appreciate your willingness to “move forward constructively,” I would also welcome EPC’s clarification on several points that have caused serious concern and ultimately led to this situation. These should also assist EPC in its internal review of what went wrong with my installation:

• Radiator incident: Despite repeated warnings over several months about a loose radiator, a clear safety issue, no one from EPC attended to check or repair it. The radiator eventually detached and injured my 3-year-old daughter (photo attached). This incident was entirely preventable. What makes it worse is that there was no communication from EPC for nearly four months, and by the time an eventual email arrived, I had already given up expecting any contact or follow-up. To suggest that a response should have been anticipated at that stage would be unreasonable, given the complete breakdown in communication. A simple follow-up phone call from EPC would have been the right and responsible action in the circumstances.
• System underperformance: EPC’s own documentation (attached) projected a system performance of 31,065 kWh output from 9,350 kWh input, a SCOP of 3.92 at 50 °C. My actual metered data over the same period shows 19,703 kWh output from 8,850 kWh input (SCOP 2.23). Despite repeatedly raising these efficiency concerns, EPC never carried out a proper on-site assessment or remedial visit.
• Lack of accountability: For a year, I have sought meaningful assistance or explanation. To date, I have not received any technical visit or follow-up that has addressed these documented performance failures.
• Radiator data discrepancy: The radiator outputs EPC relied upon were taken from the 2022 Kartell Designer Heating brochure supplied during design. However, that edition overstates radiator outputs by approximately 33 % compared with the updated 2023 and 2025 catalogues (attached and available on Kartell’s website). This shortfall would have led to systemic under-performance and heat loss across my system, an error that could have been identified had EPC responded to my repeated requests for a system assessment.
• Hydraulic configuration loss: The system also suffered from a -10 °C temperature drop across the buffer, causing distortion and cycling. Performance improved somewhat after I manually reduced the post-buffer circulation pump speed to L1 (photo attached), but efficiency remains well below the design promise.
• Accreditation concerns: Finally, I would appreciate EPC’s clarification as to why the company was removed from the Heat Geek network, despite being listed as certified and verified at the time of my installation.

Given the severity of these issues, safety, performance, and compliance, I believe it is reasonable to ask what specific actions EPC took in response to my multiple documented requests for help over the past two years.

Please confirm the revised SAR completion date, and advise whether a partial disclosure will be issued in the meantime.

Kind regards,
A M

Looking back over the communications, and the photos showing my daughter being crushed by the falling radiator, still makes me feel sick. I had warned EPC multiple times that the radiator was loose.

We were left without heating and hot water for 19 days between 23rd October and 9th November, only a month after commissioning, and I had to spend around £500 on electric heaters to keep the occupied rooms habitable.  The cost would have been a lot more if the space heater and oil radiators I purchased were not on offer on Amazon.

During that first winter, when I told them the heat pump was financially crippling us due to its inefficiency, my emails were effectively ignored, and was told I had no idea how heat pumps are supposed to work, and that mine was working at 350% efficiency.

Two years of silence, frustration, and escalating costs later, I remain angry, disappointed, and full of regret for ever choosing EPC over the Heat Geek Elite installer I originally consulted, ironically, the same engineer who finally visited this month to assess the system and provide a realistic remedial quotation.

After two long years, there is some hope that the system can be fixed. I only wish this point had been reached sooner, through honest engagement and basic aftercare.