In diesem Abschnitt kannst du Brücken zu Drittsystemen einrichten. Diese Brücken werden verwendet, um Prozessdaten aus anderen Systemen zu empfangen oder Aktionen in anderen Systemen auszulösen.

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 Konnektor gilt: Sobald du auf “Validieren & Speichern” klickst, werden die Änderungen validiert, wenn die Verbindung funktioniert, und der Konnektor wird direkt gespeichert. Um Konnektoren zu löschen, klicke auf den “Papierkorb”-Button.

Konnektorenübergreifende Funktionen

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

Konnektor Logs

Nachdem ein Konnektor angelegt wurde können die Details über das Stift-Symbol eingesehen und verändert werden. Hier findet sich der Tab “Konnektor Logs”. In diesem werden die letzten 100 Pakete des Konnektors angezeigt. So lässt sich einsehen, wie und ob zum Beispiel ein eingehender Konnektor Datenpakete erhalten hat. Hierdurch wird die Fehlersuche unterstützt, sollten die Daten nicht korrekt am virtuellen Gerät oder Drittsystem ankommen.

Status Logs

Nachdem ein Konnektor angelegt wurde, können die Details über das Stift-Symbol eingesehen und verändert werden. Hier findet sich der Tab “Status Logs”. Hier findet sich ein Verbindungsprotokoll, welches die letzten 100 Logs des Konnektors bezüglich des Verbindungsstatus anzeigt. Hierdurch wird die Fehlersuche unterstützt, sollten die Daten nicht korrekt am virtuellen Gerät oder Drittsystem ankommen.

Übersicht der verfügbaren Konnektoren

Die folgenden Konnektoren stehen zur Zeit in niotix zur Verfügung:

Konnektor “firefly”

Der “firefly”-Konnektor stellt eine Verbindung zu DIGIMONDOs firefly LoRaWAN Netzwerk Server her, um Downlink-Pakete an Geräte zu senden.

Gib folgende Informationen ein:

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Template: Wird im Moment nicht zum Aufbau der Verbindung benötigt, daher deaktiviert.
• apiKey: Füge den API-Schlüssel hinzu, den du in deiner firefly-Instanz erstellt hast - dieser API-Schlüssel wird benötigt, um sich am Firefly-System zu authentifizieren und Downlink-Pakete vom richtigen Konto zu senden.
• baseURL: Füge die Adresse deiner firefly-Instanz ein inklusive Protokoll (“http” oder “https”).
• Firefly MQTT Url (optional): Füge die Adresse deiner firefly RabbitMQ Instanz ein inklusive Protokoll (“mqtt” oder “mqtts”) z.B. “mqtts://messagequeue.firefly.com”. Dieses Feld muss nur ausgefüllt werden, wenn Virtuelle Geräte mit firefly angelegt werden sollen.

Konnektor “actility”

Der “actility”-Konnektor ermöglicht dir Downlinks über eine Regel im Digitalen Zwilling an Actility-Geräte zu senden.

Gib folgende Informationen ein:

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Actility Custom Target Profile: Gib die Zielorganisation von Actility an.
• baseURL: Füge die Adresse deiner Actility-Instanz ein.
• thingparkLogin: Der Benutzername für die Anmeldung.
• thingparkPassword: Das Passwort für die Anmeldung.

Konnektor “kafka”

Der “kafka”-Konnektor ermöglicht es Daten an einen Apache Kafka Broker weiterzuleiten. Ähnlich wie bei dem MQTT-Konnektor lassen sich so alle Aktualisierungen von Datenpunkten eines Digital Twins an den Kafka Cluster weiterleiten, um sie von dort weiter zu verarbeiten oder zu speichern.

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Broker: Die Adresse und Port des Kafka Brokers (im Format “Adresse:Port”).
• Client ID: Die ID des Clients.
• Topic to emit state changes: Der Titel, unter dem alle Aktualisierungen beim Kafka Broker veröffentlicht werden.
• SASL Mechanism: Die verwendete Methode zur Anmmeldung am Kafka Broker.
• SALS User: Der Benutzername für die Anmeldung.
• SALS Password: Das Passwort für die Anmeldung.

