zibee2mqtt Bridge wird mehrfach angelegt

[Gast45]

Zusammenfassung der bisherigen Kommunikation. Danke für die bisherige Unterstützung.

Ausgangssituation war eine FHEM-Installation auf

- Stretch
- node 10.24.1
- npm 6.14.12

Diese wurde per backup und restore übertragen auf eine neue Linux-Basis:

- bullseye
- node 20.10.0
- npm 10.2.3

Das Backup habe ich innerhalb FHEM mit "backup" in der Befehlszeile erzeugt. Nach dem übertagen des Backups habe ich es wieder ausgepackt mit:

Code Auswählen Erweitern

sudo systemctl stop fhem
sudo tar -xvzf /opt/fhem/backup/FHEM-202311tt_hhmmss.tar.gz -C /opt/fhem/
sudo systemctl start fhem

Zudem habe ich auf Empfehlung folgende Dateien von stretch nach bullseye übernommen, wodurch auch spontan die Zigbee-Komponenten wieder mit FHEM kommunizieren konnten:

Code Auswählen Erweitern

configuration.yaml
state.json
database.db

Finales Problem:
Aus mir nicht erklärlichen Gründen wurde das eigentlich in der Konfiguration schon vorhandene Bridge-Device einfach neu angelegt. Da das alte Bridge-Device bereits "MQTT2_zigbee_pi" hieß, wurde für das neue Bridge-Device als Name automatisch "MQTT2_zigbee_bridge" vergeben.

Daraufhin habe ich das alte Bridge-Device Namens "MQTT2_zigbee_pi" gelöscht, bevor das neue angelegt wurde. Danach bekam das neue Bridge-Device auch wieder automatisch den Namen "MQTT2_zigbee_pi" und ich habe noch zusätzlich angewendet:

Code Auswählen Erweitern

set MQTT2_zigbee_pi attTemplate zigbee2mqtt_bridge
Dann stellte sich noch heraus, dass mit

Code Auswählen Erweitern

set MQTT2_zigbee_pi permit_join truenoch ein weiteres Device wieder mit dem Namen "MQTT2_zigbee_bridge" automatisch angelegt wird, das nach meinem Verständnis durch die Rückmeldung auf den Befehl entsteht.

In der readingList erschien folgender Eintrag:

Code Auswählen Erweitern

zigbee2mqtt/bridge/response/permit_join:.* { json2nameValue($EVENT) }
Diesen habe ich als

Code Auswählen Erweitern

$DEVICETOPIC/bridge/response/permit_join:.* { json2nameValue($EVENT) }in die readingList des eigentlichen Bridge-Device "MQTT2_zigbee_pi" übernommen und abschließend "MQTT2_zigbee_bridge" wieder gelöscht und habe jetzt scheinbar einen stabilen Zustand.

Ich würde mich freuen, wenn mir jemand dieses für mich eigenartige Verhalten erklären könnte oder mir sagt, was ich vielleicht noch zusätzlich elementar falsch gemacht habe.

[Beta-User]

Ich würde mich freuen, wenn mir jemand dieses für mich eigenartige Verhalten erklären könnte oder mir sagt, was ich vielleicht noch zusätzlich elementar falsch gemacht habe.

Das "Problem" war zum einen, dass du ziemlich hektisch reagiert hast und immer wieder alles neu angelegt hast => das ist unübersichtlich.

Der andere Teil ist der, dass die zigbee2mqtt-User mich "gezwungen" haben, auf eine bridge-Regex zu verzichten, die nur auf unveränderte "technische" Device-Namen gehört hat ("0x..."), so dass jetzt eben mehr oder weniger alles, was an dem Dienst immer mal wieder neu erfunden wird zu Verwirrung bei den Usern führt.

Sorry for inconvenience.

[Gast45]

Vielen Dank für die Antwort.

Hektisch wurde ich erst, nachdem sich das Ganze so unerwartet verhalten hat, und ich mit diversen Versuchsreihen versucht habe, irgendwie eine Lösung zu finden. Und das zieht sich dann ordentlich in die Länge.

Der andere Teil ist der, dass die zigbee2mqtt-User mich "gezwungen" haben, auf eine bridge-Regex zu verzichten...

Das ist also sozusagen die Ursache? Inhaltlich muss ich mir das demnächst mal erarbeiten. So spontan sagt mir das grad nichts. Ich versteh auch nicht, wieso das erst auf dem neuen linux und nicht schon auf dem vorherigen passiert ist, denn die Fhem-Installation war ja 1-zu-1 übernommen?

Aber das neue System läuft jetzt seit ein paar Wochen und scheint keine sonderbaren Effekte mehr zu zeigen.