API de l'ancien export

Cette page décrit les liens d'export qui existaient avant le Metric Export. Ils sont anciens (legacy) : ils sont servis sans changement, avec les mêmes paramètres, identifiants de métrique et colonnes, et ils ne sont plus étendus.

Routes

Tous les chemins suivent https://service.mirox.io/api. Un jeton d'API du groupe Metric Export les lit toutes.

Ce qui est obsolète

Une route obsolète répond toujours, mais elle peut être supprimée dans une version ultérieure, et la référence interactive de l'API la marque comme obsolète.

• La route par modèle pour une seule centrale sous /v1/export/report/{park_uid}/data/template/…. Utilisez à la place l'export par modèle ; il accepte les mêmes modèles.
• Les trois routes POST qui répondaient les exports en JSON. L'API Metric Export répond en JSON avec format=json.
• GET /v1/export/template/metrics, la liste des anciens identifiants de métrique pour l'éditeur de modèles. Le catalogue des indicateurs la remplace.

Tout le reste de cette page est ancien, mais non obsolète.

Plusieurs centrales : fusionner ou séparer

Les quatre exports acceptent des paramètres park et portfolio séparés par des virgules. Lorsque les deux sont indiqués, les centrales de chaque portefeuille s'ajoutent aux centrales listées.

multi_park_agg détermine la façon dont plusieurs centrales sont représentées. Le paramètre est disponible sur l'export par modèle, par identifiant de métrique et brut ; l'export par composant dispose à la place de multi_component_agg.

Avec une seule centrale, les deux sont identiques et le paramètre est ignoré.

Export par modèle

GET /v1/export/metrics/template/{template_uid}

curl "https://service.mirox.io/api/v1/export/metrics/template/ABCD12340001?park=ABC123DEF456&resolution=monthly" \
  -H "Authorization: Bearer YOUR_API_TOKEN"

Anciens modèles système

Dans l'application, ces cinq modèles sont remplacés par leurs successeurs dans l'onglet Modèles. Leurs liens continuent de répondre comme auparavant.

Report Technical v1 (ABCD12340001) contient :

Métriques de séries temporelles :

1. Energy Production (kWh) - energy_grid_daily
2. Energy Radiation Total (kWh) - energy_radiation_daily
3. GTI Sensor (kWh/m²) - gti_sensor_daily
4. GTI Weather (kWh/m²) - gti_weather_daily
5. Sunhours (h) - sunhours_daily
6. Availability Inverter (%) - availability_inverter
7. Availability Energy (%) - availability_energy
8. Availability Data (%) - availability_data
9. Availability Sensor (%) - availability_sensor
10. Energy Shutdown by Grid (kWh) - energy_shutdown_grid_daily
11. Energy Shutdown by External (kWh) - energy_shutdown_external_daily

Métriques de configuration du rapport :

• Energy Report (kWh) - energy_report
• GTI Report Incident (kWh/m²) - gti_report
• GTI Report Effective (kWh/m²) - gti_report_eff
• PR Report Target (%) - pr_report

Métriques calculées (avec MiroxQL) :

• Analyse d'irradiance (réelle, utilisation météo, écart capteur-météo)
• Cibles de production (basée météo, basée capteur, réelle, corrigée)
• Ratios de performance (météo, capteur, réel, corrigé)
• Productible spécifique (Wh/W)
• Analyse des pertes (pertes non compensables)

Modèles du Metric Export sur cette route

L'export par modèle accepte aussi l'identifiant d'un modèle du Metric Export, par exemple CAFE1000CAFE. Il répond alors le Metric Export de ce modèle : les paramètres calendaires sélectionnent la période, resolution sélectionne le pas, et le fichier suit les conventions du Metric Export. Il n'a pas de colonne « Days in Month » ni « Calendar Week », et les erreurs sont répondues avec un code. Sans resolution, c'est le pas du modèle qui s'applique.

La route obsolète pour une seule centrale n'accepte pas un tel modèle et répond 400 avec le lien à utiliser.

Sortie CSV

Les fichiers portent une ligne d'en-tête avec les noms et unités des métriques. La structure dépend de la résolution :

