I do exactly the same, and also see it taking a few minutes to take notice of changes to the set point. I guess if you really want it to stop at exactly 4pm, you’ll need to give it 10 minutes notice!
@Timbones im not too bothered by it, and I can understand it may be doing some things in the background, but its the length of time it takes (especially when you put the setpoint back up) that I’m curious about - just what is it doing?
Incidentally, if you use the hard wired grid demand control contacts it turns the compressor off instantly, though leaves the pumps running.
I see similar. I think some is melcloud lag for me and I think the controller may wait a bit in case someone pushes more control buttons that would result in a very short cycle. So I setback at 1545ish to stop by 1600 peak.
1 Like
Oh that’s interesting, I wonder if the main controller or MelCloud’s own scheduler accounts for that and sends commands early or if things just happen late with it as well.
Question about how pure WC works out what to do to deliver the current flow temperature…
I understand that Auto Adapt uses historic data about how the house temperature responds to different flow temperatures in different outdoor temperatures. And I assume it also learns what the compressor needs to do to deliver the right flow temperature to achieve it but…
In pure WC (curve) mode how does the heatpump decide what it needs to do to try and achieve a flow temp without overshooting? Will it try once, massively overshoot, try again a bit less aggressively, rinse and repeat until it nears a steady state?
I ask because any time I experiment with WC it is dreadful but maybe I’m just not leaving it long enough.
Also will there a bit of settling time each time the flow temperature changes, although probably quick to settle if the change is small?
Am I understanding this correctly?
No, it’s not nearly that smart. It will race to get up to target temperature as fast as it can, and then reduce the heat output. If the heat output is still more than the radiators can emit, then the flow will keep rising until it exceeds +5°C then stops. Repeat cycles aren’t any better, and there aren’t any settings to control it like for auto adapt.
An alternative approach is to control the target temperature directly, and ramp it up slowly. This keeps the flow temperature low for as long as possible for longer cycles. It can also be good to lengthen the gap between cycles to give a chance for the system to emit some heat. See also turning off the heat pump. I found I could get much better performance this way, though I have since switched to auto-adapt.
Enabling quiet mode is another option, which limits power to 50% (level 1) or 75% (level 2), with some effect depending how oversized your heat pump is.
3 Likes
I think I keep discovering in different ways that I really need to get this new radiator installed and in the mean time AA makes the best of a bad situation.
1 Like
Results of ‘sort of’ engineering out my low loss header…
I don’t have enough data to say whether what I’ve done has actually improved performance yet, but I thought I show what can be done with a bit of Arduino hardware and some relatively simple code. My system was installed with a LLH, which I was never very keen on, but the installer was so nervous about not putting one in, I let him do it (though at his expense!). I’ve been working up a solution to ensure that there is no shunting in the LLH and so the heat pump sees exactly what’s happening in the house. The way this is now working is that the radiator/secondary circuit pump speed is being controlled to maintain 5C delta T and the ASHP side/primary pump is controlling to whatever the actual radiator circuit delta-T is. My radiator circuit pump cannot maintain 5C delta-T at all time, as you can see in the chart (towards the end - the Rads_PmpSpdSP goes to 10% PWM, which is the minimum value and corresponds to maximum pump speed. (So perhaps my installer was right to be nervous, or should just have installed a bigger pump). The control system is working very well - the delta-Ts across the inlet and outlet of LLH quickly match, meaning the ASHP control system is seeing pretty much what would happen if there was no LLH, but what I’m not sure is whether 5C is the right setpoint to use, given that I’m controlling it, the AHSP can’t actually control to that as well. (Note that the controller switches to controlling 5C delta T on the primary circuit when its in DHW mode - as per start of chart) Would it be better just to run the secondary pump at full speed and control the primary to match the delta-T or perhaps to se the SP higher - to 7C say, so that the ASHP reduces the heat input or flow temperature? It’s hard to know without knowing what the Auto-adapt control is doing, but would welcome peoples thoughts.
2 Likes
Great work Rachel. well done.
@Rachel I tested this today with my local ESP32 based serial control and it looks to be more responsive than you are seeing with MELcloud.
I turned off the heating at 4pm (call for heat was turned off at 16:00:16) and at 16:01:20 the home assistant climate control entity changed from heating to off. Emoncms see’s the power drop after 16:02 (it recieves data from HA every 30 seconds).
1 Like
Thanks Dan. That’s interesting, but I don;t think it’s MelCloud causing the problem, becuase I can stand in front of the FTC controller and see the setpoint change within a few seconds when i activate it from my NodeRed/HA interface via MelCloud. Maybe it just depends what the unit is doing at the moment it receives the command. Did you find it turns on instantly, or is there a delay then?
@Rachel what are you using to control the setpoint/call for heat? Is it a 3rd party thermostat or are you controlling the ecodan directly?
Here are a few space heating starts from my other system which HA controls the call for heat using a relay. The ecodan looks to start delivering heat energy within around 4mins of each start.
(note: the power consumption reporting on my system is offset by ~1min due to the emporia I am using reporting consumption in the previous minute)
22:35 call for heat (heat pump hadn’t been running since DHW run which finished at 15:35)
00:10 call for heat
02:00 call for heat
This seems to be the pattern my Ecodan 8.5kW has settled into when it is colder weather when doing hot water…
The black line is cylinder temp.
Things get going but are interrupted by a defrost and when it gets going again after everything appears fine for a while until we hit around 50 degree flow. I would then expect the unit to maintain this temperature while the cylinder continues to get to the 48 degree target. Except instead the temperature drops back to the return temp but with the unit still consuming around 1.4kWh until it gives up and just sticks the immersion heater on to finish.
I have seen this sequence of events repeated on a number of runs now. Surely the het pump can’t be consuming 1.4kW but nothing being delivered to the cylinder?
This was in Eco mode so I’m going to see what happens in Normal mode tonight and tomorrow.
When I was having particular trouble with my 6kW Ecodan, I had sensors on air-in, and air-out of the unit. As expected, when things go wrong, the air emerges no colder… as you say, how can heat output be less than power in?.. where is the heat going?? that is a puzzle. surely the air out not coming out warmer? Is it possible you have a reversing valve problem? dt before your defrost is 5, and healthy. it never recovers after the defrost, but why the total ‘crash’ at 13:50? power input steady, therefore compressor and pressures steady. how can the flow temperature drop and dt go to zero at that point? … Anyhow, can you look at other defrosts, and see if dt after is normally similar to dt before?
I’ve contacted Mitsubishi about this problem with my hot water cycles.
After looking at MelCloud they have suggested that my flow rate might to too low. They suggested increasing it but as far as I was concerned 20-21 l/s (as shown in EmonCMS) should be more than enough. However they said it looked like 13 l/s and have sent me the CSV output from MelCloud.
Indeed it looks like the FTC6 thinks that the flow on heating is 13 l/s and on hot water is 14-15 l/s. This would be measured by the Sika flow meter attached to the FTC6 which is on the flow a bit beyond the OSM Heat Meter.
So I think my 1st task is to work out why there is this discrepancy and fix that before carrying on working out what is wrong with my DHW cycles. Is it something to do with the placement of the Sika? Could it be that I haven’t configured the feeds properly to the My Heatpump App?
I was under the impression the only reason for having the flow meter attached to the FTC6 is as a safety cut out if flow stops and for the metering. Does anyone one know any different, for example could it be that the heat pump is being controlled in some way based on the flow rate?
I believe that the flow meter is only used for metering and data logging. You can disable the flow meter via a dip switch inside the controller.
I believe you can install a separate flow switch as a safety mechanism.
This doesn’t answer why your flow sensor and meter are so far apart of course. Might be worth physical inspection to see if there is some form of blockage?
1 Like
I’m running my Ecodan on identical flow rates as reported by FTC, but (indirect*) numbers from my heat meter suggest it’s more like 15 and 21 l/min. There’s glycol in my system, and I wonder if the Sika isn’t calibrated for that?
(*I’m inverting the maths to get the flow rate from the measured heat, SHC and dT)
Not quite the same symptoms as yours, but my unit had a wobble on Jan 20th, where the DHW kept stopping for some reason.
- 13:20 - DHW cycle starts as per normal
- 13:28 - compressor stops, CH pump switches on instead yet 3-port valve is still on DHW
- 13:36 - I turn it off-and-on-again, DHW resumes
- 13:56 - happens again: compressor stops, switches to CH pump, yet valve on DHW
- 14:00 - I increase pump speed from 4 to 5, DHW cycle resumes properly
No immersion. This is the only time I’ve ever seen this happen, and it’s not happened since. It feels like it was objecting to the low flow rate, but I have no idea if that’s the cause, or it just got confused. 
It’s being services in 3 weeks. Will keep an eye on the flow rates after then.
2 Likes
We don’t have glycol in ours, is there some configuration in the FTC settings to let it know if there is or isn’t Glycol? AFAIK the OSM heat meter is set up to assume no Glycol.