Lazer

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

C'est du UDP, donc à toi de gérer. Chaque trame SNMP est identifiée par un ID unique. Désolé j'ai oublié de te partager le tuto, je te prépare ça.

Article de Domadoo qui résume bien les rôles de Matter et Thread : [Blog Domadoo] Qu’est-ce que Thread, ce protocole domotique utilisé par Matter ?

Ah oui je l'avais vu passer ce dashboard, là c'est niveau Master++ Quand j'avais joué avec, j'ai pas fait des beaux tableaux, mais juste des trucs utiles, l'idée c'était de sortir des infos que je pouvais pas obtenir avec le Domocharts de base. Pourtant on peut faire bien plus, il y a des tonnes de données en base, il faut maintenant savoir les traiter.

Franchement c'est pas évident à configurer Grafana.... j'ai conservé les pages PHP de Domocharts, parce que je n'ai pas réussi à tout reproduire dans Grafana. Du coup j'utilise les 2, et Grafana pour des graphiques un peu spécifiques que je n'arrive pas à produire avec Domocharts (exemple : comparaison de la consommation électrique en fonction de la température extérieure) ça fait longtemps que je n'y ai pas touché cela dit... il faudrait que je me replonge dedans. Je pense que ce que tu veux faire est réalisable. De mémoire, il est possible de créer une variable, qui sera l'ID du module à afficher, à sélectionner dans une liste déroulante. Ensuite, le graph sera automatiquement mis à jour avec le bon ID.

Bienvenue sur le forum

Oui si tu peux couper tous les appareils qui utilisent le Wi-Fi, c'est bon. Perso je mets mon téléphone en mode avion la nuit, mais vu qu'il reste toujours pas mal d'appareils que je peux pas couper (Netatmo, Roborock, etc), la question ne se pose pas, je laisse les bornes Wi-Fi allumées.

A vrai dire je ne sais pas si allumer/arrêter un appareil électronique va l'user prématurément ou pas... Mais attention quand même avec l'extinction des bornes Wi-Fi, bien penser à en laisser au moins une allumée dans la maison. Sinon, les appareils vont chercher du Wi-Fi pendant plusieurs heures. Avec pour conséquences, une augmentation des ondes et une augmentation de la consommation. Là oui c'est logique.

Top, merci pour votre retour les gars

Pas de chance pour ton appareil Netgear.... en même temps... Netgear quoi, tout est dit... Tu ne vas quand même pas réécrire tout le code du protocole SNMP ? Tu ne te rends pas compte, c'est un travail de fou, si je partage mon travail, c'est justement pour qu'il serve à la communauté. Je vais te préparer un tuto, laisse moi un peu de temps (et tu verras c'est vraiment ultra simple à utiliser) Oui c'est ça, il y a des OID qui sont standards et qu'on retrouve dans tous les équipements, et ensuite chaque constructeur peut implémenter ses propres OID spécifiques. C'est pour cela qu'ils fournissent des fichiers de MIB, ça permet d'obtenir le nom et le descriptif de chaque OID. Attention à ne pas utiliser private, c'est réservé à l'écriture. Normalement on se contente de public, accès en lecture seule, c'est bien suffisant. C'est le moment de parler sécurité. SNMP n'est pas du tout sécurisé de base... public et private sont par défaut sur tous les équipements, donc du coup, n'importe qui peut consulter voir modifier les informations. Déjà, on peut commencer par renommer les communautés. Et certains appareils permettent de filtrer par IP, donc on crée une liste d'accès pour n'autoriser que les équipements autorisés à faire des requêtes SNMP sur l'équipement. Enfin, idéalement il faudrait faire du SNMP v3 qui permet de chiffrer les communications. Mais là ce n'est pas implémenté dans mon code LUA, beaucoup trop de travail (et je ne sais même pas si ça serait faisable sur la HC3, vu qu'on ne peut toujours pas faire de SSL à ma connaissance)

Faut dire à madame de trier aussi hein Même en RAW, avec 1 To, on met un paquet de photos. 1ère étape après l'import depuis la carte, c'est de trier et supprimer les ratés, flous, doublons, etc.... ça fait déjà pas mal de ménage et de place gagnée sur le disque.

Oui c'est sûr, mais ça reste un loisir... on se fait plaisir comme on peut/veut Perso je prend plus de plaisir à prendre les photos, qu'à les retoucher. C'est quand j'utilise mon appareil que je m'éclate vraiment en fait. Puisque c'est le sujet du forum, pour 99% des gens normaux, la domotique c'est beaucoup de matos, pour pas grand chose....

