Lazer

Pour cette raison, j'ai mis mon HC3 sur rallonge électrique + câble réseau long. Ainsi je l'ai déplacé pour m'approcher suffisamment du module pour pouvoir l'inclure. Mon HC3 a même fini dans le jardin à un moment Mais ça n'est pas non plus une solution idéale, car le déplacement de la box va casser les routes existantes. Et certains modules qui étaient en communication directe se retrouvent à devoir calculer un nouveau chemin par un routeur intermédiaire. Du coup au final quand j'ai repositionné la box à son emplacement définitif, j'ai affiché la cartographie de mon réseau (la page PHP partagée sur le forum, mais tu peux aussi utiliser l'outil de @jjacques68) pour détecter les modules pour lesquels il me semblait anormal d'avoir un saut intermédiaire, et forcer une reconstruction de la route. Je préfère avoir des routes directes dans la mesure du possible.

C'est étrange Peut être un bug du dernier firmware de la HC3 alors ? Il faudrait poser la question à Fibaro sur le forum officiel. Autre chose, tu as bien vérifié que les capteurs de températures n'étaient pas cachés ? Sur l'un de mes FGBS, je constate qu'il y a plein d'enfants, dont des capteurs à plusieurs niveaux que j'ai caché, et les vrais sondes de températures sont tout en bas de la liste des enfants :

Oui il faut la brancher avant l'inclusion. Ta sonde est peut être HS, tu en as une autre pour tester ?

Il faut exclure et inclure le module, la détection des sondes de températures externes se fait à ce moment là.

Oui pareil, j'ai vu ce n'est plus possible... J'ai ouvert un sujet sur le forum officiel, mais la réponse apportée pour l'instant ne laisse que peu d'espoir.... Va encore falloir modifier le code du QA... J'espère que tu n'es pas pressé...

Oui tout à fait, la charge des batteries NiMh c'est hyper simple, d'où l'intérêt de bien choisir son chargeur. Les Lacrosse sont super pour ça, quand tu branches, il commence immédiatement une charge lente, avec détection de fin de charge, c'est parfait pour les accus. Il n'y a rien à faire. Après en 2 ou 3 clicks, tu accèdes aux modes intéressant, comme le changement de cycle (décharge puis charge, refresh, etc), ou un courant de charge plus important. Tu peux avoir un courant important, mais ça fait chauffer les accus, donc ça les use plus vite. Exactement comme pour les batteries Li-ion, la charge rapide est une ânerie inventée par les services marketing des fabricants de smartphones pour compenser l'absence de progrès technologique sur les batteries elles-mêmes. Déjà que le Li-ion vieillit relativement mal (comparé au Ni-Mh), mais si en plus tu le charges en rapide, la durée de vie est encore raccourcie. Et après on nous parle d'écologie et de développement durable... bref En tout cas tu pourras nous faire un retour d'expérience pour ces "piles" Li-ion rechargeable au format AA, car ça fait pas mal de temps que j'en vois, mais aucun retour d'expérience sur la durée. Évidemment que ça fonctionne bien quand c'est neuf, je m'interroge surtout sur l'utilisation réelle.

Mais justement @jjacques68 j'avais longuement détaillé mes expériences sur l'autre sujet. Aucun souci de performance. Pour l'instant j'ai 3 QA (GEA, Velux, Porte garage) sur ma box de production qui exploitent cette API, et ça tourne nickel depuis 2 mois. Je pense même en ajouter un 4ème prochainement, quand j'aurai le temps de m'y mettre (réécrire le QA Evénements pour utiliser /refreshStates à la place de /events/history)

@Massalia@jjacques68 merci en effet j'avais oublié cet outil

C'est quoi HC3 download ? Il te dit que tu as 2 modules injoignables, c'est ça ? Ils sont surement trop loin... après, à regarder la liste des tes modules, je ne suis guère surpris, je ne vois quasiment que des modules sur piles. Tu aurais dû commencer par inclure les modules sur secteur, afin de créer un bon maillage, avant d'ajouter les modules sur batterie. Bon c'est pas trop tard, tu peux ajouter des modules sur secteur, ça va créer le maillage, auquel pourront se raccrocher les modules éloignés qui n'ont pas de communication directe avec la HC3.

