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.

Events vs. Tickets

An event is a detected signal (often automatic). A ticket is the human follow-up: investigation, assignment, comments, and resolution. You link the two together so the detected signal and the work to resolve it stay connected. Free-text title and description fields on events are being retired in favour of tickets — treat the event as the trigger and the ticket as the workspace.

Event Types

Each event carries a type that tells you what was detected:

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.
Source Availability: a data source became unreachable or recovered (data acquisition gap).
Radiation Sensor Defect: an irradiation sensor reported implausible or missing readings.
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:

Priority	Use it for
Very High	Severe conditions that need immediate attention
High	Significant problems to address promptly
Normal	The default level for routine detections
Low	Minor conditions worth monitoring
Very Low	Background occurrences that rarely need action

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.

Use tickets for the work

When an event needs investigation or a fix, open a ticket and link the event to it. The ticket carries the assignee, comments, mentions, and a full activity history; the event stays as the objective record of what was detected.

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.

Tickets — the human follow-up workspace where events are triaged and resolved
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