What UnconfirmedEventNotification Is
UnconfirmedEventNotification is an alarm-and-event service in BACnet, defined in Clause 13.9 of ANSI/ASHRAE 135-2024. A notification server uses it to tell one or more remote devices that an event has occurred when it does not need confirmation that the notification was received. It is an unconfirmed service, so there is no receipt. Applications that need to know the notification arrived use ConfirmedEventNotification instead.
Unconfirmed does not mean unsuitable for alarms. An alarm can be announced this way and still require a human response, because operator acknowledgment travels separately through AcknowledgeAlarm. A device that executes this service must support programmable process identifiers so broadcast and multicast recipients can be assigned per installation.
How It Works
The notification carries the same information as the confirmed form: 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. No response comes back. Because it needs no receipt, one invocation can reach many recipients at once through a broadcast or multicast address.
Where You’ll See It
- One-to-many alarm announcement. A device can announce an event to every workstation on the network with a single broadcast, rather than a separate confirmed invocation per recipient.
- Acknowledgeable alarms without a delivery receipt. The notification can still set
AckRequired, so operators acknowledge through AcknowledgeAlarm even though the announcement itself was never confirmed. - High-volume event streams. Sites that generate many low-priority events use the unconfirmed form to avoid an acknowledgment round trip per notification.
UnconfirmedEventNotification Error Codes
UnconfirmedEventNotification is an unconfirmed service, so it has no acknowledgment and returns no application-layer error. A notification that does not reach a recipient is not a service error; the usual causes are delivery problems:
- The notification is broadcast or multicast and never crossed to another IP subnet because no BACnet BBMD path exists.
- The receiving device was not configured with the process identifier the notification carried.
- The sender and the recipient are on different networks with no router between them.
Profiles That Require It
UnconfirmedEventNotification 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 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 the notification) | AE-N-A | Operator workstations and the operator-display profiles |
What Chipkin Provides
The CAS BACnet Stack generates UnconfirmedEventNotification from event-initiating objects on the server side, sharing the same intrinsic event algorithms as the confirmed form; 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.