zibee2mqtt Bridge wird mehrfach angelegt

Begonnen von Gast45, 12 November 2023, 20:51:02

Vorheriges Thema - Nächstes Thema

Gast45

#15
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:
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:
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:
set MQTT2_zigbee_pi attTemplate zigbee2mqtt_bridge
Dann stellte sich noch heraus, dass mit
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:
zigbee2mqtt/bridge/response/permit_join:.* { json2nameValue($EVENT) }
Diesen habe ich als
$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.


Meist liegt der Fehler vor der Tastatur

Beta-User

Zitat von: Gast45 am 27 November 2023, 15:06:33Ich 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.
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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.

ZitatDer 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.
Meist liegt der Fehler vor der Tastatur