Alarms

Allows users to view and manage alerts generated from existing alarms regarding sites and equipment monitored by the FIN BMS, when either conditions fall outside of set parameters, or a failure occurs.

There are two separate databases: one for alarms and one for historical data.

• The alarms database tracks active and unacknowledged events in real time.

• The history database stores all past events, providing a complete record over time.

Accessing the Alarms app

The Alarms app can be accessed in several ways. See below:

App Launcher Menu

The Alarms App can be found in the App Launcher Menu under the "End User Apps" section.

Open

Related Bubbles

The Alarms App can also be accessed via Related Bubbles. The Alarms bubble will only appear if alarms are present under the selected target.

Open

Navigation Header Badges

Another way to access the Alarms App is by clicking on the Navigation Header's Alarm badges that appear in "Red" for objects that have an alarm referencing them.
Alarm count is based on all active alarms, whether acknowledged or not.
Note: Its not a live count, the browser needs to be refreshed to see the latest count.

Open

Status Indicator Labels (Graphics)

Similar to how one would access the Alarms app via the Navigation Header badges, users can click on the 'red' Alarm portion of the status indicator component to open the Alarms app.
Alarm count is based on all active alarms, whether acknowledged or not.

Open

Notification Popup

Additionally, the user can click on the alarm notification popup to open the Alarms app.

Open

Alarms App Dashboard Summary

Open

Related Topics 

When using the alarms app, the following workflow may be generally followed: 

• Viewing alarms—this is the view from which alarms can be monitored for changes in alarm status warranting attention. From here actions can be logged and status changed to “acknowledged.” 

• History—the history of each alarm’s change in status and logged responses can be viewed here, along with associated metadata.

• Filtering alarms—using advanced search, alarms can be filtered from the alarming, history, and toggle history views. 

Viewing Alarms 

1. From your desired context navigate to the alarms app. 

2. The relevant alarms list will open displaying current alarms for that target. 

Individual columns may be sorted by ascending or descending order. To do so, select the column title—an up or down arrow will display indicating the current state. 

 Some columns can be hidden when unneeded, see following section. 

Customize Columns 

To customize the columns: 

1. Select the kebab menu symbol (⋮).

2. Select the resulting Column visibility dropdown.

   Open

   

• The Customize Columns popup will display. 

  Open

  

The following rows are either fixed (mandatory) or may be made visible by selecting the toggle button > Apply. Revert these changes by selecting Cancel or Restore to default. 

Contextual Alarm List and basic filtering 

The “Alarms” tab view presents users with specific information regarding relevant alarms based on the context from which they navigated. For any alarm, this list provides the following:

States

State	Status	Description

State	Status	Description
Open	not in alarm, acknowledgement required	Event source active: not acknowledged Note: Relevant only to BACnet alarm functionality.
Open	not in alarm	Event source inactive: not acknowledged
Open	in alarm	Event source active: not acknowledged
Open	in alarm, acknowledged	Event source active: acknowledged
Open	not in fault	Event source inactive: not acknowledged and Fault alarm
Open	in fault	Event source active: not acknowledged and Fault alarm
Open	in fault, acknowledged	Event source active: acknowledged and Fault alarm

• Alarming status—whether underlying conditions triggering the alarm have been resolved by the user or further attention is required, delineated by “event source active” and “event source inactive”. 

• Acknowledgment state—whether the alarm has been acknowledged by the user, delineated by “acknowledged and ”unacknowledged”. A status of “Alarming” signifies an "Alarm" state regardless of acknowledgement state, excluding items only in fault. An status of “unacknowledged” signifies unacknowledged alarms in fault within the current context regardless of alarm status. 

• Faults—an alarm status of fault signifies alarms from devices that sending back data outside expected parameters, regardless of current alarm or acknowledgement state

BACnet - Acknowledgement required

When Acknowledgement Required is enabled for "To-Normal" in a Notification Class, a normal event will appear with a solid grey bell icon. This indicates that the object has returned to a normal state (i.e., goes out of alarm) and requires acknowledgement.

