Lazer

Bienvenue sur le forum

Bienvenue sur le forum

C'est déjà le cas depuis GEA v7.11, la gestion complète des thermostats est disponible (température, mode chaud/froid/déshumidificateur, vitesse de ventilation.... évidemment en fonction des capacités de chaque thermostat) Je me demande justement de quelle manière on pourrait piloter le panneau de chauffage via GEA (dérogation, mode vacances, etc...), il faut que je me penche sur la question.

D'ailleurs cette discussion me fait penser qu'il pourrait être pertinent d'ajouter la gestion des panneaux de chauffage dans GEA. Qu'en pensez-vous, cela aurait-il un intérêt pratique ?

Pourquoi donc ? J'ai toujours eu une seule instance GEA, actuellement avec environ 200 règles sur la HC2, et ça n'a jamais posé de souci.

Tu es limitée par la rigidité des panneaux de chauffage.... même problème que sur la HC2. C'est parfait pour les horaires ultra réguliers, mais en dehors de ça, c'est compliqué..... @jojo avait fait un tuto à l'époque pour basculer facilement d'une planification à une autre, mais ça reste un contournement. Perso, en dehors de la chambre parentale, je gère le chauffage de toutes les pièces depuis GEA, ça me permet de prendre en compte plein de conditions : présence/absence, quelqu'un est rentré plus tôt, on a fini de manger, mode film, c'est le confinement de saison, etc...

C'est l'avertissement classique, il ne faut pas couper l'alimentation ON/OFF du radiateur. Si tu passes par le fil pilote, pour "donner des ordres", aucun souci.

Very interesting, thank you

@Nico je vois que tu passes par le cloud... au cas où, tu devrais essayer en local sur l'IP du contrôler, dès fois que ça soit comme chez Fibaro, avec des fonctionnalités limitées via le cloud par rapport à l'accès local

Tu devrais tout simplement prendre le type com.fibaro.rollerShutter

