Sync BACnet Alarms

In order to sync the alarms from a device, the alarmable BACnet object(s), including Event Enrollment (EE) if used, need to be added into the database. Once an object is added to the database, FIN will add itself to the recipient_list of the Notification Class object under the process ID 333. With that, alarms should then start syncing between the BACnet device and FIN.

For troubleshooting alarm issues, refer to BACnet Troubleshooting | Issue 17: Alarms not coming in

How BACnet Alarms work

BACnet Alarms are usually sent when an object's STATUS_FLAG property changes value.
To exemplify the workflow we will consider an Analog Value Object as the object the Alarm refers to (informs about).

There are 3 types of objects involved in sending BACnet Alarms:

Notification Class Object
- this is the object that contains the list of BACnet devices that will receive an Alarm.
- the list is being kept in the property RECIPIENT_LIST
Event Enrollment Object
- this object monitors the STATUS_FLAG property of other objects and if that property changes the value it will send the Alarms
- the object that it monitors is referenced by the property OBJECT_PROPERTY_REFERENCE
- this object has a property NOTIFICATION_CLASS that references a Notification Class Object
- when the STATUS_FLAG changes for the object referenced by the property OBJECT_PROPERTY_REFERENCE, the Event Enrollment object will send an Alarm to each device in the RECIPIENT_LIST property of the Notification Class Object referenced by the property NOTIFICATION_CLASS
- Setup Example:
  - Notification Class Objects NC1 and NC2
  - Analog Value Object AV1 that has property NOTIFICATION_CLASS=1
  - Event Enrollment Object EE1 that has properties OBJECT_PROPERTY_REFERENCE=AV1 and NOTIFICATION_CLASS=2
Analog Value Object
- this object can be of any type that can support reporting; we chose this type just as an example
- the object has a property NOTIFICATION_CLASS that references a Notification Class Object
- when the STATUS_FLAG property changes, the object will send an Alarm to each device in the RECIPIENT_LIST property of the Notification Class Object referenced by the NOTIFICATION_CLASS property

AV1 can support two types of reporting:

Intrinsic Reporting: where it's in charge of monitoring its own state, and when this changes, it sends Alarms to the devices from the property "RECIPIENT_LIST" of NC1
Algorithm Reporting: where an external Event Enrollment object EE1 monitors the state of AV1, and when this changes, it sends Alarms to the devices from the property "RECIPIENT_LIST" of NC2

The user doesn't have to restart the connector to subscribe to the notification class. The function bacnetNotificationsSubscribeConn() can be used.

This function tries to subscribe to Alerts for all the points dragged from the connector.
If the point is already subscribed it will have no effect. It also returns all the successful subscriptions, including the ones that were already done.

There is also a function named bacnetGetNotificationSubscriptions() that returns all the current Alarm subscriptions for a connector, without doing anything else, sending any requests to the device.

Additional information

To subscribe, a BACnet connector needs to add itself as a recipient in the property "RECIPIENT_LIST" of a Notification Class Object.

According to BACnet documentation, a recipient can be defined by it's device ID or by it's BACnet address.

How the recipient this works:

1. A recipient defined by it's device ID:

every recipient is a BACnet client and so, it has a device ID, to be reachable by other BACnet devices in the network. In FIN, all connectors by default have a LocalVirtualDevice (only one for all) in the background.
only works if both the recipient (BACnet client) and the BACnet device are in the same BACnet network
if a BACnet device has a recipient with the device ID, it will send out periodically WhoIs messages, querying about that device ID, saves the address that responds with IAm and sends Alarms to that address

2. A recipient defined by it's BACnet Address:

this is used when the recipient (BACnet client) and BACnet device are on different BACnet networks. Because of that, the WhoIs will not work, so it needs the address directly
the BACnet address we are referring to here is the local BACnet address of the recipient (our BACnet connector)
it is the BACnet address other devices use to communicate with our BACnet connector.
it is the same as the BACnet binding address if the binding address is not the default 0.0.0.0
the recipient also needs to have the network number the BACnet client is in. Here we have a problem because our BACnet connector does not have any knowledge about the BACnet network he is in.

How to configure on a BACnet connector, what type of recipient to register itself as:

by default a BACnet connector will subscribe as a recipient using the device ID
to explicitly specify how to subscribe you can add the tag "bacnetAlarmSubscribeType" on the connector or on the connTuningPolicy. The tag has a string value that can be:

- "useDevice" 
- "useAddress"
- "useBoth"

when subscribing using the BACnet address, as mentioned earlier, we need the local BACnet address that is not always the same as the binding address. We added a mechanism to try to determine as best/accurate as possible the local BACnet address. But the user can also add the tag bacnetAlarmSubscribeAddress on the connector or on the connTuningPolicy to explicitly specify the local BACnet address, e.g."bacnetAlarmSubscribeAddress":"192.168.1.23:47808". It only works for BACnet UDP addresses.
when subscribing using the BACnet address, as mentioned earlier, we need the network number and the BACnet connector does not have any knowledge about it. This must be defined explicitly by adding the tag bacnetAlarmSubscribeNetwork on the connector or on the connTuningPolicy. The default value is 0.