jjacques68

bon et bien j'ai trouvé ce qui cloche : dans une méthode d'un Child, ça ça marche pas : function MyClass:MyFunc() function Func() setTimeout(function() Func() end, 1000) end Func() end Je sais qu'on aurait pu aussi faire : function MyClass:MyFunc() setTimeout(function() self:MyFunc() end, 1000) end Par contre ça ça marche. Mais dans mon premier exemple, c'était pratique si on a plusieurs fonctions qui doivent s'enchainer : function MyClass:MyFunc() function Func1() setTimeout(function() Func2() end, 1000) end function Func2() setTimeout(function() Func3() end, 1000) end function Func3() end Func1() end enfin ça fonctionne si 1 QA tourne, si plusieurs, ça se mélange. Je sais pas pourquoi. J'ai essayé avec "local function" dans la méthode mais c'est pire. ? ? ?

alors visiblement j'ai résolu le problème. je n'arrive pas à expliquer comment... tu m'as mis la puce à l'oreille avec les self... J'ai décalé toutes mes variables dans le "__init" du Child. Je fais appel avec "self.---" La fonction "post", j'en ai fait une méthode seule, que j'appelle avec "self:post()" et j'ai une bonne indépendance des Child avec ça maintenant. Mais je comprends pas pourquoi, ça m'énerve, c'est le bordel dans ma tête

Ben il me semble que c'est que je fais, la méthode wakupStart() s'auto appelle ? nan ? EDIT : nan en fait nan, elle ne s'auto appelle pas, ce sont des fonctions locales à l'intérieur de wakupStart qui s'auto appellent...

je pensais avoir bien fait en mettant tout en local dans une fonction, qui devrait être propre à chaque Child...

@Lazer : attention 731 et 732 sont les ID de QA et non des dimmer !

je me posait la question justement de la porté de ces variables et du fameux "self" dans un QA Child...

Punaise j'ai exactement le même comportement avec mes QA Child des caméras pour la gestion de la patrouille. Même principe, j'ai un "handler" pour les faire bouger. Si les 3 patrouillent en même temps, ça se prend les pied dans le tapis. Inquiétant ça !

Je reviens dans le sujet tu topic avec un problème... très très très très étrange, limite délirant du comportement des 2 QA réveil : J'ai l'impression que les 2 child se marchent dessus, comme s'ils n'étaient pas si indépendant que ça !!! J'espère que c'est moi qui fait mal qqch, parce que sinon ça remet en cause le principe des QA Parent/Child !! Je m'explique : Dans la class "WAKEUP" de ces QA, j'ai une méthode "wakeStart", sorte de handler, qui me permet de gérer un allumage progressif de mes lumières. le voici simplifié et raccourci : "idLight" est une variable propre au Child qui stocke l'ID du dimmer qu'il doit gérer. désolé c'est pas de tout repos de devoir lire ça... --[[-------------------------------------------------- WAKEUP : wakeStart ----------------------------------------------------]] function WAKEUP:wakeStart() local idLight = self:getVariable("idLight") local handlers = { -- Début du cycle de réveil-------------------------------------------- start = function(arg) self:debug(self.id, "start") post({next='incValue',setValue=1}) end, -- boucle Allumage progressif ------------------------------------------- incValue = function(arg) --sort du cycle d'allmuage si lumière > 98 % if fibaro.getValue(idLight, "value") > 98 then post({next='wait'}) else self:debug(self.id, arg.setValue, "%") fibaro.call(idLight, "setValue", arg.setValue) post({next='incValue',setValue=(arg.setValue+1)},9*1000) end end, [...] } --[[--------------------------------- -----------------------------------]] --fonction appelante function post(arg, time) fibaro.setTimeout(time or 0, function() handlers[arg.next](arg) end) end --déclenche le cycle post({next='start'}) end Alors ça fonctionne super bien si UNE SEULE LUMIERE est actionnée. Donc un seul QA (donc un seul réveil) Si je mets les 2 lumières, ça se prend les pieds dans le tapis. Une des 2 ne continue pas son cycle d'allumage. Voici le debug qui rend ça bien visible et pourra peut-être aider à comprendre : J'ai donc appelé la méthode "wakeStart" des 2 QA à 12h30. 731 = l'ID du child pour le réveil "de gauche" 732 = l'ID du child pour le réveil "de droite" On voit bien qu'ils ont bien démarré ! que la graduation des dimmer se fait bien à la première boucle de la fonction "incValue" ! et c'est après que ça déconne !!!! On a l'impression que les 2 child ont fusionné ! Le QA 731 est comme qui dirait passé sur le QA 732 ! Et le dimmer associé ne progresse plus bien sûr... D'où peut provenir un tel comportement ? C'est délirant ! voir limite énorme ! Je précise que ma class "WAKEUP" est écrite dans un fichier autre que le main... je sais pas si ça a de l'importance... EDIT : j'ai placé la class dans le main, ça a rien changé au comportement...

