Barelle

Alors le mystère reste entier

A la vue des traces communiquées, j'avoue avoir du mal à faire le lien avec la variable globale. Ce qui est certain, c'est que dans la fonction changePeriode, on vérifie que les derniers index sont bien supérieurs aux précédents, sinon on les remets à zéro, puis on les mémorise dans la variable globale. Le surprenant est que dans les données directement lues de l'EcoDevices, les index sont nuls et on y trouve même les champs T1_BASE et T2_BASE qui ne devraient même pas exister dans le cas d'un abonnement HPHC : { "product": "Eco-devices", "T1_PTEC": "----", "T1_PAPP": 0, "T1_BASE": 0, "T2_PTEC": "----", "T2_PAPP": 0, "T2_BASE": 0, "INDEX_C1": 11463, "INDEX_C2": 0 } Bug de l'Ecodevices ? Dans quel version est-il ( la dernière est la 1.05.25) ?

Alors là, je sèche... Il paraît que la nuit porte conseil, je m'inscris en faux contre une généralisation de cet adage. Le constat : dès la lecture de la trame de l'EcoDevices, les données reçues sont erronées : Présence des champs T1_BASE et T2-BASE alors que l'abonnement parait être en HPHC ; Donc, et en bref : La trame reçue ne comprend pas les données attendues. Quels sont les changements effectués avant l'arrêt du bon fonctionnement ? Utilises-tu bien la version originale du QA que j'ai posté ? Sinon, vérifie ton code ou envoie moi ton fichier fqa.

Ben, le diagnostic est aisé : readEcodevices>>>OK, response.data={"product":"Eco-devices","T1_PTEC":"----","T1_PAPP":0,"T1_BASE":0,"T2_PTEC":"----","T2_PAPP":0,"T2_BASE":0,"INDEX_C1":11463,"INDEX_C2":0} ton EcoDevices ne renvoie que des zéros, sauf pour C1... Si tu rentres "http://aaa.bbb.ccc.ddd/api/xdevices.json?cmd=10" avec aaa.bbb.ccc.ddd l'adresse IP de l'EcoDevices dans un navigateur, quelle est la réponse ?

Regarde les premières lignes de log, juste après le démarrage du QA. Selon le log que tu as communiqué, toutes les variables sont présente dans la variable globale (cf. compteur), mais elles sont toutes à zéro sauf pour T1.

Tout est à zéro dans la variable compteur, j'ai l'impression que la télérelève de l'Ecodevices ne fonctionne pas. Essaie t'y connecter directement pour voir.

Quels sont les messages de log lors du lancement ?

Je suis surpris... et tant mieux

Si la prise et le volet sont sur le même disjoncteur, cela ne pose pas de problème technique, mais montre que l'installation n'est pas aux normes.

self:updateProperty("log", "GOOD") devrait fonctionner.

Alors, le lua Fibaro prend des initiatives... Et avec : MaVar[tostring(8)] ou MaVar["8"]

Et le json.decode ?

Ben ça marche un tableau dans une variable de QA : local tableau = { [1] = "un", [2] = "deux", [3] = "trois", } self:setVariable("tableau", tableau); local tab = self:getVariable("tableau"); self:trace("type(tab)=", type(tab), ", tab[2]=", tab[2]); ou pour avoir quelque chose de lisible, on emploie le format json : local tableau = { [1] = "un", [2] = "deux", [3] = "trois", } self:setVariable("tableau", json.encode(tableau)); local tab = json.decode(self:getVariable("tableau")); self:trace("type(tab)=", type(tab), ", tab[2]=", tab[2]);

Je suis bien d'accord, ce n'est pas la bonne syntaxe, essaie plutôt : local EcoDevice = fibaro.getGlobalVariable("EcoDevices"); self:trace("type(\"EcoDevice\")", type(EcoDevice)); -- string EcoDevice = json.decode(EcoDevice); self:trace("type(\"EcoDevice\")", type(EcoDevice)); -- table local consoActuelleWh = coDevice.teleinfo1.consoActuelleWh; self:trace(EcoDevice.teleinfo1.consoActuelleWh) avec quelques traces pour aider à la compréhension...

Désolé, une mauvaise manipulation sans doute, le zip vient d'être mis à jour.

Merci de ce rappel, toutefois, quand une fonction n'est pas déclarée locale, elle est visible depuis l'intérieur des autres fonctions déclarées avant. Alors que comme le montre mon exemple ce n'est plus vrai dans le cas d'une fonction locale qui ne devient visible que de l'intérieur des fonctions déclarées après. Après vérification, ce comportement se retrouve pour tous les types de variables, ce qui est parfaitement logique.

