Data Operations · NGSI-LD und Stellio

NGSI-LD Builder

Der Node wandelt beliebige JSON-Objekte in normalisierte NGSI-LD-Entitäten um. Er lädt den JSON-LD-@context und das zugehörige Smart-Data-Model-Schema, bietet eine interaktive Feldzuordnung, erzeugt URN-IDs, erkennt GeoProperty und Relationship automatisch und kann das Ergebnis gegen das Schema validieren.

Transformation
Smart Data Models
NGSI-LD

Node-Typ: ngsi-builder
Paket: @htag/node-red-contrib-hypertegrity-ngsi-ld
Eingänge / Ausgänge: 1 / 1
Ziel: Stellio Context Broker (NGSI-LD)

Wofür Sie den Node verwenden

Die Data-Connector-Nodes der Bibliothek liefern flache Objekte, zum Beispiel ein NewsObserved- oder WeatherObserved-Objekt mit einfachen Schlüssel-Wert-Paaren. Ein NGSI-LD Context Broker wie Stellio erwartet dagegen die normalisierte NGSI-LD-Form: Jedes Attribut ist ein Objekt mit type (Property, GeoProperty oder Relationship), einem Wert und optional einem Zeitstempel observedAt. Der NGSI-LD Builder übernimmt genau diese Umformung und ergänzt die Entität um eine URN-ID und den @context.

Typische Einsatzfälle sind:

Connector-Ausgaben (RSS Feed, Wetter, Pegelstände, Parkplätze) in Smart-Data-Model-konforme Entitäten umformen und anschließend mit Post to Stellio veröffentlichen.
Fremde APIs oder CSV-Importe über das Beispiel-JSON und die interaktive Feldzuordnung schrittweise auf ein Datenmodell abbilden.
Geodaten aus getrennten Breiten- und Längengradfeldern oder aus Koordinaten-Arrays als GeoJSON-location erzeugen.
Datenqualität sichern, indem Pflichtfelder, Wertebereiche und Aufzählungen aus dem Schema geprüft werden, bevor die Daten den Broker erreichen.

So funktioniert der Node

Auslösen

Eine eingehende Nachricht startet die Verarbeitung. Ein optionaler Themenfilter lässt nur passende msg.topic-Werte durch.

ID bilden

Aus Entitätstyp, optionalem ID-Segment und der Eingangs-ID entsteht die URN. Die Entität erhält type und @context.

Zuordnen

Je nach Modus (Smart, Einfach, Benutzerdefiniert) werden Eingangsfelder zu Property, GeoProperty oder Relationship.

Anpassen

Standort-Analyse, Transformations-Skript, globale Felder und Überschreibungen ergänzen oder ändern die Entität.

Prüfen und senden

Optional wird die Entität gegen das Smart-Data-Model-Schema geprüft. Das Ergebnis verlässt den Node als Array in msg.payload.

Ergebnis: Ein Array normalisierter NGSI-LD-Entitäten, das direkt an Post to Stellio übergeben werden kann.

Der Node ist nachrichtenbasiert: Er verarbeitet jede eingehende Nachricht sofort und fragt selbst keine Daten ab. Enthält msg.payload ein Array, wird jedes Element einzeln in eine Entität umgeformt; ein einzelnes Objekt ergibt ein Array mit einer Entität. Verschachtelte Arrays (Array aus Arrays) werden verworfen.

Beim Öffnen des Dialogs ruft der Node den @context und das Schema des Entitätstyps über einen Proxy des Node-RED-Servers ab. Beide werden eine Stunde lang zwischengespeichert; die Schaltfläche Cache leeren/erneuern erzwingt ein Neuladen.

Konfiguration

Der Bearbeitungsdialog ist in fünf Registerkarten gegliedert. Beschriftungen entsprechen der deutschen Oberfläche.

Registerkarte Allgemein

