Home Assistant & Planification, Schedy !

l'inconvénient du Scheduler que je vous avait présenté ici c'est qu'il ne fait pas de replanification et il se contente uniquement d'une action (avec ses contraintes) en début de plage, ce qui impose de devoir programmer la plage suivante. De fait si pour une raison quelconque l'appareil ou le thermostat n'a pas reçu l'ordre, c'est raté. De même il est impossible d'imposer une contrainte supplémentaire après le départ, la notion d'humidité utile pour la clim par exemple, ou encore l'arrivée d'une personne qui ne supporte pas la clim. Pour résumer le Scheduler c'est une action avec des contraintes en début de plage uniquement, là ou Schedy va savoir replanifier dynamiquement en fonction des nouvelles contraintes pendant le déroulement d'une plage. Et ça change tout !

Je vous passe l'installation, ça sous entend app_daemon et j'en ai déjà parlé ici. L'utilisation de Schedy est très simple. Tout se passe dans un seul fichier .yaml et si vous êtes le seul occupant de la demeure ce sera parfait car il suffit d'aller changer les valeur et de sauvegarder pour que les modifications soient prises en compte dynamiquement. Ce mode dynamique est le gros plus des applications app_daemon. Je vous la fait courte car la doc est très bien faite et vous y trouverez d'autres exemples, qui d'ailleurs ne s'appliquent pas uniquement au chauffage. Voici la partie principale du fichier de configuration de Schedy :

      schedule:
      - v: 20
        rules:
        - weekdays: 1-5
          rules:
          - rules:
            - x: "Next() if heating_mode() == 'Normal' else Break()"
            - { start: "06:00", end: "07:30" }
            - { start: "15:00", end: "22:30" }
          - rules:
            - x: "Next() if heating_mode() != 'Normal' else Break()"
            - { start: "08:00", end: "23:30" }
        - weekdays: 6-7
          rules:
          - { start: "08:00", end: "23:30" }

Si vous voulez changer un horaire, un mois ou une saison, il suffit le le faire ici.

Un GUI pour Schedy...

A la base Schedy ne dispose pas d'une interface et n'a pas été développé dans ce sens. Le produit est très stable et son auteur n'a plus trop le temps de le faire évoluer, pour l'heure il se contente de la maintenance.

L'idée ici n'est pas de fournir une planification plug & play pour l'administrateur, mais que celui-ci permette à un utilisateur lambda de modifier les plages et la température de garde associée à chacune d'elles. On va gérer ici 4 plages par thermostat (matin, midi, soir et nuit), sachant que l'on pourrait juste les numéroter et en créer plus ou moins. On dispose également d'une consigne pour la température qui sera appliquée en dehors de ces plages (et qui n'a rien à voir avec le mode hors gel qui lui se gère sur le thermostat.

On va se servir du mode mode "package" de Home Assistant, ce qui va nous permettre d'avoir dans un seul fichier .yaml tous les composants nécessaires pour accompagner notre thermostat. Pour ça il vous faudra faire une petite modification dans le fichier de configuration :

homeassistant:
  packages: !include_dir_named packages

Schedy n'a pas de GUI mais dispose toutefois d'une mince ouverture pour communiquer avec Lovelace et on va ainsi pouvoir lui adjoindre une interface minimale, mais sur mesure. On aurait pu penser à ce qu'il utilise des input_datetime: pour les horaires, mais non la seule possibilité réside dans des input_number: ou sensor: au travers desquels on va faire passer les températures de consigne et les heures de début et de fin des plages. Et pour les horaires (ça m'a pris du temps à comprendre) il faut lui donner l'heure sous la forme d'un nombre en minutes écoulées depuis minuit. Donc si on veut qu'une plage débute à 02:00 il faut lui donner 120. Ca ne s'invente pas !

Il va donc nous falloir traduire les input_datetime: qui vont permettre la saisie d'un horaire (à dupliquer par le nombre de plages à gérer) :

input_datetime:
  ac_start_1:
    has_date: false
    has_time: true
  ac_stop_1:
    has_date: false
    has_time: true

En sensor: afin de ne pas avoir à saisir le nombre de minutes... (Merçi @mathieu !) (à dupliquer par le nombre de plages à gérer) :

sensor:
  platform: template
  sensors:
    ac_start_1:
      friendly_name: "AC Start 1"
      icon_template: mdi:timer-sand
      value_template: "{{ (state_attr('input_datetime.ac_start_1', 'timestamp') / 60)|int }}"
    ac_stop_1:
      friendly_name: "AC Stop 1"
      icon_template: mdi:timer-sand
      value_template: "{{ (state_attr('input_datetime.ac_stop_1', 'timestamp') / 60)|int }}"

On va également créer des input_number: pour les températures de consigne (à dupliquer par le nombre de plages à gérer, sans oublier la température hors plages) :

