Zum Hauptinhalt springen
Pegelstände · 2 von 5

Daten laden, verarbeiten und speichern

Jeder Node-RED-Flow übernimmt eine geprüfte Quelle, bildet ihre Felder auf WaterObserved ab und schreibt die validierte Entität in denselben Stellio-Datenraum.

Der gemeinsame Aufbau​

1 · Laden

Quellwerte übernehmen

Inject und Quellknoten rufen Polling-Quellen ab; der MQTT-Knoten reagiert direkt auf neue Nachrichten.

2 · Verarbeiten

Auf WaterObserved abbilden

ngsi-builder vereinheitlicht Kennung, Messzeit, Pegelwert, Lage und Herkunft und validiert die Entität.

3 · Speichern

Nach Stellio schreiben

post-to-stellio führt den aktuellen Zustand im Tenant ds_environment.

4 · Historisieren

Zeitreihe fortschreiben

Eine Subscription übergibt neue Messzeitpunkte an QuantumLeap und TimescaleDB.

Quell-Flow auswählen​

Die Abbildungen zeigen jeweils den vollständigen Weg vom Eingang bis Stellio. Wählen Sie die Quelle, deren Flow Sie nachvollziehen möchten.

Ein Inject-Knoten startet den Abruf alle 300 Sekunden. Der projektspezifische Quellknoten liest neun konfigurierte Sensoren. ngsi-builder erzeugt daraus WaterObserved-Entitäten; post-to-stellio schreibt sie nach ds_environment.

Node-RED-Flow mit Inject-Knoten, Endress-und-Hauser-Quellknoten, NGSI Builder, post-to-stellio und zwei Debug-Ausgaben.
Vollständiger Polling-Flow für die Endress+Hauser-Sensoren. Im gezeigten Lauf wurden neun Sensoren gelesen.
Ablauf im Flow
Inject alle 300 s → E+H Floodmonitoring → ngsi-builder → post-to-stellio

Der Quellknoten liefert unter anderem gemessene Distanz, abgeleiteten Pegelstand, Messzeit und die im Knoten gepflegte Sensorlage. Acht der neun Sensoren werden im Dashboard verwendet.

Projektknoten vor einer Wiederverwendung prüfen

Die Screenshots dokumentieren die im Projekt eingesetzten Quellknoten. Sie sind nicht automatisch Teil jeder Node-RED-Instanz oder der veröffentlichten HYPERTEGRITY-Bibliothek. Fehlt ein benötigter Knoten in der Palette, lassen Sie ihn durch die Administration geprüft und versioniert bereitstellen.

Einen gemeinsamen WaterObserved-Vertrag bilden​

WaterObserved beschreibt neutral eine Beobachtung an einem Gewässer. FloodMonitoring enthält bereits Bewertungslogik. Deshalb werden Melde- und Hochwasserschwellen nicht in den gespeicherten Messwert eingerechnet, sondern erst bei Dashboard und Alerting angewendet.

Identität

Messstelle eindeutig halten

Die Quellkennung wird zu einer dauerhaften NGSI-LD-URN und später als entity_id historisiert.

Messwert

Pegelstand vereinheitlichen

currentLevel wird als numerischer waterLevel in Zentimetern geführt und als waterlevel historisiert.

Messzeit

Quellzeit erhalten

dateObserved oder observationDateTime wird zu dateObserved und später zu dateobserved.

Geometrie

Lage vereinheitlichen

Die Position wird als GeoJSON Point in der Reihenfolge Längengrad, Breitengrad gespeichert.

Sensorabstand

Messhöhe erhalten

measuredDistance wird – sofern geliefert – als height übernommen.

Herkunft

Quelle nachvollziehbar machen

source kennzeichnet die tatsächliche Herkunft, insbesondere bei den LANUK-Daten.

Der ngsi-builder übernimmt die Feldabbildung und validiert die erzeugte Entität. Ein kurzer Transformationsschritt setzt den gemeinsamen Zieltyp:

Gemeinsamen Entitätstyp setzen
entity.type.value = 'WaterObserved';

Vor post-to-stellio müssen mindestens diese Regeln erfüllt sein:

  • id ist eine stabile URN und ändert sich nicht bei jedem Abruf.
  • dateObserved enthält den fachlichen Messzeitpunkt der Quelle.
  • waterLevel ist eine endliche Zahl in der vereinbarten Einheit Zentimeter.
  • Koordinaten besitzen die Reihenfolge Längengrad, Breitengrad.
  • ungültige Entitäten laufen in einen Fehlerpfad und werden nicht an Stellio übergeben.
Rohentität und Zielentität unterscheiden

Einzelne Rohdaten und ältere Flow-Konfigurationen verwenden noch FloodMonitoring. Der verbindliche Ausgang des gemeinsamen Flows ist WaterObserved. ID-Regel und erreichbarer JSON-LD-Context müssen vor der Übernahme in einen weiteren Datenraum eindeutig festgelegt sein.

Aktuellen Zustand und Messhistorie speichern​

post-to-stellio führt jede validierte Entität im Tenant ds_environment. Die stabile Entity-ID sorgt dafür, dass ein neuer Messwert denselben fachlichen Zustand aktualisiert, statt eine neue Messstelle anzulegen.

Eine einmalig angelegte Subscription beobachtet dateObserved. Ändert sich dieser Wert, benachrichtigt Stellio QuantumLeap unter /v2/notify. QuantumLeap schreibt den neuen Messpunkt nach mtds_environment.etwaterobserved.

Aktueller Zustand

Stellio

Führt die aktuelle WaterObserved-Entität im Datenraum ds_environment.

Auslöser

Subscription

Reagiert auf einen neuen fachlichen Messzeitpunkt in dateObserved.

Historie

QuantumLeap

Schreibt die Zeitreihe in das tenantbezogene TimescaleDB-Schema.

Zeitachse

dateobserved

Bleibt die fachliche Messzeit; time_index beschreibt nur die spätere Plattformübernahme.

Messzeit und Eingangszeit nicht vertauschen

Nachgelieferte Werte können fast gleichzeitig in der Plattform eintreffen, obwohl ihre Messzeitpunkte auseinanderliegen. Ganglinien und fachliche Auswertungen verwenden deshalb dateobserved statt time_index.

Numerischen Typ dauerhaft absichern​

Im Projekt wurde waterlevel durch QuantumLeap nach einem ganzzahligen Erstwert zunächst als bigint angelegt. Stellio hatte mit dem späteren Dezimalwert kein Problem; erst die Historisierung von 31.84 scheiterte an der zu engen TimescaleDB-Spalte. Die Spalte wurde auf double precision geändert. Diagnose, Wartungsgrenzen und SQL-Korrektur beschreibt die Hilfe unter QuantumLeap: Dezimalwert kann nicht gespeichert werden. Dashboard-Abfragen casten den Wert zusätzlich defensiv:

Zeitreihe für die Auswertung lesen
SELECT
  $__time(w.dateobserved),
  w.waterlevel::double precision AS waterlevel,
  w.source
FROM mtds_environment.etwaterobserved AS w
WHERE $__timeFilter(w.dateobserved)
  AND w.waterlevel IS NOT NULL
ORDER BY w.dateobserved;

Fehlgeschlagene Übernahmen können in __original_ngsi_entity__ sichtbar werden. Diese Spalte dient der Fehleranalyse und nicht der normalen Fachabfrage.

Nächster Schritt​

Nach dem vollständigen Flow werden aktuelle Entität und historische Zeitreihe kontrolliert: Daten prüfen.

Weiterführende Referenzen​

Die folgenden Seiten vertiefen einzelne Teile des beschriebenen Flows. Sie sind keine weiteren Schritte der Referenzimplementierung.