MQTT mit Postman testen

Ja, du kannst MQTT mit Postman testen: neuen Request anlegen, MQTT wählen, Broker-URL eintragen, verbinden, Topics zum Abonnieren hinzufügen und Nachrichten im Composer publizieren. Das ist praktisch, um einen Broker anzutesten, wenn Postman ohnehin dein API-Werkzeug ist — aber es ist ein manueller Client, kein automatisierter MQTT-Test-Runner. Dieser Guide zeigt den Ablauf, die Einstellungen, an denen man hängen bleibt, und wo Postman nicht mehr das richtige Werkzeug ist.

Einen MQTT-Request anlegen

1. Klicke in Postman auf New (oder das + neben den Tabs) und wähle MQTT.
2. Trage im URL-Feld die Broker-Adresse mit Schema und Port ein, zum Beispiel mqtt://broker.connectmq.com:1883.
3. Öffne die Request-Einstellungen und setze eine Client-ID, wenn du eine vorhersehbare willst; sonst erzeugt Postman eine.
4. Verlangt dein Broker Authentifizierung, trage Benutzername und Passwort ein (nutze Variablen wie {{mqtt_user}} und {{mqtt_pass}} aus einem Environment, statt Secrets in den Request zu tippen).
5. Klicke auf Connect. Der Nachrichtenbereich zeigt das Verbindungsereignis oder einen Fehler, falls der Broker ablehnt.

Die Protokollversion (3.1, 3.1.1 oder 5) wählst du in den Request-Einstellungen. Mit MQTT 5 bekommst du zusätzlich Felder für Connect-Properties und User Properties bei publizierten Nachrichten.

Unsicher, welchen Port dein Broker nutzt? MQTT-Ports erklärt behandelt 1883, 8883, 8083/8084 und die Alternativen hinter Proxys.

Topics abonnieren

Wechsle in den Bereich Topics des Requests, füge einen Topic-Filter hinzu und wähle einen QoS. Wildcards funktionieren wie gewohnt — testmqtt/postman/# empfängt alles unter diesem Präfix, testmqtt/postman/+/status eine Ebene von Geräten. Eingehende Nachrichten erscheinen in der Liste mit Topic, Zeit und Payload; JSON-Payloads lassen sich aufklappen.

Nutze beim Testen ein eindeutiges Präfix. Auf einem geteilten Endpoint zeigt dir ein Abo auf # oder einen generischen Namen wie test/# den Traffic anderer Leute, und deinen eigenen findest du kaum noch. Wenn ein Filter nicht wie erwartet matcht, füge ihn zusammen mit dem Ziel-Topic in den Topic Matcher ein.

Nachrichten publizieren

Der Composer unten im Request publiziert jeweils auf ein Topic:

• Topic: zum Beispiel testmqtt/postman/device-1/telemetry
• Payload: Text oder JSON wie {"temp": 21.5, "unit": "C"}
• QoS: 0, 1 oder 2
• Retain: an, wenn neue Abonnenten sofort den letzten Wert bekommen sollen

Gespeicherte Nachrichten helfen bei wiederholten Checks — leg dir "einschalten", "ausschalten" und "fehlerhafter Payload" im selben Request an und schicke sie nacheinander ab. Da der Request selbst abonniert ist, siehst du deine eigenen Nachrichten ankommen und hast damit den Round Trip über den Broker bestätigt.

Ein nützlicher Hybrid: HTTP rein, MQTT raus

Postman glänzt, wenn dein System HTTP und MQTT mischt. Öffne zwei Tabs:

1. Einen MQTT-Request, der das Topic abonniert, auf das dein Backend publiziert, z. B. testmqtt/postman/orders/#.
2. Einen HTTP-Request, der deine API aufruft — POST /orders, einen Webhook, einen Endpoint für Gerätebefehle.

Sende den HTTP-Request und beobachte den MQTT-Tab: Du siehst, ob das Backend publiziert hat, auf welches Topic, mit welchem Payload und Retain-Flag. Das ist der schnellste manuelle Check für "die API liefert 200, aber das Gerät reagiert nie".

Fehlersuche bei Postman-MQTT-Verbindungen

Reason Codes des Brokers (zum Beispiel 0x87 Not authorized in MQTT 5) schlägst du im MQTT-Reason-Code-Tool nach.

Grenzen, die du kennen solltest

Die MQTT-Unterstützung in Postman ist zum Erkunden gedacht, nicht zur Testautomatisierung. Zum Zeitpunkt des Schreibens gilt:

• Keine Testskripte. HTTP-Requests können pm.test-Assertions ausführen; MQTT-Requests können eingehende Nachrichten nicht prüfen.
• Kein Collection Runner, kein Newman. MQTT-Requests lassen sich in Collections speichern, aber nicht mit Newman in der CI ausführen.
• Eine Verbindung pro Tab. Zehn Geräte simulieren heißt zehn Tabs — oder ein anderes Tool.
• Desktop-orientiert. Nicht-HTTP-Protokolle in der Browser-Version von Postman können den Postman Desktop Agent erfordern.

Postman entwickelt sich schnell weiter, also prüfe die Dokumentation deiner Version. Brauchst du heute etwas davon, nimm ein Tool, das es nativ kann.

Alternativen zum Testen von MQTT

Für einen CI-tauglichen Check, den Postman nicht kann, reichen zwei mosquitto-Befehle:

TOPIC="testmqtt/postman/ci-$RANDOM"
mosquitto_sub -h broker.connectmq.com -p 1883 -t "$TOPIC" -C 1 -W 10 > out.txt &
sleep 1
mosquitto_pub -h broker.connectmq.com -p 1883 -t "$TOPIC" -m '{"ok":true}' -q 1
wait
grep -q '"ok":true' out.txt && echo "PASS" || { echo "FAIL"; exit 1; }

-C 1 beendet nach einer Nachricht und -W 10 scheitert nach zehn Sekunden, das Skript hängt also nie. Weitere Muster findest du in den Beispielen zu mosquitto_pub und mosquitto_sub, und die besten MQTT-Client-Tools vergleicht die GUI-Optionen ausführlich.

Mit dem Browser-MQTT-Client vergleichen

Der MQTT-Request von Postman ist ein gutes manuelles Werkzeug, wenn dein Team ohnehin in Postman arbeitet — vor allem, um zu prüfen, dass HTTP-Aktionen die richtigen MQTT-Nachrichten erzeugen. Für alles Wiederholbare — Regressionstests, Last, viele simulierte Geräte — verschiebe dieselben Checks in Skripte oder einen dedizierten MQTT-Client und nutze Postman zum Erkunden.

Häufig gestellte Fragen