Eine Automation kann erfolgreich aussehen, obwohl die Aktion, die du testen wolltest, gar nicht ausgeführt wurde. Vielleicht stammt die Benachrichtigung noch von gestern. Vielleicht hat der Button Aktionen ausführen im Automationseditor sie erstellt, ohne Auslöser oder Bedingungen zu prüfen. Oder ein Dienstaufruf wurde angenommen, obwohl seine Daten auf das falsche Ziel verwiesen.
Ein brauchbarer Test muss diese Möglichkeiten auseinanderhalten. Verwende dafür eine fiktive MQTT-Nachricht, eine temporäre Automation, die du selbst verwaltest, und eine dauerhafte Benachrichtigung mit eindeutiger Kennung. Halte das Ziel eng gefasst: Du willst feststellen, ob ein protokollierter Automationslauf zu einem bestimmten Zeitpunkt eine einzelne harmlose Aktion erreicht hat. Damit testest du weder ein echtes Gerät noch die langfristige Zuverlässigkeit eines Brokers oder die Identität eines Geräts im Netzwerk.
Falls ein unbekannter Client Anlass für die Prüfung war, kläre dessen Zuordnung separat. Alle Geräte in deinem Netzwerk und ihre IP-Adressen finden erklärt, wie du lokale Beobachtungen mit Router-Aufzeichnungen abgleichst, bevor du ein Gerät zuordnest. Das Ergebnis einer Automation belegt weder, wem ein Gerät gehört, noch ob es im Netzwerk vorhanden ist.
Die Aktion als Beleg
Schreib vor dem Bearbeiten der Automation in einem Satz auf, was du nachweisen willst. Zum Beispiel: „Um 14:30 Uhr hat die MQTT-Nachricht auf lab/action-check/2026-11-05/event mit dem Wert fictional_check für kind die Automation automation.lab_action_check dazu gebracht, die Benachrichtigung lab_action_check_2026_11_05 zu erstellen.“
Vier Teile musst du unabhängig voneinander prüfen: Topic und Inhalt der Nachricht, die Automation, die Aktion und das sichtbare Ergebnis. Bleibt einer davon unklar, beantwortet eine später auftauchende Benachrichtigung deine Frage nicht. Vermeide Topics, die ein NAS, ein Router, eine Sicherheitsmeldung oder eine bestehende Integration verwendet. Bei einem Test-Topic mit dem heutigen Datum ist die Gefahr geringer, dass es versehentlich erneut verwendet wird.
Wähle für die erste Prüfung eine Aktion ohne Auswirkungen nach außen. Die Integration für dauerhafte Benachrichtigungen in Home Assistant eignet sich dafür gut: Die Nachricht bleibt in der Oberfläche sichtbar, bis du sie schließt, und beim Dienst zum Erstellen kannst du eine Benachrichtigungskennung angeben. Ein Logbucheintrag oder ein eigens angelegter Helfer kann denselben Zweck erfüllen. Fang nicht mit einem Schloss, einem Schalter, einem Alarm, einem Neustart, einer Nachricht an eine andere Person oder einer Änderung an der Netzwerkkonfiguration an.
Die Kennung ist wichtig. Ein fester, aussagekräftiger Wert wie lab_action_check_2026_11_05 unterscheidet dieses Ergebnis von einer allgemeinen Benachrichtigung, die ein anderer Test hinterlassen hat. Verwende darin keine Zugangsdaten, echten Gerätenamen, privaten Adressen oder Kundendaten.
Eindeutig fiktive Testdaten
Veröffentliche eine kleine JSON-Nachricht über einen Testclient, den du selbst kontrollierst. Dieses Beispiel ist bewusst fiktiv:
~~~json { "kind": "fictional_check", "label": "Tutorial sensor", "note": "harmless action verification" } ~~~
Verwende ein Topic wie lab/action-check/2026-11-05/event und notiere den genauen Zeitpunkt der Veröffentlichung. Veröffentliche die Nachricht für diesen Test des Ereignisablaufs ohne Retain. Eine mit Retain gespeicherte Nachricht kann später eintreffen, wenn sich ein Abonnent erneut verbindet. Dieses Verhalten lässt sich sinnvoll separat testen, zeigt aber nicht, dass gerade ein neues Ereignis stattgefunden hat.
Sende die Testnachricht genau einmal. Wenn du sie so lange sendest, bis eine Benachrichtigung erscheint, fehlt dir die eindeutige zeitliche Zuordnung, um das Ergebnis auszuwerten. Schlägt der erste Lauf fehl, prüfe den protokollierten Auslöser, die Bedingungen und die Aktion, bevor du für einen weiteren Test eine einzelne Variable änderst.
Bei MQTT-Topics zählt die Groß- und Kleinschreibung. Lab/action-check und lab/action-check sind unterschiedliche Topics, ebenso /event und /events. Das Topic in deiner notierten Aussage muss Zeichen für Zeichen mit der Automationskonfiguration und dem Befehl zum Veröffentlichen übereinstimmen.
Eine temporäre Automation mit klar begrenzter Aufgabe
Verwende einen MQTT-Auslöser mit dem exakten Test-Topic. Falls du nach einem JSON-Wert filterst, muss die Bedingung oder der Auslöserfilter auf den fiktiven Wert von kind passen und darf keine Daten einer echten Integration erfassen.
Gib der Automation einen klar erkennbaren temporären Namen, etwa „Labor: Prüfung der dauerhaften Benachrichtigung 2026-11-05“, und prüfe vor dem Senden der Nachricht, ob sie aktiviert ist. Füge eine einzelne Aktion persistent_notification.create hinzu. Die Nachricht kann die harmlose Bezeichnung aus den Testdaten wiederholen. Ihr Titel sollte sie als Testergebnis kennzeichnen, nicht als Warnung zu einem Gerät. Setze notification_id in den Dienstdaten auf die eindeutige Benachrichtigungskennung und kopiere dieselbe Kennung in den Titel oder die Nachricht, damit sie in der Oberfläche sichtbar ist.
Eine zweite Aktion ist nicht nötig, nur damit der Test gründlicher wirkt. Wenn du eine Benachrichtigung, einen Logeintrag, eine erneute MQTT-Veröffentlichung und ein Helfer-Update in eine Automation packst, hast du vier mögliche Fehlerstellen. Prüfe zuerst eine Aktion. Füge erst dann eine weitere hinzu, wenn die erste eindeutig belegt ist.
Entferne vor der Veröffentlichung eine eventuell vorhandene ältere Benachrichtigung mit derselben Kennung oder wähle eine neue Kennung mit Datum. Sonst kann eine echte, aber veraltete Benachrichtigung einen fehlgeschlagenen neuen Lauf erfolgreich aussehen lassen. Notiere, wann du das alte Ergebnis entfernt hast. Dieser Zeitpunkt gehört ins Testprotokoll, belegt aber nicht, dass eine Aktion ausgeführt wurde.
Manuelle Aktionen und Automationsauslöser
In Home Assistant kannst du die Aktionen einer Automation manuell ausführen. Damit lässt sich prüfen, ob ein Dienstaufruf für eine Benachrichtigung syntaktisch akzeptiert wird und die erwartete Anzeige erzeugt. Dabei werden der Auslöser und die übergeordneten Automationsbedingungen übersprungen. Bedingungen innerhalb der Aktionsfolge werden weiterhin geprüft. Das beweist also weder, dass MQTT die Testnachricht zugestellt hat, noch, dass die übergeordneten Automationsbedingungen erfüllt waren.
Wenn du Aktionen ausführen verwendest, halte das Ergebnis als reine Aktionsprüfung fest. Schließe danach die Benachrichtigung oder ändere die Kennung, bevor du den vollständigen Test durchführst. Beschreibe die beiden Ergebnisse in getrennten Sätzen. „Die Aktion kann eine Benachrichtigung erstellen“ und „Die fiktive MQTT-Nachricht hat die Aktion erreicht“ sind zwei unterschiedliche Beobachtungen.
Ein erfolgreicher Aufruf eines Dienstes zur MQTT-Veröffentlichung hat eine ähnliche Grenze: Er bedeutet, dass Home Assistant eine Anfrage zur Veröffentlichung angenommen hat. Allein daraus geht nicht hervor, ob der Broker die Nachricht an die abonnierende Automation zurückgeliefert hat, ob der Payload-Filter passte oder ob die Aktion abgeschlossen wurde. Ein angenommener Dienstaufruf liefert einen Ansatzpunkt für die weitere Prüfung. Er ist noch nicht das Endergebnis.
Getrennte Prüfung von Lauf und Benachrichtigung
Öffne nach der einmaligen Veröffentlichung den Trace oder ein anderes Ausführungsprotokoll der Automation. Suche einen Lauf mit einem Zeitstempel nach dem notierten Veröffentlichungszeitpunkt. Prüfe, ob die Auslöserdaten das separate Test-Topic nennen und die fiktive Payload enthalten. Verfolge den Lauf dann durch alle Bedingungen bis zur Aktion persistent_notification.create.
Der Aktionseintrag sollte zeigen, welchen Dienst und welche Daten die Aktion verwendet hat. Gleiche die im Titel oder in der Nachricht sichtbare eindeutige Kennung mit derselben Markierung in den Aktionsdaten des Trace ab und vergleiche den Erstellungszeitpunkt der Benachrichtigung mit dem Zeitstempel der Aktion im Trace. Eine passende Aktion im Trace und eine passende neue Benachrichtigung stützen die eng begrenzte Aussage, die du aufgeschrieben hast. Sie beweisen nicht, dass eine künftige Nachricht ankommen wird, und sagen nichts über einen tatsächlichen Sensor oder Netzwerkclient aus.
Werte Teilergebnisse vorsichtig aus:
- Kein protokollierter Lauf zum erwarteten Zeitpunkt: Prüfe vor dem Bearbeiten der Aktion, ob die Automation aktiviert ist, welcher Broker ausgewählt ist, ob das Topic richtig geschrieben ist und wann die Nachricht veröffentlicht wurde.
- Ein Lauf stoppt an einer Bedingung: Prüfe die tatsächlichen Auslöserdaten und den Bedingungsausdruck. Geh nicht davon aus, dass dieser Lauf eine sichtbare Benachrichtigung erstellt hat.
- Die Aktion erscheint im Lauf, aber keine neue Benachrichtigung ist sichtbar: Gleiche die Kennung und die Dienstdaten der Aktion mit den von der Integration erwarteten Feldern ab. Suche anschließend nach einer älteren Benachrichtigung mit derselben Kennung.
- Eine Benachrichtigung ist sichtbar, aber im protokollierten Lauf fehlt die passende Aktion: Ordne sie vorläufig einem anderen Lauf oder einer manuellen Aktion zu, bis Zeitstempel und Kennungen sie mit diesem Test verbinden.
Auch Automationsmodi können das Ergebnis beeinflussen. Im Modus single kann ein neuer Auslöser ignoriert werden, solange ein früherer Lauf noch aktiv ist. Ändere den Modus nicht bloß, damit der Test erfolgreich aussieht. Kläre zuerst, ob der erwartete Lauf stattgefunden hat und warum er die Aktion erreicht hat oder nicht.
Ein Testprotokoll für spätere Wiederholungen
Speichere außerhalb von Home Assistant ein kurzes Testprotokoll: Automationsname, separates Topic, fiktive Payload, Retain-Einstellung, Veröffentlichungszeitpunkt, Trace- beziehungsweise Laufzeitpunkt, Benachrichtigungskennung und beobachtetes Ergebnis. Lass Zugriffstoken, Broker-Passwörter, echte Hostnamen und echte Gerätekennungen weg.
Dieses Protokoll hilft mehr als eine pauschale Aussage wie „MQTT funktioniert“. Nach einem Home-Assistant-Update, einem Broker-Neustart oder einer Konfigurationsänderung liefert es der nächsten Person bei der Fehlersuche einen genauen Vergleichspunkt. Außerdem zeigt es, ob der Test einen MQTT-Auslöser oder nur eine manuell gestartete Aktion abgedeckt hat.
DeviceShelf Server kann Netzwerkbeobachtungen über MQTT Discovery an eine von dir verwaltete Home-Assistant-Installation veröffentlichen. Wenn du eine Automation auf Grundlage dieser Daten testest, prüfe zuerst den oben beschriebenen Ablauf mit den harmlosen Testdaten. Gleiche danach die Zeitstempel mit dem Ursprungsdienst und den Router-Aufzeichnungen ab. Eine dauerhafte Benachrichtigung bestätigt nur die Aktion eines einzelnen konfigurierten Ablaufs. Sie garantiert weder Geräteidentität noch Verfügbarkeit oder Zustellung und erlaubt keine verlässliche Aussage zur Sicherheit.
Deaktiviere oder entferne nach Abschluss die temporäre Automation und schließe die Testbenachrichtigung. Entferne auch alle mit Retain gespeicherten Testdaten, die du für einen separaten Test angelegt hast. So verhinderst du, dass später jemand alte Testdaten für eine aktuelle Betriebsmeldung hält.