# Zigbee2mqtt : ne plus casser le lien avec Gladys quand on renomme un appareil **URL:** \ **Category:** Demande de fonctionnalités\ **Tags:** in-progress\ **Created:** [Août 27, 2026, 3:22 UTC](https://community.gladysassistant.com/t/zigbee2mqtt-ne-plus-casser-le-lien-avec-gladys-quand-on-renomme-un-appareil/10717 "2026-08-27T15:22:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 27, 2026, 3:22 UTC](https://community.gladysassistant.com/t/zigbee2mqtt-ne-plus-casser-le-lien-avec-gladys-quand-on-renomme-un-appareil/10717/1 "2026-08-27T15:22:23Z")
### Le problème Aujourd’hui, le lien entre un appareil Zigbee2mqtt et son équivalent dans Gladys repose sur le **nom de l’appareil** (le `friendly_name` défini dans Zigbee2mqtt). Conséquence : si on renomme un appareil depuis l’interface de Zigbee2mqtt, Gladys ne le reconnaît plus. Il est traité comme un **nouvel appareil** , et l’ancien reste en base avec son ancien nom. Trois effets concrets : 1. **Des doublons apparaissent** dans les listes d’appareils, notamment au moment de créer une scène ou d’ajouter un composant à un dashboard — on ne sait plus lequel est le bon. 2. **Les scènes existantes cassent silencieusement.** Elles continuent de pointer sur l’ancien appareil, qui ne reçoit plus aucune donnée. Aucun message d’erreur n’est affiché, la scène ne se déclenche simplement plus. 3. **L’historique est coupé en deux.** Les mesures d’avant le renommage restent sur l’ancien appareil, celles d’après sont sur le nouveau. Les graphiques repartent de zéro. Le problème a été remonté sur le forum ici : [Nettoyage de la base de données des appareils](https://community.gladysassistant.com/t/nettoyage-de-la-base-de-donnees-des-appareils/10695) À noter : renommer un appareil **depuis Gladys** ne pose aucun problème, c’est bien géré. C’est uniquement le renommage côté Zigbee2mqtt qui casse le lien. ### Le contournement actuel - Choisir un nom définitif dans Zigbee2mqtt au moment de l’appairage, et ne plus y toucher ensuite. - Renommer uniquement depuis Gladys, ce qui n’a aucun impact sur le lien. - Si le mal est fait : supprimer manuellement l’ancien appareil depuis **Intégrations → Zigbee2mqtt → Appareils** , puis recréer les scènes concernées. Ça fonctionne, mais ça suppose de connaître le piège à l’avance — ce qui n’est le cas de personne la première fois. ### La fonctionnalité demandée Que Gladys suive le renommage automatiquement, sans créer de doublon et sans casser les scènes existantes. Deux approches possibles, complémentaires : **1. Écouter l’événement de renommage de Zigbee2mqtt** Zigbee2mqtt publie déjà un événement `device_renamed` contenant l’ancien et le nouveau nom. Gladys pourrait s’y abonner et mettre à jour la référence de l’appareil à la volée. C’est un correctif ciblé, sans migration de données, qui règle le cas du renommage effectué pendant que Gladys tourne. **2. S’appuyer sur l’adresse Zigbee (IEEE address) plutôt que sur le nom** C’est la solution de fond : l’adresse IEEE est l’identifiant matériel de l’appareil, elle ne change jamais, quel que soit le nom qu’on lui donne. Gladys récupère déjà cette adresse et l’affiche dans la fiche de l’appareil, mais ne s’en sert pas pour l’identification. Cette approche couvre aussi les cas que l’événement ne couvre pas (renommage effectué alors que Gladys est arrêté, par exemple). En contrepartie, elle demande une migration des appareils Zigbee existants. ### Bénéfice Renommer un appareil est une opération banale, qu’on fait naturellement en réorganisant son installation. Aujourd’hui c’est une opération à risque, dont les conséquences n’apparaissent que plus tard, quand une scène ne se déclenche plus. Cette évolution supprimerait complètement le piège. ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [Août 27, 2026, 3:25 UTC](https://community.gladysassistant.com/t/zigbee2mqtt-ne-plus-casser-le-lien-avec-gladys-quand-on-renomme-un-appareil/10717/2 "2026-08-27T15:25:18Z")
Pour information, dans HA, il est possible de propager le renommage depuis l’interface Z2M en cochant cette option. ![Capture d’écran 2026-08-27 à 17.23.45](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/2/6/264c8ba847d45fadcab31e6abf92046f72c88602.png) Mais je trouve l’option 2 plus stable et moins sujette à erreur humaine. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 28, 2026, 8:36 UTC](https://community.gladysassistant.com/t/zigbee2mqtt-ne-plus-casser-le-lien-avec-gladys-quand-on-renomme-un-appareil/10717/3 "2026-08-28T08:36:40Z")
> [@cicoub13](#): > > Mais je trouve l’option 2 plus stable et moins sujette à erreur humaine. C’est stable, mais la gestion de l’existant est complexe. Si un utilisateur avait des scripts, du Node-RED, n’importe quoi d’externe qui utilisait l’external\_id, ça casse son installation existante. Je vais demander à Fable ce qu’il préconise. ---
**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\ **Post date:** [Août 28, 2026, 9:43 UTC](https://community.gladysassistant.com/t/zigbee2mqtt-ne-plus-casser-le-lien-avec-gladys-quand-on-renomme-un-appareil/10717/4 "2026-08-28T09:43:10Z")
Salut tout le monde ! Ce sujet est désormais **en cours de développement**. Une PR a été ouverte pour conserver le lien Gladys quand on renomme un appareil dans Zigbee2mqtt : > > > \### Description > > Gladys links Zigbee2mqtt devices through their \`friendly\_name\`,… which is embedded in every \`external\_id\` (device and features) and in the MQTT topics. Renaming a device from the Zigbee2mqtt UI therefore broke the link: the device appeared duplicated in the discover page, scenes silently stopped working, and the state history was split in two. > > This PR keeps the link alive across renames, without any migration and without changing the \`external\_id\` format: > > \- \*\*\`convertDevice\` now stores the immutable IEEE address as a device param\*\* (\`IEEE\_ADDRESS\`), so every newly added device carries its hardware identifier in DB. > \- \*\*A new \`syncRenamedDevices\` step runs on every \`zigbee2mqtt/bridge/devices\` message.\*\* This topic is retained and republished by Zigbee2mqtt after each rename, so renames are caught even when they happen while Gladys is offline (unlike the \`bridge/response/device/rename\` event, which is not retained). > - Devices whose \`friendly\_name\` still matches get their \`IEEE\_ADDRESS\` param backfilled (covers devices added before this PR). > - Devices whose name no longer matches are re-attached by IEEE address: the device and feature \`external\_id\`s are updated to the new name, while \*\*selectors are left untouched\*\*, so scenes, dashboards, history and third-party API usage keep working. The Gladys device name follows the rename only if the user never customized it. > - A name match is rejected when the IEEE addresses differ (cross-rename), to avoid re-attaching to the wrong physical device. > \- The stale RAM cache entries (\`deviceByExternalId\`, \`deviceFeatureByExternalId\`) keyed by the old name are dropped after the update. > > Renaming from Gladys is unchanged (it only touches the Gladys display name). Sync errors are caught and logged per device so one failing device can't break MQTT handling or the other renames. > > \## Forum > > Forum: https://community.gladysassistant.com/t/zigbee2mqtt-ne-plus-casser-le-lien-avec-gladys-quand-on-renomme-un-appareil/10717 > > \### Checklist > > \- \[x\] Tests pass: \`cd server && npm run coverage\` — 402 zigbee2mqtt tests passing, 100% line and branch coverage on the new \`syncRenamedDevices.js\` (no UI change, Cypress not needed) > \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`) > \- \[x\] No undocumented breaking change > > 🤖 Generated with \[Claude Code\](https://claude.com/claude-code) > > https://claude.ai/code/session\_01UpTLW3uQvhKaDq9RgGs1PG > > \--- > \_Generated by \[Claude Code\](https://claude.ai/code/session\_01UpTLW3uQvhKaDq9RgGs1PG)\_ N’hésitez pas à suivre la PR, à tester (optionnel, surtout pour les petites demandes) et à faire vos retours ici si besoin.