> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector.md). # 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](/kilo-docs-de/kilo-iot-server/devices/commands.md). ## In diesem Abschnitt * [Was MQTT ist](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/what-is-mqtt.md) — Protokolleinführung für Ingenieure, die neu bei MQTT sind oder ihr Wissen auffrischen. * [Cloud MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) — Bereitstellen eines von der Plattform verwalteten Brokers für einen Connector. * [Externes MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) — Anbinden eines vorhandenen Brokers, einschließlich Netzwerkerreichbarkeit, Authentifizierung und Verifizierung. * [Topics und Geräte-Routing](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md) — Wie Topic-Muster, die Extraktion der Device-ID und der Mapping-Tab zusammenarbeiten. Vor dem Registrieren von Geräten lesen. * [Fehlerbehebung](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md) — 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](/kilo-docs-de/kilo-iot-server/gateways/mqtt-edge-gateways.md) 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. 3. 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: ``` facility/meters/{{deviceId}}/power ``` 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: ``` device.id ``` #### 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](https://www.zigbee2mqtt.io/supported-devices/) 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](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md) 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 * [Geräte registrieren](/kilo-docs-de/kilo-iot-server/devices/registering-devices.md) — Vollständige Geräteregistrierung und Digital-Twin-Konfiguration. * [Connectoren](/kilo-docs-de/kilo-iot-server/connectors.md) — Überblick über alle Connector-Typen. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.