[Z2M] Pruebas en zigbee2mqtt 1.42.0 > 2.1.3 >..> 2.4.0 >..> 2.6.1>...>2.7.2

Hola a todos,
desde hoy he pasado a z2m 2.1.3 en mi docker externo (versión de la semana pasada Releases · Koenkk/zigbee2mqtt · GitHub).
Por supuesto, hice una copia de seguridad de mi carpeta data original en 1.42.0 antes (lo básico :wink: )

Por lo tanto, con solo la modificación de la imagen koenkk/zigbee2mqtt:2.1.3 (sin nada más modificado), tenemos una actualización con muchos nuevos archivos:

Luego miré en la integración z2m de Gladys y me encontré con 2 dispositivos (enchufe NOUS A1Z) donde se solicita una actualización.


Falta el bloqueo infantil (que siempre tengo porque no lo he actualizado):

Parece que child_lock ha cambiado:

Los valores on/off de child_lock han cambiado de true/false a LOCK/UNLOCK

{"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}

Por ahora no he hecho clic en la actualización y los comandos en el panel de control siguen funcionando:

Hasta ahora todo está bien, no he visto ninguna diferencia notable.

Luego añadí al archivo configuration.yaml las líneas recomendadas (por si acaso):


No hubo cambios notables después de reiniciar el docker.

Para mis diferentes dispositivos Zigbee, no he visto otros problemas:

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

Eso es todo por mi parte por ahora, volveré si veo más cosas, y si otros quieren/podrán probar, pueden alimentar este post :blush:

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 :thinking:

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 :wink: :

  • 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.

Hola,

He intentado la aventura, directamente en 2.3.0. No tengo mucho material (algunas lámparas y botones de Ikea, sensores SonOff y Aqara) y ningún problema.

Mi procedimiento rápido y sucio para cambiar a un Zigbee2MQTT no gestionado por Gladys:

Se detiene el servicio Zigbee en la configuración de Gladys

Nos situamos en un directorio que alojará los datos y el docker-compose:

Se crea el archivo compose (a adaptar, en mi caso el dongle es /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:
      # A adaptar según su dongle
      - /dev/ttyUSB0:/dev/ttyACM0
  mqtt:
    image: eclipse-mosquitto
    ports:
      - 1884:1883
    volumes:
      - ./mqtt:/mosquitto/config

Se copian los archivos de datos de Zigbee2MQTT gestionado por Gladys en el directorio actual:

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

Se reconfigura. Como uso la red aislada por defecto de docker compose, he vuelto a poner el puerto por defecto de mqtt.

También hay que añadir el tipo de adaptador USB en la configuración de z2m a partir de la v2.0.0. En mi caso 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

Se inicia

docker-compose up -d

Para verificar que todo está bien, verificar los registros: docker logs zigbee2mqtt

Ahora se puede terminar la configuración de Zigbee2MQTT en Gladys. Se pone en « Conexión a una instalación existente », la configuración MQTT debe estar ya bien (se ha recuperado la contraseña mqtt copiando la configuración), debería arrancar solo.

También acabo de pasar directamente a 2.3.0 sin problemas por el momento.

No he pasado a 2.4.0 debido a los diferentes errores reportados:

Les mantendré informados si tengo algún problema en particular.

Gracias por vuestros comentarios @Florian y @prohand, actualizo el título del tema para saber en qué punto estamos.

Hola,

Actualizado a 2.4.0, todo bien.

Para información, los 2 errores mencionados por @prohand: El primero no afecta al docker oficial (una historia oscura de dependencia npm en la PC del tipo) y el segundo es un cambio en la visualización de las versiones en la pestaña OTA (un poco perturbador, pero no es un error)

También he cambiado el frontend de z2m al nuevo. No afecta realmente a Gladys, y funciona (solo en inglés por el momento, y el mapa graphviz no es muy amigable)

Por supuesto, les aviso si tengo errores.

PS: ha habido muchos pequeños cambios/correcciones en muchos dispositivos zigbee desde la 1.42.x, en mi equipo, nada loco, pero cosas que « actualizar » del lado de gladys (una medida de batería por aquí, algo que no servía por allá)

¡Gracias @Florian por tu respuesta!

Se parece a lo que tengo con los child_lock que han desaparecido de Gladys para mis enchufes NOUS (y que por lo tanto aún no actualizo).
Habrá que vigilar para ver si hay que hacer un poco de desarrollo antes de pasar al z2m interno de Gladys.

Sí,
Después, es un poco siempre el caso con z2m y todo el material del catálogo.
Y cuanto más « retraso » tomemos, más habrá.

Si otros quieren probar la versión beta, en todo caso, creo que la integración entre z2m 2.x y gladys sigue siendo correcta y que es « seguro » para empezar (después de hacer copias de seguridad :wink: )

¡Hola a todos! :slight_smile:

Efectivamente, creo que vamos a poder pasar a la 2.x.

He hecho una PR que simplemente actualiza el contenedor a la 2.4.0:

Esta PR permite probar el comportamiento con el modo interno, voy a proponer un build Docker.

¿Son realmente necesarias estas líneas? Parecen cosas que no usamos en Gladys

De lo que he leído, parece estar relacionado principalmente con HA.

Luego no sé cómo Gladys gestiona la información z2m enviada en mqtt.
He visto en este artículo que es mejor usar los triggers y que es mejor para una actualización (para los interruptores aparentemente). Igual parece estar relacionado con HA.

Luego están estas solicitudes de actualización que eliminan funciones como el child_lock. Ciertamente lo modifico a través de z2m y no de Gladys si es necesario, pero sería mejor poder hacerlo todo a través de Gladys para los usuarios no geeks (esa es mi opinión).
En cualquier caso, no he actualizado mis enchufes NOUS y sigue funcionando muy bien y sigo teniendo la opción de disponibilidad para usarlos en el panel o en las escenas.

¿Planeas una copia de seguridad automática de la configuración en algún momento?

Hola, para mí funciona sin ellas.
Sin embargo, es absolutamente necesario configurar el adaptador, ya que zstack ya no es el predeterminado:

serial:
  adapter: zstack

Sí, habrá que cambiar el « NONE » y pasar a zstack creo:

@cicoub13 ¿De tu lado ya habías mirado un poco esta parte?

Había mirado el cambio del controlador ezsp a ember.
En sí, la actualización es fácil. Pero hacerlo automáticamente con la verificación del firmware del dongle, eso añadía complejidad.

Si hay que añadir el controlador zstack para actualizar la configuración antes de la 2.4.0, puedo hacerlo. Pero la versión actual (1.42.0) ya permite eso?

¿Qué opinas? En este caso, no podemos hacer mucho, es trabajo de Zigbee2mqtt, nosotros no tenemos conocimiento de lo que hace.

Y gestionar varias versiones mayores de Zigbee2mqtt es muy complejo para poco interés :slight_smile:

Estoy haciendo pruebas por mi parte, no entiendo por qué los child_lock ya no están, nada ha cambiado…

Captura de pantalla en Zigbee2mqtt 1.42.0 :

Captura de pantalla en Zigbee2mqtt 2.4.0 :

Ok, es otro tema, lo dejamos para otro tema :wink:

Ok, ya lo entiendo, el get de discovered device ha cambiado de:

A esto:

nada :joy:
Broma aparte, estoy en modo bricolaje, así que un gran copiar/pegar del repositorio actual. Pero para volver atrás, es más complejo, te lo concedo.

no había mirado antes/después, te lo confieso, y efectivamente los 2 child_lock están bien en z2m pero no en Gladys.




La toma_03 se añadió cuando mi z2m ya estaba en 2.x (sin el Bloqueo infantil en Gladys) mientras que la toma_congelador (toma_01) data de la 1.4.2 (y no la he actualizado en Gladys)

Si necesitas más información, puedo revisar las 2 tomas con más detalle (con tu ayuda).

OK, el child_lock está arreglado :slight_smile: (el commit: Zigbee2mqtt: Upgrade to 2.4.0 by Pierre-Gilles · Pull Request #2334 · GladysAssistant/Gladys · GitHub)

Ahora hay que ver cómo forzar el driver zstack, pero aparte de eso no veo nada más que hacer :stuck_out_tongue:

Hice un build en gladysassistant/gladys:upgrade-zigbee2mqtt-to-2.x, probado en la práctica en mi casa con mi Beelink mini-S13 de prueba y un Sonoff Dongle-E

Acabo de pedir un dongle Sonoff ZBDongle-P para hacer pruebas de migración de « nada » a « zstack » en la configuración :slight_smile:

¡Continuación de las pruebas el jueves!