Pegelstände · 1 von 5

Datenquellen prüfen

Vor dem Flow wird für jede Quelle nachgewiesen, dass sie erreichbar ist und eine bekannte Messstelle mit Kennung, Messzeit und Pegelwert liefert.

Die Referenz verbindet drei unterschiedliche Quellen: die OAuth-geschützte Hersteller-API von Endress+Hauser, das Messwertarchiv mit Stationsstammdaten des LANUK NRW und den öffentlichen MQTT-Datenstrom von iot.hamburg.de. Wählen Sie den Quellenweg, den Sie prüfen möchten.

Was bei jeder Probe sichtbar sein muss

Die konkreten Werkzeuge unterscheiden sich, der fachliche Nachweis bleibt gleich:

• Die erwartete Ressource ist über den vorgesehenen Zugriffsweg erreichbar.
• Eine ungefährliche Probe liefert eine bekannte Messstelle statt nur einen erfolgreichen Statuscode.
• Stationskennung, Messzeitpunkt und Messwert lassen sich eindeutig erkennen.
• Einheit und Lagebezug sind bekannt oder können aus Stationsstammdaten ergänzt werden.
• Es ist geklärt, ob die Quelle regelmäßig abgefragt wird oder Nachrichten selbst sendet.

Die allgemeine Anleitung Datenquelle prüfen erklärt die verwendeten Testwerkzeuge, ihre Installation und den sicheren Umgang mit Zugängen. Hier werden diese Werkzeuge nur noch auf die drei konkreten Pegelquellen angewendet.

Quelle auswählen und prüfen

Endress+Hauser

OAuth-geschützte Hersteller-API · neun Sensoren konfiguriert · acht für das Dashboard ausgewählt

Die Referenz enthält keinen öffentlichen API-Pfad und keine OAuth-Clientdaten. Verwenden Sie deshalb die vom Betreiber übergebene vollständige Sensor-URL für eine bekannte Messstelle – beispielsweise Sensor 1927402 – und ein kurzlebiges Access Token. URL und Token werden interaktiv eingelesen und erscheinen dadurch nicht als Klartext im Befehl:

Bekannten E+H-Sensor mit curl abrufen

read -r -p 'Vollständige Sensor-URL: ' E_H_SENSOR_URL
read -r -s -p 'Kurzlebiges OAuth-Token: ' ACCESS_TOKEN
printf '\n'

curl --silent --show-error --fail-with-body \
  "$E_H_SENSOR_URL" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header 'Accept: application/json' \
  --write-out '\nHTTP %{http_code}\n'

unset ACCESS_TOKEN E_H_SENSOR_URL

Die Antwort muss zur angefragten Messstelle gehören und mindestens den gemessenen Abstand distance, den abgeleiteten Pegelstand level sowie einen Messzeitpunkt enthalten. Die tatsächliche JSON-Struktur richtet sich nach dem bereitgestellten Hersteller-Endpunkt; Feldnamen werden erst beim späteren Mapping in measuredDistance, waterLevel und dateObserved überführt.

Die Hersteller-API ist geprüft, wenn

der begrenzte Abruf mit HTTP 200 endet und die Antwort Sensor 1927402, Messzeit, Distanz und Pegelwert eindeutig erkennen lässt. Ein erfolgreicher Status ohne fachliche Messwerte reicht nicht.

Für Installation, Optionen und Authentifizierungsgrenzen verwenden Sie den Tab HTTP-API in „Datenquelle prüfen“.

LANUK NRW

ZIP-Messwertarchiv und stations.json · drei ausgewählte Stationen · Abruf alle 300 Sekunden

Der LANUK-Weg benötigt zwei öffentliche Ressourcen: das ZIP-Archiv mit Messwerten und stations.json mit den Stationsstammdaten. Der folgende Test lädt beide Dateien, kontrolliert das ZIP und sucht anschließend die Referenzstation 2729100000100 in beiden Beständen:

LANUK-Messwert und Stammdaten gemeinsam prüfen

pegel_test_dir="$(mktemp -d)"

curl --silent --show-error --fail-with-body \
  'https://www.hochwasserportal.nrw/data/downloads/messwerte.zip' \
  --output "$pegel_test_dir/messwerte.zip"

