Ajax et Home Assistant, l'intégration utile sans fragiliser l'alarme

Si Home Assistant disparaît pendant cinq minutes, l’alarme doit continuer à armer, détecter, siréner et notifier selon sa propre logique. Cette phrase suffit à trier les bonnes et les mauvaises idées.

Dans une intégration propre, Ajax reste le système maître. Le hub Ajax, ses détecteurs, ses sirènes, ses notifications et ses éventuels réglages de télésurveillance ne dépendent pas d’une automatisation HA. Home Assistant reçoit seulement des informations exploitables : état armé, alarme déclenchée, événement de contact, défaut ou signal secondaire selon la méthode choisie.

Cette séparation est moins spectaculaire qu’un dashboard unique, mais elle évite le scénario absurde : une mise à jour Home Assistant casse une intégration, puis l’utilisateur découvre que plusieurs routines de sécurité dépendaient d’un composant non garanti. Pour une alarme, la robustesse passe avant le confort.

Home Assistant documente une intégration SIA pour les systèmes d’alarme compatibles, dont Ajax. Le point important est explicite : le protocole est listen-only. Il permet de refléter des états et de réagir à ces états, pas de prendre le contrôle complet du système. Cette contrainte évite beaucoup de mauvaises architectures, parce qu’elle force à séparer le signal reçu de la décision de sécurité, au lieu de maquiller une alarme en simple périphérique domotique.

C’est précisément pour cela que l’approche est intéressante. Vous pouvez recevoir un événement d’alarme et allumer toutes les lumières, ouvrir les volets, envoyer une notification locale ou écrire dans un journal. Mais l’armement, la détection et la logique d’alerte principale restent du côté Ajax.

Le protocole SIA DC-09 est plutôt pensé pour transmettre des événements d’alarme à une station ou un logiciel de réception. Dans un contexte Home Assistant, il faut donc raisonner en réception d’événements, pas en intégration domotique universelle. La nuance change tout : on construit une passerelle d’information, pas une télécommande d’alarme.

Concrètement, vous cherchez d’abord à savoir si l’événement arrive, s’il est horodaté correctement, s’il correspond au bon équipement et s’il peut être transformé en automatisation sans ambiguïté. Ce n’est pas le même travail qu’un appairage Zigbee. Ici, la qualité du signal événementiel compte plus que le nombre d’entités visibles dans un dashboard.

Un bon pont d’alarme ne reconstruit pas une vérité approximative. Il reçoit un événement, le traduit proprement et le laisse disponible pour des scénarios limités. Si vous commencez à déduire l’état de sécurité depuis trois capteurs, une présence Wi-Fi et un booléen HA, vous fabriquez une alarme parallèle moins fiable que le système Ajax.

Le minimum utile tient en peu d’informations : état global, alarme active, défaut de communication, batterie faible ou événement de zone quand il est exposé. Avec ça, vous pouvez déjà faire 90 % des scénarios raisonnables. Le reste devient vite une maintenance cachée, surtout si chaque automatisation suppose une interprétation différente du même événement.

Gardez le modèle mental simple : Ajax constate, Home Assistant orchestre le confort autour.

Vous ne récupérerez pas forcément toutes les informations que l’application Ajax affiche. Selon le chemin utilisé, certains détails peuvent rester absents, agrégés ou difficiles à exploiter proprement. Ce n’est pas forcément un problème. Une intégration de sécurité ne doit pas maximiser le nombre d’entités ; elle doit exposer les états fiables dont vous avez réellement besoin, avec un comportement stable après redémarrage et une signification que vous pouvez tester sans ambiguïté en conditions réelles.

Si un scénario exige une donnée que vous n’arrivez pas à obtenir de façon stable, ne la déduisez pas au forceps. Mieux vaut abandonner ce scénario ou le garder côté Ajax quand c’est possible. Les bricolages de corrélation finissent souvent par créer des faux positifs, puis des exceptions, puis une configuration que plus personne n’ose modifier sans craindre de casser l’alarme ou une routine de présence déjà validée par toute la maison.

Le piège classique consiste à vouloir armer, désarmer, contourner des zones et piloter toute la sécurité depuis HA. Techniquement, certaines intégrations communautaires peuvent offrir plus de fonctions qu’une écoute SIA. La question n’est pas seulement “est-ce possible ?”, mais que se passe-t-il quand ça casse ? Et surtout : qui dans le foyer saura revenir à une procédure sûre sans ouvrir l’éditeur d’automatisations, ni relire l’historique des changements ?

