Bonjour,
J’ai commencé à corriger cette issue Philips Hue - Issue with state · Issue #1690 · GladysAssistant/Gladys · GitHub mais je n’ai pas de matériel Philips pour tester (bridge vendu).
Je cherche des volontaires pour tester la remontée de couleur/intensité des ampoules avec l’image cicoub13/gladys:fix-philips-hue-poll
Voici un tuto pour lancer une image de test Tutoriel: Lancer une image Docker de test
@Kevin je crois que tu avais le problème
Effectivement, j’ai le souci. Je pars à 150 km de chez moi dans quelques minutes et reviens au soir / nuit.
J’essaie de regarder à ça demain après le boulot, ça me permettra de tester une image de test pour t’aider 
En tout cas, un grand merci à toi de t’intéresser au problème
Oui, pas d’urgence 
L’image se lance correctement.
Par contre, avant de tout casser, petite question :
Est-ce normal de devoir recréer un compte local au lancement du container ? Etant donné qu’il semble utiliser la DB de prod avec la ligne suivante : -e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
Je me trompe ? 
Le SQLITE_FILE_PATH représente le path interne (dans le docker)
C’est plutôt la ligne -v /var/lib/gladysassistant_zwave_test:/var/lib/gladysassistant \
Est-ce que tu as mis -v /var/lib/gladysassistant:/var/lib/gladysassistant \ ? Dans ce cas-là, tu utilises la base de production 
il vaut mieux la sauvegarger avant.
Si tu as mis quelque chose comme -v /var/lib/gladysassistant_philips_test:/var/lib/gladysassistant \, oui, c’est normal de partir d’une base vide (et donc de créer un compte).
D’accord, ça fait partie du chemin interne dans le container, aucun lien avec mon fichier DB.
J’ai suivi le tuto du patron et je suis parti là-dessus :
docker run -d \
--log-driver json-file \
--log-opt max-size=10m \
--cgroupns=host \
--restart=always \
--privileged \
--network=host \
--name gladys-philips-hue-test \
-e NODE_ENV=production \
-e SERVER_PORT=8001 \
-e TZ=Europe/Brussels \
-e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /var/lib/gladysassistant_philips_hue_test:/var/lib/gladysassistant \
-v /dev:/dev \
-v /run/udev:/run/udev:ro \
cicoub13/gladys:fix-philips-hue-poll
Alors je continue Merci pour cette précision.
Petit retour :
On / Off
Gladys récupère la bonne information quand la lampe est allumée. Mais ne détecte pas si elle est éteinte.
Gladys peut allumer et éteindre la lampe.
Couleur
Tout semble fonctionner. Gladys peut changer de couleur et récupère la couleur modifiée via l’application Philips Hue.
Intensité
Gladys peut modifier l’intensité.
L’état de l’intensité n’est pas récupéré dans Gladys si l’intensité est modifiée via l’application Philips Hue.
Chaleur
Rien ne semble fonctionner. Gladys ne récupère aucune information et ne semble pas être en mesure de contrôler quoi que ce soit.
Merci pour les tests 
Pour information, le polling a lieu toutes les minutes (1 fois par minute).
Ce qui veut dire que Gladys demande à tous les appareils Philips leur état et met à jour les informations à cette fréquence.
Est-ce que tu as attendu ce temps-là pendant tes tests ?
@pierre-gilles Est-ce qu’on peut imaginer réduire ce temps de polling ? Je vais vérifier ce qui est recommendé par Philips mais je ne sais pas ce qui est fait pour les autres intégrations.
Home Assistant utilise une fréquence de polling de 5 secondes
Oui oui, j’étais au courant du polling d’une minute.
Pour cette raison que j’utilisais la couleur comme point de repère vu que j’ai constaté que cette partie fonctionnait à 100%.
Si la couleur change d’état 2x et qu’il ne se passe rien pour l’intensité, je présume qu’aucun miracle ne se produira 
OK, je vais regarder
C’est possible de changer oui ! Après 5 secondes c’est un peu agressif je trouve, on peut passer à 15/30 secondes déjà ?