Überblick

niotix bringt drei MQTT-Konnektoren mit, die unterschiedliche Rollen im Datenfluss abdecken:

Konnektor	Richtung	Rolle
mqttbroker	eingehend & ausgehend	stellt einen Zugriffsbereich auf dem niotix-Broker bereit, auf dem niotix-Konnektoren und externe Clients publizieren und subscriben können
MQTT (Incoming)	eingehend	niotix als MQTT-Client (Subscriber): abonniert einen Broker und empfängt Daten
MQTT (Outgoing)	ausgehend	niotix als MQTT-Client (Publisher): publiziert Daten aus Integrationsflows an einen externen Broker

Welcher Konnektor passt, hängt davon ab, wo der Broker steht und wer Daten liefert bzw. abholt:

• niotix-eigener Broker: Der mqttbroker stellt einen Zugriffsbereich auf dem von niotix betriebenen Broker bereit – Topic und Zugangsdaten werden automatisch erzeugt, die Gegenstelle benötigt nur einen MQTT-Client.
• Daten nach niotix hinein: Publiziert ein externes System (z. B. eine GWA-Plattform, ein IoT-Router oder ein Gateway) auf einen MQTT-Broker, abonniert MQTT (Incoming) diesen Broker. Netzgebundene Geräte – typischerweise über LTE oder NB-IoT – bauen dabei selbst die ausgehende Verbindung zum Broker auf; eine eingehende Verbindung zum Gerät ist nicht erforderlich. Als zwischengeschalteter Broker kann ein externer Broker oder der niotix-eigene mqttbroker dienen.
• Daten aus niotix an einen fremden Broker: MQTT (Outgoing) als Konnektorschritt im Integrationsflow.

mqttbroker

Der “mqttbroker”-Konnektor stellt einen Zugriffsbereich auf dem von niotix betriebenen MQTT-Broker (RabbitMQ mit MQTT-Plugin) bereit. Darauf können sowohl niotix – etwa Integrationsflows (publish) oder ein MQTT (Incoming)-Konnektor (subscribe) – als auch externe MQTT-Clients publizieren und subscriben.

Beispiel für das Parent-Topic consumers/1a2b3c4d:

Zulässig:

• Subscribe auf das Parent-Topic samt Sub-Topics, z. B. consumers/1a2b3c4d/# oder consumers/1a2b3c4d/data
• Publish auf das Parent-Topic oder ein Sub-Topic, z. B. consumers/1a2b3c4d/data

Nicht zulässig (der Broker trennt die Verbindung):

• Subscribe auf die globale Wildcard # oder andere Topics außerhalb des eigenen Parent-Topics
• Subscribe auf System-Topics ($SYS/...)
• Publish außerhalb des eigenen Parent-Topics

Verbindungsdaten

Für die Anbindung eines Clients sind nur die Angaben im Tab „Verbindungsdaten" der Konnektor-Detailansicht relevant. Dort stehen nach dem Validieren:

• URL: Adresse des MQTT-Brokers inkl. Port
• Benutzername und Passwort: automatisch erzeugt, schreibgeschützt
• Topic: das Parent-Topic (Format <vhost>/<uuid>); Clients subscriben z. B. auf <vhost>/<uuid>/#, niotix publiziert auf das Parent-Topic

Einstellungen

• Instanz-Name: Ein individueller, leicht verständlicher Name für den Konnektor.
• Beschreibung: Eine kurze Beschreibung.
• Mit “Validieren & Speichern” werden das Topic und die Anmeldedaten automatisch erstellt und angezeigt.

Hinweise für Clients

• MQTT-Version: 3.1.1
• Keep Alive: Standard auf der SaaS ist 60 Sekunden. Werden häufige Reconnects des Clients beobachtet, den Keep-Alive-Wert im Client etwas kleiner setzen (z. B. 55 Sekunden).
• QoS: niotix publiziert mit der im Integrationsflow festgelegten QoS (Standard 0); der Client setzt die Subscribe-QoS in seiner Bibliothek — wirksam ist das Minimum aus Publish- und Subscribe-QoS.
• Clean Session / Client-ID: Für QoS 1/2 und vom Broker gepufferte Zustellung clean session = false und eine stabile Client-ID verwenden — siehe QoS-Hinweis unten.
• Nachrichtenformat: Der Payload wird als String unverändert übertragen (typischerweise JSON aus dem Integrationsflow).

