Konnektoren sind die Schnittstellen, über die niotix mit der Außenwelt verknüpft wird.

Eingehende Konnektoren binden externe Datenquellen und Plattformen an. Typisch sind LoRaWAN-Netzwerk-Server (z.B. firefly, ChirpStack, Things Stack, Loriot), dazu generische Eingänge wie MQTT (Incoming) und Webhook (Incoming); je nach Setup kommen weitere Quellen (z.B. LwM2M Server) hinzu. Sie sind der Einstieg in niotix: Sie liefern Roh- oder Prozessdaten und halten – wo der Konnektor das vorsieht – Gerätebestände zwischen niotix und externen Plattformen konsistent, sodass Datenaufnahme und Lifecycle an einer Stelle zusammenlaufen können.

Funktionsprofile unterscheiden sich je nach Konnektor. Möglich sind u.a.:

• Gerätemanagement — Synchronisation von Anlegen, Lesen, Aktualisieren und Löschen mit dem externen System
• Datenquelle für Virtuelle Geräte und/oder Digitale Zwillinge
• Regeln/Kommandos (z.B. Downlinks an Endgeräte)
• reine Datenaufnahme ohne die obigen Profile

So lässt sich pro Schnittstelle klar definieren, ob niotix primär Daten empfängt, Geräte spiegelt oder beides kombiniert. Für unterstützte Netzwerk-Server und Protokolle vereinheitlicht niotix das Lifecycle-Management der Endgeräte: Statt Geräte und Metadaten parallel in mehreren Oberflächen zu pflegen, bleibt niotix die führende Stelle für Anlage, Import, Aktualisierung und Löschung in Richtung des jeweiligen Zielsystems – im Rahmen der jeweiligen Konnektor-Fähigkeiten.

Ausgehende Konnektoren übertragen Daten an nachgelagerte Systeme, u.a. über Webhook (Outgoing), MQTT(Outgoing), Kafka (Outgoing), Websocket oder MQTT Broker.Ausführliche Einstellungen in den verlinkten Konnektor-Abschnitten unter Ausgehende Konnektoren. Einsatz u.a. bei Alarmen, Zustandsänderungen, aggregierten Kennzahlen oder fortlaufender Datenweitergabe an Fachanwendungen und Integrationslandschaften (z.B. Data Lakes, OT‑Systeme, Benachrichtigungskanäle).

In Integrationsflows bilden die Schritte typischerweise eine Kette: Auslöser (z.B. neuer Messwert, Alarm) → Filter (nur für das Ziel relevante Events) → Transformationen (Struktur und Format) → ausgehender Konnektor zum Zielsystem. Filter und Transformationen reduzieren und strukturieren den Datenumfang vor der Ausleitung.

XAPI und ausgehende Konnektoren ergänzen sich: Ereignisse und aktuelle Zustände laufen in der Regel über Flows sowie Push- bzw. Streaming-Kanäle; historische Zeitreihen lassen sich bei Bedarf über die XAPI aus der Datenbank abfragen, ohne sie in denselben Echtzeit-Pfad zu legen.

Konnektorenübergreifende Funktionen

Die folgenden Funktionen stehen für alle Konnektoren gleichermaßen zur Verfügung:

Anlegen eines Konnektors

Um einen neuen Konnektor hinzuzufügen, wähle im Anlegen-Dialog den Typ des Konnektors aus. Der Pfeil neben dem Namen des Konnektors im Menü zeigt an, ob es sich um einen eingehenden Konnektor (Pfeil nach unten) zum Daten-Empfang in niotix oder einen ausgehenden Konnektor (Pfeil nach oben) zum Daten-Versand handelt. Im Anschluss an die Auswahl werden die benötigten Konnektoreinstellungen angezeigt.

Für alle Konnektoren gilt: Beim ersten Anlegen im Dialog lautet die Schaltfläche „Validieren & Speichern“; in der Konnektor-Detailansicht (nach dem Speichern) heißt sie „Sichern“ – jeweils wird zuerst validiert und bei erfolgreicher Prüfung gespeichert. Zum Löschen dient in der Konnektorliste das Papierkorb-Symbol; die Löschung erfolgt nach Bestätigung im Dialog.

Konnektor Logs

