Je demandais comment sauvegarder les configs, Pierre-Giles disait :
Tu vas dans le dossier où tu as sauvegardé ta configuration (regarde le volume Docker que tu as mis)
Par défaut sur le site on met tout dans “/var/lib/gladysassistant”
Dans ce dossier il y a un dossier SQlite: c’est la DB de Gladys qui contient toute ta configuration, tu peux le mettre de côté
Le seul truc qui sera pas gardé, c’est les containers additionnels type Zigbee2mqtt, on a pas de process pour repartir de la DB et reconstituer ces containers, mais ça vaudrait le coup de pouvoir gérer ça
Lorsque je veux le remettre en place, il m’affiche bien toute la config mais impossible de faire fonctionner Zigbee2mqtt, en effet les liens entre Gladys - mqtt et Zigbee2mqtt ne sont pas fonctionnels.
Alors que tout fonctionne bien avec le fichier de base.
Comment puis je remettre l’ancienne base et faire en sorte que Zigbee2mqtt soit fonctionnel ?
Je crois qu’il faut relancer Zigbee2mqtt dans l’intégration. Je ne crois pas qu’il y ait de process pour relancer les containers sur une nouvelle base malheureusement !
Du coup ça veut dire qu’il faut je relance la détection de tous mes éléments ?
Arf, c’est bien galère car ils sont fixés et pas forcément accessibles…
A mon avis, c’est un vrai point négatif cette impossibilité de sauvegarder les données et de pouvoir les remettre.
Gladys Plus règle ce problème ?
C’est pour savoir car pour le moment je ne me vois pas dépenser 120€/an juste pour cette feature, je n’en suis pas au point d’avoir besoin des autres.
Le souci vient de l’intégration Gladys Zigbee2mqtt qui n’est pas capable de retomber sur ces pattes en cas de sauvegarde/restauration sur une autre instance.
Il y a une issue Github qui existe depuis un bout de temps mais personne ne s’est lancé dessus pour l’instant :
Cc @AlexTrovato@cicoub13 Il y a de plus en plus de demande de pouvoir relancer une instance sur une autre machine, ça c’est vraiment bien que la network_key, pan_id et channel soit stocké dans la DB de Gladys, ça évite de devoir tout re-configurer quand on déplace Gladys d’une instance à une autre
En gros l’idée c’est de faire en sorte que le service puisse retomber sur ces pattes si on prend la DB d’une instance, et qu’on la met sur un autre. Gladys doit pouvoir relancer Zigbee2mqtt avec les mêmes paramètres, sinon l’utilisateur devra ré-appairer tout son matériel.
Hésite pas si tu as d’autres questions, on peut discuter de l’implémentation !
Comme je viens de recevoir mon RPI4, j’ai pu faire des essais.
J’aime bien en installant un nouveau système d’avoir un système de backup, alors j’ai fait des test de backup sur la db gladys et de zigbee2mqtt. Il faut savoir que j’avais installé gladys pour commencer mes essais sur un vieux pc sous ubuntu en attendant d’avoir mon RPI4.
Pour gladys pas de souci avec le .db. Pour zigbee2mqtt pas de problème non plus. J’ai simplement copier les fichiers configuration.yaml, coordinator_backup.json et database.db avant d’activer zigbee2mqtt dans gladys.
Après avoir copié ces fichiers j’ai activé zigbee2mqtt, gladys a procédé à l’installation et j’ai retrouvé mes appareils fonctionnels sans les réappairés.
Me reste plus qu’à écrire un script bash pour sauvegarder et exporter automatiquement et régulièrement ces fichiers.
