Configure alarm logic and understand how it differs from notification workflows.
An alarm represents an undesirable measured state. It can be shown in portfolio tables, device pages, alarm dashboards, and reports. Notification behaviour is configured separately through an alarm instance or watchdog.
Configured environments can evaluate conditions such as:
| Input | Purpose |
|---|---|
| Signals | Defines which telemetry series supplies the condition. |
| Node types | Limits the logic to applicable device categories. |
| Tags or source characteristics | Applies different behaviour to subgroups or data-delivery methods. |
| Lookback period | Defines the historical window used for evaluation. |
| Active time window | Avoids evaluating an expected inactive period, such as solar production at night. |
| Threshold | Defines the boundary between expected and undesirable behaviour. |
A rule combines supervised signals and node types with a lookback period and optional filters.
When several rules can match the same asset, place the most specific rule before the general fallback. For example, a daily FTP source can require a longer no-data period than a continuously connected controller.
Separate missing data from zero production
No data means the signal did not arrive. Zero production means data arrived and its value or counter change was insufficient. They require different diagnosis and should not share the same alarm meaning.