jjacques68

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 !!

J'ai fait le test pour les QA en version 5.061.36, et la seule chose en plus est dans les objets : net.UDPSocket => userdata net.WebSocketClient => userdata net.WebSocketClientTls => userdata et je pense que ça date d'avant cette mise à jour...

Je sais pas, aussi étrange que cela puisse paraitre, mes boutons de backup local sont grisés !!!! EDIT : de nouveau fait mon boulet, ils sont grisés car j'avais déjà 3 backup local stockés dans la HC3. Je confirme comme @Krikroff, l'option est sur les 2 types.

ah zut, faut le faire au moment du backup... @Lazer ? va falloir que tu modifie le script de backup auto pour tenir compte de cette option non ? vais me faire envoyer promener, je le sens...

c'est où ça quelqu'un l'a vu ?

Je viens de faire cette mise à jour, bon mon vieux !! c'était LA-BO-RIEUX !!!!! Mise à jour, assez rapide. Après don redémarrage, panique complet. Tous mes QA qui utilisent les socket ehternet = tentative de connexions en boucle, sans respecter le timeout de 3s que j'ai mis en place. Reboot de la HC3. ça a mis trois plomb. Socket OK. Moteur Z-wave a mis plus de 10 minutes à se mettre en route !! CPU à 100 % un core après l'autre pendant ces 10 minutes. et tout d'un coup c'est ok. On dirait qu'elle est plus réactive ? ou c'est une impression ? Je le constate à l'usage du CPU...

oh punaise ! il va falloir que je lise ton explication plusieurs fois !! merci pour ta patience !!

si si tout à fait, dans mon cas précis, j'ai qu'un seul type de child, les binarySensor...