Lazer

Bienvenue sur le forum

On peut s'en servir pour protéger différentes parties du code, mais j'ai envie de dire que c'est obligatoire pour 2 fonctions natives : http:request(), et json.decode() tant ces 2 fonctions ont la fâcheuse habitude de crasher. Et c'est visiblement amplifié avec la dernière Beta.

Tiens voici Attention c'est une BETA, avec beaucoup de traces de logs codées en dur, à installer uniquement pour test Netatmo_2.6_BETA.lua

GEA peut planter, il peut y avoir des bugs, notamment dans la détection des conditions. Mais les actions qu'il réalise sont assez basiques, il se contente d'appeler les actions standards sur les modules via l'API fournie par Fibaro. Du coup quand une action fonctionne sur un module (Z-Wave physique) mais pas sur un QuickApp, c'est que le problème se situe probablement dans le QuickApp de l'utilisateur. Et c'est là toute la magie et la difficulté des QuickApps sur HC3, ils permettent une intégration native dans la box, mais encore faut-il les programmer correctement et penser à tous les cas de figure. Pas toujours simple.

Mais c'est quoi ce QuickApp ? Un QA que tu as créé toi même ? En tout cas, je comprends mieux pourquoi ça ne fonctionne pas. GEA appelle setValue(), et le code de cette fonction setValue ne fait rien du tout (à part mettre à jour le champ value) Je suis pas sûr, mais je pense qu'il faudrait appeler la fonction fcCommands, puisque c'est ce qui est fait dans les fonctions open() et close() Désolé, c'est définitivement HS ici, sur le topic de GEA. PS : Et je maintiens ce que j'ai fait tout à l'heure, si tu fais glisser le slider de ton module volet roulant, que ça soit depuis l'application mobile ou l'interface Web, je vois pas bien par quelle magie ça pourrait agir sur le volet à la lecture du code. Alors c'est sûr, si tu fais juste un open/close complet, ça marche, mais ça limite l'usage.

Bon j'avance, j'ai découvert que le QA plante lors de l'appel http:request() Donc je l'ai modifié pour faire comme dans tous mes QA : pcall() pour protéger l'exécution, et déclaration de la variable http en self.http comme conseillé par Fibaro, et confirmé par nos récents tests avec @henri-allauch On verra comment ça se passe dans les heures qui viennent. L'avantage des firmwares Betas, c'est que ça nous force à écrire notre code LUA plus proprement... ça me rappelle vaguement les heures sombres de la v4 betastable Et dire que j'ai installé cette beta juste pour le correctif de la météo YR Weather, en conséquence ça fait planter la météo Netatmo, c'est comique. PS : j'aime beaucoup mon statut de Newbie 1 étoile sur le forum officiel

Perso je n'ai pas le temps de relire et modifier ton code, mais une piste quand même : sur HC3 les accès réseaux sont asynchrones (comme pour les scènes sur HC2 d'ailleurs). Tu peux regarder ce tuto pour des requêtes HTTP, le principe est le même pour TCP : Et en complément, en pratique tu as mon QuickApp Onduleur Eaton sur le forum, qui utilise des requêtes TCP pour le protocole SNMP, ça pourrait te servir d'exemple :

Il faut cliquer sur le bouton - en haut de la page Et c'est normal, il faut recliquer dessus si tu quittes la page des dispositifs et que tu retournes dessus ensuite.

Ah yes, génial, belle bête Tu dois bien t'éclater avec ça

Donne moi le lien vers le QA, j'irai regarder comment il est fait

Ah OK. Bon j'ajouterai le login/password dans une prochaine version alors. Pour ton second point, voilà exactement ce pour quoi GEA n'est pas fait !!! C'est une gestionnaire de scénario avant tout. Pour ton usage, tu peux utiliser un QuickApp (ou une scène) dédié, comme je fais avec DomoCharts par exemple, ou aussi @jjacques68 avec sa propre base de données.

Bienvenue sur le forum

