Gestion de bout en bout du chauffage

1. Le chauffage dans Home Assistant

S’il y a un domaine source de confort et d’économie dans une maison domotisée, c’est bien le chauffage. Home Assistant est un système domotique incroyable, offrant énormément de possibilités. Et pourtant, le sujet du chauffage est plutôt mal traité (pour l’instant).

Un thermostat générique (intégration et carte lovelace) est proposé par HA pour piloter un chauffage en ON-OFF, mais il est de type hystéresis : il chauffe a 100% jusqu’a atteindre la température + un seuil, puis arrête. Le convecteur sera alors soit bouillant, soit froid, ce qui crée des oscillations de température et des chaud-froid inconfortables, et cela consomme plus. C’est probablement adapté aux climatiseurs réversibles américaines mais pas du tout à nos convecteurs et autres modes de chauffage. La température extérieure n’est même pas prise en compte, pas plus que la coupure du chauffage quand une fenêtre est ouverte.

De plus, il n’y a pas de gestion des plages horaires permettant de définir les périodes de chauffe. Il faut alors faire appel à des intégrations de la communauté, ou alors pour les plus courageux tout redévelopper avec des automatisations et champs inputs (oups !!). Les 2 principales intégrations sont schedy et le scheduler. Schedy est un daemon qui permet de planifier dynamiquement des événements, mais bien que très puissant il n’a pas d’interface et son intégration est relativement complexe. Je vous proposerai d’utiliser l’autre intégration : le scheduler.

Pour gérer les différents modes, par exemple pour moduler la température sur les périodes de présences et absences, il n’y a donc pas d’autres choix que de redévelopper des automations. Se pose alors le choix entre node red ou les automatisations HA. Les 2 méthodes se discutent et ont chacune leurs avantages et inconvénients. Personnellement j’utilise les 2 : node red pour les flux (http et mqtt en particulier) ou pour bénéficier de nœuds spécifiques, et les automatisations HA pour la manipulation d’entités et des logiques type si-alors. L’avantage de ce dernier choix est d’être très bien intégré à HA, d’avoir avec les traces une capacité de contrôler ce qui se passe (mis en place depuis 2 mois et très puissant), d’avoir une forme YAML compact et facilement partageable. Mais un gros avantage est l’utilisation de blueprints : une automatisation de chauffage est créée dans un modèle, puis réutilisée pour chaque radiateur ou pièce de la maison. C’est ce que je vous propose d’utiliser ici.

2. Proposition d’implémentation

L’article qui suit propose de mettre en place :

  • Un thermostat de type TPI (Time Propostional & Integration) basé sur les températures intérieure et extérieure, avec arrêt quand une fenêtre est ouverte.
  • Une gestion des modes : auto-confort, auto-éco, manuel, hors gel, arrêt, absences.
  • Une gestion des plages horaires pour les modes auto-confort et auto-eco.
  • Une carte basique permettant de gérer le tout, dont l’affichage de la puissance en cours.

J’utilise ce type de thermostat TPI pour 8 convecteur et depuis 5 ans (avec une autre box) et c’est vraiment très performant, avec une chaleur très douce de la pièce et des radiateurs, sans grandes variations.

3. Le thermostat TPI

L’objectif du thermostat est de calculer une puissance de chauffe en fonction d’une consigne donnée, de la température intérieure et de la température extérieure. La puissance doit être de 100% quand la température de la pièce est loin de la consigne, puis baisser doucement jusqu’à atteindre la consigne. Ensuite le radiateur doit rester légèrement tiède pour compenser les pertes thermiques, ce en fonction de la température extérieure.

Le calcul de la puissance en %, est assuré par la formule :

Puissance = coeff_c * (T consigne - T intérieure) + coeff_t * (T consigne - T extérieure)

avec un min a 0% et un max a 100%

  • coeff_c est un coeff qui dépend de la puissance du chauffage et de la surface.

  • coeff_t dépend lui de l’isolation de la pièce et des pertes thermiques.

Pour une installation standard au norme on a coeff_c = 0,6 et coeff_t = 0,01

Exemple : Tint = 19°C Text = 10°C et consigne a 20°C alors puissance = 70%

Le fait de considérer la température extérieure est donc indispensable pour compenser les pertes de chaleur et garder une température très constante, ce qui n’est pas assuré par le thermostat standard de HA.

