Danfoss living connect et home assistant

ou comment gérer ses thermostats .

Maintenant que le froid est de retour ( ma femme me le rappelle chaque jour ) , il est temps de sortir de mes cartons mes thermostats Danfoss living connect afin de les connecter à Home assistant et réchauffer la maison.
Je n’ai pas de thermostat d’ambiance , mes thermostats me serviront à contrôler ( limiter) la température dans chaque pièce.

Dans cet article, je vais expliquer comment intégrer et configurer ces thermostats dans HA. Ainsi que les différentes façon de les piloter.
Cet article va permettre de montrer comment utiliser les éléments suivants :

Les entités input select / Number pour gérer les modes de thermostat
Personnalisation des thermostats avec HACS ( Home Assistant Community Store )
Le plugin Appdaemon 4 , pour les remontées de température
Automatisation via fichier de configuration yaml
Automatisation via un Calendrier ( avec intégration caldav, icoud ou synology calendar )
Automatisation via le « scheduler component »
L’intégration workday
Automatisation depuis HomeKit

Une fois mis en place , il sera possible d’obtenir ce style d’affichage.

ou avec la vue » climate thermostat CARD »

Intégration du thermostat danfoss living connect

L’intégration du thermostat Zwave Living connect , se passe de la même façon que n’importe quel appareil Zwave.Dans le menu configuration Zwave , ajouter un noeud. Le thermostat est en mode intégration dés que l’on insère les piles.

Une fois intégré on obtient l’appareil suivant :

Le seul paramètrage dans l’interface « zwave » pour ce thermostat est l’intervalle de réveil. A régler en fonction de vos besoins , pour les pièces ou la température doit être vite changé , il est possible de régler la valeur à 300 ( 5 minutes ) , pour les pièces ou il n’y a pas besoin de changer plusieurs fois dans la journée , il est préférable de régler au minimum sur 600 ( 10 minutes ) voir 900 ( 15 minutes ) afin d’économiser les piles.

Menu zwave / sélection du thermostat a paramétrer

Concrètement , la consigne de température sera changé au plus tard après la durée du réveil .Dans cet exemple l’intervalle de réveil est réglé sur 480 , la modification de consigne aura lieu au plus tard après 8 minutes.

Il faudra en tenir compte lors de la programmation des thermostats .

Pour afficher ce thermostat dans la vue « lovelace » , il faut choisir la carte « thermostat » et sélectionner le thermostat concerné.

On voit tout de suite qu’il manque des infos, la température de la pièce ne remonte pas, seule la consigne s’affiche.
Ce problème est dû au thermostat DANFOSS, qui ne remonte pas la température mesurée par la sonde interne. Mais avant de corriger ce problème , je vais customiser mes thermostats.

Pour limiter les paramètres de réglage du thermostat ( par défaut il est possible de régler de 7°c à 35°C ) , je modifie les paramètres de personnalisation afin de limiter les réglages entre 10 et 23°C.
Dans votre fichier de configuration , si ce n’est pas déjà fait , indiquer votre fichier de personnalisation (dans cet exemple il se nomme customize.yaml )

..... extrait configuration.yaml
####################################################
################# Fichiers Yaml    #################
####################################################
## configuration home assistant
homeassistant:
  customize: !include customize.yaml
  packages: !include_dir_named packages
  
## split yaml
automation: !include automations.yaml
group: !include groups.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
timer: !include timers.yaml
switch: !include switch.yaml
sensor: !include sensors.yaml
#binary_sensor: !include binarysensors.yaml
counter: !include counters.yaml
notify: !include notifications.yaml
.....

Dans le fichier customize.yaml , je rajoute ces lignes ( a reproduire pour chaque thermostat )

climate.thermostat_bureau_heating_1:
  max_temp: 23
  min_temp: 10
  hvac_modes: ["heat","idle"]

Cela a pour effet de limiter les réglages de consigne entre 10 et 23 °C. La ligne hvac_modes: [« heat », »idle »] , me permet d’assurer une compatibilité avec homekit.
Dans le menu configuration , redémarrez les fichiers de personnalisation , pour prendre en compte les nouvelles limites.

