Events

Events are the machine-detected signals your plants raise on their own — a grid shutdown, an overproduction cap, a logger losing contact with its source. They give you an objective, time-stamped record of what happened, so you can react quickly and prove later what the platform observed and when.

Events Concept

An event is automatically created when the platform recognizes a noteworthy condition at a plant. Most events come from the Digital Twin and the monitoring agents watching each plant; others are emitted as a side effect of configuration changes (for example, when a data logger is added or paused). You can also record an event yourself for something you observed on site.

Events are deliberately lightweight: each one captures what the platform detected, where, when, and how serious it is. The human side of the story — triage notes, who is working on it, what was done to fix it — lives in Tickets, not on the event itself.

Event Types

Each event carries a type that tells you what was detected. The types fall into a few families:

Production and grid

• Grid Shutdown: production was curtailed or stopped by the electrical grid operator.
• External Shutdown: production was stopped by an external instruction (for example, a direct marketer or remote curtailment).
• Overproduction: the plant exceeded its expected or permitted production level.

Component health — raised by the plant's Component Health Watchdog. Each type is named for the component it sits on, so an inverter, a combiner box and a string carry their own version of the same finding. For inverters, Inverter Events explains every one of these in detail — what opens it, what confirms it, and how it closes.

Production — exactly one of these stands on a component at a time:

• Inverter production outage: confirmed zero production under conditions that warrant production.
• Inverter measurement conflict: the inverter is producing, but its own reading is wrong — a data fault to investigate, never counted as lost production.
• Inverter not communicating: the inverter stopped reporting — its production is unknown, deliberately not counted as loss.
• Inverter reduced output: the inverter is producing, but far below its modelled expectation.

And one park-level roll-up, which stands on top of the component events rather than instead of them:

• Component outage summary: the single high-priority park summary that lists all currently-down inverters and combiner boxes — this roll-up carries the operator alarm.

Service findings — an inverter that is producing at full output while something wears out. Each opens as an Observing: … row first and becomes a confirmed finding once the evidence holds:

• Inverter elevated temperature: it runs measurably hotter than comparable units on the same logger under the same load.
• Inverter insulation weakening: its settled morning insulation reading keeps falling below its peers'.
• Inverter phase imbalance: the three AC phases no longer carry the same current.
• Inverter efficiency declining: the DC-to-AC conversion loss grows month over month beyond what load and temperature explain.

Device state — what the machine says about its own condition, one event per mode:

• Inverter device fault: the inverter reports a fault of its own, in a function the platform has no measurement for — hardware, firmware, licence, configuration, an emergency stop, a DC string or metering. A service item, not a production loss.
• Logger cannot reach inverter: the logger says it cannot reach the machine while no readings of ours arrive from it either. A quiet background record — it notifies nobody and puts no state on the inverter; after an hour of daylight it is handed over into a no-communication event.
• Inverter safety alarm: an arc fault or a residual-current condition the device reports — opened on a single live report, day or night.
• Inverter protective stop: a protection mechanism tripped the machine; it may need a manual restart on site.
• Inverter stopped by command: it was switched off deliberately, by a person or a remote instruction.
• Inverter self-derating: it is producing but throttling itself to protect itself, most often against heat.
• Battery device fault: the same record for a battery converter or container BMS — a battery's communication reports stay here, it has no separate reachability record.

Device-reported mirror — the manufacturer's own active alarm list, copied as it was sent and never judged:

• Inverter fault reported by device / Inverter warning reported by device (and the two battery equivalents): one record per code, opened when the device raises it and closed when the device withdraws it.

Sensor health — a staged chain, so a healthy sensor is never condemned on weak evidence:

• Sensor Investigation: an irradiance channel stopped delivering usable signal — under observation.
• Sensor Defect: the fault is corroborated by independent evidence — replace the sensor.
• Sensor Soiling: the sensor dome is dirty or snow-covered — clean it; escalates to a defect if it does not recover.

String investigations — the same staged approach for strings:

