RuleNodes

RuleNodes sind die funktionalen Bausteine einer RuleChain in optiCLOUD. Sie bestimmen, wie eingehende Nachrichten gefiltert, angereichert, transformiert, gespeichert oder an andere Systeme weitergegeben werden.

Diese Seite dient als praxisnahe Orientierung über die verfügbaren Knoten und ihre Einsatzgebiete:

Welche Knoten gibt es?
Wofür werden sie verwendet?
Welche Ausgänge oder Beziehungen besitzen sie?

Übersicht nach Kategorien

Filter-Knoten

RuleNode	Zweck
Message Type Filter	Lässt nur bestimmte Nachrichtentypen passieren
Message Type Switch	Verteilt Nachrichten je nach Nachrichtentyp auf verschiedene Pfade
File Type Switch	Verzweigt Dateinachrichten nach Dateityp
File Names Filter	Filtert Dateinamen nach Präfixen
Device Filter	Begrenzt die Verarbeitung auf bestimmte Geräte
Script (Filter)	Führt eine frei definierte Filterlogik per JavaScript aus
Switch	Leitet Nachrichten per Skript an dynamische Ausgänge weiter
Check Existence Fields	Prüft, ob Felder in Nachricht oder Metadaten vorhanden sind
GPS Geofencing Filter	Lässt nur Nachrichten innerhalb eines Geofence passieren

Aktions-Knoten

RuleNode	Zweck
Save Timeseries	Speichert Telemetrie als Zeitreihe
Save Attributes	Speichert Attribute in einem gewählten Scope
Save Alarms	Speichert Alarmzustände aus Alarmnachrichten
Create Alarm	Erstellt oder aktualisiert einen Alarm
Clear Alarm	Beendet einen bestehenden Alarm
Alarm Counter	Zählt Alarme innerhalb eines Zeitfensters
Log	Schreibt Debug- oder Protokollausgaben
Generator	Erzeugt periodisch Nachrichten
Message Count	Zählt eingehende Nachrichten und veröffentlicht den Zähler
Delay	Verzögert die Weiterleitung einer Nachricht
Aggregate OSF File	Liest OSF-Dateien und erzeugt daraus Telemetrie
Aggregate JSONL File	Liest JSONL-Dateien und erzeugt daraus Telemetrie
Process Raw Data File	Verarbeitet Dateioperationen im Blob-Speicher
Generate Report	Erstellt Berichte über einen definierten Zeitraum
Device System	Aggregiert Daten über mehrere Geräte hinweg
GPS Geofencing Events	Erzeugt Ereignisse beim Betreten oder Verlassen eines Geofence
RPC Call Request	Sendet einen RPC-Aufruf an ein Gerät
RPC Call Reply	Antwortet auf einen eingehenden RPC-Aufruf

Anreicherungs-Knoten

RuleNode	Zweck
Originator Attributes	Lädt Attribute des Ursprungselements in die Metadaten
Originator Telemetry	Lädt Telemetrie des Ursprungselements in die Metadaten
Originator Fields	Ergänzt Stammdaten des Ursprungselements
Tenant Details	Ergänzt Informationen des Tenants

Transformations-Knoten

RuleNode	Zweck
Script (Transform)	Ändert Nachricht, Metadaten oder Nachrichtentyp per JavaScript
To Email	Baut aus einer Nachricht ein E-Mail-Objekt

Externe Knoten

RuleNode	Zweck
REST API Call	Sendet Daten an eine externe REST-Schnittstelle
MQTT	Veröffentlicht Nachrichten an einen MQTT-Broker
Kafka	Veröffentlicht Nachrichten in ein Kafka-Topic
RabbitMQ	Sendet Nachrichten an RabbitMQ
AWS SQS	Sendet Nachrichten an eine SQS-Queue
AWS SNS	Veröffentlicht Nachrichten an ein SNS-Topic
GCP Pub/Sub	Veröffentlicht Nachrichten an Google Pub/Sub
Send Email	Sendet eine E-Mail über SMTP

Scheduler-Knoten

RuleNode	Zweck
Create Scheduled Task	Plant eine zeitversetzte Einmal-Ausführung
Clear Scheduled Task	Löscht eine zuvor geplante Aufgabe

Event- und Alarm-Knoten

RuleNode	Zweck
Complex Alarm	Erstellt Alarme anhand komplexer Echtzeitmuster
Complex Event Processing	Bewertet Dateidaten mit Event-Regeln
Enrich Alarm	Ergänzt bestehende Alarme um zusätzliche Informationen

Detailübersicht

Filter-Knoten

Message Type Filter

Kategorie: Filter
Ausgänge: True, False

Der Knoten prüft, ob der Nachrichtentyp der eingehenden Nachricht in einer konfigurierten Liste enthalten ist. Bei einer Übereinstimmung läuft die Nachricht über True weiter, andernfalls über False.

Konfiguration

Label	Pflichtfeld	Beschreibung
Message Types Filter	Ja	Liste erlaubter Nachrichtentypen. Mindestens ein Typ muss eingetragen sein.

Unterstützte Werte sind unter anderem POST_ATTRIBUTES_REQUEST, POST_TELEMETRY_REQUEST, TO_SERVER_RPC_REQUEST, TO_DEVICE_RPC_REQUEST, ACTIVITY_EVENT, INACTIVITY_EVENT, CONNECT_EVENT, DISCONNECT_EVENT, BLOB_STORE_REQUEST und POST_ALARMS.

Beispiel

Verwenden Sie diesen Knoten, wenn z.B. nur Telemetriedaten weiterverarbeitet werden sollen. In diesem Fall wird POST_TELEMETRY_REQUEST konfiguriert und über den Ausgang TRUE mit einem weiteren Knoten verbunden, welcher dann gesichert nur noch Nachrichten vom Tpy POST_TELEMETRY_REQUEST erhält.

Message Type Switch

Kategorie: Filter
Ausgänge: je Nachrichtentyp plus Other

Der Knoten verteilt Nachrichten anhand ihres Nachrichtentyps auf feste Ausgänge. Er eignet sich als früher Verteiler in einer RuleChain, wenn unterschiedliche Nachrichtentypen in getrennten Zweigen verarbeitet werden sollen.

Konfiguration

Dieser Knoten besitzt keine konfigurierbaren Optionen. Die Ausgänge sind fest definiert.

