Voilà ce que j’ai fait pour gérer mes radiateurs à inertie fluide.
Je défini sur le radiateur la température du mode hors-gel, éco et confort, et je bascule ensuite entre les différents modes grâce au qubino fil pilote derrière chacun d’eux, avec une gestion des plages horaires et des absences/ouvrants pilotée par schedy. Et voilà, je laisse donc l’électronique des mes radiateurs gérer l’inertie de chauffe.
L’inconvénient ici c’est évidemment que je ne peux pas gérer ma consigne de température via HA, mais uniquement physiquement sur mes radiateurs. Mais en pratique, je n’ai jamais besoin de changer la température cible, c’est toujours la même par mode (éco et confort)
Je dirai que oui et c’est aussi le type de radiateur que j’ai. Pour un poele, il ne peux être allumé et éteint trop souvent. Je testerai volontiers sur 30 mn et plus.
Pour changer la valeur et passer de 10mn a 30mn, il y a 2 modifications a faire dans le blue print :
Passer le temps de 10 a 30 (minutes: « /30 ») comme indiqué par @djal
Le prendre en considération dans le temps de chauffe, et passer de *6 a *18 ( temps_chauffe: ‹ {{ puissance * 18 }} ›). Ainsi une puissance de 100% donnera un temps de chauffe de 180 secondes, soit 30 minutes.
Voila le nouveau blue print
blueprint:
name: Thermostat TPI
description: Thermostat TPI (Time Propertional & Integral)
domain: automation
input:
coeff_c:
name: Coefficient C
description: coefficient multiplicateur de la différence entre la consigne et éa température intérieure pour le calcul de la puissance (0.6 conseillé)
selector:
number:
min: 0.0
max: 1.0
step: 0.01
coeff_t:
name: Coefficient T
description: coefficient multiplicateur de la différence entre la consigne et éa température extérieure pour le calcul de la puissance (0.01 conseillé)
selector:
number:
min: 0.0
max: 0.1
step: 0.001
entity_consigne:
name: Consigne
description: Champs d'entrée de la température de consigne (input number).
selector:
entity:
domain: input_number
entity_temp_ext:
name: Température extérieure
description: Sonde de mesure de la température extérieure (sensor)
selector:
entity:
domain: sensor
device_class: temperature
entity_temp_int:
name: Température intérieure
description: Sonde de mesure de la température intérieure (sensor)
selector:
entity:
domain: sensor
device_class: temperature
entity_fenetre:
name: Fenètre
description: Capteur d'ouverture de fenêtre (sensor)
selector:
entity:
domain: binary_sensor
device_class: opening
entity_puissance:
name: Puissance
description: Champs d'affichage de la puissance (input_number)
selector:
entity:
domain: input_number
entity_chauffage:
name: Chauffage
description: Interrupteur marche / arrêt du chauffage (switch)
selector:
entity:
domain: switch
# Récupération des paramètres
variables:
coeff_c: !input coeff_c
coeff_t: !input coeff_t
entity_temp_int: !input entity_temp_int
entity_temp_ext: !input entity_temp_ext
entity_fenetre: !input entity_fenetre
trigger:
- platform: time_pattern
minutes: "/30"
- platform: state
entity_id: !input entity_consigne
# - platform: state
# entity_id: !input entity_temp_int
- platform: state
entity_id: !input entity_fenetre
action:
- alias: récupération des données
variables:
entity_consigne: !input entity_consigne
consigne: "{{states(entity_consigne)}}"
temp_ext: '{{ states(entity_temp_ext) }}'
temp_int: '{{ states(entity_temp_int) }}'
fenetre: '{{states(entity_fenetre)}}'
puissance: >-
{%set val = coeff_c * (consigne - temp_int) + coeff_t * (consigne -
temp_ext) %} {% if val > 1 %} {% set val = 100 %} {% elif val < 0 or
fenetre == 'on' %} {% set val = 0 %} {% else %} {% set val = ( (val *
100) | round(0)) %} {% endif %} {{val}}
temps_chauffe: '{{ puissance * 18 }}'
- alias: Met à jour l'indicateur de puissance
service: input_number.set_value
target:
entity_id: !input entity_puissance
data:
value: '{{puissance}}'
- choose:
- conditions:
- condition: template
value_template: '{{puissance == 0}}'
sequence:
- service: switch.turn_off
target:
entity_id: !input entity_chauffage
- conditions:
- condition: template
value_template: '{{ puissance > 99}}'
sequence:
- service: switch.turn_on
target:
entity_id: !input entity_chauffage
default:
- service: switch.turn_on
target:
entity_id: !input entity_chauffage
- delay: '{{temps_chauffe}}'
- service: switch.turn_off
target:
entity_id: !input entity_chauffage
mode: restart
@djal sur l’utilisation du thermostat du radiateur : effectivement cela fonctionnera. Mais le pb est que la sonde de température du radiateur est sur le radiateur, donc chauffe forcément. Il y a un écart probable fort entre la température de consigne et celle de la pièce, plus une oscillation chaud / froid. Un thermostat dans HA avec une sonde externe permet de converger vers une température très précise, ce qui est source de confort et économie. Je te conseille de tester et mesurer l’écart consigne du radiateur / température réelle de la pièce.
Oui tu as raison, mais j’ai des sondes aqara, qui, même si elles sont précises, ne remontent pas assez fréquemment la température, avec aucune possibilités de réglages (problème du zigbee ).
Mais dans l’idée oui avec une sonde déportée ça fonctionnerai mieux.
Ceci dit , pour faire ça, je ne doit jouer qu’avec le mode confort en on/off, et régler une température haute pour ce mode sur le thermostat du radiateur, comme 27 par exemple, c’est bien ça ?
Une dernière chose également qui n’est pas claire pour moi.
Concernant la planification, dans ton example (Chambre Céline), on vois que la consigne varie entre 19.5 et 22.
Ma question est : Pourquoi ?
Pour mon usage, la consigne d’une pièce est constante lorsqu’elle est occupé (pièce a vivre ou bien chambre), soit un mode eco/confort avec une température pour chaque.
Ce que je ne comprend pas dans ton mode de fonctionnement, c’est comment une même pièce bascule entre ces 2 modes en fonction d’une plage horaires prédéfinie. C’est un peu flou.
Idéalement, j’aurais fait une seule planification « Auto » qui combine les différentes température (equivalent consigne eco/confort), et ensuite en fonction de la présence je bascule dans ce mode auto ou autre (manuel/absence avec une consigne spécifique). Et rajouter un mode off est hors-gel en plus.
Je ne voila pas l’intérêt ici d’une double planification, mais j’ai sûrement du rater un truc…
Hello,
Effectivement eco / confort devraient plutôt appelé absence / présence. L’absence est déclenchée quand l’alarme est mise ou les personnes hors de la maison. C’est typiquement une journée de travail versus une journée a la maison.
Mais un chauffage a une inertie : si on est absent, on ne peut attendre de rentrer a la maison pour chauffer. D’ou l’idée de chauffer quand même a une certaine heure en prévision du retour, en mode eco (absence).
Une manière basique (c’est juste pour illustrer) serait de faire la planification des température par plage horaire en mode confort. Puis de faire la même planification en mode eco avec 2 degrés de moins pour quand on est absent.
super merci beaucoup ! @djal moi aussi j’ai des capteurs Aqara, la remontée des données n’est effectivement pas réglable, mais par contre j’ai remarqué (confirmé par d’autres sur les forums anglo-saxons) que la fréquence d’update de l’état s’accélère quand la variation de température est supérieure à 0,5°C, donc a priori pour moi ça ne pose pas de pb dans le système d’@argonaute, en général chez moi la pièce prend + de 0,5°C en moins de 20mn donc en fonction de la durée de tes plages horaires (et de la taille de ta pièce j’imagine), ça doit pouvoir le faire non ?
Merci pour ce tuto, cependant je bloque car mes intégrations Heatzy sont considérées en Climate, et non en Switch.
Avez-vous une solution afin que puisse l’intégrer à ce blueprint ?
Malheureusement je n’ai pas de heatzy pour adapter le blueprint et tester. Je crains de ne pas être pertinent. Ce n’est pas aussi un thermostat, prenant en entrée une consigne ? Est t’il alors pertinent d’utiliser un tel thermostat pour juste piloter des on-off des radiateurs et déporter le thermostat dans HA ?
Si des personnes ayant un heatzy peuvent aider ou apporter un avis.
lors de l’ajout de la carte à l’étape 4. la carte lovelace et en copiant collant le code fourni, j’ai tout de suite une erreur qui s’affiche :
Custom element doesn't exist: button-card.
type: custom:button-card
color: '#D1DBAE'
name: Salon
styles:
card:
- background-color: '#E2E2E2'
- height: 25px
name:
- font-size: 18px
je précise que je suis un gros débutant, je l’ajoute depuis le menu Aperçu, puis ajouter une carte et je colle le code. j’ai du rater une étape ?
j’ai installer le « button-card » depuis HACS pourtant.
Bonjour, le tuto est vraiment top, mais comme ripus très gros débutant je viens de jeedom.
J’ai également custom element dosn’t exist: hui-element, et button-card même chose
Ya du boulot avec moi
