MiroxMirox
  • Platform

    • Philosophy
    • Platform Overview
    • Platform Resources
  • Mirox-Cloud

    • Cloud Overview
    • Connected Microservices
  • Mirox-Agent

    • Agent Overview
    • Deployment Options
    • Data Scraper
    • Digital Twin
  • Technical Details

    • Metric Collection
  • Information

    • Supported Plants
  • Plant Types

    • Solar Plants
    • Wind Plants
    • Battery Storage
  • Monitoring & Visualization

    • Real-time Monitoring
    • Digital Twin
    • Component States
    • Loss Detection
    • Efficiency Detection
    • KPI Dashboard
  • Data Management

    • Events
    • Tickets
    • Forecasts
    • Reports
  • Integration & Sharing

    • Cooperations
    • API Tokens
    • VPN
    • Proxy
  • AI

    • AI Assistant & Wizards
    • Agentic Access (MCP)
  • Billing

    • Market & Tariffs
    • Accounting & Billing
  • Collaboration

    • Invitations
  • Security

    • Authentication
    • Permission System
    • Cooperation Restrictions
    • Access Audit Logging
  • Nodes

    • mrxnode
  • Application

    • Door Control
    • Generic Relay
  • Edge Cluster

    • Orchestration
  • Getting Started

    • First Steps
  • Personal

    • Using the VPN
    • Using the Proxy
    • Two-Factor Authentication
    • Sessions
    • API Tokens
  • Per Park

    • Contacts
    • Network Devices
    • Data Loggers
    • Components
    • Direct VPN (per Agent)
  • Organization

    • Member Permissions
    • Cooperations
    • File Storage
  • Data Export

    • Export Metric API
    • MiroxQL Query Language
    • External Report Generation
    • Grafana
    • API Overview
  • Support

    • Request Integration Guide
  • mrxnode

    • Overview
    • How-To Guide
    • Container Deployment
    • Command Cheatsheet
    • Troubleshooting
  • Reporting

    • External Report Generator
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Platform

    • Philosophy
    • Platform Overview
    • Platform Resources
  • Mirox-Cloud

    • Cloud Overview
    • Connected Microservices
  • Mirox-Agent

    • Agent Overview
    • Deployment Options
    • Data Scraper
    • Digital Twin
  • Technical Details

    • Metric Collection
  • Information

    • Supported Plants
  • Plant Types

    • Solar Plants
    • Wind Plants
    • Battery Storage
  • Monitoring & Visualization

    • Real-time Monitoring
    • Digital Twin
    • Component States
    • Loss Detection
    • Efficiency Detection
    • KPI Dashboard
  • Data Management

    • Events
    • Tickets
    • Forecasts
    • Reports
  • Integration & Sharing

    • Cooperations
    • API Tokens
    • VPN
    • Proxy
  • AI

    • AI Assistant & Wizards
    • Agentic Access (MCP)
  • Billing

    • Market & Tariffs
    • Accounting & Billing
  • Collaboration

    • Invitations
  • Security

    • Authentication
    • Permission System
    • Cooperation Restrictions
    • Access Audit Logging
  • Nodes

    • mrxnode
  • Application

    • Door Control
    • Generic Relay
  • Edge Cluster

    • Orchestration
  • Getting Started

    • First Steps
  • Personal

    • Using the VPN
    • Using the Proxy
    • Two-Factor Authentication
    • Sessions
    • API Tokens
  • Per Park

    • Contacts
    • Network Devices
    • Data Loggers
    • Components
    • Direct VPN (per Agent)
  • Organization

    • Member Permissions
    • Cooperations
    • File Storage
  • Data Export

    • Export Metric API
    • MiroxQL Query Language
    • External Report Generation
    • Grafana
    • API Overview
  • Support

    • Request Integration Guide
  • mrxnode

    • Overview
    • How-To Guide
    • Container Deployment
    • Command Cheatsheet
    • Troubleshooting
  • Reporting

    • External Report Generator
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Monitoring & Visualization

    • Real-Time Monitoring
    • Digital Twin
    • Component States
    • Loss Detection
    • Efficiency Detection (PRRC)
    • Local Network Inspector
    • Access Monitoring
    • KPI Dashboard
    • Graph Visualization
  • Data Management

    • Events
    • Tickets
    • Forecasts
    • Reports
  • Integration & Sharing

    • Cooperations
    • API Tokens
    • VPN
    • Proxy (Web Access to Plant Devices)
  • AI

    • AI Assistant & Wizards
    • Agentic Access (MCP)
  • Billing

    • Market & Tariffs
    • Accounting & Billing
  • Collaboration

    • Invitations
  • Security

    • Authentication
    • Permission System
    • Cooperation Permission Restrictions
    • Access Audit Logging

