Monitoring & Controlling Ecodan via CN105

Hardware Heatpump
308

That’s fantastic @ajdunlop - very helpful,

Apologies for the long post but here is the breakdown (Summary and Next Steps at the end)

Detailed Breakdown (Ordered as per logs)

Lines 28 and 303: Read from FTC

DHW Temperature Setpoint = 10.00

Line 425 and 427 - Write from MELCloud Adapter:

Set System Power = On
Set DHW Mode = Eco
Set Zone1 Heating Mode = Fixed Flow
Set DHW Setpoint = 46.00
Set Zone1 Flow Setpoint = 15.00
Set Zone2 Flow setpoint = 20.00


Line 438 and 439: Internal Debug Messages

Successful write to FTC
MQTT Published to Home Assistant with updated parameters

Line 440 - Write from MELCloud Adapter:

Set Zone1 Thermostat Target = 29.50


Line 446 and 447: Internal Debug Messages

Successful write to FTC
MQTT Published to Home Assistant with updated parameters

Line 448 and 447 - Write from MELCloud Adapter:

Set DHW Force Boost = On
Prohibit Zone1 & Zone2 Heating = On (Would only apply if in Server Control Mode)


Line 454 and 455: Internal Debug Messages

Successful write to FTC
MQTT Published to Home Assistant with updated parameters

Line 474 - Write from MELCloud Adapter:

MELCloud Comms Check Heartbeat Message = On


Line 480 and 481: Internal Debug Messages

Successful write to FTC
MQTT Published to Home Assistant with updated parameters

Line 565 and 566 - Write from MELCloud Adapter:

Set System Power = On
Set DHW Mode = Eco
Set Zone1 Heating Mode = Fixed Flow
Set DHW Setpoint = 10.00
Set Zone1 Flow Setpoint = 15.00
Set Zone2 Flow setpoint = 15.00


Line 575 and 576: Internal Debug Messages

Successful write to FTC
MQTT Published to Home Assistant with updated parameters

Line 577 - Write from MELCloud Adapter:

Set Zone1 Thermostat Target = 29.50

Line 583 and 584: Internal Debug Messages

Successful write to FTC
MQTT Published to Home Assistant with updated parameters

Lines 731 and 982: Read from FTC

DHW Temperature Setpoint = 10.00

Summary

What i am suspecting from the above is Home Assistant is actually providing you the resolution to see some kind of conflict occuring between MELCloud and Havenwise writes,

We see at the start DHW Setpoint is 10.00

MELCloud then writes a setpoint of 46.00 in addition to some other parameters, which this update is subsequently published to HA

Shortly after, MELCloud then writes again in addition to some other parameters - this time a DHW setpoint of 10.00, which this update is subsequently published to HA

The reads from the FTC at the end of the log, we see DHW Setpoint is 10.00

There are no writes from HA are observed in this log

Next Steps

Do you have a setpoint of 46 in MELCloud? It looks like this figure is written first and then Havenwise? sets it back to 10 just after

I presume, based on the data above, you will see similar changes on Zone2 flow setpoint between 15 and 20?

I had to double check the Force DHW Boost request from MELCloud - i don’t understand why

It appears to be a not pretty set of conflicting and contradicting set of commands to your FTC…

309

Thanks for looking into this for me @F1p

Havenwise uses MELCloud to control the FTC so are you saying there is some problem with how they are doing this?

When I just have the MELCloud adapter connected straight to the CN105 connector rather than via the ESP dongle this problem goes away. I can verify this as I have the EmonHP setup.

You might know all this and I’ve misunderstood.

310

I don’t have a Zone 2 but looking at the data recorded for its setpoint it looks to have been at 20°C during the period recorded.

311

I’m not saying that there is a problem in doing this, but i also don’t and wont get enough information on the MELCloud side to see how they choose if the MELCloud frontend or a 3rd party integration is the “desired” setpoint.

My understanding is that the MELCloud API is an undocumented and never truley supported solution for 3rd parties and subject to change (e.g. MELCloud Home transition)

When I just have the MELCloud adapter connected straight to the CN105 connector rather than via the ESP dongle this problem goes away. I can verify this as I have the EmonHP setup.