Feld	Typ	Standard	Bedeutung
Name	Text	leer	Anzeigename des Nodes im Flow.
Themenfilter	Text	leer	Exakter Vergleich mit `msg.topic` oder regulärer Ausdruck in Schrägstrichen, zum Beispiel `/^sensor\//`. Nicht passende Nachrichten werden verworfen.
Kontext-URL	Text (Pflicht)	siehe unten	URL des JSON-LD-`@context`. Platzhalter der Form `${VAR}` werden beim Start des Nodes aus Umgebungsvariablen ersetzt. Die URL wird unverändert in das Feld `@context` jeder Entität geschrieben.
Entitätstyp	Text (Pflicht)	leer	NGSI-LD-Zieltyp, zum Beispiel `WeatherObserved`. Der Typ muss im `@context` auf ein Schema verweisen, damit die Schema-Erkennung funktioniert.
Konfig ID-Segment	Text	leer	Optionales Namenssegment in der URN. Ergebnis: `urn:ngsi-ld:<Typ>:[<Segment>:]<Eingangs-ID>`.
Cache leeren/erneuern	Schaltfläche	–	Löscht den serverseitigen Kontext- und Schema-Cache.
Debug-Modus aktivieren	Kontrollkästchen	aus	Gibt Eingabe, Konfiguration und Ergebnis als `node.warn` in der Debug-Seitenleiste aus.

Standardwerte der URL-Felder:

Kontext-URL: https://context.${DOMAIN}/main-context

Registerkarte Mapping

Feld	Typ	Standard	Bedeutung
Mapping-Modus	Auswahl (Pflicht)	leer	`Smart Modus`, `Einfacher Modus` oder `Benutzerdefinierter Modus`, siehe unten.
Beispiel-JSON (Key-Value)	Textfeld	leer	Ein Beispielobjekt (oder Array) Ihrer Eingangsdaten. Nach Beispiel parsen stehen alle Schlüssel, auch verschachtelte in Punktschreibweise wie `location.coordinates`, in den Auswahllisten zur Verfügung.
Globales observedAt Überschreiben	Kontrollkästchen	aus	Aktiviert die Übernahme des Zeitstempels aus einem Eingangsfeld.
Quellfeld	Auswahl	leer	Eingangsfeld mit einem ISO-8601-Zeitstempel (muss ein `T` enthalten). Ist das Feld leer oder ungültig, wird die Systemzeit verwendet.
Erforderliche Felder ignorieren	Kontrollkästchen	aus	Erlaubt das Speichern ohne Zuordnung aller Pflichtfelder. Zur Laufzeit werden Elemente mit fehlenden Pflichtfeldern dann nicht mehr verworfen.
Schema laden/bearbeiten	Schaltfläche	–	Lädt `@context` und Schema und zeigt alle Zielattribute des Datenmodells mit Beschreibung an. Pflichtfelder sind mit `*` markiert.
Felder suchen	Text	leer	Filtert die Liste der Zielattribute nach Name oder Beschreibung.
Feld-Mapping	Liste	leer	Je Zielattribut eine Auswahl des Quellfeldes sowie ein Uhr-Symbol, das `observedAt` für dieses Attribut ein- oder ausschaltet. Für das Attribut `type` gibt es den Eintrag `« Entitätstyp aus Allgemein »`.
Mappings anwenden	Schaltfläche	–	Übernimmt die Zuordnung, prüft Pflichtfelder und blendet nicht zugeordnete Attribute aus. Wird `location` zugeordnet, aktiviert der Node automatisch die Standort-Analyse.
Benutzerdefiniertes Mapping	Liste	leer	Nur im benutzerdefinierten Modus: freie Paare aus Quellfeld, Ziel-Eigenschaftsname und Uhr-Symbol für `observedAt`.

Die drei Modi unterscheiden sich so:

Smart Modus: Die Zielattribute kommen aus dem Smart-Data-Model-Schema. Sie ordnen jedem Attribut ein Quellfeld zu. Fehlt zur Laufzeit ein Pflichtfeld, wird das Element verworfen (außer Erforderliche Felder ignorieren ist aktiv).
Einfacher Modus: Jeder Schlüssel des Eingangsobjekts wird 1:1 zu einem gleichnamigen Attribut. Die Schlüssel id, type, @context und observedAt werden übersprungen. Ein Feld location mit ungültigen Koordinaten wird ausgelassen.
Benutzerdefinierter Modus: Nur die Paare aus Benutzerdefiniertes Mapping werden übernommen. Ein Eingangsfeld location wird zusätzlich automatisch als GeoProperty übernommen, falls es nicht bereits gesetzt ist.

