Lazer

@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

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