IIoT Connector¶

Übersicht¶

Der IIoT Connector ist ein MQTT-Client, der eine Verbindung zu einem MQTT-Broker aufbauen kann. Sobald die Verbindung hergestellt ist, kann der IIoT-Connector Nachrichten veröffentlichen oder abonnieren.

Es können unterschiedliche Systeme angebunden werden:

MQTT Broker (z. B. Mosquitto oder HiveMQ)
easyConnect (Weidmüller IIoT Cloud-Plattform)
ResMa® (Weidmüller Energie- und Prozessdatensoftware onPremise)

Der IIoT Connector unterstützt die MQTT Versionen v5 und v3.1.1.

Connector-Übersicht¶

Übersicht zur Verwaltung bestehender Connectoren sowie Einstiegspunkts für das Hinzufügen neuer Connectoren.

Connector hinzufügen: Einstiegspunkt für das Hinzufügen eines Connectors. Nach Klick öffnet eine Auswahl, bei der das Ziel gewählt wird, mit dem verbunden werden soll. Zur Auswahl stehen Azure IoT Hub, ResMa®, easyConnect oder ein MQTT-Broker.
Name: Name des Connectors in der Übersicht. Der Name wird vom Benutzer während des Hinzufügens gewählt. Eine nachträgliche Bearbeitung ist nicht möglich.
Ziel: Zieltyp, mit dem der Connector verbunden ist. Beispielsweise Azure IoT Hub oder MQTT.
Verbindungsstatus: Aktueller Status der Verbindung. Hier kann abgelesen werden, ob der Connector mit dem Ziel verbunden oder inaktiv ist. Auch Lizenzinformationen werden hier angezeigt.
Nachrichtenübersicht: Anzahl der gesendeten und empfangenen Nachrichten.
Optionen-Menü: Einstiegspunkt für Optionen des jeweiligen Connectors wie bspw. Verbinden, Bearbeiten oder Löschen.
Globale Verbindungsanzeige: Die globale Verbindungsanzeige erscheint, wenn mindestens ein bestehender Connector keine Verbindung zu seinem Ziel aufbauen konnte.

MQTT Connector¶

Die Konfiguration des MQTT Connectors ist in vier Tabs unterteilt: Kommunikation, Sicherheit, Konfiguration und Puffer.

Kommunikation¶

In diesem Tab werden grundlegende Konfigurationen für den Verbindungsaufbau hinterlegt.

Connectorname: Kann frei vergeben werden, muss jedoch eindeutig sein.
MQTT URL: Gültige URL des MQTT-Brokers, mit dem verbunden werden soll.
Cloudkommunikation: Bei Deaktivierung können keine Werte außerhalb des eigenen Netzwerkes empfangen oder gesendet werden.
Zeitintervall Keep-Alive: Das Intervall legt fest, wie oft ein Ping-Signal gesendet wird, um die Verbindung zum Broker aufrechtzuerhalten (Standard: 180 Sekunden). Ein kürzeres Intervall erhöht die Verbindungsstabilität, während ein längeres die Netzwerklast verringert.
MQTT Protokoll: Version des Protokolls. Die Version muss auf den anzubindenden MQTT-Broker angepasst werden. Die Version beeinflusst bzw. die verwendeten Status-Codes in der Kommunikation zwischen MQTT-Client und MQTT-Broker.

Sicherheit¶

In diesem Tab wird der Authentifizierungsmechanismus konfiguriert.

Authentifizierung: Gültiger Benutzer und Passwort für den Connector.
Zertifikate: Client-Zertifikate aktivieren und über den Button hochladen.

Konfiguration¶

Konfiguration von Topics, Quality of Service, Retain und Last Will.

Client-ID: Eindeutige ID.
Publish Definition: Topic für die Übertragung der Metrik-Metadaten. Für Details siehe Payloads.
Publish Instance: Topic für die Übertragung der Zeitreihenwerte. Für Details siehe Payloads.
Subscribe Instance: Topic für das Lesen der Zeitreihenwerte.
Last Will: Die Last Will Nachricht informiert den Broker darüber, welche Nachricht er an die Abonnenten senden soll, falls der Client unerwartet die Verbindung verliert. Damit können andere Teilnehmer über den Ausfall des Clients benachrichtigt werden.

Puffer (Buffering)¶

Beim Einsatz des IIoT-Connectors stellt das Buffering sicher, dass Nachrichten auch unter instabilen Netzwerkbedingungen oder bei kurzen Verbindungsabbrüchen korrekt zugestellt werden können.

Funktionsweise der Puffers¶