merci pour ces clarifications ! ça s'éclaircit j'aurai sans doutes d'autres questions

ah merde j'avais vu le coup du put !! nickel edit : je voulais dire, que j'avais PAS vu ... foutu clavier...

mais ça semble ok là ? nan ?

ouai ben là, sans avoir le module, ça va être dur... tu devrais fouiller sur dans le forum où sur le forum officiel peut-être... désolé...

alors je n'ai aucune idée, au culot, si tu essayes ça : params = { data = '{scene:IHUqzUSmWfiC9n}', description = description } ça sent de nouveau le formatage de chaine...

alors là ?? ne connaissant pas HUE.. par contre si je regarde tes captures précédentes : il manquerait le mot clé "scene" dans les paramètres nan ?

c'est quoi le message d'erreur ?

ok. donc il faudrait stocker cette valeur de any_on dans une variable du QA avec success = function(response) self:debug("response status:", response.status) self:debug("headers:", response.headers["Content-Type"]) local data = json.decode(response.data) self:debug("any_on = ", data.state.any_on) self:setVariable("anyOn", data.state.any_on) --self:debug("all_on = ", data.state.all_on) end, du coup tu peux utiliser la variable "anyOn" comme tu veux.

maintenant je sais plus ce que tu voulais faire avec

hé bé enfin

punaise oui et maintenant ? success = function(response) self:debug("response status:", response.status) self:debug("headers:", response.headers["Content-Type"]) local data = json.decode(response.data) self:debug("1 = ", json.encode(data.state)) self:debug("any_on = ", data.state.any_on) self:debug("all_on = ", data.state.all_on) end,

success = function(response) self:debug("response status:", response.status) self:debug("headers:", response.headers["Content-Type"]) local data = json.decode(response.data) self:debug("1 = ", json.encode(data.state)) end,

success = function(response) self:debug("response status:", response.status) self:debug("headers:", response.headers["Content-Type"]) local data = json.decode(response.data) self:debug("1 = ", data.state) end, et maintenant ?

ah ! et maintenant ? success = function(response) self:debug("response status:", response.status) self:debug("headers:", response.headers["Content-Type"]) self:debug("1 ", response.data.state) end,

roah punaise c'est frustrant, on est vraiment pas loin... comme dis, juste un problème de syntaxe, essaye dans le success : success = function(response) self:debug("response status:", response.status) self:debug("headers:", response.headers["Content-Type"]) self:debug("1 ", response.data) local data = json.decode(response.data) self:debug("2 ", data) end,

