How do I tell if a BACnet device is really online before blaming the app?

Q: How do I tell if a BACnet device is really online before blaming the app?

Find the device's IP address and ping it. A ping tests the plain network path, with no BACnet involved. If the ping fails, the device is unreachable on the network — a wrong subnet, a firewall, a bad cable or a wrong IP — and no BACnet tool will find it until that is fixed. If the ping succeeds but Easy BACnet still can't see it, the device is powered and on the network but its BACnet isn't answering your discovery — a very different problem with its own short list of causes. That one test tells you which half of the world to look in.

Updated 18 September 2026

Short answer

Find the device's IP address and ping it. A ping tests the plain network path, with no BACnet involved. If the ping fails, the device is unreachable on the network — a wrong subnet, a firewall, a bad cable or a wrong IP — and no BACnet tool will find it until that is fixed. If the ping succeeds but Easy BACnet still can't see it, the device is powered and on the network but its BACnet isn't answering your discovery — a very different problem with its own short list of causes. That one test tells you which half of the world to look in.

Why ping first

A BACnet scan can fail for a dozen reasons, and most of them are not the device. A ping strips all of that away: it asks one question — can any packet reach this address and come back? — without touching BACnet at all. Knowing the answer to that before anything else stops you chasing a controls problem that is really a network problem, or vice versa.

Step 1 — find the device's IP address

You need the actual IP of the controller. Common places to get it:

From Easy BACnet itself, if the device shows up in a scan at all — the IP is listed under the device name alongside its Device ID. (If it shows up, ping is moot; skip to the reads.)
From the equipment label or commissioning sheet. Controllers are often labelled with their IP, or it is in the project's points list.
From the network switch or router. Its DHCP lease table or ARP table lists every device and its IP — ask whoever runs the network to read it off, or check the router's admin page. This is exactly the “look for the IP from the network equipment” step.
From the BMS front end or the controls contractor, who will have it on record.

Step 2 — ping it

Ping from a device on the same network as the controller — a laptop plugged into the controls switch is ideal. On a laptop, open a terminal or command prompt and type ping followed by the address, e.g. ping 10.20.30.41. On a phone, a free ping/network-tools app does the same. You are looking for replies rather than “request timed out” or “destination unreachable”.

Step 3 — read the result

The ping fails (timeouts, or unreachable)

The device is not reachable on the network, and this is not a BACnet issue yet. Likely causes:

You are on a different subnet with no route to it — the most common one. Get onto the controls network and ping again.
A firewall or VLAN is blocking the path (some also block ping specifically — see below).
The IP is wrong, or the device has changed address on DHCP.
A physical problem — unplugged cable, dead switch port, or the unit is powered down.

This is an IT / network problem. Once a ping succeeds, come back and scan again.

The ping succeeds, but Easy BACnet still can't see it

This is the useful case, and the one people miss: the device is online at the network level, but its BACnet is not answering your discovery. The hardware is fine; something specific to BACnet is in the way:

The Who-Is broadcast isn't reaching it. Ping is directed at one address; discovery is a broadcast, and broadcasts are dropped or don't cross routers. Try adding the device by its IP directly in the app (a directed read rather than a broadcast). If a directed read works, the device is fine and you have a broadcast/subnet problem — you likely need a BBMD. See also why can't I find my BACnet devices.
It's on a non-standard UDP port. BACnet/IP is usually UDP 47808, but sites running multiple networks over one wire use 47809 and up. Ping doesn't care about ports; BACnet does. See what port does BACnet use.
A firewall allows ping but blocks 47808. ICMP (ping) and UDP 47808 (BACnet) are separate rules; it is common to permit one and block the other.
The device's BACnet service is disabled, mis-instanced, or has a duplicate Device ID — it answers on the network but not as the BACnet device you expect.
It's an MS/TP device behind a router that pings at its IP but whose trunk isn't being routed onto IP. Easy BACnet is BACnet IP only.

The first three are usually IT / network; the last two are your controls / BMS provider. Either way you now know it is a BACnet configuration problem, not dead hardware.

The device pings and answers BACnet, but shows no points (or no values)

Communication is fine; the device is just slow to enumerate, is refusing property reads, or genuinely exposes very little. Work through the app can't find what I'm looking for.

What this buys you on the phone

A clean ping plus a failed scan is the single most useful sentence you can give a provider: “10.20.30.41 pings fine from a laptop on the controls switch, but no BACnet tool sees it.” That rules out the network path and the hardware in one line and points straight at BACnet configuration — so the person you call starts three steps ahead.