Building Your Own Grafana Dashboards

The provisioned Grafana is not read-only. Every portfolio has its own Grafana workspace in which you can build dashboards on the same raw time series the platform records — as long as you keep one rule: the overview dashboard Mirox provides is managed and gets replaced on every version rollout, so build your own dashboards as copies, never by editing it. This guide explains how Grafana is structured, what you may change, and how the platform's time series have to be read to give correct numbers.

If you only want to open the provided dashboard, see Using Grafana as an External Read Platform. For the metric catalogue, see Metric Collection.

How Grafana Is Structured

One Grafana organization per portfolio

Mirox provisions one Grafana organization per portfolio, named <organization> - <portfolio>. Everything inside it is shared by the portfolio's members:

• One data source (<organization> - <portfolio>), scoped to the plants of that portfolio. Every query you write runs against this data source and can only ever see the portfolio's plants — there is nothing to configure and nothing to leak.
• One managed dashboard, Portfolio Overview - <portfolio>, provided by Mirox (see below).
• Your own dashboards and folders, visible to everyone who can see the portfolio.

Because a portfolio is the unit of resource sharing, a plant that belongs to several portfolios is reachable from each of their Grafana organizations, and a dashboard you build in one portfolio does not appear in another. Put a dashboard where the people who need it are members.

Who can view and who can edit

Grafana membership follows the platform's permissions and is refreshed automatically whenever they change — there is no separate Grafana user management:

Membership and roles are synced when a permission is granted or revoked; an open Grafana session is refreshed so that a newly promoted editor does not need to log out and in again.

The Managed Overview Dashboard

Portfolio Overview - <portfolio> is rendered by Mirox from a published template version. The dashboard's tags carry the version (mirox-template-v<N>) and its description names the exact published content. Mirox administrators roll new versions out from the platform's admin area, and a rollout deletes and re-creates the dashboard — this is what keeps every portfolio on a known, tested template.

What to do instead:

1. Open the managed dashboard, then use Edit → Save as copy (or Export → Export as JSON and Import) to create your own copy with a new name. Put it in a folder of your own.
2. Build on the copy: add panels, change queries, add variables. Your copy is yours — no rollout touches it.
3. After a new template version is rolled out, open the managed dashboard once to see whether it gained panels you want to carry over to your copy.

The same applies to every dashboard you create from scratch: anything that is not the managed overview is left alone by the platform.

Reading the Time Series Correctly

Grafana shows you whatever a query returns, so a wrong reading looks exactly like a right one. The rules below are the ones the platform itself follows in its reports; a custom dashboard that follows them prints the same numbers as the report pages.

Labels: what a series is

Every series is identified by its metric name plus its labels. The labels you will filter and group by:

Two things are deliberately not labels: component names (see the next section) and units — every value is stored in base SI units: W, Wh, V, A, Hz, °C, W/m², Wh/m². Set the Grafana unit to watt / watt-hour and let Grafana scale to kW / MWh; never divide in the query.

Showing current component names

Telemetry carries component identifiers, not names: a rename in Mirox must not split a series into "before" and "after". The current names are published as their own info series — powerplant_inverter_info, powerplant_gak_info, powerplant_string_info, powerplant_feedin_info, powerplant_turbine_info — keyed exactly like the telemetry and carrying the name as a label (inverter_name, gak_name, string_name, meter_name, turbine_name). Join them onto the telemetry with the following pattern (this is what the managed dashboard does):

sum by (inverter_id, inverter_name) (
  (
    powerplant_inverter_power_ac{park="${park}"}
    * on (park, inverter_id) group_left(inverter_name)
    sgn(topk_last(1, last_over_time(powerplant_inverter_info{park="${park}"}[7d] @ (now()))) by (park, inverter_id))
  )
  or on (park, inverter_id) powerplant_inverter_power_ac{park="${park}"}
)

How it works: last_over_time(...[7d] @ (now())) picks the newest info point for each component as of now, so a rename is reflected on every time range; sgn() turns it into a 1 that the multiplication keeps; group_left(inverter_name) copies the name onto the telemetry; and the or on (...) branch keeps a component visible (by its id) if it has no info series yet. For a combiner box join on (park, inverter_id, gak_id) with gak_name; for a string on (park, inverter_id, gak_id, string_number) — the info series only carries gak_id when the string sits behind a combiner box, mirroring the telemetry. Never chart, sum or alert on an info series itself.

The four shapes of a series

The report engine reads every series in one of four ways. Use the same reading and your dashboard agrees with the report pages.

Plant totals versus components

Source-derived analytics series (models, expected power, performance ratio, curtailment) exist at plant level and once per segment. Select the plant-level series with segment_id!~".+" or a segmented plant reads N + 1 times. The same applies to onshore wind settlement: per-turbine points carry turbine_id, the park sum carries none — use turbine_id!~".+" for the park lane.

For per-component panels group by the identity labels and, where you want names, join the info series as shown above. Per-component modelled power and PR (powerplant_<source>_inverter_power, powerplant_<source>_inverter_pr, and the gak / string twins) exist for the pyranometer and weather sources.

Status codes and states

powerplant_inverter_vendor_status, powerplant_turbine_vendor_status, battery_*_vendor_status are the maker's own codes: a gap means "not read", and the value is a code, never a quantity — do not sum or average them. powerplant_inverter_operating_state and powerplant_turbine_operating_state are the platform's standard states (0 unknown … 8 fault), numbered so that max by (inverter_id) reads as "the worst state in the bucket". Show them with a Grafana value mapping rather than as a line.

Common pitfalls

• last_over_time(...[30y]) to fetch "the latest value" scans the whole retention on every refresh. Use a window that matches the series cadence — [1h] for a minute gauge, [1d] for a daily value, [7d] for the info series.
• Filtering on names (inverter_name="WR 01") stops working after a rename. Filter on inverter_id and show the name through the info-series join.
• Mixing lanes: powerplant_pyranometer_power without clipping / pr pins returns several lanes of the same quantity. Pin the lane you mean — the table below names the pins the reports use.
• Multi-meter plants: powerplant_power_grid is one series per meter. sum(...) them, or read powerplant_grid_power, which is already the summed, minute-aligned plant series.
• Timezone: series are stored in UTC and Grafana displays them in the browser's timezone. Daily values (configured facts, daily verdicts) are stamped at the plant's local midnight, so set the dashboard timezone to the plant's when you compare days.

The Report Series Catalogue

The platform's report and export pages are built from a fixed catalogue of series, each with a defined reading. The table lists every item with the metric it reads, the shape it is read as (see above), the label pins the reports apply, and the level (plant, per inverter, per combiner box, per string, per segment). Items marked solar are only emitted for solar plants; the report unit is the unit the report pages display — the stored series is always in base units (Wh, W, Wh/m²). A pin period="<YYYY-MM>" selects the delivery month of a settled lane.

Meters and production counters

Plant power

Plant-plane radiation

Modelled, expected and clear-sky production

Performance ratio

On-site sensors

Power limits

Settled curtailment

Inverters

Combiner boxes

Strings

Battery

Weather

Market prices

Infrastructure

Related Documentation

• Using Grafana as an External Read Platform — reaching the provisioned Grafana and the managed dashboard
• Metric Collection — the complete metric catalogue with units and labels
• MiroxQL Query Language — the same series, queried from the platform and turned into custom metrics for reports
• Metrics Export API — cleaned, aggregated metrics as CSV or JSON