[Article] Gestion de bout en bout du chauffage

Lou_Juicy · Octobre 31, 2021, 1:52

Hello,

Avant j’utilisait des generic_thermostat pour piloter mes radiateurs Heatzy. Je viens de faire l’installation du blueprint et ça marche au top ! Personnellement, je préfère ne pas avoir de scheduler, je change juste le mode de chauffage avec des automations en fonction des absences, du mode nuit ou du réveil avec l’app HA.

Petite remarque au sujet de la récupération de la consommation. Est ce que ce ne serait pas plus simple de passer directement par un history_stats pour calculer la consommation ? J’ai peur que l’automatisation soit gourmande en performance.

Pas possible d’augmenter la température directement, on ne peut que changer le mode de chauffage via le fil pilote. Il suffit de faire un template switch (on: confort / off: eco) pour pouvoir utiliser le blueprint.

Dim33 · Octobre 31, 2021, 2:59

Je ne connais pas précisément le fonctionnement de Heatzy pilote.
Mais, pour ma part, mes radiateurs sont contrôlés par des Shelly 1 (On/Off par le fil pilote) et je possede des sondes de température dans chaque pièce. Ainsi je règle la température que je souhaite dans chaque pièces selon des plannings prédéfinis.

djal · Octobre 31, 2021, 5:08

@Lou_Juicy Salut,

Effectivement je ne connaissais pas history_stats, a voir, je vais y jeter un œil. A première vue ca me calculerait une durée de fonctionnement, qu’il faudra ensuite que je convertisse.

Pas sûr que ce soit plus pratique
Et il faut que ce soit à la seconde près, pour être aussi précis.

Les automations ne sont pas du tout gourmandes en perf, tu peux y aller

djal · Octobre 31, 2021, 5:11

@pierrekhyrd si la question c’est de savoir si tu peux « piloter » le thermostat du radiateur en direct, la réponse est non. tu peux piloter uniquement le changement de mode.

C’est bien là l’intérêt de ce sujet, c’est de déporter le thermostat du radiateur pour plus d’efficacité.

pierrekhyrd · Octobre 31, 2021, 9:49

@djal et @Lou_Juicy merci pour vos réponses . Avez vous un Blueprint en exemple où les votres pour que je l’adapte sur mon Heatzy, ça serait super. ( je commence tout juste sur HomeAssistant)
Bonne soirée à vous.

Lou_Juicy · Octobre 31, 2021, 10:30

Est ce que tu as déjà intégré un template switch ? Je ne sais pas si c’est possible via l’interface, mais tu peux regarder sur le lien plus haut pour voir la logique derrière.

Voilà le code que j’utilise pour piloter un radiateur heatzy.

- platform: template
  switches:       
    chauffage_palier:
      unique_id: chauffage_palier
      friendly_name: Palier
      value_template:  "{{ is_state_attr('climate.radiateur_palier', 'preset_mode', 'comfort') }}"
      icon_template: >-
        {% if is_state_attr('climate.radiateur_palier', 'preset_mode', 'comfort') %}
          mdi:radiator
        {% elif is_state_attr('climate.radiateur_palier', 'preset_mode', 'away') %}
          mdi:snowflake
        {% else %}
          mdi:radiator-disabled
        {% endif %}
      turn_on:
        service: climate.set_preset_mode
        entity_id: climate.radiateur_palier
        data:
          preset_mode: 'comfort'
      turn_off:
        service: climate.set_preset_mode
        entity_id: climate.radiateur_palier
        data:
          preset_mode: 'eco'

Argonaute · Octobre 31, 2021, 10:41

Point intéressant. Je ne connaissais pas history_stat.

Après, je me demande si il n’y aurait pas moyen d’utiliser différemment un utility meter, et si @djal comme moi ne partons pas sur une mauvaise méthode, respectivement trop complexe ou trop approximative.

