How to Fix BACnet MS/TP Address Conflicts

Understanding BACnet MSTP Address Conflicts

BACnet MS/TP (Master-Slave/Token-Passing) networks rely on unique MAC addresses to manage communication across an RS-485 daisy-chain. Each master device on a trunk holds a MAC address between 0 and 127, and slave devices occupy 128 through 254. Address 255 is reserved for broadcast. When two master devices share the same MAC address, both interpret themselves as the rightful token holder. The result: simultaneous transmissions, electrical collisions on the RS-485 bus, and a network that degrades from unreliable to unusable.

The challenge with a BACnet MSTP address conflict is that symptoms are often intermittent and easy to misattribute. A technician may see a controller drop off the network for a few minutes, reappear, then drop again. The front-end may show stale data from a VAV box or AHU controller. CRC error counters climb. The natural instinct is to suspect wiring or a bad port—and those are valid checks—but duplicate MAC addresses produce nearly identical symptoms and are far harder to catch without systematic diagnosis.

This problem frequently surfaces during retrofit projects where multiple contractors configure devices independently, during commissioning when default addresses haven't been changed, or after a controller replacement where the new unit ships with the same factory-default MAC as an existing device on the trunk.

Symptoms of a BACnet MSTP Address Conflict

Before diving into the fix, confirm that you're actually dealing with a duplicate MAC address. These are the telltale signs:

• Intermittent device disappearance — A device appears in your BAS front-end, disappears for seconds or minutes, then reappears. The shared address means the token ring alternates between the two devices unpredictably.
• Climbing CRC error counters — Both devices attempt to transmit when they receive the token, creating bus collisions. The resulting corrupted frames register as header CRC or data CRC errors on every device monitoring the trunk.
• Inconsistent property reads — A Who-Is request for the conflicting MAC returns responses from both devices. Read-Property requests may return values from Device A on one poll and Device B on the next, because whichever device grabs the token first in the ring sequence responds first.
• Token-passing stalls — The token-passing algorithm expects a single response when passing the token to a MAC address. Two responses create confusion, causing token drops and recovery delays of 20–100 ms per occurrence.
• Entire trunk degradation — In severe cases, the collision traffic from the duplicate address can flood the trunk to the point where even non-conflicting devices experience timeouts and lost polls.

How to Fix a BACnet MSTP Address Conflict: Step-by-Step

There is no built-in BACnet mechanism that automatically detects or resolves duplicate MAC addresses on an MS/TP trunk. Detection requires manual or tool-assisted diagnosis. Follow these steps in order:

Step 1: Document the Trunk

Before making changes, record the current state of every device on the affected MS/TP trunk. You need the MAC address, Device Instance (Object Identifier), baud rate, and Max Master setting for each controller.

# Example trunk documentation (maintain this as a spreadsheet or text file)
# ---------------------------------------------------------------
# Trunk 3 - AHU-1 Mechanical Room
# Baud Rate: 38400
# Termination: EOL resistors at Panel A (first) and Panel G (last)
# ---------------------------------------------------------------
# MAC   Device Instance   Controller        Max Master
# 001   310001            Tridium JACE 8000  31
# 002   310002            SE AS-P            31
# 003   310003            JCI FEC            31
# 010   310010            Distech EC-BOS-8   31
# 015   310015            Carrier i-Vu CCN   31
# 022   310022            Honeywell Spyder   31

Step 2: Isolate the Conflict

If your BAS front-end shows a device flickering on and off, note its MAC address. That address likely has a duplicate. To confirm, systematically disconnect devices from the trunk:

1. Disconnect the daisy-chain at the midpoint of the trunk, creating two smaller segments.
2. Check if the flickering device stabilizes on one segment. If it does, the duplicate is on the other segment.
3. Continue bisecting the problem segment until you find two devices responding on the same MAC address.

On smaller trunks (fewer than 10 devices), you can also disconnect devices one at a time from the far end of the chain. When the problem clears after removing a specific device, you've found the duplicate.

Step 3: Use a Protocol Analyzer (If Available)

A protocol analyzer on the MS/TP trunk gives definitive evidence. Tools like the Contemporary Controls BASrouter diagnostic mode, Cimetrics BACnet MS/TP Protocol Analyzer, or Optigo Visual Networks can capture raw MS/TP frames and flag duplicate token holders.

If you use Wireshark, you will need an MS/TP-to-IP capture device (such as a BACnet router with packet capture capability) since Wireshark cannot directly sniff RS-485 traffic. Look for these indicators in the capture:

# Wireshark display filter for MS/TP token and CRC issues
# Filter for Poll For Master frames to a specific MAC:
bacnet.mesgtyp == 0x01 && bacnet.daddr == 15

# Filter for Reply To Poll For Master (multiple replies = conflict):
bacnet.mesgtyp == 0x03 && bacnet.saddr == 15

# Filter for token passes to the suspect MAC address:
bacnet.mesgtyp == 0x00 && bacnet.daddr == 15

# CRC error frames (if your capture device flags them):
bacnet.crc_status == "Bad"

Step 4: Reassign the Duplicate MAC Address

Once you've identified the conflicting device, change its MAC address to an unused value. How you do this depends on the controller platform:

• DIP switches — Many field controllers (VAV boxes, unit controllers) use physical DIP switches on the board to set the MAC address. Power down the controller, change the switch positions, and power back up.
• Software configuration — Supervisory controllers and newer field controllers typically set the MAC address through their configuration tool (Niagara Workbench, Metasys SMP, System Manager, CCT). Change the MS/TP port configuration, save, and reboot the controller.
• LCD/keypad — Some controllers (Distech, certain Schneider Electric models) allow address changes from the front panel menu under Network or BACnet settings.

