TailScale, VPN/SDN simplifié

Avant, il y avait les VPN (PPTP, IPSec, OpenVPN, etc...) qui ne sont pas toujours très simple à implémenter. Et puis arrivent les SDN, qui dans l'absolu sont des VPN, orientés réseaux étendus et très simples à mettre en œuvre. D'aucun le savent, je sus un fan de Zerotier que j'utilise au quotidien, tant pour interconnecter 4 sites à la place d'IPSec, que pour des machines distantes ou quand je suis en déplacement.

Entre temps les barbus nous ont beaucoup parlé de Wireguard, qui peu ou prou fait la même chose en un peu plus compliqué avec de soit disant meilleures performances. Et puis arrive TailScale qui lui est basé sur Wireguard et lui apporte la simplicité. Une sorte de Wireguard pour les nuls, enfin, pas que, car TailScale apporte à WireGuard la notion d'annuaire qui lui manque (WG-Dynamic en cours de dev.). Comme pour Zerotier, au delà d'un certain nombre de nodes il faudra passer à la caisse, mais les tarifs sont comparables, tout comme les possibilités offertes par la version gratuite suffisante pour un usage home.

Comme pour Zerotier, il est possible :

  1. D'accéder depuis internet à une machine particulière avec un client dédié (MacOS, Windows, Linux, IOS, Android).
  2. D'accéder depuis internet à un sous réseau dès lors que l'on installe un node Linux qui servira de routeur
  3. D'accéder depuis internet à internet de façon sécurisée en passant par un node Linux installé en mode Exit-Node, chez vous ou sur un VPS.
  4. D'accéder depuis chez vous à d'autres sous réseaux, bon là c'est plus compliqué et il faudra passer à la caisse et avantage à Zerotier (ou Wireguard, mais je n'ai pas testé).

Le gros avantage de Zerotier est que l'on travaille en Layer-2 sur un subnet dédié avec la possibilité de figer des IP là ou TailScale affecte des IP aléatoires et travaille en Layer-3. Mais les deux peuvent cohabiter, et ça peut être intéressant dans certains cas. Vous trouverez ici un comparatif des deux solutions.

Ce qui est certain, c'est que si moi j'y trouve des limitations, TailScale a pour lui une simplicité qui en fera un bon choix pour ceux qui débutent et veulent juste un usage limité. On va donc se consacrer aux trois premiers points d'usage.

Accéder depuis internet à une machine distante

Je ne vais pas vous expliquer comment créer un compte (il suffit d'aller sur leur site), ou comment se faire coucou entre deux machines clic clic (MacOS, Windows, IOS ou Android), il suffit de lancer l'installation et de faire un ping. Par contre je vais le faire pour la machine Linux qui nous servira dans les deux cas qui suivent.

On part du principe que la machine existe dans sa config minimale et qu'elle communique avec Internet. On en fait un client Tailsacle, ça se passe ici et c'est un peu différent selon les distributions. J'utilise Ubuntu et on commence par ajouter les clés et le repository :

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.gpg | sudo apt-key add -
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.list | sudo tee /etc/apt/sources.list.d/tailscale.list

On fait les mise à jour et on installe :

sudo apt-get update
sudo apt-get install tailscale

On lance le client et on copie l'url pour l'autoriser :

sudo tailscale up

Et voici notre IP :

ip addr show tailscale0

A ce stade si on a un autre client TailScale on peu faire un ping... A noter que sur la console d'admin on va pouvoir définir si la clé expire ou pas...

Si votre but est d'accéder à Home Assistant, il existe un addon qui fera le travail pour vous.

Accéder depuis internet à un sous réseau

Afin de ne pas devoir installer TailScale sur toutes vos machines, et surtout accéder à celle ou il n'est pas possible de l'installer (IoT par exemple), on va installer une machine en mode routeur. Pour l'instant ce n'est faisable que sous Linux, avec un petit RPI ou une VM par exemple... On continue sur la même machine.

Première chose on active l'IP Forwarding :

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

Ensuite on active le routage du subnet :

sudo tailscale up --advertise-routes=192.168.210.0/24

Et pour terminer on va dans la console d'admin indiquer que cette machine servira de routeur pour ce subnet (sous réseau) (les ... au bout de la ligne) :

A partir de là un client TailScale pourra accéder à ce sous réseau.

Accéder depuis internet à internet de façon sécurisée

Quand vous vous connectez en WI-FI sur un hotspot public tout le monde vous dira que ce n'est pas très sécure et qu'il faut utiliser un VPN. Ici plutôt que de payer pour un VPN on va utiliser notre propre connexion, à la maison, ou encore dans un VPS. Pour ça on ajoute la fonction Exit-Node à notre machine :

sudo tailscale up --advertise-exit-node

Et on la configure de facon idoine au même endroit

Ensuite dans le client on choisit l'option Exit-Node afin que tout le trafic transite par notre nouveau point de sortie.

A noter que si l'in veut combiner les deux fonctions, subnet + Exit-Node la commande sera plutôt celle ci :

 sudo tailscale up --advertise-routes=192.168.210.0/24 --advertise-exit-node

Voilà, c'est pas plus compliqué, c'est gratuit et c'est sur. En parlant de gratuit sachez que Free a démarré une beta afin d'intégrer Wireguard dans les Freebox et que Wireguard tout comme Zerotier peut être intégré dans certains routeurs (Unifi, Asus, etc...) ce qui vous évitera la petite machine Linux. Mais ce n'est pas forcément aussi simple.

Sources :

 

Home Assistant & Hygrostat

Longtemps j'ai utilisé l'intégration custom Hygrostat pour forcer la VMC lorsque quelqu'un prend une douche. C'est un détournement en ce sens qu'un hygrostat est plutôt fait pour fonctionner de façon contestante, comme par exemple dans une cave à vin. 

La dernière version de Home Assistant (2021-08) apporte dans son lot de nouveautés un hygrostat intégré. J'ai donc naturellement voulut l'utiliser. Mais celui ci, bien que plous évolué, ne me semble pas fait pour travailler sur un écart rapide d'humidité. Hors le niveau d'humidité dans une maison varie en fonction des saisons et de la la météo. Donc, à moins de l'ajuster manuellement tous les jours, si je règle la consigne sur une valeur arbitraire, le résultat sera aléatoire.

Mon idée, il y a surement d'autres façons de faire, est de calculer la moyenne de la valeur humidité sur les 8 heures passées et d'ajuster dynamiquement la consigne de mon hygrostat toutes les heures (ces deux valeurs restent à affiner).

Mise en œuvre

On commence par déclarer l'intégration dans le fichier de configuration (attention à bien supprimer le custom hygrostat si vous l'utilisiez avant car il a le même nom) :

generic_hygrostat:
  - name: "Hygrostat : SdB"
    humidifier: switch.ipx800_7_vmc
    target_sensor: sensor.rpi_mi_h_sdb
    min_humidity: 20
    max_humidity: 80
    target_humidity: 67
    dry_tolerance: 3
    wet_tolerance: 0
    device_class: "dehumidifier"
    min_cycle_duration:
      seconds: 5
    keep_alive:
      minutes: 3
    initial_state: true
    away_humidity: 35
    away_fixed: True
    sensor_stale_duration: 00:15:00