Hello tout le monde ! j'utilise depuis le début de la HC3 l'API "debugMessages", afin de récupérer les messages (debug, trace, warning, error) pour les insérer en base. Je me suis rendu compte que je loupais de temps en temps des infos. Voici le panel de l'API : alors il faut savoir que si on met rien dans le paramètre "offset" il nous retourne que les 30 derniers... (d'où mes loupés... ... ...) En fait, je souhaite tout simplement, à chaque fois que j'interroge l'API, récupérer tous les messages depuis la dernière interrogation. Là j'arrive à faire ce que je veux avec : local MonContenu = api.get("/debugMessages?from="..self.lastCheck.."&last=0&offset=200").messages Mais j'ai du faire une usine à gaz de code pour arrivé à mes fins : A chaque boucle, je mémorise le timestamp du 1er message ainsi que son ID (attention le premier message est le plus récent) ensuite pour la prochaine interrogation, j'utilise le paramètre "from" dans lequel je lui glisse le memo du timeStamp précédent. ça marche très bien, sauf qu'il m'inclus dans la requête, CE memo du timeStamp (c'est clairement stipulé !! - younger than or equal) Donc j'ai des doublons maintenant. j'ai mis le paramètre "last" à 0. Sa définition est pas très clair... et le paramètre "offset" à 200. Le valeur -1 qui m'intéresserait ne marche pas. il comprends "1" !! Donc en français ça donne : je récupère les 200 derniers nouveau messages depuis le timeStamp mémorisé. et pour virer les doublons, si l'ID du message en en cours <= l'ID mémorisée alors je l'oublie. Mais ce serait tellement plus simple de pouvoir récupérer les messages dont l'ID est supérieur à la valeur donnée !!! Ce que devrait faire le paramètre "last", sauf que si on lui donne une valeur, il renvoie les messages inférieurs à cette valeur !!! Je me plante complètement de raisonnement, où y a des loups cachés qqpart ?? Ensuite quand on observe le JSON de réponse, il y a cette info : Quelqu'un a une idée de ce que c'est ? C'est un ID c'est sûr, mais je n'arrive jamais à voir le message correpsondant à cet ID ?? merci pour vos conseils !!! PS pour ceux que ça intéressent voici le code de la fonction dans mon QA : function QuickApp:Check() if self.properties.value == true then --recupère les data de l'API local MonContenu = api.get("/debugMessages?from="..self.lastCheck.."&last=0&offset=200").messages --pour chaque ligne for MaLigne = 1, #MonContenu do --si on trouve des ID inférieur au mémo alors on oublie (= doublon) if MonContenu[MaLigne].id <= self.memoID then break end --créé la chaine pour envoyer sur la socket local MaData = os.date("%d/%m/%Y %H:%M:%S", MonContenu[MaLigne].timestamp)..";".. MonContenu[MaLigne].id..";".. MonContenu[MaLigne].type..";".. MonContenu[MaLigne].tag..";".. json.encode(MonContenu[MaLigne].message) --l'envoie en base fibaro.call(487,"AddElement", "LOG;"..MaData) --envoi des erreur par mail si option activée if MonContenu[MaLigne].type == 'error' and self:getVariable("SendError") == "1" then fibaro.call(457, "SendMail", MaData) end end --mémorise les infos pour la prochaine boucle (l'élément 1 du tableau sera le dernier élément lors de la prochaine boucle) self.lastCheck = MonContenu[1].timestamp self.memoID = MonContenu[1].id end --bouclage setTimeout(function() self:Check() end, tonumber(self.TimeLoop)) end

J'ai bien lu tes explications. Je comprends la notion de class et d'héritage, d'instanciation, ... Mais pas évident de faire la parallèle sur la HC3 ! avec ce que du dis et ce que j'imagine, je dirais (on va voir si j'ai compris qqch ) 1ère couche : on a une class principale "Fibaro" (qui inclut des "composants" comme math, json, string, fonction spécifiques à Fibaro, ...) 2ème couche : une class "QuickApp" qui hérite de "Fibaro" (avec des fonctions, variables propres au QA en plus) qu'on utilise quand on créé un QA simple 3ème couche une class "QuickAppChild" qui hérite de "QuickApp" qu'on utilise pour les QA avec Child ou plutôt pour les Child des QA On pourrait pas créer une autre class QuickAppChild ou encore QuickApp ? En les appelant autrement biensûr... (j'en vois pas l'intérêt, mais ce serait possible ?) et ça me fait rebondir sur ton QA qui permet de lister les variables, fonctions et objects disponibles. Ce sont des éléments de la class QuickApp alors ? Les variables sont les attributs, les fonctions sont les méthodes ? où on est encore une couche plus haut ? vu qu'on retrouve des similitudes avec les scènes d'ailleurs les scènes se placent où dans tout ça ? merci d'avance !!