Alarm reception configuration

The bacnet driver supports intrinsic event reporting more commonly called alarming. Support is available for both client and server operations, which means that a station can both receive (and reroute) BACnet alarms from BACnet proxy points, and also send BACnet alarms from components that have been exported as BACnet objects.

Figure 1. Example of a BACnet alarm received in an alarm console

Prerequisites to receive alarms

To be received, a BACnet alarm must be generated by a BACnet device that is represented in the remote station. Otherwise, the driver discards the alarm.

Ideally, the alarming BACnet object should be represented by a Bacnet proxy point, in which case the alarm record source provides the proxy point name and ord. If the alarming BACnet object is not proxied in the station, the alarm record shows the source as the Alarms device extension (ord) of the corresponding BacnetDevice. In either case, alarm details provide the source Object Id, for example analogInput 3 current toState and statusFlags as well as any alarm message text.

Restrictions

AlarmClass components in the station’s AlarmService receive the BACnet alarms. Each device uses only one AlarmClass, as referenced in each BacnetDevice’s Alarms device extension. You can specify the same one (for example, the DefaultAlarmClass), or create and use separate alarm classes, as needed.

In the Notification Class object used by the sending BACnet device, any receiving station must be added in the Recipient_List property, using its numerical device ID (Local Device, Object Id). You configure this using the BACnet device’s native configuration tool, or, if the device supports it, directly from the driver using corresponding Config components for objects in that device.