Lazer

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

Mettons les choses au clair : il n'amplifie pas le signal. D'ailleurs, même le terme "répéteur" est impropre. Tu connais surement la chanson : le Z-Wave est un réseau maillé, dont chaque module alimenté sur secteur peut router les trames vers son voisin. Donc ce module là ne fait rien de plus. Il route les trames. Point. Il n'a aucune autre fonction. Ensuite, en fonction de la configuration des lieux, il faut le placer au mieux. Sachant que le comportement des ondes radio est imprévisible, il faut tester in situ. Il est évident que de le coller au module FGBS ou à la box domotique n'a aucun intérêt. Par contre, le décaler d'un mètre, peut parfois faire une grande différence en créant un chemin alternatif qui permettra d'établir une communication stable.

Si tu as un switch Unifi qui balance du 24V sur le câble, et que tu branches ton PC, une enceinte Sonos, ta TV, une imprimante, ou n'importe quoi à l'autre extrémité du câble => Pouf fumée Si tu as un switch POE 802.3 (quelque soit la marque), il n'envoie pas de tension sur les câbles tant qu'il n'est pas certain que l'appareil en face accepte la-dite tension => aucun risque

Bienvenue sur le forum

Encore une fois : cela n'a rien à voir. Tu te fais des noeuds au cerveau pour rien.

Je ne comprenais pas cette histoire de POE A et B sur l'autre topic, mais maintenant c'est clair : ça n'a juste rien à voir. Comme dit Nico, tu câbles tout en A ou tout en B, mais l'important c'est que tu fasses A A de chaque coté, ou B B. Perso je suis en B chez moi, on en avait parlé sur le forum il y a quelques semaines en plus. Les 2 normes sont correctes, mais par usage, en résidentiel en France, on câble plus souvent en B. Mais encore une fois peu importe si tu câbles de la même façon des 2 cotés. Bref le câblage n'a rien à voir avec le POE. Ensuite, le POE, comme on l'a dit plein de fois : - passif : truc propriétaire sur certains matériels Ubiquiti (pas tout), avec du 24V injecté. Dangereux si tu branches un appareil non compatible à l'extrémité, tu peux le cramer. - actif : le standard répondant aux normes 802.3af 802.4at 802.3bt (plus de puissance) => 48V autonégocié, il n'y a aucun risque, que le switch n'envoie la tension que si l'appareil en fait est compatible avec le POE. Tous les fabricants l'ont adopté, y compris Ubiquiti.

Donc on est bien d'accord, ça n'a rien à voir avec les caméras ? Et encore moins Hikvision ?

En fait moi je vais répondre que OUI c'est possible Avec un convertisseur POE actif 802.3af vers POE passif 24V : https://www.amazon.fr/dp/B01N9MJL91/ J'utilise ça pour alimenter ma vielle borne UAP de 1ère génération (donc alimentée en POE passif uniquement avec le petit transformateur/injecteur que j'ai viré), branché sur un switch POE actif 802.3af tout ce qu'il y a de plus standard. Ainsi je n'ai plus besoin de l'injecteur, et ce convertisseur fait bien son job EDIT : mince je crois que je n'ai toujours rien compris Je précise que ça ne fonctionnera pas avec une caméra, car elle a besoin de POE actif 802.3af, le truc standard quoi.

Merci je sais déjà.... Encore une fois ce n'est pas mon QA, c'est juste un exemple d'utilisation des fonctions reboot et shutdown partagées par Krikroff.

Y'en a des tonnes de ce type de ruban sur Aliexpress, et le gros souci c'est que ce n'est pas standard du tout car cela utilise 5 fils (enfin 6 avec l'alimentation), et qu'il n'y a aucun contrôleur domotique pour les piloter. Tout ce qu'on trouve, ce sont des contrôleurs propriétaires avec une petite télécommande infra-rouge, bref le truc bien nul si tu veux mon avis. Alors oui, la promesse du ruban RGB pour lequel on puisse choisir 2 couleurs de blancs, une pour le jour, une pour la nuit, c'est génial et super WAF. Mais impossible à intégrer en domotique à l'heure actuelle.... donc pas WAF. Ou alors tu es très bricoleur, et tu développes ton propre contrôleur domotique maison à base de Raspberry PI, Arduino, ou Z-Uno... mais çà te fera pas mal de codage.

Les petits codes LUA comme celui-là, j'ai toujours préféré les laisser "en ligne" sur le forum, car cela permet à Google de les indexer, et c'est justement très pratique pour débuter, car on fait une recherche de fonction sur Google, et hop on tombe sur la page avec le bel exemple d'utilisation du code. Tu vas me dire qu'il y a le topic dédié aux Snipets LUA pour ça, sauf que 99% du code LUA se trouve disséminé sur tout le forum, ça a toujours été comme ça, et c'est très bien ainsi tant que c'est indexé. Sur un forum, on échange, on teste des bouts de code, et on les fait évoluer. C'est encore plus vrai pour l'API de reboot qui a changé au moins 3 fois depuis la HC2. En plus ce bout de code n'a aucun intérêt dans un QA qui ne fait que ça, le but c'est de l'intégrer dans un vrai QA qui fait des choses utiles. J'ajoute que ce n'est pas mon code, je ne vais pas m'en attribuer le mérite en partageant un QA complet. Bref, c'est très bien comme ça. Évidemment les vrais QA je les partagerai en pièce jointe, dans un topic dédié, avec le tuto complet, comme j'ai toujours fait pour les VD et les Scènes. Mais c'est prématuré, je n'ai rien de prêt, et puis de toute façon ce n'est pas une course Et puis Nico fait surtout du mode bloc et il n'aura que faire de rebooter sa future HC3, car la sienne sera sans bug.

OK merci, ça pourra servir. J'envisage personnellement de remplacer mon ZXT-120 qui est sujet à bug (même si ça reste rare) par ce nouveau modèle ZXT-600 quand je ferai ma migration vers la HC3. Tiens nous au courant de tes expérimentations

Bah y'a rien de compliqué, c'est juste le code de @Krikroff avec 2 boutons : fibaro.HomeCenter = { SystemService = { -- reboot the gateway reboot = function() local http = net.HTTPClient() http:request("http://localhost/api/service/reboot",{ options={ headers = {["X-Fibaro-Version"] = "2"}, method="POST" } }) end, -- put the gatewau in slee mode suspend = function() local http = net.HTTPClient() http:request("http://localhost/api/service/suspend",{ options={ headers = {["X-Fibaro-Version"] = "2"}, method="POST" } }) end, -- shutdown the gateway shutdown = function() local http = net.HTTPClient() http:request("http://localhost/api/service/shutdown",{ options={ headers = {["X-Fibaro-Version"] = "2"}, method="POST" } }) end } } function QuickApp:btnShutdown(param) fibaro.HomeCenter.SystemService.shutdown() end function QuickApp:btnReboot(param) fibaro.HomeCenter.SystemService.reboot() end function QuickApp:onInit() end

Je crois que c'est tellement HS que je n'ai pas compris la question Tu ne pourras jamais alimenter une caméra avec une borne Wi-Fi