AppDaemon

Afin de faire remonter la température de la pièce dans le thermostat , il existe un programme développé par : Maciej Bieniek .
Ce programme permet de récupérer les informations d’un capteur de température au thermostat situé dans la même pièce. Ce programme se nomme : thermostat update il doit etre utilisé avec le plugin AppDaemon.

AppDaemon est un environnement d’exécution python , multithread pour le logiciel Home Assistant. Il fournit également un tableau de bord configurable (HADashboard) adapté aux tablettes murales.

Pour l’installer , il suffit de se rendre dans le menu supervisor , Addonstore et rechercher le plugin appdaemon 4 dans la partie community addon.

Documentation de AppDaemon.

Configuration de l’addon

Dans la partie configuration de l’addon , vous pouvez laisser les valeurs par défaut ou modifier le niveau de log ou le port si besoin.

Au démarrage de l’add-on , vous allez avoir un message d’erreur dans le log , vous indiquant que le fichier appdaemon.yaml n’existe pas , bloquant alors le demarrage.

Il suffit de créer le fichier appdaemon.yaml dans le repertoire appdaemon et d’y coller les infos suivantes:

secrets: /config/secrets.yaml
appdaemon:
  latitude: 52.379189
  longitude: 4.899431
  elevation: 2
  time_zone: Europe/Amsterdam
  plugins:
    HASS:
      type: hass
http:
  url: http://127.0.0.1:5055
hadashboard:
admin:
api:

Si le numero de port à été modifié , pensé à le corriger dans le script.
Renseignez vos coordonnées GPS à la place du fichier d’exemple , ainsi que votre time_zone et altitude et verifier le chemin de votre fichier secrets .

Installation de HACS

Le script thermostat update , peut etre installé directement dans le dossier apps de appdaemon , mais je préfére passer par HACS , afin de bénéficier du suivi des mises à jours et d’autres possibilités.

HACS , est un magasin mis en place par la communauté home assistant . Dans ce Magasin il est possible de télécharger des cartes personnalisés , des themes , des plugins , des integrations , des script ….etc …

Cette intégration est indispensable , et si vous ne l’avez pas encore téléchargé , dépêchez vous de le faire.
hass.io

HACS ( Home Assistant Community Store ) dispose de son site ou tout est expliqué pour l’installer.

Les étapes sont les suivantes :

Pré-requis : Avoir un compte GIthub ( vous pouvez vous créer un compte gratuitement ici )
Télécharger la derniére version de HACS
Décompressez le tout et copier le dossier dans le repertoire custom_components , si ce dossier n’existe pas, le créer.

Restart Home Assistant
Création du jeton d’accès Github . Une fois connecté à son compte github , aller sur la page parametrage token et clic sur generation new token. Une fois le token créé , copier ce dernier , une fois la fenetre fermé , il ne sera plus possible de revoir le token, il faudra en régénéré un autre.
Dans home assistant , se rendre dans le menu intégration et clic sur le « + » pour ajouter une nouvelle intégration. Recherche de hacs et ajouter.
Renseigner le token github et valider pour integration.
Clic sur Options dans la carte nouvellement ajouté et choisir les options à affiché.

Puis restart home assistant pour valider les changements.
Lors du premier démarrage de HACS , il va falloir attendre quelques minutes le temps de récupérer la liste des composants disponibles pour chaque rubrique.

thermostat update

Dans le menu HACS , nouvellement installé , je clic sur automation

et je recherche le script thermostat update

sur cette vue , j’ai déjà installer le script , dans votre cas clic sur install. Le script sera copié dans le repertoire appdaemon.

information : affiche les informations de configuration
repository : Lien vers le dossier Github du plugin
dismiss: désactive l’affichage de la carte ( il est possible de la retrouver avec le bouton « + » en bas de page ).

Configuration de thermostat update

A la racine du dossier apps , il faut créer un fichier de configuration yaml : dans mon cas je l’ai nommé thermostats-update.yaml , le nom n’a pas d’importance.Si vous avez déjà un autre fichier de configuration , vous pouvez utiliser celui en place et ajouter les lignes ci dessous en fin de fichier.