Ensuite il faut transformer la puissance calculée en une séquence de ON-OFF de notre chauffage.

L’implémentation proposée ici est pour des convecteurs avec un fil pilote (Qubino). Mais une adaptation est possible pour d’autres types de chauffage.

Pour nos convecteurs, la puissance nécessaire est recalculée toutes les 10 mn, ce qui donne le temps de marche sur la période. Avec une puissance calculée de 70%, le convecteur sera alors sur ON 7mn puis sur OFF 3mn.

La périodicité dépend de l’inertie : 30mn à 1 heure pour une chaudière, 10mn pour un convecteur on/off (fil pilote). Pour un poêle a granule, la puissance devrait être recalculée toutes les 30mn par exemple.

Le thermostat prend en charge la fenêtre et il coupe le radiateur quand cette dernière est ouverte.

Le code du thermostat est dans un blueprint. Pour l’utiliser, il faut sauver le code dans un fichier (thermostat_tpi.yaml) sous \config\blueprints\automation. Ensuite une automatisation « thermostat » peut être facilement pour chaque radiateur (j’en ai 8 à la maison).

La puissance et la consigne sont dans des input number définis spécifiquement et utilisés dans la carte lovelace. Les 2 températures sont dans des sensors et la fenêtre un binary sensor. Enfin le radiateur est piloté par un switch.

La création ou édition d’un nouveau thermostat revient alors à renseigner les paramètres suivants :

Si on a des radiateurs avec vanne thermo (pas en mode ON OFF mais injection de la puissance), il faudrait reprendre le calcul de puissance et le blueprint devrait être adapté.

Voici le code du blueprint thermostat

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: "/10"
  - 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 * 6 }}'
  - 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
 

4. La carte lovelace

Une carte assez basique permet de visualiser pour chaque radiateur le mode de chauffage, la température de consigne, de la pièce, la puissance et l’état de la fenêtre.

Elle remplace la carte thermostat de HA.
image

Voici les différents modes proposés (champs de type input select):
image

  • Mode « auto-confort » : quand la pièce est occupée. Ajuste automatiquement la température suivant des plages horaires définies dans le scheduler (planification « auto-confort »)

  • Mode « auto-eco » : quand la pièce est inoccupée (par exemple la semaine ou quand l’alarme est mise). Ajuste automatiquement la température suivant des plages horaires défini dans le scheduler (planification « auto-eco »)

  • Mode « manuel » : la consigne est gérée manuellement et non par une planification du scheduler. Dans ce mode, la carte affiche une ligne supplémentaire permettant d’ajuster la consigne.

  • Mode « hors gel » : règle la consigne sur une température donnée (en fait 10°C pour moi)

  • Mode « stop » : tout est arrêté, y compris le thermostat. C’est le mode été.

  • Mode « absent » : n’est pas censé être sélectionné manuellement, mais automatiquement mis quand une personne est absente et que le chauffage était en CONFORT. Met alors le chauffage en mode ECO. Le fait d’avoir un état dédié permet de remettre en CONFORT quand la pièce est de nouveau occupée.

La carte utilise plusieurs cartes de la communauté, qu’il faut installer au préalable : button-card, hui-element et number-box.
https://www.home-assistant.io/lovelace/button/
https://github.com/thomasloven/lovelace-hui-element
Input Number - Home Assistant (home-assistant.io)

Voici le code de la carte

type: entities
entities:
  - type: 'custom:button-card'
    color: '#D1DBAE'
    name: Salon
    styles:
      card:
        - background-color: '#E2E2E2'
        - height: 25px
      name:
        - font-size: 18px
  - entity: input_select.chauffage_salon_mode
    name: Mode
  - type: conditional
    conditions:
      - entity: input_select.chauffage_salon_mode
        state: Manuel
    row:
      entity: input_number.chauffage_salon_consigne
      type: 'custom:numberbox-card'
      name: Réglage consigne
  - type: 'custom:hui-element'
    card_type: glance
    show_name: false
    style: |
      ha-card {
        background: var(--background-card-color);
        box-shadow: none;
        font-size: 20px;
        top: -10px;
        margin: -20px
      }
    entities:
      - entity: sensor.oregon_thermometre_salon_temperature
      - entity: input_number.chauffage_salon_consigne
      - entity: input_number.chauffage_salon_puissance
      - entity: binary_sensor.aqara_fenetre_salon_onoff
        icon: 'mdi:window-closed-variant'

