MQTT

MQTT (Message Queuing Telemetry Transport) ist ein leichtgewichtiges Kommunikationsprotokoll, das speziell für den Datenaustausch zwischen Geräten entwickelt wurde. Es basiert auf dem Prinzip „Publisher-Subscriber“ und eignet sich besonders für Anwendungen im Bereich Internet of Things (IoT), da es auch bei geringer Bandbreite zuverlässig funktioniert. In dieser Bedienungsanleitung wird MQTT zur Steuerung der Bildaufnahme sowie zur Datenweiterleitung bzw. der Überwachung der Kamera verwendet. Dabei wird unterschieden, ob die Kamera auf einen Broker hört (“Subscribe”) oder Daten an ein Topic sendet (“Publish”).

Verbindungsparameter

Bevor eine Subscription eingerichtet werden kann, werden bestimmte Zugangsdaten benötigt.
Die Authentifizierung eines Clients bei einem Broker hängt von der jeweiligen Konfiguration des Brokers ab. Es gibt mehrere Möglichkeiten die Authentifizierung zu konfigurieren:

• Keine Authentifizierung

• Username und Passwort (Credentials)

• Client-Zertifikat (Certificate)

• Eine Kombination aus Username, Passwort und Zertifikat (Combination)

Darüber hinaus kann auch der Client das Server-Zertifikat überprüfen. Falls es sich um ein Zertifikat einer vertrauenswürdigen Zertifizierungsstelle handelt, kann der Client dieses automatisch akzeptieren. In der Regel sind diese im System-Store hinterlegt.

Es ist aber auch üblich, dass selbstsignierte Zertifikate (self-signed) genutzt werden. Dann muss der Client das vom Server bereitgestellte Zertifikat selbst überprüfen und benötigt dazu das entsprechende Root-CA Zertifikat (Certificate Authority).

Der Client muss also folgende Informationen besitzen, um sich erfolgreich und sicher zu verbinden:

• Client Zertifikat (z.B. .crt, .pem, …)

• Root-CA Zertifikat (z.B. .crt, .pem, …)

• Schlüsseldatei (optional) (.key)

• Schlüsseldatei Passwort (optional, falls Schlüsseldatei verschlüsselt ist)

In der nachfolgenden Tabelle können die benötigten Daten, die Sie bei Ihrer IT anfragen sollten, für die jeweilige Situation einsehen.

Im Folgenden wird auf die benötigten Zugangsdaten detailliert eingegangen.

Parameter	Type	Einheit	Erklärung	Beispiel
Address	Domain || IP		Die Zieladresse des Brokers. Diese wird in der Regel von der IT bereitgestellt.	mybroker.mydomain.de 192.168.0.123
Port	Integer		Die Port-Adresse des Brokers. Diese ist in der Regel von der IT vorgegeben. Bitte beachten Sie, dass bestimmte Ports bei der Integration der Kamera von der IT freigegeben werden müssen.	8883
Timeout	Integer	[ms]	Timeout beschreibt die Zeit, die die Anwendung maximal beim Verbinden mit dem Broker benötigen darf, bevor es in den Reconnect-Versuch geht.	5000
Topic	String		Ein Topic in MQTT ist ein hierarchischer Pfad, über den Clients Nachrichten veröffentlichen oder empfangen, basierend auf ihrem Abonnement.	myTopic Pfad/Pfad1/Pfad2/myTopic
Use Credentials Authentication	Bool		Wird für die Authentifizierung ein Username mit Passwort bereitgestellt, kann diese Option gewählt werden.
Username	String		Ein Benutzername in MQTT wird zur Authentifizierung von Clients beim Broker verwendet, oft zusammen mit einem Passwort zur Zugangskontrolle.	Hans
Password	String		Ein Passwort in MQTT wird zusammen mit dem Benutzernamen genutzt, um den Client gegenüber dem Broker sicher zu authentifizieren und den Zugriff kontrollieren zu können. Dazu wird ein Secret aus dem evoVIU Secret-Store benötigt.
Use Certificate Authentication	Bool		Statt Benutzername und Passwort verwendet MQTT hier digitale Zertifikate, um Clients und Broker gegenseitig zu authentifizieren – über eine TLS/SSL-verschlüsselte Verbindung.
Ca File	File	*.pem	Das CA-File in MQTT überprüft, ob das Zertifikat des Clients oder Brokers von einer vertrauenswürdigen Zertifizierungsstelle stammt.
Cert File	File	*.pem *.crt	Das Cert-File (Zertifikatsdatei) enthält das öffentliche Zertifikat eines Clients oder Brokers und bestätigt dessen Identität bei der Verbindung.
Key File	File	*.key	Das Key-File enthält den privaten Schlüssel des Clients oder Brokers und wird genutzt, um TLS-Verbindungen sicher zu verschlüsseln und zu signieren.
Is Encrypted Key File	Bool		Wenn das Key-File verschlüsselt ist, kann zudem der Schlüssel aktiviert werden mit einem weiteren Key File Password.
Key File Password	Secret	*.key *.pem	Das Key File Password schützt den privaten Schlüssel in der Key-Datei vor unbefugtem Zugriff – nur mit Passwort kann er entschlüsselt werden.

Anmerkungen zu den Einstellungen:

• Je nachdem wie der MQTT Broker konfiguriert ist, kann die Authentifizierung entweder per Credentials und / oder per Zertifikat erfolgen.

  • Dazu können die Toggle Use Credentials Authentication und Use Certificate Authentication verwendet werden.