Une dernière remarque, si l'on déclare une fonction locale, elle n'est visible dans un bloc de niveau inférieur que si elle est déclarée avant. Ainsi : Ce code fonctionne : local function toto(self) self:trace("Je suis Toto"); end function QuickApp:onInit() toto(self); end Quand celui-ci ne fonctionne pas : function QuickApp:onInit() toto(self); end local function toto(self) self:trace("Je suis Toto"); end On obtient l'erreur : [18.03.2021] [22:07:23] [ERROR] [QUICKAPP92]: QuickApp crashed [18.03.2021] [22:07:23] [ERROR] [QUICKAPP92]: main.lua:20: attempt to call a nil value (global 'toto') Il convient alors d'écrire : local toto; function QuickApp:onInit() toto(self); end local function totofct(self) self:trace("Je suis Toto"); end toto = totofct; Pour obtenir le bon fonctionnement de cet indispensable QA.

Un quickApp mineur

Oui, sauf à la déclarer pour qu'elle appartienne à la classe QuickApp : function QuickApp:mainLoop()

Je suis d'accord sur tout sauf sur N'oublions pas le fameux vol d'Ariane 5, je cite wikipedia :

Un rapide exemple, mais non testé... local delay = 60; -- la variable sera visible par l'ensemble du code function QuickApp:onInit() -- On prépare l'environnement d'éxécution : -- - vérification de la cohérence des variables -- - récupération des éléments nécessaires -- - initialisation des childs -- - ... local ok, err = pcall(function() mainLoop(self); end) if not ok then self:error("onInit>>>Error calling mainLoop : ".. err); end end -- QuickApp:onInit function mainLoop(self) -- On passe self en paramètre pour pouvoir utiliser les fonction natives du quickapp comme self:trace, self:debug... -- -- On fait le boulot -- processLeBoulot(self); fibaro.setTimeout(delay * 1000, function() mainLoop(self); end); end -- mainLoop function round(num, numDecimalPlaces) -- On ne passe pas self en paramètre car on n'en a pas besoin return tonumber(string.format("%." .. (numDecimalPlaces or 0) .. "f", num)); end -- round function processLeBoulot(self); self:debug("Silence, je bosse !"); self:trace("pi avec 2 décimales : ".. round(math.pi, 2)); end -- processLeBoulot

Oui on peut passer l'intervalle en paramètre, mais cela est inutile s'il est déclaré local au quickapp, étant visible par l'ensemble du code. Pour la seconde partie de ta réponse il me semble que tu crées de la confusion entre la visibilité des variables et la structure modulaire du code qui me semble être deux notions distinctes : Déclarer QuickApp:fonction(a, b) ou fonction(self, a, b), la seconde écriture demande moins de caractères... Et lors de l'appel self:fonction(a,b) et totalement comparable à fonction(self, a, b). Encore faut avoir le besoin du self dans la fonction. L'utilisation de fichiers pour améliorer la modularité du code est un choix du développeur, pour avoir par le passé travailler sur des fichiers sources de plus d'un million de lignes, si ceuc-ci sont bien structurés, cela ne présente pas de difficultés particulières. Je crois que ce choix de la multitude de petits fichiers (pas de de 1000 lignes par fichier, une fonction ne doit pas dépasser 24 lignes...) est issue du monde Unix à l'époque de machines ne disposant que de mémoire dont la taille était exprimée en ko (dans le même ordre d'idée l'emploi d'accolades pour délimiter les blocs en langage C, en lieu et place des BEGIN et END de l'Algol et de ses dérivés - Pascal, Modula 2... - n'avait pour objectif que l'économie de mémoire pour l'éditeur). Je suis septique quand à la différence de rapidité du copier/coller entre un fichier complet et une partie de fichier, je pense que dans le second cas, on est plus vigilant.

Pour avoir la visibilité sur les fonctions déclarées comme rattachées à la classe QuickApp. QuickApp:fonction(a, b, c) est syntactiquement équivalent à fonction(self, a, b, c). Dans ce dernier cas fonction est locale au quickapp sans appartenir à la classe QuickApp...

@Lazer, juste histoire de polémiquer un peu : Totalement d'accord avec ton propos, aussi, dans ton exemple, il est inutile d'utiliser une variable self.refreshInterval, quand une variable refreshInterval déclarée locale avant la déclaration de la QuickApp:onInit(). Dans le même ordre d'idée pour limiter la portée des variables, à quoi bon déclarer function QuickApp:loop() quand function loop(self) permet le même usage en restreignant, de plus, la visibilité de la fonction loop à du code externe, se qui ne peut que concourir à la robustesse du code ?

Ceci pourrait sans-doute correspondre à ton besoin...