Protocols · BACnet
BACnet Objects — Interoperability Beyond the Point List
What BACnet objects are, which properties matter for integration, and how to verify interoperability before a device reaches the point list.
Quick answer
A BACnet object is a structured representation of a point or function on a device: analog input, binary output, multi-state value, schedule, trend log and so on. Each object has an instance number and properties. Integration quality depends on checking which objects a device actually supports, not on the protocol logo on its datasheet.
The object model in plain terms
A BACnet device exposes objects, and each object has properties. An analog input carries a present value, units, status flags and a description. A binary output carries a commanded state and a feedback state. A schedule object holds a weekly programme and an exception calendar. A trend log records samples. The device object itself carries identity and service information. Once you read the model this way, a point list stops being a list of wires and becomes a list of typed data with behaviour. That is what makes BACnet integration predictable. The same logic applies to a binary input and a multi-state value: the name of the state matters as much as the number behind it.
- Objects carry properties, not just values
- The device object carries identity and services
- Typed data makes integration predictable
Interoperability is a document, not a promise
Two devices can both claim BACnet and still share very little. Vendors implement different object types, services and optional properties. Ask for the protocol implementation conformance statement and the object list before design. Check which objects are readable, which are writable and which require a proprietary tool. Confirm whether the device supports change-of-value subscriptions or only polling. Confirm the device instance and network number. These questions belong in the interface audit, not in a commissioning surprise. If the vendor cannot supply the document, treat the device as a black box and price the uncertainty into the integration, rather than discovering it during commissioning, when the programme is least forgiving. A short pilot test is cheaper than a late surprise.
- Ask for the PICS and object list
- Check COV versus polling
- Confirm device instance and network number
Priority, relinquish and ownership
BACnet writes use a priority array. A command at a higher priority overrides a lower one, and when it is released the lower value becomes effective again. That is useful for life-safety, demand response and manual overrides, but it also means two systems can fight over a setpoint without either appearing broken. Decide who writes at which priority, document the relinquish default and test the release path. The question 'who owns this setpoint?' should have one answer in the design. A written priority table, agreed by the controls, fire and energy teams, prevents a well-intentioned override from becoming an unexplained loss of control at the worst moment. It also gives the commissioning team something concrete to test.
- Priority arrays decide who wins
- Document relinquish defaults
- Test the release path
Checklist for a clean object integration
Collect the device instance, network number, object list, units, scaling and COV settings. Confirm BBMD and network routing if the device sits across subnets. Check MS/TP baud rate, termination and bias where serial segments are used. Map each object to a controller point with a consistent name and a defined failure state. Test read, write, release and recovery, not just a single value on a screen. Then store the object list with the as-built documentation so the next engineer starts from evidence rather than guesswork. The object list is not a one-off commissioning artefact; it is the map the next integration will start from, and it should be updated whenever the device changes.
- Map each object to a named point
- Test read, write, release and recovery
- Store the object list as an as-built
Common BACnet objects
6 rows| Object | What it represents | Integration note |
|---|---|---|
| Analog input | A measured value such as temperature or pressure | Check units, scaling and status flags |
| Analog output | A commandable analogue setpoint or valve position | Confirm priority and relinquish behaviour |
| Binary input | A two-state status such as a running proof | Check active and inactive text and polarity |
| Binary output | A commandable start, stop or enable | Test feedback separately from command |
| Multi-state value | A mode or selector with named states | Map state text, not only the number |
| Schedule | A time programme with exceptions | Decide whether the schedule lives here or in the supervisor |
Project images
3 images
Frequently asked
01What is a BACnet object instance?
The number that identifies an object within a device. The same object type can appear many times, so the instance number is part of the address.
02What is a PICS?
The protocol implementation conformance statement: a document that lists the services, object types and optional features a device supports.
03What is COV?
Change of value: the device sends an update when a value changes, instead of the supervisor polling continuously. It reduces network load but depends on subscription limits.
04Can we write setpoints over BACnet?
Only if the object is commandable and the priority is agreed. Some points are read-only by design or by vendor configuration.
05Is BACnet MS/TP still relevant?
Yes, on older plant and field controllers. It needs correct baud rate, termination, bias and a documented segment plan.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.