Discovery in BACnet/IP is a broadcast on UDP 47808, and IP routers do not forward broadcasts. Everything on your own subnet answers; everything one hop away stays silent, and the tool looks broken when the network is simply doing what it is designed to do. The standard has two answers for this — a BBMD on each subnet, and Foreign Device Registration for anything arriving from outside. Here is what each one actually does, and the handful of configuration mistakes that quietly break both.
Windows 10/11 · one-time license · 14-day trial
A Who-Is goes to the subnet broadcast address. Every BACnet device that hears it replies with an I-Am. That is the whole mechanism, and it works perfectly — within one IP subnet.
A router exists in part to stop broadcasts from crossing. So the moment a plant is split across VLANs, buildings or floors — which is to say, the moment it is a real site — a Who-Is reaches a fraction of the equipment. Nothing reports an error. The scan simply returns fewer devices than exist, and nothing anywhere says why.
This is not a defect in BACnet or in your tool. It is the reason Annex J of the standard defines a way to carry broadcasts between subnets deliberately and under control, instead of asking the network to leak them.
The two are often spoken about as one thing. They are not, and knowing which one a situation calls for saves an afternoon.
A BACnet/IP Broadcast Management Device sits on a subnet and holds a Broadcast Distribution Table: the list of BBMDs on the other subnets. When a broadcast appears locally, the BBMD sends a unicast copy to each peer in that table, and each peer re-broadcasts it on its own subnet. The broadcast crosses the router as ordinary unicast traffic, which routers forward without complaint.
This is infrastructure. It is configured once, in devices that stay powered, and it is usually a controller or a BACnet router that already has the function built in — you rarely add hardware for it.
An engineering laptop is not on a BACnet subnet at all. It sits on the office network, or at the end of a VPN. Rather than adding a BBMD for one machine, it sends a Register-Foreign-Device message to an existing BBMD with a time-to-live. The BBMD adds it to its Foreign Device Table and starts forwarding broadcasts to it by unicast.
The registration is a lease, not a setting. It expires, and the tool has to renew it before it does. This is the mechanism an explorer or a commissioning tool should be using.
If the equipment itself is spread across subnets and has to find its peers, the site needs BBMDs. If the equipment is fine and only you cannot see it from where you are sitting, you need Foreign Device Registration against a BBMD that already exists. Adding a second BBMD to solve a laptop problem is the common wrong turn, and it causes the third fault in the next section.
| What you see | Usually this |
|---|---|
| Only local devices answer, nothing from the other subnet | No BBMD on one of the subnets, or your tool is not registered as a foreign device with one |
| Devices appeared, then vanished a few minutes later | The foreign-device lease expired. A BBMD drops the entry after the time-to-live plus a 30-second grace period |
| Every device answers twice, or the network gets busy for no clear reason | Two BBMDs on the same IP subnet, each re-broadcasting what the other forwarded |
| Some subnets work, one never does | That BBMD is missing a peer in its distribution table. Every BBMD has to know about every other one — the table is configured, not learned |
| Registration is refused outright | The BBMD returned a NAK, result 0x0030. Its foreign-device table is full, or it is configured not to accept registrations |
Two more are worth knowing because nothing in BACnet will tell you about them. A firewall blocking UDP 47808 produces exactly the same silence as a missing BBMD: no error, no answer. And NAT breaks BBMDs — a distribution table holds real IP addresses, and a translated address is not the one a peer will reply to. Where a site sits behind NAT, foreign-device registration through a reachable BBMD is the workable route, not a table entry.
One historical trap: older setups used one-hop forwarding, where a peer entry carries the real subnet mask and the peer forwards using a directed broadcast. Modern routers drop directed broadcasts by default, so one-hop configurations that worked for years stop after a network refresh. Two-hop — mask 255.255.255.255, peer receives unicast and re-broadcasts locally — is what to use now.
Foreign Device Registration lives in the BACnet/IP panel: a BBMD address, a time-to-live, a Register button. What matters is what happens after you press it.
The registration is re-sent at 75% of the time-to-live, so the lease never lapses while the tool is open. The default is 300 s; anything from 30 s upward is accepted.
A refusal from the BBMD and no answer at all look identical in most tools. Here they are separate — a NAK reports its BVLC result code, a timeout says the BBMD never replied.
The BBMD address and time-to-live are remembered and registration is re-established when the connection returns, so you are not re-entering it after every restart.
Foreign Device Registration applies to BACnet/IP only. On MS/TP there are no IP broadcasts to manage, and BACManager says so rather than appearing to accept the setting — see MS/TP over RS-485 for the discovery problems that segment has instead.
Download the free trial and browse a real Priority_Array on your own devices — no credit card, no cloud.
Windows 10/11 · $149 one-time
We use Google Analytics cookies to see how the site is used. You can accept or decline — declining keeps analytics off.