BACnet Discovery Finds No Devices: How to Fix It
You run a discovery from your BACnet client or new supervisor and the device list comes back empty, even though controllers are online and another workstation sees them fine. BACnet discovery rides on broadcasts, and broadcasts are fragile in routed networks, so an empty discovery is nearly always a network-scoping problem rather than dead devices. This guide walks the causes in order: same-subnet basics, the UDP port, host firewalls, and the BBMD infrastructure that discovery depends on the moment more than one subnet is involved.
BACnet discovery finds no devices in one line: When BACnet discovery finds no devices, remember what discovery is: a Who-Is broadcast that devices answer with I-Am. IP broadcasts do not cross routers, so a client on a different subnet from the controllers hears nothing unless a BACnet Broadcast Management Device forwards broadcasts between subnets or the client registers with a BBMD as a foreign device. On the same subnet, empty discovery usually means the wrong UDP port - the default is 47808, but sites run others - or a host firewall silently dropping the inbound I-Am replies.
First Checks: Same Subnet, Right Port, Open Firewall
Prove the simplest case first: put your client on the same IP subnet as one known controller and discover again. Same-subnet discovery needs no BBMD and no routing help, so failure here is local and has only a few causes. The first is the port: BACnet/IP defaults to UDP 47808, but installations legitimately use other ports, particularly where multiple BACnet networks share infrastructure, and a client transmitting on the wrong port is invisible no matter how healthy the network is. The building's controls documentation or an existing workstation's settings give the real port in seconds.
The second local cause is the host firewall on the machine running the client. The Who-Is goes out, devices answer with I-Am - and the operating system's firewall drops the inbound UDP replies, so the client sits in silence it created itself. Laptops new to a site do this almost by default. A packet capture is the honest test: if you can see I-Am frames arriving in the capture while the application shows nothing, the block is on your own machine. While capturing, also confirm the subnet mask matches the site's - a wrong mask makes the local broadcast address wrong, and the Who-Is never reaches the wire correctly.
Crossing Subnets: BBMDs and Foreign Device Registration
The moment client and controllers sit on different subnets, plain discovery is designed not to work: routers do not forward broadcasts, so the Who-Is never arrives. BACnet's answer is the BACnet Broadcast Management Device. One BBMD on each subnet, each holding a broadcast distribution table listing its peers, forwards broadcast traffic between subnets so that a Who-Is on one side is re-broadcast on the others. If a site spans subnets and discovery works from some machines and not others, map which subnets have a BBMD and what the distribution tables contain - an out-of-date table after a re-subnetting project is a classic silent breakage.
For a visiting client - a laptop, a new supervisory server, a monitoring gateway - the intended mechanism is foreign device registration: the client registers itself with an existing BBMD, which then relays broadcasts to it despite it having no BBMD on its own subnet. An empty discovery from a machine on a foreign subnet with no registration configured is therefore expected behavior, not a fault. The fix is entering the BBMD's address in the client's foreign device settings and confirming the registration is accepted; failure to register points at the BBMD's address, port, or a policy that restricts foreign devices, all of which live with the site's controls contractor.
Two configuration errors corrupt this infrastructure from within. Two BBMDs on the same subnet cause duplicate and looping broadcast traffic, and inconsistent distribution tables - one BBMD listing a peer that does not list it back - produce one-way discovery where side A sees side B but not the reverse. Both are worth checking whenever discovery behaves asymmetrically.
The Devices That Still Do Not Appear
When discovery returns some devices but not the ones you need, the scope of the Who-Is is the next suspect. Who-Is can carry a device instance range, and clients configured with a limited range skip everything outside it. Duplicate device instance numbers - two controllers configured with the same instance - cause responses that confuse clients and can make devices appear and vanish between discoveries. Each device instance on a site must be unique, and a duplicate is a configuration fault to correct at the device, not a client-side nuisance to tolerate.
Remember also that many field controllers are not BACnet/IP at all but MS/TP devices on serial trunks behind a BACnet router. If the router is discovered but its children are not, the problem lives on the MS/TP side - trunk wiring, MAC addressing, or the router's own configuration - and no amount of IP-side network work will surface those devices. The routed-network topology means discovery results should be read against the site's network number plan, which the controls documentation should provide.
When to Escalate
Escalate to the site's controls contractor or IT with the specific artifact BACnet gives you: a packet capture showing the Who-Is leaving and whether any I-Am returns, plus the BBMD addresses and distribution tables you believe are current. Discovery problems that survive same-subnet testing, correct ports, and confirmed registration are network policy problems - multicast and broadcast filtering, private VLAN isolation, or firewall rules between subnets - and those are fixed by whoever owns the switches, with your capture as the evidence.
For permanent integrations, treat discovery as a commissioning tool rather than an operating dependency. A monitoring platform such as Merobix reading building data through a BACnet gateway should be configured against a known device and object list once discovery has done its job, so day-to-day data flow does not depend on broadcasts working forever. Sites drift, BBMDs get replaced, and the integration that relied on re-discovery at every restart is the one that mysteriously loses devices after a network refresh.
Frequently Asked Questions
Why does BACnet discovery work on one subnet but not across subnets?
Because discovery is a Who-Is broadcast, and IP routers do not forward broadcasts. Devices on other subnets never hear the request. Crossing subnets requires BACnet's broadcast management infrastructure: a BBMD on each subnet forwarding broadcasts to its peers per its distribution table, or the client registering with a BBMD as a foreign device so broadcasts are relayed to it directly. Without one of those, empty cross-subnet discovery is the designed behavior.
What is a BBMD and when do I need one?
A BACnet Broadcast Management Device forwards BACnet broadcast messages between IP subnets that routers would otherwise isolate. You need BBMDs as soon as BACnet devices span more than one subnet and must discover or broadcast to each other - one per subnet, each listing the others in its broadcast distribution table. A device on a subnet without a BBMD can still participate by registering with a remote BBMD as a foreign device.
Discovery finds the BACnet router but not the controllers behind it - why?
The controllers are probably MS/TP serial devices on a trunk behind that router, so they are not IP devices at all. If the router answers but its children do not appear, the fault is on the serial side: trunk wiring, device MAC addresses, baud settings, or the router's routing configuration. The IP network is doing its job; the investigation moves to the MS/TP trunk and the router's own diagnostics.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.