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.

Replay. La suite...

J'avais un peu laissé en plan cette idée mais mon climatiseur Daikin perd parfois le WI-FI, donc la notion de replanification de Schedy prend toute son importance. Entre temps @PYG a publié un script qui simplifie grandement la création des différentes entités nécessaires, script à lancer en SSH et que l'on pourra adapter à souhait, ce que j'ai fait ici pour mon climatiseur en mode chauffe, et qu'il me faudra adapter en mode froid (on gère les pièces en ligne 10 et le nombre de périodes en 12).

/bin/bash
test -d /config/packages || mkdir /config/packages
cd /config/packages
cat >heating_global.yaml<<EOF
input_boolean:
  heating_enabled:
    name: Heating Global
    icon: mdi:toggle-switch
EOF
for room in hall_ac
do
for period in {1..4}
do
cat >${room}_heating_period_${period}.yaml<<EOF
input_datetime:
  ${room}_heating_period_${period}_start:
    name: "Heating Period ${period} Start Time"
    has_date: false
    has_time: true
  ${room}_heating_period_${period}_end:
    name: "Heating Period ${period} End Time"
    has_date: false
    has_time: true
sensor:
  platform: template
  sensors:
    ${room}_heating_period_${period}_start:
      value_template: "{{ (state_attr('input_datetime.${room}_heating_period_${period}_start', 'timestamp') / 60)|int }}"
    ${room}_heating_period_${period}_end:
      value_template: "{{ (state_attr('input_datetime.${room}_heating_period_${period}_end', 'timestamp') / 60)|int }}"
input_number:
  ${room}_heating_period_${period}_temperature:
    name: Heating Period ${period} Temperature
    min: 18
    max: 25
    step: 1
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
input_boolean:
  ${room}_heating_period_${period}:
    name: Heating Period ${period} Enabled
    icon: mdi:toggle-switch
EOF
done
done
exit

Ensuite j'ai un peu modifié sa config Schedy afin de l'adapter à mon besoin...

schedy_heating:
  module: hass_apps_loader
  class: SchedyApp
  
  actor_type: thermostat
  
  actor_templates:
    default:
      send_retry_interval: 30
      send_retries: 10
      supports_hvac_modes: true
      off_temp: 18
  
  watched_entities:
  - input_boolean.homeoffice
  - binary_sensor.workday_sensor
  # - binary_sensor.holiday_sensor
  - input_boolean.heating_enabled
  
  expression_environment: |
    def homeoffice():
      return is_on("input_boolean.homeoffice")
    def workday():
      return is_on("binary_sensor.workday_sensor")
    # def holiday():
      # return is_on("binary_sensor.holiday_sensor")
    def time_between(start, end):
        start = int(state(start))
        end = int(state(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: "14 if is_off('input_boolean.heating_enabled') else Next()"
  
  rooms:
    hall_ac:
      allow_manual_changes: true
      rescheduling_delay: 1
      actors:
        climate.daikin:
          template: default
      watched_entities:
      - input_number.hall_ac_heating_period_1_temperature
      - input_boolean.hall_ac_heating_period_1
      - sensor.hall_ac_heating_period_1_start
      - sensor.hall_ac_heating_period_1_end
      - input_number.hall_ac_heating_period_2_temperature
      - input_boolean.hall_ac_heating_period_2
      - sensor.hall_ac_heating_period_2_start
      - sensor.hall_ac_heating_period_2_end
      - input_number.hall_ac_heating_period_3_temperature
      - input_boolean.hall_ac_heating_period_3
      - sensor.hall_ac_heating_period_3_start
      - sensor.hall_ac_heating_period_3_end
      - input_number.hall_ac_heating_period_4_temperature
      - input_boolean.hall_ac_heating_period_4
      - sensor.hall_ac_heating_period_4_start
      - sensor.hall_ac_heating_period_4_end
      schedule:
      - rules:
        # not workday
        - rules:
          - x: "Break() if workday() else Next()"
          - x: >
              state("input_number.hall_ac_heating_period_1_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_1")
              and time_between("sensor.hall_ac_heating_period_1_start", "sensor.hall_ac_heating_period_1_end"))
              else Next()
          - x: >
              state("input_number.hall_ac_heating_period_2_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_2")
              and time_between("sensor.hall_ac_heating_period_2_start", "sensor.hall_ac_heating_period_2_end"))
              else Next()
          - x: "Break(2)"
        # workday
        - rules:
          - x: >
              state("input_number.hall_ac_heating_period_3_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_3")
              and time_between("sensor.hall_ac_heating_period_3_start", "sensor.hall_ac_heating_period_3_end"))
              else Next()
          - x: >
              state("input_number.hall_ac_heating_period_4_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_4")
              and time_between("sensor.hall_ac_heating_period_4_start", "sensor.hall_ac_heating_period_4_end"))
              else Next()
          - x: "Break(2)"
      # default
      - v: 18

Et j'ai créé la carte Lovelace qui va avec...

type: grid
square: true
cards:
  - type: vertical-stack
    cards:
      - type: entities
        entities:
          - entity: binary_sensor.heating_enabled
            name: Etat du chauffage
          - entity: input_boolean.heating_enabled
            name: Activation du chauffage
          - entity: binary_sensor.workday_sensor
            name: Jour de semaine
        theme: teal
        title: AC Daikin
      - type: entities
        entities:
          - entity: input_boolean.hall_ac_heating_period_1
          - entity: input_datetime.hall_ac_heating_period_1_start
          - entity: input_datetime.hall_ac_heating_period_1_end
          - entity: input_number.hall_ac_heating_period_1_temperature
          - entity: input_boolean.hall_ac_heating_period_2
          - entity: input_datetime.hall_ac_heating_period_2_start
          - entity: input_datetime.hall_ac_heating_period_2_end
          - entity: input_number.hall_ac_heating_period_2_temperature
        title: Week-End & Jours fériés
        show_header_toggle: false
        theme: teal
        state_color: true
      - type: entities
        entities:
          - entity: input_boolean.hall_ac_heating_period_3
          - entity: input_datetime.hall_ac_heating_period_3_start
          - entity: input_datetime.hall_ac_heating_period_3_end
          - entity: input_number.hall_ac_heating_period_3_temperature
          - entity: input_boolean.hall_ac_heating_period_4
          - entity: input_datetime.hall_ac_heating_period_4_start
          - entity: input_datetime.hall_ac_heating_period_4_end
          - entity: input_number.hall_ac_heating_period_4_temperature
        title: Semaine
        show_header_toggle: false
        theme: teal
        state_color: true
columns: 1

Et voilà !