jjacques68 Posté(e) le 17 août 2020 Signaler Posté(e) le 17 août 2020 hello ! Autre question concernant l'initialisation à la création des QA child : en effet on leur donne leur type avec : local child = self:createChildDevice({ name = "toto", type = "com.fibaro.binarySwitch", }, _MyClass) Mas par défaut il les déclare en "Light" (avec tout ce qui va avec : propriété isLight = true ; interfaces = ["lights", "quickAppChild"] ; categories = ["light"]) et si on veut mettre autre chose !! sans avoir à se taper tous les child à la main !! attention au jeux de mots : "Rôle" = "interface"... J'ai trouvé comment faire pour l'icone et la catégorie : dans le code d'init du child : function MyClass:__init(device) QuickAppChild.__init(self, device) self:trace(string.format("[%s] %s - init" , self.id, self.name)) self:updateProperty("deviceIcon", 1011) self:updateProperty("isLight", false) self:updateProperty("categories", {"other"}) end y a juste besoin de le faire la première fois. On peut laisser le code, mais il ne sera plus utile. remarque : J'ai pensé du coup à le glisser dans la fonction de création du child, mais il le prend pas en compte : local child = self:createChildDevice({ name = "toto", type = "com.fibaro.binarySwitch", deviceIcon = 1011, isLight = false, categories = {"other"}, }, _MyClass) fin remarque. mais pour le rôle (donc interface), pas moyen d'y arriver, j'ai du me les faire à la main ! le problème est que le rôle ne fait pas partie de la section "propriété" dans l'API. donc j'ai essayé la bonne vieille méthode du api get/put, sans succès : local MyApi = api.get("/devices/"..self.id) MyApi.interfaces = {"quickAppChild"} res = api.put("/devices/"..self.id, MyApi) pas de message d'erreur, mais pas de modifications dans l'API... qqun a une idée ?? ou je fais complètement fausse route !?
jang Posté(e) le 17 août 2020 Signaler Posté(e) le 17 août 2020 self:createChildDevice({ name = <name>, type=<type>, initialProperties = .... initialInterfaces = ... }, <Class> ) 2
jjacques68 Posté(e) le 17 août 2020 Signaler Posté(e) le 17 août 2020 (modifié) yes super !! OK for the properties, but not for Interfaces : self:createChildDevice({ name = "toto", type = "com.fibaro.binarySwitch", initialProperties = { deviceIcon = 1011, isLight = false, categories = {"other"}, }, initialInterfaces = {"quickAppChild"}, }, MyClass) It still set interfaces with "lights" and "quickAppChild"... I try with : initialInterfaces = {} but same result... Modifié le 17 août 2020 par jjacques68
Lazer Posté(e) le 17 août 2020 Signaler Posté(e) le 17 août 2020 C'est surprenant, d'autant plus que Toto c'est pas une lumière 2
jang Posté(e) le 17 août 2020 Signaler Posté(e) le 17 août 2020 self:createChildDevice always add "quickAppChild" for you. Some types of device will also add their specific interfaces.
jjacques68 Posté(e) le 17 août 2020 Signaler Posté(e) le 17 août 2020 Ok with "quickAppchild" as default. I understand this type. But the type "lights" is added too. I would like to delete the others types. Just to keep "quickAppchild".
jang Posté(e) le 17 août 2020 Signaler Posté(e) le 17 août 2020 self:deleteInterfaces({"light"}) or myQuickApp:deleteInterfaces({"light"}) 1
jjacques68 Posté(e) le 17 août 2020 Signaler Posté(e) le 17 août 2020 YEESSSS ! it works fine ! Now I juste have "quickAppChild" in interfaces. but there is a bug with the IHM : "light" is still display... while in the API it's ok : all these functions/possibilities are not explain in the manual of Fibaro... Once again, thank you !!!!
Lazer Posté(e) le 16 septembre 2020 Signaler Posté(e) le 16 septembre 2020 Le 17/08/2020 à 15:27, jjacques68 a dit : "light" is still display... Ce n'est pas un bug, en fait l'interface Web se base sur la property deviceControlType qui a toujours la valeur 2 dans le JSON du device, et qui correspond au type Lumière. => Il faut injecter deviceControlType = 20 dans les properties du Child Device au moment de sa création pour qu'il prenne bien le rôle "Autre appareil" : Je récapitule : Créer le device enfant avec les initialProperties suivantes : deviceControlType = 20, categories = {"other"}, Supprimer l'interface suivante : "light" Exemple de code abrégé : local child = self:createChildDevice({ name = "Mon enfant", type = "com.fibaro.binarySwitch", initialProperties = { deviceControlType = 20, categories = {"other"}, }, }, childClass ) if child then chiild:deleteInterfaces({"light"}) end Pour info voici les valeurs de la propriété deviceControlType que j'ai pu identifier pour le type de device Commutateur binaire / Binary switch "com.fibaro.binarySwitch" : 2 Lumière 3 Arroseur 4 PIN 5 Lampe de chevet 6 Bouilloire 7 Applique murale 8 Climatisation 9 Alarme - violation 10 Machine à café 11 Lampe de jardin 12 TV 13 Ventilateur de plafond 14 Grille-pain 15 Radio 17 Fenêtre de toit 20 Autre appareil 21 Etat d'alarme (armé / désarmé) 22 Alarme - Armement 24 Interphone vidéo 25 Ouverture du portail vidéo On remarque qu'il y a plusieurs types de lumières/lampes qui rétablissent automatiquement la propriété isLight = true. 1
jjacques68 Posté(e) le 16 septembre 2020 Signaler Posté(e) le 16 septembre 2020 ah ça c'est top, merci pour l'info !!!
MAM78 Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 Dans un Quick App en cours de construction, j'ai un comportement curieux que je ne m'explique pas. Dans ce QuickApp, j'ai un Child de type "com.fibaro.doorLock" auquel est associé des actions de type "secure" et "unsecure". Ces actions (changement de value) fonctionnent très bien lors de la première exécution qui crée le Child (après la sauvegarde de la Quick App). J'obtient les messages suivants dans les logs : onAction: {"actionName":"secure","args":[223,"secure"],"deviceId":223} QuickApp:action("Secure", "Relay_1_Portail", table[2]) Mais si j'effectue des modifications de la QuickApp et dès lors que j'effectue sa sauvegarde, les actions "secure" et "unsecure" ne fonctionnent plus, j'obtient les messages suivants dans les logs : onAction: {"actionName":"secure","args":[223,"secure"],"deviceId":223} "Class does not have secure function defined - action ignored" Pour refaire fonctionner ce Child, je suis obligé de supprimer le Child et relancer mon QuickApp qui recréer le Child. Auriez-vous une idée de la cause de ce problème et comment y remédier ?
Lazer Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 Je pense que tu associes la mauvaise classe à ton child lors de l'initialisation au début de la fonction onInit() du device parent.
MAM78 Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 J'ai mis ça : ---------------------------------------------------------------------------------------------------- -- QuickApp Child device - MyChild ---------------------------------------------------------------------------------------------------- class 'MyChild' (QuickAppChild) -- -- Constructor -- function MyChild:__init(device) QuickAppChild.__init(self, device) tools.log(self, "", 0) end
Lazer Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 (modifié) ça OK, mais faut que tu associes ta classe MyChild à tes modules enfants maintenant. Ce que tu dois faire dans onInit() Regarde le log, tu dois voir un message d'avertissement si tu as oublié de le faire. EDIT : avec self:initChildDevices() comme indiqué dans la doc, chapitre "Initializing child devices on Quick App startup" : https://manuals.fibaro.com/knowledge-base-browse/hc3-quick-apps-managing-child-devices/ C'est d'ailleurs surprenant que Fibaro nous laisse créer un Child avec une Classe donnée, puis en changer plus tard lors des redémarrage ultérieurs du QuickApp dans le onInit(). Bon l'avantage c'est que ça permet de faire évoluer son code dans détruire/recréer les children. Modifié le 13 décembre 2020 par Lazer
MAM78 Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 Je l'ai fait il me semble, j'ai mis ça : local ChildDevice = { name = Device.name, type = Device.type, class = MyChild, properties = { deviceControlType = Child.properties.deviceControlType, categories = Child.properties.categories, manufacturer = Child.properties.manufacturer, model = Child.properties.model, value = Device.defaultValue, }, variables = { {name = "ID", value = Device.name}, }, } if not tools.createChild(self, ChildDevice) then self:error("Error : Automatic child device(s) creation failed") end
Lazer Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 Oui mais non, tu confonds la création du child, et ses initialisations ultérieures relis mon message précédent, j'ai édité.
MAM78 Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 Faut-il mettre autant de lignes qu'il y a de type ? ou est-ce qu'il faut autant de MyChild qu'il y a de Type différents ? -- Setup classes for child devices self:initChildDevices({ ["com.fibaro.binarySwitch"] = MyChild, ["com.fibaro.doorLock"] = MyChild, ["com.fibaro.motionSensor"] = MyChild, })
Lazer Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 (modifié) "autant de lignes qu'il y a de type" Sachant que plusieurs types peuvent utiliser la même classe. Une autre façon de le dire : une seule classe peut gérer plusieurs types différents Exemple valide avec 2 classes différentes : self:initChildDevices({ ["com.fibaro.binarySensor"] = MyInput, ["com.fibaro.motionSensor"] = MyInput, ["com.fibaro.doorSensor"] = MyInput, ["com.fibaro.windowSensor"] = MyInput, ["com.fibaro.gateSensor"] = MyInput, ["com.fibaro.rainDetector"] = MyInput, ["com.fibaro.temperatureSensor"] = MyInput, ["com.fibaro.humiditySensor"] = MyInput, ["com.fibaro.lightSensor"] = MyInput, ["com.fibaro.multilevelSensor"] = MyInput, ["com.fibaro.powerSensor"] = MyInput, ["com.fibaro.binarySwitch"] = MyDigitalOutput, }) Modifié le 13 décembre 2020 par Lazer
MAM78 Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 Merci pour les précisions Où puis-je trouver la liste différents type de devices disponibles sur la HC3. Je cherche notamment un type de type sonnette (Doorbell). Ca doit bien exister puisqu'il existe des sonnettes Z-wave.
Lazer Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 /api/quickApp/availableTypes
MAM78 Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 MErci, mais il n'y a rien de spécifique pour une sonnette
Lazer Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 Binarysensor tout simplement
MAM78 Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 binarySwitch ou binarySensor. Lequel est plus logique ? Mais je pense effectivement plus à un binarySensor puisque l'état On est furtif.
Lazer Posté(e) le 13 décembre 2020 Signaler Posté(e) le 13 décembre 2020 Un Sensor c'est un capteur Un Switch c'est un actionneur Pour pour remonter le statut de la sonnette, sans aucune hésitation il faut un binarysensor C'est déjà comme ça sur HC2, y'a pas de raison de faire différemment sur HC3. (j'utilise un vrai module, un Fibaro Universel FGBS)
Messages recommandés