What ConfirmedEventNotification Is
ConfirmedEventNotification is an alarm-and-event service in BACnet, defined in Clause 13.8 of ANSI/ASHRAE 135-2024. A notification server uses it to tell a remote device that an event has occurred and to get back confirmation that the notification was received. It is a confirmed service, and the confirmation means only that the device received the message. It does not mean a human saw it. That second step, operator acknowledgment, is handled separately by AcknowledgeAlarm when the notification’s AckRequired flag is set.
Each recipient is notified with its own invocation of the service. When a receipt is not needed, the lighter UnconfirmedEventNotification carries the same information without the round trip.
How It Works
The notification carries the process identifier, the initiating device identifier, the event object identifier, a timestamp, the notification class and priority, the event type, an optional message text, the notify type (alarm, event, or acknowledgment notification), and, for alarms and events, the AckRequired flag with the from-state and to-state of the transition. The receiving device takes whatever local action it is configured for (logging the event, displaying it, routing it to an operator) and returns a positive result to confirm receipt. Because delivery is confirmed, each recipient gets a separate unicast invocation.
Where You’ll See It
- Alarm routing to a workstation. A controller that detects an off-normal condition sends a confirmed event notification to the head end (the central BMS server), which confirms receipt so the controller knows the alarm was delivered.
- Acknowledgeable alarms. When the notification’s
AckRequiredflag is TRUE, the receipt does not close the loop; the workstation still sends an AcknowledgeAlarm once an operator responds. - Fault reporting. A transition into a fault state arrives as a confirmed notification with an event type of
CHANGE_OF_RELIABILITY, so the workstation learns not just that a value is off but that the device distrusts its own reading.
ConfirmedEventNotification Error Codes
Clause 13.8 defines the confirmed result but does not list service-specific situations with their own error class and code; a receiver that cannot process a notification returns an error under the general model of Clause 18 of the standard. In practice the receiver rarely rejects a well-formed notification, because taking action on it is a local matter.
Reading these in the field:
- A device must not fail or return an error just because the message text is in an unsupported character set; the clause requires it to process the notification anyway and treat the text as a local matter.
- A returned error usually points to a malformed request or a receiver that is out of resources, not to a problem with the event itself.
- No response at all is not a service error. A timeout means the notification never reached the receiver or its confirmation never came back, which is a transport or addressing problem.
Profiles That Require It
ConfirmedEventNotification splits by direction. Originating the notification comes from the AE-N-I-B and AE-N-E-B building blocks (and AE-LS-B for life-safety events) and is required of the controllers that generate alarms. Receiving and confirming it comes from AE-N-A and is an operator-workstation behavior.
| Direction | Required by BIBB | Profiles |
|---|---|---|
| Initiate (originate the notification) | AE-N-I-B, AE-N-E-B | Controllers that generate alarms: B-BC, B-AAC, and the advanced life-safety, access-control, and elevator controllers |
| Execute (receive and confirm) | AE-N-A | Operator workstations and the operator-display profiles |
What Chipkin Provides
The CAS BACnet Stack generates ConfirmedEventNotification from event-initiating objects on the server side, including the intrinsic event algorithms that decide when a transition occurs; the workstation receive side is implemented in Chipkin’s BACnet test tooling. Talk to us about adding BACnet client or server support to your device.