Anyone monitoring a new R32 Ecodan?

By technology, I include a control system that is clever enough to account for the disinterested installer and Joe Public.

It also seems that the data available from most of these systems out of the box, is woeful, linked to propriety data systems, and insufficient to setup the HP properly.

It takes very little effort or knowledge to get a combi gas boiler system working efficiently and effectively. Even a poorly setup system still works and does not use an excessive amount of energy. A heat pump is in a completely different ball park in terms of the complexity to get it running efficiently, and that is simply something Joe Public cannot (or wants to) do.

Even those here who have an interest and the knowledge (or know how to ask) have trouble setting an HP up well.

In addition, there is conflicting advice as to how to set one up well!!!

5 Likes

Amen, but I think you’re preaching to the choir on a free/libre/open-source site like this! Even though we have access to lots of data through pymelcloud, it bugs the hell out of me that I sometimes can’t tell what the controller is doing and why, such as that decision-making about flow setpoint :frowning_face:

Does it, or is gas just so cheap at the moment that few care if it’s wasting 25% of energy compared to an efficient weather-compensated modulating setup? But with a heatpump and the published COP numbers, often cited to convince waverers to switch from a boiler, everyone can spot a dog of a setup running away with their wallet, especially if they have a Metering and Monitoring Service Package, even if they don’t know how to fix it.

2 Likes

It does work well @johncantor. Here’s how I work out how long to dwell when it’s on and the algorithm wants to turn it off. This makes sure it doesn’t cycle on and off too often. It’s based on the effective temperature which includes outdoor temp, humidity and wind speed:

def turnOffDwellFromTemperature(temperature: float) -> float:

    dwellTime = 500.0

    # Reduce dwell time according to how warm it is
    adjustment = math.pow(abs(temperature), 2.5)
    adjustment = math.copysign(adjustment, temperature)
    dwellTime = dwellTime - adjustment
    dwellTime = max(120, dwellTime)
    dwellTime = min(900, dwellTime)

    return dwellTime

So basically it uses magic numbers to work out the deviation from a 500 second default. Then it applies a lower and upper bound to make sure it doesn’t go crazy.

Then I hold it “off” for a while before it’s allowed to turn back on. Again that’s based on the effective temperature:

def turnOnDwell(temperature) -> float:

    dwellTime = 360.0

    # Extend dwell time according to how warm it is
    adjustment = math.pow(abs(temperature), 2.5)
    adjustment = math.copysign(adjustment, temperature)
    dwellTime = dwellTime + adjustment
    dwellTime = max(0, dwellTime)
    dwellTime = min(900, dwellTime)

    return dwellTime

Note that the smallest dwell time might be zero which means it’ll come straight back on in extreme cases. There are some other tweaks I’ve removed from this post to keep it simple, such as extending the dwell-whilst-off time during the night to save money.

Of course those numbers are magic for my setup (sort of reinforcing @borpin’s point about the technology) but hopefully it gives a flavour of an approach that can work (notably with my over-sized ASHP).

I know that :slight_smile:

Yes that is partly because of cost, but again, whole life cost - the additional running costs of a slightly inefficient system are small compared to the capital cost of a new fangled system. I’m not comparing the efficiency of an old to a new system. I’m suggesting that most existing systems could be improved by 5, perhaps 10% with a bit of tweaking. An HP can easily be 50% inefficient. That is the issue.

So I need to pay more (Metering and Monitoring Service Package) for it to tell me I’m wasting money?

This really doesn’t sell it to the public. I’ve seen a few items in the MSM that HPs were costing a fortune to run. I’d anticipate that bad press will get worse and eventually the ban on new gas systems will be put back by public pressure (esp if energy prices stay high).

1 Like

No, but if you do, it’ll be even more obvious: that’s why I wrote “especially”.

Then I think I agree with @Timbones: the technology may be imperfect but it might not be at fault as much as the boiler-sellers now installing heat pumps badly. Is it because they know no better and are happy to waste customer money, or is it that big incentive that if they mess up nastily, they can keep dumping dirty old gas systems onto the market for longer.

well done @MyForest I’m not familiar with python, but will have another look. I was considering C++ because I vaguely know that. I guess there are lots of ways of approaching it.
I would have expected Mitsi to have fathomed out ways to minimise some of the bad cycling etc that I have seen. It should be simple addition to their algorithms. It seems that getting the highest COP in all conditions isn’t on top of their list. I wonder how many years it will be before we see proper good turn-down… multiple compressors/circuit units in 1 box etc…?

1 Like

Hello David,
I have got nowhere with Mitsubishi. They are not interested in my pocking into finer details. Given that I probably cannot sell this 6kW easily, I think I will need to make a control like yours and make the best of it. My issue is different to yours. Mine is not oversized, but COP seems to ‘crash’ sometimes. I am getting excellent COPs at times and will probably spend my time working out how to control it better and minimise the ‘crashes’.
See the graph showing a big dip in output whilst the input power drops very little… it remains a puzzle!

1 Like

What was your flow-return temperature drop / delta T when that happened?

