Sync Bacnet Alarms

Sync Bacnet Alarms

In order to sync alarms made in Bacnet, the points need to exist in the DB Builder app after dragging them in from the connector. Most of the time, it would just work without a tuning policy.

  • If alarms don't automatically come in, the user will have to make sure a connTuning policy is on the connector on which the points are coming from and that's it.

Here is how to create a tuning policy and adding it to a connector.

Distech Tip

For the alarms to come in from a Distech device, the user has to make sure the Recipient settings are configured in the Notification Classes.

  • The user would have to add the IP Address of the machine that FIN Stack is running on and the IP Port of which it is on.

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:

  1. 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 “RECIPIEN_LIST"

  2. Event Enrollment Objects

    • 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 “RECIPIEN_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

  3. 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 "RECIPIEN_LIST" property of the Notification Class Object referenced by the "NOTIFICATION_CLASS" property

 

AV1 can support two types of reporting:

  1. 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 "RECIPIEN_LIST" of NC1

  2. 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 "RECIPIEN_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 (for more information on how Alarms work to see the Alarms doc).

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. On Finstack, all connectors by default have a LocalVirtualDevice (only one for all) in the background.

  • only works it 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 connTunningPolicy. The tag has a string value that can be:

- "useDevice"  - "useAddress" - "useBoth"
  • when subscribing using the BACnet address, as I said earlier, we need the local BACnet address that is not always the same as the binding address. I 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 connTunningPolicy 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 I said 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 connTunningPolicy. The default value is 0.