You could maybe use an EmonTH with one or two ds18b20 probes on it??
To not get up to 48°C in 1hr 20min seems suspicious - like the 3 way valve is passing and some of the heat is being delivered into the heating
Or is it hitting the 90min limit in the controller?
The Carnot COP for when its heating from 25-50c is about 43% . that is only a little bit low. (Mine is around 46%). Heat output 5.5-6kW.
@ajdunlop I occasionally have the same problem as you, but not quite so dramatically. A week back I decided to move the temperature sensor to a different pocket on the tank; it didn’t make any difference, but then I realised that the installer had not pushed it all the way in originally and had then put a cable tie on which meant that I couldn’t push it all the way in either. I’ve now rectified that and I’ve added some heat sink compound to the sensor. The result has been dramatic in the change in reading and the speed with which the sensor now picks up the rise in tank temperature. I’ve done the same with my other tank sensors. You can see that I got an instant increase in measured temperature of nearly 10C and that the ‘mid T’ (which is actually located about 2/3 of the way up the coil) now sits with the top C. The ASHPTDHWTemp probe is in the same pocket as the top T sensor, but I only read that from the API every 15 mins.
This image is from before I fixed the temperature sensors and you can see the CoP drops below 1 , 40 minutes in. Overall the temperature rise here is about 10C over an hour.
This image is from the new sensor arrangement. It’s a slightly lower temperature rise of about 8C, but it does it in about 30mins. The CoP is much higher (slightly higher ambient) and there is no collapse below 1.
Now I’m going to disappoint you by saying I have seen it do the weird stuff since, but only once so far and that was a 3C night run. You noted that it does it more in ECO mode, so if the problem is that the ASHP DHW sensor isn’t getting an accurate reading, that could be a problem (more in ECO than NORM) because it’s possible that the ASHP isn’t ramping the flow temperature fast enough - i.e. the tank temperature is getting to the point where it’s possible that the bottom part of the coil is putting heat into the tank and the the top part is taking it out again!
I don’t think it’s going to solve the problem completely, but just making sure those sensors are pushed fully into the pockets and ideally putting some heat sink compound on them might help (if you’ve not already done that).
2 Likes
@Rachel after your post I put some paste on the lower sensor that is used by the Ecodan when heating up. However I have since had another bad DHW warm up.
I did also put paste on the flow and return sensors connected to the FTC. This looked like it does make a difference to how quickly these sensors change with changing temperature and much more closely match the in pocket sensors of my EmonHP. This has allowed me to remove the adjustments I had applied in the FTC settings.
I think this might help the performance generally but the dips are still happening when the outdoor temperature increases and the heat pump is trying to reduce down the flow temperature. It looks like the dips are more likely something to do with the control of the expansion valve or the refrigerant temperature sensors.
I really think installers should really always be installing the flow and return sensors in pockets or there could be all sorts of performance issues caused by saving a few minutes and pounds.
2 Likes
I’ve been following this Dutch forum that discusses Ecodans:
Mitsubishi Electric Ecodan Lucht/Water Warmtepompen - Duurzame energie en installaties - GoT
Some interesting things when things aren’t lost in translation.
2 Likes
Following on about the above forum…
Unfortunately I can’t register to ask questions there as it’s only open to people in the Netherlands.
The majority of posters have split systems but a few have monoblocks.
An interesting topic is the options for quiet mode. Before FTC6 the way of doing this was to attach a cable to the CNDM connector on the outdoor unit and then there were 2 ways of reducing noise,
This as well as the FTC6 way are described in this post.
https://gathering.tweakers.net/forum/list_message/70363414#70363414
Posts by this user suggest the cable method can still be used on the PUZ-WM units (although might be a bit different).
https://gathering.tweakers.net/forum/find/poster/1020969/messages
Now you might be wondering why I should care if I can now set up quiet mode on my FTC6. Well I’m interested in the fact that there was 2 types of noise reduction available.
One was to limit the compressor consumption. This to me sounds like what the quiet mode in the FTC6 does.
However the other one looks to reduce the max RPMs of the fan.
My unit can be a bit noisy when it gets cold. I think in my case this is more caused by the fan noise than the compressor so if there was a way to experiment with running at a lower fan speed to see what effect this has on noise but also what impact it has on performance I might give it a go,
Does anyone know anything about this on here?
2 Likes
FTC6 has two quiet modes, which I believe to limit the compressor to 50% and 75% respectively (oddly the opposite order to what’s documented on the forum). I would guess than the fan speed scales with compressor, so would expect quiet mode to also reduce the speed of the fan. I’ve not measured it myself.
Are you looking to reduce the fan speed without limiting the compressor?
The very old ecodans has options to reduce either fan or compressor, then I got the feeling they simplified it and dropped both speeds together. I had assumed that it would compromise efficiency a bit , I have been using it on my 6kw… partly to stop it revving up so much. Will be interestingly to hear your findings
1 Like
@johncantor et al.
The CN105 work done by @gekkekoe and @F1p now means that it is possible to read and log out to Home Assistant or elsewhere the values that can be accessed from the ‘Running Information’ on the FTC.
This includes Fan Speed, LEV A pulses, readings from TH4 (discharge temperature), TH3 (Refrigerant Liquid Temperature), TH6 (2-phase Temperature, TH8 (Heatsink temperature) and TH32 (Supercool Temperature).
I don’t know if this will be helpful for looking at some of the strange behaviours we are seeing with our units.
The resolution is fairly low but I believe can be increased but I’m not sure what the limitation on this is.
It’s possible to get LEV A,B & C if required - initially i was awaiting feedback as to what parameters are of most interest/use and at what resolution.
Then the refresh rates can be optimised to match
1 Like
Keep in mind that polling a service code cost around 5s. It’s quite expensive. Subcool and superheat can be calculated, so I did not retrieve them.
Its ‘free’ on FTC7 so, thinking of a way to do this cleanly
on early Ecodans, you could choose the %age drop for compressor and fan. makes sense since these are two different noises. but i think they simplified this by dropping both together. I would have thought optiminsing for noise could compromise energy efficiency, i.e. the fan might drop more than ideal. However, simply reducing capacity will reduce noise… just max output is limited.
I’m in the level 1 Quiet Mode on my Ecodan R32 8.5kW with FTC6 and it looks like the fan speed drops from about 660 rpm to 440 rpm at 6°C:
This seems like a very arbitrary way to control the fan, surely this could be more fine tuned to the refiguration cycle as I assume depending on the unit location, how iced up the evaporator is etc different fan speeds would provide better performance?
Also from a noise point of view 660 rpm is much noisier so I’d have thought gradually increasing the speed would be better.
At some point when we are back under 6°C I’ll try switching between between the Quiet Mode levels to see if the max fan speed is varied.
I still haven’t found the right connector to try the wire method that works with older models to see if I can limit just the fan speed on the PUZ-WM.
@johncantor what do you think are the most useful things to measure?
@F1p I’m finding the resolution a bit low apart from on TH3 where you’ve increased it. How many other sensors could be read at that resolution before it would start to be an issue?
@ajdunlop FTC7 user? those units can have free higher resolution of all the outdoor thermistors
I’ve published the field here: Update protocol.md for FTC7+ 0x0f fields · gekkekoe/esphome-ecodan-hp@e3b3b92 · GitHub
Yes, it does seem a crude fan speed adjustment. I could redo similar experiments. I did it once, but didn’t record it. Re old models , I have a switch fitted to outside unit PCB board.
Unfortunately not, I’m on an FTC6 with an R32 unit.
It’s a delicate balance,
In my FTC5 it takes 4.8s per service code to get the data back
Where in regular data it’s 400ms to get 5+ values out
So 12x slower and 80% less data, and this is where I draw on your expertise to determine what sensors provide data valuable enough to make this compromise
I’m no expert but the ones that I think are most important are TH3, TH4, TH6, TH34 and LEV A and maybe B.
I don’t know where LEV C is I assume my model doesn’t have it.
Not sure other sensors like TH8 or TH33 matter unless there are particular issues of components overheating.
Fan speed is interesting but doesn’t very a whole lot so this could remain low frequency.
Don’t know what other service codes there are that could be interesting. @johncantor do you find any other running information service codes useful to record when trying to work out what the Ecodans are doing?