Binding Zigbee : des interrupteurs actifs sans serveur

Quand Home Assistant redémarre, un interrupteur mural devrait encore allumer la pièce. Une automatisation classique ne le garantit pas : le bouton envoie un événement au coordinateur, le logiciel décide quoi faire, puis renvoie une commande à la lampe. Le binding Zigbee raccourcit ce chemin en reliant directement un émetteur compatible à une lampe, une prise ou un groupe Zigbee.

Nature de cet article : analyse documentaire des documentations Home Assistant et Zigbee2MQTT, complétée par des articles étrangers. Aucun appareil n’a été installé ni mesuré pour cet article. La compatibilité doit être vérifiée modèle par modèle avant de généraliser la méthode dans un logement.

Le binding n’est ni un nouvel appairage ni une automatisation cachée. Les appareils restent membres du même réseau Zigbee et continuent à remonter leurs états au système domotique. Ils reçoivent simplement une relation supplémentaire : tel endpoint du bouton peut envoyer tel type de commande à tel appareil ou groupe.

Ce que le binding change réellement

Une commande liée contourne Home Assistant, ZHA ou Zigbee2MQTT au moment où elle est exécutée. Les documentations officielles de Zigbee2MQTT et de ZHA donnent les deux bénéfices utiles : la commande peut rester disponible lorsque le logiciel ou le coordinateur est indisponible, et le pilotage direct évite l’aller-retour logiciel.

Cette propriété répond à un problème très concret. Une maison locale ne devient pas résiliente simplement parce qu’elle n’utilise pas le cloud : un serveur unique peut encore être un point de panne. Le binding permet de réserver un chemin minimal aux gestes essentiels, par exemple allumer, éteindre ou faire varier une lumière.

Il ne remplace pas pour autant les automatisations. Une liaison transporte les commandes prévues par les clusters Zigbee compatibles ; elle ne sait pas décider que la lumière doit rester éteinte en journée, choisir une scène selon la présence ou attendre une temporisation. Pour ces règles, Home Assistant reste le bon niveau.

Besoin	Binding Zigbee	Automatisation Home Assistant
Marche, arrêt, variation directe	Adapté si les appareils exposent les mêmes clusters	Possible, avec un détour par le serveur
Fonctionnement pendant un redémarrage du serveur	Oui, après configuration	Non
Conditions, horaires, présence, scènes	Très limité	Adapté
Appareils de protocoles différents	Non	Oui
Diagnostic et historique centralisés	Partiel	Oui

Appairage, groupe et binding : trois notions différentes

L’appairage fait entrer un appareil dans le réseau Zigbee. Il lui donne les clés du réseau et permet au coordinateur de le connaître. Sans cette première étape, ZHA ou Zigbee2MQTT ne peut pas configurer proprement la liaison.

Un groupe Zigbee donne une adresse commune à plusieurs appareils. Une commande envoyée au groupe peut atteindre toutes les lampes sans répéter le même message pour chacune. Ce groupe vit dans le réseau Zigbee ; il ne faut pas le confondre avec un groupe d’entités créé seulement dans l’interface de Home Assistant.

Le binding enregistre enfin la relation entre une source et une cible. La cible peut être un appareil ou un groupe. La documentation Zigbee2MQTT illustre précisément le cas d’une télécommande liée à un groupe de lampes : la télécommande commande le groupe sans intervention du logiciel domotique.

L’article néerlandais de Tweakers sur IKEA Home Smart montre que ce principe est ancien : les télécommandes et lampes Trådfri pouvaient déjà être reliées directement sans passer par l’application. Le sujet n’est donc pas une fonction récente de Home Assistant, mais une capacité du protocole que ses intégrations permettent désormais d’administrer.

Les conditions à vérifier avant de commencer

Le logo Zigbee ne prouve pas qu’un binding utile est possible. La source doit exposer un cluster de sortie et la cible le cluster d’entrée correspondant. Pour l’éclairage, les noms rencontrés sont notamment genOnOff pour marche/arrêt, genLevelCtrl pour la variation et lightingColorCtrl pour la couleur ou la température de couleur. Un appareil peut n’en prendre en charge qu’une partie.

Quatre vérifications évitent la plupart des impasses :

La fiche de l’appareil source mentionne le binding. Une télécommande qui remonte seulement des événements au coordinateur ne sait pas nécessairement commander une cible directement.
La cible expose le même cluster. Un bouton marche/arrêt ne peut pas inventer une commande de variation absente de son endpoint.
Les deux appareils sont sur le même réseau Zigbee. Deux ponts distincts créent deux réseaux, même s’ils sont tous deux intégrés à Home Assistant.
L’appareil sur pile est réveillé pendant la configuration. Zigbee2MQTT et ZHA préviennent tous deux qu’une télécommande endormie peut ignorer la demande de liaison ; il faut généralement appuyer sur un bouton juste avant de confirmer.

