Annuaire indépendant, créé par le développeur de Vulpo. Non affilié à Home Assistant ni à l’Open Home Foundation.

À propos

Connection Observer surveille les connexions des appareils de la maison connectée par protocole et envoie des notifications quand des appareils passent hors ligne. Des familles entières d’intégrations comme Zigbee, Z-Wave, Bluetooth, ESPHome et Shelly sont sélectionnées pour la surveillance à la place d’entités individuelles, et des étiquettes peuvent marquer des entités précises à surveiller ou à ignorer. Les alertes peuvent être envoyées immédiatement, sous forme de résumé planifié à des jours et des heures choisis, ou les deux, avec un avis facultatif quand un appareil se reconnecte. Les délais d’alerte peuvent être réglés globalement ou par protocole, avec des valeurs recommandées disponibles, et un délai de repos, une durée minimale hors ligne et des exclusions d’appareils ou de domaines réduisent le bruit. Un capteur conserve les événements de déconnexion récents, le texte des notifications peut être personnalisé avec des modèles, et un problème peut apparaître dans le panneau Corrections après un nombre d’heures défini hors ligne. Il fonctionne en local, se configure dans l’interface et fournit des capteurs binaires et des capteurs.

Résumé automatique du README et du code de OleSint/ha-connection-observer, traduit automatiquement. Une erreur, ou tu maintiens ce projet et tu veux ton propre texte ici ? Prendre contact

Prise en charge

  • Fonctionne en local Communique avec tes appareils sur ton propre réseau. Aucun cloud de fournisseur entre les deux.

  • Depuis la Marketplace S’installe depuis la Marketplace, anciennement HACS.

  • Maintenance active Son auteur a publié une version ou poussé une modification au cours des six derniers mois.

Fournit

  • Capteurs

Mise en place

Installe-la depuis la Marketplace et redémarre Home Assistant, puis ajoute-la dans Paramètres > Appareils et services.

Connection Observer – Protocoles

  • Protocoles à surveiller
  • Langue des notifications

Connection Observer : Notifications

  • Service(s) de notification
  • Cible de notification (facultatif)Utile uniquement si votre service de notification envoie à plusieurs destinataires à la fois et que vous voulez n'en atteindre qu'un seul. Avec notify.send_message, indiquez ici l'entity_id du destinataire visé (ex. notify.smtp_jane_doe). Avec d'autres services (ex. telegram_bot.send_message), indiquez plutôt la valeur brute attendue par ce service (ex. un identifiant de chat).
  • Notification immédiate lors d'une déconnexion
  • Résumé planifié
  • Heure du résumé
  • Jours du résumé
  • Notifier lors de la reconnexion (opt-in)

Connection Observer : Test

  • Envoyer une notification de test maintenant

