Metric-Export-API

Die Metric-Export-API liefert jede Metrik Ihrer Anlagen als Zeitreihe, als CSV oder JSON, mit einer einzigen GET-Anfrage. Sie liest dieselbe Metriksammlung wie die Berichte, einschließlich der Metriken, die Ihre Organisation selbst definiert hat.

Jeder Link, den die Seite Daten-Export zeigt, ist ein Aufruf dieser API. Der einfachste Weg zu einer funktionierenden Anfrage ist also, sie dort zusammenzustellen und zu kopieren.

Die Export-Links des bisherigen Exports funktionieren unverändert weiter. Sie sind in der Legacy-Export-API beschrieben; wie Sie vom einen zum anderen wechseln, steht im Leitfaden zum Umstieg.

Routen

Alle Pfade folgen auf https://service.mirox.io/api.

Authentifizierung

Senden Sie ein API-Token der Gruppe Metric Export im Header Authorization:

Authorization: Bearer YOUR_API_TOKEN

Das Token liest jede Export-Route dieser Seite und die Legacy-Routen. Es kann nichts erstellen, ändern oder löschen. In einem Browser, in dem Sie bei Mirox angemeldet sind, funktionieren die Links ohne Token.

Sie erhalten nur Daten der Anlagen, deren Messwerte Sie lesen dürfen. Die Metriken Ihrer Organisation werden von jeder Organisationsrolle außer Extern exportiert. Siehe Wer was exportieren kann.

Eine Zeitreihe exportieren

GET /v1/export/series

Netzeinspeisung einer Anlage über den Vormonat, je Tag:

curl --compressed "https://service.mirox.io/api/v1/export/series?park=ABC123DEF456&metrics=plant.grid_feedin&window=previous_month&step=day" \
  -H "Authorization: Bearer YOUR_API_TOKEN" -o feedin.csv

Date;Grid feed-in (kWh)
2026-08-01;5321,4
2026-08-02;4980,2
...

Parameter

lane_limit und lane_page außerhalb ihrer Grenzen werden auf die nächste Grenze gesetzt. Ein Parameter, den die Route nicht kennt, wird ignoriert.

Metriken und Werte

Eine Metrik-ID hat die Form <Präfix>.<Name>, zum Beispiel plant.grid_feedin, inverter.ac_power oder sensor.irradiance. Eine Metrik Ihrer Organisation lautet organization.<ID der Metrik>. Der Katalog listet sie alle.

Jede Metrik hat eine Größenart, die bestimmt, welche Wertemodi sie anbietet:

Ein Suffix legt den Modus einer einzelnen Metrik fest und hat Vorrang vor values:

metrics=plant.grid_feedin:cumulative,plant.grid_power

Ein Modus, der für eine Metrik nicht gilt, ist nie ein Fehler. Die Metrik wird als native exportiert, und der Hinweis value_mode_ignored sagt das. delta wird nie auf eine Leistung angewendet.

Dieselbe Metrik in zwei Modi ergibt zwei Spalten. Dieselbe Metrik zweimal im selben Modus ergibt eine.

Zeitraum

Geben Sie den Zeitraum auf eine von drei Arten an. Zwei Arten in einer Anfrage antworten mit 400 window_conflict.

Freier Zeitraum. start und end sind ein Datum (2026-07-01) oder ein Datum mit Uhrzeit (2026-07-01T06:00, 2026-07-01T06:00:00Z, 2026-07-01T06:00:00+02:00). Ein Wert ohne Zeitzone wird in der Zeitzone der Zeilen gelesen. Ein end, das ein Datum ist, schließt diesen Tag ein; ein end mit Uhrzeit ist der Moment, in dem der Zeitraum endet. Ohne end endet der Zeitraum jetzt. end allein, ohne start, wird abgelehnt.

Kalender. year von 2020 bis 2100, quarter 1 bis 4, month 1 bis 12, week 1 bis 53 (ISO-Woche), day 1 bis 31. day braucht month. Ohne year ist das laufende Jahr gemeint. day hat Vorrang vor week, week vor month, month vor quarter.

Voreinstellungen. today, yesterday, last_7_days, last_30_days, this_week, previous_week, this_month, previous_month, this_quarter, previous_quarter, this_year, previous_year. Die this_-Voreinstellungen laufen bis jetzt; last_7_days und last_30_days laufen bei Schrittweiten unter einem Tag rollierend bis jetzt (dieselbe Uhrzeit 7 bzw. 30 Tage zurück); ab day sind es die letzten 7 bzw. 30 Tage der Anlage einschließlich heute. Ab day wird jedes Zeitfenster auf ganze Tage (Wochen, Monate …) in der Zeitzone der Anlage erweitert; die Antwort nennt das tatsächliche Zeitfenster.

