Lazer

Oui tout à fait, c'était le principe lancé par @jang avec son Webhook QD Probablement plus efficace. Mias l'appel de fonction entre QA ce n'est pas neutre non plus, j'imagine que si un seul QA passe son temps à appeler en permanence des fonctions des autres QA, cela doit avoir un cout CPU non négligeable. Mais là aussi il faudrait benchmarker le comportement en charge.

OK.... oui c'est sûr que les électriciens et la domotique ça fait souvent 2 (sauf notre Did national ) Par contre est-ce que tu peux arrêter de citer systématiquement les messages précédents le tient ? C'est pénible.... Merci

Pour le câblage tu as des tonnes de schémas sur Google : https://www.google.fr/search?q=relai+domotique+chauffe-eau&sxsrf=ALeKk00mZ8It2m-Yr8eTCRnBvA89qqmosA:1620379003103&source=lnms&tbm=isch&sa=X&ved=2ahUKEwiGkoaXnrfwAhUI8BQKHa8WBF8Q_AUoAnoECAEQBA&biw=2560&bih=1308 En fait tu vas juste remplacer la sortie contact sec de ton compteur par le contact sec du module Fibaro, c'est relativement simple. Désolé pas de support en privé pour ma part. Mais si tu es si peu à l'aise avec l'électricité, peut être faut-il faire appel à un électricien ? Dans tous les cas, coupe bien le courant au disjoncteur général avant de faire l'opération.

Parce que je FGS-212 n'est plus fabriqué depuis un bon moment. Mais si tu en as un en stock, il fonctionnera tout aussi bien. Ou un FGS-211 ou encore un FGS-224

