Lazer

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)

Oui oui c'est très bien 50%, aucune inquiétude à avoir Je ne me souviens plus trop, mais je crois qu'une box neuve, sans rien, doit être autour des 40%.

Le compteur MID comptera l'énergie en kWh, donc tu devrais avoir un résultat précis... de ce qui est facturé ! Mais ça ne donne pas la puissance instantanée en Watts. En fait le compteur c'est complémentaire de la pince ampèremétrique.... j'utilise plusieurs couples de chaque pour mesurer différents circuits chez moi, tous reliés à un IPX800 (mais un EDRT2 ferait aussi bien). Le souci du Cos Phi moyen utilisé par l'EDRT2 est un vrai problème, qui a justement été discuté récemment ici-même... il n'y a rien qu'on puisse faire à part remonter le problème sur le forum GCE Electronics en espérant qu'ils puissent trouver une solution. Perso comme j'ai branché mes pinces sur l'IPX800 via l'extension X400-CT, je peux appliquer manuellement en coefficient sur chaque formule analogique afin de compenser le Cos Phi (d'ailleurs c'est faux, on devrait parler de facteur de forme) En tout cas une chose est sure, le FGBS Smart Implant n'est pas utilisable en compteur d'impulsion, tu vas louper des impulsions, ce n'est pas prévu pour. Le mieux reste l'entrée numérique d'un EDRT2 ou IPX800... mais c'est cher, sinon il faut se tourner vers un Arduino, Raspberry PI, etc, mais il faudra coder un peu.

Non ta RAM n'est pas à 89%, car à tous les coups du regardes le mauvais graph. Le problème existe depuis la HC2, je ne sais pas pourquoi Fibaro continue d'afficher ce graph qui perturbe tout le monde (enfin, 99% des gens, c'est à dire ceux qui ne connaissent pas Linux) Exemple : je suis à 66% de RAM utilisée, et non pas à 94% (et pour le coup ma box est pas mal chargée, mais je sais pourquoi, j'ai un QuickApp trop gourmand) => L'espace tampon et le cache ne comptent pas dans la RAM utilisée.

Super réactif, je suis impressionné, ils sortent une stable en plein été, avec des petits bugs qu'ils corrigent dans la foulée au mois d'août avec 2 nouvelles stables successives. Le rachat par Nice semble avoir du bon en fin de compte

Ah mais clair, ça confirme ce qui avait déjà été annoncé, CHIP prévoie un fonctionnement autonome en local des fonctions de base de la domotique. Le cloud sera une option pour des services additionnels (accès distant, assistants vocaux, interconnexion avec les IOT, etc.... ou de futurs services à inventer)