ARTICLE INCOMPLET EN COURS DE RÉDACTION

Ce ne sont que mes notes compilées au fil de l'eau... Et vous pouvez poser des questions !
N'hésitez pas à revenir ou d'utiliser la touche F5, et de me signaler les erreurs :-)

Comme je l'ai déjà expliqué dans les articles précédents (1 | 2), Jeedom, qui a remplacé la ZiBase, me sert essentiellement à gérer mes convecteurs. Jeedom est plutôt bien fait sur ce point grâce aux plugin Thermostat, Mode et Agenda. On va voir ici que l'on peut faire la même chose avec Home Assistant, on ne se contentera par contre pas de cliquer sur des boutons, il faudra un peu de codage, rien de bien méchant et surtout du copié / collé. Mais une fois que l'on a compris le concept c'est bien plus rapide et surtout extrêmement fiable. Home Assistant ne fait pas tout, mais il fait très bien ce qu'il propose.

Ici pas de plugins mais des fonctions que l'on assemble. Et donc à chaque étape, on vérifie que ça fonctionne (en exécutant ce que l'on fait), et avec le validation intégrée à HA au cas ou l'on aurait codé n'importe quoi ou simplement pas respecté les indentations. Certaines modifications apportées à configuration.yaml et ses sous ensembles nécessitent un redémarrage, par contre on peut recharger à la volée les modifications apportées aux scripts et automations.

HA dispose d'un éditeur de scripts et automations, c’est bien pour faire de petites choses et pour se familiariser, mais dès que l'on souhaite taper dans le dur je vous conseille vivement d'éditer les fichiers .yaml avec un éditeur de code (comme Notepad++, Sublime ou VSCodium (je viens de me prendre un virus avec ce dernier, surement par le biais d'une extension, du coup je suis retourné à Visual Studio Code). Attention c’est l'un ou l'autre, mais pas les deux en même temps, et ce qui sera édité à la mano ne le sera plus avec l'interface.

Alors c'est parti ! Le propre d'une solution domotique est d'obtenir un résultat final calqué à ses besoins, il faut donc les définir, ce qui doit déjà être fait si vous venez de Jeedom. Par contre il ne faudra pas chercher à reproduire exactement la même chose, mais à profiter de ce qu'offre HA.

Dans ce projet j'aurais tout pu faire en code, mais mon objectif de départ est que n'importe qui puisse ensuite changer les plages horaires de base et les températures de consigne sans aller dans le code.

Je pars du principe que vous avez déjà joué avec Home Assistant et intégré ses concepts de base, si ce n'est pas le cas commencez par là et revenez plus tard. Je vais présenter ici quelques exemple, mais ensuite je publierait toute la configuration sur Git-Hub, publication possible et intégrée à HA bien entendu.

Concepts de base

Pour gérer le chauffage on va utiliser plusieurs plusieurs composants et fonctions :

• Climate, qui est en fait un thermostat générique que l'on adaptera à nos besoins.
• Input_Select, Input_Boolean, Input_Number et Input_DateTime qui vont nous permettre de saisir, afficher et d'utiliser des valeurs, un peu comme des données variables, mais qui seront persistantes dans le système tant qu'on ne les change pas (donc même après un redémarrage).
• Des automations (des scénarios) qui vont nous permettre de planifier les plages horaires.
• Des scripts pour exécuter de rapides routines.
• Des sources de température, les capteurs que l'on placera judicieusement dans les pièces à chauffer. J'utilise des sondes Xiaomi Aqare en Zigbee via Deconz / Phoscon et des sondes Xiaomi avec afficheur en Bluetooth. Mais n'importe quel type de sonde fera l'affaire pourvu qu'elle remonte la température quand elle change.
• Des actionneur ON/OFF pour chaque convecteur, j'utilise une vieille carte IPX800 v2, mais ça peut être du Shelly, du Zwave, du fil pilote, bref n'importe quoi capable d'allumer un convecteur en respectant les normes en vigueur (on évite de commander un convecteur avec une chinoiserie. Et on évité également des équipements qui ne sont pas pilotables en local afin d'éviter de se retrouver sans chauffage en cas de coupure internet).

Le thermostat

La première chose à faire pour pouvoir jouer est de créer un premier Thermostat en éditant le fichier climate.yaml que l'on aura inclut dans configuration.yaml (je vous conseille de faire ainsi pour tout afin d'aérer votre code, !include_dir_merge_list permettant d'inclure tout ce qui est dans un sous répertoire pour une type donné) :

