Intro

Dans une usine, personne ne surveille cent capteurs en lisant des SMS : on a une salle de contrôle, avec un tableau où chaque alarme apparaît, se fait acquitter par un opérateur, et laisse une trace. Chez moi, jusqu’ici, c’était l’inverse : des notifications éparpillées dans autant d’automatismes et de blueprints. Dans cet article, je détaille comment j’ai mis en place un véritable tableau d’alarmes dans Home Assistant avec l’intégration HACS Industrial Alarm Panel : installation, fonctionnement, règles concrètes, un seul automatisme de notification Telegram, et une annonce vocale réservée aux alarmes critiques.

Le besoin : pourquoi un tableau plutôt que des notifications éparpillées

Une notification « disque presque plein » envoyée dans Telegram a trois défauts bien connus :

• Elle est sans état : impossible de savoir si le problème est toujours là, s’il a été pris en compte, ou s’il est revenu à la normale tout seul.
• Elle n’a pas de mémoire : l’historique se noie dans la conversation, et il faut fouiller pour retrouver « quand est-ce que le congélateur a dérapé ? ».
• Elle se dilue : chaque alerte vit dans son propre automatisme, avec sa propre logique de relance (quand il y en a une), et personne n’a la vue d’ensemble.

Un tableau d’alarmes apporte ce qui manque : un acquittement (« j’ai vu, je m’en occupe »), des rappels tant que personne n’a réagi, un historique horodaté, des priorités pour distinguer « la maison s’arrête » de « une sonde est muette », et surtout une vue d’ensemble : en un coup d’œil, ce qui est actif, ce qui est acquitté, ce qui est revenu à la normale.

Présentation et installation de l’intégration

Industrial Alarm Panel est une intégration HACS personnalisée, développée par une seule personne, qui reprend le principe des annonciateurs d’alarmes industriels (les « DCS »). Elle ajoute un panneau dans la barre latérale de Home Assistant, accessible sur /industrial-alarms. Elle est encore très jeune : lors de mon test, le 4 novembre 2026, elle était en version 1.1.0, avec peu d’étoiles sur GitHub, sous licence Apache-2.0. À réserver donc à ceux qui acceptent de défricher un peu.

Note importante : HACS est en pleine évolution. À partir de Home Assistant 2026.11, il devient le Marketplace intégré à Home Assistant. Les étapes ci-dessous, rédigées début novembre 2026 avec HACS « classique », peuvent donc changer ce mois-ci (noms de menus, ajout d’un dépôt personnalisé…). En cas de doute, le principe reste le même : ajouter le dépôt AlRiachi/industrial-alarm-panel, télécharger l’intégration, redémarrer, puis l’ajouter dans Appareils et services.

Les étapes d’installation :

1. Dans HACS, ajouter un dépôt personnalisé, catégorie Intégration : AlRiachi/industrial-alarm-panel.
2. Télécharger l’intégration, puis redémarrer Home Assistant.
3. Paramètres → Appareils et services → Ajouter une intégration → Industrial Alarm Panel.
4. Si le panneau reste blanc après une mise à jour : Ctrl+Maj+R dans le navigateur pour vider le cache.

Le panneau vient d’être ajouté à la barre latérale ; aucune règle n’est encore définie.

Le fonctionnement

Cycle de vie et priorités

Une alarme passe par plusieurs états : active, acquittée, revenue à la normale, mise en sommeil (shelve, une suspension temporaire) ou désactivée. Chaque règle porte aussi une priorité : critique, haute, moyenne, basse, info ou statut.

Les entités créées

Chaque règle crée 4 entités : un capteur binaire (l’alarme elle-même) et trois boutons (acquitter, désactiver, mettre en sommeil). Avec 90 règles, cela fait environ 360 entités : à garder en tête pour la taille de la base de données et de l’historique.

S’y ajoutent des entités globales : le nombre d’alarmes actives et non acquittées (binary_sensor.industrial_alarm_panel_any_active et binary_sensor.industrial_alarm_panel_any_unacknowledged), la « dernière alarme », le « dernier événement » (type, nom, repère, lieu, priorité) et l’état du klaxon. C’est sur le « dernier événement » que s’appuiera l’automatisme de notification.

La fiche d’une alarme

