Lazer

Pour ajouter une interface, tu ne peux pas le faire injectant un paramètre dans le JSON d'un module. Car il ne s'agit pas que d'ajouter un nouvel élément à la table interfaces du module, cela va également créer des nouvelles propriétés dans le module, qui dépendent de l'interface ajoutée. => il faut appeler la méthode addInterfaces du QuickApp (avec l'ID du parent ou d'un enfant, peu importe ça fonctionne pour les 2) Tu peux regarder comment je fais en LUA dans ma librairie tools que tu trouveras dans tous mes QuickApps du forum. Ou alors directement via une méthode GET en passant par callAction : /api/callAction?deviceID=123&name=addInterfaces&arg1=%5B%22power%22%5D /api/callAction?deviceID=123&name=addInterfaces&arg1=%5B%22virtualEnergyConsumption%22%5D Remarque de fond sur la gestion de modules : Je n'aime pas la technique consistant à créer autant d'enfants que d'informations à remonter. Ex : un enfant de type binarySwitch, un autre de type powerMeter, un autre de type energyMeter, et un autre de type battery... ça surcharge l'interface, et remplie la DB de nombreux modules inutiles. Je préfère sélectionner soigneusement le type de mon module (par exemple binarySwitch), et lui ajouter les interfaces nécessaires, donc dans cet exemple : power, energy (ou virtualEnergyConsumption), et battery => On a 1 seul module dans l'interface, c'est propre, concis, et toutes les informations utiles sont bien présentes. Fibaro a inventé ce concept d'interface sur la HC2, il nous permet depuis la HC3 de l'appliquer aux QuickApps, autant en profiter.

Oui ça c'est normal. Relis bien mon message, ce n'est pas ce que je demandais => Soit mettre le power sur un child existant d'un autre type, soit ajouter virtualEnergyConsumption sur ce child de type powerSensor

J'ai l'impression que c'est une limitation actuelle de la box... je n'ai pas non plus cette option sur les powerSensors, alors que je l'ai que les autres types de modules (sur ma capture d'écran d'hier, c'était un binary switch, à laquelle j'ai ajouté l'interface "power") Barelle, plutôt que de créer un child dédié pour la mesure de puissance, est-ce que tu ne pourrais pas l'ajouter en tant qu'interface power sur un module existant (parent ou enfant) ? Si le type est différent, je pense que la HC3 laissera l'utilisateur activer l'option virtualenergyconsumtion. Autre piste, forcer l'ajout du virtualEnergyConsumption via l'API sur le child en question, je pense que ça peut marcher (auquel car ça serait juste une limitation de la page Web, mais pas de la box, ce ne serait pas la 1ère fois que Fibaro nous fait le coup)

Voilà une capture d'écran : Barelle ne pourra pas cliquer à ta place

Oui j'ai vu, super prix, mais y'a un doute sur le fait qu'il soit neuf ou reconditionné....

Les modules qui remontent une puissance (power, en Watts) ne sont pas gérés par le panneau d'énergie. Comme son nom l'indique justement, il ne présente que les données issues des capteurs qui remontent une énergie (energy, en kWh) Ce que tu peux faire à partir d'un module qui remonte la puissance, c'est d'activer l'option virtualEnergyConsumption, il y a une case à cocher pour cela dans les propriétés du module. La box va automatiquement calculer l'énergie en kWh à partir de la consommation instantanée en W, et donc le module devrait être géré par le panneau d'énergie.

Ah oui pas bête la DHT22, j'oublie toujours que le nouveau Smart Implant est compatible.

Entre la fiabilité toute relative du capteur de température intégré, le fait qu'il soit situé sur la fenêtre (donc élément froid), et en hauteur (donc au dessus de la tête), et le fait que ça soit un module sur batterie donc pas adapté à remonter la température chaque minute, il est clair que ce type de module ne peut pas être utilisé pour de la gestion de chauffage. Ces capteurs de températures intégrés aux modules domotiques (FGK, FGMS, FGSD, etc), c'est du gadget plus argument commercial que réellement utile. A la limite ça donne une indication de l'ambiance générale de la pièce, mais c'est insuffisant pour gérer du chauffage. Le mieux ça reste la sonde Dallas (une originale, pas une clone chinoise) branchée sur un FGBS Smart Implant, ça c'est ultra fiable et précis. Le souci évidemment, c'est d'amener une alimentation électrique.

@jjacques68 hum.... c'est moche Quick & Dirty comme ils disent .... ça marche, et puis un jour ça ne marchera plus