Nachdem ein Konnektor angelegt wurde, sind die Details über das Stift-Symbol in der Liste erreichbar und dort bearbeitbar. Im Tab Konnektor Logs werden die letzten 100 vom Konnektor verarbeiteten Datenpakete (eingehend und ausgehend) mit Zeitstempel und Payload angezeigt; die Liste lässt sich aktualisieren und durchsuchen. Die Suche umfasst sowohl Payload als auch Metadaten; der Suchbegriff wird in der URL gespeichert, sodass gefilterte Ansichten als Link geteilt werden können. Das unterstützt die Fehlersuche, wenn Daten nicht wie erwartet ankommen.

Status Logs

Im Tab Status Logs derselben Detailansicht ist ein Verbindungsprotokoll mit den letzten 100 Statusmeldungen (u.a. erfolgreiche und fehlgeschlagene Verbindungsversuche) zu finden, ebenfalls mit Aktualisieren und Suche. Auch das dient der Fehlersuche bei Verbindungsproblemen.

Übersicht der verfügbaren Konnektoren und der Funktionen

Die Tabellen sind nach eingehenden und ausgehenden Konnektoren getrennt — entsprechend der Einordnung in der Oberfläche (Pfeil nach unten bzw. nach oben im Menü).

Eingehende Konnektoren

Ausgehende Konnektoren

Beschreibung der Funktionen

• Gerätemanagement: Der Konnektor bietet eine Gerätesynchronisation mit dem externen System (Anlegen, Lesen, Aktualisieren, Löschen); je nach Konnektor können einzelne Operationen fehlen (z. B. ohne vollständiges Lesen aus dem Zielsystem).
• Datenpunkt Virtuelles Gerät: Der Konnektor kann als Quelle für Datenpunkte im Virtuellen Gerät verwendet werden
• Datenpunkt Digitaler Zwilling: Der Konnektor kann als Quelle für Datenpunkte im Digitalen Zwilling verwendet werden
• Regeln: Der Konnektor kann zum Senden von Kommandos verwendet werden
• Datenweiterleitung: Der Konnektor kann zur Weiterleitung von Datenpunkten verwendet werden (Integrationsflows)

Eingehende Konnektoren

Generische eingehende Konnektoren wie MQTT(Incoming) und Webhook (Incoming) besitzen im UI das Feld Template. Dieses Feld enthält die Transformation der eingehenden Daten in das interne niotix-Standarddatenformat. Da diese Konnektoren mit unterschiedlichsten Systemen und Geräten verwendet werden können, muss das Template auf das jeweilige Quelldatenformat abgestimmt werden. Das erwartete Eingangsdatenformat ist im Abschnitt Datenformat für eingehende Daten beschrieben.

Konnektoren für spezifische Cloud-Systeme oder Protokolle (z.B. firefly, ChirpStack, Things Stack, LwM2M Server) verwenden eine fest integrierte Standard-Transformation, die das jeweilige systemspezifische Format automatisch in das niotix-Format überführt. Eine manuelle Template-Konfiguration ist hier in der Regel nicht erforderlich.

Pass-through: Wenn die Daten bereits im niotix-Standarddatenformat ankommen, kann das Template „Pass-through" (bzw. pass-through) verwendet werden. Der Payload wird dann unverändert weitergeleitet.

JavaScript-Transformation: Entspricht das eingehende Format nicht dem niotix-Standarddatenformat, kann eine eigene JavaScript-Funktion hinterlegt werden. Mit Klick auf den Stift-Button öffnet sich der Editor zum Eingeben und Testen der Transformation. Die Funktion wird als Body eingegeben, der Rahmen ist fest vorgegeben: module.exports = (packet) => { ... }. Das Argument packet entspricht dem Eingangsformat des Konnektors.

Beispiel — eingehendes Paket einer externen Quelle:

{
  "deviceId": "sensor-42",
  "timestamp": "2025-03-21T09:26:04Z",
  "payload": {
    "temperature": 21.5,
    "humidity": 58
  }
}

Passende Transformation, die daraus das niotix-Standardformat erzeugt:

module.exports = (packet) => {
  return {
    identifier: packet.deviceId,
    data: {
      value: {
        payload: packet.payload
        },
      time: packet.timestamp     // optional; fehlt dieser Wert, wird die Systemzeit verwendet
    }
  };
};

Die Felder identifier, data entsprechen dem niotix-Standardformat für Virtuelle Geräte; alternativ kann routing für eine Adressierung von Digitalen Zwillingen über Referenz-ID-Schlüssel verwendet werden — Details dazu im Abschnitt Adressieren von Datenpunktupdates über Datenrouting.

Konnektor “Chirpstack”

