BACnet/IP device not discovered in Niagara 4: a field checklist
Discover in the BACnet Device Manager comes back empty or misses controllers? Work through this checklist from the network up, in the order that finds faults fastest.
You’ve added a BACnet network to a station, pressed Discover in the BACnet Device Manager, and nothing comes back, or half the site is missing. It’s one of the most common jobs on a BMS integration, and the cause is almost always one of a short list of things.
The trick is to work from the bottom of the stack up: prove the IP path first, then the station’s own BACnet settings, then routing between networks, and only then the devices themselves. Skipping straight to the controllers is how a ten-minute fault becomes an afternoon.
Before you touch anything: take a station backup, and agree changes with the building operator. Re-addressing a live BACnet network can drop plant off the BMS.
Quick checklist
| # | Check | Typical fix |
|---|---|---|
| 1 | Can the station host reach the device over IP at all? | Correct subnet, mask, VLAN or switch port |
| 2 | Is the station’s BACnet/IP port enabled, bound to the right network adapter and using UDP 47808? | Enable the port, pick the right adapter, open the firewall |
| 3 | Is the station’s network number unique and consistent with the rest of the site? | Agree a network numbering scheme and fix clashes |
| 4 | Is the device on a different IP subnet? | Set up BBMDs or register as a foreign device |
| 5 | Is the device on MS/TP behind a router? | Fix the router’s network numbers and the MS/TP trunk |
| 6 | Are device instances unique, and is discovery filtered? | Fix duplicates, clear any discovery range |
| 7 | Still stuck? | Capture the traffic and read what’s actually happening |
1. Prove the IP path first
BACnet/IP rides on ordinary UDP/IP, so if the station’s host can’t reach the controller’s IP address, nothing BACnet-related will help.
- Check the controller’s IP address, subnet mask and gateway against the station host (the JACE, or the supervisor PC). A wrong mask is the classic: the controller thinks the station is on another network and sends its replies to the gateway instead.
- Ping it. Some controllers block ping, so a failed ping isn’t proof on its own, but a successful one rules out a lot.
- On managed networks, confirm both ends are on the same VLAN, or that routing between VLANs is in place and allows UDP 47808. Site IT teams often put the BMS on its own VLAN and forget the supervisor.
2. Check the station is listening properly
In Niagara 4 the BACnet/IP settings live under Drivers › BacnetNetwork › Bacnet Comm › Network › IpPort.
- Enabled and healthy. The IpPort should be enabled and its status should be OK. A port that failed to bind will often show a fault here.
- Right network adapter. Supervisors and some JACEs have more than one network interface (site LAN, corporate LAN, a laptop’s Wi-Fi). If the BACnet link is bound to the wrong one, discovery broadcasts go out of the wrong door.
- UDP port 47808. BACnet/IP normally uses UDP 47808 (0xBAC0). Some sites deliberately use a different port to separate systems; if so, every device and the station must agree.
- Firewall. On a Windows supervisor, inbound UDP 47808 must be allowed for the Niagara process. The Who-Is goes out fine, but the I-Am replies get dropped on the way back in.
- Port already in use. If another BACnet tool is running on the same PC and bound to 47808, the station may not be able to use the port at all. Close test tools before you blame the network.
Also check the Local Device under the BacnetNetwork: the station is a BACnet device in its own right, and its device instance (the Object Id) must be unique on the site like any other.
3. Network numbers must be unique and agreed
Every BACnet network on a site, each IP subnet used for BACnet and each MS/TP trunk, needs its own network number (1 to 65534; 65535 is reserved for global broadcasts). The station’s IpPort has one too.
Problems appear when two routers claim the same number for different physical networks, or the station’s number for the IP network doesn’t match what the site’s other BACnet routers believe it is. Discovery can then work for devices on the station’s own subnet but fail for anything routed.
Get the site’s network numbering on paper (the O&M manual or points schedule should have it) and make the station match. If there’s no scheme, now is the time to write one.
4. Different subnet? Broadcasts don’t cross routers
Discovery uses Who-Is, an unconfirmed broadcast. Devices answer with I-Am. IP broadcasts stop at IP routers, so a station on 10.0.1.x won’t see controllers on 10.0.2.x just because both are reachable by ping.
There are two standard fixes, both from Annex J of the BACnet standard:
- BBMDs (BACnet Broadcast Management Devices). Put one BBMD on each subnet and give them all the same Broadcast Distribution Table listing each other. They forward broadcasts between subnets. Only one BBMD per subnet.
- Foreign device registration. The station registers with a BBMD on the remote subnet and receives its broadcasts. Handy for a supervisor that sits on a different network to the plant.
A Niagara station can act as a BBMD itself, which is often the tidiest option when the JACE already sits on the BMS subnet.
5. MS/TP devices behind a router
If the controllers are on an MS/TP trunk behind a BACnet router (a JACE’s RS-485 port, or a standalone IP-to-MS/TP router), discovery depends on the router as well as the trunk.
- The router must have the correct network number for the MS/TP side, unique on the site.
- On the trunk itself, check the basics: every device on the same baud rate, unique MAC addresses (0 to 127 for master devices), Max Master set high enough to cover the highest MAC in use, correct termination at both ends and a shield grounded at one point only.
- A single device with a duplicate MAC or wrong baud rate can disrupt token passing for the whole trunk, so “half the trunk is missing” often points at one bad device rather than many.
6. Duplicate device instances and discovery filters
Every BACnet device needs a device instance (0 to 4,194,302) that is unique across the entire site, not just its own network. Two controllers with the same instance can cause one to “disappear”, flick between addresses, or show another device’s values.
Also look at the Discover dialog in the Device Manager. If a device instance range or network was set during an earlier visit, discovery will quietly ignore everything outside it.
7. Watch the wire
If the checklist hasn’t found it, stop guessing and capture the traffic. Run Wireshark on the station host (or a mirrored switch port) while you press Discover, with the display filter:
bvlc || bacnet| What you see | What it means |
|---|---|
| No Who-Is leaving the station | The IpPort isn’t sending: wrong adapter, port disabled or not bound |
| Who-Is goes out, no I-Am comes back | The device isn’t receiving the broadcast (subnet, VLAN, BBMD) or its reply isn’t reaching you (mask, gateway, firewall) |
| I-Am arrives, but Niagara shows nothing | Firewall on the host, port conflict, or a discovery filter in Niagara |
| Two I-Am replies with the same device instance | Duplicate device instance: fix it before anything else |
A capture also gives you something concrete to show the site’s IT team when the fix is on their side.
Found the device, but points won’t read?
That’s a different fault, usually down to the device’s maximum message size, segmentation support, or the device rejecting ReadPropertyMultiple requests. Check the device’s settings in Niagara against what the manufacturer’s PICS document says it supports.
Summary
Work bottom-up: IP path, the station’s IpPort, network numbers, subnets and BBMDs, MS/TP routers, then device instances. Most “BACnet won’t discover” calls are fixed at steps 1 to 4, and a two-minute Wireshark capture settles anything that isn’t.