Tiens merci, Varta Industrial je n'ai jamais testé, je garde en tête. Intéressant tes durées avec les accus rechargeables sur les FGMS et ST814, donc à priori tu as des durées de vie environ 2 fois plus courtes qu'avec des piles (je tiens largement 3 ans, voire plus, avec les FGMS, et plus de 2 an avec ST814) Après les accus NiMh, même après 5 ans, ça tiens encore, c'est normal, c'est une techno qui vieilli mieux que le Li-ion, j'ai constaté ça même avec mes très vieux accus, s'ils sont correctement entretenus (= pas laissés complètement déchargés... je me suis fait avoir pour 2 jeux que j'ai oublié, ils sont morts) Le Li-ion a ceci de pénible, qu'on l'utilise ou non, il vieilli tout seul.

En LR6, donc taille standard, je te recommande à 100% Eneloop, elles sont à milles lieux de toutes les autres marques. C'est THE référence en accus rechargeables. Les anciennes étaient déjà pas mal, avec un faible taux d'autocharge. Les derniers modèles ont carrément un taux ultra faible... ce qui les rend exploitables dans les appareils à très faible consommation d'énergie comme nos modules domotiques. Ils annoncent 70% de charge restante au bout de 10 ans. Même une Alcaline ne fait pas ça. Reste les autres problèmes évoqués : tension 1.2V et courbe de décharge non linéaire. Comme je disais, les accus rechargeables c'est toujours une histoire de compromis, aucun modèle n'est parfait. Autre chose, au moins aussi important que le choix de l'accu, c'est le choix du chargeur. Les chargeurs basiques tuent les accus, donc c'est pas la peine. Dans le domaine, les chargeurs Lacrosse font figure de référence, même s'il existe d'autres bons modèles, de marques plus ou moins connus. Ce qui est important, c'est la détection de fin de charge, et le choix du courant de charge. Comme pour toutes les batteries du monde (téléphone, voiture, etc), plus on charge lentement, mieux c'est. La charge rapide est à bannir et à réserver aux situation d'urgence. Certains chargeurs ont un contrôle de température intégré, ainsi qu'une ventilation forcée, c'est encore mieux. Option sympa aussi, c'est la programmation du cycle complet de décharge avant la recharge, pour luter conter l'effet mémoire pour lequel les accus NiMh sont encore partiellement soumis, contrairement aux Li-Ion. Et le cycle de refresh (charge/décharge plusieurs fois de suite) pour régénérer un accu qui a dormi un peu trop longtemps dans un tiroir. Je n'ai jamais essayé les accus Li-Ion comme ceux de ton exemple. Le Li-Ion est une techno bien plus complexe, qui explose, les amateurs de modélisme le savent bien. Là je vois sur tes modèles que le chargeur est intégré dans l'accu, il suffit de brancher le cordon USB pour l'alimentation. Sans expérience, je ne sais pas comment ils vieillissent.... j'imagine que comme la plupart des batteries Li-Ion grand public, au bout de 3 ans il te reste 50% de la capacité... pas top.

Vieux sujet oui... C'est toujours les mêmes problèmes avec les batteries (accus) rechargeables : - la tension nominale est souvent de 1.2V et non 1.5V, donc même chargé à bloc, le module va croire que la pile est déjà partiellement déchargée - la courbe de tension ne décroit pas linéairement dans le temps, mais elle reste relativement stable, puis s'effondre d'un coup. Si bien que le module n'étant pas calibré pour ça, ne va pas voir venir la chute de tension, n'aura pas le temps de prévenir que la batterie est faible, et va cesser de communiquer - la plupart des batteries ont un taux d'auto-décharge plus élevé que les piles alcalines, donc sur un appareil pour lequel la durée de vie de la pile est longue (1 an ou plus), alors la batterie se videra plus vite toute seule que par le consommation du module lui-même.... pas très optimal tout ça. La technologie de batterie parfaite n'existe pas. Les fabricants arrivent à répondre à l'un des points évoqués ci-dessus, ou l'autre, mais jamais tous en même temps. Perso je conserve des piles dans mes modules domotique (et alarme, encore plus critique). En les achetant par lots (sur Amazon), ça coute 10x moins cher qu'au supermarché. En prenant des piles de qualité (en Alcaline j'aime bien les Duracell Ultrapower), ça dure assez longtemps. Ce dont je suis certain, c'est que les piles les moins couteuses reviennent le plus cher. Comme souvent, "le pas cher coute cher". Sans même compter le désagrément du remplacement des piles sans arrêt... Et les FGK, de 1ère génération, il faut s'en débarrasser. Le FGDW est juste magique en comparaison. Tous les autres modules Fibaro tiennent très bien, y compris les FGMS (série 300 et 500 inclus), facilement 3 ans avec la bonne config. Tu dois avoir un souci de config. Les Aeotec sont bien aussi. Si tu as des problèmes, il faut te débarrasser des vieux modules, typiquement les Z-Wave chipset v300, qui n'étaient pas optimisés du tout... technologie d'il y a 10 ans quand même.

Et pourquoi ne pas regarder les capteurs "à basculement mécanique" (désolé je ne connais pas le terme). J'ai ça sur ma pompe immergée de puits. Quand le niveau baisse, le capteur (qui est 100% étanche et flotte) descend, ça active un contact mécanique, qui coupe le circuit. Bête et méchant, mais efficace.

De mon coté je n'ai jamais eu de déclenchement. Et tant mieux Tu n'aurais pas des problèmes de plomberie ? Mais là tu compares des choses qui n'ont rien à voir, une utilisation au sol, c'est le cas normal prévu par le fabricant, le module a été conçu en ce sens. Une utilisation en extérieur, dans un skimmer, ça n'a rien à voir, je veux bien croire que ça ne donne pas du tout satisfaction.

Peut être le nouveau Sensative Strips Drip 700 https://www.domotique-store.fr/domotique/usages/domotique-alarme-securite/inondation-fuite-eau-coupure-automatique/1538-sensative-strips-drip-700-detecteur-d-inondation-extra-plat-z-wave-compatible-exterieur-avec-puce-z-wave-v2-serie-700.html Il est indiqué compatible extérieur et certifié IP 44 Mais ça reste de la domotique, donc probablement pas plus fiable que le Fibaro Flood Sensor, attention si tu veux faire un scénario de pilotage automatique du remplissage. Mais pour une notification et un contrôle manuel, ça doit faire le job.

Oui je suis d'accord, si j'ai bien compris ta question, alors il faut utiliser "Or" pour mettre plusieurs profils en conditions.

Mais justement, tu n'as pas saisis l'intérêt du QuickApp Évidemment que je n'utilise pas non plus un Roller Shutter pour piloter ma porte de garage, puisqu'aucune porte de garage ne peut être pilotée avec un FGR. C'est toujours du contact sec. J'utilise un contact d'un IPX800 en série avec un FGS (double sécurité, je ne veux pas que la porte s'ouvre toute seule... bon malgré tout ce n'est toujours pas câblé comme dis précédemment). Mais avec un FGS-224 comme le tient ça serait pareil. C'est le QA qui est de type Roller Shutter, pour apparaitre proprement dans l'interface Fibaro (web et mobile). Et laisser la box gérer les icônes toutes seules, selon son pourcentage d'ouverture. Dans la pratique, comme j'ai 2 capteurs (bas et haut), je peux déterminer 3 positions (complètement fermé, complètement ouvert, et intermédiaire). Comme toi. Donc dans la propriété value du QA RollerShutter, ça se traduit par 0, 50 et 99, comme tu peux le voir dans le code LUA. Bref, vu le code ci-dessus, ça permet de remonter l'état de la porte de garage dans la box. Et il reste à écrire les lignes dans la fonction QuickApp:setValue(value) pour agir sur la porte. EDIT:

Dans l'immédiat, tu peux déjà faire le minimum syndical, c'est à dire un pilotage en tout ou rien, ON/OFF, avec un module relai type FGS-214 Après, je pense qu'il n'est pas très recommandé de couper sa ventilation, et d'ailleurs ce n'est pas la température qu'il faut surveiller, mais d'autres paramètres : l'humidité principalement, et éventuellement d'autres tels que le CO2 ou les COV.... mais ces capteurs sont plus rares, et chers. On en trouve chez MCO Home par exemple, avec écran à fixer au mur.

oui mais le clearTimeout() c'est pour interrompre un timeout en attente dans un process (instance) de scène/QA en cours d'exécution. Si le process/instance est tué parce que la scène/QA a été redémarré, alors peu importe le cleartimeout, puisque de toute façon le process précédent n'existe plus, et avec lui le timeout en attente.

Qu'est-ce que tu veux faire avec un transfo 12-24V ? C'est un moteur 230V, si tu l'alimentes en 12V ou 24V, il ne se passera rien du tout, le moteur ne bougera pas du tout. Pour la sonde de température, il y a le nouveau minuscule module Aeotec Aërq sur batterie qui est pas mal du tout, il y a un topic dédié à son sujet sur le forum

Oui centraliser les ID des modules quelques part est une bonne approche. Perso c'est un peu différent, car 99% de mes scénarios sont ensemble : dans GEA. Du coup c'est une simple table LUA au début du script qu'il me suffit de maintenir à jour, juste avant le long listing des différentes règles. Les rares exceptions en fin de compte, c'est une scène Alarme, qui est autonome, et fait clignoter les éclairages et envoie des snapshots des caméras. Là les ID sont aussi codée en dur dans une tableau LUA au début de la scène. Ainsi elle reste le plus légère possible et fonctionne en toute circonstance sans dépendre d'une variable globale externe. Et puis de toute façon, les ID de mes éclairages ne changent jamais. Comme tu dis, le jour où on passe sur le moteur Z-Wave v3 et que les ID changent, je n'aurai que 2 endroits à modifier, très simple. Exactement ccomme ce qui s'est passé quand j'ai basculé de HC2 à HC3, la bascule a été très simple (c'était la réécriture préalable des QA qui a été longue)

Le vendeur est... un vendeur justement ! On ne lui demande pas de connaitre le fonctionnement de son produit, juste d'en vendre. Ce qu'il a réussi visiblement, donc il est bon. Bon dans son métier de vendeur. Dans mon métier (technique) je travaille avec des commerciaux tous les jours, chacun son rôle, et ça fonctionne bien. Et non, rien à voir avec l'électricité ou la domotique. Si tu viens sur un forum, c'est pour avoir des avis techniques éclairés que ton vendeur n'est pas capable de t'apporter. Certes sur les forums, les gens peuvent aussi se tromper, on est là pour discuter, échanger des avis, expérimenter, et apporter des retours d'expérience. Bon là il n'y a aucun doute, la variation de fréquence ce n'est pas possible. Là ton expérience va consister à tester avec un dimmer, normalement prévu pour un éclairage, et de regarder comment se comporte le moteur. Comme je te l'ai indiqué, ça devrait fonctionner, mais pas sûr à 100%. Normalement, le moteur ne démarrera pas en dessous d'une certaine tension moyenne (correspondant à un certain pourcentage de variation du dimmer) Il risque aussi de grésiller, ce qui va l'user prématurément. Là où tu vas avoir un souci, c'est si tu utilises le FGD-212, car il force une calibration au démarrage pour détecter le type d'éclairage, et adapter en conséquence (leading ou trailling edge, 2 façons de hacher la sinusoïde, je te laisse chercher sur Google si tu veux approfondir). Mais il risque de ne pas aimer quand il va "voir" le moteur, ou plutôt ne pas comprendre à quel type de charge il a affaire. Donc il faudra que tu modifies le paramètres qui va bien (regarde le numéro dans la doc) pour désactiver la calibration automatique. Ou alors utiliser le dimmer v1, le FGD-211, si tu arrives encore à en trouver d'occasion, qui sera surement plus adapté : pas de calibration automatique, et supporte une plus grande puissance (500W versus 250W pour le FGD-212)

tu as vu ça où ? Relis bien ce que j'ai écris au dessus. Si ce n'est pas clair, le web regorge d'informations, avec des schémas qui seront plus parlants. De plus, dans la doc de ton moteur, c'est quand même clairement indiqué : moteur monophasé 50 Hz, vitesse variable par dévoltage (NDLR : ouh là là, quel vilain anglisme) Je ne sais pas pourquoi tu t'obstines à vouloir faire varier la fréquence....

Précision : le setTimeout ne fonctionne pas dans un Thread autonome, car tous les QA et Scènes sont mono-threadés sur la HC3 (comme sur la HC2) Le setTimeout fait donc partie du process de la scène en cours d'exécution. Quand une nouvelle instance de scéne démarre, c'est à dire un nouveau processus (au sens Linux) est démarré, donc le précédent est tué, afin de ne pas laisser plusieurs instances (= processus) de scènes s'exécuter en parallèle. Et ça c'est une différence fondamentale avec la HC2, sur laquelle on pouvait avoir jusqu'à 10 instances (processus) de scènes s'exécuter en parallèle.

Euh.... il sort d'où ton extracteur d'air monophasé ? C'est une technologie extra-terrestre ? Un moteur électrique dont on fait varier la fréquence, perso, je ne connais pas... même pas certain que ça existe. Peut être à la NASA ? Bref, ton moteur il fonctionne en 50 Hz, soit la fréquence du réseau électrique en Europe, point final. Je pense que tu confonds la fréquence électrique et la vitesse de rotation, car c'est bien cette vitesse de rotation que tu veux faire varier pour ton application Pour faire varier la vitesse de rotation d'un moteur, on utilise généralement un hacheur. Un hacheur de la sinusoïde électrique, qui reste toujours à la fréquence de 50 Hz. Et autre confusion de ta part, les variateurs Z-Wave ne sont ni des variateurs d'intensité, ni de tension. Ce sont justement des hacheurs. Même si au final, puisque la sinusoïde est tronquée, alors la tension moyenne est réduite, d'où l'impression d'une variation de tension. Et puisque la résistance de la charge est constante (dans le cas d'une ampoule lumineuse), alors le courant aussi varie à la baisse, puisque U=RI. Pour un moteur, c'est à peu près pareil, plusieurs utilisateurs ont rapporté qu'ils avaient réussi à faire varier la vitesse de leur moteur de VMC avec un simple gradateur (=dimmer en anglais) Z-Wave. Donc tu peux tester un FGD. Cela dit, je n'ai jamais testé personnellement (je n'ai pas de VMC), mais j'imagine que ça ne va pas forcément bien fonctionner avec tous les moteurs. Certains n'aiment pas trop, cela peut les faire grésiller par exemple. A tester donc.