Der Konnektor stellt eine Verbindung zur Chirpstack-Instanz her: Uplinks werden per Webhook (HTTP POST) empfangen; Gerätemanagement und Downlinks erfolgen über die Chirpstack REST API. Ein Konnektor ist immer auf eine “Application” in Chirpstack begrenzt. Der Konnektor unterstützt die Chirpstack Versionen 3 und 4.

Details zur Funktion:

• Authentifizierung: API-Schlüssel (Bearer Token)
• Datenpfad (eingehend): Webhook-basiert — Chirpstack sendet Uplinks per HTTP POST an niotix
• Chirpstack-Version: v3 oder v4 (Standard: v4); für v4 ist zusätzlich die Tenant ID erforderlich
• API-Timeout: 2.000 ms
• Downlink-Parameter (konfigurierbar im Virtuellen Gerät oder in einer Regel):
  • EUI — EUI des Zielgeräts als Hex-String (16 Zeichen, Pflichtfeld)
  • data — Downlink-Payload als Hex-String (Pflichtfeld)
  • port — LoRaWAN FPort, Standard: 0
  • confirmed — Bestätigter Downlink, Standard: false
  • pending — Als Pending markieren, Standard: false

Unterstützte Remote-Aktionen:

• Gerät erstellen: Unterstützt. Virtuelle Geräte, die in niotix erstellt werden, werden automatisch in der Application erstellt, auf die der Konnektor verweist.
• Gerät importieren: Unterstützt. Virtuelle Geräte, die bereits in Chirpstack vorhanden sind, können über ihre EUI importiert werden.
• Gerät aktualisieren: Unterstützt. Konnektorspezifische Eigenschaften die im Virtuellen Gerät verändert werden, wie zum Beispiel Region oder der Titel, werden auch in Chirpstack verändert.
• Gerät löschen: Unterstützt. Virtuelle Geräte, die in niotix gelöscht werden, werden automatisch aus der Chirptstack-Application gelöscht (wenn die Option “Gerät im externem Service beim Löschen” aktiviert ist).
• Downlink senden: Unterstützt. Es können Downlinks aus dem Virtuellen Gerät oder einer Regel im Digitalen Zwilling versendet werden.

Konnektor “firefly”

Der “firefly”-Konnektor stellt eine bidirektionale Verbindung zu DIGIMONDOs firefly LoRaWAN Netzwerk Server her: Uplink-Daten werden über eine MQTT-Subscription empfangen; Downlinks und Gerätemanagement erfolgen über die firefly REST API.

Details zur Funktion:

• Authentifizierung: API-Schlüssel (für REST API und MQTT)
• Protokoll: REST API (Gerätemanagement, Downlinks) + MQTT (Datenempfang via RabbitMQ-Subscription)
• API-Timeout: 2.000 ms; MQTT-Timeout: 2.000 ms
• Downlink-Parameter (konfigurierbar im Virtuellen Gerät oder in einer Regel):
  • eui — EUI des Zielgeräts (Pflichtfeld)
  • payload — Downlink-Payload (Pflichtfeld)
  • encoding — Kodierung: utf8 (Standard), base16, base64
  • port — LoRaWAN FPort, Standard: 0
  • confirmed — Bestätigter Downlink, Standard: false
• Multicast-Downlink: Unterstützt (per Multicast-ID mcid)
• Geräteparameter (Standard): Aktivierungsmodus OTAA; Region EU868; RX2 Data Rate 0 (SF 12 / BW 125 kHz)

Unterstützte Remote-Aktionen:

• Gerät erstellen: Unterstützt. Virtuelle Geräte, die in niotix erstellt werden, werden automatisch in der Organisation erstellt, auf die der Konnektor verweist.
• Gerät importieren: Unterstützt. Virtuelle Geräte, die bereits in Firefly vorhanden sind, können über ihre EUI importiert werden.
• Gerät aktualisieren: Unterstützt. Konnektorspezifische Eigenschaften die im Virtuellen Gerät verändert werden, wie zum Beispiel Region oder der Titel, werden auch in Firefly verändert.
• Gerät löschen: Unterstützt. Virtuelle Geräte, die in niotix gelöscht werden, werden automatisch aus der Firefly-Organisation gelöscht (wenn die Option “Gerät im externem Service beim Löschen” aktiviert ist).
• Downlink senden: Unterstützt. Es können Downlinks aus dem Virtuellen Gerät oder einer Regel im Digitalen Zwilling versendet werden.

Konnektor “Loriot”

