Posted by: @cathoderay

↑

@robs, @sunandair — I expect you may already have seen this thread, but if you haven't, it contains an interesting analysis of possible MELCloud energy data reporting errors. The accompanying charts (you need to click on the link to get the relevant MEL Pump chart) also have an isolated defrost on the right hand side which on eyeball assessment looks like it may be energy neutral.

@sunandair — it does seem others are also sceptical about the credibility of Ecodan data. In his opening post @sheriff-fatman says (emphasis added) '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'. I appreciate that part of your logic is that you are looking at relative differences in your data, and therefore any errors should in theory cancel out, but that makes a big unverified assumption, that the error is constant. Even if it is constant, the actual value of the difference remains uncertain. I have to say that without independent energy data monitoring, which I don't think you have in any shape or form, please correct me if I am wrong, your reliance solely on MELCloud data does compromise the strength of your findings.       

Hi @cathoderay

Thanks for linking me into your post.  This is not a thread that I have followed in any detail so I would have missed seeing this without it.

Just to briefly summarise my findings with regard to Ecodan reporting, particularly the part with added emphasis, the thread you've linked to is primarily focused on why the Ecodan stat reporting is significantly less accurate when the system runs in auto-adaptive mode than it when running in weather compensation, to the effect that demonstrable improvements in performance under WC (as measured via alternative sources) are masked within the reporting.  In terms of my own Heating CoP figure, the Ecodan data understates this by 0.29 (i.e. MelPump reports a heating COP of 2.89 at an average OAT of 6.3°C over a 55 day period running Auto Adaptive mode, compared to a figure of 3.18 using data from the 3rd party CN105 dongle feeding in to the Open Energy Monitor add-in within Home Assistant).  The latter has been sense checked against smart meter readings from the meter connected to the heat pump, and closely aligns with this data.

As mentioned in a recent video by @editor in which he analysed Havenwise data across a number of brands, one known issues is that the Ecodan reporting generally overstates input power, which is consistent with my own testing, hence the comment regarding questionable accuracy.  This looks to be the case in all modes of operation, but becomes less accurate in AA mode.  My own figures show input power being over-reported by 7.6% across 45 days of testing in WC mode, which then deteriorates further to 12.5% when run in AA mode.  For anyone trying to analyse performance without a means to independently access input power data, I would suggest discounting the reported input data by these figures as a start point.

Hopefully this provides some context to my findings for anyone with interest in Ecodan systems within this thread.

@sheriff-fatman — I was expecting the forum machinery would notify you that I had mentioned you in a post and hoped that you would pick up on it, thanks for doing so!

There has been a long discussion on this thread about the questionable accuracy of Ecodan energy data. I was impressed by your collection of data from different sources as a way of checking one against the other, bearing in mind that some methods are inherently more likely to be accurate, and should therefore be preferred when different sources give different results. The emphasis on this particular thread is not so much on the COP as the raw energy in data, in an everlasting quest to determine whether setbacks saves energy or not, but the fact remains, both endeavours require tolerably accurate assessments of energy in (and out to get the COP) to give meaningful results.

I wonder if there are any clues as to what is going on in the fact the Ecodan data becomes even less accurate when running in AA mode. It shouldn't make any difference in the unit is deriving its energy in data from the raw parameters, amps x volts. Do we even know how an Ecodan unit derives its energy in data? I do know from earlier comments in this thread that various correction factors (default or custom) get applied, but I wonder what are they are being applied to?     

@cathoderay One instinct I have from my testing is that the Ecodan data capture doesn't measure specific input usage by mode of operation, so it's working from daily totals and 'assigning' a share of this to DHW and Heating usage, presumably based on total time spent in each mode.  This applies to all methods of usage, not just AA, but there is generally an overstatement of DHW CoP alongside the understatement of Heating CoP which has led me to that conclusion.

