Metric Collection

Mirox gathers performance data from your renewable energy plants into a single, standardized metric vocabulary — the foundation for every monitoring, analysis, reporting, and forecasting capability on the platform. This page is the reference catalog of what is measured and how the measurements are organized.

The full taxonomy spans 458 standardized metric names across twelve families: plant production (powerplant), battery storage, the site's alarm system, weather inputs, weather-derived models, and several operational families that describe the collection itself — network monitoring, the agents, the operator fleet, basic network reachability, and the scraper sources. The tables below document the families you will chart most often; the operational families are summarized in the Network Metrics and Agent Metrics sections.

Data Scraper Architecture

At the core of metric collection is the Data Scraper, the edge component that collects time-series data from your plants. Rather than a single generic protocol engine, it uses a dedicated adapter per device family (data loggers, inverters, meters, battery systems), each built for that vendor's interface. The Data Scraper can operate in two deployment modes:

Cloud-Based Collection

When deployed in the cloud:

• Connects to solar parks via secure internet connections
• Aggregates data from multiple sites centrally
• Handles connection management and retry logic
• Optimizes bandwidth usage through intelligent polling

Edge-Based Collection

When deployed at the edge (on-site):

• Directly interfaces with local equipment for minimum latency
• Operates with local buffering to handle internet outages
• Performs preliminary data validation and filtering
• Synchronizes with the cloud when connectivity is available

The dual-mode architecture ensures reliable data collection regardless of site connectivity conditions or system scale.

Collected Metrics

The metric collection system gathers a comprehensive set of measurements that provide complete visibility into renewable energy plant performance. Metrics are grouped along three orthogonal axes:

• Site Metrics describe the physical site itself — its powerplant, its battery storage, its alarm system, and the weather around it.
• Network Metrics describe the connectivity between the site and the cloud.
• Agent Metrics describe the data-collection agents themselves — the scraper sources and the supporting infrastructure services running on the IoT device.

Site Metrics

Site metrics are the raw, time-series measurements collected directly from the equipment installed at a renewable energy site. They are partitioned by domain into the powerplant (PV inverters, grid connection, etc.), the battery energy storage system (BESS), the site's alarm system, and the weather (forecast and modelled).

Powerplant Metrics

Grid Metrics

Inverter Metrics

Junction Box (GAK) Metrics

String Metrics

Control Metrics

Irradiance Metrics

Environmental Metrics

Loss Metrics

Report Metrics

Digital Twin Metrics

Edge Analytics Metrics

The Data Scraper computes a set of analytics directly at the plant and publishes them as chartable series alongside the raw measurements. These are the series behind the platform's performance-ratio, curtailment and settlement features. Most families exist once per irradiance source — written <source> below, one of pyranometer (on-site sensors), satellite (satellite-derived irradiance for the site) or weather (modelled irradiance from meteorological data) — so each source keeps its own independent series and a drifting input can never silently distort the others.

Irradiance & modelled production

The plane-of-array irradiance each source sees, and the theoretical (uncurtailed) plant output modelled from it. One set per source — 13 series in total.

Performance ratio

Actual production compared against the modelled production — one independent PR lane per irradiance source, at plant level. See Expected Power and Performance Ratio for how the filters work.

Expected power & energy

The PR-calibrated expectation — the modelled production scaled by the plant's real-world efficiency. This is the baseline the component health watchdog holds live production against.

Per-component model & performance ratio

The component-level analogue of the plant-wide model: theoretical output and PR of a single inverter, combiner box (GAK) or string, using that component's own orientation and peak power. Emitted for the weather and pyranometer sources; series carry the component's identity labels. <component> is one of inverter, gak, string — 12 series in total, plus the daily completion marker.

Live & forecast power lanes

Real-time and forward-looking production references.

Curtailment