Der Konnektor stellt eine Verbindung zur Loriot-Instanz her: Uplink-Daten werden über WebSocket empfangen; Downlinks und Gerätemanagement erfolgen über die Loriot REST API. Ein Konnektor ist immer auf eine “Application” in Loriot begrenzt.

Details zur Funktion:

• Authentifizierung: API-Schlüssel
• Protokoll: WebSocket (Datenempfang) + REST API (Gerätemanagement, Downlinks)
• WebSocket-Heartbeat: 10 Sekunden; Verbindungs-Timeout: 30 Sekunden ohne eingehende Nachricht
• Rate Limiting: Standardmäßig deaktiviert; aktivierbar (Standard wenn aktiv: 6 Nachrichten / 2 Sekunden, konfigurierbar)
• Downlink-Parameter (konfigurierbar im Virtuellen Gerät oder in einer Regel):
  • EUI — EUI des Zielgeräts (Pflichtfeld)
  • data — Downlink-Payload (Pflichtfeld)
  • encoding — Kodierung: utf8 (Standard), base16, base64
  • port — LoRaWAN FPort, Standard: 0
  • confirmed — Bestätigter Downlink, Standard: false
• Aktivierungsmodi: OTAA (Standard) und ABP werden unterstützt

Unterstützte Remote-Aktionen:

• Gerät erstellen: Unterstützt. Virtuelle Geräte, die in niotix erstellt werden, werden automatisch in der Application erstellt, auf die der Konnektor verweist.
• Gerät importieren: Unterstützt. Virtuelle Geräte, die bereits in Loriot vorhanden sind, können über ihre EUI importiert werden.
• Gerät aktualisieren: Unterstützt. Konnektorspezifische Eigenschaften die im Virtuellen Gerät verändert werden, wie zum Beispiel Region oder der Titel, werden auch in Loriot verändert.
• Gerät löschen: Unterstützt. Virtuelle Geräte, die in niotix gelöscht werden, werden automatisch aus der Loriot-Anwendung gelöscht (wenn die Option “Gerät im externem Service beim Löschen” aktiviert ist).
• Downlink senden: Unterstützt. Es können Downlinks aus dem Virtuellen Gerät oder einer Regel im Digitalen Zwilling versendet werden.

Konnektor “LwM2M Server”

Der Konnektor “LwM2M Server” ist Bestandteil des Moduls “LwM2M Server” und ermöglicht eine Einbindung von LwM2M-Geräten in niotix.

Details zur Funktion:

• Authentifizierung: OAuth2 (Benutzername/Passwort gegenüber dem LwM2M-Server); Access Token wird beim Validieren automatisch erzeugt und ist schreibgeschützt
• API-Timeout: 2.000 ms
• Datenpfad (eingehend): Webhook-basiert — LwM2M-Geräte senden Uplinks per HTTP POST an niotix; Gegenstelle ist der LwM2M-Server
• Sicherheitsmodi: PSK (PreShared Key, Schlüssel als Hex-String) oder NoSec (unverschlüsselt, nur für Entwicklung)
• Server-Typen: Management Server oder Bootstrap Server — wird pro Gerät konfiguriert
• Rate Limiting: 1.000 Nachrichten / 5 Sekunden
• Downlinks: Nicht unterstützt

Konnektor “MQTT(Incoming)”

Der “MQTT(Incoming)” Konnektor stellt einen MQTT-Client dar und baut eine Verbindung zu einem MQTT-Broker auf, um Messdaten in niotix zu verarbeiten. Er wird typischerweise in zwei Szenarien eingesetzt:

• Anbindung von Cloud-Systemen: Systeme wie GWA-Plattformen, die Daten über MQTT publizieren, werden direkt als Datenquelle angebunden.
• Anbindung über einen zwischengeschalteten Broker: In Kombination mit dem MQTT-Broker-Konnektor oder einem externen MQTT-Broker können netzgebundene Geräte – typischerweise über LTE oder NB-IoT – eingebunden werden. Die Geräte bauen selbst eine ausgehende Verbindung zum Broker auf; eine eingehende Verbindung zum Sensor ist nicht erforderlich. Typische Beispiele sind Fernwirkanlagen oder IoT-Router.

Details zur Funktion:

• Authentifizierung: Benutzername und Passwort (optional); optional zertifikatsbasiert — CA-Zertifikat, Client-Zertifikat und Client-Schlüssel für TLS/mTLS konfigurierbar
• MQTT Version: 3.1.1
• TLS/WebSocket: Verschlüsselung durch mqtts:// im URL-Feld; WebSocket-Verbindungen über ws:// oder wss:// ebenfalls unterstützt
• QoS (Subscribe): Standard 1 (konfigurierbar)
• Clean Session: Standard Yes
• Keepalive-Intervall: 60 Sekunden (MQTT.js-Standard)
• Verbindungs-Timeout: 2.000 ms; automatischer Reconnect nach 5.000 ms — das Topic-Abonnement wird dabei automatisch erneuert
• Nachrichtenformat: JSON wird geparst; Arrays werden elementweise verarbeitet (max. 50 Objekte je Nachricht, konfigurierbar); bei Parsefehler wird der Wert als Rohstring weitergeleitet

Konnektor “niota”

Der “niota”-Konnektor stellt eine Verbindung zu einer bestehenden Instanz von niota 1.0/IoT Data Hub her, um Gerätedaten von einem ausgewählten Konto zu empfangen.

Konnektor “openweathermap.org”

Der “openweathermap.org”-Konnektor empfängt Wetterdaten von der openweathermap.org-Plattform und stellt sie als Datenpunkte im Digitalen Zwilling bereit. Verfügbar sind aktuelle Messwerte sowie eine Vorhersage für bis zu 7 Tage (Regen-Tagesprognose für den aktuellen Tag).

Für die Einrichtung des Konnektors ist eine Registrierung bei openweathermap.org sowie das Anlegen eines API-Schlüssels dort erforderlich.

Details zur Funktion:

• Authentifizierung: API-Schlüssel
• API: openweathermap.org One Call API v3
• Datenpunkte (Auswahl): Aktuelle Werte (cur_temperature, cur_humidity, cur_pressure, cur_wind_speed, cur_wind_direction, cur_uv_index, cur_clouds_pct); tägliche Vorhersage für heute sowie bis zu 6 Folgetage (today_temp_day/night/min/max, today_wind_speed, today_rain_mm, today_uv_index u. a.)
• Abrufintervall: Wählbar: 1 Min., 10 Min., 30 Min., 1 Std., 6 Std., 12 Std., 1 Tag; Standard (intern): 60 Minuten
• Einheiten: metrisch oder imperial
• Downlinks / Gerätemanagement: Nicht unterstützt

Konnektor “smartservice”

Der “smartservice”-Konnektor baute eine Verbindung zu den Lösungen von Thüga SmartService her.

Konnektor “Things Stack”

Dieser Konnektor stellt eine Verbindung zu einem LoRaWAN-Netzwerkserver des Typs The Things Network oder The Things Industries her: Uplinks werden über MQTT empfangen; Gerätemanagement und Downlinks erfolgen über die TTS REST API.

Details zur Funktion:

• Authentifizierung: API-Schlüssel (Bearer Token)
• Protokoll: MQTT (Datenempfang, TLS-verschlüsselt) + REST API (Gerätemanagement, Downlinks)
• MQTT-Timeout: 2.000 ms
• Aktivierungsmodi: OTAA (Standard) und ABP werden unterstützt
• LoRaWAN-Klassen: A (Standard), B (Beaconing), C (Continuous), B+C
• Gerät aktualisieren: Nicht unterstützt — Änderungen an konnektorspezifischen Gerätefeldern werden nicht in TTS zurückgeschrieben
• Downlink-Parameter (konfigurierbar im Virtuellen Gerät oder in einer Regel):
  • deviceId — End-Device-ID des Zielgeräts (Pflichtfeld)
  • frm_payload — Downlink-Payload (Pflichtfeld)
  • encoding — Kodierung: hex (Standard), base64
  • f_port — LoRaWAN FPort, Standard: 1
  • confirmed — Bestätigter Downlink, Standard: false

Unterstützte Remote-Aktionen:

• Gerät erstellen: Unterstützt. Virtuelle Geräte, die in niotix erstellt werden, werden automatisch in der Things Network/Industries Instanz erstellt, auf die der Konnektor verweist.
• Gerät importieren: Unterstützt. Virtuelle Geräte, die bereits in der Things Network/Industries Instanz existieren, können anhand ihrer Endgeräte-ID importiert werden.
• Gerät aktualisieren: Das Aktualisieren des Geräts im remote System wird noch nicht unterstützt.
• Gerät löschen: Unterstützt. Virtuelle Geräte, die in niotix gelöscht werden, werden automatisch aus der The Things Network/Industries Instanz gelöscht.
• Downlink senden: Unterstützt. Senden eines Downlinks von niotix zum Sensor über die verbundene The Things Network/Industries Instanz.

Konnektor “Webhook (Incoming)”