If you look at how the MelPump data updates after midnight using the Ecodan reporting, the daily input and average temperature data updates immediately after midnight, but the CoP calculations take several hours to filter through (so typically I don't get to see what CoP has been reported until the next morning).  This suggests to me that there's some sort of calculation processing in the background to estimate this, but which doesn't refer to the binary 'on/off' statuses for when it's running in DHW and Heating mode.  Typically, the system runs harder to do DHW heating, so that element of the calculation 'benefits' from whatever allocation is being applied, at the expense of the heating CoP figure.  If the system had real-time access to data usage and mode of operation it logically would be able to produce an instant calculation alongside reporting the factual data.  The fact that it takes a few hours to do this is a bit of a red flag for me.

I too am perplexed by why the margin of error increases in AA mode, and it's currently only my own findings that have suggested this.  Ideally, I'd love to see it confirmed by someone else running an equivalent test, which would require that they have access to the dongle data alongside the Ecodan reporting, and also be as obsessive as I've been in monitoring it over a reasonable period of time.  

The Frient interface for the smart meter that I purchased as part of the monitoring https://www.frient.com/products/electricity-meter-interface-2-led has been a revelation with regard to how accurate it's data is, and is a great way to monitor input power if there's a smart meter attached to the installation (not just for Ecodan systems).  The downside is that it required a Zigbee interface to get it to integrate into Home Assistant, so wasn't the easiest thing to get up and running (albeit I'm a relative n00b using HA).  Once I'd got it to spit out data, it has been 100% accurate at replicating the daily meter reading totals and, unlike the manual method of taking meter readings at midnight each day, is also then able to output a profile of power draw across the day.  Definitely recommended as a potential measurement device.

I now recollect that somewhere a while ago I read something that suggests that in the absence of add ons MELCloud estimates power in by multiplying the units maximum power draw by the current compressor frequency expressed as a percentage of the compressor's maximum frequency eg if max power draw is 3kW and the compressor is currently running at 50% of max, then current power is 1kW, and if it stays like that for an hour then that is 1kWh. Perhaps others more knowledgeable about MELCloud's inner workings can confirm of refute this. It it is confirmed, then it seems to me that it is a very crude estimate of energy in, and will depend very much on things like sampling frequency when the unit is not in steady state.

Posted by: @cathoderay

↑

Perhaps others more knowledgeable about MELCloud's inner workings can confirm of refute this

Flow temperature will have a influencing factor too,

However, yes, as there is an absence of power monitoring inside i think this formula is how it is calculated

Posted by: @f1p

↑

Posted by: @cathoderay

↑

Perhaps others more knowledgeable about MELCloud's inner workings can confirm of refute this

Flow temperature will have a influencing factor too,

However, yes, as there is an absence of power monitoring inside i think this formula is how it is calculated

Why on earth not just measure current drawn and voltage, assume a power factor, job done.  If Shelly can do this in a device that retails for gbp13 and has significant compute power, mitsubishi can do it in a device costing several £1000

Posted by: @f1p

↑

However, yes, as there is an absence of power monitoring inside i think this formula is how it is calculated

I've been trying to find a Mitsubishi source for this, without success. The closest I have got so far is this description of monitoring levels from Mitsubishi's MELCloud User Manual (page 10):

This implies that basic standard monitoring (EMP1) is less accurate than enhanced monitoring EMP2, but doesn't say by how much. It does however say that EMP1 only measures to the nearest kWh, which will introduce rounding errors. 

Posted by: @jamespa

↑

Why on earth not just measure current drawn and voltage, assume a power factor, job done.

Indeed.

@cathoderay The FTC5 is quite old tech and current installations will likely use the FTC7 controller.  The blurb for the FTC7, quoted below, simply states that it includes energy monitoring, but there is no detail given as to the extent of this.  However, it likely implies that there is no longer an option available as to the level of monitoring, as suggested for the FTC5.  Users simply get the default monitoring provided within the FTC7.

The Ecodan FTC7 controller is easy to navigate with its colour touch screen and one touch settings access. Smart Grid and PV integration ready with the additional built in quiet mode interface and step by step installation wizard and intelligent room temperature control as standard. It also includes energy monitoring, showing consumed and produced energy.

The description of EMP2 in your chart is intriguing, as it suggests there is a pulse meter type input measurement available for the FTC5.  However, I doubt that the FTC7 uses anything as accurate as this, as my own system has a 3rd party smart pulse meter attached to the installation and the Ecodan's input power recordings are completely independent of this and, as noted in my data analysis, can be routinely overstating the smart meter data by circa 12.5% in auto adaptive mode.

@sheriff-fatman — the FTC7 description is even more cryptic. But what is interesting is that in your system, the Ecodan input power is higher than the smart meter data, which will lead to an underestimate of COP (which is relevant to the claims of an unduly low COP by @ecoste on the other thread). On my system it is the other way round, I suspect because the Midea reported amps and volts are those used only by the compressor, leaving out the ancillaries. I deal with this by using a correction factor when calculating power/energy in, and the corrected figure is tolerably close to my manual heat pump kWh meter readings. Over 2025, the calculated value under-reported the metered value by 3.6%.

As a matter of interest, does your energy in smart metering use an optical pulse counter which counts the LED flashes on the main electricity meter? If so, could you say what you use, and given a basic idea of how it is setup to collect the data?

Posted by: @cathoderay

↑

As a matter of interest, does your energy in smart metering use an optical pulse counter which counts the LED flashes on the main electricity meter? If so, could you say what you use, and given a basic idea of how it is setup to collect the data?

I posted the details of the Frient pulse counting device in an earlier post on the thread - https://renewableheatinghub.co.uk/forums/postid/60807/

I've attached a photo of it.  There's a magnetic clamp that sits over the LED of the meter, and it then connects to the white oval box above it that houses the 2 x AA batteries that power it.  The other models I've seen of similar devices all need a mains power source, so this is a big advantage of the Frient device for a cylinder cupboard in the bathroom where there are no mains sockets nearby.

It connects to Home Assistant, but requires a Zigbee interface to get it to talk to HA.  I then have two output graphs in HA, one which monitors the total daily usage, and another which provides the usage profile.  This aligns very closely to the CN105 dongle data in profile (it's the CN105 data that's used in the emoncms data, which looks to be slightly overstating power compared to the meter readings, by circa 2.2%).  I haven't reconfigured emoncms to use the meter reading data, so as to have a consistent data source, but doing so would uplift my CoP figures very slightly.

Output data within Home Assistant shown below.  The first is just the Frient sensor graphs.  The second shows the input power profile underneath the equivalent data from the CN105 dongle, which also shows output data (the coloured input lines reflect Heating and DHW usage).

@sheriff-fatman — thanks, that is very useful, and sorry, I should have checked whether you had previously posted details. The use of AA batteries for power makes good sense as the one place most people don't have a mains socket is by their meter(s). I do have an ancient HA installation, but don't actively use it, it is only still there as its underlying OS is what I use to run my python scripts. There may well be a python module/library that can directly read and collect data from the sensor, I will look into it. I note it isn't cheap, with the Zigbee gubbins it looks like getting on for £100. A modbus enabled kWh meter can be had for about half the price, and I already have everything in place to connect it, but I am nervous about changing the current manual read only one to a modbus enabled meter, for fear of electrocuting myself! 

@cathoderay Cost via Amazon was £42 for the monitoring device and £26 for a Zigbee adapter, as I didn't already have this.  Having the digital display available on the meter has enabled me to verify the accuracy of the device, which has been spot on since it was set up.  My spreadsheet includes a 'virtual' cumulative meter reading from the device, by summing up the daily usage, and it is basically a 2 decimal place replica of the meter readings each day.