[Article] Gestion de bout en bout du chauffage (archive)

La subtilité de ce blueprint est d’activer et désactiver les automatisations générées par le scheduler en fonction du mode de chauffage choisi. Le pb vient probablement d’un mauvais nom d’une des entités automatisation générée par le scheduler et entré en paramètre du blueprint quand il est utilisé.
Il faut donc retrouver le nom des automatisations générée par le scheduler pour ensuite les entrer en paramètre.

Pour information, le nom des automatisations générées par le scheduler peuvent être personnalisées : aller dans le scheduler, ouvrir l’automatisation, cliquer sur option puis changer le nom. L’ID de l’entité automatisation générée ensuite peut se retrouver par une recherche dans configuration / automatisation.

Je pense avoir compris le principe mais j’ai l’erreur au niveau du Blueprint alors que je n’ai pas encore crée l’automatisation. :thinking:

Edit: j’ai nettoyé manuellement le fichier automation.yaml et recrée l’automatisation à partir du blueprint modifié et tout est OK.

J’ai modifié le Blueprint d’ @Argonaute en remplaçant le détecteur d’ouverture de la fenêtre par un input_boolean (entity_onoffchauffage).
Je pense que je n’ai pas trouvé la bonne syntaxe pour récupérer son état car le switch n’a aucun effet.
Un peu d’aide serait la bienvenue.

J’ai crée le boolean comme ça :

switch_chauffage_salon:
  name: Interrupteur Chauffage Salon
  initial: off
  icon: mdi:toggleswitch

