Connecting to both ETH03 ports?

[caravanboy]

An update on this issue...

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

[slychiu]

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

[caravanboy]

Unfortunately I spoke too soon - it seems that when I was testing at night, because I didn\'t have many comfort events on the bus it stayed connected for longer than usual.

So, I\'m still seeing the same issues as before.

Both UCM/ETH03 ports are set to 2 minute timeout.

Connecting to port 1001 regularly disconnects me even though keepalive events are being sent my by MQTT bridge.

Connecting to port 1002 is rock solid - it has been connected to that port for over 24 hours with no disconnections.

So, I can use port 1002, but it niggles me that there must be a Comfort bug somewhere. Is there any way we can investigate this further now that I\'m on the latest firmware?

[slychiu]

if you try to send a command in port 1001 every inute or so does it still log out?

[caravanboy]

Hi, yes port 1001 still times out in that circumstance - the MQTT bridge sends a keepalive every 30 seconds.
The odd thing is that with LESS comfort activity it takes longer before it times out.

I will do a test and temporarily disable the keepalives and test both ports and prove that they timeout 2 minutes after the last command was sent.

[caravanboy]

I’ve done various tests now and in conclusion: 


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?

[slychiu]

Thanks for the information 
we will investigate the behaviour of port 2 time out


 

[caravanboy]

Did you make any discoveries re. the behaviour of port 2, slychiu?

I have my workaround for now so I\'m happy enough with the current behaviour anyway

[slychiu]

I just tested again on port 2, it did time out, not sure if it was 2 minutes exactly, but after 5 minutes it was logged out