5. La planification (scheduler)

La planification est basée sur le scheduler proposé dans HACS, composé d’un composant et une carte.
https://community.home-assistant.io/t/scheduler-card-custom-component/217458

Une vue principale permet de voir les différents thermostats. L’interface présentée ici est pour un mobile. L’entête de la vue a un icone « outils » à sa droite qui permet d’accéder à une deuxième vue de réglages des radiateurs, qui contiendra alors la scheduler card.

La vue réglage contient une seule scheduler card affichant la planification de tous les radiateurs.

Chaque radiateur a 2 planifications : une CONFORT et une ECO. Malheureusement, la scheduler card les affichent ici dans le désordre (en fait en fonction des plages horaires).

image

La planification sera bien entendue active ou non en fonction du mode choisi dans le thermostat. La température de consigne va automatiquement changer en fonction de l’heure et du programme quand la planification est activée (le scheduler gère cela automatiquement pour nous).

Il est possible si on est administrateur d’éditer chaque planification, puis sélectionner la température de consigne par plage horaire

Voici le code de l’implémentation de la scheduler card

type: 'custom:scheduler-card'
include:
  - input_number.chauffage_*_consigne
time_step: 15
title: ''
show:
  labels: true
  labels_secondary: false
display_options:
  primary_info: name
  secondary_info: ' '
style: |
  .card-header {
    font-size: 18px;
  }
discover_existing: false

Une fois la carte scheduler créée, elle est vide. Il faut utiliser l’interface pour créer les différentes planifications (type schema - 2 planifications : auto-eco et auto-confort pour chaque radiateur).

Ci-dessous également le code du bandeau d’entête de la vue principale, avec l’icone pour accéder à la vue de paramétrage.

type: 'custom:vertical-stack-in-card'
horizontal: true
cards:
  - type: 'custom:button-card'
    color: '#D1DBAE'
    icon: 'mdi:close'
    styles:
      card:
        - height: 40px
        - width: 50px
        - padding: 0px 0px
        - background-color: '#FFC0BF'
      icon:
        - left: 8px
        - width: 70%
        - color: var(--primary-text-color)
    tap_action:
      action: navigate
      navigation_path: accueil
  - type: 'custom:button-card'
    name: Chauffage
    color: '#D1DBAE'
    styles:
      card:
        - height: 40px
        - padding: 0px 0px
        - background-color: '#FFC0BF'
      icon:
        - left: 10px
        - width: 18%
        - color: var(--primary-text-color)
      name:
        - position: absolute
        - left: 22px
        - top: 10px
        - font-size: 20px
  - type: 'custom:button-card'
    color: '#D1DBAE'
    icon: 'mdi:tools'
    styles:
      card:
        - height: 40px
        - width: 50px
        - padding: 0px 0px
        - background-color: '#FFC0BF'
      icon:
        - left: 10px
        - width: 55%
        - color: var(--primary-text-color)
    tap_action:
      action: navigate
      navigation_path: chauffage-config

6. L’automatisation des modes

La sélection du mode doit activer ou désactiver les 3 automatisations : thermostat (notre premier blueprint), auto-confort et auto-eco (les 2 automatisations créées par le scheduler). La consigne est changée pour une valeur en dure si le mode n’est pas auto-eco ou auto-confort (par exemple pour le hors-gel).
Pour ce faire, une dernière automatisation, codée également dans un blueprint, permet de prendre en charge cette sélection du mode par chaque radiateur. Elle prend en entrée le mode de chauffage désiré, la consigne et les 3 automatisations à piloter (thermostat, auto-confort et auto-eco).

Point important : comme déjà évoqué, si par exemple on passe du mode confort au mode eco, le scheduler ajuste automatiquement la consigne en fonction de sa planification et de l’heure qu’il est. Cela permet de se passer d’un deamon dynamique comme shedy.

Enfin le thermostat met la consigne à 0 si la fenêtre est ouverte, et remet la bonne valeur une fois fermée.

Voyons maintenant chacun des modes, et comment le changement de mode active ou désactive les 3 automatisations thermostat, auto-confort, auto-eco :

Mode "auto-confort"

  • Automatisation thermostat : ON
  • Automatisation auto-confort : ON
  • Automatisation auto-eco : OFF

Mode "auto-eco"

  • Automatisation thermostat : ON
  • Automatisation auto-confort : OFF
  • Automatisation auto-eco : ON