Ein Zeitraum beginnt frühestens 2020 und umfasst höchstens 1827 Tage (fünf Jahre). Ein Zeitraum, der in die Zukunft reicht, endet jetzt, mit dem Hinweis end_clamped.

Schrittweiten

step=auto wählt eine Schrittweite, die jede angefragte Metrik bedient und die in die Grenzen passt: 15min bis zu zwei Tagen, 1h bis zu 62 Tagen, day bis zu drei Jahren, darüber month. Passt diese Schrittweite nicht, wird die nächstgröbere versucht, danach die feineren. Der Hinweis step_auto und der Header X-Mirox-Step nennen die gewählte Schrittweite.

Jede Metrik bietet ihre eigenen Schrittweiten an. Der Katalog listet sie als export_steps:

Leistung wird nur bei 15 Minuten oder feiner angeboten. Eine Tages- oder Monatsleistung ist ein Mittelwert, der verbirgt, was geschehen ist; die Energie-Metrik liefert die Zahl, die gemeint ist.

Eine Schrittweite wird nie stillschweigend geändert. Mit mismatch=refuse, der Voreinstellung, antwortet eine Schrittweite, die eine der Metriken nicht bedient, mit 400 step_not_served und den Schrittweiten jeder Metrik, und mit step=auto antworten Metriken ohne gemeinsame Schrittweite mit 400 no_common_step. Mit mismatch=sparse wird eine solche Anfrage stattdessen geliefert — siehe Metriken mit verschiedenen Schrittweiten.

Schrittweiten von einem Tag oder länger umfassen ganze Intervalle. Ein Zeitraum, der innerhalb eines Intervalls beginnt oder endet, wird nach außen erweitert, mit dem Hinweis window_aligned. Wochen beginnen am Montag.

Metriken mit verschiedenen Schrittweiten

mismatch=sparse liefert eine Anfrage, deren Metriken nicht alle die Schrittweite bedienen, solange jede von ihnen irgendeine Schrittweite bedient. Das Raster der Datei ist die angeforderte Schrittweite; mit step=auto ist es die Schrittweite, die die meisten Metriken unverändert bedienen, wie üblich nach Zeitraum und Grenzen gewählt. Spaltenpositionen und die Form der CSV- und JSON-Antwort ändern sich nicht.

Zwei Fälle werden in beiden Modi mit 400 step_not_served abgelehnt: ein Wert je Monat, Quartal oder Jahr in einer week-Datei, weil sein erster Tag kaum je ein Montag ist; und ein Monatswert wie der Marktwert in einer quarter- oder year-Datei, weil eine Summe oder ein Mittel von Monaten nicht dieser Wert ist. In einer month-Datei wird er unverändert gelesen, in einer feineren Datei ist er dünn besetzt.

Die Schätzung listet dieselben Hinweise, zählt die Lesevorgänge in der eigenen Schrittweite jeder Metrik und markiert eine Schrittweite in per_step auch dann als innerhalb der Grenzen, wenn nicht jede Metrik sie bedient. Die Seite Datenexport fragt immer mit mismatch=sparse an; eine Vorlage trägt ihr eigenes mismatch in ihrer spec.

Zeitraster

Mit tz=local folgen die Zeilen der Ortszeit der Anlage, einschließlich der Sommerzeit: Ein Tag ist ein lokaler Tag mit 23, 24 oder 25 Stunden, ein Monat ist ein lokaler Monat. Mit tz=utc folgen die Zeilen dem UTC-Kalender.

• Bei Schrittweiten unter einem Tag in Ortszeit folgt die Spalte UTC-Versatz auf die Zeitspalte (+02:00). Am Tag, an dem die Uhren zurückgestellt werden, erscheint eine Stunde zweimal; der Versatz unterscheidet die beiden. offset_column=false lässt die Spalte weg.
• Anlagen in verschiedenen Zeitzonen teilen sich eine Zeitspalte. Eine solche Anfrage wird auf dem UTC-Kalender beantwortet, mit dem Hinweis merged_on_utc, gleich ob die Anlagen zusammengefasst oder getrennt werden.
• Mit tz=utc und einer Schrittweite von einem Tag oder länger hat eine Metrik, die es nur je lokalem Tag gibt, keinen UTC-Wert. Ihre Spalte bleibt leer, mit dem Hinweis utc_calendar_unsupported.

