Data Connectors · Wetter

Nivus Regenschreiber

Der Node liest die kumulierte Füllhöhe von Nivus-Regenschreibern über die Nivus DataKiosk API, berechnet daraus den Niederschlag seit der letzten Messung und gibt je Station ein WeatherObserved- und ein WaterObserved-Objekt aus. Stationen wählen Sie in einer Doppelliste aus, die der Node direkt aus der API befüllt.

Datenquelle
Triggerbasiert
API-Schlüssel

Node-Typ: nivus-rainfall
Paket: @htag/node-red-contrib-hypertegrity-weather
Eingänge / Ausgänge: 1 / 2
Datenquelle: Nivus DataKiosk API (datakiosk-api.nivusweb.com/api/v2)

Wofür Sie den Node verwenden

Regenschreiber von Nivus erfassen Niederschlag als kumulierte Füllhöhe eines Sammelbehälters und übertragen ihre Messwerte in das Nivus-Portal. Die DataKiosk API stellt diese Werte bereit. Der Nivus-Regenschreiber-Node übernimmt die Authentifizierung, das Zusammenführen von Stammdaten und aktuellen Werten sowie die Umrechnung in Niederschlag je Messintervall.

Typische Einsatzfälle sind:

Lokale Niederschlagsmessung aus dem eigenen Sensornetz in einen NGSI-LD Context Broker übernehmen.
Starkregen-Monitoring für Kanalnetz, Hochwasserschutz oder Bauhof mit stündlichen Niederschlagswerten.
Füllstände der Sammelbehälter überwachen, um Wartung und Entleerung zu planen.

So funktioniert der Node

Auslösen

Eine eingehende Nachricht startet den Durchlauf. Ohne Eingangsnachricht erzeugt der Node keine Ausgabe.

Stammdaten laden

Über GET /stations und GET /stations/{Id} ermittelt der Node Name, GPS-Position und den Wert-Kanal jeder Station und legt sie im Node-Kontext ab.

Werte abrufen

Über POST /channels/curdata holt der Node die aktuellen Kanalwerte, verwirft Platzhalterwerte und verknüpft den Rest mit den Stammdaten.

Niederschlag berechnen und ausgeben

Die Differenz der Füllhöhe zur vorherigen Gerätemessung ergibt den Niederschlag. Ausgang 1 erhält WeatherObserved, Ausgang 2 WaterObserved.

Ergebnis: Je Station ein Niederschlags- und ein Füllhöhenobjekt mit Geoposition, als Array oder als Einzelnachrichten.

Der Node ist triggerbasiert. Jede Eingangsnachricht schreibt zunächst den Stammdaten-Cache neu und ruft dann die aktuellen Werte ab. Zusätzlich kann der Node den Cache in einem festen Intervall und beim Start vorwärmen; diese Läufe erzeugen keine Ausgabe.

Der Niederschlag ist die Zunahme der kumulierten Füllhöhe zwischen zwei unterschiedlichen Gerätemessungen, erkannt am Zeitstempel CurValueTS. Beim ersten Abruf einer Station ist der Wert 0. Lösen Sie den Node mehrfach aus, ohne dass eine neue Messung vorliegt, wird der zuletzt berechnete Wert erneut ausgegeben und die Bezugshöhe bleibt erhalten. Negative Differenzen durch Behälterentleerung oder Zählerüberlauf werden auf 0 begrenzt.

Konfiguration

Der Bearbeitungsdialog ist in vier Registerkarten unterteilt.

Registerkarte „Allgemein“

Feld	Typ	Standard	Bedeutung
Name	Text	leer	Anzeigename des Nodes im Flow.
Nachrichtenformat (`messageFormat`)	Auswahl	`Eine Nachricht (Array)`	`Eine Nachricht (Array)`: je Ausgang eine Nachricht mit allen Entitäten als Array. `Eine Nachricht pro Station`: je Station und Ausgang eine eigene Nachricht.