Hum, je ne sais pas quoi penser de ce message d'erreur apparu dans les notifications sur la HC3 : A priori, je pense que cet événement est apparu suite au reboot violent de la HC3 survenu lors d'une micro-coupure de courant (elle n'est pas sur onduleur). Je n'ai reçu aucune notification push ni email, je viens de m'en rendre compte en me reconnectant sur la HC3 environ 2 jours après. Cela ne m'inquiète pas plus que ça, car je n'utilise pas le protocole NICE, mais bon... voilà encore un joli bug. Firmware 5.050.13 stable

Bon, fini de déconner, je ferme ce topic Le monsieur mal élevé qui ne s'est pas présenté est prié de continuer la discussion sur le topic unique.

Aeotec "aërQ" Sonde de température et d'humidité Z-Wave Plus V2 (Gen7) Aeotec ZWA009-C : version initiale Aeotec ZWA039-C : nouvelle version avec meilleure autonomie et mesure plus fiable du niveau de pile Z-Wave Plus V2 (puce Série 700 / Gen7) Mesure la température de -10 à 65°C (+- 1°C) Mesure l'humidité de 10 à 95% Mesure le point de rosée de -10 à 65°C (+- 1°C) Indique le risque de moisissure via son voyant LED intégré et vers le système domotique Peut commander par association directe jusqu'à 5 appareils par groupes : sur température haute, température basse, humidité haute, humidité basse (seuils et commandes configurables) Peut transmettre à d'autres équipements la température mesurée (5, en plus de la box domotique) Seuils de transmission des mesures configurables : Températures : de 0,1 à 100°C Humidité : de 1 à 20% + cycliques toutes les 15min à 18h Communications sécurisées S0 ou S2 avec cryptage AES (grade bancaire) Installation simplifiée par flash code "SmartStart" Garantie 2 ans Indice de protection : IP20 => normalement prévu pour l'intérieur, aucune protection contre l'eau, à ne surtout pas utiliser sous la pluie Compact : 35 x 35 x 18 mm Alimentation par pile lithium 3V CR2477 fournie pour une durée de vie de 2 ans : Page officielle : https://aeotec.com/z-wave-home-automation/temperature-humidity-sensor.html Manuel : https://aeotec.freshdesk.com/support/solutions/articles/6000227918-aërq-temperature-and-humidity-sensor-user-guide- Spécifications techniques : https://aeotec.freshdesk.com/support/solutions/articles/6000227919-aërq-temperature-and-humidity-sensor-technical-specification- Disponibilité : début 2021

Bien vu, merci pour l'astuce

Étrange.... peut être l'un de tes codes LUA qui est parti dans une boucle infinie ?

Justement, de ce que j'ai compris, le thermostat est juste ... inutile ! Le thermostat d'ambiance dans le salon, c'est une relique du passé, à une époque où les logements étaient plus petits, qu'il n'y avait pas de têtes thermostatiques sur les radiateurs (juste un robinet mécanique standard) Donc le thermostat régulait la température dans la pièce principale... et tant pis pour la température dans les autres pièces qui étaient forcément plus froides (pour les chambres ce n'est pas un souci, pour la SDB c'est problématique) Aujourd'hui avec les têtes thermostatiques, tu vas régler la température indépendamment dans chaque pièce de la maison, y compris le salon, dans lequel il faut supprimer le thermostat d'ambiance. La logique derrière ça étant que la chaudière doit être toujours en fonctionnement pour que les têtes thermostatiques puissent réguler. Conséquence, une tête dans tout le réseau doit être toujours ouverte à fond (pour que le circulateur de la chaudière ne force pas), en général la salle de bain, qui devient la pièce la plus chaude de la maison. L'optimisation ultime, les 1% d'économies restantes, c'est justement de contrôler la chaudière avec un relai (FGBS, ou FGS, au choix) ou son circulateur (présence éventuelle d'un bypass). Il me semble que c'est @Yohan qui avait super bien expliqué le principe, avec @Nico et quelques autres. Les thermostat connectés à la mode que tu vois partout (Nest, Netatmo, etc), ça sert surtout pour ceux qui ne veulent rien domotiser. En gros, tu remplaces le thermostat d'ambiance du salon de grand-mère par ce thermostat connecté. Qui permet de faire des économies / améliorer le confort par la simple programmation des horaires (optimisé avec algo de détection de présence, et contrôle à distance depuis le smartphone pour le retour de vacances). Mais ça ne résout en rien le problème du chauffage des autres pièces de la maison, et comme tu le constates, cela empêche carrément le fonctionnement des têtes thermostatiques... donc il ne faut pas utiliser de thermostat central/d'ambiance/connecté quand on a têtes thermo.

Parfaitement de circonstance pour le réveillon seul à la maison

"commerciale" : tout est dit. Ce module va juste te permettre de piloter ta chaudière en mode contact sec. Ce module n'a aucune intelligence, et ce n'est pas lui qui va gérer ton chauffage. Il y a donc une grosse réflexion en amont sur la façon de gérer ton chauffage. Le pilotage de chauffage central est bien plus complexe que le chauffage électrique, perso je ne saurais pas t'aider, mais il y a déjà eu plusieurs discussions assez avancées sur le sujet sur le forum il y a quelques années, je te laisse les retrouver. De mémoire et en résumé, ça donnait : il est compliqué de gérer son chauffage central à la fois par les têtes thermostatiques + chaudière, mais c'est faisable..... même si le gain est très faible, car les têtes thermostatiques font 99% du boulot.

Il me plaît bien ce ZWA009 Vivement qu'il soit dispo

Tiens tiens... Bienvenue sur le forum @jluc2808

Tu fais comme tu le sens, mais je reste persuadé que toute la logique du réveil est déclenchable depuis le parent. Bon l'essentiel c'est que tu t'y retrouves dans ton propre code.

Oui voilà plus dans l'esprit de ta dernière suggestion. Cela dit, je pense que tu peux simplifier, pourquoi avoir Func1 et Func2, alors que tu pourrais en voir une seule et passer les arguments en paramètre. Enfin, je veux dire, si Func1 et Func2 font la même chose, alors il faut les regrouper en 1 seul avec un code commun, et des arguments en paramètre. Si elles font des choses différentes, dans ce cas, tu peux garder des fonctions différentes. Mais je maintiens ce que j'ai dis plus haut. Il ne devrait pas y avoir de Settimeout dans la classe enfant. Le settimeout devrait se faire dans une loop du parent (classe QuickApp), qui à chaque passage de boucle appelle une fonction des enfants : MyChild:update() ou un truc dans le genre Je pense qu'une bonne pratique, c'est de laisser l'intelligence et l'orchestration des actions dans le parent. Et ne donner aux enfants que des tâches le plus basiques possible. Cette bonne pratique éviterai les confusions avec des variables locales je pense. Bref, c'est une toute autre façon d'organiser son code

Ah oui exact mais tu as un souci avec self, au moment où tu appelles les fonctions locales, le self ne correspond plus à chaque child je t'ai dis que je n'aurais pas du tout écrit ces fonctions de cette façon là.... j'aurais simplement une méthode de WAKEUP qui s'appelle elle-même avec settimeout(), de cette façon tu es certain que self pointe bien sur le bon child en cours. Cela dit, il me semble que @jang nous avais dit un jour qu'un child n'est pas censé se mettre à jour tout seul. Tout cela devrait être supervisé par le parent, dans directement dans une méthode de QuickApp. A lui de parcourir les children et de les mettre à jour. C'est en tout cas la technique que j'utilise dans tous mes QA, et je n'ai jamais eu de souci de "mélange" de child.

je pense que c'est normal. Premier appel de wakeStart() : tu définies ta variables locale ainsi : local idLight = self:getVariable("idLight") Qui va prendre la valeur 731, et qu'il va conserver... jusqu'au 2nd appel de wakeStart(), moment où cette même variable locale sera écrasée avec la valeur du 2nd child : 732 Ensuite, il conservera indéfiniment 732 Il faut te méfier quand tu mélanges des variables locales avec plusieurs instances d'objets, chacun accessibles au travers de leur propriété self. Je n'aurais personnellement pas du tout écrit tes fonctions ainsi, car elles portent à confusion. Dans l'immédiat, tu peux essayer de remplacer la variable local par une variable stockée dans le child : self.idLight = self.idLight or self:getVariable("idLight") Déjà c'est bien plus efficace, car on conserve sa valeur tant que le QA n'est pas redémarré, donc on évite des appels inutiles à self:getVariable() (assez lent, puisqu'il va parcourir l'API) Ensuite, dans tes fonctions, tu utilises self.idLight, tu es certain que cette variable est associée à chaque child, indépendamment des valeurs des variables locales.

Bienvenue sur le forum