What ConfirmedCOVNotification Is
ConfirmedCOVNotification is an alarm-and-event service in BACnet, defined in Clause 13.6 of ANSI/ASHRAE 135-2024. A device that hosts a monitored object uses it to notify a subscriber that one or more properties of that object have changed. It is a confirmed service: the subscriber acknowledges each notification, so the sender knows the update was delivered. Subscriptions are established with SubscribeCOV or SubscribeCOVProperty, and the subscriber chooses confirmed or unconfirmed delivery when it subscribes.
COV (Change of Value) reporting replaces repeated polling. Instead of a client reading a point over and over, the device pushes a notification only when the value actually changes, which cuts traffic on busy networks.
How It Works
When a subscribed property changes past its COV increment, the device sends the subscriber process identifier, its own initiating device identifier, the monitored object identifier, the time remaining on the subscription, and a list of the changed values. The subscriber acknowledges receipt. Because delivery is confirmed, the notification is always unicast to the one subscriber that asked for it, never broadcast. A time remaining of zero tells the subscriber the subscription has an indefinite lifetime with no automatic cancellation.
Where You’ll See It
- Supervisory monitoring. A head end (the central BMS server) subscribes to the points it cares about, and the controllers push confirmed notifications as those points change, so the head end stays current without polling.
- Reliable value delivery. Confirmed delivery suits values where a missed update matters, because the sender retries until the subscriber acknowledges.
- Subscription upkeep. The time-remaining field lets a subscriber see when a subscription is about to lapse and resubscribe before it does.
ConfirmedCOVNotification Error Codes
Clause 13.6 defines the error class and code a subscriber returns when it cannot accept a notification. The general error model lives in Clause 18 of the standard.
| Situation | Error class | Error code |
|---|---|---|
| No subscription exists for the specified object, property, and process identifier | SERVICES | UNKNOWN_SUBSCRIPTION |
| The encoding of a value in a service parameter is not valid for its datatype | SERVICES | INVALID_DATA_ENCODING |
Reading these in the field:
UNKNOWN_SUBSCRIPTIONmeans the subscriber received a notification it has no record of subscribing for, often after the subscriber restarted and lost its subscription table while the server kept sending. The clause allows a subscriber to ignore this case and simply acknowledge instead of returning the error.INVALID_DATA_ENCODINGpoints to a malformed value in the notification, not a subscription problem.- No response at all is not a service error. A timeout means the notification never reached the subscriber or its acknowledgment never came back, which is a transport or addressing problem.
Profiles That Require It
ConfirmedCOVNotification splits by direction. The device hosting the monitored object initiates the notification (DS-COV-B for object subscriptions, DS-COVP-B for property subscriptions); the subscriber executes it, meaning it receives and acknowledges the notification (DS-COV-A, DS-COVP-A).
| Direction | Required by BIBB | Profiles |
|---|---|---|
| Initiate (send the notification) | DS-COV-B, DS-COVP-B | Controllers that host COV-reporting objects: life-safety, access-control, and elevator controllers |
| Execute (receive and acknowledge) | DS-COV-A, DS-COVP-A | Client and operator profiles that subscribe: operator workstations and supervisory controllers |
What Chipkin Provides
The CAS BACnet Stack sends ConfirmedCOVNotification from the server side when a subscribed property changes and tracks subscription lifetime; the subscriber receive side is implemented in Chipkin’s BACnet test tooling. Talk to us about adding BACnet client or server support to your device.