Chaque alarme dispose d’une fiche avec la courbe de tendance du capteur sur 6 heures, l’historique des événements, les consignes d’intervention et les boutons d’action. C’est ce qui donne vraiment l’impression de « salle de contrôle » : on voit non seulement qu’une alarme est active, mais comment on en est arrivé là.

Le tableau regroupe les alarmes par état et par priorité.

La fiche d’une alarme : tendance du capteur sur 6 heures, historique des événements et consigne d’intervention.

Les champs d’une règle

Une règle se décrit avec : un nom, un repère (tag, l’identifiant court à la mode industrielle), un lieu, un système, l’entité surveillée, une condition, un seuil, un délai à l’activation et au retour, une hystérésis (deadband, pour éviter les va-et-vient autour du seuil) et une consigne d’intervention.

Des exemples de règles concrets

Les règles se créent avec le service industrial_alarm_panel.create_rule, depuis Outils de développement → Actions (ou Services selon votre version). Voici un exemple complet, avec des valeurs génériques :

service: industrial_alarm_panel.create_rule
data:
  rule:
    id: disque_lxc_exemple
    entity_id: sensor.lxc_exemple_disk_free_percentage
    name: "LXC exemple : disque presque plein"
    tag: DISQUE-LXC-EXEMPLE
    area: Proxmox
    system: LXC exemple
    condition: below
    threshold: 20
    deadband: 2
    delay_on_seconds: 300
    priority: medium
    requires_ack: true
    audible: false
    instructions: Libérer de la place ou agrandir le disque du conteneur.

Et quelques idées de règles, avec la condition à utiliser :

Besoin	Capteur surveillé	Condition
Disque presque plein (80 % utilisé)	Espace libre en %	below 20, hystérésis 2, attente 5 min
Congélateur trop chaud	Température	above -10, attente 10 min
Porte ouverte la nuit	Capteur binaire	is_on, attente 5 min
Sonde en panne	La sonde elle-même	unavailable_for 300 s
ESP hors ligne	Capteur de connexion ESPHome	is_off, attente 5 min
Perte du réseau électrique	Tension du réseau	below 20 V, attente 5 s
Onduleur à l’arrêt	État de l’onduleur	is_off, et unavailable_for 5 s
Service surveillé par Uptime Kuma	Temps de réponse	unknown_for 120 s

Une astuce pour Uptime Kuma

Le statut d’un moniteur Uptime Kuma est du texte (up / down), donc inutilisable tel quel (nous y reviendrons dans les pièges). En revanche, son temps de réponse devient « inconnu » quand la cible est réellement en panne, et « indisponible » quand on met le moniteur en pause. D’où la règle unknown_for 120 s. J’ai vérifié en conditions réelles : une coupure de l’alimentation de mon imprimante a bien déclenché l’alarme.

Mon échelle de priorités

• Critique : la maison s’arrête (onduleur, réseau électrique)
• Haute : dégâts immédiats possibles (congélateur, gel)
• Moyenne : à traiter dans la journée (disques, sondes, ESP)
• Basse : confort

Côté organisation, mes anciens automatismes (un blueprint de relance par alarme) ont été désactivés, jamais supprimés, et toutes les nouvelles entités portent une même étiquette Home Assistant : on peut ainsi tout retrouver, ou tout supprimer, d’un coup.

Création ou édition d’une règle par le service industrial_alarm_panel.create_rule.

Un seul automatisme de notification Telegram

Plutôt qu’un automatisme par alarme, un seul gère tout, en surveillant l’entité « dernier événement » du panneau :

• Alarme qui apparaît : message avec le nom, le lieu, le repère, la priorité et l’état du capteur (valeur arrondie, unité ajoutée seulement si c’est un nombre).
• Rappels : toutes les 10 minutes, 5 fois au maximum, tant que l’alarme est active et non acquittée. L’acquittement ou le retour à la normale les arrête.
• Acquittement d’une alarme encore active : message « toujours active et acquittée ».
• Retour à la normale : message avec le nom de l’alarme.

Les créations ou modifications de règles sont ignorées par une condition native, sans modèle Jinja. Le mode restart est important : une nouvelle alarme n’attend pas la fin des rappels de la précédente.

alias: Alarmes - Notification Telegram
mode: restart   # une nouvelle alarme n'attend pas la fin des rappels
triggers:
  - trigger: state
    entity_id: sensor.industrial_alarm_panel_last_event
