All proxy points (regardless of property chosen for polling), poll the target object’s Status_Flags property (if present). This reflects in the proxy point’s status, as it is “merged” with the native Niagara status for the point itself. For details, see Status merger for Bacnet proxy points.

Prioritized points (for objects with Priority_Array property) always poll that property in addition to the chosen property, such that this extra information is seen in the point display, using a “bac=n” display convention to show the currently active level.

Points polled from the “dibs” stack in any Poll Service (highest priority) are always polled using the ReadProperty service instead of ReadPropertyMultiple. This individual poll technique does not always make best use of polling bandwidth.

BacnetDevice components use a “maxDevicePollSize” property, a dynamic property that is sometimes added and (initially) auto-calculated when the device is learned or created, going by the property “maxAPDULengthAccepted” in its corresponding Device object. The purpose of this property was to allow tunable “group polling” (ReadPropertyMultiple service, if supported by device), specifying the number of points per poll—where you may adjust it downwards, if found necessary. This was sometimes needed if polling was for points with larger, unbounded data types, such as string or octet-string. Also, this property could automatically decrement on its own, in certain scenarios where polling issues occurred. In these cases, this resulted in more poll list entries (using single ReadProperty service).