Only Niagara components in the station that are exported as BACnet objects can generate BACnet alarms, where alarming capability is “intrinsic” to that object. For example, a Niagara control point exposed as an Analog Input object must use an OutOfRange algorithm (in Niagara, an OutOfRangeAlarmExt)—another alarm extension, say the StatusAlarmExt, is not supported.

In general, only components exported as BACnet object types Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Multistate Input, Multistate Output, or Multistate Value are good candidates. (Exported Calendar and Schedule components are not alarmable). In the station these are typically control points (often proxy points), but may include various components from the kitControl module—at least those with a “NullProxyExt”.

Only one alarm extension is supported on a Niagara point configured for BACnet alarming (referencing an AlarmClasss linked to a BacnetDestination).

A separate BacnetDestination component must be added under the station’s AlarmService for each remote BACnet client to which alarms need to be sent (one-to-one BacnetDestination to device). In this component, you specify the unique BACnet device identifier for this device, and possibly make other non-default configuration changes.

Each AlarmClass component that you link to a BACnetDestination component must be exported to BACnet, as a Notification Class object. Linked BacnetDestination components automatically appear as entries in the “Recipient List” of these Notification Class objects.

Unless “escalation levels” are defined in AlarmClass components that are used, alarms are not regenerated. If a BACnet device is down when Niagara sends an alarm, the alarm is not saved for retransmission. Of course the station maintains a record of alarms in the alarm database.