Smart Data Model auswählen

Tragen Sie zuerst die Kontext-URL und den Entitätstyp ein, zum Beispiel WeatherObserved. Der Node sucht den Typ im @context, folgt der dort hinterlegten Schema-URL, löst $ref- und allOf-Verweise auf und listet alle Attribute des Datenmodells mit Beschreibung und Pflichtkennzeichen auf. Fügen Sie dann ein Beispiel-JSON ein, klicken Sie auf Beispiel parsen und wählen Sie je Attribut das passende Quellfeld.

Registerkarte Standort

Feld	Typ	Standard	Bedeutung
Erweiterte Standort-Analyse aktivieren	Kontrollkästchen	aus	Erzeugt aus den folgenden Feldern eine GeoProperty `location`. Ist sie aktiv, haben Mapping-Einträge auf `location` keine Wirkung mehr.
Geo-Typ	Auswahl	`Punkt`	`Punkt`, `Linienzug`, `Polygon`, `MultiPunkt`, `MultiLinienzug` oder `MultiPolygon`.
Positionsformat	Auswahl	`Separate Felder (Breite, Länge)`	Nur bei Punkt: getrennte Felder oder ein Array `[x, y]`.
Breitengrad / Längengrad	Auswahl	leer	Quellfelder bei getrennten Feldern. Werte werden als Dezimalzahl gelesen.
Koordinaten-Array Feld	Auswahl	leer	Quellfeld bei Array-Format für Punkt.
Polygon-Array Feld	Text	leer	Quellfeld mit dem GeoJSON-`coordinates`-Array für Linienzug, Polygon und Multi-Typen.
Koordinaten-Reihenfolge	Auswahl	`Länge, Breite (GeoJSON Standard)`	Reihenfolge innerhalb der Arrays. Bei `Breite, Länge` tauscht der Node alle Paare rekursiv in GeoJSON-Reihenfolge.

Eine Kartenvorschau zeigt die aus dem Beispiel-JSON ermittelte Geometrie an. Ungültige Koordinaten (Breite außerhalb −90 bis 90, Länge außerhalb −180 bis 180) werden als Fehler unter der Karte gemeldet.

Registerkarte Logik

Feld	Typ	Standard	Bedeutung
Benutzerdefinierte Transformationslogik	Kontrollkästchen	aus	Aktiviert das Skript.
Transformations-Skript (JavaScript)	Code-Editor	leer	Läuft nach dem Mapping in einer Sandbox. Verfügbar sind `entity` (die bisher erzeugte Entität, direkt änderbar), `item` (das Eingangsobjekt), `msg` (Kopie der Nachricht mit `payload = item`), `console`, `setTimeout` und die Hilfsfunktion `formatProperty(key, value, observedAt, includeObservedAt)`.

Die Feldreferenz unter dem Editor listet alle aktuell gemappten Attribute; ein Klick fügt entity.<Attribut>.value = an der Cursorposition ein. Mit dem Skript lassen sich auch Metadaten ergänzen, die der Builder nicht automatisch setzt, zum Beispiel entity.temperature.unitCode = "CEL";.

Registerkarte Erweitert

Feld	Typ	Standard	Bedeutung
Globale Wert-Überschreibungen	Liste (Feld, Wert, Typ)	leer	Statische Werte für jede Entität. Typen: `string`, `number`, `boolean`, `object`, `array`. Das Feld `id` ersetzt die komplette URN, `type` den Entitätstyp; andere Felder werden als Property gesetzt.
Datenmodell-Validierung aktivieren	Kontrollkästchen	an	Prüft die fertige Entität gegen das Schema. Fehlende Pflichtfelder führen immer zum Verwerfen der Entität.
Zusätzliche Felder außerhalb des Kontexts	Kontrollkästchen	aus	Attribute, die nicht im Schema stehen, gelten als ungültig.
Fehlende optionale Felder	Kontrollkästchen	aus	Optionale Schemafelder ohne Wert gelten als ungültig.
Ungültige Werte (Typ, Bereich, Enum)	Kontrollkästchen	aus	Prüft `value` jedes Attributs auf Typ, `enum`, `minimum`/`maximum`, `minLength` / `maxLength` und `pattern`.
Ungültige optionale Felder verarbeiten	Auswahl	`Ungültige Eigenschaft überspringen`	`Ungültige Eigenschaft überspringen` entfernt nur das betroffene Attribut, `Entität entfernen` verwirft die ganze Entität, `Ignorieren (nur Warnung)` gibt sie unverändert aus.
Globale benutzerdefinierte Felder	Liste (Quelle, Ziel)	leer	Zusätzliche Eingangsfelder, die in allen Modi auf ein Zielattribut abgebildet werden. Ein Ziel `id` liefert die Eingangs-ID für die URN-Bildung.