# Example: Setting MAC address on a Tridium Niagara station
# Navigate to: Station > Config > Drivers > BacnetNetwork > MS/TP Port
#
# Properties to verify:
#   Mac Address:      22        (must be unique on this trunk)
#   Baud Rate:        38400     (must match all other devices)
#   Max Master:       31        (must be >= highest MAC on trunk)
#   Max Info Frames:  1         (default; increase only if needed)

Step 5: Set Max Master Correctly on All Devices

The Max Master parameter tells each device the highest MAC address to include in token-passing polls. If Max Master is set too low, devices above that address are excluded from the token ring and cannot communicate. If set too high, the trunk wastes time polling non-existent addresses every 50 token cycles (Poll For Master), adding latency.

Best practice: set Max Master on every device to the highest actual MAC address on the trunk, or one value above it. If your highest MAC is 22, set Max Master to 22 or 23 on all devices.

# Max Master guidance
# ---------------------------------------------------
# Highest MAC on trunk:  22
# Recommended Max Master: 22 (or 23 for one spare)
#
# Impact of incorrect Max Master:
#   Too low (e.g., 15):  Devices at MAC 16+ are invisible
#   Too high (e.g., 127): Each unused address adds ~100ms
#                          polling delay per PFM cycle
#   Just right (22-23):   Minimal overhead, all devices polled

Step 6: Verify Baud Rate Consistency

While you're touching device configurations, confirm that every device on the trunk uses the same baud rate. Mixed baud rates cause symptoms nearly identical to address conflicts—CRC errors, dropped frames, and intermittent communication. Common MS/TP baud rates are 9600, 19200, 38400, 76800, and 115200 bps. Most BAS installations standardize on 38400 or 76800.

Step 7: Verify Wiring and Termination

After resolving the address conflict, do a quick physical-layer check to rule out compounding issues:

• Confirm daisy-chain topology—no star or T-tap connections.
• Verify correct polarity on the RS-485 A (+) and B (-) lines at every device. A single polarity swap will take down the trunk.
• Check that 120-ohm end-of-line (EOL) termination resistors are installed at the first and last devices on the trunk only. Resistors at intermediate points cause signal reflections.
• If the trunk includes a third conductor for signal ground (reference), verify it is continuous end to end.

Step 8: Confirm Resolution

After making changes, monitor the trunk for at least 30 minutes. Watch for:

• All devices consistently present in the BAS front-end.
• CRC error counters stable (not incrementing).
• Property reads returning consistent, expected values.
• No token-pass timeouts in the protocol analyzer (if running).

Common BACnet MSTP Address Conflict Mistakes

• Confusing Device Instance with MAC address. These are separate identifiers. The Device Instance (Object Identifier) must be globally unique across the entire BACnet internetwork. The MAC address must be unique only within a single MS/TP trunk. Fixing a Device Instance conflict does not fix a MAC address conflict, and vice versa. Both must be unique in their respective scopes.
• Setting Max Master to 127 "just to be safe." This forces every device on the trunk to poll MAC addresses 0 through 127 during Poll For Master cycles. With only a handful of actual devices, the trunk spends significant time sending PFM requests to empty addresses and waiting for timeouts (Tno_token, approximately 20–100 ms each). On a trunk with 10 devices clustered at MACs 1–10, setting Max Master to 127 can reduce effective throughput by 30–40%.
• Assuming auto-baud detection will handle mixed rates. While some controllers support auto-baud detection, it is unreliable in multi-vendor environments. A device auto-detecting at 9600 bps on a trunk running 38400 bps will generate constant CRC errors. Always manually configure baud rates to match across the entire trunk.
• Adding termination resistors at every device. EOL resistors (120 ohms) must be installed only at the two physical endpoints of the daisy chain. Adding them at intermediate devices reduces signal amplitude, creates reflections, and mimics the symptoms of address conflicts—intermittent communication and CRC errors. A common mistake during troubleshooting is adding resistors to "fix" a problem that's actually a duplicate address.
• Not checking for conflicts after a controller replacement. New controllers often ship with factory-default MAC addresses (commonly 0 or 1). Swapping a failed controller and powering it up without first setting its MAC address is the most frequent cause of address conflicts in the field. Always configure the MAC address before connecting the replacement to the trunk.

Platform and Version Compatibility

BACnet MS/TP address conflicts are protocol-level issues, not vendor-specific bugs. Any device that implements BACnet MS/TP per ASHRAE Standard 135 is subject to the same addressing rules. The troubleshooting steps above apply across all major BAS platforms:

The BACnet MS/TP specification supports MAC addresses 0–127 for master devices and 128–254 for slave devices across all protocol revisions. These addressing rules have remained consistent since BACnet was first standardized in ASHRAE 135-1995 through the current revision.

Sources and 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.
• The 3 Most Common MS/TP Mistakes — Optigo Networks. Details wiring errors, overload conditions, and device configuration mistakes on MS/TP trunks.
• What Happens When 2 BACnet MSTP Devices Have the Same Device ID — Chipkin Automation Systems. Explains token-ring behavior during MAC and Device Instance conflicts.
• BACnet MS/TP Bus Communication Troubleshooting Checklist — Schneider Electric Community. Comprehensive checklist for MS/TP bus diagnostics including baud rate, Max Master, and wiring verification.
• BACnet MS-TP Addressing — Continental Control Systems. Technical reference for MAC address ranges, token passing mechanics, and address clustering best practices.
• BACnet MSTP Issue — HVAC-Talk Forum. Field technician discussion of MS/TP trunk protocol issues including duplicate addresses, dropped tokens, and CRC errors.
• ASHRAE Standard 135 — BACnet—A Data Communication Protocol for Building Automation and Control Networks. The definitive standard governing MS/TP MAC addressing, token passing, and frame formats.