Duplicate BACnet device instances: how to find and fix them
Controllers vanishing or values jumping between devices? A duplicate BACnet device instance is a likely cause. How to prove it and number a site properly.
A duplicate BACnet device instance is one of those faults that doesn’t look like itself. Instead of an obvious error, you get strange behaviour: a controller that drops offline and comes back, a VAV box showing another floor’s temperatures, or a graphic that works one day and not the next.
This guide covers why duplicates cause so much trouble, how to prove you have one, and how to number a site so it doesn’t happen again.
What a device instance is
Every BACnet device has a Device object, and that object’s instance number is the device’s identity on the whole BACnet internetwork. It’s a number from 0 to 4,194,302 (4,194,303 is reserved as a wildcard).
The key rule: device instances must be unique across the entire site, not just on one MS/TP trunk or one IP subnet. Network numbers and MAC addresses tell BACnet where a device is; the device instance tells it which device it is.
Supervisors and integration platforms, Niagara included, generally track devices by device instance. When two devices claim the same one, the supervisor binds to whichever answered last, and the other is effectively hidden.
Symptoms that point to a duplicate
- A device shows as offline or “down”, then recovers on its own, over and over.
- A device’s network address in the supervisor keeps changing between two values.
- Point values for one device suddenly look like a different piece of plant.
- Only one of two identical controllers (for example two fan coil units from the same batch) ever appears after discovery.
- Problems started right after a contractor added or replaced controllers.
That last one matters. New controllers often arrive with a factory default device instance, and if nobody changes it during installation, every replacement unit can clash with the last one.
How to prove it
In Niagara
Run a fresh Discover in the BACnet Device Manager with no instance range filter. Compare the discovered list with the database. Look for one device instance appearing against a different network address from the one in the database, or a device whose address changes between discoveries.
On the wire
The most reliable proof is a capture. Run Wireshark on the station host while discovering and filter for BACnet traffic:
bvlc || bacnetFind the I-Am replies and compare their device instance and source address. Two I-Am replies carrying the same device instance from two different addresses is conclusive.
You can also send a targeted Who-Is for just that instance (most BACnet test tools let you set a low and high limit to the same number). One device should answer. If two do, you’ve found your duplicate.
On MS/TP
On an MS/TP trunk behind a router, both replies may appear to come through the router with different MAC addresses on the same network number. Note the MAC addresses so you can find the physical devices.
Fixing it
- Back up first. Take a station backup and note the current settings of both devices.
- Decide which device keeps the number. Usually the one that’s been in the supervisor longest, so graphics, histories and alarms stay linked.
- Re-number the other device using the manufacturer’s tool or the device’s own configuration interface. On some controllers the device instance is derived from DIP switches or the MAC address, so a physical change may be needed.
- Rediscover and re-match in the supervisor. In Niagara, the existing device in the database may need matching to the new instance so its points, histories and alarms carry over rather than creating a duplicate entry.
- Check everything that referenced the old device. Links between controllers, trend logs and alarm routing that pointed at the moved instance need updating.
- Update the as-built documentation. The next engineer will thank you.
A numbering scheme that prevents duplicates
The best fix is a site-wide scheme agreed at the start of a project and written into the specification. A widely used approach for MS/TP is:
device instance = network number × 1000 + MAC address
So MAC 23 on MS/TP network 401 becomes device instance 401023. Because MS/TP MAC addresses never go above 255, every number is unique as long as network numbers are unique and no higher than 4,194. An engineer on site can also work out where a device lives from its instance alone.
| Network number | MAC | Device instance |
|---|---|---|
| 401 | 1 | 401001 |
| 401 | 23 | 401023 |
| 401 | 123 | 401123 |
| 402 | 23 | 402023 |
Avoid the shorter “network × 100 + MAC” version you’ll sometimes see: once MAC addresses go above 99, it overlaps. MAC 123 on network 401 and MAC 23 on network 402 would both become 40223.
For IP controllers, the same formula works on a /24 subnet with the last octet of the IP address in place of the MAC: a controller at 10.20.1.45 on BACnet network 10 becomes 10045. Whatever you choose, keep a register. The exact scheme matters less than having one and enforcing it.
Make it part of handover
When you commission or take over a site, ask for the device instance register alongside the points schedule. If there isn’t one, building it from a fresh discovery is a half-day job that saves days of fault-finding later.
Summary
Duplicate device instances cause intermittent, confusing faults because the supervisor binds to whichever device answered last. Prove it with a capture or a targeted Who-Is, re-number the newer device, re-match it in the supervisor, and put a numbering scheme in writing so replacement controllers don’t bring the problem back.