After bricking my UCM/ETH03 during the firmware upgrade I've now received it back from Laser who kindly re-flashed it to 7.150 for me (discussed and resolved on another thread)
So, I'm now on the latest firmware on Comfort, Slave and all UCMs and the issue has gone away. I've been connected to port 1001 for an hour or two now now with no timeouts so far
From memory, I *think* I re-tested it with everything upgraded except the UCM/ETH03 (which was the last one I was doing before the upgrade failure) and it still timed out. So, that implies the bug must have been in the old 7.098 firmware
There is no known bug in 7.098 but there may have been imprivements since then (2017).
UCM firmeare upgrading is generally error-free. If you have any problme, please repeat the firmware upgrade imediately
I can see why koocyrat's MQTT bridge times out in my case - there is a bug because it incorrectly assumes that receiving a message FROM Comfort resets Comfort's connection timeout counter. It only sends the 'cc' echo command when there has been no message RECEIVED from Comfort for 30 seconds. So, where there is little/no comfort activity it will stay connected as it is regularly sending the 'cc' echo commands to keep the connection alive, but when there is a lot of zone activity for example it never sends a 'cc' so it will timeout 2 minutes after the last command was SENT.
I will work out a fix for this and post on the relevant forum thread in case anyone is interested. However, Eth03 Ports 1 and port 2 still behave differently for timeouts – on my system both are set to 2 minutes. Just using Comfigurator I can see a difference:
Comfigurator with Port 1 will timeout (i.e. I receive an LU00) if no commands are sent for 2 minutes, which seems to be the expected behaviour.
Comfigurator with Port 2 seems to stay connected forever (well, for at least 5 minutes when there was no activity in the UCM I/O monitor window, which was well beyond the timeout period). Surely comfort should have timed out after 2 minutes?