Lazer

Oui, tu peux utiliser /api/events, que tu pourras même requêter directement depuis ton NAS si tu souhaites utiliser un autre langage que LUA embarqué dans la HC3. Regarder le Swagger disponible sur la HC3 pour avoir la syntaxe complète. Cette API donne exactement le contenu du panneau d’événements que tu regardes. Pour ta mise à jour, regarde le topic officiel (il faut surement que tu réveilles ton module, et/ou que tu l'approches de ta box) :

En fait, les détecteurs sont bien autonomes. C'est même indiqué dans leur nom, comme imposé par la norme : DAAF = Détecteur et avertisseur autonome de fumée Ce que tu voudrais, ce sont des détecteurs interconnectés. Comme je t'ai dit, ça n'existe pas (à ma connaissance) en Z-Wave. Le Nest Protect le permet peut-être, à vérifier. Mais en fait, ce que tu veux, c'est une installation professionnelle comme on en trouve dans les entreprises : un réseau filaire de capteurs, interconnectés par un câbles spécifique (résistant (retardant) au feu, de couleur orange), qui pilote des sirènes dédiées via une centrale spécifique, le tout protégé par une alimentation secourue (le même type d'alimentation que pour les alarmes) Franchement, exagéré pour une installation à domicile... Et là, tu vas me dire que si la centrale flambe, ben y'a plus d'avertissement... et hop, retour à la case départ, c'est le même scénario que la box domotique. Donc si tu pense que le feu peut partir de ton cellier, car il y a un risque (chaudière, ou que sais-je), alors ce n'est pas l'endroit où il faut y installer ta box domotique.

Faudrait regarder le code, pas eu le temps encore, c'est vrai que c'est particulièrement agaçant.

Je ne suis pas certain, mais il me semble que les NEST savent se faire sonner entre eux. En tout cas à ma connaissance, ça n'existe pas en Z-Wave, les détecteurs de fumée, pour être à la norme NF machin-truc, sont obligatoirement sur piles. Et en Z-Wave, un module sur pile est endormi par définition. Donc impossible de le piloter à distance. Il faudrait un détecteur de fumée qui exploite FLIRS, donc réveil fréquent pour intercepter la consigne de sonner, mais bonjour la durée de vie des piles.... s'il faut les changer tous les 6 mois, ça n'a aucun intérêt (le détecteur finira débranché) Après, ton raisonnement concernant le cellier est inexact. Le détecteur sonnera dès que la fumée apparait, donc la box n'a pas encore eu le temps de bruler (sauf si c'est elle qui prend feu ) Du coup, la box a le temps d'envoyer les notifications, d'allumer les lumières pour réveiller les gens endormis, ouvrir les volets pour sortir, voire faire sonner une (vraie) sirène, etc. N'oublions jamais qu'un détecteur de fumée, quel qu’il soit, n'est pas là pour empêcher un incendie. C'est déjà trop tard. Il est là pour sauver des vies, en réveillant les habitants avant qu'il ne soit trop tard, afin qu'ils ne se fassent par intoxiquer, asphyxier, voire carboniser dans les cas extrêmes (ou être contraint de sauter dans le vide par la fenêtre... je sais pas lequel est pire) C'est pour cette raison, que le norme dit que les détecteurs doivent être installés dans les lieux de passages (hall, couloir, etc), là où ils ont le plus de chance d'être entendus. Un détecteur de fumée dans un cellier est totalement inutile vis à vis de la protection des personnes, personne ne l'entendra. Cela dit, j'ai moi aussi posé des détecteurs dans des endroits improbable, mais c'est justement pour détecter le feu le plus tôt possible, et parce que je sais que grâce à la domotique, je peux faire remonter l'information jusqu'aux personnes à l'autre bout de la maison, laissant le temps de sortir tranquillement. Voire, qui sait, me laisser le temps d'attraper l'extincteur, et de tenter d'éteindre le départ de jeu (j'ai placé un détecteur au dessus de la cheminée, et un autre entre la plaque de cuisson et le four). Rever de la médaille, ils ont tendance à se déclencher trop facilement (genre cheminée qui refoule)... c'est pas agréable du tout pour les oreilles.

Bienvenue sur le forum

Non, puisque le module envoie son état en cas d'action sur ses boutons. C'est ce qu'on appelle le retour d'état. C'est plutôt pour les cas rares et exceptionnels. J'ai donné un exemple : après une coupure de courant. Mais également, si par exemple le réseau Z-Wave est mal maillé ou bien trop encombré, dans ce cas il se peut que le retour d'état soit perdu... donc un polling quelques minutes plus tard ne fait pas de mal. Après tu peux très bien n'activer le polling que sur les modules "à problème". Sur mon installation, je pourrais citer 2 modules qui sont installés autour de mon portail et de la sonnette, qui sont loin de la maison, et une fois sur 2 il y a un écran qui vient s’intercaler (le portail ouvert justement... qui est métallique) Il y a plusieurs filtres en haut de la page des événements, mais je pense qu'ils seront perdus à chaque rechargement de la page. En fait au tout début j'utilisais cette pages, quand j'avais 10 modules..... il y a 7 ans. Maintenant, je ne l'utilise plus. Là tout de suite, j'ai 75 modules (et je n'ai pas encore fini de tout migré), et c'est déjà quasi inexploitable, ça défile non stop. Donc il faut savoir exactement quoi chercher, et utiliser les filtres.

Euh ben non désolé, je n'en sais rien du tout. Cherche "forum français grafana" sur Google tu seras fixé.

Tiens regarde là : https://www.materielelectrique.com/alimentation-ports-modules-blanc-p-217243.html Pour annuler les frais de port, il faut un minimum de commande. Et il y a un programme de parrainage aussi, ainsi qu'un système de point, donc si tu fais pas mal de travaux et des commandes régulières, ce sont les moins cher que j'ai trouvé. Et très sérieux, quand ils n'ont pas en stock, ils approvisionnent en 1 semaine max.

Il faut désactiver l'interrogation régulière de ce module : Il y a 2 écoles, mais perso je préfère laisser cette option (d'ailleurs je l'active, car ce n'est pas le cas par défaut), ça permet de détecter les nœuds morts, mais aussi de relire l'état des modules, par exemple après une coupure de courant.

Bienvenue sur le forum

Lors de mes migrations de modules, certains étaient encastrés et trop loin pour joindre la HC3, donc les opérations d'exclusion/inclusion échouaient. Plutôt que de les sortir, j'ai trouvé plus rapide de mettre la HC3 sur une rallonge électrique, avec un long câble réseau, et je l'ai baladé pour l'approcher des modules, éviter les murs gênants, etc. Elle a même fini dans le jardin (vite vite avant l'orage) Mais attention, ce n'est pas forcément une méthode optimale, car cela a tendance à casser les routes des autres modules déjà inclus et qui communiquaient en direct avec la box, et qui se retrouvent à devoir chercher une autre route, potentiellement en rajoutant un saut intermédiaire. Même quand la box retrouve son emplacement initial, ce saut est conservé, donc le réseau est moins optimal.... du coup faut se taper des reconstructions de routes manuellement.

En effet, je viens de retrouver ma première commande, c'était également il y a 7 ans. J'en ai ajouté d'autres par la suite, maintenant j'en ai 4 en tout. Tous payés entre 22 et 23€, sur une boutique on ne peut plus sérieuse (materielelectrique) où je suis certain de ne pas me faire refiler de la contrefaçon.... apparemment assez courant avec Legrand dès qu'on sort du circuit de distribution officiel. @jjacques68 je ne sais pas où tu as trouvé à 25, mais ça ne semble pas le meilleur prix.

OK merci, donc reconfiguration douce ou débranchement/rebranchement doit avoir plus ou moins le même effet alors. Bon à savoir.

Bon, je viens de réessayer, après avoir débranché et rebranché le module, et ça fonctionne maintenant (il est sur alimentation USB) Surement un bug du firmware du module, suite à son inclusion. Mon problème n'était pas lié à l'affichage du paramètre dans l'interface de la HC3, car dans le log, on voyait clairement qu'il ne prenait pas en compte la nouvelle valeur et restait bloqué à sa valeur par défaut 178 : [TRACE] [ZWAVE]: ID 248: Set parameter 27, value = 54 [TRACE] [ZWAVE]: ID 248: Received parameter 27 report, value = 178 D'ailleurs ce retour se faisait instantanément. Donc après redémarrage du module, maintenant c'est OK : [01.06.2021] [10:33:12] [TRACE] [ZWAVE]: ID 248: Set parameter 27, value = 54 [01.06.2021] [10:33:21] [TRACE] [ZWAVE]: ID 248: Received parameter 27 report, value = 54 Et là je constate comme toi un délai de l'ordre de 10 secondes pour la prise en compte du nouveau paramètre (après quoi l'interface Web demande le rafraichissement de la page) Testé à l'instant, la PAC reçoit bien les consignes Merci

Ah ouais, nickel ça alors

Comme un chargeur normal quoi Je n'ai pas mesuré la consommation en veille, mais elle est obligatoirement présente. La norme impose moins de 0.5W je crois. J'ai ma station Netatmo est est alimentée par ce module Legrand depuis des années.

Oui j'en ai plusieurs, rien à signaler, ça fonctionne bien, c'est propre. ça chauffe un peu (donc ça consomme un peu), mais pas outre mesure je trouve. Après c'est du Legrand, je ne suis pas inquiet, je suppose qu'il y a suffisamment de protection pour que le module tombe en panne sans provoquer un incendie.

J'ai exclu mon module et j'en ai profité pour passer le firmware en version 1.01. Pas de changement visible pour l'instant, si ce n'est l'apparition du paramètre 64 permettant de passer en degrés Fahrenheit, inutile donc, mais comme il est documenté dans l'Engineering sheet, je ne comprenais pas pourquoi mon module le refusait avant cela. C'est donc le firmware 1.01 qui ajoute cette option. On verra à l'usage si le comportement des relevés de batterie s'est stabilisé. EDIT : ce qui est surprenant, c'est que sur la HC3 la version remontée est la 1.1 :

@ericl78 tu n'a pas eu de souci pour modifier le paramètre 27 permettant de choisir le code IR préenregistré ? J'essaye désespérément de le modifier, et il reste toujours à la valeur 189. Je n'ai pas de souci avec les autres paramètres, que je peux modifier puis remettre à leur valeur par défaut. Je suis toujours en version du firmware 1.4.

Bienvenue sur le forum

Les QuickApps, ça s'intègre nativement dans l'interface de la HC3, comme un module Z-Wave, grâce au type que l'on choisi lors de sa création, ce qui est déjà un progrès immense par rapport aux VD. Et tout le code s'exécute dans un seul process, permettant l'utilisation de fonctions, de variables, etc, ce qui était là aussi impossible pour les VD avec leurs boutons et Main Loop isolés les uns des autres. Il y en a déjà pas mal de disponibles sur le forum dans la rubrique idoine. Sinon pour leur écriture, voici la doc officielle : https://manuals.fibaro.com/home-center-3-quick-apps/ Pas la plus didactique qui soit, mais elle a le mérite d'exister, c'est déjà un progrès chez Fibaro. Et sinon le sujet qu'il faut impérativement lire pour devenir un Maître Jedi du QuickApp, c'est sur le forum officiel, particulièrement les messages décrivant leur anatomie : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/

Ouais optimiste J'ai eu mon HC3 Il y a 1 an ! Bon faut dire qu'entre temps j'ai réécris tous les QuickApps les plus complexes, donc j'ai attendu que tout soit prêt pour effectuer ma migration Z-Wave. Et depuis 3 jours, on a enfin coupé le chauffage (printemps 2021 à mettre dans les anales), je ne me serais pas lancer dans une telle migration sachant que la domotique gère tout le chauffage.

Oui c'est mieux, cela va créer un bon maillage sur lequel vont s'appuyer les modules sur batterie. Et il faut aussi commencer par les modules les plus proches de la box, qui vont communiquer avec en direct, sans saut. Idéalement même, il faut inclure les modules à coté de la box, et ensuite aller les installer à leur emplacement définitif. Sauf que ce n'est pas pas toujours possible, donc les modules qui sont encastrées, tu les inclues là où ils sont installé, et tu laisses bien la case "L’appareil est situé loin de la Home Center" cochée :

ah bien Du boulot en perspective alors !

Oui mais ça se sont les enfants. Il faut que tu regardes le nombre de modules Z-Wave, dans l'onglet Réseau Z-Wave :