group: !include groups.yaml
#automation: !include automations.yaml
automation: !include_dir_merge_list automations/
script: !include scripts.yaml
scene: !include scenes.yaml
switch: !include switch.yaml
climate: !include climate.yaml
notify: !include notify.yaml
sensor: !include sensor.yaml
input_boolean: !include input_boolean.yaml
input_datetime: !include input_datetime.yaml
input_number: !include input_number.yaml
input_text: !include input_text.yaml
input_select: !include input_select.yaml

Et ensuite dans climate.yaml on va placer notre premier thermostat. Attention à toujours respecter l'indentation propre aux fichier .yaml (d'ou un éditeur de code).

  - platform: generic_thermostat
    name: Thermostat Cuisine
    heater: switch.study_heater
    target_sensor: sensor.mi_cuisine
    min_temp: 15
    max_temp: 21
    ac_mode: false
    target_temp: 17
    cold_tolerance: 0.3
    hot_tolerance: 0
    min_cycle_duration:
      seconds: 5
    keep_alive:
      minutes: 3
    initial_hvac_mode: "off"
    away_temp: 16
    precision: 0.1

Je ne vais pas vous expliquer le paramétrage du thermostat, il y a des docs (paramétrage | utilisation) pour ça, et sous HA elles sont très bien faites, documentées et fournies avec des exemples.

J'ai géré des convecteurs, mais il est également possible de gérer des climatiseurs réversibles ou d'autres types d'appareils. Il faudra bien sur ajuster ces valeurs, on constate d'emblée la présence d'une valeur du mode absence qui dans certains cas constituera un seuil, le reste consistant à chauffer ou pas. C'est adapté à un poêle ou du chauffage central, mais pas à du chauffage électrique ou il faudra être plus précis et gérer des mode Eco/Confort.

A partir de la on ajoute notre thermostat dans l'interface avec une carte Thermostat et on peut commencer à jouer avec (j'ai un peu customisé le thermostat de base...).

Les Input

Ils vont nous servir de variables de base pour planifier le fonctionnement de nos thermostats avec différentes températures de consigne et différentes plages horaires.

Input_Select : c'est une sorte de combo qui me permettra de passer d'un mode à un autre pour déclencher un script qui va reparamétrage l'ensemble (planification et consignes) en fonction d'une situation. Dans mon cas j'ai un mode Normal, un mode Dîner ou j'élargit les plages horaires et je chauffe un peu plus certaines pièces quand je reçoit du monde (avec option "elle" reste dormir auquel cas je chauffe un peu plus la chambre si c'est une frileuse, ou la chambre d'amis), le mode Week-End si je reçoit des amis avec chauffage de la chambre d'amis, etc..

input_select: # ligne à supprimer quand on place ça dans un sous-fichier
  chauffage:
    name: Etats du Chauffage
    icon: mdi:home-minus
    options:
     - Normal
     - Diner
     - Week-End
     - Abscent

Cette fonction va généralement déclencher un script de mise en situation qui activera les planifications idoines, il faudra également déclencher un script de sortie pour repasser en mode Normal.

Enfin on se servira du mode défini en tant que condition  pour l'exécution d'une planification. Par exemple je chauffe le groupe (on verra plus tard la notion de climate_group) des pièces de vie en mode Confort+ à la condition que que le mode Dîner soit activé.

Input_Boolean : c’est une sorte d’interrupteur virtuel qui va me permettre de passer à ON tous les thermostats à au début de l'hiver (ce que je pourrais également programmer à l'aide des données météo externes), ou de signaler la présence des enfants en vacances chez moi et d'activer la planification du chauffage de leurs chambres (ce que je pourrais également automatiser grâce à leur géolocalisation sur une zone élargie, genre leur TGV approche à moins de 100 km, le temps d'aller les chercher à la gare et leur chambre est chauffée.

input_boolean:
  presence_antoine:
    name: Présence Antoine
    initial: off
    icon: mdi:account-switch
  presence_marie:
    name: Présence Marie
    initial: off
    icon: mdi:account-switch
  thermostats_on_off:
    name: Chauffage On / Off
    initial: off
    icon: mdi:thermostat-box

Input_DateTime : va nous servir à définir nos plages horaires de chauffage. Mais afin de pouvoir s'en servir il faut au préalable définir le sensor Date & Time. (je n'ai pas encore compris ce point, mais il est indispensable).

sensor:
    - platform: time_date
      display_options:
      - 'time'
      - 'date'
      - 'date_time'
      - 'date_time_utc'
      - 'date_time_iso'
      - 'time_date'
      - 'time_utc'
      - 'beat'

