Lazer

Oui, tout à fait, c'est la bonne méthode pour suivre les événements en temps-réel. On en parle ici : Le QA Evénement, à l'origine, c'était pas destiné à suivre les événements en temps réel, mais juste à consulter après-coup l'historique, comme le panneau d'événement de la HC2/HC3, mais depuis l'application mobile. Finalement, vu la taille des tables à manipuler, peut être bien que l'API refreshStates serait finalement moins gourmande que l'API /event/history.

J'ai partagé ce soir la nouvelle version du QA Événements, avec quelques commentaires ici : Comme vous pourrez le lire, lors de mes tests (= usage normal de la box), j'ai constaté que ce QA pouvait consommer jusqu'à 50 Mo de RAM, et plus de 1% de CPU. Ce qui est énorme comparé à tous mes autres QA, et même à GEA avec ses 200 règles et 4000 lignes de codes, qui est de loin le QA le plus complexe qui tourne sur ma box (GEA fait des pointes à 6 Mo de RAM seulement) A comparer avec le sujet dont il est question ici, à savoir l'API refreshStates, qui s'est avéré finalement moins consommatrice qu'initialement craint. En effet, même si l'exploitation de cette API impose un polling régulier et très fréquent (100 ms, soit 10 fois par secondes), à chaque boucle elle récupère soit une table vide, soit une petite table (un seul, ou quelques événements), qu'il est finalement très rapide de parcourir, comparer, analyser, traiter. A l'inverse, le QA événements va interroger une autre API (/api/events/history), dans laquelle on retrouve sensiblement les mêmes informations (c'est à dire que les 2 API sont très bavarde, on y voit passer tout ce qui se passe sur la box). Mais il le fait à intervalle plus espacé (60 secondes), et surtout il doit collecter suffisamment de lignes pour remplir les 35 labels, elle se retrouve à devoir traiter de grosses tables... ce qui est finalement beaucoup plus consommateur de CPU et de RAM. Bref, il semble que l'API refreshStates soit vraiment une très bonne solution pour traiter les événements de la box, en vue d'un traitement en (quasi) temps-réel. Mangez-en, c'est du tout bon PS : En écrivant ce blah blah, il m'est venu à l'esprit qu'il serait finalement peut être plus judicieux de réécrire intégralement le code du QA événement pour exploiter l'API refreshStates, avec un potentiel énorme bénéfice sur les performances..... à méditer pour plus tard.

Mise en ligne de la version 1.10, qui fonctionne avec les firmwares récents (nouvelle API /api/events/history) Parmi les nouveautés, le QA ajuste automatiquement le nombre de labels en fonction du chiffre paramétré dans ses variables, et il est maintenant possible d'exclure certains propriétés des modules (par exemple power et energy) Je ne partage pas le code LUA de la nouvelle version car il y a trop de différences au niveau de la structure du QuickApp (labels, variables, etc), donc il est plus simple de supprimer l'ancienne version 1.0 et d'importer le nouveau fichier fqa en version 1.10. Je tiens à préciser qu'il s'agit d'un QuickApp gourmand en ressources, tant CPU que RAM. En effet, à chaque rafraichissement (60 secondes par défaut), il lit le tableau des événements, qui peuvent être extrêmement nombreux sur une box de production avec pas mal de modules (Z-Wave, QuickApps, etc) J'ai constaté des occupations mémoires jusqu'à 50 Mo (là où les autres QA se limitent généralement à environ 1 Mo), et une utilisation CPU supérieure à 1% (là où les autres QA, supposément bien écris, sont plutôt autour de 0.1%) C'est très clairement mon QA le plus consommateur, et même très largement au delà de mon instance GEA avec 200 règles. J'ai optimisé tout ce que j'ai pu pour limiter l'utilisation de la RAM. Je pourrais forcer une libération plus agressive de la RAM (en forçant le Garbage Collector), mais au prix d'une occupation CPU plus importante, donc... autant laisser comme ça pour l'instant. Cela étant dit, cette version du QuickApp Événement semble très bien fonctionner sur la durée, pas de plantage à signaler chez moi.

Yes, j'ai eu un retour ce matin, ils ont identifié le problème, ils confirment que c'est lié au traitement des données d'énergie. Ils préparent des optimisations qui seront disponibles dans la prochaine version 5.072. Je ne vois pas tout ce qu'ils ont fait sur ma box, mais dans les logs des QA, je vois qu'ils ont modifié le code de mon QA GCE EDRT2, pour mettre des traces et analyser le comportement. Franchement, sur ce coup là, Fibaro a été top (mais attendons quand même de voir le résultat)

Héhé En tout il se passe des choses, je vois le CPU et la RAM qui font du yoyo, et des messages inédits comme "not enough memory for buffer allocation" et "stack overflow" dans les logs. ça bosse dur.

Pour info, suite à la discussion sur le forum officiel, un développeur Fibaro est connecté sur ma box de test en ce moment même pour étudier le problème CPU lié aux relevés d'énergie, donc c'est bon signe

