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

• A curtailment by the grid operator or the direct marketer is recorded as Detected Curtailment (see Curtailment and settlement below).
• 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 every currently-down unit — inverters, combiner boxes, wind turbines and battery units alike, so a hybrid site still has one summary — 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.

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 battery, wind-turbine, solar-tracker and park-controller equivalents): one record per code, opened when the device raises it and closed when the device withdraws it. They are detail behind the judged events — they never notify on their own. They are filed under the Vendor alarms category in the event list, whatever the plant type.

Wind turbines — judged from each turbine's 10-minute data; see Alarm Levels — Wind turbines:

• Turbine stopped by fault: the turbine reports a fault or protection stop. Joins the component outage summary after two consecutive rows.
• Turbine not communicating: the turbine's data stopped while the other turbines of the site still deliver.
• Turbine safety alarm: fire, smoke or an arc in the converter or switchgear — Critical, notified at once.

A remote pause, bat, shadow-flicker, ice or noise curtailment, a stop ordered by the marketer or the grid operator, a keyboard pause or a service stop is status, not an event.

Battery storage — judged per power converter (PCS) and battery container on every site with battery hardware, including solar plants with storage; see Alarm Levels — Battery storage:

• Battery unit stopped by fault: the unit's status word reports a fault for five minutes. Joins the component outage summary after 15 minutes.
• Battery unit not communicating: one unit's data stopped while its data source keeps delivering.
• Battery device fault: the unit reports a fault of its own but keeps operating — a service item, not a stop.
• Battery safety alarm: a fire alarm, smoke or gas detection, thermal runaway, a released fire suppression or an arc — Critical, notified at once.

Battery events carry the same categories in the event list as those of the other plant types — faults, stops and safety alarms Production, a unit that stops communicating Availability, the battery's own device-reported alarms Vendor alarms — and notify through the Production row of your notification settings. Earlier records may still show the Battery category.

Solar trackers and park controllers — a tracker row judged from the record its field refreshes about every five minutes, and the optional park controller of a tracker field or a battery plant judged from its one-minute reads; see Alarm Levels — Solar trackers and park controllers:

• Tracker stopped by fault: the row's error word stays set for two refreshes, about 10 minutes.
• Tracker not communicating: no record for three refreshes while the field keeps refreshing.
• Tracker misaligned (Low): at least 10° off its setpoint for about 15 minutes while it is tracking and the field controller holds no stow, override or cleaning.
• Tracker safety alarm: a danger class reported by the row — Critical, notified at once.
• Park controller fault: the controller reports the plant in fault for two consecutive reads — Critical, notified on its own.
• Park controller not communicating: no reading for 15 minutes.
• Park controller safety alarm: a fire alarm, smoke or gas detection or a released fire suppression on the plant level — Critical, notified at once.
• Park controller stopped by command (Low): standby, night mode, a stow, an override or a cleaning run — recorded as the explanation, never notified.

Trackers never join the component outage summary. Changes to a plant's trackers and park controllers — discovered or edited — are recorded under the Components category.

Alarm system — the plant's alarm signals: signals your organisation defined with the generic Modbus reader, and the fixed contacts of existing WAGO installations (the intrusion alarm panel and the communication cabinet); see Alarm System:

• Alarm raised (Critical), Alarm panel fault, UPS alarm and Main switch off (High), UPS on battery and Heating breaker tripped (Normal): each opens while its contact is asserted and closes when it returns to normal. An open gate or door is recorded as a signal only.
• Operator-defined signal (level set per signal): a contact, a status bit or a measured value against a limit, defined on a Modbus device. It opens while its condition holds and closes when it returns to normal; a signal without a condition is recorded only.
• Alarm signals not readable (High): the device a reader polls stopped answering — the signals are then unknown, not normal.

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. They appear under the Curtailment analysis category in the event list.

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 one of six levels — Critical, Very High, High, Normal, Low and Very Low. The level is set by the platform per event type and is the same on every plant — with one exception, operator-defined alarm signals, whose level the plant's technical operator sets per signal: Critical means possible physical danger, High a site situation that costs production or leaves you blind, Normal a single unit's state. Which events open at which level, how fast they are detected and which of them can notify you is listed in Alarm Levels; you choose the minimum level per category on your notification settings.

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.

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
• Alarm Levels — every event that can notify, its level, timing and examples
• 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