Konnektor “IEC-104 Push”

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• IEC Port: Gib hier den Port des IEC Servers an.
• IEC Server Push URL: Gib hier die URL des IEC Servers ein.
• Header Auth Type: Gib die Art der Authentifizierung an
• Header Auth Value: Gib den Wert der Authentifizierung an
• IEC Server Time UTC: Aktiviere diesen Toggle Button, um die Server Zeit auf UTC festzulegen.
• Reject invalid SSL certs: Aktiviere diesen Toggle Button, um ungültige SSL-Zertifikate abzulehnen.
• IEC k Value: Gib die maximale Anzahl unbestätigter APDUs an, die die Slave-Outstation (Geo SCADA Expert) über diesen Kanal senden soll, bevor sie auf eine Bestätigung des SCADA-Masters wartet, dass diese APDUs erfolgreich empfangen wurden.
• IEC w Value: Gib die maximale Anzahl von APDUs an, die die Slave-Außenstation auf diesem Kanal empfangen kann, bevor sie eine Bestätigung sendet, dass sie diese APDUs erfolgreich empfangen hat.
• IEC Timeout 1: Gib hier die maximale Zeit in Sekunden an, die die Slave-Outstation (Geo SCADA Expert) wartet, bis eine gesendete Application Protocol Data Unit (APDU) vom SCADA-Master als empfangen bestätigt wird.
• IEC Timeout 2: Hiermit wird die maximale Zeitspanne festgelegt, die die Slave-Outstation (Geo SCADA Expert) nach dem Empfang einer APDU im Leerlauf bleiben kann, bevor sie eine Antwort an den SCADA-Master senden muss, um anzuzeigen, dass sie die APDU erfolgreich empfangen hat.
• IEC Timeout 3: Mit dieser Funktion kann die Slave-Außenstation so eingestellt werden, dass sie in bestimmten Abständen einen Testrahmen (über den Kanal) sendet. Durch die Übertragung eines Test-Frames kann die Slave-Außenstation feststellen, ob der Kanal nach einer längeren Zeit der Kommunikationsinaktivität (es werden keine Daten über den Kanal gesendet) noch verfügbar ist.
• Whitelisted Clients (Comma Separated List): Gib hier eine durch Kommas getrennte Liste an erlaubten Clients an.
• Allow Anon. Clients: Gib an, ob anonyme Clients akzeptiert werden sollen.

Konnektor “Loriot”

Der Konnektor stellt eine Verbindung zu Ihrer Loriot-Instanz her, um Daten über WebSocket zu empfangen und Geräte aus niotix heraus zu verwalten. Ein Konnektor ist immer auf eine “Application” in Loriot begrenzt.

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 Konnector 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.

Einstellungen:

• Instanzname: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• WebSocket URL: Fügen Sie die WebSocket URL der output configuration aus der entsprechenden Application in Loriot ein.
• API Url: Fügen Sie die Basis-URL der Loriot Rest API Ihrer Instanz ein, z.B. https://eu1pro.loriot.io/
• API-Schlüssel: Erstellen Sie einen API-Schlüssel für Ihre Loriot-Instanz und fügen Sie ihn hier ein.

Konnektor “mail”

Der"mail”-Konnektor wird im Zusammenhang mit dem Regeleditor im Digital Twin verwendet. Im Regeleditor kannst du Regeln erstellen, dass bei bestimmten Wert-Entwicklungen E-Mails versendet werden. Dafür benötigst du den Konnektor. Der Mail-Konnektor unterstützt auch die Anmeldung an Mailservern ohne Zugangsdaten (User und Passwort), wie es z.B. oft bei OnPremise-Installationen in Verwendung mit einem Microsoft Exchange Server der Fall ist.

Gib folgende Informationen ein:

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Fallback “from’-mail: Eine Absendeadresse die angezeigt wird, falls z.B. in einer Digital Twin Regel keine Absendeadresse hinterlegt wird
• Service: Falls vorhanden, wähle deinen E-Mail-Service-Provider, um die Authentifizierung zu konfigurieren
• Host: Gib die Adresse des SMTP-Servers an.
• Port: Gib den Port des SMTP-Servers an.
• User: Gib den Namen des Nutzers des Servers an.
• Pass: Gib das Passwort dieses Nutzers an.
• Secure/Unsecure: Wähle mit dem Schieberegler aus, ob es sich um eine gesicherte Verbindung (TLS) handelt oder nicht.
• Ignore/UnignoreTLS: Falls die Verbindung unverschlüsselt ist (d.h. im vorherigen Punkt “unsecure”), aber mit STARTTLS erfolgen soll, muss diese Option auf “IgnoreTLS” stehen.
• Self-signed certificate: Stelle dies auf ‘accept’, falls selbst-generierte Zertifikate erlaubt seien sollen.

Konnektor “mqtt”

