jjacques68

j'ai la chance d'en avoir 2 qui fonctionnent comme je le souhaite (via 1 QA de gestion). après c'est que pour du on/off des sèches serviettes...

bon c'est toujours pas le fil pilote...

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

je ne sais pas ce qui te retourne cette réponse. Mais je pense que pour l'exploiter il faut l'avoir en format table et non chaîne. Du coup, pour faire des simulations je travaillerai avec une table (donc solution 1). Au final tout est de type table.

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

Pas sûr d'arriver à expliquer ce que tu affiches provient d'un json.encode(), donc c'est une chaine de caractères. Et donc ne peut pas être utilisée en tant que table. si tu veux utiliser le même style de syntaxe, il faut alors écrire ta table sous forme de chaine et ensuite faire un json.decode(). mais c'est pas agréable à utiliser... (avis perso) Ce que j'ai posté est la même chose sous forme de table et non de chaine. copie/colle c'est exemple et regarde le debug, tu as les 2 manières d'écrire : --à partir d'une table resp = {{deviceType=0, nukiId=1, name="Entrée1"}, {deviceType=0, nukiId=184981569, name="Entrée"}, {deviceType=0, nukiId=3, name="Entrée3"}} print("point de départ en table :", resp) print("on l'utilise comme une table : ", resp[1].name) resp = json.encode(resp) --on transforme en string print("transformé en chaine : ", resp) print('****************************************************') --à partir d'une string resp = '[{"deviceType": 0, "nukiId": 1, "name": "Entrée1"}, {"deviceType": 0, "nukiId": 184981569, "name": "Entrée"}, {"deviceType": 0, "nukiId": 3, "name": "Entrée3"}]' print("point de départ en chaine : ", resp) resp = json.decode(resp) --on transforme en table print("transformé en table : ", resp) print("on l'utilise comme une table : ", resp[1].name)

ah et aussi la syntaxe : resp = { {deviceType=0, nukiId=1, name="Entrée1"}, {deviceType=0, nukiId=184981569, name="Entrée"}, {deviceType=0, nukiId=3, name="Entrée3"}, }

si tu remplaces les [] par {} ?

alors ça je suis pour !!

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 !?

et ça fait que commencer...

faut que je regarde de plus près...

@Nico tu feras un topic pour l'instal de ton groupe

@Lazer oui ça me parle ces sujets de discutions en effet dis comme ça, c'est plus simple

ah étrange ça... Chez moi j'ai pas constaté ça... ... Je viens de checker vite fais les log de l'onduleur, c'est vrai que j'ai plusieurs fois la ligne "fonctionne sur batterie", mais ça dur 1 seconde à chaque fois. C'est l'auto test de l'onduleur non ? (onduleur eaton 5P racké)

La question maintenant est : redémarre t elle toute seule après coupure secteur ? @Nico tu te mets en mode survivalist ? Mais on va y devoir y aller tout doucement, je le crains...

et pendant un long, très long, très très long moment...

merci @jojo pour ces essais. Mais si on est pas là ... ? y a pas aussi une manip avec le bouton power pour lancer un recovery ? je sais plus...

ouai... donc on va attendre qu'un stagiaire se remette dessus quoi

ah tient ! Je n'utilise pas GEA... mais est ce qu'elle fonctionne ? tu peux tester ?

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

oui voilà ! c'est ce à quoi j'étais entrain de penser ! Je l'avais déjà en plus merci !

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

Ok je comprends... on connait la liste des propriété pour le initialeProperties du :creatChildDevice() ? 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()

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 !