jjacques68

oui tout à fait : voilà le debut du code : --------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------- -- INIT PARENT --------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------- function QuickApp:onInit() __TAG = "QA_"..self.id.."_Child" self:debug("QuickApp:onInit") self:initChildDevices({ ["com.fibaro.binarySwitch"] = IPX, }) self:debug("Child devices:") for id,device in pairs(self.childDevices) do self:debug("[", id, "]", device.name, ", type of: ", device.type) end end --------------------------------------------------------------------------------------- -- CREAT CHILD --------------------------------------------------------------------------------------- function QuickApp:createChild(name, type, uid) local child = self:createChildDevice({ name = "ECL OUEST", type = "com.fibaro.binarySwitch", }, IPX) child:setVariable("D_OUTPUT", "5") self:trace("Child device created: ", child.id) end ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ -- CLASS IPX ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ class 'IPX' (QuickAppChild) ---------------------------------------------------- -- ON INIT ---------------------------------------------------- function IPX:__init(device) QuickAppChild.__init(self, device) self:debug(self.id , "MyBinarySwitch init") end function IPX:onInit() self:debug(self.id, "onInit") self:trace(self.parent:getVariable("IP")) end

oui, je me suis rendu compte que le "__init" n'était pas pareil que le "onInit", qui peut être déclaré également dans la classe : même erreur class 'IPX' (QuickAppChild) function IPX:__init(device) QuickAppChild.__init(self, device) self:debug(self.id , "MyBinarySwitch init") end function IPX:onInit() self:debug(self.id, "onInit") self:trace(self.parent:getVariable("IP")) end [17.05.2020] [11:09:00] [DEBUG] [QA_528_CHILD]: 552 onInit [17.05.2020] [11:09:01] [ERROR] [QUICKAPP528]: QuickApp crashed [17.05.2020] [11:09:01] [ERROR] [QUICKAPP528]: line: 47 attempt to index a nil value (field 'parent') je m'étais dis que les variables parents n'étaient accessible que depuis les "actions" prédéfinies comme "turnOn" et "turnOff", mais non j'en une méthode où ça fonctionne très bien !!

ahhhh je pige pas un truc : pour accéder a une variable parent depuis l'enfant, on a vu que : self.parent:getVariable("MaVar") fonctionne très bien : exemple typique pour le TurnOff d'une sortie de l'IPX : on voit dans cette exemple que j'accède à 2 variables "parent" (IP et PASSWORD) et une variable du "Child" (D_OUTPUT) tout ça depuis la méthode TurnOff de la classe IPX. function IPX:turnOff() self:debug("child", self.id, "turned off") local http = net.HTTPClient({timeout=3000}) http:request("http://"..self.parent:getVariable("IP").."/preset.htm?set"..self:getVariable("D_OUTPUT").."=0", { options = { headers = {['Authorization']='Basic '..self.parent:getVariable("PASSWORD")}, method = 'GET' }, success = function(response) end, error = function(err) self:error(tostring(err)) end }) end mais POURQUOI LA : dans une autre méthode de la même classe j'ai cette erreur ? : la ligne 97 est la ligne avec le http:request() function IPX:Ask_State() local http = net.HTTPClient({timeout=3000}) self:warning(self.parent:getVariable("IP")) http:request("http://"..self.parent:getVariable("IP").."/api/xdevices.json?cmd=20", { options = { headers = {['Authorization']='Basic '..self.parent:getVariable("PASSWORD")}, method = 'GET' }, success = function(response) self:Find_Out(response.data) end, error = function(response) self:error(tostring(response)) end }) end ??????? EDIT : je précise que cette méthode est appelée dans le code "__init" du "Child" : function IPX:__init(device) QuickAppChild.__init(self, device) self:debug(self.id , "MyBinarySwitch init") self:Ask_State() end

ben on découvre aussi...

alors d'après la doc, il semble qu'il y aurait une possibilité de "synchroniser" les Child... mais comme dit @Krikroff, faut extrapoler l'exemple qu'il donne, et là... franchement... pourtant je suis reposé... mais je bug complet

un inconvénient quand même et pas un petit !! : si un jour on fait une modification sur les Child, il faut supprimer l'ancien pour créer le nouveau avec les modifications !! et du coup l'ID du Child change à chaque fois, un peu pénible si on l'utilise comme trigger ou autre... à moins que j'ai loupé qqch ?

roooo là là !!! c'est de la BOMBE CE TRUC !!!!!!!!!!!!!!!

comment on fait pour accéder à une variable du parent dans le Child ? j'ai trouvé : self.parent:getVariable()

ah mais quel c... je suis !!!! je faisais child.setVariable() au lieu de child:setVariable() c'est pas la première fois que je me fais avoir... foutu classe on y accède pas depuis l'interface, mais on peut depuis le code ? faut que j'essaye...