If you do not want this behavior, you need to disable the Acknowledgement Required setting for "To-Normal" in the Notification Class on the device side.

Open

To filter alarms at a basic level by these categories, select the corresponding tab in the left-hand lower menu bar.

Open

Advanced filtering 

The advanced view allows users to search for specific values and refine results with one or more filters.

Open

• Acknowledgment state—whether an alarm has been acknowledged by the user. 

• Alarm state—search just for alarms with “in alarm”, “not in alarm”, or “fault” status. 

• Priority—search for alarms by priority level. Alarm priorities range from 1 (most critical) to 255 (least critical).

• Occurrence—restrict the query to alarms occurring “on”, “on or before”, or “on or after a selected day”, using =, >, and <. 

• Haystack filter—search for alarms by associated haystack tags. 

Examples

Open

1. Filter for all alarms that have occurred after September 5th, 2025 and are currently in alarm.

   Open

   

2. Filter for all alarms with priority upper limit (>150) and are currently unacknowledged.

   Open

   

3. Filter for all alarms with state “offNormal” and event value (curVal) is greater than 90.

   Open

   

4. Filter for all alarms that have “lighting” tag in the metadata dictionary tag.

   Open

   

5. Filter for all alarms from equip named 'VAV-01' and the point named 'Fan' under that equip.

   Open

   

Acknowledge All 

To acknowledge all alarms: 

1. Select Acknowledge all.  

• A module will display stating the total number of alarms available for acknowledgement. You will be prompted to enter an optional acknowledgement message, which will display in the Messages column of the acknowledged alarm. 

Acknowledge Specific Alarms

To acknowledge specific alarms: 

1. Select one or more alarms that you would like to acknowledge. 

• The selected alarms will be highlighted in taupe grey. 

2. Select Acknowledge selected alarms. 

• A popup will display, stating the number of alarms available for acknowledgment and prompting the user to enter an optional acknowledgement message, which will display in the Messages column of the acknowledged alarm.

  Open

  

• Select Acknowledge. 

• Next to the alarm, the columns “Acknowledged at” and “acknowledged by” will now describe the time and agent of acknowledgement. Users may track the state transition of their acknowledged alarm in alarms info menu. 

Current Alarm Acknowledgement Status 

Some alarms take time to acknowledge, and their progress statuses will display in the sidebar Alarm acknowledgement info menu popup found on the right-hand side—in progress or failed are the two possible alarm transition states.

Open

Viewing History for all alarms 

Select the History button to view a basic list of all events associated with alarms. To more closely examine logged event details in the context of the chosen alarms, select Toggle History.

Open

Additional options are available in the top-right corner:

• Refresh history - Updates the list to include any recent changes or new events.

• Download history - Exports the complete alarm history as a CSV file.

Event Icons

Icon	Description

Icon	Description
Open	Acknowledgement of event source
Open	Event source went active
Open	Event source fault detected
Open	Event source went inactive
Open	Return to normal

Contextual Alarm History using Toggle History

Upon selection of one or more alarms, data is displayed from within a specific Alarm Context or Alarm Sub-Context. 

• You have selected one or more alarms. 

1. Select Toggle History. 

• A page displays the history of the selected alarm(s).

  Open

  

Message displays all alarms for which a user entered a message upon acknowledgment.   

Alarm Settings 

1. From the Alarms app, select the kebab menu symbol (⋮) in the upper-right menu > Settings.

   • The Alarm Settings popup will display.

Open

2. Set the following: 

   • Toggle New Alarm Sound—alarm notifications accompanied by sound.

3. When finished, select Save. 

Example of an Alarm Email

Below is an example of an alarm email that is sent when an alarm is triggered and when it returns to normal. An email will only be sent if SMTP settings are properly configured and the user is subscribed to receive alarm notifications.

Open

Open

Users have the flexibility to design custom email templates tailored to specific notification needs. Once created, these templates can be linked and used within the Notifications system to control how alarm or event messages are delivered.