Eingang

Eigenschaft	Typ	Bedeutung
`msg.payload`	Objekt oder Array von Objekten	Die umzuformenden Datensätze. Jedes Element wird zu genau einer Entität. Elemente, die keine Objekte sind, werden übersprungen. Ein Array aus Arrays wird komplett verworfen.
`msg.topic`	Text	Wird nur ausgewertet, wenn ein Themenfilter konfiguriert ist.
`msg.payload[].id`	Text	Dient als Eingangs-ID, wenn weder Überschreibung, benutzerdefiniertes Feld noch Mapping eine ID liefern. Beginnt der Wert mit `urn:`, wird er unverändert als `id` übernommen.
`msg.payload[].<Quellfeld>`	beliebig	Quellfelder gemäß Mapping, Standort-Analyse und observedAt-Quellfeld. Punktschreibweise und Array-Indizes wie `data.items[0].value` werden unterstützt.
`msg` (gesamt)	Objekt	Steht dem Transformations-Skript als `msg` zur Verfügung.

So entsteht die URN-ID

Die ID wird in dieser Reihenfolge bestimmt:

Globale Wert-Überschreibung mit Feld id: Der Wert ist die endgültige ID.
Globales benutzerdefiniertes Feld mit Ziel id: Der Wert des Quellfeldes ist die Eingangs-ID.
Mapping (Smart oder benutzerdefiniert) mit Ziel id: Der Wert des Quellfeldes ist die Eingangs-ID.
Eingangsfeld id des Datensatzes.
Zufällige UUID in der Form Entity-<uuid>, wenn nichts davon zutrifft.

Beginnt die Eingangs-ID bereits mit urn:, wird sie unverändert verwendet. Sonst bildet der Node urn:ngsi-ld:<Entitätstyp>:<Konfig ID-Segment>:<Eingangs-ID>; das Segment entfällt, wenn es leer ist.

So werden Attribute typisiert

Eingangswert	Ergebnis
Text, der mit `urn:` beginnt	`Relationship` mit `object`
Zielattribut `location` oder Objekt mit GeoJSON-`type` (`Point`, `LineString`, `Polygon`, `MultiPoint`, `MultiLineString`, `MultiPolygon`)	`GeoProperty` mit `value`
alles andere (Zahl, Text, Boolean, Objekt, Array)	`Property` mit `value`

Ist observedAt für das Attribut aktiv, wird der Zeitstempel ergänzt (Quellfeld oder Systemzeit). Zielnamen in Punktschreibweise wie address.streetAddress erzeugen eine Property address, deren value ein Objekt mit dem Unterfeld ist. Einen unitCode setzt der Node nicht automatisch; ergänzen Sie ihn bei Bedarf im Transformations-Skript.

Ausgang

msg.payload enthält immer ein Array von Entitäten, auch wenn nur ein Objekt eingegangen ist. Alle übrigen Nachrichteneigenschaften bleiben erhalten.

Beispiel: Ein Wetter-Connector liefert folgendes flaches Objekt. Konfiguriert sind der Entitätstyp WeatherObserved, das Konfig-ID-Segment beispielstadt, das observedAt-Quellfeld dateObserved, die Standort-Analyse als Punkt aus den Feldern lat und lon sowie ein Smart-Mapping für dateObserved, temperature, relativeHumidity und refDevice.

