BACnet Duplicate Device ID: Find and Fix It

Symptoms of Duplicate BACnet Device IDs

Duplicate device instance numbers produce symptoms that are easy to confuse with network faults or device failures. If you're seeing any combination of the following, a device ID collision should be on your short list:

• Flickering devices in the front-end — A device appears online, drops off for seconds or minutes, then reappears. The BAS supervisor alternates between I-Am responses from the two conflicting devices, displaying whichever responded last.
• Wrong data on read requests — A Read-Property request for a supply air temperature returns values that don't match the physical sensor. The request was answered by the wrong device because both share the same instance number.
• Control commands hitting the wrong equipment — A Write-Property command intended for a VAV damper actuator reaches an AHU controller instead. This is the most dangerous symptom—it can cause equipment damage, comfort complaints, or safety events.
• Multiple I-Am responses to a single Who-Is — A Who-Is request targeting a specific device instance range returns two or more I-Am responses with the same device ID but different IP addresses or MAC addresses. This is the definitive indicator.
• Intermittent COV subscription failures — Change-of-Value subscriptions drop unexpectedly because the subscribing client receives confirmed notifications from a device it didn't subscribe to, and the subscription context doesn't match.

How BACnet Device Instance Numbers Work

Every BACnet device on an internetwork must have a globally unique device instance number. This is a 22-bit unsigned integer stored in the Object_Identifier property of the Device object, giving a valid range of 0 through 4194302. Instance number 4194303 is reserved by the BACnet specification as a wildcard value for Who-Is broadcasts and must never be assigned to a device.

The device instance number serves as the primary identifier when a client needs to reach a specific device. When a BAS front-end or workstation tool sends a Who-Is request, devices respond with an I-Am that includes their device instance number and network address. The client then caches that mapping and uses it for all subsequent Read-Property, Write-Property, and subscription requests. If two devices share the same instance number, the client's address cache oscillates between the two addresses, causing every symptom described above.

It is critical to distinguish the device instance number from other BACnet addresses:

• Device instance number — Must be unique across the entire BACnet internetwork (all subnets, all trunks, all routers). This is the number that causes problems when duplicated.
• MS/TP MAC address — Must be unique only within a single MS/TP trunk (0–127 for masters, 128–254 for slaves). Different trunks can reuse the same MAC addresses.
• BACnet network number — Identifies each network segment (IP subnet, MS/TP trunk). Must be unique across the internetwork but is not a device-level address.

A device can have a unique MAC address on its MS/TP trunk and still conflict on the device instance number with a controller on a completely different subnet. This is the scenario technicians miss most often—the conflict doesn't require devices to be on the same wire.

How to Find Duplicate Device IDs

Finding the conflict is the hard part. Once you've identified which two devices share the same instance number, the fix is straightforward. Here are three proven methods, from quickest to most thorough.

Method 1: Wireshark Capture

Wireshark on a workstation connected to the BACnet/IP network is the fastest way to confirm a duplicate. Capture traffic on the interface carrying BACnet/IP (UDP 47808) and apply these display filters:

# Show all I-Am responses — look for the same device instance
# from two different source IP addresses
bacnet.unconfirmed_service == 0

# Filter I-Am responses for a specific suspected device instance
# Replace 310001 with the instance number you suspect is duplicated
bacnet.unconfirmed_service == 0 && bacnet.instance_number == 310001

# Show all Who-Is requests (useful to trigger I-Am responses)
bacnet.unconfirmed_service == 8

# Show Who-Is and I-Am together for the full exchange
bacnet.unconfirmed_service == 8 || bacnet.unconfirmed_service == 0

# Show I-Have responses (another service that reveals device identity)
bacnet.unconfirmed_service == 1

To trigger the conflict, send a Who-Is broadcast while the capture is running. If two I-Am responses come back with the same device instance number but different source IP addresses, you have confirmed the duplicate. Note both IP addresses—these are the two devices you need to resolve.

