Krikroff Posté(e) le 23 novembre 2021 Auteur Signaler Posté(e) le 23 novembre 2021 A ma connaissance si le type change c’est cuit ! Mais je suis curieux Envoyé de mon iPhone en utilisant Tapatalk
Lazer Posté(e) le 23 novembre 2021 Signaler Posté(e) le 23 novembre 2021 Oui, j'allais le dire, le type d'un module ne peut pas être changé ! name, visible, room, enabled, etc tout ça tu peux le changer sans souci par contre. La bonne pratique à mon avis est d'identifier chaque enfant d'une façon unique, avec un ID stocké dans une variable du module enfant. Par exemple pour Netatmo, chaque child est identifié par rapport à l'ID du module renvoyé par l'API Netatmo. Pour IPX800 et EDRT2, chaque child est identifié par rapport au numéro du port. Pour Surveillance Station, c'est l'ID de chaque caméra. Etc. Avec cette technique, les mises à jour du QuickApp devraient permettre de retrouver ses petits.
jang Posté(e) le 23 novembre 2021 Signaler Posté(e) le 23 novembre 2021 The type of the QA defines a lot of the available key-values of the QA device structure. Changing the type of the QA would require some migration of values. For some types the property.value is a boolean for others a float etc. It would be messy. For children you need to update the mother QAs, as children can't migrate to another mother QA (one could experiment with changing the .parentId but my guess it could create havoc...) I have a Hue QA that I have updated the mother QA for a year now and users have been able to keep their children and more important the children deviceId's. I have my own version of the QuickAppChild class called QuickerAppChild that manages the children and reloads them with the correct class and it works well. I have also an 'UpdaterQA' that allow people to upgrade (and downgrade) my EventRunner and ChildrenOfHue's QAs. 1
MAM78 Posté(e) le 24 novembre 2021 Signaler Posté(e) le 24 novembre 2021 Il y a 5 heures, jang a dit : I have my own version of the QuickAppChild class called QuickerAppChild that manages the children and reloads them with the correct class and it works well. Thank you, that seems to meet my needs perfectly. I haven't figured out all your code yet, but it'll probably help me a lot.
MAM78 Posté(e) le 24 novembre 2021 Signaler Posté(e) le 24 novembre 2021 Je me doutais bien qu'il ne devait pas être possible ou conseillé de modifier les éléments "type" et "parentId" de la structure des QuickAppChild. C'était bien la raison pour laquelle j'ai posé la question sur les limites et impacts Il y a 7 heures, Lazer a dit : La bonne pratique à mon avis est d'identifier chaque enfant d'une façon unique, avec un ID stocké dans une variable du module enfant. Ca, je l'avais déjà identifié et intégré dans mon QuickApp pour repérer l'existence/absence du Child Merci @Lazer pour tes conseils. Maintenant, je vais devoir essayer de comprendre le code et faire des tests d'intégration de la solution proposée par @jang
henri-allauch Posté(e) le 11 mars 2022 Signaler Posté(e) le 11 mars 2022 Depuis un Qa X on peut obtenir les, infos des dévices enfants par : -- Print all child devices. self:debug("Child devices:") for id,device in pairs(self.childDevices) do self:debug("[", id, "]", device.name, ", type of: ", device.type) end Existe il une fonction pour obtenir depuis un Qa X les childDevices d'un Qa Y Ou faut il parmi tous les devices extraire ceux dont le parentid correspond au Qa Y
Lazer Posté(e) le 11 mars 2022 Signaler Posté(e) le 11 mars 2022 Je pense qu'il faut passer par l'API, ce que tu peux faire très simplement en filtrant au niveau de la requête : /api/devices?parentId=123 D'ailleurs, je ne serais pas surpris que ce soit exactement ce que fait le QA lui-même au moment de son initialisation, pour remplir la table self.childDevices 2 1
Bloug Posté(e) le 28 mai 2022 Signaler Posté(e) le 28 mai 2022 (modifié) Le 15/05/2020 à 21:09, Lazer a dit : Justement c'est ça le problème, il n'y a PAS d'exemple. La page de manuel est super confuse, pas du tout didactique, quelques bouts de code balancés en vrac et dans le désordre, j'ai dû relire au moins 15 fois pour finir par comprendre. Bref, du Fibaro quoi, ils n'ont jamais été copains avec les documentations.... J'ai vraiment du mal a comprendre avec la doc à 2 balles pour créer un ChildDevice.... qui semble pourtant si simple à vous lire ! Je cherche pas déjà à "créer" un QA mais juste à "comprendre" les childDevice.... Question : j'ai un QA AirZone qui fonctionne bien. comme un p'tit bouton pour le On/Off. Quand je l'ouvre j'ai la température et l'humidité Peut être est il possible de modifier en ajoutant un ou deuxChilddevice ["com.fibaro.temperatureSensor"] & ["com.fibaro.humiditySensor"] et ainsi avoir un capteur de Température et d'humidité de référence pour chaque pièce ? j'ai les deux variables : -- self:updateView("tempAirzone", "text",'TªAmb: '..ambTemp..''..units..'/ TªSet: '..setTemp..''..units..'/ Humidity: '..humidity..'%') Température : ambTemp Humidité : humidity Donc dans le QA j'ajoute une nouvelle page pour bidouiller ? Est-il possible de m'indiquer un truc simple ( un exemple simple d'un capteur de T°) pour comprendre car j'ai cherché entre les tutos et dans vos QA .....bah y'a pas de logique avec le tuto Fibaro.... 1 - Defining class for a child device 2 - Defining method for new classes 3 - Creating a new child device 4 - Initializing child devices on Quick App startup ..... et je parle pas du reste :p merci Modifié le 28 mai 2022 par Bloug
Lazer Posté(e) le 29 mai 2022 Signaler Posté(e) le 29 mai 2022 Ton nouveau fichier "Mes_bidoiuilles" permet juste de séparer une portion du code LUA dans un autre fichier, pour faciliter la maintenance ou l'organisation du code (surtout utiles quand on a plusieurs milliers de lignes), mais n'a absolument rien à voir avec la gestion des modules enfants, qui peut (et j'ajoute "doit") être réalisée dans le fichier principal (main), comme tout ce qui touche directement au QuickApp. Perso j'utilise les autres fichiers pour les fonctions annexes (librairie d'outils, de notification, de communication avec un autre appareil externe, etc) Désolé je n'ai pas trop le temps de t'écrire ton QuickApp (car c'est ce que tu demandes en fin de compte), mais je peux te conseiller de consulter le code des différents QuickApps déjà partagés sur le forum. Il y a aura 90% du code qui ne t'intéresse pas, mais il faut que tu en extraies les lignes utiles pour la gestion des modules enfants. Je peux te conseiller mon QA Onduleur Eaton, qui doit être l'un des plus simples (et je te déconseille le QA GCE qui est le plus complexe du coup...), car il gère des modules enfants, et notamment de température.
Bloug Posté(e) le 29 mai 2022 Signaler Posté(e) le 29 mai 2022 Il y a 5 heures, Lazer a dit : Désolé je n'ai pas trop le temps de t'écrire ton QuickApp (car c'est ce que tu demandes en fin de compte) Pas comme tu l'exprimes lol .... je pense plus à un Tuto ou une Exemple simple .... Un tuto d'exemple simple ^^ :s Il y a 5 heures, Lazer a dit : Je peux te conseiller mon QA Onduleur Eaton, qui doit être l'un des plus simples Justement , c'est là que je regarde il y a des éléments super intéressant pour calquer le modèle ( notamment dans le Tool ) genre : -- -- Create child device -- -- Usage : -- local child = { -- name = "Name", -- required ! -- type = "com.fibaro.multilevelSensor", -- required ! -- properties = { -- optional -- deviceIcon = 127, -- icon = { path="plugins/com.fibaro.denonHeos/img/icon.png"}, -- deviceControlType = 20, -- categories = {"other"}, -- }, -- class = MyChild, -- required ! -- unit = "V", -- optional -- variables = {{name = "MyVariable", value = "Hello World"}}, -- optional -- interfaces = {}, -- optional -- } -- if not tools.createChild(self, child) then -- self:error("Error : child creation failed") -- end -- mais qui reste difficile à appréhender avec des brides de code où je retrouve des éléments sans forcement comprendre la logique Après c'est peut être un problème de temps ou simplement d'un autre niveau de prog ! A Voir... avec le temps
Lazer Posté(e) le 29 mai 2022 Signaler Posté(e) le 29 mai 2022 Mouais mais un tuto c'est limite plus long que d'écrire le code LUA.... comme toute documentation, c'est hyper long La librairie tools tu peux l'utiliser si tu veux, mais en fait ça ne va pas aider à t'apprendre la construction d'un Child from scratch. Du coup je me dit que mes QA ne sont pas les meilleurs exemples pour débuter. Le self:initChildDevices c'est documenté par Fibaro, donc aucune surprise à ce niveau là, cela doit impérativement être fait dans le onInit() Par contre le tableau que tu as copié juste au dessus, c'est du pur perso, c'est une table qui me sert à déclarer tout ce que va faire le QA (mettre à jour des propriétés, des variables globales, et entre autre, des child devices (juste la dernière ligne))
Bloug Posté(e) le 30 mai 2022 Signaler Posté(e) le 30 mai 2022 j'avance à mini pas ... si j'y arrive je te send un MP pour corriger histoire ne ne pas poser un tuto avec des bourdes ( si tu as le temps .... et si j'y arrive )
Lazer Posté(e) le 30 mai 2022 Signaler Posté(e) le 30 mai 2022 Bravo Tu veux faire un tuto ? Chouette
Bloug Posté(e) le 30 mai 2022 Signaler Posté(e) le 30 mai 2022 C'est pas gagné j'y suis arrivé par Erreur ( que j'arrive plus à reproduire lool ) Contrairement à toi ....je vais passer moins de temps au faire un tuto en Image ..... que de faire le code
Bloug Posté(e) le 2 juin 2022 Signaler Posté(e) le 2 juin 2022 @Lazer , j'ai besoin d'un coup pouce stp je tourne en rond pour indiquer la Température dans un appareil enfant c'est bien dans dans la fonction la section : Keeping your devices synchronized function QuickApp:storeDevice(uid, hcId) self.devicesMap[uid] = hcId -- Save devicesMap, so you can restore it after Quick App restart. -- Just put self.devicesMap = self:getVariable("devicesMap") in onInit method. self:setVariable("devicesMap", self.devicesMap) end dans mon cas j'ai deja une variable qui est : ambTemp dois je trifouiller avec ???? self.devicesMap = ambTemp self:setVariable("devicesMap", ambTemp) #NoComprenDO
Lazer Posté(e) le 2 juin 2022 Signaler Posté(e) le 2 juin 2022 Euh... pourquoi s'embêter avec une variable de QA, c'est totalement inutile ? Je veux dire, pourquoi stocker la température dans une variable, alors que tu cherches à la stocker dans la propriété value du module. C'est directement là qu'il faut la stocker, pas besoin de rajouter une étape intermédiaire. Ensuite pour la façon de structurer son code, tout dépend de ce que tu fais. Là il n'y a aucune règle. Par exemple dans la majorité de mes QA, les enfants sont "passifs", c'est à dire qu'ils attendent des événements, mais n'ont aucune boucle infinie. La boucle infinie est gérée par le QA Parent, qui va lire les infos dans le monde extérieur (exemple fictif pour rester dans la discussion précédente : le statut de l'onduleur connecté au réseau). Une fois que cette boucle a obtenu toutes les valeurs désirées (température, état de l'alimentation, niveau de batterie, etc)... qui sont alors stockée dans des variables locales au sens LUA du terme, alors elle va "pousser" les valeurs dans les propriétés de chaque QA Enfant. Et dans cette façon de pousser les valeurs, il y a différentes façon de s'y prendre. La méthode basique c'est d'appeler directement la propriété updateProperty() des enfants. Exemple ultra simplifié, à intégrer dans ta boucle infinie du QA parent : -- Temperature : local value = 21 -- Mise à jour de la propriété value du module enfant identifié par son id : self.childDevices[id]:updateProperty("value", value) Bon après faut que tu gères correctement ton tableau d'enfants, car les identifier par leur ID ce n'est pas le plus simple dans le code. Perso ce que je fais maintenant, je crée une fonction push() pour les enfants, ce qui présente 2 avantages : - le parent peut mettre à jour les propriétés des enfants via cette fonction - le monde entier, via l'API, peut également mettre à jour les enfants. C'est particulièrement pratique avec les GCE IPX800 et EDRT2 qui permettent de déclencher des événements Push vers la box domotique pour un rafraichissement instantané. Mais c'est quelque chose que tu pourras voir dans un second temps.
Bloug Posté(e) le 2 juin 2022 Signaler Posté(e) le 2 juin 2022 Malheureusement après multiiiii testss rien ne s'affiche. ne maitrisant pas du tout le truc je vais envoyé un message au développeur du QA c'est plus sage En tout cas, merci pour les explications !
Lazer Posté(e) le 2 juin 2022 Signaler Posté(e) le 2 juin 2022 Ah je n'avais pas compris que tu voulais ajouter des Child devices à un QA existant, dont tu n'es pas l'auteur. Donc à la difficulté de gestion des QA enfants, s'ajoute la difficulté de compréhension du code LUA de quelqu'un d'autre... pas simple. Il faudrait vraiment écrire un tuto complet sur la création et la gestion des QA enfants, mais c'est un travail titanesque, surtout si on doit reprendre les bases d'un QA tout simple, ce que beaucoup d'utilisateurs ne maitrisent déjà pas très bien. En attendant le mieux qui existe, je conseille toujours cette lecture sur le forum officiel : The anatomy of QuickApps - Part 1 The anatomy of QuickApps – Part 2 The anatomy of QuickApps – Part 3 QuickAppChildren and how to raise them - Part 4
Bloug Posté(e) le 2 juin 2022 Signaler Posté(e) le 2 juin 2022 Ohh Oui le QA n'est pas de moi, c'est le QA Airzone disponible sur le marketplace. il est casi l'identique au VD de la HC2. L'idée est simplement ( lool) d'ajouter deux Childevice : 1 pour la température et l'autre pour l'humidité pour qu'ils soient en "natif" dans les pièces pour la HC3. Mais bon, rien de bloquant c'est plus histoire de toucher...bidouiller... découvrir la hc3 j'ai envoyé un mp à l'auteur wait&see Sinon oui j'ai vu les topics ! c'est déjà du très lourd .... j'utilise quand j'arrive pas à dormir
Bloug Posté(e) le 3 juin 2022 Signaler Posté(e) le 3 juin 2022 une lueur d'espoir .... J'ai utiliser un le QA Ecodevice Relais de @mprinfo pour me calquer dessus. Ta ligne pour mètre à jour le child fonctionne parfaitement : self.childDevices[367]:updateProperty("value", ambTemp) Bon pour l'ID elle est modifiée à la mano (forcement ) Maintenant je vais chercher à ajouter le second Child
Lazer Posté(e) le 3 juin 2022 Signaler Posté(e) le 3 juin 2022 Cool Pour l'ID des enfants, ce qu'il faut faire c'est se construire un tableau dynamique des modules enfants, reconstitué à chaque démarrage, afin d'identifier facilement les enfants. De mémoire la doc Fibaro indique de procéder comme cela. Après la façon de le mettre en œuvre varie selon les gens. Perso lors de la création de chaque module enfant, je leur affecte une variable (variable de quickapp, donc visible dans l'onglet idoine du module) qui contient un identifiant unique (la forme de cet identifiant est très variable selon le but recherché... parfois c'est un ID numérique, parfois c'est juste du texte). Puis lors du démarrage du QA, je vais charger cette variable pour chaque enfant, et me construire une table utilisée dans le code LUA.
Bloug Posté(e) le 3 juin 2022 Signaler Posté(e) le 3 juin 2022 (modifié) donc quand j'ai l'info dans le debug : local child = self:createChildDevice({name = Nom, type = "com.fibaro.temperatureSensor",}, AirTemp) self:trace("Child device created: ", child.id) end c'est pas possible de récupérer cette variable child ( de local child ..... ) et de l'indiquer directement à la mise a jour ? self.childDevices[369]:updateProperty("value", ambTemp) self.childDevices[child]:updateProperty("value", ambTemp) (désolé pour les questions betes) Modifié le 3 juin 2022 par Bloug
Lazer Posté(e) le 3 juin 2022 Signaler Posté(e) le 3 juin 2022 Si, la variable child retournée par createChildDevice() pointe bien sur le module enfant, enfin sa représentation en mémoire (= une instance de l'objet, cf discussion sur le nouveau topic du QA pour les débutants) Tu peux l'exploiter comme bon te semble, mais c'est de courte durée, car au démarrage suivant du QA, la mémoire est perdue. Donc il faut recréer ton tableau de child, d'où mon message précédent, il te faut un moyen d'identifier simplement les child autrement que par leur ID. La variable stockée dans chaque child est le meilleur moyen à mon avis. 1
Bloug Posté(e) le 3 juin 2022 Signaler Posté(e) le 3 juin 2022 Bon j'avance, et j'arrive à avoir mes deux valeurs. Je comprends ton explication sur les ID des childs .... mais de là à la mettre en pratique !
RS600807 Posté(e) le 24 juin 2022 Signaler Posté(e) le 24 juin 2022 Salut @Bloug, Je m'intéresse comme toi à la création des child à partir de la QA Airzone. Même si cette QA est déjà plutôt bien pour pouvoir récupérer les infos avec le système airzone, je trouve effectivement dommage de ne pas pouvoir obtenir plus '"directement" (au lieu d'avoir à cliquer sur l'icone pour voir les infos) la valeur de température et d'humidité. C'ets la que prend tout son sens la notion de child. Débutant dans l'apprentissage du LUA, je m'efforce de lire les tuto et les pages du forum. Pas toujours simple, surtout quand on n'est pas du domaine et que les cours d'informatique sont déjà loin ! Je ne sais pas trop où tu en es dans le développement de ton code, mais je vais m'y pencher dessus. Je suis en train de m'inspirer d'autre QA qui gèrent des child pour pouvoir l'adapter à la QA airzone. Si tu as des choses nouvelles, n'hésite pas à faire signe. Merci de ton retour.
Messages recommandés