Donc tu as tout réécris ? Tu est bien motivé...

Ah, changement de comportement constaté lors de l'utilisation de net.httpClient() Lorsqu'on appelle http:request(), si l'hôte distant est joignable, la fonction success() est appelée, avec les entêtes et les données dans la variable response, qui est une table : httpClient:request(url, { success = function(response) print(response.status) --> Exemple : 404 print(response.data) --> Exemple : "" end, error = function(message) end, }) Quand le code retour est 404 (page non trouvée), la variable response.status contient bien le code 404, comme avant. En revanche, dans ce cas précis, le variable response.data est une chaine vide, même si l'hôte distant a retourné quelque chose (car plusieurs serveurs Web affichent un message personnalisé pour avertir l'utilisateur que le page demandée n'existe pas). Précédemment, response.data contenait cette page, ce n'est plus le cas maintenant. QuickApp affecté : Network Monitor Fibaro a dû considéré que le contenu de la page n'avait pas d'importance quand le code retour est 404, c'est bien dommage....

@henri-allauch mon HC3 était stable dès le 1er jour, et plus que la HC2 qui a planté 6 fois durant sa dernière année de fonctionnement en production (redémarré automatiquement par mon watchdog sur NAS). Durant les 6 mois suivants, ou j'ai laissé tourné la HC2, mais sans aucun module Z-Wave, celle-ci n'a pas craché une seule fois => ma conclusion, le nombre de modules Z-Wave important faisait planter ma HC2... bon il faut dire qu'elle n'a jamais subit de recovery, donc elle fonctionnant dans son jus, avec la base de données d'origine en v3 migrée en v4. Pas si mal en fin de compte. @mprinfo : tous mes QA sont taggués, aucun souci.

Ah OK, oui le QA Surveillance Station, mais en fait il fonctionnait avec une mise à jour vers la 5.100. Ce qui ne fonctionnait pas, c'était uniquement la création de nouveaux enfants, donc typiquement quand on fait une nouvelle installation avec une box neuve, ...... ou alors un recovery chaque semaine

J'ai modifié des QA, mais ce n'était pas une condition nécessaire pour cette mise à jour. Ce qui m'a retenu tout ce temps, c'était les instabilités (reboot, serious problem detected, ...), qui semblent avoir été résolues avec cette mise à jour. Car la 5.070 était vraiment très stable. Seul problème non bloquant, des freeze de temps en temps... on verra si ceux-là sont toujours présents avec la 5.100 ou non.

Et voilà, je viens de faire la mise à jour sur ma box de production. Un peu long... plusieurs longues minutes, mais c'est passé et tout fonctionne. Ne pas oublier le célèbre vidage de cache après la mise à jour (CTRL+F5 suffit) J'étais en 5.070, donc depuis mars 2021, soit 11 mois ! Je vais pouvoir profiter des nouveautés.... espérons que cette version 5.100 stable soit vraiment stable

Exemple, là c'est pas du Grafana, mais du PHP + JavaScript, mais c'est juste pour montrer que SQL permet de manipuler des données sur de longues périodes (ici 12 années), et les performances sont excellentes, les graphs sont générés dans la seconde : Et sous Grafana j'avais fait ça, un tableau de bord de la répartition des consommations électrique par catégorie, les données sont issues de la base SQL DomoCharts :

En réalité, InfluxDB est conçu pour l'ingestion massive de données, exactement ce qu'on fait avec la domotique. En réalité il est même plus adapté que MySQL pour cet usage. Mais je trouve que sa configuration est complexe, la manipulation des données peu aisée, enfin surtout l'aspect historisation à long terme. C'est pour cela que je préfère SQL, je connais le langage depuis des années, je fais vraiment ce que je veux de mes données, et j'ai trouvé les bonnes optimisations (clés, index, etc) pour conserver de bonnes performances même avec des millions de lignes dans la base de données. Rien que pour la Téléinformation, j'ai plus de 10 ans d'historique (depuis qu'on habite dans la maison), et ça tourne comme une horloge. Donc pas de raison de changer en ce qui me concerne. Et vu que Grafana peut aller piocher les données aussi bien dans une base SQL que InfluxDB, j'ai fait mon choix Après les beaux tableaux de bords sous Grafana, ça n'a rien à voir avec la base choisie (SQL, InfluxDB, ou autre), c'est juste de la manipulation dans Grafana. On trouve pas mal de tutos et d'aide sur Internet, il faut pas mal fouiller, car là aussi, c'est loin d'être simple de prime abord.

