Je sais c’est un problème sur les deux 
Une idée comme ça ,peut être qu’on devrai recupérer la variable
SQLITE_FILE_PATH
Et stocker la conf au même endroit, plutôt que de tout mettre en dur
2 « J'aime »
Hello à tous !
Pour information, suite aux changements de @cicoub13 sur la PR, j’ai effectué une review technique et fonctionnelle de la PR.
Le compte rendu de ma review est disponible sur GitHub: Zigbee2mqtt service by cicoub13 · Pull Request #1098 · GladysAssistant/Gladys · GitHub
Edit: J’attend aussi le fix ici:
Comme dit dans la PR :
- Gestion du SQLITE_FILE_PATH
- Fix des valeurs click pour les boutons
Il me reste la petite vidéo de démo et la documentation dans gladys-website 
7 « J'aime »
Hello, super travail, de mon côté juste une remarque, il semblerait que certains mapping ait sauté pour les deux seuls types d’appareils que j’ai (deux switchs WXKG01LM Aquara ainsi qu’un cube MFKZQ01LM Aquara).
Le problème avait été corrigé mais il semble que ça ne soit plus le cas.
Sinon je pense que les points évoqués plus haut sont bien corrigés, en tout cas je n’ai pas vu d’autres problèmes
Hello @Albenss
Je viens de corriger le type de tes deux devices. Est-ce que tu peux mettre à jour l’image et tester à nouveau ?
Actuellement, les valeurs single, double, hold sont transformées en valeurs numériques.
Les autres sont traitées comme des chaînes de caractères : triple, quadruple, release, many et toutes celles de ton cube shake, wakeup, fall, tap, slide, flip180, flip90, rotate_left, rotate_right.
Tu peux poster/voir le thread suivant : Scène avec un bouton (double ou simple clic)
Alors comme test j’ai commencé par supprimé le container Gladys (mais pas Z2M et MQTT) pour le recréer après avoir pull la nouvelle image, j’ai alors observé le même comportement, je me suis dit que c’était surement un problème venant de la BD.
J’ai donc recréé le tout avec la persistance dans un nouveau dossier, malheureusement la création automatique du conteneur mqtt ne fonctionne pas, il semble qu’il y ait encore un problème de droit d’accès au dossier, ou alors mqtt ne sais pas ou trouver son fichier de config, dans le log de MQTT j’ai ceci :
1616604311: Error: Unable to open config file /mosquitto/config/mosquitto.conf.
Je pense qu’il reste encore des endroits ou le path est en dur. En effet quand je change le dossier de persistance pour /var/lib/z2m-test quand on active le service zeegbee2mqtt un nouveau dossier se créé ici /var/lib/gladysassistant.
J’ai donc un doublon de dossier qui est créé par le service :
$ ls -al gladysassistant/zigbee2mqtt/
mqtt/ z2m/
$ ls -al z2m-test/zigbee2mqtt/
mqtt/ z2m/
EDIT : par contre c’est bien dans le nouveau dossier de persistance /var/lib/z2m-test/zigbee2mqtt/mqtt/ que les fichiers de configs de mosquitto se trouvent et pas dans le dossier doublon dans le path /var/lib/gladysassistant donc l’ancien path est probablement en dur dans mqtt
Oui pardon. Il faut que tu supprimes les devices pour qu’ils aient les bons types de feature dans la base.
Pour les paths et droits, est-ce que tu as supprimé tous les containers depuis le 22 mars au soir ? Sinon, les containers Z2M et MQTT sont toujours sur les anciens paths.
Le fix que j’ai fait modifie les paths à la création, mais ne gère pas la modification post création.
Yes j’avais bien supprimé tous les containers, je vais réessayer d’ici 30 min après avoir supprimé les images également pour tester.
1 « J'aime »
Bon toujours le même problème malheureusement…
Tu utilises bien la variable SQLITE_FILE_PATH (comme dans ton docker-compose plus haut) ?
"SQLITE_FILE_PATH=/var/lib/gladys-z2m/gladys-z2m-production.db"
Tu peux me donner le résultat des commandes suivantes ?
docker inspect -f '{{ .Mounts }}' gladys-z2m-mqtt
docker inspect -f '{{ .Mounts }}' gladys-z2m-zigbee2mqtt
Ma commande est la suivante :
docker run -d \
--log-opt max-size=10m \
--restart=always \
--privileged \
--network=host \
--name GladysZigbee2mqtt \
-e NODE_ENV=production \
-e SERVER_PORT=1080 \
-e TZ=Europe/Paris \
-e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-zigbee2mqtt.db \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /var/lib/z2m-test:/var/lib/gladysassistant \
-v /dev:/dev \
-v /run/udev:/run/udev:ro \
cicoub13/gladys:dev-zigbee2mqtt
$ docker inspect -f '{{ .Mounts }}' gladys-z2m-mqtt
[{volume 227a9e1e87d118c13a7d214c28395292e7b69fae2abcf2b330821ceb31add32d /var/lib/docker/volumes/227a9e1e87d118c13a7d214c28395292e7b69fae2abcf2b330821ceb31add32d/_data /mosquitto/data local true } {bind /var/lib/gladysassistant/zigbee2mqtt/mqtt /mosquitto/config true rprivate} {volume c30bc5eede272b937d1e6bb1dd46c224f576b9d3c294bec90ed8cd6cca80926c /var/lib/docker/volumes/c30bc5eede272b937d1e6bb1dd46c224f576b9d3c294bec90ed8cd6cca80926c/_data /mosquitto/log local true }]
Concernant la deuxième commande je ne peux pas te fournir de réponse puisque Z2M ne s’est pas créé.
$ docker inspect -f '{{ .Mounts }}' gladys-z2m-zigbee2mqtt
Error: No such object: gladys-z2m-zigbee2mqtt
OK, j’ai compris 
Quand tu mets ces deux options :
-v /var/lib/z2m-test:/var/lib/gladysassistantSQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-zigbee2mqtt.db
Tu montes ton dossier host /var/lib/z2m-test dans le container en tant que /var/lib/gladysassistant
Puis tu dis à Gladys de fonctionner avec /var/lib/gladysassistant, ce qu’il fait quand il crée les fichiers de configuration Mosquito et Z2M. C’est d’ailleurs pour cela que tu retrouves bien les fichiers de configuration dans /var/lib/z2m-test dans ton host.
Lorsque Gladys crée les autres containers (Mosquito et Z2M), il utilise la variable SQLITE_FILE_PATH pour monter les volumes. Donc le /var/lib/gladysassistant de ton host… C’est là où ça ne va pas. Je ne sais pas comment détecter que /var/lib/gladysassistant est en fait un montage de /var/lib/z2m-test.
Je te propose d’essayer avec ce fichier docker-compose 
:
docker run -d \
--log-opt max-size=10m \
--restart=always \
--privileged \
--network=host \
--name GladysZigbee2mqtt \
-e NODE_ENV=production \
-e SERVER_PORT=1080 \
-e TZ=Europe/Paris \
-e SQLITE_FILE_PATH=/var/lib/z2m-test/gladys-zigbee2mqtt.db \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /var/lib/z2m-test:/var/lib/z2m-test \
-v /dev:/dev \
-v /run/udev:/run/udev:ro \
cicoub13/gladys:dev-zigbee2mqtt
1 « J'aime »
Les fichiers de configuration doivent être écrits par Gladys sur ton host quelque part. J’ai décidé d’utiliser SQLITE_FILE_PATH comme le dossier où écrire ces fichiers. Mais sans penser au cas où tu montes ce dossier depuis un autre path sur ton host.
Mais peut-être qu’il faudrait utiliser une autre variable pour cela ? Genre HOST_PATH_Z2M_FILES ?
La on arrive dans l’exotique, en standard c’est /var/lib/gladysassistant
On gérera pas tout les cas et on pourra pas rajouter une variable aux instances de production
1 « J'aime »
Je ne suis pas d’accord, toutes les images que j’ai utilisé jusqu’à maintenant te permette d’utiliser un chemin de persistance différent de chemin officiel.
Le réel problème qu’on a ici c’est de devoir spécifier plusieurs chemin si on utilise un chemin alternatif.
A-t-on vraiment besoin de spécifier un chemin pour la base données, ne peut on pas tout simplement mettre tous les fichiers au sein du conteneur dans un même dossier, ici surement /var/lib/gladysassistant donc fixer la valeur du SQLITE_FILE_PATH (et donc de le supprimer de la config et ensuite simplement demander à l’utilisateur de remplir la valeur PERSISTANCE_FOLDER (par exemple) qui ferait un mapping entre le dossier du conteneur et l’hote ?
La on est dans un cas ou si on veut tester plusieurs images de gladys on doit modifier tous les chemins de la config, le SQLITE_FILE_PATH puis le dossier dans le conteneur et le dossier de mapping sur l’hôte.
Effectivement tout fonctionne bien maintenant, c’est vrai que comme mon message l’indique d’au dessus on soit obligé de changer trois valeurs pour faire ça, mais tous les problèmes sont résolus.
Les deux types d’appareils aquara que j’ai fonctionnent bien, le chemin des fichiers est bien modifié comme il faut et la remontée des infos se fait bien sur le dashboard, bravo pour le taff à tout ceux qui ont bossé sur cette intégration.
Relis moi, j’ai pas dit que techniquement c’était pas possible. J’ai juste dit qu’on ne peut pas exploser toutes les instances de gladys en production. Car faire ce changement ça pète tout.
Exact cas particulier, pas en production. La commande de @cicoub13 marche parfaitement car tous les paths correspondent.
Bref c’est de l’héritage.
1 « J'aime »
Pourquoi ne pas simplement faire comme l’exposition des ports avec Docker ?
Par exemple, par défaut une application se lance sur le port 3456, mais tu veux exposer le port 80 publiquement, alors tu utilises l’option -p 80:3456.
Pour moi il faut faire pareil dans Gladys : tout est stocké dans le conteneur par défaut dans /var/lib/gladysassistant et la modification du chemin passe par la modification du chemin du conteneur : -v /data/exemple/Gladys:/var/lib/gladysassistant.
Ça me semble plus simple faire et à comprendre !
1 « J'aime »
Bah c’est le cas pour Gladys, le problème n’est pas là.
Il faudrai pourvoir depuis le conteneur récupérer le bind (-v) pour le communiquer aux autres conteneurs. Si on gère ça ça résoud tout.
Objectif: récupérer depuis le conteneur le bind sur /var/lib/gladysassistant