Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

MQTT-Connector

Bringen Sie MQTT-fähige Geräte in Kilo IoT ein — Cloud MQTT (plattformbereitgestellter Broker) oder Externes MQTT (Ihren Broker anbinden).

Der MQTT-Connector ermöglicht es Ihnen, jedes MQTT-fähige Gerät in den Kilo IoT Server einzubinden, ohne über LoRaWAN zu gehen. SPSen in der Fabrik, HVAC-Controller, Gebäudestromzähler, MQTT-erzeugende Edge-Gateways (Modbus-zu-MQTT-, BACnet-zu-MQTT-, OPC-UA-zu-MQTT-Brücken) und Sensoren mit eigener Firmware, die bereits Daten über MQTT veröffentlichen, können alle direkt verbunden werden. Sobald sie verbunden sind, durchlaufen ihre Daten dieselbe Normalisierungspipeline, lösen dieselbe Regel-Engine aus und erscheinen in denselben Dashboards wie jedes andere Gerät auf dem Server.

Es sind zwei Varianten verfügbar:

Variante
Wie der Broker bereitgestellt wird
Limit
Am besten geeignet für

Externes MQTT

Ihr eigener Broker — in der Cloud gehostet, on-premises oder in einem Facility-Netzwerk, sofern er von der Plattform erreichbar ist

Bis zu 10 pro Organisation

Vorhandene Infrastruktur anbinden, die bereits per MQTT veröffentlicht

Cloud MQTT

Von der Plattform bereitgestellt — der Server stellt pro Connector einen dedizierten Broker-Endpunkt und Anmeldedaten bereit

Unbegrenzt

Neue Rollouts, Piloten und entfernte Standorte, an denen Sie MQTT-Daten aufnehmen möchten, ohne die Broker-Infrastruktur selbst zu betreiben

Verwenden Sie External MQTT, wenn bereits ein Broker läuft. Verwenden Sie Cloud MQTT, wenn die Plattform einen bereitstellen soll — Sie geben dem Connector einen Namen, die Plattform stellt den Rest bereit.

The Add connector dialog with External MQTT and Cloud MQTT in the connector type list

Geltungsbereich. Diese Dokumentation behandelt die MQTT-Telemetrieaufnahme und das Geräte-Mapping. Das Senden von Befehlen in die andere Richtung — also das Steuern eines verbundenen Geräts mit Downlinks — wird pro Gerät unter Gerätebefehle.

In diesem Abschnitt

  • Was MQTT ist — Protokolleinführung für Ingenieure, die neu bei MQTT sind oder ihr Wissen auffrischen.

  • Cloud MQTT — Bereitstellen eines von der Plattform verwalteten Brokers für einen Connector.

  • Externes MQTT — Anbinden eines vorhandenen Brokers, einschließlich Netzwerkerreichbarkeit, Authentifizierung und Verifizierung.

  • Topics und Geräte-Routing — Wie Topic-Muster, die Extraktion der Device-ID und der Mapping-Tab zusammenarbeiten. Vor dem Registrieren von Geräten lesen.

  • Fehlerbehebung — Diagnose von Verbindungs-, Topic-Match- und Logs-Tab-Problemen.

Für die Hardware-/Edge-Gateway-Seite der Integration — Modbus-, BACnet-, OPC-UA-, Sparkplug-B- und Zigbee2MQTT-Brücken, die MQTT in den Connector veröffentlichen — siehe MQTT Edge Gateways unter Gateways.

Hinzufügen eines External MQTT-Connectors

  1. Navigieren Sie zu Connectoren in der Seitenleiste.

  2. Klicken Sie auf Connector hinzufügen.

  3. Auswählen Externes MQTT aus dem Connector-Typ Dropdown-Menü.

  4. Füllen Sie das Konfigurationsformular aus:

    Feld
    Erforderlich
    Details

    Name

    Ja

    Anzeigename für diesen Connector

    Broker-URL

    Ja

    Vollständige URL mit Schema und Port. Der Broker muss von der Plattform aus netzwerkseitig erreichbar sein — ein Broker, der nur in einem isolierten lokalen Netzwerk erreichbar ist, kann nicht verbunden werden. Akzeptierte Schemas: mqtt://, mqtts://, tcp://, ssl://. Beispiel: mqtts://broker.facility.example.com:8883

  5. Wählen Sie eine Authentifizierungsmethode aus den Tabs:

    Methode
    Was einzutragen ist

    Anonym

    Keine Anmeldedaten erforderlich

    Basis

    Benutzername und Passwort (das Passwort verfügt über einen Ein-/Ausblenden-Schalter)

    Zertifikat

    Drei Schaltflächen zum Hochladen von Dateien: CA-Zertifikat, Client-Zertifikat, Privater Schlüssel. Laden Sie jede Datei hoch — fügen Sie keinen PEM-Inhalt ein

    JWT-Token

    Token-Feld (ein-/ausblenden + kopieren). Das Token ist die erforderliche JWT-Anmeldeinformation. Ein Zertifikats-Uploadfeld erscheint im Formular — es ist optional; die Plattform sendet für die JWT-Authentifizierung nur das Token

  6. Klicken Sie auf Hinzufügen.

