Proposition d'ajout de fonction dans cmd pour récupération récursive et multiples d'équipements de type générique

Utilisation du core de Jeedom
1

Bonjour,

Dans le développement de certains scénarios, j’ai besoin de récupérer tous les équipements de type génériques qui sont dans un objet et ses enfants. Pour récupérer dans un objet, il y a la méthode statique cmd::getCmdByGenericTypeObjectId.

Pour répondre à mon besoin, j’ai développé dans les fonctions utilisateurs une méthode userFunction::getCmdByGenericTypeObjectIdMultipleAndRecursive($genericTypeName, $rootObjects) qui se charge de faire le job :

  • De manière récursive en récupérant les équipements génériques correspondants à genericTypeName dans $rootObjects et tous ses enfants.

  • De manière multiple : $rootObjects peut être un tableau d’objets de départ, ou un objet seul.

Un exemple (pour le moment en fonction utilisateurs):

$exteriorLights = userFunction::getCmdByGenericTypeObjectIdMultipleAndRecursive(
      'LIGHT_STATE_BOOL', 
      [
           jeeObject::byName('Façade ouest'), 
           jeeObject::byName('Façade nord')
      ]
)

Comme je l’indique au-dessus, si on n’a pas besoin de plusieurs objets racines, mais de la récurrence dans les enfants, on peut l’utiliser ainsi :

$exteriorLights = userFunction::getCmdByGenericTypeObjectIdMultipleAndRecursive(
      'LIGHT_STATE_BOOL', 
      jeeObject::byName('Extérieur')
)

Note : Je mettrais plus de détails dans la MR si cette proposition intéresse, mais j’ai remarqué qu’un objet vide dans la collection parcourue faisait planter la requête. J’ai donc bordé en excluant dans la boucle les objet vides (count sur getEqLogic).

est-ce que vous pensez cette petite feature intéressante et mérite une MR?

Merci pour vos retours,

2

Bonjour,

Merci de vous référer au sujet des bonnes pratiques du forum pour ne pas exiger de l’aide d’un développeur en le nommant directement.

1 « J'aime »
3

Mes excuses, je suis passé à côté de ce point. J’ai vu que vous l’aviez modifié dans le post, merci à vous.

4

Je pense que ta remarque correspond à ceci, corrigé en 4.3 normalement.