Ensuite on défini autant de plages horaires que nécessaire. Je me suis abstenu à une plage par pièce, mais il est tout à fait possible d'en ajouter, par exemple sdb_start_confort_matin, de même que j'ai fait un start/stop_confort et qu'explicitement de bascule ensuite en consigne eco, mais j'aurais également pu créer un start_eco ou start_confort_plus, etc...

input_datetime:
  sejour_start_confort:
    has_date: false
    has_time: true
  sejour_stop_confort:
    has_date: false
    has_time: true
  sdb_start_confort:
    has_date: false
    has_time: true
  sdb_stop_confort:
    has_date: false
    has_time: true

On peut également pour chaque entrée ajouter un name:, je ne l'ai pas fait car je vais me servir du plugin multiple-entity-row (à installer depuis HACS) pour afficher tous ça sur une ligne horizontale dans une carte.

Input_Number : va lui me servir à définir mes consignes de température. Je les ai définie globalement, mais comme pour le reste on pourrait affiner. De base c'est c'est affiché en tant que slider, mais il est possible de faire un affichage box et une saisie manuelle, ou comme je l'ait fait de regrouper ces valeurs sur une seule ligne avec multiple-entity-row. Et on peut en ajouter à souhait !

input_number:
  consigne_confort:
    name: Confort
    initial: 20
    min: 19
    max: 24
    step: 0.1
    unit_of_measurement: °C
  consigne_eco:
    name: Eco
    initial: 17
    min: 15
    max: 19
    step: 0.1
    unit_of_measurement: °C

On en a maintenant terminé avec les Input, sachez toutefois qu'il existe également Input_Text qui pourra servir à définir le contenu des messages de notification (SMS, Slack, Telegram ou vocaux via Google Home ou Alexa). Voici le résultat en image :

Vous remarquerez que c'est en anglais, c'est volontaire le temps du développement. En effet toutes les docs étant en langue anglaise, il est bien plus facile pour la compréhension de travailler avec une interface dans cette même langue. En un clic tout peut repasser dans une autre langue.

A ce stade on peut cliquer sur les valeurs pour changer les horaires de début et de fin ainsi que les consignes (elles seront persistantes après un redémarrage car on à pas défini de valeur par défaut dans les Input).

Planification

Si à ce stade on peut commencer à utiliser manuellement nos thermostats, l’intérêt d'une solution domotique est bien sur d'automatiser afin que la domotique nous apporte une expérience confortable adaptée à notre mode de vie.

Pour y parvenir on va planifier les horaires pour adapter le confort (températures) souhaité à notre mode de vie. On commencer par la vie courante (je me lève, je travaille, je dors) et on s'occupera ensuite des cas particuliers (je voyage, je reçoit, je prends une douche à un horaire non planifié, je regarde un film, etc...). On va également gérer les cas particuliers récurrents comme la présence durant les vacances scolaires des enfants pendant x jours, ensemble ou séparément.

Autant vous dire qu'on va rentrer dans le code et notamment se servir de la notion de Template (& Templating) afin d'utiliser les valeurs définies dans nos Imput's pour nos automatisations à base d'Automation ou de Scripts. Mais n'ayez pas peur, je parle de code car ça y ressemble et que je vous recommande un éditeur de code, mais il ne s'agit jamais que de bouts de code généralement issus de nos recherches, le copié / collé est roi, heureusement car je vous rappelle que je ne sais pas coder !

Pour planifier le chauffage d'une pièce ou d'une zone notre Automation va se décomposer en trois parties qui devront êtres parfaitement formatées et indentée, chaque partie peut être multiple (and ou or, je pense) :