Der “mqtt"Konnektor stellt einen MQTT-Client dar und baut eine Verbindung zu einem MQTT-Broker auf, um Events über niotix zu senden(alle Datenpunkt Änderungen des Accounts werden an das konfigurierte Topic übertragen. Um granularere aussendungen zu machen kann der MQTT (Outgoing) - Konnektor zusammen mit einem Integrationsflow verwendet werden) oder zu empfangen (Datenpunkt oder Virtuelles Gerät).

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Template: Standardmäßig ist “pass-through” ausgewählt. Dadurch wird keines der Pakete transformiert. Sollen die Daten an Datenpunkte eines virtuellen Gerätes geschrieben werden, muss das Template “Virtual Device Inbound” gewählt und je nach Datenstruktur der gelieferten MQTT Daten entsprechend der Anweisungen im Template angepasst werden.
• Topic to emit state changes: Du kannst alle Änderungen aller Zustände deines Digital Twins an einen MQTT-Broker ausgeben. Wenn du alle Zustandsänderungen ausgeben möchtest, definiere hier das Topic. Für das Topic kannst du Platzhalter verwenden, um verschiedene Topics pro Account und/oder pro Digital Twin zu definieren (z.B. /{AccountId}/digitaltwins/{TwinId}/states/{state}”):
  • {accountId} wird durch die zugehörige Konto-ID ersetzt
  • {twinId} wird durch die zugehörige Digital Twin-ID ersetzt
  • {state} wird durch die Status-ID des entsprechenden Digital Twin ersetzt
• Username: Gebe den Benutzername des mqtt-Client-Benutzers an.
• Password: Gebe das Passwort des mqtt-Client-Benutzers an.
• Path: Gebe das Topic an, in dem neue Ereignisse veröffentlicht werden sollen.
• URL: Gebe die Adresse des MQTT-Brokers an.
• Self-signed certificate: Über dieses Auswahlfeld könnt ihr mit “accept” einstellen, dass ihr selbst signierte Zertifikate akzeptiert oder mit “reject”, dass diese nicht akzeptiert werden. So lassen sich die mit dem MQTT-Broker ausgetauschten Daten verschlüsselt übertragen.

Konnektor “MQTT(Outgoing)”

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

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• url: Geben Sie die vollständige Url und den Port an, z.B. mqtts://mybroker.cloud:8883
• Self-signed certificated: Setzen Sie diese Option auf accept, wenn Sie selbstsignierte Zertifikate zulassen wollen
• Client-ID: optional - geben Sie eine statische Client-ID an, wenn dies für den Broker erforderlich ist. Wenn Sie diese Option leer lassen, wird bei der Verbindung automatisch eine Client-ID generiert.

Konnektor “mqttbroker”

Der “mqttbroker"Konnektor stellt einen MQTT-Client dar, der auf einen im niotix Service-Verbund installierten RabbitMQ eine Verbindung aufbaut, ein Topic erzeugt und Anmeldedaten (Benutzer und Passwort) erstellt. Danach “published” der Konnektor Daten auf das automatisch erstellte Topic, die dann von “Subscribed” MQTT Clients empfangen werden können. Dieser Konnektor sollte also dann eingesetzt werden, wenn die Daten-empfangende Gegenstelle einen MQTT Client zur Verfügung hat.

So legst du einen “mqttbroker” Konnektor an:

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Klicke auf “Validieren & Speichern”, das Topic und die Anmeldedaten werden daraufhin automatisch erstellt und angezeigt.

Überlegungen zur Quality of Service (QoS)

Der “mqttbroker”-Konnektor erlaubt es, eine QoS zu definieren, wenn er in einem Integrationsflow verwendet wird. Die folgenden Einstellungen können vorgenommen werden:

• 0 - Höchstens einmal
• 1 - Mindestens einmal
• 2 - Genau einmal

Die Voreinstellung ist “0 - Höchstens einmal”. Wenn für den Anwendungsfall eine höhere Zuverlässigkeit erforderlich ist, werden die beiden anderen Optionen unterstützt. In diesen Fällen ist es notwendig, dass der abonnierende Client eine kohärente QoS verwendet, eine Client-ID angibt und clean session auf false setzt. Bei entsprechender Konfiguration wird niotix Nachrichten in eine Queue stellen, wenn die Verbindung des abonnierenden Clients unterbrochen wird. Die Menge der in der Queue befindlichen Daten wird durch die Größe des Volumens begrenzt, das dem RabbitMQ zur Verfügung steht (bei SaaS-Nutzung von niotix achten wir darauf, dass dieses Volumen angemessen dimensioniert ist, um Ihre Daten zu verarbeiten).

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.

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• apiKey: Gib den API-Schlüssel an, den du in deinem niota 1.0-Tenant definiert hast. Dieser API-Schlüssel wird benötigt, um sich am niota 1.0-System zu authentifizieren und nur Daten vom richtigen Konto zu empfangen.
• baseURL: Gib die Adresse deiner niota 1.0-Instanz an.

Konnektor “openweathermap.org”

Der “openweathermap.org”-Konnektor bietet eine Möglichkeit, Wetterinformationen von der openweathermap.org-Plattform zu empfangen. Mit diesem Konnektor kannst du aktuelle Wetterinformationen wie Temperatur, Luftfeuchtigkeit, Wind, etc. für verschiedene Orte weltweit empfangen inklusive einer Vorhersage für bis zu 6 Tage. Die Vorhersage für Regen ist für den aktuellen Tag möglich.

