Connection Observer überwacht deine Smart-Home-Geräte und benachrichtigt dich, wenn die Verbindung abbricht — bevor du selbst merkst, dass ein Lichtschalter nicht mehr reagiert oder ein Sensor keine Werte mehr liefert.
Ich wollte, da einige ZigBee-Geräte immer wieder offline gingen, eigentlich nur eine Benachrichtigungsfunktion bauen, damit ich mitbekomme wann das passiert und wie oft das passiert etc. pp.
Herausgekommen ist eine ganze Integration, mit deutlich mehr/praktischere Funktionen, die ganze Protokolle Überwacht (Zigbee, Z-Wave, Hue, ESPHome, Shelly, Sonos, …). *Aktuell sind es über 100 - auf Wunsch kann das schnell noch erweitert werden. Probiert sie sehr gerne aus. Bei mir läuft sie ohne Probleme und sehr zuverlässig. Durch die einfache Anpassbarkeit kann man überflüssige Meldungen gut herausfiltern - auch wenn es gerade am Anfang durchaus interessant sein kann wie häufig sich einzelne Geräte reconnecten bzw. erst mal offline gehen, ohne dass man es unbedingt mitbekommt.
Beispiel-Benachrichtigungen
Sofort (Deutsch) — mit Raum und Geräteinformationen:
Wohnzimmer Steckdose (shelly) hat um 14:32 die Verbindung verloren. Wohnzimmer · Shelly Plus 1PM
Zusammenfassung (Deutsch):
3 Gerät(e) seit der letzten Zusammenfassung betroffen: • Küchen-Sensor [Küche] (zha): offline seit 12.05. 07:15, wieder online um 07:42 • Schlafzimmer Birne [Schlafzimmer] (hue): offline seit 12.05. 09:05 noch offline • Flur Bewegungsmelder (esphome): offline seit 12.05. 11:20, wieder online um 11:28
Sofortbenachrichtigung – wird direkt gesendet, sobald ein Gerät offline geht
Geplante Zusammenfassung – Sammelnachricht zu konfigurierbaren Tagen und Uhrzeiten mit allen Verbindungsabbrüchen seit der letzten Zusammenfassung
Beide Modi gleichzeitig – Sofort + Zusammenfassung können parallel aktiv sein; Zusammenfassung ist standardmäßig vorausgewählt
Wiederverbindungsbenachrichtigung – optionale Meldung, wenn ein Gerät wieder online geht
Verzögerung – opt-in: Ereignis wird erst erstellt, wenn das Gerät N Minuten offline war — kurze Aussetzer werden komplett ignoriert
Cooldown – opt-in: Sofortbenachrichtigung pro Gerät höchstens alle N Minuten
Mindestausfallzeit – opt-in: kurze Aussetzer werden aus der Zusammenfassung herausgefiltert
Raum / Bereich – opt-in: HA-Bereichsname in Benachrichtigungen einblenden
Hersteller & Modell – opt-in: Geräteinformationen in Sofortmeldungen einblenden
Entitäten ausschließen – einzelne, störungsanfällige Entitäten von der Überwachung ausnehmen
5 Sprachen – Benachrichtigungen auf Englisch, Deutsch, Französisch, Niederländisch oder Spanisch (konfigurierbar)
Benachrichtigungsvorlagen – Texte beliebig anpassen mit Variablen wie {device_name}, {protocol} und {time}
HA-Reparaturen – nach einer konfigurierbaren Offline-Dauer erscheint ein Eintrag im HA Repairs-Panel; wird automatisch gelöst, wenn das Gerät zurückkommt
Testbenachrichtigung – integrierter Testschritt im Setup-Assistenten
Persistenter Zustand – Ereignisse überleben HA-Neustarts; ein Neustart löst keinen falschen Alarm aus
Watchdog – läuft alle 5 Minuten still im Hintergrund und fängt Reconnects ab, die kein State-Change-Event ausgelöst haben
Sehr schön, werde ich gleich mal ausprobieren, nachdem die letzten Tage eins meiner 2 Wohnzimmerrollos bei der Abendautomatik nicht mehr wollte und ichs auf eine der letzten Core- Aktualisierungen geschoben, bei der weiteren Recherche jedoch festgestellt habe, daß der Antrieb immer wieder offline war und ebenso die LED-Birne, über die das Teil verbunden war (Zigbee).
Ja, sowas war auch der Auslöser bei mir, Zigbee-Fensterkontakte, die ich zweckentfremdet habe.
Meine Integration löst zwar das Problem an sich natürlich nicht, aber kann helfen überhaupt Probleme zu identifizieren. Und zumindest ich habe das Gefühl auch viel besser zu wissen was da überhaupt “abgeht”.
Gerade installiert, schöne, einfache Einrichtung ohne komplizierten Schnickschnack. Ich hoffe nur mal, man wird nach einem HA-Neustart nicht mit Benachrichtigen zugebombt, hast du das bedacht oder läuft das über die einstellbare Verzögerung?
Ist bedacht. Die Zustände überleben einen HA-Neustart. Nur ESPHome löst bei mir aus, wenn ich neu starte, bzw. die darüber eingebundenen ESP32er.
Kannst gerne auch in die Doku auf GitHub schauen, da ist ein ganz guter Vorschlag für eine Konfiguration drin, damit man z.B. nicht bei jedem WLAN-Schluckauf benachrichtig wird
Edit: Hier die empfohlene Startkonfiguration:
Empfohlene Startkonfiguration
Sofortbenachrichtigung: aus
Zusammenfassung: ein, täglich um 08:00 Uhr
Verzögerung: 5 Minuten (vermeidet Fehlalarme durch kurze WLAN-Aussetzer)
Mindestausfallzeit: 5 Minuten (hält die Zusammenfassung übersichtlich)
Bereich anzeigen: ein (macht Benachrichtigungen deutlich lesbarer)
HA-Reparaturen-Schwellwert: 24 Stunden
Die anderen Einschränkungen der Integration sind:
13. Bekannte Einschränkungen
Nur-Cloud-Integrationen: Geräte, die ausschließlich über einen Cloud-Dienst verbunden sind, werden möglicherweise nicht erkannt, wenn die Integration bei fehlender Cloud-Verbindung keinen unavailable-Status setzt.
Polling-Integrationen: Eine Verbindungsunterbrechung wird erst nach dem nächsten Abfragezyklus erkannt, was zu einer kurzen Verzögerung führen kann.
Bluetooth-Abdeckung: Geräte, die nur auf der Ebene des rohen Bluetooth-Adapters sichtbar sind, werden möglicherweise nicht abgedeckt.
Nur eine Instanz: Connection Observer unterstützt eine einzige Integrationsinstanz pro HA-Installation.
30-Tage-Ereignisaufbewahrung: Ereignisse, die älter als 30 Tage sind, werden automatisch aus dem Speicher entfernt.
Ich habe leider allerhand Warnmeldungen im Protokoll, mit denen ich so erstmal nichts anfangen kann:
Logger: homeassistant.helpers.frame
Quelle: helpers/frame.py:350
Erstmals aufgetreten: 20. Mai 2026 um 15:50:36 (311 Vorkommnisse)
Zuletzt protokolliert: 17:45:14
Detected that custom integration 'connection_observer' calls hass.async_create_task from a thread other than the event loop, which may cause Home Assistant to crash or data to corrupt. For more information, see https://developers.home-assistant.io/docs/asyncio_thread_safety/#hassasync_create_task at custom_components/connection_observer/coordinator.py, line 343: lambda _now: self.hass.async_create_task(self._run_watchdog()),. Please create a bug report at https://github.com/OleSint/ha-connection-observer/issues
Logger: py.warnings
Quelle: components/mqtt/client.py:646
Erstmals aufgetreten: 20. Mai 2026 um 19:32:49 (8 Vorkommnisse)
Zuletzt protokolliert: 17:33:51
/usr/local/lib/python3.14/site-packages/paho/mqtt/properties.py:211: RuntimeWarning: coroutine 'ConnectionObserverCoordinator._run_watchdog' was never awaited 26: (self.types.index("UTF-8 Encoded String"), [PacketTypes.CONNACK]),
/usr/local/lib/python3.14/site-packages/paho/mqtt/properties.py:202: RuntimeWarning: coroutine 'ConnectionObserverCoordinator._run_watchdog' was never awaited 19: (self.types.index("Two Byte Integer"), [PacketTypes.CONNACK]),
/usr/local/lib/python3.14/site-packages/paho/mqtt/properties.py:251: RuntimeWarning: coroutine 'ConnectionObserverCoordinator._run_watchdog' was never awaited def __setattr__(self, name, value):
/usr/local/lib/python3.14/site-packages/paho/mqtt/properties.py:212: RuntimeWarning: coroutine 'ConnectionObserverCoordinator._run_watchdog' was never awaited 28: (self.types.index("UTF-8 Encoded String"),
/usr/local/lib/python3.14/site-packages/paho/mqtt/properties.py:255: RuntimeWarning: coroutine 'ConnectionObserverCoordinator._run_watchdog' was never awaited object.__setattr__(self, name, value)
Logger: py.warnings
Quelle: components/recorder/util.py:173
Erstmals aufgetreten: 07:55:10 (3 Vorkommnisse)
Zuletzt protokolliert: 14:40:10
/usr/local/lib/python3.14/site-packages/sqlalchemy/engine/cursor.py:1197: RuntimeWarning: coroutine 'ConnectionObserverCoordinator._run_watchdog' was never awaited rows = dbapi_cursor.fetchall()
/usr/local/lib/python3.14/site-packages/sqlalchemy/engine/result.py:563: RuntimeWarning: coroutine 'ConnectionObserverCoordinator._run_watchdog' was never awaited made_rows = [make_row(row) for row in rows]
Der erste klingt spontan aus dem Bauch raus nach nem Bug, den die aktuelle Version nicht mehr haben sollte.
Den und die anderen schau ich mir nachher an
Update:
War etwas anderes als ich spontan dachte.
Fix ist raus, mein Log ist sauber. Entweder die Infos manuell in Hacs in der Integration aktualisieren wenn es schnell gehen soll, ansonsten warten. Kann ein paar Stunden dauern, bis HA das Update automatisch hat.
Wen es interessiert:
Der Watchdog-Scheduler verwendete eine nackte lambda ohne @callback-Dekorator. HA rief diese dadurch aus einem Nicht-Event-Loop-Thread auf, was zu 311× async_create_task from a thread other than the event loop und dem daraus folgenden coroutine was never awaited führte — der Watchdog lief also faktisch gar nicht. Fix: lambda durch eine ordentlich dekorierte @callback-Funktion ersetzt, identisch zum bereits korrekten _fire-Callback nebenan.
*by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)
Zur Info:
Bei mir läuft es insgesamt jetzt rund - nur meine ESP32 über ESP-Home zeigen Offline an, obwohl sie es nicht sind. Das ist offenbar ein relativ spezielle Fehler, der nur auftreten sollte wenn die sich gerade updaten und der Observer gleichzeitg was spezielles tut, das ich selbst manuell ausgelöst hatte. Dürfte demnach kaum jemanden betreffen. Das habe ich bisher noch nicht gelöst bekommen.
Habe die Installation und eine erste Konfiguration vorgenommen. Bei den Protokollen ist zigbee2mqtt nicht vorhanden - ich habe nun erst einmal die MQTT Integration genutzt.
Wenn ich mich richtig erinnere, hatte ich Z2M bei der Einrichtung noch mit drin stehen, da es ja aber eh über MQTT läuft, sollte das ja ausreichend sein.
zigbee2mqtt Geräte legen ihre Entitäten in HA über MQTT-Discovery an, sie werden also erfasst wenn MQTT ausgewählt ist.
Nachteil ist natürlich, dass man unter Umständen aber nicht ALLE MQTT-Geräte drin haben will, sondern eben nur die z2mqtt, aber so richtig sauber lässt sich das, bis jetzt, noch nicht lösen aus besagten Gründen - außer man wählt die jeweiligen Geräte einzeln aus. Ich aktualisiere das in der Doku entsprechend.
Auf meiner Roadmap steht ein Feature, dass man die HA eigenen Labels nutzen können wird. So könnte man z.B. allen seinen z2mqtt-Geräten ein Label “z2m” geben und in meiner Integration dann alle entsprechend gelabelten auswählen - das ist noch nicht drin, aber eines der nächsten angedachten Features.
Könnte man auch Labels hinzufügen das er die ignoriert? Problem ist Mein pc kann ich über ZigBee ein und Ausschalten. Wenn er aus ist bekomme ich Nachricht das es offline ist. Mein Pc hat 18 Entitäten .
eine sehr nützliche Integration, die mir viel manuelle Arbeit ersparen könnte, danke dafür! Damit sie für mich perfekt ist, würde ich aktuell noch folgende Wünsche haben.
Es wird Bluetooth und Shelly unterstützt, BTHome (z. Shelly BLE Door/Window) fehlt. Ist das eventuell über eine der beiden anderen abgedeckt?
Dashboard-Karten:
a) Eine Karte die alle aktuell offline-Geräte auflistet
b) Eine Karte die mir den Status je integration zeigt (z.B. Shelly: Alle geräte Online, MQTT: Gerät xy seit 3 Minuten offline
Ein Timeout je Integration. Shelly-WLAN-Geräte sind bei mir kritischer als BTHome-Geräte, die sich nur selten mleden. MQTT (bei mir nur Feuchtesensoren für Pflanzen) können aber auch 15 min offline sein und sind kein Problem.
Vielleicht passt davon ja was in eines der nächsten Releases
A und B sollten machbar sein, auch wenn ich primär erstmal keine Karten anbieten wollte, so könnte ich zumindest die passenden Entitäten bieten. Bisher gibt es eine Entität, die die Gesamtzahl der offline Entitäten zeigt. Ist also zumindest schon mal grob in die Richtung.
zum dritten Punkt muss ich mir Gedanken machen wie konkret ich das umsetze. Es soll ja gleichzeitig nicht überladen werden. Zudem könnte das eventuell Hand in Hand gehen mit der Verwendung der Flags, die ich eh einbauen will. Sodass man zum Beispiel in HA die Geräte „kritisch“ flaggt, die sofort gemeldet werden sollen und - keine Ahnung - „kritisch30“ wenn die erst nach ner halben Stunde gemeldet werden sollen usw. Mit dem System wäre unserer Fantasie dann fast freier Lauf gegeben.
Edit: Das ging fix. Das Update hab ich grad freigegeben, sollte also demnächst bei Euch aufschlagen. BTHome ist drin - neue Domains sind zum Glück nur jeweils eine Zeile Code.
Das Attribut hab ich erweitert.
Original Posting
BTHome ist eine eigene Domain. Kommt in das nächste Update.
das bestehende sensor.connection_observer_offline_devices um ein Attribut by_protocol erweitern, das etwa so aussieht:
Wohnzimmer Steckdose (shelly) hat um 14:32 die Verbindung verloren.
Wohnzimmer · Shelly Plus 1PM
3 Gerät(e) seit der letzten Zusammenfassung betroffen: • Küchen-Sensor [Küche] (zha): offline seit 12.05. 07:15, wieder online um 07:42 • Schlafzimmer Birne [Schlafzimmer] (hue): offline seit 12.05. 09:05
by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)