input_number:
  ac_max_1_temp:
    name: Ac Temp 1
    min: 14
    max: 26
    step: 0.5
    unit_of_measurement: °C

On ajoute un input_boolean: pat plage, il va nous permettre d'activer ou désactiver la plage :

input_boolean:
  ac_1:
    name: AC 1
    icon: mdi:account-check

De façon plus globale on se servira également d'un binary_sensor:  sur lequel reposera l'activation du chauffage, un autre pour la climatisation (je pense que ça peut également être des input_boolean:). Au chapitre des contraintes j'ai déjà un input_boolean: qui me sert au mode absent. Il est également possible d'utiliser workday: dans les contraintes et ainsi définir des plages qui s'exécuteront soit les jours de travail, soit le week-end. Mais on peut s'en passer et gérer ça dans Schedy, l'avantage restant à workday: qui lui gère les jours fériés.

Voici la première partie du fichier de configuration de la partie Schedy :

schedy_heating:  # This is our app instance name.
  module: hass_apps_loader
  class: SchedyApp

  actor_type: thermostat

  expression_environment: |
    def time_between(start, end):
        current = time.hour * 60 + time.minute + 1
        if start >= end:
            return current >= start or current < end
        return current >= start and current < end
  
  schedule_prepend:
  - x: "Mark(OFF, Mark.OVERLAY) if not is_empty(filter_entities('binary_sensor', state='on', window_room=room_name)) else Next()"
  - x: "OFF if is_off('binary_sensor.heating_enabled') else Next()"

  watched_entities:
  - binary_sensor.heating_enabled

La première partie  concerne la déclaration de l'application app_daemon. Ensuite le type d'utilisation et l'environnement qui va nous permettre de récupérer les informations de planification depuis Lovelace. On trouve ensuite la gestion des ouvertures (Voir plus bas en détail) et du mode OFF du chauffage. La dernière ligne concerne la déclation des entités HA que nous utilisons dans cette partie, ici le binary_sensor: du ON/OFF.

La suite concerne les pièces avec leurs thermostats associés :

rooms:
    bureau:
      rescheduling_delay: 120
      actors:
        climate.thermostat_bureau:
       
      watched_entities:
      - binary_sensor.bureau_door_delayed
      - input_number.day_temperature
      - sensor.ac_start_1
      - sensor.ac_stop_1
      - input_boolean.thermostats_away        # Mode Absent qui pourrait également être dans les paramètres globaux
      - input_boolean.ac_1
      # - binary_sensor.workday_sensor

      schedule:
      - months: 1-4
        weekdays: 1-6
        rules:
        - x: state("input_number.day_temperature") if (state("input_boolean.ac_1") == "on") and (state("binary_sensor.bureau_door_delayed") == "off") and  (state("input_boolean.thermostats_away") == "off") and time_between(int(state("sensor.ac_start_1")), int(state("sensor.ac_stop_1"))) else Next()
      - v: 19

Outre le thermostat on déclare ici les différentes entités que l'on va utiliser.

La ligne importante est la plus longue à la fin. On commence par la température, l'activation ou nom de ce planning, la gestion de l'ouverture, le mode absent qu'il me faudra déplacer dans les paramètres globaux et l'heure de début et de fin. On remarque également que je n'ai ici pas utilisé workday: mais que j'ai choisit de laisser (pour l'exemple) les jours et mois ou cette planification peut s'exécuter (on peut également utiliser la saison). La dernière ligne concerne la température de consigne qui sera appliquée en dehors des plages. Il est également possible de la gérer depuis Lovelace avec l'input_number: idoine.

Les ouvertures

Curieusement l'auteur a prévu de gérer les ouvertures, mais il n'a pas intégré la notion de délai. Ainsi de base si on ouvre une porte ou une fenêtre on coupe le convecteur immédiatement, ce qui n'a pas de sens si on ne fait que rentrer ou sortir, alors que ça en aurait si on ouvre une fenêtre pour aérer une pièce plus longuement. D'ailleurs si ça n'a pas d'impact sur un convecteur, le résultat sera bien différent pour un climatiseur pour lequel les changements d'état on souvent une grande latence. On va donc devoir jouer des avec les templates et ainsi créer des retardateurs pour les ouvertures (et non je ne pousserait pas le vice jusqu'à aller gérer les delais dans Lovelace...) (la partie icon_template: est vraiment là pour l'exemple car il n'y aucun intérêt à afficher ça dans Lovelace) :

binary_sensor:
  - platform: template
    sensors:
      garage_door_delayed:
        friendly_name: "Delayed Garage Door"
        #window_room: bedroom
        delay_on: 
          seconds: 180
        delay_off:
          seconds: 360
        value_template: >-
          {{ is_state('binary_sensor.porte_garage', 'on') }}
        icon_template: >-
          {% if is_state('binary_sensor.porte_garage', 'on') %}
            mdi:door-open
          {% else %}
            mdi:door-closed
          {% endif %}

