Ein MQTT-Ereignis klingt erst mal einfach: Ein Publisher sendet eine Nachricht, und eine Automation reagiert darauf. Schwieriger ist die Frage, was diese Nachricht bedeutet. Ein Gerät taucht im Netzwerk auf, wird erreichbar, geht offline oder bietet einen veränderten Dienst an. Das kann eine nützliche Information sein. Dahinter kann aber auch ein normaler Neustart, ein Smartphone im Ruhezustand oder ein WLAN-Wechsel stecken.
Diese Anleitung ist für eine Home-Assistant-Installation und einen MQTT-Broker gedacht, die dir gehören oder die du administrierst. Du erfährst, wie du aus Geräteereignissen Automationen machst, die du gezielt testen kannst, ohne jede Beobachtung im Netzwerk als Notfall zu behandeln.
Ein klar definiertes Ereignis
MQTT sendet Anwendungsnachrichten an benannte Topics. Ein Subscriber empfängt Nachrichten für die Topics, die er abonniert hat. MQTT allein sagt dem Subscriber nicht, wie die Payload zu interpretieren ist. MQTT legt fest, wie Nachrichten zugestellt und Topics zugeordnet werden. Was die Payload bedeutet, bestimmt der Publisher. Halte deshalb vor dem Erstellen einer Automation genau fest, wodurch das Ereignis ausgelöst wird. OASIS: MQTT Version 5.0
Für die Netzwerküberwachung kommen Ereignisnamen wie new_device, device_online, device_offline oder new_port infrage. Jeder davon bedeutet etwas anderes. Ein new_device-Ereignis kann bedeuten, dass die Netzwerküberwachung eine Kennung zum ersten Mal in ihrem Inventar erfasst hat. Das sagt nichts darüber aus, wem das Gerät gehört oder ob es unerwünscht ist. Ein Offline-Ereignis kann durch ausgebliebene Antworten auf Prüfungen entstehen. Es beweist keinen Stromausfall.
Definiere das Ereignis in einem Satz, bevor du Home Assistant konfigurierst: „Dieses Ereignis wird gesendet, wenn …“ Halte dabei fest, von wo aus die Beobachtung erfolgt, welches Zeitfenster gilt und welche Fälle ausgeschlossen sind. Sonst behauptet eine Bezeichnung wie „Eindringlingsalarm“ schnell mehr, als die Daten hergeben.
Discovery- und Ereignisnachrichten
Die MQTT-Integration von Home Assistant kann Geräte und Entitäten anhand von MQTT-Discovery-Nachrichten erkennen. Du kannst Geräte auch manuell konfigurieren. Discovery beschreibt, wie Home Assistant eine Entität anlegen oder wiederherstellen soll. Eine Ereignisnachricht meldet eine spätere Zustandsänderung oder ein Vorkommnis, das eine Automation nutzen kann. Diese Abläufe hängen zusammen. Dass eine Discovery-Konfiguration als Retained-Nachricht gespeichert wird, bedeutet aber nicht, dass auch ein Ereignis so gespeichert oder erneut zugestellt werden sollte. Home Assistant: MQTT-Integration
Nach einem Neustart des Brokers oder von Home Assistant werden Discovery-Informationen möglicherweise erneut verarbeitet, bevor Geräte und Entitäten verfügbar sind. Ein Publisher kann auf die Birth-Nachricht von Home Assistant reagieren, indem er die Discovery-Daten erneut veröffentlicht. Ob normale Ereignisse gefahrlos verzögert oder wiederholt zugestellt werden können, musst du gesondert beurteilen. Home Assistant: MQTT-Discovery-Nachrichten und Verfügbarkeit
Beginne mit einer dokumentierten Ereignisentität oder einem dokumentierten Zustands-Topic. Verwende den weit gefassten Topic-Filter # nicht als dauerhaften Auslöser. Die Funktion „Auf ein Topic hören“ ist praktisch für einen schnellen Blick auf die Nachrichten. Eine dauerhaft laufende Automation sollte ihre Quelle gezielt eingrenzen.
Prüfung echter Nachrichten vor den ersten Benachrichtigungen
Die Meldung aufs Smartphone kommt später. Schau dir zuerst ein paar echte Nachrichten an, während du eine harmlose Änderung vornimmst, die du in den Nachrichten wiederfinden solltest: Verbinde ein Testgerät neu, starte einen Dienst in der Testumgebung neu oder ändere die Netzwerkverbindung eines bekannten Geräts. Öffne die MQTT-Integration in Home Assistant und nutze die Funktion „Auf ein Topic hören“ für das dokumentierte Topic. Notiere das Topic, die Payload-Felder, die Uhrzeit und eine eventuell vorhandene eindeutige Kennung. Die Dokumentation der Integration erklärt, wie du mit # vorübergehend Nachrichten prüfen und die Ansicht mit einem Filter auf ein bestimmtes Topic eingrenzen kannst. Home Assistant: Mithören auf einem MQTT-Topic
Prüfe in den erfassten Daten vier Punkte:
- Identität: Welches dauerhaft gleichbleibende Feld identifiziert die Quelle? Verwende bevorzugt eine dokumentierte Geräte-ID oder eine Kombination aus Inventar-ID und MAC-Adresse statt nur eines Anzeigenamens.
- Zeitstempel: Liefert der Publisher eine Zeitangabe mit? Falls ja, ist eindeutig, ob sie den Zeitpunkt der Erkennung, der Veröffentlichung oder der letzten Sichtung angibt?
- Grund: Lässt sich anhand der Payload unterscheiden, ob ein Gerät erstmals gesehen wurde, sich neu verbunden hat, neu gestartet wurde oder ein Fehler aufgetreten ist?
- Duplikate: Löst eine einzelne Änderung am Gerät oder im Netzwerk mehrere Nachrichten aus? Zeichne einen kurzen Testablauf auf, bevor du eine Regel zur Unterdrückung von Meldungen ergänzt.
Wenn die Payload deiner Automation nicht genug Kontext liefert, bleib während der Tests bei einem Eintrag im Home-Assistant-Logbuch. Leite Gerätename, Besitzer, Standort oder die Schwere eines Sicherheitsvorfalls nicht allein aus einer MAC-Adresse oder einer Herstellerabfrage ab.
Eine erste Automation mit begrenzten Folgen
Ein Protokolleintrag ist in dieser Phase meist nützlicher als ein Alarm. Erstelle zum Beispiel eine Benachrichtigung mit dem Text „Die Netzwerküberwachung hat ein Ereignis zu einem neuen Gerät gemeldet; prüfe das Inventar“ und ergänze nur Felder, die der Publisher tatsächlich geliefert hat. Als Administrator kannst du das Ereignis dann mit einer Liste bekannter Geräte, der Clientliste des Routers oder den Daten von Switches und Access Points abgleichen.
Grenze den Auslöser eng ein. Ergänze eine Bedingung, die zur Bedeutung des Ereignisses passt: Ein new_device-Ereignis ist vielleicht nur dann einen Eintrag wert, wenn seine dauerhafte Kennung noch nicht in einer dokumentierten Liste erlaubter Geräte steht. Bei einem device_offline-Ereignis möchtest du möglicherweise nur für ein bestimmtes NAS, einen Access Point oder einen Host mit wichtigen Diensten eine Meldung erhalten, und auch dann erst nach Ablauf der Wartefrist der Netzwerküberwachung. Löse aufgrund einer allgemeinen Meldung wie „Gerät ist offline gegangen“ keine Sicherheitsmaßnahme aus.
Baue einen ausdrücklichen Testmodus ein und leite das Ergebnis zunächst an eine dauerhafte Benachrichtigung, das Logbuch oder einen unaufdringlichen Testkanal weiter. Wiederhole die bekannte Änderung. Lief die Automation genau einmal und mit den erwarteten Feldern? Wenn dein Publisher oder Broker Nachrichten erneut zustellen kann, teste auch nach einem Neustart. Ein erfolgreicher Test zeigt nur, dass genau dieser Ablauf funktioniert. Er belegt nicht, dass jedes Gerät erkannt oder jeder Ausfall erklärt wird.
Weniger Meldungen durch Auswertung beobachteter Ereignisse
Netzwerkereignisse kommen oft gehäuft. WLAN-Clients wechseln den Access Point und Geräte gehen in den Ruhezustand; Router starten neu und DHCP-Einträge ändern sich. Eine kurze Sperrzeit kann wiederholte Meldungen verhindern. Richte sie aber nach dem beobachteten Verhalten aus, statt einen Wert aus einem anderen Netzwerk zu übernehmen. Führe während der Tests eine kleine Tabelle mit Ereignistyp, Quelle, Uhrzeit, tatsächlichem Geschehen und der Angabe, ob die Benachrichtigung nützlich war.
Lege für jeden Zweck eine eigene Regel an. Eine kann ein erstmals gesehenes Gerät zur späteren Prüfung protokollieren. Eine andere meldet dir, wenn ein NAS nicht mehr erreichbar ist, während eine dritte wiederkehrende Ereignisse für eine tägliche Zusammenfassung sammelt. Wenn du alles in eine einzige Automation packst, lässt sich die Empfindlichkeit nur schwer anpassen, ohne versehentlich wichtige Meldungen zu unterdrücken.
Schicke keine Zugangsdaten, vollständigen Netzwerkinventare oder ungeschwärzten MAC- und IP-Listen in Benachrichtigungen aufs Smartphone. In der lokalen Home-Assistant-Historie oder einem geschützten Dashboard können diese Angaben nützlich sein. Der Inhalt von Benachrichtigungen kann jedoch auf Sperrbildschirmen und in Backups auftauchen. Wenn ein berechtigter Administrator mehr Details braucht, verlinke den lokalen Eintrag.
Die Rolle eines Publishers für das Netzwerkinventar
Ein MQTT-Publisher, der Beobachtungen aus dem Netzwerk bereitstellt, ermöglicht Home Assistant, strukturiert auf Änderungen zu reagieren. Er bleibt trotzdem nur eine Informationsquelle unter mehreren. Die Server-Edition von DeviceShelf ist eine Möglichkeit: Ihr dokumentierter Home-Assistant-Export nutzt MQTT Discovery und stellt eine Ereignisentität für new_device, device_online, device_offline und new_port bereit. Sieh diese Ereignisse als Aufforderung, das zugrunde liegende Inventar zu prüfen. Sie liefern keine automatischen Schlussfolgerungen zur Sicherheit oder dazu, wem ein Gerät gehört. Server-Dokumentation
Dasselbe Vorgehen gilt für jeden Publisher. Beschränke den Zugriff auf den Broker auf die Systeme, die ihn brauchen, und verwende ein eigenes Konto mit so wenigen Berechtigungen, wie die Integration erlaubt. Prüfe die aktuelle Dokumentation des Publishers, bevor du Einstellungen für Discovery, Verfügbarkeit oder Retained-Nachrichten änderst. Die Einrichtungsanleitung von Home Assistant erklärt, wie du die MQTT-Integration unter „Geräte & Dienste“ konfigurierst, ohne ein bestimmtes Add-on oder eine benutzerdefinierte Komponente vorauszusetzen. Home Assistant: MQTT einrichten
Prüfung der Automation nach normalen Netzwerkänderungen
Vergleiche eine Woche lang jedes Ereignis mit dem, was tatsächlich passiert ist. War das Gerät neu, hat es sich nur erneut verbunden oder war es bereits unter einer privaten WLAN-Adresse bekannt? Hat ein geplanter Neustart das Offline-Ereignis ausgelöst? Kam die Portänderung durch ein beabsichtigtes Dienst-Update zustande? Markiere falsche oder wenig hilfreiche Ereignisse und passe dann gezielt die Regel an, die darauf reagiert hat.
Diese Prüfung hilft dir, die Automation für den Alltag zuverlässig genug zu machen. Ein paar Ereignisse, die du erklären kannst, sind mehr wert als ein Dashboard voller Meldungen oder eine dringlich klingende Benachrichtigung, mit der niemand etwas anfangen kann. Du brauchst ein wiederholbares Vorgehen, um anhand der Beobachtungen aus deinem Netzwerk zu entscheiden, ob du ein Ereignis protokollierst, prüfst, genauer untersuchst oder ignorierst.