• Bei der Authentifikation per Zertifikat können über Ca File, Cert File und Key File die entsprechenden Dateien aus dem File System geladen werden. Dazu müssen sie zunächst im File System hinterlegt werden.

  • Sollte das Key File verschlüsselt sein, kann über den Toggle Is Encrypted Key File und den Input Key File Password der nötige Schlüssel hinterlegt werden.

Workflow Setup

Unterschied zwischen MQTT Publish und MQTT Subscription

Der Publish-Knoten dient dazu, Daten von der Kamera an einen Broker zu senden, wobei ein bestimmtes Topic angesprochen wird. Über eine Subscription können hingegen Daten empfangen werden, sobald auf dem jeweiligen Topic neue Informationen veröffentlicht werden.

In der Visionweb-Plattform lassen sich beliebig viele Publish- und Subscription-Endpunkte einrichten. So kann beispielsweise die Bildaufnahme einschließlich zugehöriger Metadaten über eine Subscription ausgelöst und anschließend an einen gewünschten Ziel-Endpunkt gesendet werden. Gleichzeitig ist es möglich, über einen anderen Endpunkt Status- oder Gesundheitsdaten bereitzustellen.

Anlegen der MQTT Subscription - Schritt für Schritt

Nach Anlegen der MQTT Subscription Component kann der Event Node Receive Bytes zum Workflow hinzugefügt werden. Dieser wird bei einer eingehenden Nachricht vom MQTT Broker auf das entsprechende Topic ausgelöst und enthält die mitgeschickten Daten als Byte-Array im Socket Parameter.

1. Gehen Sie in Workflows unter Components auf ➕ .

2. Suchen Sie nach “MQTT Subscription”.

3. Es erscheint eine neue Komponente mit dem Namen “MQTT Subscription”.

4. Geben Sie die MQTT | Zugangsdaten ein.

5. Gehen Sie in Ihren Event Graph und öffnen Sie per Rechtsklick das Context-Menü.

6. Suchen Sie unter Events nach “MQTT Subscription” bzw. den Namen, den Sie der Komponente gegeben haben.

7. Wählen Sie das “Recieve Bytes (MQTT Subscription)” Event aus.

Ab diesem Zeitpunkt löst das Event immer dann aus, wenn sich am Broker der Datensatz ändert. Am besten kann man dies über den Print-Knoten im Output anzeigen lassen.

Ausgabe der empfangenen Daten im Output

Das folgende Beispiel zeigt eine einfache Möglichkeit schnell zu prüfen, ob Daten des Brokers von der Kamera entgegengenommen werden können.

Anlegen der MQTT Publish - Schritt für Schritt

Nach Anlegen der MQTT Subscription Component kann der Event Node Receive Bytes zum Workflow hinzugefügt werden. Dieser wird bei einer eingehenden Nachricht vom MQTT Broker auf das entsprechende Topic ausgelöst und enthält die mitgeschickten Daten als Byte-Array im Socket Parameter.

1. Gehen Sie in Workflows unter Components auf ➕ .

2. Suchen Sie nach “MQTT Publish”.

3. Es erscheint eine neue Komponente mit dem Namen “MQTT Publish”.

4. Geben Sie die MQTT | Zugangsdaten ein.
   

Im Gegensatz zur Subscription verfügt die Publish-Komponente zunächst über kein Eingabefeld für das Topic. Dieses wird erst im nachgelagerten Workflow-Schritt im Publish-Knoten benötigt, da einem Endpunkt mehrere Topics zugewiesen werden können.

5. Gehen Sie in Ihren Event Graph und öffnen Sie mit einem Rechtsklick das Context-Menü.

6. Suchen Sie unter Events nach “Publish” bzw. den Namen, den Sie der Komponente gegeben haben.

7. Wählen Sie den Knoten “Publish” und die dazugehörige Bezugskomponente “Get MQTT Publish” .

Platzieren Sie den Publish-Knoten an der Stelle im Workflow, an der Sie Ihre Daten an einen gewünschten Endpunkt weiterleiten möchten. Wenn Sie mehrere verschiedene Broker-Endpunkte nutzen, können Sie entsprechend mehrere Publish-Komponenten anlegen. Achten Sie dabei auf eine sinnvolle und eindeutige Benennung der Komponenten, um die Übersicht im Workflow zu gewährleisten.

Verwendung des Knoten “Publish”

Beim “Publish”-Knoten können Sie sehr flexibel und dynamisch die Daten an ein beliebiges Topic senden. Dazu geben Sie entweder das gewünschte Topic in die Parameterzeile des Knoten direkt ein oder lassen dieses im Workflow automatisch generieren und einbinden.

Bitte stellen Sie sicher, dass die Topics korrekt geschrieben sind. Bei Unsicherheiten wenden Sie sich an Ihre IT-Abteilung.

In der Regel gelten folgende Konventionen:

• Einfache Topics (direkte Bezeichnungen) bestehen meist aus einem einzelnen Begriff:
  myTopic

• Themenpfade werden häufig durch Schrägstriche ( / ) oder Punkte ( . ) getrennt:
  myTopic/myUntertopic/superTopic
myTopic.myUntertopic.superTopic

• In manchen Systemen ist ein abschließendes Trennzeichen erforderlich, um mehrere Datensätze oder Subtopics zu adressieren:
  myTopic/myUntertopic/superTopic/
myTopic.myUntertopic.superTopic.

Sollten Daten nicht wie erwartet empfangen oder gesendet werden, überprüfen Sie bitte die Schreibweise des Topics. Ein fehlerhafte Syntax kann die Ursache sein.

Die Payload kann aus allen möglichen Daten in ein Byte-Array umgewandelt und über MQTT versendet werden. So ist es möglich nicht nur Meta-Daten und Ergebnisse zu senden, sondern auch ganze Datensätze inkl. Bilder, wenn dies gewünscht ist.