What is a BACnet points list?
A BACnet points list is an inventory of every data object a BACnet device exposes to the network. Each row is one point — a sensor reading, a setpoint, a command, or a status flag — identified by its object type (Analog Input, Binary Output, and so on) and its instance number, usually alongside the point name, its present value, and its engineering units. It is the document an integrator, vendor, or analytics platform needs before they can read or control anything in your building.
What a point actually is
BACnet models a controller as a collection of objects. Every
object has properties, and the one nearly everybody cares about is
Present_Value — the number or state the point is reporting right
now. A rooftop unit controller might expose eighty objects: supply air
temperature, fan status, damper position, occupancy mode, a dozen setpoints, and
a long tail of internal values that only the manufacturer cares about.
Each object is addressed by a pair: its type and its instance number. Analog Input 3 and Binary Input 3 are different points on the same controller. The pair is what makes a point unambiguous, which is why a points list that gives only names is not much use to an integrator.
What a points list contains
A usable points list has at least these columns:
| Column | Why it matters |
|---|---|
| Device ID (instance) | Identifies which controller the point lives on. Must be unique across the whole BACnet internetwork. |
| Device name / IP address | How a person and a machine respectively find the controller. |
| Object type | Analog Input, Binary Value, Multi-State Output, etc. Determines the datatype and whether the point can be commanded. |
| Object instance | The number within that type. Type plus instance is the point's address. |
| Point name | The Object_Name property. Human-readable, and often the only clue to what the point does. |
| Present value | What it reads right now. Proves the point is live and gives the reader a sanity check on units. |
| Units | Degrees F, percent, CFM, and so on. Without this a number is meaningless. |
| Status flags | In alarm, fault, overridden, out of service. Tells you whether the value can be trusted. |
The object types you will actually see
Three families cover the overwhelming majority of points in a building:
- Analog (Input, Output, Value) — anything with a continuous number: temperatures, pressures, percentages, setpoints.
- Binary (Input, Output, Value) — two-state points: a fan running or stopped, a call for cooling, an alarm contact.
- Multi-state (Input, Output, Value) — a small set of named states: Off / Low / High, or Occupied / Unoccupied / Standby.
Within each family, Input generally means a physical sensor, Output a physical actuator, and Value a software point that exists only inside the controller's logic. That distinction matters when someone wants to write to a point: see BACnet priority and stuck overrides.
Why anyone asks for one
- Integration. An analytics platform, a tenant billing system, or a new head-end needs to know what exists before it can map anything.
- Commissioning and troubleshooting. Comparing the points list against the sequence of operations is how you find the sensor that was never wired.
- Handover. When a building changes hands or contractors, the points list is the map of the control system.
If someone has asked you for one, see what to send when a vendor asks for your BACnet information. If you need to produce one from a live system, see how to find your BACnet points list.