On a la consommation instantanée exacte et à tout instant : c’est la puissance du radiateur si switch à on ou 0 si off. La puissance instantanée en W à tout instant peut être retournée simplement par un template sensor prenant en entrée le switch et la puissance du radiateur.
Puis on injecte cela dans un utility meter qui devrait nous faire correctement l’intégration pour obtenir des Wh : sauf erreur il ne recalcul théoriquement pas à intervalle régulier, mais quand la valeur d’entrée change. Donc il fera le calculs de temps lui, soit chaque fois que la puissance instantanée change.

Je n’ai pas testé. Mais un avis à ce sujet ? Est ce que ma compréhension du fonctionnement de l’utility meter serait bonne ?

Argonaute · Octobre 31, 2021, 10:54

Oui cela fonctionne. J’imagine que tu mets une température eco très faible et une température confort forte dans heatzy ? Mais sauf erreur, le heatzy fonctionne exactement comme le qubino avec les 4 modes : confort, eco, hors gel et arrêt. Il n’y a pas juste moyen de faire un on-off en passant de confort à arrêt, plutôt que de confort à eco ?

pierrekhyrd · Novembre 1, 2021, 9:28

Super merci, et tu mets ça danse configuration.yaml en changeant bien sûr le nom des climate. Par contre tu utilises le generic thermostat aussi ou pas ?

diyanei · Novembre 2, 2021, 8:28

Hello,

En s’inspirant de Energy monitoring in Home Assistant - with or without power meters avec les éléments déjà discutés, plutôt que faire des mises à jour de sensors et des cumuls dans des variables (comme le propose @djal, si je ne me trompe pas), effectivement, l’utilisation d’utility_meter semble être « the way to go », car dédié aux mesures de puissance.
Je suis en train de tester, mais j’ai l’impression que la façon suivante permet de faire un calcul de puissance consommée journalière/mensuelle.

Pour chaque radiateur, ajouter deux sensors dans la conf:

- platform: template
  sensors:
    puissance_radiateur_chambre:
      friendly_name: "Puissance Radiateur Chambre"
      unit_of_measurement: 'W'
      value_template: >
        {% if is_state('switch.multilevel_power_switch_switch', 'on') %}
          1000
        {% else %}
          0
        {% endif %}

- platform: integration
  source: sensor.puissance_radiateur_chambre
  name: energie_radiateur_chambre
  unit_prefix: k
  round: 2
  method: left

Le premier sensor surveille les moments où le radiateur est « on », le second fait l’intégration (au sens mathématique: Intégration (mathématiques) — Wikipédia), i.e. calcule l’énergie consommée par le radiateur.

Ensuite deux utility_meter (easy, dizy): un pour la consommation quotidienne, l’autre pour celle mensuelle:

utility_meter:
  radiateur_chambre_daily_energy:
    source: sensor.energie_radiateur_chambre
    cycle: daily
  radiateur_chambre_monthly_energy:
    source: sensor.energie_radiateur_chambre
    cycle: monthly

Il suffit alors d’utiliser sensor.radiateur_chambre_daily_energy pour avoir l’énergie en kWh consommée par jour, et sensor.radiateur_chambre_monthly_energy pour celle par mois (je vois que vous suivez ).
De mes tests préliminaires, cela me semble fonctionner, mais des pincettes sont nécessaires, pour confirmer.

Avec un peu de conf, j’ai l’intuition qu’on peut - à partir du prix du kWh de votre fournisseur d’énergie, vous savez, celui qui vient de vous dire que cela va (bien) augmenter sous peu - calculer direct le prix en euros.

Edit (suite aux remarques étayées d’@djal ici): Attention pour le cas où le sensor est en ON/OFF, le sensor d’intégration doit utiliser la méthode left d’intégration, et non la méthode par défaut (trapézoïdale) pour avoir des valeurs réalistes.

djal · Novembre 2, 2021, 9:28

@diyanei excellent!!

Je ne connaissais pas l’intégration « integration », je vais tester, mais ca semble prometteur effectivement.

Merci!

Edit: Je suis en train de tester et effectivement ca fait le Job. A savoir simplement que le sensor « integration » ne se met a jour qu’au changement d’état du sensor « template », donc a chaque activation/désactivation du convecteur.
Mais bon c’est pas très grave. Je vais certainement passer tous mes radiateurs avec cette méthode, bien plus simple!