Précision : ce n'est pas EDF (ou l'un de ses concurrents) qui fourni le signal HC/HP (appelé Pulsadis), mais Enedis. Et ce signal est fourni tout le temps, quelque soit l'abonnement, puisqu'il est envoyé en CPL sur le réseau électrique. D'ailleurs, il n'y a pas que HC/HP, il y a aussi EJP ou TEMPO. En revanche, c'est le compteur, qui une fois programmé en mode BASE uniquement, ne te donneras plus les changements d'heure. Si tu installes ton propre compteur, tu as toujours la possibilité de récupérer le signal en question. Mais l'intérêt est limité, si tu as une box domotique, elle connait forcément l'heure, et peut faire les scénarios que tu veux. Je suis d'accord avec @fredokl le plus simple c'est un module relai qui va actionner ton contacteur actuel. Ainsi pas de problème de puissance. Après tu peux aller plus loin pour améliorer le pilotage, mais c'est plus compliqué. Perso j'ai un ballon avec ACI (courant imposé anti oxydation de l'anode), donc il faut qu'il reste en marche, du coup je ne coupe que la résistance (et surtout pas le thermostat), via un gros relais. C'est @Did qui avait donné l'info. Je fais ça depuis cet hiver, en ne chauffant qu'en fin de nuit, je suis à environ 20% de gain de consommation électrique, c'est énorme.

Bienvenue sur le forum

Oui tu as surement raison.

Merci, je ferai la mise à jour fin mai quand j’exclurai le module pour le ré-inclure sur ma box de prod.

Théoriquement tu pourrais avoir plusieurs QA qui exploitent l'api refreshStates. Je ne sais pas quel serait l'impact sur la charge système, je manque encore de recul.

Euh, j'ai demandé le firmware, pas le prix

Encore une traduction mal.... traduite ! C'est une relation parent/enfant. Et c'est tout à fait normal.... enfin, aussi normal que peut l'être la logique Fibaro. Il n'y a rien à casser. La parent, c'est le module Z-Wave proprement dit. Les enfants, ce sont les "endpoints", disons les fonctions que ce module sait gérer. Si tu n'en n'as pas besoin, tu caches le modules correspondant dans l'interface, tout simplement.

Tu pourrais partager le firmware ? Je ne vois rien sur leur site, pourtant Aeotec partage toujours ses firmwares, c'est même le seul bon élève dans la classe Z-Wave.

Oui, je comprends, en fait tu cherchais une logique similaire à /api/redreshStates Les 2 ont un comportement inversé : /api/events/history permet de remonter dans le passé /api/redreshStates permet de suivre les nouveaux événements au fil de l'eau Du coup, n'est-ce pas refreshStates que tu aurais dû utiliser pour ton application ? Même si tu as trouvé une solution de contournement avec les timestamps from, cela me parait moins précis, car tu peux avoir plusieurs événements au même timestamp (pendant une seconde, c'est long).

Bienvenue sur le forum

Effectivement, la doc du swagger semble erronée, mais le comportement en revanche est logique. Avec numberOfRecords tu récupères les N derniers événements par rapport au moment spécifié (avec lastId). Si lastId n'est pas spécifié, alors c'est le tout dernier. L'idée, est de coller au fonctionnement du panneau d'événement de la HC3. D'abord, on affiche les N derniers événements (afin de remplir la page) Si l'utilisateur scrolle la page, alors on cherche les N événements précédent le dernier ID connu. Etc... cela permet de scroller indéfiniment, et de remonter dans l'historique.

En tout cas 43% pour le used, c'est tout à fait normal, j'ai la même valeur sur mon HC3. J'insiste, je le répète partout sur le forum, il ne faut prendre en compte que le used (= espace utilisé), et ignorer le cache et le buffer.

Ouais c'est ça la magie de GEA Extrait de la doc de syntaxe rédigée par @pepite : Je souhaite que la lumière s'allume au levé du soleil mais pas avant 7h30 : Utiliser le paramètre Sunrise>07:30 ou Sunrise<07:30. GEA.add({"Time", "Sunrise>07:30", "07:35"}, 60, "Allumage lumière", {"TurnOn", 18})

C'est quand même assez aléatoire....

Euh, si, on peut utiliser Sunrize avec >, pourquoi tu dis ça ? Je l'utilise dans mon GEA v6 sur HC2 Pour moi cette condition devrait être valide : {"Time", "Sunrise>08:40", "09:00"}

Non la valeur par défaut c'est seulement 3000 ms, soit 3 secondes. Et j'avais justement augmenté cette valeur à 10000 ms, soit 10 s, pour minimiser les erreurs, car le cloud Netatmo est parfois lent à répondre. Même si ce n'est pas suffisant, car j'ai encore des échecs de connexion. J'ai testé avec 20000 voire 30000, mais ça ne change rien.

J'ai plutôt l'impression que c'est un module qui a buggé, qui inonde le réseau, et fait tout planter. Je ne sais pas combien tu as de modules, mais il va falloir l'identifier... et si tu ne sais pas lequel c'est, il faudra les déconnecter un par un jusqu'à trouver le coupable.

Non la mise à jour ne modifie pas la config du module. Je suppose qu'il n'est pas nécessaire de mettre à jour la HC Lite avant la mise à jour de ce module.

Hum, oui en effet, alors le type multilevel, comme son nom l'indique, ce sont tous les modules qui peuvent prendre une infinité de valeur. Exemple classique : capteur de température, d'humidité, de luminosité, etc. Même si les valeurs peuvent être bornées (ex : humidité, forcément entre 0 et 100) Mais tu as aussi les actionneurs, exemple, le dimmer. D'ailleurs Fibaro fait bien la distinction : multilevelSensor et multulevelSwitch Les capteurs de mouvement et d'ouverture sont de type binaire, true ou false, 2 valeurs uniquement. Le generic n'a rien à voir, puisqu'il n'a tout simplement pas de valeur. Tiens regarde cette URL, tu verras la liste des types sous forme d'arbre : /api/devices/hierarchy Tu verras que temperatureSensor, humiditySensor, etc.. sont des cas particuliers de multilevelSensor L'avantage d'utiliser le type le plus juste, est d'avoir l'unité préconfigurée, l’icône, etc.... Quand tu utilises un multilevelSensor car tu ne trouves pas de type prédéfinis correspondant à ton besoin, tu peux lui affecter ta propre unité (par défaut l'unité n'est pas définie : chaine de caractère vide)

Home Center 3, Home Center 3 Lite and Yubii Home comparison Cela confirme que la seule différence de la Yubii avec la HC3L est la présence de la puce NICE, comme sur la HC3. Cela dit, pour tout le reste, elle est strictement identique à la HC3L. Si je devais faire un classement, je dirais : HC3 >> Yubii > HC3L (oui j'ai bien mis double supérieur entre la HC3 et la Yubii, tant les différences sont nombreuses). Les râleurs vont dire qu'elle n'a pas de puce Z-Wave 700

Ce n'est pas encore en place avec cette version.... ça viendra, mais plus tard. Maintenant je travaille activement sur la migration de ma propre installation d'ici fin mai, donc les améliorations des QA existants, et futurs nouveaux QA, reprendront après.