> 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/external-mqtt.md).
# Externes MQTT
Verbinden Sie Kilo IoT Server mit Ihrem eigenen MQTT-Broker — Mosquitto, AWS IoT Core, HiveMQ — mit TLS-Authentifizierung und Topic-Routing.
Externes MQTT verbindet den Kilo IoT Server mit einem MQTT-Broker, den Sie bereits betreiben. Die Plattform stellt eine Verbindung zum Broker her, abonniert die relevanten Topics und verarbeitet Nachrichten in dieselbe Routing-Pipeline wie Cloud-MQTT-Daten. Wählen Sie diese Option, wenn der Broker bereits Teil Ihrer Infrastruktur ist — ein lokaler Mosquitto-Cluster, AWS IoT Core, eine unternehmensweite HiveMQ-Bereitstellung oder ein vom Anbieter verwalteter Broker, der standortübergreifend gemeinsam genutzt wird.
## Wann Externes MQTT die richtige Wahl ist
* **Ein vorhandener Broker ist bereits Teil des Betriebs.** Geräte veröffentlichen bereits darauf; mehrere Abonnenten (Historians, Dashboards, Integrationsplattformen) konsumieren bereits davon. Die Plattform als weiteren Abonnenten hinzuzufügen, ist betrieblich einfacher, als die Publisher umzuleiten.
* **Compliance- oder Anforderungen an die Datenresidenz** legen fest, dass Telemetriedaten zuerst über Ihren eigenen Broker laufen müssen, bevor sie SaaS-Konsumenten erreichen.
* **Hybride Architekturen** bei denen eine lokale Edge-Verarbeitung stattfindet, bevor ein Teil der Telemetriedaten an die Plattform weitergeleitet wird.
Für Bereitstellungen ohne vorhandenen Broker, [Cloud MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) ist der Weg mit geringerem Aufwand.
## Erreichbarkeitsanforderung
Der Kilo IoT Server stellt von außen eine Verbindung zu Ihrem Broker her, daher muss der Broker über das öffentliche Internet per DDNS, Portweiterleitung oder eine dedizierte öffentliche IP erreichbar sein. Ein Broker, der nur über ein privates VLAN erreichbar ist, ist vom Cloud-Kontrollplane der Plattform aus nicht erreichbar.
Das Standard-Produktionsmuster ist eine öffentliche IP oder ein DDNS-Hostname für den Broker, wobei Firewall-Regeln steuern, welche Quellen eine Verbindung herstellen können.
Für Entwicklungs- oder Pilotbereitstellungen funktioniert ein Exposure-Tunnel wie ngrok für kurzfristige Tests — beachten Sie jedoch, dass der Betrieb eines Exposure-Tools allein nicht bestätigt, dass Kilo den Broker erreichen kann. Nach dem Speichern des Connectors, **eine Testnachricht veröffentlichen und bestätigen, dass sich der Wert „Zuletzt empfangene Daten“ aktualisiert** auf der Detailseite des Connectors. Dies ist der einzige Weg, die End-to-End-Erreichbarkeit zu verifizieren.
## Authentifizierungsoptionen
Der Connector unterstützt vier Authentifizierungsmethoden, auswählbar bei der Erstellung:
| Methode | Wann verwenden | Konfigurationsfelder |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Anonym** | Nur für Entwicklungs-Broker. **Nicht für produktiv exponierte Broker verwenden** — jeder im Internet, der den Broker findet, kann veröffentlichen oder abonnieren. | Keine |
| **Basis** | Benutzernamen- und Passwortauthentifizierung. Die häufigste Konfiguration für produktive Bereitstellungen, bei denen TLS die Anmeldedaten während der Übertragung schützt. | Benutzername, Passwort |
| **Zertifikat** | TLS-Clientauthentifizierung mit gegenseitiger Zertifikatsprüfung. Höchstes Vertrauensniveau; Standard für regulierte Bereitstellungen. | CA-Zertifikatsdatei, Client-Zertifikatsdatei, Datei für den privaten Schlüssel (als Dateien hochgeladen; PEM-Inhalt nicht einfügen) |
| **JWT-Token** | Token-basierte Authentifizierung, kompatibel mit Brokern, die JWTs validieren (z. B. AWS IoT Core mit benutzerdefinierten Authorizern oder andere Broker mit JWT-Plugins). | Token |
Bei Zertifikat bilden die drei hochgeladenen Dateien die Client-Seite eines mTLS-Austauschs; der Broker muss so konfiguriert sein, dass er der CA vertraut und das Client-Zertifikat dagegen validiert. Der private Schlüssel muss beim Hochladen unverschlüsselt sein.
## Bereitstellung des 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 Folgendes aus:
| Feld | Erforderlich | Details |
| -------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Ja | Betriebliche Bezeichnung, z. B. `Mosquitto Werk 3` oder `Broker-Cluster Nordamerika`. |
| **Broker-URL** | Ja | Vollständige URL mit Schema und Port. Beispiele: `mqtts://broker.facility.example.com:8883`, `ssl://broker.example.com:8883`. |
5. Wählen Sie die Authentifizierungsmethode und füllen Sie deren Felder aus.
6. Klicken Sie auf **Hinzufügen**.
Der Connector erscheint in der Connectortabelle. Klicken Sie auf die Detailseite, um den **Zuletzt empfangene Daten** Indikator
## Verifizierungsschritt
Die End-to-End-Erreichbarkeit wird nur durch eine tatsächliche Veröffentlichung bestätigt, die in der Plattform ankommt. Nach dem Speichern des Connectors:
1. Veröffentlichen Sie eine Testnachricht an Ihren Broker in einem beliebigen Topic, das der Connector abonniert.
2. Öffnen Sie die Detailseite des Connectors in Kilo.
3. Bestätigen Sie **Zuletzt empfangene Daten** aktualisiert sich innerhalb weniger Sekunden.
Ein einfacher Einmal-Test von einem Host aus, der den Broker erreichen kann:
```bash
mosquitto_pub \\
-h broker.facility.example.com -p 8883 \\
--cafile /path/to/ca.crt \\
-u {username} -P {password} \\
-t "test/connectivity" \\
-m '{"hello":"world"}'
```
(Ersetzen Sie Schema/Port und Anmeldedaten entsprechend der Authentifizierungsmethode Ihres Brokers.)
Wenn **Zuletzt empfangene Daten** wenn sich nach einer erfolgreichen lokalen Veröffentlichung nicht aktualisiert, siehe [Fehlerbehebung](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md). Die häufigsten Ursachen sind Firewall-Regeln zwischen dem Egress der Plattform und Ihrem Broker, nicht übereinstimmende IP-Allowlisten, abgelaufene Tunneling-Sitzungen bei der Verwendung von ngrok für Tests oder eine falsche TLS-Konfiguration auf Broker-Seite.
## Referenzbereitstellung für selbst gehostetes Mosquitto
Für Bereitstellungen, die eine schnelle Referenz für das Einrichten eines selbst gehosteten Mosquitto-Brokers zu Test- oder Pilotzwecken benötigen, sieht das minimale Docker-Compose so aus:
```yaml
services:
mosquitto:
image: eclipse-mosquitto:2
container_name: mosquitto
restart: unless-stopped
ports:
- "1883:1883"
volumes:
- ./mosquitto/config:/mosquitto/config
- ./mosquitto/data:/mosquitto/data
```
`mosquitto.conf`:
```
listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd
persistence true
persistence_location /mosquitto/data/
log_dest stdout
```
Zwei Betriebshinweise:
* **`log_dest stdout`** wird in containerisierten Bereitstellungen gegenüber dateibasiertem Logging bevorzugt. Per Bind-Mount eingebundene Log-Verzeichnisse scheitern oft unter SELinux/AppArmor oder aufgrund von Besitzerkonflikten; die Standardausgabe des Containers wird vom Docker-Logging-Treiber erfasst.
* **Port 1883 kollidiert.** In Entwickler- oder gemeinsam genutzter Infrastruktur kann Port 1883 bereits belegt sein (z. B. durch ein kubectl port-forward oder einen anderen lokalen Broker). `ss -tlnp \| grep 1883` identifiziert den bindenden Prozess. Ordnen Sie den Port auf der Host-Seite neu zu (z. B. `"1885:1883"`) und leiten Sie stattdessen den neuen Host-Port weiter — der interne Container-Port kann für Publisher im Netzwerk weiterhin 1883 bleiben.
Für die TLS-Terminierung ist vor einer öffentlichen Freigabe ein separater Reverse-Proxy oder die native TLS-Konfiguration von Mosquitto erforderlich (hier nicht im Umfang — siehe Mosquitto-Dokumentation).
## Grenzen
Extern-MQTT-Connectoren sind auf 10 pro Organisation begrenzt. Für Bereitstellungen, die zusätzliche Broker-Integrationen über dieses Limit hinaus benötigen, wenden Sie sich während der Bereitstellungsplanung an das Platform Engineering.
---
# 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/external-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.
