BACnet

Building Automation and Control Networks

Definition

BACnet (Building Automation and Control Networks) is a standard protocol in the field of building automation, used for data acquisition and control of building equipment such as HVAC, lighting, and security. The Device Management Platform enables BACnet device access through gateways, coexisting with industrial protocols such as OPC UA and Modbus.

Protocol Features

BACnet, established by ASHRAE, supports multiple physical layers (Ethernet, RS-485, ZigBee, etc.) and uses an object-oriented data model. Devices expose properties in the form of objects, supporting read/write/subscribe operations. It is widely used for the interconnection of HVAC, lighting, elevators, and energy metering equipment in smart buildings, data centers, hospitals, and other scenarios.

Integration Methods with DMP

Device Management Platform converts BACnet device data into cloud-side protocols such as MQTT and HTTP through Edge Gateway or protocol conversion modules, enabling building devices to connect to the cloud. The gateway is responsible for BACnet object discovery, polling, or subscription, and maps the data to platform Thing Model attributes, supporting remote monitoring, alarms, and energy analysis.

Use Cases

Suitable for smart buildings, campuses, hotels, hospitals, and other scenarios. The integration of BACnet with the IoT platform allows unified access to cross-brand building devices, centralized monitoring, and energy efficiency optimization, supporting green building certification and reducing operation and maintenance costs.

How object properties map onto the platform

In device management, BACnet means treating analog, binary, and multi-state values inside a building controller as addressable objects, not as an opaque serial message. Each object has an instance number and a set of properties. Reading a property returns the current value. Writing a property is the control. The platform usually does not sit on the whole building network. A gateway discovers objects, reads them on an agreed cycle or accepts change-of-value notifications, and writes them as properties the device access layer can recognize. The mapping has to keep object type, instance number, and unit. Stuffing the number into a field called “data” makes it impossible later to tell temperature, valve position, and run state apart.

This is appropriate when the site controllers already expose objects over BACnet, and the gateway and the controllers are on the same building network or on a routable BACnet link. If a controller offers only a vendor’s private registers and has no object table, it should not be described as already accessed over BACnet. Who may write which property must be authorized on its own. A read-only point must not become writable just because it was mapped onto the platform. The priority array has to be kept as well. In a building, manual override, schedule, and emergency often occupy different priorities. If the platform always writes the same priority, it either covers a higher-priority protection on site or its own command never takes effect.

When field device numbers and network numbers collide

A likely mistake is a device instance number repeated across buildings. After routing, a BACnet device instance should be unique on the network. If two controllers both keep the factory default number, the gateway reads their objects into each other, and the curve on the platform actually comes from the other machine. An inconsistent network-number plan also makes routing come and go. The same segment configured as two network numbers can be discovered, then time out on a later property read. Treating a COV subscription as a guarantee of live data is another mistake. After the controller restarts, or after the subscription table is full, notifications stop, and the platform still shows the last old value. It looks like data that is healthy but no longer changing.

When a control write fails, distinguish a property that is not writable, a priority that is occupied, and a data type that does not match. Writing a float into a binary object, or writing an enumeration as free text, is rejected by the controller. If the platform records only “delivery failed” and does not keep the error class, the site cannot tell whether to change the thing model or the controller. Used together with device monitoring, offline should point at this controller or this routed segment, not mark the whole building as one device offline. Polling too often fills an MS/TP bus and shows up as random timeouts. The root is the scan cycle, not a point that is itself broken.

When a write priority is already taken on site

Inside a building controller, the same property often has several priority levels. A manual knob, a time schedule, an emergency action, and the building management system each write one level. If the platform does not know which level it should write, two opposite faults appear. Writing too low a level leaves a higher level on site covering it: the command looks sent, and the device does not change. Writing too high a level presses down on an emergency or fire interlock until someone remembers to clear it. During mapping, record whether this property has priorities, which level the platform always uses, and whether a clear writes an empty value or a relinquish command. An integration with no relinquish leaves one test write occupying that point permanently.

A read should not take only the value currently in effect. The same effective value may come from a schedule or from a manual level that someone has locked. Sending one number to the platform makes operations treat it as the result of their own last delivery. If change-of-value notification is not subscribed again after the controller restarts, the platform keeps showing the number from before the restart, which does not match the screen in the control room. Troubleshooting should be able to see the object instance number, the priority currently in effect, and the reason for the latest failed write. Folding a whole building into one device, without keeping controller boundaries, makes this mismatch impossible to place in a specific control cabinet.

Related Terms

Return to Device Management Platform terminology