Joining the Renewable Heating Hub forums is completely free and only takes a minute. By registering you’ll be able to ask questions, join discussions, follow topics you’re interested in, bookmark useful threads and receive notifications when someone replies. When choosing your username, please note that it cannot be changed later, so we recommend avoiding brand or product names. Before registering, please take a moment to read the Forum Rules & Terms of Use so we can keep the community helpful, respectful and informative for everyone. Thanks for joining!
Some of the moderators of this forum post data from OEM, so I'm not the only one doing that. Other forum contributors have also stated that they own OEM monitoring kit, so I'm not the only one doing that too. Are some of the moderators and other contributors also advocating the buying of things from OEM?
...
In the interests of clarity, @robs, I need to make some minor comments.
The dongle you're referring to is not OEM. Mitsubishi have never produced an addon quite like it, so it's not accurate to call it original equipment. It is in every sense an independent third party piece of kit.
Secondly, the key part of the dongle is the firmware, and that is open source, posted on Github. It is centred around an ESP32 microprocessor, so anyone wishing to buy their own ESP32 board and solder a couple of appropriate connections to it could download and apply that firmware to it and have precisely what the developer sells.
Thirdly, I'm assuming, by "some of the moderators", you mean me. That is correct; I have a Mitsubishi Ecodan and use the CN105 dongle to gain local control of it. However, when the developer first joined the forum I did remind him of the fine line between forum contribution and product promotion, and he has remained helpful and within the spirit of the rules at all times since. Rereading the post @sunandair refers to, I'm inclined to apply the same comments to it that I made to the developer of the dongle. Nonetheless, the ideal would perhaps have been for you to link to the Github repository (where all the documentation and helpful stuff are anyway) rather than the marketplace.
Finally, "other people are doing it too" is never going to be a great argument. If you'd been found to have posted something inappropriate and I'd done the same thing, I'd expect both our posts to be removed or edited notwithstanding my moderator role here. If you want to argue the legitimacy of anything you post, it would be far better to refer to the rules directly - which are objective and stable - rather than the actions of others.
105 m2 bungalow in South East England
Mitsubishi Ecodan 8.5 kW air source heat pump
18 x 360W solar panels
1 x 6 kW GroWatt battery and SPH5000 inverter
1 x Myenergi Zappi
1 x VW ID3
Raised beds for home-grown veg and chickens for eggs
"Semper in excretia; sumus solum profundum variat"
I've just been made aware, @robs, that you may be using "OEM" to refer to the heat pump specific "Open Energy Monitor", not the more generally recognised term of "Original Equipment Manufacturer". Oh, the joys of acronyms.
If so, please disregard my first paragraph in the previous post.
105 m2 bungalow in South East England
Mitsubishi Ecodan 8.5 kW air source heat pump
18 x 360W solar panels
1 x 6 kW GroWatt battery and SPH5000 inverter
1 x Myenergi Zappi
1 x VW ID3
Raised beds for home-grown veg and chickens for eggs
"Semper in excretia; sumus solum profundum variat"
@robs I have to query your ridiculous accuracy figures of MELCloud
when I find your comment ill post it here…. Rob, You state…. “You continue to use electrical consumption estimates that can be 40% to 60% inaccurate”
The general consensus on web searches only report 10% to 20% under certain circumstances such as rapid cycling. Perhaps you’d like to explain what extreme circumstances you created to get you your inaccuracies?
I don’t seem to be having the issues your new R290 system appears to be having. I see reports of startlingly similar outdoor temperatures and the corresponding consumption figures are likewise reassuringly similar. See below two different days. 3rd January 2026 and 10th January 2026
And 10th Jan chart
Great, so you have proven that MELCloud is consistently inaccurate! That doesn't prove in anyway that the estimated values from MELCloud are accurate, you need a third party source of information for that.
So @robs you say MELCloud is consistently inaccurate yet the above charts are generating only temperature graphs are you saying these are inaccurate?
To my knowledge this is taken straight off the system thermistor… not even 2% inaccurate. So once again your blanket statement that MELCloud is useless is totally misleading
in the end the calculated energy figures are exactly that- calculated and the manufacturers confirm that they are estimated. The issue of distortion of data is brought about when operating under exceptional circumstances such as rapid cycling etc.
Whereas the use of comparative data like the energy consumption of 2 similar operating day temperatures like the two graphs above show very similar consumption figures when both in setback. This suggests to me that the same operating temperature for a 24 hour continuous operation period like the one below is accurate enough to demonstrate that setbacks do save energy.
In the end it’s about knowing the limitations of a system and that good-enough is sometimes all that is needed. We have had as much as 8.4 kWh saving by using a setback in colder climate days compared with a 24 hour continuous heating day at the same outdoor temperature. Obviously that isn’t just on the defrost saving it is also made up by the energy saving by not having the heating on during the setback period.
So to be clear the 8.4 kWh saving I quoted above is also an estimate by comparing TWO similar OAT 24 hour periods. One period having the heating on continuously for 24 hours and one period having the heating on but operating the setback period over night.
This post was modified 3 days ago 2 times by SUNandAIR
In the end it’s about knowing the limitations of a system and that good-enough is sometimes all that is needed.
I don't have any problem with the concept of 'good enough', I use it all the time (has its origins in medicine), along with the related great being the enemy of the good. But we have to be very careful indeed of a single comparison (effectively it is n=1 (comparison) from n=1 property). One swallow does not a summer make. Your findings might be true, they might be close to true, and therefore maybe good enough, or they may arise from natural (random) variation), or they may be out because of bias (systematic as opposed to random error) eg your monitoring is up the spout.
I will leave it to you and @robs argue the pros and cons of MELCloud, because you both have access to it which I don't. I look forward to a sensible conclusion without too many black eyes along the way, if you feel the need to attack, attack what is being said, not the person saying it. The only thing I would say is that when relying on manufacturer generated data, it is very prudent, I might even say essential, to have a way of checking that data through independent measurements. On my Midea setup, I check the energy in against an independent kWh meter that supplies only the heat pump (and yes the Midea data does under-report energy use, which I deal with by using an averaged over time correction factor), and the energy out by confirming the Midea reported flow rate against an independent analogue flow meter, and the delta t from careful IR thermometer readings on the pipework (and yes that is far from perfect for absolute readings, but for a delta t ie a difference measurement, it is hopefully good enough, as any error will occur on both readings).
Meanwhile my monitoring system continues to collect data. I had a look at using degree hours to find similar days, but it is no better than mean OAT, in fact they are effectively the same thing, just different ways of expressing it:
Midea 14kW (for now...) ASHP heating both building and DHW
Yes @cathoderay, thanks … one would think that is how it will be.
I have no axe to grind about Open Energy Monitoring… it’s been very useful to see different systems in a fuller detail. And if you like data it might be what you want. But it does come with the added commitment of monitoring time that doesn’t suit everyone.
It seems Obvious you get a lot of pleasure using and evaluating your data. Nothing wrong with that… we all have our strengths.
Data is very, very useful but it’s not the whole story or the only method of understanding, monitoring and controlling a heat pump. And in discussions It’s important to show mutual respect.
Some of the moderators of this forum post data from OEM, so I'm not the only one doing that. Other forum contributors have also stated that they own OEM monitoring kit, so I'm not the only one doing that too. Are some of the moderators and other contributors also advocating the buying of things from OEM?
...
In the interests of clarity, @robs, I need to make some minor comments.
The dongle you're referring to is not OEM. Mitsubishi have never produced an addon quite like it, so it's not accurate to call it original equipment. It is in every sense an independent third party piece of kit.
Secondly, the key part of the dongle is the firmware, and that is open source, posted on Github. It is centred around an ESP32 microprocessor, so anyone wishing to buy their own ESP32 board and solder a couple of appropriate connections to it could download and apply that firmware to it and have precisely what the developer sells.
Thirdly, I'm assuming, by "some of the moderators", you mean me. That is correct; I have a Mitsubishi Ecodan and use the CN105 dongle to gain local control of it. However, when the developer first joined the forum I did remind him of the fine line between forum contribution and product promotion, and he has remained helpful and within the spirit of the rules at all times since. Rereading the post @sunandair refers to, I'm inclined to apply the same comments to it that I made to the developer of the dongle. Nonetheless, the ideal would perhaps have been for you to link to the Github repository (where all the documentation and helpful stuff are anyway) rather than the marketplace.
If I am being accused of posting a link to the OEM marketplace and admonished for doing so, then can I see the evidence please? Using the forum's search facility I've put images of every instance of openenergymonitor (which hosts their marketplace) and heatpumpmonitor (that links to the openenergymonitor site) in my posts to this thread below. As you can see that while I have repeatedly used the text "heatpumpmonitor.org", I have not created any links. And the only instance of openenergymonitor in my posts is from quoting one of @cathoderay's posts. You will also please note that I an not alone in using text and not links for heatpumpmonitor.
Finally, "other people are doing it too" is never going to be a great argument. If you'd been found to have posted something inappropriate and I'd done the same thing, I'd expect both our posts to be removed or edited notwithstanding my moderator role here. If you want to argue the legitimacy of anything you post, it would be far better to refer to the rules directly - which are objective and stable - rather than the actions of others.
Two moderators, James using OEM's data and Cathoderay putting the text "heatpumpmonitor.org" into his posts, does legitimise it and seem to set a precedent though.
@robs I have to query your ridiculous accuracy figures of MELCloud
when I find your comment ill post it here…. Rob, You state…. “You continue to use electrical consumption estimates that can be 40% to 60% inaccurate”
The general consensus on web searches only report 10% to 20% under certain circumstances such as rapid cycling. Perhaps you’d like to explain what extreme circumstances you created to get you your inaccuracies?
Here's a couple of examples:
10.7 kWh estimated vs 7.3 kWh actual => 46.6%
12.1 kWh estimated vs 7.6 kWh actual => 59.2%
No rapid cycling, a few cycles off due to the IAT rising too high but nothing exceptional.
So to be clear the 8.4 kWh saving I quoted above is also an estimate by comparing TWO similar OAT 24 hour periods. One period having the heating on continuously for 24 hours and one period having the heating on but operating the setback period over night.
If you reduce (in fact almost eliminate) the over-estimating for 8 hours of the setback period then you will reduce the over-estimating by around one third for that 24 hour period.
If I am being accused of posting a link to the OEM marketplace and admonished for doing so, then can I see the evidence please?
No, you’re not. If I or any of the other mods felt a need to take any action, we would do so. Oblique accusation is neither our style nor necessary.
I posted what I did to clarify a couple of things, first amongst them being the OEM point that turned out to be a misunderstanding. Secondly was to draw a parallel between your mention of a commercial product and Phil’s mention of the same, and to make the point both mentions were primarily informational rather than promotional. That was confirming your point, not attacking it.
As I said earlier, I haven’t been following this thread in any detail, and to be frank given how heated it has become I don’t really want to start now. It’s now a contest for who is right or wrong instead of what is and the objectivity is evaporating quickly.
105 m2 bungalow in South East England
Mitsubishi Ecodan 8.5 kW air source heat pump
18 x 360W solar panels
1 x 6 kW GroWatt battery and SPH5000 inverter
1 x Myenergi Zappi
1 x VW ID3
Raised beds for home-grown veg and chickens for eggs
"Semper in excretia; sumus solum profundum variat"
@robs I have to query your ridiculous accuracy figures of MELCloud
…. Rob, You stated - “You continue to use electrical consumption estimates that can be 40% to 60% inaccurate”
Rob :- Your inaccuracy figures could be down to anything, like tampering with your default settings.
In the graphs you posted below there are any number of possible causes.
From the simplest of explanations it looks like you haven’t removed the built in extra energy markup MELCloud carries which may be over compensating for multiple pumps - if you don’t have multiple pumps in your circulating system your MELCloud still adds a pre determined kWh value. (an estimate.) Either that or you have done something else with your factory settings. As I’ve stated I know we have 2.8 kwh standard markup on our daily energy reports even when no energy is used the FTC Program will still add 2.8 kWh to the days energy report.
Your claims of a massive inaccuracy of 40 and 60% in its estimation system is not watertight. And the ~ 3kwh over value of both your examples would equate to other comments on this forum where some people have noticed a 3kwh markup.
To my mind you can’t make such sweeping claims of errors in a system based on your own modified system.
So @robs you say MELCloud is consistently inaccurate yet the above charts are generating only temperature graphs are you saying these are inaccurate?
As I said before, it is the 33 kWh and 28.8 kWh estimates that you have annotated that are inaccurate.
So just to be clear it is not the whole of MELCloud that is inaccurate by 40% to 60%. They are accurate to 2%…. it is the generated energy estimates you say are 40% to 60%. Is that right?
Are you saying the 33kwh estimate and the 28.8 kWh estimate and for that matter the 28.5kwh estimate are each calculated so randomly by 40 to 60% that there would be no consistency or meaning to their values?
see below the graphs of the two night time setback periods and observe the 2% accuracy of the outside temperature. And then compare the energy similarity of the MELCloud energy consumption.
So in terms of temperature variance these two outside temperature graphs are very close to each other which is very rare to find in outside temperatures. Secondly the energy estimations from MELCloud for both of these are fairly similar being only 300wattHours apart out of a 28500wattHours consumption… that’s a 1% variance. That doesn’t look like 60% inaccuracy.
So now to do the same comparison with the 24 hour continuous use graph operating at roughly the same night time temperature as the two graphs above.
the 24 hour period is operating at the same cold night but with the big difference of a massive rise in daytime temperature for 8 hours. However it has also been operating continuously heating for 24 hours. (No setback over night) the 24 hour energy report from MELCloud states 33 kWh consumption. All 3 days have consistent cold nights but the 2 nights where setbacks have been used have consistently used less energy than the continuous operating night.
My point being there is no inconsistency in the MELCloud report between two of these charts which have near identical climatic conditions and identical hours of operation. And the third chart is operating in the same cold conditions but operating continuously for 24 hours. There is no reason to assume a. 60% overestimate which is being claimed by @robs. The only realistic conclusion is that operating the the system for the setback period has resulted in energy savings.
From the simplest of explanations it looks like you haven’t removed the built in extra energy markup MELCloud carries which may be over compensating for multiple pumps - if you don’t have multiple pumps in your circulating system your MELCloud still adds a pre determined kWh value. (an estimate.) Either that or you have done something else with your factory settings. As I’ve stated I know we have 2.8 kwh standard markup on our daily energy reports even when no energy is used the FTC Program will still add 2.8 kWh to the days energy report.
The FTC7 controller we have has configuration settings for pump power consumption values:
Our settings have 39W for pump 1, as that's the power consumption of the water pump, and zero for the other three. So it seems that Mitsubishi have improved their estimating system in the FTC7 and it doesn't just add a fixed value, like 2.8kWh, to account for the water pump(s).
As an aside, if your FTC6(?) is adding 2.8kWh to account for water pumps then your 8 hour (?) setback would save a third of that value (0.93 kWh) because the water pump will be off for that time.
So just to be clear it is not the whole of MELCloud that is inaccurate by 40% to 60%. They are accurate to 2%…. it is the generated energy estimates you say are 40% to 60%. Is that right?
To quote myself from a pervious post:
"it's temperature sensors are thermistors with +/- 0.5C accuracy so at a dT of 5C can introduce a +/- 20% inaccuracy (also these are installed by the installer, so the quality of the install could introduce further inaccuracy). It's flow meter is a vortex based Silka unit that is susceptible to turbulence in the water flow (so how accurate this can be is again dependant on the installer)"
So the temperatures are accurate to +/- 0.5C, the dT (hence output power) could be +/- 20% inaccurate, and the flow meter (output power again) is very dependant on the installer.
The accuracy of the energy consumption estimates seem to vary with OAT (and hence required energy to heat the house). Picking days with a range of OATs, on cooler days the estimate is more accurate (although still 15-20% out), while warmer days are worse, with a day in May last year being an "impressive" 77% greater than actual. Having now compared a wider range of OATs, it would seem that the (in)accuracy of the consumption estimates is even more variable. But days with similar OATs seem to have similar inaccuracies.
Are you saying the 33kwh estimate and the 28.8 kWh estimate and for that matter the 28.5kwh estimate are each calculated so randomly by 40 to 60% that there would be no consistency or meaning to their values?
As I mentioned before (and above), MELCloud seems to be quite consistent in its inaccuracy. So it is no surprise that two similar days have a similar degree of inaccuracy, and hence similar reported energy consumption estimates.
the 24 hour period is operating at the same cold night but with the big difference of a massive rise in daytime temperature for 8 hours. However it has also been operating continuously heating for 24 hours. (No setback over night) the 24 hour energy report from MELCloud states 33 kWh consumption. All 3 days have consistent cold nights but the 2 nights where setbacks have been used have consistently used less energy than the continuous operating night.
My point being there is no inconsistency in the MELCloud report between two of these charts which have near identical climatic conditions and identical hours of operation. And the third chart is operating in the same cold conditions but operating continuously for 24 hours. There is no reason to assume a. 60% overestimate which is being claimed by @robs. The only realistic conclusion is that operating the the system for the setback period has resulted in energy savings.
If you effectively eliminate the over reporting of MELCloud for a third of the 24 hour period (i.e. 8 hour setback) then a third of the over reporting will be absent from the reported estimate for that 24 hours. So the days with a setback will have lower consumption estimates solely due to the reduced period of over reporting.
