Oui ça sera violent mais toutes les 60 secondes.
Faudrait qu’on trouve le moyen d’avertir l’utilisateur si le device est détecté. Car typiquement y’a plein d’infos avec ce device mais qui n’ont pas d’intérêt domotique, exemple sur le screen de @Albenss , l’'expose ISOUSC ne change jamais de valeur.
Ou peut être la solution est d’identifier ces features et les « bannir »
Effectivement !
Hello,
De mon côté j’ai demandé un passage en mode « Standard » de mon linky auprès d’EDF (il suffit de faire la demande via les formulaires de demandes de modification).
Les données remontent bien mieux maintenant, j’ai encore un peu de réglage je pense mais c’est déjà mieux 
@VonOx J’ai vu que tu m’avais demandé une review sur la PR pour gérer le Lixee TIC, cool si tu as pu avancer 
Est-ce que tu peux m’en dire plus sur la PR ici ?
Oui
Non car j’ai paramétré le device côté z2m ( j’anticipe c’est pas possible de le faire côté gladys )
Non malheureusement, je fais un build de suite pour faire tester.
Ok, donc il y a 2 gros points à résoudre avant de pouvoir passer en prod.
top
Le poll est à 60 secondes par défaut côté z2m.
De mon côté j’avais appairé mon device avec un ancien firmware et sur zigbee2mqtt dev pour commencer la PR côté gladys.
Le standard ne pose pas de problème particulier.
La seul chose que doit faire l’utilisateur c’est whitelister ce qu’il veut de son compteur ( ça dépend de la météo et de l’âge du capitaine)
Je vois vraiment pas ce que l’on peut faire.
D’un autre côté d’autre solution avale ces données sans problème ( ha / sqlite) donc y’a peut être de quoi creuser indépendamment de cette PR.
Donc en gros, si je comprend bien, l’intégration Z2M avale un gros volume de donnée toutes les 60 secondes ? (en pic)
Tu as des chiffres sur le volume avalé par défaut ?
L’intégration Z2M peut aussi faire du throttling vu que c’est un gros pic, et distribuer les évènements de manière plus distribué dans le temps. On reçoit tout via MQTT, rien ne nous force à tout traiter dans la nano-seconde.
Au lieu d’envoyer 1000 events (je sais pas) en 1 bloc, on peut rajouter un peu d’attente entre chaque event, pour laisser à Node.js le temps de respirer.
Node.js il faut pas oublier que c’est une techno single-threaded qui fonctionne autour d’une « event-loop » ( Node.js — The Node.js Event Loop, Timers, and process.nextTick()), et cette event-loop peut-être bloquée par des opérations synchrones qui prennent trop de temps. Dans l’idéal, cette event loop doit tourner en permanence et n’être jamais bloquée.
A voir si dans l’intégration Z2M (ou dans le core) il n’y a pas un bloc synchrone un peu trop gros qui entraine des blocages de l’event loop et qui font côté utilisateur une sensation de blocage.
Pour débugger ce genre de soucis, il y a des libs qui existent (à utiliser uniquement en local pour tester) :
A la louche ( j’ai pas compté )
Le device expose par défaut ceci:
ADCO, BASE, OPTARIF, ISOUSC, HCHC, HCHP, BBRHCJW, BBRHPJW, BBRHCJR, BBRHPJR, IINST, IINST2, IINST3, IMAX, IMAX2, IMAX3, PMAX, PAPP, PTEC, DEMAIN, HHPHC, PPOT, PEJP, ADPS, ADIR1, ADIR2, ADIR3, LTARF, NTARF, VTIC, DATE, EASF07, EASF08, EASF09, EASF10, EASD01, EASD02, EASD03, EASD04, EAIT, ERQ1, ERQ2, ERQ3, ERQ4, URMS1, URMS2, URMS3, STGE, PCOUP, SINSTI, SMAXIN, SMAXIN-1, CCASN, CCASN-1, CCAIN, CCAIN-1, UMOY1, UMOY2, UMOY3, SINSTS2, SINSTS3, SMAXN2, SMAXN3, SMAXN-1, SMAXN2-1, SMAXN3-1, MSG1, MSG2, PRM, DPM1, FPM1, DPM2, FPM2, DPM3, FPM3, RELAIS, NJOURF, NJOURF+1, PJOURF+1, PPOINTE1, linkquality
80 features
En réglant son type de contrat il en enlève une bonne partie ( il y’a maintenant un mode auto )
Plus s’il y’a trop d’expose inutile on peut whitlister
Ce qui donne chez moi 7 features
Ceux qui sont motivé pour tester, j’ai build une image de test
vonox/gladys:lixee
Ok !
Je veux bien que tu regarde pour le coup de l’event loop bloqué du coup Je veux bien t’aider si tu as besoin
OK tu veux que je me remette dans ma conf initiale ? L’infra va fumer un peu.
Faut juste que tu me dise ou je dois poser la fonction blocked() , je pensais que c’était un wrapper mais non.
Tu mets le blocked() n’importe où dans le code (vraiment n’importe où), du moment que c’est exécuté une fois ça écoutera en permanence et ça te dira si jamais l’event loop est blocked, et surtout où c’est blocked!
Du coup par exemple le mettre ici au démarrage de Gladys c’est pas déconnant:
( A retirer ensuite bien-sûr, c’est juste pour le debug là)
J’ai reçu le module lixee mais je n’arrive pas a le voir encore dans mon réseau. J’ai le compteur à environs 20 m de ma box.
J’ai essayé de rapprocher une lampe Hue mais pour l’instant c’est pareil.
Dès que j’ai trouvé, je vous tiens au courant.
ça spam pas mal au démarrage, je n’ai pas encore remis en conf par défaut côté z2m
Mais j’ai ça qui revient régulièrement: ( toutes les 30/40 secondes )
Blocked for 36.14090771484375ms, operation started here: [
' at Socket.connect (net.js:970:7)',
' at Object.connect (net.js:201:17)',
' at Object.streamBuilder (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/connect/tcp.js:18:14)',
' at MqttClient.wrapper [as streamBuilder] (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/connect/index.js:154:36)',
' at MqttClient._setupStream (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/client.js:298:22)',
' at new MqttClient (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/client.js:277:8)',
' at Object.connect (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/connect/index.js:156:16)',
' at Zigbee2mqttManager.connect (/src/server/services/zigbee2mqtt/lib/connect.js:16:40)',
' at Zigbee2mqttManager.init (/src/server/services/zigbee2mqtt/lib/init.js:88:18)',
' at async Object.start (/src/server/services/zigbee2mqtt/index.js:17:5)',
' at async Service.start (/src/server/lib/service/service.start.js:33:7)'
]
ça concorde avec le publish d’un device z2m de nouvelles datas
Donc à mon avis , un device verbeux fout tout en carrafe
Super intéressant, cool que tu ai mis cette lib pour tester
Ok, dans ce cas il faudrait étudier le code de l’intégration Zigbee2mqtt dans Gladys, et faire du testing de publish de valeur sur des devices super verbeux, et voir combien de temps d’exécution synchrone on observe (ça peut se faire dans les unit test ça), pour si il le faut pouvoir découper certaines opérations en plus petites opérations pour laisser le reste du process souffler et avancer dans l’event loop
Tu pense pouvoir regarder ou tu aurais besoin d’aide là dessus ?
pas sur d’avoir compris ce que tu voulais faire, tu veux que je flood un device z2 ? . Sachant que je ne peux pas créer de fake device ( à la main en db peut être), j’aimerai ne pas pourrir ma prod.
Non juste tu vas dans les unit-test (sur ton ordi, pas en prod)
Tu créé un test assez similaire au cas du Lixee TIC ( de toute façon pour la PR j’imagine t’as rajouté des tests ? )
Et tu vois ce qui est « lent » et ce qui bloque le code de façon synchrone
L’idée ensuite c’est de voir si l’intégration Z2M pourrait être adaptée pour être moins « brutale »
En plus pour le coup c’est un mini chantier qui sera bénéfique à toute l’intégration Z2M