Foregone production attributed to its cause — <party> is grid (a grid-operator setpoint limits production) or marketer (the direct marketer's cap limits production). Each combination is emitted as instantaneous power and cumulative energy, in two variants: the settled series and a live series computed in real time. 24 series in total.

Settlement families

Series backing curtailment settlement and compensation. The fixed (flat-rate) family implements the source-independent settlement method: the reference is the average measured grid power over the 15 minutes before the curtailment began, frozen for the whole measure — no irradiance input needed. The Mischpreis family prices curtailment energy with the quarter-hourly German market mixed price, giving a revenue value in EUR per 15-minute interval.

Battery Metrics

The battery_* family is the vendor-independent metric vocabulary for any Battery Energy Storage System (BESS). It follows a strict component hierarchy where instance identification lives in labels, not in the metric name:

battery_environment_*       ambient sensors around the BESS
battery_pcs_*               grid-tied Power Conversion System in front of the box
battery_box_*               a BESS box / container — the DC battery
└── battery_storage_*       a cabinet / rack inside the box
    └── battery_module_*    a module inside the cabinet
        └── battery_cell_*  an individual cell inside the module

The battery hierarchy (box → storage → module → cell) describes the DC battery itself. The PCS (battery_pcs_*) is the grid-tied AC↔DC converter that sits in front of the box — it owns the AC side of the BESS plus its own converter telemetry, and is identified per device by the pcs label. Modelling it as its own component lets the battery and its converter be collected as two independent devices for the same container without their series colliding.

This is a collection-only spec — adapters publish raw values exactly as the vendor exposes them, with no aggregations, derivations, _min / _max / _mean modifiers, or status / health flags. All interpretation, roll-ups and alarming are downstream concerns of the digital twin.

Environment

Ambient sensors around the BESS — distinguished by the sensor label.

PCS Level

The grid-tied Power Conversion System — the AC↔DC converter in front of the battery box. It owns the AC side of the BESS (which the DC battery never measures), plus its own DC-bus reading, the battery state it relays, and converter-side telemetry. A PCS is a distinct device, identified by the pcs label; phase distinguishes per-phase AC quantities. Sign convention: positive = charging (grid → battery); direction is resolved from the directional energy counters, never from a status bit.

DC bus

The converter's own view of the DC link — the battery's authoritative DC state remains at box level.

AC side

Setpoints

Read-only view of the active dispatch targets.

Energy counters

Published exactly as the device's own lifetime counters report them — separate directional counters, so no sign decision is needed.

Relayed battery state & converter limits

The PCS relays a battery-management summary and reports its own dynamic operating limits. Where the battery management system is collected directly, battery_box_soc is authoritative and the relayed value is redundant; on a PCS-only site it is the only state of charge available.

Box Level

The top of the battery side — a BESS box / container. Required label: box. Optional labels: inverter, phase. AC-side metrics are only present when the AC↔DC conversion physically sits at box level.

AC-side energy flow

DC-side interface

Chemistry & state

Storage Level

A cabinet / rack inside a box. Required labels: box, storage. AC metrics are rare at this level — they are present only when the AC↔DC conversion physically sits at storage level.

AC-side energy flow

The same AC vocabulary as the box level, without per-phase or setpoint variants.

DC-side interface

Chemistry & state

Module Level

A module inside a cabinet — the smallest unit that has its own BMS chip. Required labels: box, storage, module. AC metrics are practically never present here.

DC-side interface

Chemistry & state

Cell Level

The smallest physical unit. Cells are series-connected within a module and share the module current, so per-cell current and power are not meaningful. Required labels: box, storage, module, cell.

Weather Forecast Metrics

Daily Weather Metrics

15-Minute Weather Metrics

Weather Calculation Metrics

Weather Model Metrics

Weather Model Power Metrics

Clearsky Model Power Metrics

Alarm System Metrics

The alarm_* family is the site's own alarm signalling. Nothing in it is measured: every value is the position of a relay contact read through a controller's digital inputs — an intrusion alarm panel's own relay outputs, plus the supervision contacts of the communication cabinet the panel is wired through.

Every series is a 0/1 gauge normalized so that 1 always means "the condition is present" (door open, alarm raised, UPS on battery, breaker tripped) and 0 means normal, whatever polarity the contact has on the wire. Absence is never a zero: a signal the device did not serve this cycle is not published at all, and a contact the operator has declared unwired is withheld rather than left standing in alarm. Instance identification lives in the alarm label — the alarm system the signals belong to — never in the metric name.

Every signal except alarm_door_open also opens a park event of the same name while it is asserted; an open door is routine and stays a series only. See Alarm System for the page these series feed.

Network Metrics

Network metrics describe the connectivity between the IoT device and the cloud, independent of any specific scraper or service.

Agent Metrics

Agent metrics describe the data-collection agents themselves — both the per-source state of individual scraper adapters, and the overall health and traffic of the agents and supporting connectivity. These metrics let your dashboards correlate data gaps with adapter or connectivity failures rather than with the equipment under measurement.

Scraper Source Metrics

The Data Scraper emits one set of these metrics per active adapter source. Series are distinguished by the source, source_num and name labels, so that data gaps can be correlated directly with adapter health rather than with the equipment being measured.

• scraper_health_state: Current adapter state, encoded as an integer: 0 = initializing, 1 = healthy, 2 = unhealthy, 3 = reconnecting, 4 = frozen (the logger is returning stale/stuck values), 5 = paused.
• scraper_cycles_total: Number of fetch cycles the adapter has executed since process start (resets on restart).
• scraper_errors_total: Number of fetch cycles that ended in an exception since process start (resets on restart).
• scraper_last_success_timestamp: Unix epoch seconds of the last successful fetch cycle. Only emitted after the first success.

Agent Service Metrics

These metrics track the health and network usage of the individual agent services (Data Scraper, Digital Twin, and supporting services) running on a device, so you can see whether a data gap is the equipment or the agent itself.

Network Traffic

Agent Health

Organization VPN

Connectivity and traffic for the organization-wide VPN link between the plant and the cloud.

Direct VPN

Connectivity and traffic for each direct (per-plant) VPN tunnel. Series carry a vpn_name label so each tunnel is identified individually.

SaaS VPN

Connectivity and traffic for the built-in agent-to-cloud tunnel that carries the platform's remote-access traffic to the plant.

VPN Server

When the agent itself acts as a VPN server for incoming connections, these metrics report the server state and every connecting peer. Per-peer series carry the interface, peer_uid and peer_kind labels, so dashboards can tell user connections and site links apart.

• agent_vpn_server_peer_last_handshake: Unix epoch seconds of the peer's last completed handshake; 0 means the peer never completed one. For OpenVPN peers, which expose no per-handshake timestamp, the connected-since time is published under the same metric so one query covers both protocols.

Operator Metrics

The operator fleet pushes infrastructure metrics for VPN tunnel monitoring and operator health, letting you see the state of the cloud-side connectivity that links your plants to the platform.

VPN Tunnel Metrics

• operator_vpn_connected: 1 if the VPN tunnel has a recent handshake (within the last 3 minutes), 0 otherwise
• operator_vpn_rx_bytes: Total bytes received through the VPN tunnel (counter)
• operator_vpn_tx_bytes: Total bytes transmitted through the VPN tunnel (counter)

Operator Health Metrics

• operator_health: 1 if the operator has an active cloud connection, 0 if in timeout state
• operator_uptime_seconds: Seconds since the operator process started
• operator_cloud_response_age_seconds: Seconds since the last successful cloud API response

Collection Process

The data collection process follows a structured workflow:

1. Discovery: The system identifies all components to monitor based on park configuration
2. Scheduling: Collection schedules are optimized based on metric importance and variability
3. Retrieval: The data scraper connects to devices and collects raw measurements
4. Validation: Collected data is validated for accuracy and range compliance
5. Enrichment: Contextual information is added (timestamps, component identifiers, etc.)
6. Transmission: Data is securely transmitted to the Time-Series Database
7. Verification: The system confirms successful storage and availability

Integration Points

The metric collection system integrates with other platform components:

• Monitoring Dashboard: Provides real-time data visualization
• Event Detection: Supplies data for anomaly and issue identification
• Reporting Engine: Furnishes measurements for performance reports
• Analytics System: Feeds data into advanced performance calculations
• Forecasting Module: Provides historical data for prediction models

Data Security

All collected metrics are protected through multiple security measures:

• Encryption: Data is encrypted both in transit and at rest
• Access Control: Metrics are subject to the same permission model as other resources
• Auditing: All access to metric data is logged for compliance purposes
• Anonymization: Aggregated data used for benchmarking is anonymized

Extensibility

The metric collection system is designed for extensibility:

• New Device Families: We build a dedicated adapter for each device family on request — if your plant uses a logger, inverter, meter, or battery system we do not yet support, it can be added without a generic catch-all.
• Custom Metrics: Support for site-specific or equipment-specific measurements.
• External Data Sources: Weather and reference-irradiance series are pulled in alongside your plant data to power analysis and forecasting.

Related Features

• Data Scraper — the edge agent that collects these metrics with a dedicated adapter per device family
• Digital Twin — turns the raw metrics into simulated production, performance ratio, and loss findings
• Metrics Export API — query and download these metrics for your own use
• MiroxQL — the query format for programmatic and raw access to your collected metrics
• Real-Time Monitoring — live dashboards built on the collected metrics