The Problem
Today, the link between a Zigbee2mqtt device and its equivalent in Gladys is based on the device name (the friendly_name defined in Zigbee2mqtt).
Consequence: if a device is renamed from the Zigbee2mqtt interface, Gladys no longer recognizes it. It is treated as a new device, and the old one remains in the database with its old name.
Three concrete effects:
- Duplicates appear in the device lists, especially when creating a scene or adding a component to a dashboard — you no longer know which one is the correct one.
- Existing scenes break silently. They continue to point to the old device, which no longer receives any data. No error message is displayed, the scene simply no longer triggers.
- The history is split in two. Measurements before the renaming remain on the old device, those after are on the new one. The graphs start from zero.
The problem has been reported on the forum here: Cleaning the device database
Note: renaming a device from Gladys does not cause any problems, it is well managed. It is only the renaming on the Zigbee2mqtt side that breaks the link.
Current Workaround
- Choose a final name in Zigbee2mqtt at the time of pairing and never touch it again.
- Rename only from Gladys, which has no impact on the link.
- If the damage is done: manually delete the old device from Integrations → Zigbee2mqtt → Devices, then recreate the affected scenes.
It works, but it assumes you know about the trap in advance — which is not the case for anyone the first time.
The Requested Feature
That Gladys automatically follows the renaming without creating duplicates and without breaking existing scenes.
Two possible approaches, complementary:
1. Listen to the Zigbee2mqtt renaming event
Zigbee2mqtt already publishes a device_renamed event containing the old and new name. Gladys could subscribe to it and update the device reference on the fly. This is a targeted fix, without data migration, that addresses the case of renaming performed while Gladys is running.
2. Rely on the Zigbee address (IEEE address) rather than the name
This is the fundamental solution: the IEEE address is the hardware identifier of the device, it never changes, regardless of the name given to it. Gladys already retrieves this address and displays it in the device card, but does not use it for identification. This approach also covers cases that the event does not cover (renaming performed while Gladys is stopped, for example). In return, it requires a migration of existing Zigbee devices.
Benefit
Renaming a device is a common operation, which is done naturally when reorganizing your installation. Today it is a risky operation, whose consequences only appear later, when a scene no longer triggers. This evolution would completely eliminate the trap.
