Lazer

Ah OK, je n'ai pas lu ton code, mais tu n'as peut être pas intégré de routine de détection du token expiré, puis demande d'un nouveau ? En redémarrant ton QA, c'est à ce moment là que le token aurait pu être régénéré. La mise à jour de mon QA date de juillet 2023. En mars 2024, il a certainement renouvelé tout seul le token, en tout cas je n'ai eu aucun dysfonctionnement, je ne m'en suis pas rendu compte. Et donc vu la validité de 1 an, il devrait être renouvelé automatiquement en mars 2025. Il faudrait que je me mette une alarme pour surveiller le log ce jour là.

Hum.... comment tu t'es rendu compte du changement de token ? Je viens de regarder les logs de mon QA, tout tourne, et dans l'historique (quelques heures seulement) pas de trace de changement de token. Après peut être que mon token a été généré après le tient et que je vais avoir le même problème dans les jours qui viennent... EDIT : bon bah j'ai la réponse, j'ai décodé le token en base64 et il expire le 03/03/2025... ça me laisse de la marge. N'empêche, ça n'explique pas pourquoi le tiens n'a pas été rafraichis automatiquement par le QA. Mais dis-moi... tu utilises ton QA, pas le miens ?

Bienvenue sur le forum

ça m'inquiète cette histoire, car ça veut dire qu'on ne sait plus compiler les firmwares... Il faut que j'essaye de trouver du temps pour creuser le sujet, mais je ne garantie pas que ça soit tout de suite...

ça c'est génial ça casse tout l'intérêt du module Si c'est juste pour faire une télécommande murale à 4 boutons, c'est pas terrible, surtout que niveau WAF les interrupteurs multiples c'est assez catastrophique je trouve.... souvenir ému de 2 séjours en gite et hôtel de luxe tous domotisés, où tu cherches 10 minutes avant de te coucher comment éteindre toutes les lumières.... sans en rallumer d'autre en même temps ! Pour trouver un intérêt à ce module, il faut un cas de figure où on a besoin de récupérer 4 contacts distincts, mais avec une tension commune (soit le 230V pour le modèle AC, soit la masse pour le modèle DC)... là je ne vois pas. @Sowliny j'ai isolé ton message dans un topic dédié à ce module (enfin, les 2 versions AC et DC du module)

Apparemment c'est la version ESPHome de juin 2024 qui a tout pété : https://github.com/geoffdavis/esphome-mitsubishiheatpump/issues/152 Ils disent que la compilation crashe quand on utilise UART2, ce qui le cas dans notre montage... Il y a des solutions qui sont données, mais je n'ai ni le courage ni le temps de tester tout ça maintenant.... je me demande si en attendant, le mieux n'est pas de trouver un moyen de downgrader à la version précédente de ESPHome.

Dommage... Tu n'as pas un autre PC pour tester ? Je vois que tu es sous MacOS, peut être qu'avec Windows ou Linux le compilateur se comporte différemment ?

[Frandroid] Matter 1.4 dévoilé : la mise à jour qui pourrait tout changer pour votre maison connectée et votre voiture électrique

Effectivement, bonne remarque sur les requêtes qui s'empilent... comme dit, je n'ai plus mon code en tête, mais c'est une idée de vérification et d'optimisation potentielle. J'avais eu ce souci sur un autre QA plus récent (celui des PAC Mitsu avec ESPHome), et j'avais développé tout une gestion de file d'attente des requêtes. C'est une idée à creuser... d'autant plus qu'entre temps, il me semble que mon QA Yamaha Musiccast fait face au même problème dans certaines circonstances...

Je suis à 5 secondes, et non absolument aucune erreur. Comme je le disais sur l'autre topic, temps de réponse inférieur à la seconde, parfois 2s. Firmware D8.2.4264 apparemment, donc comme toi. De toute façon chez Enphase on ne choisi pas (plus), les mises à jour sont poussées à distance depuis leur cloud.

Ah OK... bon bah alors c'est vraiment la faute de mon code. Ce qui est étonnant alors, car les 2 autres QA du forum, qui sont complètement différents, ont le même problème.... ce qui est étonnant aussi, c'est que le problème n'apparait pas chez moi. A devenir fou....

Hum... tu veux dire que sur HC2, tu arrives à interroger l'Envoy avec un intervalle très court, tandis que ça ne fonctionne pas sur HC3 ? Dans ce cas, alors il doit y avoir un souci avec le code LUA.... j'ai pas lu ton code (déjà met la coloration syntaxique, ça sera plus avenant), et ça fait maintenant des années que j'ai codé mon QuickApp donc je n'ai plus tout ça en tête... il faudrait que je me replonge dedans pour voir de quel façon l'optimiser... un jour peut être... dans quelques mois.... sachant que je n'ai pas le problème chez moi, donc difficile à reproduire. Sinon tu peux prendre le code de mon QuickApp et faire tes tests à partir de ça, l'avantage c'est que la gestion des child devices est déjà en place.

