Je reviens vous consulter quelques mois après avoir pris mes premiers renseignements sur ce fil.
Je me suis entre temps équipé de 7 vannes thermostatiques Eurotronics Spirit Z+, que j’ai équipées sur les radiateurs dont il m’importe de réguler la température des pièces dans lesquelles ils se situent.
Ma chaudière à gaz est une chaudière classique, elle ne fonctionne pas en basse consommation et se met en route lorsque le thermostat qui y est raccordé lui ordonne.
Mes questions maintenant :
J’ai remarqué que parfois, une vanne reste ouverte dans une certaine mesure (cf coefficient d’ouverture de la vanne) alors que la température qu’elle mesure est 3 à 3.5°C supérieure à celle de la consigne. Alors je sais que la vanne dispose d’une intelligence qui peut adapter son comportement suivant l’isolation de la pièce, etc… mais ça m’interpelle quand même, dois-je m’en inquiéter ? Car en hiver, cela signifiera une consommation accrue de gaz.
J’utilise donc au final un ensemble de 7 vannes, dont les consignes sont données via les événements de mes différents agenda (un par pièce). Pour l’activation de la chaudière, je me sers du rapport d’ouverture des différentes vannes. Pour l’activation, je fais un OU entre les différentes vannes, et si l’une des vannes a un coefficient d’ouverture strictement supérieur à 8%, j’active la chaudière. Pour la désactivation, j’utilise un ET : si toutes les vannes ont des coefficients d’ouverture inférieurs ou égaux à 8%, je désactive la chaudière. Sur le papier, ça m’a l’air fonctionnel, cela étant je ne pourrai le tester en situation réelle qu’au début de l’hiver.
Sauf que si, comme dans ma première question, la vanne garde un taux d’ouverture suffisant > 8%, alors qu’il fait bien assez chaud dans la pièce, la chaudière continuera de tourner, et au prix de l’énergie…
J’imagine qu’une vérification temporelle par le biais d’une moyenne pourrait faire l’affaire, mais existe-t-il une meilleure méthode ?
Dernier point, mon contrôleur Z-wave est sur mon serveur Debian situé au sous-sol, pour anticiper des problèmes de portée et de qualité du signal, j’ai acheté 2 range extender 7 d’Aeotec et 2 smart switch, que j’ai répartis de façon uniforme dans la maison. Malgré tout, le RSSI moyen de mes équipement oscille autour de -90 dbm, de ce que j’ai pu lire c’est excessivement mauvais. J’ai également remarqué que liens empruntés par les vannes pour arriver au contrôleur sont parfois aberrants : la vanne de la chambre de mes enfants située au premier étage se connecte au range extender du 2ème étage, lui-même est lié au smart switch du rez-de-chaussée, pour que ce dernier se connecte enfin au contrôleur, 3 hops au lieu d’un seul attendu. Est-ce un comportement normal pour un mesh Z-wave ? Je compte essayer de profiter d’une Rpi 4 que j’ai sur le côté et le placer au milieu de la maison pour comparer, mais est-ce normal que la gen 7 tant vantée pour sa portée améliorée galère autant dans une maison dont les planchers sont en bois (sauf entre le RDC et le sous-sol) ?
La portée est très compliquée à définir, pour ma part des radiateurs, la carcasse métallique fait probablement cage de farraday et la portée est très faible. Le meilleur moyen au que j’ai trouvé est d’ajouter 2 prises sur secteur qui font relai.
As tu essayé le plugin thermostat pour le chauffage ?
J’ai suivi ton conseil et j’ai mis un répéteur directement à côté de la clé. J’ai vu une nette amélioration, même si je pense pouvoir arriver à quelque chose de mieux encore.
Le graphe des nœuds est déjà plus cohérent, les liens sont physiquement en accord avec la physionomie de la maison :
Je vais transposer ma stack docker jeedom/mosquitto/zwavejs sur un raspberry central dans la maison pour comparer par rapport au sous-sol.
Pour les %ages d’ouverture des vannes, je vois déjà un mieux par rapport à il y a quelques jours. Je ne sais pas trop ce qu’apporterait le plugin thermostat, ça me semble redondant avec les vannes, qui sont déjà des thermostats. A quelles fonctionnalités penses-tu ?
Ah, et je suis satisfait car le MULTISENSOR 7 fraîchement reçu arrivé bien à envoyer sa consigne à la vanne du salon pour écraser sa propre lecture en température.
Un changement de consigne à la baisse pourrait corriger ce phénomène.
Tu pourrais rajouter de l’hystérésis dans tes scénarios afin d’éviter des allumages/extinctions intempestifs de la chaudière (surtout obtenir des phases de coupure plus longues au détriment un peu du confort) : <8% pour couper et >20% pour allumer. L’idée de faire la somme des ouvertures est aussi intéressante. Ainsi, avec 7 radiateurs, tu coupes la chaudière lorsque la somme est inférieure à 56 (=7x8) et la rallumes lorsque la somme est supérieure à 140 (=7x20).
Oui c’est bien celui-là, il est certes un peu cher mais ça a l’air d’être un capteur de qualité. De plus j’avais touché 8 vannes pour 100€ donc ça me laissait un peu de marge pour me faire plaisir.
Et le support d’encastrement je l’ai trouvé en seconde main, c’est le même que pour le 6 ou le trisensor.
Merci pour l’idée de la somme des coefficients, je n’y avais pas songé, ça permet de réduire la consommation.
Pour info, j’ai mis en place la gestion par cumul des ouvertures (pour l’allumage de la chaudière), il faudra voir en saison mais de ce que j’ai pu observer, ça a l’air assez fiable, le tout étant de trouver les bonnes valeurs par rapport à son habitation, je verrai dans quelques mois.
Egalement, j’ai essayé de résoudre les problèmes de portée et les noeuds avec lesquels je perdais souvent la connexion. Il se trouve qu’en fait, le net regorge de sujets parlant de problèmes concernant le Z-stick gen7 d’Aeotec. En effet, malgré les updates de firmware, les bugs sont bien présents, principalement que lorsqu’il y a un trafic important, le stick ne répond plus, résultat les scenarios foirent, les périphériques mettent leurs reports d’informations en file d’attente et essaient à intervalles réguliers d’atteindre le contrôleur, résultat corollaire un usage intense de la batterie.
Donc je peux tout remettre sur ma Debian visiblement, ce que je préfère, vu que j’ai un schéma de sauvegarde et restauration bien plus poussé sur celle-ci que sur le raspberry.
Je vais voir si je trouve un stick gen5+ qui semble ne pas avoir de problèmes, et est a priori compatible avec mes équipements actuels.
Après quelques jours de test, il s’avère qu’en désactivant le backup NVM via cron du Z-stick, il n’y a plus aucun problème de nœud mort ou inactif.
Même en laissant les agendas activés, avec par conséquent des moments où le trafic est intense, aucune commande de scenario n’a été omise pour l’instant.
J’essaierai à l’occasion de faire un backup manuel voir si ça bloque de nouveau la clé.
