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 und der Funktionen

Beschreibung der Funktionen

• Gerätemanagement: Der Konnektor bietete eine Gerätesynchronisation in ein externes System (Anlegen, Lesen, Aktualisieren, Löschen)
• 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)

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 “Chirpstack”

Der Konnektor stellt eine Verbindung zu Ihrer Chirpstack-Instanz her, um Daten über Webhook zu empfangen und Geräte aus niotix heraus zu verwalten. Ein Konnektor ist immer auf eine “Application” in Chirpstack begrenzt. Der Konnektor unterstützt die Chirpstack Versionen 3 und 4.

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

Einstellungen:

• Instanzname: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• Chirpstack Version: Wähle aus für welche Chirpstack Version der Konnektor verwendet werden soll.
• Base URl: Füge die Basis-URL der Chirpstack Instanz ein unter die die API erreichbar ist.
• API-KEY: Erstelle einen API-Schlüssel für den Chirpstack Tenenat und füge ihn hier ein.
• Application ID: Die Id der Application aus Chirpstack für die der Konnektor erstellt werden soll.
• Template: Das Template “Chirpstack v3” ist ebenfalls kompatibel mit der Version 4. Spezifische Änderungen bei der Datentransformation können hier bei Bedarf vorgenommen werden.

Konnektor “firefly”

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

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

Einstellungen:

• 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 “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.

Folgende Einstellungen können im Konnektor vorgenommen werden:

• Instanz-Name: Gib dem Konnektor einen individuellen Namen.
• Beschreibung: Gib eine kurze Beschreibung an.
• IEC Port: Gib hier den Port des niotix IEC-104-Servers an.
• IEC Server Push URL: Gib hier die URL des niotix EC-104-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 der niotix IEC-104-Server über diesen Kanal senden soll, bevor er auf eine Bestätigung des Leitsystems wartet, dass diese APDUs erfolgreich empfangen wurden.
• IEC w Value: Gib die maximale Anzahl von APDUs an, die der niotix IEC-104-Server auf diesem Kanal empfangen kann, bevor er eine Bestätigung sendet, dass er diese APDUs erfolgreich empfangen hat.
• IEC Timeout 1: Gib hier die maximale Zeit in Sekunden an, die der niotix IEC-104-Server wartet, bis eine gesendete Application Protocol Data Unit (APDU) vom Leitsystem als empfangen bestätigt wird.
• IEC Timeout 2: Hiermit wird die maximale Zeitspanne festgelegt, die er niotix IEC-104-Server nach dem Empfang einer APDU im Leerlauf bleiben kann, bevor er eine Antwort an das Leitsystem senden muss, um anzuzeigen, dass er die APDU erfolgreich empfangen hat.
• IEC Timeout 3: Mit dieser Funktion kann der niotix IEC-104-Server so eingestellt werden, dass er in bestimmten Abständen einen Testrahmen (über den Kanal) sendet. Durch die Übertragung eines Test-Frames kann der niotix IEC-104-Server 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.
• IEC Server Push URL: In diesem Feld wird die URL eingetragen, unter welcher der HTTP-Listener der IEC-104 Server erreichbar ist.

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 “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.
• Rate limit (per hour): Definiere hier wie viele Mails pro Stunde von niotix über diesen Konnektor versendet werden dürfen. Wird das Limit überschritten verwirft niotix die Mails und schreibt einen Log-Eintrag in das Konnektor-Log.

Konnektor “MQTT(Incoming)”

Der “MQTT(Incoming)” 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:(deprecated) Diese Funktion ist veraltet und sollte nicht weiter verwendet werden. Als Alternative steht hier mittlerweile der dedizierte “MQTT(Outgoing)” Konnektor zur Verfügung der mittels Integrationsflow verwender werden kann. 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.
• Rate limit (per hour): Definiere hier wie viele Messages pro Stunde an den Broker gesendet werden dürfen. Wird das Limit überschritten verwirft niotix die Requests und schreibt einen Log-Eintrag in das Konnektor-Log.

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.
• Connection timeout(ms): Standardwert ist 2000 Millisekunden. Bitte verwenden Sie einen höheren Wert nur, wenn das Drittsystem regelmäßig länger braucht, um zu antworten, da diese Einstellung zu einer hohen Anzahl offener Verbindungen führen kann.”
• 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://…”).
• Rate limit (per hour): Definiere hier wie viele Requests pro Stunde an den Service der definierten WebhookUrl gesendet werden dürfen. Wird das Limit überschritten verwirft niotix die Requests und schreibt einen Log-Eintrag in das Konnektor-Log.

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://…”)

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.

Gib folgende Informationen ein:

• Instanz Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
• Beschreibung: Gib eine kurze Beschreibung an.