Visiblement oui Envoyé de mon iPhone en utilisant Tapatalk Pro

où places-tu cette ligne ? dans la méthode createChild() ? ça me retourne une erreur...

chose faite... en effet ça aide à comprendre. Pour la création des Chlid, c'est OK. par contre concernant l'IPX, je suppose que l'idée de base est d'avoir autant de Child que de Output ! je vois bien les 3 fonctions propres au Child, et je pense comprendre leur rôle. function MyBinarySwitch:__init(device) QuickAppChild.__init(self, device) self:debug(self.id , "MyBinarySwitch init") end function MyBinarySwitch:turnOn() self:debug("child", self.id, "turned on") self:updateProperty("value", true) end function MyBinarySwitch:turnOff() self:debug("child", self.id, "turned off") self:updateProperty("value", false) end Le code de pilotage des sortie se mettra dans les fonctions turnOn/Off... Mais comment associer le numéro de sortie de l'IPX à un Child ?

je relance le sujet, je viens de me rendre compte que dans l'API de scènes, il y a une propriété "maxRunningInstances" qui visiblement par défaut est à 2. J'ai réussi à la mettre à plus, ici 10, mais je ne constate aucun changement de comportement... bien dommage ça ! { "id": 6545, "name": "__essai", "type": "lua", "mode": "automatic", "maxRunningInstances": 10, "icon": "scene_lua", "hidden": false, "protectedByPin": false, "stopOnAlarm": false, "restart": false, "enabled": true, "content": "{\"conditions\":\"{}\",\"actions\":\"fibaro.warning(\\\"essai\\\",\\\"start\\\")\\nfibaro.setTimeout(10*1000, function() fibaro.warning(\\\"essai\\\",\\\"end\\\") end)\"}", "created": 1589226657, "updated": 1589610840, "categories": [ 1 ] }

@Lazer tu pourras poster ton projet de child device avec l'ipx ? ça m'intéresserait d'avoir un exemple concret... pour comprendre le principe...

ok donc on peut paramétrer chaque port comme on veut !

en relisant, je viens de m'en rendre compte oui. punais avec du recul, y a moyen de vachement simplifier ça !!! et sans passer par les Child Device... j'ai fait compliqué sur ce coup-là, va falloir que je corrige ça... allé... comme dis c'était la prise en main pour les Child Device, j'avoue ne pas trop comprendre encore leur exemple sur leur site...

tu as quoi comme idée ? dans mon cas j'ai un QA unique de gestion de l'IPX, avec plusieurs fonctions : demander le status d'une In/Output modifier une output réceptionne le retour d'état d'une sortie (qui d'ailleurs affecte la valeur des QA créés pour chaque fonction : éclairage, arrosage, ...) et qui me permet depuis ce même QA de modifier les OUT (en fait ça c'est inutile, mais c'était la première chose que j'avais faite à la réception de la HC3 )

c'est propre aux switch Unifi ? et ça concerne tous leurs modèles ? parce que je me suis jamais posé la,question, j'ai un vieux switch POE netgear (encore en 100Mo) qui,alimente les caméras et AP, mais j'ai aussi un PC branché dessus ! jamais eu de soucis... je m'étais dis que j'allais mettre un gros switch unifi POE pour tous mes besoins, mais à te lire... la question se pose...

ce serait le rêve, imagines un QA avec toutes les petites fonctions dedans, que tu peux appeler quand tu veux, et récupérer le retour directement. ben en gros tout le contenu du "snippet" sur le forum que tu as créé

c'est dans les tuyaux d'après @Krikroff. du moins il a fait remonté l'info...

oui c'est chiant ça ! c'est comme les scènes qui sont triggée, alors l'instance précédente n'est pas terminée, suivant l'option que tu as choisi dans les propriétés de la scène ("Allow to restart a runing scene"), tu vas avoir des erreurs avec ... rien comme libellé !

pour l'icône pas encore. pour l'appel de fonction dans les scènes : fibaro.call(ID_QA,"Ma_Fonction") pour la récupération de valeur de retour, on en a déjà discuté, pas encore... du moins pas sans usine à gaz... en attendant passer par une VG de retour, peut aider pour l'usine à gaz : (suis pas fan, jamais essayé) https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/?tab=comments#comment-201165 pour la variable, j'ai aussi remarqué que ça pouvait marché sans le "self." Après comme le QA est une "mini" classe, c'est presque de la POO... si j'ose dire... donc c'est plus "propre"... n'hésitez pas à me corriger !!

Ah j'avais oublié ça ! Bien vu ! Envoyé de mon iPhone en utilisant Tapatalk Pro

bon la vous avez citez le top du top dans le domaine

RAS sous chrome...