Détecter une coupure de courant avec Home Assistant et des prises Zigbee

par Anne-Laure DELPECH | 16 Juil 2026 | Domotique & Maison connectée

Tu veux savoir si une coupure de courant a eu lieu chez toi pendant ton absence, sans investir dans du matériel dédié ? Voici comment détecter une panne secteur avec des prises connectées Zigbee et Home Assistant, et recevoir une alerte par e-mail à chaque coupure et à chaque retour du courant.

Cet article s’inscrit dans la série Domotique avec Home Assistant et réutilise l’infrastructure mise en place dans la série Projets Ubuntu (Docker, Portainer, Zigbee2MQTT).

Le matériel utilisé

• Un mini PC Ubuntu, protégé par un onduleur, faisant tourner Home Assistant, Mosquitto et Zigbee2MQTT en containers Docker
• Un dongle Zigbee (Sonoff MG21)
• Cinq prises connectées Zigbee Nous A7Z, chacune alimentant un appareil différent de la maison (dont le réfrigérateur et le congélateur, dont la charge constante en fait de bons indicateurs)
• Un Chromecast Audio, connecté en Wi-Fi

L’idée : si tous ces appareils disparaissent du réseau en même temps, c’est qu’il n’y a plus de courant dans la maison. Le mini PC et sa box internet, eux, restent en ligne grâce à l’onduleur.

Demander à Zigbee2MQTT de vérifier activement le réseau

Sans réglage supplémentaire, une prise Zigbee débranchée, ou sans courant, ne passe jamais à indisponible : Zigbee2MQTT ne vérifie pas activement, par défaut, si un appareil alimenté sur secteur répond encore. Il se contente d’afficher la dernière valeur reçue, indéfiniment, tant qu’aucun nouveau message n’arrive. Pour une prise débranchée, ça veut dire un blocage permanent sur son dernier état connu.

Il faut donc activer la fonctionnalité de vérification de disponibilité de Zigbee2MQTT, qui va interroger (ping) les prises à intervalles réguliers pour confirmer qu’elles répondent encore.

Piège à éviter : ce réglage ne doit jamais être fait en éditant directement le fichier configuration.yaml de Zigbee2MQTT à la main. Zigbee2MQTT garde sa configuration active en mémoire et la réécrit sur le fichier physique à chaque redémarrage du container, ce qui efface silencieusement toute modification manuelle qui n’a pas été prise en compte par le service lui-même.

Le bon réglage passe par l’interface Web de Zigbee2MQTT :

1. Va dans Paramètres > Disponibilité
2. Active la case « Activer les vérifications de disponibilité »
3. Dans la section Active, renseigne un timeout (en minutes). Trois minutes est un bon compromis entre rapidité de détection et charge sur le dongle Zigbee
4. Enregistre

Ce réglage global s’applique à tous les appareils Zigbee alimentés sur secteur (comme les prises), sans qu’il soit nécessaire d’activer quoi que ce soit individuellement pour chacune.

Une fois activé, débranche une prise et observe sa fiche dans le frontend de Zigbee2MQTT : après le délai configuré, elle passe à « Disponibilité : Désactivé ». Côté Home Assistant, l’entité switch correspondante passe à indisponible au même moment, ce qui fait automatiquement basculer le capteur de groupe.

Sécuriser l’envoi d’e-mail

Avant de configurer l’envoi d’alertes, un point de sécurité important : n’utilise jamais un compte e-mail personnel ou professionnel pour ce genre d’automatisation. Si ce compte est compromis un jour, l’impact reste limité à cette seule automatisation.

La bonne pratique consiste à créer un compte Gmail secondaire, dédié uniquement à l’envoi de ces alertes, avec un mot de passe d’application (pas le mot de passe du compte lui-même). Tout le détail de cette mise en place, avec l’activation de la double authentification (mais pas la création du mot de passe d’application), fait l’objet d’un article séparé : Sécuriser son compte Gmail avec la double authentification et Aegis Authenticator.

Une fois le mot de passe d’application créé, tous les identifiants (mot de passe, adresse expéditrice, adresse destinataire) sont stockés dans secrets.yaml, jamais directement dans configuration.yaml, pour ne jamais les exposer si tu partages ta configuration.

Dans /home/USER/docker/home-assistant/config/secrets.yaml :

notify_email_password: "le_mot_de_passe_application_16_caracteres"
notify_email_recipient: "adresse_destinataire@exemple.com"
notify_email_sender: "adresse_gmail_secondaire@exemple.com"

Dans /home/USER/docker/home-assistant/config/configuration.yaml, à la suite du contenu existant :