Ausgang	Bedingung
`POST_ATTRIBUTES`	Nachrichtentyp ist `POST_ATTRIBUTES_REQUEST`
`POST_TELEMETRY`	Nachrichtentyp ist `POST_TELEMETRY_REQUEST`
`POST_ALARMS`	Nachrichtentyp ist `POST_ALARMS`
`BLOB_STORE_REQUEST`	Nachrichtentyp ist `BLOB_STORE_REQUEST`
`RPC_REQUEST_FROM_DEVICE`	Nachrichtentyp ist `TO_SERVER_RPC_REQUEST`
`RPC_REQUEST_TO_DEVICE`	Nachrichtentyp ist `TO_DEVICE_RPC_REQUEST`
`ACTIVITY_EVENT`	Nachrichtentyp ist `ACTIVITY_EVENT`
`INACTIVITY_EVENT`	Nachrichtentyp ist `INACTIVITY_EVENT`
`CONNECT_EVENT`	Nachrichtentyp ist `CONNECT_EVENT`
`DISCONNECT_EVENT`	Nachrichtentyp ist `DISCONNECT_EVENT`
`Other`	Alle anderen Nachrichtentypen

Beispiel

In einer Root RuleChain kann dieser Knoten direkt nach dem Eingang stehen, um Telemetrie, Attribute, Alarme, RPC-Nachrichten und Dateioperationen in getrennte Verarbeitungszweige aufzuteilen.

File Type Switch

Kategorie: Filter
Ausgänge: OSF, JSONL, Other

Der Knoten verzweigt Dateinachrichten anhand der Dateiendung. Er wird in Datei-Pipelines eingesetzt, nachdem eine Dateioperation als BLOB_STORE_REQUEST erkannt wurde.

Konfiguration

Dieser Knoten besitzt keine konfigurierbaren Optionen. Die Erkennung erfolgt anhand der Dateiendung in den Metadaten.

Ausgang	Erkannte Dateiendungen
`OSF`	`.osf`, `.osfz`
`JSONL`	`.log`, `.log.gz`
`Other`	Alle anderen Dateiendungen

Beispiel

Leiten Sie .osf-Dateien z.B. an Aggregate OSF File weiter.

File Names Filter

Kategorie: Filter
Ausgänge: True, False

Der Knoten lässt Dateinachrichten nur dann über True weiterlaufen, wenn der Dateiname mit einem der konfigurierten Präfixe beginnt.

Konfiguration

Label	Pflichtfeld	Beschreibung
File Prefixes	Ja	Liste von Dateinamen-Präfixen. Die Prüfung ist case-sensitive.

Hinweise

Eine leere Präfixliste führt dazu, dass alle Nachrichten über False laufen.
Der Dateiname wird aus den Metadaten der Nachricht gelesen, in der Regel aus fileName.

Beispiel

Wenn ein Gerät Dateien mit data_ und config_ hochlädt, können zwei File Names Filter verwendet werden, um beide Dateigruppen getrennt weiterzuverarbeiten.

Device Filter

Kategorie: Filter
Ausgänge: True, False

Der Knoten beschränkt die Verarbeitung auf bestimmte Geräte. Die Geräteliste kann je nach Einstellung als Freigabeliste oder Sperrliste verwendet werden.

Konfiguration

Label	Pflichtfeld	Beschreibung
Devices	Ja	Geräteauswahl per Mehrfachauswahl.
Allow selected devices	Ja	Aktiviert: nur ausgewählte Geräte laufen über `True`. Deaktiviert: ausgewählte Geräte werden blockiert.

Ausgänge

Ausgang	Bedingung
`True`	Gerät ist erlaubt oder nicht gesperrt
`False`	Gerät ist nicht erlaubt oder explizit gesperrt

Beispiel

Soll eine Regel nur für bestimmte Geräte ausgeführt werden, kann vor die Regel der DeviceFilter gesetzt werden und nur eine Auswahl der Geräte an die nachfolgende Regel weiterleiten.

Script (Filter)

Kategorie: Filter
Ausgänge: True, False

Der Knoten führt eine JavaScript-Funktion aus. Gibt das Skript true zurück, läuft die Nachricht über True weiter. Bei false oder einem Skriptfehler läuft sie über False.

Konfiguration

Label	Pflichtfeld	Beschreibung
Filter Function	Ja	JavaScript-Funktion mit der Signatur `Filter(msg, metadata, msgType)`.

Skriptkontext

Variable	Beschreibung
`msg`	JSON-Nachrichtentext
`metadata`	Metadaten der Nachricht
`msgType`	Nachrichtentyp

Beispiel

var threshold = parseFloat(metadata.tempThreshold) || 50;
return msg.temperature > threshold;

Switch

Kategorie: Filter
Ausgänge: dynamisch per Skript

Der Knoten leitet eine Nachricht an einen oder mehrere benannte Ausgänge weiter. Die Ausgangsnamen werden von einer JavaScript-Funktion als Array zurückgegeben.

Konfiguration

Label	Pflichtfeld	Beschreibung
Switch Function	Ja	JavaScript-Funktion mit der Signatur `Switch(msg, metadata, msgType)`.

Das Skript muss ein Array von Strings zurückgeben. Jeder String entspricht einem Ausgangsnamen.

Hinweise

Nicht verbundene Ausgangsnamen werden ignoriert.
Ein leeres Array verwirft die Nachricht.
Für alle möglichen Rückgabewerte sollten passende Verbindungen in der RuleChain angelegt werden.

Beispiel

Über folgende Funktion kann man z.B. den Temperaturwert einer Nachricht überprüfen und die Nachrichten entsprechend des Wertes verschieden weiterleiten.

Verbindung "highTemp" könnte z.B. an einen AlarmKnoten weitergeleitet werden, der einen "High Temperture" Alarm erzeugt
Verbindung "lowTemp" könnte z.B. an einen AlarmKnoten weitergeleitet werden, der einen "Low Temperture" Alarm erzeugt
Verbindung "normalTemp" könnte z.B. an Knoten weitergeleitet werden, die ein "TempStatus = OK" Attribut setzt

function nextRelation(msg) {
    if(msg.temperature > 50){
      return ['highTemp'];
    } else if (msg.temperature < 20){
      return ['lowTemp'];
    } else {
      return ['normalTemp'];
    }
    
}
return nextRelation(msg);

Check Existence Fields

Kategorie: Filter
Ausgänge: True, False

Der Knoten prüft, ob bestimmte Felder im Nachrichtentext und/oder in den Metadaten vorhanden sind. Damit können nachfolgende Knoten vor unvollständigen Nachrichten geschützt werden.

Konfiguration

Label	Pflichtfeld	Beschreibung
Message Data	Nein	Feldnamen, die im Nachrichtentext vorhanden sein müssen.
Message Metadata	Nein	Feldnamen, die in den Metadaten vorhanden sein müssen.
Check All Keys Present	Ja	Aktiviert: alle genannten Felder müssen vorhanden sein. Deaktiviert: mindestens ein Feld muss vorhanden sein.

