[Z2M] Tests in zigbee2mqtt 1.42.0 > 2.1.3 >..> 2.4.0 >..> 2.6.1>...>2.7.2

[mutmut]

Hallo zusammen,
seit heute bin ich auf z2m 2.1.3 in meinem externen Docker umgestiegen (Release der letzten Woche Releases · Koenkk/zigbee2mqtt · GitHub).
Ich habe natürlich ein Backup meines ursprünglichen data-Verzeichnisses von 1.42.0 gemacht (die Basis )

Also mit nur der Änderung des Images koenkk/zigbee2mqtt:2.1.3 (ohne weitere Änderungen) gibt es ein Update mit vielen neuen Dateien:

Dann habe ich in der z2m-Integration von Gladys nachgeschaut und habe zwei Geräte (NOUS A1Z-Steckdose), bei denen ein Update angefordert wird.

Es fehlt die Kindersicherung (die ich immer noch habe, da nicht aktualisiert):

Es scheint, dass sich child_lock geändert hat:

child_lock on/off-Werte wurden von true/false zu LOCK/UNLOCK geändert

{"child_lock":"UNLOCK","countdown":0,"current":0,"energy":68.2,"indicator_mode":"off/on","last_seen":"2025-03-10T18:22:28+01:00","linkquality":196,"power":0,"power_outage_memory":"restore","state":"ON","update":{"installed_version":192,"latest_version":192,"state":"idle"},"voltage":226}

Bisher habe ich nicht auf das Update geklickt und die Befehle im Dashboard funktionieren weiterhin:

Bisher ist alles in Ordnung, ich habe keine bemerkenswerten Unterschiede festgestellt.

Dann habe ich einige empfohlene Zeilen zur configuration.yaml-Datei hinzugefügt (nur für den Fall):

Keine bemerkenswerten Änderungen nach dem Neustart des Docker.

Bei meinen verschiedenen Zigbee-Geräten habe ich keine weiteren Probleme festgestellt:

SONOFF SNZB-02D / ZBMINI
NodOn SIN-4-1-21 / SIN-4-2-20 / SIN-4-1-20
Nous A1Z
Aqara DJT11LM / JY-GZ-01AQ
IKEA E2013 / E2213
HEIMAN HS1CA-E
Tuya RB-SRAIN01

Das ist alles für mich für den Anfang der Tests, ich komme zurück, wenn ich noch etwas sehe, und wenn andere testen wollen/können, könnt ihr diesen Beitrag ergänzen

[pierre-gilles]

Génial merci pour ton test @mutmut !

Pour l’histoire du child_lock, normalement ça devrait quand même fonctionner (d’ailleurs c’est bien le cas chez toi), car Gladys utilise dynamiquement une valeur donné par Zigbee2mqtt (expose.value_on)

Par contre bizarre que ça ne soit plus affiché dans les fonctionnalités disponibles

[mutmut]

Quelques news de la version 2.1.3
Pas de problèmes relevés jusqu’à aujourd’hui, tout fonctionne correctement depuis mon upgrade 1.42.0 à 2.1.3

Test avec Z2M 2.2.1
J’avais un capteur d’ouverture IKEA qui m’indiquait une ouverture alors qu’il était fermé. Les données passaient bien car Z2M voyait quand j’ouvrais et je fermais ma porte mais ne répercutait pas le bon état (EDIT : c’était les piles qui étaient presque vides …)
J’ai checké github et vu qu’il y avait une nouvelle version de Z2M donc test :

• stop du docker z2m
• sauvegarde du rep data
• modif du docker-compose et redémarrage

Côté Z2M, tout est ok.
Côté Gladys, j’ai toujours mes 2 prises NOUS qui demande un update et qui ne me montrent toujours pas la sécurité enfant (donc je n’update pas ces 2 devices pour l’instant).

Je surveille maintenant l’évolution dans Gladys, à suivre.

[Florian]

Hallo,

Ich habe es gewagt, direkt mit 2.3.0. Ich habe nicht viel Material (einige Lampen und Knöpfe von Ikea, SonOff- und Aquara-Sensoren) und keine Probleme.

Meine schnelle und schmutzige Prozedur, um auf ein von Gladys nicht verwaltetes Zigbee2MQTT umzustellen:

Man stoppt den Zigbee-Dienst in der Gladys-Konfiguration

Man wechselt in ein Verzeichnis, das die Daten und die docker-compose-Datei aufnehmen wird:

Man erstellt die compose-Datei (anpassen, bei mir ist das Dongle /dev/ttyUSB0):

docker-compose.yml

services:
  zigbee2mqtt:
    container_name: zigbee2mqtt
    image: ghcr.io/koenkk/zigbee2mqtt
    restart: unless-stopped
    volumes:
      - ./z2m:/app/data
      - /run/udev:/run/udev:ro
    ports:
      # Frontend-Port
      - 8080:8080
    environment:
      - TZ=Europe/Paris
    devices:
      # Anpassen je nach Dongle
      - /dev/ttyUSB0:/dev/ttyACM0
  mqtt:
    image: eclipse-mosquitto
    ports:
      - 1884:1883
    volumes:
      - ./mqtt:/mosquitto/config

