En y réfléchissant, @Argonaute m’avait donné la solution dans un post plus haut et avec la balise, cela permet de filtrer sur le planning de la pièce. Y’a plus qu’a !!!
Par contre, il est affiché « Ajuster la valeur à X°C A 22:00 » ou " Ajuster la valeur Dans 1 heure". Est-il possible d’avoir toujours le même format « Ajuster la valeur à X°C A 22:00 ».
Merci encore.
@Argonaute Merci pour ton Blueprint qui me donne des idées. Par contre j’ai abandonné le Scheduller au profit de Schedy que je trouve bien plus souple, mais j’ai du créer une interface et ça c’est moins simple…
Merci @mycanaletto. Oui je suis un lecteur et fan de ton blog. J’avais lu ton post sur schedy et le choix se défend. Par contre effectivement, le thermostat virtuel par défaut de HA n’est pas trop adapté a nos convecteurs électriques. N’hésites pas a faire tes retours et adaptations si tu t’inspires de ma proposition. J’ai dans ma todo le fait de mettre le temps (10mn actuellement) en paramètre pour l’ajuster en fonction de l’inertie du chauffage.
Je profite du post de @mycanaletto pour apporter ma petite contribution.
Comme je l’avais écris dans un précédent post, j’avais dans l’idée de partir sur la solution de @mycanaletto pour la gestion de mon chauffage électrique. Schedy semblant être plus « dynamique » que Scheduler mais plus complexe (au premier abord) à mettre en oeuvre.
Toutefois, ayant basculé de Domoticz à HA récemment, mes connaissances de HA étaient (sont … mais un tout petit peu moins maintenant) limitées et l’hiver approchant à grand pas, j’ai opté pour le blueprint de @Argonaute.
J’ai légèrement modifié l’idée du blueprint en définissant 4 zones (1 pièce à vivre et 3 chambres) et 4 plannings différents (avec semaine et week-end) soit 16 plannings au total.
Chaque planning définit une température en fonction d’une plage horaire (semaine et weekend).
L’une des options qui me manquaient terriblement était de pouvoir changer de planning temporairement et à la volée (invitation à dîner par exemple). J’ai contourné cette problématique par la mise en place d’un timer qui permet de définir un planning selon un temps prédéfini et qui permet à la fin de ce temps de revenir au planning initial.
La carte donne ça :
Je passe l’hiver avec cette installation et si celle-ci me convient, le passage à Schedy ne me sera peut être pas nécessaire. A voir …
Merci @mycanaletto , je suis un fans de ton blog également.
Mais avec la solution que tu propose, pas d’intégration de l’algo TPI il me semble non? C’est du ON/OFF avec l’intégration climate basique?
J’ai des convecteurs (corrects, pas des grilles pain…) et je trouve qu’il fait le boulot, tout au moins aussi bien que celui de Jeedom. A l’usage je n’ai jamais constaté un vrai plus avec les modes temporel et l’hystérésis du thermostat de Jeedom. Par contre celui de Jeedom disposait d’un système de planification que faisait sa force…et que est obligé ici de contourner. Mais avec ce que j’ai mis en place avec Schedy je gère tout ce qui m’est utile dans deux maisons.
Bonjour,
Petite question j’ai des radiateurs électriques chacun relié à Heatzy pilote.
J’ai plusieurs capteur de température chez moi. Je pilote actuellement le chauffage via home assistance, mais je n’ai pas de thermostat j’aimerai pouvoir augmenter la température de mes radiateurs (Sauter gyali) via home assistance, est-ce possible ?
Merci à vous.
Hello,
Merci beaucoup @Argonaute et @djal. 
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.
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.
@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.
Les automations ne sont pas du tout gourmandes en perf, tu peux y aller 
@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é.
@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.
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'
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.
Je n’ai pas testé. Mais un avis à ce sujet ? Est ce que ma compréhension du fonctionnement de l’utility meter serait bonne ?
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 ?
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 ?
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.
@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!