Le froid

Toute cette partie peut s'appliquer à des convecteurs ou climatiseurs en mode chauffage. Pour le mode froid le fonctionnement est un peu différent, on va gérer un seuil de déclenchement et une température de maintient, alors qu'en dehors des plage on éteindra le climatiseur (ici dans la dernière partie).

Epilogue...

Pour cet article, qui m'a pris un peu trop de temps, je me suis bien sur inspiré de mon expérience puisée dans le documentation de Schedy et le fil de discutions du forum Home Assistant. Mais j'ai également trouvé le GitHub d'un utilisateur ou il présente sa configuration. Je vous invite à aller y puiser des idées, et vous remarquerez qu'il a choisit une présentation un peu différente pour la saisie des plages horaires à l'aide de sliders. En ce qui me concerne j'ai préféré compacter au maximum cette partie, même si toutes les fantaisies sont possibles. Pensez à revenir car j'enrichirait cet article dès que j'aurais le temps de continuer.

Home Assistant & Planification, la suite !

Ce qui déroute souvent quand on débute avec Home Assistant c'est l'absence de planificateur intégré, alors même que la chose parrait évidente. Il y a tout de même plusieurs façons de planifier des évènements et on a déjà examiné ici plusieurs solutions :

  • En codant des des automation basées sur des input_time, etc... On peut obtenir quelque chose de très personnalisé. Mais il faut pas mal d'huile de coude.
  • Avec des agendas externes comme Google Agenda ou Microsoft 365, ou encore des agendas plus geeks... (ics, etc).

Il y a une autre solution qui bien que dépourvue d'interface est vraiment très puissante, mais un peu compliquée à appréhender. Je veux parler de Shedy. Ca impose d'installer AppDaemon et ensuite ça se passe en YAML, à ceci près que sous AppDaemon la prise en compte des modifications apportées au code YAML est dynamique, et ça c'est très sympa.  AppDaemon c'est un addon qui s'installe dans la section addon de HA et je m'en sert également pour ControlerX. Dans toutes ces solutions, seul Shedy sait faire de la replanification dynamique, c-a-d que toutes les x minutes il reconsidère l'état de tous les paramètres, là ou les autres se contentent de faire ON au début et OFF à la fin (ou augmenter la consigne et la baisser).

Depuis peu il y a aussi les BluePrint, ça va changer beaucoup de choses sous HA et surement permettre de proposer des planifications simples et prêtes à l'emploi.

On a peut être aussi des possibilités avec NodeRed, mais pour moi c'est non, vous le savez, je n'aime pas. Bon, blague à part, c'est bien et même intéressant, surtout pour ceux qui ne réussissent pas à entrer dans la logique yaml, ce qui se comprends très bien. Mais dans l'absolu ça n'a pas besoin de HA, à part pour l'interface, ah oui NR n'a pas d'interface utilisateur, juste une interface dev. Bon, après chacun son truc.

Et puis il y a le Scheduler dont je veux vous parler aujourd'hui et pour lequel je vous conseille de suivre cette conversation.

L'idée de son auteur est de créer un scheduler entièrement graphique, donc à l'opposé de Schedy. A vrai dire j'aurais préféré qu'il fasse une interface pour Schedy. Mais les développeurs sont ce qu'ils sont et lui est parti sur deux modules, un composant moteur et une carte d'interface. Du coup si l'interface est très réussie il reste encore des choses à voir coté motorisation pour arriver au niveau de Schedy, qui lui gère notamment la notion de re planification dynamique. Attention, ce n'est pas un reproche, Niels a fait un travail remarquable en très peu de temps, et comme c'est un perfectionniste, je ne doute pas qu'au fil des semaines cet outil, déjà totalement utilisable, gagnera en fonctionnalités.

Je vous passe les détails de l'installations décrits ici, et , en gros on installe le composant depuis HACS, on redémarre et on installe la carte. Ensuite on va créer une carte à laquelle on attribuera des objets à planifier avec des conditions. Par exemple, je veux que le thermostat de la cuisine passe à 21° tous les matins à 07:15 et qu'il repasse à 19.5° à 09:00 (avec plusieurs plages possibles dans la journée), mais à condition que nous soyons en semaine, que le commutateur qui autorise le chauffage soit à ON et que je ne soit pas en voyage, etc...

On va donc créer une carte avec les objets dont on a besoin que l'on peut choisir par type ou mieux individuellement. Par exemple un thermostat, et les input_bolean: Chauffage ON/OFF et Mode Absent ON/OFF : 

Je prends l'exemple des thermostats qui me préoccupait, mais on peut bien sur planifier tout ce qui est actionnable, directement, via des scripts ou des scènes.