conditions:
  - condition: or
    conditions:
      - condition: state
        entity_id: sensor.industrial_alarm_panel_last_event
        attribute: event_type
        state: [activated, cleared]
      - condition: and        # acquittement d'une alarme encore active
        conditions:
          - condition: state
            entity_id: sensor.industrial_alarm_panel_last_event
            attribute: event_type
            state: acknowledged
          - condition: state
            entity_id: sensor.industrial_alarm_panel_last_event
            attribute: new_state
            state: ACTIVE_ACK
actions:
  - variables:
      nom: "{{ trigger.to_state.attributes.name }}"
      eid: "{{ trigger.to_state.attributes.entity_id }}"
  - choose:
      # 1) Apparition d'une alarme
      - conditions:
          - condition: state
            entity_id: sensor.industrial_alarm_panel_last_event
            attribute: event_type
            state: activated
        sequence:
          # (le bloc vocal de la section suivante se place ici, AVANT Telegram)
          - action: telegram_bot.send_message
            data:
              config_entry_id: "<ID_TELEGRAM>"
              title: "🚨 Alarme"
              message: >-
                {{ nom }}
                Entité : {{ state_attr(eid, 'friendly_name') }} =
                {{ states(eid) | round(2, default=states(eid)) }}
          - repeat:           # rappels : 5 fois, toutes les 10 minutes
              count: 5
              sequence:
                - wait_for_trigger:
                    - trigger: state
                      entity_id: binary_sensor.industrial_alarm_panel_any_active
                      to: "off"
                    - trigger: state
                      entity_id: binary_sensor.industrial_alarm_panel_any_unacknowledged
                      to: "off"
                  timeout: { minutes: 10 }
                - if:
                    - condition: state
                      entity_id: binary_sensor.industrial_alarm_panel_any_active
                      state: "on"
                    - condition: state
                      entity_id: binary_sensor.industrial_alarm_panel_any_unacknowledged
                      state: "on"
                  then:
                    - action: telegram_bot.send_message
                      data:
                        config_entry_id: "<ID_TELEGRAM>"
                        title: "⏰ Rappel alarme"
                        message: "{{ nom }} : toujours active et non acquittée"
                  else:
                    - stop: "Alarme revenue à la normale ou acquittée"
      # 2) Retour à la normale
      - conditions:
          - condition: state
            entity_id: sensor.industrial_alarm_panel_last_event
            attribute: event_type
            state: cleared
        sequence:
          - action: telegram_bot.send_message
            data:
              config_entry_id: "<ID_TELEGRAM>"
              title: "✅ Retour à la normale"
              message: "{{ nom }} : revenue à la normale"
      # 3) Acquittement d'une alarme encore active
      - conditions:
          - condition: state
            entity_id: sensor.industrial_alarm_panel_last_event
            attribute: event_type
            state: acknowledged
        sequence:
          - action: telegram_bot.send_message
            data:
              config_entry_id: "<ID_TELEGRAM>"
              title: "👍 Alarme acquittée"
              message: "{{ nom }} : toujours active et acquittée"

Un point à retenir : le réglage « relance de l’alarme » que l’on trouve dans chaque règle du panneau ne relance pas les automatismes de Home Assistant. Les rappels doivent donc être gérés dans l’automatisme de notification, comme ci-dessus. Remplacez <ID_TELEGRAM> par l’identifiant de votre entrée de configuration Telegram.

Le cycle complet vu dans Telegram, de l’alarme au retour à la normale.

L’annonce vocale des alarmes critiques via Music Assistant

Seules les alarmes critiques (chez moi : onduleur à l’arrêt ou indisponible, perte du réseau) parlent, sur une enceinte Bose de la cuisine, via l’add-on Music Assistant. Il met la musique en pause, joue l’annonce au volume voulu, puis remet le volume d’avant et reprend la musique tout seul.

- if:
    - condition: state
      entity_id: sensor.industrial_alarm_panel_last_event
      attribute: tag
      state: [MP2-OFF, MP2-INDISPO, RESEAU-TENSION-BASSE]
  then:
    - action: music_assistant.play_announcement
      target:
        entity_id: media_player.cuisine_mass     # l'enceinte vue par Music Assistant
      data:
        tts_entity_id: tts.google_ai_tts
        use_pre_announce: false
        announce_volume: 50
        message: >-
          Lis clairement, à un rythme normal et sur un ton d'alerte :
          Alarme {{ nom | replace(' : ', ' ') | regex_replace(' [(][^)]*[)]', '') }}.