1. Trigger: c'est ce qui va déclencher la planification, dans notre cas on utilisera l'heure début, mais cela pourrait également être un interrupteur, un événement, un état, etc...
   PS : je pense que dans une v2 j’utiliserai un time_pattern permettant la re planification en fonction de conditions (par exemple, de telle heure à telle heure, uniquement le samedi et en fonction d'un mode défini...).
   PS2 : On oublie time_pattern pour cet usage, trop chargé, et surtout on ne peu plus dans ce cas changer la valeur de consigne manuelement.
2. Condition: pour l'instant je vais me servir uniquement de l'état du Mode (voir input_select plus haut). 
3. Action: c'est ici que l'on va dire ce que l'on fait. Dans mon cas je vais :
   1. Définir la température de consigne Confort du thermostat (ou d'un groupe de thermostats) en me servant d'une valeur définie plus haut (avec input_number), ensuite j'attendrait
   2. Attendre qu'il soit l'heure de repasser en mode Eco avec un wait_template: et mon heure de fin.
   3. Définir la température de consigne Eco du thermostat
   4. Éventuellement je peux ajouter d'autres actions, comme afficher un voyant sur la vieille ZiBase (qui ne sert plus qu'à ça...) pour indique l'état Confort de la pièce... Ou encore envoyer une notification à Slack qui me servira de journal d’événements... A vous d'imaginer !

Voici ce que ça peut donner :

- alias: 'Planification / Thermostat : Antoine'
  trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.antoine_start_confort.state[0:5] }}'
  condition:
  - condition: state
    entity_id: input_boolean.presence_antoine
    state: 'on'
  action:
  - service: climate.set_temperature
    entity_id: climate.thermostat_antoine
    data_template:
      temperature: '{{ states.input_number.consigne_confort.state }}'
  - wait_template: '{{ states.sensor.time.state == states.input_datetime.antoine_stop_confort.state[0:5] }}'
  - service: climate.set_temperature
    entity_id: climate.thermostat_antoine
    data_template:
      temperature: '{{ states.input_number.consigne_eco.state }}'

Et pour repasser en mode Eco, j'ai dans ce cas intégré un wait_template. Si ça fonctionne, ça n'a rien de fabuleux car pendant tout ce temps d'attente de plusieurs heures, il peut se passer plein de choses, et notamment le redémarrage de HA, et dans ce cas il ne saura plus qu'il doit repasser en mode Eco à telle heure. On va donc oublier cette façon de faire et créer une ou plusieurs automations de fin de séquence. Je dis une ou plusieurs car si pour l'instant je n'ai imaginé qu'une seule plage par jour, dans bien des cas il en aura plusieurs (matin, midi, soir...). Mais il est possible de créer une automation de déclenchement regroupant plusieurs input_time START ou STOP afin de réduire le nombre d'automations, les multiples triggers fonctionnant sur le mode OR. On peut également imaginer une automation de nuit qui repasse en Eco tous les thermostats...

trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.antoine_start_confort_matin.state[0:5] }}'
trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.antoine_start_confort_midi.state[0:5] }}'
trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.antoine_start_confort_soir.state[0:5] }}'

On peut également vouloir déclencher un trigger à un jour et heure spécifique liée à in input_datetime.

value_template: "{{ states('sensor.date_time') == (states.input_datetime.next_diner.attributes.timestamp | int | timestamp_custom('%Y-%m-%d, %H:%M', True)) }}"

Il nous faudra donc pour chaque thermostat ou groupe de thermostats une automation qui va gérer les  START et une automation pour les STOP.

Pour valider les templates il y a dans l’interface de HA un éditeur qui permet de voir et vérifier le résultat. Notez au passage [0:5] à la fin de la seconde Template qui va me permettre de ne considérer que les 5 premiers digit [20:15] d'une valeur qui en compte plus [20:15:56] (les : comptent).

Gestion des modes

J'ai fait le choix dans cet input_select de lancer des scripts pour ne pas encombrer, il il est tout à fait possible de lancer ici une suite d'action.

- alias: 'Mode : Etats du chauffage'
  description: ''
  trigger:
  - entity_id: input_select.chauffage
    platform: state
  condition: []
  action:
  - service: script.turn_on
    data_template:
      entity_id: >
        {% if is_state("input_select.chauffage", "Normal") %}
          script.mode
        {%-elif is_state("input_select.chauffage", "Diner") %}
          script.mode_boost_diner
        {%-elif is_state("input_select.chauffage", "Week-End") %}
          script.mode_boost_week-end
        {%-elif is_state("input_select.chauffage", "Abscent") %}
          script.mode_abscent
        {% endif %}

Par contre dans la gestion de cet input_bolean j'agit directement.

- alias: 'On / Off des Thermostats'
  description: ''
  trigger:
  - platform: state
    entity_id: input_boolean.thermostats_on_off
  action:
  - service: climate.set_hvac_mode
    entity_id: climate.climate_all
    data_template:
      hvac_mode: >
        {% if states.input_boolean.thermostats_on_off.state == "on" %}
          heat
        {% else %}
          off
        {% endif %}

Alors que dans cet exemple on va utiliser deux actions sur deux entités différentes :

