So you should try to avoid this behavior. Try to have all circuits open all the time and tune the flow
Hello! Any chance to sync the Ecodan clock in order to automatically adjust daylight savings instead of manually doing it twice per year?
The only option observed so far is read only the current controller time, and this may change with newer or future FTC’s
With Home Assistant automations and server control though you can mitigate the need to depend on controller time as HA will adjust for DST
CAn you explain more?
currently there’s no way to set the time over cn105, else I would have synced it with NTP already
What @F1p is trying to say is that you can use HA and automate everything using the clock in HA. That should work for most parts. Only the daily energy report will be off for one hour (when summer time is active)
Could someone post a plot of their LEV A and LEV B over a heating cycle.
I just want to check what I should be expecting.
@F1p is there an easy way for me to increase the resolution for these?
My LEV B seems to be either 224 or 0… where LEV A seems to be a bit more varable:
Yes if you want to poll quicker - build two automations for MQTT Publish at your desired polling rate, using Payload 22 for LEV A and Payload 23 for LEV B like this:
Thanks @F1p
I will record my LEV values for a while at a higher resolution to see what’s going on.
If I understand correctly each pulse sent to the LEV moves it on a little bit. So I assume no pulses means the valve isn’t moving and 224 means it is moving as fast as it can to a new position.
Rather than the value representing the current position.
However it doesn’t indicate the direction of travel of the LEV so it could be opening or closing.
But then I’m confused as when my compressor isn’t running both LEVs read 224 pulses all the time.
@F1p I have one of your dongles that allows pass through from the MelCloud adapter.
I’ve recently been experimenting with Havenwise that uses MelCloud to control my Ecodan.
Havenwise will set the DHW setpoint to 10°C when hot water runs shouldn’t happen and put this up to my normal hot water setpoint to trigger a hot water heat up.
However somethings when it does this it stats flicking back and forward between the bigger and lower valves every few minutes.
I’ve checked and when only the MelCloud adapter is attached to CN105 it behaves correctly but with the dongle on between I see the strange behaviour.
Any idea what might be going on or if there is any way to output any debug to try and work out what might be happening? Thanks.
Interesting - Yes, please obtain logs when Havenwise writes, you can connect via Telnet with a Client such as PuTTY and write a log file
I would be interested to see the logs over a 5-10 min period, espeically when it does this “flicking” that you observe
It is interesting that Havenwise will attempt this, because 10°C is out of range for the FTC, i tested mine, note via MQTT only:
Telnet Log of write occuring from Home Assistant:
Climate card does retain 10°C as value after a few cycles, meaning it has stuck:
But 10°C is out of bounds on the FTC, so it displays 40°C - wonder who is correct…
I disallow temps outside the range btw.
Are you able to set the temp to 10c with the melcloud UI ? Would be surprised if that worked.
I think writes are made by the 3rd party Havenwise app via MELCloud API, not the UI
10°C is a valid setpoint it seems, I tested on my unit and it didn’t start running
you were able to set it via MRC ? I know you can do it over cn105.
Not via MRC, but it’s definately set as 10 in the FTC, not 40 as per MRC
Thanks for looking into this for me.
This was what the setpoints were doing last night when the problem was occuring:
The longer periods were when the DHW run was actually happening.
I’ll see if I can catch it doing it later when it repeats and telnet the output.
Have you got any home assistant automation which might be triggering?
No, the only automation I had which I have now switched off was to do the service call to get the LEV values more often but I have seen this behaviour since this was disabled.
Also the dongle has been disconnected and reconnected since this automation was disabled.
Unfortunately (well at least for this purpose) because it was so sunny yesterday I don’t think Havenwise sent the command through that triggers this behaviour. It is a bit more cloudy today so will continue to watch.
I was away at the weekend but have just managed to capture some telnet output while the problem was happening this evening.
DHW set point problem.txt (96.4 KB)