Lazer

Effectivement, désolé pour ce bug, je pense avoir trouvé ce qui pose problème. PS : la prochaine fois pense à activer GEA.debug = true Voici la version 7.33 : Corrige le bug de "RoomLights" GEA v7.33.lua

Pour la Téléinfo, le câble est normé, je ne me souviens plus, mais tu peux retrouver l'info dans les PDF d'Enedis, ou si @Did passe par là. 80m ça commence à faire pas mal, je dirais qu'idéalement il faudrait du câble réseau en paire torsadée (tu n'as besoin que de 2 fils, soit 1 seule paire pour la Téléinfo) et blindé. Perso j'utilise du câble de Catégorie 5e non blindé et ça fonctionne très bien, mais je n'ai pas une grosse longueur (je n'ai pas mesurée, mais je dirais moins de 20m)

Oui il y a surement une API, après libre à toi de créer le QA pour remonter les infos du WES sur la Home Center. Sinon je mettrai peut être en vente mon Eco Devices v1 un de ces jours, vu que je suis passé sur le nouvel EDRT2. Il faut juste que je l'installe proprement dans le tableau, pour l'instant il pendouille toujours posé sur la Freebox, avec la HC3 en travers par dessus, c'est juste honteux.

Ecodevices 1 fin de série : https://forum.gce-electronics.com/t/ecodevices-1-fin-de-serie/13222

Je n'ai pas ce Walli Controller, mais connaissant Fibaro je ne serais pas surpris qu'il faille utiliser CentralSceneEvent, comme toutes les télécommandes récentes. Tu peux vérifier dans sa doc.

Effectivement, merci de m'avoir aiguillé, c'était bien un bug introduit depuis la version 7.30. Voici donc la version 7.32 : Corrige le #name# Corrige l'option "Parameter" GEA v7.32.lua

Bienvenue sur le forum

De mémoire il y a un bug dans GEA sur HC2, quand on a pour seule condition "Sensor". Tu serais donc dans ce cas de figure. Essaye de rajouter une condition principale, simplement vérifier que l'appareil est allumé : GEA.add({89, {"Sensor+", 89, 500}}, -1, "Allumage Pompe!") GEA.add({89, {"Sensor-", 89, 500}}, -1, "Extinction Pompe!")

@Dragoniacs tu pourrais me donner la règle GEA.add() qui produit se plantage ?

Box/Logiciel/ on s'en fout c'est pareil hein Alors oui une scène chez Fibaro c'est clairement plus simple que sur Jeedom. Mais je savais pas que tu venais du forum Jeedom, c'est clairement une différence fondamentale de réflexion de mise en place de la domotique. J'ai déjà remarqué, chez d'autres utilisateurs Jeedom, cette tendance à vouloir tout centraliser sur la box (logiciel ), et n'utiliser aucune fonction "de base" propre aux modules. Je pense que par extension, ça explique pourquoi beaucoup d'utilisateurs de Jeedom ne voient pas la valeur ajoutée de Z-Wave par rapport à d'autres protocoles. Et notamment Zigbee qui est à la mode, mais dont les modules sont à peu près aussi basiques qu'à l'époque du 433 MHz (j'exagère, il y a quand même le retour d'état en Zigbee, c'est déjà un gros plus) Dans ce cas, c'est clair qu'il n'y a pas beaucoup d'intérêt à prendre des modules Z-Wave à 50€ quand un module à 20€ fait sensiblement la même chose. PS : je cites Jeedom car tu en parles, mais c'est le même comportement avec Home Assistant étonnamment.

Je ne suis pas trop d'accord. Les associations c'est parfait pour toutes les actions de base, qui doivent pouvoir se passer sans box. Le cas de @TheRevolutioner est un vrai cas d'école, l'association est exactement ce qu'il faut dans ce cas là, et passer par un scénario via la box serait une bêtise (plus compliqué à mettre en place (encore qu'avec une scène en mode bloc, ça reste à peu près simple), plus lent, dépend de la box qui doit être opérationnelle) Ça revient à faire en sans fil ce qui se pratique en KNX. Les fonctions de base sont automatisées (comprendre : autonome, indépendante) Les scènes sur la box, c'est bien pour les scènes plus "complexes", c'est à dire qui prennent de multiple conditions. Exemple appliqué à la lumière : il est inutile que le détecteur de mouvement allume la lumière (en association directe) s'il fait déjà jour. Dans ce cas, la scène permet de prendre en compte la luminosité et/ou l'heure, ainsi que d'autres conditions (présent/absent, en effet on va pas allumer la lumière si c'est juste le chat qui se balade pendant qu'on est absent)

Bienvenue sur le forum

Théoriquement c'est une bobine/inductance/self, afin de luter contre l'effet capacitif des charges à base d'alimentation à découpage.

Tiens, tu peux essayer cette version 7.31 J'ai effectivement corrigé une erreur dans "Ask", un caractère s'était malencontreusement introduit... J'en ai profité pour améliorer cette option, on peut maintenant identifier la Scène ou le QuickApp à appeler par son nom. GEA v7.31.lua

@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.