Der Nachrichtenversand wird durch den IIoT-Connector durchgehend überwacht.
Kann eine Nachricht nicht versendet werden, wird ein Nachrichtenpuffer eingerichtet.
Größe und Speichermedium des Puffers werden durch die Puffer-Konfiguration bestimmt.
Die erste Nachricht, die nicht versandt werden konnte, wird in den Puffer aufgenommen.
Alle weiteren Nachrichten werden der Warteschlange des Puffers sequenziell geordnet hinzugefügt, solange keine Verbindung zum Ziel besteht.
Bei Überschreiten der maximalen Nachrichtenanzahl wird die älteste Nachricht des Puffers durch die neueste Nachricht überschrieben.
Sobald wieder eine Verbindung zum Ziel besteht, wird der Puffer abgearbeitet.
Die Abarbeitung erfolgt sequenziell von alt nach neu.
Entstehen neue Nachrichten während der Abarbeitung des Puffers, werden diese dem Puffer hinzugefügt, bis er vollständig abgearbeitet ist.
Der Puffer wird nach vollständiger Abarbeitung der Warteschlange geschlossen und die Nachrichten werden wieder direkt übertragen.

Behandlung von Nachrichten mit Quality of Service 0¶

Nachrichten, die mit Quality of Service 0 (QoS 0) übertragen werden, werden niemals gepuffert. Per Definition ist die Übertrag einer QoS 0 Nachricht nicht garantiert. Bei einer QoS 0 wird die Nachricht höchstens einmal übertragen. Der MQTT-Broker sendet bei QoS 0 auch keine Bestätigung an den Sender, ob die Nachricht erhalten wurde. Für Details siehe Quality of Service (QoS).

Default-Werte¶

Neue Connectoren werden mit folgender Puffer-Konfiguration angelegt:

Anzahl der gepufferten Nachrichten: 1000
Puffer-Art: RAM

Puffer-Konfiguration¶

Anzahl der gepufferten Nachrichten: Diese Option legt die Größe des Ringpuffers fest. Bei Überschreiten wird die älteste Nachricht mit der neuesten Nachricht überschrieben. Wählen Sie die Anzahl der gepufferten Nachrichten basierend auf den Anforderungen Ihrer Anwendung und der verfügbaren Hardware. Achten Sie bei der Hardware in Abhängigkeit der gewählten Puffer-Art auf ausreichend Reserven bei RAM bzw. Festplattenspeicher.
Puffer-Art: Die Pufferung kann flüchtig im RAM (Arbeitsspeicher) oder Persistent auf dem Dateisystem gespeichert werden.

RAM: Performanter als persistente Pufferung. Eignet sich beim Einsatz auf Steuerungen und Gateways. Bei Neustart des Dienstes oder des Gerätes wird der Puffer unwiderbringlich verworfen. Die RAM-Auslastung des Geräts muss bei der Konfiguration konkret berücksichtigt werden.

Persistent: Gepufferte Nachrichten bleiben beim Neustart von Dienst oder Gerät erhalten. Der persistente Speicher muss ausreichend dimensioniert sein. Der Pufferprozess führt zu einer Vielzahl von Schreibzyklen auf dem Dateisystem, was die Lebensdauer der Hardware ggf. beeinträchtigen kann.

Payloads¶

Für eine auslastungsoptimierte Übertragung werden Metrikdefinition und Zeitreihenwerte getrennt übertragen.

Definition Payload¶

JSON Beispiel

[
   {
      "addProps": [
         {
            "cloud": "publish"
         }
      ],
      "arrayQualifier": {
         "maxLength": 10,
         "minLength": 0
      },
      "baseDataType": "Double",
      "definitionUuid": "f6adfde5-07a9-414f-b71b-d5144ab4099a",
      "deviceUuid": "6883f158-561a-4d28-8281-8fe471b0427d",
      "name": "Temperature"
      "numericQualifier": {
         "defaultDecimalCount": "2",
         "lowerBound": "0.00",
         "upperBound": "100.00"
      },
      "subType": "None"
   }
]

addProps: Additional properties, die der User frei setzen kann. Dieser Abschnitt ist optional. Konfiguration über Tag-Editor in UI möglich.
arrayQualifier: Maximale und minimale Länge von Arrays. Wird auch für Strings verwendet. minLength ist dann immer 0, maxLength die maximale String-Länge.
baseDataType: Datentyp des Tags.
definitionUuid: UUID des Tags. Über diese kann ein JOIN mit der Instance Payload gemacht werden.
name: Tag-Name.
numericQualifier: Datentypspezifische Zusatzinformationen für Numerics. Dieser Abschnitt wird nur für numerische Werte übermittelt. Anzahl der Dezimalstellen, Minimalwert und Maximalwert.
subType: Subtyp, bspw. Ressourcenzähler. Konfiguration über Tag-Editor in UI möglich.

