What UnconfirmedCOVNotificationMultiple Is
UnconfirmedCOVNotificationMultiple is an alarm-and-event service in BACnet, defined in Clause 13.18 of ANSI/ASHRAE 135-2024. A server device uses it to notify subscribers, in one message, that properties on one or more objects have changed. It is an unconfirmed service: the notification is sent and no acknowledgment is expected. Subscriptions are established with SubscribeCOVPropertyMultiple, where the subscriber chose unconfirmed delivery.
It is the unconfirmed counterpart to ConfirmedCOVNotificationMultiple. It can also carry unsubscribed notifications, distributing properties of wide interest, such as outside air conditions, to many devices at once without any subscription; those carry a process identifier of zero.
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. Nothing is returned. For a subscribed notification, delivery is unicast to the subscriber; an unsubscribed notification uses a process identifier of zero and a time remaining of zero, and may be broadcast. When the number of changes exceeds what fits in one message, the server sends as many notifications as needed to convey them all.
Where You’ll See It
- Shared environmental data. A device broadcasts outside air temperature or a similar value of general interest, and many devices consume it without ever subscribing.
- Lightweight multi-point monitoring. A subscriber that can tolerate an occasional missed update takes unconfirmed notifications to avoid the acknowledgment round trip on every change.
- Elevator status feeds. An elevator controller pushes a batch of changed status properties where the lower overhead of unconfirmed delivery is acceptable.
UnconfirmedCOVNotificationMultiple Error Codes
UnconfirmedCOVNotificationMultiple is an unconfirmed service, so it has no acknowledgment and returns no application-layer error. A notification that never arrives is not a service error; it is a subscription, addressing, or delivery problem. The usual causes:
- The subscription lapsed. Its lifetime elapsed with no re-subscription, so the server stopped sending.
- An unsubscribed broadcast did not reach the receiver because of a subnet or BACnet BBMD path problem.
- The receiver and sender are on different networks with no router between them.
- Because delivery is unconfirmed, an individual notification can simply be lost in transit with no retry.
Profiles That Require It
UnconfirmedCOVNotificationMultiple splits by direction. The device hosting the monitored objects initiates the notification (DS-COVM-B); the subscriber executes it, meaning it receives and processes the notification. 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 process) | DS-COVM-A | Operator and client profiles that subscribe to multi-property devices |
What Chipkin Provides
The CAS BACnet Stack supports UnconfirmedCOVNotificationMultiple, sending both subscribed and unsubscribed multi-property notifications from the server side. Talk to us about adding BACnet client or server support to your device.