{
  "id": "station-042",
  "dateObserved": "2026-10-01T06:00:00Z",
  "temperature": 14.2,
  "relativeHumidity": 0.81,
  "lat": 50.3315,
  "lon": 7.3322,
  "refDevice": "urn:ngsi-ld:Device:station-042"
}

Daraus erzeugt der Node:

[
  {
    "id": "urn:ngsi-ld:WeatherObserved:beispielstadt:station-042",
    "type": "WeatherObserved",
    "@context": ["https://context.beispielstadt.example/main-context"],
    "location": {
      "type": "GeoProperty",
      "value": {"type": "Point", "coordinates": [7.3322, 50.3315]},
      "observedAt": "2026-10-01T06:00:00.000Z"
    },
    "dateObserved": {
      "type": "Property",
      "value": "2026-10-01T06:00:00Z",
      "observedAt": "2026-10-01T06:00:00.000Z"
    },
    "temperature": {
      "type": "Property",
      "value": 14.2,
      "observedAt": "2026-10-01T06:00:00.000Z"
    },
    "relativeHumidity": {
      "type": "Property",
      "value": 0.81,
      "observedAt": "2026-10-01T06:00:00.000Z"
    },
    "refDevice": {
      "type": "Relationship",
      "object": "urn:ngsi-ld:Device:station-042",
      "observedAt": "2026-10-01T06:00:00.000Z"
    }
  }
]

Feld	Bedeutung
`id`	URN aus Entitätstyp, Konfig-ID-Segment und Eingangs-ID.
`type`	Der konfigurierte Entitätstyp (im Smart-Modus optional aus einem Eingangsfeld).
`@context`	Array mit der konfigurierten Kontext-URL (Platzhalter bereits ersetzt).
`location`	GeoProperty aus der Standort-Analyse; Koordinaten stets in GeoJSON-Reihenfolge Länge, Breite.
`<Attribut>.type`	`Property`, `GeoProperty` oder `Relationship` gemäß Erkennung.
`<Attribut>.value` / `.object`	Wert beziehungsweise Ziel-URN der Beziehung.
`<Attribut>.observedAt`	ISO-8601-Zeitstempel in UTC, wenn für das Attribut aktiv.

Attribute, deren Wert nach allen Schritten undefined ist, werden vor der Ausgabe entfernt.

Beispiel-Flow

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

Schritt 1

Inject und Function

Ein Inject-Node startet einen Function-Node, der ein Array von Luftqualitäts-Datensätzen (AirQualityObserved) erzeugt.

Schritt 2

Split und Delay

Das Array wird in Pakete zu fünf Datensätzen geteilt und auf eine Nachricht alle zwei Sekunden gedrosselt.

Schritt 3

NGSI Builder und Debug

Der Builder im Smart-Modus formt jedes Paket in AirQualityObserved-Entitäten um; ein Debug-Node zeigt das Ergebnis.

Beispiel-Flow als JSON anzeigen