Registerkarte „Stationen“

Feld	Typ	Standard	Bedeutung
Verfügbare Stationen / Ausgewählte Stationen (`stations`)	Doppelliste	leer	Beschränkt den Abruf auf die rechte Liste. Ohne Auswahl werden alle Stationen der API abgefragt. „Neu laden“ holt die Stationsliste erneut über die API, „Auswahl leeren“ entfernt alle Einträge. Das Suchfeld filtert die linke Liste.

Die Stationsliste lädt der Editor über das Node-RED-Backend mit dem gespeicherten API-Schlüssel beziehungsweise der Umgebungsvariable API_KEY. Dafür ist nach dem Eintragen eines neuen Schlüssels gegebenenfalls ein Deploy nötig.

Registerkarte „Authentifizierung“

Feld	Typ	Standard	Bedeutung
API Key (`apiKey`)	Credential (Passwort)	leer	Wird als HTTP-Header `X-API-Key` gesendet. Leer lassen, um die Umgebungsvariable `API_KEY` des Node-RED-Prozesses zu verwenden.

Registerkarte „Erweitert“

Feld	Typ	Standard	Bedeutung
API Basis-URL	Text, Pflichtfeld	siehe unten	Basis aller API-Aufrufe. Gespeichert als `apiBase`.
Wert-Kanal	Text, Pflichtfeld	`in1_val`	Kanal, dessen `Name` oder `ExchangeName` die Messwerte liefert. Stationen ohne diesen Kanal werden übersprungen. Gespeichert als `channelName`.
Cache-Intervall (Min.)	Zahl	`120`	Periodisches Neuschreiben des Stammdaten-Caches in Minuten. `0` = nur bei Eingangsnachricht. Erzeugt keine Ausgabe. Gespeichert als `cacheInterval`.
Cache beim Start laden	Kontrollkästchen	aktiv	Wärmt den Cache etwa zwei Sekunden nach Deploy oder Start vor. Erzeugt keine Ausgabe. Gespeichert als `fetchOnStartup`.
Timeout (Sek.)	Zahl	`60`	HTTP-Timeout je Anfrage. Gespeichert als `requestTimeout`.
WeatherObserved-Typ	Text, Pflichtfeld	`WeatherObserved`	Entitätstyp für Ausgang 1. Gespeichert als `weatherType`.
WaterObserved-Typ	Text, Pflichtfeld	`WaterObserved`	Entitätstyp für Ausgang 2. Gespeichert als `waterType`.
ID-Präfix	Text	`urn:ngsi-ld:`	Die Entitäts-ID entsteht aus Präfix, Typ, Doppelpunkt und Stations-ID (siehe Beispiel unter Ausgang 1). Gespeichert als `idPrefix`.
Debug-Modus	Kontrollkästchen	inaktiv	Gibt detaillierte Protokolle mit dem Präfix `[Nivus]` als Warnungen in der Debug-Seitenleiste aus. Gespeichert als `debug`.

Standardwerte der URL-Felder:

API Basis-URL: https://datakiosk-api.nivusweb.com/api/v2

API-Schlüssel beziehen

Der Schlüssel für die DataKiosk API gehört zu Ihrem Nivus-Kundenkonto. Wenden Sie sich an Ihren Nivus-Ansprechpartner oder den Nivus-Support, um den Zugang zur DataKiosk API freischalten zu lassen. Kontingente und Nutzungsbedingungen ergeben sich aus Ihrem Vertrag mit Nivus; der Node selbst setzt keine Limits.

Eingang

Der Eingang dient als Auslöser. Der Inhalt der Nachricht wird nicht ausgewertet; ihre Eigenschaften werden jedoch in die Ausgangsnachrichten übernommen, soweit sie nicht von payload, topic oder nivus überschrieben werden.

Eigenschaft	Typ	Bedeutung
`msg`	beliebig	Jede Nachricht startet Stammdaten-Abgleich und Werteabruf. Läuft bereits ein Werteabruf, wird der neue Durchlauf übersprungen.

