What ConfirmedCOVNotificationMultiple Is
ConfirmedCOVNotificationMultiple is an alarm-and-event service in BACnet, defined in Clause 13.17 of ANSI/ASHRAE 135-2024. A server device uses it to notify a subscriber, in one message, that properties on one or more objects have changed. It is a confirmed service: the subscriber acknowledges each notification, so the sender knows the update was delivered. Subscriptions are established with SubscribeCOVPropertyMultiple, where the subscriber chose confirmed delivery.
It is the multi-property counterpart to ConfirmedCOVNotification. Where the single-object form reports one object’s changes, this service bundles changes from any objects and properties that share the same subscriber, address, and process identifier into one notification.
How It Works
The notification carries the subscriber process identifier, the initiating device identifier, the time remaining on the subscription, an optional timestamp, and a list of COV notifications, each naming an object and the properties whose values changed. The subscriber acknowledges receipt. Because delivery is confirmed, the notification is always unicast to the one subscriber that asked for it. When the timestamped flag was set at subscription time, the notification also carries the queued changes and the time each occurred, so the subscriber sees the full sequence rather than only the latest value.
Where You’ll See It
- Elevator and lift monitoring. An elevator controller reports a batch of changed status properties to a supervisory system in a single acknowledged message.
- Reliable multi-point delivery. Confirmed delivery suits status sets where a missed update matters, because the sender retries until the subscriber acknowledges.
- Timestamped change history. A subscriber that asked for timestamps receives the ordered sequence of changes queued since the last notification.
ConfirmedCOVNotificationMultiple Error Codes
Clause 13.17 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 one of the specified objects, properties, 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, often after it restarted and lost its subscription table while the server kept sending. The clause lets a subscriber ignore this case and acknowledge with a simple ACK 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
ConfirmedCOVNotificationMultiple splits by direction. The device hosting the monitored objects initiates the notification (DS-COVM-B); the subscriber executes it, meaning it receives and acknowledges. The requiring set is the elevator controllers that expose multi-property COV reporting.
| Direction | Required by BIBB | Profiles |
|---|---|---|
| Initiate (send the notification) | DS-COVM-B | B-EC, B-AEC, B-EM |
| Execute (receive and acknowledge) | DS-COVM-A | Operator and client profiles that subscribe to multi-property devices |
What Chipkin Provides
The CAS BACnet Stack sends ConfirmedCOVNotificationMultiple from the server side when subscribed properties change and tracks subscription lifetime. Talk to us about adding BACnet client or server support to your device.