Lazer

@manuxenon Y'a même pas de message d'erreur..... comme d'habitude, tu peux activer self.debug=true et self.lldebug=true (et isole ta règle fautive) @jang Je répond en français, je pense que Google Translate saura traduire à peu près correctement vers l'anglais. Tu as raison, l'appelle d'une méthode d'un QA peut modifier des propriétés. J'y ai pensé, et mon système de cache est censé le gérer. Il y a plusieurs caches. Une table LUA pour les propriétés des devices Une table LUA pour les variables globales Une table LUA pour les profiles etc. Prenons un exemple, la table des propriétés des devices. Elle a une structure comme telle, qui est remplie au fur et à mesure de la lecture des propriétés : self.cachedDeviceProperties = { 3 = { Temperature = 20 }, 10 = { value = true, power = 100 } } Dans cet exemple, le premier index est l'ID des devices, et le second index représente les propriétés de chaque device. Ce tableau est créé et rempli dans la fonction GEA:getDeviceProperty(id, property) Maintenant, quand une action est effectuée sur un device, le plus simple est de supprimer du cache toutes les propriétés de ce device : self.cachedDeviceProperties[id_num] = {} Cela répond au problème de l'appel d'une méthode qui est susceptible de modifier plusieurs propriétés d'un device. Dans d'autres situations, par exemple les actions "Dead", "Polling", "ApiGet", "ApiPost", etc... et aussi à chaque démarrage d'une nouvelle boucle de GEA, on force la suppression complète de la table avec self.refreshDeviceProperties = true (qui sera traité dans la fonction cachedDeviceProperties()). Ainsi, normalement on ne devrait jamais avoir de cas où une propriété n'est pas à jour. Le principe est similaire pour tous les autres objets stockés en cache : labels et sliders des QA, zone de climat, partition d'alarme, variables globales, variables de Quickapp, propriétés de scènes, météo, profile actif, paramètres systèmes J'ai essayé de faire court, j'espère que c'est clair.

Aucun de message d'erreur, c'est typiquement le type de plantage impossible à analyser. Par contre attention, je vois que GEA est en mode suspendu, donc plantage ou pas, il ne risque pas de fonctionner. Dans tous les cas, installe la dernière version, c'est préférable.

@Fredmas en fait tu es en train de réinventer la roue Ce que tu cherches à faire, c'est exactement ce que fait déjà GEA, ou l'exemple de @jang GEA fait bien plus évidemment, mais ça fonction de base c'est de surveiller à intervalle régulier l'état de plusieurs conditions, et agir (ou pas) en conséquence. Maintenant si tu veux juste apprendre pour le plaisir de coder en LUA, dans ce cas tu peux effectivement écrire ta propre boucle, comme dans l'exemple intervalRunner(), qui sera plus efficace (plus précis) que GEA (qui est précis à 30 secondes près). Dans l'esprit, cela ressemble beaucoup au Scheduler qui existait sur HC2 v3.

Une remarque sur les performances. Sur une grosse config (pas loin de 200 règles), la consommation CPU est divisée d'un facteur d'environ 10. C'est énorme. Ce qui signifie aussi que tous les traitements sont accélérés, aussi bien la boucle infinie avec rafraichissement de 30 secondes, que les événements instantanés. J'ai constaté que tous les appels à l'API Fibaro (via les fonctions fibaro.* et api.*), sont extrêmement lents. On ne s'en rend pas compte dans un usage normal, mais dans le cas de GEA, qui effectue plusieurs centaines d'appels par minute, le temps cumulé est énorme. L'amélioration des performances a donc principalement consisté à mettre en place un système de cache local. Exemple concret, supposons plusieurs règles qui testent la valeur d'un profil, d'une variable globale, de la valeur de température d'un module, etc.... ça faisait autant de lecture de la même info plusieurs dizaines de fois pour rien. La première fois, la valeur est lue, puis conservée en cache (de simples tables LUA), pour être réutilisée quasiment instantanément lors du passage sur la règle suivante. Évidemment, à chaque déclenchement de GEA (c'est à dire à chaque boucle de 30s ou à chaque déclenchement instantané), le cache est vidé afin de forcer une nouvelle lecture des données. Autre cas où le cache est vidé : lorsqu'une règle déclenche une action de modification. Exemple : on modifie une variable globale, il faut vider le cache afin que la règle suivante, si elle lit la même variable, reprennent bien la nouvelle valeur. Ce cache est donc l'axe d'amélioration principal des performances. Plus quelques optimisations par ci par là sur le code. Il serait encore possible de gagner en performance, mais ça oblige à modifier profondément GEA, je ne suis pas encore prêt (c'est que GEA est sacrément complexe....) C'est déjà très bien comme ça. Sur ma box de prod, je ne dépasse quasiment plus les 0.5% de CPU utilisé, alors qu'avant ces optimisations, je dépassais facilement 5%, voire 10% de CPU. Ce qui se ressentait sur les scénarios, lumières qui s’allument en retard, etc. La consommation CPU du QuickApp est maintenant affichée à coté de la RAM : Sur la capture d'écran ci-dessus, on voit également l'amélioration de l'affichage des déclencheurs/triggers, puisqu'on voit le nom, la pièce, la propriété. Ce sont des infos qui étaient visibles dans les toutes premières version de GEA sur HC2 v3, mais que @Steven avait dû retirer lors du passage en v4, avec justement la même gestion de la DB que sur HC3, et les lenteurs d'accès aux fonctions fibaro() et api(). Maintenant grâce à la mise en place du cache, ce problème est résolu. C'est aussi l'avantage du QuickApp, l'espace mémoire est partagé entre toutes les fonctions, là où les scènes sur HC2, avec leurs instances différentes, avaient leur propre espace mémoire, donc impossible de partager des données.

Mise en ligne de GEA version 7.30 : Améliorations : Amélioration des performances Affichage des informations détaillées sur les déclencheurs instantanés (triggers) dans la console de logs Amélioration de l'option "Picture" : ID ou nom de l'utilisateur Amélioration et correctif de l'option "Ask" : après réponse de l'utilisateur, permet d'exécuter une scène, une méthode d'un QuickApp, ou une action GEA Correctifs : Correctif de l'option "Weather" : prise en compte de la météo globale définie dans la box et non pas uniquement du module n°3 YR-Weather Correctif de l'option "SonosMP3" : utilisable avec le QuickApp de Krikroff pour HC3 Ajouts : Ajout de l'option "isEvenDay" : Teste si le numéro du jour en cours est pair Suppressions : Suppression de l'option "Popup" : non compatible HC3 Correctifs et améliorations diverses Copier/coller le contenu des fichiers LUA téléchargés par dessus les fichiers main et tools dans le QuickApp (ou bien télécharger le QuickApp complet disponible en 1ère page)  GEA v7.30.lua Library - tools v2.12.lua

Thanks, useful library Nouveau record d'utilisation de la RAM par le QA ce matin :

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 ?