Mindestens eines der beiden Felder messageNames oder metadataNames muss Einträge enthalten.

Beispiel

Vor einem Script Knoten kann z.B. überprüft werden, ob alle Kanäle, die in dem Script verwendet werden, auch in der Nachricht vorhanden sind. Dies verhindert das das Script fehlschlägt und mindert die Komplexität des Scripts, bei dem man sonst ggf. Vorkehrungen treffen muss über if/else Bedingungen, um zu prüffen ob Kanäle vorhanden sind. Ist dieser Knoten einem Script Knoten voran gestellt, kann im Script Knoten davon ausgegangen werden, dass die Kanäle in der Nachricht vorhanden sind.

GPS Geofencing Filter

Kategorie: Filter
Ausgänge: True, False

Der Knoten prüft, ob GPS-Koordinaten innerhalb eines definierten Geofence liegen. Die Prüfung ist zustandslos und bewertet jeweils die aktuelle Nachricht.

Konfiguration

Label	Pflichtfeld	Beschreibung
Latitude Key Name	Ja	Feldname für den Breitengrad im Nachrichtentext.
Longitude Key Name	Ja	Feldname für den Längengrad im Nachrichtentext.
Fetch Perimeter Info from Metadata	Ja	Aktiviert: Geofence-Definition wird aus Metadaten gelesen. Deaktiviert: Geofence wird statisch im Knoten konfiguriert.
Perimeter Type	Ja, bei statischer Konfiguration	`Circle` oder `Polygon`.
Circle-Felder	Ja, bei Kreis	Mittelpunkt, Radius und Einheit des Kreises.
Polygon Definition	Ja, bei Polygon	GeoJSON- oder WKT-Definition des Polygons.

Hinweis

Für zustandsbasierte Betreten-/Verlassen-Ereignisse wird GPS Geofencing Events verwendet.

Beispiel

Verarbeiten Sie z.B. nur Telemetrie, wenn sich ein Fahrzeug innerhalb einer definierten Zone befindet, andernfalls wird die Telemetrie verworfen.

Aktions-Knoten

Save Timeseries

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten speichert Telemetriedaten aus dem Nachrichtentext als Zeitreihenwerte in der Datenbank.

Konfiguration

Label	Pflichtfeld	Beschreibung
Default TTL	Ja	Lebensdauer gespeicherter Datenpunkte in Sekunden. `0` bedeutet keine automatische Löschung.
Enable Type Cast	Ja	Konvertiert Zahlen- oder Boolean-Werte aus Strings in native Datentypen.

Eingang

Der Nachrichtentyp muss POST_TELEMETRY_REQUEST sein. Der Nachrichtentext muss ein JSON-Objekt sein oder ein Array von JSON-Objekten mit ts-Zeitstempel enthalten.

Save Attributes

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten speichert Schlüssel-Wert-Paare aus dem Nachrichtentext als Attribute der Ursprungseinheit.

Konfiguration

Label	Pflichtfeld	Beschreibung
Attribute Scope	Ja	Ziel-Scope für die Attribute.
Enable Type Cast	Ja	Konvertiert Zahlen- oder Boolean-Werte aus Strings in native Datentypen.

Scope	Bedeutung
`CLIENT_SCOPE`	Vom Gerät gemeldete Attribute, die für das Gerät sichtbar sind.
`SHARED_SCOPE`	Server-seitig gesetzte Attribute, die an das Gerät verteilt werden können.
`SERVER_SCOPE`	Server-interne Attribute, die nicht an das Gerät gesendet werden.

Eingang

Der Nachrichtentext muss ein JSON-Objekt sein. Jeder Schlüssel wird als Attributname gespeichert.

Save Alarms

Kategorie: Aktion
Ausgänge: Activated, Deactivated, Sustained

Der Knoten verarbeitet Nachrichten vom Typ POST_ALARMS und speichert Alarmzustände in der Datenbank. Er bildet dabei Zustandswechsel von Alarmen ab.

Ausgänge

Ausgang	Bedeutung
`Activated`	Ein neuer Alarm wurde geöffnet oder ein gelöschter Alarm wurde erneut aktiv.
`Deactivated`	Ein aktiver Alarm wurde beendet.
`Sustained`	Ein bereits aktiver Alarm bleibt aktiv.

Konfiguration

Label	Pflichtfeld	Beschreibung
Propagate	Ja	Gibt an, ob Alarme an übergeordnete Entitäten propagiert werden.

Eingang

Die Nachricht muss vom Typ POST_ALARMS sein und Alarmdaten gemäß dem Alarmmodell der Plattform enthalten.

Create Alarm

Kategorie: Aktion
Ausgänge: Created, Updated, False

Der Knoten erstellt einen Alarm für den Ursprung der Nachricht oder aktualisiert einen bereits vorhandenen Alarm desselben Typs. Die Alarmdetails werden per JavaScript aus Nachricht und Metadaten aufgebaut.

Ausgänge

Ausgang	Bedeutung
`Created`	Ein neuer Alarm wurde erstellt.
`Updated`	Ein bestehender Alarm dieses Typs wurde aktualisiert.
`False`	Das Skript hat keinen Alarm erzeugt.

Konfiguration

Label	Pflichtfeld	Beschreibung
Alarm Details Builder	Ja	JavaScript-Funktion `Details(msg, metadata, msgType)` für die Alarmdetails.
Alarm Type	Ja	Alarmtyp. Unterstützt `${metadata.key}`-Muster.
Alarm Severity	Ja	Schweregrad: `CRITICAL`, `MAJOR`, `MINOR`, `WARNING`, `INDETERMINATE`.
Propagate	Ja	Propagiert den Alarm an übergeordnete Entitäten.

Metadaten nach Verarbeitung

Der Knoten ergänzt unter anderem alarmType, alarmIsNew, alarmSeverity und alarmId.

Beispiel

Ein vorgeschalteter Script Filter prüft msg.temperature > 80. Bei True erstellt dieser Knoten einen Alarm HighTemperature mit Schweregrad MAJOR. In den Details könnte z.B. eine Funktion stehen, die den Temperatur Höchststand in den Details festhält, so lange ein Alarm aktiv war und geupdated wurde

var details = {};
if (metadata.prevAlarmDetails) {
    details = JSON.parse(metadata.prevAlarmDetails);
    if (parseFloat(details.highestTemp) < msg.temperature){
        details.highestTemp = msg.temperature;
    }
}
return details;

Clear Alarm

Kategorie: Aktion
Ausgänge: Cleared, False

Der Knoten beendet einen aktiven Alarm des konfigurierten Typs für den Ursprung der Nachricht.

Ausgänge