Der Connector erscheint in der Connectors-Tabelle. Klicken Sie auf seine Zeile, um die Detailseite des Connectors zu öffnen.

Hinzufügen eines Cloud-MQTT-Connectors

  1. Navigieren Sie zu Connectoren in der Seitenleiste.

  2. Klicken Sie auf Connector hinzufügen.

  3. Auswählen Cloud MQTT aus dem Connector-Typ Dropdown-Menü.

  4. Geben Sie einen Name für den Connector.

  5. Klicken Sie auf Hinzufügen.

Die Plattform stellt einen dedizierten Broker-Endpunkt bereit und zeigt die erzeugten Anmeldedaten an:

Anmeldedaten
Details

Broker-URL

Der verwaltete MQTT-Endpunkt. Kopieren Sie ihn mit der Kopieren-Schaltfläche.

Themenpräfix

Alle an diesen Connector veröffentlichten Nachrichten müssen dieses Präfix verwenden. Dadurch werden Ihre Daten im zugewiesenen Namespace des Connectors organisiert. Kopieren Sie es mit der Kopieren-Schaltfläche.

Benutzername

Wird automatisch zugewiesen. Kopieren Sie es mit der Kopieren-Schaltfläche.

Passwort

Einmal angezeigt. Kopieren Sie es sofort. Wenn sie verloren gehen, rotieren Sie die Anmeldedaten in den Connector-Einstellungen — die Geräte müssen mit dem neuen Passwort neu konfiguriert werden. Im Bearbeitungsmodus ist eine Schaltfläche zum Neuerzeugen verfügbar.

Geräte mit Cloud MQTT verbinden

Konfigurieren Sie Ihre Geräte oder Ihre Gateway-Software so, dass sie an den bereitgestellten Endpunkt veröffentlichen. Wichtige Details vor dem Verbinden:

  • Die Broker-URL ist der vollständige Endpunkt — kopieren Sie sie genau so, wie sie angezeigt wird. Sie verwendet MQTTS (TLS) auf Port 1884. Konfigurieren Sie Ihre Geräte entsprechend; dies ist nicht der Standardport 1883.

  • Alle veröffentlichten Topics müssen mit dem Topic-Präfix beginnen. Das vollständige Topic, an das Ihr Gerät veröffentlicht, ist {Topic prefix}/{device topic} — zum Beispiel, wenn das Präfix iot/abc123/xyz789 und Ihr Gerät Leistungswerte veröffentlicht, könnten Sie an iot/abc123/xyz789/EM-4492/power.

  • Routing-Vorlagen auf dem Gerät enthalten das Präfix nicht. Wenn Sie im Topic-Tab das Device-ID-Topic konfigurieren, geben Sie nur den gerätespezifischen Teil ein — zum Beispiel {{deviceId}}/power. Die Plattform entfernt das Präfix vor dem Routing.

Auf Ihrer Seite ist keine Broker-Infrastruktur erforderlich — die Plattform verwaltet den Broker.

Ein Gerät per MQTT registrieren

Jedes Gerät, das über einen MQTT-Connector veröffentlicht, muss einzeln registriert werden. Die Registrierung ordnet die MQTT-Topic-Struktur und das Payload-Format dem Gerätemodell des Servers zu.

  1. Klicken Sie auf der Detailseite des Connectors auf Gerät hinzufügen — oder navigieren Sie zu Geräte → Geräte registrieren und wählen Sie diesen Connector aus.

  2. Füllen Sie die standardmäßigen Gerätefelder aus (Name, Connector, Vorlage).

