--- title: "Concepts" canonical: "https://help.scopious.co.nz/space/KB/175702018/Concepts" format: markdown --- > Macro (excerpt) > > An [Alarm](https://scopious.atlassian.net/wiki/spaces/KB/pages/85917701/Glossary+of+Terms#Alarm) can be a challenging feature to understand and configure so this section is here to help you better understand concepts and terms you will find throughout our documentation and application. Alarms can be as simple or complex as you like, but their main purpose is to provide you with a quick and easy way to identify and be notified of any problems with ‘things’ you are monitoring or to trigger command and webhook actions. > Macro (toc) ## Alarm Rules An [Alarm](https://scopious.atlassian.net/wiki/spaces/KB/pages/85917701/Glossary+of+Terms#Alarm) is made up of one or more [Alarm Rules](https://scopious.atlassian.net/wiki/spaces/KB/pages/85917701/Glossary+of+Terms#Alarm-Rule). An Alarm Rule consists of: - Logical conditions that determine whether the rule is met or not. - The alarm level to set when the rule conditions are met. - A list of users to notify when the rule conditions are met - A list of actions to take when the rule conditions are met. ## Alarm Level The alarm level is used to provide a quick and easy way to view the overall status of the ‘thing’ being measured. - Alarm levels consist of `OK`, `INFO`, `WARNING`, and `CRITICAL`. - An alarm can be configured to switch between levels by defining multiple alarm rules, with each rule defining a different level. - An **Otherwise** rule defines the default alarm level if none of the conditions in all the rules are met. - The Alarm will show the highest currently triggered level in the Control Centre. ## Rule Conditions Rule conditions are the heart of alarms and define the logic used to switch between alarm levels. - An alarm rule is made up of one or more conditions. - A condition is where received device data is compared against a configured value. - When all conditions within a rule are met, the rule is ‘triggered’. - When a rule is triggered, 3 things happen: - The alarm level is set to the level configured for the rule, and - Users are notified the rule conditions have been met, and - Any configured actions are processed. - Multiple conditions can be combined together using `AND` and `OR` logic to form a single logical condition. This can be used to create very powerful rules. ## Transition Effects Transition effects are Hysteresis (value-based) or Delay (time-based) dampening used to avoid rapid alarm state changes caused by fluctuations around the condition level. ### Hysteresis You can apply hysteresis rules to conditions to help mitigate the issue of rapid switching between alarm states when an input value fluctuates around the condition level. The Hysteresis transition effect can only be applied on conditions that check for non-equivalency (e.g. `Greater Than`, `Less Than`, etc). You can specify a variation to the threshold level so once the alarm triggers, it will not trigger again until the reported value has changed more than the variation you configured. - Example: A condition is configured to trigger when the temperature is greater than 15.0°C and configured with a variation of 2°C. The temperature rises to 15.1°C, the alarm triggers and changes state. The alarm will remain in that state until the temperature drops below 13.0°C. ### Delay You can apply delay rules to conditions to help mitigate the issue of rapid switching between alarm states when an input value changes quickly. The Delay transition effect can be applied to all types of conditions. You can specify a `Trigger after` time period that defines how long the condition must remain true before triggering the rule, and a `Recover after` time period that defines how long the condition must remain false before the rule exits its triggered state. - Example: A condition is configured to trigger when a GPIO input level is high. The `Trigger after` period is configured with an interval of 10 seconds and the `Recover after` period is configured with an interval of 10 seconds. The GPIO line changes from low to high. The alarm does not immediately trigger or change state. 10 seconds later the GPIO line is still high, and so then the alarm triggers and changes state. The GPIO line changes from high to low. 10 seconds later the GPIO line is still low, so the alarm recovers and exits its triggered state. ## Alarm Actions ### Command Actions Command Actions can be added to any rule. When that rule is triggered, it will queue each of the listed device downlink commands. - If you queue multiple commands for a single device, they will execute in the order specified. For each command you can use the advance configuration options to configure what happens when a command fails to execute. Refer to the [Commands](https://scopious.atlassian.net/wiki/spaces/KB/pages/399605774) section for more information. - Commands queued to separate devices will execute in parallel and will always be triggered regardless of any failures. ### Webhook Actions Webhooks allow for advanced functionality when an Alarm rule triggers. - Webhooks are configured with an http/https URL, a list of headers, and a body defined by text. You can change the type of the body by supplying a '`Content-Type`' header. - Headers can be marked as secret so that they are stored as encrypted values. - When a rule is triggered, all webhooks for that rule will be sent in parallel. - Webhooks are POST requests.