Dans ce fichier on renseigne le nom de l’entité correspondant au thermostat et le nom de l’entité correspondant au capteur de température à associé pour chaque pièce.

Par exemple : Dans le bureau j’ai un thermostat qui se nomme climate.thermostat_bureau_heating_1 et le capteur de température dans le bureau sensor.temperature_bureau

Ce qui donne :

thermostats_update:
  module: thermostats-update
  class: ThermostatsUpdate
  rooms:
    bureau:
      thermostat: climate.thermostat_bureau_heating_1
      sensor: sensor.temperature_bureau
    salon:
      thermostat: climate.thermostat_salon_heating_1
      sensor: sensor.temperature_salon

Une fois le script enregistré , restart de home assistant.

Après le redémarrage votre vue thermostat montrera la température de consigne et la température mesurée ( attendre la fin de démarrage du réseau Zwave , avant de voir les premieres infos remontées )

Personalisation de la vue avec lovelace climate thermostat card

Dans HACS , le menu frontend , permet d’importer des nouvelles vues ainsi que des themes. Par l’option recherche ou « + » , parcourir les répertoires afin de chercher l’extension climate thermostat card pour lovelace.

Clic sur install.

Pour information , les nouvelles cartes sont installé dnas le dossier www/community de home assistant.

L’utilisation de la carte est trés simple , il suffit d’ajouter une carte de type manuel et de copier le code suivant.

type: 'custom:thermostat-card'
entity: climate.thermostat_bureau_heating_1
title: Bureau

Gestion des thermostats

Pour changer la température d’un thermostat , je peux utiliser le service : climate.set_temperature

action:
      - service: climate.set_temperature
        data:
          entity_id: 
            - climate.thermostat_bureau_heating_1           
          temperature: 20

l’inconvenient de cette méthode , et que je ne connais pas l’état de mes thermostats , est il en mode confort , nuit , eco ?

Les entrées

Plutôt que d’indiquer directement des valeurs de températures ,je souhaite gérer ces thermostats , en sélectionnant un mode de chauffage parmi quatre modes : Confort / Nuit / Absent / Vacances.

Pour cela je créé une nouvelle entité de type : input_select . Je suppose que toutes ces entrées sont directement écrite dans le fichier configuration.yaml. Si votre configuration est « splitté » , il faudra renseigner le fichier correspondant.

# select mode Bureau
input_select:
  mode_bureau:
    name: Mode Chauffage Bureau
    options:
      - confort
      - nuit
      - absent
      - vacances

Pour les valeurs des modes je créé un input_number pour chaque mode souhaité , cela me permettra de modifier la température par défaut sans avoir à retoucher a l’automatisation.

input_number:
############### Temp pour mode confort
  temp_confort_bureau:
    name: Température Mode Confort pour bureau
    min: 13
    max: 22
    step: 0.5
    unit_of_measurement: "°C"
############### Temp pour mode nuit
  temp_nuit:
    name: Température Mode Nuit 
    min: 13
    max: 20
    step: 0.5
    unit_of_measurement: "°C"
################ Temp pour mode absent
  temp_absent:
    name: Température Mode Absent
    min: 13
    max: 20
    step: 0.5
    unit_of_measurement: "°C"
################ Temp pour mode vacances
  temp_vacances:
    name: Température Mode Vacances
    min: 13
    max: 20
    step: 0.5
    unit_of_measurement: "°C"

J’enregistre et je recharge les fichiers de configuration dans configuration / contrôle du serveur

On obtient la vue suivante :

Automatisation select

Pour que le sélecteur « mode » ajuste la température en fonction de la sélection , j’écris le programme suivant dans « automation »

automation:
### --> Select Bureau
  - alias: chauffage auto select Bureau
    trigger:
      - platform: state
        entity_id: input_select.mode_bureau
    action:
      - service: climate.set_temperature
        data:
          entity_id: 
            - climate.thermostat_bureau_heating_1           
          temperature: >
              {% if is_state('input_select.mode_bureau', 'confort') %}
              {{ states.input_number.temp_confort_bureau.state }}
              {%-elif  is_state('input_select.mode_bureau', 'absent') %}
              {{ states.input_number.temp_absent.state }} 
              {%-elif  is_state('input_select.mode_bureau', 'vacances') %}
              {{ states.input_number.temp_vacances.state }} 
              {% else %}
              {{ states.input_number.temp_nuit.state }}              
              {% endif %}