Ausgang

Alle Attribute werden flach ausgegeben; nur location ist als NGSI-LD-GeoProperty strukturiert, wie es der Stellio Context Broker erwartet. Die Objekte können an den NGSI-LD Builder übergeben werden.

Ausgang 1: WeatherObserved

Im Array-Modus ein Array aller Stationen mit msg.topic = "WeatherObserved", im Einzelmodus je Station eine Nachricht mit msg.topic = Entitäts-ID.

[
  {
    "id": "urn:ngsi-ld:WeatherObserved:123",
    "type": "WeatherObserved",
    "name": "Regenschreiber Kläranlage",
    "alternateName": "in1_val",
    "location": {"type": "GeoProperty", "value": {"type": "Point", "coordinates": [7.77, 49.44]}},
    "dateObserved": "2026-10-01T08:00:12.000Z",
    "precipitation": 1.4,
    "nivusHeight": 238.6
  }
]

Feld	Bedeutung
`id`	ID-Präfix + WeatherObserved-Typ + `:` + Stations-ID.
`type`	Der konfigurierte WeatherObserved-Typ.
`name`	Stationsname aus der API.
`alternateName`	Name des Wert-Kanals (`Channel.Name`).
`location`	GeoProperty mit GeoJSON-Punkt `[Länge, Breite]` aus den GPS-Daten der Station.
`dateObserved`	Zeitpunkt des Abrufs im ISO-8601-Format.
`precipitation`	Niederschlag seit der vorherigen Gerätemessung, zwei Nachkommastellen, in der Einheit des Kanals nach Anwendung von `Unit.Factor` (bei Regenschreibern mm).
`nivusHeight`	Rohwert `CurValue` des Sensors ohne Umrechnung.

Ausgang 2: WaterObserved

Im Array-Modus ein Array aller Stationen mit msg.topic = "WaterObserved", im Einzelmodus je Station eine Nachricht mit msg.topic = Entitäts-ID.

[
  {
    "id": "urn:ngsi-ld:WaterObserved:123",
    "type": "WaterObserved",
    "name": "Regenschreiber Kläranlage",
    "alternateName": "in1_val",
    "location": {"type": "GeoProperty", "value": {"type": "Point", "coordinates": [7.77, 49.44]}},
    "dateObserved": "2026-10-01T07:55:00.000Z",
    "height": 238.6,
    "waterLevel": 1.4
  }
]

Feld	Bedeutung
`id`	ID-Präfix + WaterObserved-Typ + `:` + Stations-ID.
`type`	Der konfigurierte WaterObserved-Typ.
`name`, `alternateName`, `location`	Wie bei Ausgang 1.
`dateObserved`	Zeitstempel der Gerätemessung (`CurValueTS`).
`height`	Kumulierte Füllhöhe `CurValue × Unit.Factor`, zwei Nachkommastellen.
`waterLevel`	Änderung der Füllhöhe seit der vorherigen Messung, identisch mit `precipitation`.

Zusätzliche Nachrichteneigenschaften

Eigenschaft	Bedeutung
`msg.nivus`	Metadaten zum Abruf: `source` (`Nivus DataKiosk API`), `apiBase`, `channelName`, `retrievedAt`, `stationCount` und `containsPersonalData: false`.
`msg.topic`	Im Array-Modus der Entitätstyp, im Einzelmodus die Entitäts-ID.

Beispiel-Flow

Das Paket bringt einen Beispiel-Flow mit. Sie importieren ihn in Node-RED über Menü → Importieren → Beispiele → @htag/node-red-contrib-hypertegrity-weather → nivus. Alternativ laden Sie die Datei nivus.json herunter und importieren sie über Menü → Importieren.

Schritt 1

Inject

Ein Inject-Node löst den Abruf manuell oder in einem festen Intervall aus, passend zur Messrate der Geräte.

Schritt 2