Il est bien sur possible de faire ça par le code, ce qui permet en plus d'ajouter des options de présentation de la carte. Personnellement j'ai choisit d'utiliser une carte de type "Vertical Stack" "Panel Mode", ce qui sera bien plus agréable à utiliser pour planifier une journée. Ce mode n'est pas très adapté au mobile, mais c'est le genre de choses que je fais depuis mon PC.

type: vertical-stack
cards:
  - type: 'custom:scheduler-card'
    discover_existing: false
    display_options:
      primary_info:
        - '<b>{entity} / {name}</b>'
      secondary_info:
        - >-
          <b>Next</b> : {relative-time} ({days} {time}) | <b>Action</b> :
          {action} ({additional-tasks})
      icon: 'mdi:radiator'
    include:
      - climate.daikin
      - input_boolean.thermostats_ac_on_off
      - input_boolean.thermostats_away
      - input_boolean.thermostats_on_off
      - input_select.chauffage
    title: AC Daikin
  - type: 'custom:scheduler-card'
    discover_existing: false
    display_options:
      primary_info:
        - '<b>{entity} / {name}</b>'
        - '<b>Next</b> : {relative-time} | <b>Action</b> : {action}'
        - additional-tasks
      secondary_info:
        - '{days} {time}'
      icon: 'mdi:radiator'
    include:
      - climate.thermostat_lionel
      - input_boolean.thermostats_ac_on_off
      - input_boolean.thermostats_away
      - input_boolean.thermostats_on_off
      - input_select.chauffage
    title: Thermostat Chambre Lionel

J'utilise ici une carte de la pile pour chaque thermostat et dans chaque carte je vais pouvoir ajoute plusieurs planifications. Par exemple une pour la semaine et une pour les week-end et jours fériés. A noter que workday: est supporté, ce qui simplifie grandement la gestion des jours férié. A droite de chaque planification on a un interrupteur qui permet d'activer ou désactiver la planification, fonction également possible par une automation. On peut également la laisser activée et la soumettre à une condition pour peu qu'on ait associé l'objet idoine, un input_bolean: par exemple...

Quand on ajoute une entrée on choisit l'objet sur lequel on peut agir, ici un thermostat, on précise l'entité et le type d'action unique à exécuter (allumer, éteindre plus adapté à d'autres équipements, ou mieux de faire un schéma, ce qui sera pleinement adapté à un thermostat :

Par exemple ici j'ai choisit de chauffer le séjour, le week-end, de 08:00 à 22:30 à 21.5°. Sauf que si on laisse la chose en l'état à 22:30 le thermostat continuera à chauffer à 21.5°. La logique actuelle veut que l'on crée une plage suivante avec une autre température, mais également une précédente, contrairement à Schedy qui lui va considérer une température de base (Eco) et uniquement augmenter les plages définies pour revenir ensuite à sa température de base.

Le développeur me répond qu'il ne veut pas faire un planificateur trop spécifique au chauffage. Mais je pense l'avoir convaincu de changer sa logique, et pour chaque plage définie ainsi prévoir une action de début et une action de fin, ce qui me paraitrait un bon début.

Il n'y a pas ici d'options de replanification dynamique. Si Home Assistant redémarre, le thermostat conservera son état (à condition de ne pas utiliser l'option initial_hvac_mode:), par contre face à d'éventuelles coupures secteur, il faut utiliser des actionneurs capables de retrouver leur état avant coupure et de les configurer ainsi. C'est les cas des Shelly ou des cartes IPX800, mais certains actionneurs resteront muets après coupure et ne sont donc pas conseillés pour cette utilisation.

Avec le bouton Options en bas à droite on va pouvoir ajouter des conditions supplémentaires basées sur l'état des entités que l'on aura choisies, ici un input_bolean: qui conditionne le fonctionnement du chauffage. Donc si cette condition n'est pas remplie la planification ne s'exécutera pas, la validation se faisant en début de planification. 

J'ai par exemple un input_bolean: qui conditionne le chauffage des chambres de ma fille et mon fils qui vivent à l'autre bout de la France. Ce commutateur s'actionne soit manuellement, soit en en fonction de leur date d'arrivée que j'aurais saisie (et peut être un jour automatisée en fonction des billets TGV reçus... ou en fonction de leur localisation...).

Voilà pout un petit tour rapide. Alors vous allez me demander pourquoi utiliser une solution plutôt qu'une autre ? Il y a plusieurs questions à se poser, la plus évidente étant de savoir si vous êtes le seul à agir ou si vous voulez un système plus WAF accessible à tous les membre de la maison.

Par exemple j'ai monté un Home Assistant chez mon frère, ce n'est pas un geek et je n'avais pas l'intention d'intervenir chaque fois qu'il souhaite ajuter ses plages de températures. Au départ j'avais basé ses planifications sur Google Agenda, une solution qui fonctionne très bien, mais pas idéale coté expérience utilisateur, en effet cela nécessitait deux interfaces, celle de HA et celle de Google Agenda. De plus les jours fériés n'étaient pas pris en compte (il aurait fallut faire des automations plus complexes). J'ai donc remplacé tout ça par ce Scheduler et ça lui va très bien.

En ce qui me concerne j'ai le nez dans le code et j'avais dès le début fait pas mal d'automations pour gérer les différentes situations (présent, absent, j'ai du monde à diner, à coucher, des amis passent le week-end ici, etc...) et pour l'instant ça reste ainsi. Mais mon installation est également un labo et j'ai installé Schedy pour le tester en live, notamment au niveau des conditions et situations particulières. J'aimerais aussi pouvoir le personnaliser avec un minium de GUI. Je ne suis pas un bon exemple à suivre...