Instance Payload¶

JSON Beispiel

[
   {
      "arrayIndex": 1,
      "definitionUuid": "f6adfde5-07a9-414f-b71b-d5144ab4099a",
      "metricValue": {
         "type": "double",
         "value": 0
      },
      "statusCode": "GOOD",
      "timestamp": 1744120850000
   }
]

arrayIndex: Index innerhalb des Arrays. Für einfache Werte immer 1.
definitionUuid: UUID der Tag-Definition. Über diese kann ein JOIN mit der Definition Payload gemacht werden.
type: Datentyp des Tags.
value: Wert der Tags.
statusCode: Qualität der Übertragung. BAD weißt auf veraltete Werte hin, bspw. wenn der Tag nicht gelesen werden konnte oder die Verbindung zur Steuerung abgebrochen ist.
timestamp: Zeitstempel des Wertes als UNIX-Timestamp im Millisekundenformat.

Datendefinitionen¶

Für jeden der hinzugefügten Connectoren können Datendefinitionen hinzugefügt werden. Mithilfe dieser Datendefinitionen können einzelne oder mehrere definierte Werte zusammengefasst, übermittelt oder gelesen werden.

Durch Aufklappen des Connectors in der Übersicht erscheint eine Übersicht über die bereits erstellten Datendefinitionen sowie der Button Datendefinition hinzufügen.

Im anschließenden Dialog werden zuerst die allgemeinen Einstellungen getätigt.

Clouddatendefinitionsname: Zwingend erforderlich, muss eindeutig sein.
Verbindungstyp: Zur Auswahl stehen:
- Sende Tags bei Werteänderung (publish)
- Sende Tags periodisch (publish) > Hier muss anschließend noch der Zyklus und die Zeiteinheit festgelegt werden
- Lese Tags (subscribe)

Im Tab Tags können dann die Variablen ausgewählt werden, die überwacht werden sollen.

Quality of Service (QoS)¶

Der Quality of Service (QoS) in einem MQTT-Client legt fest, wie Nachrichten zwischen Client und Broker übermittelt werden. Es gibt drei QoS-Stufen: 0, 1 und 2. Jede Stufe bietet eine unterschiedliche Balance zwischen Zuverlässigkeit und Performance. QoS-Stufen

QoS 0 – „At most once“ (Maximal einmal)
- Funktionsweise: Die Nachricht wird einmal gesendet, ohne dass der Sender eine Bestätigung vom Empfänger erhält. Es gibt keine Garantie, dass die Nachricht ankommt.
- Performance: Höchste Performance, da keine Bestätigungen notwendig sind und die Übertragung nur einmal erfolgt.
- Anwendungsfall: Geeignet für unkritische Daten, bei denen es nicht auf die zuverlässige Zustellung ankommt, z.B. Sensordaten, die häufig aktualisiert werden.
QoS 1 – „At least once“ (Mindestens einmal)
- Funktionsweise: Die Nachricht wird so lange erneut gesendet, bis eine Bestätigung vom Empfänger eintrifft. Es kann jedoch passieren, dass die Nachricht mehrfach zugestellt wird.
- Performance: Mittlere Performance, da es zu Wiederholungen der Übertragung kommen kann.
- Anwendungsfall: Passend für Anwendungen, bei denen die Nachricht auf jeden Fall ankommen soll, aber eine mehrfache Zustellung tolerierbar ist, z.B. Zahlungsaufträge oder Status-Updates.
QoS 2 – „Exactly once“ (Genau einmal)
- Funktionsweise: Die Nachricht wird garantiert genau einmal zugestellt. Dies wird durch einen mehrstufigen Handshake-Prozess zwischen Sender und Empfänger erreicht.
- Performance: Niedrigste Performance, da mehrere Kommunikationsschritte notwendig sind, um die doppelte Zustellung zu verhindern.
- Anwendungsfall: Ideal für kritische Nachrichten, bei denen doppelte Zustellung nicht akzeptabel ist, z.B. bei der Übermittlung von Auftragsdaten in einem Bestellsystem.

Bemerkung

Die Wahl der QoS-Stufe sollte abhängig von den spezifischen Anforderungen der Anwendung getroffen werden, um ein optimales Verhältnis zwischen Zuverlässigkeit und Performance zu erreichen.

QoS 0: Maximal einmal – Hohe Performance, keine Garantie für Zustellung.
QoS 1: Mindestens einmal – Balance zwischen Zuverlässigkeit und Performance.
QoS 2: Genau einmal – Höchste Zuverlässigkeit, geringere Performance.