Der Header X-Mirox-Grid nennt den verwendeten Kalender: local:Europe/Berlin oder utc.

Mehrere Anlagen

Mit multi_park_agg=merge ist jede Metrik eine Spalte für alle Anlagen, zusammengefasst nach der Regel der Metrik. Der Katalog listet die Regel als merge:

Eine Metrik, die sich nicht zusammenfassen lässt, wird je Anlage exportiert, mit dem Hinweis merge_not_meaningful. Das gilt auch für ein Verhältnis in einer Schrittweite, in der seine beiden Hälften nicht verfügbar sind, und für Preise von Anlagen in verschiedenen Marktzonen.

Mit multi_park_agg=split ist jede Metrik eine Spalte je Anlage. Bei einer einzelnen Anlage ergeben beide dieselbe Datei.

Komponenten-Metriken sind immer je Anlage (Hinweis components_split_by_park).

Komponenten

Eine Metrik einer Komponentenebene ergibt eine Spalte je Komponente. Die Ebenen sind inverter, gak (Generatoranschlusskasten), string, turbine, sensor, meter, battery_box (Container), battery_storage (Rack), battery_module, battery_cell und battery_pcs (Umrichter).

Ohne components enthält der Export alle sichtbaren Komponenten der Anlagen, lane_limit je Metrik und Seite. Gibt es mehr, nennt der Hinweis lanes_truncated die Gesamtzahl; fordern Sie die nächste Seite mit lane_page an.

components schränkt den Export auf die Komponenten ein, die Sie nennen. Eine Referenz hat die Form <Ebene>:<ID>, zum Beispiel inverter:1043. Ein Sensor oder Zähler, den Mirox misst, der aber keinen Eintrag in den Komponenten der Anlage hat, hat eine Referenz der Form sensor:h3f9c2a71b04e6d5. Die Komponenten-Route listet die Referenzen einer Anlage. Eine Referenz, die zu keiner der gewählten Anlagen gehört, antwortet mit 400 unknown_lane.

metrics=inverter.ac_power&components=inverter:1043,inverter:1044

Rohe MetricsQL-Abfragen

expr fügt einem Export eine rohe Abfrage in MetricsQL hinzu, der Abfragesprache der Zeitreihendatenbank der Plattform — für eine Reihe, für die die Sammlung keine Metrik hat. Der Parameter kann bis zu fünfmal wiederholt werden; jeder Ausdruck darf bis zu 4 000 Zeichen haben. Eine Anfrage kann expr allein oder metrics und expr zusammen tragen; die Metrik-Spalten kommen zuerst.

expr=sum by (inverter_id) (powerplant_inverter_power_ac)&park=ABC123DEF456&window=yesterday&step=15min

Ein Ausdruck wird je Anlage ausgewertet, so wie ein Dashboard ihn auswertet: auf den Daten der Anlage, in der angeforderten Schrittweite, als Rohwerte — jede Schrittweite ist erlaubt, values und die Zusammenfassungsregeln der Metriken gelten nicht. Mirox fügt die Anlage in jeden Selektor des Ausdrucks ein; ein Ausdruck, der selbst ein Label park, organization oder plant nennt, wird mit 400 expr_forbidden_label abgelehnt.

Liefert ein Ausdruck an irgendeiner seiner Anlagen mehrere Reihen, tragen die Spalten dieses Ausdrucks an jeder Anlage die Reihen-Labels, sodass eine Datei je Ausdruck eine Benennung hat. Ein Kopf länger als 1 000 Zeichen wird mit … innerhalb des Ausdrucks gekürzt, nie im Reihentext. In der JSON-Antwort ist columns[].key der Text von header=id und columns[].metric die ID des Ausdrucks, expr.e1, expr.e2, …, die Hinweise und Ablehnungen verwenden. Eine Anlage, an der der Ausdruck nichts liefert, behält eine leere Spalte, mit dem Hinweis expr_no_series; bei mehreren Anlagen erhält jede Anlage ihre eigenen Spalten, mit dem Hinweis expr_split_by_park.

