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

×