Lazer

Punaise, c'est beau, on dirait du Lifedomus Tu es doué @Domodial

Pas vraiment de raison particulière, mais vu que je ne suis pas l'auteur original (je ne suis qu'un imposteur ) et qu'il y a déjà une page "officielle" sur le Market Fibaro, je n'ai pas créé de topic ici. Cela dit, ça pourrait être pas mal pour en discuter.... mais comme il y a déjà un topic qui en parle, je n'ai pas créé de nouveau : Et il y a même une page Github, ça devrait te plaire https://github.com/gsmart-pl/Netatmo-QA-FIBARO-HC3 Car c'est la plateforme qu'on a utilisé pour se synchroniser.

Ouais ça va être trop gros et disgracieux. Si tu as bricoleur, tu peux aussi faire un bras de déport avec un profilé alu (ou même en bois), et ensuite venir fixer une petite rotule sur bras en question.

Voilà, sans support Perso j'ai utilisé un petit support de caméra Foscam trouvé sur Amazon, mais l'article a été retiré du catalogue. En tout cas il n'a pas bougé depuis des années. Sinon Netatmo vend un support officiel, fort cher pour ce que c'est. Le filetage est du 1/4 pouce standard utilisé en photo depuis toujours, donc n'importe quel support fera l'affaire, on retrouve maintenant ce standard dans tous les appareils, y compris certains outils de bricolage (genre niveau laser, etc).

La rapidité, je te l'ai déjà dit, c'est plusieurs minutes. Par expérience, je dirais entre 3... et environ 15 minutes ! En effet, en pratique tu dois additionner plusieurs délais : - le temps que le godet se remplisse, bascule, ce qui permet au module de compter (je crois que le mini est 0.2mm de pluie, donc déjà en dessous il ne verra jamais la pluie) - le temps que le module envoie l'info à la station de base - le temps que la station envoie l'info au cloud (toutes les 10 minutes, non configurable) - le temps que la box domotique aille chercher (par polling) l'info sur le cloud Netatmo. Dans le QuickApp sur HC3, j'ai optimisé ce temps. A chaque interrogation, il regarder le timstamp du dernier remonté d'info par la station, puis fait un setTimeout du prochain relevé à 10 minutes + 10 secondes. Ainsi, en théorie la HC3 ne devrait jamais avoir plus de 10s de retard par rapport à la dernière info connue du cloud. C'est mieux que sur HC2 pour lequel le plugin faisait ce qu'il voulait (et surtout planter....) Pour le positionnement, regarde sur le forum, il y a 2 ou 3 exemples. Par exemple chez moi : Ou celui-ci dont je terrai le nom :

ça c'est typique d'un algorithme de régulation mal réglé. C'est quoi dans les têtes, du PID ? On peut agir sur les coefficients ? Perso j'ai un seul thermostat programmable, c'est le SRT-321 que j'utilise sur un radiateur électrique (mais il est aussi utilisable pour une chaudière). Et ils ont laissé l'accès à un paramètre permettant d'agir sur la régulation PID, en fait c'est un facteur jouant sur l'inertie du chauffage. Pour un radiateur électrique de type radiant, faible inertie, je l'ai dont réglé au minimum, et il régule super bien, il tape juste à tous les coups, au pire il dépasse de 0.2°C, c'est même pas sensible. Mais je ne connais pas les possibilités de paramétrage des têtes thermostatiques.

On dit pas merci ça nous coute cher Mon colis vient d'être préparé ce soir à 23:08 Ils sont forts...

Ben je suis d'accord, mais ils ne sont pas d'accords avec eux-même SetVR05=0 (met le volet 1 de la seconde extension à 0 %) => là OK SetVR02=12&SetVR05=60 (met le volet 4 de la troisième extension à 12 % et le volet 1 de cette même extension à 60%) => là ils ont fumé

Je parlais du module additionnel bien sûr, ce n'était pas clair ? Je pensais que tu l'avais et que tu l'utilisais. Mais bon du coup c'est une demi bonne nouvelle, car je vais pouvoir reporter la gestion des volets à plus tard.... ça ira plus vite Ce n'est pas la valeur qui me pose problème, c'est surtout l'index des volets (chaque extension peu piloter 4 VR). Je pense qu'il y a des erreurs dans la doc, en tout cas ce n'est pas clair. Mais ce n'est pas grave, on laisse tomber pour le moment, il faudra tester quand quelqu'un aura cette fameuse extension.

Oui c'est un détecteur. C'est binaire. Tandis qu'un pluviomètre est un compteur de quantité. Bon en région parisienne, peu de chance d'avoir de la pluie pure, donc de ce coté là on est tranquille Finalement c'est plus compliqué pour les apprentis domoticiens de la Creuse @Emmanuel2017 il faut que tu regardes le Wiki ou la doc de syntaxe (un fichier texte) de Pepite, c'est un peu plus clair pour débuter. Il faut commencer par des scénarios super simples (1 condition, 1 action), puis après tu améliores.

Ben quand tu fais en 1 seule ligne ce qu'il te faudrait 10 lignes en LUA normal, le choix est vite fait. Et je te parle même pas du mode bloc, qui est limité aux scénarios les plus simples.

Ah ben je sais pas, ça fait 3 ans qu'il est sur l'établi en attente d'être installé... et c'est pas cet hiver que je vais monter sur le toit En effet les commentaires font peur, ça ne doit pas être une technologie super fiable Après quand tu as les 2, c'est à dire le capteur et le pluviomètre, tu maximises les chances de détecter la pluie.... suffit de faire un "OR" dans GEA. Mais ça ne sera probablement jamais parfait s'il faut fermer les fenêtre à temps à 100% de réussite :/

