Zigbee2mqtt: Verbindung zu Gladys nicht trennen, wenn Gerät umbenannt wird

Das Problem

Heute basiert die Verbindung zwischen einem Zigbee2mqtt-Gerät und seinem Äquivalent in Gladys auf dem Gerätenamen (dem friendly_name, der in Zigbee2mqtt definiert ist).

Folge: Wenn man ein Gerät über die Zigbee2mqtt-Oberfläche umbenennt, erkennt Gladys es nicht mehr. Es wird als neues Gerät behandelt, und das alte bleibt in der Datenbank mit seinem alten Namen.

Drei konkrete Auswirkungen:

  1. Doppelungen erscheinen in den Gerätelisten, insbesondere beim Erstellen einer Szene oder beim Hinzufügen eines Komponenten zu einem Dashboard — man weiß nicht mehr, welches das richtige ist.
  2. Bestehende Szenen brechen leise. Sie zeigen weiterhin auf das alte Gerät, das keine Daten mehr erhält. Es wird keine Fehlermeldung angezeigt, die Szene löst einfach nicht mehr aus.
  3. Der Verlauf wird in zwei Teile gespalten. Die Messungen vor dem Umbenennen bleiben beim alten Gerät, die danach sind beim neuen. Die Diagramme starten von vorne.

Das Problem wurde im Forum hier gemeldet: Reinigung der Gerätedatenbank

Zu beachten: Ein Gerät über Gladys umzubenennen, stellt kein Problem dar, das wird korrekt behandelt. Nur das Umbenennen auf Seiten von Zigbee2mqtt bricht die Verbindung.

Die aktuelle Umgehung

  • Einen endgültigen Namen in Zigbee2mqtt beim Pairing wählen und ihn danach nicht mehr ändern.
  • Nur über Gladys umbenennen, was keine Auswirkungen auf die Verbindung hat.
  • Wenn der Schaden bereits geschehen ist: Das alte Gerät manuell unter Integrationen → Zigbee2mqtt → Geräte löschen und die betroffenen Szenen neu erstellen.

Das funktioniert, setzt aber voraus, dass man die Falle im Voraus kennt — was beim ersten Mal niemand tut.

Die gewünschte Funktion

Dass Gladys das Umbenennen automatisch verfolgt, ohne Doppelungen zu erzeugen und ohne bestehende Szenen zu brechen.

Zwei mögliche, sich ergänzende Ansätze:

1. Das Umbenennungsereignis von Zigbee2mqtt abhören

Zigbee2mqtt veröffentlicht bereits ein Ereignis device_renamed, das den alten und den neuen Namen enthält. Gladys könnte sich daran anmelden und die Gerätebezugnahme automatisch aktualisieren. Das ist ein gezielter Fix ohne Datenmigration, der den Fall des Umbenennens während des Gladys-Betriebs löst.

2. Die Zigbee-Adresse (IEEE-Adresse) statt des Namens verwenden

Das ist die grundlegende Lösung: Die IEEE-Adresse ist die Hardware-ID des Geräts, sie ändert sich nie, unabhängig vom Namen. Gladys holt sich bereits diese Adresse und zeigt sie in der Gerätekarte an, verwendet sie aber nicht zur Identifizierung. Dieser Ansatz deckt auch Fälle ab, die das Ereignis nicht abdeckt (z. B. Umbenennung, während Gladys ausgeschaltet ist). Als Gegenleistung erfordert er eine Migration der bestehenden Zigbee-Geräte.

Nutzen

Ein Gerät umzubenennen ist eine banale Operation, die man natürlich beim Umorganisieren der Installation durchführt. Heute ist es eine riskante Operation, deren Folgen erst später auftreten, wenn eine Szene nicht mehr ausgelöst wird. Diese Entwicklung würde die Falle vollständig beseitigen.

Zur Information: In HA ist es möglich, die Umbenennung von der Z2M-Oberfläche aus zu verbreiten, indem Sie diese Option aktivieren.

Aber ich finde Option 2 stabiler und weniger fehleranfällig.

Es ist stabil, aber die Verwaltung des Bestehenden ist komplex. Wenn ein Benutzer Skripte, Node-RED oder irgendetwas Externes hatte, das die external_id nutzte, würde es seine bestehende Installation beschädigen.

Ich werde Fable fragen, was sie empfiehlt.

Hallo zusammen!

Dieses Thema ist nun in Entwicklung.

Ein Pull Request wurde eröffnet, um den Gladys-Link zu behalten, wenn man ein Gerät in Zigbee2mqtt umbenennt:

Zögert nicht, dem Pull Request zu folgen, zu testen (optional, besonders bei kleinen Anfragen) und euer Feedback hier zu hinterlassen, falls nötig.