How do I test a BACnet IP device without a BMS?

Updated 11 October 2026

Short answer

You do not need the head-end to prove a BACnet IP controller is up and working. Any BACnet client on the same subnet can do it, including Easy BACnet on a phone. Plug into the network, run a scan, and if the controller shows up with its Device ID it is powered, addressed and speaking BACnet. Read its inputs to check the sensors make sense, then, where it is safe, command an output, watch the equipment respond, and release it. That is a useful point-to-point check before the BMS is connected.

Why you can do this without the BMS

BACnet IP has no login and no single master. A head-end is a BACnet client with graphics, trends and schedules on top; a handheld client can do the same discovery, reads and writes. That makes a phone handy at start-up, for checking a replacement controller, or for “is this new RTU controller talking yet?” before the integrator has it in the Supervisor.

Before you start

A new controller is often still on its factory IP address and Device ID. Find out what they are (label, manual, or the commissioning tool) and give your phone's Ethernet adapter a static IP on that subnet. If two new controllers share the same default Device ID, sort that out before anything else; see duplicate Device IDs.

The test, step by step

1. Prove it is on the network (discovery)

Run a scan. If the controller shows up with its Device ID and IP, it is powered, on the network and speaking BACnet/IP. If it does not answer, that is a network or addressing problem first, not necessarily a dead controller: see why does my BACnet IP device show offline?

2. Check the inputs

Open the device and read its input points. Do the values make sense? A zone temperature around 70 °F, an outdoor air temperature that matches the weather, a damper feedback between 0 and 100%. A point flagged Fault, or reading -40 or 250, usually means an open or shorted sensor, a wiring error, or the wrong sensor type configured.

3. Check the outputs respond

On a commandable output, write a value at priority 8 and watch the equipment: the valve strokes, the fan starts, the feedback point follows. Then release it so you do not leave an override behind, and re-read to confirm it went back to auto. Only do this where moving the equipment is safe and the people on site know. See how to write to a BACnet point and priority and stuck overrides.

The whole job, start to finish. Steps 4 and 5 are the ones people skip.

What a phone test can and cannot tell you

Can: confirm the controller is online, that inputs read sensible values, that outputs respond to commands, and capture the lot as a spreadsheet for the record.
Cannot: discover a whole other subnet without a BBMD (one known device can be added by IP), or connect straight to an MS/TP trunk; MS/TP controllers need a BACnet router. And it does not check schedules, trends, alarms or the full sequence of operation. It proves the controller and its I/O work, not that the programming is right.

Check it on your own network. Easy BACnet is a free Android app that finds BACnet IP devices and reads their points in a couple of taps.

Get it on Google Play