[
  {"id": "tab1", "type": "tab", "label": "DataOps", "disabled": false, "info": ""},
  {"id": "inject1", "type": "inject", "z": "tab1", "name": "", "props": [{"p": "payload"}], "repeat": "", "once": false, "payload": "", "payloadType": "date", "x": 200, "y": 160, "wires": [["func1"]]},
  {"id": "func1", "type": "function", "z": "tab1", "name": "Luftqualität", "func": "msg.payload = [\n  {\"id\": \"urn:ngsi-ld:AirQualityObserved:beispielkreis:2026-09-30\", \"type\": \"AirQualityObserved\", \"dateObserved\": \"2026-09-30T00:00:00Z\", \"location\": {\"type\": \"Point\", \"coordinates\": [7.3322, 50.3315]}, \"areaServed\": \"Beispielkreis\", \"temperature\": 9.8, \"no2\": 0.000067, \"o3\": 0.1239}\n];\nreturn msg;", "outputs": 1, "x": 390, "y": 160, "wires": [["split1"]]},
  {"id": "split1", "type": "split", "z": "tab1", "name": "", "splt": "\\n", "spltType": "str", "arraySplt": "5", "arraySpltType": "len", "stream": false, "property": "payload", "x": 610, "y": 160, "wires": [["delay1"]]},
  {"id": "delay1", "type": "delay", "z": "tab1", "name": "", "pauseType": "rate", "timeout": "5", "timeoutUnits": "seconds", "rate": "1", "nbRateUnits": "2", "rateUnits": "second", "drop": false, "x": 180, "y": 280, "wires": [["builder1"]]},
  {"id": "builder1", "type": "ngsi-builder", "z": "tab1", "name": "", "contextUrl": "https://context.${DOMAIN}/main-context", "entityType": "AirQualityObserved", "mode": "smart", "entityId": "", "addObservedAt": true,
    "mappings": [
      {"target": "id", "source": "id", "addObservedAt": true, "required": true},
      {"target": "type", "source": "type", "addObservedAt": true, "required": true},
      {"target": "dateObserved", "source": "dateObserved", "addObservedAt": true, "required": true},
      {"target": "location", "source": "location.coordinates", "addObservedAt": true, "required": true},
      {"target": "areaServed", "source": "areaServed", "addObservedAt": true, "required": false},
      {"target": "temperature", "source": "temperature", "addObservedAt": true, "required": false},
      {"target": "no2", "source": "no2", "addObservedAt": true, "required": false},
      {"target": "o3", "source": "o3", "addObservedAt": true, "required": false}
    ],
    "customFields": [], "customMappings": [], "overwrites": [], "debugMode": false, "useTransformation": false, "transformationScript": "", "topicFilter": "", "useObservedAtOverwrite": false, "observedAtField": "", "ignoreRequired": false, "enableValidation": true, "invalidExtraFields": false, "invalidMissingOptional": false, "invalidValue": false, "invalidOptionalAction": "skip",
    "locationConfig": {"enabled": true, "type": "Point", "posType": "array", "latField": "", "lonField": "", "arrayField": "location.coordinates", "polyField": "", "order": "lonlat"},
    "x": 420, "y": 280, "wires": [["debug1"]]},
  {"id": "debug1", "type": "debug", "z": "tab1", "name": "Air Quality", "active": true, "tosidebar": true, "complete": "payload", "targetType": "msg", "x": 610, "y": 280, "wires": []}
]

Der mitgelieferte Flow enthält im Function-Node mehrere tausend Tagesdatensätze eines Satellitendienstes; die Darstellung oben ist auf einen Datensatz gekürzt.

Status und Fehler

Anzeige	Bedeutung
Grüner Punkt „bereit“	Konfiguration ist vollständig; die letzte Nachricht wurde verarbeitet.
Gelber Ring „übersprungen (Topic)“	`msg.topic` passt nicht zum Themenfilter. Die Nachricht wird verworfen.
Roter Ring „Konfiguration fehlt“	Entitätstyp oder Mapping-Modus ist leer. Zusätzlich wird ein Fehler ausgelöst.
Gelber Punkt „übersprungen (fehlende oder ungültige Felder)“	Kein Element ergab eine gültige Entität, zum Beispiel wegen fehlender Pflichtfelder oder fehlgeschlagener Validierung. Es wird keine Nachricht gesendet.
Roter Punkt „error“ mit Fehler „[NGSI-LD Builder] Interner Fehler: …“	Unerwarteter Fehler bei der Verarbeitung der Nachricht.
Fehler „Ungültiger Themenfilter Regex: …“	Der reguläre Ausdruck im Themenfilter ist fehlerhaft.
Fehler „[NGSI-LD Builder] Standort-Analyse-Fehler: …“	Die Geodaten konnten nicht gelesen werden; die Entität wird ohne `location` weiterverarbeitet.
Fehler „[NGSI-LD Builder] Skript-Fehler: …“	Das Transformations-Skript hat eine Ausnahme ausgelöst; die Entität wird ohne die Skriptänderungen weiterverarbeitet.
Fehler „[NGSI-LD Builder] Kritischer Verarbeitungsfehler: …“	Ein Element konnte nicht verarbeitet werden und wird übersprungen.
Warnung „[Zeitstempel Validierung] Ungültiges Format in Feld '…'“	Das observedAt-Quellfeld enthält keinen ISO-8601-Zeitstempel; die Systemzeit wird verwendet.
Warnung „[Validierung] Entität … verworfen (ungültig): …“	Ein Pflichtfeld des Schemas fehlt; die Entität wird verworfen.
Warnung „[Validierung] Entität … ist ungültig (Warnung): …“	Optionale Felder sind ungültig; die Behandlung folgt der Einstellung Ungültige optionale Felder verarbeiten.

