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

powerplant_grid_power is the minute-aligned interpolation of powerplant_power_grid, summed across every meter, and powerplant_grid_energy_total the platform's own boot-aware energy counter integrated from it — the one monotonic site-production series the analytics read (a multi-meter park has several raw powerplant_energy_grid_total counters). Both carry a boot_time label; read the counter with sum(increase(…)).

PV and Battery Feeder Meters

A park with a battery (or another producer) behind the same grid connection point meters each feeder separately. The grid family above is the connection point, summed park-wide; the PV feeder publishes the powerplant_pv_* family and the battery feeder the powerplant_battery_* family — the same quantities with the same sign convention (production / discharge positive). The two battery counters are named by what the unit did: _energy_discharge_total is what it gave out, _energy_charge_total what it took in. Not to be confused with the battery_* families below, which are the battery controller's own view of its box, storage, module and cell levels.

Plant AC Totals

Plant-level AC totals published by loggers that report the plant as one AC unit (legacy naming, energy/power before ac).

Inverter Metrics

powerplant_inverter_power / powerplant_inverter_energy_total are the inverter-summed, minute-aligned analogues of the grid pair above (one plant series with a boot_time label, not one per inverter). powerplant_inverter_data_complete is the per-minute verdict on that sum: 1 when every expected inverter contributed, 0 otherwise, absent when no verdict was possible. powerplant_inverter_operating_state is the platform's standard operating state derived from the maker's status code (0 unknown, 1 idle, 2 producing, 3 producing limited, 4 self-derating, 5 stopped by command, 6 stopped by protection, 7 unreachable, 8 fault — numbered so max reads as the worst state), while powerplant_inverter_derating_reason is the maker's own reason code for a derate.

Junction Box (GAK) Metrics

String Metrics

Wind Turbine Metrics

A wind turbine is a flat plant component like an inverter, identified by the turbine_id label (with turbine_name and turbine_vendor). Values are the 10-minute averages the turbine controller records. powerplant_turbine_blade_pitch_angle carries a blade label (A/B/C) and powerplant_turbine_temperature a sensor label (gearbox, generator, transformer, nacelle, …). The time_* series are seconds per 10-minute interval spent in each state — measured availability, not inferred from gaps. The curtailment and loss series are the measured gap between possible and actual power, attributed to a party by the controller's own status code (grid = grid operator, marketer = plant-controller dispatch, environment = shadow / bat / ice / weather stops, command = manual or service stops, fault = a turbine alarm); their _energy_total counters are lifetime totals the platform maintains.

Component Info Series

The names an operator gave the components, published as their own series so dashboards can show current names without the telemetry carrying them as labels (a label change would fork a series). One series per component, keyed exactly like its telemetry (inverter_id; gak_id; string_number, with gak_id only behind a combiner box; id for a feed-in meter; turbine_id) plus the name label (inverter_name, gak_name, string_name, meter_name, turbine_name). The value is the emission time; the series is refreshed on every tree sync, so a rename shows up on the next sync. Never chart, sum or alert on these — join them onto the telemetry as shown in Building Your Own Grafana Dashboards.

Control Metrics

Battery setpoints are signed (positive = discharge, negative = charge): _external / _external_w is the marketer's order, _local_w the operator's manual entry, _applied / _applied_w what the plant controller actually commands the storage with after folding every order and cap into one number. Caps are positive magnitudes: powerplant_max_power_import_by_grid is the grid operator's limit on what the plant may draw (100 = no reduction), and the battery_max_power_charge/discharge_by_grid pairs the grid operator's limits on the storage inside a larger plant, one lane per direction. Each device publishes the lane it states natively (percent or watts); the platform never converts between them.

Irradiance Metrics

Environmental Metrics

Loss Metrics

Report Metrics

Digital Twin Metrics

Status Metrics

The platform's daily production verdict per component: 1 when the component produced normally, 0 otherwise, with the detailed state in the status label. Not to be confused with powerplant_inverter_operating_state, which is what the device itself reports per poll.

Configured Facts

Published once per park-local day by the platform from the plant configuration, never measured: the peak power of each component and of the park, the park's inverter limit and the component counts. Hidden components are excluded and an unconfigured value writes no sample, so "not configured" stays distinguishable from "configured as zero". Read them like any series, e.g. last_over_time(powerplant_inverter_peak_power[1d]).

Deprecated Metrics

Kept only for dashboards that already use them — new dashboards should use powerplant_solar_radiation and powerplant_inverter_frequency instead.

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.

Wind settlement families

Onshore wind settles curtailment per turbine and sums to a park lane: the per-turbine points carry a turbine_id label, the park sum carries none — read them apart with turbine_id!~".+", since a bare sum(...) over both double-counts. Three methods share the same maths and labels: nacelle (the turbine's own anemometer feeds the certified power curve), windref (the default — a reference turbine's or a meteorological-service wind speed), and windfixed (flat-rate: the last unrestricted measured power, frozen for the whole measure). The Marktprämie feed-in is the measured grid feed-in with every negative-price quarter zeroed, one copy per negative_price_rule. <party> is grid or marketer.

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.

Network Monitoring Metrics

The agent's own active checks (ICMP, TCP, HTTP) against the devices on the plant network. Per-device series carry device_ip, device_name, device_type and device_vendor; TCP checks add the port, HTTP checks the endpoint. netmon_park_network_up is one roll-up series per plant.

SNMP Metrics

Read from SNMP-capable devices on the plant network (switches, routers, gateways). Device series carry the same device labels as above; interface series add if_index, if_name and if_type.

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
• operator_cloud_liveness_age_seconds: Seconds since the cloud process was last confirmed alive (health endpoint) — stays fresh even while the main API returns errors, so it is the failsafe gate

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