Automatisation du Chauffage....version "Basique"

[YvanLeTerrible]

Salut -
je donne ici une petite variante pour une gestion « centralisée » de plusieurs « radiateurs »
rendons a césar… c’est tiré de l’excellent tuto de « Argonaute » - GG - UN GRAND MERCI A LUI !!!
Gestion de bout en bout du chauffage
que j’ai "choisi"de simplifier pour coller a mon besoin, plus modeste en terme de fonctions (mode éco …)
(euh - en fait c’est un peu aussi parce j’ai pas tout compris / reussi a tout refaire …)

bref
bien basé sur Plusieurs Thermostats TPI (voir sont Tuto !!!) - très très bon Blueprint - simples et efficace
chaque thermostat a sa consigne et sa régulation individuelle

a partir de la, mon besoin était : un « Mode général » (OFF , AUTO ou Manuel) (input_select.tpi_general)

• Une consigne « master Température générale » input_number.tpi_consigne_home
  … pilotée par un planning Scheduler (ou plusieurs : ex : 1 profil semaine, et 1 profil Weekend)
  
  
  
  … Propagée vers les régulateurs suivant le besoin

Donc ça donne 2 Automatismes : pour controler l’ensemble
1 pour Arreter Tous les Thermostats si le Mode Général est « OFF » (assez simple, automatisation basique - je détaille pas)
1 (plus rusé - code ci dessous) Pour intercepter tout changements de la « Master temp » (qu’il soit fait manuellement ou généré par le Scheduler)
ET - quand on est en mode AUTO - LE PROPAGER dans Chaque Variable « consigne TPI » (mais ça peut être aussi vers des entités climate Standard) ==>> donc la , faut lister tous les TPI concernés !!!

L’idée c’est que - en mode AUTO - même si un petit malin règle son thermostat a l’occasion, La consigne générale reprends le dessus au prochain changement planifié

• bon, je sais c’est discutable (et un peu hégémonique) et un fonctionnement plus « user friendly » serait de définir les modes Auto ou manu pour chaque « Pièce » par exemple - mais bon, dans mon cas j’ai décidé (un peu pour me simplifier la vie) que j’en avais pas besoin. Et si j’ai besoin, je peux quand même désactiver ou activer chaque « TPI » (par son automatisme)

euh, …faudrait peut être que je me rajoute une automatisation pour Rallumer tous les les thermostats quand je repasse de OFF sur AUTO ? - on y pensera…

Ci dessous l’automatisme qui assure la « Propagation » de la variable Master vers les autres variables
(Utilisation de l’event state_changed, et du « Data_Template » sur le service: input_number.set_value

alias: TPI_MasterTemp_Propagate
description: Propagation de la tempetature Principale aux TPI
trigger:
  - platform: event
    event_type: state_changed
    event_data:
      entity_id: input_number.tpi_consigne_home
condition:
  - condition: state
    entity_id: input_select.tpi_general
    state: AUTO
action:
  - data_template:
      value: '{{states.input_number.tpi_consigne_home.state }}'
    entity_id: input_number.tpi_consigne_bureau
    service: input_number.set_value
  - data_template:
      value: '{{states.input_number.tpi_consigne_home.state }}'
    entity_id: input_number.tpi_consigne_alex
    service: input_number.set_value
  - data_template:
      value: '{{states.input_number.tpi_consigne_home.state }}'
    entity_id: input_number.tpi_consigne_c_y
    service: input_number.set_value
mode: single

[Haz]

Super!
Je viens de voir un ordre d’instruction que je ne connaissais pas…
Je mettais systématiquement les actions dans l’ordre:

  - service: input_number.set_value
    target:
      entity_id: input_number.pw_cmd1
    data:
      value: '{{ P1 }}'

Sinon il va falloir que je partage, moi aussi, ce que j’ai fait du blueprint d’Argonaute…
De mon coté, j’ai réparti une puissance commandée totale vers les 3 radiateurs d’une même pièce.
L’automatisation peux les allumer alternativement ou deux par deux quand la puissance totale est faible.

[YvanLeTerrible]

oui, Le chauffage est un très bon terrain de jeu (surtout en hiver)
et n’hésite pas a parager si tu a des codes « exotiques »

c’est d’arriver a faire marcher le data_template qui m’a permis d’avancer

d’après toi j’aurais pu faire : qqchose comme ?

  - service: input_number.set_value
    target:
      entity_id: input_number.consigne_temperature_cible
    data:
      value: '{{ states.input_number.tpi_consigne_home.state }}'    # peut être besoin de rajouter un | float ?

ou alors il faudrait que je comprenne mieux : Templating

bref, je suis pas sorti des ronces si je veux faire des trucs encore plus « sophistiqués »

[Haz]

Salut

je me suis mis au templating dans la douleur voir un exemple que j’ai partagé ici pour des réponses à la messagerie Telegram:
https://forum.hacf.fr/t/utilisation-de-telegram-plusieurs-commandes-dans-un-seul-trigger/8015

Depuis, j’ai utilisé des variables que je calcule en début d’automatisme comme dans l’exemple que je donne ci dessus.

- id: Top_synchro_rad
  alias: Top_synchro_rad
  description: 'Lancement de la synchro des radiateurs'
  trigger:
  - platform: time_pattern
    minutes: "/5" 
  action:
  - variables: 
      Pcmd:   '{{ states("input_number.PW_cmd_totale") }}'
      P1: |
        {% if  Pcmd <100  %}
          {% set P =  0 %}
        {% elif  Pcmd <500  %}
          {% set P =  Pcmd %}
        {% elif  Pcmd <900  %}
          {% set P =  Pcmd / 2 %}
        {% else  %}
          {% set P =  Pcmd / 3 %}
        {% endif  %}
        {{ P }}
  - service: input_number.set_value
    target:
      entity_id: input_number.pw_cmd1
    data:
      value: '{{ P1 }}'

Dans ton cas, je me demande si tu ne pourrais pas factoriser encore plus car la variable que tu veux faire passer aux 3 thermostat est la même?
Par exemple, est ce que cela fonctionne?

action:
  - data_template:
      value: '{{states.input_number.tpi_consigne_home.state }}'
    entity_id: 
      - input_number.tpi_consigne_bureau
      - input_number.tpi_consigne_alex
      - input_number.tpi_consigne_c_y
    service: input_number.set_value

En effet, quand je regarde la description de input number, je vois:

Input Number

C’est à dire que plusieurs entitées peuvent être mise à jour avec la même valeur…