Aller au contenu
Krikroff

Gestion des appareils enfants

Recommended Posts

A ma connaissance si le type change c’est cuit ! Mais je suis curieux :)


Envoyé de mon iPhone en utilisant Tapatalk

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

 

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites
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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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 :5:

Partager ce message


Lien à poster
Partager sur d’autres sites
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 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

 

  • Like 2
  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites
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 ! :o

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é

 

 a.JPG.1690710b2d4cf5b584ab882605d714d7.JPG

 

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  ? 

b.JPG.1dbc5a4e5ff75071ca8647b5a5a4ec4c.JPG

 

 

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é par Bloug

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites
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 :P  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

 

CC.thumb.JPG.15beb09aac800f291afd3855afddfd92.JPG

 DD.JPG.cbec621d0e0b6a15c962af1360ae8463.JPG

 

Après c'est peut être un problème de temps ou simplement d'un autre niveau de prog ! A Voir... avec le temps :)

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

 

Partager ce message


Lien à poster
Partager sur d’autres sites

EEE.JPG.f05f2e511ef07a0453a91373aea5fd27.JPG

 

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 )

Partager ce message


Lien à poster
Partager sur d’autres sites

Bravo

Tu veux faire un tuto ? Chouette :)

 

Partager ce message


Lien à poster
Partager sur d’autres sites

C'est pas gagné j'y suis arrivé par Erreur :wub: ( 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 :D 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

@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

 

 

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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 !

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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 :

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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 :P

Partager ce message


Lien à poster
Partager sur d’autres sites

FFFF.JPG.0b00fa840db3b3ff6f2bf5a69ed5ada0.JPG

 

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 :o) Maintenant je vais chercher à ajouter le second Child

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

ggg.JPG.93dfa7cc27cb5a4d2d6e62e0c017fd75.JPG

 

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é par Bloug

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

hhh.JPG.2cb4751ff0e25173c4c866bf3e3f8545.JPG

 

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 !   

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

×