A chaque changement d’état de input_select.mode_bureau , la température du thermostat bureau sera programmé en fonction de la valeur par défaut renseigné dans le input_number correspondant au mode.

Il suffit de reproduire ses lignes , pour chaque thermostat existant.

Afin d’automatiser les changements de mode de chaque thermostat , il existe de nombreux moyen sous HA de le faire.
Ci -dessous, Je vais m’intéresser à 4 façons de le faire ( via fichier de configuration , calendrier , plugin scheduler ou encore homekit ) , mais ils existent d’autres possibilités ….. HA permet de s’adapter à la préférence et à l’environnement de chacun.

Programmation horaire des thermostats ( via fichier config yaml )

Afin que le thermostat passe automatiquement en mode nuit ou en mode confort , je créé deux entrées supplémentaires input_datetime , afin de basculer automatiquement en mode nuit ou confort. Ces deux entités me servent à déterminer le début de la période confort et la fin de la période confort.

input_datetime:
  start_confort_bureau:
    name: Début Confort Bureau
    has_date: false
    has_time: true
    
  end_confort_bureau:
    name: Fin Confort Bureau
    has_date: false
    has_time: true
### automation
automation:   
  - alias: chauffage auto Bureau
    description: 'gère la commutation auto du chauffage confort / nuit si auto bureau actif'
    trigger:
    - platform: time
      at: 
        - input_datetime.start_confort_bureau
        - input_datetime.end_confort_bureau
 #   condition:
 #   - condition: state
 #     entity_id: input_boolean.enabled_bureau_chauffage
 #     state: 'on'
    action:
    - delay: '1'
    - choose:
      - conditions:
        - condition: or
          conditions:
            - condition: time
              after: input_datetime.start_confort_bureau
              before: input_datetime.end_confort_bureau
        sequence:
          - service: input_select.select_option
            data:
              entity_id: input_select.mode_bureau
              option: 'confort'
      default:
        - service: input_select.select_option
          data:
            entity_id: input_select.mode_bureau
            option: 'nuit'
    mode: single

Dans ce script , j’ai commenté l’utilisation d’une entrée input_boolean , qui me permet de désactiver la programmation horaire si je souhaite ne pas automatiser le changement de mode ( par exemple le mode absent ou vacances ).

   condition:
    - condition: state
      entity_id: input_boolean.enabled_bureau_chauffage
      state: 'on'

Si plusieurs zones horaires sont prévus , il suffit de les insérer dans la liste des conditions ( OR ).

Par exemple Z1 mode confort entre 08H00 et 10H00 et Z2 mode confort entre 16H00 et 20H00

- condition: or
          conditions:
            - condition: time
              after: input_datetime.start_confort_bureau_Z1
              before: input_datetime.end_confort_bureau_z1
          conditions:
            - condition: time
              after: input_datetime.start_confort_bureau_Z2
              before: input_datetime.end_confort_bureau_Z2

Si je suis en dehors de ces horaires , je bascule par défaut en mode nuit.

default:
        - service: input_select.select_option
          data:
            entity_id: input_select.mode_bureau
            option: 'nuit'

Programmation horaire des thermostats ( via un calendrier )

Il est possible dans home assistant de déclencher des événements en fonction d’un calendrier ou plusieurs. Pour illustrer cette partie , je vais utiliser l’intégration caldav de home assistant.

Pour cela , je vais illustrer depuis deux types de calendrier . Calendrier de type icloud ( étant sous mac ) et avec synology calendar .

Pour intégrer un calendrier de type caldav , voici la procédure à suivre , selon le type de calendrier ( icloud ou synology ) , il y aura quelques ajustements :

Calendrier icloud :

Se rendre sur le site https://appleid.apple.com/ afin de créer un mot de passe pour application
Générer un mot de passe et le noter
Configuration du calendrier sous home assistant