Do you mean you don’t see the spikes because home assistant isn’t reporting Setpoint anymore? Am i correct that EmonHP would only see actual?
I think it will still be happening, you just cant see it unless you are refreshing the main controller very quickly (its probably only 46.00C for 2-3s)

312

I can’t see what the setpoint is unless the the ESP dongle is connected in HA.

But with EmonHP I can see that the short hot water cycles aren’t happening when the ESP dongle is disconnected as the flow and return temperatures don’t change.

When this behaviour is happening I can see a spike in the return then flow temperatures as it switches the 3 port valve and the water being pumped around has the slug of warmer water that was sitting in the cylinder coil.

When it is happening it looks like this in Emoncms:

image
image1095×488 117 KB

I don’t see this behaviour when it is just the MELCloud adapter connected.

313

Ah, that’s the info from the original problem statement that i think i was missing

So that appears to be coming from for Forced DHW request MELCloud made:

Line 448 and 447 - Write from MELCloud Adapter:

Set DHW Force Boost = On
Prohibit Zone1 & Zone2 Heating = On (Would only apply if in Server Control Mode)


Line 454 and 455: Internal Debug Messages

Successful write to FTC
MQTT Published to Home Assistant with updated parameters


Line 737: FTC Status Read

Forced DHW = On

I don’t see in the log file the cancel request which must be switching that off again,
It doesn’t explain why you see a difference with the bridge connected or not, but the force hot water request came from MELCloud…

Edit afterthought: Potentially MELCloud and it’s boost request is actually being fulfilled by the bridge when it isn’t usually? Maybe we can try and capture the log of the stop request too

314

What happens if you disconnect Havenwise?

315

Interesting so could be something to do with the boost requests coming through as well as the setpoint temperature.

This is what Home Assistant has recorded for last night. As you can see only the longer boosts have the setpoint adjusted.

image
image1152×505 17.8 KB

I’ve asked Havenwise if they can let me know what they changed in MelCloud during that period so we can see why it is ending up as this when the ESP is involved.

If I see the behaviour happening again later I will capture for longer to maybe get a couple of these events.

Thinking about it, could the ESP home be changing the order or timing of the commands coming through from MelCloud such that the force boost and setpoint changes happen in a way that the FTC itself cancels the boost because its still on the 10°C setpoint so it thinks the heat up is complete or not needed?

316

That would be a bit tricky as we could end up with cold water.

I guess it the FTC would just go back to trying to achieve whatever setpoint is set up on it.

317

Yeah that’s right, as long as it is set up in the controller correctly then hot water would operate as normal.

The order is the same, as the messages come in they are transferred and written to the FTC. It could be some kind of race condition observed which the bridge is breaking because it’s handling and negotiating both sets of communication.

It would be interesting to isolate Havenwise from this because there are around 200 connectors out there with MELCloud parallel which haven’t reported forced hot water requests

318

It’s also not very economic to force a boost, it will run the pump at full power and ignore the economy features (is this the intention?)

It shouldn’t need forced unless the schedule is prohibiting running

319

Response from Havenwise:
“1915, we started a hot water cycle. This sets power to on, sets the target temperature (in this case to 46C), and sends a hot water boost command. This is repeated periodically until the tank is at temperature. This cycle finished successfully at 2015.”

So it looks like the dongle is cancelling or reverting the requests for a while until eventually one sticks.

320

I have passed this on to them.

321

It would be ideal if we could log over the period that this happens

322

Hot water temperature is currently high due to lots of sun but children about to have showers might cause a drop and for the behaviour to start again.
I’ll try and capture it then.

323

Thanks - the duration of each boost request seemed quite consistent, how long are each ‘on’ and ‘off’?

324

It has started again, I missed the start but will try and capture the telnet for as long as possible now.

Here are some timings for the most recent runs:

image
image1170×2216 173 KB

325

I would be interested in capturing the end, where is transitioned to Off if possible please

1 Like
326

Rubbish I think my iOS telnet app only keeps a certain number of lines in its output so probably has lost the interesting bits

327

I’ll have to try again tomorrow from a proper telnet console where I can pipe to a file.

1 Like