Ein Ausdruck darf an einer Anlage höchstens 500 Reihen liefern (400 expr_too_many_series); fassen Sie ihn zusammen, etwa mit sum by (…). Die Reihen zählen gegen dieselben 400 Spalten und 1 800 000 Werte wie jeder Export: Der erste Lesevorgang jedes Ausdrucks an jeder Anlage ist eine kurze Probe, die Breiten werden über die ganze Anfrage summiert, und eine Anfrage, die die Grenzen überschreitet, wird mit 400 over_budget und params.series abgelehnt, bevor irgendein Ausdruck vollständig gelesen wird. Ein Ausdruck, der nicht geparst werden kann, leer oder zu lang ist oder den die Datenbank ablehnt, antwortet mit 400 expr_invalid und dem reason.

Die Schätzung zählt einen Ausdruck als eine Spalte je Anlage, weil seine Reihen erst beim Lesen bekannt sind. Ausdrücke werden nicht in Vorlagen gespeichert.

CSV-Antwort

Die Antwort ist UTF-8, mit dem Dateinamen series_export_<erster Tag>_<letzter Tag>_<Schrittweite>.csv. Eine Antwort über etwa 1 MB wird komprimiert, wenn die Anfrage Accept-Encoding: gzip enthält (curl: --compressed).

Die Spalten sind, in dieser Reihenfolge: die Zeit, der UTC-Versatz, wo er zutrifft, danach die Metriken in der Reihenfolge von metrics.

Die Zeitspalte wird je Schrittweite formatiert, sofern datetime_format nicht angegeben ist:

Jede Zeile trägt den Beginn ihres Intervalls als Zeitstempel. Ein fehlender Wert ist eine leere Zelle, sodass sich „keine Daten“ und „null“ unterscheiden lassen; empty=zero schreibt stattdessen 0.

Vier Header der Antwort wiederholen, was aufgelöst wurde:

JSON-Antwort

format=json beantwortet dieselbe Tabelle als strukturierte Daten:

Hinweise

Ein Hinweis sagt Ihnen, was Mirox von sich aus getan hat. Er lässt einen Export nie scheitern. Hinweise sind Teil der JSON-Antwort und des Headers X-Mirox-Notes. Der Header enthält bis zu 1 KB an Hinweisen, geschrieben als code:key=value,key=value und getrennt durch ;. Passen nicht alle hinein, endet der Header mit notes_omitted:count=<n>; die JSON-Antwort enthält alle.

Eine leere Spalte bleibt immer erhalten. Eine Metrik, die für eine der Anlagen nicht gilt, oder eine Geld-Metrik ohne Buchhaltungsberechtigung lässt ihre Spalte an ihrem Platz, sodass sich die Positionen der übrigen Spalten nie verschieben.

Vor dem Export schätzen

GET /v1/export/series/estimate

Die Route nimmt die Parameter des Exports, ohne das Dateiformat, und beantwortet, was der Export wäre — ohne Daten zu lesen und ohne auf das stündliche Kontingent zu zählen.

Eine Ablehnung lässt die Schätzung nie scheitern: Sie antwortet mit 200 und listet die Ablehnung. Die Schätzung zählt, sie rendert nichts: Zeilenbeschriftungen und Spaltenköpfe sind die des Exports. Eine rohe Abfrage zählt als eine Spalte je Anlage, und mit mismatch=sparse nennen die Hinweise die zusammengefassten und dünn besetzten Spalten.

Der Metrikkatalog

GET /v1/export/series/catalog

Jede Metrik trägt neben ID, Name, Beschreibung, Einheit und Ebene:

Bei bis zu 10 Anlagen wird jede Anlage auf die Ausstattung geprüft, die eine Metrik braucht. Darüber werden Anlagen nur nach ihrem Typ beurteilt; was einer einzelnen Anlage fehlt, zeigt sich beim Export als Hinweis metric_unavailable.

Glossar. format=csv beantwortet die ganze gefilterte Liste als Datei, metric_catalog_<Sprache>.csv, mit den Spalten ID, Ebene, Name, Einheit, Beschreibung, Größenart, Wertemodi, Schrittweiten, Messintervall, Zusammenfassung über Anlagen, Hinweis und bisherige IDs. page und limit gelten nicht.

curl "https://service.mirox.io/api/v1/export/series/catalog?format=csv&language=en" \
  -H "Authorization: Bearer YOUR_API_TOKEN" -o metric_catalog_en.csv

Verfügbare Metriken

Die Sammlung ist nach Ebene geordnet. Das Präfix einer ID sagt, wohin eine Metrik gehört.

