Si vous utilisez Zigbee2MQTT, vous n’êtes pas sans savoir qu’une mise à jour majeure en 2.x est disponible depuis plusieurs mois maintenant. Pourtant, beaucoup sont encore hésitants à franchir le pas et laisser une version Z2M 1.4x pour passer en 2.x. Pourtant, cette nouvelle version apporte un lot impressionnant de correctifs et d’améliorations du code. Ce qui permet à Zigbee2MQTT d’être toujours plus performant et fiable, et surtout de voir le support des nombreux derniers périphériques Zigbee du marché, comme la nouvelle gamme Shelly Zigbee, par exemple.
Alors il faut franchir le pas? D’autant que la version majeure 2.0 de zigbee2mqtt a déjà reçu bon nombre de mises à jour depuis sa libération, puisque, à l’heure où j’écris ces lignes, nous sommes déjà en version 2.2.1 pour la dernière version stable du célèbre gestionnaire de réseau Zigbee.
Principal probleme, la gestion des boutons avec Z2M 2.x
Dans la grande majorité des cas, la mise à jour vers Zigbee2MQTT 2.x se passe sans douleur. Le développement de cette nouvelle version optimisée prend en compte la migration automatique et c’est plus ou moins transparent en fin de compte, sauf pour les boutons et interrupteurs… Alors, si vous avez plusieurs périphériques de type interrupteurs et boutons dans votre réseau Zigbee, comme les interrupteurs Aqara par exemple, vous regretterez sans doute d’avoir effectué la mise à jour. Mais pas d’inquiétude, il faut simplement adopter les nouvelles pratiques pour revenir à une gestion stable et complète de ces périphériques.
En effet, comme mentionné dans un post qui préparait la mise à jour vers Zigbee2MQTT 2.0, tous les capteurs de clic ont été supprimés dans cette nouvelle version. Cela signifie que les sensor.*_click ainsi que les capteurs d’action sensor.*_action sont désormais désactivés par défaut et les entités supprimées.
Concrètement, cela peut rendre fou au premier regard, puisque un bouton intégré à zigbee2MQTT se comporte comme avant dans l’interface de Z2M. Autrement dit, dans l’onglet “Expose” des périphériques, le type d’action s’affiche bien à la pression sur la touche.
Mais du côté de Home Assistant, le même périphérique qui est correctement découvert par Home Assistant semble comme figé, affichant des états “unavailable” ou encore “unknown”. Les boutons étaient auparavant présentés comme des capteurs, ils sont désormais des actions.
Comment prendre en charge les boutons et interrupteurs Zigbee avec Zigbee2MQTT 2.x ?
Il existe 2 méthodes. La première, la plus simple, qui permet de rétablir le fonctionnement de vos automatisations et votre Home Assistant comme avant et d’activer tout simplement l’option Home Assistant legacy action sensors dans la configuration de Zigbee2MQTT.
Simple et rapide, cela permet de restaurer vos automatisations existantes utilisant ces périphériques. Pourtant, ce n’est pas une solution pérenne, qui est là pour permettre une transition douce, mais pourrait bien disparaitre dans une prochaine version de Zigbee2MQTT. De plus, après plusieurs mois de tests, j’ai constaté des fonctionnements parfois aléatoires avec cette option, avec également une petite latence par moment.
L’autre solution est d’utiliser plutôt le déclencheur de périphérique MQTT qui est spécifiquement fait pour cela. Mais pour cela, il va falloir modifier vos automatisations Home Assistant, qui ne doivent plus porter sur la valeur action des périphériques, mais sur son trigger.
Une petite exploration sous MQTT Explorer permet de mieux comprendre le fonctionnement. Pour chaque association d’un périphérique compatible, un topic trigger automation est créé pour ce périphérique sous le sujet homeassistant/device_automation/id_du_device/.
La logique de traitement de l’événement est alors tout autre sous une automatisation. Il n’est plus question d’écouter le canal action de l’entité en question, mais son trigger. Concrètement, le changement à opérer dans l’automatisation se traduit par le bloc ci-dessous :
triggers:
- domain: mqtt
device_id: 7543837550ff8bc1593bbfe8942c5f63
type: action
subtype: single_left
trigger: device
- entity_id:
- sensor.inter_garage_entree_inter_garage_entree_scene_state_scene_002Plus simplement, depuis l’interface graphique du moteur de gestion des automatisations Home Assistant, il ne s’agit plus de choisir une entité en déclencheur, mais un appareil.
On tape ensuite le nom donné à l’appareil sous Zigbee2MQTT et on choisit le déclencheur, ici une pression sur le bouton gauche de mon interrupteur Aqara.
L’automatisation écoute alors le trigger MQTT de l’action du périphérique et agit en conséquence. Le reste de l’automatisation n’a pas besoin de changement, uniquement la partie qui concerne le déclencher pour l’adapter à la nouvelle méthode.
Un changement bon à connaître et appliquer
Pas de dépendance à un mode legacy temporaire qui risque de disparaitre prochainement et même une latence disparue !
Voilà, je n’avais pas encore pris le temps de vous détailler cela pour plus de clarté, c’est maintenant chose faite. Je me suis moi-même pas mal triturer les meninges après ma migration vers Zigbee2MQTT 2.x. Outre le fait de devoir reprendre autant d’automatisations qui exploitent ce type de périphériques, ce qui peut être long et fastidieux, le passage vers Zigbee2MQTT 2.x n’est vraiment pas un problème et apporte pas mal d’optimisations, alors foncez.
Alors franchement recommander d’activer une option legacy… Ça me pose un problème… À dire vrais, je croyais même que ça avait dégagé avec Z2M 2.0.
Après, la méthode du device trigger, bien que recommandée, pour moi, c’est une régression avec l’utilisation d’id non lisible.
Reste la méthode expérimentale qui pour moi est certe la plus risquée quant à sa stabilité, mais peu être la plus pérenne, car la méthode legacy va disparaitre, celle des recommandée va passer legacy et l’expérimentale va devenir recommandée.
Bonjour,
Totalement d’accord avec toi. D’ailleurs, je ne recommande pas d’activer l’option legacy, qui montre même de la latence chez moi, comme je l’explique. Mais “l’activation temporaire” pour une transition douce dans le cas où tu as beaucoup de boutons sur ton install est une bonne alternative pour faire le switch.
Je te rejoins aussi sur la régression et la complication avec les triggers. Je trouve étrange de ne pas proposer quelque chose de plus simple, mais une fois que l’on a compris le truc, c’est finalement assez simple.