Désolé j’ai pas été réactif, je mangeais 
@Romuald_Pochet tu serais dispo pour un petit call développeur dans 7 minutes aujourd’hui ? 
Je vois que tu as été actif sur le sujet Z-Wave aujourd’hui, comme ça on peut parler avec toi de ce sujet !
Je suis deg’ je vous ai loupé…
Inter en urgence toute l’aprem au boulot …
Vous pourrez nous faire un topo si pas trop contraignant ?
Et surtout bon anniversaire @pierre-gilles et @AlexTrovato !!
2 « J'aime »
Un gâteau et une bouteille chacun pas de favoritisme.
Bon anniversaire à tous les 2.
2 « J'aime »
Dommage ! 
Je te fais un recap !
Lixee TIC et affichage des appareils complexe dans l’UI
-
On a parlé de l’affichage des appareils complexe type Lixee TIC qui actuellement sont peu lisible dans Gladys car ils ont plein de fonctionnalités du même type. Pour ces appareils on va probablement afficher le feature name sur le dashboard et les scènes. Tout le travail étant de savoir comment détecter les appareils complexe/pas complexe. @AlexTrovato va regarder pour faire un POC, et il faudra tester le avant/après sur des installations complète. L’idée étant de faire vraiment un fonctionnement hybride, et pas de généraliser ce comportement qui est vraiment propre à des appareils qui sortent de l’ordinaire.
-
On a parlé des soucis de performance quand il y a beaucoup d’évènements, ce souci étant dû à la nature synchrone des EventEmitter Node.js. @AlexTrovato va regarder pour que l’émission des évènements soit fait en mode « à faire plus tard » (en gros), pour que Node.js ne se bloque pas.
Une fois ces deux points validés, pour moi la PR Lixee TIC pourra être mergée.
Migration Z-WaveJS
@Romuald_Pochet nous a fait une démo vraiment très prometteuse de ce qu’il a fait en passant par ZwaveJS2Mqtt, qui tourne chez lui en prod et ça a vraiment l’air sympa !
Au niveau fonctionnel, ça a l’air vraiment bien, maintenant avant de pouvoir merger en prod il y a 3 choses à faire:
- Travail sur l’UI pour que le fonctionnement de bout en bout soit nickel: création des containers, etc…
- Finir tout ce qui est test unitaire, Cypress, etc… pour que le code soit bien propre et testé
- Se renseigner sur combien de personnes utilisent l’intégration Open-ZWave actuelle en production, car en gros cette nouvelle intégration sera « breaking », pour quelqu’un qui a une installation Z-Wave existante, si on pousse ça comme ça, son installation est cassée. Je vais regarder de mon côté pour avoir plus de telemetry sur ce point pour qu’on puisse suivre l’usage réel de chaque intégration. Ensuite, l’idée c’est de voir en fonction de qui utilise quel plan de migration on met en place.
Apparemment @Romuald_Pochet a du temps début août ou il pourra avancer sur ça, comme on est quasi tous en vacances en août on pourra faire un point à la rentrée à mon avis
Sinon compte tenu du fait que l’intégration Open-Zwave actuelle nous bloque sur pas mal de sujets: mise à jour de Node 14 à Node 16, build très lent sur le CI à cause de ça, mise à jour de certaines dépendance impossible à cause de Node 14, etc… On a globalement tous dit que là l’objectif était de faire une 1ère version « simple mais stable », toujours dans la philosophie de la v4: on fait bien les choses mais on part pas dans tous les sens niveau fonctionnalités.
J’oublie des sujets ?
1 « J'aime »
Pour info @Romuald_Pochet @AlexTrovato @VonOx , j’ai avancé sur le sujet de la mesure de l’usage des intégrations.
Chaque service doit désormais exposer une fonction isUsed (facultative pour l’instant), par exemple dans le cas du Z-Wave :
J’ai fais le service Zigbee2mqtt aussi, mais pas les autres services pour l’instant.
L’idée c’est de pousser ça asap pour avoir plus d’informations sur l’usage du service Z-Wave, et ensuite on avisera sur ce qu’on fait
Est ce que cela représentera vraiment la réalité sur l’utilisation des services ? Par exemple j’utilise z-wave mais le service est désactivé dans Gladys. Je gère tous mes périphériques z-wave par NodeRed
Oui, tes appareils ne seront pas comptabilisé comme service Z-Wave mais comme service MQTT.
C’est justement ce qu’on cherche ici, savoir à quel point le service Open-Zwave actuel est utilisé, ou non, pour pouvoir décider de la méthode de migration que l’on va adopter.
Ok mais ca va pas être simple de savoir que le périphérique en mqtt est en faite en z-wave
Ce n’est pas le but de la fonctionnalité
Ok je viens de comprendre (le lundi c’est dur) en lisant ton récap le but
1 « J'aime »
@AlexTrovato @VonOx Pour info j’ai fais un test de rendre la fonction .emit de notre EventEmitter global asynchrone !
Je me suis inspiré du code de cette lib qui est assez connue (mais bon, trop complète pour nous, on a pas besoin de tout ça):
ça donne ça niveau code, c’est vraiment tout simple:
En gros, à chaque fois qu’on emit un event, l’event ne sera publié de façon synchrone « qu’après », on laisse la main à Node.js de faire ce qu’il veut entre l’appel de la fonction et l’emit synchrone.
Dans le cas d’appareils qui engendrerait des centaines d’emit, (qui eux même généreraient des centaines d’emit, car on vérifie plein de choses: les scènes, websockets vers le front, etc…), chaque event n’est pas consommé de façon synchrone, mais de façon asynchrone quand Node.js peut.
ça devrait résoudre les soucis avec les appareils comme le Linxee TIC
Vous en pensez quoi ?
Edit: @VonOx vu que c’est un changement de quelques lignes, tu pourrais remplacer le fichier dans ta prod et voir l’effet que ça a, voir si ça résout bien le soucis ?
C’est fait, je te fait un feedback demain
1 « J'aime »
J’ai l’impression que c’est un peu « laggy »
Je vais remettre du log pour avoir les temps d’exécution
ah, donc ça résout pas aussi bien le problème que le setImmediate?
Pour info, par rapport à notre discussion sur les utilisateurs actuels de l’intégration open-zwave:
https://community.gladysassistant.com/t/v4-integration-z-wave/6057/99?u=pierre-gilles
@pierre-gilles je penses qu’on est bon.
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:power:active_power: 0.01ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:power:active_power_max: 0.008ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:power:active_power_ph_b: 0.008ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:power:apparent_power: 0.008ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:current:available_power: 0.008ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:voltage:average_rms_voltage_meas_period: 0.008ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:index:current_tier1_summ_delivered: 0.023ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:index:current_tier2_summ_delivered: 0.008ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:current:power_threshold: 0.015ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:binary:relais: 0.008ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:current:rms_current: 0.009ms
EventEmit zigbee2mqtt:Lixee TIC:energy-sensor:voltage:rms_voltage: 0.008ms
@VonOx Et niveau expérience, c’est fluide ou ça lag ? Le plus important c’est qu’en tant qu’utilisateur ça soit parfaitement fluide
Oui c’est good, j’avais trop d’onglet ouvert la dernière fois 
1 « J'aime »