Ausgang	Bedeutung
`Cleared`	Ein passender aktiver Alarm wurde gefunden und beendet.
`False`	Es wurde kein passender aktiver Alarm gefunden.

Konfiguration

Label	Pflichtfeld	Beschreibung
Alarm Details Builder	Ja	JavaScript-Funktion für die finalen Alarmdetails beim Beenden.
Alarm Type	Ja	Alarmtyp, der exakt zum zuvor erzeugten Alarm passen muss.

Metadaten nach Verarbeitung

Der Knoten ergänzt alarmType und alarmId.

Beispiel

Wenn ein Gerät wieder temperature < 70 meldet, kann Clear Alarm den zuvor erstellten Alarm HighTemperature beenden.

info

Der AlarmTyp ist Case Sensitiv! Wenn mit einem Create Alarm Knoten ein Alarm vom Typ HighTemperature erstellt wurde, muss genau dieser HighTemperature Alarm-Typ auch im Clear Alarm Knoten eingetragen werden, damit dieser auch gecleared werden kann.

Alarm Counter

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten zählt Alarme nach konfigurierten Kriterien innerhalb eines Zeitfensters und speichert die Ergebnisse als Server-Attribute am Ursprung der Nachricht.

Konfiguration

Der Knoten enthält eine Liste von Zählerdefinitionen.

Label	Pflichtfeld	Beschreibung
Find by Field Name	Ja	Alarmfeld, nach dem gefiltert wird, z. B. `severity` oder `type`.
With Field Value	Ja	Wert, den das Feld besitzen muss, z. B. `CRITICAL`.
Save in Server Attribute	Ja	Name des Server-Attributs, in dem der Zähler gespeichert wird.
Time Period Alarm Considered	Ja	Betrachtetes Zeitfenster in Sekunden. `0` bedeutet ohne zeitliche Einschränkung.

Beispiel

Mit

fieldName = severity
fieldValue = CRITICAL
attributeName = criticalAlarms24h
periodInSeconds = 86400

wird die Anzahl kritischer Alarme der letzten 24 Stunden gezählt und unter dem ServerAttribut criticalAlarms24h gespeichert.

Log

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten schreibt einen per JavaScript erzeugten Text in das Server-Log und leitet die ursprüngliche Nachricht unverändert weiter.

Konfiguration

Label	Pflichtfeld	Beschreibung
Log Function	Ja	JavaScript-Funktion `ToString(msg, metadata, msgType)`, die den Log-Text zurückgibt.

Hinweise

Der Knoten ist vor allem für Entwicklung, Analyse und Fehlerbehebung gedacht.
Er sollte sparsam eingesetzt werden und am besten erst nach Rücksprache mit Optimeas, da ein Log Knoten eigentlich nur dann Sinn ergibt, wenn ese zuvor zu Fehlern kam, die ggf. vom Benutzer selbst nicht behoben werden können.

Generator

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten erzeugt periodisch Nachrichten per JavaScript und speist sie in die RuleChain ein. Er kann für Tests, Simulationen oder zeitgesteuerte Abläufe genutzt werden.

Konfiguration

Label	Pflichtfeld	Beschreibung
Message Count	Ja	Anzahl zu erzeugender Nachrichten. `0` bedeutet unbegrenzt.
Period in Seconds	Ja	Abstand zwischen erzeugten Nachrichten in Sekunden.
Originator	Ja	Ursprungsgerät für die erzeugten Nachrichten.
Generator Function	Ja	JavaScript-Funktion `Generate(prevMsg, prevMetadata, prevMsgType)`.

Die Funktion muss msg, metadata und msgType zurückgeben.

Beispiel

Will man z.B. eine RuleChain erstellen und testen, hat jedoch gerade kein echtes Gerät zur Hand, oder eines, welches genau in dem Moment Live-Daten sendet, kann man mit dem Generator Knoten künstliche Nachrichten erzeugen. Für einen geeigneten Test, sollten diese künstlich erzeugten Nachrichten am Besten die prognostizierten Nachrichten eines echten Gerätes speigeln.

Folgendes Beispiel erzeugt Nachrichten mit:

Telemetriekanälen: {"temperature": 42} und {"humidity": 77}

Metadaten: {"data": 40}

Typ: POST_TELEMETRY_REQUEST

var msg = { temperature: 42, humidity: 77 };
var metadata = { data: 40 };
var msgType = "POST_TELEMETRY_REQUEST";

return { msg: msg, metadata: metadata, msgType: msgType };

In dem obigen Beispiel handelt es sich um statische Nachrichten mit immer den gleichen Werten (42,77,40). Ein Generator kann aber auch variierende Daten erzeugen über z.B.:

var temp = Math.floor(Math.random() * max);
var hum = Math.floor(Math.random() * max);
var meta = Math.floor(Math.random() * max);

var msg = { temperature: temp, humidity: hum };
var metadata = { data: meta };
var msgType = "POST_TELEMETRY_REQUEST";

return { msg: msg, metadata: metadata, msgType: msgType };

Hinweis

In produktiven Umgebungen sollte der Zeitraum bewusst gewählt werden, damit keine unnötig hohe Nachrichtenlast entsteht.

Message Count

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten zählt Nachrichten innerhalb eines Zeitintervalls und veröffentlicht den Zählerstand als Telemetrie.

Konfiguration

Label	Pflichtfeld	Beschreibung
Interval in Seconds	Ja	Länge des Zählfensters in Sekunden.
Output Timeseries Key Prefix	Ja	Telemetrieschlüssel für den Zählerwert.

Ausgabe

Am Ende jedes Intervalls wird eine POST_TELEMETRY_REQUEST-Nachricht erzeugt, z. B.:

{
  "messageCount": 42
}

Eingehende Nachrichten werden zusätzlich unverändert über Success weitergeleitet.

Delay

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten hält Nachrichten für eine konfigurierte Dauer zurück und gibt sie danach weiter. Die Verzögerung kann statisch oder über Metadaten bestimmt werden.

Konfiguration

Label	Pflichtfeld	Beschreibung
Use Metadata Period Pattern	Ja	Aktiviert eine dynamische Verzögerung über Metadaten.
Period in Seconds	Ja, wenn statisch	Statische Verzögerung in Sekunden.
Period in Seconds Pattern	Ja, wenn dynamisch	Metadatenfeld oder `${...}`-Ausdruck für die Verzögerung.
Max Pending Messages	Ja	Maximale Anzahl zwischengespeicherter Nachrichten.

Hinweise

Bei einem Serverneustart gehen wartende Nachrichten verloren, da sie nicht persistent gespeichert werden
Wenn zu viele Nachrichten erreicht ist, laufen neue Nachrichten über Failure.

