Wenn Sie Mosquitto auf dem Raspberry Pi installieren, erhalten Sie einen schnellen, schlanken MQTT-Broker, der in Ihrem lokalen Netzwerk weiterarbeitet, auch wenn das Internet ausfällt. In diesem Tutorial installieren Sie die Mosquitto-Pakete für den Raspberry Pi aus dem Repository des Betriebssystems, konfigurieren einen Listener mit Passwort-Authentifizierung, testen ihn über die Kommandozeile und entscheiden, wann ein lokaler Broker genügt und wann er per Bridge an einen Cloud-MQTT-Broker angebunden werden sollte. Jede Konfigurationsdatei ist vollständig und direkt kopierbar.
Wann ein lokaler Mosquitto-Broker sinnvoll ist
Ein Broker auf dem Pi passt für manche Aufgaben gut und für andere schlecht. Seien Sie ehrlich, welche Situation Sie haben, bevor Sie Zeit investieren.
| Situation | Lokaler Mosquitto auf dem Pi | Cloud-MQTT-Broker |
|---|---|---|
| Alle Geräte in einem LAN, kein Fernzugriff nötig | Passt gut | Optional |
| Muss bei Internetausfällen weiterlaufen | Passt gut | Mit lokalem Broker kombinieren |
| Geräte in mehreren Gebäuden oder in Mobilfunknetzen | Passt schlecht, erfordert Portweiterleitung | Passt gut |
| Smartphone-Apps und Dashboards von überall | Passt schlecht, erfordert VPN oder offene Ports | Passt gut |
| TLS, Authentifizierung und Updates soll jemand anders übernehmen | Passt schlecht | Passt gut |
| Sehr geringe Latenz zwischen lokalen Geräten | Passt gut | Fügt einen Internet-Roundtrip hinzu |
In der Praxis ist das Muster verbreitet, das beides kombiniert: Geräte kommunizieren mit einem lokalen Mosquitto auf dem Pi, und Mosquitto leitet ausgewählte Topics per Bridge an einen Cloud-Broker weiter. Lokale Automatisierungen laufen offline weiter, und die Cloud-Seite erhält die Daten für Dashboards und Fernzugriff. Genau dort endet dieses Tutorial. Wenn Sie zuerst die Rolle des Brokers auffrischen möchten, lesen Sie, was ein MQTT-Broker macht.
Schritt 1: Mosquitto auf Raspberry Pi OS installieren
Raspberry Pi OS Bookworm liefert Mosquitto 2.0 im Repository mit, was für die meisten Einsätze aktuell genug ist:
sudo apt update
sudo apt install -y mosquitto mosquitto-clients
sudo systemctl enable --now mosquitto
mosquitto -h | head -n 1
systemctl status mosquitto --no-pager
Das Paket mosquitto-clients ergänzt mosquitto_pub und mosquitto_sub, die Sie zum Testen verwenden.
Im Auslieferungszustand ist Mosquitto 2.0 bewusst abgeriegelt: Ohne konfigurierten Listener akzeptiert er nur Verbindungen vom Pi selbst (localhost) und weist anonyme entfernte Clients ab. Das überrascht alle, die älteren Anleitungen gefolgt sind, in denen der Broker jeden auf Port 1883 akzeptierte. Es ist die richtige Voreinstellung, und der nächste Schritt öffnet ihn auf sichere Weise.
Schritt 2: Benutzer und Passwortdatei anlegen
Legen Sie eine Passwortdatei mit einem Benutzer pro Gerät oder Dienst an. Der Schalter -c erstellt die Datei, verwenden Sie ihn also nur für den ersten Benutzer:
sudo mosquitto_passwd -c /etc/mosquitto/passwd sensors
sudo mosquitto_passwd /etc/mosquitto/passwd nodered
sudo mosquitto_passwd /etc/mosquitto/passwd dashboard
Jeder Befehl fragt nach einem Passwort und speichert einen gesalzenen Hash, nicht den Klartext. Beschränken Sie die Datei so, dass nur root und der Broker sie lesen können:
sudo chown root:mosquitto /etc/mosquitto/passwd
sudo chmod 0640 /etc/mosquitto/passwd
Aktuelle Mosquitto-Versionen warnen im Log, wenn die Passwortdatei für alle lesbar ist, und künftige Versionen könnten sie ablehnen – setzen Sie die Berechtigungen also gleich jetzt.
Schritt 3: Den Listener konfigurieren
Lassen Sie die Hauptdatei /etc/mosquitto/mosquitto.conf im Auslieferungszustand; sie bindet jede Datei in /etc/mosquitto/conf.d/ ein. Legen Sie Ihre eigene Konfiguration dort ab:
sudo nano /etc/mosquitto/conf.d/local.conf
# Listener im lokalen Netzwerk mit Authentifizierung
per_listener_settings true
listener 1883 0.0.0.0
allow_anonymous false
password_file /etc/mosquitto/passwd
# Grenzen, die einen kleinen Pi schützen
max_connections 200
max_inflight_messages 20
max_queued_messages 1000
message_size_limit 262144
# Die SD-Karte schonen: Persistenz ist in der Hauptdatei standardmäßig aktiv,
# alle 5 Minuten statt fortlaufend auf die Platte schreiben
autosave_interval 300
Einige Hinweise zu diesen Einstellungen: per_listener_settings true erlaubt jedem Listener eine eigene Authentifizierung, was Sie brauchen, wenn Sie später einen WebSocket-Listener mit anderen Regeln hinzufügen. message_size_limit hindert einen fehlerhaften Client daran, riesige Payloads an einen Pi mit begrenztem RAM zu senden. autosave_interval steuert, wie oft die Persistenzdatenbank aus dem Arbeitsspeicher geschrieben wird, was für den Verschleiß der SD-Karte wichtig ist.
Starten Sie neu und prüfen Sie das Log:
sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 30 --no-pager
Das Log sollte Opening ipv4 listen socket on port 1883 zeigen. Schlägt der Dienst fehl, nennt die Logzeile direkt über dem Fehler die fehlerhafte Option.
Schritt 4: Den lokalen Broker testen
Abonnieren Sie in einem Terminal auf dem Pi mit dem Benutzer dashboard:
mosquitto_sub -h localhost -p 1883 -u dashboard -P 'dashboard-password' \
-i test-sub -t 'home/#' -v
Veröffentlichen Sie in einem zweiten Terminal oder von einem Laptop im selben Netzwerk über die IP-Adresse des Pi als sensors:
mosquitto_pub -h 192.168.1.50 -p 1883 -u sensors -P 'sensors-password' \
-i test-pub -t home/kitchen/temperature -m 21.6
Der Subscriber gibt home/kitchen/temperature 21.6 aus. Versuchen Sie es nun ohne Zugangsdaten, um zu bestätigen, dass anonymer Zugriff abgewiesen wird:
mosquitto_pub -h 192.168.1.50 -p 1883 -i anon-test -t home/x -m test
# Connection error: Connection Refused: not authorised.
Weitere Kommandozeilen-Muster finden Sie in den Beispielen für mosquitto_pub und mosquitto_sub.
Schritt 5: Optionaler WebSocket-Listener für lokale Dashboards
Muss ein Browser-Dashboard in Ihrem LAN mit dem Broker auf dem Pi sprechen, ergänzen Sie in derselben Datei einen WebSocket-Listener:
listener 9001 0.0.0.0
protocol websockets
allow_anonymous false
password_file /etc/mosquitto/passwd
Da per_listener_settings aktiv ist, braucht dieser Listener eigene Zeilen für allow_anonymous und password_file. Unverschlüsseltes ws:// ist in einem vertrauenswürdigen LAN akzeptabel, nicht aber über das Internet.
Härtungs-Checkliste nach der Installation von Mosquitto auf dem Raspberry Pi
- Ändern Sie das Passwort des Standardbenutzers auf dem Pi und halten Sie das System mit
sudo apt full-upgradeaktuell. - Leiten Sie Port 1883 nicht in Ihrem Router weiter. Ein unverschlüsselter Broker im Internet lädt zum Erraten von Passwörtern und zum Mitschneiden des Datenverkehrs ein.
- Verwenden Sie einen eigenen MQTT-Benutzer pro Gerät oder Dienst, damit Sie einen sperren können, ohne die übrigen anzufassen.
- Fügen Sie eine Firewall-Regel hinzu, damit nur Ihr LAN den Broker erreicht:
sudo ufw allow from 192.168.1.0/24 to any port 1883. - Verlegen Sie die Persistenz auf eine SSD oder reduzieren Sie Schreibvorgänge, wenn der Pi jahrelang von einer SD-Karte läuft.
- Überwachen Sie den Pi selbst; der Publisher für Raspberry-Pi-Systemwerte meldet Speicherplatz und Temperatur.
Für den Zugriff von außen widerstehen Sie der Versuchung, Ports zu öffnen. Diese Aufgabe erledigt ein Cloud-MQTT-Broker besser.
Den lokalen Mosquitto-Broker per Bridge an ConnectMQ anbinden
Hier treffen sich lokaler Broker und Cloud-Broker. Mosquitto hat eine eingebaute Bridge: Sie verbindet sich als gewöhnlicher MQTT-Client nach außen mit einem entfernten Broker und leitet die von Ihnen gewählten Topics weiter. ConnectMQ ist ein Cloud-MQTT-Broker; aus seiner Sicht ist Ihr Pi also nur ein weiterer Client, der sich mit dem im Portal generierten Benutzernamen, Passwort und der Client-ID anmeldet. Auf der Cloud-Seite ist keine spezielle Bridge-Funktion nötig, und in Ihrem Netzwerk wird kein eingehender Port geöffnet.
Eine minimale Bridge-Datei, /etc/mosquitto/conf.d/bridge-connectmq.conf, sieht so aus:
connection connectmq
address broker.connectmq.com:8883
bridge_capath /etc/ssl/certs
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
bridge_protocol_version mqttv311
try_private false
cleansession false
notifications false
start_type automatic
# Lokales Topic home/... erscheint in der Cloud als site1/home/...
topic home/# out 1 "" site1/
# Befehle aus der Cloud erreichen lokale Geräte
topic home/+/set in 1 "" site1/
Starten Sie Mosquitto neu, und das Log zeigt Connecting bridge connectmq. Nachrichten, die lokal auf home/kitchen/temperature veröffentlicht werden, erscheinen nun zusätzlich auf site1/home/kitchen/temperature bei ConnectMQ, wo der Live-Topic-Explorer und das Dashboard im Portal sie anzeigen können. Fällt das Internet aus, sprechen lokale Geräte weiter mit dem Pi, und mit cleansession false und QoS 1 werden ausgehende Nachrichten lokal bis zur Grenze max_queued_messages zwischengespeichert, bis die Bridge sich wieder verbindet.
Der Cloud-Broker verwendet ein Let's-Encrypt-Zertifikat, deshalb ist bridge_capath /etc/ssl/certs die gesamte erforderliche TLS-Einrichtung. try_private false ist wichtig: Es verhindert, dass Mosquitto ein Mosquitto-spezifisches Protokoll-Flag verwendet, das andere Broker nicht erwarten. Die vollständige Erklärung aller Optionen, einschließlich Schleifenvermeidung und Tests, finden Sie im Leitfaden zur Mosquitto-Bridge-Konfiguration.
Stellen Sie irgendwann fest, dass Sie den Pi-Broker nur noch behalten, um die Cloud zu erreichen, sollten Sie ihn ganz entfernen und die Geräte direkt auf die Cloud richten. Diesen Weg beschreibt der Leitfaden zur Migration von Mosquitto in die Cloud.
Fehlerbehebung
| Fehler oder Symptom | Ursache | Abhilfe |
|---|---|---|
Connection refused von anderen Rechnern |
Kein Listener auf 0.0.0.0 | listener 1883 0.0.0.0 ergänzen |
not authorised |
Falscher Benutzer oder falsches Passwort, oder Datei für den Broker nicht lesbar | mosquitto_passwd erneut ausführen, chown root:mosquitto prüfen |
| Dienst startet nach Konfigurationsänderung nicht | Doppelter Listener oder Tippfehler | journalctl -u mosquitto lesen |
| Clients trennen sich ständig | Zwei Clients teilen sich eine ID | Eindeutige Client-IDs verwenden |
| Bridge verbindet sich und bricht dann ab | Client-ID oder Zugangsdaten stimmen nicht | Alle drei exakt aus dem Portal kopieren |
Starten Sie mit ConnectMQ
Behalten Sie Mosquitto für schnellen lokalen Datenverkehr und überlassen Sie alles, was über das Internet geht, einem verwalteten MQTT-Broker. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, kopieren Sie die generierten Zugangsdaten in Ihre Bridge-Datei und sehen Sie zu, wie Ihre lokalen Topics im Portal erscheinen. Weitere Pi-Projekte finden Sie im Raspberry Pi MQTT Tutorial.
Häufig gestellte Fragen
Warum weist Mosquitto nach der Installation Verbindungen anderer Geräte ab?
Mosquitto 2.0 lauscht nur auf localhost und weist anonyme Clients ab, solange Sie keinen Listener konfigurieren. Ergänzen Sie listener 1883 0.0.0.0 mit allow_anonymous false und einer Passwortdatei.
Sollte ich meinen Mosquitto-Broker auf dem Raspberry Pi ins Internet stellen?
Das wird nicht empfohlen. Binden Sie ihn stattdessen ausgehend per Bridge an einen Cloud-MQTT-Broker an, damit der Fernzugriff über einen TLS-gesicherten Dienst läuft und Ihr Router alle eingehenden Ports geschlossen hält.
Kann Mosquitto auf einem Raspberry Pi viele Geräte bewältigen?
Für ein Zuhause oder einen kleinen Standort bewältigt ein Pi typischen Sensorverkehr mühelos. Die ersten Grenzen sind meist der Verschleiß der SD-Karte und der Wartungsaufwand, nicht der reine Durchsatz.
Braucht die Bridge ein spezielles Konto bei ConnectMQ?
Nein. Die Bridge ist ein normaler MQTT-Client und verwendet daher denselben Benutzernamen, dasselbe Passwort und dieselbe Client-ID, die das Portal für jedes Gerät generiert.