Die vollständige Liste mit Namen, Einheiten und Beschreibungen in Ihrer Sprache ist der Katalog, die Glossardatei oder Erklärungen auf dem Tab Metriken. Die Wettervorhersage-Werte des bisherigen Exports sind nicht Teil der Sammlung; siehe den Leitfaden zum Umstieg.

Komponenten einer Anlage

GET /v1/export/series/lanes

Jeder Eintrag hat die Referenz ref für den Parameter components, den name, das level, das übergeordnete Element (parent_ref, parent_name — zum Beispiel den Wechselrichter eines Strings), attributes (role eines Zählers, position eines Einstrahlungssensors, vendor), hidden und source: db für einen Eintrag der Komponenten der Anlage, store für eine Reihe, die gemessen wird, aber keinen solchen Eintrag hat.

Eine Anlage, die nicht existiert, und eine Anlage, die Sie nicht lesen können, antworten beide mit 404 park_not_found.

Vorlagensystem

Eine Vorlage ist eine gespeicherte Liste von Metriken mit Voreinstellungen für Schrittweite, Zeitraum, Werte, Zeitzone, Zusammenfassung der Anlagen, Seitengröße der Komponenten und Spaltenköpfe. Wofür Vorlagen da sind und wie Sie sie in der App verwalten, steht in der Anleitung zum Metric Export.

Eine Vorlage exportieren

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

Die Route nimmt die Parameter des Exports außer metrics, components und values, die die Vorlage festlegt. Jeder Parameter, den Sie weglassen, nimmt die Voreinstellung der Vorlage; jeder Parameter, den Sie angeben, hat Vorrang.

curl --compressed "https://service.mirox.io/api/v1/export/series/template/CAFE1000CAFE?park=ABC123DEF456&window=previous_month&header=id" \
  -H "Authorization: Bearer YOUR_API_TOKEN" -o standard.csv

• Eine Vorlage einer anderen Organisation antwortet mit 404 template_not_found.
• Eine Legacy-Vorlage antwortet mit 400 template_is_legacy; params.legacy_url ist der Link, der sie exportiert.
• Eine Spalte, deren Metrik nicht mehr verfügbar ist, wird leer unter ihrem Spaltenkopf exportiert, mit dem Hinweis metric_unavailable. Dasselbe gilt für eine Metrik Ihrer Organisation, wenn Sie als Extern exportieren (reason not_permitted).

Systemvorlagen

Die ersten fünf lösen CAFE0000CAFE, CAFE0001CAFE, CAFE0002CAFE, CAFE0003CAFE und ABCD12340001 ab, die auf der Legacy-Route weiter funktionieren. Ihre Spalten stehen im Leitfaden zum Umstieg. Sie bieten die Schrittweiten day, week, month, quarter und year an; die ersten vier zusätzlich 15min und 1h.

Vorlagen verwalten

Vorlagen werden unter /v1/export/template gelistet, gelesen, erstellt, geändert und gelöscht. Das Lesen funktioniert mit einem Token Metric Export. Das Schreiben braucht die Organisationsrolle Admin, Moderator, Asset Manager (Technisch) oder Asset Manager (Kaufmännisch) und eine Anmeldung oder ein Token Voller Zugriff.

Die spec einer Vorlage:

label ist der Spaltenname der Spalte bei header=name. Eine Metrik darf einmal vorkommen, und eine Vorlage enthält keine rohen Abfragen. Beim Speichern einer Vorlage muss jede Metrik exportierbar sein, und die Metriken müssen eine gemeinsame Schrittweite haben — unter mismatch=sparse muss jede irgendeine Schrittweite bedienen; andernfalls lautet die Antwort 422 spec_invalid, und params.problems nennt die Metrik und den Grund. Eine Vorlage läuft mit ihrem eigenen mismatch (die App zeigt es als Metriken mit anderem Schritt: Strikt oder Tolerant); der Parameter im Export-Link hat Vorrang.

Eine Legacy-Vorlage umwandeln

POST /v1/export/template/{template_uid}/convert

Die Antwort listet mapped (legacy_id, metric, values, exactness: exact oder approximate) und unmapped (legacy_id, reason: formula, no_equivalent, report_value oder instant, und bis zu drei suggestions) und, sofern es kein Probelauf war, die neue template. Ein Probelauf antwortet mit 200, eine Umwandlung mit 201.