- alias: Input Select Chauffage Antoine
  description: ''
  initial_state: true
  hide_entity: false
  trigger:
  - entity_id: input_select.thermostat_antoine
    platform: state
  condition: []
  action:
  - service: climate.set_preset_mode
    entity_id: climate.thermostat_antoine
    data_template:
      preset_mode: >
        {% if is_state("input_select.thermostat_antoine", "Présent") %}
          none
        {%-elif is_state("input_select.thermostat_antoine", "Absent") %}
          away
        {% endif %}
  - service: climate.set_hvac_mode
    entity_id: climate.thermostat_antoine
    data_template:
      hvac_mode: >
        {% if is_state("input_select.thermostat_antoine", "Marche") %}
          heat
        {%-elif is_state("input_select.thermostat_antoine", "Arrêt") %}
          off
        {% endif %}

Cas particuliers

Mode réception

Je ne suis pas frileux et j'essaie de réaliser quelques économies. J'ai donc une température de Confort entre 19 et 20°, par contre si je reçoit du monde à dîner je ne veut pas gâcher l'ambiance à cause du froid que pourraient ressentir mes invités. Je vais donc créer une dérogation à la planification normale et utiliser une température de consigne que j'appellerait Confort+ que j'aurais définie avec un input_number. Pour définir la date et l'heure du début de l’événement, je me servirait d'un input_datetime qui me servira à lancer l'automation idoine, qui va définir la température en Confort+, basculer l'état de mon input_select en mode Diner / Réception (cet état pourra me servir pour des scènes par exemple, ou à conditionner le thermostat de la chambre). 

- alias: 'TH : CONFORT+ Groupe Réception'
  description: 'Activation CONFORT+ des Thermostats du groupe Réception (CHBS)'
  trigger:
  - platform: template
    value_template: "{{ states('sensor.date_time') == (states.input_datetime.next_diner.attributes.timestamp | int | timestamp_custom('%Y-%m-%d, %H:%M', True)) }}"
  condition:
  - condition: state
    entity_id: input_select.chauffage
    state: Normal # Normal ? Dans l'absolu cette vérification est inutile)
  action:
  - service: input_select.set_options # On bascule le mode du chauffage en : Diner
    entity_id: input_select.chauffage
    data:
      options: Diner
  - service: climate.set_temperature
    entity_id: climate.climate_reception
    data_template:
      temperature: '{{ states.input_number.consigne_confort_plus.state }}'
  - service: notify.slack_hass_canaletto
    data:
      message: Passage en mode CONFORT+ ({{ states.input_number.consigne_confort_plus.state }}°) de la zone Réception (CHBS). La température moyenne est de {{ states('sensor.mi_bureau') }}°

J'utilise ici le groupe de thermostats Réception (CHS) qui comprends la cuisine, le hall et le séjour.  Vous remarquerez au passage la présence de messages vers Slack. Très utile en période de debug, cela permet également par la suite de suivre la chronologie des événements bien plus lisible que les logs.

Je n'utilise pas d'heure de fin d’événement car l'automation de clôture de nuit normale basculera en mode ECO le groupe CHBS et repassera l'état en Normal. Je déclenche ce mode à minuit par exemple, et je considère que si on se couche plus tard on pourra faire une dérogation exceptionnelle à la main directement sur les thermostats. C’est pourquoi cette automation de clôture aura un second trigger vers 03:00.

Le mode Week-End

Là c’est un peu plus compliqué. Il va falloir désactiver les automation courantes, chauffer le séjour que j'utilise peu en temps normal, chauffer les chambres des enfants qui pourront devenir des chambres d'amis...

Je vais me servir de deux input_datetime pour le début et la fin du week-end car un week-end n'est pas forcément un samedi et un dimanche mais peut être prolongé. Je pourrais ajouter un ou deux input_boolean pour valider l'utilisation des chambres des enfants en tant que chambre d'amis, mais faisons simple et consolideront simplement l'occupation de ces chambres avec une date d'arrivée et de départ comme s'il s'agissait des enfants (il faudra juste saisir les dates).

# A VENIR
# trigger à ajuster ultérieurement + select mode basé sur le mode réception...

Absence

Basculer un via un input_boolean (géré ou pas en Géo Localisation) le groupe de thermostat ALL en mode absent permettra de conserver une température minimale qui est définie dans la configuration du thermostat. A voir selon les cas d'usage, ça peut correspondre à notre fameux Hors-Gel. On peut également se dire qu'il s'agit d'une température de type Eco.

# CODE

Présence enfants

C'est un mode à part car il peut y avoir Réception avec ou sans l'un ou l'autre de mes enfants. J'ai utilisé ici des input_boolean ou le ON va définir la condition pour le fonctionnement de la planification de leur chambre, tandis que le OFF stoppera les thermostats associés.

