Test Setup:
Device-A: BACnet/SC Hub
Device-B: BACnet/SC Node

Scenario:
Device-A (BACnet/SC hub) and Device-B (BACnet/SC node) are connected via BACnet/SC. When the IP address of Device-B (BACnet/SC node) is changed without a cold restart, the Secure Connect Stack in Device-B remains in the CONNECTION state with Device-A.

Upon changing the IP address of Device-B, Device-A closes the WebSocket connection immediately. Device-B then sends an heartbeat request to Device-A, expecting an acknowledgment. However, due to network disturbances, no acknowledgment is received from Device-A. Consequently, Device-B continues to send heartbeat requests every 30 seconds for health checks over a period of more than 12 minutes. After a timeout, Device-B closes the connection and sends a new connection request to Device-A, which is then accepted, establishing the connection after 12-20 minutes.

Clarifications Needed:

  1. Should Device-B (BACnet/SC node) be restarted during IP address changes to ensure the BACnet/SC Connection Accepting Peer State Machine returns to the IDLE state and the connection is established immediately?

  2. Is it correct for Device-A (BACnet/SC hub) to close the WebSocket connection immediately when the IP address of Device-B (BACnet/SC node) is switched?

  3. According to section YY.6.3 Connection Keep-Alive in ANSI/ASHRAE Addendum bj to ANSI/ASHRAE Standard 135-2016, connections may be kept alive for as long as the WebSocket connection maximum lifetime allows, which is a local matter. Is Device-A (BACnet/SC hub) right to close the WebSocket connection immediately?

  4. What is the potential fix for this issue, and should it be implemented in Device-A (BACnet/SC hub) or Device-B (BACnet/SC node) to resolve the network outage?

 

Last edit: kaushik piparotar 2025-03-22