Non , certaines sont inactives
Ok, après active ou non, chaque scène sera « parcourue » pour vérifier si elle est active ou pas, donc ça impacte quand même
Je serais curieux de faire un petit test chez toi, afin de laisser à Gladys le temps de « respirer » entre chaque event, remplace la ligne:
this.gladys.event.emit(EVENTS.DEVICE.NEW_STATE, newState);
Par:
setImmediate(() => this.gladys.event.emit(EVENTS.DEVICE.NEW_STATE, newState));
C’est juste un test (c’est pas ce qu’on fera en prod), mais l’idée c’est qu’au lieu de gérer un gros bloc synchrone en une fois, on ajoute l’émission de l’event à la fin de l’event loop pour être traitée « plus tard », et laisser le temps à Gladys de traiter d’autres demandes potentiellement prioritaire (comme une requête du front)
Radical
readValue zigbee2mqtt:Lixee TIC:energy-sensor:current:power_threshold: 0.016ms
gladysEventEmit: 0.143ms
readValue zigbee2mqtt:Lixee TIC:energy-sensor:binary:relais: 0.017ms
gladysEventEmit: 0.142ms
readValue zigbee2mqtt:Lixee TIC:energy-sensor:current:rms_current: 0.014ms
gladysEventEmit: 0.141ms
readValue zigbee2mqtt:Lixee TIC:energy-sensor:voltage:rms_voltage: 0.017ms
gladysEventEmit: 0.139ms
Ca c’était sur, mais est-ce que ça améliore l’expérience sur Gladys ou est-ce que c’est toujours ultra lent ? 
Oui clairement, je ne ressens pas de lenteurs ou en tout cas c’est beaucoup mieux
Ok cool ! Maintenant 2 pistes pour fixer ça sur Gladys, faut faire des tests et voir:
- Soit on rajoute ce genre de callback (setImmediate) carrément dans le code du listener de l’event (côté core), si ça marche ça serait le mieux parce que du coup ça améliorerait les performances pour toutes les intégrations
- Soit si ça suffit pas (si par exemple c’est le fait d’exécuter de .emit en lui même qui est lent), alors là il faudra faire le changement dans le code de l’intégration Z2M, un peu comme la ligne que je t’ai mise ici
Le 3ème point, c’est que le check des triggers de scènes peut aussi être optimisé à mon avis, j’avais créé une issue dans le passé mais comme personne n’était gêné j’avais pas dédié de temps à ça, après là maintenant ça peut valoir le coup d’investir un peu de temps dessus
Ouai je vois l’idée vu qu’il y a plein d’évent en même temps ça fait autant de check de scène.
Dis moi moi si tu veux que je test dans le core vu que mon instance de prod est hybride 
2 « J'aime »
Hello !
Je m’interroge sur cette integration, juste pour ma curiosité, quel genre de scene cette intégration permettra ?
Y aura til des graph un peu plus spécifiques a ces données ? Ou cest juste des données envoyées en mode hey maintenant je vais me monter un grafana a côté et je prend les données dans gladys.
Je m’interroge plus précisément pour ma futur utilisation ^^
Typiquement j’ai une scène qui m’alerte sur la puissance. Si j’approche du seuil de mon abonnement ( j’ai le plus petit à 6kva). Ça évite une coupure.
1 « J'aime »
Ah ok et dans ce cas tu coupes un appareil pour eviter que ton fournisseurs te passe a un abonnement supérieure avec leurs régulation a la noix ?
Que fais tu exactement
J’éteins un appareil, sinon ça disjoncte.
Et cela t’arrivait souvent ? ^^’
Parce que je me dis qui si cetait le cas alors c’est que ton abonnement est sous dimensionner par rapport a ton besoin non?
Je comprend pas l’intérêt (si ce n’est financier) de se dire mince j’éteins la tv sinon tout va couper ^^.
Parce que sa me ferais chier de me dire merde je peut pas allumer ma plaque parce que sinon tout va coupé ^^.
Je pense que quelque chose m’échappe ^^
On parle pas d’une télévision mais de gros poste de consommation.
Ça nous arrive surtout en hiver et avec des gamins.
T’enchaine lessive / sèche linge / four + tous les a côté. T’es pas loin. Suffit de rajouter un petit chauffage électrique d’appoint dans la salle de bain et boom c’est tout noir.
Pour tout te dire moi j’y penses, pas ma femme.
L’été clairement ça sert à rien, c’est l’hiver que ça arrive régulièrement.
L’abonnement supérieur n’est pas nécessaire quand le besoin est occasionnel.
1 « J'aime »
Ah je me disais bien ne pas comprendre ^^’
Ok ca me semble plus clair maintenant .!
Je vais tres certainement avoir le soucis cet hiver xD
Merci de l’information et hate de voir ce quon pourrait faire
Salut à tous !
Je relance le sujet pour savoir où on est.
Par rapport à cette PR, quand on avait fait un call avant les vacances on s’était dit qu’il y avait 2 soucis à corriger avant le merge:
- Les soucis de performance, qui ont été corrigés via la PR Make event emitting async to avoid blocking the event-loop by Pierre-Gilles · Pull Request #1569 · GladysAssistant/Gladys · GitHub
- Les soucis d’affichage de ce périphérique « complexe ». On avait parlé de faire un affichage hybride (cf compte rendu de la réunion: Appel développeur les prochaines semaines? - #35 par pierre-gilles ) @AlexTrovato est-ce que tu avais pu commencer un POC au final ?
Oui il y’a un POC mais pas de PR
La balle est chez moi, j’ai oublié de répondre à alex
2 « J'aime »
Pour info, on avance sur ce sujet:
Discussion connexe, j’avance sur l’intégration via l’API Enedis, c’est une intégration différente de celle proposées par @VonOx, complémentaire.
Ce sera une intégration moins « live » que celle de @VonOx, mais plus pour analyser de la donnée historique de consommation, et pouvoir suivre en direct son budget énergie, un sujet d’actualité 
La réflexion est ici et je suis preneur de retour:
ça me parait vraiment bien, une fois de plus un super travail de Pierre-Gille !
Je ne vois rien à redire, j’ai hâte que cela soit dispo. dans Gladys, une date ?