Lazer

Oui c'est ça, relai collé, c'est un grand classique avec les LED et leur fort courant d'appel. Je confirme, même module que Did, à installer en série entre la sortie du relai et les LED, et plus aucun souci.

Vu la valeur délirante, ça ressemble à un dépassement de buffer ou un truc dans le genre. Donc tu es certain d'avoir choisi la bonne taille pour l'option (1, 2, 3 ou 4 octets) ? Dans le doute, supprime l'option, enregistre, puis tu la recréer en mode lecteur seule, tu enregistre, il va interroger le module, et remplir correctement avec la valeur par défaut et la bonne taille d'option. Autre chose : tu peux faire la mise à jour du firmware de ce module si tu as une clé Aeotec.

Pas de chance.... J'ai ouvert un topic sur le forum officiel, si vous voulez bien aller appuyer la demande : https://forum.fibaro.com/topic/54715-high-cpu-usage/

Voilà une des raisons pour laquelle il me semble important de typer correctement ses QA, afin que la fonction principale du QA (exemple : ON/OFF, Variation, etc) soit accessible directement sans avoir besoin d'ouvrir la vue du QA. Aller cliquer sur des boutons devrait être utilisé en dernier recours (à la mode Virtual Device sur HC2) Autre sujet, mais la domotique ça sert surtout à automatiser, donc le recours à l'application mobile devrait être réduit autant que possible. Perso à chaque fois que j'utilise mon téléphone, c'est plutôt pour vérifier à distance que d'agir. Et puis les fois où je peux pas faire autrement, je prends le téléphone et j'ouvre la vue du QA, mais finalement c'est assez rare.

Non, c'est bien la première option que j'ai en tête : inclure cette boucle RefreshStat pour chaque QA qui souhaite tirer parti d'un "trigger" D'où le test de charge, pour m'assurer que ça ne plombe pas la box. Sur ma box de production, avec 3 QA qui exploitent ce principe et beaucoup d'événements, ça ne pose aucun souci. La 2nde option, un QA qui centralise tous les triggers, puis les redispatch vers les autres, est l'approche choisie par @jang avec son Webhook QA : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/6/?tab=comments#comment-202423 Je principe est top, mais perso je ne suis pas fan, à cause de la dépendance entre les QA (maintenance plus complexe, et il devient très compliqué de partager ses propres QA avec la communauté s'il faut monter une usine à gaz pour les utiliser)

Il me semble que les modules conservent leur dernier chemin même après un reboot électrique.... du coup la solution de couper le disjoncteur ne permet pas de reconstruire le réseau.

ça m'arrive de temps en temps sur l'appli, sous Android, la page du QA est blanche.... puis ça refonctionne un moment plus tard... sans que je ne comprenne pourquoi.

C'était au cas où la boucle pose problème, et fasse planter la box, car j'étais en phase de test et j'en ai lancé plusieurs dans différents QA simultanément, pour tester la montée en charge. Si la boucle avait été en démarrage automatique dans le QA et fasse rebooter la box en boucle, je n'aurais jamais pu m'en sortir (expérience vécue lors d'un autre test...) Mais maintenant qu'on sait que ça fonctionne, tu peux utiliser ta boucle normalement dans ton QA, avec un lancement automatique. Ton setTimeout me semble OK

Si j'installe une HC3 avec tes icônes dans ma voiture, est-ce que je serai prioritaire aux carrefours comme les bus ?

Justement, tu as un exemple de code utilisable dans le topic en question. Il faut juste ajouter ton propre traitement dans la boucle là où j'ai laissé des commentaires. Sinon, en QA déjà existant sur le forum, il y a GEA, mais pas vraiment le meilleur exemple, tellement le code est complexe.

Oui avec l'API refreshStates, mais pas simple : La façon de faire standard de Fibaro, c'est d'utiliser un trigger dans une scène. Mais quand tu veux faire ça dans un QuickApp, soit tu utilises une scène qui appelle le QA (un peu lourd à maintenir, à cause de la dépendance entre les ID), ou bien avec la technique que j'ai donnée au dessus.

Clairement oui, Wait & see !! Pour une fois, Fibaro a bien fait les choses, le nouveau moteur n'est accessible qu'après un recovery complet, et un choix volontaire de l'utilisateur, c'est clairement tu "early access" comme ils le disent, c'est à dire du programme beta. Il faudra plusieurs mois avant d'attendre le niveau de stabilité du moteur actuel. Dès que j'aurai un moment, je ferai la test de la v3 sur ma box de développement, mais je vais rester sagement sur la moteur v2 sur ma box de production.

Là est la question.... comme ils le disent, le nouveau moteur n'est pas encore garanti de fonctionner avec tous les modules, il faut tu temps pour déboguer tout ça. Après je vois pas pourquoi ça serait basé sur l'âge. Les vrais raisons d’incompatibilité sont plutôt techniques, genre certains modules qui présentent des caractéristiques un peu bizarres ou pas trop standard (au hasard certains firmwares buggués de chez Qubino )

