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
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.
Excellent @diyanei !!! As tu testé directement sans la platform integration ? Je pensais que cela marchait.
@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.
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 
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.
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
leftmethod 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
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!
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 !
Bon, j’ai fait rapidement une plateforme de test qui simule un changement de puissance passant alternativement entre 0 et 600 watts toutes les 30 secondes. L’intégration n’est effectivement pas bonne. La somme de Riemann permet de faire un échantillonnage d’une courbe simulée, puis de faire la somme des échantillons. Après tests, l’intégration « Riemann sum integral » retourne une erreur assez forte par rapport à ce qui devrait être.
Le code de ma plateforme de test si jamais.
#Simule le switch de marche-arrêt d'un convecteur
input_boolean:
test_conso_onoff:
name: "Switch convecteur"
#Allume le convecteur 30 secondes puis l'éteint 30 secondes
automation:
- alias: test_conso_automation
mode: single
trigger:
- platform: time_pattern
minutes: /1
action:
- service: input_boolean.turn_on
target:
entity_id: input_boolean.test_conso_onoff
- delay:
seconds: 30
- service: input_boolean.turn_off
target:
entity_id: input_boolean.test_conso_onoff
# Simule la consommation instantannée avec un convecteur de 600 watts => alterne 0 et 600 watts
sensor:
- platform: template
sensors:
test_conso_puissance:
friendly_name: "Puissance instantanée"
unit_of_measurement: 'W'
value_template: >
{% if is_state('input_boolean.test_conso_onoff', 'on') %}
600
{% else %}
0
{% endif %}
# Intègre la consommation => on devrait avoir 5 watts/heure de plus toutes les minutes
- platform: integration
source: sensor.test_conso_puissance
name: test_conso_energie
unit_prefix: k
round: 4
# Calcul la consomation horaire => devrait être 300 watts / heure
utility_meter:
test_conso_heure:
source: sensor.test_conso_energie
cycle: hourly
A suivre…
@Argonaute Je vois que tu n’as pas utilisé la méthode left, je dirais donc que ta conclusion est logique.
Merci pour le code de test, c’est effectivement une bonne façon de tester sans dépendre de son chauffage réel.
Bon je viens de mettre left et relancer. Je te dirai le résultat en fin de journée 
Après 4h30 de fonctionnement du convecteur depuis minuit, voilà les résultats avec la méthode left en comparaison de ma méthode :
L’écart est moins grand que ce que je pensais, mais il existe quand même.
Hello
Déja un tout grand merci à toi Argonaute pour ce partage et le travail accompli !!
Cependant j ai un petit soucis, je souhaiterai l adapter pour un poêle à Pellet qui chauffe en gros une fois le matin et une fois le soir (moment où nous sommes présent) J aimerai donc augmenter le temps de chauffe à 1h30 Soit 90 min et donc la puissance doit être multiplier par 54 (car à 6 pour 10), mais dans ce cas le thermostat bug et se coupe. J arrive à max 45 min de chauffe après cela plante. Une idée ?
Un tout grand merci d avance.
Hello,
Bon je viens de faire un test avec mon démonstrateur sur plusieurs heures, et il serait concluant avec la méthode left dans l’intégration, comme proposé par @diyanei. L’utility meter se remet à 0 à chaque heure, puis s’incrémente jusqu’à atteindre 0.3 kWh, ce qui est le résultat attendu.
Sur une heure oui je n’ai pas d’écart, mais j’observe un écart de 0.07 sur une journée de mon côté
Hello @Pistt,
Bienvenue sur le forum si c’est la première fois que tu publies.
Difficile de t’aider sans avoir le code ni les logs, mais aucune raison que cela plante. Que se passe t’il ? 54 est effectivement juste si tu veux une période de 90 mn à la place de 10mn. Tu dois bien mettre le trigger à 90 minutes (/90 ligne 73 du blue print).
Après, je n’ai pas de recul pour un poêle à pellet. J’aurai dit intuitivement plutôt 30 minutes (45 max) par rapport à l’inertie, cela restant à tester (vitesse de convergence vers la consigne et absence d’oscillations). Cela ne semble pas forcément bon de mettre la période de recalcul du thermostat égale à la durée de chauffe totale souhaitée. 1h30 sans revérifier la température et recalculer la puissance nécessaire sera à mon sens trop long, et la température de consigne pourrait alors être dépassée. Plutôt qu’une période longue du thermostat TPI, le thermostat générique de HA aurait alors presque plus de pertinence : chauffe jusqu’à obtention de la température puis arrêt à l’hystérésis prêt. Ou alors baisser la période du thermostat TPI…
Oui c est bien 45 min Max en temps de recalcul, ça marche en mettant 1h20 de chauffe et j ai mis le recalcul du thermostat à 25, on verra ce que cela donne. Ta méthode permet la prise en compte de la température extérieure qui permet vraiment un confort je trouve, il faut peaufiner ensuite.
Merci à toi
Merci. Ton retour avec un poele a pellet est précieux pour la communauté. N’hésites pas a publier tes conclusions après une période de mise au point des paramètres.
Hello, bon j’ai ajouté la méthode left pour tous mes convecteurs (5), je vous dirais en fin de journée mes conclusions.
Sinon je viens de voir PowerCalc dans HACS, si quelqu’un veut tester.