Madame aime bien faire des albums, elle en distribue aussi à la famille. Et elle fait un calendrier par an aussi, ça finit dans la cuisine des uns et des autres, et c'est assez plaisant de revoir les photos de l'année passée comme ça. Même si bon, là on est éclairement dans de la photo style "Tata Ginette", rien d'artistique. Mes photos de voyages, j'en ai tiré quelques unes en agrandissement, là c'est vraiment sympa. Et pour le coup j'apprécie l'évolution de la technologie, mon 1er reflex n'avait que 8 Megapixels, c'est clairement insuffisant pour les grandes tailles. On a fait des blogs de voyages aussi, pas systématiquement, mais c'est vraiment sympa pour le partage, et pour revenir dessus longtemps après. La lecture des textes permettent de se remémorer des impressions qu'on a eu sur le moment, et qui ne transparaissent pas dans les photos. J'ai fait 2 mariages, j'ai remis les fichiers aux mariés, et mis les photos en ligne sur une galerie. C'est assez amusant de voir qu'il y a régulièrement des vus plusieurs années plus tard. Probablement des membres de la famille qui apprécient de revoir les photos régulièrement. Maintenant je mets mes photos sur Google Photos, et j'aime beaucoup la fonctionnalité qui te propose automatiquement des photos d'il y a 1, 2, 3,.... 10 ans. C'est spontané et inattendu.

Je t'incite à regarder mes QA existants, par exemple Onduleur Eaton, Xiaomi Roborock, GCE IPX800 & EDRT2, pour lesquels j'ajoute des interfaces aux modules. Par nécessairement pour des enfants d'ailleurs, puisque le principe est le même pour les modules parents. Attention à ne pas ajouter l'interface à un module qui la possède déjà, sinon c'est le redémarrage en boucle assuré. Donc avant d'ajouter, on vérifier si l'interface n'est pas déjà présente sur le module. Tout est dans ma librairie tools, mais les commandes de bases sont : -- mode bourin, là on va ajouter 3 interfaces d'un coup : local interfaces = {"power", "energy", "battery"} -- parent : self:addInterfaces(interfaces) -- enfant : child:addInterfaces(interfaces) -- ou n'importe quel device du système : fibaro.call(id, "addInterfaces", interfaces) Et regarde ma function tools.hasInterface() pour le reste.

Je t'ai dit qu'il faut ajouter l'interface power. Une fois cela fait, la propriété power apparaitra (le QA est automatiquement redémarré sitôt l'interface ajoutée) Chaque mot a son importance, il faut bien prendre le temps de lire mes phrases Je t'ai mis en gras et en couleurs les mots importants pour comprendre la logique des modules chez Fibaro (héritée de la HC2, donc ce n'est pas nouveau)

Sous Linux c'est très facile. Installation : apt install snmp Exemple d'utilisation de snmpget pour obtenir une infirmation sur un onduleur : snmpget -m +/root/stdupsv1.mib -On -c public -v 1 192.168.1.1 UPS-MIB::upsAlarmBatteryBad On y voit l'utilisation d'une MIB dans un fichier. Et aussi snmpwalk pour parcourir tout une branche d'un arbre SNMP. Ces 2 commandes sont indispensables pour se balader à la recherche des infos qu'on veut. Après la protocole est un peu particulier, ce que j'ai fait en LUA avec mes Modules virtuels puis QuickApp, c'est d'implémenter complètement le protocole SNMP v1 en LUA. J'ai bien fait les choses, puisque c'est une librairie (fichier, ou plutôt une table au sens LUA du terme) complètement indépendante, qu'on peut réutiliser dans n'importe quel QuickApp (ou même en dehors de la HC3, c'est du LUA standard après-tout). J'ai eu le nez creux lorsque je l'ai développé pour HC2, puisque le portage sur HC3 était quasiment instantané. Je l'ai utilisé pour d'autres VD et QA jamais partagés : mon routeur Ubiquiti par exemple (voilà de quoi faire criser @mprinfo qui s'acharne à le faire en passant par l'API. Testé rapidement aussi sur les switchs Cisco, c'est fonctionnel. Ce qu'il faudrait que je te fasse, c'est une doc pour utiliser ma librairie... fraichement c'est super facile.

Une discussion a démarré sur le forum officiel concernant les problématiques de balance entre la production et la consommation, je vous invite à aller appuyer votre demande : https://forum.fibaro.com/topic/58682-energy-panel-effective-energy-producedconsumed/

Inutile de créer des modules enfants dédiés pour la consommation. Tu peux ajouter l'interface "power" sur les modules enfants existants, et mettre à jour la propriété power avec la consommation actuelle.