boscorelly · Novembre 3, 2021, 12:05

Bonsoir :

merci pour ton tuto qui devrait me permettre de quitter domoticz et migrer sur HA uniquement

j’ai une petite question : je pense avoir un cas particulier, car j’ai un radiateur que je veux couper via l’ouverture d’une fenetre ou… deux fenetres. Mais je ne peux mettre qu’un seul capteur d’ouverture dans le blueprint, une idée ?

j’ai regardé un peu le yaml, mais je ne vois pas comment je pourrais lui dire qu’un élément est facultatif

Argonaute · Novembre 3, 2021, 9:10

Hello,
Merci @boscorelly. Le plus simple est de faire un template binary sensor qui retourne On si une des deux fenêtres est ouverte. Puis mettre ce binary sensor dans le blue print.
J’enverrai le code si tu as du mal a le faire.

Argonaute · Novembre 3, 2021, 9:19

Excellent @diyanei !!! As tu testé directement sans la platform integration ? Je pensais que cela marchait.

djal · Novembre 3, 2021, 1:33

@diyanei Bon après quelques heures de tests, j’ai des doutes.

Exemple pour un convecteur de 1950w :

voila mon template et mon « integration » :

- platform: template
  sensors:
    puissance_convecteur_salon2:
      friendly_name: "Puissance convecteur Salon 2"
      unit_of_measurement: 'W'
      value_template: >
        {% if is_state('light.chauffage_2_qubino_salon', 'on') %}
          1950
        {% else %}
          0
        {% endif %}

- platform: integration
  source: sensor.puissance_convecteur_salon2
  name: energie_convecteur_salon2
  unit_prefix: k
  round: 2

J’ai fais en + un « history_stats » pour être sûr du temps d’activation :

- platform: history_stats
  name : Chauffage Salon 2 temps
  entity_id: light.chauffage_2_qubino_salon
  state: "on"
  type: time
  start: "{{ 0 }}"
  end: "{{ now() }}"

Et j’ai fais 2 sensors « utility meter » pour qu’il me donne les 2 valeurs à l’heure, pour mes tests :

  temps_hourly_convecteur_salon2_test:
    source: sensor.chauffage_salon_2_temps
    cycle: hourly

et

  consommation_hourly_convecteur_salon2:
    source: sensor.energie_convecteur_salon2
    cycle: hourly

et voilà ce que j’obtiens selon ces sensors pour l’heure en cours :

Donc 4.8 minutes de fonctionnement pour 0.49kWh, c’est impossible.
Un convecteur de 1950w consomme donc 1.95kWh pour 60 minutes (1h) de fonctionnement, 0.49kWh correspond environ à 15mn de fonctionnement.

Je vais continuer les tests, notamment pour avoir un valeur au jour, mais soit j’ai fait une boulette dans les sensors, soit je ne sais pas

Je vais garder ma méthode pour l’instant, certes + complexe mais très précise.

Dites moi si j’ai fais des erreurs, et si vous pouvez faire des tests.

Merci

Edit: En fait le « history_stats » à l’air OK, ça correspond bien au temps de fonctionnement.
Mais il y a un soucis avec « integration » , dès que mon convecteur se met en marche, il ajoute 0.12kWh à son compteur (pas la même valeur en fonction de la puissance déclarée dans le template) , et c’est ça qui créé le décalage il me semble. si quelqu’un peut confirmer.

Lou_Juicy · Novembre 3, 2021, 5:35

Hello !

L’utilisation d’integration est top dans le cas d’une puissance variable comme c’est indiqué dans l’article de ton blog (merci beaucoup pour la ressource au passage, très sympa pour voir la consommation virtuelle des ampoules dimmable). Personnellement je l’utilise pour calculer la consommation de mon lave-linge dont la consommation varie.

Mais dans le cas d’une consommation fixe, comme c’est le cas ici, j’utilise simplement un history_stats, un utility_meter et un simple template sensor (la nouvelle méthode pour l’avoir dans le dashboard energy).

Pour commencer un history_stats pour calculer le temps d’utilisation :

