Skip to main content

Reporting Events

Report Energy Management System (EMS) control actions that alter your resource's default behaviour to improve forecast accuracy.

What are Events?​

Events are EMS control actions or data-quality issues that mean a resource's metered data no longer reflects its normal behaviour. For example:

  • Solar panels curtailed due to negative day-ahead prices
  • A window of corrupted meter data (e.g. an inverter outage or stuck readings)
Important

Do not report deviations caused by Powernaut activations. Only report events initiated by your local optimisations.

Why Report Events?​

Our forecasting models predict normal resource behaviour without interventions. To provide accurate forecasts, we need to know when these interventions occur so we can:

  • Train models on clean data (excluding intervention periods)
  • Account for planned changes in our predictions
  • Improve forecast accuracy over time

How to Report Events​

API Endpoint​

POST /v1/connect/resources/{id}/events

Request Format​

Each event report includes:

  • event_type: The type of control action
  • payload: Event-specific data (timing, parameters, etc.)

Example Request​

{
  "event_type": "PV_CURTAILMENT_SCHEDULED",
  "payload": {
    "start": "2025-09-19T08:00:00Z",
    "end": "2025-09-19T17:00:00Z"
  }
}

Supported Event Types​

Photovoltaic Curtailment​

Event Type: PV_CURTAILMENT_SCHEDULED

Report when photovoltaic generation is curtailed for a specific time period (e.g., due to negative day-ahead prices).

Payload:

  • start: ISO 8601 timestamp when curtailment begins
  • end: ISO 8601 timestamp when curtailment ends

A single window must not exceed 31 days — split longer periods into multiple events.

When to Report: Report before the curtailment occurs so we can account for it in forecasts.

Example:

{
  "event_type": "PV_CURTAILMENT_SCHEDULED",
  "payload": {
    "start": "2025-09-19T08:00:00Z",
    "end": "2025-09-19T17:00:00Z"
  }
}
Best Practice

Report events as soon as you know they will occur. This gives us the most time to adjust their predictions accordingly.

Corrupted Data​

Event Type: CORRUPTED_DATA

Report a window during which a resource reported corrupted meter data — for example an inverter outage, or stuck or otherwise implausible readings. Every quarter-hour in the window is excluded from the metering we aggregate to pool level, from target tracking error calculations, and from the data used to train your forecasts, so a temporary fault does not skew your results or degrade future forecasts.

Payload:

  • start: ISO 8601 timestamp when the corrupted-data window begins. Should be a perfect quarter-hour.
  • end: ISO 8601 timestamp when the corrupted-data window ends. Should be a perfect quarter-hour.
  • reason (optional): free-text description of the problem

Like curtailment and mFRR events, start and end must fall on quarter-hour boundaries. The event can be reported for any resource type, and every quarter-hour the window spans is excluded. A single window must not exceed 31 days — split longer periods into multiple events.

When to Report: Report once the affected window is known (typically after detecting the fault).

Example:

{
  "event_type": "CORRUPTED_DATA",
  "payload": {
    "start": "2025-09-19T00:00:00Z",
    "end": "2025-09-20T00:00:00Z",
    "reason": "Inverter offline, meter reported zero output all day."
  }
}
Last updated on