TLS und Zertifikate

Die Verbindung zum Broker erfolgt ausschließlich per MQTTS (MQTT über TLS) über den nach dem Validieren angezeigten Endpunkt; unverschlüsseltes mqtt:// ist auf der SaaS (niotix.io) nicht vorgesehen. Die Anmeldung erfolgt über den automatisch erzeugten Benutzernamen und das Passwort – ein Client-Zertifikat ist nicht erforderlich.

In den meisten Fällen ist nichts weiter zu tun: Die TLS-Serverzertifikate der SaaS stammen von Let’s Encrypt, und übliche Betriebssysteme wie auch Embedded-Systeme mit Linux und Zertifikatsspeicher (Trust Store) bringen die nötige öffentliche Vertrauenskette bereits mit.

Nur wenn kein aktueller Trust Store vorhanden ist (z. B. eingebettete Systeme mit älterer Firmware), muss das Root-Zertifikat ISRG Root X1 als Vertrauensanker in der Firmware bzw. MQTT-Bibliothek hinterlegt werden. Die PEM-Datei steht auf der Let’s-Encrypt-Download-Seite bereit (Direktdownload: isrgrootx1.pem).

Weitere Hinweise:

• Certificate Pinning auf das konkrete Serverzertifikat (oder den öffentlichen Schlüssel) ist möglich; bei einem Zertifikatswechsel am Broker muss die Gerätekonfiguration dann angepasst werden.
• Das Abschalten der TLS-Zertifikatsprüfung ist nur in abgeschotteten Testumgebungen vertretbar, nicht als dauerhafte Produktionslösung.

Hinweise für On-Premise-Administratoren

• Dedizierte RabbitMQ-Instanz: Für diesen Konnektor ist eine dedizierte RabbitMQ-Instanz (mit MQTT-Plugin) einzurichten — der interne niotix-RabbitMQ sollte nicht verwendet werden. Eine gemeinsam genutzte Instanz genügt für alle Konnektoren dieses Typs.
• Zertifikate: Wird der Broker mit einem selbstsignierten Zertifikat oder einer eigenen Firmen-CA betrieben, muss die zugehörige CA bzw. das Serverzertifikat in den MQTT-Clients als vertrauenswürdig hinterlegt werden.

MQTT (Incoming)

Der “MQTT(Incoming)” Konnektor stellt einen MQTT-Client (Subscriber) 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 mqttbroker-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: Wahlweise Basic Auth oder mutual TLS (mTLS). Für Basic Auth sind Benutzername und Passwort erforderlich. Für mTLS sind Client-Zertifikat und Client-Schlüssel erforderlich; optional kann zusätzlich ein CA-Zertifikat zur Serverprüfung hinterlegt werden
• 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

Einstellungen

• Instanz-Name: Ein individueller, leicht verständlicher Name für den Konnektor.
• Beschreibung: Eine kurze Beschreibung.
• Template: Standardmäßig ist “Pass-through” ausgewählt (keine Transformation).
• Topic to emit state changes (deprecated): Diese Funktion ist veraltet und sollte nicht weiter verwendet werden. Als Alternative steht der dedizierte “MQTT(Outgoing)"-Konnektor zur Verfügung, der mittels Integrationsflow verwendet werden kann. Alle Änderungen aller Zustände eines Digitalen Zwillings können an einen MQTT-Broker ausgegeben werden. Dafür kann hier das Topic definiert werden. Für das Topic können Platzhalter verwendet werden, um verschiedene Topics pro Konto und/oder pro Digitalem Zwilling zu definieren (z. B. /{accountId}/digitaltwins/{twinId}/states/{state}):
  • {accountId} wird durch die zugehörige Konto-ID ersetzt
  • {twinId} wird durch die ID des Digitalen Zwillings ersetzt
  • {state} wird durch die Status-ID des entsprechenden Digitalen Zwillings ersetzt