- platform: history_stats
  name: Radiateur salon
  entity_id: switch.chauffage_salon
  state: 'on'
  type: time
  start: '{{ now().replace(hour=0).replace(minute=0).replace(second=0) }}'
  end: '{{ now() }}'

Ensuite un utility_meter pour stocker la valeur en fonction de cycle (daily, monthly, …) :

energy_radiateur_salon_daily:
    source: sensor.radiateur_salon
    cycle: daily

Et pour terminer, un template sensor pour récupérer la valeur en kWh en fonction de la puissance du radiateur (1500W dans mon cas) :

- sensor:
  - name: "Radiateur salon daily"
    unit_of_measurement: "kWh"
    state_class: measurement
    device_class: energy
    state: "{{ (((states.sensor.energy_radiateur_salon_daily.state|float) * 1500) / 1000)|round(2) }}"
    attributes:
      last_reset: '1970-01-01T00:00:00+00:00'

(Les variables unit_of_measurement , state_class, device_class et l’attributes last_reset sont obligatoire pour l’affichage dans le dashboard energy).

Après quelques jours de tests, j’ai les presque les mêmes valeurs qu’avec l’automation de @djal (à 0,2 kW/j).

Personnellement je préfère de pas utiliser les automations dans ce cas et garder l’intégration pour des appareils à consommation variable. D’un point de vue purement théorique, les 3 méthodes doivent fonctionner pour calculer une consommation qui reste virtuelle.

Je vais maintenant me pencher un peu plus sur ton article de blog @diyanei pour calculer la consommation virtuelle de mes ampoules HUE

djal · Novembre 3, 2021, 6:25

Merci pour ta réponse.
Mais je ne comprends tout de même pas pourquoi ça ne fonctionne pas avec intégration.
Dans l’exemple du blog, il le fait avec une ampoule de 10w, donc ça devait fonctionner avec une consommation fixe.

diyanei · Novembre 3, 2021, 7:32

Effectivement, je suis d’accord avec vous, je constate des valeurs assez peu réalistes.
Je ne comprends pas non plus pourquoi l’utilisation d’integration serait plus juste en puissance variable qu’en puissance fixe, la seule différence étant le calcul de la puissance à chaque instant (fonction de la brightness dans le cas d’une ampoule à variateur).

Mais comme je n’ai pas non plus compris pourquoi cela ne fonctionne pas de façon réaliste dans un cas simple de puissance fixe, cela ne veut pas dire grand chose

Investiguons, il y a une explication, c’est sûr.

Edit: En commençant par relire la doc Integration - Riemann sum integral - Home Assistant la phrase suivante me saute aux yeux:

In case you have an appliance which produces spikey consumption (like an on/off electrical boiler) you should opt for the left method to get accurate readings.

De là à en déduire une réponse, je ne m’avance pas.

Edit2: D’autres ont effectivement été confrontés au même problème: Help with integration sensor - #2 by 123 - Configuration - Home Assistant Community et la méthode method: left semble donc juste.
Si des fois des lecteurs ne lisent pas les commentaires en détail, je vais modifier les instructions de mon post d’hier Gestion de bout en bout du chauffage - #180 par diyanei

djal · Novembre 3, 2021, 7:52

Ah ça me rassure!
Oui effectivement, j’ai lu un peu la doc et j’ai vu qu’on pouvait changer la méthode utilisée.
Je vais essayé left.

EDIT: Beaucoup, beaucoup mieux!! Déjà il me rajoute plus 0.12kWh sur le compteur a chaque déclenchement du sensor.
J’ai 0.02 d’écart sur 25mn avec ma méthode, a voir si ca dérive pas trop sur une journée/semaine/mois. (si la derive continue ca me fera environ 1.5kWh d’écart sur la journée, pas top!).

J’en saurais plus demain soir!

Argonaute · Novembre 3, 2021, 9:35

Hello @djal et @diyanei,
Bon j’ai pu prendre un peu de temps pour tester. Sans plateforme intégration, puis avec. Et même constat, résultats aberrants. Il faut que l’on trouve !