Ah c'est dommage ça, tu aurais donc le même problème que @TitiXsi dont on a parlé également sur les topics des 2 autres QuickApps dédiés à cette passerelle Envoy... Franchement je ne sais pas quoi en penser, il y a la piste de la connexion réseau Ethernet versus Wi-Fi, mais aussi la piste de la présence, ou non, des 2 pinces de mesure de courant.... à moins que ça ne soit encore autre chose ?

Je fais pareil Mais je n'avais jamais pensé à la seconde raison...

Oui, c'est la réutilisation, et c'est mieux que le recyclage. Malheureusement c'est assez peu pratiqué, car le réflexe c'est souvent de mettre à la déchèterie.

Dommage... J'aime bien ce débat. J'ai de gros doute sur l'aspect écologique avancé par les adaptes de l'occasion. Exemple : tu as la dernière box domotique à la mode, la dernière TV, le dernier téléphone, voiture,... ou même une fringue. Cet objet est encore parfaitement fonctionne, répond à ton besoin, mais comme tu es "riche", tu te dis que ça serait quand même bien d'acheter le nouveau modèle, et de vendre l'ancien d'occasion. Chouette alors c'est écolo en plus, ça me donne bonne conscience pour consommer toujours plus de produits inutiles. A l'autre bout de la chaine, un "pauvre", qui n'a pas les moyens de se payer du neuf, va acheter ton objet d'occasion. Et jeter un autre appareil qui fonctionnait encore... et là, c'est tout le contraire de l'écologie, le discours du riche est complètement mis à mal, par le fait qu'à l'autre bout de la chaine de consommateurs, qu'il ne voit pas, il a poussé un object fonctionnel à la déchèterie (avec un peu de chance ça sera recyclé ce qui limite les dégats, avec beaucoup de chance ça sera incinéré/enfoui) Dit autrement : le marché de l'occasion, est en partie une incitation au consumérisme. Toute la question est de savoir quantifier cette partie. Si c'est, disons, 10%, alors on peut considéré que c'est acceptable (dans ce cas, les 90% achètent/revendent le produit pour un vrai besoin). Mais j'ai le sentiment c'est que carrément l'inverse, c'est 90% de changement pas pur plaisir, et 10% seulement de changement par besoin (ne répond plus au besoin, est en panne, etc) D'ailleurs, sur le "est en panne", en tourne en boucle, car pourquoi ne pas le réparer ? Voilà, ça le truc... c'est bien dommage, ce n'est pas toujours réparable bien sûr, mais ne même pas avoir tenter la réparation est bien triste.... Donc dans ces circonstances, dire que tu en achètes une autre et que c'est de la récup d'occasion, donc écolo, bah je suis désolé, mais pas du tout.

Sur la HC2, tu l'ouvres, tu vires la clé USB, et tu installes un disque SATA, et là c'est nolimit Attention à ne pas faire l'erreur de remplacer la clé USB interne par une clé USB du commerce, car là c'est le crash assuré. La clé interne est un véritable petit SSD, avec de la mémoire Flash SLC et un contrôleur intégré qui gère tout ça correctement.

Non, pour cela il faudrait interroger les données SMART, ce qui est évidemment impossible sans disposer d'un accès root au système. Par ailleurs, je ne suis même pas sûr que la mémoire flash embarqué dans ces box ne propose d'informations SMART... Dans ces cas de figure, pas trop le choix de croiser les doigts pour que tout aille bien, et si un jour le problème se présente, il faut demander au support Fibaro de faire un diagnostique (qui sera à coup sûr un retour atelier avec remplacement de la clé USB Interne.... voir de la carte mère, car je suppose que la mémoire Flash est soudée dans la HC3) Avoir une box de secours est une bonne idée dans ce cas. Il peut aussi être une bonne idée de tenter un recovery, ça va reformater complètement la mémoire interne, avec un peu de chance c'est juste une corruption logique du système de fichiers.