calendar:
  - platform: caldav
    url: https://caldav.icloud.com
    username: user_icloud
    password: password application 
    calendars:
      - maison

url : https://caldav.icloud.com ( url par défaut du calendrier icloud ) , ne pas modifier
username : compte icloud
password: le mot de passe pour application généré sur le site Apple
calendars: liste des calendrier à importer ( le nom du calendrier )

Calendrier synology:

Home assistant peut importer aussi des calendrier issus de l’application calendar de synology.

L’application calendar , s’installe via le centre de paquets sur votre serveur synology. Une fois installé , il suffit d’ouvrir l’application calendar , créer son calendrier et positionné des événements. Afin de pouvoir intégrer le calendrier nouvellement ajouté dans Home Assistant , il faut récupérer son URL.

Pour cela on clique , dans la partie droite de la fenetre sur le calendrier , et on sélectionne dans le menu qui apparait « compte caldav »

L’application va afficher les url correspondant au calendrier.

il suffit de copier l’url au format macos/IOS , sous la forme : http://ipserveur:port/caldav/user . La particularité pour intégrer les calendriers de synology est de remplacer caldav par caldav.php avant de renseigner user.

on obtient le fichier de configuration suivant pour home assistant :

## integration calendrier synology calendar
- platform: caldav
    url: https://192.168.1.121:5005/caldav.php/byfeel
    username: byfeel
    password: password compte syno
    verify_ssl: false
    calendars:
     - chauffage

Calendrier personalisé

Quelque soit le calendrier retenu , il est possible de personnalisé plusieurs entités calendrier à partir d’un seul calendrier par le biais des mot clés.

calendar:
  - platform: caldav
    url: https://192.168.1.121:5005/caldav.php/byfeel
    username: byfeel
    password: password compte syno
    verify_ssl: false
    custom_calendars:
    # CALDAV Synology chauffage
     - name: 'bureau'
       calendar: 'chauffage'
       search: 'bureau'
     - name: 'salon'
       calendar: 'chauffage'
       search: 'salon'

Utilisation du mot clé dans search . Il est possible d’utiliser des caractères génériques comme * , par exemple bur* , cherchera tous les mots clé commençant par bur .

Dans cet exemple , je crée deux entités calendrier basé sur les mots clés « bureau » et « salon » , ces deux entités auront pour nom : calendar.chauffage_bureau et calendar.chauffage_salon.
Le nom est construit sous la forme : calendar.nom-calendrier_nom-entité
calendar : Domaine ( ici le domaine calendrier )
nom-calendrier: nom du calendrier option calendar ( ici chauffage )
nom-entité: nom donné à l’option name ( ici salon )

Ce qui nous donne la vue suivante , sur les deux entités

Il ne reste plus qu’a automatiser le changement de mode en fonction des calendriers :

automation:  
  - alias: chauffage bureau via calendrier
    trigger:
        - platform: state
          entity_id: calendar.chauffage_bureau
    action:
        - choose:
          - conditions:
            - condition: state
              entity_id: calendar.chauffage_bureau
              state: 'on'
            sequence:
            - service: input_select.select_option
              data:
                option: confort
                entity_id: input_select.mode_bureau
          - conditions:
            - condition: state
              entity_id: calendar.chauffage_bureau
              state: 'off'
            sequence:
            - service: input_select.select_option
              data:
                option: nuit
                entity_id: input_select.mode_bureau

Il est possible d’améliorer le script , en utilisant les templates et les attributs fournis par l’entité calendar.

Par exemple , voici une vue des attributs de l’entité calendar Salon

Les attributs disponibles sont :

état : on ou off ( on pendant toute la durée de l’evenement )
message: titre du rdv calendrier
start_time et end_time : debut et fin de l’evenement
location: info noté dans lieu du rdv
description: info noté dans le corps du rdv , dans les notes
all_day: true si l’évenement à lieu toute la journée
Offset_reached: Passera à « true » a l’heure programmé plus le décalage. Par exemple si on indique un décalage de -10 , l’attribut sera vrai 10 minutes avant le début de l’événement. Il restera à true , jusqu’a la fin de l’événement.