Pour les détails de sa configuration ça se passe ici.

Je ne me suis pas vraiment intéressé aux autres valeurs possibles, mais dans notre cas on veut déshumidifier, donc attention du device class...

Ensuite je vais utiliser l'intégration Statistics afin de calculer la moyenne du taux d'humidité de la salle de bain durant les 8 dernières heures :

    - platform: statistics
      name: 'Humidité Salle de Bain (moyenne)'
      entity_id: sensor.rpi_mi_h_sdb
      sampling_size: 700     
      max_age:
        hours: 8

Et pour terminer je vais créer une petite automation qui va ajuster la consigne en fonction de cette moyenne en ajoutant + 10 :de façon à ce que la VMC se mette en route si l'humidité monte lors d'une douche :

- alias: '000 : Set Hygrostat'
  trigger:
  - platform: time_pattern
    hours: '1'
  action:
  - service: humidifier.set_humidity
    target:
      entity_id: humidifier.hygrostat_sdb
    data_template:
      humidity: "{{ states('sensor.humidite_salle_de_bain_moyenne') | float + 10 }}"

Il ne reste plus qu'à tester... Et surement à affiner les valeurs.

Alternatives

L'objectif étant de forcer la VMC lors d'une douche il y a d'autres alternatives à explorer :

  • Détecter si quelqu'un prend une douche : ça pourrait se faire en détectant le débit de l'eau... un peu compliqué ! Ou encore avec un détecteur de présence dans la cabine de douche. A creuser.
  • Par un scénario : en hiver quand je dis à Alexa que j'ai l'intention d'aller me doucher, elle lance un script qui va lancer une play list sur Sonos et un radiateur soufflant, ensuite elle me dit (c'est bien la seule à répondre à touys mes souhaits !) quand la température est idéale pour me doucher. Je pourrait inclure la VMC.

Enjoy !

PS : idées et corrections bienvenues...

 

Home Assistant, Zigbee, encore...

Alors, comment dire, dans la série jamais content, le Zigbee... Aujourd'hui ce protocole dispose d'une multitude d'approches plus ou moins simples à mette en œuvre, on résume :

  • Deconz / Phoscon : l'ancêtre toujours vaillant avec les clés Combee I et II ou le module RPI. Ca fonctionne, mais le développement est lent les nouveaux appareils tardent à êtres intégrés. De plus ça nécessite un addon et une intégration, le tout étant moyennement bien intégré. C'est ce qui assure la grande majorité de mes objets Zigbee depuis le début, d'abbord Sous Jeedom et ensuite sous Home Assistant.
  • ZHA (Zigbee Home Automation) : Totalement intégré à Home Assistant c'est la voie la plus simple qui supporte la majorité des clés du marché. Rien à redire, presque trop simple...
  • Zigbee2MQTT : La voie royale de geeks en tout genre, MQTT est à la mode, ce protocole est certes génial, mais franchement si vous débutez en domotique il est tout à fait possible de s'en passer en passant par ZHA.
  • Les passerelles des marques (Xiaomi, Ikea, Hue, etc...) : ça peut faire le job, mais ça restera lié aux équipement de la marque.
  • Les passerelles sous Tasmota, comme la Sonoof : pas testé, donc par essence ça me parait complexe et vaut mieux avoir un pote barbu habile du fer à souder. Idem pour la fameuse SLS dont certains ont du entendre parler.

Si la première des solutions (Deconz) fonctionne exclusivement avec la clé de la marque, ZHA et Zigbee2MQTT savent fonctionner avec toutes les clés disponibles. A commencer par la peu couteuse mais pas très performante cc2531. C'est pas cher et c'est une bonne option pour se faire la main, mais on se rendra rapidement compte que ça manque parfois de réactivité, une faiblesse qui ne sera pas gênante sur des sondes de température, mais qui le deviendra sur des interrupteurs, ou pire des variateurs. On va donc chercher à gagner du temps en explorant d'autres options.

Je vais explorer deux options en utilisant Zigbee2MQTT, mais j'aurais pu faire la même chose avec ZHA si j'avais voulut faire simple.

Clé USB à base de cc2652P

Si on commence à en trouver sur le net, il se trouve que j'ai un pote habile de ses mains qui sait souder et cherche à gagner sa vie en intégrant cette clé. Je lui ai donc acheté une des premières productions il il y a quelques semaines et je l'ai faite fonctionner sous Zigbee2MQTT en replacement de la cc2532.

J'ai un peu galéré sur la config à changer (pan_id) et surtout on passe en Zigbee 3.0 et le ré appairage des équipements est obligatoire, au final surtout fastidieux.

  serial:
  port: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
advanced:
  rtscts: false
  log_level: info
  pan_id: 231  ## Attention à ce point...

La réactivité est bien meilleure et dans l'absolu le nombre d'équipements supportés simultanément bien plus important

La passerelle Xiaomi V3

Là vous vous demandez ce que vient faire cette passerelle que je dénigras plus haut. En fait elle est là car je vais l'utiliser non pas en mode natif avec une liste de devices limitée, mais en remplacement de la clé USB avec Zigbee2MQTT (ou ZHA). La liaison se fait en WIFI, et je peux donc placer la passerelle ou je veut dans la maison. Et cerise sur le gâteau les devices BLE reconnus remontent nativement dans Home Assistant...

La mise en place est un peu plus compliquée car il y a plusieurs façon d'utiliser ça, mais je vais essayer de vous mâcher un peu le travail. D'abord il vous faut une Gateway Xiaomi v3 (ZNDMWG03LM (CN) ou ZNDMWG02LM (EU) et rien d'autre), on en trouve chez AliExpress (27 €) ou Amazon (35/40€), de plus ces temps ci il y en a pas mal en reconditionnées état neuf chez Amazon à 25 €, donc plus simple que d'attendre 3/4 semaines avec le risque que le tanker se mette en travers du canal de Suez...

Une fois que vous avez en main votre nouveau jouet, vous l'ajoutez à Mi Home sans faire les mise à jour proposées (serveur Chine, j'ai pas essayé en serveur Europe mais ça devrait fonctionner également, retour welcome). A partir de là il faut récupérer le token (Mi Home, ou ici par exemple.) et lui assigner une réservation DHCP pour ne pas la perdre.

Ensuite sous Home Assistant :

  • On installe cette intégration via HACS (si vous n'avez pas HACS ou ne savez pas ce dont il s'agit, repassez dans quelques semaines...).
  • On ajoute l'intégration Xiaomi Gateway 3 dans Home Assistant (choisir Host & Token) en renseignant le HOST et le TOKEN et sans toucher aux options Telnet. Si ça ne fonctionne pas c'est surement lié à la version du firmware, firmware qu'il est possible de downgrader via Telnet (et pour une fois sans rien à souder).

Je vous ai perdu ? Pas de panique, tout est expliqué dans le GitHub de l'intégration et Google Translate est notre ami !