Connection Observer – Avancé

  • Délai global (minutes hors ligne avant la création d'un événement)0 = immédiat. Valeur par défaut pour tous les protocoles, sauf si remplacée à l'étape suivante.
  • Délai minimal entre les notifications immédiates par appareil (0 = pas de limite)
  • Durée minimale hors ligne pour apparaître dans le résumé (0 = tous les événements)
  • Délai de re-vérification au démarrage (minutes) avant de signaler un appareil déjà hors ligneAprès un redémarrage, un appareil toujours indisponible est revérifié après ce délai (en minutes) avant d'être signalé hors ligne. Augmentez cette valeur si plusieurs appareils se reconnectent simultanément (ex. de nombreux appareils WiFi sur un même routeur).
  • Inclure la pièce / zone dans les notifications
  • Inclure le fabricant et le modèle dans les notifications
  • Domaines d'entités exclus (ex. sensor, button)
  • Appareils exclus (facultatif)

Connection Observer : Expert

  • Appliquer les délais recommandés pour tous les protocolesCochez et cliquez sur Soumettre pour préremplir tous les champs avec les valeurs recommandées. Vous pouvez les ajuster ensuite.
  • Zigbee (ZHA) – délai d'alerteRecommandé : 5 min | Routage maillé Zigbee prend un moment
  • Zigbee (deCONZ) – délai d'alerteRecommandé : 5 min | Routage maillé Zigbee prend un moment
  • Z-Wave (Z-Wave JS) – délai d'alerteRecommandé : 5 min | Routage maillé Z-Wave prend un moment
  • Matter – délai d'alerteRecommandé : 5 min | Comportement de type maillé
  • Thread (OTBR) – délai d'alerteRecommandé : 5 min | Maillage Thread
  • Bluetooth – délai d'alerteRecommandé : 10 min | Connexion BLE plus lente
  • BTHome – délai d'alerteRecommandé : 20 min | BLE passif – rares advertisements
  • RFXtrx (433 MHz) – délai d'alerteRecommandé : 10 min | RF 433 MHz unidirectionnel, pas d'ACK
  • MySensors – délai d'alerteRecommandé : 10 min | Polling lent
  • Insteon – délai d'alerteRecommandé : 5 min | Bus propriétaire, basé sur polling
  • KNX – délai d'alerteRecommandé : 5 min | Bus filaire, fiable mais polling
  • Velbus – délai d'alerteRecommandé : 5 min | Bus filaire
  • ESPHome – délai d'alerteRecommandé : 2 min | TCP persistant, détection très rapide
  • Shelly – délai d'alerteRecommandé : 2 min | TCP persistant, détection très rapide

Après la mise en place

  • Protocoles à surveiller
  • Langue des notifications
  • Service(s) de notification
  • Cible de notification (facultatif)Utile uniquement si votre service de notification envoie à plusieurs destinataires à la fois et que vous voulez n'en atteindre qu'un seul. Avec notify.send_message, indiquez ici l'entity_id du destinataire visé (ex. notify.smtp_jane_doe). Avec d'autres services (ex. telegram_bot.send_message), indiquez plutôt la valeur brute attendue par ce service (ex. un identifiant de chat).
  • Notification immédiate lors d'une déconnexion
  • Résumé planifié
  • Heure du résumé
  • Jours du résumé
  • Notifier lors de la reconnexion
  • Délai global (minutes hors ligne avant la création d'un événement)0 = immédiat. Valeur par défaut pour tous les protocoles, sauf si remplacée à l'étape Expert.
  • Délai minimal entre les notifications par appareil (minutes, 0 = pas de limite)
  • Durée minimale hors ligne pour le résumé (minutes, 0 = tous les événements)
  • Délai de re-vérification au démarrage (minutes) avant de signaler un appareil déjà hors ligneAprès un redémarrage, un appareil toujours indisponible est revérifié après ce délai (en minutes) avant d'être signalé hors ligne. Augmentez cette valeur si plusieurs appareils se reconnectent simultanément (ex. de nombreux appareils WiFi sur un même routeur).
  • Inclure la pièce / zone dans les notifications
  • Inclure le fabricant et le modèle dans les notifications
  • Domaines d'entités exclus (ex. sensor, button)
  • Appareils exclus
  • Signalement HA Repairs après N heures hors ligne (0 = désactivé)
  • Appliquer les délais recommandés pour tous les protocolesCochez et cliquez sur Soumettre pour préremplir tous les champs avec les valeurs recommandées. Vous pouvez les ajuster ensuite.
  • Zigbee (ZHA) – délai d'alerteRecommandé : 5 min | Routage maillé Zigbee prend un moment
  • Zigbee (deCONZ) – délai d'alerteRecommandé : 5 min | Routage maillé Zigbee prend un moment
  • Z-Wave (Z-Wave JS) – délai d'alerteRecommandé : 5 min | Routage maillé Z-Wave prend un moment
  • Matter – délai d'alerteRecommandé : 5 min | Comportement de type maillé
  • Thread (OTBR) – délai d'alerteRecommandé : 5 min | Maillage Thread
  • Bluetooth – délai d'alerteRecommandé : 10 min | Connexion BLE plus lente
  • BTHome – délai d'alerteRecommandé : 20 min | BLE passif – rares advertisements
  • RFXtrx (433 MHz) – délai d'alerteRecommandé : 10 min | RF 433 MHz unidirectionnel, pas d'ACK
  • MySensors – délai d'alerteRecommandé : 10 min | Polling lent
  • Insteon – délai d'alerteRecommandé : 5 min | Bus propriétaire, basé sur polling
  • KNX – délai d'alerteRecommandé : 5 min | Bus filaire, fiable mais polling
  • Velbus – délai d'alerteRecommandé : 5 min | Bus filaire
  • ESPHome – délai d'alerteRecommandé : 2 min | TCP persistant, détection très rapide
  • Shelly – délai d'alerteRecommandé : 2 min | TCP persistant, détection très rapide
  • Notification immédiate – titre (vide = par défaut)Variables : device_name, protocol, time, area, model
  • Notification immédiate – message (vide = par défaut)Variables : device_name, protocol, time, area, model
  • Notification de reconnexion – titre (vide = par défaut)Variables : device_name
  • Notification de reconnexion – message (vide = par défaut)Variables : device_name
  • Résumé – titre (vide = par défaut)Variables : count
  • Résumé – ligne événement résolu (vide = par défaut)Variables : device_name, area, protocol, time_offline, time_online
  • Résumé – ligne toujours hors ligne (vide = par défaut)Variables : device_name, area, protocol, time_offline
  • Envoyer une notification de test maintenant

Textes issus du code de OleSint/ha-connection-observer. Les textes que le dépôt ne fournit pas en français ont été traduits automatiquement.

Extrait du README

  • Protocol-based monitoring – select entire integration families (Zigbee, Z-Wave, Hue, ESPHome, Shelly, Sonos, …) instead of configuring individual entities. 100+ integrations supported out of the box.
  • Immediate notifications – get alerted the moment a device goes offline
  • Scheduled summaries – receive a digest on configurable days and times listing everything that disconnected since the last summary, including whether the device came back online and when
  • Both modes simultaneously – immediate + summary can both be active at once; summary is pre-selected by default
  • Reconnect notifications – opt-in alert when a device comes back online
  • Alert delay – opt-in: only create an event after a device has been offline for N minutes, filtering out brief dropouts entirely
  • Cooldown – opt-in: limit immediate notifications per device to once every N minutes
  • Minimum offline duration – opt-in: suppress short blips from the summary without losing them
  • Room / area – opt-in: include the HA area name in notifications
  • Manufacturer & model – opt-in: include device info in immediate notifications
  • Event history sensor (v1.3.0) – sensor.event_history exposes the last 100 disconnect events as a structured events attribute with timestamps, area, protocol, and reconnect info — ready for…
  • Label-based monitoring (v1.2.0) – assign observer_critical, observer_watch, or observer_ignore labels to any HA entity; works independently of protocols, no config-flow changes needed after setup
Extrait du README de OleSint/ha-connection-observer, MIT License. Abrégé.

S’affiche dans Vulpo :

carte Graphique, Apple Watch.

Informations

Installations
96 partagent leurs statistiques
Étoiles GitHub
15
Connexion
Fonctionne en local
Maintenance
Mise à jour au cours des 6 derniers mois
Version
v1.3.13.1,
Catégorie
Messagerie et notifications, Notifications push
Type
Intégration de la Marketplace
Prérequis
Nécessite la Marketplace (HACS sur Home Assistant 2026.10 et les versions antérieures)
Domaine
connection_observer

À découvrir aussi

Annuaire indépendant, créé par le développeur de Vulpo. Non affilié à Home Assistant ni à l’Open Home Foundation. À propos de ces chiffres