Device ID = Topic-Segment, Byte für Byte. Alles, was Sie als Kennung des Geräts eingeben, muss exakt mit dem gerätespezifischen Topic-Segment übereinstimmen, das Ihre Hardware veröffentlicht. Das Eingabefeld für die Device ID entfernt Leerzeichen, daher werden Kennungen wie EM 4492 werden stillschweigend nicht mit einem Gerät übereinstimmen, das veröffentlicht unter EM-4492. Verwenden Sie in der Geräteaufzeichnung und auf der Veröffentlichungsseite exakt denselben String; die Groß-/Kleinschreibung bleibt erhalten und ist relevant.

  1. Das Gerät öffnet mit einem Zuordnung -Tab. Im Mapping gibt es zwei Unter-Tabs: Topic (wo die Plattform lernt, wie das Gerät im Topic-Stream gefunden wird) und Zuordnung (wo Sie Payload-Schlüssel normalen Kennzahlen zuordnen). Wenn Sie Zuordnung auswählen, öffnet sich zuerst der Topic Unter-Tab; klicken Sie auf Weiter oder den inneren Zuordnung Beschriftung, um zu den zeilen pro Schlüssel zu gelangen.

Topic-Tab

Der Topic-Tab teilt dem Connector mit, wo die Gerätekennung in jeder MQTT-Nachricht zu finden ist und welche Topics Telemetriedaten enthalten.

Topic für die Geräte-ID (erforderlich)

Das MQTT-Topic-Muster, an das dieses Gerät veröffentlicht. Verwenden Sie {{deviceId}} um das Topic-Segment zu markieren, das die Gerätekennung enthält.

Beispiel: Wenn Ihr Energiezähler an facility/meters/EM-4492/power, geben Sie ein:

Der Server extrahiert EM-4492 aus diesem Segment und leitet alle übereinstimmenden Nachrichten an den Digital Twin dieses Geräts weiter.

Woher die Geräte-ID kommt

  • Topic (Standard) — Die ID wird aus dem {{deviceId}} Segment des Topics extrahiert.

  • Nutzlast — Die ID wird aus einem Feld innerhalb des JSON-Payloads entnommen. Wenn diese Option ausgewählt ist, wird das Feld Device-ID-Payload-Pfad erforderlich.

Device-ID-Payload-Pfad (wird angezeigt, wenn Quelle = Payload)

Ein Pfad in Punktnotation zum Device-ID-Feld innerhalb des JSON-Payloads.

Beispiel: Für einen Payload {"device": {"id": "EM-4492"}, "power": 4.2}, geben Sie ein:

Telemetrie-Topics (optional)

Telemetry-Topic-Zeilen definieren, wie einzelne Messwerte aus MQTT-Nachrichten extrahiert werden. Sie sind optional.

Bei Geräten, die einen flachen JSON-Payload auf einem einzelnen Topic veröffentlichen — etwa Gebäudeleitsysteme oder SPSen, die ein Statusobjekt veröffentlichen — können Sie diesen Abschnitt vollständig überspringen. Der Server analysiert alle Schlüssel aus dem JSON-Payload automatisch, einschließlich verschachtelter Objekte, die in Pfade in Punktnotation umgewandelt werden (zum Beispiel, {"device": {"temperature": 22.5}} wird zugänglich als device.temperature). Der Mapping-Tab ist weiterhin erforderlich — jeder Payload-Schlüssel benötigt eine entsprechende Zeile mit einem passenden Connector-Schlüssel, um zu einer normalisierten Plattform-Kennzahl zu werden. Fügen Sie Telemetry-Topic-Zeilen nur hinzu, wenn Sie eine explizite Steuerung pro Topic benötigen: zum Beispiel, wenn Messwerte im Topic-Pfad statt im Payload eingebettet sind oder wenn Sie bestimmte Messwerte umbenennen möchten.

Feld
Details

MQTT-Topic für Telemetrie

Topic-Muster für diese Messwertzeile, unter Verwendung von {{deviceId}} Platzhalter

Connector-Schlüssel

Benennt den Quellschlüssel, der über MQTT ankommt. Dieser Schlüssel muss mit dem übereinstimmen, was das Gerät veröffentlicht. Der Connector-Schlüssel erzeugt nicht von sich aus eine Plattformkennzahl — im Mapping-Tab wird er mit einer normalisierten Kennzahl verknüpft.

