jjacques68

ok, I understand. I had problem in a function in a class with variable (I think...). It seemed to mix with another childs ?? (see the message above, with "WAKEUP" class...) function myClass:Func1() local var1 local var2 end when I declare the variables in the "__init" of child, it works fine. I don't understand why.

alors vous je sais pas, mais moi, depuis cette version, à chaque redémarrage de la box, j'ai des soucis avec l'ouverture de mes socket, que je n'avais pas avant !! l'ouverture tourne en boucle sans arriver à se connecter. alors ça vient peut-être de ma manière de coder, mais quoi qu'il en soit, j'ai décaler de 30 secondes l'ouverture des socket, et la plus de soucis, connexion du premier coup à chaque reboot. étrange...

oui le tout est de s'y retrouver... mais y a toujours cette zone d'ombre quant à la porté des variables déclarées dans un child... et le "self"...

tout à fait, là c'est un exemple, dans mon cas elles sont différentes justement. ah mais là je te suis pas ! Les child devrait pouvoir avoir leurs propres méthodes qui s'exécutent tout à fait indépendamment les uns des autres ainsi que du parent ! Mes réveils sont un bon exemple. le premier déclenche à 7h00 le second peut déclencher à 7h01 si je veux. Ils ont un cycle d'allumage particulier. Ils doivent être les 2 autonomes et le parents ne gère rien du tout dans l'histoire. Ce ne sont que les variables propres aux child qui feront la différence. Ce serait un vrai casse-tête de passer par le parent... j'imagine pas trop le truc... ce doit être suivant l'usage, par exemple pour l'IPX, en effet c'est le parent qui a toute l'intelligence (socket) Les child ne font que utiliser les fonctions du parent (du moins les binarySwitch pour actionner les sorties, les inputs ne fond pas appel au parent, sont complement passif, c'est le parent qui modifie leur état) Punaise avec cette box, il y a mille façons de faire les choses, c'est génial, mais ça rend fou Chacun voit le truc différemment ! on est plus vraiment dans des child tout simple comme on peut le voir souvent (qui affiche une température, un état, ...) lls deviennent actif. PS : merci de m'avoir mis sur la piste pour mon soucis, ça marche très bien maintenant

tu me montreras ton système en video aussi

une video ! carrément ! pffff

juste pour tenir au courant... Donc j'ai pris un Nokia 6 sous android 9 (mise à jour). Et bien c'est nickel ! La programmation sous Windev est impec, il a téléchargé tout seul les SDK (téléphone + android ---> c'est super volumineux plus de 20 Go !!). La compilation (avec Gradle) est un peu longue mais bon... (1 bonne minute) L'installation de l'application sur le téléphone prends 5 secondes. La gestion des bases de données se passent comme pour une application classique (.EXE). Suis content, ça peut ouvrir de bonnes perspectives... merci pour les conseils !

en fait après avoir analysé tout ça tu aurai fait un truc comme ça ? function MyClass:Func1() setTimeout(function() self:Func2() end, 1000) end function MyClass:Func2() setTimeout(function() self:Func3() end, 1000) end function MyClass:Func3() [...] end

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