Erstellen Sie Ihren ersten MQTT-Konnektor

So erstellen Sie Ihren ersten MQTT-Konnektor

Nutzen Sie diese Anleitung, um zu erfahren, wie Sie MQTT-Themen in Tulip einbinden

In dieser Anleitung erfahren Sie:* Wie Sie eine MQTT-Datenquelle in Tulip einrichten

Wenn Sie über einen funktionierenden MQTT-Broker verfügen, den Sie mit Tulip verbinden möchten, können Sie eine MQTT-Datenquelle einrichten und Ihre erste App zur Maschinenüberwachung erstellen.

Einrichten einer MQTT-Verbindung

MQTT-Konnektoren können auf der Seite „Konnektoren“ oder auf der Seite „Maschinendatenquellen“ erstellt werden. Der Einrichtungsprozess ist identisch, und eine an einer Stelle erstellte Verbindung wird auch an der anderen Stelle angezeigt.

Weitere Details zur Erstellung von Konnektoren finden Sie hier: So konfigurieren Sie einen Konnektor

Einrichtung als Maschinen-Datenquelle

1. Klicken Sie in der Menüleiste unter der Registerkarte „Fertigungsbereich“ auf die Option „Maschinen“.

1. Klicken Sie anschließend im linken Seitenmenü auf „Maschinendatenquellen “.

1. Klicken Sie anschließend auf der Seite „Maschinendatenquellen“ auf „Maschinendatenquelle erstellen “.

1. Geben Sie Ihrer Datenquelle einen Namen, wählen Sie einen Connector-Host aus, wählen Sie „MQTT“ und die gewünschte MQTT-Version.

1. Fügen Sie die Verbindungsdaten hinzu, um eine Verbindung zu Ihrem Broker herzustellen.

Konfigurieren der MQTT-Verbindung

„Läuft auf“

„Läuft auf“ bezeichnet den Connector-Host, der für die Verwaltung der Verbindung zu Ihrem Broker zuständig ist. Wenn Ihr Broker nicht über das öffentliche Internet erreichbar ist, ist ein On-Prem-Connector-Host erforderlich, um auf Ihren MQTT-Broker zuzugreifen. Bitte überprüfen Sie die folgenden Versionsanforderungen, bevor Sie den Connector-Host testen.

MQTT vs. MQTTs

MQTTs ist einfach MQTT mit einer zusätzlichen Sicherheitsebene. Wenn „MQTTs“ ausgewählt ist, wird für die Kommunikation vom Client zum Broker SSL/TLS verwendet. Darüber hinaus unterstützt MQTTs private Schlüssel, Zertifikate und/oder Token vertrauenswürdiger Zertifizierungsstellen (CA). Wenn nur „MQTT“ ausgewählt ist, stehen lediglich die Authentifizierung über Benutzername und Passwort oder über den Benutzernamen anhand der Client-ID zur Verfügung.

Client-ID

Die Client-ID ist die Kennung, mit der sich der Tulip-Client gegenüber Ihrem MQTT-Broker identifiziert. Im einfachsten Fall wird sie häufig zur Authentifizierung und Zugriffskontrolle verwendet. Sie kann auf einen statischen Wert festgelegt oder – bei aktivierter Option „Automatisch generieren“ – auf einen zufälligen Wert gesetzt werden.

Keep-Alive

Die Keep-Alive-Zeit ist die maximale Zeit in Sekunden, während der der Client die Kommunikation mit dem Broker aufrechterhalten möchte. Wenn in diesem Zeitraum keine Nachrichten vom Broker an den Client übermittelt wurden, sendet der Client eine Nachricht an den Broker, um anzuzeigen, dass er noch aktiv ist.

Clean Session

Das MQTT-Flag „Clean Session“ legt die Lebensdauer der Sitzung fest. Ist es aktiviert, wird eine neue Sitzung gestartet, und alle Sitzungsdaten (Abonnements, Nachrichten in der Warteschlange) werden bei Trennung der Verbindung verworfen. Ist es deaktiviert, versucht der Broker, eine vorherige Sitzung fortzusetzen, wobei Abonnements und Nachrichten für den Client erhalten bleiben, falls dieser die Verbindung wiederherstellt.

Quality-of-Service-Stufen

Die Einstellung „Quality of Service“ (QoS) bestimmt die Zuverlässigkeit der Nachrichtenübermittlung zwischen Sender und Empfänger. Diese kann auf Konnektorebene konfiguriert und durch die Konfiguration der Konnektorfunktion überschrieben werden. Es stehen drei Stufen zur Verfügung:

• QoS 0 (Höchstens einmal): Nachrichten werden ohne Bestätigung gesendet. Dies ist die schnellste, aber am wenigsten zuverlässige Option, bei der keine Zustellungsgarantie besteht.
• QoS 1 (Mindestens einmal): Die Zustellung der Nachricht ist garantiert, sie kann jedoch doppelt versendet werden, wenn der Absender keine Bestätigung erhält.
• QoS 2 (Genau einmal): Die zuverlässigste Option, die sicherstellt, dass jede Nachricht genau einmal zugestellt wird. Dies ist mit mehr Overhead verbunden und die langsamste der drei Optionen.