curl --silent --show-error --fail-with-body \
  'https://www.hochwasserportal.nrw/data/internet/stations/stations.json' \
  --output "$pegel_test_dir/stations.json"

unzip -t "$pegel_test_dir/messwerte.zip"

unzip -p "$pegel_test_dir/messwerte.zip" messwerte.txt \
  | awk -F';' \
      '$1 == "2729100000100" && $2 != "" && $3 != "" { latest=$0 }
       END { if (latest) print latest; else exit 1 }'

jq -r \
  '.[]
   | select(.station_no == "2729100000100")
   | [.station_no, .station_name, .station_latitude, .station_longitude]
   | @tsv' \
  "$pegel_test_dir/stations.json"

printf 'Testdateien: %s\n' "$pegel_test_dir"

Der konkrete Messwert und sein Zeitstempel ändern sich. Entscheidend ist, dass die erste Ausgabe eine nicht leere Zeile mit Stationsnummer, Messzeit und Wert in Zentimetern liefert. Die zweite Ausgabe muss dieselbe Stationsnummer mit Menden_1 und ihren Koordinaten zeigen:

Erwartete Struktur der Ausgaben

2729100000100;<aktueller Messzeitpunkt>;<Pegelwert in cm>
2729100000100  Menden_1  50.7978982508198  7.15914416477298

Die LANUK-Quelle ist geprüft, wenn

beide Downloads erfolgreich sind, messwerte.zip fehlerfrei geöffnet wird und die Stationsnummer 2729100000100 sowohl einem nicht leeren Messwert als auch den Stammdaten von Menden_1 zugeordnet werden kann.

curl wird in der allgemeinen HTTP-Prüfung eingeführt. Die Auswertung verwendet zusätzlich unzip, awk und jq; fehlen diese Werkzeuge, lassen Sie den Test in einer dafür vorgesehenen Arbeitsumgebung ausführen, statt die Downloads nur anhand ihres HTTP-Status freizugeben.

MQTT

Öffentlicher Ereignisstrom von iot.hamburg.de · Topic v1.0/Observations · Port 1883

Der öffentliche Broker kann ohne Zugangsdaten mit mosquitto_sub beobachtet werden. Der Test endet nach der ersten neuen Nachricht oder spätestens nach 30 Sekunden:

Eine neue SensorThings-Beobachtung empfangen

mosquitto_sub \
  --host iot.hamburg.de \
  --port 1883 \
  --topic 'v1.0/Observations' \
  --qos 0 \
  --protocol-version mqttv311 \
  -R \
  -C 1 \
  -W 30 \
  -v

Die Ausgabe besteht aus Topic und JSON-Payload. In der Beobachtung müssen mindestens ein Messwert, ein Beobachtungszeitpunkt und eine SensorThings-Beziehung zur Messreihe erkennbar sein – typischerweise über result, phenomenonTime und Datastream@iot.navigationLink. Eine Stationskennung oder Geometrie kann erst über die verknüpften SensorThings-Ressourcen aufgelöst werden und muss nicht vollständig in derselben MQTT-Nachricht stehen.

Die MQTT-Quelle ist geprüft, wenn

innerhalb des abgestimmten Beobachtungsfensters eine neue JSON-Nachricht aus v1.0/Observations empfangen und Messwert, Messzeit sowie Datastream-Bezug erkannt werden. Ein Timeout belegt nicht automatisch einen Fehler; bei einem unregelmäßigen öffentlichen Datenstrom muss der Test später wiederholt werden.

Installation und Bedeutung der Optionen sind im Tab MQTT in „Datenquelle prüfen“ sowie in der dort verlinkten offiziellen mosquitto_sub-Dokumentation beschrieben.

Der öffentliche MQTT-Zweig ist ein Demonstrationsweg

Der dokumentierte Brokerzugang verwendet Port 1883 ohne TLS und QoS 0. Das reicht für die Demonstration eines Push-Wegs, ist aber kein Produktionsmuster. Ein produktiver Zugang benötigt einen freigegebenen Broker, TLS, technische Credentials, Topic-Rechte und eine abgestimmte Behandlung möglicher Nachrichtenverluste.

Nächster Schritt

Sind die drei Proben nachvollziehbar, werden Laden, Verarbeitung und Speicherung im vollständigen Node-RED-Flow umgesetzt: Datenfluss umsetzen.