I assume that temperature setpoint drop causes the boost turn off
Hi @F1p I have finally managed to capture a telnet output from when the short DHW cycles are occurring till after an actual run that happens after.
DWG_problem.txt (185.3 KB)
It was roughly between the two arrows:
Some bad news unfortunately, the logs appear to be from the wireless thermostat simulator (CNRF) bridge
Ah poo, wrong IP address!
I’ll try again when I next catch it.
Ok @F1p I have, I hope, managed to capture from the correct ESP Home.
DWG_problem_2.txt (703.1 KB)
DWG_problem_3.txt (978.7 KB)
DWG_problem_4.txt (308.1 KB)
My telnet connection dropped a couple of times, hence why it is in 3 files. But hopefully I captured the key parts.
Yeah that captures it yes - there appears to be a constant loop that happens:
- MELCloud Sets Temperature at 46
- MELCloud Forces DHW Boost
- (Boost Starts)
- MELCloud Sets Temperature at 10
- (FTC now stops boosting hot water because Setpoint < Actual)
- MELCloud Sets Temperature at 46
- MELCloud Forces DHW Boost
- (Boost Starts)
- (continues)
It looks like there are a few disconnects between the Bridge and the FTC and that’s why it “stuck” once, because the FTC wasn’t actually connected to the bridge when the Set of 10 was requested so it couldn’t pass the request on
As Havenwise is the only thing that can set a target of 10, do you know what the logic is that triggers it?
I don’t know Havenwise’s logic but I can ask them questions.
They have told me for when this has happened in the past that they just set the heat pump power to on, the target to 46 (my set point) and enable Force Boost and that they repeat this periodically in case there is a connection issue.
They aren’t sending the 10° unless they want to end the heat up.
This doesn’t happen when the dongle isn’t there forwarding the MELCLoud. I don’t understand how this communication works, does the dongle send back an acknowledgement to MELCloud when it sends a message through to the FTC or forward one back from the FTC?
From the logs, this is what we see being sent ‘mid-run’ so it would be interesting to understand the logic behind it
The forwarding works as so:
- On connecting to the FTC, the bridge requests the current state of data and retains it in the bridge memory
- It then periodically checks the FTC for changes, updating the bridge memory with the latest information
- The bridge then pretends to MELCloud that it is a FTC, replying to its requests with this retained information
- If MELCloud wishes to write, the Bridge accepts the request as successful (optimistically) as it pretends to be the FTC and immediately passes this request onto the real FTC (which can succeed or fail and be reattempted)
Thanks for the explanation.
Forgive me if this makes no sense at all but…
Is there any way the setpoint change and force hot water changes happen really close together so somehow the bridge’s state hasn’t had a chance to update and this gets fed back to MelCloud on the subsequent request making it think the temperature is still 10°C when it has actually been increased. Or something…
The setpoint change and then force hot water writes are close together, appear to be sequential requests from the MELCloud unit
The MELCloud unit doesn’t request the status of hot water operation immediately, so doesn’t see it is active - i think it even then reports back to the MELCloud servers quite slowly too.
One of the advantages of the bridge speaking directly with the FTC is that is can poll 2-3x faster than MELCloud tpyically does - so it does appear to have the updated hot water status before MELCloud unit asks for it.
Potentially there is Havenwise logic, to stop & re-try if hot water did not start within a certain time frame?
Reply from Havenwise “We don’t stop a cycle during the checks if it hasn’t cycled. All we do each time we check is force hot water mode, then set dhw setpoint”
What inputs cause a cycle to be stopped (by setting temperature to 10)?
This is an interesting comment @ajdunlop
It might revert to within the bounds of the limit if you press something on the main controller.
Not that I am suggesting this is what is happening - however it’s perhaps not the best way to do this prohibit
Interesting, I’m not sure I completely follow what’s happening in that thread but could it be something to do with my CNRF dongle ‘correcting’ the 10°C value?
I think the issue above is slightly different however, because in the logs we observed MELCloud writing the 10°C and ending the run.
CNRF I don’t have any way currently to change temperature of DHW, only to run the force boost.
You presumably left it connected when you had MEL only?
Yes CNRF dongle wasn’t touched so probably nothing to do with that.
I think you should not set values outside the ‘available’ range defined in the MRC (main remote controller if I’m not mistaken, the main screen of your ftc). See the link above, I reverted the ability in my project. It gave inconsistencies when changes are made in the MRC. Your setup is affected if Havenwise sets temp < 40c.
Does MRC stand for?
Main Room?/Remote? Controller
Ah ok.
Although why would this range only be ‘enforced’ by the controller when MelCloud is connected via the ESP Home dongle and not when connected directly to the FTC?