La date et l'heure de début et de fin va être soit saisie dans un input_datetime, soit ajoutée à celui ci depuis un agenda externe (Google ou Outlook), une information publique (calendrier des vacances scolaires), tout dépends du mode de vie, mais la saisie me parait un bon début.

#CODE

J’envisage également d'utiliser la géo localisation des enfants afin d'activer ou désactiver ce commutateur. Comme ils habitent loin, on peut imaginer que s'ils entrent dans un rayon de plus de 100 km on considère qu'ils sont ici en vacances, et de fait on chauffe...

Fenêtre ouverte

Une fonction que je n'avais jamais mis en oeuvre sur Jeedom, faute d'avoir eut un résultat immédiat, couper le thermostat quand on ouvre une fenêtre (ou un groupe de fenêtres). Il faudra bien sur un détecteur d'ouverture sur la fenêtre, après quoi une paire d'automations fera le job (à répéter sur chaque thermostats ou groupes de thermostats) :

# On couppe le chauffage quand la fenêtre est ouverte
- alias: '716 : WINDOWS : OPEN'
  trigger:
    platform: state
    entity_id: binary_sensor.fenetre_antoine
    from: 'off'
    to: 'on'
    for:
      minutes: 5
  action:
  - service: climate.set_hvac_mode
    entity_id: climate.thermostat_antoine
    data:
      hvac_mode: 'off'

- alias: '717 : WINDOWS : CLOSED'
  trigger:
    platform: state
    entity_id: binary_sensor.fenetre_antoine
    from: 'on'
    to: 'off'
    for:
      minutes: 5
  action:
  - service: climate.set_hvac_mode
    entity_id: climate.thermostat_antoine
    data:
      hvac_mode: heat

Douche ponctuelle

Quand on a une vie rangée calquée sur des horaires fixes on peut bien sur préchauffer la salle de bain pour la douche du matin ou du soir. Sur ce point j'ai une vie un peu décousue et ce genre de programmation n’est pas envisageable. De plus mon radiateur sèche serviettes Acova est au normes, il n'est donc jamais brûlant et ne permet pas de chauffer rapidement la salle de bain. J'ai donc ajouté un radiateur soufflant pour obtenir une rapide montée en température (22/23° en 10/15" selon la température de départ). 

Je vais donc programmer une Automation qui aura pour trigger un double clic sur un bouton Xiaomi Aqara, voire un déclenchement vocal via GH ou Alexa, action conditionnée par un seuil de température qui lancera le radiateur soufflant et le sèche serviettes pendant 45 minutes. (cette valeur pourra être définie dans l'interface grâce à un input_timedate, input_number ou pourquoi pas un timer que je n'ai pas encore utilisé...).

# Douche ponctuelle
- alias: 'SW : Douche ON pour 45 mn.'
  description: '2 clics Inter Gauche, scèche servietets + radiateur souffant'
  trigger:
  - device_id: d800f7295af147dcad3a5f6ca4970f4a
    domain: deconz
    platform: device
    type: remote_button_double_press
    subtype: left
  condition: []
  action:
  - service: switch.turn_on
    entity_id: switch.osram
  - service: switch.turn_on
    entity_id: switch.x2d
  - service: notify.slack_hass_canaletto
    data:
      message: Passage en chauffe de la SDB. La température actuelle est de {{ states('sensor.bt_t_salle_de_bain') }}°
  - delay: '00:45:00'
  - service: switch.turn_off
    entity_id: switch.osram
  - service: switch.turn_off
    entity_id: switch.x2d
  - service: notify.slack_hass_canaletto
    data:
      message: Fin [automatique] de chauffe de la SDB. La température actuelle est de {{ states('sensor.bt_t_salle_de_bain') }}°

# Cas d'une douche rapide ou on souhaite mettre fin au chauffage avec un simlple clic
- alias: 'SW : Douche OFF'
  description: '1 click Inter Gauche'
  trigger:
  - device_id: d800f7295af147dcad3a5f6ca4970f4a
    domain: deconz
    platform: device
    type: remote_button_short_press
    subtype: left
  condition: []
  action:
  - service: switch.turn_off
    entity_id: switch.osram
  - service: switch.turn_off
    entity_id: switch.x2d
  - service: notify.slack_hass_canaletto
    data:
      message: Fin [manuelle] de chauffe de la SDB. La température actuelle est de {{ states('sensor.bt_t_salle_de_bain') }}°

VMC

