Issue
COVNotification messages in BACnet captures.
Product Line
EcoStruxure Building Operation
Environment
- BACnet IP network
- BACnet MSTP network
- BACnet networks with controllers that support COV (Change of Value)
Cause
COV increment is an attribute that is available in several BACnet points that is settable and when this attribute COV Increment is left at a setting of zero can cause COVNotification messages appearing as broadcast storms creating un-necessary network traffic.
Resolution
It is suggested to set the value of the COV increment attribute to something other than the default zero or to a value that is pertinent to the point in question. The COVNotification services are uni-cast messages and can have a many to one relationship depending on how may clients are subscribing to the point.
Example:
Jobsite has a BACnet OAT (outside air temp) input point with the COV increment of zero. The OAT point is added to the watch window or a binding to a graphic or program. The OAT is changing ridiculously fast due to wind and intermittent clouds. The value is changing by 1/1000 of a degree and each COV (change of value) message is delivered out to any object that is referencing the point. But does the value need to display or do we care if the point changes by 1/1000 of a degree. Let's say that the sites requirement only needs value changes of 2 degrees or more. The COV increment can be set to 2.0 and now the UnconfirmedCOVnotification message would only be sent if the OAT changed by 2 degrees or greater. This alone would reduce 100's if not 1000's of network packets. Imagine a jobsite with the above scenario and 100 different points all with the COV increment of zero.
Setting the COV increment to something other than the default of zero is one of many ways to improve BACnet communications and reduce what may appear as broadcast storms on the network.