Der „Webhook (Incoming)“-Konnektor stellt einen HTTP-Endpunkt bereit, über den externe Systeme Daten per HTTP POST an niotix senden können. Er wird typischerweise verwendet, um andere Cloud-Systeme anzubinden, die ausgehende Webhooks unterstützen – beispielsweise IoT-Plattformen, Monitoring-Systeme oder Automatisierungslösungen. Die Endpunkt-URL wird automatisch generiert und kann aus dem schreibgeschützten Feld „API Endpunkt“ kopiert werden.

Details zur Funktion:

• Authentifizierung: Token-basiert — das Token wird automatisch erzeugt und ist im Feld „API Endpunkt“ als ?token=<token> enthalten. Alternativ kann der Token direkt (ohne Bearer-Prefix) im Authorization-Header übergeben werden: Authorization: <token>.
• HTTP-Methode: POST; OPTIONS wird für CORS-Preflight unterstützt (Antwort: 204).
• Nachrichtenformat: Der Body muss gültiges JSON sein. Der Content-Type-Header wird serverseitig nicht geprüft; application/json wird empfohlen.
• Batch-Verarbeitung: Ein einzelnes JSON-Objekt oder ein Array von Objekten. Die maximale Array-Größe beträgt standardmäßig 50 Einträge und ist per Umgebungsvariable (INCOMING_WEBHOOK_MAX_BATCH_SIZE) konfigurierbar.
• Fehler-Antworten: 400 bei ungültigem JSON oder überschrittenem Array-Limit; 401 ohne Token; 403 bei unbekanntem Token oder deaktiviertem Konnektor.
• Rate Limiting: Intern begrenzt auf 1.000 Anfragen pro 5 Sekunden (konfigurierbar per Umgebungsvariable).

Das eingehende Datenformat wird über das Template in das niotix-Standardformat transformiert — siehe Abschnitt Eingehende Konnektoren. Wenn die Quelldaten bereits im niotix-Format ankommen, genügt „Pass-through“. Für abweichende Formate kann eine JavaScript-Transformation hinterlegt werden.

Konnektor “Wireless M-Bus Decoder”

Der Konnektor Wireless M-Bus Decoder ist Bestandteil des Moduls “Wireless M-Bus Decoder” und ermöglicht eine einfache Dekodierung und Entschlüsselung von Wireless M-Bus Nachrichten (wM-Bus), welche von einem wM-Bus-Konzentrator über einen Konnektor an niotix gesendet werden.

Ausgehende Konnektoren

Ausgehende Konnektoren senden Daten aus niotix an externe Systeme — typischerweise ausgelöst durch einen Integrationsflow. Das Datenformat, das ein ausgehender Konnektor erhält, entspricht dem niotix-internen Ausgabeobjekt des Integrationsflows (z.B. das „After state handling”-Objekt mit meta- und value-Feldern).

Muss das Format an die Anforderungen des Zielsystems angepasst werden, kann im Integrationsflow vor dem ausgehenden Konnektor eine Transformation eingebunden werden. Transformationen können in JavaScript oder JSONata geschrieben und direkt in der Oberfläche getestet werden.

Konnektor “actility”

Der “actility”-Konnektor ermöglicht das Senden von LoRaWAN-Downlinks an Aktility-Geräte über die ThingPark-API. Er wird ausschließlich als Aktion in einer Regel im Digitalen Zwilling eingesetzt.

Details zur Funktion:

• Authentifizierung: OAuth2 Client Credentials — client_id = <CustomTargetProfile>/<Login>, client_secret = Passwort; das Token wird automatisch vor jedem Request erneuert (kein manuelles Token-Management erforderlich)
• Standard-baseURL: https://dx-api.thingpark.com (wird verwendet, wenn das Feld leer gelassen wird)
• API-Timeout: 2.000 ms
• Downlink-Parameter (konfigurierbar in der Regel im Digitalen Zwilling):
  • eui — EUI des Zielgeräts (Pflichtfeld)
  • payloadHex — Downlink-Payload als Hex-String (Pflichtfeld)
  • port — LoRaWAN-Port (FPort), Standard: 0
  • confirmed — Bestätigter Downlink, Standard: false
  • flushQueue — Bestehende Downlink-Queue leeren, Standard: false
• Erfolgsprüfung: Die Actility-API muss mit status: "QUEUED" antworten — andernfalls wird der Fehler in das Konnektor-Log geschrieben

Konnektor “IEC-60870-5-104 Push”