Euh... si, les ID multiples sont censés être pris en compte pour les actions Open et Close, c'est étrange ça. Il faudra que je fasse des tests alors. @manulemalin concernant tes volets RTS, si ça ne fonctionne pas, c'est que tes modules ne sont pas correctement configurés. Un com.fibaro.rollerShutter doit toujours répondre aux actions Open et Close. D'ailleurs si ce n'est pas le cas, alors ils sont probablement également inutilisable depuis l'interface Web ou l'application mobile. Mais je pense que c'est totalement hors sujet ici. Je ne connais pas du tout ce QuickApp, il faut que tu ailles demander à son développeur. Je n'ai pas implémenté les login/password pour les requêtes http, donc ça ne fonctionne probablement pas dans l'URL, ce qui est normal (c'est une syntaxe qui n'existe que dans les navigateurs Web, et qui d'ailleurs est fortement déconseillée depuis pas mal d'année....). Je l'ajouterai à l'occasion, mais par contre, si c'est pour faire une requête de la box Fibaro, je ne vois pas l'intérêt de passer par ce chemin là ? Tu peux soit utiliser une option native de GEA, ou bien utiliser getApi L'option httpGet, je l'ai pensé pour d'autres usages, par exemple appeler une URL sur un NAS, un objet connecté, etc. Elle est très limitée car GEA n'a pas non plus vocation à devenir un outil pour traiter des données externes, pour cela il vaut mieux avoir sa propre scène/QA à coté, éventuellement appelé par GEA

1/ Compteur d'eau Ta ligne est OK, mais tu as forcé l'unité sur mètres cubes, c'est peu courant, en général on utilise des litres (bon suffit de multiplier par 1000... ou dans ton cas de NE PAS diviser par 1000). En tout cas cela explique pourquoi ça ne remonte pas dans DomoCharts, qui ne prend que les modules de type com.fibaro.multilevelSensor en litres et en litres par minute (unités "l" et "l/min") 2/ Là c'est pas bon du tout, le type Teleinfo c'est exclusivement pour la Teleinformation, comme indiqué dans l'exemple en 1ère page et dans le fichier de config. Dans ton cas ce serait plutôt le type PowerSensor qu'il faudrait utiliser. Et inutile de forcer l'unité, elle est automatiquement configurée sur Watts par défaut pour ce type. 3/ Pour le cout, tout dépend de comment tu as configuré tes postes et sous-postes dans l'EcoDevices RT2. Là tu as pris le Poste 1, le QuickApp se contente de remonter l'information calculée par l'EDRT2.

Le miens n'a pas craché, il a tourné toute la nuit jusqu'à maintenant sans problème. Mais sur le forum officiel, ils ont testé avec le math.floor, et aussi de remettre un intervalle fixe de 5 minutes (au lieu de mon intervalle qui s'ajuste aux 10 minutes de l'API remontée par Netatmo), et ça ne change rien, plantage quand même : https://forum.fibaro.com/topic/53868-the-“netatmo-weather-station-qa-for-hc3”-has-stoped-working-since-5063-installed/ C'est mystérieux. J'ai vérifié tous mes propres QA, y compris le gros GEA, et aucun n'a de problème, il n'y a que le Netatmo qui pose souci... et comme je ne suis pas l'auteur original, je ne maitrise pas vraiment le code, donc difficile de rentrer dedans.

Justement, c'est le cas dans tous mes QA, exactement comme pour les VD (et scènes) "Total memory in use by LUA ..." => cette ligne a un double avantage : en plus d'apparaitre toutes les 5 minutes, elle permet également de surveiller la consommation mémoire Franchement y'a rien d'extraordinaire, toute la logique du Watchdog a été développée à l'époque de la HC2, et c'est ultra robuste, je n'ai jamais eu à revenir dessus. Je pensais juste pouvoir l'éviter sur HC3, mais en fait non, il vaut mieux le porter, je m'en rend compte à la lumière du problème survenu avec ce QA Netatmo.

Parfait, ainsi tu pourras nous faire un beau QA

Voilà Aller, je vais m'y mettre... vu que j'ai fini les QA en cours, c'est l'occasion où jamais