Im Debug-Modus erscheinen zusätzlich die Warnungen „Verarbeite Eingabe“, „Ergebnis erstellt“, „Element ist kein Objekt, überspringe.“ und „Element verworfen wegen fehlender Pflichtfelder: …“. Fehler werden über node.error gemeldet und können mit einem Catch-Node abgefangen werden.

Hinweise

Netzwerkzugriff beim Konfigurieren: Kontext und Schema werden vom Node-RED-Server über die Admin-Endpunkte /ngsi-builder/proxy und /ngsi-builder/flush-cache geladen. Der Server benötigt dafür Zugriff auf die Kontext-URL und auf die Schema-URLs der Smart Data Models (häufig GitHub). Hinter einem Proxy müssen die üblichen Umgebungsvariablen gesetzt sein.
Validierung: Ohne erreichbaren Kontext oder erreichbares Schema findet zur Laufzeit keine Validierung statt. Kontext und Schema werden eine Stunde zwischengespeichert.
Zeitstempel: observedAt wird immer in UTC mit Millisekunden ausgegeben. Ohne Quellfeld entspricht er dem Verarbeitungszeitpunkt, nicht dem Messzeitpunkt.
Koordinaten: Die Ausgabe folgt GeoJSON, also Längengrad vor Breitengrad. Stellen Sie die Koordinaten-Reihenfolge passend zu Ihren Eingangsdaten ein.
Einheiten: Der Node übernimmt Werte unverändert und setzt keinen unitCode. Konvertieren Sie vorab in metrische Einheiten (°C, mm, m³/s, km/h, µg/m³) und ergänzen Sie den unitCode bei Bedarf im Transformations-Skript.
Transformations-Skript: Das Skript läuft mit den Rechten des Node-RED-Prozesses. Beschränken Sie den Zugriff auf den Editor entsprechend.
Personenbezogene Daten: Der Node entfernt keine Inhalte. Enthalten Eingangsdaten Namen, Adressen oder Fahrzeugkennzeichen, prüfen Sie vor der Veröffentlichung im Context Broker, ob diese Daten übertragen werden dürfen.

NGSI-LD Builder

Wofür Sie den Node verwenden

So funktioniert der Node

Auslösen

ID bilden

Zuordnen

Anpassen

Prüfen und senden

Konfiguration

Registerkarte Allgemein

Registerkarte Mapping

Registerkarte Standort

Registerkarte Logik

Registerkarte Erweitert

Eingang

So entsteht die URN-ID

So werden Attribute typisiert

Ausgang

Beispiel-Flow

Inject und Function

Split und Delay

NGSI Builder und Debug

Status und Fehler

Hinweise

Weiterführende Themen

Referenzen

Wofür Sie den Node verwenden​

So funktioniert der Node​

Auslösen

ID bilden

Zuordnen

Anpassen

Prüfen und senden

Konfiguration​

Registerkarte Allgemein​

Registerkarte Mapping​

Registerkarte Standort​

Registerkarte Logik​

Registerkarte Erweitert​

Eingang​

So entsteht die URN-ID​

So werden Attribute typisiert​

Ausgang​

Beispiel-Flow​

Inject und Function

Split und Delay

NGSI Builder und Debug

Status und Fehler​

Hinweise​

Weiterführende Themen​

Referenzen​

Wofür Sie den Node verwenden

So funktioniert der Node

Konfiguration

Registerkarte Allgemein

Registerkarte Mapping

Registerkarte Standort

Registerkarte Logik

Registerkarte Erweitert

Eingang

So entsteht die URN-ID

So werden Attribute typisiert

Ausgang

Beispiel-Flow

Status und Fehler

Hinweise

Weiterführende Themen

Referenzen