En conclusion je dirais que ce Scheduler est vraiment ce que tout le monde attendait et qu'il couvrira la majorité des besoins. Après il y avait un vague projet de scheduler intégré au core, mais pour l'heure ça reste une arlésienne.

 

Home Assistant & Notifications d'état

Avant, je planifiait mon chauffage avec des automations qui s'appuyaient sur des input_date, input_time pour actionner et input_number pour sélectionner la température de consigne souhaitée et je notifiait dans un journal sur Slack, ce qui me permet un debug facile. J'en avait largement parlé ici, mais maintenant il existe un vrai scheduler et je vais changer ma façon de faire. Sauf que ce scheduler, dont je vous parlerais bientôt, ne dispose pas d'une option de notification. Ca viendra peut être, et ce travail sera peut être à jeter, bien que le principe puisse être adapté à d'autre notifications.

Le scheduler pilotant dans mon cas les thermostats, je vais donc me baser sur les changement d'était du thermostat pour notifier l'état à Slack (voire faire autre chose...). Pour cela je vais stocker les états qui ont changés dans des input_number et des input_text et m'en servir pour notifier avec les bonnes variables.

La liste des courses

J'ai essayé de simplifier en minimisant les besoins, mais il nous faut des input_number: et des input_text:

input_number
  trigger_source_notify_temp_current:
    name: Température Ambiante
    mode: box
    min: 0
    max: 30
    unit_of_measurement: "°C"

  trigger_source_notify_temp_target:
    name: Température de consigne
    mode: box
    min: 0
    max: 30
    unit_of_measurement: "°C"

input_text:
  trigger_source_notify_name:
    name: Trigger Source Name

  trigger_source_notify_hvac_mode:
    name: Trigger Source HVAC Mode

  trigger_source_notify_hvac_action:
    name: Trigger Source HVAC Action
  
  trigger_source_notify_preset_mode:
    name: Trigger Source Preset Mode

  trigger_source_notify_state:
    name: Trigger Source State

Ces "inputs" vont servir à stocker temporairement les valeurs que je vais afficher dans mes notifications.

Une seule automation

Ensuite on va avoir besoin d'une automation qui va :

  1. Se déclencher (trigger) sur les changements d'état pour lesquels on souhaite envoyer une notification. Ici les attributs de deux thermostats.
  2. Ecrire (action) les valeurs liées à la source de déclenchement dans les input_number: et input_text:
  3. Notifier (action) en se servant des valeurs écrite précédemment.
- alias: Notifications des Thermostats
  trigger:
  - platform: template
    value_template: "{{ state_attr('climate.daikin','temperature')  }}"
  - platform: template
    value_template: "{{ state_attr('climate.daikin','preset_mode')  }}"
  - platform: template
    value_template: "{{ state_attr('climate.daikin','hvac_modes')  }}"

  - platform: template
    value_template: "{{ state_attr('climate.thermostat_antoine','temperature')  }}"
  - platform: template
    value_template: "{{ state_attr('climate.thermostat_antoine','preset_mode')  }}"
  - platform: template
    value_template: "{{ state_attr('climate.thermostat_antoine','hvac_modes')  }}"

  action:
  - data_template:
      entity_id: input_number.trigger_source_notify_temp_target
      value: '{{ trigger.to_state.attributes.temperature }}'
    service: input_number.set_value
  - data_template:
      entity_id: input_number.trigger_source_notify_temp_current
      value: '{{ trigger.to_state.attributes.current_temperature }}'
    service: input_number.set_value
  - data_template:
      entity_id: input_text.trigger_source_notify_name
      value: '{{ trigger.to_state.attributes.friendly_name }}'
    service: input_text.set_value
  - data_template:
      entity_id: input_text.trigger_source_notify_hvac_action
      value: '{{ trigger.to_state.attributes.hvac_action }}'
    service: input_text.set_value
  - data_template:
      entity_id: input_text.trigger_source_notify_preset_mode
      value: '{{ trigger.to_state.attributes.preset_mode }}'
    service: input_text.set_value
  - data_template:
      entity_id: input_text.trigger_source_notify_state
      value: '{{ trigger.to_state.state }}'
    service: input_text.set_value

  - service: notify.slack_hass_canaletto
    data:
      message: "{{ states.sensor.date_time.state}} > {{ states.input_text.trigger_source_notify_name.state }} : Consigne à {{ states.input_number.trigger_source_notify_temp_target.state }}° |  
                Température ambiante : {{ states('input_number.trigger_source_notify_temp_current') }}° | 
                Etat : {{ states.input_text.trigger_source_notify_hvac_action.state }} / {{ states.input_text.trigger_source_notify_preset_mode.state }} / {{ states.input_text.trigger_source_notify_state.state }}

