@ 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.
Bonsoir,
Un sujet très intéressant, j’utilise actuellement Simple_thermostat + scheduler + un input bolean en condition sur le scheduler basé sur la position de mon téléphone (Zone HA).
Changement aussi du preset_mode sur ouverture de fenêtre, tout ok puisque je suis seul chez moi mais quand mes filles viennent ou que je télétravaille, c’est en effet moins évident à gérer.
Je testerai à l’occasion, merci @Jean-Marc_Collin pour ce sujet.
Bob
1 « J'aime »
Je suis demandeur d’un retour quand tu auras eu le temps de le tester
Je comprends et je suis conscient que c’est assez énorme et je sais que Niels en a un peu bavé quand il s’est lancé dans le scheduler !
Au départ j’avais abandonné le Scheduler car il ne me permettait pas de gérer certaines exceptions (samedi travaillé et samedi férié. Aujourd’hui je pense que je pourrais le gérer, mais mon interface est plus facile pour l’utilisateur (ça reste subjectif mais il préfère). J e l’ai donc bordée avec 3 type de journées et 4 plages par journées.
Question : dans ton thermostat, peux t’on sortir les valeurs des preset pour les gérer dans du Lovelace ? (pour qu’ils soient gérable spar un user non admin)
tu parles des valeurs des températures ? Non, on ne peut pas, c’est paramétré à la création de l’entity.
Mais ce serait pas compliqué à faire par contre. Ca pourrait être soit une valeur soit un template qui donne ce qu’on veut. Ca se tente ça
Bonjour,
Tout d’abord, un grand merci pour le travail réalisé.
Je me mets tout juste à HA et à la vrai domo que récemment.
Et, je serais preneur d’avoir un peu plus de détails pour comprendre comment tu as construit ta vue de synthèse.
À tout hasard, lorsque tu cliques sur l’un de tes chauffages, rentres-tu dans un affichage plus détaillé ?
Merci 
Hello @Jeanyvon ,
La vue de synthèse est basée sur Mushroom chips (la liste des thermostats), en mode template avec le template suivant:
type: horizontal-stack
cards:
- type: grid
cards:
- type: custom:mushroom-chips-card
chips:
- type: template
entity: climate.thermostat_sam1
icon: >-
{% if is_state_attr('climate.thermostat_sam1', 'hvac_action',
'idle') -%}mdi:radiator-disabled {%- elif
is_state_attr('climate.thermostat_sam1', 'hvac_action', 'off')
-%}mdi:radiator-off {%- else -%}mdi:radiator {%- endif %}
icon_color: |-
{%- if is_state('climate.thermostat_sam1', 'cool') -%}blue
{%- elif is_state('climate.thermostat_sam1', 'heat') -%}#FF8000
{%- elif is_state('climate.thermostat_sam1', 'off') -%}lightgray
{%- endif %}
content: >-
{{ state_attr('climate.thermostat_sam1', 'friendly_name') |
regex_replace('Thermostat ','')}} -
{{state_attr('climate.thermostat_sam1', 'preset_mode')}}
({{state_attr('climate.thermostat_sam1', 'temperature')}} °C)
tap_action:
action: toggle
hold_action:
action: more-info
- type: template
entity: climate.thermostat_sam2
La deuxième vue est une history card avec la liste des switchs (qui pilotent les radiateurs):
- type: history-graph
title: Etat radiateurs
entities:
- entity: switch.radiateur_bureau
- entity: switch.radiateur_sam1
- entity: switch.radiateur_sam2
- entity: switch.radiateur_sam3
- entity: switch.radiateur_entree
- entity: switch.radiateur_musique
- entity: switch.radiateur_mezzanine
- entity: switch.radiateur_chambre_laure
- entity: switch.radiateur_chambre2
- entity: switch.radiateur_chambre4
hours_to_show: 2
Le plus long a été de mettre au point les templates chips pour avoir les icones, les couleurs qui varient en fonction des états.
1 « J'aime »