Aggregate OSF File

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten lädt eine referenzierte OSF-Datei aus einem BLOB_STORE_REQUEST und verarbeitet sie.

Eingang und Ausgabe

Eingang: BLOB_STORE_REQUEST mit Methode GET.
Die Metadaten müssen die Referenz auf die gespeicherte Datei enthalten.
Pro erkanntem Zeitintervall erzeugt der Knoten eine POST_TELEMETRY_REQUEST-Nachricht mit den Messwerten.

Verarbeitungskette

File Type Switch [OSF]
  -> Aggregate OSF File [Success]
  -> Save Timeseries

Aggregate JSONL File

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten lädt eine JSONL-Datei aus einem BLOB_STORE_REQUEST und verarbeitet sie.

Eingang und Ausgabe

Eingang: BLOB_STORE_REQUEST mit Methode GET.
Die Datei muss gültiges JSONL enthalten.
Jede Zeile erzeugt eine POST_TELEMETRY_REQUEST-Nachricht über Success.

Verarbeitungskette

File Type Switch [JSONL]
  -> Aggregate JSONL File [Success]
  -> Save Timeseries

Process Raw Data File

Kategorie: Aktion
Ausgänge: Download, Upload, Delete, Other

Der Knoten klassifiziert BLOB_STORE_REQUEST-Nachrichten nach Dateioperation und leitet sie an den passenden Ausgang weiter.

Konfiguration

Label	Pflichtfeld	Beschreibung
Selected Scopes	Ja	Attribut-Scopes, die verarbeitet werden sollen.
Selected Methods	Ja	HTTP-Methoden bzw. Dateioperationen, die weitergeleitet werden sollen.

Methode	Ausgang	Bedeutung
`PUT`	`Upload`	Datei wurde hochgeladen.
`GET`	`Download`	Datei soll heruntergeladen werden.
`DELETE`	`Delete`	Datei wurde gelöscht.
andere	`Other`	Unbekannte oder nicht konfigurierte Operation.

Beispiel

Upload kann an File Type Switch angeschlossen werden, um OSF- und JSONL-Dateien weiter zu unterscheiden.

Generate Report

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten erzeugt einen Bericht für den Ursprung der Nachricht über ein konfiguriertes Zeitfenster.

Konfiguration

Bereich	Felder
Berichtstyp	`reportType` mit Werten wie `DEVICE_ACTIVITY`, `TELEMETRY`, `DEVICE_STATISTIC`, `ALARM`, `OSF_DATA`, `JASPER_TEMPLATE`.
Bedingte Felder	`alarmSearchStatus`, `templateId`, `keys`, `sources`, abhängig vom Berichtstyp.
Zeitfenster	`useMetadataIntervalPatterns`, `startInterval`, `startIntervalTimeUnit`, `endInterval`, `endIntervalTimeUnit`, `startIntervalPattern`, `endIntervalPattern`.

Beispiel

Für einen täglichen Telemetrieexport kann reportType = TELEMETRY mit einem Zeitfenster von einem Tag und den gewünschten Telemetrieschlüsseln konfiguriert werden.

Device System

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten verarbeitet Daten, die aus einem Device System stammen. Dabei werden Daten mehrerer zusammengehöriger Geräte aggregiert oder korreliert.

Konfiguration

Der Knoten besitzt keine konfigurierbaren UI-Optionen. Die interne Version wird von der Plattform gesetzt.

Hinweise

Der Ursprung muss zu einem konfigurierten Device System gehören.
Die Struktur des Device Systems wird aus der Datenbank gelesen.
Der Knoten ist nur relevant, wenn die Device-System-Funktion genutzt wird.

GPS Geofencing Events

Kategorie: Aktion
Ausgänge: Entered, Left, Inside, Outside

Der Knoten verfolgt den Geofence-Zustand pro Gerät und erzeugt Ereignisse beim Betreten oder Verlassen eines Bereichs. Im Unterschied zum GPS Geofencing Filter ist dieser Knoten zustandsbehaftet.

Konfiguration

Die Koordinaten- und Geofence-Felder entsprechen dem GPS Geofencing Filter. Zusätzlich werden Mindestdauern konfiguriert:

Label	Beschreibung
Minimal Inside Duration	Dauer, die ein Gerät innerhalb des Bereichs sein muss, bevor `Entered` erzeugt wird.
Inside Duration Unit	Zeiteinheit für `minInsideDuration`.
Minimal Outside Duration	Dauer außerhalb des Bereichs, bevor `Left` erzeugt wird.
Outside Duration Unit	Zeiteinheit für `minOutsideDuration`.

Ausgänge

Ausgang	Bedeutung
`Entered`	Gerät war lange genug innerhalb des Bereichs und war vorher außerhalb.
`Left`	Gerät war lange genug außerhalb des Bereichs und war vorher innerhalb.
`Inside`	Gerät ist innerhalb, die Mindestdauer ist aber noch nicht erreicht.
`Outside`	Gerät ist außerhalb, die Mindestdauer ist aber noch nicht erreicht.

RPC Call Request

Kategorie: Aktion
Ausgänge: Success, Failure, Timeout

Der Knoten sendet einen RPC-Aufruf vom Server an ein Gerät und wartet auf die Antwort.

Konfiguration

Label	Pflichtfeld	Beschreibung
Timeout	Ja	Wartezeit in Sekunden, bevor die Nachricht über `Timeout` weiterläuft.

Eingang und Ausgabe

Der Nachrichtentext muss method und params enthalten. Der Ursprung muss ein Gerät sein. Bei Success ersetzt die Geräteantwort den Nachrichtentext.

Beispiel

{
  "method": "emergencyShutdown",
  "params": { "reason": "HighTemperature" }
}

info

Das Gerät muss entsprechend konfiguriert sein, um die genauen Remote Procedure Calls auch ausführen zu können.

RPC Call Reply

Kategorie: Aktion
Ausgänge: Success, Failure

Der Knoten sendet eine Antwort auf eine vom Gerät kommende RPC-Anfrage zurück. Der Antwortinhalt wird aus dem aktuellen Nachrichtentext gebildet.

Konfiguration

Label	Pflichtfeld	Beschreibung
Request ID Metadata Attribute	Nein	Metadatenfeld mit der RPC-Request-ID.

Eingang

Die Nachricht muss vom Typ TO_SERVER_RPC_REQUEST sein. serviceId, sessionId und requestId werden in der Regel von der Plattform gesetzt.

Anreicherungs-Knoten

Originator Attributes

Kategorie: Anreicherung
Ausgänge: Success, Failure

Der Knoten liest Attribute und letzte Telemetriewerte des Ursprungs aus der Datenbank und schreibt sie in die Metadaten der Nachricht.

