Lazer

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)

Cool Étrange quand même ce bug...

Oui ça va venir. Cette semaine, c'est un autre acteur majeur, Samsung, qui a annoncé préparer son écosystème SmartThing pour le rendre compatible avec Matter... et surtout hors cloud [Frandroid] Pour mieux gérer la maison connectée, Samsung a une solution pour se passer du cloud

Voilà....

Je ne sais pas, mais tu as oublié la fin de la phrase, ça concerne les polonais, donc on n'est pas concerné du coup.

Oui c'est bien celui là. Du coup, si ça se trouve, pour procéder à l'exclusion puis l'inclusion, il faut faire l'inverse, c'est à dire libérer ce contact... ce qui implique que tu devras décoller le module. Je dis ça, mais c'est une supposition... j'espère que tu ne m'en voudras pas si après décollage ça ne fonctionne pas mieux.

Apparemment la seule nouveauté de cette version 5.080.12 par rapport à la 5.080.9 est : > The version 5.080.12 adds full support for the PKO Smart Home program available on the territory of Poland. Dommage que le changelog ne soit pas plus clair, car ils reprennent la liste de la stable précédente.

Il me semblait avoir mis un délai entre 2 retry de 1 seconde, mais apparemment ce n'est pas le cas (ça devait l'être sur HC2) Chez moi j'ai certains appareils avec jusqu'à 8 retry. Mais attention, tu as aussi un paramètre timeout sur lequel il faut jouer. J'ai jusqu'à 10 secondes pour certains appareils qui sont trop lents à répondre. La plupart des exemples donnés en haut de page ont un timeout de 1 seconde, ce qui est trop court. Donc si on met 8 retry avec un timeout de 10 seconde, ça laisse quand même 80 secondes à l'appareil pour se réveiller, ça devrait être large, sinon c'est que tu as un autre souci. Le numéro de ligne peut varier selon ta config, donc si tu veux faire la modif pour ajouter un délai entre 2 retry, voici le bloc concerné, il y a 2 lignes setTimeout() à modifier : remplacer le 0 par 5000. -- New try if device.protocol == "tcp" then fibaro.setTimeout(0, function() self:connectTCP(device, try+1) end) elseif device.protocol == "http" or device.protocol == "https" then fibaro.setTimeout(0, function() self:requestHTTP(device, try+1) end) else self:error("Unknown protocol :", device.protocol) end

Repose en paix.

C'est un bug, Fibaro est au courant et censé le corriger, mais apparemment ce n'est pas encore le cas.