Die Wahl der QoS-Stufe sollte abhängig von den spezifischen Anforderungen der Anwendung getroffen werden, um ein optimales Verhältnis zwischen Zuverlässigkeit und Performance zu erreichen.

Retain¶

Konfigurationsoption: Retain Option im MQTT-Client

Die Retain Option in einem MQTT-Client bestimmt, ob eine Nachricht auf dem Broker gespeichert („retain“) wird, damit sie an zukünftige Abonnenten gesendet werden kann. Dies beeinflusst, wie der Broker mit neuen Abonnenten umgeht, die sich nach der Veröffentlichung der Nachricht anmelden.

Retain Option aktiviert
- Verhalten: Wenn die Retain Option aktiviert ist, speichert der Broker die letzte gesendete Nachricht für jedes Topic, das sie betreffen. Diese gespeicherte Nachricht wird dann automatisch an alle neuen Abonnenten gesendet, sobald sie sich für dieses Topic anmelden.
- Anwendungsfall: Nützlich, wenn Abonnenten immer die aktuellste Information erhalten sollen, auch wenn sie sich nach der ursprünglichen Veröffentlichung anmelden. Zum Beispiel, wenn der aktuelle Status eines Systems (wie Temperatur oder Online-Status) immer verfügbar sein muss.
Retain Option deaktiviert
- Verhalten: Ohne die Retain Option wird die Nachricht nicht auf dem Broker gespeichert. Neue Abonnenten erhalten nur Nachrichten, die nach ihrer Anmeldung veröffentlicht werden. Frühere Nachrichten werden nicht zugestellt.
- Anwendungsfall: Geeignet für Daten, die nur in Echtzeit relevant sind, wie beispielsweise kontinuierlich aktualisierte Sensordaten, bei denen es nicht wichtig ist, die letzte Nachricht zu kennen.

Bemerkung

Die Wahl, ob die Retain Option aktiviert oder deaktiviert wird, sollte auf den Bedürfnissen der Anwendung basieren, insbesondere darauf, ob neue Abonnenten auf den letzten bekannten Zustand zugreifen müssen oder nicht.

Retain Option aktiviert: Speichert die letzte Nachricht auf dem Broker und stellt sicher, dass neue Abonnenten diese erhalten. Ideal für Statusinformationen, die immer aktuell sein müssen.
Retain Option deaktiviert: Nachrichten werden nicht gespeichert; neue Abonnenten erhalten nur zukünftige Nachrichten. Optimal für Echtzeit-Daten, bei denen vergangene Informationen nicht relevant sind.

Die Wahl, ob die Retain Option aktiviert oder deaktiviert wird, sollte auf den Bedürfnissen der Anwendung basieren, insbesondere darauf, ob neue Abonnenten auf den letzten bekannten Zustand zugreifen müssen oder nicht.

ResMa®- und easyConnect-Connector¶

Der Connector ist für ResMa®- und easyConnect identisch.

Connectorname: Kann frei vergeben werden, muss jedoch eindeutig sein.
Aktivierungscode: Der Code dient dazu, die Identität des Clients zu besätigen und den Zugriff auf den MQTT-Broker zu sichern. Der Code muss in easyConnect bzw. ResMa® erzeugt und hier eingetragen werden. Die Erzeugung des Codes in ResMa® ist nachfolgend im Detail beschrieben.
Server-URL: Für ResMa-Verbindungen ersetzen Sie hier den Passus [RESMA_HOST]:[PORT] mit der IP oder dem DNS-Eintrag Ihres ResMa-Servers sowie dem zugehörigen Port (default ist 8080).
Cloudkommunikation: Bei Deaktivierung können keine Werte außerhalb des eigenen Netzwerkes empfangen oder gesendet werden.
Zeitintervall Keep-Alive: Das Intervall legt fest, wie oft ein Ping-Signal gesendet wird, um die Verbindung zum Broker aufrechtzuerhalten (Standard: 180 Sekunden). Ein kürzeres Intervall erhöht die Verbindungsstabilität, während ein längeres die Netzwerklast verringert.

Aktivierungscode in ResMa® erzeugen¶

Um die Verbindung zwischen PROCON-Connect und ResMa® herzustellen, muss ein Aktivierungscode in ResMa® erstellt und dann in PROCON-Connect hinterlegt werden.

Führen Sie dazu die folgenden Schritte in ResMa® aus:

