> 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/what-is-mqtt.md).
# Was MQTT ist
Was ist MQTT? Ein leichtgewichtiges Pub-Sub-IoT-Protokoll — Broker, Topics, QoS — und wie es dem Kilo-Connector zugeordnet wird.
MQTT ist ein leichtgewichtiges Publish-Subscribe-Nachrichtenprotokoll, das für eingeschränkte Netzwerke und Geräte entwickelt wurde, ursprünglich 1999 von IBM für SCADA über Satellitenverbindungen spezifiziert und heute als ISO/IEC 20922 standardisiert. Drei Eigenschaften machen es heute zum dominierenden Industrial-IoT-Protokoll: geringer Overhead des Übertragungsformats, geeignet für Mobilfunk- und batteriebetriebene Endpunkte, entkoppelte Produzenten und Konsumenten über einen zentralen Broker sowie klar definierte Zustellgarantien (QoS 0/1/2), die es Integratoren ermöglichen, je Topic Durchsatz gegen Zuverlässigkeit abzuwägen.
Wenn Sie ein bestehendes MQTT-erzeugendes System – ein Gebäudeleitsystem, eine Flotte von zellulär verbundenen Zählern, eine über MQTT angebundene SPS-Flotte – in den Kilo IoT Server integrieren, behandelt die folgende Orientierung das Modell, das die Plattform voraussetzt. Wenn Sie MQTT bereits produktiv betreiben und direkt weitergehen möchten, [Cloud-MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) und [Externes MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) die Connector-Konfiguration direkt beschreiben.
## Architektonische Rollen
An jedem MQTT-Austausch sind drei Rollen beteiligt:
* **Broker** — die Routing-Infrastruktur. Geräte und Anwendungen verbinden sich mit dem Broker; der Broker ordnet Publishern auf Grundlage von Topic-Mustern passende Subscriber zu und übernimmt die Zustellung gemäß dem angeforderten QoS-Level. Der Broker ist für jeden MQTT-Teilnehmer der einzige Verbindungspunkt; es gibt kein Peer-to-Peer-Fallback.
* **Publisher** — erzeugen Nachrichten zu Topics. Zu den industriellen Publishern zählen in der Praxis SPSen mit MQTT-Firmware, Edge-Gateways, die Modbus / BACnet / OPC-UA in MQTT übersetzen, herstellerspezifische Brücken (Zigbee2MQTT, ESPHome) und maßgeschneiderte Embedded-Firmware auf Feldgeräten.
* **Subscriber** — konsumieren Nachrichten. Der MQTT-Connector des Kilo IoT Server ist ein Subscriber. Mehrere Subscriber können dieselben Topics unabhängig voneinander konsumieren — Ihr vorhandenes Dashboard, der lokale Historian und die Plattform können alle dieselben Daten ohne Abstimmung empfangen.
```
Feldgeräte ──┐
SPSen ───────────┤
Brücken ────────┼──> Broker ──> Subscriber (Kilo, Historian, Dashboards, ... )
Edge-Gateways ──┘
```
Geräte sind typischerweise sowohl Publisher (sie melden Telemetriedaten) als auch Subscriber (sie empfangen Sollwerte, Konfiguration, Downlinks). Der Broker ist die immer vorhandene Mitte.
## Topics: der Routing-Schlüssel
Jede MQTT-Nachricht trägt ein **Topic** — eine durch Schrägstriche getrennte UTF-8-Zeichenkette. Der Broker verwendet Topics, um Publishern Subscriber zuzuordnen; Subscriber registrieren ihr Interesse an Mustern mit `+` (Single-Level-Wildcard) und `#` (Multi-Level-Wildcard am Ende). Topics sind nicht vordefiniert; die veröffentlichende Partei wählt das Topic, und ein Topic-Katalog wird durch Konvention oder eine Vereinbarung mit dem Hersteller festgelegt.
Häufige Konventionen in industriellen Deployments:
* **Hierarchische Topic-Struktur nach Standort/Anlage/Metrik** — zum Beispiel, `plant-3/line-a/extruder-04/temperature` oder `building-12/floor-2/ahu-1/setpoint`. Das macht Wildcard-Abonnements für standortweite Aggregationen naheliegend.
* **Schemata mit Herstellerpräfix** für Protokollbrücken — z. B. `zigbee2mqtt/{friendlyName}`, `tasmota/{deviceName}/SENSOR`, `mosquitto/+/state`. Der Kilo IoT Server unterstützt jede Topic-Form über das **Device ID Topic** Feld „pattern“ — siehe [Topics und Geräte-Routing](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md).
* **Sparkplug-B-Namespaces** — für OPC-UA-ähnliche Hierarchien — z. B. `spBv1.0/{group}/DDATA/{node}/{device}`. Die Plattform verarbeitet diese als gewöhnliche MQTT-Topics; die Sparkplug-spezifische Decodierung wird vom publizierenden Edge-Gateway übernommen.
Die Connector-Konfiguration der Plattform behandelt Topics als Muster: Bei jedem Gerät setzen Sie das Topic aus Segmenten zusammen und markieren das Segment, das die Gerätekennung enthält, und die Plattform extrahiert die Kennung bei jeder eingehenden Nachricht aus dieser Position.
## Payloads: strukturiertes JSON in der Praxis
Das MQTT-Protokoll selbst ist payload-agnostisch — Bytes hinein, Bytes heraus. In produktiven Umgebungen ist JSON mit überwältigender Mehrheit das Format der Wahl für neue Systeme, mit gelegentlichem Einsatz von Sparkplug B (Protocol Buffers) und proprietären binären Formaten für Legacy-Brücken. Der MQTT-Connector des Kilo IoT Server analysiert JSON-Payloads automatisch — flache Objekte, verschachtelte Objekte (zu Pfaden in Punktnotation abgeflacht) und primitive Werte werden alle unterstützt.
Eine typische industrielle Telemetrie-Payload:
```json
{
"timestamp": "2026-01-15T14:32:18Z",
"temperature": 78.4,
"pressure": 4.21,
"vibration": {"rms": 0.42, "peak": 1.8},
"status": "running"
}
```
Wenn sie auf Plattform-Metriken abgebildet werden, `temperature`, `Druck`, `vibration.rms`, `vibration.peak`, und `Status` werden jeweils zu einem adressierbaren Connector Key. Die Registerkarte Mapping verknüpft jeden Connector Key mit einer normalisierten Metrik, die dann in den Digital Twin, die Regel-Engine und den historischen Speicher fließt.
Für Schemata mit einer Metrik pro Topic (Legacy-Brücken, OPC-UA-Aliasing-Muster), das **Telemetrie-Topics** Zeilen auf dem Unter-Tab „Topic“ erlauben es Ihnen, jedes Topic explizit einem benannten Connector Key zuzuordnen.
## QoS, Retained Messages, Last-Will
Drei Protokollfunktionen kommen in industriellen Einsätzen so oft vor, dass es sich lohnt, sie ausdrücklich zu erwähnen:
* **QoS-Stufen** — 0 (höchstens einmal), 1 (mindestens einmal), 2 (genau einmal). Der Connector der Plattform verarbeitet jedes QoS-Niveau, das der Publisher verwendet; wählen Sie das Niveau, das Ihrer betrieblichen Toleranz gegenüber Duplikaten vs. Verlusten entspricht. QoS 2 hat den höchsten Overhead für den Broker und ist typischerweise für Steuerbefehle oder kritische Zustandsänderungen reserviert.
* **Zurückgehaltene Nachrichten** — markierte Nachrichten, die der Broker speichert und neuen Subscribern beim Verbinden erneut zuspielt. Nützlich für die Bekanntgabe des aktuellen Zustands (z. B. „online/offline“-Meldungen). Wenn der Broker zurückgehaltene Nachrichten als normale abonnierte Publishes an die Plattform liefert, können sie wie jede andere Payload zugeordnet werden — prüfen Sie das anhand des Verhaltens Ihres Brokers.
* **Letzter Wille und Testament (LWT)** — eine Nachricht, die der Broker im Namen des Publishers veröffentlicht, wenn er unerwartet getrennt wird. Übliches Muster: Das LWT eines Geräts veröffentlicht `"offline"` an sein Status-Topic, sodass Subscriber Zustandsänderungen bei einer Trennung sehen, ohne pollen zu müssen. Wenn Ihr Broker LWT-Nachrichten als normale MQTT-Publishes an den Connector liefert, können sie wie jede andere Payload zugeordnet werden.
Diese Funktionen werden von der publizierenden Partei konfiguriert, nicht vom Connector. Der Connector akzeptiert alles, was der Broker liefert.
## Warum MQTT für Industrial IoT
Die Einführung des Protokolls in kommerziellen Deployments wird durch drei Eigenschaften vorangetrieben, die sich sauber auf betriebliche Anforderungen abbilden:
* **Bandbreiteneffizienz.** Der Overhead des Übertragungsformats ist klein genug für per Mobilfunk angebundene Feldgeräte und drahtlose Deployments mit hoher Dichte. Keep-Alives und Pings lassen sich so konfigurieren, dass sie zu den verfügbaren Verbindungsfenstern passen.
* **Entkoppelte Produzenten und Konsumenten.** Das Hinzufügen eines neuen Subscribers (eines Historians, einer Analyseplattform eines Drittanbieters, des Kilo IoT Server) erfordert keine Neukonfiguration der Publisher. Betriebsteams können neue Consumer ausrollen, ohne die Feldgeräte anzufassen.
* **Ausgereiftes Ökosystem.** Es gibt Mosquitto, HiveMQ, AWS IoT Core, Azure IoT Hub und viele weitere Broker. Die meisten modernen industriellen Protokollbrücken (Modbus-zu-MQTT, BACnet-zu-MQTT, Sparkplug-B-Edge-Gateways) bringen erstklassiges MQTT-Publishing mit.
Für die deploymentspezifische Konfiguration fahren Sie fort mit [Cloud-MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) für plattformverwaltete Broker, oder [Externes MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) für den Anschluss eines bestehenden Brokers.
---
# 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/what-is-mqtt.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.