Mode "Hors-gel"

  • Automatisation thermostat : ON
  • Automatisation auto-confort : OFF
  • Automatisation auto-eco : OFF
  • Consigne forcée à 10°C (bon un peu plus qu’un hors gel…"

Mode "Manuel"

  • Automatisation thermostat : ON
  • Automatisation auto-confort : OFF
  • Automatisation auto-eco : OFF

Mode "Arrêt"

  • Automatisation thermostat : OFF
  • Automatisation auto-confort : OFF
  • Automatisation auto-eco : OFF
  • Consigne et puissance a 0.

Mode "Absence"

  • Automatisation thermostat : ON
  • Automatisation auto-confort : OFF
  • Automatisation auto-eco : ON

Le thermostat fonctionne en ECO. Le mode absence n’est pas censé être activé manuellement, mais automatiquement par la détection d’une absence (l’alarme mise dans mon cas).

Voici le code du blueprint de gestion des modes.

blueprint:
  name: Pilotage chauffage
  description: Gestion des différents modes de chauffage - Stop  Hors-gel  Auto confort Auto eco 
  domain: automation

  input:
    entity_consigne:
      name: Consigne
      description: Champs d'entrée de la température de consigne (input number).
      selector:
        entity:
          domain: input_number
    entity_mode:
      name: Sélection du mode
      description: Entité de gestion du mode de gestion du chauffage (input_select)
      selector:
        entity:
          domain: input_select
    entity_schedule_confort:
      name: Schedule mode confort
      description: Entité générée par schedule pour la planification du mode confort (switch)
      selector:
        entity:
          domain: switch
    entity_schedule_eco:
      name: Schedule mode eco
      description: Entité générée par schedule pour la planification du mode eco (switch)
      selector:
        entity:
          domain: switch
    entity_thermostat_tpi:
      name: Thermostat
      description: Entité de gestion du thermostat TPI (automation)
      selector:
        entity:
          domain: automation


# Température pour le hors gel
variables:
  temperature_hg: 10

alias: Pilotage chauffage bureau Patrick
description: ''
trigger:
  - platform: state
    entity_id: !input entity_mode
condition: []
action:
  - choose:
      # ----- Mode Stop
      - conditions:
          - condition: state
            entity_id: !input entity_mode
            state: Stop
        sequence:
          - service: input_number.set_value
            data:
              value: 0
            target:
              entity_id: !input entity_consigne
          - service: switch.turn_off
            target:
              entity_id:
                - !input entity_schedule_eco
                - !input entity_schedule_confort
          - service: automation.turn_off
            target:
              entity_id: !input entity_thermostat_tpi
      # ----- Mode Hors-gel
      - conditions:
          - condition: state
            entity_id: !input entity_mode
            state: Hors-gel
        sequence:
          - service: automation.turn_on
            target:
              entity_id: !input entity_thermostat_tpi
          - service: input_number.set_value
            data:
              value: '{{temperature_hg}}'
            target:
              entity_id: !input entity_consigne
          - service: switch.turn_off
            target:
              entity_id:
                - !input entity_schedule_eco
                - !input entity_schedule_confort
      # ----- Mode Auto - confort
      - conditions:
          - condition: state
            entity_id: !input entity_mode
            state: Auto - confort
        sequence:
          - service: automation.turn_on
            target:
              entity_id: !input entity_thermostat_tpi
          - service: switch.turn_on
            target:
              entity_id: !input entity_schedule_confort
          - service: switch.turn_off
            target:
              entity_id:
                - !input entity_schedule_eco
      # ----- Mode Auto - eco ou absent
      - conditions:
          - condition: or
            conditions:
              - condition: state
                entity_id: !input entity_mode
                state: 'Auto - eco'
              - condition: state
                entity_id: !input entity_mode
                state: 'Absent'
        sequence:
          - service: automation.turn_on
            target:
              entity_id: !input entity_thermostat_tpi
          - service: switch.turn_off
            target:
              entity_id:
                - !input entity_schedule_confort
          - service: switch.turn_on
            target:
              entity_id: !input entity_schedule_eco
    # ----- Mode manuel
    default:
      - service: switch.turn_off
        target:
          entity_id:
            - !input entity_schedule_eco
            - !input entity_schedule_confort
      - service: automation.turn_on
        target:
          entity_id: !input entity_thermostat_tpi
mode: single

7. Gestion des absences

J’utilise actuellement le marche-arrêt de l’alarme pour détecter les absences. Pour information, j’ai une alarme MyFox qui voit HA comme un actionneur 433MHz (type Chacon). Cela permet d’avertir HA quand l’alarme est mise ou enlevée sans avoir à passer par une API web…

La gestion de l’alarme est :

  • Si alarme mise, mettre dans les chauffages qui sont en auto-confort en absence.
  • Si alarme enlevée, mettre dans les chauffages qui sont en absence en auto-confort.

L’automatisation n’a pas été reportée ici, mais elle est basique. Il est également possible de gérer la présence de chaque membre de la famille pas son portable.

9. Pour aller plus loin

Le problème d’un pilotage de convecteur par fil pilote est qu’il n’y a pas de mesure de consommation. Avec notre thermostat, il est facile de mettre en place un tempate sensor qui multiplie la puissance calculée par la puissance du radiateur. Ne reste plus qu’à intégrer cela avec un utility meter. Cela peut se faire avec d’autres modes de chauffage comme les granules.

Enfin, le bon fonctionnement des thermostats implique le bon fonctionnement des sondes. Avec mon ancienne box, j’avais un « sanity check » toutes les 2 heures pour vérifier que les sondes rafraichissaient toujours bien leurs données. Le chauffage coute trop chère pour ne pas avoir ce type de vérification, et ne pas se contenter de la vérification de la pile des capteurs…

6 J'aime

Super mais n’ayant pas assez de connaissance j’ai ce message d’erreur et je ne comprend pas pourquoi

Citation
2021-06-02 21:48:17 ERROR (MainThread) [homeassistant.components.automation] Blueprint Thermostat TPI generated invalid automation with inputs OrderedDict([(‹ coeff_c ›, 0.6), (‹ coeff_t ›, 0.01), (‹ entity_consigne ›, ‹ input_number.consigne ›), (‹ entity_temp_ext ›, ‹ sensor.ds18b20_2_temperature_2 ›), (‹ entity_temp_int ›, ‹ sensor.cuisine ›), (‹ entity_fenetre ›, ‹ input_boolean.fenetre_ouverte ›), (‹ entity_chauffage ›, ‹ input_boolean.marche_thermostat ›), (‹ entity_puissance ›, ‹ input_number.puissance_thermostat ›)]): extra keys not allowed @ data[‹ action ›][2][‹ default ›][2][‹ target ›][‹ mode ›]. Got None

Hello,

Le blueprint devrait prendre en entrée les mêmes types que ceux définis dans le code : binary sensor pour la fenêtre et switch pour le chauffage en sortie. Tu utilises des input boolean et le pb doit venir de la. Les services appelés par le script sont spécifiques a ces types.

Il faudra vérifier ensuite que toutes les entités utilisées en entrées retournent bien des valeurs correctes et ne sont pas indéfinies ( les 2 températures, la consigne, l’etat de la fenêtre).

Pourtant ça m’a l’air d’être ok

Salut Argonaute,

Un seul mot : Bravo & Super
Quel beau tuto !!!

1 J'aime

Pour les paramètres que je vois, oui, Je ne vois pas l’actionneur du chauffage. Est ce bien un switch ?

Est ce que toutes les entités en entrée renvoient bien des valeurs correctes (les 2 températures, la consigne et fenêtre) ? Il faut vérifier avec lovalace ou dans l’outil développeur.

Le log indiquait des input boolean pour la fenêtre et le switch du chauffage. J’imagine que tu as changé. Quelle erreur as tu maintenant ?

Voici les derniers logs

Citation * Blueprint Thermostat TPI generated invalid automation with inputs OrderedDict([(‹ coeff_c ›, 0.62), (‹ coeff_t ›, 0.01), (‹ entity_consigne ›, ‹ input_number.consigne ›), (‹ entity_temp_ext ›, ‹ sensor.ds18b20_2_temperature_2 ›), (‹ entity_temp_int ›, ‹ sensor.xavier ›), (‹ entity_puissance ›, ‹ input_number.puissance_thermostat ›), (‹ entity_chauffage ›, ‹ switch.tasmota3 ›), (‹ entity_fenetre ›, ‹ binary_sensor.door ›)]): extra keys not allowed @ data[‹ action ›][2][‹ default ›][2][‹ target ›][‹ mode ›]. Got None

Et le switch

Merci de ton aide

Steph

Merci pour ce partage @Argonaute.
J’ai des personnes de mon entourage qui ont tado ou netatmo quand ont regarde le prix est assez conséquents mais garantie une compatibilité avec des tête de chauffe thermostatique.

S’en suit pour moi une suite de question logique dans ce sens concernant les avantages et/ou inconvénient d’un système face aux autres comme peut-on panaché les tête thermostatique si l’on part sur un thermostat ou un autres et l’intégration possible ou non avec HA.

J’aimerai me lancer du coter chauffage bientôt et je partage ton avis le chauffage est une source de dépense conséquente chaque année non négligeable et ce forum non sponsorisé par une marque ou une autres serait un bon terrain neutre pour faire la lumière.

Merci encore pour ce partage pharaonique🙂

Merci @Felix62.
La question récurrente est toujours de soit refaire dans home assistant avec n composants, soit s’adosser à des écosystèmes comme netatmo, nest ou todo, souvent super bien fait et avec une UX irréprochable.

Il y a à mon sens 4 enjeux principaux :

  1. intégrer les différents système (mettre en eco le chauffage quand on met l’alarme par exemple ou qu’une personne est absente).
  2. avoir une interface centralisée et non une gestion dans n applis
  3. et pour le chauffage avoir une gestion fine de la gestion de chaque pièce séparément, avec une sonde de température bien placée et une détection d’ouverture des fenêtres.
  4. enfin avoir malgré tout un système fiable et facile à utiliser

Tout dépend de sa sensibilité, son budget, du temps à allouer et bien entendu du matériel à intégrer. Il y a toujours beaucoup de solutions, et encore plus avec Home Assistant qu’avec d’autres systèmes.

1 J'aime

Bon il faut trouver ! Le pb intervient à la création de l’automatisation et non son utilisation, n’est ce pas ?
Le log semble indiquer qu’une des entrées du blueprint est invalide. Je confirme que tes types sont bons cette fois.

Il faudrait dans une premier temps reprendre l’id de chaque entité utilisée, et le coller dans le champs entité, dans outils de développement - état, et vérifier que chaque ID est bon et retourne un état correcte : des températures pour les 2 sensors, un on-off pour le binary-sensor du capteur de la fenêtre et pour le switch, un nombre pour la puissance.

Salut @Argonaute,

Merci beaucoup pour le temps consacré au partage de ton travail !
C’est vraiment appréciable d’avoir cet état d’esprit, c’est exactement ce qu’il faut pour faire vivre un forum

Je vais lire l’ensemble plus en détail ton tuto (que j’ai simplement survolé pour le moment pour être honnête) mais il me semble que mon cas n’est pas traité.

En effet, j’ai l’objectif de connecter ma pompe à chaleur à Home Assistant dont l’objectif serait qu’Home Assistant gère la consigne de température d’eau du circuit de mes planchers chauffant.

L’objectif est de pouvoir prendre en compte la météo et ainsi anticiper les changements, surtout pour les phases « Temps nuageux » vers « Temps ensoleillé » où il serait ineteressant de désactiver à l’avance le planché chauffant du fait de son inertie. Cela irait dans le sens des économies mais aussi celui du confort en limitant un overshoot de température.

1 J'aime

Argonaute, oui l’automation du coup n’est pas créé
Pour moi tout est normal
image
image
image
image
image
image

Je dois passer à coté de quelque chose du coup !

Hello @Steph_Flo,
Effectivement, tout bon côté entité effectivement. Par contre, je viens de voir que tu es en format décimal avec des virgules (format français par défaut) et moi des points (je suis en format suisse). Il faudrait que tu essaies de mettre des virgules dans le blueprint.

Bonsoir en utilisant file editor j’ai cette erreur
unknown tag !<!input> at line 65, column 28:
coeff_c: !input ‹ coeff_c ›

C’est pareil chez tous ?

Hello,
Bon après quelques échanges en direct avec @Steph_Flo, nous avons eu confirmation que le pb venait bien des points a la place des virgules dans les valeurs numériques du blueprint.

Normalement les blueprints devraient être interopérables, et donc non sensibles aux formats des nombres. Je vais creuser le partage des blueprint, mais si quelqu’un a déja un élément de réponse sur ce sujet…

Merci d’avoir partagé cet élément de réponse. Cependant je ne sais pas répondre.