Um den “openweathermap.org”-Konnektor einzurichten, musst du dich bei openweathermap.org registrieren und dort einen API-Schlüssel einrichten.

Gib folgende Informationen ein:

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• API-Key: Füge den API-Schlüssel hinzu, den du in deiner openweathermap.org-Instanz erstellt hast.
• City: Wähle den Ort, für den Sie Wetterinformationen verwenden möchten.
• Units (Einheiten): Wähle zwischen metrischem oder imperialem System für die Angabe der Einheiten.
• Update interval (Aktualisierungsintervall): Wähle den Zeitintervall, wie oft niotix aktualisierte Informationen abrufen soll.

Konnektor “smartservice”

Der “smartservice”-Konnektor baut eine Verbindung zu den Lösungen von Thüga SmartService her. Wenn du Interesse an diesem Konnektor hast, kontaktiere deinen DIGIMONDO-Ansprechpartner.

Gib folgende Informationen ein:

• Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• API-Key: Füge den API-Schlüssel hinzu.
• Value timestamp from: Wähle zwischen “api” oder “generated”.
• Update Interval: Wähle aus, in welchem Zeit-Intervall das Update des Konnektors erfolgen soll.

Konnektor “Things Stack”

Dieser Konnektor stellt eine Verbindung zu einem LoRaWAN-Netzwerkserver des Typs The Things Network oder The Things Industries her, um mit virtuellen Geräten Daten zu empfangen und Geräte aus niotix heraus in The Things Network/Industries zu verwalten. 

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.

Einstellungen:

• Instanzname: der individuelle Name des Konnectors
• Beschreibung: eine interne Beschreibung
• API Url: Geben Sie die Basis-URL der The Things Network/Industries Rest API Ihrer Instanz ein, z.B. https://eu1.cloud.thethings.network/api/v3/
• API-Schlüssel: Erstellen Sie einen API-Schlüssel für Ihre The Things Network/Industries-Instanz und fügen Sie ihn hier ein.

Konnektor “Webhook (Outgoing)”

Der “Webhook (Outgoing)"-Konnektor ermöglicht es, aus niotix mittels Webhook Daten an Drittsysteme zu senden. So kann z.B. eine Regel im Digitalen Zwilling ein individualisiertes JSON an eine Webhook-Adresse versenden. Zum Testen der Verbindung empfehlen wir - sofern keine eigenen Lösungen zur Verfügung stehen - kostenlose und offene Plattformen wie webhook.site.

Gib folgende Informationen ein:

• Instanz Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Header Auth Type: Gib an, wie niotix sich am Webhook-Empfänger authentifiziert (falls - wie bei webhook.site - keine Authentifizierung benötigt wird: “None”).
• Header Auth Value: Gib den Wert (z.B. Schlüssel) für die Authentifizierung an (wenn der “Header Auth Type=none” ist, wird das Feld leer gelassen).
• Method: Wähle die HTTP-Methode aus (z.B. für webhook.site ist dies “POST”).
• WebhookURL: Gib die Adresse des Drittsystem-Webhooks an (inklusive “https://…”).

Konnektor “Webhook (Incoming)”

Dieser Konnektor erlaubt es Daten per HTTP POST an ein virtuelles Gerät als eingehende Pakete zu senden. Die URL für den HTTP POST Request wird automatisch erzeugt und kann aus dem Feld “API Endpunkt” kopiert werden. Der Body des Requests muss vom Typ application/json sein und sollte die folgende Default Struktur haben:

{
    "id": "4711",
    "timestamp": "2022-08-19T13:11:05.068Z",
    "payload": {
        "key1" : "value1",
        "key2" : "value2"
    }
}

oder

{
    "id": "4711",
    "timestamp": "2022-08-19T13:11:05.068Z",
    "payload": "01AB02DEF0"
}

Die id ist die Externe ID des Virtuellen Geräts. Sollte der JSON Body in einem beliebigen anderen Format vorliegen, kann er im Template Script umgeformt werden, dazu die Vorlage Virtual Device Inbound auswählen und den Anweisungen in den Code-Kommentaren folgen.

Konnektor “websocket”

Der “websocket”-Konnektor ermöglicht es aus niotix per wss Daten an einen Websocket-Server weiterzugeben. Zum Testen der Verbindungen können - sofern keine eigenen Lösungen zur Verfügung stehen - kostenlose und offene Websocket-Server wie Pie Socket oder Socketbay verwendet werden.

Gib folgende Informationen ein:

• Instanz Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Connection timeout (ms): Gib hier an nach wie vielen Millisekunden der Request wegen Timeouts abgebrochen werden soll. Ist das Feld leer sind es 10 Sekunden.
• Websocket Url: Gib die Adresse des Websocket-Servers an mit dem die Verbindung aufgebaut werden soll (inklusive “wss://…”)