Eine MQTT-Automation kann fertig aussehen, obwohl sie noch keine einzige Nachricht von einem Broker verarbeitet hat. Die YAML-Konfiguration lässt sich speichern, eine manuell ausgeführte Aktion erzeugt eine Benachrichtigung, und das Dashboard sieht richtig aus. Das ist gut zu wissen. Es beweist aber nicht, dass Topic, Payload-Filter, Template und Aktion zusammenspielen, wenn ein Publisher ein Ereignis sendet.
Ein kleines fiktives Ereignis eignet sich besser als erster Test. Verwende ein reserviertes Test-Topic, Daten ohne Bezug zu echten Personen oder Geräten und eine harmlose Aktion mit sichtbarem Ergebnis. Die Frage ist klar eingegrenzt: Hat diese Automation diese Nachricht zu diesem Zeitpunkt verarbeitet? Ein erfolgreicher Test beweist weder, dass ein Gerät vorhanden ist, noch, dass ein Scanner es immer findet oder MQTT jede künftige Nachricht zustellt.
Die Beispiele verwenden Home Assistant. Der Unterschied zwischen einer Prüfung im Editor, einer manuell ausgeführten Aktion und einem Test des gesamten Ereigniswegs gilt aber für jeden MQTT-Consumer. Verwende nur einen Broker und eine Automation, die du selbst verwaltest.
Ein klares Testziel vor der Bearbeitung
Schreib das gewünschte Ergebnis in einem Satz auf. Zum Beispiel: Eine JSON-Nachricht auf lab/automation-test/2026-10-31/event mit dem Ereignistyp new_device erzeugt genau eine dauerhafte Benachrichtigung. Damit legst du ein Topic, ein Payload-Feld, einen passenden Wert und eine beobachtbare Aktion fest. Das lässt sich viel leichter prüfen als die vage Aussage, dass MQTT funktioniert.
Trenne die verschiedenen Aussagen voneinander. Eine erfolgreich verarbeitete fiktive Nachricht belegt den Weg von einem bekannten Publisher über einen Broker zu einer Automation. Sie identifiziert kein echtes Gerät, weist keinen Einbruch nach und garantiert keine genau einmalige Zustellung. Wenn du entscheiden willst, ob du ein Gerät näher untersuchen musst, halte zuerst unabhängige Beobachtungen fest. Alle Geräte in deinem Netzwerk und ihre IP-Adressen finden erklärt, wie du ein Inventar mit Router-Informationen abgleichst, ohne einen Namen als Identitätsnachweis zu behandeln.
Wähle eine sichere erste Aktion. Verwende eine dauerhafte Benachrichtigung, einen Logbucheintrag oder einen eigenen Helfer, statt einen Schalter, ein Schloss, einen Alarm oder eine Netzwerkeinstellung zu ändern. Eine Benachrichtigung liefert dir außerdem einen Zeitstempel, den du mit dem Trace der Automation vergleichen kannst.
Ein eigenes Test-Topic
Lege ein Topic unter einem Präfix an, das du kontrollierst, und ergänze ein Datum oder eine Testkennung. Verwende zum Beispiel lab/automation-test/2026-10-31/event. Das fällt im Broker-Log schnell auf und überschneidet sich kaum mit einer produktiven Integration. Später kannst du es leicht wieder entfernen.
Vermeide Topics, die mit einer Aktion mit echten Folgen verbunden sind. Verwende im Beispiel keine echten Zugangsdaten, privaten Adressen, Kundennamen oder Kennungen tatsächlich genutzter Geräte. Eindeutig fiktive Daten machen den Test leichter wiederholbar und nachvollziehbar.
MQTT gleicht Topics exakt ab, sofern du nicht ausdrücklich Wildcards konfiguriert hast. Das s am Ende macht einen Unterschied: lab/automation-test/2026-10-31/event und lab/automation-test/2026-10-31/events sind verschiedene Topics. Auch Groß- und Kleinschreibung zählt. Wenn ein Trigger nicht auslöst, vergleiche zuerst das Topic des Publishers Zeichen für Zeichen mit dem Topic des Triggers, bevor du etwas anderes änderst.
Eine Automation mit eng gefasstem Filter
Dies ist eine einzelne Home-Assistant-Automation für den YAML-Editor, keine vollständige configuration.yaml. Sie lauscht auf dem reinen Test-Topic und akzeptiert nur ein JSON-Ereignis, dessen event_type den Wert new_device hat.
~~~yaml alias: MQTT-Test mit fiktivem Ereignis description: Prüfen, ob eine reine MQTT-Testnachricht diese Automation erreicht. triggers:
- trigger: mqtt topic: lab/automation-test/2026-10-31/event value_template: "{{ (value_json.event_type | default('')) if value_json is defined and value_json is mapping else '' }}" payload: new_device conditions: [] actions:
- action: persistent_notification.create data: notification_id: mqtt_fictional_event_check title: MQTT-Test empfangen message: >- Fiktives Ereignis empfangen für {{ trigger.payload_json.name | default('unbenanntes Beispiel', true) }}. mode: single ~~~
Das Value-Template liest event_type aus, und die Payload-Bedingung vergleicht den Wert mit new_device. Ungültiges JSON oder ein fehlendes Feld ergibt einen leeren Wert und damit keinen Treffer. Das ist Absicht: Der Test soll eindeutig fehlschlagen, statt eine unpassende Nachricht als Erfolg erscheinen zu lassen.
Speichere die Automation und prüfe, ob sie aktiviert ist. Um zu prüfen, ob der Benachrichtigungsdienst selbst funktioniert, rufe persistent_notification.create separat mit einem festen Nachrichtentext wie „MQTT-Benachrichtigungstest“ auf. Der Button „Aktionen ausführen“ in Home Assistant liefert keine Trigger-Daten, sodass das Nachrichten-Template der gezeigten Automation bei manueller Ausführung fehlschlagen kann. Teste diese Automation durch das Senden einer MQTT-Nachricht; ein erfolgreicher separater Dienstaufruf belegt nicht, dass eine Broker-Nachricht die Automation erreicht hat.
Versand einer fiktiven Nachricht
Verwende das MQTT-Tool „Publish a packet“ in Home Assistant oder einen anderen Publisher, der mit demselben Broker verbunden ist. Lass retain ausgeschaltet. Sende genau einmal an das exakte Test-Topic und verwende diese Payload:
~~~json { "event_type": "new_device", "name": "Beispieldrucker", "ip": "192.0.2.42", "note": "fiktive Testdaten" } ~~~
Die Adresse 192.0.2.42 gehört zu einem für Dokumentation reservierten Adressbereich und bezeichnet keinen Host, den du kontaktieren sollst. Auch der Beispieldrucker ist fiktiv. Diese Payload prüft die Struktur, die der Trigger erwartet. Sie meldet keine tatsächliche Änderung im Netzwerk.
Prüfe nach dem Senden, ob die dauerhafte Benachrichtigung erscheint, und suche dann nach einem neuen Trace der Automation, der zum Sendezeitpunkt passt. Halte den Sendezeitpunkt und das Topic zusammen mit dem Trace des Durchlaufs und dem Ergebnis der Aktion fest. Ein neuer Trace, der die Trigger-Daten und das Ergebnis der Benachrichtigungsaktion zeigt, sagt mehr aus als ein Screenshot des Editors.
Wenn keine Benachrichtigung erscheint, prüfe Folgendes in dieser Reihenfolge:
- Prüfe, ob die Automation gespeichert und aktiviert ist.
- Vergleiche die Topics von Publisher und Trigger auf exakte Übereinstimmung.
- Prüfe, ob Home Assistant und der Publisher den vorgesehenen Broker verwenden.
- Prüfe, ob die Payload gültiges JSON ist und event_type exakt den Wert new_device hat.
- Suche vor jeder Änderung nach einem neuen Trace, der zum Sendezeitpunkt passt. Gibt es keinen, prüfe MQTT-Empfang und Filterung; eine Nachricht, die die Automation nicht auslöst, erzeugt keinen neuen Trace. Gibt es einen, prüfe seine Trigger-Daten und das Ergebnis der Aktion.
Ändere immer nur eine Variable. Wenn du Broker, Topic, Trigger und Payload gleichzeitig austauschst, hast du einen neuen Test erstellt, dessen Ergebnis du nicht einordnen kannst.
Eine Gegenprobe
Sende eine zweite fiktive Nachricht an dasselbe Topic, diesmal mit einem Ereignistyp, der nicht zum Filter passen soll:
~~~json {"event_type":"device_offline","name":"Beispieldrucker","note":"fiktive Daten für die Gegenprobe"} ~~~
Die Automation darf nicht ausgeführt werden. Ohne diese Gegenprobe zeigt die erste Benachrichtigung womöglich nur, dass die Subscription sehr breit gefasst ist. Das erste Ergebnis allein belegt nicht, dass der Filter unpassende Ereignisse abweist.
Vermeide bei diesem Ereignistest Retained Messages. Ein Broker kann eine gespeicherte Retained Message an einen Subscriber senden, der sich erst später verbindet. Für aktuelle Zustände ist das nützlich. Es kann aber täuschen, wenn du prüfen willst, ob ein Ereignis eingetreten ist, nachdem der Empfänger bereit war. Falls auf dem Test-Topic bereits ein Zustand als Retained Message gespeichert ist, isoliere oder lösche ihn nach dem dokumentierten Verfahren des Brokers, bevor du den nächsten Durchlauf auswertest.
Neustarts als separater Test
Sobald der positive Test und die Gegenprobe funktionieren, kann ein Neustart eine andere Frage beantworten: Was passiert, wenn der Empfänger nicht verfügbar ist? Starte die Automation oder Home Assistant in einem geeigneten Wartungsfenster neu und prüfe anschließend die Zeitstempel im Trace. Eine alte Benachrichtigung kann weiterhin sichtbar sein. Dadurch darf ein früheres Ereignis, das ohne retain gesendet wurde, nicht zu einem neuen Ereignis werden.
Availability-Topics brauchen einen eigenen Test. Ein konfigurierter Wert für online oder offline zeigt dir, wie Home Assistant eine Nachricht auf diesem Topic interpretiert hat. Er erklärt aber nicht, warum ein Publisher, Dienst oder Gerät nicht mehr verfügbar war. Teste Wechsel der Verfügbarkeit getrennt von der Ereignisverarbeitung. Notiere dabei, ob die Nachricht mit retain gesendet wurde.
Der Wechsel zu einer echten Integration
Passe die Automation erst dann an einen echten Publisher an, wenn das separate Test-Topic funktioniert. Beschränke die erste Aktion im Produktivbetrieb auf eine Beobachtung. Eine Benachrichtigung mit der Bitte, ein Inventar abzugleichen, ist sicherer als eine automatische Einstufung oder eine Änderung am Netzwerk.
DeviceShelf Server ist ein möglicher Publisher für Beobachtungen im lokalen Netzwerk über MQTT Discovery. Gleiche seine Ausgaben trotzdem mit Router-Aufzeichnungen und Informationen zu bekannten Geräten ab. Eine Nachricht ist kein Beweis für die Identität oder Verfügbarkeit eines Geräts, eine zuverlässige Zustellung oder einen Einbruch.
Führe ein kurzes Testprotokoll mit dem reservierten Topic, der fiktiven Payload, dem Sendezeitpunkt, dem Trace-Ergebnis und allen Änderungen, die du aufgrund des Traces vorgenommen hast. Damit hast du eine wiederholbare Grundlage für die spätere Fehlersuche. Entferne die reine Test-Automation, den Helfer und gespeicherte Retained-Testdaten, sobald du sie nicht mehr brauchst.
Ein erfolgreicher Test belegt eine begrenzte, aber nützliche Tatsache: Ein bekannter Broker hat eine fiktive Nachricht angenommen, und diese Automation hat sie wie konfiguriert verarbeitet. Der Test misst keine langfristige Zuverlässigkeit und ersetzt keine Untersuchung eines Vorfalls. Genau darum geht es bei dieser Übung: diese Grenze klar im Blick zu behalten. Ein ruhiger, wiederholbarer Test ist viel hilfreicher als Rätselraten bei einem echten Ausfall oder einem unerwarteten Geräteereignis.