What Is a BACnet Device Object?
Every BACnet device has exactly one Device object, and it is the first thing a client reads when it meets a device it does not know. The Device object is where the device announces its identity, lists every other object it holds, and declares which services and message sizes it supports. This reference explains what the Device object is for, which of its properties matter to an integrator, and why reading it is the natural first step in mapping any BACnet controller.
BACnet Device Object in one line: The Device object is the single mandatory object that describes a BACnet device as a whole. Its instance number is the device's address on the internetwork, and its properties tell a client everything needed to talk to the device: the Object_List of every object it holds, the Protocol_Services_Supported it will answer, the maximum message size it accepts, and vendor and model identity. A client reads the Device object first, then walks its Object_List to map the rest.
What the Device Object Declares
The Device object is a self-description of the whole controller. Its Object_Identifier carries the device instance number that names the device across the internetwork. Its Object_Name gives the device a human-readable label. Vendor_Identifier, Model_Name, and Firmware_Revision identify what the device is and what code it runs. Together these properties let a client, or a person browsing with a tool, know what they are connected to before reading a single point value.
The property that makes integration possible is Object_List: a list of the Object_Identifiers of every object the device contains. A client reads Object_List to enumerate the device's objects, then reads Object_Name and Present_Value for each to build a point list. This is the browse step that turns an unknown controller into a mapped one, and it is why BACnet integration is usually a matter of reading the device's own self-description rather than importing an external map. On large devices the Object_List can be long, which is one reason the batched read described in the ReadPropertyMultiple reference exists.
The Device object also declares the device's communication capabilities. Protocol_Services_Supported is a bit string saying which BACnet services the device will answer - whether it supports COV subscriptions, whether it supports ReadPropertyMultiple, whether it can be a time master, and so on. Max_APDU_Length_Accepted and the segmentation properties declare the largest message the device can receive and whether it can split large responses across multiple frames. A client that respects these declarations sizes its requests to what the device can handle, rather than sending a message the device will reject.
Why the Device Object Is the Starting Point
Reading the Device object first is the disciplined way to approach any BACnet device, because it turns guesswork into fact. Rather than assuming a device supports COV or ReadPropertyMultiple, a client reads Protocol_Services_Supported and knows. Rather than guessing at message sizes and triggering rejects, it reads the APDU limits and sizes accordingly. Rather than hunting for points, it reads Object_List and enumerates them. Every capability question about a device has an answer in its Device object.
The Device object is also where addressing and identity come together. Its instance number is what Who-Is and I-Am exchange during discovery, so the same number that identifies the device object identifies the device on the network. This is the tie between the object model and the network layer: the Device object is simultaneously an object you read and the address you reach the whole device by, a duality covered in the object identifier reference.
For a monitoring integration, the Device object is what a gateway or cloud SCADA reads to establish a durable connection to a controller. Reading Object_List once at commissioning captures the point set; reading the service and APDU declarations sizes the ongoing polling correctly. A platform such as Merobix that has mapped a device's objects from its Device object can then trend and alarm those points in the same historian as process data, without depending on rediscovering the device on every restart - the operating-dependency pitfall discussed in the discovery troubleshooting guide.
Frequently Asked Questions
How many Device objects does a BACnet device have?
Exactly one. The Device object is mandatory and singular - it describes the device as a whole, and its instance number is the device's address on the internetwork. Every other object the device holds is listed in the Device object's Object_List property, but there is only ever one Device object per physical device.
What does the Object_List property contain?
The Object_Identifiers of every object the device holds, including the Device object itself. A client reads Object_List to enumerate the device's objects, then reads each object's name and value to build a point list. On a large device the list can be long, so clients often batch the reads with ReadPropertyMultiple rather than issuing a separate request per object.
How does a client know which services a BACnet device supports?
By reading the Device object's Protocol_Services_Supported property, a bit string in which each bit indicates support for a specific BACnet service - COV subscriptions, ReadPropertyMultiple, time synchronization, and so on. Reading this before assuming a capability lets a client tailor its requests to what the device can actually answer, rather than sending a service the device will reject.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.