> 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/cloud-mqtt.md).
# Cloud MQTT
Stellen Sie einen verwalteten Cloud-MQTT-Broker in Kilo IoT bereit — dedizierter Endpunkt und Zugangsdaten pro Connector, ideal für Pilotprojekte.
Cloud MQTT ist die vom Plattformbetreiber verwaltete Broker-Option für einen MQTT-Connector. Der Kilo IoT Server stellt pro Connector einen dedizierten Broker-Endpunkt bereit, erzeugt Anmeldeinformationen und weist ein eindeutiges Topic-Präfix zu, das den Namespace des Connectors innerhalb des verwalteten Brokers abgrenzt. Geräte und Edge-Gateways veröffentlichen an diesen Endpunkt; die Plattform verarbeitet die Nachrichten direkt.
Für Bereitstellungen, die keinen betrieblichen Bedarf haben, einen eigenen MQTT-Broker zu betreiben — Pilotprojekte, entfernte Standorte, kürzlich übernommene Anlagen, vom Hersteller bereitgestellte MQTT-Firmware, die nur ein öffentliches Ziel benötigt — reduziert Cloud MQTT den Integrationsumfang um Broker-Bereitstellung, Zertifikatsverwaltung und Erreichbarkeitsfragen.
## Wann Cloud MQTT die richtige Wahl ist
* **Greenfield-Ingestion.** Kein vorhandener Broker; einen einzurichten würde den Infrastrukturumfang ohne betrieblichen Nutzen erhöhen.
* **Vom Hersteller bereitgestellte MQTT-Firmware.** Ein Gerät oder Gateway ist so konfiguriert, dass es MQTT an einen über das Internet erreichbaren Endpunkt veröffentlicht, und ein verwalteter Endpunkt ist besser als der Aufbau eigener Infrastruktur.
* **Entfernte Standorte mit eingeschränktem Betrieb.** Ein Standort verfügt über eine Mobilfunk- oder Satellitenanbindung und nur begrenzte IT vor Ort; Publisher auf einen verwalteten Cloud-Endpunkt zu verweisen, ist betrieblich einfacher als einen lokalen Broker zu betreiben.
* **Pilotbereitstellungen.** Validierung einer MQTT-Integration, bevor in Broker-Infrastruktur investiert wird.
Wenn bereits ein vorhandener Broker im Einsatz ist — ein lokaler Mosquitto-Cluster, AWS IoT Core, eine HiveMQ-Instanz im Unternehmen oder ein anderes Broker-Produkt — siehe [Externes MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) stattdessen.
## Bereitstellung des 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 an (betriebliche Bezeichnung, z. B. `Anlage 3 Linie A Telemetrie`).
5. Klicken Sie auf **Hinzufügen**.
Die Plattform stellt den Broker-Endpunkt bereit und zeigt vier Anmeldeinformationen an:
| Feld | Verhalten |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Broker-URL** | Der vollständige verwaltete Endpunkt, einschließlich Schema und Port. Verwendet MQTTS (TLS) auf Port 1884. Wortgetreu kopieren — Schema und Port sind Teil der Anmeldeinformation. |
| **Themenpräfix** | Das eindeutige Namespace-Präfix für Nachrichten, die an diesen Connector weitergeleitet werden. Jede Nachricht, die Ihre Geräte veröffentlichen, muss mit diesem Präfix beginnen. Das Präfix hat die Form `iot/{org}/{connection}` — zwei undurchsichtige Segmente, die Ihre Organisation und diesen Connector identifizieren. |
| **Benutzername** | Von der Plattform generiert. Genau kopieren — es muss auf der Veröffentlichungsseite Byte für Byte reproduziert werden. |
| **Passwort** | Ein zufällig generiertes Geheimnis. Wird nur einmal angezeigt. **Beim Erstellen kopieren und sicher aufbewahren.** Eine Wiederherstellung ist nicht möglich — nur eine Rotation. |
Das Passwort wird nicht in wiederherstellbarer Form gespeichert. Behandeln Sie die Kopie nach der Bereitstellung als einzige Gelegenheit, es zu erfassen; wenn dieser Moment verpasst wird, müssen Anmeldeinformationen neu erzeugt und alle Publisher neu konfiguriert werden.
## Integrationsmodell
Cloud-MQTT-Publisher stellen ausgehend eine Verbindung zum verwalteten Broker her. Drei Details sind wichtig:
* **TLS auf Port 1884.** Konfigurieren Sie den MQTT-Client Ihres Publishers so, dass er das `mqtts://` Schema auf Port 1884 verwendet. Gehen Sie nicht von Port 1883 aus — der verwaltete Broker akzeptiert keine Klartextverbindungen. Das Broker-Zertifikat ist von einer öffentlich vertrauenswürdigen CA signiert, daher ist für Standardbibliotheken kein CA-Bundle auf der Client-Seite erforderlich.
* **Das Topic-Präfix ist für jedes veröffentlichte Topic obligatorisch.** Ein Gerät, das Energiewerte veröffentlicht, muss an `{Topic prefix}/{your topic}` — zum Beispiel, `iot/{org}/{connection}/meters/EM-4492/power`. Nachrichten, die außerhalb des Präfixes veröffentlicht werden, werden nicht an diesen Connector zugestellt.
* **Das Topic-Präfix wird vor dem Geräte-Routing entfernt.** Wenn Sie im Unter-Tab „Topic“ das Device-ID-Topic eines Geräts konfigurieren, geben Sie nur den Teil auf Geräteebene an (`meters/{{deviceId}}/power` oder ähnlich). Die Plattform übernimmt das Präfix intern.
Für speziell über Zigbee2MQTT angebundene Geräte ist das Z2M `base_topic` -Einstellung in `configuration.yaml` sollte `{Topic prefix}/zigbee2mqtt`. Z2M veröffentlicht dann jedes Gerät unter `{Topic prefix}/zigbee2mqtt/{friendlyName}`, und das auf Geräteebene für das Routing sichtbare Topic lautet `zigbee2mqtt/{friendlyName}`.
## Ingestion überprüfen
Nach dem Start des Publishers öffnen Sie die Detailseite des Connectors. Das **Zuletzt empfangene Daten** Feld wird innerhalb von Sekunden nach der ersten Veröffentlichung aktualisiert. Bei Z2M-angebundenen Setups ist die eigene `bridge/state` Beibehaltungsnachrichten-Ankündigung das Erste, was der Broker akzeptiert — typischerweise ist das der Zeitpunkt, an dem **Zuletzt empfangene Daten** zum ersten Mal erscheint, bevor ein Gerät gemeldet hat.
Wenn **Zuletzt empfangene Daten** nicht aktualisiert wird, nachdem der Publisher eine erfolgreiche Broker-Verbindung gemeldet hat, sind die häufigsten Ursachen der falsche Port (1883 vs. 1884), das falsche TLS-Schema oder ein nicht übereinstimmendes Topic-Präfix. Siehe [Fehlerbehebung](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md) für die vollständige Diagnoseabfolge.
## Anmeldeinformationen rotieren
Rotieren Sie Cloud-MQTT-Anmeldeinformationen, wenn:
* Das ursprüngliche Passwort ging verloren oder wurde nie erfasst.
* Ein Leck der Anmeldeinformationen wird vermutet.
* Ein Teamwechsel oder das Offboarding eines Auftragnehmers macht eine Rotation erforderlich.
* Eine Compliance-Richtlinie schreibt eine regelmäßige Rotation vor.
So rotieren Sie:
1. Öffnen Sie die Detailseite des Connectors.
2. Regenerieren Sie im Bearbeitungsmodus das Passwort.
3. Erfassen Sie das neue Passwort sofort.
4. Aktualisieren Sie jeden veröffentlichenden Client (Firmware-Konfiguration, Z2M `configuration.yaml`, Edge-Gateway-Einstellungen) mit dem neuen Passwort.
5. Starten Sie die Publisher neu, damit sie die neuen Anmeldeinformationen übernehmen.
Benutzername und Topic-Präfix bleiben über die Rotation hinweg stabil. Nur das Passwort ändert sich.
## Grenzen
Cloud-MQTT-Connectoren sind pro Organisation unbegrenzt. Verwenden Sie mehrere Connectoren, um Namespaces nach Standort, Hersteller oder Betriebsteam abzugrenzen — jeder Connector hat sein eigenes Topic-Präfix und eigene Anmeldeinformationen, und der Zugriff kann pro Connector unabhängig verwaltet werden.
---
# 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/cloud-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.