• Journalière — une ligne par jour.
• Hebdomadaire — une colonne « Date » au format de semaine ISO et une colonne « Calendar Week » avec le numéro de semaine.
• Mensuelle — une colonne « Days in Month » pour la normalisation.

Les valeurs sont agrégées par jour puis regroupées : l'énergie et les heures sont sommées, tout le reste est moyenné. Un jour est un jour UTC. Une valeur manquante est écrite 0.

Export par identifiant de métrique

GET /v1/export/metrics/query exporte un ensemble d'anciens identifiants de métrique sans modèle, avec les paramètres de période et le format CSV de l'export par modèle.

Export de séries temporelles brutes

GET /v1/export/raw/query renvoie des séries temporelles brutes au niveau de la centrale. GET /v1/metrics/raw liste chaque identifiant brut avec son nom, son unité, sa catégorie et l'opérateur qu'il applique entre les séries (sum, avg, min ou max).

curl --compressed "https://service.mirox.io/api/v1/export/raw/query?metrics=raw_grid_energy_total&park=ABC123DEF456&start=2026-07-01T00:00:00Z&end=2026-07-08T00:00:00Z&step=15m&value=use_delta" \
  -H "Authorization: Bearer YOUR_API_TOKEN" -o production_week.csv

Date;Grid Production (Wh)
2026-07-01 00:00;0,00
2026-07-01 06:15;1250,50
...

L'énergie est en Wh, et l'heure est en UTC.

Export brut par composant

GET /v1/export/raw/component/query exporte les séries temporelles brutes de composants individuels — onduleurs, boîtes de jonction ou strings uniques — d'exactement une centrale. Les identifiants de métriques de composant portent le préfixe comp_raw_ et sont listés, par type de composant, via GET /v1/metrics/components.

Limites

Les deux exports bruts refusent toute requête plus grande avec un 400 :

Les réponses de plus de 1 Mo environ sont compressées lorsque la requête porte Accept-Encoding: gzip.

Anciens identifiants de métrique

Les métriques journalières de l'export par modèle et par identifiant de métrique. Chacune peut être agrégée en valeurs hebdomadaires, mensuelles, trimestrielles ou annuelles. La colonne de formule montre sous forme simplifiée comment une valeur est dérivée. L'indicateur qui répond pour chaque identifiant dans le Metric Export figure dans la correspondance des identifiants.

Métriques de production d'énergie

Métriques de coupure et de perte

Métriques d'irradiance

Métriques météo

Métriques environnementales

Métriques de disponibilité

Métriques de batterie

Métriques de rapport

Les identifiants bruts et de composant sont listés par GET /v1/metrics/raw et GET /v1/metrics/components, ainsi que dans la correspondance des identifiants.

Comportements connus qui restent tels quels

Les chiffres des anciens exports sont conservés tels quels, afin qu'un classeur affiche demain ce qu'il affichait hier. Cela inclut trois lectures que le Metric Export effectue différemment :

Corrections

Deux groupes de colonnes de l'export de séries temporelles brutes étaient vides et portent désormais des valeurs. Un classeur qui les lit affiche des nombres là où il affichait des cellules vides.

Informations de centrale

GET /v1/export/report/{park_uid}/info

Répond les données de base d'une centrale en JSON : nom, type et description, emplacement et fuseau horaire, puissance crête, organisation et portefeuille, adresse et dates de mise en service. Un exemple figure dans le Générateur de rapports externe.

Événements

GET /v1/export/report/{park_uid}/events.csv

Les colonnes sont Event ID, Start Date, End Date, Duration (hours), Type, Creator, Description et Priority. La date de fin d'un événement encore ouvert est Ongoing. Une priorité de 1000 ou plus marque un événement important.

Fonctionnalités associées

• API Metric Export — l'export actuel
• Migrer vers le Metric Export — ce qui change, et la correspondance des identifiants
• Formules MiroxQL — l'API de formules derrière les colonnes calculées
• Générateur de rapports externe — informations de centrale et événements dans un exemple Python
• Jetons d'API — le jeton Metric Export