Introduction
Monitoring handles a wide variety of events created by the smart device or external devices and services, ranging from a single temperature reading to more advanced information such as state changes and critical alarms.
Monitoring events can be stored locally on the smart device and pushed to the Cloud. The information from the events stored on the cloud can be aggregated into reports and graphs. Monitoring events can be used in the Composer Wait for Monitoring-block to act upon events as they happen.
Alarms
A monitoring event can include an alarm. Alarm can be one-time or persisting with every monitoring event until cancelled.
Sometimes a significant amount of "positive" values need to be registered before an alarm can be cancelled. For example, when monitoring the humidity of the soil of a flower pot, the decision whether the plant needs water or not is the result of a long-term evaluation of sensor readings, not based on a singular event.
Severity levels
To distinguish severity in alarms, every alarm includes a severity level payload.
The severity levels are based on RFC5424, which defines severity levels for the syslog protocol.
| Code | Severity | Description |
|---|---|---|
0 |
Emergency |
system is unusable |
1 |
Alert |
action must be taken immediately |
2 |
Critical |
critical conditions |
3 |
Error |
error conditions |
4 |
Warning |
warning conditions |
5 |
Notice |
normal but significant condition |
6 |
Informational |
informational messages |
7 |
Debug |
debug-level messages |
A normal alarm can be 4, anything smaller than or equal to 4 is an alarm. Level 0 should only be used in severe, perhaps life-threatening situations