Neues Topic hinzufügen — fügt eine Telemetrie-Topic-Zeile hinzu.

Alle anwenden — verwendet das Device-ID-Topic-Muster als Präfix, um Telemetrie-Topic-Vorlagen für Zeilen zu erzeugen, in denen bereits ein Connector-Schlüssel ausgefüllt ist. Es erzeugt topic-spezifische Muster basierend auf dem Device-ID-Topic — es kopiert den Wert des Device-ID-Topics nicht wörtlich.

Platzhalter-Referenz

Platzhalter
Verwendung
Was es tut

{{deviceId}}

Device-ID-Topic, Telemetrie-Topic-Vorlagen

Markiert das Topic-Segment, das die Gerätekennung enthält

{{value}}

Telemetrie-Topic-Vorlagen

Markiert ein Topic-Segment, dessen Inhalt der Messwert selbst ist — zum Beispiel, meters/EM-4492/230.5 wo 230.5 ist der Messwert. Verwenden Sie {{value}} nicht für Topic-Segmente, die die Kennzahl benennen (wie power oder voltage) — wenn das Segment ein Label statt eines Werts ist, verwenden Sie stattdessen die Payload-basierte Vorgehensweise

Mapping-Tab

Der Mapping-Tab verknüpft eingehende MQTT-Daten mit normalisierten Plattformkennzahlen. Hier werden rohe Gerätewerte zu abfragbaren Sensordaten im Digital Twin.

Der Connector-Schlüssel im Mapping-Tab muss mit dem in der MQTT-Nachricht veröffentlichten Schlüssel übereinstimmen (oder mit dem im Topic-Tab definierten Connector-Schlüssel). Ohne Übereinstimmung werden die Daten stillschweigend ignoriert — der Hilfetext über der Tabelle bestätigt dies: "Wenn der Connector-Schlüssel nicht ausgefüllt ist, werden die Daten ignoriert."

Die Tabelle hat 8 Spalten:

Spalte
Typ
Details

Normalisierter Schlüssel

Dropdown

Aus Sensortemplates auswählen; enthält die Option "+ Neue Kennzahl hinzufügen"

Einheit

Nur lesbar

Abgeleitet aus der ausgewählten Vorlage

Typ

Nur lesbar

Integer, Float, String oder Boolean — aus der Vorlage abgeleitet

Datentyp

Dropdown

Gemeldeter Zustand, Telemetrie oder Geräte-Metadaten

Connector-Schlüssel

Dropdown

Listet die Schlüssel auf, die aus dem Payload dieses Geräts empfangen wurden. Bleibt leer, bis mindestens eine Veröffentlichung eingegangen ist

Wert

Nur lesbar

Aktueller Live-Wert, der vom Broker empfangen wurde

Letzte Aktualisierung

Nur lesbar

Zeitstempel des zuletzt empfangenen Werts

Aktionen

Symbol

Das Papierkorbsymbol entfernt die Zeile

Schlüssel hinzufügen — fügt eine neue leere Mapping-Zeile hinzu.

Gemeldeter Zustand vs. Telemetrie

Die Datentyp Das Dropdown unterscheidet zwei Betriebskategorien:

  • Gemeldeter Zustand — steuerbare Geräteeigenschaften, deren aktuellen Wert das Gerät veröffentlicht. Der Sollwert eines HVAC-Controllers, der Ein-/Aus-Zustand eines Smart-Aktors, der Offen-/Geschlossen-Zustand eines Ventils. Dies sind Werte, die das Gerät auch per Befehl ändern kann.

  • Telemetrie — nur lesbare Messwerte. Temperaturfühler, Energiezählerwerte, RMS-Werte für Vibrationen, Link-Qualität. Dies sind Beobachtungen, die das Gerät über sich selbst oder seine Umgebung macht.

Wählen Sie den Typ, der zur betrieblichen Bedeutung des Werts passt. Gemeldeter Zustand eignet sich für Zustandsmaschinenfelder und konfigurierbare Sollwerte; Telemetrie eignet sich für Sensorwerte und Diagnosen.

Das Connector-Schlüssel-Dropdown ist leer, bis das Gerät einmal veröffentlicht hat

Die Connector-Schlüssel Die Spalte ist ein Dropdown, das mit Payload-Schlüsseln gefüllt wird, die tatsächlich vom Gerät empfangen wurden — kein Freitext-Eingabefeld. Vor dem ersten Eintreffen einer Veröffentlichung ist das Dropdown leer und die Zeilen können nicht ausgefüllt werden.