Der IEC-60870-5-104 Push Konnektor ist ein ausgehender Konnektor in niotix, welcher mit einem Integrationflow Daten an den niotix IEC-104-Server sendet. Die Ausgehenden Pakete enthalten neben den Standard-Metadaten auch das Objekt outbound_values, welches die IEC-104-Adressen enthält.

Konnektor “kafka”

Der “kafka”-Konnektor ermöglicht die Weiterleitung von Datenpunkten an einen Apache Kafka-Cluster. Er wird als Konnektorschritt in einem Integrationsflow verwendet und kann Zustandsänderungen eines Digitalen Zwillings für die weitere Verarbeitung oder Speicherung an den Cluster senden.

Details zur Funktion:

• Authentifizierung: Optional — SASL PLAIN (Benutzername/Passwort); optional TLS/SSL (boolesch)
• Nachrichtenformat: Jede Nachricht enthält einen zufällig erzeugten UUID-Schlüssel, die Payload als String-Wert sowie den festen Header origin: niotix
• Bestätigungsmodus (acks): Standard -1 (alle In-Sync-Replicas müssen bestätigen)
• Publish-Timeout: Standard 30.000 ms
• Verbindungs-Timeout: 500 ms; bei Fehler 2 Wiederholungsversuche (Initial Retry Time: 100 ms)
• Topic: Wird je Nachricht im Integrationsflow definiert — Topics müssen im Kafka-Cluster vorab angelegt sein

Konnektor “mail”

Der “mail”-Konnektor dient zum E-Mail-Versand aus niotix heraus und wird in zwei Szenarien eingesetzt:

• Regeleditor im Digitalen Zwilling: Im Regeleditor können Regeln erstellt werden, die beim Eintreten bestimmter Wert-Entwicklungen E-Mails versenden.
• Systemmails: Der Konnektor kann auf Konto-Ebene als SMTP-Relay für niotix-Systemmails konfiguriert werden (z. B. Passwort-Reset, Willkommens-E-Mail, Benachrichtigungen). Die Zuordnung erfolgt in der Konto-Verwaltung unter E-Mail-Einstellungen → Mail-Konnektor verwenden.

Details zur Funktion:

• Protokoll: SMTP via Nodemailer; unterstützte Felder je Nachricht: from, to, cc, bcc, subject, text, html, Anhänge
• Authentifizierung: Benutzername/Passwort oder OAuth2 — automatische Token-Erneuerung nur für Outlook365(OAuth2.0) implementiert (inkl. einmaligem Retry bei Authentifizierungsfehler 535); alle anderen Dienste verwenden Nodemailer-Standard-Auth
• TLS: Secure → implizites TLS ab Verbindungsaufbau (typischerweise Port 465); Unsecure → Verbindung beginnt unverschlüsselt, STARTTLS wird vom Server angeboten; IgnoreTLS → STARTTLS-Aushandlung wird deaktiviert (rein unverschlüsselte Übertragung)
• Verbindungs-Timeout: 2.000 ms (TCP-Verbindung zum SMTP-Server); Gesamttimeout des Sendevorgangs: 15 Sekunden
• Retry: Kein automatischer Retry (außer Outlook 365 OAuth2: ein Retry nach Token-Erneuerung bei Fehler 535)
• Rate Limiting: Optional pro Stunde konfigurierbar; ohne Angabe gilt kein Limit

Konnektor “MQTT(Outgoing)”

Der “MQTT(Outgoing)"-Konnektor ermöglicht die Verbindung zu externen MQTT-Brokern und kann als Konnektorschritt in Integrationsflows verwendet werden. Topic und Quality of Service werden in den Einstellungen des Integrationsflows definiert.

Details zur Funktion:

• Authentifizierung: Benutzername und Passwort (optional); kein mutual TLS — Zertifikatsvalidierung über rejectUnauthorized (Standard: reject)
• MQTT Version: 3.1.1
• TLS/WebSocket: Verschlüsselung durch mqtts:// im URL-Feld; WebSocket-Verbindungen über ws:// oder wss:// ebenfalls unterstützt
• QoS (Publish): Standard 0; konfigurierbar im Integrationsflow (0 / 1 / 2)
• Clean Session: Standard Yes
• Keepalive-Intervall: 60 Sekunden (MQTT.js-Standard)
• Verbindungs-Timeout: 2.000 ms; automatischer Reconnect nach 5.000 ms bei Verbindungsverlust
• Nachrichtenformat: Payload wird als String unverändert übertragen (typischerweise JSON aus dem Integrationsflow)