notify:
  - name: email_alertes
    platform: smtp
    server: smtp.gmail.com
    port: 587
    timeout: 15
    sender: !secret notify_email_sender
    encryption: starttls
    username: !secret notify_email_sender
    password: !secret notify_email_password
    recipient:
      - !secret notify_email_recipient

Après modification, redémarre complètement le container Home Assistant : ce type de service (notify) n’est pas pris en compte par un simple rechargement de configuration.

Pour tester, va dans Outils de développement > Actions, cherche notify.email_alertes, renseigne un message, et lance l’action. Vérifie ta boîte de réception, y compris le dossier spam : un premier envoi automatisé depuis une adresse encore peu utilisée y atterrit parfois. Marquer le message comme « non spam » et ajouter l’adresse aux contacts résout le problème pour la suite.

Créer les capteurs template et le groupe

Le Chromecast Audio se comporte différemment des prises Zigbee : c’est un appareil Wi-Fi, dont Home Assistant détecte lui-même la perte de connexion en quelques secondes, sans configuration particulière à ajouter côté réseau. Son entité media_player passe directement à indisponible en cas de coupure.

Les prises Zigbee, elles, ont besoin d’un réglage supplémentaire détaillé dans la section suivante avant de se comporter de la même façon. On va surveiller la présence de chaque appareil sur le réseau Zigbee, pas sa consommation. Home Assistant expose pour chaque prise Zigbee une entité switch, qui représente son état de connexion. Tant que la prise répond, cette entité a une valeur (on ou off, selon que la prise est allumée ou éteinte manuellement). Si la prise ne répond plus, l’entité passe à indisponible.

On crée d’abord un capteur « template » par appareil : des capteurs virtuels qui traduisent l’état de chaque appareil en on ou off, selon qu’il est présent ou non sur le réseau. Puis on les regroupe en un seul capteur, qui résume l’état du secteur pour toute la maison.

À ajouter dans configuration.yaml :

template:
  - binary_sensor:
      - name: "Courant Prise A Bureau"
        unique_id: courant_prise_a_bureau
        device_class: power
        state: >
          {{ states('switch.prise_a_bureau_entree') != 'unavailable' }}

      - name: "Courant Prise B Salon"
        unique_id: courant_prise_b_salon
        device_class: power
        state: >
          {{ states('switch.prise_b_salon_tel') != 'unavailable' }}

      - name: "Courant Prise C Garage"
        unique_id: courant_prise_c_garage
        device_class: power
        state: >
          {{ states('switch.prise_c_garage_machine_a_laver') != 'unavailable' }}

      - name: "Courant Chromecast Salon"
        unique_id: courant_chromecast_salon
        device_class: power
        state: >
          {{ states('media_player.salon') != 'unavailable' }}

      - name: "Courant Prise D Frigo"
        unique_id: courant_prise_d_frigo
        device_class: power
        state: >
          {{ states('switch.prise_d_frigo') != 'unavailable' }}

      - name: "Courant Prise E Congélateur"
        unique_id: courant_prise_e_congelateur
        device_class: power
        state: >
          {{ states('switch.prise_e_congelateur') != 'unavailable' }}

binary_sensor:
  - platform: group
    name: "Courant Secteur Maison"
    unique_id: courant_secteur_maison
    entities:
      - binary_sensor.courant_prise_a_bureau
      - binary_sensor.courant_prise_b_salon
      - binary_sensor.courant_prise_c_garage
      - binary_sensor.courant_chromecast_salon
      - binary_sensor.courant_prise_d_frigo
      - binary_sensor.courant_prise_e_congelateur

Remplace switch.prise_a_bureau_entree et les autres par les identifiants exacts de tes propres prises. Tu les trouves dans Outils de développement > États, en filtrant sur switch..

Le groupe fonctionne en logique « au moins un » : il reste à on tant qu’un seul des appareils listés est présent sur le réseau, et ne passe à off que si tous sont indisponible en même temps. C’est ce qui permet de distinguer une vraie coupure générale d’un simple appareil débranché ou en panne.

Pour ajouter une prise supplémentaire plus tard, il suffit de dupliquer un bloc de capteur template avec le bon identifiant, et d’ajouter la ligne correspondante dans entities: du groupe. Rien d’autre à modifier : ni le service notify, ni les automatisations, qui s’appuient uniquement sur le capteur de groupe.

Activer le ping de disponibilité sur Zigbee2MQTT

Sans réglage supplémentaire, une prise Zigbee débranchée ne passe jamais à indisponible : Zigbee2MQTT ne vérifie pas activement, par défaut, si un appareil alimenté sur secteur répond encore. Il se contente d’afficher la dernière valeur reçue, indéfiniment, tant qu’aucun nouveau message n’arrive. Pour une prise débranchée, ça veut dire un blocage permanent sur son dernier état connu.