Pour définir un décalage , il suffit de rajouter dans le titre de l’évenement calendrier les symboles suivants : !! (deux points d’exclamation) + temps en minutes.
exemple :

!!-10 ( pour avancer de 10 minutes ) ou !!+25 ( pour retarder de 25 minutes )

exemple offset -10mn dans événement salon

Exemple d’automatisation , en utilisant les attributs.

  - alias: test calendar attribut
    trigger:
      - platform: state
        entity_id: calendar.chauffage_chauffage_bureau
        to: "on"
    action:
        - service: input_select.select_option
          data:
            option: "{{ state_attr('calendar.chauffage_chauffage_bureau', 'description') }}"         
            entity_id: "input_select.mode_{{ state_attr('calendar.chauffage_chauffage_bureau', 'location') }}"

En utilisant , ici les attributs location et description , il est possible d’écrire une seule automatisation pour tous les evenements. Il suffit d’indiquer le lieu ( bureau, salon, chambre etc ….) et le mode dans le champs description ( confort , nuit , absent … ) . Bien sur , il faudra penser à ajouter dans la partie « trigger » , les autres calendriers

Ce qui permet a chaque début d’événement ( state = on ) , d’appeler le servcie : input_select.select_option et luis transmettre les data :

option: confort , nuit , absent , vacances ( récupéré dans l’attribut description , via les templates )
entity_id: en fonction de l’info inscrit dans « location » , par exemple bureau , le sélecteur de mode choisi sera input_select.mode_bureau

Exemple d’automatisation compléte pour gérer les modes en fonctions des infos dans calendar.
Le nom du calendrier = la piéce du thermostat ( par exemple bureau )
Dans emplacement ( location ) : le mode de chauffage ( confort , absent , etc … )

Par défaut si rien définit , le mode est nuit. La seule condition est que la maison soit en mode présent pour gérer les changements automatique. Si dans un autre mode , l’automatisme ne se fera pas , même si précisé dans l’agenda.

########################################
### automatisation par calendrier ######
########################################
  - alias: Auto thermostat calendar
    description: 'Permet de changer automatiquement les modes selon le calendrier déclencheur'
    trigger:
      - platform: state
# liste de tous les calendrier a surveiller
        entity_id: 
          - calendar.chauffage_bureau
          - calendar.chauffage_salon
          - calendar.chauffage_sdb
    condition:
      - condition: state
        entity_id: input_select.mode_maison
        state: present
    action:
      - choose:
          - conditions: "{{ trigger.to_state.state == 'on' }}"
            sequence:
              - service: input_select.select_option
                data:
                  option: "{{ trigger.to_state.attributes.location }}"       
                  entity_id: "input_select.mode_{{ trigger.to_state.attributes.friendly_name }}"
          - conditions: "{{ trigger.to_state.state == 'off' }}"
            sequence:
              - service: input_select.select_option
                data:
                  option: "nuit"       
                  entity_id: "input_select.mode_{{ trigger.to_state.attributes.friendly_name }}"
#### debug state trigger si besoin de vérifier les différents champs.
#     - service: persistent_notification.create
#        data:
#          message: >
#            nom : {{ trigger.to_state.attributes.friendly_name }}  ,sur location {{
#            trigger.to_state.attributes.location }} avec info description {{
#            trigger.to_state.attributes.description }} ET ETAT A : {{ trigger.to_state.state }}
#          title: test state attribut
#    
    mode: single

Programmation horaire des thermostats ( via scheduler )

Si vous êtes allergiques au fichier de configuration , il existe un composant qui peut permettre de faciliter ces programmations.Il existe une integration disponible avec HACS : SCHEDULER COMPONENT qui permet de gérer des « planificateur » depuis l’interface Lovelace . Il est possible de gérer des volets , lumieres , switch , entrée select , termostat , etc ….

Ce composant est en cours de développement a l’heure actuelle , comporte encore quelques bug de fonctionnement , mais son développeur le corrige au fur et a mesure. Certaines fonctionnalité risquent d’être modifiés , selon la date de lecture de ce document .