As I may have written elsewhere, I suspect that these ecodans handle small delta T badly, backing off too fast even when they don’t cycle, and that may be part of why the “auto-adaptive” (aka “room target” if the DIP switches are set a certain way) programming drives flow up so aggressively. It may result in a lower coefficient than slowly ramping up or a well-tuned compensation curve, but it reduces the number of coefficient-harming backing-off-too-much cases.

Its about 4 degrees. 17lit/min. Its an oddity with Ecodan since they always say dt should be 5 degrees, but the spec suggests 50% output is possible. If so, dt could go down to 2.5. My old 5kW is quite happy with this variation in dt. If they really want 5 degrees you would expect a speed controlled pump like other models have. Anyhow, I think you are right about new ones being sensitive to dt.

1 Like

Well the good news @johncantor is that if anyone can work out what’s going on it’s going to be you!

Please keep sharing your experience with us. It’s helpful to watch you diagnose it and maybe we might even be able to help.

2 Likes

I notice that your flow temp and dT drops at about the same time. Where does ‘heat_calc’ come from? Is it calculated from the dT, or is the flow temp reacting to the drop in heat being generated?

Also, how come the FlowRate drops off at 04:27, and yet input power and flow temperature continue to rise. Some metering issue there?

I don’t have your diagnostic vision. I am more an in-the-moment look and see sort of person. between us all, we should do OK.

1 Like

The heat is simply a flowrate X dt. The flowrate, flow temperure and return temperature are from the mbus heat meter, so should be accurate.
I think the heat output drops, and the result of this is the flow temperature drops.
Well spotted and diagnosed. The heat meter has a weird fault and the flowrate goes to zero when temperure goes above 40 or so. I have a new meter now!

1 Like

John, I see you posted a similar looking chart that crashed back in January in another thread.

I’ve reviewed my own Ecodan 11.2 kW over the past week (since getting a Sontex meter fitted), and I’m not seeing anything similar. :man_shrugging:

1 Like

Is yours R32?
I just had a look at mine for today. This shows one of the worst I have seen. It goes to dhw at 15:03. Thereafter COP is chronic. Flow rate is 16lit/min which is about right, and would give dt of about 5 if 5 to 6 kw output. Refrigeration wise, I am struggling to fathom out how the COP can actually drop so low

Yes, mine has the new R32 refrigerant - I think many manufacturers have switched over to it.

Here’s a snapshot from my own system during a similar scenario: at 18:20 it switched to heating DWH and the flow/return temperatures jump up to match the tank temperature then gradually increases up to 50 degrees at 18:35. COP is pretty poor (between 1 and 2), but not quite as bad as yours. I do note that the dT is pretty small at this point (2 degrees) - not quite sure what that means.

I’ve only had a heat pump for 3 months, and written no books about it, so I’m not sure I’m qualified to advise on your situation John. :smiley:

Your chart shows the flow temps steadily rising after 15:03 at about the same rate as mine, which make me think it could be the heat_calc that’s off rather than the heat pump itself.

Interesting graph. Your dt’s are quite close. You flowrate looks greater than Mitsi recommend.

I did a test with mine at lower flow rate. The 1st graph is flowrate slower than recommended, and COP is fairly consistent with the data sheet (my red line).


The 2nd graph is a repeat of the earlier with an approximate COP on it (my red line)
I still am no wiser as to why this should be happening.

1 Like

Hi
I’ve just installed an 8.5kW ecodan with R32. Ive only got the monitoring up and running over the weekend and currently think my flow and return sensors might be a bit to close to the low loss header or my primary pump flow is way too high as I’m getting very low delta T and lower CoP than I expect. I have my own sensors (in the same place as the Ecodan ones)and ive piggy-backed onto the flow meter output with an ESP8266. I was logging my gas boiler heat output for a couple of years before installing the ASHP, so i’m pretty sure (having compared) its a heat flow reading /calc issue rather than poor ASHP performance. I’ll post some charts when I’ve explored tye current issues!
Rachel

Hi Rachel,
I think its quite possible that your primary flow is too high. I have come across this a few times. If its only pumping to a low loss header, then resistance could be very low. If water is flowing, then it should be OK putting the sensor very close to the LLH. So…, if the dt is low, then the heat measurement will not be very accurate. Are you taking the voltage output from the Sika VFS flow sensor? . I guess your temperature sensors are not in pockets? I tend to feel you can probably get away with it if your dt is say around 5. If its 2 degrees, the temperature sensor error is becoming significant. Interested to know how you get on.

Hi John
Thanks for your thoughts…

No pockets for the sensors and since I got them under some proper insulation, the delta T has dropped to about 2C!!

I’m reading the voltage output from the Sika VFS directly on the ESP8266 NodeMCU input. Ive double checked my calcs and I seem to have a flow rate of 0.34l/s or 20.4l/m - thats reasonable for the pump curve given its a short run without many bends. It’s also within the range for the unit, but I’m only running at minimum load at the moment, hence low DT. Your point about accuracy is well made - just checked and those DS18B20 sensors have an accuracy of +/- 0.5C, so error could be huge at 2C delta!. I probably need to get a pair that are well matched even if running at 5C DT.

Rachel