publish: Domotique : les vrais problèmes en domotique Zigbee & Home Assistant
This commit is contained in:
Cédrix
@@ -1,19 +0,0 @@
|
||||
{
|
||||
"title": "Domotique : les vrais problèmes en domotique Zigbee & Home Assistant",
|
||||
"slug": "domotique-les-vrais-problemes-en-domotique-zigbee-home-assistant",
|
||||
"_updated_at": "2026-05-16 06:39:16",
|
||||
"published": true,
|
||||
"published_at": "2026-05-22 18:00",
|
||||
"category": "domotique",
|
||||
"tags": {
|
||||
"tags": [
|
||||
"Zigbee2MQTT",
|
||||
"Home Assistant",
|
||||
"MQTT",
|
||||
"Zigbee"
|
||||
]
|
||||
},
|
||||
"seo_title": "",
|
||||
"seo_description": "Retour d'expérience sur les vrais problèmes en domotique Zigbee et Home Assistant : déconnexions, mises à jour, capteurs HS et pollution réseau.",
|
||||
"og_image": "https://www.abonnel.fr/file?uuid=da1b3cec-980d-458c-9d2b-0c950d278f22&name=cover.svg"
|
||||
}
|
||||
@@ -1,79 +0,0 @@
|
||||
# Domotique : les vrais problèmes en domotique Zigbee & Home Assistant
|
||||
|
||||
Quand on parle de domotique sur YouTube ou dans les articles de blog, on voit souvent des installations parfaites, des tableaux de bord magnifiques et des automatisations qui se déclenchent au millième de seconde. La réalité, quand on auto-héberge sa domotique au quotidien, est un peu différente. Après avoir publié une première vidéo sur *Zigbee, Zigbee2MQTT et Home Assistant* qui présentait l'écosystème et ses avantages, je voulais aborder l'envers du décor : les **problèmes concrets** que je rencontre régulièrement et la façon dont je tente de les résoudre.
|
||||
|
||||
L'objectif n'est pas de me plaindre ni de critiquer les outils que j'utilise — au contraire, j'ai choisi cette approche justement parce qu'elle me laisse la main. Mais je trouve important de **montrer la réalité du terrain**, parce que c'est dans ces moments-là, quand on cherche, qu'on teste, qu'on tâtonne, qu'on apprend vraiment comment tout fonctionne. Et si d'autres rencontrent les mêmes soucis, peut-être qu'ils pourront comparer leurs expériences, proposer des solutions, ou simplement se rassurer en sachant qu'ils ne sont pas seuls.
|
||||
|
||||
## Le problème le plus pénible : l'antenne Zigbee qui décroche
|
||||
|
||||
Le souci qui m'a poussé à écrire cet article, c'est ma clé Zigbee, déportée en PoE, qui se **déconnectait régulièrement** de Zigbee2MQTT. À intervalles aléatoires, toutes les 5 à 15 minutes, la connexion tombait. C'était intermittent, difficile à diagnostiquer, et surtout extrêmement frustrant. Parfois elle réapparaissait toute seule au bout de quelques secondes, parfois il fallait redémarrer le service Zigbee2MQTT, et parfois même redémarrer toute la machine.
|
||||
|
||||
Le problème, c'est que **toute la chaîne domotique dépend de cette antenne**. Quand le Zigbee tombe :
|
||||
|
||||
- les capteurs deviennent inaccessibles et leurs valeurs ne sont plus remontées,
|
||||
- les automatisations qui dépendent de ces capteurs ne se déclenchent plus,
|
||||
- les commandes envoyées vers les actionneurs (prises, ampoules, vannes thermostatiques) restent en attente ou échouent,
|
||||
- et selon ce qui est piloté, ça peut devenir un vrai problème — j'y reviens plus bas avec les radiateurs.
|
||||
|
||||
Au final, après pas mal de pistes explorées (alimentation de la clé, position de l'antenne, interférences Wi-Fi sur la même bande), le coupable était ailleurs : **un switch réseau défaillant** qui provoquait des micro-coupures. La clé Zigbee elle-même fonctionnait parfaitement, mais comme elle est déportée en PoE, la moindre coupure réseau coupait aussi le lien avec Zigbee2MQTT. Le remplacement du switch a réglé le problème d'un coup. C'est typiquement le genre de panne qu'on ne soupçonne pas au début, parce que le réseau "marche" — la box répond, les autres équipements semblent OK — mais les micro-coupures, elles, ne se voient pas sans aller chercher dans les logs.
|
||||
|
||||
Pour diagnostiquer ce genre de souci, un outils m' été indispensable : le flair.
|
||||
|
||||
## Les problèmes côté serveur : mises à jour et dépendances
|
||||
|
||||
Auto-héberger Home Assistant, c'est génial pour la liberté que ça offre, mais ça implique aussi de gérer soi-même les mises à jour. Et toutes ne se passent pas bien.
|
||||
|
||||
Régulièrement, je rencontre des situations où :
|
||||
|
||||
- une mise à jour de Home Assistant casse une intégration qui fonctionnait très bien la veille,
|
||||
- un addon refuse de redémarrer après update à cause d'une dépendance cassée,
|
||||
- une intégration tierce ne répond plus comme avant parce que son API interne a changé,
|
||||
- ou plus subtil, le système redémarre partiellement, certains services remontent et d'autres non.
|
||||
|
||||
Cela dit, soyons honnêtes : ce n'est pas spécifique à l'auto-hébergement. **Même avec des solutions cloud**, on a régulièrement des changements d'API, des fonctionnalités qui disparaissent, des intégrations qui cessent d'être maintenues, ou des conditions tarifaires qui évoluent. La différence, c'est qu'en auto-hébergé on peut souvent corriger soi-même, alors qu'en cloud on subit.
|
||||
|
||||
Il faut simplement avoir en tête, quelle que soit la solution choisie, qu'on **passera toujours un moment, de temps en temps, à corriger, adapter, reconfigurer**. Une installation domotique n'est jamais "finie". La parade reste classique : lire les *release notes* avant de mettre à jour, faire des sauvegardes systématiques, et **ne jamais mettre à jour la veille d'un départ en vacances**.
|
||||
|
||||
## Les problèmes côté objets connectés
|
||||
|
||||
C'est là que la diversité du matériel devient à la fois la force et la faiblesse de l'écosystème Zigbee. Plusieurs marques, plusieurs firmwares, plusieurs comportements, et donc plusieurs types de problèmes.
|
||||
|
||||
### Pile HS
|
||||
|
||||
Le grand classique. Un capteur de température, d'ouverture ou de mouvement qui se met à remonter des valeurs erratiques ou qui ne remonte plus rien du tout. Souvent, c'est simplement la pile en fin de vie. Home Assistant peut généralement remonter le niveau de batterie, ce qui aide à anticiper, mais certains capteurs annoncent encore 80 % juste avant de tomber complètement.
|
||||
|
||||
### Valeurs incomplètes
|
||||
|
||||
Certains objets ne remontent pas toutes les données qu'on attendrait. Une prise connectée qui devrait remonter la **puissance instantanée** ne renvoie parfois que l'énergie totale consommée, ou inversement. Cela peut venir du firmware de l'objet, mais aussi de la façon dont Zigbee2MQTT expose les valeurs : selon le modèle déclaré dans la base de Zigbee2MQTT, certains clusters Zigbee ne sont pas exposés.
|
||||
|
||||
### Valeurs incorrectes
|
||||
|
||||
Plus piégeux : les valeurs sont bien remontées, mais elles sont fausses. Par exemple, il fait 9 °C dehors et mon capteur extérieur indique -1 °C. Ou l'**énergie totale consommée passe de 1234 kWh à 950 kWh** d'un coup, ce qui est physiquement impossible puisqu'un compteur ne peut que monter. Ces dérives faussent les graphiques et peuvent déclencher des automatisations à tort. Quand on s'en aperçoit, il faut souvent redémarrer le capteur (retirer puis remettre la pile), voire le réappairer.
|
||||
|
||||
### Mauvaise réactivité
|
||||
|
||||
Parfois, l'objet n'a pas perdu le réseau, il est bien visible dans Zigbee2MQTT, mais les commandes mettent un temps fou à lui parvenir — voire ne lui parviennent pas du tout du premier coup. C'est particulièrement gênant pour de l'éclairage où on attend une réponse immédiate. Dans mon cas, j'ai pu résoudre ce point en jouant sur la **configuration de Zigbee2MQTT** (paramètres de transmission, canal Zigbee, position de la clé, ajout de routeurs Zigbee pour densifier le maillage).
|
||||
|
||||
### Pollution Zigbee et appareils bavards
|
||||
|
||||
Un point souvent sous-estimé : tous les objets Zigbee ne sont pas égaux face à la **discipline réseau**. Certains capteurs, notamment du **matériel chinois bon marché**, sont extrêmement bavards. Ils envoient des trames à très haute fréquence, remontent des valeurs même quand rien ne change, ou réémettent leur état toutes les quelques secondes "au cas où". Pris isolément, ça passe. Mais quand on en accumule plusieurs sur le même réseau Zigbee, ça crée une vraie **pollution** : la bande passante du canal sature, les routeurs Zigbee passent leur temps à relayer du bruit, et au final ce sont les objets utiles qui en pâtissent (latence, perte de paquets).
|
||||
|
||||
Le plus gênant, c'est que ce type d'appareil est **difficile à régler** : peu (voire pas) de paramètres exposés pour réduire la fréquence des reportings, firmware fermé qu'on ne peut pas reflasher, et parfois aucune documentation sur les valeurs réellement envoyées. La parade, quand c'est possible, c'est de **limiter le nombre de ces appareils**, de les isoler sur un réseau secondaire ou un autre canal, ou de filtrer leur trafic au niveau de Zigbee2MQTT (via les options de *debounce* ou de *throttle*) pour ignorer les remontées trop rapprochées.
|
||||
|
||||
### Perte de réseau
|
||||
|
||||
Le scénario le plus pénible : un objet décroche complètement du réseau Zigbee. Sur un capteur, c'est gênant. Sur un actionneur qui pilote un **radiateur électrique** en plein hiver, ça l'est beaucoup plus. Si la commande "passer en mode confort" n'arrive pas, on rentre dans une maison froide. Pire, si la commande "passer en mode éco" n'arrive pas et que le radiateur reste en confort toute la journée, on s'en aperçoit sur la facture. C'est pour ce type de scénario qu'il faut **toujours prévoir un mode de repli** : un thermostat physique sur le radiateur, un mode manuel, ou une logique qui détecte qu'un actionneur ne répond plus depuis trop longtemps et qui envoie une notification.
|
||||
|
||||
## Les outils indispensables
|
||||
|
||||
Pour gérer tout ça au quotidien, deux outils reviennent constamment :
|
||||
|
||||
- **SSH**, pour accéder à la machine hôte, consulter les logs système, ceux de Zigbee2MQTT, redémarrer un service ciblé sans tout casser, ou éditer un fichier de configuration à la volée.
|
||||
|
||||
## Pourquoi continuer malgré tout
|
||||
|
||||
À la lecture de tout ça, on pourrait se demander pourquoi je m'embête. La réponse tient en deux points. D'abord, **tout cela tourne**. Au quotidien, ma domotique fait ce que je lui demande, et les problèmes décrits ici représentent une fraction du temps total d'utilisation. Ensuite et surtout, j'ai **la main sur tout** : pas de cloud, pas d'abonnement, pas de dépendance à un éditeur qui peut décider du jour au lendemain de fermer son service ou de changer ses conditions.
|
||||
|
||||
Le revers de cette liberté, c'est précisément ce que je décris dans cet article. C'est moi qui diagnostique, c'est moi qui répare. Et c'est aussi en faisant ça qu'on comprend vraiment comment Zigbee, MQTT et Home Assistant communiquent entre eux — bien mieux qu'en suivant un tutoriel "tout va bien".
|
||||
|
||||
Si vous rencontrez les mêmes types de soucis, n'hésitez pas à partager vos solutions en commentaire. C'est exactement le genre d'échange qui fait avancer ces sujets, parce qu'on est nombreux à tâtonner sur les mêmes problèmes — et qu'une astuce trouvée par quelqu'un d'autre peut faire gagner des heures de debug.
|
||||
@@ -7,7 +7,7 @@
|
||||
"featured": false,
|
||||
"published_at": "2026-05-22 18:00",
|
||||
"created_at": "2026-05-22 18:00:00",
|
||||
"updated_at": "2026-05-16 06:34:48",
|
||||
"updated_at": "2026-05-16 06:39:18",
|
||||
"revisions": [
|
||||
{
|
||||
"n": 1,
|
||||
@@ -21,7 +21,7 @@
|
||||
"external_links": [],
|
||||
"seo_title": "",
|
||||
"seo_description": "Retour d'expérience sur les vrais problèmes en domotique Zigbee et Home Assistant : déconnexions, mises à jour, capteurs HS et pollution réseau.",
|
||||
"og_image": "",
|
||||
"og_image": "https://www.abonnel.fr/file?uuid=da1b3cec-980d-458c-9d2b-0c950d278f22&name=cover.svg",
|
||||
"category": "domotique",
|
||||
"tags": {
|
||||
"tags": [
|
||||
|
||||
Reference in New Issue
Block a user