Man kopiert die Daten-Dateien von Zigbee2MQTT, verwaltet von Gladys, in das aktuelle Verzeichnis:

cp -r /var/lib/gladysassistant/zigbee2mqtt/* ./

Man konfiguriert neu. Da ich das standardmäßig isolierte Docker-Compose-Netzwerk verwende, habe ich den Standard-MQTT-Port wiederhergestellt.

Man muss auch den USB-Adapter-Typ in der Z2M-Konfiguration ab Version 2.0.0 hinzufügen. Bei mir ist es zstack.

sed -i 's/mqtt:\/\/localhost:1884/mqtt:\/\/mqtt/g' z2m/configuration.yaml
sed -i 's/serial:/&\n  adapter: zstack/' z2m/configuration.yaml

sed -i 's/listener 1884/listener 1883/'  mqtt/mosquitto.conf

Man startet

docker-compose up -d

Um zu überprüfen, ob alles in Ordnung ist, überprüft man die Logs: docker logs zigbee2mqtt

Jetzt kann man die Zigbee2MQTT-Konfiguration in Gladys abschließen. Man stellt auf „Verbindung zu einer bestehenden Installation“ ein, die MQTT-Konfiguration sollte bereits in Ordnung sein (man hat das MQTT-Passwort durch Kopieren der Konfiguration wiederhergestellt), es sollte von selbst weiterlaufen.

[prohand]

Ich bin auch direkt auf 2.3.0 umgestiegen, bisher ohne Probleme.

Ich bin nicht auf 2.4.0 umgestiegen, aufgrund der verschiedenen gemeldeten Fehler:

Frequent Z2MQTT restarts since updating to 2.4.0

Zigbee2MQTT 2.4.0, OTA. Incorrect detection of firmware version of all devices

Ich halte euch auf dem Laufenden, falls ich besondere Probleme habe.

[mutmut]

Danke für euer Feedback @Florian und @prohand, ich aktualisiere den Titel des Themas, um zu sehen, wo wir stehen.

[Florian]

Hallo,

Aktualisiert auf 2.4.0, alles in Ordnung.

Zur Info, die beiden von @prohand erwähnten Fehler: Der erste betrifft nicht das offizielle Docker (eine dunkle Geschichte mit npm-Abhängigkeiten auf dem PC des Typen) und der zweite ist eine Änderung der Anzeige der Versionen im OTA-Tab (etwas verwirrend, aber kein Fehler).

Ich habe auch das Frontend von z2m auf das neue umgestellt. Das betrifft Gladys nicht wirklich, und es funktioniert (nur auf Englisch für den Moment, und die Graphviz-Karte ist nicht benutzerfreundlich).

Natürlich sage ich euch Bescheid, wenn ich Fehler habe.

PS: Es gab viele kleine Änderungen/Korrekturen an vielen Zigbee-Geräten seit der Version 1.42.x. Bei meiner Ausrüstung nichts Wildes, aber ein paar Dinge, die auf Gladys-Seite aktualisiert werden müssen (hier eine Batteriemessung, dort etwas, das nichts nützte).

[mutmut]

Danke @Florian für dein Feedback!

@Florian

Aber es gibt ein paar Dinge, die bei Gladys „upgedated“ werden müssen (hier eine Batteriemessung, da etwas, das nicht gebraucht wird)

Das erinnert mich an mein Problem mit den verschwundenen child_lock in Gladys für meine NOUS-Steckdosen (die ich deshalb noch nicht aktualisiere).
Man muss das im Auge behalten, um zu sehen, ob man vor dem Wechsel auf das interne z2m von Gladys noch etwas entwickeln muss.

[Florian]

Ja,
Später ist das immer ein bisschen der Fall mit z2m und all dem Material im Katalog.
Und je mehr man „Rückstand“ aufholt, desto mehr wird es.

Falls andere es beta testen wollen, denke ich, dass die Integration zwischen z2m 2.x und Gladys immer noch in Ordnung ist und dass es „sicher“ ist, damit zu beginnen (nachdem man Backups gemacht hat )

[pierre-gilles]

Hallo zusammen

Ja, ich denke, wir können auf die Version 2.x umsteigen!

Ich habe einen Pull Request erstellt, der einfach das Container-Image auf 2.4.0 aktualisiert:

Zigbee2mqtt: Upgrade to 2.4.0 (#2334)

Dieser Pull Request ermöglicht das Testen des Verhaltens im internen Modus. Ich werde einen Docker-Build vorschlagen.

@mutmut

Danach habe ich in der Datei configuration.yaml die empfohlenen Zeilen hinzugefügt (nur für den Fall):

Sind diese Zeilen wirklich notwendig? Das sieht wirklich nach Dingen aus, die wir in Gladys nicht verwenden.

[mutmut]

@pierre-gilles

Sind diese Zeilen wirklich notwendig? Das sieht aus wie etwas, das wir in Gladys nicht verwenden

Laut dem, was ich gelesen habe, scheint das hauptsächlich mit HA verbunden zu sein.

Dann weiß ich nicht, wie Gladys die von z2m in mqtt gesendeten Informationen verwaltet.
Ich habe in diesem Artikel gesehen, dass es besser ist, die Triggers zu verwenden und dass das besser für ein Upgrade ist (offensichtlich für die Schalter). Genauso scheint das mit HA verbunden zu sein.

Dann gibt es diese Update-Anforderungen, die Funktionen wie den child_lock entfernen. Klar, ich ändere das über z2m und nicht Gladys, falls nötig, aber es wäre besser, alles über Gladys für die nicht-technischen Benutzer tun zu können (das ist meine Meinung).
Jedenfalls habe ich meine NOUS-Steckdosen nicht aktualisiert und es funktioniert immer noch sehr gut und ich habe immer noch die Verfügbarkeitsoption, um sie im Dashboard oder in den Szenen zu verwenden.

[mutmut]

@pierre-gilles

Ich habe einen PR erstellt, der einfach das Container-Image auf 2.4.0 aktualisiert:

Planst du eine automatische Sicherung der Konfiguration für den Fall?

[Florian]

@pierre-gilles

Sind diese Zeilen wirklich notwendig? Das sieht wirklich nach Dingen aus, die wir in Gladys nicht verwenden

Hallo, für mich funktioniert es auch ohne.
Allerdings muss der Adapter unbedingt konfiguriert werden, da zstack nicht mehr der Standard ist:

serial:
  adapter: zstack

[pierre-gilles]

@Florian

Allerdings muss der Adapter unbedingt konfiguriert werden, da zstack nicht mehr standardmäßig aktiviert ist

Ja, ich denke, man muss das « NONE » ändern und zu zstack wechseln:

@cicoub13 Hast du schon mal einen Blick auf diesen Teil geworfen?

[cicoub13]

Ich hatte den Wechsel des Treibers von ezsp zu ember beobachtet.
An sich ist das Update einfach. Aber es automatisch durchzuführen und dabei die Firmware des Dongles zu überprüfen, fügte Komplexität hinzu.

Falls der Treiber zstack hinzugefügt werden muss, um die Konfiguration vor der Version 2.4.0 zu aktualisieren, kann ich das tun. Aber erlaubt die aktuelle Version (1.42.0) das bereits?

[pierre-gilles]

@mutmut

Planst du eine automatische Sicherung der Konfiguration für den Fall?

Was meinst du? In diesem Fall können wir nicht viel tun, das ist die Aufgabe von Zigbee2mqtt, wir haben keine Ahnung, was es macht!

Und mehrere Hauptversionen von Zigbee2mqtt zu verwalten, ist sehr komplex und bringt wenig Interesse

@mutmut

Dann gibt es diese Update-Anforderungen, die Funktionen wie child_lock entfernen.

Ich teste gerade auf meiner Seite, ich verstehe nicht, warum die child_lock nicht mehr da sind, nichts hat sich geändert…

Screenshot in Zigbee2mqtt 1.42.0 :

Screenshot in Zigbee2mqtt 2.4.0 :

@cicoub13

Ich hatte den Wechsel des Treibers von ezsp zu ember überprüft.

Ok, das ist ein anderes Thema, wir behalten das für ein anderes Thema

[pierre-gilles]

Ok, ich habe verstanden, dass sich der GET-Request für das entdeckte Gerät von:

zu folgendem geändert hat:

[mutmut]

@pierre-gilles

Siehst du was?

nichts
Witz beiseite, ich bin im Bastelmodus, also ein großes Copy/Paste vom aktuellen Repo. Aber um zurückzugehen, ist es komplexer, das gebe ich zu.

@pierre-gilles

Ich führe gerade Tests auf meiner Seite durch, ich verstehe nicht, warum die child_lock nicht mehr da sind, nichts hat sich geändert…

Ich hatte vorher/nachher nicht geschaut, ehrlich gesagt, und tatsächlich sind die 2 child_lock in z2m, aber nicht in Gladys.

Die Steckdose_03 wurde hinzugefügt, als mein z2m bereits in 2.x war (ohne „Kindersicherung“ in Gladys), während die Gefriertruhe-Steckdose (Steckdose_01) aus der Version 1.4.2 stammt (und ich sie nicht in Gladys aktualisiert habe)

Falls du mehr Infos brauchst, kann ich die 2 Steckdosen mit deiner Hilfe genauer überprüfen.

[pierre-gilles]

OK, das ist für den child_lock erledigt (der Commit: Zigbee2mqtt: Upgrade to 2.4.0 by Pierre-Gilles · Pull Request #2334 · GladysAssistant/Gladys · GitHub)

Jetzt müssen wir den zstack-Treiber erzwingen, aber abgesehen davon sehe ich nichts anderes zu tun

Ich habe einen Build auf gladysassistant/gladys:upgrade-zigbee2mqtt-to-2.x gemacht, zu Hause an meinem Beelink mini-S13 getestet mit einem Sonoff Dongle-E

[pierre-gilles]

Ich habe gerade einen Sonoff ZBDongle-P bestellt, um Tests für die Migration von „nichts“ zu „zstack“ in der Konfiguration durchzuführen

Weiter geht’s mit den Tests am Donnerstag!