Use default alarms as a conservative starting point and tune them to each data source.
Default alarms are intended to catch meaningful problems without overwhelming operators. Exact defaults are configuration data and can evolve independently of the Insights user-interface code, so always review the values shown in your active portal.
| Category | Typical signals or calculations | Important context |
|---|---|---|
| No production data | Active production power | Solar operating window and source delivery interval. |
| No storage data | Storage power or state of charge | Whether the battery is expected to communicate continuously. |
| No charger data | Charger or socket power | Chargers can remain unused while still communicating normally. |
| No grid data | Grid power or meter measurements | Meter polling interval and gateway health. |
| Zero energy change | Cumulative import, export, production, charge, or discharge counters | A stable counter is different from a missing signal. |
| Low performance ratio | Production relative to irradiation and installed capacity | Irradiation quality, weather delay, curtailment, and maintenance. |
| Low uptime | Valid operating time relative to expected time | Site schedule and measurement completeness. |
The alarm library makes the distinction between no-data, low-delta, performance-ratio, and uptime checks visible before you edit a rule.
Do not copy thresholds blindly
Validate each threshold against a known healthy period and a known incident. An alarm that is always active or never active is not operational supervision.
Review the alarm set after the first week and first full reporting period. Track nuisance alarms, missed events, delivery delays, and site-specific operating windows, then adjust the most specific matching rule rather than weakening the global fallback.