Konnektor “mqttbroker”

Der “mqttbroker”-Konnektor nutzt einen im niotix Service-Verbund installierten RabbitMQ (mit MQTT-Plugin) als MQTT-Broker. Beim Validieren werden ein Topic und Anmeldedaten (Benutzer und Passwort) automatisch erstellt; der Nutzer wird in RabbitMQ angelegt. Der Konnektor veröffentlicht (publish) Daten auf dieses Topic; externe MQTT-Clients können die Daten durch Subscriben (subscribe) empfangen. Der Konnektor eignet sich, wenn die datenempfangende Gegenstelle einen MQTT-Client einsetzt.

Details zur Funktion:

• Authentifizierung: Benutzername und Passwort werden beim ersten Validieren automatisch erzeugt und sind schreibgeschützt — eine manuelle Eingabe ist nicht erforderlich
• MQTT Version: 3.1.1
• Topic: Wird automatisch generiert (Format: <vhost>/<uuid>/#); externe Clients abonnieren dieses Topic, niotix publiziert auf <vhost>/<uuid>
• QoS (Publish): Fest 0 — der abonnierende Client kann abweichende QoS-Stufen verwenden (siehe Hinweis unten)
• Clean Session: Standard true
• Keepalive-Intervall: 60 Sekunden (MQTT.js-Standard)
• Verbindungs-Timeout: 2.000 ms; automatischer Reconnect nach 5.000 ms bei Verbindungsverlust
• Nachrichtenformat: Payload wird als String unverändert übertragen (typischerweise JSON aus dem Integrationsflow)

Konnektor “Webhook (Outgoing)”

Der “Webhook (Outgoing)"-Konnektor ermöglicht es, aus niotix Daten per HTTP an externe Systeme zu senden. Er wird als Konnektorschritt in einem Integrationsflow verwendet. Zum Testen der Verbindung können – sofern keine eigene Lösung zur Verfügung steht – kostenlose und offene Plattformen wie webhook.site verwendet werden.

Details zur Funktion:

• HTTP-Methoden: POST (Standard), PUT, GET, PATCH
• Authentifizierung: None (Standard), Basic Auth, Bearer Token, X-API-Key, API-Key — konfiguriert über Header Auth Type und Header Auth Value
• Custom Headers: Beliebige zusätzliche HTTP-Header als JSON-Objekt konfigurierbar (z. B. {"X-Custom-Header": "wert"})
• Nachrichtenformat: Standard application/json; alternativ application/x-www-form-urlencoded; der Payload wird als JSON-String übergeben und vor dem Senden geparst
• Immer gesendete Header: User-Agent: webhook connector, Content-Type gemäß Encoding-Einstellung
• Timeout: Standard 2.000 ms (auswählbar: 1.000 / 2.000 / 3.000 / 5.000 / 10.000 ms); gilt für den gesamten Request (kein separater Connect/Read-Timeout)
• Retry: Kein automatischer Retry bei HTTP-Fehlern — ein Versuch pro Nachricht
• Fehlerbehandlung: Non-2xx-Antworten und Antwort-Bodies mit error-Feld werden als Fehler behandelt und ins Konnektor-Log geschrieben
• TLS: Standard rejectUnauthorized: true — selbstsignierte Zertifikate werden abgelehnt (deaktivierbar)

Konnektor “Websocket”

Der “Websocket”-Konnektor baut eine ausgehende WebSocket-Verbindung zu einem externen Server auf und überträgt Datenpunkte als Echtzeit-Datenstrom. Er wird als Konnektorschritt in einem Integrationsflow verwendet. Zum Testen der Verbindung können – sofern keine eigene Lösung zur Verfügung steht – kostenlose und offene Dienste wie Pie Socket oder Socketbay verwendet werden.

Details zur Funktion:

• Protokoll: RFC 6455 WebSocket (Bibliothek: ws v7); Verschlüsselung durch Verwendung von wss:// im URL-Feld
• Authentifizierung: Keine integrierte Authentifizierung — Zugangsdaten können bei Bedarf als Query-Parameter in der URL übergeben werden (z. B. wss://server.example.com/data?token=<token>)
• Nachrichtenformat: Raw Payload-String (UTF-8 Text-Frame), kein zusätzlicher Envelope durch niotix
• Verbindungs-Timeout: Standard 10.000 ms (konfigurierbar im Einstellungsfeld)
• Reconnect: Keine automatische Wiederverbindung nach Verbindungsabbruch
• Keep-alive / Ping-Pong: Nicht konfiguriert