El complemento Zigbee2mqtt tiene un botón « Activar/Desactivar » que detiene los contenedores, pero no limpia ni las variables en la base de datos ni los archivos en el disco. No hay forma de reiniciar desde cero sin intervención manual. La idea es agregar un botón « Restablecer » en la página de configuración, con confirmación (como en matterbridge/node-red), que realice un reinicio completo: desconexión, eliminación de variables, eliminación de archivos y contenedores.
Procedimiento de reinicio:
Llamar a this.disconnect() (detener contenedores + desconexión MQTT)
Eliminar todas las variables de configuración en la base de datos mediante this.gladys.variable.destroy(key, this.serviceId) para cada clave de CONFIGURACIÓN en constants.js:
Por lo que vale, me parece perfecto. ¡Es muy claro!
En cuanto a la copia de seguridad de Gladys +, si restauramos una versión con un antiguo dongle, ¿no hay riesgo? ¿O, por el contrario, es una seguridad adicional porque podríamos restaurar en caso de manipulación incorrecta?
En este caso, habría que probarlo, no sé cómo reacciona. En los casos que hemos visto en el foro, era otro caso: cambio de dongle con archivos ya en el disco.
En el caso de la restauración de Gladys Plus, no se restauran los archivos de Zigbee2mqtt, solo se proporciona a Zigbee2mqtt lo necesario para volver a empezar con la misma configuración, no es exactamente lo mismo.
Para mí, se guarda todo el contenido de la carpeta zigbee2mqtt (por lo tanto configuration.yaml, database.db y coordinator_backup.json).
Pero la restauración prueba si hay una nueva configuración. Si se restaura una copia de seguridad hecha con un antiguo dongle (mientras que un nuevo dongle está conectado y z2m no está inicializado), también habrá que usar este botón.
Aproveché para reforzar la robustez de la integración, ya que había inestabilidades que se volvían aún más visibles con esta nueva funcionalidad.
En particular, el error del contenedor detenido: hasta ahora, en Gladys, si el contenedor Zigbee2mqtt ya estaba detenido, se emitía un error 304 y nunca se pasaba a la eliminación del contenedor. Esto se ha corregido para todas las integraciones
Lo he probado en muchos casos localmente en un mini-PC, ¡y funciona genial!
Lo probé en una instancia con un dongle pero sin dispositivos emparejados. Funciona bien, los estados son correctos después y las carpetas/variables/contenedores se eliminan correctamente