Lazer

100% d'accord

Voilà je confirme c'est ce que je disais au dessus

Justement, tu es ultra limité dans le __init(), c'est précisé dans la doc : WARNING: QuickApp.childDevices is not accessible in a child’s constructor, only in their methods. => Il faut que tu fasses un appel à setTimeout() pour exécuter une autre fonction qui aura les droits d'accéder à tous les objets

Dans le cas de mon IPX800, je crée un Child par entrée/sortie de l'IPX. Il faut que pour chaque Child, je puisse préciser, par une variable, à quel E/S il est associé : entrée numériques D1 à D56, entrée analogique A1 à A4, sorties numériques R1.... Si tu as un IPX avec 56 entrées numériques maximum, je ne vais pas créer 56 Childs devices si je n'ai besoin de gérer que, admettons, 10 entrées dans la HC3. Donc plutôt que de créer les 56 children, je laisse à l'utilisateur la possibilité de ne créer que les 10, et de modifier la variable de chacun de ces 10 modules, pour spécifier à quelle entrée numérique il est associé. C'est une propriété propre au Child, par au Parent.

Euh mais je comprend pas là ? Pourquoi tu voudrais faire une mise à jour du Child, il n'y a aucune raison de le faire, et donc de changer son ID ! Le child utilise le code LUA du parent, et c'est ça qui est génial, tu modifies le code LUA de ton parent = 1 seule modification, et tes 200 devices enfants en profite. Cela simplifie tellement les mises à jours et évite des copiers/coller fastidieux de code. Les seules choses que tu aies besoin de changer sur ton child device, c'est : - son nom, modifiable par l'utilisateur dans le GUI - ses variables => on retombe dans le bug que j'ai signalé, impossible de modifier ses variables via le GUI (pour l'instant j'espère)

Putains les gars, vous faites les questions réponses tous seuls, enfin surtout JJacques, c'est impossible de suivre et encore moins de répondre là..... 15 messages en 1 heure, ça serait pas mieux de tester avant de poser la question ? Comme on dit, tourner 7 fois sa langue dans sa bouche....

Non surtout pas une prise. Les dimmers, c'est pour les lumières.

3000, wow ça va vite Merci les gars.

Perso j'en ai déjà des câbles coudés pour planquer derrière les meubles Dispo en différente longueur, mais rigides, disponible dans les 2 sens : https://www.amazon.fr/gp/product/B0044682Q0/ https://www.amazon.fr/gp/product/B0044662NU/ https://www.amazon.fr/gp/product/B0043Q8A72/ https://www.amazon.fr/gp/product/B00485ME02/ etc

Et ben on dirait que y'a plus de pénurie de HC3 Bienvenue au club les gars

Yes ils disent que l'embout serti est souple et coudable comme on veut

Vous avez vu les câbles de brassage Unifi ? C'est tout mignon, de toutes les couleurs, coudés, avec des petits tailles pour faire un brassage ultra propre : https://eu.store.ui.com/products/unifi-ethernet-patch-cable

Ben oui, avec setVariable()

La méthode createChild() n'existe pas au sens Fibaro, c'est juste une méthode crée par le programmeur de l'exemple que tu as utilisé. L'appel à setVariable() c'est juste après avoir créé le child device avec la fonction self:createChildDevice() Dans mon code je récupère le retour dans la variable "child", mais si tu l'as appelé différemment faut que tu adaptes. Exemple de bout de code pour comprendre la logique (non testé) : local child = self:createChildDevice({ name = "myChild", type = "com.fibaro.multilevelSensor", }, childClass ) if child then -- Add child device unit if childUnit then child:updateProperty("unit", childUnit) end -- Add child device variables child:setVariable("Digital_Input", "0") else -- Afficher une insulte end En bonus je t'ai mis l'instruction pour ajouter une unité au périphérique enfant... en pratique c'est utile pour les devices de type multilevelSensor (par exemple luminosité en lux, bruit en dB, etc). C'est inutile pour les températures et humidité qui disposent déjà de leur type prédéfini (com.fibaro.temperatureSensor et com.fibaro.humiditySensor) car l'unité est automatiquement configurée dans ce cas. Sinon tu peux t'inspirer du QuickApp Netatmo Weather Station QA for HC3 sur le Market : https://marketplace.fibaro.com/items/netatmo-qa-for-hc3 En fait mieux que ça : - autant de child que d'entrées/sorties, tant numériques qu'analogiques - et j'ai même prévu de laisser le choix à l'utilisateur, il pourra choisir de créer ou non les devices correspondants aux différents I/O de l'IPX800 L'idée c'est de faire un QA entièrement paramétrable, sans saisir une seule ligne de code LUA, juste en cliquant sur des boutons et en renseignant des valeurs dans les variables de chaque device (via l'interface graphique, quand Fibaro aura implémenté l'onglet manquant que je réclame quelques messages plus haut) Dans la variable de chaque QA Child justement c'est tout l'objet du bug remonté.