et le blueprint ainsi :

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 la 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_onoffchauffage:
      name: Interrupteur marche / arrêt du chauffage
      description: On/Off Chauffage
      selector:
        entity:
          domain: input_boolean
    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 radiateur (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_onoffchauffage: !input entity_onoffchauffage

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_onoffchauffage

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) }}'
      onoffchauffage: "{{states(entity_onoffchauffage)}}"
      puissance: >-
        {%set val = coeff_c * (consigne - temp_int) + coeff_t * (consigne -
        temp_ext) %}  {% if val > 1 %} {% set val = 100 %}  {% elif val < 0 or
        onoffchauffage == 'off' %} {% 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_on
            target:
              entity_id: !input entity_chauffage
      - conditions:
          - condition: template
            value_template: '{{ puissance > 99}}'
        sequence:
          - service: switch.turn_off
            target:
              entity_id: !input entity_chauffage
    default:
      - service: switch.turn_off
        target:
          entity_id: !input entity_chauffage
      - delay: '{{temps_chauffe}}'
      - service: switch.turn_on
        target:
          entity_id: !input entity_chauffage
mode: restart

Merci d’avance.

Hello,
Le input_boolean retourne true/false et non on/off. A priori c’est pour ça que la condition ne change pas.
Tu peux vérifier les templates utilisés dans outil de développement / modèle.

Hou la ! … Tu me parles en chinois là !!!

Désolé message parti trop vite et je viens de le modifier.

Dans Outils de développement → Etats … , l’état du boolean renvoie bien On ou Off.

Ok effectivement.
Je peux encore vérifier le code de l’automatisation générée par le blueprint si jamais.

OK. Merci. ça fait 2 jours que je suis dessus et je vois pas le pb.

Je n’ai malheureusement pas pu reproduire le problème et la syntaxe semble bonne. Tu aurais du avoir des traces dans les logs autrement. Il faudrait tester la syntaxe jinja 2 dans ton environnement avec l’outil de développement / modèle.

Après, si tu n’as pas pour l’instant de capteur d’ouverture de fenêtre dans certaines pièces (capteur vu comme un switch) pour couper le chauffage quand une fenêtre est ouverte, tu peux en simuler un et ne pas modifier mon blueprint. Ainsi, le jour ou tu installes un capteur de fenêtre dans la pièce concernée, il n’y aura qu’à remplacer le switch simulé par celui du capteur.
Pour cela :

  • Créer un input_boolean (comme tu l’as fait), appelé « fenetre » dans mon exemple.
  • Créer en yaml un switch de type template basé sur cet input_boolean
  • Le switch peut ainsi être utilisé dans mon blueprint originel sans aucune modification

Voici le code pour créer le switch adossé à l’input_boolean.

switch:
  - platform: template
    switches:
      fenetre:
        value_template: "{{ is_state('input_boolean.fenetre', 'on') }}"
        turn_on:
          service: input_boolean.turn_on
          target:
            entity_id: input_boolean.fenetre
        turn_off:
          service: input_boolean.turn_off
          target:
            entity_id: input_boolean.fenetre

Si tu veux que le switch ne soit pas modifiable, et que seul l’état de l’input boolean modifie l’état du switch, ce code fonctionnera

switch:
  - platform: template
    switches:
      fenetre:
        value_template: "{{ is_state('input_boolean.fenetre', 'on') }}"
        turn_on:
        turn_off:

Mon but était simplement de remplacer le détecteur d’ouverture fenêtre par un input_boolean me permettant via celui-ci de couper manuellement le chauffage dans chaque pièce.

Je n’ai aucune erreur dans les logs mais l’état de l’input_boolean n’a aucun effet alors qu’il devrait dans un cas faire passer la puissance à 0.

Je vais essayer en utilisant ta proposition mais qui consiste (si j’ai bien compris) à créer un switch qui va agir sur l’input_boolean. J’ai du mal à saisir pourquoi il n’est pas possible d’agir directement sur l’input_boolean. :thinking:

Je ne comprends pas ton objectif : pour couper le chauffage, on met le mode (input select) a arrêt ou hors gel.

Pour ma part, l’input_select sera commun à toute les pièces ainsi je peux tout couper par l’input_select ou pièce par pièce par l’input_boolean.
J’ai essayé ta proposition, résultats identiques. Le switch est sur off pour autant puissance = 100

image

le pb semble être ici mais je ne le vois pas :

      puissance: >-
        {%set val = coeff_c * (consigne - temp_int) + coeff_t * (consigne - 
        temp_ext) %}  {% if val > 1 %} {% set val = 100 %}  {% elif val < 0 or 
        fenetre == 'off' %} {% set val = 0 %}  {% else %} {% set val = ( (val * 
        100) | round(0)) %} {% endif %} {{val}}

Effectivement, cela s’éloigne un peu de l’idée de base :smirk: Je pense qu’il faudrait mieux garder tous les thermostats indépendants, et avoir un script qui modifie leur état. C’est ce que je fais quand je met l’alarme et qui passe les thermostats en mode eco. Avoir des thermostats indépendants permet par exemple d’avoir une pièce inoccupée en mode eco et les autres en confort.

Autrement je crains un malentendu concernant le template fourni précédemment : as tu bien essayé de réutiliser mon code du thermostat TPI sans le modifier et en utilisant pour la fenêtre le switch que j’ai proposé ? Le template permet de remplacer le détecteur de type switch demandé par le blueprint vu que tu n’utilises pas de détecteur d’ouverture physique ?

Dans les traces que tu fournis, je vois que la fenêtre est à off. Quand tu modifies l’état du switch fenêtre, as tu bien « on » dans les traces pour la variable fenêtre ?

Enfin oui, le code de calcul de la puissance est bien dans code jinja 2 et c’est bien celui qu’il faudrait vérifier dans l’outil de développement. Mais il ne peut juste être collé et il faut l’adapter pour bien passer les valeurs des variables en entrée. Cela demande de relativement bien connaitre la syntaxe. Et sans l’outils de développement c’est souvent difficile de débogger des templates en jinja 2 :upside_down_face:

Effectivement, cela s’éloigne un peu de l’idée de base :smirk: Je pense qu’il faudrait mieux garder tous les thermostats indépendants, et avoir un script qui modifie leur état. C’est ce que je fais quand je met l’alarme et qui passe les thermostats en mode eco. Avoir des thermostats indépendants permet par exemple d’avoir une pièce inoccupée en mode eco et les autres en confort.

Je reverrai probablement ma position pour l’input_select, pour l’instant je ne traite q’une pièce avant de déployer pour les autres.

Autrement je crains un malentendu concernant le template fourni précédemment : as tu bien essayé de réutiliser mon code du thermostat TPI sans le modifier et en utilisant pour la fenêtre le switch que j’ai proposé ? Le template permet de remplacer le détecteur de type switch demandé par le blueprint vu que tu n’utilises pas de détecteur d’ouverture physique ?

Oui, c’est bien ce que j’ai fait.

Dans les traces que tu fournis, je vois que la fenêtre est à off. Quand tu modifies l’état du switch fenêtre, as tu bien « on » dans les traces pour la variable fenêtre ?

Oui.

J’ai tout recommencé depuis le debut et je vais devenir fou … :exploding_head:
J’ai copié ton code tu thermostat TPI en modifiant uniquement ça :

    entity_fenetre:
      name: Fenètre
      description: Capteur d'ouverture de fenêtre (sensor)
      selector:
        entity:
          domain: binary_sensor
          device_class: opening

Par ça, sinon je ne peux sélectionner le switch template :

    entity_fenetre:
      name: Fenètre
      description: Capteur d'ouverture de fenêtre (sensor)
      selector:
        entity:
          domain: switch

Pour l’entity_fenetre, je sélectionne bien le switch template. Et pour autant, l’état du switch n’a aucun effet : Fenetre sur ON et puissance à 100 ???
Par contre si la consigne est inférieure à la température, la puissance passe bien à 0 (voir dernière capture).



Dans le fichier automatisation.yaml, j’ai ça :

- id: '1632126984054'
  alias: Thermostat Salon 2
  description: ''
  use_blueprint:
    path: homeassistant/thermostat2.yaml
    input:
      coeff_c: 0.6
      coeff_t: 0.01
      entity_fenetre: switch.fenetre
      entity_consigne: input_number.consigne_salon
      entity_temp_ext: sensor.thgr810_thgn800_e9_0a_temperature
      entity_temp_int: sensor.thgn122_123_thgn132_thgr122_228_238_268_fa_02_temperature
      entity_puissance: input_number.puissance_radiateur_salon
      entity_chauffage: switch.pilot_wire_4

Je suis certain que je loupe un truc évident mais lequel ???

Je ne vois pas d’erreur. Si fenêtre ouverte, alors puissance forcée à 0. Si fenêtre fermée, alors puissance variant en fonction de la consigne. Tu n’as donc pas ça ?

Autrement, je m’aperçois que l’entrée du blueprint n’est pas un switch mais un binary sensor de type opening pour la fenêtre. Peux tu encore essayer de créer un binary sensor pour pouvoir ne pas avoir à modifier le blueprint thermostat TPI ?

Voici le code si jamais (change d’état en fonction du input boolean):

binary_sensor:    
  - platform: template
    sensors:
      fenetre:
        device_class: opening
        value_template: "{{ is_state('input_boolean.fenetre', 'on') }}"

Je ne vois pas d’erreur. Si fenêtre ouverte, alors puissance forcée à 0. Si fenêtre fermée, alors puissance variant en fonction de la consigne. Tu n’as donc pas ça ?

Non. Il semblerait que l’état du switch n’est pas du tout pris en compte.

Autrement, je m’aperçois que l’entrée du blueprint n’est pas un switch mais un binary sensor de type opening pour la fenêtre. Peux tu encore essayer de créer un binary sensor pour pouvoir ne pas avoir à modifier le blueprint thermostat TPI ?

Toujours pareil. J’ai copié/collé ton blueprint sans rien modifier.
La camisole n’est pas loin … :face_with_head_bandage:

Hello,
Peux-tu me préciser la correction que tu as faite ? (j’ai la même erreur que toi)
Merci

Je n’ai pas trouvé l’origine du problème. Pour couper le chauffage, je passe par l’input_select (mode arrêt ou hors gel).

Merci @Argonaute pour ce superbe boulot.
Concernant la planification Confort et Eco pour chaque radiateur, j’ai du mal à comprendre la différence sachant que dans le planificateur, on peut choisir sa consigne de température suivant l’heure et le jour.
As-tu un exemple ?