Ce bloc est arrivé après plusieurs essais. Voici le chemin parcouru, dans l’ordre où je me suis fait piéger.

Une voix saccadée

Lire le nom de l’alarme tel quel sonne haché : « Onduleur : à l’arrêt (off) » est dit avec des pauses, et « (off) » à l’anglaise. Les « : », les parenthèses et les virgules font chacun un blanc d’environ une seconde. D’où le nettoyage dans le modèle : on retire les deux-points et les parenthèses avant d’envoyer le texte.

Des mots anglais mal articulés

La voix articulait mal « test » ; « essai » passe très bien. Pour les alarmes parlées, mieux vaut donc des noms de règles en français courant, sans anglicismes. Côté moteur de synthèse, la voix Google AI TTS est nettement plus fluide que celle de Home Assistant Cloud, qui reste saccadée. Une consigne de lecture placée devant le texte règle le rythme (« lentement » était trop lent, « à un rythme normal » convient).

Des micro-coupures et un volume bloqué

Envoyer directement l’annonce à l’enceinte par Cast donnait des micro-coupures (mise en mémoire tampon) et laissait le volume bloqué à 50 % si l’automatisme était interrompu en cours de route. Passer par Music Assistant a réglé les deux problèmes d’un coup : c’est lui qui gère la pause, le volume de l’annonce, puis la restauration.

L’ordre des actions

La voix doit partir avant Telegram. Lors d’un test, l’envoi Telegram a pris 40 secondes, et la voix, placée après, n’est jamais partie (le mode restart avait relancé l’automatisme entre-temps). Pour une alarme critique, c’est le canal le plus urgent qui passe en premier.

Tester sans toucher aux vraies alarmes

Pour régler tout cela, j’ai créé une règle dédiée aux essais, branchée sur un simple interrupteur (input_boolean) : on l’allume, l’alarme se déclenche, on teste la voix et les messages, sans jamais couper l’onduleur.

Les pièges et conseils

Les limites à connaître

• Les seuils ne sont que numériques. Le panneau ne compare pas un texte (par exemple un état down). Il sait seulement tester « allumé », « éteint », « indisponible depuis X secondes » et « inconnu depuis X secondes » : d’où l’astuce du temps de réponse pour Uptime Kuma.
• La « relance de l’alarme » d’une règle ne relance pas les automatismes : les rappels se gèrent dans l’automatisme de notification.
• Éviter le bouton « Create All » des règles suggérées : il créerait des centaines d’entités d’un coup.

Mes conseils

1. Commencer petit : 3 ou 4 règles, pas les règles suggérées.
2. Tester la détection sur une vraie panne (couper l’alimentation d’un équipement) avant de désactiver les anciennes alertes. Chez moi, un ancien blueprint surveillait un état « off » qui n’existait jamais : il n’avait donc jamais fonctionné, et je ne l’avais pas su.
3. Garder les alertes à la source pour ce qui surveille Home Assistant lui-même : si HA tombe, le tableau tombe avec lui.
4. Garder les détecteurs de fumée et de CO indépendants, sur leur propre circuit : le tableau ne les remplace pas.

En résumé

• Un tableau d’alarmes apporte ce que les notifications seules n’ont pas : acquittement, rappels, historique, priorités et vue d’ensemble.
• Industrial Alarm Panel s’installe via HACS (démarche à revérifier avec le Marketplace intégré de Home Assistant 2026.11) et crée 4 entités par règle.
• Un seul automatisme Telegram, basé sur l’entité « dernier événement », gère alarme, rappels, acquittement et retour à la normale.
• Seules les alarmes critiques parlent, via Music Assistant, avec la voix avant Telegram et un texte nettoyé de sa ponctuation.
• Testez sur une vraie panne, et gardez les alertes à la source pour Home Assistant lui-même ainsi que les détecteurs de fumée et de CO indépendants.

---

Article rédigé avec l’assistance de Claude AI (Anthropic) à partir de mes données et retours d’expérience.