Who-Is, I-Am, and ReadPropertyReadProperty, COV, WriteProperty)Analog Input with Present Value, which the BMS can read or subscribe to using COVBACnet has become one of the reference protocols for building automation, enabling HVAC, lighting, metering, and many other systems to communicate over a common language. In modern smart buildings, hundreds or even thousands of devices need to exchange data reliably across different vendors and technologies.
To make that possible, each device must be uniquely identifiable within the BACnet ecosystem. This is exactly the role of the BACnet Device Instance: a numerical identifier that allows a Building Management System (BMS) or supervisory platform to know which physical device it is talking to at any time.
If you’re just getting started with BACnet in general, it’s useful to first understand the protocol at a high level. You can read more in Actility’s introductory guide “What is BACnet?” . For a deeper dive into frames, objects, and services, you can also explore “BACnet Protocol Basics”.
In this article, we’ll focus specifically on the Device Instance:
In BACnet, every physical or virtual device is represented by a Device Object—a special object type that contains key information such as vendor ID, model name, object list, firmware revision, and more. One of the most critical properties of this Device Object is the Device Instance.
The BACnet Device Instance is a unique 22-bit numerical identifier assigned to each BACnet device within an internetwork. It ensures that no two devices share the same identity, allowing them to be reliably addressed, discovered, and managed.
When a BMS platform discovers devices on the network, it does not rely on the IP address or MAC address to represent the identity of the controller. Instead, the Device Instance becomes the canonical, stable reference.
For example:
These numbers allow the supervisory system to uniquely identify and map every device, even across VLANs, routers, or multi-site architectures.
“In modern BACnet architectures, the Device Instance is far more than a simple identifier. It is the backbone of interoperability — the anchor that allows thousands of devices to communicate reliably across complex, multi-vendor environments. Without a disciplined approach to Device Instance management, scalability and stability simply cannot be achieved.”
The BACnet Device Instance is defined by the BACnet standard as a 22-bit unsigned integer. This creates a strictly controlled numeric range that ensures consistency and interoperability across all BACnet-certified manufacturers.
A 22-bit number gives a maximum possible value of 4,194,303, but the highest valid Device Instance is 4,194,302 (0x3FFFFE).
The top value (4,194,303) is reserved and should never be used.
| Range | Meaning |
|---|---|
| 0 – 4,194,302 | Valid BACnet Device Instance values (22 bits) |
| 4,194,303 | Reserved / Invalid value |
| ≥ 4,194,304 | Out of specification |
The BACnet Device Instance is defined by the BACnet standard as a 22-bit unsigned integer. This creates a strictly controlled numeric range that ensures consistency and interoperability across all BACnet-certified manufacturers.
BACnet was designed to support massive building automation deployments, potentially involving tens of thousands of devices across campuses or even entire cities. A 22-bit space ensures:
The BACnet Device Instance is defined by the BACnet standard as a 22-bit unsigned integer. This creates a strictly controlled numeric range that ensures consistency and interoperability across all BACnet-certified manufacturers.
The BACnet Device Instance is not just a configuration parameter—it is a core element of the BACnet architecture. It enables reliable communication, discovery, and supervision across devices from different vendors and network segments. Without it, a BACnet system simply cannot operate correctly.
Every BACnet device must have a unique Device Instance within the same internetwork.
If two devices share the same number:
Uniqueness is not optional — it is a strict requirement for BACnet communication.
BACnet routers, BMS platforms, and field devices use the Device Instance as the primary global identifier to route messages across:
Even if IP addresses or MAC addresses change, the Device Instance provides a stable identity that ensures consistent communication across the entire system.
When a supervisory system performs device discovery using BACnet “Who-Is” and “I-Am” services:
The Device Instance is therefore the primary key for discovery and auto-mapping mechanisms.
Within a BMS, the Device Instance is used as the long-term reference for:
It remains constant even when IP addresses, network topologies, or hardware configurations evolve.
In large-scale environments—airports, hospitals, universities, industrial sites—tens of thousands of devices must coexist. The Device Instance makes it possible to:
It is a foundational requirement for reliable, scalable smart building infrastructures.
BACnet relies on the Device Instance at multiple layers of the protocol: routing, discovery, supervision, and cross-network communication.
Below is a clear visual summary of how and where this identifier is used.
| Function | Description |
|---|---|
| Global Device Addressing | BACnet targets devices using their Device Instance rather than IP or MAC addresses. |
| Inter-network Routing | Routers use the Device Instance to determine the correct path across subnets, VLANs, or MSTP segments. |
| Device Discovery (Who-Is / I-Am) | The Device Instance is the key identifier used during automatic BACnet discovery. |
| BMS Point Binding | BMS systems bind point lists to a device based on its Device Instance, not its IP. |
| Alarm & Trend Mapping | Historical logs, alarms, and notifications are stored against the Device Instance. |
| COV Subscriptions | COV (Change of Value) reporting uses the Device Instance to track subscriptions. |
| Firmware & Configuration Management | Upgrade processes and configuration templates target devices via their Device Instance. |
| BACnet/SC Routing | In BACnet Secure Connect, the Device Instance remains the primary logical identifier. |
Choosing and managing BACnet Device Instances is not just a technical detail — it is a design decision that directly impacts scalability, maintainability, and troubleshooting in your building automation system.
A good strategy will:
Below are common strategies and best practices.
| Strategy | Description |
|---|---|
| Sequential numbering | Assign Device Instances incrementally (e.g. 10000, 10001, 10002). Simple for small buildings and pilot projects. |
| Per building or site | Reserve a range per building (e.g. Building A: 100000–199999, Building B: 200000–299999) to avoid cross-site conflicts. |
| Per floor or zone | Encode floor or zone in the instance (e.g. 201xxx for 1st floor, 202xxx for 2nd floor) to make diagnostics easier. |
| Per device type | Use separate ranges for controllers, meters, sensors, gateways, etc., to simplify documentation and filtering. |
| Vendor-allocated ranges | Agree specific ranges with integrators or manufacturers to avoid overlap in multi-vendor projects. |
| Legacy system mapping | Keep a dedicated range to mirror legacy system IDs when migrating from an older BMS to a BACnet-based one. |
Beyond the strategy itself, day-to-day management is critical. Here is a compact “do and don’t” style view:
| Best Practice | Why It Matters |
|---|---|
| Document all assigned ranges | Maintains a single source of truth for integrators, operators, and future projects. |
| Avoid using manufacturer defaults | Default values often collide when multiple identical devices are deployed. |
| Validate uniqueness with BACnet scan tools | Quickly detects duplicate Device Instances before commissioning goes live. |
| Reserve buffer ranges for future expansion | Prevents fragmentation and renumbering when the building grows. |
| Align instances with naming conventions | Makes it easier to trace a device from documentation to BMS and on-site location. |
| Control who can change Device Instances | Reduces the risk of accidental changes that break BMS mappings and alarms. |
Even with a solid Device Instance strategy, issues can occur—especially during commissioning, migrations, or multi-vendor integrations.
Below is a clear, practical table summarizing the most common problems and how to fix them.
| Issue | Solution |
|---|---|
| Duplicate Device Instances | Reassign one of the conflicting instances and update documentation. Use BACnet scanners to verify uniqueness. |
| Factory default instances left unchanged | Always update default IDs during commissioning. Assign instances based on the site’s global addressing plan. |
| Unclear or inconsistent numbering strategy | Define a site-wide allocation plan (per building, floor, or device type). Communicate it to all integrators. |
| Conflicts after merging two networks | Create a consolidated addressing map and remap duplicate ranges before convergence of the networks. |
| Devices appearing in the wrong BMS location | Verify instance mapping, naming conventions, and segmentation settings. Check for address duplication. |
| Unknown devices discovered in the BMS | Scan the network to identify unregistered devices. Assign them to a proper range and update documentation. |
| MSTP devices missing from discovery | Check for duplicate Device Instances, incorrect baud rates, or faulty routing. Rerun Who-Is/I-Am queries. |
| Device Instance changed accidentally | Restrict permissions on device configuration tools. Restore the original value using the documentation log. |
Below are three practical scenarios illustrating how Device Instances can be structured in small buildings, campus environments, and migration projects.
| Scenario | Description |
|---|---|
| Small Building (100–150 devices) | A simple sequential range is sufficient (e.g. 50,000–50,150). Easy to maintain and ideal for small facilities. |
| Multi-building Campus (thousands of devices) | Assign a unique range per building (e.g. Building A: 100,000–149,999, Building B: 150,000–199,999). Prevents conflicts across large systems. |
| Migration from a Legacy BMS | Reserve a block replicating legacy IDs for compatibility (e.g. 200,000–205,000), then assign new ranges for BACnet-native devices. |
| Strategy | Description |
|---|---|
| Sequential Numbering | Easy to implement and suitable for small sites, but not scalable and offers poor structure for large networks. |
| Per Building Allocation | Prevents cross-building conflicts and simplifies troubleshooting, but requires upfront planning and reserved expansion ranges. |
| Per Floor / Zone | Intuitive and aligned with physical layout, yet can become complex and requires strict centralized coordination. |
| Per Device Type | Good for filtering and BMS reporting, but less intuitive for on-site technicians and devices become scattered. |
| Vendor-Allocated Ranges | Reduces multi-vendor conflicts, though only works if vendors consistently follow the agreed allocation rules. |
| Legacy Mapping | Helps migrations by preserving old identifiers, but may carry forward outdated or inconsistent numbering logic. |
No. The MAC address identifies a device on the local network segment, while the Device Instance is a logical BACnet identifier used across the entire internetwork.
No. Within the same BACnet internetwork, every Device Instance must be unique. Duplicate instances cause discovery problems, routing errors, and incorrect point mapping in the BMS.
You can typically find it in:
Yes, but it must be done carefully. Changing it without updating the Building Management System (BMS) references may break alarms, history logs, bindings, and COV subscriptions.
BACnet defines the numeric range (0 to 4,194,302), but not the allocation strategy. Projects must define their own scheme: per building, per floor, per device type, vendor-specific, etc.
Yes. Wireshark’s BACnet dissector displays the Device Instance in BACnet messages, especially in I-Am responses and other Device Object–related packets.
Conflicts will occur as soon as they form a single internetwork. One range must be renumbered before merging to avoid collisions.
Some devices allow dynamic assignment, but this is not recommended. Device Instances should remain stable to maintain consistent BMS references and avoid breaking integrations.
About Actility
Actility, one of the co-inventors of LoRaWAN® technology and a founding member of the LoRa Alliance, is the leader in industrial-grade low-power wide-area network (LPWAN) connectivity and IoT tracking solutions. Actility’s ThingPark™ platform, which supports multi-radio connectivity (LoRaWAN®, NB-IoT, LTE-M), powers the majority of public networks and numerous private and enterprise networks worldwide. Through its subsidiary Abeeway, Actility offers patented ultra-low power, multi-radio trackers and comprehensive indoor and outdoor geolocation services. Additionally, the ThingPark Market boast the largest catalog of LoRaWAN® devices, gateways, and solutions available.
Media contact : marketing@actility.com – https://www.actility.com/contact/
© 2025 Actility’s All Rights Reserved