Monitoring & Controlling Ecodan via CN105

It may not be directly related to your situation - we see in the logs both setpoints are coming from MELCloud directly.
What @gekkekoe and I are saying is that changes you make on the MRC unit will adjust the value to back within the range of 40-60 and reinforces this method of prohibiting DHW isn’t totally robust.

It may be worth saying that rival app MELPump natively supports the ESP dongles and also has smart features, although i can’t compare like-for-like with Havenwise

my repo now also has German translations.

Regarding energy reporting, is 0.1kwh the minimum unit (when no external energy meter is connected)?

My unit in particular seems to use 1.5kwh per day just idling (all pumps off), which I find a bit absurd. So I was wondering if I could get some help from the numbers to find the real culprit.

At least when looking at the values over one day, it does not seem to increase at a constant rate, which points at more than passive component usage.

The ecodan have quite some ‘idle’ usage. It eats around 30w here when doing nothing with some peaks. But this is generally ‘known’ ? I have an actual energy meter and it uses around 0.8kWh a day here idling.

Samsung users have recently identified an intermittent ~60W draw by the compressor seal oil heater - see Samsung HTQuiet 8KW Idle power consumption 60W?.
Maybe something similar on the Ecodan?

I have been working on quite a significant update to my project, moving the weather curve calculation from the controller to the ESP - which i know several other people have already implemented performing the weather calc somewhere else and feeding in the result.

This overcomes some limitations with the Ecodan and allows some advanced features:

  • The Ecodan Main Room Controller (MRC) has the ability to design a curve with a maximum of 3 points, there is no limit to the number of points which can be sent to the CN105 Ecodan Bridge device.

  • There is also no ability to add an +/- offset to the current curve remotely, only by adjusting on the the controller screen. By moving the curve onto the CN105 Ecodan Bridge, an offset can be adjusted remotely.

  • The Ecodan uses the Outside Air Temperature sensor located on the back of the outdoor unit, this sensor can be influenced by the likes of direct sunlight. By moving the curve onto the CN105 Ecodan Bridge it’s possible to use another temperature source to determine the flow temperature.

  • The Ecodan cannot automatically adjust for other influencing factors, such as wind or solar gain. By moving the curve onto the CN105 Ecodan Bridge it’s possible to automate the offset when conditions may influence the building.

The device can continue to calculate and input to the curve if the connection is broken.

There are challenges to overcome - primarly making it user friendly to design and input to as currently it’s a bit too manual, updates as they come :slight_smile:

2 Likes

Sounds excellent.

The big win would be to enable adjustable hysteresis on the flow temperature.
Currently the FTC only supports this in Auto Adjust mode where you can tell it how much above and below the temperature it is targeting it is allowed to go.

On systems with emitters that aren’t large enough this can help with cycling and efficiency.
It needs to be adjustable as different buildings will be able to cope with different amounts of over and undershoot before it feels uncomfortable.

Our Ecodan R32 8kW seems today to be drawing a constant 20W with increases to 40W.

I think this is normal but definitely hits the COP at this time of year when there is a lot of not running time.

@ajdunlop mine does that too, 2 x 11.2kW R410a units in cascade.

Sounds interesting @F1p watching with interest and look forward to testing it out when you are ready for feedback :slight_smile:

Does anyone by chance have access to FTC5 firmware updates?

I’ve got three different versions on my FTC5 controllers (master, slave 1, slave2) and I’d like to get them all on the same version before the next heating season.

1 Like

@ajdunlop

FYI, another user has reported similar Havenwise behaviour occuring - these stop/start requests from MELCloud and forced boost

I’m just not sure how it can be fixed - the bridge is only sending on the requests from MELCloud so it must be some kind of luck (or bug) that without the bridge it doesn’t occur…

1 Like

@ajdunlop

I’m not particularly confident in this, but I moved the routine ‘heartbeat’ that MELCloud performs to just between the Bridge and MELCloud - this keeps the FTC freed up a little bit more.

If you have an opportunity, it’s included in the 6.3.0 Fork:

Sorry @F1p I have stopped using Havenwise now.
It is good but my setup is a bit complicated to work well with it.