Le guide sur le choix du coordinateur Zigbee explique les critères de protocole, de connexion et de placement à vérifier avant de constituer le réseau.

Configurer un binding avec Zigbee2MQTT

La procédure documentée par Zigbee2MQTT passe par son interface : ouvrir la fiche de l’appareil source, choisir l’onglet Bind, sélectionner la cible puis les clusters compatibles. Une cible de groupe est préférable lorsqu’un même bouton doit piloter plusieurs lampes ; elle évite de multiplier les relations individuelles.

L’ordre prudent est le suivant :

appairer la télécommande et la ou les lampes au même coordinateur ;
créer un groupe Zigbee si plusieurs cibles doivent réagir ensemble ;
ouvrir l’onglet de binding de la source ;
réveiller la source si elle fonctionne sur pile, puis lancer la liaison ;
vérifier dans la réponse que les clusters souhaités ont réussi et que la liste des échecs est vide.

Une fois la liaison créée, il faut couper temporairement le service Zigbee2MQTT ou Home Assistant et vérifier les commandes essentielles. Ce contrôle chez vous est plus probant qu’une simple confirmation dans l’interface : il valide le comportement de vos modèles et de leurs firmwares, pas seulement l’enregistrement de la relation.

Le pas-à-pas installer Zigbee2MQTT couvre l’installation du coordinateur, du broker MQTT et le premier appairage. Le binding intervient après ces fondations, pas à leur place.

Configurer la même relation avec ZHA

La documentation ZHA décrit un chemin équivalent dans Home Assistant : Paramètres → Connectivité → Zigbee → Appareils, puis la gestion de l’appareil source et l’onglet des bindings. ZHA propose les appareils ou groupes qu’il considère comme liables. Il faut là aussi réveiller une télécommande sur pile juste avant de confirmer.

Une nuance mérite attention : ZHA lie normalement les télécommandes au coordinateur pour transmettre leurs événements à Home Assistant. Certains modèles limitent le nombre de cibles et peuvent exiger de retirer cette relation avant d’en accepter une autre. Cette opération peut alors supprimer des événements utiles aux automatisations. Il vaut mieux noter la configuration initiale et avancer sur une seule pièce avant de modifier tout le logement.

L’article italien de Henrik Sozzi documentait déjà la liaison de groupes avec ZHA en 2021 et le besoin de réveiller les télécommandes. Son interface illustrée est ancienne : pour les menus actuels, la documentation officielle Home Assistant reste la référence.

L’article britannique de Neil Turner insiste sur la même limite : tous les appareils ne prennent pas en charge le binding, et certains endpoints n’exposent qu’une partie des fonctions. L’article allemand de SmartHomePraxis complète cet angle avec la distinction entre cible individuelle et groupe.

Choisir du matériel sans promettre une compatibilité universelle

Un coordinateur compatible ZHA ou Zigbee2MQTT est nécessaire pour former le réseau, appairer les appareils et administrer leurs relations. Le SONOFF ZBDongle-E est déjà documenté dans le catalogue du blog et convient à ces deux piles logicielles. Le binding peut ensuite préserver les commandes compatibles pendant une indisponibilité du serveur ; il ne rend pas le coordinateur inutile pour l’installation et la maintenance du réseau.

Pour une cible d’éclairage, une ampoule Zigbee standard est plus cohérente qu’une ampoule Wi-Fi pilotée par une API séparée. Les Philips Hue peuvent rejoindre un coordinateur local sans pont, comme l’explique l’article passer ses ampoules connectées en 100 % local. Cela ne dispense pas de vérifier la fiche Zigbee2MQTT ou ZHA du modèle et les clusters exposés avant d’en faire une cible de binding.

Une architecture à deux étages

Le compromis le plus robuste consiste à conserver deux niveaux. Le premier assure les gestes fondamentaux avec quelques bindings simples : interrupteur du couloir vers son groupe de lampes, bouton du chevet vers l’éclairage principal. Le second laisse Home Assistant enrichir ces gestes avec la présence, l’heure, la luminosité ou les scènes.

Cette séparation limite les surprises. Si le serveur fonctionne, les automatisations apportent le confort attendu. S’il redémarre, les commandes physiques de base restent utilisables. Le binding ne doit toutefois pas devenir une toile de relations invisibles : documentez chaque source, chaque cible et les clusters choisis, puis conservez une procédure d’unbinding.

Enfin, un arrêt physique de l’alimentation d’une ampoule connectée reste un arrêt physique. Aucun binding ne peut commander une lampe privée de courant. Le bon montage doit donc conserver l’alimentation des ampoules et fournir aux occupants un geste mural compréhensible, point déjà détaillé dans le guide sur les ampoules locales.