Modes de fonctionnement

  1. Natif Mi Home : On remonte dans Home Assistant les devices associables à Mi Home en ZigBee ou BLE (modules Xiaomi, Aqara et quelques ampoules Ikea).
  2. ZHA : La passerelle devient le coordinateur de ZHA et on profite de tous les devices supportés par ZHA. Cette option n'est pour l'instant pas la plus stable.
  3. Zigbee2MQTT : La passerelle devient le coordinateur de Zigbee2MQTT et on profite de tous les devices supportés par cette option. C'est la voie que j'ai explorée.

En choisissant l'option 3 et en considérant que Zigbee2MQTT est bien installé avec son broker, il suffit de modifier la configuration de l'addon en remplaçant la clé USB par un port TCP :

serial:
  port: 'tcp://192.168.210.119:8888'
  adapter: ezsp

Et bien sur de refaire les associations... Et constater une excellente réactivité. Meilleure qu'avec la clé à base de cc2652P, il me semble mais ça reste vraiment très subjectif. En tous cas sans commune mesure comparé à une clé cc2531.

On fait ainsi d'une pierre deux coups avec du Zigbee déporté qui intéressera ceux qui font tourner Home Assistant dans une VM installée au fond du garage, mais aussi la remontée des capteurs BLE, ce qui permettra de faire le ménage dans les intégrations dédiées BLE, et dans mon cas me séparer de mon Home Assistant remote qui supportait les clés USB

Et si on fait l'impasse sur le BLE, je pense qu'une fois la passerelle configurée pour Zigbee2MQTT on peut même désinstaller l'intégration...

Cette solution basée sur du reverse engineering sera pérenne pour peu que vous ne fassiez pas les mises à jour depuis Mi Home, et pour ça il existe dans l'intégration une possibilité de blocage.

EDIT 21/05/2021 : J'observe quelque plantages qui nécessitent le redémarrage de Zigbee2MQTT. Le problème semble venir du driver EZSP et non de la passerelle. Et curieusement ces plantages sont différents selon le type d'équipements. J'ai constaté une certaine allergies aux télécommandes IKEA par exemple... Par contre parfait pour remonter des sondes en BLE. A suivre.

EDIT 01/07/2021 : En l'état pas d'amélioration et inutilisable avec ZHA ou Zigbee2MQTT. Par contre 100% fiable en mode natif Xiaomi Mi Home. Donc parfait pour déporter des devices reconnus dans Mi Home

 

Home Assistant & Unifi Doorbell

Ca faisait un moment que je voulais moderniser la sonnette basic du portail par quelque chose de plus moderne. Il existe bien des solution élégantes de type Ring ou Nest, voire des chinoiseries plus ou moins attrayantes, mais l'inconvénient de toutes ces solutions c'est qu'elles passent par le cloud et que je trouve ridicule une telle dépendance, sans compter qu'il faut passer à la caisse...

En étant déjà équipé Unifi Protect j'ai donc attendu la disponibilité du système Dorbell G4 EU. Ce système fonctionne en WI-FI et la version EU est fournie avec un transformateur au format DIN pour l'alimenter en 24 volts. Donc entre le portail et la maison nous n'aurons besoin que d'une paire en BT et bien sur d'un signal WI-FI convenable.

Le problème est que ce système d'origine US est prévu pour fonctionner en 24 V. AC, le standard US pour ce genre d'équipement. Hors les sonnettes européennes fonctionnent soit en 220 V AC soit en 8 V. AC. Je me suis donc mis dans un premier temps à la recherche d'un carillon fonctionnant avec la bonne tension comme expliqué ici, objet rare sous nos latitudes et avec des commentaires déplorables.

Et puis j'ai réfléchit un peu, le Doorbell G4 remonte dans Home Assistant et j'ai des enceintes connectées dans toutes les pièces, on devrait donc pouvoir se passer d'une antique sonnette...

Après quelques tentatives j'ai utilisé un BluePrint existant (et perfectible) qui va me permettre de notifier avec un message vocal (TTS) une enceinte Google et d'envoyer une notification sur mon mobile avec la photo de la personne qui sonne, ce qui dans la pratique est bien plus efficace que l'application Unifi qui se contente de notifier mais qui ensuite est longue à afficher l'image. De plus si j'avais un portail électrique je pourrais me servir d'une action sur la notification pour l'ouvrir à distance depuis Home Assistant.

Mais tout ça ne sera pas suffisant pour me sortir du lit quant un livreur sonne tôt. Il me faut donc aller plus loin et faire sonner plusieurs enceintes Sonos. Le problème étant que si vous envoyez simplement un son à une enceinte Sonos, ça va certes le jouer au volume en cours, mais également casser l'état et le groupage des enceintes ainsi que le programme courant. J'ai donc créé une automation en parallèle qui va :

  • Sauvegarder l'état courant du système Sonos
  • Ajuster le volume des enceintes choisies
  • Grouper les enceintes choisie pour cette notification
  • Jouer le mp3 de la sonnerie (large choix ici).
  • Restaurer l'état précédent...
- alias: "RC : Doorbell Call Sonos Sound"
  trigger:
    - platform: state
      entity_id: binary_sensor.doorbell_g4_doorbell
      from: 'off'
      to: 'on'
  condition: []
  action:
  - service: sonos.snapshot
    data:
      entity_id: all
  - service: sonos.unjoin
    data:
      entity_id: media_player.sonos_hall
  - service: sonos.join
    data:
      master: media_player.sonos_hall
    entity_id: media_player.sonos_hall, media_player.sonos_cuisine
  - service: media_player.volume_set
    data:
      volume_level: 0.5
    target:
      entity_id: media_player.sonos_hall
  - service: media_player.play_media
    data:
      media_content_id: https://ha.canaletto.fr:8123/local/iphone.mp3
      media_content_type: music
    target:
      entity_id: media_player.sonos_hall
  - delay: 00:00:08
  - service: sonos.restore
    data:
      entity_id: all

Voilà, tout ceci reste perfectible, mais comme on dit, ça fait le job et il me reste à fixer l'objet !

A noter que cet appareil comporte également un détecteur de présence qui pourra ainsi permettre de signaler une présence (facteur ?), et que ce détecteur peut également allumer un led sous l'appareil. Le problème étant qu'il sera fixé dans la rue à la portée du premier vandale venu...

 

 
 

 

 

Home Assistant & Planification, Schedy, la suite !

Encore, allez vous me dire ! Oui car d'une part mon dernier article sur Schedy était un peu fouillis, et surtout en relisant les réponses de son auteur à ceux qui tentent de créer une interface, je me suis aperçu que l'approche que j'avais, qui consistait à faire passer à Schedy des plages horaires, n'était pas la plus simple ni la plus adaptée. D'une part il faut transformer des input_time en sensor ou en input_number (les deux seules possibilité pour transmettre à Schedy un horaire de début et de fin de plage sous la forme du nombre de minutes écoulées depuis minuit). C'est lié à son fonctionnement interne, ce n'est pas très pratique. Son auteur n'a pas le temps de faire évoluer, et surtout c'est un barbu qui déteste les interfaces graphiques...

