What UnconfirmedCOVNotification Is
UnconfirmedCOVNotification is an alarm-and-event service in BACnet, defined in Clause 13.7 of ANSI/ASHRAE 135-2024. A device uses it to notify subscribers that properties of a monitored object have changed, or to distribute a value of wide interest (such as outside-air conditions) to many devices at once without any subscription. It is an unconfirmed service: there is no acknowledgment, so the sender never learns whether a given notification arrived.
COV (Change of Value) reporting replaces repeated polling. This unconfirmed form is the lighter-weight option: it fits values where an occasional missed update is acceptable, and it is the only form that can serve unsubscribed recipients.
How It Works
The notification carries the subscriber process identifier, the initiating device identifier, the monitored object identifier, the time remaining on the subscription, and the list of changed values, exactly as the confirmed form does, but no response comes back. When it results from a SubscribeCOV subscription it is unicast to the subscriber. For unsubscribed distribution the sender may broadcast or multicast, and a subscriber process identifier of zero marks the notification as unsubscribed. The algorithm that decides when to send an unsubscribed notification (change of value, a periodic timer, or some other trigger) is a local matter.
Where You’ll See It
- Broadcast of shared values. A device that owns an outside-air-temperature point can push it to every device on the network with one unsubscribed notification, so each controller reads a common value without its own subscription.
- Lightweight monitoring. A subscriber that chose unconfirmed delivery when it called SubscribeCOV receives these notifications without the overhead of acknowledging each one.
- High-rate points. Values that change often and tolerate an occasional loss suit unconfirmed delivery, which avoids the acknowledgment round trip.
UnconfirmedCOVNotification Error Codes
UnconfirmedCOVNotification is an unconfirmed service, so it has no acknowledgment and returns no application-layer error. A notification that does not produce the expected effect 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 listening for the process identifier the notification carried.
- The subscription lapsed on the sending device, so notifications simply stopped arriving.
Profiles That Require It
UnconfirmedCOVNotification splits by direction. The device hosting the monitored object initiates the notification (DS-COV-B and DS-COVP-B for subscribed delivery, DS-COVU-B for unsubscribed distribution); the receiver executes it (DS-COV-A, DS-COVP-A, DS-COVU-A).
| Direction | Required by BIBB | Profiles |
|---|---|---|
| Initiate (send the notification) | DS-COV-B, DS-COVP-B, DS-COVU-B | Controllers that host COV-reporting objects or distribute shared values: life-safety, access-control, and elevator controllers |
| Execute (receive the notification) | DS-COV-A, DS-COVP-A, DS-COVU-A | Client and operator profiles that subscribe or consume broadcasts: operator workstations and supervisory controllers |
What Chipkin Provides
The CAS BACnet Stack sends UnconfirmedCOVNotification from the server side, both for subscribed changes and for unsubscribed distribution; the receive side is implemented in Chipkin’s BACnet test tooling. Talk to us about adding BACnet client or server support to your device.