Une intégration non officielle peut dépendre d’un changement d’API, d’un jeton, d’un compte cloud, d’un mainteneur ou d’une version précise. Sur une lumière décorative, ce n’est pas dramatique. Sur une alarme, ce type de dépendance doit rester périphérique. Si elle tombe, vous perdez un confort, pas la protection, et ce contrat doit être écrit noir sur blanc dans vos notes d’installation, avec la liste des automatisations concernées.

Je déconseille aussi les automatismes qui désarment l’alarme sur simple présence détectée par téléphone. Les erreurs de géolocalisation, les téléphones déchargés, les invités, les délais réseau et les redémarrages créent trop de cas limites. Un désarmement automatique doit être traité comme une action sensible, pas comme une scène d’éclairage.

Le même principe vaut pour les automatisations “intelligentes” qui mélangent absence, sommeil, animaux, invités et plages horaires. Elles semblent élégantes jusqu’au premier cas réel : un téléphone resté dans la voiture, un enfant rentré plus tôt, une connexion cloud en retard, ou une mise à jour HA lancée au mauvais moment. Sur la sécurité, un scénario prévisible vaut mieux qu’une automatisation brillante mais opaque, surtout si plusieurs personnes vivent dans le logement.

Les bons scénarios sont ceux qui ajoutent de la visibilité sans voler le rôle d’Ajax. Une alarme déclenchée peut allumer le couloir, passer certaines ampoules en blanc froid, envoyer une notification sur un tableau de bord local ou démarrer un enregistrement côté caméra si votre installation le permet légalement et techniquement. La valeur vient du contexte ajouté autour de l’alerte, pas du remplacement de l’alerte, et elle doit rester visible dans les tests.

Un état armé peut aussi changer la maison en mode absence : couper certaines prises non critiques, baisser le chauffage, fermer des volets ou activer une simulation de présence. Ce sont des actions de confort et d’énergie. Si elles échouent, l’alarme reste armée, ce qui est le bon ordre de priorité.

Pour Nicolas, c’est là que l’intégration devient intéressante : pas dans le fantasme du contrôle total, mais dans des réactions mesurables. Un événement Ajax devient un signal domotique fiable à condition de garder les automatisations HA courtes, lisibles et réversibles.

Le bon test : un autre utilisateur doit pouvoir ouvrir l’automatisation et comprendre son effet en moins d’une minute.

1. Alarme déclenchée : allumer les zones de passage et envoyer une notification secondaire.
2. Armement total : couper les prises de confort et lancer le mode absence.
3. Désarmement manuel : remettre l’éclairage d’entrée et désactiver les routines absence.
4. Défaut ou perte de communication : créer une alerte maintenance, sans masquer l’alerte Ajax principale.

Commencez par définir le besoin exact avant de choisir la méthode.

Si votre besoin principal est de déclencher des actions secondaires sur état ou événement, commencez par SIA. C’est moins riche, mais plus cohérent avec une architecture de sécurité. Le mode listen-only est une limite assumée, pas un défaut.

Si vous avez besoin d’exposer davantage d’entités Ajax dans HA, vous pouvez regarder les intégrations communautaires, mais avec une discipline de production : sauvegarde avant installation, note de version surveillée, rollback documenté, et aucun automatisme critique tant que l’intégration n’a pas tenu dans le temps. HACS n’est pas une garantie de support, seulement un mode de distribution pratique pour composants tiers, avec les mêmes limites de maintenance que tout code communautaire.

Enfin, il existe un troisième choix sous-estimé : ne rien intégrer. Si votre installation Ajax fonctionne seule, que les notifications natives suffisent et que vous n’avez pas de scénario concret, ajouter une passerelle peut créer plus de maintenance que de valeur.

Dans beaucoup d’installations, le problème ne vient pas d’Ajax ni de Home Assistant, mais du réseau. un serveur HA en Wi-Fi, un routeur redémarré la nuit, une IP qui change ou un pare-feu “temporairement” ouvert peuvent suffire à rendre les événements invisibles côté domotique. L’alarme continue de fonctionner, mais la couche de réaction devient silencieuse, ce qui peut donner une fausse impression de panne Ajax alors que le pont local est seul en cause.

Donnez donc une place claire à chaque élément : IP fixe ou réservation DHCP pour le serveur HA, sauvegarde de la configuration, accès limité au port utilisé, et redémarrage testé après changement. Si vous utilisez un mini-PC ou un NAS pour Home Assistant, vérifiez aussi l’onduleur et la reprise automatique. Une intégration d’alarme qui dépend d’un serveur arrêté après coupure n’a pas beaucoup de valeur opérationnelle, même si elle était parfaite au moment de l’installation.