For MS/TP networks behind a BACnet router, the I-Am responses will show the same source IP (the router's IP) but different NPDU source addresses (SADR). Check the BACnet Network Layer source address field to distinguish the two devices.

Method 2: YABE (Yet Another BACnet Explorer)

YABE provides a graphical device tree that makes duplicates visible at a glance:

1. Launch YABE and add a BACnet/IP transport on the correct network interface.
2. Click Send WhoIs to discover all devices.
3. Examine the device tree in the left panel. If a device instance number appears twice with different addresses, YABE will show two separate entries with the same instance number.
4. Right-click each entry and read the Device object properties to identify the device model, vendor, and location.

YABE's log tab (bottom of the window) also shows raw BACnet traffic, so you can see both I-Am responses arriving in real time.

Method 3: Vendor-Specific Tools

Most BAS platform tools include some form of device discovery that will flag duplicates:

• Johnson Controls Metasys SMP/ADX — The Metasys Site Management Portal flags device instance conflicts during network discovery. Check the Integration tab under the NAE or NIE supervisory engine. The system logs will show "Duplicate Device Object Instance" warnings.
• Schneider Electric EcoStruxure Building Operation — The BACnet device scan in System Manager flags conflicting instance numbers. Check the Automation Server's BACnet integration log for conflict messages.
• Tridium Niagara Workbench — The BACnet network's device discovery table shows all responding devices. Duplicate instances appear as separate rows with the same device ID. Check the BACnet Network > Device Table view.
• Optigo Visual BACnet — Optigo's network diagnostic tool automatically detects and highlights duplicate device instance numbers across the entire BACnet internetwork, including devices behind routers.
• Contemporary Controls BDT — The free BACnet Discovery Tool performs a Who-Is scan and lists all responding devices. Sort by device instance to spot duplicates.

How to Fix BACnet Device ID Conflicts

Once you've identified the two devices sharing an instance number, follow these steps:

Step 1: Decide Which Device Keeps the Current ID

If one device has been on the network longer and has existing integrations, trend logs, schedules, and alarm configurations pointing to its instance number, that device should keep its current ID. The newer or less-integrated device gets reassigned.

Step 2: Choose a New Device Instance Number

Select an unused number within the valid range of 0 through 4194302. Most organizations use a structured numbering scheme tied to building number, floor, or equipment type. Common conventions:

# Example device instance numbering convention
# Format: BBBFFDD (Building-Floor-Device)
#
# Building 3, Floor 1, Device 01:  310001
# Building 3, Floor 1, Device 02:  310002
# Building 3, Floor 2, Device 01:  320001
# Building 5, Floor 1, Device 01:  510001
#
# Before assigning, run a Who-Is across the full range to confirm
# the chosen number is not already in use:
# In YABE: Send WhoIs with range [new_id] to [new_id]
# In Wireshark: filter for bacnet.instance_number == [new_id]

Step 3: Change the Device Instance Number

The method varies by controller platform:

• Software configuration tool — Most supervisory controllers (JACE, Metasys NAE, EcoStruxure AS) require a configuration tool to change the device instance. In Niagara Workbench, navigate to Config > Drivers > BacnetNetwork > Local Device and modify the Object Identifier. In Metasys SCT, open the device object and change the instance number. Save and download the configuration.
• Web interface — Many modern controllers (Distech EC-BOS, Reliable Controls MACH series, Contemporary Controls BASrouter) expose the device instance in a web-based configuration page under BACnet or Network settings.
• Front panel or LCD menu — Some field controllers allow device instance changes from the local keypad. Navigate to the BACnet or Communication menu and enter the new value.
• BACnet Write-Property — The BACnet specification allows writing to the Object_Identifier of the Device object, but most manufacturers disable this. Don't count on this method unless the vendor documentation explicitly supports it.

Step 4: Power Cycle and Verify

After changing the device instance, reboot the controller. Some devices apply the change immediately; others cache the old identity until the BACnet stack restarts. After the reboot:

1. Send a Who-Is targeting the old (conflicting) instance number. You should receive exactly one I-Am response.
2. Send a Who-Is targeting the new instance number. You should receive exactly one I-Am from the reassigned device.
3. Verify that the BAS front-end shows both devices online simultaneously without flickering.
4. Check trend logs, schedules, and alarm routing for any references to the old instance number that need updating.

Step 5: Update Integrations

Changing a device instance number breaks any existing references to that device. Update these items on the BAS front-end and any third-party integrations:

• Point references in the supervisory controller's BACnet device table
• Trend log configurations bound to the old device ID
• Schedule objects referencing the old device
• Alarm notification class recipient lists
• Graphics or dashboards hardcoded to the old instance number
• Analytics or fault detection platforms pulling data from the device

Preventing Future Conflicts

Duplicate device IDs are almost always the result of poor planning or skipped commissioning steps. These practices eliminate the problem:

• Establish a device instance numbering plan before commissioning. Define a scheme (building-floor-device, site-system-device, or sequential blocks per contractor) and document it in the project's BAS specification. Distribute the plan to every subcontractor and integrator on the project.
• Reserve ranges per contractor or system. Assign each integrator a block of instance numbers (e.g., Contractor A gets 100000–199999, Contractor B gets 200000–299999). This prevents conflicts even when contractors commission devices independently.
• Run a full Who-Is scan before bringing new devices online. Before energizing a new controller, connect a laptop to the BACnet network and scan for the instance number you plan to assign. If you get a response, the number is already taken.
• Change default device IDs immediately. Controllers ship with factory-default instance numbers (commonly 0, 1, 260001, or vendor-specific defaults). Never leave a device at its default ID. Configure the instance number as the first commissioning step, before connecting to the production network.
• Maintain a living device registry. Keep a spreadsheet or database of every device instance number in the building or campus. Update it during every add, replace, or decommission event.

Common Mistakes

• Confusing device instance with MS/TP MAC address. These are different identifiers with different scopes. The device instance must be unique across the entire BACnet internetwork—every subnet, every trunk, every building connected by routers or BBMDs. The MS/TP MAC address only needs to be unique within a single trunk. Fixing one does not fix the other.
• Assuming duplicates only matter on the same subnet. Two devices on different BACnet/IP subnets bridged by a BBMD or BACnet router will still conflict if they share a device instance number. The Who-Is/I-Am exchange crosses subnet boundaries through BBMD forwarding. Technicians who segment troubleshooting by subnet often miss cross-subnet duplicates.
• Changing the device instance without updating integrations. Fixing the conflict is only half the job. Every point reference, trend log, schedule, alarm routing entry, and analytics binding that referenced the old instance number is now broken. Skipping the integration update creates a second outage.
• Leaving controllers at factory-default instance numbers. This is the root cause of most duplicate ID incidents. A replacement controller arrives, the technician mounts it, connects it to the network, and powers it up without configuring the instance number. The default (often 0 or 1) immediately conflicts with another device that was also left at the default.
• Using device instance 4194303. This value is reserved as the wildcard in BACnet Who-Is requests. Assigning it to a device produces unpredictable behavior across the entire internetwork because every Who-Is broadcast with no range limit uses 4194303 internally as "all devices."

Platform Compatibility

Duplicate device instance numbers are a BACnet protocol-level issue, not a vendor-specific bug. Any device implementing BACnet per ASHRAE Standard 135 is subject to the same uniqueness requirement. The detection and resolution steps above apply universally, with platform-specific configuration differences noted below:

The valid device instance range (0–4194302) and the uniqueness requirement have been part of the BACnet standard since ASHRAE 135-1995 and remain unchanged through all revisions, including BACnet/SC (Secure Connect).

Source Attribution

The technical guidance in this entry is informed by the following sources:

• Fixing BACnet Duplicate Addressing Issues — Optigo Networks. Covers the three types of BACnet duplicate addressing (MAC, Device Instance, Network Number) with diagnostic approaches.
• Johnson Controls Metasys Technical Documentation — Metasys system troubleshooting for BACnet device instance conflicts, including SCT and SMP diagnostic procedures.
• BACnet MS/TP Bus Communication Troubleshooting Checklist — Schneider Electric Community. BACnet diagnostic procedures including device instance verification and trunk health checks.
• What Happens When 2 BACnet MSTP Devices Have the Same Device ID — Chipkin Automation Systems. Explains the distinction between MAC address conflicts and device instance conflicts with protocol-level detail.
• YABE — Yet Another BACnet Explorer — Open-source BACnet diagnostic tool used for device discovery and duplicate detection.
• ASHRAE Standard 135 — BACnet—A Data Communication Protocol for Building Automation and Control Networks. The normative reference for device instance number assignment, valid ranges, and the Who-Is/I-Am discovery mechanism.

Additional testing and field validation by SiteConduit.