Loss Detection

The Digital Twin's watchdog monitoring system not only detects component states but also calculates precise energy losses for your installations. Loss detection helps you understand how much energy a component has lost compared to expected production.

General Concepts

Basic Principle of Loss Detection

Loss detection compares the actually produced energy with the expected energy based on weather data and system configuration:

  • Expected Energy: Calculated through simulation based on environmental conditions and component specifications
  • Measured Energy: Actual production according to energy meters
  • Loss: The difference when measured energy is lower than expected
Loss = max(0, Expected Energy - Measured Energy)

When Are Losses Calculated?

The system only calculates losses under certain conditions to avoid false alarms:

Losses ARE calculated for:

  • Components with significant underproduction: When measured energy is significantly below simulation
  • During detected outage periods: During actual production failures
  • With reliable data: Measurements must be physically plausible and consistent

Losses are NOT calculated for:

  • Communication failures: When data loggers don't send data, but production continued
  • Unfavorable weather conditions: Under conditions that make measurements unreliable
  • Times without expected production: When no energy is expected due to environmental conditions
  • Unreliable measurements: When measurements are physically impossible or inconsistent

Classification of Time Periods

The system analyzes energy time series and classifies each period:

ClassificationDescriptionLoss Calculation
Potential OutageEnergy didn't recover after a data gap. Likely a real outageYes - Losses are counted
Data GapEnergy recovered after a data gap. The component continued producing, only communication was interruptedNo - Period is excluded
Data Collection IssueA parent component reports healthy production, but a child component's data is missing or implausible. This is a communication or logging problem, not lost energyNo - Period is excluded
Border ConditionsUnfavorable weather conditions make analysis unreliableNo - Period is excluded
Normal ProductionContinuous data without gapsOnly for candidates - Losses are calculated for underproducing components

Data Collection Issue vs. Real Loss

A common source of confusion is a child component (for example, a string) whose data is missing while its parent (the inverter) clearly shows healthy production. The system recognizes this pattern: if the inverter's measured energy is consistent with its strings producing normally, the missing string data is treated as a data collection issue — a logger or communication problem — and never counted as an energy loss.

Why this matters

You will not be alarmed by phantom losses every time a single logger drops out. Only when the evidence points to genuinely lost production — the parent's own numbers confirm the shortfall — is a loss recorded.

Example: Communication Outage vs. Real Outage

Scenario A: Communication Outage (DATA_GAP)

Time:            08:00    [Gap]    12:00
Energy meter:    100 kWh    ???      180 kWh
                    │                  │
                    └──────────────────┘
                    Large jump: +80 kWh

Expected energy during gap: 100 kWh
Ratio: 80/100 = 80% ≥ 50% threshold

→ DATA_GAP: Component produced, only communication was interrupted
→ This period is EXCLUDED from loss calculation

Scenario B: Real Outage (POTENTIAL_OUTAGE)

Time:            08:00    [Gap]    12:00
Energy meter:    100 kWh    ???      105 kWh
                    │                  │
                    └──────────────────┘
                    Small jump: +5 kWh

Expected energy during gap: 100 kWh
Ratio: 5/100 = 5% < 50% threshold

→ POTENTIAL_OUTAGE: Likely a real outage
→ Losses are CALCULATED for this period

Confidence Levels

Each calculated loss receives a confidence level indicating how certain the system is that it's a real loss:

Confidence LevelMeaningTypical Scenarios
HIGHVery likely a real loss. Data is consistent and complete• Continuous underproduction
• Consistent measurements across all levels
• No data gaps
MEDIUMLikely a real loss, but with some uncertainty• Losses during POTENTIAL_OUTAGE periods
• Borderline data consistency
• Minor inconsistencies
LOWPossible loss, but significant uncertainty. Could be a data problem• Contradictory measurements
• Unclear outage situations
• Borderline deviations

Border Conditions

Certain environmental and weather conditions make loss analysis unreliable. These periods are excluded for ALL components:

Excluded Conditions:

ConditionReason
Unfavorable weather conditionsSnow, dew, fog, or other conditions reduce production but aren't component issues
Network outagesCommunication infrastructure failed, affects all components
Maintenance workPlanned shutdowns or maintenance

Why global exclusions?

These conditions affect all components simultaneously and are not component-specific problems. For example, when snow is detected, this time period is excluded from loss calculation for all components, even if individual components show low production.


Loss Detection for Solar Parks

For solar parks, the system uses multi-level analysis along the energy chain: from individual strings through inverters to the grid feed-in meter.

Hierarchical Loss Calculation

Losses are calculated at string level and aggregated upwards:

String → GAK → Inverter → Feed-in Meter

Important Principles:

  • Losses are primarily calculated at string level
  • Parent components = Sum of child components
  • If string data is unreliable, it's skipped
  • The system validates that string losses don't exceed the physically possible losses of the inverter

Example: Hierarchical Consistency

Inverter:
  Simulation: 10,000 Wh
  Measurement:  9,000 Wh
  Max. Loss: 1,000 Wh

String 1:                    String 2:
  Loss: 500 Wh               Loss: 500 Wh

Sum: 1,000 Wh = Inverter Max. Loss ✓

→ Consistent: String losses equal inverter loss

Solar Park-Specific Border Conditions

For solar parks, additional weather-specific exclusions are applied:

Day with morning snow:
Time   | Snow  | Loss Calculation
-------|-------|------------------
06:00  | 0 cm  | Calculate normally
07:00  | 2.5cm | EXCLUDED
08:00  | 3.1cm | EXCLUDED
09:00  | 1.8cm | EXCLUDED
10:00  | 0 cm  | Calculate normally

→ 07:00-09:00 excluded for ALL components
→ Even if string shows low production, no loss counted

Special Scenarios for Solar Parks

Inverter Failure with String Data Gaps

When an inverter fails, string data loggers may fail. In this case:

  1. During the outage: ALL strings are included (not just candidates)
  2. After the outage: Only strings with continuously poor performance are counted as losses
  3. Advantage: Prevents losses from being overlooked due to logger failures

Meter Corruption After Outages

Sometimes string meters get stuck after an inverter outage:

String energy meter:
07:00  →  5000 Wh    (Normal)
07:45  →  5000 Wh    (Inverter failure, logger fails)
10:45  →  5000 Wh    (Inverter recovers, logger doesn't)
18:00  →  5000 Wh    (Meter stuck)

→ String appears as candidate (low daily production)
→ BUT: Only losses during 07:45-10:45 counted
→ After 10:45: No losses (meter corruption, not real loss)

Examples of Confidence Levels in Solar Parks

HIGH Confidence Loss:

String X:
- Daily simulation: 5,000 Wh
- Daily measurement: 4,000 Wh
- Sim_err: 0.80 (20% loss)
- Continuous data, no gaps
- Parent inverter healthy

→ Loss: 1,000 Wh with HIGH confidence
→ Clear case of underproduction

MEDIUM Confidence Loss:

String Y during inverter outage:
- Outage from 08:00 to 11:00
- Losses only counted during this period
- After outage: normal production

→ Loss: 800 Wh with MEDIUM confidence
→ Loss is limited to outage period

LOW Confidence Loss:

String Z:
- String reports 60% less than expected
- But: Inverter shows only 10% loss
- Data flow ratio inconsistent

→ Possible loss: 2,000 Wh with LOW confidence
→ Likely measurement problem, not real loss

Common Loss Patterns in Solar Parks

Continuous Underproduction:

  • A string consistently produces 20-30% less
  • → HIGH confidence loss
  • → Possible causes: Shading, soiling, defective modules

Periodic Outages:

  • String shows recurring outage periods
  • → MEDIUM confidence loss during outages
  • → Possible causes: Inverter problem, network issues

Inconsistent Measurements:

  • String losses don't match inverter losses
  • → LOW confidence
  • → Likely cause: Measurement problem, not real loss

Interpreting Loss Data

How to Evaluate Losses

  1. Check confidence level: Focus first on HIGH confidence losses
  2. View component state: Compare with Component States
  3. Identify temporal patterns: Are losses continuous or periodic?
  4. Validate hierarchy: For hierarchical systems (e.g., solar parks), check if losses are consistent across different levels

Related Loss Attribution

Not every shortfall against expected production is a fault. The edge agent separately tracks curtailment — production you were deliberately prevented from delivering — and attributes it to the responsible party:

  • Marketer curtailment: Output reduced on instruction from your direct marketer or trading party.
  • Grid curtailment: Output reduced by the grid operator (for example, feed-in management during grid congestion).

Curtailment is detected when a plant is held at or near its active power cap, and the foregone energy is recorded per minute against the marketer or the grid rather than being flagged as a component loss. This lets you distinguish a defective string from a perfectly healthy plant that was simply told to throttle.

Related Features

  • Digital Twin — the watchdog monitoring system that detects and calculates losses
  • Component Evaluation — how each component's state is classified
  • Efficiency Detection — performance ratio and string-configuration analysis
  • Data Scraper — edge analytics including curtailment tracking
  • Digital Twin Architecture — technical implementation
Prev
Component States
Next
Efficiency Detection (PRRC)
MIT Licensed | Copyright 2026 Mirox Verwaltungs GmbH