Ce n’est pas du durcissement extrême. C’est le minimum pour éviter les faux diagnostics.

Une intégration d’alarme n’est pas un gadget réseau. Documentez les ports, les secrets, les identifiants et les flux. Si vous exposez une réception SIA, limitez-la au réseau nécessaire, évitez les ouvertures publiques inutiles et gardez une trace de ce qui a été modifié. Cette trace doit rester compréhensible sans relire toute la documentation Home Assistant ni deviner le rôle d’un port oublié.

La configuration doit aussi rester compréhensible dans six mois. Notez où se trouve le réglage côté Ajax, quel composant HA reçoit les événements, quelles automatisations consomment ces états et comment désactiver proprement le pont. Le jour où une alerte arrive, personne ne doit chercher dans trois dashboards pour savoir quelle couche fait foi, ni deviner si une règle HA a modifié le comportement attendu au milieu d’un incident réel.

Sur une installation familiale, ajoutez une règle simple : l’application Ajax reste la référence sécurité. Home Assistant peut afficher, notifier et automatiser, mais il ne remplace pas les procédures connues par les occupants.

Le test utile n’est pas seulement “l’événement apparaît dans HA”. Il faut aussi redémarrer Home Assistant, couper le réseau local, simuler une perte du serveur domotique et vérifier que l’alarme Ajax garde son comportement attendu. Ce test paraît brutal, mais il révèle vite les dépendances mal placées.

Vérifiez aussi le sens des automatisations. Une lumière qui s’allume en cas d’alarme, très bien. Une règle qui désarme parce qu’un téléphone revient dans la zone, beaucoup moins. Une notification HA qui complète Ajax, très bien. Une notification HA qui remplace l’alerte native, non.

Si vous ne savez pas expliquer le scénario en une phrase, supprimez-le ou documentez-le mieux.

Avant même d’activer les automatisations, notez comment revenir à l’état précédent. Ce plan doit tenir sur quelques lignes : désactiver l’intégration HA, couper les automatisations liées, retirer la destination SIA si nécessaire, puis vérifier que l’application Ajax et les notifications natives fonctionnent seules. Le rollback doit être aussi accessible que l’installation, sinon l’intégration n’est pas prête pour un usage quotidien, même si la démo fonctionne sur le moment.

Cette étape évite un piège courant : on teste pendant une soirée, tout fonctionne, puis l’installation reste en place sans documentation. Trois mois plus tard, une mise à jour casse le flux et plus personne ne sait si l’événement devait encore allumer les lumières, envoyer une notification HA ou simplement être ignoré. Une alarme intégrée demande une mémoire d’exploitation, même dans une maison, parce que la sécurité ne doit pas dépendre de souvenirs.

Si vous n’êtes pas prêt à maintenir ce plan, limitez l’intégration à un simple affichage d’état.

Je ne connecterais pas Ajax à Home Assistant si le serveur HA tourne déjà de façon instable, si le réseau local est bricolé, si personne ne maintient les sauvegardes ou si le foyer ne sait pas quelle application utiliser en cas d’alerte. Dans ces cas, l’intégration ajoute de la confusion avant d’ajouter de la valeur, et elle rend le diagnostic plus lent le jour où il faut agir vite, avec moins de certitude sur la source du problème.

Je l’éviterais aussi pour une résidence secondaire sans supervision minimale. Une automatisation qui paraît utile sur place peut devenir impossible à diagnostiquer à distance. Commencez par fiabiliser Ajax, les notifications natives, l’alimentation et la connexion du hub. Home Assistant viendra ensuite, comme couche de confort et de visibilité.

Pour une maison connectée sérieuse, je garderais Ajax autonome et j’utiliserais Home Assistant en lecture/réaction. SIA est le bon point de départ si votre objectif est de récupérer des événements et d’ajouter des scénarios périphériques. C’est sobre, limité, mais aligné avec la logique d’une alarme, et c’est précisément ce que je privilégierais sur une installation familiale.

Je réserverais les intégrations communautaires aux installations où l’utilisateur accepte vraiment la maintenance : surveillance des mises à jour, rollback, tests réguliers et aucune dépendance critique. Si vous voulez seulement un dashboard plus joli ou deux automatisations de confort, ne faites pas porter ce poids à une intégration fragile.

La règle finale tient en une ligne : Ajax décide, Home Assistant réagit. Tant que cette séparation reste vraie, l’intégration apporte de la valeur. Dès qu’elle devient floue, vous êtes en train de déplacer la sécurité vers la couche la moins prévisible.