J'ai donc opté pour une autre approche plus simple et plus concise qui va consister à se servir des input_datetime: de début et de fin de plage pour actionner un binary_sensor: qui passera à ON si on se trouve dans la plage.

A partir de là dans Schedy, on change la température de consigne (input_number:) de la la plage, si la plage est activée (input_boolean:) et la période active (binary_sensor:).

Et bien sur on le fait en fonction des contraintes que l'on s'impose en fonction de la situation de chacun (jour de travail, demie journée de travail, week-end ou télétravail), et tout ça pour chacune des pièces que l'on gère auxquelles correspond un thermostat (climate:) ou un groupe de thermostats.

De cette façon on continue à faire une gestion horaire qui correspondra à la majorité des usages, mais avec ce "mode" binaire on peut très bien imaginer une gestion à base de géolocalisation. Par exemple, en été, si un des membres du logement travaille à une distance de 20 Km, on peut imaginer mettre en route la climatisation s'il se rapproche à moins de 10 Km... Le chauffage (convecteurs + climatiseur) ne se gérant pas comme la climatisation (climatiseur seul) j'y reviendrait prochainement.

Le script

Pour plus de facilité on va utiliser un script afin de créer l'ensemble des entités nécessaires. Dans ce script on crée les entités nécessaires à chaque pièce et le nombre de plages que l'on veut gérer chaque jour que l'on multiplie avec le nombre de jours particuliers à gérer ( jours de semaine, le samedi qui est travaillé le matin et les dimanches et fériés par exemple). 

Pour chaque plage on crée (à chaque plage correspond un fichier qui est stocké dans les pakages) :

  • Deux input_datetime: pour le début et la fin de chaque plage,
  • Un binary_sensor: pour savoir si on est dans la plage,
  • Un input_number: pour définir la température de consigne de la plage,
  • Un input_boolean: pour activer ou désactiver la plage.

On va également créer un fichier heating_global.yaml qui va contenir :

  • Un binary_sensor: s'appuyant sur workday: pour savoir si on est un samedi travaillé,
  • Deux input_number: pour définir la température de consigne pour les plages inactives (deux ou trois car ce n'est pas pareil pour une chambre vide ou un climatiseur),
  • Deux input_boolean: un premier pour activer un mode télétravail, et un autre pour activer / désactiver le bazard.

On pense à éditer les lignes 39 pour définir les pièces et 41 pour le nombre de plages par pièces. On est pas obligé de faite tout d'un coup bien sur (et je vous conseille de commencer light).

/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
  homeoffice:
    name: Home Office
    icon: mdi:toggle-switch
input_number:
  off_temperature:
    name: Off Température
    min: 14
    max: 26
    step: 1.0
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
  off_temperature_ac:
    name: Off Température
    min: 14
    max: 26
    step: 1.0
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
binary_sensor:
  - platform: template
    sensors:
      workday_saturday_working:
        friendly_name: "Samedi travaillé"
        value_template: >
          {% if now().isoweekday() in (5,) and states.binary_sensor.workday_sensor.state == 'on' %}
            true
          {%else%}
            false
          {% endif %}
EOF
for room in hall_ac
do
for period in {1..12}
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
binary_sensor:
  - platform: template
    sensors:
      ${room}_slot_${period}:
        entity_id: sensor.time
        friendly_name: ${room}_Slot ${period}
        value_template: >
          {% set t = states('sensor.time') %}
          {% set start = states('input_datetime.${room}_heating_period_${period}_start') [0:5] %}
          {% set stop = states('input_datetime.${room}_heating_period_${period}_end') [0:5] %}
          {{ start <= t < stop if start < stop else (start <= t or t < stop) }}
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

On teste la configuration (check configuration) et on recharge ce qui est nécessaire (reload input booleans, reload input date times, reload input numbers, reload templates entities).

Les cartes Lovelace

Ici on a deux approches possibles. Un mode normal ou un mode compact. J'ai déjà évoqué le mode normal, mais quand on 12 plages par pièces on va essayer de compacter la chose. C'est un peu plus fastidieux pour saisir les valeurs, mais en général on ne change pas ces valeurs tous les jours.

type: entities
entities:
  - entity: input_boolean.heating_enabled
    name: Activation AC mode chauffage
  - entity: binary_sensor.heating_enabled
    name: Etat global du chauffage
  - entity: binary_sensor.workday_sensor
    name: Jour de semaine
  - entity: binary_sensor.workday_saturday_working
  - entity: input_boolean.homeoffice
  - entity: input_number.off_temperature
  - entity: schedy_room.schedy_heating_hall_ac
    name: Retour Schedy AC
  - label: SEMAINE
    type: section
  - entities:
      - entity: binary_sensor.hall_ac_slot_1
        name: false
      - entity: input_number.hall_ac_heating_period_1_temperature
        name: false
        unit: °
        format: precision1
      - entity: input_datetime.hall_ac_heating_period_1_start
        name: false
        format: relative
      - entity: input_datetime.hall_ac_heating_period_1_end
        name: false
    entity: input_boolean.hall_ac_heating_period_1
    name: Plage 1
    show_state: false
    toggle: false
    icon: 'mdi:calendar-range'
    type: 'custom:multiple-entity-row'
    state_color: true
# >>> Ici les autres avec un séparateur...
show_header_toggle: false
state_color: true
theme: teal
title: Schedy AC
footer:
  type: graph
  entity: sensor.daikin_inside_temperature
  hours_to_show: 24

Et voici le résultat...

Schedy

S'agissant de la configuration de Schedy il a bien sur fallut l'adapter. Vous dire que j'ai tout compris serait un mensonge et il y a certainement moyen de simplifier, et je suis preneur d'idées. Voici donc ce que ça donne (j'ai volontairement laissé quelques commentaires).

schedy_heating:
  module: hass_apps_loader
  class: SchedyApp

  actor_type: thermostat
  actor_templates:
    default:
      send_retry_interval: 15
      send_retries: 20
      supports_hvac_modes: true
      off_temp: 17
  
  watched_entities:
  - input_boolean.homeoffice
  - binary_sensor.workday_sensor
  - binary_sensor.workday_saturday_working
  - input_boolean.heating_enabled

  schedule_prepend:
  - x: "14 if is_off('input_boolean.heating_enabled') else Next()" # Le HorsGel... Possible aussi de créer un input_number...
  
  rooms:
    hall_ac:
      allow_manual_changes: true  # On autorise le changement manuel de consigne ou le passage en off
      rescheduling_delay: 90      # Délais après lequel Schedy repassera sur les valeurs prédéfinies
      actors:
        climate.thermostat_x:
          template: default
      watched_entities:
      # COMMON
      - input_boolean.homeoffice
      - binary_sensor.workday_sensor
      - binary_sensor.workday_saturday_working
      - input_number.off_temperature
      # ROOM SPECIFIC
      - input_number.hall_ac_heating_period_1_temperature
      - input_boolean.hall_ac_heating_period_1
      - binary_sensor.hall_ac_slot_1
      - input_number.hall_ac_heating_period_2_temperature
      - input_boolean.hall_ac_heating_period_2
      - binary_sensor.hall_ac_slot_2
      - input_number.hall_ac_heating_period_3_temperature
      - input_boolean.hall_ac_heating_period_3
      - binary_sensor.hall_ac_slot_3
      - input_number.hall_ac_heating_period_4_temperature
      - input_boolean.hall_ac_heating_period_4
      - binary_sensor.hall_ac_slot_4
      schedule:
      - rules:
        # WORKDAY
        - rules:
          - x: "Next() if is_on('binary_sensor.workday_sensor') else Break()"
          - x: >
              state("input_number.hall_ac_heating_period_1_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_1") and (is_on("binary_sensor.hall_ac_slot_1")))
              else Next()
          - x: >
              state("input_number.hall_ac_heating_period_2_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_2") and (is_on("binary_sensor.hall_ac_slot_2")))
              else Next()
          - x: >
              state("input_number.hall_ac_heating_period_3_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_3") and (is_on("binary_sensor.hall_ac_slot_3")))
              else Next()
          - x: "Break(2)"
        # WEEK-END
        - rules:
          - x: "Next() if is_off('binary_sensor.workday_sensor') else Break()"        
          - x: >
              state("input_number.hall_ac_heating_period_4_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_4") and (is_on("binary_sensor.hall_ac_slot_4")))
              else Next()
          - x: "Break(2)"

      # - v: 13 # On remplace par un input_number >>> Attention : v = valeur, x = expression
      - x: state("input_number.off_temperature") # Consigne entre les plages

