I'm posting this as a heads up for Ecodan users using the Mitsubishi's internal stat reporting to diagnose issues with their system, as it's something that I've discovered 'accidentally' while reviewing other aspects of my system performance, but is something that will potentially lead to mis-diagnosis if it's more widespread than in my own system.

I've discovered that the accuracy of the Ecodan's own daily reporting of energy use, which is of questionable accuracy to begin with, significantly deteriorates when the system is running in Mitsubishi's own Auto-Adaptation mode, relative to when it is being run in other modes, such as weather compensation, or constant flow temp mode (which is the mode used by Havenwise and MelPump to control the system remotely, if set up to use in this way).  This is essentially masking the performance improvements which running in Auto-Adaptation mode appears to deliver, and which are very apparent from the 'eyeball test' of the daily performance profile.

First, a bit of background as to the 'accidental' nature of the discovery.  I've been doing extensive monitoring of my 10kW system since installation in June 2025 to better understand a very modest COP performance to date of around 3.0.  Initially, I ran the system via Havenwise, and more recently had been using weather compensation.  I've been using MelPump and the optional dongle to monitor performance of the system in detail and was very excited via the release of MelPump's own multi-point weather compensation curve setting, which potentially would allow this to be fine-tuned further.

Unfortunately, the initial release of the MelPump curve had a bug in it, which caused the curve settings to reset each time they were saved.  As a bit of an experiment while awaiting this to be fixed (which I believe was done after a few days) I switched the system to Auto-Adaptation mode out of intrigue.  The first time I'd attempted to do this lasted about 30 minutes, as the response had been for the system to immediately increase the flow temp to circa 48°C from something in the mid-30s, but I had been subsequently re-assured by @f1p suggesting that this was part of the self-learning operation it does when the settings are switched.  I was also intrigued by some of @f1p's other posts on the forum which suggest that the tolerances used by the Ecodan in Auto-Adapt are different to those available in other modes, suggesting that this mode opens up efficiencies that are not readily available in the other modes.  I was intrigued to see if this was noticeable over a short-period of a few days, pending the fix to the MelPump curve settings going live.

It took less than 48 hours to realise that the daily profile of operation was noticeably improved within Auto-Adapt.  The system was able to deliver much longer periods of sustained running without cycling relative to performance under similar conditions under weather compensation.  Interestingly, many of these periods of 'equilibrium' operation showed it to be matching the target temperature to the return temperature, rather than the flow temperature, which is something that seems to be unique to AA mode and which, for some reason, allows the pump to run in a very stable way for extended periods of time.  I'm not currently sure why this should be the case, but it seems to work effectively.

However, what also became noticeable was that the daily reporting figures from the Ecodan, which MelPump uses within its daily summaries, including the COP calculations, were noticeably different to what was being observed via the 5 minute updates throughout the day.  In addition to using MelPump analysis, I have configured the system within Home Assistant to report using the Open Energy Monitor integration, and have been comparing both outputs against each other since early December.  Prior to switching to Auto-Adapt there hadn't been a hugely significant variation between the two, or at least to the extent that the differences couldn't be attributed to anything other than an expected margin of error between the two systems.  A noticeable divergence between the two systems coincided pretty much immediately with the switch to Auto-Adapt mode.

To summarise the type of variance I'm talking about, I've used data from 5th February in the images below.  This day has been the 'cleanest' full day of operation I've seen from the system, with almost 24 hours of equilibrium running being interrupted only by a couple of defrost cycles and 3 short periods of DHW heating.  The summary from emoncms (the Home Assistant integration) for the day is shown below, in simplified form (i.e. without lines for flow rate, DHW temp and instantaneous COP which I normally have showing):

As can be seen, the profile during heating operation (the yellow background) is about as good as it gets in terms of stable running, and the heating COP of 2.94 at an average outside air temperature of 3.1°C (which is low for many people) would be 'acceptable' from my perspective and would likely indicate a SCOP of 3.3 or 3.4 to be achievable over a full year, which would match my initial expectations of what might be achievable for the system at installation.  I should note at this point that the system is delivering significant cost savings relative to the gas boiler it replaced, currently in the region of 40-50% on the equivalent period last year, so the low COP is something of a 'niggle' for me rather than a fundamental concern about the installation.

The link to the MelPump data for the same day is also linked below.  This is 'interactive' so is easy to interrogate specific data points within it, but essentially provides the same overall picture for the day.  Note in particular that the instantaneous COP figure at pretty much any point of the equilibrium is consistently around or just below the 3.0 mark during the day, and entirely consistent with the emoncms figure of 2.94 as shown above.  The system spent most of the day running at a compressor frequency of 26-30Hz, at an input power of just over 1kW.  The lowest power input I typically see from the system is 940W, so it was operating close to this for a prolonged period of time.  (NB: Ignore the image that displays on the post directly, as this is just a 'stock' image from MelPump.  Click on the hyperlink to open the actual data).