Loggen Sie sich in Ihr ResMa®-System ein.
Schalten Sie die den Objektbaum von der Ansicht Standard in die Ansicht Connector.
Schalten Sie den Objektbaum in den Editiermodus um.
Machen Sie einen Rechtsklick auf den Standort, dem Sie den IIoT Connector hinzufügen möchten. Es öffnet ein Kontextmenü.
Wählen Sie im Kontextmenü die Option ‚Neues Gerät‘. Es öffnet die Konfigurationsseite für den IIoT Connector.
Geben Sie dem Connector einen Namen. Dieser wird in den Objektbaum übernommen.
Markieren Sie den Aktivierungscode aus dieser Übersicht und kopieren Sie diesen mit der Tastenkombination Strg + c.
Klicken Sie auf Speichern, um die Konfiguration des Connectors abzuschließen.

Anschließend können Sie den kopierten Aktivierungscode in die Konfiguration des IIoT Connectors in PROCON-Connect einfügen mit der Tastenkombination Strg + v.

Datendefinitionen¶

Die Datendefinitionen der Connectoren für ResMa®, easyConnect und MQTT sind identisch. Siehe dazu Kapitel Datendefinitionen.

Puffer¶

Siehe Kapitel Puffer (Buffering)

Azure IoT Hub¶

Kommunikation¶

Im Tab Allgemein werden grundlegende Konfigurationen für den Verbindungsaufbau hinterlegt.

Connectorname: Kann frei vergeben werden, muss jedoch eindeutig sein.
Server URL: URL des Azure IoT Hub, mit dem verbunden werden soll.
Cloudkommunikation: Bei Deaktivierung können keine Werte außerhalb des eigenen Netzwerkes empfangen oder gesendet werden. Kann bspw. zur Offline-Konfiguration deaktiviert werden.
Zeitintervall Keep-Alive: Das Intervall legt fest, wie oft ein Ping-Signal gesendet wird, um die Verbindung zum Azure IoT Hub aufrechtzuerhalten (Standard: 180 Sekunden). Ein kürzeres Intervall erhöht die Verbindungsstabilität, während ein längeres die Netzwerklast verringert.
MQTT Protokoll: Der Azure IoT Hub unterstützt ausschließlich die MQTT Version 3.1.1. Eine Umschaltung auf Version 5 ist für Verbindungen zu einem Azure IoT Hub nicht möglich.

Sicherheit¶

Im Tab Sicherheit wird der Authentifizierungsmechanismus konfiguriert. Die Authentifizierung ist über Geräte-ID und SAS-Token oder Geräte-ID und x.509 Zertifikate möglich.

Per default wird die Konfiguration über SAS-Token angezeigt. Um die Authentifizierung auf Zertifikate umzustellen, muss der Authentifizierungsmechanismus im Dropdown umgestellt werden. Die UI bietet nun die Möglichkeit, die entsprechenden Dateien hochzuladen.

Azure IoT Hub Authentifizierungseinstellungen

Geräte ID: ID des Geräts aus dem Azure IoT Hub.
Authentifizierungsmechanismus: Dropdown zur Umschaltung zwischen SAS-Tokens und x.509 Zertifikaten.
SAS Token: SAS Token aus dem Azure IoT Hub.

Device Twin¶

Eine Verbindung zu einem Azure IoT Hub kann maximal einen Device Twin haben. Über den Device Twin wird der Zustand eines Systems zwischen dem Gerät und dem Azure IoT Hub in der Cloud synchronisiert.

Reported Properties werden vom Gerät in die Cloud synchronisiert.

Desired Properties werden von der Cloud auf das Gerät synchronisiert.

Der gesamte Device Twin kann über eine Anfrage des Get Device Twin Topics auf einen String-Tag geschrieben werden. Nach einem Reboot des Geräts wird automatisch immer zuerst der gesamte Device Twin über dieses Topic abgeglichen.

Ein Device Twin kann angelegt werden, indem die Verbindung zu einem Azure IoT Hub ausgeklappt wird und im Unterbereich Device Twin auf den Button Device Twin hinzufügen geklickt wird.

Reported Properties¶

Im Tab Reported Properties können für den Device Twin die Tags gewählt werden, die bei Wertänderung vom Gerät an den Azure IoT Hub übertragen werden sollen. Der Payload ist dabei konfigurierbar bis zu einer Gliederungstiefe von zehn Ebenen. Die Limitation gibt der Azure IoT Hub vor.