Alarm engine

The alarm engine and its components are entirely data-driven, meaning they are configured through database records and automatically stay in sync with any updates made to those records.

Additional components include the Rules Engine, Alarm Router, and Notification Extension, each playing a distinct role in how alarms are triggered, routed, and communicated.

Rule Engine: The Rule Engine allows you to define conditions that trigger alarms based on your data. It continuously monitors incoming data and activates alerts when specified criteria are met.

Alarm Router: The Alarm Router determines how alarms are processed once triggered. Each route is defined by a database record containing specific tags that control how and where the alarm is forwarded or acted upon.

Notifications: The Notification System handles the delivery of alerts or messages for entities within the system. Currently, alarms are the only entity utilizing this system to send notifications.

Axon functions

These functions are used to interact with the alarm engine.

• toAlarm - This function is used to transition an entity into a given state and has the following parameters in order:

  • targets (required) - list of targets to transition

  • state (required) - to transition targets to (offNormal, normal, fault, ...)

  • message (optional) - the message for the alarm transition

  • occurred (optional) - the time the alarm occurred. If this is omitted, the system will use the current time

  • priority (optional) - priority of the alarm. if this is omitted, the system will use this priority configured for the state.

  • metadata (optional) - this is a miscellaneous dictionary of tags that will follow the lifecycle of the alarm.
    for compatibility, if "ackRequired" is set on the metadata, it will take precedence over the state's configured ackRequired flag.

• toNormal - This function is used to transition an entity into a normal state and has the following parameters in order:

  • targets (required) - list of targets to transition to normal

  • message (optional) - the message for the alarm transition

  • occurred (optional) - the time the alarm occurred. If this is omitted, the system will use the current time

  • metadata (optional) - this is a miscellaneous dictionary of tags that will follow the lifecycle of the alarm.
    for compatibility, if "ackRequired" is set on the metadata, it will take precedence over the state's configured ackRequired flag.

• alarms - This function is used to query the alarm database and has the following parameters in order:

  • targets (optional) - list of targets to query alarms for. If this parameter is null it will query everything

  • span (optional) - DateSpan used to filter alarms. If this is null it will return alarms for all dates

  • filter (optional) - filter used to filter alarm result

• alarmsGetById - This function is used to get an alarm record by the alarm record's id. it has the following parameters in order:

  • alarmId - a ref of the alarm to return

• alarmAck - This function is used to acknowledge alarms and has the following parameters in order:

  • alarms (required) - Alarm(s) to acknowledge in any of the following formats: (Grid, Dict[], Ref[], Dict, Str, Ref)

  • message (optional) - acknowledgement message

• readAlarmHistory - This function is used to query the alarm history database and has the following parameters in order:

  • targets (optional) - List/Grid of targets or target ids to query database for. If omitted this will query the database for all entities

  • span (optional) - DateSpan to used to query the history database. If omitted this will return records for all dates in the database

• alarmHistoryCount - This function will return the number of alarm history records in the database and has the following parameters in order:

  • target (optional) - this is the rec or id of the target. If omitted, it will count all records in the database.

• clearAlarmHistory - This function will clear the alarm history database and has the following parameters in order:

  • spanOrBefore (optional) - DateSpan of entries to clear

  • rebuild (optional) - if spanOrBefore is null and this is true, it will destroy the history database and recreate its schema.

• clearAlarmHistoryBefore - This function clears entries from the alarm history database based on a specified date:

  • date (required) - Deletes all alarm history entries before the specified date.

• alarmsRemove - This will delete the alarms.

• alarmDigest - returns a current list of active alarms from a site record.

Notifications

• notifyTarget - This function is used to manually send an interest to a notification target. This function has the following parameters in order:

  • target (required) - This is the record or Ref to the notificationTarget such as a Direct Email, Email Topic, or Push Bullet Target

  • interest (required) - This is the source for the notification and will be used to populate the template.

Example Axon Queries