un exemple de la planification pour le bureau

Ce programmateur , est facile à mettre en place et simple à comprendre.

Installation du composant scheduler

Dans HACS , Integration , rechercher « scheduler component » et clic sur « install« . « Repository » , vous envoie sur le github du développeur ( Niels Faber ) , ou la procedure d’installation et de configuration est expliqué.

Etapes installation :

installation de scheduler component ( via hacs ) – Les fichiers sont déposés dans le dossier custom_components
Restart Home assistant
Menu integration de Home assistant , recherche de l’integration scheduler et ajouter.

Il est possible d’utiliser cet appareil depuis les fichiers de configuration , mais le plus simple est d’utiliser la carte « Lovelace dédié ».

Ajout de la carte Lovelace Scheduler CARD :

Depuis le menu HACS , Frontend , recherche et installation de la carte Scheduled Card

La carte sera disponible dans l’interface Lovelace.

L’utilisation de la carte est trés simple :

Titre de la carte : Par défaut / Caché ou Personalisé
Show all schedule : Permet d’afficher tous les programmateur ou de n’afficher que ceux définis pour l’entité sélectionné ( mettre sur Off , afin d’avoir une vue par entité pour chaque carte )
Time display : affichage format 12 ou 24 heures
Time step : Par défaut le réglage des planificateurs est toutes des les 10 minutes , il est possible de diminuer ou d’augmenter cette valeur.
Includes entities : Liste toutes les entités disponibles sur HA , susceptible d’être activée par le planificateur ( cocher les entités à contrôler )

Par exemple , j’ai choisis un pas de 4 et le contrôle du « select mode bureau » , ce qui donne ( affichage editeur de code )

type: 'custom:scheduler-card'
discover_existing: false
title: Planificateur test
time_step: 4
include:
  - input_select.mode_bureau

Si aucun réglage n’a été mis en place pour cette entité , j’obtiens cet affichage9looôo

Le planificateur fait appel à la notion de workday ( jours ouvrable ) , afin de planifier les événements. Pour cela , si ce n’est déjà fait , il faut installer l’entité workday.

Integration de workday

L’entité binaire « workday » indique si le jour en cours est un jour ouvrable ou non. Il permet de spécifier quels jours de la semaine compteront comme des jours ouvrables et utilise également le module Python jours fériés pour incorporer des informations sur les jours fériés spécifiques à la région.

Comment le configurer

# dans configuration.yaml
binary_sensor:
  - platform: workday
    country: FR

il existe d’autres paramètres optionnels permettant de modifier le comportement par défaut de workday. En voici quelques uns.

workdays : [mon, tue, wed, thu, fri] – valeur par défaut pour les jours ouvrables , si vous ne travaillez pas le mercredi , vous pouvez enlever ce dernier de la liste avec [mon, tue, thu, fri]
excludes: [sat, sun, holiday] – valeur par défaut , exclus le samedi , dimanche et jours fériés correspondant au code pays ( holiday = jours fériés et pas vacances )
add_holidays: permet d’ajouter des dates personnalisés , comme des vacances ou tout autres dates à exclure qui ne ferait pas partis de la liste des jours fériés. La date doit etre au format : « YYYY-MM-DD » , par exemple pour exclure le 13 Octobre 2020 j’inscris : « 2020-10-13 ».

Retrouver plus d’infos sur le capteur Workday , dans la documentation officiel de home assistant.

La premiere planification

Pour mettre en place son premier planificateur , je clic sur ajouter un item.

Je sélectionne l’entité sur laquelle je veux planifier une action , suivant , puis je choisis l’action à effectuer et l’heure et enfin « sauvegarder ».

Les options jours permettent de choisir :

chaque jour : le planificateur s’execute tous les jours
workdays: le planificateur s’execute les jours de travail ( hors jours férié et wee end ) comme définit dans l’integration workday
weekend : Désigne tous les autres jours qui ne sont pas dans workdays ( weekend = not workdays )
Sur mesure : permet de sélectionner les jours individuellement

Mon planificateur à été créé , a droite une information m’indique l’heure à laquelle sera déclenché ce dernier. Dans mon exemple « demain à 09H00 ».