Metadaten-Präfixe

Quelle	Präfix in den Metadaten
Client-Attribute	`cs_`
Shared-Attribute	`shared_`
Server-Attribute	`ss_`
Letzte Telemetrie	kein Präfix

Konfiguration

Label	Pflichtfeld	Beschreibung
Client Attributes	Nein	Client-Attribute, die als `cs_<name>` ergänzt werden.
Shared Attributes	Nein	Shared-Attribute, die als `shared_<name>` ergänzt werden.
Server Attributes	Nein	Server-Attribute, die als `ss_<name>` ergänzt werden.
Latest Timeseries	Nein	Letzte Telemetriewerte, die ohne Präfix ergänzt werden.
Tell Failure	Ja	Aktiviert: fehlende Werte führen zu `Failure`. Deaktiviert: fehlende Werte werden übersprungen.

Mindestens ein Attribut- oder Telemetrieschlüssel muss eingetragen sein.

Beispiel

Wenn man z.B. manuell einen Offset Wert für einen TemperaturKanal definieren will, könnte man ein Server Attribut in der Form von offset : 5 anlegen. Über diesen Knoten könnte man dann diesen Wert auslesen und die Metadaten anreichern, um mit diesem Wert dann weiter zu arbeiten, indem man den Kanal offset unter Server Attribute auswählt. in deinem darauf folgenden Script Knoten kann man dann auf diesen Wert zugreifen über:

var offset = metadata.ss_offset;
var correctedTemperature = msg.temperature + offset;
return {
    msg: msg,
    metadata: metadata,
    msgType: msgType
};

Originator Telemetry

Kategorie: Anreicherung
Ausgänge: Success, Failure

Der Knoten liest historische Telemetriewerte des Ursprungs aus einem Zeitfenster und ergänzt sie in den Metadaten.

Konfiguration

Bereich	Felder
Datenauswahl	`latestTsKeyNames`, `fetchMode` mit `FIRST`, `LAST` oder `ALL`.
Zusatzfelder bei `ALL`	`aggregation`, `orderBy`, `limit`.
Zeitfenster	`useMetadataIntervalPatterns`, `startInterval`, `startIntervalTimeUnit`, `endInterval`, `endIntervalTimeUnit`, `startIntervalPattern`, `endIntervalPattern`.

Hinweise

Bei FIRST oder LAST wird ein einzelner Wert pro Schlüssel ergänzt.
Bei ALL werden Werte als JSON-Array in den Metadaten abgelegt.

Beispiel

Für einen Vergleich mit dem Durchschnitt der letzten fünf Minuten kann temperature mit fetchMode = ALL geladen und anschließend in einem Transform-Skript ausgewertet werden.

*Script Knoten

var temperatureArray = metadata.temperatureArray;
var total = 0;
var avgTemp = 0;

for (var i = 0; i < temperatureArray.length; i++) {
    total += temperatureArray[i];
}

if (temperatureArray.length > 0) {
    avgTemp = total / temperatureArray.length;
}

msg.avgTemp = avgTemp;

return {
    msg: msg,
    metadata: metadata,
    msgType: msgType
};

Originator Fields

Kategorie: Anreicherung
Ausgänge: Success, Failure

Der Knoten liest Stammdatenfelder des Ursprungs, beispielsweise Name oder Typ, und schreibt sie unter konfigurierbaren Namen in die Metadaten.

Konfiguration

Label	Pflichtfeld	Beschreibung
Fields Mapping	Ja	Zuordnung von Entity-Feldnamen zu Metadatenschlüsseln.

Quellfeld	Bedeutung
`name`	Anzeigename des Gerätes
`type`	Entitätstyp, `DEVICE`
`label`	Label der Entität
`additionalInfo`	Zusätzliche Informationen als JSON
`createdTime`	Erstellungszeitpunkt als Epoch-Millisekunden

Beispiel

Mit name -> deviceName kann ein nachfolgender To Email-Knoten ${deviceName} im Betreff verwenden.

Tenant Details

Kategorie: Anreicherung
Ausgänge: Success, Failure

Der Knoten ergänzt Kontakt- und Adressdaten des Tenants in den Nachrichtentext oder in die Metadaten.

Konfiguration

Label	Pflichtfeld	Beschreibung
Details	Ja	Ausgewählte Tenant-Felder. Mindestens ein Feld muss gewählt werden.
Add Details to Metadata	Ja	Aktiviert: Werte werden in Metadaten geschrieben. Deaktiviert: Werte werden in den Nachrichtentext geschrieben.

Verfügbare Felder sind TITLE, EMAIL, PHONE, COUNTRY, CITY, STATE, ZIP, ADDRESS, ADDRESS2 und ADDITIONAL_INFO.

Transformations-Knoten

Script (Transform)

Kategorie: Transformation
Ausgänge: Success, Failure

Der Knoten verändert Nachrichtentext, Metadaten und/oder Nachrichtentyp per JavaScript. Das Ergebnis des Skripts wird an nachfolgende Knoten weitergegeben.

Konfiguration

Label	Pflichtfeld	Beschreibung
Transform Function	Ja	JavaScript-Funktion `Transform(msg, metadata, msgType)`.

Rückgabewert

Das Skript muss ein Objekt mit msg, metadata und msgType zurückgeben.

Beispiel

var newMsg = {};
newMsg.temperatureF = msg.temperature * 9 / 5 + 32;
newMsg.humidity = msg.humidity;

return {
    msg: newMsg,
    metadata: metadata,
    msgType: msgType
};

To Email

Kategorie: Transformation
Ausgänge: Success, Failure

Der Knoten erstellt aus der aktuellen Nachricht und ihren Metadaten ein E-Mail-Objekt.

Konfiguration

Label	Pflichtfeld	Beschreibung
From	Ja	Absenderadresse.
To	Ja	Empfängeradresse oder mehrere Empfänger durch Komma getrennt.
CC	Nein	CC-Empfänger.
BCC	Nein	BCC-Empfänger.
Subject	Ja	Betreff.
Body	Ja	E-Mail-Inhalt.

Alle Felder unterstützen Platzhalter im Format ${metadataKey}.

info

Derr Knoten to Email erzeugt nur die Email. Gesendet wird die Email mit dem Send Email Knoten, der die Kommunikation mit den SMTP Server übernimmt.

Verarbeitungskette

Externe Knoten

REST API Call

Kategorie: Extern
Ausgänge: Success, Failure

Der Knoten sendet eine HTTP-Anfrage an eine externe REST-Schnittstelle. Der aktuelle Nachrichtentext wird als Request-Payload verwendet.

Konfiguration