Die neue Vorlage exportiert Tage über den Vormonat. Die Legacy-Vorlage wird nie verändert. Zwei Legacy-Spalten, die denselben Zähler lesen, werden zu einer Spalte. 422 nothing_to_convert bedeutet, dass keine Spalte eine Entsprechung hat oder dass die Vorlage keine Legacy-Vorlage ist.

Grenzen

Ein Export wird innerhalb einer Anfrage beantwortet, daher ist seine Größe begrenzt. Jede Grenze wird geprüft, bevor Daten gelesen werden; eine zu große Anfrage wird sofort abgelehnt und sagt Ihnen, was passen würde.

Einen großen Export aufteilen

400 over_budget nennt in params, was gebraucht wurde und was erlaubt ist, und in hint den Ausweg: step, die nächstgröbere Schrittweite, die passt, und max_days, den längsten Zeitraum, der in der angefragten Schrittweite passt. Fragen Sie zuerst die Schätzung, wenn Sie Anfragen in einem Skript zusammenstellen; ihr per_step listet die Größe für jede Schrittweite.

Wenn weder eine gröbere Schrittweite noch ein kürzerer Zeitraum das ist, was Sie möchten, teilen Sie den Export auf:

Manche Metriken werden für jeden Tag aus mehreren Quellen ermittelt, allen voran plant.production_reported (Produktion, aufgelöst). Sie brauchen in jeder Schrittweite deutlich mehr Lesezugriffe auf den Messdatenspeicher als ein Zählerstand. Eine Anfrage oder eine Vorlage, die eine solche Metrik enthält, erreicht derzeit etwa neun Anlagenmonate: eine Anlage über neun Monate oder neun Anlagen über einen Monat. Eine Schrittweite von einer Woche oder länger weitet den Zeitraum auf ganze Intervalle aus, und der ausgeweitete Zeitraum zählt. Teilen Sie solche Exporte nach Zeit oder nach Anlage auf, oder exportieren Sie die Metrik in einer eigenen Anfrage.

429 busy und 429 rate_limited tragen den Header Retry-After mit den Sekunden, die zu warten sind.

Fehler

Ein Fehler der Routen dieser Seite hat diese Form:

{
  "detail": {
    "code": "step_not_served",
    "message": "The step is not served by every requested metric.",
    "params": {"step": "1h", "metrics": {"plant.grid_power": ["1min", "5min", "15min"]}},
    "hint": {"offered_common": ["1min", "5min", "15min"]}
  }
}

code ist stabil und für Programme gedacht. message ist ein englischer Text für Menschen. params sagt, was falsch war, hint, was funktionieren würde.

401 bedeutet, dass das Token fehlt, abgelaufen oder widerrufen ist.

IDs des bisherigen Exports

Der Parameter metrics akzeptiert auch die IDs des bisherigen Exports, etwa energy_grid_daily oder raw_grid_power. Eine ID mit Entsprechung wird in ihre Metrik übersetzt, in dem Wertemodus, der der bisherigen Zahl am nächsten kommt, und der Hinweis legacy_id_mapped sagt, welche Metrik geantwortet hat und ob die Zahl dieselbe ist (exact) oder dieselbe Größe auf bessere Weise gelesen wird (approximate).

Eine ID ohne Entsprechung antwortet mit 400 legacy_metric_id. hint.reason sagt, warum, hint.closest nennt die nächstliegende Metrik, sofern es eine gibt, hint.pending nennt die Metrik, die sie künftig tragen soll, und legacy_url ist der Link des bisherigen Exports, der die ID weiterhin liefert. Bei mehr Anlagen, als ein Link nennen kann, nennt legacy_url die erste Anlage, und params.legacy_url_scope ist first. Eine Komponenten-ID einer Batterie-Ebene hat keinen Link des bisherigen Exports; hint.legacy_route ist dann none. Der Leitfaden zum Umstieg listet jede ID.

Excel und Skripte

• Metric Export für Excel — Rezepte und die Power-Query-Verbindung mit dem Header Authorization
• Externer Berichtsgenerator — ein vollständiges Python-Beispiel

Verwandte Funktionen

• Metric Export — die Seite Daten-Export
• Umstieg auf den Metric Export — alte IDs, neue Metriken und was sich ändert
• Legacy-Export-API — die bisherigen Export-Links
• Metriken — eigene Metriken definieren und exportieren
• API-Tokens — das Token Metric Export erstellen
• API-Übersicht — die interaktive Referenz aller Routen