Understanding Alarms
Identifying faults in devices and assets within an IoT network is the most vital part of any monitoring application. It provides insight into the health of devices and assets, and consequently, the overall health of the network. This capability allows for the prompt detection of issues and proactive management, ensuring timely resolution. Effective fault management not only mitigates risks but also maximizes the benefits of IoT technology across various applications and industries.
Alarm Scenarios
Alarms can be raised in various situations to indicate specific conditions in the devices and assets in the IoT network that require attention. Some common scenarios in IIoT, Energy Monitoring, HVAC, BMS, etc., setup are provided below:
- Energy Management: When energy consumption exceeds predefined limits or when energy-saving opportunities are identified.
- Environmental Monitoring: When environmental conditions, such as temperature, humidity, or air quality, reach critical levels or deviate from pre-defined thresholds.
- Production Issues: When production processes deviate from expected parameters, such as a drop in production rate or quality issues.
- Security Breaches: When unauthorized access or tampering is detected in the industrial network or systems.
- HVAC System Issues: When there are faults or malfunctions in heating, ventilation, and air conditioning (HVAC) systems, such as temperature sensors indicating extreme temperatures or air handlers not functioning properly.
- Power Failures: When there are power outages or failures in the electrical system, including backup power systems.
- Water Leaks and Flooding: When the water sensors detect a sudden drop in quantity, detecting leakages that damage the building.
- Carbon Emission Monitoring: When carbon emission levels exceed predefined thresholds, indicating potential environmental impact.
Alarm Properties
Before proceeding further, let's understand the alarm properties used in the application.
Term | Description |
Alarm Name | The unique name of the alarm. This name represents the problem or metric which is being monitored. For example, Fuel Level, Battery Charge Level, Filter Condition, etc. |
State | Represents the different conditions of an alarm. For example, a temperature monitoring alarm rule can have high, low, or normal conditions. Instead of creating different alarms for each such condition, the State option helps to consolidate all these conditions under a single alarm. Learn More. |
Previous State | Represents the previous state of an alarm. The previous state will be empty for a new alarm. |
Severity | Represents the criticality of an alarm (i.e. fault). The available severities are:
Where Critical is the highest severity, and Clear is the lowest severity. Learn More |
Previous Severity | Represents the previous severity of an alarm. |
Last Resolved time | Represents the date and time when an alarm severity is updated with Clear. |
Unresolved time | Represents the duration since the severity is updated from Clear to Non-Clear severity. |
Assigned To | Denotes the user to whom the alarm is assigned. The user can be a supervisor or technical person who takes actions on any notification sent for the alarm. |
Last Assigned Time | Denotes the date and time when an alarm is assigned to the user. |
Message | Is the message associated with an alarm describing it. |
Category | Denotes the name provided to a group of similar sets of alarms. This helps to filter and segregate similar alarms. For example, the category "Energy Alerts" can be created to segregate all energy related alarms. |
Created Time | Denotes the date and time at which the alarm is created. |
Modified Time | Denotes the date and time at which the alarm is last updated. |
Rule Name | Is the name of the alarm rule from which the alarm was generated. The name will be empty for System alarms. |
Caused By | Denotes how the alarm has been created in the application. For example, via. Alarm Rules or System Rules. Learn More |
Incident Occurred Time | Denotes the date and time at which the severity is updated from Clear to Non-Clear. |
Alarms Generation
Alarms in Zoho IoT are generated through one of the following processes.
- Alarm Rules
- System Rules
The flow diagram below describes how alarm rule alarms and system rule alarms are generated in the application.
Images: Flow diagram of alarms generation and alarm actions.
a. Alarm Rules
In the case of alarm rules, the datapoint values from the device, asset, or location, and device notifications are the primary inputs to determine any deviations. The datapoint values, such as temperature, fuel level, and CO2 level, pass through conditions defined in the alarm rule. The real-time incoming datapoint values or calculated KPI datapoints pass through these conditions, and the alarm is generated if the condition is satisfied.
The below diagram indicates some of the primary inputs configured as datapoints in a diesel generator for monitoring purposes.
Image of a diesel generator with fault monitoring datapoint parameters
The alarm rules generate alarms and perform user-defined actions when configured, such as executing commands, running custom logic functions, initiating webhook actions, and alerting users or personnel about critical events via email notifications.
Note: Generating alarms through alarm rules can be stopped by setting the Alarm Rule Status to OFF by editing the alarm rule.
b. System Rules
System Rule alarms are generated by the application automatically based on device notifications that occur in different scenarios. For example, system alarms are generated during device connect or disconnect, or authentication check success or failure.
The following table lists some of the System Rule alarms in the application:
S.No. | Alarm Name | Description | Status | Severity | Category | Source |
1 | Gateway Connection Status | The application generates the alarm when the gateway device gets disconnected/connected from/to the cloud. | Disconnected: When the gateway disconnects | Critical: When the gateway disconnects | System Alerts | Gateway device |
Connected: When the gateway connects. | Clear: When the gateway connects. | |||||
2 | Gateway Authentication process | The application generates the alarm when the gateway device's authentication failed while connecting to the cloud. | Authentication Failed : When the gateway authentication fails. | Critical : When the gateway authentication fails. | System Alerts | Gateway device |
Authentication Passed : When the gateway authentication passes. | Clear : When the gateway authentication passes. | |||||
3 | Available Device's Health | One or more devices available in this location are having alarms. | State: Alarming/Cleared | Severity : Highest severity of the devices in that location. | Category: Status Propagation | Location |
4 | Available Asset's Health | One or more assets available in this location are having alarms. | State Name: Alarming/Cleared | Severity : Highest severity of the assets in that location. | Category: Status Propagation | Source: Location |
5 | Children Health | One or more child assets are having alarms. | State Name: Alarming/Cleared | Severity : Highest severity of the parents' children's assets. | Status Propagation | Parent Asset |
6 | Child Location Health | One or more child locations are having alarms. | State Name: Alarming/Cleared | Severity : Highest severity of the parents' children's location. | Status Propagation | Parent Location |
Alarm Terminologies
It is necessary to understand the alarm related terminologies to further understand the alarms feature in the application. Below are some important terms used in the module.
Alarm Rule Template and Alarm Rule
Alarms are generated from Alarm Rules, and these Rules are derived from Alarm Rule Templates specific to a device, asset, or location model.
Refer to the Understanding Alarm Rule Templates & Alarm Rules document for more details.
Alarm Severities
The most important aspect to note in an alarm is its severity, which denotes the measure of criticality. Understanding the severity of an alarm is crucial for effectively addressing and resolving issues. The following are the most common and default severities in the IoT application.
- Critical
- Major
- Minor
- Warning
- Clear
As the names indicate, criticality of the severities is in the descending order with 'Critical' at the top. The 'Clear' severity does not bear any criticality. It represents normal or default behavior, indicating that the managed entity functions normally.
For example, consider the DG Monitoring application to monitor the functioning of a diesel generator. Here, you want to create an Alarm Rule named Fuel Level Monitoring to monitor the fuel level in the DG. You can configure the severity for the Alarm for this scenario as given below.
Conditions for Fuel Level | State | Severity Settings |
<10 | Almost Empty | Critical |
>= 10 <20 | Extremely Low Fuel Level | Major |
>= 25 <50 | Moderate Fuel Level | Minor |
>=50 <75 | Normal | Warning |
>=75 | High Fuel Level | Clear |
As you can see, Critical is the highest severity with an alarmingly low fuel level, and Clear is the normal severity.
The severity of an alarm is defined when configuring the Alarm States when creating Alarm Rules.
Note: Refer to the Working with Alarm Rules document for more details on States and Severity.
Alarm State
Alarms in Zoho IoT represent a specific problem. And any problem can have different conditions also referred to as severity to identify the specific context of the problem. These conditions are represented using Alarm States.
Alarms History and Alarms
All alarms generated for a managed entity are recorded under Alarms History. The latest or current alarm is considered the active Alarm. In other words, all alarms that preceded the current Alarm form the Alarms History.
Note: Refer to the Working with Alarms document for more details.
Alarm Status Propagation
Status propagation refers to the process by which the status of a fault in any asset or location in the child is carried forward to the parent in the parent-child relationship model. Here, the highest severity of any child is updated in the parent.
Note: Refer to the Understanding Status Propagation document for complete details.
Assign and Clear Alarms
Assign Alarm
Alarms can be manually assigned to users to send them notifications, prompting them to take the necessary actions. This immediate notification ensures that the user is aware of the problem and can quickly respond to mitigate any potential impact.
Clear Alarm
Typically, the system automatically clears an alarm when the fault is resolved and the same will be reflected in the application. In rare cases, when the fault has been rectified but the alarm remains uncleared, you can manually clear the alarm using the Clear Alarm option.
Source Alarms & Related Alarms
The Source Alarms provide a consolidated view of the alarms directly associated with that location. Whereas, the Related Alarms provides a consolidated view of all the alarms under the selected location and the alarms associated with the devices and assets mapped to the child locations of the selected location. These alarms can be viewed by using the respective toggle button option.
Availability
All Alarm Rules operations require necessary permissions. Refer to Users and Profiles document for more details.
Check Feature Availability and Limits
Check Feature Availability and Limits