Ah tu vas mettre les données dans InfluxDB ? Tu vas voir, c'est assez compliqué... perso je n'ai pas aimé, on n'a pas une bonne maitrise sur la conservation des données à long terme, de ce coté là je préfère rester en SQL, que je maitrise relativement bien.

Oui ce courant de fuite suffit à alimenter le module. Mais en fait attention à ce que tu dis, il n'y a pas de relai dans le module, c'est justement pour cela que ça fonctionne. Dans un dimmer (FGD), c'est un triac, donc une sorte de transistor Cela ne peut pas fonctionner pour un relai, c'est la raison pour laquelle tous les modules avec relais (FGS chez Fibaro, ou autre marque) ont impérativement besoin du neutre. Pour en revenir eu Dimmer, oui le dimmer est obligatoire en pratique à cause des LED. Cela dit, même avec un un bypass, ça ne fonctionnera jamais aussi bien qu'avec le neutre, donc autant que possible, il faut essayer d'amener le neutre en passant une aiguille en nylon dans les gaines. Pour du ON/OFF, ça marche bien, mais quand on fait de la variation (soft start & stop, ou bien gradation partielle), c'est pas trop avec les LED. Comme je dis souvent, pour mettre toutes les chances de son coté, il faut utiliser le neutre, et des LED des gammes professionnelles des grand fabricants reconnus (Ex : Parathom Pro chez Osram/Ledvance) Avec les LED chinoises, c'est la loterie, parfois ça fonctionne bien, parfois mal...