Die Registrierung eines MQTT-Geräts ist daher ein zweistufiger Ablauf:

  1. Fügen Sie pro Kennzahl eine Zeile hinzu, wählen Sie Normalisierter Schlüssel aus dem Vorlagen-Dropdown aus (oder verwenden Sie + Neue Metrik hinzufügen um eine zu erstellen), setzen Sie Datentyp, und lassen Sie den Connector-Schlüssel leer.

  2. Klicken Sie auf Speichern. Der Gerätedatensatz wird gespeichert.

  3. Stellen Sie sicher, dass das Gerät veröffentlicht — bei einem MQTT-erzeugenden Edge-Gateway, dass der Gateway-Prozess läuft und das Gerät mindestens eine Nachricht gesendet hat.

  4. Öffnen Sie das Gerät erneut. Das Connector-Schlüssel Dropdown listet nun die Schlüssel auf, die aus den zuletzt veröffentlichten Nachrichten empfangen wurden.

  5. Ordnen Sie jeder Mapping-Zeile einen Schlüssel zu.

  6. Klicken Sie auf Speichern erneut.

Spalte Wert in der Registerkarte Mapping vs. Verlauf in der Registerkarte Logs

Die Wert Wert-Spalte im Mapping-Tab zeigt den zuletzt empfangenen Payload — eine Live-Schnappschussansicht. Werte erscheinen hier, sobald das Topic-Matching erfolgreich ist, noch bevor Connector-Schlüssel befüllt sind.

Die Protokolle Registerkarte ist der Verlauf pro Sensor. Sie wird nur durch Publishes gefüllt, die nach Die Connector-Schlüssel werden gespeichert. Nach dem zweiten Durchlauf des oben beschriebenen Ablaufs erzeugen Sie eine neue Veröffentlichung (ein Wake-on-Event vom Gerät, ein geplanter Bericht oder bei Entwicklungsgateways eine Poll-Anfrage), um zu bestätigen, dass der Logs-Tab Datensätze empfängt.

Mapping ist iterativ — nach Eintreffen der Daten erneut prüfen

MQTT-Mapping ist keine einmalige Aktion. Die anfängliche Registrierung basiert oft auf der Erwartung des Bedieners, was das Gerät oder Edge-Gateway veröffentlichen wird; der erste echte Payload offenbart häufig zusätzliche Schlüssel — herstellerspezifische Diagnosefelder, undokumentierte Zustandsfelder, verschachtelte Objekte mit nützlichen Unterpfaden. Betrachten Sie den Mapping-Tab als einen Ort, den Sie erneut aufrufen:

  1. Nachdem Live-Daten über einen repräsentativen Zeitraum eingegangen sind, öffnen Sie den Gerätedatensatz erneut.

  2. Prüfen Sie das Connector-Schlüssel Dropdown und die Wert Spalte, um zu sehen, was das Gerät tatsächlich veröffentlicht.

  3. Fügen Sie Mapping-Zeilen für Felder hinzu, die der Einsatz nun nachverfolgen soll (ein Diagnosefeld für vorausschauende Wartung, ein Zustandsfeld, das betriebsrelevant geworden ist, eine verschachtelte Vibrations-Teilkennzahl und so weiter).

  4. Wählen Sie für jede neue Zeile den richtigen normalisierten Schlüssel und Datentyp.

  5. Speichern Sie.

  6. Lösen Sie eine neue Veröffentlichung aus, damit der Logs-Tab beginnt, Verlauf für die neuen Zuordnungen zu sammeln.

Diese iterative Verfeinerung ist der erwartete Ablauf, insbesondere bei gemischt-herstellerlichen Flotten, in denen sich Payload-Schemata über Firmware-Versionen nominal identischer Geräte hinweg subtil unterscheiden.

Übersetzung von Payload-Typ → Kennzahl-Typ

Wenn ein Gerät einen enumerierten Zustand als String veröffentlicht (zum Beispiel ein Aktor, der "OPEN"/"CLOSED", oder ein Zigbee- state Feld mit "ON"/"OFF"), kommt der Wert als String an — obwohl der konzeptionelle Typ binär ist. Ordnen Sie diese dem Zeichenfolge Typ in der Kennzahlvorlage zu, nicht Boolean. Wenn Sie für ein als String codiertes Enum Boolean wählen, führt das zu Null-Werten.