Reported properties: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Die Quality of Service kann zwischen 0 und 1 gewählt werden. Die Quality of Service 2 wird durch den Azure IoT Hub nicht unterstützt.
Response of reported properties: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Die Quality of Service kann zwischen 0 und 1 gewählt werden. Die Quality of Service 2 wird durch den Azure IoT Hub nicht unterstützt. Die Responses für Reported Properties und Get Device Twin werden vom Azure IoT Hub auf demselben Topic gepublisht. Eine Änderung der QoS an einem der Topics wirkt sich also immer auf beide aus.
Gruppe hinzufügen: Button zum Hinzufügen eines Gliederungsknotens zum Payload.
Tag hinzufügen: Button zum Hinzufügen eines Tags zum Payload. Es öffnet ein Dialog zur Tag-Auswahl. Der Tag-Name wird standardmäßig gesetzt, kann jedoch optional überschrieben werden. An den Azure IoT Hub wird dieser frei wählbare Name übertragen. Wird ein String-Tag gewählt, erscheint zusätzlich die Checkbox String enthält JSON. Bei aktiver Checkbox wird der String als JSON geparst und dem Payload als JSON hinzugefügt.
Payload-Übersicht: Übersicht des aktuell konfigurierten Payloads. Die Reihenfolge und Schachtelung kann per drag & drop modelliert werden. Innerhalb einer Gliederungsebene wird die Reihenfolge der Items automatisch analog zu Azure IoT Hub alphanummerisch aufsteigend sortiert.

Reported Properties Payload

JSON Beispiel

{
   "temperature": 13.5,
   "doorGroup": {
      "isOpen": true,
      "displayText": "Door is open."
   }
}

Desired Properties¶

Im Tab Desired Properties können für den Device Twin die Tags angezeigt werden, die bei Wertänderung vom Azure IoT Hub an das Gerät übertragen werden.

Desired properties: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Die Quality of Service kann zwischen 0 und 1 gewählt werden. Die Quality of Service 2 wird durch den Azure IoT Hub nicht unterstützt.
Payload-Übersicht: Übersicht der aktuellen Payload, wie sie im Azure IoT Hub konfiguriert ist. Zur Ansicht muss der Device Twin zunächst angelegt und die Seite erneut aufgerufen werden.

Get Device Twin¶

Im Tab Get Device Twin kann optional ein String-Tag ausgewählt werden, auf den der gesamte Device Twin geschrieben wird. Der Request auf das Get Device Twin Topic erfolgt automatisch beim Reboot des Geräts. Der Device Twin wird im Response des Azure IoT Hubs mitgeliefert.

Get Device Twin: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Die Quality of Service kann zwischen 0 und 1 gewählt werden. Die Quality of Service 2 wird durch den Azure IoT Hub nicht unterstützt.
Response of Get Device Twin: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Die Quality of Service kann zwischen 0 und 1 gewählt werden. Die Quality of Service 2 wird durch den Azure IoT Hub nicht unterstützt. Die Responses für Reported Properties und Get Device Twin werden vom Azure IoT Hub auf demselben Topic gepublisht. Eine Änderung der QoS an einem der Topics wirkt sich also immer auf beide aus.
Tag: Dropdown zur Auswahl eines String-Tags. Auf den gewählten Tag wird der vollständige Device Twin als JSON geschrieben, der im Payload des Responses steckt.

Device to Cloud¶

Eine Device-to-Cloud-Kommunikation kann angelegt werden, indem die Verbindung zu einem Azure IoT Hub ausgeklappt wird und im Unterbereich Device-to-Cloud auf den Button Datendefinition hinzufügen geklickt wird.

Allgemein¶

Im Tab Allgemein wird ein Name für die Sendekonfiguration vergeben und das Sendeverhalten festgelegt.

Clouddatendefinitionsname: Zwingend erforderlich, muss eindeutig sein.
Verbindungstyp: Zur Auswahl stehen:
- Sende Tags bei Werteänderung (publish)
- Sende Tags periodisch (publish) > Hier muss anschließend noch der Zyklus und die Zeiteinheit festgelegt werden

Tags¶

Im Tab Tags wird der Payload zusammengestellt, der an den Azure IoT Hub übertragen werden soll. Der Payload ist dabei konfigurierbar bis zu einer Gliederungstiefe von zehn Ebenen. Die Limitation gibt der Azure IoT Hub vor.

Azure IoT Hub Device to Cloud Tag-Konfiguration

Events Topic: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Die Quality of Service kann zwischen 0 und 1 gewählt werden. Die Quality of Service 2 wird durch den Azure IoT Hub nicht unterstützt.
Gruppe hinzufügen: Button zum Hinzufügen eines Gliederungsknotens zum Payload.
Tag hinzufügen: Button zum Hinzufügen eines Tags zum Payload. Es öffnet ein Dialog zur Tag-Auswahl. Der Tag-Name wird standardmäßig gesetzt, kann jedoch optional überschrieben werden. An den Azure IoT Hub wird dieser frei wählbare Name übertragen. Wird ein String-Tag gewählt, erscheint zusätzlich die Checkbox String enthält JSON. Bei aktiver Checkbox wird der String als JSON geparst und dem Payload als JSON hinzugefügt.
Payload-Übersicht: Übersicht des aktuell konfigurierten Payloads. Die Reihenfolge und Schachtelung kann per drag & drop modelliert werden. Innerhalb einer Gliederungsebene wird die Reihenfolge der Items automatisch analog zu Azure IoT Hub alphanummerisch aufsteigend sortiert.

