Ahhh effectivement ça passe 
Je te remercie énormément pour ton temps, bien qu’il soit hors sujet. Je vais creuser tout ça et te ferai un retour !
1 « J'aime »
J’étais en train de faire autre chose et je suis tombé sur cette description d’Apexchart-card : GitHub - RomRider/apexcharts-card: 📈 A Lovelace card to display advanced graphs and charts based on ApexChartsJS for Home Assistant
On a l’impression qu’on peut tracer directement les attributs et non le state directement sans passer par un template donc. Je pense que ça répond à ta question du coup:
attribute : Instead of retrieving the state, it will retrieve an attribute of the entity.
Ree
Alors j’ai réussi avec le template à récupérer la consigne, ça fonctionne. et j’étais en train de bruler mon cerveau à savoir comment récupérer l’état de chauffe ou non… 
et je sèche.
Du coup je vais aussi étudier ça
Merci pour l’info !!
L’état de chauffe ou non tu l’as directement sur l’entity switch qui représente le radiateur. C’est le plus simple.
Si tu veux vraiment utiliser le thermostat, il faut utiliser l’attribut hvac_action qui vaut idle si le radiateur est éteint et heating si il est allumé.
Effectivement !! beaucoup plus simple avec l’attribut
- entity: climate.thermostat_salon
attribute: temperature
Par contre ne fonctionne pas avec le hvac_action, qui n’est pas une valeur numérique, logique.
- entity: climate.thermostat_salon
attribute: hvac_action
Faut maintenant que je comprenne comment remplacer cette valeur par une valeur numérique genre heating = 100 ou 1 et iddle = 0
Voici pour ceux qui cela interesse la carte apex (sans l’état de chauffe) :
type: custom:apexcharts-card
header:
show: true
title: Historique sur 24h
graph_span: 24h
update_interval: 15 min
yaxis:
- id: temperature
- id: pourcentage
opposite: true
decimals: 0
series:
- entity: sensor.tvoc_temperature
name: Temperature
stroke_width: 2
group_by:
duration: 1 min
show:
extremas: true
legend_value: false
yaxis_id: temperature
- entity: climate.thermostat_salon
attribute: temperature
name: Consigne
stroke_width: 4
curve: stepline
yaxis_id: temperature
show:
extremas: true
legend_value: false
De mon coté, plutot que de tout avoir sur un même graphique, j’ai séparé comme ça:
J’ai l’état de chauffe du radiateur, la température et la puissance consommée en history-card directement (sans Apexchart qui n’est pas souple sur l’échelle de temps). Ca me fait ça :
- type: history-graph
entities:
- entity: switch.radiateur_bureau
refresh_interval: 1
hours_to_show: 2
- type: history-graph
entities:
- entity: sensor.total_puissance_radiateur_bureau
- entity: sensor.temperature_bureau
refresh_interval: 1
hours_to_show: 12
Et pour les vues de synthèse, j’ai fais ça:
C’est des history-cards aussi et des Mushrooms chips cards de type template pour chaque thermostat.
1 « J'aime »
Sinon tu as aussi un attribut « current_temperature » qui te donne la température du capteur directement dans le thermostat.
Et pour l’état de chauffe tu peux modifier l’état idle / heating de ton apexchart avec l’option transform (GitHub - RomRider/apexcharts-card: 📈 A Lovelace card to display advanced graphs and charts based on ApexChartsJS for Home Assistant). Y a un exemple qui donne exactement ce que tu cherches :
type: custom:apexcharts-card
update_delay: 3s
update_interval: 1min
series:
- entity: binary_sensor.heating
transform: "return x === 'on' ? 1 : 0;"
@ Jean-Marc , Es-tu content de tes switchs, Toujours un peu peur avec le wifi. j’avais vu ceux la en zigbee: Disjoncteur intelligent Tuya ZigBee 20A/30A, interrupteur, moule On/Off, contrôleur électrique pour appareils ménagers, bricolage de votre maison | AliExpress.
D’apres toi, ils peuvent faire l’affaire aussi?
Bravo @Jean-Marc_Collin pour ton thermostat, il commence à y en avoir pléthore mais sur le papier il me semble le plus aboutit. Je vais le tester.
Tu gère les preset, ouvertures et mouvement et tu délègue la planification au Scheduler qui fonctionne très bien mais ça a ses limites si tu veux gérer des types de journées particulières, ce qui fait qu’au final de mes pérégrinations j’ai fini par faire ça en yaml. Ici My Canaletto | Home Assistant, planification, encore... et là My Canaletto | Home Assistant & Schedy, encore... afin de proposer une interface la plus user friendly.
Mais là ou je veux en venir c’est que j’aimerais trouver une solution de geofencing afin de coupler et d’anticiper les modes de chauffage en fonction des habitudes, c-a-d aller au-delà de la simple présence.
Actuellement je me sert de proximity: afin de détecter la distance des occupants, ce n’est pas parfait, mais ça permet d’optimiser un peu. Par exemple dans la maison de mon frère activer la clim (pas les mêmes conditions en hiver ou été) selon qu’il rentre déjeuner ou pas…
Quand les occupants sont parfaitement réglés avec des horaires stricts c’est facile, ça l’est moins pour les occupants qui ont des horaires de départ et retour toujours différents…
Bref, idées welcome et bravo pour ton travail !
1 « J'aime »
Hello, ton second lien ne fonctionne pas.
Hello!
Alors voici mon retour d’expérience
Je trouve effectivement la prise en main beaucoup plus simple et accessible que celui que j’avais pu tester avant (cf argonaute). Pour un utilisateur lambda comme moi c’est très bien et très fonctionnel avec les différents presets et options. Concernant l’algorithme j’émets plus de réserve par rapport à mon utilisation. Dans mon salon, j’ai deux radians connectés et pilotés avec le fil pilote. Sur 2 jours, j’ai eu du mal à atteindre la consigne. La pièce a mis toute la soirée pour l’atteindre. Je pense que c’est dû à la faible inertie des radiateurs, et le fait de faire le yoyo on off sur les cycles, ne permet pas de bien chauffer et atteindre rapidement la consigne. Je pense que pour une régulation continue ça doit bien fonctionner, mais pour des changements de consigne régulière (nuit, absence etc) cela à du mal dans ma configuration. J’ai de meilleurs résultats avec un thermostat de type TPI (cf argonaute). Pour moi l’idéal serait d’implanter son algorithme à ton interface 
mais ça je vous laisse en discuter ensemble lol
En tout cas bravo pour ton travail, et surtout ton aide ! je garde l’idée sous le coude
1 « J'aime »
Les switchs marchent bien oui. Mais il faut un bon wifi en effet et j’ai été obligé d’ajouter des répéteurs wifi notamment à l’étage ou ca marchait moins bien.
Un switch Zigbee devrait fonctionner mieux et sans soucis si tu es équipé.
Super intéressant en effet. Avant de faire l’intégration je dupliquais aussi des automatisations mais je trouve ça super lourd en maintenance et le thermostat permet de supprimer tout ça. C’était vraiment l’objectif n°1.
Sur les journées particulières, il me semble que le Scheduler fait une distinction semaine / week-end.
Et en plus avec le Scheduler on peut gérer des conditions qui permet (dans mon cas) de gérer les jours ROUGE différemment. Y a un thread la-dessus : Plusieurs Scheduler sur les mêmes entités - #5 par Jean-Marc_Collin qui peut être intéressant.
On pourrait donc, de mon point de vue, gérer toutes les spécificités directement avec le Scheduler même si la configuration est parfois un peu lourde.
Il me reste une automatisation pour la gestion des absences basée sur des proximity sensors pour forcer le mode ‹ Away › si il n’y a personne à la maison. Ce serait intégrable facilement dans le thermostat directement oui. Ca ferait une automatisation en moins. Est-ce que tu penses que ce serait utilisable dans ton cas ?
Je suis en train de penser, on doit pouvoir avec la version actuelle s’approcher de ça, en utilisant la détection de mouvement. Si on passe un binary_sensor qui vaut true si proximity est proche, ça allumerait le radiateur automatiquement. On met le radiateur sur le preset « Activity » et lorsque le binary_sensor passe à true ca change le preset tout seul. Je suis à peu près sur que ca doit marcher car c’est comme ça que je teste en fait.
Y a aussi des templates utilisables type:
- binary_sensor:
- name: maison_occupee
unique_id: maison_occupee
state: "{{is_state('person.jmc', 'home') or is_state('person.chr', 'home')}}"
device_class: occupancy
Sinon, il faut j’intégre les radiateurs avec fil pilote (je ne gère que les On/Off actuellement) et les clims (réversibles ou non).
J’ai eu le même genre de soucis et c’est connu avec les algo de type Proportionnel uniquement.
Je palie à ça avec un biais (float) qui biaise la consigne pour viser un peu au dessus.
Chez moi, une valeur de 0,25 marche pas mal dans les grandes pièces type salle à manger.
Tu as aussi le choix de la fonction de regulation ‹ Linear › ou ‹ Atan ›. Atan est plus aggressive et permet d’atteindre la consigne plus vite avec la contre-partie d’avoir un peu plus de risque d’oscillations.
Essaye ça et dis moi si ca change quelque-chose.
edit:
Quand à l’idée d’avoir un thermostat full PID, je ne sais pas trop. L’algo me parait super complexe, les réglages très compliqués. Je n’ai pas non plus vocation a dupliquer ce qui existe déjà et qui fonctionne.
J’ai refais l’intégration car celle que j’utilisais awesome_thermostat n’est plus maintenue par son développeur. Mais je garde l’idée dans un coin. Peut être qu’avec @Argonaute on pourrait voir comment effectuer un rapprochement / fusion ? A voir.
En tout cas merci pour ton retour très intéressant.
J’étais en contact avec l’auteur du Scheduler à ses début. Depuis j’ai un peu perdu de vue. Ce que je lui reprochait à l’époque c’est de ne pas faire de re-planification. Ca a peut être changé depuis, mais l’avantage de Schedy ou ce que j’ai fait en yaml c’est que toute les x minutes il reconsidère la situation, là ou le scheduler ne va renvoyer le on ou le off qu’en début de plage (en tous cas c’était ainsi à l’époque).
Pour la géoloc il ne s’agit pas seulement de savoir si la personne est présent ou pas, proximity à la place du bin de présence suffirait, mais de savoir si par habitude quand une personne se trouve à tel ou tel point géo va rentrer (et donc anticiper la chauffe) ou se diriger ailleurs, en fonction de ses habitude (un peu ce que fait Nest il me semble), donc avec une sorte d’IA…
Depuis j’ai un peu perdu de vue. Ce que je lui reprochait à l’époque c’est de ne pas faire de re-planification.
Je me demande si ce n’est pas ce bouton là sur Scheduler (que je n’ai pas creusé j’avoue)
donc avec une sorte d’IA
ok. Chaud ça…
Non, la il s’agit de re planifier si une condition change, moi je veux re planifier par exemple si le switch passe off pour une raison quelconque ou si qq un change la consigne manuellement par exemple… (et bien sur les conditions genre fenêtre ouverte que tu gères).
Et si tu intégrait la partie planification au thermostat ? (moi je ne suis pas dev mais je suis pret à y bosser comme je le fait avec mes devs en pro)
La présence je la gère actuellement avec un autre objectif pour les chambres enfants / amis, avec un calendrier qui va basculer un boolean (vacances des enfants ou visite d’un ami), je considère alors que la chambre sera occupée (abs > eco et ensuite activation des plages de confort avec proximity)
Quelques précisions à ce sujet.
Chaque changement d’une planification dans le scheduler change la consigne : changement de plage horaire dans le scheduler, de température de consigne, arrêt marche de la planification et redémarrage d’Home Assistant.
Prenons quelques exemples
Exemple 1 :
- Scheduler : planification avant 14h à 18°c, après à 20°c
- Il est midi donc consigne à 18°C
- On modifie dans le scheduler pour avoir consigne à 18°c à 11h et 20°c après
- La consigne du chauffage passe immédiatement à 20°c
Exemple 2 :
- La planification du scheduler est arrêtée. Consigne à 15°c
- On active la planification => la consigne se met immédiatement à la bonne valeur (par exemple 20°C).
Si on modifie « à la main » la consigne du chauffage, la planification du scheduler ne remettra effectivement pas automatiquement la consigne programmée. Mais il est possible de lui demander de la recharger en appelant le service scheduler.run_action, en passant en paramètre la planification à mettre à jour.
Je n’éprouve pas le besoin d’utiliser ce service, car je n’ai jamais constaté de différences entre la consigne programmée et la consigne réelle avec l’implémentation que je propose. Mais ce peut répondre à ton éventuel reproche suivant comment tu utiliserai le scheduler.
C’est bien ce que je constate. Et je trouve ça vachement pratique de pouvoir overrider la consigne du scheduler temporairement jusqu’au prochain changement auto.
J’ai froid, je force le preset sur Boost, ca se remettra tout seul à Eco en nuit.
Pour moi c’est une feature et pas un « bug »
Je ferai jamais mieux que le Scheduler et faut garder la philosophie qui a fait le succès de Linux (entre autre): on en fait peu mais on le fait bien. Donc je suis pas fan et franchement, c’est ultra-compliqué si on veut faire un truc bien.