Triggers: alarm condition handling

Triggers define conditions for alarms to be raised when monitoring IoT devices. You can define simple immediate triggers, or ones that depend on multiple assets or the past history of an asset.

Simple triggers

Assetwolf has a simple interface for setting a trigger. A typical example might be "temperature too high" or "device has not communicated for X minutes".

There are anti-noise options if you need them, such as to avoid a trigger being fired spuriously.

Procedures

When a trigger fires, something needs to happen (and somebody usually needs to be notified). So Assetwolf has the concept of Procedures which are followed.

A Procedure can have multiple-steps, so that (for example) an email is sent, an SMS sent, or even that the portal should send some data to the asset in the form of a Command.

In addition, it's usual for the alarm to be logged, so that it can be recorded in a report or other display of information about the asset.

Alarm Severity Levels

How bad is the thing that occurred?

Assetwolf has Alarm Severity Levels, so that you can always determine what state an asset is in, and thereby help users prioritise what needs to be done first.

Here's an idealised diagram of an alarm occurring:

Alarm states.png

 

In the first cycle, the condition begins and the trigger fires, and the asset's alarm severity level jumps from 0 ("OK") up to 3 (severe). The condition ends quickly (perhaps something got too warm but then cooled off), and before anyone could acknowledge it; so the severity level dropped to level 1. 

But "1" is notable above "0" as it may be important that you know it has happened. For example, if a refrigerator got too warm because of a power cut, and the food went bad, you would want to know about it, even if the power came back on and the refrigerator cooled down again.

In the second cycle, the condition occurs again, but this time it's acknowledged quickly. Somebody responds to the problem quickly, and after some time the original condition goes away, again with the severity level going down to 0 when the normal operating situation is restored.