https://melpump.com/public-report/view/019c3265-0f21-7df3-81e6-df7ebbcf8e67

As had become the norm during this period of scrutiny, the Ecodan produced data for that day, which MelPump collates within its daily reporting statistics, showed a Heating COP for that day of 2.62 and an overall COP of 2.56.  The daily COP figure in both cases was 0.32 lower than that represented in the above picture, and there are very few points during the day's profile where the instant COP is as low as that.  The daily totals simply don't match the output, which is a picture I've been seeing consistently in the 16 days of auto-adaptive monitoring so far.

I've attached below a spreadsheet analysis of the daily reported totals over the period in which Auto-Adapt has been the mode of operation for the system.  Over the 16 day period, the Ecodan Heating COP figure has been under-reported by an average of 0.38 each day, with the overall daily COP being under-reported by an average of 0.29 per day.  Typically, some of the heating error is recovered by the DHW reporting, but both the heating and total COP differences are significant.

Obviously, the immediate point of challenge is to establish which of the two figures looks to be the accurate one (as it's feasible that the emoncms data might be over-reporting performance).  The most significant element of the difference arises from the recorded input power within the reporting.  The salmon shaded cells on the analysis show the reported usage compared to daily meter readings I've been taking from the Smart Meter installed with the ASHP at midnight on each of the last few days.  This shows the the dongle/emoncms figures are 99.4% accurate over 6 days so far, so are under-reporting usage very slightly.  By contrast, the Ecodan data is, on average, being over-stated by an average of 10.8% each day.

I don't have daily smart meter readings to assess the period prior to this, but I can track from the daily calculations the percentage by which the Ecodan reporting differs from the emoncms reporting.  In the 16 days of Auto-Adaptive running, this difference has been 11.0%.  In the 45 days prior to this, when the system has been mostly run on weather compensation, the equivalent difference was only 3.6%.  So whilst there is likely an element of under-reporting performance across all modes of operation, the scale of the error increases significantly when the system runs in auto-adaptive mode.

The problem with this is that, without the benefit of having the dongle attached to the system or being able to see a daily profile of operation that looks noticeably different to the reported data, then the under-reporting is significant enough to change the interpretation of the system's performance for the end-user.  For the 16 day period in question, I'd be extremely concerned about the average COP from the Ecodan data of only 2.72 at average daily temperatures of 4.4°C.  The picture looks somewhat different when the more likely COP figure looks to be closer to 3.10, prior to any scrutiny of the produced energy figures, which is a topic for another occasion.

Quite why the margin of error increases so significantly in Auto Adaptive mode is a mystery to me.  I've seen enough from the heat pump daily profiles over the last couple of weeks or so to convince me that running the system in auto-adaptive mode looks to be the best method of operation of the system.  For whatever reason, the system is demonstrating a much improved ability to modulate itself across longer periods of operation in auto adaptive mode than in equivalent conditions using weather compensation or constant flow modes, which I can only assume arises from the internal 'logic' of operation that I have no ability to influence.  @F1p can likely articulate this far better than I can, but he's made reference to something previously in another thread which is perhaps the start point of an explanation.

Mitsibuishi Auto-Adapt uses the "Thermo Diff." setting to allow the Flow Temperature to overshoot the Flow Setpoint by up to +5C (default)

 

The tolerance of flow temp overshoot in fixed flow or the curve in the controller is far less and hence many users find they have increased cycling in these modes, particularly in milder conditions

However, based on my analysis so far, admittedly limited in scope, the benefit of this would be lost to anyone relying on the Ecodan's data reporting for information (even if using Mel Pump to access it) as the margin of error within this mode increases so significantly as to suggest that there is no improvement, or even a deterioration in performance when being run this way.

Hopefully this might prove to be of some interest to those looking at the performance of their own Ecodan systems, as there are quite a few recent threads from other Ecodan users.  As Mars' recent YouTube video reviewing Havenwise data showed, the Mitsubishi system reporting tends to be on the 'cautious' side in general, but if other users are also potentially exposed to COP reporting that is 0.3 to 0.4 below the true figure, then that would be a concern.

I will continue to monitor this further, a job which will be made much simpler now as I've managed to successfully configure an LED reader on the smart meter within Home Assistant (and discovered the joys of Zigbee integration in doing so) to remove the reliance on midnight meter readings each day.  I'm now getting an energy usage profile direct from the smart meter itself and the data is correlating perfectly with the periodic meter readings.