Oui, je vais changer le niveau de log.
Pourquoi tu fais 400 requêtes par minute ? Tu as des centaines d’appareil ?
Dans le range c’est stylé effectivement! 
Je pense savoir d’où ça vient, en fait à chaque fois qu’une nouvelle valeur de capteur est publiée, Gladys doit vérifier qu’aucunes scènes ne doit être déclenchée.
Actuellement, ce qui est fait, c’est qu’à chaque valeur de capteur reçue, Gladys parcourt chaque scène existante et vérifie que la scène valide/ou pas la condition. C’est un banal forEach synchrone qui est donc bloquant.
En terme de complexité, c’est du O(n), plus il y a de scènes à parcourir, plus c’est long. Surtout dans ton cas ou tu as 400 req/minutes (6.6req/sec), ça fait beaucoup de parcours de boucle 
Par curiosité tu as combien de scènes ?
J’avais cette limitation en tête, et j’avais créé une issue github pour fixer ça: Each Node.js event should trigger a O(1) function, not O(n) · Issue #803 · GladysAssistant/Gladys · GitHub
En gros l’idée ce serait de trouver un moyen de stocker différemment les scènes en RAM, dans un format où on serait capable de vérifier qu’une scène est valide en un simple 0(1), au moins pour les events de type « device new state »
J’utilise le réseau Zigbee pour faire de l’ambilight avec mes lampes, et du coup ça envoie beaucoup de requête 
J’avais même réussi à faire crash mon réseau Zigbee à force.
Du coup, j’ai diminué le nombre de requêtes, mais Gladys à toujours du mal.
Je n’ai actuellement q’une seule scène qui est un déclenchement programmé.
Je me suis demandé si cela ne venais pas du fait que Gladys enregistre chaque nouvelle valeur en base ?
Tu es sur un SSD ou une carte SD ?
Effectivement Gladys enregistre en base les valeurs et si tu es sur une carte SD ca peut devenir le facteur limitant
De manière générale je recommande vraiment les SSD pour une installation qui tiennent sur le long terme
L’OS du raspberry tourne sur une carte SD, mais la data de Gladys est save sur un disque dur branché en USB3 sur le rasp.
Un disque dur a plateau ? A voir la vitesse du disque, mais effectivement si tu essaie d’écrire continuellement à 6 req/secondes + de lire, forcément les requêtes sont mise en attente et tu vas voir des ralentissements côté Gladys
Tu as setup comment ton ambilight?
Effectivement je pense pas que ce soit une bonne idée d’enregistrer de la data à chaque changement d’état, en plus de ça ta DB va devenir énorme !
Oui les bons vieux disques durs 
J’ai un serveur Express qui émule l’api de Philips Hue, et qui après envoie du mqtt au Zigbee. Pour transmettre l’écran j’utilise Hyperion NG.
Je pense aussi, admettons, je laisse tourner 1h, je n’imagine même pas le nombre d’enregistrements effectué 
Et du coup gladys récupère les évènements parce que Zigbee2mqtt renvoie les retours de valeurs à Gladys ?
Oui, il me semble que Gladys écoute les devices enregistrée sur l’intégration Zigbee2mqtt (appareil Hue play par exemple).
De ce fait toutes valeurs reçues par Zigbee et qui sont enregistrée sur Gladys sont ensuite reçu par Gladys.
Le chemin étant :
Hypérion → Api Philips (Express) → Zigbee2Mqtt → Périphérique && Gladys
Ah je vois!
Déjà tu es sûr que c’est best practice de tabasser autant l’API Philips Hue? (niveau durée de vie des ampoules, réseau Zigbee et cie?)
Je ne connais pas bien Zigbee2mqtt, je ne sais pas si il est possible de désactiver côté Zigbee2mqtt l’envoie des évènements à Gladys, je laisse @cicoub13 te répondre là dessus.
Hum…en soit, je n’ai fais que recrée ce que fait Philips à travers leurs logiciel Hue Sync qui permet de caster les lumières de ton écran sur des lampes. A voir sur la durée effectivement.
Je pense qu’il faudrait plutôt rajouter un bouton permettant de désactiver l’enregistrement des anciennes valeurs.
Ou alors oui désactiver l’envoie des évènements, mais je pense qu’il faut pouvoir quand même discuter avec Zigbee2mqtt dans les 2 sens.
On a déjà dans Gladys la possibilité de ne pas enregistrer l’historique d’un capteur (c’est pas dans l’UI du service Zigbee2mqtt mais c’est une fonctionnalité qui est présente dans Gladys core), mais ça ne changera rien dans ton cas, vu qu’on enregistre dans tous les cas la dernière valeur (pour pouvoir afficher la dernière valeur sur le dashboard tout simplement)
Si on laisse la possibilité d’arrêter d’écrire absolument toutes les valeurs, quand tu afficheras ton dashboard la valeur affichée sera fausse.
Effectivement, il y aura toujours une partie du problème, mais au moins la BDD ne sera pas surchargé non ?
Effectivement !
Il faudrait rajouter dans l’UI du service Zigbee2mqtt un toggle “enregistrer l’historique des valeurs”, et qui correspond à l’attribue “keep_history” de la table “device_feature”.
Cf code: Gladys/device_feature.js at master · GladysAssistant/Gladys · GitHub
Tu veux prendre le développement @JeuFore ? 
@cicoub13 peut t’aider à comprendre la structure de l’intégration Zigbee2mqtt si tu as besoin d’aide, c’est lui qui a le plus bossé dessus
@cicoub13 J’ai eu une coupure de courant
Au restart plus de z2m / mqtt
2021-06-22T14:20:11+0200 <warn> service.start.js:44 (Service.start) Unable to start service zigbee2mqtt Error: (HTTP code 301) unexpected -
at /src/server/node_modules/docker-modem/lib/modem.js:301:17
at getCause (/src/server/node_modules/docker-modem/lib/modem.js:331:7)
at Modem.buildPayload (/src/server/node_modules/docker-modem/lib/modem.js:300:5)
at IncomingMessage.<anonymous> (/src/server/node_modules/docker-modem/lib/modem.js:275:14)
at IncomingMessage.emit (events.js:388:22)
at endReadableNT (internal/streams/readable.js:1336:12)
at processTicksAndRejections (internal/process/task_queues.js:82:21) {
reason: undefined,
statusCode: 301,
json: <Buffer >
}
2021-06-22T14:20:11+0200 <error> index.js:20 (process.<anonymous>) uncaughtException catched: uncaughtException
2021-06-22T14:20:11+0200 <error> index.js:21 (process.<anonymous>) Error: getaddrinfo ENOTFOUND containers
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:67:26) {
errno: -3008,
code: 'ENOTFOUND',
syscall: 'getaddrinfo',
hostname: 'containers'
}
Tout est ok niveau docker
Home Assistant n’as aucun soucis de connection à ce même server mqtt.
Je comprends pas pourquoi je me retrouve dans cet état bancale.
Je m’en suis rendu compte car la box “Temperature in room” n’avais pas de données récentes
Impossible de configurer le service ( le dongle est configuré )
Beaucoup d’infos mais si tu as besoin d’autre chose hésite pas
EDIT: J’ai du restart mon serveur ( physique ) , ça a résolu mon soucis , c’est probablement la lib dockerode qui a fait n’importe quoi
Je vais sûrement pouvoir me libérer d’ici quelques jours, donc pourquoi pas regarder cela de plus près
Hello,
Du coup, j’ai commencé à regarder pour la fonctionnalité de keep_history sur le Zigbee2mqtt.
Je test ce week-end si cela marche en condition réel, car je ne suis pas chez moi actuellement.
3 « J'aime »
Hello. La température des ampoules est maintenant gérée (avec un beau slider).
Est-ce que tu peux mettre à jour l’image cicoub13/gladys:dev-zigbee2mqtt et tester à nouveau (spoiler, j’ai testé et ça marche super bien) ?
Ça devrait arriver vite dans la version disponible pour tout le monde 
3 « J'aime »
Hello,
Okay, je test l’image ce week-end. Par contre, petite question, personne n’a de problèmes pour créer les containers zigbee via Gladys 
?