Et on obtient une notification dans le journal Slack

2020-12-06, 20:24 > Thermostat : Antoine : Consigne à 13.0° | Température ambiante : 17.1° | Etat : idle / away / heat

Bonus

On peut s'amuser à traduire les messages d'état et ainsi les insérer en clair et en français dans la notification... En bricolant quelque chose du genre :

  {% if is_state('input_text.trigger_source_notify_hvac_action', 'heating') %}
    Etat : Chauffe
  {%-elif is_state('input_text.trigger_source_notify_hvac_action', 'cooling') %}
    Climatise
  {%-elif is_state('input_text.trigger_source_notify_hvac_action', 'dry') %}
    Désumidifie
  {%-elif is_state('input_text.trigger_source_notify_hvac_action', 'fan_only') %}
    Ventile
  {%-elif is_state('input_text.trigger_source_notify_hvac_action', 'heat_cold') %}
    Auto
  {% else %}
    Etat : Inactif
  {% endif %}

  {% if is_state('input_text.trigger_source_notify_preset_mode', 'away') %}
    Préréglage : Absent
  {%-elif is_state('input_text.trigger_source_notify_preset_mode', 'eco') %}
    Préréglage : Eco
  {%-elif is_state('input_text.trigger_source_notify_preset_mode', 'boost') %}
    Préréglage : Boost
  {% else %}
    Préréglage : Normal
  {% endif %}

  {% if is_state('input_text.trigger_source_notify_state', 'heat') %}
    Mode : Chauffage
  {%-elif is_state('input_text.trigger_source_notify_state', 'cold') %}
    Mode : Climatisation
  {%-elif is_state('input_text.trigger_source_notify_state', 'dry') %}
    Mode : Désumidifiation
  {%-elif is_state('input_text.trigger_source_notify_state', 'fan_only') %}
    Mode : Ventilation
  {%-elif is_state('input_text.trigger_source_notify_state', 'heat_cold') %}
    Mode : Auto
  {% else %}
    Mode : Arrêt
  {% endif %}

Voilà, bien entendu tout ça est adaptable à d'autres besoins....

 

Home Assistant IR, AC & More...

