ALARMS
Alarms are mechanisms that allow users to receive real-time notifications about specific events or conditions related to their IoT devices. These alarms are essential for proactive management.
Last updated
Alarms are mechanisms that allow users to receive real-time notifications about specific events or conditions related to their IoT devices. These alarms are essential for proactive management.
Last updated
Alarms in Thinger.io serve several important purposes:
Real-Time Monitoring: They allow users to monitor their devices in real-time and receive immediate notifications about critical events, such as device failures or abnormal conditions.
Predictive Maintenance: They help anticipate problems before they occur, which is essential for predictive maintenance. For example, receiving an alarm when a motor's temperature exceeds a specific threshold can prevent major failures.
Security and Control: They enhance security by alerting users about unauthorized access or suspicious activities. Alarms can also be used for control, activating other devices or services in response to an event.
Operational Optimization: They facilitate operational optimization by providing information on device performance, allowing for continuous adjustments and improvements in processes.
Customized Notifications: Users can define custom alarms according to their specific needs, ensuring that relevant information is delivered to the right people at the right time.
To access the alarm functionality, click on the "Alarms" tab in the main menu. This will take you to the alarms terminal, where you can view all currently active alarm events. This interface provides useful information related to each alarm, including the time the alarm was triggered, the severity, and the current status of the alarm. You can also see details about the affected device and any relevant data points that caused the alarm to be triggered.
IMAGEN
This comprehensive overview allows you to monitor the status of your devices in real-time and respond promptly to any issues. But if more detail is required, there is also an "Alarms Inspector" accessible using the top-right corner menu, which allows to review of the raw data of the server events that are being produced by each alarm rule.
Alarms are generated by the server when the criteria specified in a rule are met. Users can define these alarms by accessing the "Rules" section of the alarm console. In this section, you will find a list of existing rules, which allows for their management, as well as the option to create new rules by clicking the "+ Add Rule" button, which will display the following context:
Rule Identifier: A unique identifier without spaces and special characters must be used
Name: Mnemonic identification for users
Description: Additional information to help recognize the rule in the long term
Enabled: Allows to enable or disable the execution of the rule
Severity: This is used to categorize and prioritize alarm based on their importance or impact. It helps users manage and respond to different types of events more effectively.
Check interval: Is used to define how frequently the system evaluates the conditions set in a rule to determine if an alarm should be triggered. It allows users to adjust the check interval based on the specific needs of their monitoring setup.
Note that setting an appropriate check interval helps balance the frequency of evaluations with system resource usage. In scenarios requiring high responsiveness, a shorter interval may be chosen, while less critical scenarios may use a longer interval. If the interval is too long, critical issues might not be detected promptly, while a very short interval may lead to excessive checks and potential performance impacts.
Este submenú permite especificar el comportamiento de la regla, especificando qué variables se van a monitorizar, cual es el valor de consigna y qué resultado tendrá cuando se produzcan evaluaciones positivas de la condición. También se especifica el comportamiento de desactivación de la regla
This section allows users to specify which data sources will be evaluated by the rule. Data sources may include data from buckets, device properties, or the device status (allowing also to monitor device disconnections).
Name: Use a unique identifier avoiding spaces or special characters. This name will be used to identify the JSON which contains the data point.
Data source: This may be a Devie Property, a Data Bucket, or the Device Status. Note that depending on the data source type, the menu may expose filtering options that allows to work with multiple devices with the same behavior, so just one rule can be used to monitor multiple devices.
When working with device data, it is recommended to use a product data bucket instead of individual data buckets. This way just one rule will monitor every product devices.
In the "Data Sources" section of the rule configuration menu in Thinger.io, the "+ Add Source" button allows users to add variables to a specific rule. This feature is essential for configuring the rule with the necessary data for evaluation.
The alarm activation refers to the process in which the system monitors the variables specified in the "Sources" section and generates notifications when these conditions are met. This means the system continuously checks the data against the defined criteria to detect any deviations or specific events but note that it is possible to define confirmation criteria that prevent false activations.
The alarm activation section in Thinger.io consists of a form with three main sections: Conditions, Confirmation, and Notification. Each of these sections plays a crucial role in defining how and when alarm are triggered and how notifications are managed.
In this example, we are using the variable "temperature" which comes from a datapoint that contains multiple variables:
Data1
{"temperature":20,
"humidity":50,
"pressure":850
}
The desired variable can be selected through the following structure in the input text: "Data1.temperature"
Conditions: allows users to define one or more comparisons of a selected variable and a setpoint. These conditions specify the exact criteria that must be met for the alarm to be activated. By setting these conditions, users can precisely monitor the desired metrics and ensure alarm are only triggered when specific thresholds or ranges are met. The comparisons can be:
Greater than
Less than
Equal to
Not equal to
Within a range
Outside of a range
Note that it is possible to create more complex behaviors by adding additional conditions to the rule
Confirmation: This section section helps to avoid false activations of alarm. it is an essential step for filtering out transient or spurious events that do not require immediate attention, thus ensuring that alarm are only generated for sustained or repeated conditions. This can be configured in several ways:
Immediate Confirmation: The alarm is triggered as soon as the condition is met.
Sequence: The alarm is activated if the condition is met multiple times
Timespan: The alarm is only triggered if the condition remains true for a specified amount of consecutive valid comparisons.
Notification: This section allows users to define the endpoint profile (previously defined) that will be used to send the notification if the alarm alarm is necessary. By configuring the notification settings, users can ensure that the right people are informed promptly about critical conditions, facilitating a quick and appropriate response.
The normalization section of the rules configuration allows users to define the platform's behavior for deactivating an alarm when the necessary conditions for it to be cleared are met in the device's data. This configuration uses the same elements as in the activation section but with the focus on setting values that ensure a reliable deactivation of the alarm.
The Reminder section of the alarm configuration is designed to provide ongoing notifications at regular intervals when an alarm remains active. This feature ensures that critical alarms are not overlooked or forgotten over time. It is possible to select two elements:
Interval: Users can specify the time interval at which the reminders should be sent. This can be configured to match the urgency of the alarm, with shorter intervals for more critical issues and longer intervals for less urgent ones.
Notification: Users can define the endpoint profile for the reminder notifications. This includes the communication method (e.g., email, SMS, push notifications) and the details for delivering these reminders.
The alarm list Thinger.io is a comprehensive interface that displays all the active alarms generated by the system when the specified conditions are met. It provides a detailed overview of all current alarms that have been triggered. This list helps users to track and manage ongoing issues across their IoT devices and systems.
Key Data Displayed in the Alarms List
Alarm ID: Each alarm is assigned a unique ID for easy reference and tracking.
Origin: It's the source of the alarm, it indicates the device or data source that triggered the alarm. This helps identify the exact point of origin of the alarm.
Severity: Displays the severity of the alarm, as it was defined in the rule configuration. This feature is aimed to help to prioritize response actions. Severity levels might include Critical, High, Medium, Low and None.
State: The status of the Alarm, it shows the current state of the alarm, which can be:
Activated: The alarm is currently active and has not been resolved.
Latch: The alarm has been acknowledged but remains active.
Shelve: The alarm has been temporarily suppressed or postponed.
Values: Displays the trigger Variable, the specific variable that triggered the alarm along with its current value, Helping to understanding the cause of the alarm.
Visualized Time
Timestamp: Indicates the moment when the user first viewed the alarm. This helps in tracking how long the alarm has been known to the team.
Elapsed Time
Duration: Shows the time elapsed since the alarm was activated. This information is critical for measuring response times and understanding the persistence of issues.
The alarm list also includes several control functions that appear when one or more alarm instances are selected. These controls allow users to manage the alarms effectively.
Alarm management in the alarm List is a critical function that allows users to maintain control over active alarms, ensuring that they are addressed appropriately and efficiently. Here’s how each control contributes to effective alarm management:
Acknowledge: When users acknowledge an alarm, it signifies that the alarm has been noticed and is being addressed. This step is essential in a team environment to prevent multiple people from working on the same issue unknowingly.
Shelve: Shelving an alarm allows users to temporarily suppress it, reducing noise and distraction from alarms that are known but not immediately actionable. This helps in focusing on more urgent alarms while ensuring that less critical ones are revisited later.
Latch: Latching an alarm ensures that it stays active until a manual action is taken to clear it. This is particularly useful for severe issues that require explicit confirmation that they have been resolved, ensuring accountability and thoroughness in alarm management.
Clear: Clearing an alarm is the final step once the issue has been resolved. This keeps the alarm List up to date and focused only on current, unresolved issues, helping users to quickly identify and respond to ongoing problems.
Set Projects: Assigning alarms to projects helps in organizing and managing them within specific contexts. This is particularly useful in larger deployments where alarms may pertain to different devices, locations, or operational areas.
Remove: Removing alarms from the system is necessary for cleaning up outdated or irrelevant alarms. This ensures that the Alarm List remains relevant and uncluttered, making it easier to manage current alarms.
The Alarms Inspector in Thinger.io is a tool designed to provide detailed insights into the behavior of the alarms. It helps users track and analyze the behavior of the alert system by showing the event history of alarms. It helps users understand the lifecycle and behavior of each alarm by providing a detailed timeline of events.
Filtering Options
The Alarms Inspector offers several filtering options that allow users to focus on specific types of alarm events. These filters include:
alarm_instance_activate
Filter Events: Shows events where an alarm instance is activated.
alarm_instance_create
Filter Events: Displays events where a new alarm instance is created.
alarm_instance_delete
Filter Events: Shows events where an alarm instance is deleted.
alarm_instance_normalize
Filter Events: Displays events where an alarm instance is normalized, indicating that the condition triggering the alarm is back to normal.
alarm_instance_update
Filter Events: Shows events where an alarm instance is updated with new information or conditions.
alarm_rule_create
Filter Events: Displays events where a new alarm rule is created.
alarm_rule_delete
Filter Events: Shows events where an alarm rule is deleted.
alarm_rule_execute
Filter Events: Displays events where an alarm rule is executed, showing the process of checking conditions and triggering alarms.
alarm_rule_update
Filter Events: Shows events where an alarm rule is updated with new parameters or conditions.