Oui mais là le QA n'a pas planté, il s'est arrêté de fonctionner. Ce n'est pas pareil. Mon Watchdog ne fait pas que chercher les erreurs, il recherche également la présence régulière d'une chaine de caractère... ça fait toute la différence, car on peut détecter quand un QA s'est arrêté de fonctionner. D'ailleurs la HC3 fait la moitié du boulot, car quand un QA plante sur erreur, elle le redémarre automatiquement la minute suivante (donc ta boucle de refreshState ne fait pas mieux).

Il semble que ça soit lié au niveau firmware 5.063.30 - BETA sorti hier Pour commencer je te propose d'ajouter un math.floor() au setTimeout() de la ligne 221 comme suit : fibaro.setTimeout(math.floor(waitDelay*1000), function() self:loop() end) J'ai fait la modif de mon coté, je laisse tourner quelques temps, on verra si le problème se reproduit. Je me dit qu'il va falloir que je fasse un Watchdog pour les QuickApps comme on avait sur HC2....

Mince oui tu as raison, je me rend compte que la version initiale de GEA n'avait tout simplement pas de fichier tools, donc il faut le créer en cliquant sur le bouton "+", puis il faut le nommer correctement en cliquant sur le crayon :

Tant mieux Le fichier de syntaxe n'est pas aussi complet (moins didactique) que le Wiki initial présent sur le NAS de @Steven mais j'y ai intégré ce que j'ai pu récupérer dans le cache de Google. main et tools, ce sont les fichiers qui contiennent le code LUA de GEA. En temps normal il ne faut jamais y toucher, sauf dans le cas d'une mise à jour d'une nouvelle version. Comme Fibaro ne propose pas de mécanisme permettant de mettre à jour un QuickApp existant, on ne va pas s'amuser à importer un nouveau QuickApp à chaque nouvelle version, ce qui créerait un nouveau module, avec un nouvel ID, etc. Donc je propose le partage du contenu des fichiers LUA, qu'il suffit de copier/coller dans leur intégralité pour remplacer l'existant. Le fichier config, lui, est bien celui que tu dois modifier pour créer tes propres règles personnalisées. C'est un mécanisme que j'adopte dans tous mes QuickApps que je partage sur le forum, à défaut d'avoir mieux. Fibaro proposera surement un mécanisme plus abouti de téléchargement direct de QuickApp depuis la Market officiel, avec gestion des mises à jours, code protégé contre la lecture/écriture, etc mais d'ici là le Covid ne sera qu'un lointain souvenir (ou pas)

Publication en 1ère page de la version 7.01 : v7.01 : Mars 2021 Correction des consommations d'énergies électriques quotidiennes qui ne sont pas générées dans certain cas Pour la mise à jour du QuickApp existant, simplement copier/coller le contenu du fichier main pour le remplacer.

Nouvelle version 1.10 en première page : v1.10 : Mars 2021 [IPX800] Correction de l'inversion des volets roulants [IPX800] Ajout des formules pour la sonde TC-100 (capteur de température) [IPX800/EDRT2] Ajout du support de l'extension X-THL (sonde de température/humidité/luminosité) [IPX800/EDRT2] Ajout du support de l'extension X-4FP (fil pilote) [EDRT2] Ajout du support des abonnements TEMPO et EJP [EDRT2] Ajout du support du compteur Linky en mode téléinfo standard [EDRT2] Ajout du support des commandes "DIndex", "Price" et "DPrice" Vous pouvez soit importer le fichier FQA pour créer un nouveau QuickApp, soit mettre à jour l'existant en copiant/collant le contenu des 3 fichiers main, GCE, et tools.

C'est moi qui avait introduit ce changement, pour optimiser les requêtes. On regarde l'heure de dernière remonté des infos de la station vers le Cloud Netatmo, et ensuite on programme (setTimeout) les suivants 10 secondes après. Cela permet de minimiser le retard de remonté des infos dans la HC3, donc d'avoir des mesures les plus récentes possible. Je n'ai jamais constaté de bug sur mon installation (pas d'escalier, les courbes sont bien linéaires) Sauf... depuis hier ! Je constate un plantage... le QA a l'air de tourner, mais les valeurs ne se mettent plus à jour. Je vais investiguer...