Label	Pflichtfeld	Beschreibung
Endpoint URL Pattern	Ja	Ziel-URL. Unterstützt `${metadata}`-Platzhalter.
Request Method	Ja	HTTP-Methode: `GET`, `POST`, `PUT`, `DELETE`.
Use Simple Client HTTP Factory	Nein	Verwendet einen einfachen HTTP-Client, z. B. für große Antworten.
Headers	Nein	HTTP-Header als Key-Value-Liste.

Ausgabe

Bei Erfolg werden status, statusCode, statusReason und headers in die Metadaten geschrieben. Der Response Body wird zum neuen Nachrichtentext.

MQTT

Kategorie: Extern
Ausgänge: Success, Failure

Der Knoten veröffentlicht den aktuellen Nachrichtentext auf einem externen MQTT-Broker. Das Topic kann über Metadaten dynamisch aufgebaut werden.

Konfiguration

Label	Pflichtfeld	Beschreibung
Topic Pattern	Ja	MQTT-Topic mit optionalen `${metadata}`-Platzhaltern.
Host	Ja	Hostname oder IP-Adresse des Brokers.
Port	Ja	Broker-Port, z. B. `1883` oder `8883`.
Connection Timeout	Ja	Verbindungs-Timeout in Sekunden.
Client ID	Nein	MQTT-Client-ID.
Clean Session	Nein	Steuert, ob Broker-Sessiondaten verworfen werden.
Enable SSL	Nein	Aktiviert TLS/SSL.

Zugangsdaten

Unterstützt werden anonymous, basic mit Benutzername/Passwort und cert.PEM für mTLS mit PEM-Zertifikaten.

Kafka

Kategorie: Extern
Ausgänge: Success, Failure

Der Knoten veröffentlicht den aktuellen Nachrichtentext als Record in einem Kafka-Topic.

Konfiguration

Label	Pflichtfeld	Beschreibung
Topic Pattern	Ja	Kafka-Topic, optional mit Metadaten-Platzhaltern.
Bootstrap Servers	Ja	Kommaseparierte Broker-Liste.
Auto Retry Times	Nein	Anzahl erneuter Sendeversuche.
Batch Size	Nein	Batchgröße in Bytes.
Time to Buffer	Nein	Wartezeit zum Sammeln von Records in Millisekunden.
Buffer Max Size	Nein	Maximaler Producer-Puffer.
Acks	Ja	Bestätigungsverhalten des Brokers.
Serializer	Ja	Serializer-Klassen.
Other Properties	Nein	Zusätzliche Kafka-Producer-Eigenschaften.

Ausgabe

Bei Erfolg werden offset, partition und topic in die Metadaten geschrieben.

RabbitMQ

Kategorie: Extern
Ausgänge: Success, Failure

Der Knoten veröffentlicht den Nachrichtentext an eine RabbitMQ-Exchange. Exchange und Routing Key können aus Metadaten gebildet werden.

Konfiguration

Label	Pflichtfeld	Beschreibung
Exchange Name Pattern	Nein	Exchange-Name. Leer bedeutet Default Exchange.
Routing Key Pattern	Nein	Routing Key.
Message Properties	Nein	AMQP-Nachrichteneigenschaften.
Host	Ja	RabbitMQ-Host.
Port	Ja	AMQP-Port.
Virtual Host	Nein	RabbitMQ Virtual Host.
Zugangsdaten	Nein	Authentifizierung.
Automatic Recovery	Nein	Automatische Wiederverbindung.
Timeouts	Nein	Verbindungs- und Handshake-Timeout.
Client Properties	Nein	Zusätzliche Client-Eigenschaften.

AWS SQS

Kategorie: Extern
Ausgänge: Success, Failure

Der Knoten sendet den aktuellen Nachrichtentext an eine AWS-SQS-Queue. Unterstützt werden Standard- und FIFO-Queues.

Konfiguration

Label	Pflichtfeld	Beschreibung
Queue Type	Ja	Standard- oder FIFO-Queue.
Queue URL Pattern	Ja	URL der SQS-Queue. Unterstützt Metadaten-Platzhalter.
Delay Seconds	Nein	Verzögerung für Standard-Queues.
Message Attributes	Nein	Zusätzliche SQS-Attribute.
AWS-Zugangsdaten	Ja	IAM-Zugangsdaten.
AWS Region	Ja	AWS-Region der Queue.

Ausgabe

Bei Erfolg werden unter anderem messageId, requestId, messageBodyMd5, messageAttributesMd5 und bei FIFO-Queues sequenceNumber ergänzt.

AWS SNS

Kategorie: Extern
Ausgänge: Success, Failure

Der Knoten veröffentlicht den aktuellen Nachrichtentext an ein AWS-SNS-Topic.

Konfiguration

Label	Pflichtfeld	Beschreibung
Topic ARN Pattern	Ja	ARN des SNS-Topics. Unterstützt Metadaten-Platzhalter.
AWS-Zugangsdaten	Ja	IAM-Zugangsdaten.
AWS Region	Ja	AWS-Region des Topics.

Ausgabe

Bei Erfolg werden messageId und requestId in die Metadaten geschrieben.

GCP Pub/Sub

Kategorie: Extern
Ausgänge: Success, Failure

Der Knoten veröffentlicht den aktuellen Nachrichtentext in einem Google-Cloud-Pub/Sub-Topic.

Konfiguration

Label	Pflichtfeld	Beschreibung
GCP Project ID	Ja	Google-Cloud-Projekt-ID.
Topic Name	Ja	Name des Pub/Sub-Topics.
GCP Service Account Key	Ja	Upload einer JSON-Datei mit Service-Account-Zugangsdaten.
Message Attributes	Nein	Zusätzliche Pub/Sub-Attribute.

Hinweis

Der Service Account benötigt die Berechtigung roles/pubsub.publisher für das Ziel-Topic.

Ausgabe

Bei Erfolg wird messageId in die Metadaten geschrieben.

Send Email

Kategorie: Extern
Ausgänge: Success, Failure

Der Knoten versendet ein E-Mail-Objekt über SMTP. Das E-Mail-Objekt muss zuvor über den Knoten To Email erzeugt werden.

Konfiguration

Label	Pflichtfeld	Beschreibung
Use General SMTP Settings	Ja	Aktiviert die systemweiten SMTP-Einstellungen.

Wenn die systemweiten SMTP-Einstellungen deaktiviert werden, können smtpProtocol, smtpHost, smtpPort, username, password, timeout, enableTls, requireTls, checkServerIdentity und sslTrustHost konfiguriert werden.

Hinweis

Wenn die eingehende Nachricht kein gültiges E-Mail-Objekt ist, läuft sie über Failure.

Scheduler-Knoten

Create Scheduled Task

Kategorie: Scheduler
Ausgänge: Success, Failure

