Auf dieser Seite

Korrekturen und erneute Zustellung bei Push-Kanälen

Speichern Sie, was ein Webhook oder eine MQTT-Verbindung liefert, dann schreiben Sie jeden Wert mit einem Upsert und nie mit einem einfachen Insert. Dasselbe Intervall kann mit besserer Qualität erneut eintreffen, und eine zweite Kopie eines bereits vorhandenen Werts muss diesen ersetzen. Dieser Artikel beschreibt, wann das passiert und welchen Schlüssel Sie dafür verwenden.

Warum ein Wert erneut eintrifft

Netzbetreiber verbessern Werte nachträglich. Ein Wert, der zuerst als unzuverlässiger Schätzwert (L3) ankommt, wird durch einen zuverlässigen (L2 oder L1) ersetzt; der Netzbetreiber hat dafür 60 Tage Zeit. Trifft der Ersatz ein, überschreibt er den gespeicherten Wert, und der korrigierte Datensatz wird an Ihre Verbindung erneut zugestellt. Die automatische Nachforderung fordert solche Ersatzwerte beim Netzbetreiber an und kann eine Korrektur dadurch früher bringen.

Ein Wert kann auch zweimal eintreffen, obwohl er sich nicht geändert hat:

  • Eine fehlgeschlagene Webhook-Zustellung wird wiederholt, und Ihr System hat den ersten Versuch womöglich schon gespeichert.
  • Sie können einen Zeitraum aus den Zustellprotokollen erneut senden, siehe Zustellprotokolle & Fehler.
  • MQTT-Nachrichten werden mit mindestens einmaliger Zustellung (At-least-once) veröffentlicht, ein Wiederholungsversuch von Broker oder Netzwerk kann also ein Duplikat erzeugen.

Der Schlüssel für den Upsert

Ein Wert ist durch drei Angaben bestimmt:

Teil Webhook MQTT
Zählpunkt smart_meter.metering_point_number Das von Ihnen konfigurierte Topic (EnerChart) oder das verbundene Gerät (ThingsBoard)
OBIS-Code obis_code jedes Datensatzes Das Topic (EnerChart) oder der Schlüssel in values (ThingsBoard)
Intervallbeginn timestamp jedes Datensatzes (UTC) ts der Nachricht

Eine Korrektur trägt dieselben drei Angaben wie das Original und einen anderen value oder data_quality. Das Beispiel verwendet erfundene Werte:

JSON
{ "obis_code": "1-1:1.9.0 P.01", "timestamp": "2025-03-15T23:00:00Z", "timestamp_end": "2025-03-15T23:15:00Z", "value": 0.31, "data_quality": 3, "unit": "kWh" }
JSON
{ "obis_code": "1-1:1.9.0 P.01", "timestamp": "2025-03-15T23:00:00Z", "timestamp_end": "2025-03-15T23:15:00Z", "value": 0.285, "data_quality": 1, "unit": "kWh" }

Beide Datensätze beschreiben dieselbe Viertelstunde. Der zweite ersetzt den ersten.

Was Sie mit jeder Lieferung tun

  1. Suchen Sie den Wert über den dreiteiligen Schlüssel.
  2. Gibt es ihn nicht, legen Sie ihn an.
  3. Gibt es ihn, ersetzen Sie value und data_quality durch die gelieferten Werte.

Die Plattform sendet geänderte Datensätze in der Reihenfolge, in der sie sich geändert haben. Wenden Sie die Lieferungen in der Reihenfolge des Eintreffens an, bleibt daher die neueste Fassung stehen. Kann Ihre Pipeline Nachrichten in anderer Reihenfolge verarbeiten, ergänzen Sie eine Absicherung: Ersetzen Sie einen gespeicherten Wert nicht durch einen Wert schlechterer Qualität, also mit höherer Zahl in data_quality. Dieselbe Regel wenden wir auf unsere eigenen Daten an, dort überschreibt ein erneut eingespieltes L3 nie ein gespeichertes L1 oder L2.

Weil Duplikate möglich sind, muss der Schreibvorgang idempotent sein. Ein Upsert ist das bereits.

Besonderheiten je Kanal

  • Webhook. Eine Korrektur ist eine normale Zustellung. Das Ereignis bleibt measurement.created, und nichts im Payload kennzeichnet einen Datensatz als korrigiert, der Schlüssel ist also die einzige Möglichkeit, ihn zu erkennen. data_quality steht in jedem Datensatz: 1 gemessen, 2 geschätzt, 3 unzuverlässig.
  • MQTT. Die Payloads für ThingsBoard und EnerChart enthalten nur Wert und Zeitstempel, kein Qualitätsfeld. Ein korrigierter Wert kommt als weitere Nachricht für denselben Zeitstempel, und die spätere Nachricht ersetzt die frühere. Prüfen Sie, wie Ihr Zielsystem einen wiederholten Zeitstempel für dieselbe Reihe behandelt.
  • CSV per E-Mail und SFTP. Diese Dateien entstehen aus denselben Änderungen, eine Datei kann also Werte enthalten, die Sie schon früher erhalten haben, nun mit besseren Zahlen.

Grenzen

  • Eine Korrektur wird zugestellt, wenn sich der gespeicherte value oder data_quality wirklich geändert hat. Ein wiederholter identischer Wert zählt nicht als Änderung.
  • Korrekturen für Intervalle, die älter sind als die Datenaufbewahrung Ihres Plans, werden nicht zugestellt.
  • Die Lieferungen betreffen die eigene Reihe des Zählers. Die gesonderten Werte je Energiegemeinschaft gehören nicht dazu.
  • Eine Korrektur kommt nach dem Zeitplan der Verbindung, zusammen mit dem nächsten Paket.

Wenn Sie lieber abrufen, liefert die REST-API dieselben Fassungen über ihren Cursor.