Energiedaten verstehen

Dieses Tutorial wendet die Abfragetechniken aus Tutorial 2 auf eine echte Fachdomäne an: eine Erneuerbare-Energie-Gemeinschaft, in der die Mitglieder den selbst erzeugten Strom teilen. Sie erkunden die Stammdaten einer Gemeinschaft, finden die Zeitreihen eines Zählpunkts, lernen die Bedeutung der Zählerregister kennen und berechnen die Kennzahlen, die beschreiben, wie gut die Gemeinschaft funktioniert.

Sie benötigen einen Tenant, in dem die EnergyCommunity-Lösung installiert ist (Blueprint EnergyCommunity.Base) und der Daten enthält, zum Beispiel eine simulierte Demo-Gemeinschaft. Den Hintergrund beschreibt der Use Case Energiegemeinschaften; dieses Tutorial verweist unterwegs auf die passenden Abschnitte.

Zeitbedarf: etwa 60 Minuten.

Die Fragen hinter den Daten

Eine Energiegemeinschaft muss jeden Tag einige Fragen beantworten:

Wer sind die Mitglieder, und welche Zählpunkte bringen sie ein?
Wie viel hat jedes Mitglied in jeder Viertelstunde verbraucht und erzeugt?
Wie viel des Verbrauchs konnte durch die eigene Erzeugung der Gemeinschaft gedeckt werden, und wie viel blieb übrig?
Wie verlässlich sind diese Zahlen: gemessen, interpoliert oder geschätzt?

Jede Frage entspricht einem Teil des OctoMesh-Modells.

Schritt 1: Mitglieder, Anlagen, Zählpunkte

Die Stammdaten bilden einen Baum: Kunde → Anlage (Operating Facility) → Zählpunkt (Verbraucher oder Erzeuger). Lesen Sie zuerst das Datenmodell und fragen Sie es dann ab:

query Members {
  runtime {
    energyCommunityCustomer(first: 20) {
      totalCount
      items {
        customerNumber
        contact { firstName lastName companyName }
        facilities(ckTypeIds: ["Basic.Energy/OperatingFacility"]) {
          items {
            ... on BasicEnergyOperatingFacility {
              name
              children(ckTypeIds: ["EnergyCommunity/Consumer", "EnergyCommunity/Producer"]) {
                items {
                  ... on EnergyCommunityConsumer {
                    rtId ckTypeId meteringPointNumber partitionFactor meteringDataSource
                  }
                  ... on EnergyCommunityProducer {
                    rtId ckTypeId meteringPointNumber partitionFactor productionType
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Worauf Sie achten sollten:

partitionFactor ist ein Prozentwert. 100 bedeutet, dass der Zählpunkt vollständig an dieser Gemeinschaft teilnimmt.
meteringDataSource gibt an, woher die Werte stammen: EDA (der Netzbetreiber), SIMULATED oder SELF_REPORTED.
Zählen Sie Verbraucher und Erzeuger. Das Verhältnis von Verbrauch zu installierter Erzeugung bestimmt weitgehend, wie sich eine Gemeinschaft verhält.

Übung: Notieren Sie die rtId eines Verbrauchers und eines Erzeugers.

Schritt 2: Vom Zählpunkt zu seiner Zeitreihe

Ein Zählpunkt speichert selbst keine Werte. Für jedes Register hat er eine Kind-Entität vom Typ Basic.Energy/EnergyMeasurement, den Anker einer Zeitreihe. Dessen rtId übergeben Sie an Stream-Data-Abfragen:

query Anchors($meteringPoint: OctoObjectId!) {
  runtime {
    energyCommunityConsumer(rtId: $meteringPoint) {
      items {
        meteringPointNumber
        children(ckTypeIds: ["Basic.Energy/EnergyMeasurement"]) {
          items {
            ... on BasicEnergyEnergyMeasurement { rtId rtWellKnownName obisCode }
          }
        }
      }
    }
  }
}

Ein Verbraucher hat typischerweise zwei Anker, 1-1:1.9.0 G.01 und 1-1:2.9.0 G.03; ein Erzeuger hat drei, 1-1:2.9.0 G.01, 1-1:2.9.0 G.01T und 1-1:2.9.0 P.01T. Die Tabelle unter Zählerregister erklärt jedes davon.

Sie können auch den umgekehrten Weg gehen und alle Anker eines Registers im Tenant auflisten:

query SelfCoverageAnchors {
  runtime {
    basicEnergyEnergyMeasurement(
      first: 500
      fieldFilter: [{ attributePath: "obisCode", operator: EQUALS, comparisonValue: "1-1:2.9.0 G.03" }]
    ) {
      totalCount
      items { rtId rtWellKnownName }
    }
  }
}

Schritt 3: Ein Tag in 15-Minuten-Slots

Strom wird in 15-Minuten-Slots abgerechnet: 96 pro Tag, 92 bzw. 100 an den Tagen der Zeitumstellung. Fragen Sie einen Tag des Verbrauchsankers Ihres Verbrauchers aus dem Rohdatenarchiv ab (die vollständige Abfrage finden Sie in Tutorial 2, Rohwerte):

archiveRtId: das Rohdatenarchiv der Gemeinschaft (im Studio unter Archives, üblicherweise mit dem Namen energy-measurements)
rtIds: der Anker von 1-1:1.9.0 G.01
from / to: lokale Mitternacht bis lokale Mitternacht in UTC, zum Beispiel 2026-10-05T22:00:00Z bis 2026-10-06T22:00:00Z für den 6. Oktober (Sommerzeit)

Führen Sie anschließend dieselbe Abfrage für den Anker 1-1:2.9.0 G.01 des Erzeugers aus.

Übung: Stellen Sie beide Reihen über den Tag grafisch dar (jedes Werkzeug ist geeignet). Wann speist der Erzeuger ein, wann bezieht der Verbraucher am meisten? In welchen Slots könnte die Erzeugung des Erzeugers den Bedarf des Verbrauchers decken?

Jede Zeile enthält außerdem eine dataQuality. Lesen Sie Datenqualität, um zu verstehen, warum ein geschätzter Wert (L3) nie einen gemessenen (L1) überschreibt.

Schritt 4: Die tägliche Verteilung

Die Register G.03, G.01T und P.01T sind das Ergebnis der Verteilung: Für jeden Slot verteilt die Gemeinschaft, was ihre Erzeuger anbieten, auf die Verbraucher, die in diesem Slot Energie benötigen; der Rest ist Überschuss. Die Verteilung läuft einmal täglich für den Vortag (D+1). Die Regeln finden Sie unter Tägliche Verteilung.

Prüfen Sie die Bilanz selbst. Summieren Sie einen Tag je Register mit einer gruppierten Aggregation über das Rohdatenarchiv (Abfrage in Tutorial 2). Ein Beispielergebnis:

Register	kWh	Bedeutung
`1-1:1.9.0 G.01`	431.36	Verbrauch aller Verbraucher
`1-1:2.9.0 G.01`	474.27	Erzeugung aller Erzeuger
`1-1:2.9.0 G.01T`	474.01	der Gemeinschaft angebotene Erzeugung
`1-1:2.9.0 G.03`	207.63	aus der Gemeinschaft gedeckter Verbrauch
`1-1:2.9.0 P.01T`	266.38	angebotene, nicht verteilte Erzeugung

Die Bilanz geht auf: G.01T − P.01T = 474.01 − 266.38 = 207.63 = G.03. Beachten Sie, dass die Gemeinschaft über den Tag mehr erzeugt als verbraucht hat und trotzdem nur etwa die Hälfte ihres Verbrauchs gedeckt hat: Erzeugung und Verbrauch finden zu unterschiedlichen Tageszeiten statt, und geteilt werden kann nur Energie im selben Slot.

Übung: Wiederholen Sie die Aggregation für einen einzelnen Slot zu Mittag und einen einzelnen Slot am Abend. Wie verändern sich die Anteile?

Schritt 5: Kennzahlen

Zwei Quoten beschreiben eine Gemeinschaft über einen Zeitraum (siehe Kennzahlen):

Deckungsgrad = Σ 2.9.0 G.03 / Σ 1.9.0 G.01
Überschussquote = Σ P.01T / Σ G.01T

Für den Beispieltag oben: Deckungsgrad = 207.63 / 431.36 = 48 %, Überschussquote = 266.38 / 474.01 = 56 %.

Verwenden Sie für längere Zeiträume die Rollup-Archive statt des Rohdatenarchivs: Das monatliche Rollup enthält bereits die Monatssumme je Anker. Das Python-Skript in Tutorial 2, Schritt 6 berechnet beide Quoten je Monat:

month     consumption  self-cov.  coverage surplus %
2026-06       12940.8     7950.0     61.4%     61.7%
2026-07       13372.1     8093.9     60.5%     61.4%
2026-08       13372.1     7623.0     57.0%     60.2%
2026-09       12737.3     6720.7     52.8%     58.1%

Übungen:

Erweitern Sie das Skript auf ein ganzes Jahr. Wie verändern sich die Quoten zwischen Sommer und Winter, und warum?
Berechnen Sie die Quoten je Verbraucher statt für die ganze Gemeinschaft. Welche Mitglieder profitieren am meisten?
Der Überschuss ist Energie, die die Gemeinschaft verkaufen könnte. In welchen Stunden des Tages ist der Überschuss am größten? Verwenden Sie das stündliche Rollup.

Was Sie beachten sollten

Einheiten und Vorzeichen: Alle Werte sind kWh pro Slot und positiv; die Richtung steckt im OBIS-Code.
Zeitzone: Der Tag der Gemeinschaft ist der lokale Tag in Europe/Vienna. Die Archive speichern UTC.
Ausrichtung am Raster: Fragen Sie auf volle Viertelstunden (Rohdatenarchiv) bzw. lokale Mitternacht (tägliche und gröbere Rollups) ab, sonst werden teilweise erfasste Fenster voll gezählt.
Qualität: Ein Zeitraum mit L3-Werten enthält Schätzungen. Prüfen Sie die Spalte dataquality_max der Rollups, bevor Sie einer Summe vertrauen.
Vorläufig oder endgültig: Die Verteilung für Tag D ist erst nach dem Meldeschluss am Tag D+1 endgültig.

Zusammenfassung

Die Stammdaten bilden den Baum Kunde → Anlage → Zählpunkt; jeder Zählpunkt hat eine Anker-Entität pro Register.
Rohwerte sind 15-Minuten-Fenster in einem Time-Range-Archiv; Rollups liefern Summen von stündlich bis jährlich.
1.9.0 G.01 und 2.9.0 G.01 sind die Messwerte; G.03, G.01T und P.01T sind das, was die Verteilung daraus gemacht hat.
Deckungsgrad und Überschussquote fassen zusammen, wie gut eine Gemeinschaft ihre eigene Erzeugung nutzt.

Weiter: Lösungen mit KI über den MCP-Server bauen lässt einen KI-Assistenten diese Erkundung gemeinsam mit Ihnen durchführen.

Die Fragen hinter den Daten​

Schritt 1: Mitglieder, Anlagen, Zählpunkte​

Schritt 2: Vom Zählpunkt zu seiner Zeitreihe​

Schritt 3: Ein Tag in 15-Minuten-Slots​

Schritt 4: Die tägliche Verteilung​

Schritt 5: Kennzahlen​

Was Sie beachten sollten​

Zusammenfassung​