Device to Cloud Payload

JSON Beispiel

{
   "temperature": 13.5,
   "doorGroup": {
      "isOpen": true,
      "displayText": "Door is open."
   },
   "timestamp": "2025-05-26T14:14:15.000Z"
}

Der Zeitstempel wird automatisch im ISO 8601 Format hinzugefügt:

2025-05-26 → Datum (Jahr-Monat-Tag)
T → Trennt Datum und Uhrzeit
14:14:15.000 → Uhrzeit (Stunden:Minuten:Sekunden.Millisekunden)
Z → Zulu-Zeit, also UTC (koordinierte Weltzeit)

Direct Methods¶

Direct Methods werden vom Azure IoT Hub an ein Gerät gesendet, um eine bestimmte Methode oder Funktion auf diesem Gerät auszuführen, z. B. ein Gerät neu zu starten oder eine Einstellung zu ändern. Die Kommunikation verläut synchron, das Gerät antwortet direkt auf die Anfrage und gibt den Status der ausgeführten Aktion zurück.

Allgemein¶

Im Tab Allgemein wird der Methodenname für die Direct Method vergeben. Der Methodenname muss identisch sein zu dem Methodennamen im Azure IoT Hub, da auf Basis des Methodennamens die Subscription angelegt wird.

Request¶

Im Tab Request wird festgelegt, wie der Request an das Gerät übertragen werden soll. Es gibt zwei Möglichkeiten:

Übertragung als JSON: Die Informationen Methodenname, Request-ID und Payload werden als JSON vom Azure IoT Hub über PROCON-Connect ans Gerät über einen String-Tag durchgereicht. Die Weiterverarbeitung des JSON erfolgt in diesem Fall auf der Steuerung.
Payload-Konfiguration: Request-ID und Payload werden direkt auf Tags gemappt. Die Wertübertragung wird durch PROCON-Connect auf Basis der Treiberanbindung des jeweiligen Tags realisiert. Die Steuerung muss nur noch den Response auf Basis der Request-ID anstoßen. Die Request-ID muss einen numerischen Tag abgebildet werden.

Request mittels JSON¶

Request Topic: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Der Methodenname im Topic wird aus dem Tab Allgemein übernommen. Die Quality of Service ist für Request nicht einstellbar.
Konfigurationstyp: Es stehen zwei Konfigurationstypen zur Verfügung. Es können entweder die gesamten Methodeninformationen als JSON an die Steuerung übertragen und die Daten dort prozessiert werden oder Request-ID und Payload werden auf einzelne Tags gemappt.
Tag - Method Information: Dropdown für die Auswahl eines String-Tags. Auf den String-Tag werden Metadaten und Payload der Methode aus dem Azure IoT Hub geschrieben.

Der Payload hat die Form:
```
{"methodName":"[methodName]","payload":{"[tagName]":[tagValue]},"requestId":requestId}
```
Beispiel:
```
{"methodName":"coolDown","payload":{"target_temperature":19},"requestId":9}
```

Request mittels Payload-Konfiguration¶

Request Topic: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Der Methodenname im Topic wird aus dem Tab Allgemein übernommen. Die Quality of Service ist für Request nicht einstellbar.
Konfigurationstyp: Es stehen zwei Konfigurationstypen zur Verfügung. Es können entweder die gesamten Methodeninformationen als JSON an die Steuerung übertragen und die Daten dort prozessiert werden oder Request-ID und Payload werden auf einzelne Tags gemappt.
Tag - Request ID: Dropdown für die Auswahl eines numerischen Tags. Auf den Tag wird die Request-ID geschrieben. Die Request-ID kann den Wertebereich [1;255] annehmen. Sie muss von der Steuerung verarbeitet und mit in den korrelierenden Response gepackt werden. Erhält der Azure IoT Hub keinen Response mit entsprechender Request-ID wird ein TimeOut ausgelöst nach Ablauf des dort konfigurierten Method TimeOuts.
Payload Konfiguration: Der Payload muss hinsichtlich Schachtelung und Benamung exakt mit dem Payload im Azure IoT Hub übereinstimmen. Für die Übereinstimmung sind die frei vergebbaren Namen für die Tags ausschlaggebend, nicht die Tag-Namen selbst.