Pourtant je m'étais déjà préparé psychologiquement à développer un watchdog pour la HC3. Du coup il n'y aura certainement pas besoin

Ben tu vois 2 lignes au dessus que je ne pourrai pas le partager tant que Fibaro ne corrigera pas le bug... donc ça implique que OUI je vais le partager. Enfin j'y crois. Que Fibaro va finir de développer sa box pour ajouter les fonctions manquantes. En tout cas je m'éclate là Et si tu me demande de le partager en l'état, pour l'instant c'est impossible, c'est un prototype très loin d'être fonctionnel, il y a encore pas mal d'heures de développement. Surtout que mon projet a déjà évolué entre hier et aujourd'hui, au fur et à mesure que je découvre les possibilités des Quick Apps.

@Krikroff Nouveau bug, peut-être déjà remonté ? On peut définir des variables pour les child devices, comme mentionné dans la doc : https://manuals.fibaro.com/knowledge-base-browse/hc3-quick-apps-managing-child-devices/ Juste après avoir créé un enfant, j'ai utilisé une instruction setVariable() comme ceci pour définir une variable dans l'enfant : child.setVariable("Digital_Input", "0") On retrouve bien cette variable dans le JSON de l'enfant : Cependant, impossible d'y accéder depuis l'interface Web, le panneau de propriétés de l'enfant ne montre pas ses variables : J'ajoute que le bug est reproductible sur tous les Child Devices que j'ai créé, de différents types. => Je pense que Fibaro a "oublié" d'implémenter le panneau de configuration des variables pour les device enfants. Évidemment, ça me bloque dans le développement de mon QA IPX800.... donc l'immédiat je vais tricher en injectant manuellement les valeurs dans les variables, mais il faudra que Fibaro ajoute ce panneau indispensable pour que je partage le QuickApp aux utilisateurs.

Admettons.... l'explication se tient.... mais alors pourquoi l'avoir mis sur des équipements destinés à être installés en intérieur sur courte distance ? - Tous les premiers UAP, EdgeRouter 5 POE, certains switchs, etc A mon avis l'autre raison non avouée, ce sont des couts de licence et/ou de chipset plus économiques N'oublions pas que ce qui a fait le succès d'Ubiquiti, c'est de proposer du matériel aux caractéristiques pro à des tarifs compétitifs. Faut bien faire des économies quelque part. Je ne sais pas pour la protection, en tout cas le port n'est pas alimenté par défaut. Le danger pour moi réside dans le scénario typique où tu avais une vieille borne UAP alimentée en 24V passif sur un port, tu la débranche, et branche autre chose à la place. Si pas de protection, pouf !

ça donne faim

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.... Ce que je te conseille parce que c'est finalement le plus simple, c'est de créer un QA de type Device Controller, et tu auras une trame de code utilisable. Heureusement de ce coté là, sur les bouts de codes par défaut des différents types de QA, ils se sont appliqués un minimum en donnant un template fonctionnel pour chaque type de QA.

Ben oui à ma connaissance y'a que Ubiquiti pour faire du 24V passif propriétaire... et comme expliqué c'est dangereux. J'aime bien cette marque, mais ça, c'est une aberration. EDIT : Nico a raison, commence par lire la datasheet, c'est quand même clair ce point

Ton tuto est prévu pour l'IPX800 v3 Et de ce que j'ai compris de ton tuto, tu n'as pas un QA unique, car tu crées autant de QA qu'il y a d'entrées/sorties sur l'IPX800 Perso je veux simplifier tout ça, exploiter les QA tels qu'ils sont prévus pour, avec les Child Devices c'est hyper puissant.

Par contre un truc galère pour débugguer, c'est que le numéro de ligne renvoyé dans l'erreur LUA ne correspond pas au numéro de ligne de l'éditeur. J'en déduis que la HC3 encapsule notre code dans un code plus large. En cela, rien d'étonnant, c'était déjà le cas sur les Main Loop des modules virtuels de la HC2. Mais il faudrait retourner le numéro de ligne correct pour l'utilisateur.... un petit bug à faire remonter à Fibaro !

Avez vous remarqué que la HC3 intègre nativement un Watchdog sur les QuickApps, lorsque l'un d'eux plante, il est automatiquement redémarré à la minute suivante : C'est chouette ça

Va installer un Wall Plug dans les combles toi... ça coute 2 fois le prix, et tu n'auras jamais besoin du relai commandé. Ce module a une réelle utilité, encore faut-il en avoir le besoin. C'est typiquement le cas de @fel-x qui rencontre une problématique d'un module distant au fond de son jardin. Tu remarqueras que je n'ai pas cité les combles par hasard, car c'est un endroit surélevé de la maison, qui a normalement une bonne vision sur l'ensemble du jardin, et qui présente la particularité de n'avoir que les tuiles à traverser, beaucoup plus transparentes aux ondes radios qu'un mur en parpaing/béton armé.