Je crois que Fibaro a tout dit..... pas de migration v2 => v3, il faudra attendre. Sur le forum officiel ils annoncent 3 à 4 mois minimum (ce qui correspond plus ou moins au prochain firmware en prenant en compte le rythme de développement actuel) Si tu es en prod, que ça fonctionne, et que tu n'as pas envie de refaire toute ton installation à zéro, je t'invite à conserver le moteur v2 actuel, qui fonctionne déjà très bien.

Dans le name, tu peux laisser avec les majuscules, mais l'index de l'option doit toujours être en minuscule, donc : GEA.options.estpair = { -- ... } D'ailleurs c'est pas bête cette option, je vais l'intégrer en standard dans GEA je pense

Non tu ne peux pas agir sur un autre process (chaque QA s’exécute dans un process différent au niveau du système d'exploitation Linux) Tout ce que tu peux faire, c'est faire communiquer 2 QA par le biais du mécanisme mis en place par Fibaro (appel de fonction avec fibaro.call()), ou bien en partageant du contenu dans une variable globale. Cette dernière solution est proscrire autant que possible, car cela va réaliser des écritures inutiles dans la DB (impact sur les performances et l'usure de la mémoire Flash), et demander un "polling" régulier de la part du QA cible... pas du tout optimal. Le mieux reste d'appeler une fonction de ton autre QA, qui elle-même réalisera exactement ce que tu fais avec ton bouton actuel, à savoir définir une variable locale qui désactivera l'exécution du QA

Non Mais tu appliques le même principe, puisque je vois que tu fais un settimeout, donc tu dois retester la valeur de ta variable au sein même de la fonction apellée par settimeout, et tu auras le résultat voulu.

Dans ton bouton stop, tu définie une variable interne au QA, par exemple : self.codearret = true Et dans ta boucle infinie, tu testes sa valeur pour savoir si tu dois exécuter le code ou non : if not self.codearret then -- faire des choses end Attention, ça n'arrêtera pas le code en cours d'exécution dans le bouton4. Mais ça empêchera qu'il exécute une nouvelle action lors du prochain clic sur le bouton

Il va falloir qu'on le signale sur le forum officiel ou bien via le support Fibaro, sinon ils risque de laisser ce dysfonctionnement majeur d'ici la sortie de la prochaine stable.... et alors on aura perdu, car il faudra attendre 3 ou 4 mois d'ici la stable suivante. Je vais le faire, est-ce que tu peux nous partager un screenshot de ton graph CPU sur 5 minutes ?

Oui c'est ça, je pense qu'il faut que tu choisisses EnergyMeter pour ton enfant qui va porter la production, puis tu configures ce modules comme tel dans ses propriétés, comme vu sur le topic du nouveau firmware 5.071.52

Ouch violent ton CPU. A mon avis c'est amplifié par le fait que tu as plein de modules qui rapportent une consommation d'energy, à chaque mise à jour d'une valeur ça déclenche un cycle CPU intense.

Oh oui dis donc, c'est génial ça, et surtout on peut enfin modifier les variables d'un child depuis ses propriétés via l'interface Web, une fonctionnalité dont je m'étonnais de son absence il y a 1 an Je n'ai pas testé, je me demande ce qui se passe si on ajoute un fichier LUA à un child.... ?!? Et ce que je vais tester, c'est surtout la possibilité de customiser son interface, avec des labels et boutons, car ce n'était pas possible jusqu'à présent.

Pareil, j'ai l'impression que l'interface Web est plus lente aussi, mais je n'était pas certain... bon bah maintenant c'est clair. Décidément, c'est pas un succès cette beta... une braie beta quoi !

Bon, voilà qui est clair net et précis, et confirme ce que je pensais depuis 2 jours : Dès que je désactive mon QuickApp GCE qui s'occupe de l'EDRT2, les pics de CPU disparaissent. Je précise que le problème ne vient pas du QuickApp en lui-même, car : - le pic de CPU se produit juste après la boucle infinie (rafraichissement toutes les 60 secondes) qui met à jour les modules enfants. - j'en ai un second strictement identique, mais qui gère l'IPX800 au lieu de l'EDRT2, qui est toujours en fonctionnement, et cela n'impacte pas le CPU Et celui de l'EDRT2, justement, il met à jour un module enfant, qui représente la consommation électrique globale de la maison, au niveau du compteur (Teleinfo Linky). Donc forcément, chaque minute, la valeur change. @Barelle laisse moi deviner, tu as un QA pour ton Eco Devices, et celui-ci produit la même conséquence sur le CPU de ta box. Est-ce que tu peux le désactiver pendant 2 ou 3 minutes pour confirmer le comportement ? @josephMa tes 2 modules qui remontent de l'énergie, c'est quoi ? Des modules Z-Wave ou des QuickApps ? Ils remontent du power (W) ou du energy (kWh) ? Ce qui n'est pas pareil... Et enfin, les appareils branchés dessus, est-ce qu'il consomment suffisamment pour déclencher une mise à jour chaque minute ou pas ? Parce que s'ils consomment peu et n'envoie une mise à jour de la consommation d'énergie qu'une fois toutes les quelques heures, tu ne risques pas de voir la moindre pointe CPU sauf à rester coller devant l'écran. Du coup, tu aurais le problème, mais sans le voir.

Est-ce que tu as des modules qui remontent une consommation d'énergie ? Je soupçonne que ça soit lié