Der Knoten plant eine einmalige Aufgabe für einen späteren Zeitpunkt. Die Aufgabe kann einen Bericht erzeugen oder eine RuleChain auslösen.

Konfiguration

Label	Pflichtfeld	Beschreibung
Job Name	Ja	Eindeutiger Name der geplanten Aufgabe.
Delay Before Start	Ja	Verzögerung bis zur Ausführung.
Type	Ja	`REPORT` oder `RULE_CHAIN`.
Rule Chain	Ja, bei `RULE_CHAIN`	Auszuführende RuleChain.
Report-Felder	abhängig vom Berichtstyp	Konfiguration für geplante Berichte.

Hinweise

Eine Aufgabe mit gleichem jobName für dieselbe Entität wird überschrieben.

Clear Scheduled Task

Kategorie: Scheduler
Ausgänge: Success, Failure

Der Knoten löscht eine zuvor geplante Aufgabe, bevor sie ausgeführt wird.

Konfiguration

Label	Pflichtfeld	Beschreibung
Job Name	Ja	Exakter Name der Aufgabe, die gelöscht werden soll.

Hinweise

Der Name muss dem Namen aus Create Scheduled Task entsprechen.
Die Zuordnung erfolgt pro Ursprungseinheit.
Existiert keine passende Aufgabe, läuft die Nachricht über Failure.

Event- und Alarm-Knoten

Complex Alarm

Kategorie: Event-Regel
Ausgänge: Success, Created, Cleared

Der Knoten erzeugt oder beendet Alarme anhand einer Event-Regel für Echtzeit-Telemetrie. Er eignet sich für Muster, die nicht über eine einfache Einzelwertprüfung abgebildet werden können.

Konfiguration

Label	Pflichtfeld	Beschreibung
Event Rule	Ja	Auswahl einer vorhandenen Event-Regel.

Hinweise

Die Event-Regel muss vor der Verwendung des Knoten angelegt sein. Siehe Event Processing
Created bedeutet, dass ein neuer Alarm geöffnet wurde.
Cleared bedeutet, dass ein bestehender Alarm beendet wurde.
Success bedeutet, dass keine Alarmzustandsänderung stattgefunden hat.

Complex Event Processing

Kategorie: Event-Regel
Ausgänge: Success, Created, Cleared

Der Knoten wendet Complex Event Processing auf bereits geladene OSF-Dateidaten an. Er ist die dateibasierte Variante zu Complex Alarm.

Konfiguration

Label	Pflichtfeld	Beschreibung
Event Rule	Ja	Auswahl der Event-Regel für die CEP-Auswertung.

Hinweise

Der Knoten wird nach Aggregate OSF File platziert.
Die Event-Regel muss vorab in der Plattform angelegt sein. Siehe Event Processing

Enrich Alarm

Kategorie: Event-Regel
Ausgänge: Success, Failure

Der Knoten reichert einen bestehenden Alarm mit zusätzlichen Informationen aus einer Excel-basierten Event-Regel an.

Konfiguration

Label	Pflichtfeld	Beschreibung
Event Rule	Ja	Auswahl einer Event-Regel mit zugehöriger Excel-Datei für die Anreicherung.

Hinweise

Die Event-Regel muss vorab in der Plattform angelegt sein. Siehe Event Processing
Die Event-Regel muss eine Excel-Datei mit Zuordnungen für Alarmtypen oder Bedingungen besitzen.
Der Knoten wird nach Create Alarm oder Complex Alarm eingesetzt.
Die ergänzten Details werden zurück in den Alarmdatensatz geschrieben.

RuleNodes​

Übersicht nach Kategorien​

Filter-Knoten​

Aktions-Knoten​

Anreicherungs-Knoten​

Transformations-Knoten​

Externe Knoten​

Scheduler-Knoten​

Event- und Alarm-Knoten​

Detailübersicht​

Filter-Knoten​

Message Type Filter​

Konfiguration​

Beispiel​

Message Type Switch​

Konfiguration​

Beispiel​

File Type Switch​

Konfiguration​

Beispiel​

File Names Filter​

Konfiguration​

Hinweise​

Beispiel​

Device Filter​

Konfiguration​

Ausgänge​

Beispiel​

Script (Filter)​

Konfiguration​

Skriptkontext​

Beispiel​

Switch​

Konfiguration​

Hinweise​

Beispiel​

Check Existence Fields​

Konfiguration​

Beispiel​

GPS Geofencing Filter​

Konfiguration​

Hinweis​

Beispiel​

Aktions-Knoten​

Save Timeseries​

Konfiguration​

Eingang​

Save Attributes​

Konfiguration​

Eingang​

Save Alarms​

Ausgänge​

Konfiguration​

Eingang​

Create Alarm​

Ausgänge​

Konfiguration​

Metadaten nach Verarbeitung​

Beispiel​

Clear Alarm​

Ausgänge​

Konfiguration​

Metadaten nach Verarbeitung​

Beispiel​

Alarm Counter​

Konfiguration​

Beispiel​

Log​

Konfiguration​

Hinweise​

Generator​

Konfiguration​

Beispiel​

Hinweis​

Message Count​

Konfiguration​

Ausgabe​

Delay​

Konfiguration​

Hinweise​

RuleNodes

Übersicht nach Kategorien

Filter-Knoten

Aktions-Knoten

Anreicherungs-Knoten

Transformations-Knoten

Externe Knoten

Scheduler-Knoten

Event- und Alarm-Knoten

Detailübersicht

Filter-Knoten

Message Type Filter

Konfiguration

Beispiel

Message Type Switch

Konfiguration

Beispiel

File Type Switch

Konfiguration

Beispiel

File Names Filter

Konfiguration

Hinweise

Beispiel

Device Filter

Konfiguration

Ausgänge

Beispiel

Script (Filter)

Konfiguration

Skriptkontext

Beispiel

Switch

Konfiguration

Hinweise

Beispiel

Check Existence Fields

Konfiguration

Beispiel

GPS Geofencing Filter

Konfiguration

Hinweis

Beispiel

Aktions-Knoten

Save Timeseries

Konfiguration

Eingang

Save Attributes

Konfiguration

Eingang

Save Alarms

Ausgänge

Konfiguration

Eingang

Create Alarm

Ausgänge

Konfiguration

Metadaten nach Verarbeitung

Beispiel

Clear Alarm

Ausgänge

Konfiguration

Metadaten nach Verarbeitung

Beispiel

Alarm Counter

Konfiguration

Beispiel

Log

Konfiguration

Hinweise

Generator

Konfiguration

Beispiel

Hinweis

Message Count

Konfiguration

Ausgabe

Delay

Konfiguration

Hinweise