Pour piloter un climatiseur avec Home Assistant il existe plusieurs options, mais vu qu'il n'existe pas de protocole unifié (à par peut être KNX que l'on oublie pour des questions de coûts), ça va bien souvent se terminer en IR, là ou une option MQTT sur les interfaces WI-FI des constructeurs aurait été une bénédiction. En dehors de Dalkin qui dispose d'une intégration et Xiaomi (non importé), ces interfaces sont bien sur propriétaires et fermées.

Alors on se rabat sur l'infrarouge, ce qui n'est pas très sexy en 2020 ! D'ailleurs si vous voulez juste piloter une clim avec une application, plutôt que de payer cher une option WIFI du constructeur, pour 80/90 € offrez vous simplement un Tado ou un Sensibo, ça fera le job en mieux et ce sera compatible Alexa et Google Home, avec des intégrations Home Assistant (Tado | Sensibo) à la clé. Sauf que c’est du cloud et que je veux un pilotage local.

On va donc partir sur un Broadlink qui dispose d'une intégration. A la base ce gadget permet de piloter n’importe quel appareil IR depuis une application mobile. Ici on va faire la même chose, mais de puis Home Assistant, et on va voir qu'il existe plusieurs façons de faire, et accessoirement que j'ai perdu bien du temps en ne trouvant pas la seconde option tout de suite...

Intégration du Broadlink à Home Assistant

Ça c'est la première chose à faire dans tous les cas, sans perdre de vue que votre Broadlink sera sur l'application ou sur Home Assistant, pas les deux. Il est toutefois intéressant de l'ajouter une fois à l'application pour récupérer son IP et son adresse Mac.

  1. On supprime le Broadlink de l'application mobile.
  2. Sans le débrancher on lui fait un reset en appuyant 6 secondes avec un trombone.
  3. On ajoute le Broadlink au réseau avec l'application, mais sans le connecter au cloud Broadlink, pas maintenant, pas plus tard. On sort de l'application et on l'oublie.

Ensuite on ajoute ces quelques lignes au fichier configuration.yaml en reportant les infos précédament récupérées et on redémarre HA. Idéalement on place une réservation DHCP sur cette IP.

remote:
  - platform: broadlink
    name: rm4_mini
    type: rm4c_mini  # Ça c'est très important....
    host: 192.168.210.132
    mac: '24:AF:A2:30:0D:E2'

A partir de là on a deux possibilités. La première va consister à apprendre les codes IR et à les restituer. Pour les apprendre on va faire un petit script et se laisser guider par les notifications de Home Assistant pour presser sur les touches idoines au bon moment...

learn_tv_commands:
  alias: Apprentissage IR
  sequence:
  - data:
      command:
      - turn on
      - turn off
      - volume up
      - volume down
      - chanel up
      - chanel down
      device: television_sam
      entity_id: remote.sam
    entity_id: remote.rm4_mini
    service: remote.learn_command

Et on va se retrouver avec les fichier /config/.storage/broadlink_remote_24dfa2300de2_codes qui va contenir nos codes IR, fichier dans lequel il nous suffira d'aller récupérer les bons codes.

{
    "data": {
        "television_sam": {
            "chanel down": "JgDSAJOUEjcTNxQ1ExIUERMSExITERQ2FDYTNhMSExITEhMSFBETERQRExITEhM2FBETEhMSFDYUNRM3FDYTEhM2EzcTNhQABgKWkhQ2EzcUNRQRExITEhMSFBEUNRM3EzYUERMSFBEUERQRExITERQRExIUNhMSFBEUEBQ2EzYUNhM3FBETNhM3EzYVAAYBlpIUNhQ2FDUTEhQRFBEUERMRFDYUNhM2FBEUERQRExIUERQQFBEUERMSFDUVEBQRExIUNhQ1FDYUNhQQFDYUNhQ1FQANBQAAAAA=",
            "chanel up": "JgAYAZSTEzcTNhM3ExIUERMRFBETEhQ2FDUUNhQRExITERUQFBETEhQ2FBEUEBQ2ExIUERQRFDUTEhQ2FDUUERQ2FDUUNhQABgOUkxQ2EzcUNRMSExIUERQRFBAUNhQ2FDUUERQRFBEUERQRFBAUNhQRExIUNRQRFBETEhM2FRAVNRM3FBETNhQ2FDUVAAYClZIVNRQ2FDUVEBQRFBEUERMSFDUUNhQ2FBAVEBMSFBEUERQRFDUUERQRFDYTERUQFBEUNhMSFDUUNhMSFDUUNhM3FAAGApWTFDUUNhM3FBAUERQRFBETEhQ1FTUUNhQRExEVEBQRFBETEhQ1FRAUERQ2FBETERQREzcUERQ1FDYUERQ1FDYUNhQADQUAAAAAAAAAAAAAAAAAAA==",
            "turn off": "JgBGAJGVEzcTNhQ2ERQTEhMSExEUERM3EzcTNhMSExITEhEUExEUERM3ExITEhMREhMTEhMSEzYUERQ2ETkTNhQ2EjgTNhQADQU=",
            "turn on": "JgCMAJWTEzYTNhQ2FBETEhMSExEUERQ2EzYUNhQRFBETEhMSExEUERQ2ExITEhMRFBEUERQREzYUERQ2FDYTNhQ2FDYTNhQABgOVkhQ2FDYTNhQRFBEUERMSExITNhQ2EzYUERQRFBEUERMSExITNhQRFBETEhMSExEUERQ2ExITNhQ2FDYTNhQ2FDYTAA0FAAAAAAAAAAAAAA==",
            "volume down": "JgDSAJSTEzYTNxM3ExIRExMSExITEhM3ETgSOBMSExITERQRExITNxM2ExITNxEUExISEhMSExITEhM3ERMTNxM3EzYSOBEABgSWkxE5ETgTNxEUExITEhISEhMTNxM2EzcTEhMSExIRExMSEzcTNhITEzcRFBMSExIRExMSExITNxEUEjcTNxE4EzcTAAYDlZMTNxM2EzcTEhMSExITERQREzcTNxI3ExITEhMSExITERQ2EzcTEhM2ExITEhMSExETEhMSEzcTEhM2EzcTNxM2EwANBQAAAAA=",
            "volume up": "JgDSAJKVETgSOBE5ERQRExITEhMRFBE5ETgSOBEUERQRExITEhMRORE4EjgRFBEUERQRExITEhMRFBEUETgSOBE5ETgSOBIABgSVkxQ2EzYUNhMSExITERQRFBEUNhM2FDYUERMSExITERQRFDYTNhQ2FBETEhMSExITERQRFBETEhM2FDYUNhM2FDYUAAYClJQTNxM2FDYTEhITEhMSEhMSEzcSNxM3ExISExEUEhISExM3EjgROBITERQRFBEUERMSExITEhMROBI4EjgROBI4EQANBQAAAAA="
        }
    },
    "key": "broadlink_remote_24aca7a1dce2_codes",
    "version": 1
}

Ensuite on va créer un switch qui pourra d'ailleurs en contenir plusieurs... Et avec lesquels ont pourra interagir depuis des automation, scripts ou l'interface Lovelace...

- platform: broadlink
  host: 192.168.210.132
  mac: '24:AF:A2:30:0D:E2'
  type: rm4c_mini  # Toujours aussi important !
  timeout: 15
  switches:
    tv_on:
      friendly_name: "TV Power"
      command_on: 'JgCMAJWTEzYTNhQ2FBETEhMSExEUERQ2EzYUNhQRFBETEhMSExEUERQ2ExITEhMRFBEUERQREzYUERQ2FDYTNhQ2FDYTNhQABgOVkhQ2FDYTNhQRFBEUERMSExITNhQ2EzYUERQRFBEUERMSExITNhQRFBETEhMSExEUERQ2ExITNhQ2FDYTNhQ2FDYTAA0FAAAAAAAAAAAAAA=='
      command_off: 'JgDSAJKUFDYSOBI3ExITEhITEhMSExI2FDcSNxMSExITEhITEhMSExI3ExISExITEhITEhMSEjgSExI3EzcSOBI3EzcSNxMABgOVkxQ2EzcSOBMRFBETEhITExITNhQ2EjcUERQRFBETEhITExITNhMSExITEhMSExEUERM3ExISNxQ2EzcTNhQ2EzcTAAYClZQTNhQ2EzcTERQRFBETEhMSEzYUNhM3EhMSEhMSFBETEhITEjcTEhMSEhMSExITEhITNxITEjgSNxM3EjcTNxM3EgANBQAAAAA='

Ça c'était la version manuelle, c’est pratique car ça permet d'associer n’importe quel appareil piloté par une télécommande IR. Par contre c'est fastidieux et j'ai passé mon après-midi à me dire qu'il était impossible que quelqu'un n'ai pas fait mieux, à savoir une intégration ou je n'aurais qu'à choisir la référence de mon climatiseur pour le commander avec une carte Climate. Et ça existe !

SmarIR

SmartIR s'appuie sur le Broadlink, ou d'autres interfaces IR, qu'il s'agisse de Xiaomi, d'un ESP DIY ou d'un objet en MQTT. Pour le configurer il nous faut avoir intégré notre interface à HA, ici le Broadlink, et installer le composant depuis HACS.

Pour activer cette intégration on ajoute une entrée dans configuration.yaml :

smartir:

Une entrée dans switch.yaml :

- platform: broadlink
  host: 192.168.210.132
  mac: '24:AF:A2:30:0D:E2'
  type: rm4c_mini  # Toujours aussi important !

Et enfin une dernière dans climate.yaml ou l'on n'oubliera pas de reporter le bon code IR : 

- platform: smartir
  name: Office AC
  unique_id: office_ac
  device_code: 1260  # Ici le code IR pour les climatiseurs Toshiba
  controller_data: 192.168.210.132
  temperature_sensor: sensor.temperature  # Ici on peut associer un capteur de température externe
  humidity_sensor: sensor.humidity  # Ici on peut associer un capteur d'hygrométrie externe
  power_sensor: binary_sensor.ac_power

Un petit redémarrage et on est prêt à piloter notre climatiseur comme on le ferait pour n'importe quel thermostat, sauf qu'ici on dispose de toutes les commandes utiles (mixte, chauffage, refroidissement, de-humidification, ventilation) propre au modèle choisit (on ne voit pas

Mon projet portait sur la climatisation, mais avec SmartIR il est également possible de piloter des ventilateurs ou du matériel Audio / Vidéo, pourquoi pas votre magnétoscope VHS ! Et ce qui ne sera pas possible avec SmartIR le sera en mode manuel.

EDIT HA 0.115 : Broadlink est maintenant intégré à HA, donc on vire ce qui est dans configuration.yaml et switch.yaml et on adapte l'utilisation avec le device ID que l'on trouvera dans l'intégration, ici remote.ir_clim_remote :

- platform: smartir
  name: AC Sejour
  unique_id: ac_sejour
  device_code: 1260
  controller_data: remote.ir_clim_remote
  temperature_sensor: sensor.mi_t_carre
  humidity_sensor: sensor.mi_h_carre
  power_sensor: binary_sensor.ac_power

Sources