La sonde de température, c'est le truc qui coute rien et que tous les fabricants intègrent à tous leurs modules, même quand ce n'est pas adapté. Le cas des micromodules Qubino, mais aussi les détecteurs d'ouvertures aux fenêtres (froides), les détecteurs de mouvements aux plafond (chaud), etc.... donc pour moi c'est avant tout une fonctionnalité marketing à défaut d'être utile. Dans ton cas, c'est d'autant plus inutile que la sonde sera dans la boite du micromodules, derrière le radiateur, pas du tout le bon endroit pour prendre une mesure de température. A la limite, si tu pouvais tirer une rallonge de plusieurs mètres pour aller installer la sonde sur le mur opposé à 1.5m de hauteur, là tu aurais une vraie mesure, représentative de la température d'ambiance de la pièce. Dans tous les cas, cette mesure de température, qu'elle soit judicieusement placée ou non, ne te sera pas utile pour la régulation si tu exploites les ordres du fil pilote. Car c'est le radiateur qui fera sa propre régulation de température avec son thermostat interne. Cela dit, une sonde de température dans une pièce, c'est toujours utile : - pour connaitre la température, faire des graphs, des statistiques, remplir le dashboard de l'application mobile, geeker, etc - anticiper la chauffe dans un scénario plus avancé. Si la température d'ambiance est inférieure de 1°C à la température de confort, tu lanceras le radiateur plus tard que si le delta est de 3°, l'objectif étant d'avoir la bonne température au moment où tu vas arriver dans la pièce (heure du doucher, heure du diner, de la douche, etc selon les pièces)

Bienvenue sur le forum

Bizarre, je n'ai jamais vu ça.

Bienvenue sur le forum

Oui, David, le créateur du blog et du forum a annoncé il y a plusieurs mois qu'il arrêtait complètement toutes ses activités domotiques.... Une page se tourne...

Effectivement, tu as mis le doigt dessus, une histoire de taille de bit.... Le VD et le QA n'ont aucune ligne LUA en commun, j'ai entièrement repris l'écriture à zéro. Sauf... la librairie qui gère la crypto, que ni moi ni @ADN182 ne maitrisons, elle provient d'Internet. Nous l'avons pris à des endroits différents, mais je pense qu'au final c'est bien le même auteur original. Perso j'ai utilisé la version packagée et testée par Tinman pour HC3.

Je pense que tu dois être le premier à tester ce QuickApp sur HC3 Lite.... j'ai la même impression que toi, ça semble provenir de LUA. Pas de la version, qui est surement la même, mais plutôt d'une limitation liée aux ressources disponibles, car il te dit qu'il a besoin de nombre flottants à plus de 53 bits, ce qui est assez énorme.... Malheureusement cela vient de la librairie sha2lib, donc la cryptographie, le code n'est pas de moi, je ne sais pas le débogguer.... C'est bien dommage ça, car la HC3 Lite serait finalement plus limitée qu'on ne le pensait au début.

10% ça va encore, on est loin des 100% d'augmentation sur les cartes graphiques et les disques durs... merci les cryptomonnaies Zigbee, c'est mois cher, mais on sait pourquoi maintenant : ce protocole est mort, il vit ses derniers mois. C'est surtout les produits Matter & Thread qu'il faut attendre.... j'espère que ça ne va pas prendre de retard vue la situation....

Justement, j'ai découvert très récemment que GEA sur HC2 n'utilisait pas les infos de l'API Weather de la HC2, mais uniquement les infos du module n°3.... qui est donc toujours YR Weather Cela sera corrigé dans la prochaine version de GEA sur HC3... Mais sur HC2... je n'y touche plus. Il faudrait que tu ailles lire directement les propriétés de ton module Weather Provider, avec l'option "Property". Par exemple : {"Property", 123, "Temperature"} (non testé) Ou bien, tout simplement, la Value du module enfant associé à ta station Netatmo.... ce que j'ai toujours fait sur HC2, donc ça fonctionne.

OK... donc non à ma connaissance ce n'est pas possible.

En série oui. Non rien à voir avec le bypass, au contraire, là on essaye de limiter le courant de démarrage. Et oui, il faut en utiliser surtout avec le transfo des LED, les transfos c'est pire que tout au niveau pic de courant, particulièrement les modèles chinois (tous ceux qui sont sans marque, c'est à dire 99% du marché) Si tu installes le limiteur de courant que t'as montré Did, tu n'auras pas besoin de changer le FGS, les relais ne devraient pas recoller. En revanche, si tu continues à l'utiliser tel quel, il pourrait bien recoller à la prochaine utilisation, ou la suivante, etc.

Hum; j'en ai un, mais il n'est pas inclus en ce moment....

Je n'ai pas compris la question... tu veux dire que tu voudrais des variables énumérées dans les QuickApps ?

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.