A suivre...

Il existe dans Schedy un système d'events qui vont permettre de créer des dérogations ponctuelles. Par exemple un bouton ou une commande vocale quand je vais aller prendre une douche qui va lancer une dérogation pour augmenter sensiblement la température de la salle de bain pendant un temps défini ou jusqu'à ce qu'on lui envoie un contre ordre. On peu aussi imaginer chauffer une chambre d'amis lorsqu'on reçoit ou le boudoir lors d'une galante visite (encore que ces temps-ci la fonction ne servirait pas à grand chose...).

Et bien sur la gestion des ouvertures est gérée pour couper le chauffage... Plus tard...

Pour en finir...

Dans cet usage Schedy n'est plus vraiment le planificateur mais un moteur qui va surveiller (re planification) les thermostats et leur donner les bons ordres en fonction des évènements, états  et ordres venus de Home Assistant. Si Schedy peut également gérer des lampes (light:) et des actionneurs (switch:) c'est sans internet, sauf peut être pour superviser la machinerie d'une piscine...

 

Home Assistant & Coupures secteur

Ceux qui habitent à la campagne le savent, le réseau ERDF/Enedis est dans un état suffisamment lamentable pour que la moindre intempérie provoque des coupures électriques. Par ailleurs il peut arriver que pour une raison ou une autre un différentiel saute. Et ces coupures on un impact sur toute installation domotique, si sur certains appareils on peut gérer le comportement lors de la reprise électrique (Shelly par exemple) ce n'est pas le cas de beaucoup d'ampoules ou de prises commandées (Tuya pour le mauvais élève), il faudra donc gérer ce que l'on fait lors de la reprise en domotique et / ou être avertit en cas d'absence afin de mandater quelqu'un pour réarmer le différentiel du congélateur...

Et pour ça il faut que Home Assistant soit très rapidement informé sur les points de coupure possibles afin par exemple de sauvegarder et restaurer un état comme j'en avait parlé ici. Chez moi je dénombre 4 point de coupures. Le disjoncteur général + 4 disjoncteurs différentiels (1 par étage de mon tableau électrique).

Il me fallait donc un système qui me permette de tester la non présence électrique sur ces 5 points de coupure. Pour y parvenir j'ai commandé une carte qui comporte 8 optocoupleurs (lien non sponsorisé) (ça existe en 1, 3 et 8 canaux) que je vais pouvoir exploiter en GPIO. Le principe est simple, si présence électrique en entrée le port passe à 1.

Au départ je comptais exploiter ça sur le Raspberry qui me sert en remote pour le Zigbee et BLE avec l'intégration GPIO idoine, mais ce n'était pas assez réactif, j'ai donc opté pour un ESP que j'avais sous la main, et c'est ainsi que j'ai mis le doigt dans Tasmota, chose dont je connaissait l'existence grâce à @mathieu qui en fait une promotion quasi sectaire, mais que je n'avais jamais exploré...

ESP8266