MQTT-Zertifikatsinformationen

Privater Schlüssel

Aktualisiert die Eigenschaft „key“ in der Node.js-Authentifizierungskonfiguration.

Private Schlüssel im PEM-Format. PEM bietet die Möglichkeit, private Schlüssel zu verschlüsseln. Verschlüsselte Schlüssel werden mit options.passphrase entschlüsselt. Mehrere Schlüssel, die unterschiedliche Algorithmen verwenden, können entweder als Array unverschlüsselter Schlüsselzeichenfolgen oder Puffer oder als Array von Objekten in der folgenden Form bereitgestellt werden. Die Objektform kann nur in einem Array vorkommen. „object.passphrase“ ist optional. Verschlüsselte Schlüssel werden mit „object.passphrase“ entschlüsselt, sofern angegeben, andernfalls mit „options.passphrase“.

Zertifikat

Aktualisiert die Eigenschaft „cert“ in der Node.js-Authentifizierungskonfiguration.

Zertifikatsketten im PEM-Format. Pro privatem Schlüssel sollte eine Zertifikatskette bereitgestellt werden. Jede Zertifikatskette sollte aus dem im PEM-Format vorliegenden Zertifikat für einen bereitgestellten privaten Schlüssel bestehen, gefolgt von den im PEM-Format vorliegenden Zwischenzertifikaten (falls vorhanden) in der richtigen Reihenfolge, wobei die Stamm-Zertifizierungsstelle (Root-CA) nicht enthalten sein darf (die Stamm-Zertifizierungsstelle muss dem Peer bereits bekannt sein, siehe ca). Wenn mehrere Zertifikatsketten bereitgestellt werden, müssen diese nicht in derselben Reihenfolge wie die zugehörigen privaten Schlüssel in „key“ stehen. Werden die Zwischenzertifikate nicht bereitgestellt, kann der Peer das Zertifikat nicht validieren, und der Handshake schlägt fehl.

Vertrauenswürdige Zertifizierungsstelle

Aktualisiert die Eigenschaft „ca“ in der Node.js-Authentifizierungskonfiguration.

Optional können die Zertifikate der vertrauenswürdigen Zertifizierungsstellen überschrieben werden. Standardmäßig werden die von Mozilla kuratierten, allgemein anerkannten Zertifizierungsstellen als vertrauenswürdig eingestuft. Die Zertifizierungsstellen von Mozilla werden vollständig ersetzt, wenn Zertifizierungsstellen mithilfe dieser Option explizit angegeben werden. Der Wert kann eine Zeichenkette oder ein Buffer sein oder ein Array aus Zeichenketten und/oder Buffern. Jede Zeichenkette oder jeder Buffer kann mehrere miteinander verkettete PEM-Zertifikate von Zertifizierungsstellen enthalten. Das Zertifikat des Gegenübers muss mit einer vom Server als vertrauenswürdig eingestuften Zertifizierungsstelle verkettet werden können, damit die Verbindung authentifiziert werden kann. Bei der Verwendung von Zertifikaten, die nicht mit einer bekannten Zertifizierungsstelle verkettet werden können, muss die Zertifizierungsstelle des Zertifikats explizit als vertrauenswürdig angegeben werden, andernfalls schlägt die Authentifizierung der Verbindung fehl. Wenn der Peer ein Zertifikat verwendet, das nicht mit einer der Standard-Zertifizierungsstellen übereinstimmt oder nicht an diese verketten lässt, verwenden Sie die Option ca, um ein Zertifizierungsstellen-Zertifikat anzugeben, mit dem das Zertifikat des Peers übereinstimmen oder an das es verketten lässt. Bei selbstsignierten Zertifikaten ist das Zertifikat selbst die Zertifizierungsstelle und muss bereitgestellt werden. Bei PEM-kodierten Zertifikaten werden die Typen „TRUSTED CERTIFICATE“, „X509 CERTIFICATE“ und „CERTIFICATE“ unterstützt. Siehe auch tls.rootCertificates.

Testen Ihrer Verbindung

Klicken Sie auf „Test“, um zu prüfen, ob Sie erfolgreich eine Verbindung zum Broker herstellen können.

Wenn der Test erfolgreich ist, können Sie mit der Einrichtung einer Maschine beginnen. Klicken Sie auf „Speichern“ und wechseln Sie anschließend zur Seite „Maschinentypen“, um Ihre erste Maschinenkategorie einzurichten.

Haben Sie gefunden, wonach Sie gesucht haben?

Sie können auch community.tulip.co besuchen, um Ihre Frage zu stellen oder nachzuschauen, ob andere bereits ein ähnliches Problem hatten!