Issue
BACnet devices not found but are visible in other third party BACnet applications
An update may cause devices to go offline
Product Line
EcoStruxure Building Operation
Environment
- BACnet IP Network
- Building Operation EnterpriseServer
- Building Operation Automation Server (AS, AS-P, AS-B)
Cause
According to BACnet routing rules, each BACnet Device should have a unique BACnet Instance ID and each BACnet Network should have a unique BACnet Network ID
When a BACnet interface is created on an EBO Server, a BACnet IP network is created with default Network ID of 1. This is a local Network address and in not published on the network, it is therefore not a problem if this is duplicated with other EBO Servers. On many site this will remain at 1 for multiple EBO servers with no problems.
If a third party BACnet device uses a published Network ID that is identical to the EBO local Network ID, then it will be ignored.
There will be a "Duplicate of local network" System Alarm and line similar to below in the trace log
"nsp.pin.BACnet Device <device name>claims to be router to Network #1234 but that is a local network (BACnetMain)"
Resolution
If the EBO Server is not finding a BACnet device on a different network type (via BACnet routing like MSTP or virtual IP) then it could be the Network ID is identical to the local EBO Server Network ID. If this is the case, then simply change the EBO local Network ID and retest.
BACnet Devices on the same IP network, including those on different IP subnets and linked via BBMD or Foreign Devices are not BACnet routed and therefore will not have this issue (no BACnet Network ID route is involved)
Some earlier versions of EBO did not ignore these duplicate Network IDs, thus when up grading some devices could go offline. The workaround would be the same.
The correction to the BACnet operation occurred in v1.9.3 and v2.0.2
