Bonjour @Jean-Marc_Collin.
Tout d’abord, un grand bravo et merci pour ton VTherm.
Ca fait quelques années que j’utilise la domotique à une échelle très réduite, mais ça fait maintenant quelques semaines où je me plonge réellement dedans. Je rénove depuis 3 ans 1/2 une maison, en ayant tout prévu pour que la domotique soit correctement implantée (mais totalement déconnectable. Pour moi, la domotique c’est du confort, et de l’économie d’énergie, mais clairement pas indispensable).
J’avais prévu de développer un automatisme à base de PID pour réguler le chauffage à la maison, mais je crois bien que je vais pouvoir m’éviter la tâche Donc merci encore.
Je suis encore en phase d’apprentissage sur VTherm, donc je me cantonnerai de te répondre.
J’ai commandé une Sonoff TRVZB pour faire des tests, car j’ai des radiateurs à eau.
D’après mon comparatif (que je peux partager), la sonoff, avec la Shelly, serait celle qui permettrait de piloter son ouverture en %.
La Shelly est en wifi.
La Sonoff en Zigbee.
Je n’ai pas encore totalement poussé mes tests, mais la sonoff serait pilotable par VTherm, à condition que sa consigne locale soit très supérieur à la consigne VTherm. En gros, en la mettant localement à 35°C, et en pilotant l’ouverture maximale de la vanne.
Je ne sais pas si tu as plus d’infos, mais je pense que c’est perfectible.
A dispo si besoin.
Comment j’ai découvert que la course réel n’est que de 70%:
Pour installer les têtes sur mes vieux radiateurs, j’ai opté pour le remplacent des robinets, et j’ai testé le fonctionnement des têtes sur les robinets avant des installé, j’avais donc un visuel sur le mouvement du clapet. De plus lors de la fermeture on entends une petite différence de bruit lorsque la « tétine » vient en appuis sur le robinet.
Je vais tester ton fonctionnement en mode over_valve. Effectivement voir 35° d’affiché peut paraitre étrange, mais si en contre partie la régulation est plus fine ça me va. De plus, j’ai l’impression qu’en mode climate, la vanne fonctionne en tout ou rien, ce qui me dérange, se n’est pas l’intérêt d’une vanne thermostatique, qu’elle soit domotisable ou non.
Par contre je pense qu’il est préférable de verrouiller la tête pour éviter que quelqu’un modifie ce réglage de 35° depuis la tête, même si ton automatisation semble régulièrement forcer cette valeur.
Hello,
J’ai regardé la doc et les discussions avant de poster (une habitude de dev Debian que j’étais un peu plus jeune ;)) et je n’ai pas trouvé d’où mes questions. Mais il est possible que je sois passé à côté, auquel cas j’en suis désolé.
Concernant le site que tu mentionnes avec les shelly TRV, il est indiqué qu’ils sont en rupture
Pour piloter efficacement les Sonoff, il faudrait à la fois modifier la valeur valve_opening_degree et valve_closing_degree.
En modifiant les 2 valeurs en même temps par leurs valeurs inversées (30% ouvert d’un côté = 70% de fermé de l’autre), alors quelque soit la température de consigne de la vanne, elle serait ouverte à la consigne attendue (30% par exemple ici).
valve_opening_degree intervient quand la T° de consigne est > à la T° ambiante
valve_closing_degree intervient quand la T° de consigne est < à la T° ambiante
Egalement, je pense qu’en faisant ainsi, on fait outre la gestion de la régulation par la TRV elle même.
Le fonctionnement idéal pour moi, ce serait :
que la température affichée sur la sonde soit la température de consigne attendue de VTherm,
que la modification locale de la consigne soit remontée à VTherm (il y a le lock si on souhaite sécuriser pour les enfants)
que la modification distance de la consigne soit redescendue à la TRV
et piloter les 2 valeurs opening et closing pour inhiber la régulation autonome de la sonde.
Sauf erreur de ma part, je pense que tout ça doit être jouable avec quelques automatismes et des triggers bien pensés.
En tout cas, avec Z2M on peut modifier l’ens
J’espère pas. En over_climate, le VTherm va donner une consigne de température en fonction de plusieurs paramètres. Et j’espère que la vanne elle-même gère l’ouverture de sa valve en fonction de l’écart de températures.
Je pensais aussi mais non. Si tu changes la valeur de closing_degree (en la mettant >0), ton radiateur chauffera tout le temps (quand la chaudière envoie de l’eau chaude bien sûr).
Je pense qu’il suffit de modifier l’opening_degree et de mettre la température au max.
Si c’est en over_climate, ça n’a pas de sens. Elle ne fonctionne pas en over_valve comme on aimerait.
Si la température réelle de la pièce est 18, que celle relevée est 17, la vanne va pousser plus qu’elle ne devrait et donc la température de consigne réelle ne sera pas respectée. Après, on peut l’utiliser pour remonter une consigne locale vers le VTherm. Mais une fois cette info remontée, le VTherm va appliquer une nouvelle température de consigne qui sera différente de celle demandée. Et il ne faut pas que la personne se dise « ah merde mais elle comprend rien cette vanne » et remette la nouvelle valeur
Donc delocker, remonter l’info, relocker ?
C’est déjà le cas. Mais ce sera pas la consigne réelle de l’utilisateur.
je plussoie totalement cette feature. Je ne savais pas que c’était le cas et je pense que ça répond à certaines de mes interrogations. D’ailleurs, si t’as le temps, je serais curieux d’avoir un exemple où suivre le comportement du sous-jacent est utile. Pour moi, utiliser VTherm permet d’oublier ce qu’il se passe en-dessous.
Bonsoir à tous, c’est important pour ceux qui ont des têtes thermostatiques, car quand la consigne est changée manuellement en tournant la tête (ce qui arrive souvent chez moi) , la consigne affichée dans HA ne serait plus à jour.
C’est exactement ce qui me retient de passer mes têtes over_climate en self regulation. Je ne veux pas que la consigne affichée sur la tête soit différente de ma consigne réelle.
J’ai des Danfoss Ally (avec sondes tempé externes) et je trouve l’algo interne nul, soit ça met longtemps a chauffer soit ça dépasse la consigne d’où mon intérêt pour VT,. Une solution que j’avais imaginé c’est que VT agisse sur le paramètre zigbee " Regulation setpoint offset Décalage du point de consigne de régulation dans la plage -2,5°C à 2,5°C par pas de 0,1°C. "
Comme ça on peut agir sur la régulation sans changer véritablement la consigne. Mais je ne sais pas si ce paramètre est répandu parmi les têtes thermostatiques Zigbee.
Juste au dessus par exemple, tu as @Superfrog (que je remercie au passage pour les infos) qui dit que serait bien que la consigne locale soit remontée au VTherm.
Moi, je fais comme toi, je ne change jamais les consignes locales et je finis même oublier qu’on peut le faire, mais je comprends que si on veut changer la température on puisse le faire : tout le monde n’a pas l’envie d’ouvrir HA à la place de prendre une télécommande ou de tourner un bouton.
C’est exact ce serait certainement une solution et y a beaucoup de discussion sur le github à ce sujet, et même un PR en développement (mais non aboutie pour l’instant). La grosse difficulté c’est de trouver si l’équipement a cette fonction et de trouver l’entité correspondante ainsi que sa plage d’utilisation. Tout cela n’a pas l’air très normalisé et d’une tête à l’autre la détection de cette entité d’offset n’est pas la même.
L’autre soucis, c’est que je n’en ai pas moi même donc je suis en aveugle sur ces sujets TRV.
Comme je le disais un peu avant, pour moi, la domotique ne doit être ni indispensable, ni devenir une contrainte.
Or, ça ne fait que quelques semaines/mois que je suis obligé de passer par mon téléphone pour m’apporter le confort ou la simplicité que j’attend de la domotique (par exemple, démarrer une scène d’ambiance pour un certain besoin : lecture par exemple), et j’en ai déja marre
Il faut sortir/trouver le téléphone, ouvrir HA, et appuyer sur le raccourci de la scène.
Pour résoudre ce problème, j’ai 2 solutions :
Soit avoir un trigger pertinent (ouverture de la porte d’entrée => Eclairage d’ambiance minimum pour y voir quelque chose).
Soit avoir un actionneur physique (je me suis commandé des interrupteur zigbee que je vais fixer sous les tâbles (ne gênent pas, invisibles, ne sont jamais perdus, …) qui me permettra de réaliser les actions que j’attend en fonction de là où je me trouve.
Il en est donc de même pour le réglage de la température d’une pièce.
Evidemment que si je suis ici, c’est que j’attend à ne plus me soucier de la température de ma maison et que tout soit le plus autonome possible. Il n’empêche que si je souhaite modifier la consigne, je suis obligé de trouver mon téléphone, ouvrir HA, …
Je peux bien sûr comme précédemment rajouter un potar zigbee. Mais ça tombe bien, il y en a déja un sur ma TRV
Si j’ai tout bien compris:
en mode over_climate, on vient tricher sur la consigne locale de l’actionneur pour le forcer à chauffer selon une sonde plus juste. Il faut également prendre en compte la température locale de l’équipement afin de s’assurer que la consigne envoyée est supérieure à la température de l’équipement. (cas d’usage chez moi hier : 21°C en local sur la clim, 18°C dans la pièce).
en mode over_valve, on vient simplement indiquer à l’actionneur la position attendue (en % d’ouverture) selon le calcul de régulation.
J’ai quand même l’impression (sauf erreur de ma part) que le over_valve est bien plus simple en fonctionnement, paramétrage et régulation qu’en over_climate. Ce serait dommage de se passer de ce mode.
J’ai l’impression qu’elle fonctionne, mais il faut imposer une consigne locale très supérieure à la consigne de régulation.
L’idéale pour des TRV, ça aurait été d’avoir un simple moteur commandé en % d’ouverture. C’est un produit qui est difficile à trouver, et d’après mes recherches la sonoff serait la meilleure solution (en zigbee).
Pour éviter d’avoir un fonctionnement « bancal » mais fonctionnel, je vais continuer mes tests, mais je pense qu’il faut bien imposer les 2 valeurs opening et closing. C’est VTherm qui pilote, c’est lui qui donne le % d’ouverture. Ainsi, quelque soit la consigne et la température locale, la vanne sera ouverture à la valeur envoyée par VTherm (qui je pense, aura une meilleure régulation que n’importe quel système automatisé, car bien plus souple et configurable).
Et cerise sur le gateau, faire en sorte que la commande locale remonte la consigne à VTherm (et vice versa). ça n’aura aucune influence sur la consigne de régulation, étant donné que dans le cas d’un over_valve, consigne régulation = consigne utilisateur.
Pas exactement. Je disais simplement qu’il était possible de verrouiller la commande locale, et donc n’avoir qu’un seul et unique mode de fonctionnement : la remontée quoi qu’il en soit de la consigne locale. Si on ne veut pas que la consigne locale ai d’incidence sur la consigne VTherm => On lock la tête.
Si on veut qu’il y ait une incidence : => On ne lock pas la tête.
En over_valve non, puisque je suis obligé de mettre ma TRV à 35°C en local, et de forcer avec VTherm le % d’ouverture.
Si je veux 20°C, je met 20°C sur ma vanne, et ca met ma consigne VTherm à 20°C. Ensuite VTherm joue avec opening/closing valve pour contrôler en %.
Evidemment qu’une vanne avec un contrôle direct de l’ouverture simplifierait énormément les choses, mais ca n’est pas chose courante à l’heure actuelle.
Malheureusement avec les têtes SONOFF, j’ai fait le test et quelque soit l’écart de température entre la consigne et la mesure, la vanne s’ouvre à 100% ou se ferme à 0%. Elle régule donc une chauffe en mode tout ou rien. D’où l’intérêt de passer sur un over_valve, ce que je teste en se moment.
Je suis d’accord avec toi, agir sur les 2 réglages permettra de figer la position de la vanne quelque soit la consigne appliquée directement sur la TRV. J’ai créé un input_number en 0-100% qui prend la valeur de ma régulation Vtherm et je l’injecte dans le opening. En parallèle j’injecte dans le closing (100 - input_number).
La position de la valve suit bien la consigne, et nous somme sur une véritable régulation avec un débit d’eau de chauffage proportionnel au besoin et non sur un fonctionnement tout ou rien.
Reste à voir dans le temps si les réglages des coefficients nécessiteront un ajustement. Le gros problème avec la régulation de chauffage étant l’inertie, il faut être patient pour tout affiner.
Je pense que si la vanne sonoff ne permet pas de contrôler le % d’ouverture de la vanne, c’est justement parce qu’il risque d’y avoir un problème entre ouverture de la vanne et température de consigne. Donc, c’est l’algo interne qui décide combien elle est ouverte en fonction de la température de consigne entrée. Le reste, c’est du bricolage.
Je maintiens ma position quant à piloter la vraie température de la pièce depuis la vanne : exception faite des Aqara quand elles sont couplées à un capteur externe, tu ne peux pas envoyer une consigne de température à VTherm et t’attendre à ce que VTherm te mette réellement cette température dans la pièce tout en l’affichant sur la vanne.
Sinon, moi non plus je n’aime pas sortir mon téléphone et lancer une app pour commander quelque chose. C’est pour ça que j’ai installé des interrupteurs pour commander mes lumières et autres appareils directement. Ça marche bien pour les choses simples (arrosage, volets, lumières, prises) mais pas pour contrôler un thermostat (même si l’interrupteur Hue Tap Dial pourrait permettre de contrôler la température mais sans affichage). C’est la raison pour laquelle j’aurais bien aimé trouver un capteur de température zigbee avec affichage local et des boutons + et - pour contrôler les thermostats. Et les seuls que je trouve, c’est ceux qui se branchent sur le courant pour piloter une chaudière. Je pourrai en installer un par pièce pour contrôler la température de la pièce en question, sans qu’il commande aucune chaudière, mais ça coûterait un peu cher pour une télécommande.
On est d’accord
Par contre tu as créé 2 input ? Tu peux mettre directement l’entité opening dans le sous jacent de VTherm, et calculer le closing à partir de l’opening. Ainsi que n’as créé qu’un seul input.
Pour la suite, je veux bien que tu m’expliques ta procédure pour le calcul et l’envoi de la commande vers la TRV, car je suis également en apprentissage côté Home Assistant et Z2M ^^
Pour la régulation, pour le moment je fais confiance aux paramétrage standard de VTherm Je règle d’abord le fonctionnement du pilotage des TRV avant de m’attaquer à la suite.
Je ne connaissais pas la régulation TPI, je vais essayer de le comparer au PID que je maitrise mieux. Ensuite j’essaierai soit de manière empirique comme toi (mais c’est long), soit d’essayer d’approcher une valeur avec des essais réels (je dois recevoir une caméra thermique, je ferai plusieurs tests réels), pour ensuite affiner de manière empirique.
Je crois bien que Better Thermostat joue justement avec l’offset. Je ne l’ai pas testé, j’ai sauté sur VTherm quand j’ai vu son fonctionnement
Mais je ne suis pas trop fan de cette solution (du moins si c’est le seul levier à dispo, on fait avec).
Car dans ce cas c’est quand même l’algo de l’équipement qui s’occupe de la régulation. Je pense que VTherm sera plus puissant, plus précis et surtout fonctionnel quelque soit son équipement (sous réserve de pilotage possible).
Je remet en forme mon fichier excel de comparaison des TRV et des fonctionnalités dispo, puis je vous le partage ici.
La Sonoff a également la compensation d’offset, c’est pour ça que je l’ai prise (compatible régulation via Better Thermostat et via VTherm), en plus d’être relativement pas trop chère sur Aliexpress.
Bonjour, les Sonoff TRVZB sont parfaitement pilotables en over_valve, mais y a quelques prérequis à faire.
En effet, cette vanne n’expose aucune entité pour piloter l’ouverture de la vanne. La seule entité dispo (depuis les màj récente), c’est une entité « d’ouverture max ». Ça permet d’imposer une limite sur l’ouverture max à la vanne. Si on met 50%, la vanne, même si on demande du chaud plein pot, ne s’ouvrira pas plus de 50%. C’est donc ce paramètre qui est exploité pour piloter la vanne en over_valve
Voici les grandes étapes :
la première, c’est que ça fonctionne uniquement en Z2M. En ZHA, les entités pour piloter la vanne ne sont pas exposées (dans mon cas, j’ai du racheter un autre coordinateur pour faire tourne Z2M en parallèle de ZHA pour tous mes autres équipements).
màj (OTA) pour avoir le firmware 1.1.5 minimum, celui qui expose les entités pour contrôler la vanne.
régler le paramètre offset au minimum (-12.8°C). Ça veut dire que s’il fait 20°C dans votre salon, la vanne va retourner une valeur de 7.2°C et donc forcer l’ouverture à 100%
installer le Blueprint (dans le github de la discussion) pour synchroniser l’affichage de la vanne avec la consigne du Vtherm. C’est une synchro bidirectionnelle (un changement sur l’un le réaffecte sur l’autre). Le Blueprint peut gérer plusieurs vannes dans la même pièce associées sur le même Vtherm.
Le pilotage de la vanne se fait via l’entité number.trv_valve_opening_degree
Si on ne fait rien, la vanne sera toujours ouverte à 100%. C’est du à l’offset qu’on a réglé au minimum.
Le VTherm va piloter la vanne en lui envoyant une commande d’ouverture max, par exemple 10%.
Alors oui, c’est pas du « out of the box », mais malheureusement il n’y a que cette vanne qui fonctionnent en over_valve aujourd’hui.
La shelly (Wifi pour rappel), est en rupture de stock partout.
La SEULE autre référence qui permettait d’inhiber le thermostat intégré et de la rendre 100% pilotable, c’est la EUROTRONIC SPZB0001, également épuisée partout…
Attendez un peu… Y a sa remplaçante, la Comet Eurotronic Zigbee, mais elle n’est pas référencée sur la doc de Z2M. En revanche la doc du fabricant indique bien un mode TRV et une entité valve_position en read/write. Je pense que c’est l’heureuse gagnante, mais à deux fois le prix de la Sonoff…
On va espérer que Sonoff nous gratifie d’une màj avec cette fameuse entité valve_positionen read/write !
Tu peux m’expliquer ta procédure de test afin que je la reproduise ?
Car de mon côté, avec les quelques tests que j’ai réalisés en déconnecté (TRV dans la main), et en jouant avec les valve_opening_degree et valve_closing_degree, j’arrivais à avoir le % d’ouverture que je souhaitais.
Si on parle avec un référentiel « ouverture absolue » ou x = valeur min d’ouverture, et y = valeur max d’ouverture, alors :
x = 100 (%) - valve_closing_degree (en %)
y = valve_opening_degree (en %).
De ce fait, 2 exemples, sans même prendre en compte la température de consigne de la vanne.
Je dis à ma vanne :
– tu peux t’ouvrir au maximum à 30% : valve_opening_degree = 30% : y = 30%
– Tu peux te fermer au maximum à 100% : vale_closing_degree = 100% : x = 100-100 = 0
– Alors la vanne régulera d’elle même entre x : 0 et y : 30% d’ouverture max.
Je dis à ma vanne :
– tu peux t’ouvrir au maximum à 30% : valve_opening_degree = 30% : y = 30%
– Tu peux te fermer au maximum à 70% : vale_closing_degree = 100% : x = 100-100 = 30
– Alors la vanne régulera d’elle même entre x : 30 et y : 30% d’ouverture max : donc ouverte à 30%.
Tu me met le doute, je referai des tests dès que possible, mais c’est ce que j’ai conclu de mes tests d’hiers.
L’opening_degree semble être une valeur absolue et non relative. Donc la valeur finale appliquée par la vanne est bien l’opening_degree et non lopening_degree x % ouverture vanne.
Donc merci encore.