Speziell bei über Zigbee2MQTT angebundenen Geräten sind die zigbee2mqtt.io Geräteseiten jedes Feature mit einem Typ auf — übersetzen Sie wie folgt:

Z2M-Feature-Typ
Metriktyp
Hinweise

binary

Zeichenfolge

Werte "ON"/"OFF" Strings, nicht Booleans

numeric

Zahl

Numerische Bereiche direkt zugeordnet

enum

Zeichenfolge

Enumerierte Werte kommen als Strings an

text

Zeichenfolge

Freiformtext

Wie Sie herausfinden, welche Schlüssel ein Gerät veröffentlicht

Der Mapping-Tab erkennt Schlüssel nicht automatisch. Drei Methoden zum Ermitteln, in praktischer Reihenfolge:

  1. Die Dokumentation des Geräts oder das Datenblatt des Herstellers. Industrielle Geräte werden typischerweise mit einem Payload-Schema oder einem Topic-Katalog ausgeliefert.

  2. Für über Zigbee2MQTT angebundene Geräte, die Geräteseite unter https://www.zigbee2mqtt.io/devices/{modelId}.html listet das Exposes-Set auf. Beachten Sie, dass echte Payloads Schlüssel enthalten können, die nicht auf der Geräteseite aufgeführt sind — vertrauen Sie bei Abweichungen dem Live-Payload statt der Dokumentation.

  3. Beim Broker abonnieren und den Live-Payload prüfen — mosquitto_sub gegenüber dem Broker (oder dem Logs-Tab, sobald mindestens eine Mapping-Zeile aufgelöst ist) zeigt den JSON-Payload direkt an. Jeder Top-Level-Schlüssel ist ein gültiger Connector-Schlüssel.

Erwartete Ergebnisse

Nachdem der Connector konfiguriert und die Geräte registriert sind:

  • Die Connector-Zeile auf der Connectoren Seite zeigt Zuletzt empfangene Daten aktualisiert sich, wenn Nachrichten eintreffen.

  • Die Verbundene Geräte Anzahl spiegelt die registrierten Geräte wider.

  • Der Digital Twin jedes Geräts wird mit eingehender Telemetrie aktualisiert — sichtbar auf der Gerätedetailseite und in Dashboards.

  • Bedingungen der Regel-Engine, die auf diese Gerätekennzahlen verweisen, werden in Echtzeit ausgewertet.

Fehlerbehebung

Eine kurze Liste — siehe Fehlerbehebung für Diagnoseanleitungen zu Authentifizierungsfehlern, Zertifikatsabweichungen, dem Muster des leeren Logs-Tabs und Verifizierungstools.

