What I-Am Is
I-Am is the device-announcement service in BACnet, defined in Clause 16.10 of ANSI/ASHRAE 135-2024. A device sends I-Am to advertise its Device object identifier, its maximum APDU (Application Protocol Data Unit) length, meaning the largest message it can accept in one exchange, its segmentation support, meaning whether it can split a large message across multiple packets, and its vendor identifier. It is an unconfirmed service, and it is the answer to a Who-Is request, though a device may also send it on its own.
Who-Is and I-Am are the discovery pair. Who-Is asks “who is out there”; I-Am is how each device replies “here I am, and this is my identity.”
How It Works
A device sends I-Am for one of two reasons: to answer a Who-Is whose device-instance range it falls within, or unsolicited, most commonly as a broadcast at power-up so any listening client learns of it immediately. The message carries the device’s instance number and the parameters a client needs to talk to it. The sender’s network address is not a field in the message; the receiver derives it from the packet, from the MAC address on the local network or the network-layer information for a device on a remote network.
Where You’ll See It
- Populating a device list. Every row a tool like the CAS BACnet Explorer shows after a discovery came from an I-Am.
- Power-up announcements. A controller rebooting broadcasts an unsolicited I-Am, which is how a head end (the central BMS server) notices a device came back without re-scanning.
- Duplicate-instance detection. Two I-Am responses carrying the same device instance are the signature of a device-instance conflict, one of the most common BACnet commissioning faults.
I-Am Error Codes
I-Am is an unconfirmed, often broadcast service, so it has no acknowledgment and returns no application-layer error. Problems show up indirectly:
- No I-Am after a Who-Is is a discovery or addressing problem: wrong network, no BACnet BBMD path, or the device instance outside the requested range.
- Two I-Am messages with the same device instance indicate a duplicate device-instance number, which must be resolved for reliable communication.
Profiles That Require It
I-Am pairs with Who-Is through the dynamic-binding BIBBs, and profiles require it by direction. Sending I-Am comes from DM-DDB-B and is required of nearly every device profile so it can be discovered. Receiving and processing I-Am comes from DM-DDB-A and is required of the client and operator profiles that build device lists.
| Direction | Required by | Profiles (examples) |
|---|---|---|
| Initiate (send I-Am) | DM-DDB-B | Nearly all device profiles: B-BC, B-AAC, B-ASC, B-SA |
| Execute (receive I-Am) | DM-DDB-A | Client and operator profiles: B-OD, B-OWS, B-AWS, and controllers acting as clients (B-BC, B-AAC) |
A device on an MS/TP segment (Master-Slave/Token-Passing, BACnet’s RS-485 serial transport) configured as a subordinate may be exempt from the dynamic-binding requirement.
What Chipkin Provides
The CAS BACnet Stack supports I-Am in both directions, announcing the device’s identity and processing the I-Am responses of others. Talk to us about adding BACnet client or server support to your device.