Elle est programmée pour se mettre en route en fin de nuit si la température extérieure est supérieure à 5°. (prévoir la définition de cette valeur dans l'interface avec un input_number.).

- alias: 'Q : VMC : Lancement Quotiden' #5 minutes avant
  description: ''
  trigger:
    platform: time
    at: '08:00:00'
  condition:
  - condition: template
    value_template: "{{ states('sensor.bt_t_terrasse') | float > 5 }}"
  action:
  - service: switch.turn_on
    entity_id: switch.ipx800_7_vmc
  - service: notify.slack_hass_canaletto
    data:
      message: VMC Quotidienne ON à {{ states.sensor.time.state }}, la température extérieure est de {{ states.sensor.bt_t_terrasse.state }}°  
  - delay: 00:01:00
  - service: switch.turn_off
    entity_id: switch.ipx800_7_vmc
  - service: notify.slack_hass_canaletto
    data:
      message: VMC Quotidienne OFF à {{ states.sensor.time.state }}, la température extérieure est de {{ states.sensor.bt_t_terrasse.state }}° 

La VMC se mets également en route si un certain seuil d'humidité est détecté dans la salle de bain, pendant une douche par exemple. Cette consigne est définie dans l'interface par un input_number et comparé à l'humidité détectée (après avoir tâtonné pas mal je suis parti sur cet exemple.).

- alias: '"P : VMC ON/OFF : Sur Humidité excessive SDB'
  trigger:
    platform: state
    entity_id:
      - input_number.consigne_humidite
      - sensor.bt_h_salle_de_bain
  action:
    service_template: >-
      {% set hi = (states('input_number.consigne_humidite') | float) + 2.5 %}
      {% set lo = hi - 5 %}
      {% set humidity = states('sensor.bt_h_salle_de_bain') | float %}
      {% if humidity > hi %}
        switch.turn_on
      {% elif humidity < lo %}
        switch.turn_off
      {% else %}
        switch.turn_{{states('switch.ipx800_7_vmc') | lower}}
      {% endif %}
    entity_id: switch.ipx800_7_vmc

ECS

Programmée aux heures creuses, toutes nuits en hiver et un jours sur deux en été. (il me reste à bricoler un input_qq_chose pour définir les lancements car il n'y a pas que hiver ou été comme variables, le nombre de personnes présentes est également un paramètre, et comme le chauffe eau est vieillissant pour l'instant ça sera toutes les nuits).

- alias: 'Q : ECS ON : Lancement Quotiden'
  description: ''
  trigger:
    platform: time
    at: '01:00:00'
  condition:
    condition: and
    conditions:
    - condition: state
      entity_id: input_boolean.thermostats_away # Prendre en compte le mode abscent
      state: 'off'
    - condition: time
#      after: '15:00:00' # Juste pour l'exemple
#      before: '02:00:00'
      weekday:
        - mon
        - tue
        - wed
        - thu
        - fri
        - sat
        - sun
  action:
  - service: switch.turn_on
    entity_id: switch.ipx800_7_ecs
  - service: notify.slack_hass_canaletto
    data:
      message: ECS Quotidienn ON à {{ states.sensor.time.state }}

- alias: 'Q : ECS OFF : Lancement Quotiden'
  description: ''
  trigger:
    platform: time
    at: '05:00:00'
  action:
  - service: switch.turn_off
    entity_id: switch.ipx800_7_ecs
  - service: notify.slack_hass_canaletto
    data:
      message: ECS Quotidienn OFF à {{ states.sensor.time.state }}

Groupage de thermostats

By design le thermostat générique ne permet de gérer qu'un seul actionneur. Pour palier à cet inconvénient, mais également pour pouvoir appliquer des actions ou des valeurs à plusieurs thermostats il existe l'intégration climate_group qui va nous permettre de définir des groupes de thermostats qui seront ainsi vus comme un seul. Il est même possible de créer une carte avec ce groupe qui reprendra la moyenne des températures remontées sur chaque thermostat et d'y affecter une valeur de garde unique. Si cette dernière possibilité est inutile, je vais utiliser le groupe climate_jour avec de 3 thermostats dans ma zone de vie et le groupe climate_all pour allumer ou éteindre le chauffage avec le ON/OFF d'un un input_boolean.

  climate:
  - platform: climate_group
    name: 'Climate Jour'
    entities:
    - climate.thermostat_bureau
    - climate.thermostat_cuisine
    - climate.thermostat_hall

  - platform: climate_group
    name: 'Climate All'
    entities:
    - climate.thermostat_bureau
    - climate.thermostat_cuisine
    - climate.thermostat_hall
    - climate.thermostat_salle_de_bain
    - climate.thermostat_sejour
    - climate.thermostat_lionel
    - climate.thermostat_antoine
    - climate.thermostat_marie

Attention : pour l'instant ce composant ne supporte pas set_preset_mode qui permet de passer un thermostat en mode absent. C’est en discussion sur GitHub.

Surveillance

Comme expliqué plus haut j'ai choisit de générer des messages Slack pour chaque événements, delà me permet d'avoir un journal. Pour le debug on peut également surveiller ce qui est en place sur le dashboard, notamment au niveau des températures avec ce genre de graphique (interactif en passant la souris sur les courbes) :

Consommation

En ces temps ou l'énergie est de plus en plus coûteuse il devient opportun d’installer des compteurs d'énergie. Certains modules, Shelly par exemple, présentent l'avantage de remonter cette information, instantanée et cumulée. Cela pourra permettre d'afficher la consommation, mais également, avec un peu d’huile de coude, d'en calculer le coût. On peut également utiliser un Shelly EM avec des pinces pour mesurer la consommation d'un segment, ce que j'ai fait ici pour ma baie informatique et l'arrivée EdF, alors que la troisième ligne prends en compte le comptage d'un dimmer.

L’insertion de compteurs ou de pinces n'est pas facile dans un tableau existant utilisant des peignes. Legrand a bien annoncé des modules disjoncteurs ou différentiels intégrant cette fonction, mais outre leur tarif qui sera élevé, rien ne dit que le protocole (Zigbee) sera suffisamment ouvert pour s'en servir dans Home Assistant, mais c’est à considérer pour du neuf. En rénovation on préférera des module au dos des convecteurs ou les blocs de 4 relais DIN proposés par Shelly.

Re-Planification

Pour toutes ces automatisations on part du postulat que :

1. La machine qui héberge Home Assistant est fiable et secourue par un UPS.
2. Les actionneurs savent retrouver leur état initial après une coupure électrique. En ce qui me concerne c’est le cas des Shelly mais également de ma carte IPX800 v2. Pour les autres (modules X2D ou DI-O en 433 Mhz. par exemple, il faudra les remplacer s'ils sont stratégiques, du reste ils sont gérés par le RFPlayer sur mon Jeedom en esclave qui lui aussi devra à terme disparaître.

Si on respecte ça, une coupure du réseau électrique n'affectera pas le chauffage au retour, pas plus qu'un redémarrage de Home Assistant puisqu'on dans tous les cas on n'a pas de WAIT mais des automations de fin de cycle.

GéoLocalisation

La géolocalisation fonctionne tellement bien sous HA, que ce soit via l'application ou via le partage de position sur Google Maps, que ça me donne envie de l'utiliser. On peut également utiliser le plugin Unifi pour gérer une présence basée sur le WI-FI vraiment locale, alors que via Google Maps on pourra gérer des approches.

Avec des convecteurs la montée en chauffe est assez longue, par contre dans le cas d'un climatiseur il est possible d'obtenir un bon rafraîchissement d'une pièce en une dizaine de minutes. On peut donc facilement imaginer d'activer un climatiseur quand un utilisateur sort de sa zone Travail pour rentrer chez à son domicile et ainsi ne pas perdre en confort s'il rentre trop tôt, ou ne pas consommer de l’énergie inutile s'il rentre trop tard.

Conclusion

J'ai longtemps été sceptique sur la possibilité de remplacer Jeedom, et j'ai longtemps repoussé. J'avais peur de ne pas pouvoir faire ce que je fais avec Jeedom pour le chauffage, ce n’est pas le cas, tout est possible avec Home Assistant, par contre il faut rentrer dans le concept, ce qui finalement m'a pris bien moins de temps que quand j'ai transité de la ZiBase à Jeedom.

Le résultat est concluant et me semble bien plus fiable, on verra à l'usage, mais surtout je ne suis plus tributaire de certaines mises à jours de plugin hasardeuses. Finalement pas sur que ça m'ai pris plus de temps qu'un passage de la v3 à la v4 de Jeedom.

Maintenant que j'ai défini le concept de ma gestion du chauffage il va me falloir finaliser, dupliquer les blocs de code, les ajuster, tester encore et basculer réellement de Jeeom à HA. Je ne serait pas aidé par la météo qui est ici très clémente cet hiver (19.5° ce midi). Une fois terminé, j'ajusterais cet article en fonction des modifications éventuelles.

N’hésitez pas à commenter.

Next !

Il me reste à nettoyer tous ces codes et à les publier sur GitHub !