Response¶

Im Tab Response wird wird festgelegt, wie der Response an den Azure IoT Hub übertragen werden soll. Es gibt zwei Möglichkeiten:

Übertragung als JSON: Die Informationen Methodenname, Request-ID, Status-Code und Payload werden als JSON vom Gerät über PROCON-Connect an den Azure IoT Hub über einen String-Tag durchgereicht.
Payload-Konfiguration: Request-ID, Status-Code und Payload werden direkt auf Tags gemappt. Den Zusammenbau des Nachrichtenformats für den Azure IoT Hub übernimmt PROCON-Connect.

Response mittels JSON¶

Response Topic: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Der Methodenname im Topic wird aus dem Tab Allgemein übernommen. Die Quality of Service ist für Responses auf 0 oder 1 einstellbar.
Konfigurationstyp: Es stehen zwei Konfigurationstypen zur Verfügung. Es können entweder die gesamten Methodeninformationen als JSON an die Steuerung übertragen und die Daten dort prozessiert werden oder Request-ID, Status-Code und Payload werden auf einzelne Tags gemappt.
Tag - Method Information: Dropdown für die Auswahl eines String-Tags. Auf den String-Tag muss das Gerät mindestens die passende Request-ID schreiben. Wird kein Status-Code angegeben, wird per default der Status-Code 200 gesetzt.

Minimalanforderung:
```
{"requestId":[requestId]}
```
Beispiel:
```
{"requestId":1}
```
Kompletter Response:
```
{"payload":{"tagName":[tagValue]},"requestId":[requestId],"statusCode":[statusCode]}
```
Beispiel:
```
{"payload":{"errorMsg":"Wrong formatted request"},"requestId":1,"statusCode":400}
```

Response mittels Payload-Konfiguration¶

Response Topic: Das Topic ist durch den Azure IoT Hub definiert und unveränderlich. Der Methodenname im Topic wird aus dem Tab Allgemein übernommen. Die Quality of Service ist für Responses auf 0 oder 1 einstellbar.
Konfigurationstyp: Es stehen zwei Konfigurationstypen zur Verfügung. Es können entweder die gesamten Methodeninformationen als JSON an die Steuerung übertragen und die Daten dort prozessiert werden oder Request-ID, Status-Code und Payload werden auf einzelne Tags gemappt.
Tag - Request ID: Dropdown für die Auswahl eines numerischen Tags. Auf den Tag wird die Request-ID geschrieben. Die Request-ID kann den Wertebereich [1;255] annehmen. Sie muss von der Steuerung verarbeitet und mit in den korrelierenden Response gepackt werden. Erhält der Azure IoT Hub keinen Response mit entsprechender Request-ID wird ein TimeOut ausgelöst nach Ablauf des dort konfigurierten Method TimeOuts.
Tag - Status Code: Dropdown für die Auswahl eines numerischen Tags. Auf den Tag wird der Status Code geschrieben. Der Status Code ist frei wählbar und muss sich nicht Normen wie HTTP-Codes orientieren. Der Status-Code ist optional. Per default wird bei Nichtbelegung immer der Status-Code 200 gesendet in Anlehnung an den Status HTTP.OK.
Payload Konfiguration: Der Payload muss hinsichtlich Schachtelung und Benamung exakt mit dem Payload im Azure IoT Hub übereinstimmen. Für die Übereinstimmung sind die frei vergebbaren Namen für die Tags ausschlaggebend, nicht die Tag-Namen selbst.

Puffer¶

Siehe Kapitel Puffer (Buffering)

IIoT Connector¶

Übersicht¶

Navigation¶

Connector-Übersicht¶

MQTT Connector¶

Kommunikation¶

Sicherheit¶

Konfiguration¶

Puffer (Buffering)¶

Funktionsweise der Puffers¶

Behandlung von Nachrichten mit Quality of Service 0¶

Default-Werte¶

Puffer-Konfiguration¶

Payloads¶

Definition Payload¶

Instance Payload¶

Datendefinitionen¶

Quality of Service (QoS)¶

Retain¶

ResMa®- und easyConnect-Connector¶

Aktivierungscode in ResMa® erzeugen¶

Datendefinitionen¶

Puffer¶

Azure IoT Hub¶

Kommunikation¶

Sicherheit¶

Device Twin¶

Reported Properties¶

Desired Properties¶

Get Device Twin¶

Device to Cloud¶

Allgemein¶

Tags¶

Direct Methods¶

Allgemein¶

Request¶

Request mittels JSON¶

Request mittels Payload-Konfiguration¶

Response¶

Response mittels JSON¶

Response mittels Payload-Konfiguration¶

Puffer¶