• Username: Benutzername des MQTT-Clients. Erforderlich bei Basic Auth.
• Password: Passwort des MQTT-Clients. Erforderlich bei Basic Auth.
• Server-Zertifikat (CA): Optional. CA-Zertifikat des Brokers zur Verifizierung der Server-Identität (TLS/SSL).
• Client-Zertifikat: Client-Zertifikat zur Authentifizierung des Clients gegenüber dem MQTT-Broker. Erforderlich bei mTLS.
• Client-Schlüssel: Privater Schlüssel zum Client-Zertifikat; wird zusammen mit dem Client-Zertifikat für die zertifikatsbasierte Authentifizierung verwendet. Erforderlich bei mTLS.
• Topic: Topic, auf das der Konnektor subscribed (z. B. exampletopic/#). Eintreffende Nachrichten werden hier empfangen.
• URL: Adresse des MQTT-Brokers inkl. Protokoll und Port (z. B. mqtts://mybroker.cloud:8883).
• Self-signed certificate: Mit “accept” können selbstsignierte Zertifikate zugelassen werden, mit “reject” werden sie abgelehnt. Ermöglicht verschlüsselte Übertragung mit dem MQTT-Broker.
• Client-ID: Optional. Statische Client-ID, wenn vom Broker gefordert; andernfalls wird beim Verbindungsaufbau automatisch eine erzeugt.
• Clean session: “Yes” (Standard) oder “No” – legt fest, ob die Session beim Trennen bereinigt wird (persistente Subscriptions bei “No”).
• QoS: Quality of Service für das Abonnement: 0, 1 oder 2 (Standard: 1).

MQTT (Outgoing)

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

Details zur Funktion:

• Authentifizierung: Wahlweise Basic Auth oder mutual TLS (mTLS). Für Basic Auth sind Benutzername und Passwort erforderlich. Für mTLS sind Client-Zertifikat und Client-Schlüssel erforderlich; optional kann zusätzlich ein CA-Zertifikat zur Serverprüfung hinterlegt werden
• 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)

Einstellungen

• Instanz-Name: Ein individueller, leicht verständlicher Name für den Konnektor.
• Beschreibung: Eine kurze Beschreibung.
• URL: Vollständige Broker-URL inkl. Protokoll und Port (z. B. mqtts://mybroker.cloud:8883).
• Username: Benutzername des MQTT-Clients. Erforderlich bei Basic Auth.
• Password: Passwort des MQTT-Clients. Erforderlich bei Basic Auth.
• Server-Zertifikat (CA): Optional. CA-Zertifikat des Brokers zur Verifizierung der Server-Identität (TLS/SSL).
• Client-Zertifikat: Client-Zertifikat zur Authentifizierung des Clients gegenüber dem MQTT-Broker. Erforderlich bei mTLS.
• Client-Schlüssel: Privater Schlüssel zum Client-Zertifikat; wird zusammen mit dem Client-Zertifikat für die zertifikatsbasierte Authentifizierung verwendet. Erforderlich bei mTLS.
• Self-signed certificate: Mit “accept” können selbstsignierte Zertifikate zugelassen werden, mit “reject” werden sie abgelehnt. Ermöglicht verschlüsselte Übertragung mit dem MQTT-Broker.
• Client-ID: Optional. Statische Client-ID, wenn vom Broker gefordert; andernfalls wird beim Verbindungsaufbau automatisch eine erzeugt.
• Clean session: “Yes” (Standard) oder “No” – ob die Session beim Trennen bereinigt wird.
• Rate limit (per hour): Maximale Anzahl Nachrichten pro Stunde an den Broker. Bei Überschreitung verwirft niotix weitere Requests und schreibt einen Eintrag in die Konnektor Logs.