@MAM78 je suis toujours en train de préparer le QuickApp pour l'IPX800 v4 (et en même temps l'EDRT2). Je sais que tu as le module Volet Roulants, est-ce que tu en as d'autres ? J'aurais besoin que tu fasses quelques tests via l'API. Déjà pour obtenir les infos (afin de confirme ce que je pense)... si tu pouvais avoir au moins un volet ouvert et un autre fermée, voire en position intermédiaire, ça me permettrait de voir à quoi ressemblent les valeurs (je suppose de 0 à 100) : /api/xdevices.json?key=apikey&Get=VR Mais là où je suis dans le flou, c'est pour piloter les volets : /api/xdevices.json?key=apikey&SetVR05=0 /api/xdevices.json?key=apikey&SetVR05=60 Je n'arrive pas à comprendre la doc sur la numérotation des volets lors d'un Set. Si tu pouvais m'éclairer. Merci

C'est un peu le but oui c'est un contact sec hein, c'est juste un capteur, pas un module domotique à part entière. Il n'est pas capable de communiquer.

Ah ben moi je fais ça sous GEA, ce scénario est un grand classique, il y a même plusieurs exemples dans les showrooms GEA

dans la gouttière, qui ça, moi ? L'intérêt de ce capteur est justement de détecter la pluie le plus rapidement possible, contrairement au pluviomètre qui compte... et ne rapport l'information qu'une fois qu'il a plus suffisamment, donc quelques minutes plus tard... additionnées au retard de remonté d'information via le cloud de Netatmo, donc 10 minutes. Le pluviomètre c'est bien pour gérer l'arrosage, mais pas pour alerter de fermer les fenêtre ou rentrer le linge.

En fait je pense que le stop apparait parce que tu es probablement en mode debug = true, sinon il ne devrait pas apparaitre. Pour le Wiki, oui je pense que je finirai par m'y coller. Mais @pepite m'avait dit qu'il était motivé.... il est en mode fantôme en ce moment. Pourtant il a du temps libre le temps la nuit... très tôt le matin

OK donc tu t'es heurtée à l'API de la HC3 qui a changé par rapport à la HC2. Les modules de type binaire (actionneur comme capteur) prennent value = true | false maintenant Et c'est très bien ainsi, c'était une aberration les valeurs 0 et 1 sur la HC2. Donc pour te répondre, les "0" et "1" ne peuvent pas fonctionner, puisqu'il ne matchent jamais avec les valeurs booléennes true et false des modules qui nous intéressent. A l'époque, dans le code de GEA, @Steven avait bidouillé pour prendre en compte les status 0 et 1, car la HC2 stockait toutes les value en mode String. Je me suis justement appliqué à supprimer ces bidouilles, afin de coller exactement à l'API de la HC3, car comme je disais au dessus, les modules prennent enfin des valeurs logiques. Soit Booléennes, soit Numériques, soit Érotiques (String... désolé ) selon le type de module. Tu peux regarder le JSON des différents modules (Z-Wave ou QuickApps) et tu verras. Ces modifications dans GEA ont justement été à l'origine d'un bug que tu m'as aidé à identifier dans cette dernière version. De façon générale, que ça soit en LUA ou dans GEA, quand tu exploites les valeurs des modules, il faut que tu fasses attention à leur valeur réelle... à vérifier dans le JSON de chaque module. Je ne suis pas certain de savoir te répondre pour le "stoppé", mais je suppose que c'est parce que l'action a déjà été réalisée. Si tu mettais un "Repeat", il devrait re-déclencher l'action (si la valeur de l'osmolateur n'a pas changé pour une raison ou une autre)

Le Kemo M152 ça fait au moins 3 ans que je l'ai... un jour il faudra que je l'installe quand même EDIT : "Vous avez acheté cet article pour la dernière fois le 30 avril 2017." Bon bah voilà quoi...

Fait quand même attention, il faut changer les piles régulièrement sur ces modules, s'il faut sortir la grande échelle à chaque fois ça peut être pénible. C'est très variable selon les utilisateurs, disons 1 fois par an en moyenne, mais avec un écart type énorme, mon anémomètre (qui doit avoir un défaut) vide les piles en 3 semaines....

Je ne suis pas certain de comprendre ta question. Si tu veux faire ton scénario en LUA ou en mode bloc, tu es au bon endroit. Si c'est bien une règle pour GEA que tu veux écrire, il faut poser ta question sur le seul et unique topic dédié :

Faut bien qu'on s'entraine à les élever, car quand @jojo va revenir avec sa colonie de chats noirs, on va moins rire

Il me faut bien des beta-testeurs J'avais qu'à mieux beta-tester par moi-même.....

ah... "absolument rien" ? Il va falloir m'en dire plus, sinon impossible de deviner. Que se passe-t-il si tu tests unitairement chacun des modules, comme par exemple : GEA.add({{"Value", "Réserve Némo", true}}, 0, "&0&OSMOLATEUR : Réserve pleine") GEA.add({{"Value", "Réserve Némo", false}}, 0, "&0&OSMOLATEUR : Réserve vide") Si tu veux éviter d'aller tremper le détecteur pour chaque test, tu peux forcer son changement d'état avec les commandes curl suivantes depuis un Shell : curl --write-out "HTTPSTATUS:%{http_code}" --request PUT --user 'Login:Password' --data '{"properties":{"value":false}}' http://192.168.1.1/api/devices/36 curl --write-out "HTTPSTATUS:%{http_code}" --request PUT --user 'Login:Password' --data '{"properties":{"value":true}}' http://192.168.1.1/api/devices/36 (il doit t'afficher en retour le JSON du module modifié ainsi que le code HTTP 200)

Dans ce cas tu les remplaces par plusieurs micro-modules, que tu peux ensuite associer et synchroniser entre eux. Avec des FGD-212 par exemple.