Ah bah alors tu as connu ça Oui, la HC3 est une chouette machine, dont on sous-exploite le potentiel. Je suis en moyenne autour des 11% de CPU la nuit (peu d'activité Z-Wave, et de déclenchement des scénarios instantanés GEA), tandis que ça oscille globalement entre 15 et 22% en cas de présence la journée, avec quelques petits pics au delà de 25%.

Au top ta mise en pratique Comme j'aime compliquer les choses, si on avait la possibilité de faire tourner des QuickApps Multi-thread, alors on pourrait faire exécuter notre code en parallèle sur 2, 3 voire 4 cœurs, maximisant ainsi l'utilisation du CPU, et cela afin de .... : Sérieusement, si on appliquait la formule sans la diviser par le nombre de cœurs, notre QA multi-threadé nous ferait croire qu'on dépasse les 100% d'utilisation (puisque 2 ou plus cœurs travaillent simultanément), ce qui est impossible. Cela dit, je ne te souhaite pas de faire un jour de la programmation multi-thread, sauf si tu aimes te faire des nœuds au cerveau. C'est ultra puissant, mais ça peut vite devenir un vrai sac de nœuds, car on ne maitrise alors plus du tout l'ordre d'exécution du code des différents threads de notre programme, avec des effets de bords pas du tout sympa comme une variable qui est lue avant d'avoir été écrite, ou bien une autre variable qui change de valeur pendant le calcul d'une formule se basant sur cette variable. On doit alors utiliser des mutex et autres joyeusetés du même genre pour gérer de tels conflits d'exécutions... et assez rapidement on conçoit des programmes qui plantent tout seuls, sans prévenir, simplement parce qu'ils se bloquent si plusieurs threads s'attendent l'un et l'autre... Sur le LUA de la HC3, Fibaro nous a proposé un truc très sympa, qui est aussi mis en oeuvre dans tous les langages modernes (JavaScript, etc), c'est l'asynchronisme, dont il y a déjà plusieurs discussions à ce sujet sur le forum. Cela permet, tout en conservant un programme mono-thread, de faire s'exécuter le code de façon non linéaire, puisqu'une fonction peut se terminer (rendre la main au système), ou bien se mettre en attente (du retour d'une requête réseau, un timeout, etc) et ainsi permettre à d'autres bouts de code de s'exécuter. C'est une sorte de multi-thread simplifié, sans l'être vraiment. Tient, d'ailleurs, on peut faire du multi-thread sans forcément avoir plusieurs cœurs, 1 seul suffit... et ça fonctionne ainsi depuis les vieux ordinateurs mono-processeur et mono-cœur. De même, on peut n'avoir que des programmes mono-thread sur un ordinateur multi-processeur et multi-cœur, comme expliqué précédemment, c'est le job du noyau du système d'exploitation que de répartir les programmes et/ou threads sur les différents cœurs/processeurs de la machine. En revanche, comme dit, pour s'exécuter sur plusieurs cœurs et/ou processeurs, un programme doit impérativement être multi-thread. Conséquence de ça, lors de l'apparition des premières machines à plusieurs processeurs (mono-thread) puis des premiers processeurs multi-thread, les applications étaient plus lentes sur la nouvelle génération de machine, bien que vendue plus cher avec l'argumentaire marketing de la performance accrue. En effet, les applications en ce temps là (euh... c'est encore le cas aujourd'hui pour certains programmes.... les QA par exemple, bon mais c'est aussi vrai sur les PC, Smartphones, etc) étant développées en mono-thread, elles étaient incapables de bénéficier de la puissance de calcul supplémentaire apportée par les processeurs/cœurs supplémentaires, l'application est littéralement bridée, ce que démontre parfaitement ton benchmark, incapable d'exploiter la puissance de calcul totale de la machine. Pire que ça, la vitesse d'exécution était réduite, car à génération équivalente, un core sur un processeur mono-core est plus performant qu'un seul core sur un processeur multi-core... cela est dû aux mécanisme interne du processeur qui "perd" du temps à faire fonctionner plusieurs cores en parallèle, ne serait-ce parce qu'en interne, dans sa file d'attente des instruction à exécuter, il doit les diriger vers le bon core. Les joueurs sur PC connaissent bien ce phénomène, plusieurs fois, sur le dernier processeur Intel sorti les performances sont moindre, jusqu'à ce que le studio de développement propose une mise à jour du jeu pour mieux gérer le multithread et le spécificités du nouveau processeur. Déjà vu sur smartphone, avec les processeurs Qualcomm par exemple.

Bienvenue sur le forum, même si je pense que tu as loupé le processus d'inscription, tu es encore indiqué comme Invité.

Indeed, no consumption clamp on my system because I can't connect it (too far away). However I have the production clamp. Aside from the Ethernet/Wi-Fi connexion, the missing clamp may explain the difference, my Envoy has less computing to do.

Je n'ai pas inventé cette formule de calcul, j'ai repris celle que j'ai trouvé quelque part... sans certitude, mais je crois que c'est de @Steven qui l'avais partagé sur le forum, à l'époque de la HC2. En fait cette formule est un grand classique du calcul d'utilisation CPU sur un ordinateur... les métriques remontés par le noyau donnent un temps processeur cumulé (en "tick" processeur, c'est l'unité élémentaire, basée sur le cycle d'horloge, donc le plus petit temps possible), cela pour l'ensemble des cœurs actifs. C'est valable pour les différents systèmes d'exploitation, Linux, AIX, etc... (Windows aussi je suppose, je n'ai jamais développé avec les API de performance sur cette plateforme). Il faut donc diviser le temps total mesuré par le nombre de cœurs installés pour obtenir le bon pourcentage d'utilisation moyen de la machine. Le facteur 4 c'est juste à cause du nombre de cœurs dans le processeur de la HC3, je crois de mémoire que c'est seulement 2 dans le cas de la HC3 Lite. D'où l'utilisation de la variable nbCPUs qui compte le nombre de cœurs dans la formule. Pour s'assurer de la fiabilité de cette formule effectuée en LUA, il faudrait effectuer un benchmark. Pour cela, écrire un code LUA dans un QuickApp, qui tourne en boucle "à fond la caisse", par exemple en faisant un calcul mathématique simple, et cela pendant de longues minutes. Le code LUA du QuickApp étant mono-threadé, il sera affecté à un seul cœur du processeur. Ce cœur sera donc à 100%. La HC3 disposant de 4 cœurs, la charge moyenne du processeur sera donc de 25% (en pratique un peu plus, car la HC3 fait aussi d'autre choses : moteur Z-Wave, autres QuickApps, scènes, et interface Web qui consomment tous un peu de CPU) La formule de calcul, devrait donc donner un résultat approximativement autour de 25% (1 cœur à 100%, divisé par 4 cœurs pour moyenner sur le processeur du système) Cependant, il y a une grosse limitation. L'API /diagnostics remonte les informations fournies par le noyau Linux, donc précises, sur l'ensemble du système (incluant donc la totalité des processus tournant sur la machine... tant les processus utilisateurs (QuickApps, Scènes, les différents binaires Fibaro) que les processus systèmes (noyau, librairies de gestion des entrées/sorties (stockage, réseau, etc). Cependant, la commande collectgarbage("count") utilisée en LUA pour récupérer la consommation CPU du QuickApp, ne compte que le processus utilisateur proprement dit (rappel : 1 QuickApp = 1 processus utilisateur sous Linux). Impossible donc, depuis un QuickApp, de mesurer l'activité induite par le QuickApp, à savoir les autres processus systèmes et noyau. Exemple, un QuickApp qui appelle l'API de la box fait travailler le serveur Web embarqué ainsi que d'autres processus Fibaro. Cette activité sera "vue" par l'API système /diagnostics, mais pas par l'API LUA locale. De même pour un QuickApp qui fait des requêtes réseau, des affichages dans la console de debug, ou déclenche des activités sur les autres modules (physiques ou QuickApps....) Quoi qu'il en soit, mon test de benchmark proposé précédemment, s'il se contente de faire un calcul mathématique simple en local (une simple addition suffit... ou même pas de calcul du tout, ça peut être une bête boucle infinie de type "while true do end") devrait théoriquement limiter l'activité externe induite par le QuickApp, et donc permettre d'approcher les 25% de charge moyenne de la box, tout en étant lui-même à 100% sur un seul cœur. Ou tout du moins, un bon ordre de grandeur (étant donné, encore une fois, que la box fait aussi autre chose en même temps) Pas simple l'analyse de performance en informatique... Oui mais attention, ce cas que tu décris n'est qu'un cas particulier où la charge est équilibrée sur l'ensemble des cores, ce qui est hautement improbable (statistiquement on s'en approche tout de même sur un système chargé avec un grand nombre de processus, car le noyau Linux fait de son mieux pour équilibrer la charge sur les différents cores) Par ailleurs, si tu as suivi mon exposé, tu peux avoir 1 core à 100%, et les autres qui ne font rien, ça fait 25% en moyenne. Ou n'importe quelle autre combinaison de charge de travail (ce qui, dynamiquement, change un grand nombre de fois chaque seconde lorsque le noyau rééquilibre les processus sur les cores) Oui.

Yes, wired Ethernet for all my equipment, including the Envoy gateway. Despite having an excellent Wi-Fi thanks to my 3 Unifi AP, it is only used by mobile devices such as phones, tablets, or some few devices without any Ethernet port such as ESP32 or Netatmo. Nothing cas beat Ethernet connection, not even the latest WiFi 7 protocol. It took me hours, days, weeks of work to be able to bring Ethernet cables to almost everywhere in my house, from the basement to (literally) the roof.

@TitiXsi I remember this old conversation we already had, but my Envoy S Metered has no problem being polled by my QuickApp with a 5 seconds interval. It's monitoring 2 Q-Relays and 16 IQ7+ micro-inverters. Most API requests are delivered within less than 1s, sometimes a little more, but still less than 2 seconds.