• String Investigation: a string shows unexplained zeros under conditions that warrant production — under observation.
• String Outage / String Defect: the investigation was confirmed — a dead string, or one producing far below its siblings without recovering.
• String Shading: the string's zeros recur along the sun's path — recorded quietly as shading, not a defect.

Connection and availability — one alarm at the layer where the root cause sits:

• VPN Offline: the monitoring tunnel to the plant is down.
• Park Network Offline: the plant's local network is unreachable.
• Network Device Offline: a single monitored network device stopped answering.
• Network Device Mass Outage: a large share of the plant's devices went offline together.

Curtailment and settlement — see Curtailment Settlement for the full explanation:

• Detected Curtailment: the live record of each curtailment episode, with its real start, end and limit.
• Settlement Records: the bookkeeping behind compensation — a settlement event per curtailment measure with the legal method and figures, a monthly value per plant, and revision events for later official price corrections.

Energy integrity

• Energy Counter Stalled: a device's lifetime energy register stopped advancing while it keeps producing — its own record of production needs repair.
• Feed-in Energy Estimated: part of the plant's feed-in series is temporarily estimated from power readings.

Data acquisition and configuration

• Source Availability: a data source became unreachable or recovered (data acquisition gap).
• Logger Lifecycle: a data logger was created, updated, paused, resumed, deleted, or had its credentials changed.
• User Created: an event you recorded manually for an observed condition.

Event Priority

Every event carries a priority level so you can focus on what matters first:

Event Status

Events move through a short, clear lifecycle:

• Detected: the event has just been raised and not yet reviewed.
• Acknowledged: someone has seen the event and accepted it for follow-up.
• Closed: the underlying condition is resolved. Many events close automatically — for example when a curtailed source reconnects, a shutdown ends, or overproduction subsides — while others are closed manually once the work is done.

Closed events can be reopened if the condition returns, so a recurring problem keeps its history together.

Linking and Follow-Up

Events do not stand alone. You can connect each event to the parts of the plant it concerns and to the work needed to resolve it:

• Component Links: attach an event to the specific components it affects (a logger, inverter, GAK, string, feed-in meter, or sensor), and search the plant's components to find the right one.
• Ticket Links: reference an event from a ticket so investigation, assignment, comments, and resolution are tracked in one place.
• Notification Tracking: each event records which users were notified and who has seen it.

Shutdown Tracking

Grid and external shutdown events are also collected into a dedicated production-loss view. Filtered by plant and portfolio, it lets you see how often production was interrupted and attribute the lost energy — a direct input to performance reviews and reporting. See Loss Detection for how interrupted production is quantified.

Finding and Reviewing Events

Events are retained as a long-term history so you can both react in the moment and analyze trends later:

• List and Filter: browse events across the plants you can access, filtered by plant, portfolio, type, status, or priority, and sorted to surface the newest or most urgent first.
• Counts: at-a-glance counters summarize how many events are open and how they break down, feeding the KPI Dashboard.
• Detail View: open any event to see its full context, linked components, linked tickets, and notification history.
• Historical Record: closed events stay available for audits, warranty claims, and identifying recurring patterns over time.

Access and Permissions

Events are a plant sub-resource, so access follows your role on the parent plant — not a separate setting. Anyone who can view a plant can see its events. Beyond that:

• Technical roles — Operators and Technical Managers get full event handling: acknowledge, create, close, and delete.
• Asset Manager (Commercial) can create and acknowledge events for commercial oversight, but cannot delete them.
• Viewers have read-only access.

Cooperators who hold the required job role on a shared plant are included on the same terms. See the Permission System for the full role model.

Related Features

• Tickets — the human follow-up workspace where events are triaged and resolved
• Inverter Events — every component-health event an inverter can carry, in detail
• Digital Twin — the analysis engine that detects most events
• Loss Detection — quantifies the production lost during shutdowns
• KPI Dashboard — surfaces event counts alongside performance metrics
• Reports — incorporates event and shutdown-loss data into periodic documentation