Ce module présente l'avantage de s'alimenter en Micro USB, avantage car on a tous dans nos tiroirs des chargeurs et des câbles dans ce format. C'est également avec ce câble que l'on va le brancher sur un PC afin de le Tasmotiser (pas sur que l'Académie ajoute ce verbe cette année). Pour le reste, je ne suis pas spécialiste pour vous parler de ses avantages et inconvénients, ah si, il était présent au fond de mon tiroir.

On lance tasmotizer.exe (ça existe pour d'autres confessions que Windows) et le reste se fait tout seul, ça va même télécharger le firmware idoine. Presque trop facile. Une fois que c'est fait alimente l'ESP et on se connecte dessus en WI-FI afin de renseigner notre SSID dédié IoT. Après un redémarrage on peut ouvrir avec un navigateur et débuter la configuration du module. Je vous laisse trouver comment repérer l'IP et lui faire une réservation DHCP.

Tasmota

Dans la configuration on commence par choisir le type de module (Generic 18) et on configure 5 GPIO en mode SWITCH. Attention tous les ports ne sont pas utilisables, il faut tâtonner un peu quand on ne connait pas la signification des options possibles.

Ensuite on va passer à la configuration MQTT (Host, port, user et password). Et c'est tout. Enfin, il faut tout de même connecter notre carte optocoupleur avec l'ESP avec des câbles Dupont (+3.3, GND et GPIO 1 2 3 4 5).

Intégration

Sous Home Assistant il a plusieurs façons d'exploiter Tasmota (voir ici), en mode pur MQTT pour intégriste barbu (au sens Geek du terme hein !) en déclarant les devices en YAML, en mode MQTT discovery et depuis peu avec l'intégration Tasmota officielle qui va s'appuyer sur MQTT pour créer les devices et les entities. Comme je ne suis pas barbu et que je pense qu'il faut s'ouvrir au plus grand nombre, vous imaginez bien que j'ai choisit cette option.

On ajoute l'intégration avec le bouton + dans les intégrations et on laisse les options de base.

Ensuite on va dans la console du module Tasmota afin de saisir quelques options (que l'on pourrait du reste envoyer en MQTT ou en HTTP...).

SetOption19 0 # Pour lui dire de ne pas faire du discovery en MQTT mais via l'intégration Tasmota

SetOption114 # Pour activer le mode switch

SwitchMode1 2 # Mode folow inversé (0 = on, 1 = off) sur switch 1
SwitchMode2 2 # Mode folow inversé (0 = on, 1 = off) sur switch 2
SwitchMode3 2 # Mode folow inversé (0 = on, 1 = off) sur switch 3
SwitchMode4 2 # Mode folow inversé (0 = on, 1 = off) sur switch 4

Normalement à ce stade il ne nous reste plus qu'à tester notre montage en alimentant chacun des ports en 220 V. Attention, on ne le répètera jamais assez, le 220 V c'est très dangereux, donc on prend ses précautions (et si on ne le sent pas on retourne jouer à la marelle avec ses copines !). Moi je décline bien sur toute responsabilité.

Vous devriez rapidement obtenir quelque chose qui ressemble à ça :

Usage

Il ne restera ensuite plus qu'à exploiter ces binary_sensor: pour des actions ou des notifications, et pour ça je vous conseille l'intégration alert...

alert:
  tableau_1:
    name: Diff 1
    entity_id: binary_sensor.switch2
    state: 'off'   # Optional, 'on' is the default value
    repeat:
      - 10
      - 30
      - 60
      - 300
    can_acknowledge: true  # Optional, default is true
    skip_first: true  # Optional, false is the default
    message: "{{ states.sensor.date_time.state}} > ALERTE | Différentiel 1 : OFF" 
    done_message: "{{ states.sensor.date_time.state}} > ALERTE | Différentiel 1 : OK"
    notifiers:
      - slack_hass_canaletto
      - Free_Mobile

Voilà, presque trop simple. Et merci à ceux qui m'ont aidé à cogiter tout ça !

 

Home Assistant & Alarme

De base Home Assistant contient ce qu'il faut pour construire son propre système d'alarme DIY. Ca fonctionne très bien avec un peu d'huile de coude, et même que certains n'hésitent pas à publier sur ce sujet des articles du genre pute à clics, qui en fait n'expliquent rien et proposent plus de liens sponsorisés que de mots utiles. Soyons sérieux, il suffit de chercher sur Google avec deux ou trois mots clés pour trouver de bien meilleures explications.

De mon coté je ne vais pas vous parler de ça (Alarm Control Panel) mais d'une intégration faite par Niels (le développeur du Scheduler). Cette intégration très poussée va cous permettre de créer un système d'alarme personnalisé en quelques clics de souris.

Attention :  on parle ici d'un système de sécurité DIY, donc non agrée par les assurances et autres... Ca ne veut pas dire que ça ne fonctionne pas, juste que ça ne répond pas aux normes NF en vigueur dans ce domaine.

Alarmo

C'est le nom de cette intégration que vous allez pouvoir installer depuis HACS. Ensuite il suffit de l'ajouter dans le menu des intégrations. Je ne vous fait pas un dessin, comme toujours Niels documente très bien ses créations.

Une fois en place vous allez voir apparaitre Alarmo sur la barre latérale. On clique et obtient la page de configuration qui comporte plusieurs onglets.

Les réglages généraux

je ne vais pas les décrire en détail car ils sont parfaitement explicites, juste vous dire que l'option MQTT servira à communiquer avec des applications tierces, une tablette murale par exemple, mais on y reviendra. Pour le reste on règle des délais, des zones et les différents modes de l'alarme selon que l'on soit absent ou que l'on veuille conserver une sécurité périphérique la nuit. Ou encore un mode personnalisé à customiser.

Les capteurs

Cet onglet nous permettra de les sélectionner et de les adapter à chaque type de surveillance. Par exemple en mode nuit seul les capteurs périphériques (portes et fenêtres seront surveillées alors que les détecteurs d'incendie sont surveillés dans tous les modes. 

Les codes

Ici on va configurer les utilisateurs et leurs codes d'activation. Dans la pratique je trouve qu'ouvrir son smartphone pour rentrer un code est encore moins pratique que de le saisir sur un boitier mural. Il existe une autre option qui n'est pas prévue ici et nécessitera une petite automation, c'est l'utilisation de tags RFID. Par exemple, dans l'automation qui suit, quand je passe mon mobile sur le tag RFID collé sur la porte on va désactiver l'alarme et loguer cette action dans Slack. On pourrait bien sur également en profiter pour exécuter d'autres actions... 

- alias: "Alarm : Action on return"
  trigger:
  - platform: tag
    tag_id: b38qdq2-c0qdsddc-43cds2-8881-c6a7824fa4ff # TAG Porte
  action:
  - service: alarm_control_panel.alarm_disarm
    data:
      code: !secret alarm_code
    entity_id: alarm_control_panel.home_alarm
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M')}} > ENTER HOME | DISARM ALARM | State : {{ states.alarm_control_panel.home_alarm.state }}" 

On peut également utiliser le RFID avec un lecteur de tags et des cartes ou portes clé RFID. Autre possibilité, utiliser une télécommande, un bouton Aqara par exemple qui permettra d'exécuter des actions différentes selon le nombre de clics

Une variante pourrait consister à désactiver par géolocalisation, mais non, mauvaise idée, car si on vous dérobe votre mobile il pourrait servir à désactiver alors que le RFID ne fonctionnera que si ce même mobile est déverrouillé. Par contre on peut imaginer utiliser la géolocalisation pour activer l'alarme en considérant que tous les occupants sont hors zone...

Les actions

Le dernier paramétrage porte sur les actions. On a deux types d'actions possibles, des notifications et des actions plus concrètes. Les notifications (notify.xx) nous permettront de tenir un journal des évènements, sur Slack par exemple, et de notifier une ou plusieurs alarme(s) par SMS en précisant la source de déclanchement. Il est également possible à chaque étape de faire de doubler ça avec des notifications vocales, pour ça je vous conseille de créer des notifiers adaptés au TTS que vous utilisez (ici le cloud Home Assistant NabuCasa). Cela sera par exemple très pratique pour avoir un retour vocal si l'alarme de veut pas s'activer car une fenêtre est ouverte, et vous préciser quelle ouverture il faut fermer, une fonctionnalité gérée par Alarmo.

notify:
  - name: tts_sonos_hall
    platform: tts
    tts_service: tts.cloud_say
    media_player: media_player.Sonos_hall

Les actions permettent quant à elles de déclencher des appareils ou des scripts. On peu par exemple en cas d'intrusion détectée allumer des projecteurs, une sirène ou lancer un script pour combiner des actions plus complexes.

Aller plus loin

Et puis il y a ceux qui aiment les afficheurs de contrôle muraux. Pour ça un autre développeur a créé de son coté MQTT Alarm Panel, un autre système d'alarme conçurent basé sur une application Android qui travaille en MQTT avec Home Assistant. C'est plus primaire, par contre l'interface sur une tablette est parfaite, elle affiche par défaut l'état de l'alarme et en option Lovelace. Et la bonne nouvelle c'est que les deux développeurs sont en train de discuter pour s'entendre entre eux de façon à ce que le projet Android puisse s'adapter facilement à Alarmo. Elle est pas belle la vie open source  !

Notez que...

Pour une efficacité maximale Il est évident que tout ce qui va se rapporter à ce système d'alarme devra être autonome. Home Assistant sur onduleur, mais également les moyens de transmission (routeur, voire routeur GSM), ainsi que les sirènes, etc... Il existe également des sirènes secourues en Zigbee comme la Heiman HS2WD dans sa version Zigbee par exemple, ou encore des sirènes vraiment pas couteuses et très puissantes, bref, pas de liens mais Amazon Et AliExpress sont vos amis...

 

Home Assistant & Shelly

Il y a un an quand j'ai commencé à utiliser des Shelly sous Home Assistant l'évidence était d'utiliser l'intégration tierce Shelly4HASS. Depuis la compatibilité MQTT s'est bien améliorée et j'y ait trouvé un intérêt, alors même  que les équipes de Home Assistant ingéraient le support natif de Shelly au core. Donc aujourd'hui il n'y a plus vraiment d'intérêt à utiliser cette intégration tierce, toujours dans la logique de faire au plus simple. Bien que Shelley4HASS fonctionne toujours très bien et présente l'avantage de fournir beaucoup d'informations dans les attributs.

Deux options

  1. Vous débutez en domotique ou vous voulez juste allumer deux ampoules et actionner un relaie. Laissez vous guider, HA découvrira vos modules et vous les piloterez en deux clics afin d'n exploiter toutes les possibilités, l'intégration de base supporte toutes les possibilités et s'améliore de releases en releases.
  2. Vous passez vos nuits sur votre serveur domotique, vous fréquentez des barbus qui vous poussent à souder des cartes électroniques, votre facteur vous regarde bizarrement depuis que vous recevez plusieurs fois par semaine des paquets en provenance de Chine. Attention, bientôt vous n'aurez plus de famille, d'ailleurs votre femme pense à demander le divorce. Mais faites vous plaisir prenez la route MQTT, en attendant de retrouver la votre, c'est aussi une forme de liberté.

Je ne vais pas vous expliquer MQTT, d'autres l'ont fait, mais MQTT est un vrai protocole domotique en devenir. Attention toutefois, chez Shelly, c'est Cloud (App mobile, Alexa, GH) ou MQTT. Il faut choisir. Attention également aux modules Shelly fonctionnant sur piles, personnellement j'ai abandonné ces modules car même avec du WI-FI Low Energy les piles sont trop rapidement à changer, et il y a des chances qu'en MQTT ce soit encore pire. Donc pour les sondes et autres capteurs, Zigbee est à mon sens plus adapté.

MQTT sur Home Assistant

Je ne vais pas détailler ici l'a mise en œuvre de MQTT, ce n'est pas le propos, mais en gros on installe un broker (dans les adons) et ensuite on ajoute l'intégration MQTT depuis la page des intégrations. Et si on ne veut pas se taper la configuration individuelle des modules, on installe Shelly Discovery qui est un script Python qui va le faire pour vous. Pourquoi ça alors que d'autre modules vont en MQTT créer tout ce qui est nécessaire sous HA ? Simplement parce que Shelly se veut générique et ainsi ils n'ont pas à gérer cette partie. Ca se défend.

Migration vers MQTT

On commence par imprimer une liste des Shelly existants sous Shelly4HASS avec leur adresse et leur usage afin de pouvoir les repérer en MQTT.

Dans l'intégration MQTT qui a remonté nos modules c'est le moment de penser au renommage. C'est un point important et il sera bien moins aisé d'y revenir. Il y a plusieurs écoles.

  • Renommage soft ou on renomme juste le display name.
  • Renommage hard ou l'on renomme le display name et l'entité. Dans ce cas il faut le faire avant d'aller faire le travail suivant car ça aura des conséquences sur le travail d'intégration.
  • Renommage unique du display name de l'entité qui actionne (light ou switch). Ca sera utile pour le présenter dans Alexa ou GH.
  • Dans tous les cas il ne faut pas oublier d'affecter une pièce (qui sera également reprise dans Alexa et GH)
  • Et sur la config des Shelly de type relais (1, 1PM, 2.5 ou prises) utilisés pour les éclairages, aller dans Appliance type et changer general pour light.

A ce stade on veut virer Shelly4HASS dans les intégrations et aussi le composant dans HACS. Avantage on va voir tout de suite ce qui ne fonctionne plus. Mais on peu aussi le faire après avoir migré en MQTT si on ne pense pas pouvoir faire ce travail d'une traite. Quand Shelly4HASS n'est plus présent on va voir remonter automatiquement les modules via l'intégration de base Shelly. On peut éviter ça si on en a beaucoup ou simplement clique sur ignorer dans les intégrations.

discovery:
  ignore:
    - shelly

Ensuite il va falloir de la patience et comme toujours de la rigueur.

Point à vérifier pour chaque module :

  • S'ils sont affichés dans Lovelace (relais et conso).
  • S'ils sont télécommandés (par quoi, automation, BP ou ComanderX).
  • S'ils sont déclarés en utility_meter:
  • S'ils sont utilisé dans les automations ou des thermostats
  • S'ils sont utilisés dans d'autres cas particuliers.

On les faits les uns après les autres et on valide chaque étape en en vérifiant le bon fonctionnement.

Bienvenue dans MQTT !

En bonus, MQTT Explorer qui sera bien utile pour mettre au point des choses complexes et vérifier ce qui se trame sur votre broker. Broker que l'on a ici monté sur HA, mais qui dans l'absolu pourrait être sur une autre machine, un NAS, voire même sur un autre site. Il existe d'ailleurs des brokers publics pour faire communiquer différents objets entre eux. Vous allez me dire que c'est une façon de recentraliser l'information, oui, mais ça peut être nécessaire en IoT avec des objets volatiles car si l'objet A ne parvient pas à joindre l'objet B, le broker conservera alors le message le temps que l'objet B soit disponible... D'où l'intérêt d'une certaine centralisation qui peut d'ailleurs être répartie...

EDIT : un article très bien fait : https://henriksozzi.it/2021/02/shelly-e-home-assistant/ (clic droit traduire si vous ne maitrisez pas l'italien...)

 

Home Assistant & UPS

Vous allez me demander pourquoi gérer les onduleurs sur Home Assistant ? Simplement pour être avertit en cas de coupure électrique via une notification (si on est en déplacement il peut être intéressant d'envoyer une personne de confiance réarmer en cas d'une défaillance locale, histoire de ne pas perdre le contenu du congélateur (vécu)), ensuite exécuter des actions sur ce qui est secouru et en dernier ressort éteindre le serveur. Les informations ainsi remontées donneront également des indication sur l'état des batteries afin de les changer préventivement.

J'ai souvent des coupures à la campagne, j'ai deux gros onduleurs réseau de marque APC et je me suis dès mes débuts intéressé à eux avec ce que j'ai alors trouvé de plus simple.

APC UPS Daemon

ApcUpsd s'installe sous la forme d'un addon et la suite est intégrée à Home Assistant.

On ajoute aux addons ce repository : https://github.com/korylprince/hassio-apcupsd et on installe la version IP ou USB qui nous convient. Et on configure.

name: APC UPS
cable: ether
type: snmp
device: 192.168.210.6

Ensuite on ajoute ça dans configuration.yaml :

apcupsd:

Ainsi que quelques sensors :

- platform: apcupsd
  resources:
    - apc
    - date
    - hostname
    - version
    - upsname
    - cable
    - driver
    - upsmode
    - starttime
    - model
    - status
    - linev
    - loadpct
    - bcharge
    - timeleft
    - mbattchg
    - mintimel
    - maxtime
    - maxlinev
    - minlinev
    - outputv

Et on termine avec un binary :

- platform: apcupsd
  name: UPS

Les paquets sont marqués obsolètes, mais pour l'instant j'utilisait ça depuis un an et ça fonctionne très bien.

SNMP

Si on dispose d'un onduleur réseau, ici APC, voici un "package" (mode pakage de HA) pour le faire en SNMP. Le gros avantage c'est qu'il n'y a absolument rien à installer, SNMP étant supporté de base dans Home Assistant. Attention c'est un peu long...

sensor:
  - platform: snmp
    name: ups_smart_750_capacity
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.2.2.1.0
    accept_errors: true
    unit_of_measurement: '%'
  - platform: snmp
    name: ups_smart_750_runtime_remaining
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.2.2.3.0
    accept_errors: true
    value_template: >-
      {% set time = (value | int) / 100 | int %}
      {% set minutes = ((time % 3600) / 60) | int %}
      {% set hours = ((time % 86400) / 3600) | int %}
      {% set days = (time / 86400) | int %}
    
      {%- if time < 60 -%}
        Less than a minute
        {%- else -%}
        {%- if days > 0 -%}
          {{ days }}d
        {%- endif -%}
        {%- if hours > 0 -%}
          {%- if days > 0 -%}
            {{ ' ' }}
          {%- endif -%}
          {{ hours }}h
        {%- endif -%}
        {%- if minutes > 0 -%}
          {%- if days > 0 or hours > 0 -%}
            {{ ' ' }}
          {%- endif -%}
          {{ minutes }}m
        {%- endif -%}
      {%- endif -%}
  - platform: snmp
    name: ups_smart_750_load_percentage
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.4.2.3.0
    accept_errors: true
    unit_of_measurement: '%'
  - platform: snmp
    name: ups_smart_750_battery_temperature
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.2.2.2.0
    accept_errors: true
    unit_of_measurement: '°C'
  - platform: snmp
    name: ups_smart_750_battery_status
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.2.2.4.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        Good
      {% elif value == '2' %}
        Failed
      {% endif %}
  - platform: snmp
    name: ups_smart_750_type
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.1.1.1.0
    accept_errors: true
  - platform: snmp
    name: ups_smart_750_input_voltage
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.3.2.1.0
    accept_errors: true
    unit_of_measurement: 'V'
  - platform: snmp
    name: ups_smart_750_last_transfer_reason
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.3.2.5.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        No events
      {% elif value == '2' %}
        High line voltage
      {% elif value == '3' %}
        Brownout
      {% elif value == '4' %}
        Loss of mains power
      {% elif value == '5' %}
        Small temporary power drop
      {% elif value == '6' %}
        Large temporary power drop
      {% elif value == '7' %}
        Small spike
      {% elif value == '8' %}
        Large spike
      {% elif value == '9' %}
        UPS self test
      {% elif value == '10' %}
        Excessive input voltage fluctuation
      {% endif %}
  - platform: snmp
    name: ups_smart_750_output_load
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.4.2.3.0
    accept_errors: true
    unit_of_measurement: '%'
  - platform: snmp
    name: ups_smart_750_output_current
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.4.2.4.0
    accept_errors: true
    unit_of_measurement: 'A'
  - platform: snmp
    name: ups_smart_750_last_self_test_result
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.7.2.3.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        OK
      {% elif value == '2' %}
        Failed
      {% elif value == '3' %}
        Invalid Test
      {% elif value == '4' %}
        Test In Progress
      {% endif %}
  - platform: snmp
    name: ups_smart_750_last_self_test_date
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.7.2.4.0
    accept_errors: true
  - platform: snmp
    name: ups_smart_750_communication_status
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.8.1.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        on
      {% elif value == '2' %}
        off
      {% endif %}
  - platform: snmp
    name: ups_smart_750_status
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.4.1.1.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        Unknown
      {% elif value == '2' %}
        On Line
      {% elif value == '3' %}
        On Battery
      {% elif value == '4' %}
        On Smart Boost
      {% elif value == '5' %}
        Timed Sleeping
      {% elif value == '6' %}
        Software Bypass
      {% elif value == '7' %}
        Off
      {% elif value == '8' %}
        Rebooting
      {% elif value == '9' %}
        Switched Bypass
      {% elif value == '10' %}
        Hardware Failure Bypass
      {% elif value == '11' %}
        Sleeping Until Power Returns
      {% elif value == '12' %}
        On Smart Trim
      {% endif %}

homeassistant:
  customize:
    sensor.ups_smart_750_status:
      device_class: connectivity
      friendly_name: Smart-UPS status
    sensor.ups_smart_750_capacity:
      device_class: battery

NUT

Enfin on peut aussi utiliser NUT (Network UPS Tools) que beaucoup ici connaissent et qui est une légende dans le monde des UPS.

Pour ça il faut installer le serveur NUT que l'on trouvera dans les addons et qui communiquera avec vos onduleurs. Voici deux configurations à adapter selon que l'onduleur soit connecté en USB ou en IP. La documentation de NUT est une véritable bible des UPS et vous y trouverez ce qui vous manque.

USB

users:
  - username: nut
    password: MyPassword
    instcmds:
      - all
    actions: []
devices:
  - name: apc
    driver: usbhid-ups
    port: auto
    config:
      - desc = "APC Back-UPS 600VA"
      - vendorid = 051d
mode: netserver
shutdown_host: 'false'

IP

users:
  - username: nut
    password: MyPassword
    instcmds:
      - all
    actions: []
devices:
  - name: apc_1400
    driver: snmp-ups
    port: 192.168.210.6
    community: public
    snmp_version: v1
    pollfreq: 15
    config:
      - desc = "APC Smart-UPS 1400VA"
  - name: apc_750
    driver: snmp-ups
    port: 192.168.210.7
    community: public
    snmp_version: v1
    pollfreq: 15
    config:
      - desc = "APC Smart-UPS 750VA"
mode: netserver
shutdown_host: 'false'

A partir de là il faut aller dans les intégrations, ajouter l'intégration NUT, la configurer avec ces informations :

  • Host : a0d7b954-nut
  • Port : 3493
  • Username : nut
  • Password : MyPassword

Et ensuite choisir les seniors que l'on souhaite créer, utiliser et superviser.

Automations

Une fois que l'on dispose des sensors il sera possible d'effectuer des actions selon le comportement de ceux ci. Libre à vous d'imaginer, ou par exemple utiliser l'intégration Alert pour recevoir des notifications répétées.

ups_1:
  name: UPS APC 1
  entity_id: binary_sensor.ups
  state: 'off'   # Optional, 'on' is the default value
  repeat:
    - 10
    - 30
    - 60
    - 300
  can_acknowledge: true  # Optional, default is true
  skip_first: true  # Optional, false is the default
  message: "{{ states.sensor.date_time.state}} > A L A R M  U P S | Coupure EDF" 
  done_message: "{{ states.sensor.date_time.state}} > A L A R M  U P S | Rétablissement EDF"
  notifiers:
    - slack_hass_canaletto
    - Free_Mobile

Voilà, un peu soporifique, je suis d'accord, mais le sujet n'est pas rigolo !

 

 
 

 

 

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.

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à !