Alarm Analytics

Use Alarm Analytics when a list of individual alarms is not enough. Compare raw alarm records or group them into an aggregated view to see recurring alarm types, affected devices, duration, and attributed energy loss.

Choose a view

• Raw View keeps one row per alarm result. Use it to inspect individual events and their context.
• Aggregated View groups results for comparison. Use it to spot recurring alarm types and alarm frequency.

The available columns can differ between views. You can show or hide optional columns when the column selector is available.

Set the analysis window

Choose a start and end date. You can also limit the time of day with minimum and maximum hour values. The default hour range is 06:00–18:00.

Select one or more plants, or keep the fleet selection when you want to compare sites. The results are limited to plants available to your account.

Filter the result

Use the analytics filters for:

• alarm type
• status
• severity
• plant
• minimum and maximum hour

Apply filters together when you want a focused question, such as “Which critical inverter alarms occurred at Plant A during operating hours?”

Interpret the columns

Raw results can include:

• device label and model
• plant name
• alarm type and category
• status
• start and end time
• duration in minutes
• energy loss in kWh, when available
• remarks explaining why loss was not computed, when supplied

AVA Fault and vendor Fault remain separate alarm types. Keep the alarm-type column visible when you need to distinguish them.

An instantaneous alarm is represented by one analysis interval so it remains visible even when its recorded start and clear times are the same. If an inconsistent source timestamp places the clear time before the start time, the displayed duration is clamped to zero rather than shown as a negative value.

Aggregated results can include the same context plus Alarm Freq, which shows the number of alarms in the group. Date, device, plant, alarm type, duration, and status determine how useful a comparison is—keep those dimensions in view when reading a high frequency value.

Energy loss is an attributed analytics estimate, not a direct meter reading or a replacement for the alarm’s status or duration. SolarSENS calculates it only for eligible inverter events during operating hours where the required 5-minute intervals have sufficient data. Device Offline and Grid Power Outage typically do not receive a computed estimate.

How energy loss is estimated

Energy loss is calculated for each 5-minute interval that overlaps an alarm window:

1. Expected power is estimated from irradiance and plant-specific performance models.
2. Actual power is 0 for outage-type alarms (grid outages, frequency events), or the recorded Active Power telemetry for derating-type alarms.
3. Loss per 5-minute interval: max(0, expected - actual) × (5 ÷ 60) kWh.
4. Total alarm loss: sum of all 5-minute interval losses across the alarm’s duration.

A loss value is not computed when any of the following conditions are met:

Condition	Remarks value	Impact
No soiling model exists for the plant’s date range	soiling model	Loss set to 0
No irradiance telemetry for the time window	irradiance	Loss set to 0. Common for night-time alarms.
Alarm type is Device Offline	device offline	Loss set to 0
No Active Power telemetry (and not Device Offline)	active power	Loss set to 0

When any 5-minute interval within an alarm has a reason code, the entire alarm’s energy loss is set to 0.

Worked examples

Example 1: Grid Power Outage (daytime, data available)

An SG125CX-P2 inverter (125 kW rated) experiences a 30-minute grid power outage from 10:00 to 10:30. Based on irradiance and plant performance data, estimated expected power for this period is 707.7 kW per interval.

Per 5-minute interval:

• Expected power: 707.7 kW
• Actual power: 0 kW (outage-type alarm)
• Loss: 707.7 kW × (5 ÷ 60) = 58.98 kWh

Total alarm loss: 6 intervals × 58.98 = 353.85 kWh

Example 2: Inverter Derating (partial production)

The same inverter derates to 400 kW during high irradiance for 15 minutes. Expected power for this period is 761.8 kW per interval.

Per 5-minute interval:

• Expected power: 761.8 kW
• Actual power: 400 kW (recorded Active Power telemetry)
• Loss: 361.8 kW × (5 ÷ 60) = 30.15 kWh

Total alarm loss: 3 intervals × 30.15 = 90.45 kWh

Example 3: Grid Power Outage (night-time, no irradiance)

The same 30-minute outage from the screenshot (17:50–19:05, after sunset). Irradiance is null.

Per-interval check: Irradiance is null → reason set to irradiance. Total alarm loss set to 0. The alarm still appears with Duration = 75 min and Energy Loss = 0, with Remarks showing irradiance.

Always read Energy Loss together with Remarks:

Energy Loss shown	Remarks	Safe interpretation
Positive value	Blank or supporting context	Eligible intervals produced a positive attributed estimate. This does not establish root cause by itself.
0	A reason is present (e.g. soiling model, irradiance)	Do not read the value as confirmed zero impact. Use the reason to understand why attribution was limited or unavailable.
0	- or blank	The current presentation is ambiguous. Common for non-inverter alarms or events outside operating hours.
Blank or unavailable, where preserved	A reason may be present	No attributed value is available in that representation.

Views and exports may not preserve every source state in the same way. Never replace a missing value with your own estimate.

Investigate attributed impact

1. Filter to the plant, alarm type, and period.
2. Inspect the alarm status, duration, and device context.
3. Read Energy Loss and Remarks together.
4. If a zero or blank is ambiguous, check plant and device data coverage for the same period.
5. Compare device health and string performance where relevant.
6. Open String Analytics when the affected equipment and plant support string-level analysis.
7. Return to Alarm Triage for alarm-state actions.

Use analytics with triage

1. Start with a date range and plant selection.
2. Filter by severity, status, or alarm type.
3. Use Aggregated View to identify repeated patterns.
4. Switch to Raw View to inspect the individual alarms behind a pattern.
5. Return to Alarm Triage to acknowledge or clear the alarms that need action.

Analytics are processed results. They are useful for comparison and investigation, but the current alarm list remains the place to take alarm-state actions. For the boundary between source alarms, processed analytics, and work orders, see Device health, alarms, and string performance.