Nach der Verbindung kommen keine Daten an:

  • Für External MQTT: überprüfen Sie das Broker-URL-Schema (mqtt://, mqtts://, tcp://, oder ssl://), bestätigen Sie, dass der Broker vom öffentlichen Internet aus erreichbar ist (der Kilo IoT Server verbindet sich ausgehend mit Ihrem Broker), und prüfen Sie die Anmeldedaten erneut.

  • Für TLS (Zertifikatsauthentifizierung): überprüfen Sie, ob das CA-Zertifikat mit der Zertifikatskette des Brokers übereinstimmt und dass Client-Zertifikat und privater Schlüssel zusammengehören.

  • Für Cloud MQTT: bestätigen Sie, dass Ihre Geräte an die korrekte Broker-URL und das korrekte Topic-Präfix veröffentlichen und dass Benutzername und Passwort korrekt sind. Wenn das Passwort verloren gegangen ist, rotieren Sie es in den Connector-Einstellungen.

Gerät ist registriert, aber es werden keine Daten angezeigt:

  • Vergleichen Sie das registrierte Device-ID-Topic mit dem genauen Topic, an das das Gerät veröffentlicht. Topics sind groß-/kleinschreibungssensitiv und müssen exakt übereinstimmen.

  • Bestätigen Sie die {{deviceId}} Position des Platzhalters mit dem tatsächlichen Device-ID-Segment im Topic übereinstimmt.

  • Bestätigen Sie, dass das Device-ID-Feld bytegenau identisch mit dem gerätespezifischen Segment ist — Leerzeichen werden bei der Eingabe entfernt und zerstören die Übereinstimmung.

  • Wenn Sie die Quelle Payload verwenden: überprüfen Sie, ob der Device ID Payload Path korrekt gegen die tatsächliche Payload-Struktur aufgelöst wird.

Die Wert-Spalte im Mapping-Tab wird aktualisiert, aber der Logs-Tab ist leer: Dies ist das häufigste Muster, wenn Connector-Schlüssel gespeichert werden, nachdem die letzte Veröffentlichung eingetroffen ist. Der Logs-Tab wird nur durch empfangene Veröffentlichungen befüllt nach Die Connector-Schlüssel werden gespeichert. Lösen Sie eine neue Veröffentlichung aus — ein Aufwachen des Geräts, ein geplanter Bericht oder ein /get Polling für Entwicklungsgateways — und der Logs-Tab wird befüllt.

Kennzahlwerte fehlen oder zeigen falsche Schlüssel:

  • Prüfen Sie, ob der Connector-Schlüssel im Mapping-Tab exakt mit dem Schlüssel im MQTT-Payload übereinstimmt (groß-/kleinschreibungssensitiv).

  • Wenn Sie sich auf die automatische JSON-Analyse verlassen (keine Telemetrie-Topics definiert): Die Plattform flacht den gesamten JSON-Payload einschließlich verschachtelter Objekte in Schlüssel in Punktnotation ab — zum Beispiel, {"device": {"temperature": 22.5}} wird zugänglich als device.temperature. Verwenden Sie diese Pfade in Punktnotation in der Connector-Schlüssel-Spalte des Mapping-Tabs.

Cloud-MQTT-Passwort verloren: Das Passwort kann nach der Erstellung nicht mehr abgerufen werden. Rotieren Sie die Anmeldedaten in den Connector-Einstellungen und konfigurieren Sie die Geräte mit dem neuen Passwort neu.

Gerät lässt sich bei einem Cloud-MQTT-Connector nicht speichern: Wenn das Speichern eines Geräts an einem Cloud-MQTT-Connector fehlschlägt, wenden Sie sich an den Support. Der Support kann dabei helfen, die Registrierung über den unterstützten API-gestützten Pfad abzuschließen.

Betriebsbeispiele

Fabrik-SPS — Telemetrie pro Topic: Eine SPS veröffentlicht einzelne Messwerte auf separate MQTT-Topics an einem Broker in der Produktion (mqtts://plc-broker.plant.example.com:8883). External MQTT-Connector, Benutzername/Passwort-Authentifizierung. Device-ID-Topic: plant/line-a/{{deviceId}}/data. Eine Telemetrie-Topic-Zeile pro Messwert (cycle_time, reject_count, temperature). Jede Zeile wird im Mapping-Tab einer normalisierten Plattformkennzahl zugeordnet.

Gebäude-HVAC-System — flacher JSON-Payload: Ein Gebäudeleitsystem veröffentlicht ein JSON-Statusobjekt pro Gerät auf einem einzelnen Topic. Der Payload ist flaches JSON, daher sind keine Telemetrie-Topic-Zeilen erforderlich — alle Schlüssel werden automatisch analysiert. Die Device ID befindet sich im Topic-Segment. Der Mapping-Tab ordnet jeden JSON-Schlüssel der passenden normalisierten Kennzahl zu.

Neuer Standort-Rollout — Cloud MQTT: Ein entfernter Standort benötigt MQTT-Datenaufnahme, aber das Team möchte keinen Broker betreiben. Es wird ein Cloud-MQTT-Connector erstellt; die Plattform stellt einen Broker-Endpunkt bereit. Energiezähler und Umweltsensoren werden so konfiguriert, dass sie an den bereitgestellten Endpunkt und das Topic-Präfix veröffentlichen. Keine Broker-Infrastruktur zu verwalten — die Plattform übernimmt das.

System zur Unterzählung von Energie: Energiezähler veröffentlichen einzelne Messwerte (kWh, kW, Spannung, Stromstärke) auf separate Topics. Telemetrie-Topic-Zeilen ordnen jedem Topic einen benannten Connector-Schlüssel zu. Der Mapping-Tab verknüpft jeden Connector-Schlüssel mit normalisierten Plattformkennzahlen. Alle Messwerte werden in einem einzigen Digital Twin des Geräts zusammengeführt.

Wie geht es weiter

VorherigeTracker-Connector
NächsteWas MQTT ist

Zuletzt aktualisiert