Lazer

Et bien... suffisait d'en parler, ça vient de m'arriver, à 18h. Je me suis rendu compte que GEA n'avait pas exécuté une action à cette heure là (action simple, sans autre condition que l'heure) Je regarde la courbe CPU de DomoCharts, et je constaste un affreux pic à cette heure là.... donc forcément, GEA n'a pas pu exécuter l'action à l'heure dite. La solution de contournement, tant que Fibaro n'aura pas travaillé sur ce problème de freeze, c'est d'allonger les plages horaires "Time" qu'on utilise dans GEA.... Là où je suis inquiet, c'est que personne, à part toi et moi, ne semble avoir relevé ces freeze (faut dire que c'est pas évident à détecter).... et encore moins remonté sur le forum officiel, donc Fibaro n'est pas prêt de travailler sur ce sujet... D'ailleurs, c'est très étonnant que ça soit tous les jours à la même heure chez toi, car chez moi c'est assez rare. Plutôt tous les 15 jours, à des horaires variables.

Ah voilà tu as retrouvé où on en a parlé il y a quelques temps Outre les problématiques de portée et de risque d'erreur de réutilisation, précisons, au sujet des performances, qu'il est plus rapide d'utiliser des variables locales que des variables globales (en LUA, ce n'est pas le cas avec d'autres langages) En effet, en LUA, accéder à une variable globale requiert de parcourir la table super-globale _G (une table qui contient toutes les variables globales, les fonctions, etc), ce qui prend des cycles CPU à chaque accès. Mais on parle là de micro-optimisations. Il n'y aura un gain sensible à ce niveau que pour un algorithme très lourd, avec une boucle qui effectue des millions d'accès à la même variable. Cela n'a rien à voir avec la différence de performance lors de l'accès à une variable persistante en DB, pour laquelle la différence de performance est considérable.

Attention de ne pas confondre : les variables LUA (qui existent dans le code LUA, qu'elles soient locales, globales, ou attribuées à un objet via self) => elles résident uniquement en RAM, elle sont créées à chaque démarrage du QuickApp, et perdues lors de son arrêt les variables persistantes de la box (globales, de QuickApp, ou de Scène) => elles sont stockées dans la DB, donc conservées à chaque redémarrage du QA ou reboot de la box.

Dans mon exemple, mavariable est affectée à l'objet self, c'est à dire l'objet QuickApp, cette variable n'est donc accessible que depuis l'une des fonctions membres de QuickApp (avant de me faire reprendre par les experts : en pratique on peut y accéder d'ailleurs, mais chut, on va pas compliquer inutilement pour l'instant) Dans ton dernier exemple, mavariable est une variable globale dans le code LUA de ton QA. C'est qui n'est pas idéal, car une bonne pratique c'est toujours de limiter la portée d'une variable au strict nécessaire. C'est un sujet qui a été abordé plusieurs fois sur le forum, mais l'information étant diluée ça et là au fil des discussions, c'est pas évident à retrouver. On pourrait transformer ta variable globale en variable locale en l'écrivant ainsi : local mavariable function QuickApp:onInit() mavariable = "Hello" end function QuickApp:ModifyVariable(value) mavariable = value end En revanche attention ce code est faux, car la variable serait alors locale uniquement à la fonction onInit() et ne serait donc pas accessible depuis la fonction ModifyVariable (qui créerait alors une autre variable, globale cette fois-ci, portant le même nom) function QuickApp:onInit() local mavariable = "Hello" end function QuickApp:ModifyVariable(value) mavariable = value end Quelques bonnes lectures :

Si GEA redémarre tout seul, il faudra me donner les logs au moment du redémarrage, sans ça impossible de deviner le problème. Par ailleurs, mettez bien une règle qui vous envoie une notification au redémarrage de GEA (comme dans l'exemple fourni), ça évitera les "impressions" et vous aurez des certitudes sur le redémarrage (ou non) de GEA. Personnellement ça ne m'est jamais arrivé depuis 3 mois que mon GEA tourne en production, avec 150 règles environ (par contre j'ai eu quelques redémarrages de la box) Par ailleurs, est-ce que ça ne serait pas un problème plus général sur la box ? Avec des freeze ou une saturation de la RAM ? Sujet plusieurs fois abordé sur le forum. Si vous avez Domocharts, regardez les graph CPU et RAM. Perso j'en ai assez rarement des freeze, mais ça semble arriver plus souvent à @jjacques68 notamment. Parce qu'un freeze de 1, 2, 3 minutes, voire plus, ça peut expliquer les actions manquées telles que l'allumage du sèche serviette de ton exemple. Mais ça n'expliquerait pas la règle d'extinction du sèche serviette, qui n'a pas de référence horaire. Quand ça arrive, dans la HC3, le module 454, il est bien ON ? Il faut analyser les causes des comportements erratiques, sinon tu ne trouveras jamais.

Attention si tu souhaites mettre la HC3L en passerelle derrière la HC3, il y a encore de nombreux bugs avec cette stable pour les modules esclaves (exemple : impossible de modifier leur propriétés). Fibaro travaille sur le correctif.

Bienvenue sur le forum

Je mettrais un "Repeat" oui.... car le problème avec les détecteurs de mouvement, c'est que s'il se déclenche et s'arrête entre 2 boucles de GEA (toutes les 60s), alors GEA rate des mouvements. Je sais que ça m'arrive sur certains de mes scénarios, depuis la HC2. Donc le Repeat devrait permettre de contourner ce problème.

Je ne sais pas.... je suppose que ça va tout supprimer. Sinon tu attends, ça va se purger automatiquement.

Non, avec updateProperty tu ne peux modifier que les propriétés, c'est à dire les valeurs qui sont dans la sous-table properties du JSON du module (visible via /api/devices/ID) Si la variable est "locale", c'est qu'elle est dans la mémoire (pile) du code LUA en cours d'exécution, donc elle n'est absolument pas accessible depuis un autre QA. C'est l'isolation élémentaire des espaces mémoires des programmes informatiques. Encore heureux... encore que des bugs/failles existent, ce qui mène aux plantages ou piratages qu'on voit parfois passer... En revanche, tu peux modifier les variables de QA (celles qui sont dans l'onglet Variables de l'interface Wzb), puisqu'elles sont stockées dans les properties du QA. Mais attention, le format est un peu spécifique, c'est une sous-table qui liste toutes les variables et leurs valeurs, cela n'est donc pas modifiable avec updateProperty, il faut passer par l'API directement.... ou plus simplement appeler la méthode setVariable du QA cible : fibaro.call(ID, "setVariable", "ma_variable", "ma_valeur") je l'ai déjà dit plusieurs fois sur le forum, mais toutes les méthodes (= fonctions) d'un QuickApp sont automatiquement exposées, elles peuvent donc être exécutées depuis un autre QA, ou bien depuis n'importe où dans le monde en passant par l'API HTTP de la box. Cela inclue donc des fonctions aussi élémentaires que self:debug() ===> fibaro.call(ID, "debug", "Injection d'un message dans le log du QA cible") Cela étant dit, tu peux créer une fonction dans un QA, qui permet de modifier une variable locale. Exemple tout simple : function QuickApp:onInit() self.mavariable = "Hello" end function QuickApp:ModifyVariable(value) self.mavariable = value end Il suffit d'appeler depuis un autre QA : fibaro.call(ID, "ModifyVariable", "Goodbye")

En effet, normal, il fallait écrire avec self : fibaro.setTimeout(0, function() self:loop() end) fibaro.setTimeout(3000, function() self:loop() end) Je t'ai dis, c'est pas testé, et écris à l'arrache

C'est un bon début Alors c'est normal, car tu as déclaré tes variables en local, donc elles ne sont connues que dans la fonction onInit(), mais pas dans loop() Voir : Ensuite, il ne faut surtout pas utiliser sleep(), ça va bloquer ton QA, donc mener à un plantage de celui-ci, voire à un reboot de la box. Il faut utiliser setTimeout() C'est de l'asynchronisme, un mécanisme pas évident à comprendre.... Voir ici : Ce que tu peux faire, c'est affecter tes variables à self (l'objet qui désigne le QuickApp en mémoire), ainsi tu peux utiliser les variables dans toutes les fonctions du QA. Pour accéder à un élément particulier d'une table, il faut utiliser les crochets, et le dièse pour compter le nombre d'éléments de la table : for i=1, #Table do print(Table[i]) end ce qui devrait donner un truc dans le genre (non testé, à affiner, mais ça te donne une base de travail) : function QuickApp:onInit() self:debug("onInit") local tempOld = self.properties.value self.Table = {} for i = 1, 10 do table.insert(self.Table, tempOld) end self:debug(json.encode(self.Table)) fibaro.setTimeout(0, function() loop() end) -- on lance la boucle end function QuickApp:loop() self:debug("loop !") table.remove(self.Table, 1) local newValue = fibaro.getValue(123, "value") -- il s'agit de l'ID de ton module température Z-Wave ou Netatmo table.insert(self.Table, newValue) self:debug(json.encode(self.Table)) local tempSum = 0 for i = 1, #self.Table do tempSum = tempSum + self.Table[i] end local tempMoy = tempSum / #self.Table self:debug("Nouvelle moyenne :", tempMoy) self.updateProperty("value", tempMoy) fibaro.setTimeout(3000, function() loop() end) -- prochaine boucle dans 3 secondes end

Au cas où, tu es en Wi-Fi ? Essaye de le désactiver pour passer en 4G. Sur le forum officiel, plusieurs personnes ont des problèmes avec l'appli en Wi-Fi (dans la sous-catégorie iOS, j'ai l'impression que ça ne concerne pas Android)

Chez moi ça marche, rien à signaler. Sur Android pour info.

La table c'est une variable en RAM, donc non elle n'est pas sauvegardée lors du redémarrage du QA, comme tout programme informatique en fait. On pourrait imaginer sauvegarder cette table dans une variable du QA (donc stocké dans la base de données de la HC3), mais je ne te le conseille pas du tout (impact sur les performances, usure de la mémoire flash) La solution de @jang est élégante, mais ce n'est pas une vraie moyenne glissante comme tu le voulais, et elle ne résout pas non plus le problème du redémarrage du QA. Après là tu as plusieurs notions à prendre en compte : - du LUA pur, mais c'est un faux problème car la manipulation des tables est hyper simple (je t'ai donné les 2 fonctions à utiliser) , donc on en revient à un principe de programmation en général (du coup est-ce que tu es à l'aise sur un autre langage, car tout ceci n'est que de l'algorithme) - des mathématiques.... c'est à dire comment calculer une moyenne glissante - le QA en particulier, et la façon que Fibaro propose pour mémoriser des données de façon persistante Pour ce dernier point, comme dit plus haut, je ne te conseille pas du tout de mémoriser la table complète à chaque passage dans la boucle. De toute façon le QA va calculer sa moyenne glissante via sa table en mémoire vive, et mettre à jour sa propriété "value", puisque ton QA aura comme type "com.fibaro.temperaturesensor" je suppose. Du coup, en cas de redémarrage du QA, dans le onInit() je relirais la valeur courante de la value (puisque celle-ci est bien persistante), et je m'en servirait pour initialiser ma table de 7200 valeurs. Je trouve que c'est un moyen simple et efficace de résoudre la problème du redémarrage du QA.

Sur HC2 j'utilise toujours l'ancienne application, qui existe depuis pas mal d'année. La connexion se fait via le cloud Fibaro, il te faut un compte, avant de choisir la HC2 et de s'y connecter dessus.

Si ça marche touche à rien Faut pas exagérer, incendie aucun risque Mais bon tu devrais les contacter, photo à l'appui.

Possible.. tu le verras facilement si le numéro de série et/ou l'adresse MAC ont changé.

Ah cool Oui parfois ils font payer, d'autre fois non, c'est la loterie, enfin tant mieux pour toi. Du coup j'ai du mal à comprendre quel était le problème.... mais par contre je te confirme que le clé USB recovery ne sert plus à rien et doit être débranchée depuis les firmwares > 4.500 Aïe pour l'antenne, mais du coup tu ne peux plus l'installer ? Ou juste pas la visser à fond ? Parce que ça risque de ne pas bien fonctionner du tout sans antenne... à l'extrême ça peut même cramer le chipset (un appareil avec une antenne doit toujours avoir son antenne connectée... idem pour les routeurs Wi-Fi) Je te conseille sauvegarde locale et cloud. Il y a un script sur le forum pour faire des sauvegardes automatique en local, sur un NAS. Perso il tourne chaque week-end dans la nuit de samedi à dimanche.

Une boucle infinie, avec une table suffisamment grande pour stocker l'historique des mesures sur 5 jours. Par exemple chaque minute sur 5 jours ça fait : 60*24*5 = 7200 éléments dans le tableau, rien de méchant. Puis avec une petite boucle for tu additionnes toutes les valeurs, tu divises par le nombre d'éléments. A chaque passage dans la boucle infinie, il faut faire un table.insert() pour ajouter la nouvelle valeur, et faire un table.delete() si l'historique dépasse 7200 valeurs.

Ah oui alors pour la Téléinfo c'est particulier, j'ai bidouillé, j'ai dédié une fonction spécialement pour cela dans mon QA. Et en effet tu as raison, le compteur remonte, via la Téléinfo, uniquement la puissance apparente en VA (cette information n'est pas utile pour la facturation, mais elle est utile pour faire du délestage, puisque le compteur Linky, ainsi que le disjoncteur de branchement, sont calibrés sur la puissance apparente en VA). Du coup, la puissance active en W est bien la seule valeur que je calcule avec mon QA... en faisant la différence entre 2 relevés de l'index du Téléinfo (toutes les 60s par défaut). Mais ça reste approximatif, puisque du coup ça donne une puissance à 60 Watts près. Outre cette approximation du calcul, c'est reste de la bidouille, de par la façon dont je l'ai implémenté dans le QA. Et en plus, je vais devoir le modifier, à cause du nouveau firmware et du nouveau panneau d'énergie.... pffff..... mais j'ai pas le temps tout de suite.

Non mon QA ne calcule rien, il se contente de remonter les infos délivrées par l'EDRT2/IPX800, ce que tu peux configurer au travers du fichier de configuration (comme décrit dans le tuto). Bref que des infos accessibles via l'API HTTP. Su tu veux faire le calcul de la puissance, il faudrait réaliser un autre QA, et j'envisage la méthode suivante : - à chaque impulsion, l'IPX/EDRT effectue un push vers la HC3 afin d'appeler une fonction - la fonction de ce QA mémorise le timestamp de l'impulsion précédente, et connaissant le nouveau timestamp, il est possible de calculer la puissance. MAIS : - le timestamp est limité à ... 1 seconde près ! Ce qui est très insuffisant - rien ne garantie que la fonction du QA soit exécutée instantanément, elle peut être exécutée quelques secondes plus tard, voire quelques minutes plus tard (voir sujet sur les freeze de la HC3) => tu auras un calcul de la puissance très approximatif, voire carrément faux. Je considère que ce n'est pas une solution viable. Si tu veux connaitre avec précision la puissance et l'énergie consommée par des gros appareils électriques, le mieux reste encore d'utiliser l'Aeotec Heavy Duty. J'en ai un sur ma plaque de cuisson.... mais... ça coute assez cher. Remarque : pas forcément plus cher qu'un IPX800, plusieurs extensions X400CT et autant de pinces ampérométriques et compteurs à impulsion. Donc le bon vieux module Aeotec reste un choix à considérer.

Euh... je vois pas comment tu veux calculer la puissance instantanée si l'EDRT2 ne le fait pas.... parce que l'IPX800, je suis sûr que non, c'est bien pour cela que j'utilise une pince par circuit.

Oui un compteur à impulsion branché sur une entrée numérique utilisée pour le comptage. Sur un IPX, je sais qu'il ne permet pas de calculer la puissance en W à partir du comptage de l'énergie en kWh (il faut une pince en plus pour cela). Mais un EDRT2 peut être, je n'ai pas encore testé... Dans la théorie c'est simple, il suffit de mesurer le temps entre 2 impulsions (1 impulsion = 1 Wh en général) pour obtenir la puissance instantanée. Par contre en pratique, quand l'appareil consomme trop peu et que le temps entre 2 impulsions s'allonge à plusieurs heures, le calcul de la puissance devient impossible (ou alors on arrondi à 0) Je l'avais fait avec un Raspberry PI, mais je cherche à tout basculer sur l'EDRT2, donc faudra que j'étudie ça.

Il faut appeler la méthode updateProperty (la même que tu utilises pour mettre à jour le QA lui-même), sauf qu'au lieu d'utiliser self, il faut utiliser fibaro.call() avec l'IP du QA cible. Par exemple pour mettre à jour la propriété "value" : fibaro.call(ID, "updateProperty", "value", value)