Très bonne question ! Les électrons arrivent par la phase, il faut qu'ils puissent repartir. En fait, il y a un courant de fuite, très faible, qui va passer au travers de la lampe, pour retourner vers le neutre. Normalement avec des ampoules classiques (incandescentes et halogènes), ce courant très faible n'est pas suffisant pour allumer le filament, donc la lampe reste totalement éteinte, et tout fonctionne bien dans le meilleure des mondes. Avec les fluocompactes et les LED, c'est plus compliqué, car l'électronique de la lampe va être alimentée, et là les résultats sont imprévisibles selon les marques / modèles. Le risque étant un scintillement permanent, pas du tout acceptable. Il faut donc ajouter un bypass, petit module vendu par Fibaro (qui contient condensateur + microprocesseur, en fait on ne sait pas exactement c'est leur secret) qui va permettre de dévier ce courant de fuite afin qu'il ne traverse pas la lampe LED.

Bienvenue sur le forum

Héhé tu as lu le code, c'est bien Alors si, elle est bien utilisée, en fait elle permet de réaliser une série d'instructions (get...). La différence avec le WALK, qui va parcourir toute une branche de façon récursive (et ramener potentiellement énormément de valeurs), la SEQUENCE permet d'aller chercher plusieurs valeurs à des adresses différentes, en une seule fois. C'est plus facile à écrire en LUA, et plus rapide à l'exécution. Tu as un exemple d'utilisation dans le QuickApp Onduleur Eaton. J'ai rajouté dans le 1er post un autre exemple d'utilisation basique. J'ai également rajouté l'information pour activer le mode debug de la librairie, avec SNMP.isdebug = true

@mprinfo oui mais toi tu as choisi d'exploiter l'API HTTP, donc c'est complètement différent. Là où @jjacques68 utilise SNMP, exactement comme je le fait, donc c'était assez facile de faire un mini tuto. Je n'ai pas écris de code LUA spécifique pour le coup, tout existait déjà.

Voici :

Librairie SNMP v1 en LUA pour QuickApps sur HC3 Cette librairie est déjà utilisée dans mes QuickApps onduleur Eaton (partagée sur le forum), et Ubiquiti EdgeRouter (jamais partagée....) En fait de librairie, il s'agit en réalité d'un fichier à inclure dans un QuickApp, et même plus spécifiquement d'une table au sens LUA du terme. A la demande de @jjacques68, voici les 2 ou 3 trucs à savoir pour l'utiliser, comme toujours avec mes librairies, elles sont conçues pour être facilement réutilisables d'un QuickApp à l'autre. C'est là qu'on voit la force des fichiers dans les QuickApps Seule la version 1 du protocole SNMP est supportée, donc trames en clair sur le réseau, pas de sécurité, etc. Pour ce qu'on en fait (usage en réseau local), c'est largement suffisant. A l'exception de la fonction SNMP:configure() qui est synchrone et appelée une seule fois avant d'utiliser la librairie, les autres fonctions sont asynchrones, sur le même modèle de net.HTTPClient(), donc la suite de l'exécution se déroule dans les fonctions success() et error() données en paramètre de chaque fonction appelée : SNMP:get() SNMP:set() SNMP:walk() SNMP:sequence() Initialisation Avant d'utiliser la librairie, il faut l'initialiser avec la fonction SNMP:configure(), par exemple dans QuickApp:onInit() : -- Ici les variables sont définies localement, mais idéalement ce sont des variables du QuickApp obtenues via self:getVariable() local protocol = "udp" -- paramètre obligatoire local host = "192.168.1.1" -- paramètre obligatoire local port = 161 -- paramètre obligatoire local community = "public" -- paramètre obligatoire local version = 1 -- paramètre obligatoire local language = "en" -- paramètre facultatif local timeout = 5000 -- paramètre facultatif -- Initialize SNMP library local configured, SNMP_URL = SNMP:configure(protocol, host, port, community, version, language, 5000) if configured then self:debug("SNMP library v" .. (SNMP._VERSION or SNMP.version or "???") , "successfully initialized") else self:error("Error : Can't initialize SNMP library :", SNMP_URL or "<i>nil</i>") self:warning("QuickApp stopped") return end Note : on peut activer le mode debug de la librairie de la façon suivante, cela permet d'obtenir des traces très détaillées : SNMP.isdebug = true Lecture d'une valeur - "snmpget" La fonction SNMP:get() permet de lire la valeur d'un OID donné. L'OID peut être l'index numérique, ou bien un nom prédéfini. Dans cet exemple, "SNMPv2-MIB::sysDescr.0" est strictement identique à ".1.3.6.1.2.1.1.1", mais en plus lisible : local oid = "SNMPv2-MIB::sysDescr.0" SNMP:get(oid, { success = function(response) if type(response) == "table" and response.errorStatus and response.errorStatus == 0 and response.value then self:debug("Value =", response.value) else self:error("Error : invalid SNMP response :", SNMP.ERROR_STATUS[response.errorStatus] or "???") end end, error = function(response) self:error("Error : SNMP get failed :", response or "???") end, }) Modification d'une valeur - "snmpset" La fonction SNMP:set() permet de modifier la valeur d'un OID donné : Dans cet exemple on active le port n°5 du switch : SNMP:set("IF-MIB::ifAdminStatus.5", 1, { -- Enable port 5 success = function(response) if type(response) == "table" and response.errorStatus and response.errorStatus == 0 and response.value then self:debug("New value =", response.value) else self:error("Error : invalid SNMP response :", SNMP.ERROR_STATUS[response.errorStatus] or "???") end end, error = function(response) self:error("Error : SNMP set failed :", response or "???") end, }) Parcours d'un arbre - "snmpwalk" La fonction SNMP:walk() permet de parcourir un arbre à partir d'un OID donné. Cet exemple liste tous les ports d'un switch/routeur : SNMP:walk("IF-MIB::ifName", { success = function(snmp) for j = 1, #snmp do local oid = tools:split(snmp[j].oid, ".") local index = oid[#oid] self:debug("Found interface <b>" .. snmp[j].value .. "</b> with index <b>" .. index .. "</b>") end end, error = function(message) self:error("Error : can't get device interface list from router :", message) end, }) Lecture de plusieurs valeurs La fonction SNMP:sequence() permet de réaliser une série d'instructions (get...). La différence avec le WALK, qui va parcourir toute une branche de façon récursive (et ramener potentiellement énormément de valeurs), la SEQUENCE permet d'aller chercher plusieurs valeurs à des adresses différentes, en une seule fois. C'est plus facile à écrire en LUA, et plus rapide à l'exécution. Il faut donner en paramètre un tableau qui contient l'instruction à réaliser et l'OID. Les instructions seront réalisées dans l'ordre indiqué par l'index de chaque élément du tableau : local instructions = {} instructions[1] = { instruction = "get", oid = "SNMPv2-MIB::sysDescr.0", } instructions[2] = { instruction = "get", oid = "SNMPv2-MIB::sysContact.0", } instructions[3] = { instruction = "get", oid = "SNMPv2-MIB::sysLocation.0", } SNMP:sequence(instructions, true, { success = function() self:debug("System : <b>" .. (instructions[1].response or "<i>nil</i>") .. "</b>") self:debug("Contact : <b>" .. (instructions[2].response or "<i>nil</i>") .. "</b>") self:debug("Location : <b>" .. (instructions[3].response or "<i>nil</i>") .. "</b>") end, error = function(message) self:warning("Can't get router information :", message) end, }) Téléchargement Library - SNMP v1.1.lua