Il faut donc activer la fonctionnalité de vérification de disponibilité de Zigbee2MQTT, qui va interroger (ping) les prises à intervalles réguliers pour confirmer qu’elles répondent encore.

Piège à éviter : ce réglage ne doit jamais être fait en éditant directement le fichier configuration.yaml de Zigbee2MQTT à la main. Zigbee2MQTT garde sa configuration active en mémoire et la réécrit sur le fichier physique à chaque redémarrage du container, ce qui efface silencieusement toute modification manuelle qui n’a pas été prise en compte par le service lui-même.

Le bon réglage passe par l’interface Web de Zigbee2MQTT :

1. Va dans Paramètres > Disponibilité
2. Active la case « Activer les vérifications de disponibilité »
3. Dans la section Active, renseigne un timeout (en minutes). Trois minutes est un bon compromis entre rapidité de détection et charge sur le dongle Zigbee
4. Enregistre

Ce réglage global s’applique à tous les appareils Zigbee alimentés sur secteur (comme les prises), sans qu’il soit nécessaire d’activer quoi que ce soit individuellement pour chacune.

Une fois activé, débranche une prise et observe sa fiche dans le frontend de Zigbee2MQTT : après le délai configuré, elle passe à « Disponibilité : Désactivé ». Côté Home Assistant, l’entité switch correspondante passe à indisponible au même moment, ce qui fait automatiquement basculer le capteur de groupe.

Les automatisations

Deux automatisations : une pour signaler le début d’une coupure, une pour signaler le retour du courant. Toutes deux intègrent un délai de 30 secondes avant de se déclencher, pour éviter une alerte sur une micro-coupure sans conséquence.

À ajouter dans /home/USER/docker/home-assistant/config/automations.yaml :

- id: alerte_debut_panne_courant
  alias: "Alerte début de panne de courant"
  trigger:
    - platform: state
      entity_id: binary_sensor.courant_secteur_maison
      to: "off"
      for:
        seconds: 30
  action:
    - service: notify.email_alertes
      data:
        title: "[home ALD] Coupure de courant détectée"
        message: >
          Une coupure de courant a été détectée à {{ now().strftime('%H:%M:%S') }}.

          Ce mail a été généré automatiquement par Home Assistant d'Anne-Laure, suite à l'automatisation id: alerte_debut_panne_courant.

- id: alerte_fin_panne_courant
  alias: "Alerte fin de panne de courant"
  trigger:
    - platform: state
      entity_id: binary_sensor.courant_secteur_maison
      to: "on"
      for:
        seconds: 30
  action:
    - service: notify.email_alertes
      data:
        title: "[home ALD] Retour du courant"
        message: >
          Le courant est revenu à {{ now().strftime('%H:%M:%S') }}.

          Ce mail a été généré automatiquement par Home Assistant d'Anne-Laure, suite à l'automatisation id: alerte_fin_panne_courant.

Deux détails utiles à reproduire, indépendamment du sujet de l’automatisation :

• Un préfixe cohérent dans le titre (ici [home ALD]) permet de créer facilement un filtre ou une étiquette dans ta messagerie pour regrouper toutes les alertes de ta maison connectée
• Une ligne de traçabilité dans le corps du message, citant l’identifiant de l’automatisation à l’origine de l’envoi, facilite le diagnostic si tu dois un jour retrouver quelle automatisation a déclenché quel e-mail

Après modification, recharge les automatisations (Outils de développement > YAML > Recharger les automatisations), ou redémarre complètement Home Assistant si tu préfères.

Bilan des tests réels

Le test décisif consiste à débrancher réellement les appareils concernés, plutôt que de forcer un état depuis l’interface, pour valider le comportement de bout en bout.

En débranchant une seule prise, rien ne se passe : le groupe reste alimenté grâce aux autres appareils encore présents sur le réseau, exactement le comportement attendu. En débranchant tous les appareils, le capteur de groupe passe à indisponible, et l’e-mail de coupure arrive environ 30 secondes après la détection effective par Zigbee2MQTT, conformément au délai configuré dans l’automatisation.

Au rebranchement, le Chromecast est détecté quasiment tout de suite (c’est un appareil Wi-Fi). Les prises Zigbee, elles, réapparaissent en quelques minutes au maximum, le temps que Zigbee2MQTT confirme leur présence lors de son prochain cycle de vérification.

Pour aller plus loin

Retrouve tous les articles de la série Domotique avec Home Assistant et de la série Projets Ubuntu.