BACnet Objects and Properties: What Panel Builders Need to Know
Before you wire a single BACnet panel, learn what an 'object' actually is on the wire — a modeled point with defined properties — and why the Device Instance number has to be unique across the entire building network, not just your panel.
How to read a BACnet points list before you touch a panel
Start with the Device object
Every BACnet device — controller, sensor, gateway — has exactly one Device object, identified by a unique Device Instance (0–4194302). Find it first; it's the address every other object on that device sits behind.
Understand what an 'object' really is
A BACnet object is a modeled point — not a raw register — with a fixed set of properties such as Present_Value, Status_Flags, Object_Name, Units and Description. Read the property, not the wire.
Recognise the standard object types
Analog Input/Output/Value (AI/AO/AV) for continuous values, Binary Input/Output/Value (BI/BO/BV) for on/off points, and Multi-state Input/Output/Value for stepped states — these cover most of a commissioning sheet.
Check Device Instance uniqueness before go-live
The Instance number must be unique across the whole internetwork, not just the local segment. A clash breaks Who-Is/I-Am discovery silently — the fault shows up as a 'missing device' weeks later, at another site.
The object and property model, in practical terms
Device Instance range
A 22-bit number, one per Device object, that must stay unique across the entire BACnet internetwork — the basis for automatic discovery via Who-Is/I-Am.
Properties define what you can actually do with a point
Present_Value carries the reading or command, Status_Flags exposes fault/override/alarm state, and Out_Of_Service lets you force a value for testing without touching wiring.
Object types map directly to your I/O
AI/AO/AV for analogue signals, BI/BO/BV for digital points, Multi-state for stepped positions — plus supervisory objects like Schedule, Calendar, Trend Log and Notification Class for logic that lives in the controller, not a PLC program.
Naming discipline pays off at handover
Auto-generated names like 'AI-1' or 'BO-14' are unreadable on a BMS graphic. A consistent floor–system–point naming convention on Object_Name and Description turns your points list into a document someone else can commission from.
PICS tells you what a device actually supports
The Protocol Implementation Conformance Statement lists the object types and services a specific device implements. Check it before you design the panel, not after the integrator calls back.
The Priority Array resolves who's in control
Controllable objects like BO and AO carry 16 priority levels — level 1 for life-safety override, level 8 for manual operator override, level 16 as default — so multiple systems can 'vote' on one point without wiring conflicts.
What our engineers check on a BACnet points list
Before a panel goes to assembly, we validate the object model against the actual devices — not just the spec sheet.
- Object and property review against the supplied PICS documents
- Device Instance allocation plan, checked for network-wide uniqueness
- Object naming convention proposal (floor–system–point) for BMS graphics
- Panel assembly to IEC 61439 with BACnet wiring documented for handover
- Commissioning support for Who-Is/I-Am discovery issues on site
Frequently asked questions
What exactly is a BACnet object?
It's a modeled representation of a physical or logical point — a sensor, a relay, a setpoint — exposed as a defined set of properties (Present_Value, Status_Flags, Object_Name, Units, and others) rather than a raw memory address. You read and write properties, not registers.
What's the difference between AI, AO, AV, BI, BO and BV?
The letters split into signal type and direction: Analog (continuous values) vs Binary (on/off), and Input (from the field), Output (to the field) or Value (internal, not wired to I/O). AI/AO/AV and BI/BO/BV cover most points on a commissioning sheet; Multi-state adds stepped states beyond simple on/off.
Why must the Device Instance be unique network-wide, not just on my segment?
Who-Is/I-Am discovery broadcasts across the whole internetwork through BBMDs and routers, not just the local wire. Two devices sharing an Instance number on different segments will still collide once the network is routed together — often at a different site, months after your panel shipped.
What actually breaks if two devices share a Device Instance?
Discovery becomes unreliable: a Who-Is broadcast can get an I-Am response from the wrong device, or workstations intermittently 'lose' one of the two devices depending on which responds first. It's rarely an immediate hard failure, which is what makes it hard to diagnose later.
Do I need to memorise every property, or just a few?
For day-to-day panel work, Present_Value, Status_Flags, Out_Of_Service, Object_Name, Description and Units cover the vast majority of what you'll touch. Deeper properties like the Priority_Array matter mainly on controllable objects (AO/BO) where more than one system can command the same point.
Wiring a BACnet panel for the first time?
Send us the points list and device PICS documents — our engineers will check the object model and Device Instance plan before assembly starts, not after.