Pour supprimer le planificateur , clic sur le programme créé et clic sur effacer ( rouge )

Il ne reste plus qu’a programmer autant de planificateur , que d’action nécessaire.

Il y a une option « make scheme » , en cours de développement , qui présente une planification plus graphique. A ce jour ( 12 octobre 2020 ) , lors de mes dernier tests , elle à un fonctionnement aléatoire. Le service s’arrête après la premiere execution , ou se désactive au bout de quelques heures . Pour finir les planificateurs ne fonctionnent plus.

Bonne idée que ce type de planification , très visuelle mais encore trop de bug. Je ne doute pas , que cela devrai vite être corrigé.
Pour l’instant j’utilise les planificateurs standard , mais je surveille les évolutions de ce plugin.

Intégration et automatisation Homekit

Pour terminer cet article , je vais parler de l’intégration des thermostats dans homekit et la programmation de ces derniers via les automatisations homekit. Si vous disposez d’un HomePod ( ou mini ) , appleTV ou iPad ils peuvent être utilisé comme hub , l’application maison de apple peut rendre bien des services.

L’intégration de homekit dans Home assistant , à été simplifié. Il est possible de réaliser une intégration via l’interface UI , ou via la configuration yaml ou même les deux ( possibles d’avoir plusieurs instances homekit ).

Integration via interface UI : Dans le menu intégration , clic sur « + » et rechercher homekit , choisir « passerelle homekit » ( Accessoire homekit , permet d’intégrer dans HA , des appareils gérés par homekit ). Il est possible aussi de configurer via le fichier de configuration ( plus de détail , sur la doc en ligne ) .

Puis sélection des domaines à importer , dans cet exemple je choisis d’importer uniquement le domaine climate ( thermostat ) , je ne peux pas inclure les domaines input_select ( pas pris en charge par homekit ) qui gére directement les modes de fonctionnement.

Si je ne choisis pas d’autres domaines , l’intégration est finis et HA me propose de passer à l’appairage .

Le QR code se trouve dans la partie notification , il ne reste plus qu’a le scanner depuis votre smartphone .

Dans l’application « maison » , clic sur « + » et ajouter un accessoire.

Les thermostats remontent dans l’application maison , il ne reste plus qu’a affecter les pièces.

Pour effectuer une automatisation depuis homekit , il faut faire un clic sur la roue crantée

Ajouter une automatisation , choisir un déclencheur , je choisi à une heure précise

je sélectionne l’heure et les jours de la semaine . Suivant , je clic sur le thermostat et je sélectionne la température souhaitée . Puis OK

Dans cet exemple ,mon thermostat se réglera a 20° tous les jours a partir de 09:18.

Toutes les entités ne sont pas supportés dans homekit , retrouvez le détail ici .Pas possible de remonter le domaine input_select , pour la gestion des modes. Il faut passer par un script ou une scène.

Exemple avec les modes scènes :

Pour créer une scène, menu « scene« , donner un titre, une icône,chercher l’entité correspondant au mode « select » désiré ( ici le mode chauffage bureau), clic sur le mode est sélectionné confort. Sauvegardez le tout. Votre scène bureau confort vient d’être créé.
Pour la remontée dans home kit, il suffit de retourner sur le panneau d’intégration de home assistant, je sélectionne home kit puis options.

sélectionnez les domaine à relier : je coche la case « scene«

soumettre puis rechargez l’intégration.
La scène est disponible dans homekit

Pour créer l’automatisation de la scene , je passe par le menu Automatisation / créer une automatisation / A une heure précise / sélection de l’heure et suivant / sélection du composant mode confort et suivant / choisir l’état allumé et ok

Conclusion

il ne reste plus qu’a choisir une méthode , ou en combiner plusieurs.
De mon coté j’utilise les scripts dans 80 % des cas , mais je bascule petit à petit sur la gestion via calendrier. J’ai mis en test sur une pièce le scheduler , qui permet de changer facilement les horaires via l’interface.

Je me sers de homekit pour ajuster la température si besoin d’un peu plus de chaleur.