OpenEnergyMonitor Community

Heat pump experiment review after two years

Thanks @MyForest for all of your help and suggestions above, I will get back to you on this shortly. It’s been a really interesting heat pump install to try and understand and work out what’s going wrong. Will share more about it soon hopefully.

1 Like


Hi myforest I have installed an ecodan 6kw heatpump and also an emonpi to monitor its power usage. I have the basic energy monitoring on the ecodan which comes with a flow meter which is nice as it can give approx cop. However looking at the MELCloud app the power usage compared to my emonpi can be very close some days and then off by 20% or so on other days. From your digging around inside the MELCloud api have you seen anything in the way the ecodan measures power to suggest why there would be such a difference. Of course it could be the emonpi that’s wrong I guess.


Hi @Gavin_Armstrong

I’m a bit torn on this.

My gut feeling is that the MELCloud stuff can’t be right because it reports numbers that we all find hard to believe. For example, it reports energy is being generated when it’s turning off. It could be right because warm water is being pumped around.

So I’ve decided to take their readings with a pinch of salt. It’s nice to have an mostly gives something I can use to guide what I’m doing. I wouldn’t bet my house on the numbers though.

However, I also correlated what was being reported by MELCloud and absorbed into EmonCMS by my scripts with what electricity the meter says has been consumed. It seemed close enough that I decided MELCloud was good enough.

I wouldn’t be surprised to see a 20% variation on occasion, but that it’s right most of the time.

Finally got round to setting up the script to read from melcloud, I’ve been getting really good data from the emonPi on this customers heat pump, it will be interesting now to see how melcloud compares:

import aiohttp
import asyncio
import pymelcloud
import requests
import json
import time
import math

from inspect import getmembers
from pprint import pprint

async def main():

    async with aiohttp.ClientSession() as session:
        # call the login method with the session
        token = await pymelcloud.login("EMAIL ADDRESS", "PASSWORD", session=session)

        # lookup the device
        devices = await pymelcloud.get_devices(token, session=session)
        device = devices[pymelcloud.DEVICE_TYPE_ATW][0]

        last_update = 0

        while True:
            if math.floor(time.time())%60==0:
                # perform logic on the device
                await device.update()

                props = [
                data = {}
                for key in props:
                  data[key] = device._device_conf['Device'][key]
                print (data)
                reply = requests.get("", {'apikey':'APIKEY', 'node':'melcloud', 'data': json.dumps(data)}, timeout=60)
                print (reply.text)
        await session.close()

loop = asyncio.get_event_loop()

The goal this winter is to hopefully improve their COP by quite a bit through better balancing and system control and write up the results as a case study next year.

A little comparison of the data so far, here’s the flow and return temperatures from melcloud vs the emonpi, looks great!

Melcloud heat pump frequency vs emonpi CT sensor:

Melcloud heat pump energy consumed vs emonpi CT sensor, resolution is a bit poor but maybe we can use this with the right scaling factor…

Melcloud energy consumed and produced x1130 matches emonpi electric consumption: suggests COP around 4.1… great…

Daily heating energy and daily hot water energy vs emonpi CT sensor, not sure what’s going on here…

Simulated heat output using carnot COP equation suggests a COP that’s a bit lower at 3.54…

Will be interesting to see how these results compare over time. I think I might piggy back onto the Sika VFS flow sensor used by the EcoDan and try and read the flow rate into the emonPi with a simple analog voltage input…

1 Like

That looks like a metric that’s their view of the whole day. I don’t use that.

That is a great idea, it will be interesting to see that. You’re in a good position to see if the MELCloud stuff is working as expected. It’s notable that you have finer-grain data from emonpi. One of the questions people keep asking me is “what granularity do we need?”. For example, SMETS is half-hourly - is that good enough to understand usage or do you need each minute, or every six seconds? Specifically for me, with solar input varying by the second I need local control by the second, but for modelling purposes it may be that half-hourly is sufficient.

As you’ve probably gathered, I’m trying to do mine without interfering with the device at all. I’m trying to make sure I don’t mess up my RHI rebate.

Hello @MyForest . This looks really interesting work. I will need to rev-up my brain in order to digest it all. I am not the fastest at understanding things.
I would love to get my old 5kW Ecodan controlled better, but my FTC3 is far too old for MelCloud sadly.

Hi @johncantor,

Thanks for the kind words.

If you think it would help I’m happy to chat to you directly or even show you some of the experiments. Just let me know when would suit you. I’m up in Yorkshire and I believe you are not, so we may end up doing it virtually, but I can drive to places if that helps. It’s the least I can do for you considering the efforts you have put in over the years (including your book sat next to my arm right now which I show to friends who ask about these things).

I don’t think I’ll be able to get MELCloud on your FTC3 though :slight_smile: