Initialisation des Child lors de la création

[jjacques68]

Hello tout le monde,

 

Je suis entrain de faire des essais pour affiner l'initialiser des paramètres des Child lors de leur création.

(donc sans avoir à passer par l'onglet propriété, afin de modifier l'un ou l'autre paramètre, une fois créés).

 

Voici le bout de mon code actuel, qui fonctionne très bien, que j'utilise dans ma fonction qui crée les Child :

local child = self:createChildDevice({
	name = "MyChild",
	type = "com.fibaro.binarySwitch",
	initialProperties = {
		isLight = false,
		deviceIcon = 1234,
		categories = {"other"},
	},
}, MyClass)

child:deleteInterfaces({"light"})

Je souhaite maintenant affiner les paramètres, en y ajoutant par exemple :

• le "roomID"
• le "deviceRole" qui est toujours = "ligth" par défaut 

 

Donc logiquement, en analysant l'API je fais ceci :

local child = self:createChildDevice({
	name = "MyChild",
	type = "com.fibaro.binarySwitch",
	roomID = 255,
	initialProperties = {
		isLight = false,
		deviceIcon = Liste[i]._icon,
		categories = {"other"},
		deviceRole = {"Other"},
	},
}, MyClass)

 

résultat : 

 

pour le "roomID", c'est totalement ignoré !?

pour le "deviceRole" j'ai une erreur qui me dit qu'il ne connait pas cette propriété !?

 

J'avoue ne pas trop comprendre pourquoi ?

Si quelqu'un a une explication ?  

 

 

 

Autre question, qui n'a rien à voir... enfin...  

 

comment connaitre les propriétés disponibles par le mot-clé "self" dans un QA ?

par exemple :

self.name 		---> renvoie le nom
self.id			---> renvoie l'ID
self.properties.value	---> renvoie la value
self.roomID		---> renvoie null ??
self.visible		---> renvoie null ??

et bien-sûr l'instruction 

hub.getValue(1234, "roomID")

renvoie rien du tout  

 

merci pour votre patience !

Modifié le 5 août 2022 par jjacques68

[Lazer]

le roomID tu ne peux pas le définir lors du createChild, il faut le modifier juste après la création du child.
C'est ce que je fais dans ma librairie tools déjà partagée plusieurs fois sur le forum.

 

Pour le role, je ne sais pas trop...

 

Pour connaitre ce qui est dispo dans self, il te suffit de parcourir la table avec une boucle for k, v in pairs(self)...

 

[jjacques68]

Il y a 3 heures, Lazer a dit :

le roomID tu ne peux pas le définir lors du createChild, il faut le modifier juste après la création du child.

 

Ok je comprends...

on connait la liste des propriété pour le initialeProperties du :creatChildDevice() ?

 

Il y a 3 heures, Lazer a dit :

Pour le role, je ne sais pas trop...

ben avec ce que tu viens d'expliquer, voilà ce que j'ai fais et qui fonctionne :

donc après l'appel de :creatChildDevice()

--création du Child
local child = self:createChildDevice({
	...
}, MyClass)
	
--modification d'autres paramètres
local ChildAPI = api.get("/devices/"..child.id)		--récupère l'API du Child
	ChildAPI.roomID = self.ParentAPI.roomID		--roomID (self.ParentAPI initialisé dans le OnInit() du parent)
	ChildAPI.properties.deviceRole = "Other"	--role
api.put("/devices/"..child.id, ChildAPI)		--on appllique

du coup j'ai fixé le roomID ainsi que le deviceRole.

 

Je me demande d'ailleurs si c'est pas plus simple de fixer trous les paramètres comme de cette manière plutôt que dans le  :creatChildDevice() 

[Lazer]

Bravo.

 

A ma connaissance il n'y a pas de liste officielle des propriétés qu'on peut définir lors de la création du child device, il faut tester au cas par cas.

 

Note : le roomID n'est pas d'une "propriété" au sens où il ne fait pas partie de la sous-table "properties", contrairement à deviceRole.

Pourtant cela n'a pas vraiment d'incidence sur le fait de pouvoir définir la valeur ou non lors de sa création...

[jjacques68]

Il y a 4 heures, Lazer a dit :

Pour connaitre ce qui est dispo dans self, il te suffit de parcourir la table avec une boucle for k, v in pairs(self)...

hmmm erreur, il aime pas le "pairs(self)", il me dit que c'est un "userdata" au lieu d'une table 

Modifié le 5 août 2022 par jjacques68

[Lazer]

Ah oui, en effet....

 

Cf bout de code ici :

 

Du coup, il faut explorer manuellement...

 

[jjacques68]

oui voilà ! c'est ce à quoi j'étais entrain de penser !

Je l'avais déjà en plus 

merci !

[jjacques68]

ah zut, ça me donne les fonctions disponibles, pas les propriétés...

[jjacques68]

y a quand même un truc étrange avec l'init des child...

 

déjà ça fait le 4 ème child que je créé ces derniers jours en faisant TOUT pour pas qu'il soit de type "light" (je parle de son type, rôle, catégorie, interface, ..., ..., ...)

 

Quand je parcours l'API des child, visiblement TOUT EST OK niveau paramètres.

 

MAIS !

 

il faut attendre un reboot de la HC3 pour ce soit vraiment pris en compte !!

ça semble délirant alors,  je m'explique pourquoi je dis ça :

 

la backup auto de @Lazer fait que la box redémarre toutes les nuits (ça c'est pour la partie redémarrage).

J'ai un script qui m'éteins toutes les lumières à une certaine heure ; que je filtre avec :

ListeDevice = fibaro.getDevicesID({visible=true, properties={isLight=true}})

Et bien mes Child, où je fais tout pour qu'ils ne soient PAS DE TYPE "light", s'éteignent quand même le premier soir !!!

EDIT : je viens de recréer un child, il n'est pas listé par le filtre ci-dessus... ?!

 

Le lendemain soir ce sera ok, ils resteront allumés !

 

c'est de la science fiction ça !?

 

 

 

 

 

 

 

Modifié le 6 août 2022 par jjacques68

[jjacques68]

Je confirme, il faut bien un redémarrage de la box pour que le Child soit réellement bien configuré.

Sauf que on a aucune vision de la chose...  

 

[jojo]

Le 06/08/2022 à 08:17, jjacques68 a dit :

c'est de la science fiction ça !?

mais non tout a une explication très logique.

Avant le bit avait deux valeur possibles : 0 ou 1.

Maintenant, avec les avancées de l'informatique moderne, il faut y ajouter une troisième valeur possible : 0,5

CQFD ...

[jjacques68]

 ben disons qu'il reste des zones d'ombres.

et puis y en a qui apparaissent avec les mises à jour.

puis y en a qui n'ont jamais été corrigé (là je pense au panneau d'arrosage...)