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 : Dorbell sound"
  trigger:
    - platform: state
      entity_id: binary_sensor.doorbell_g4_doorbell
      from: 'off'
      to: 'on'
  condition: []
  action:
  - data: {}
    entity_id: all
    service: sonos.snapshot
  - data:
      volume_level: 0.5
    entity_id: media_player.sonos_hall, media_player.sonos_cuisine
    service: media_player.volume_set
  - data:
      master: media_player.sonos_hall
    entity_id: media_player.sonos_hall, media_player.sonos_cuisine
    service: sonos.join
  - data:
      media_content_id: https://home-assistant.canaletto.local:8123/local/chime.mp3 # ou IP de HA
      media_content_type: music
    entity_id: media_player.sonos_hall
    service: media_player.play_media
  - delay: 00:00:05
  - data: {}
    entity_id: all
    service: sonos.restore

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

 

 
 

 

 

Home Assistant, restauration d'état après une coupure secteur

Comme d'aucuns ont pu le remarquer, les ampoules connectées s'allument après une coupure secteur (Mi, Hue, Ikea, Tuya, etc...)., c'est logique car si on les actionne depuis un inter d'origine il faut bien que l'ampoule répondre en dehors de tout contexte domotique, bien que certaines, Shelly par exemple, permettent comme les prises commandées et modules de choisir cet état.

Pour palier à ce problème et ne pas retrouver toutes mes ampoules allumées quand je rentre à cause d'une coupure ayant eu lieu dans la journée, j'ai fait un groupe d'ampoules (dans light.yaml) à éteindre après que l'onduleur ait signalé la reprise électrique (ça sous entend bien sur d'avoir configuré un addon sur l'onduleur afin d'avoir le binay_sensor: idoine).

- platform: group
  name: Groupe de Coupure
  entities:
    - light.tuya_cour_1
    - light.tuya_cour_2
    - light.tuya_chevet
    - light.tuya_strip_antoine
    - light.hall_1
    - light.hall_2
    - light.cuisine_led
    - light.sejour_led
    - light.cuisine_lampe_de_table
    - light.bureau_led_bt
    - light.ikea_r14_entree
    - light.ikea_e27_tv

Et une petite automation :

- alias: P - Light OFF après reprise électrique
  description: ''
  trigger:
  - platform: state
    entity_id: binary_sensor.ups
    from: 'off'
    to: 'on'
  condition: []
  action:
  - service: light.turn_off
    data: {}
    entity_id: light.groupe_de_coupure

Ca fonctionne mais ce n'est pas satisfaisant car ça éteint toutes les ampoules, et pas seulement celles qui étaient éteintes avant la coupure. J'ai commencé par me dire qu'idéalement il faudrait connaitre leur état avant la coupure, le stocker dans des input quelque chose et faire une automation de malade à exécuter lors du rétablissement électrique. Ca m'a donné mal au crane et j'ai procrastiné la chose...

Et puis, en discutant dans notre groupe préféré et confidentiel, la lumière jaillit ! Il y a une fonctionnalité souvent peu utilisée dans Home Assistant, ce sont les scènes. En général on crée une scène, genre j'allume des ampoules à telle ou telle intensité ou couleur, je baisse les stores, et je lance un film sur Netflix... Mais, si on lit la doc jusqu'au bout on découvrira que l'on peut également créer des scènes à la volée, un peu comme un snapshoot de l'état de certaines entités.

Et là ça devient très simple. Si une ampoule n'est plus alimentée, elle ne signale pas son état à Home Assistant. Il suffit alors d'enregistrer son état dans une scène dès lors que le binary de l'onduleur passe à OFF :

- alias: P - Sauve l'état des lampes lors d'une coupure
  trigger:
  - platform: state
    entity_id: binary_sensor.ups
    from: 'on'
    to: 'off'
  condition: []
  action:
  - service: scene.create
    data:
      scene_id: light_state
      snapshot_entities:
      - light.tuya_cour_1
      - light.tuya_cour_2
      - light.tuya_chevet
      - light.tuya_strip_antoine
      - light.hall_1
      - light.hall_2
      - light.cuisine_led
      - light.sejour_led
      - light.cuisine_lampe_de_table
      - light.bureau_led_bt
      - light.ikea_r14_entree
      - light.ikea_e27_tv

Et de restaurer la scène quand celui ci passe à ON :

- alias: P - Restaure l'état des lampes lors d'une coupure
  trigger:
  - platform: state
    entity_id: binary_sensor.ups
    from: 'off'
    to: 'on'
  condition: []
  action:
  - delay : '00:00:60' # On ajoute une temporisation afin que les ampoules se reconnectent
  - service: scene.turn_on
    data:
      entity_id: scene.light_state

Et on retrouve l'état de l'éclairage avant qu'Enedis ait sévit. Car si les coupures électriques sont peu fréquentes en ville, à la campagne le moindre aléa climatique en provoque, ce qui en dit long sur l'état du réseau. 

J'ai pris ici l'exemple de l'éclairage lors d'une coupure secteur. Mais il est tout à fait possible de restaurer ainsi l'état d'autres entités, mais également de s'en servir dans d'autres contextes, par exemple sauvegarder un état d'éclairage avant de fermer les volets ou de regarder un film, et de le restaurer ensuite. Avec Emby (et surement d'autres triggers) on peu par exemple jouer deux états selon que l'on appuie sur PLAY ou PAUSE... La suite n'étant qu'une question d'imagination ;-)

 

 

Home Assistant & Planification, la suite !

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Home Assistant & Tuya zéro cloud

On le sait tous, la domotique nous fait acheter beaucoup de bricoles qui souvent deviennent obsolètes, bref il y a toujours mieux. Par exemple les prises et autres objets Tuya ou Sonoff qui nécessitent le cloud, alors qu'un prise Shelly dispose de base de MQTT, peut être flashée avec ce que l'on souhaite et dans tous les cas fonctionne en local. Bien sur on ne va pas parler des prises en RF433 genre DIO mise au rebus faute de retour d'état, pas plus que des solutions Zigbee qui se traitent autrement. Tuya c'est du matériel OEM disponibles en marque blanche que des entreprises peuvent distribuer sous leur étiquette. Je trouve d'ailleurs scandaleux qu'une marques comme Konyks soit labelisée French Tech alors qu'il se contente de distribuer de produits chinois sous leurs marque sans aucune R&D... Bref !

Nous avons donc en Wi-Fi...

  • L'écosystème Sonoff : en dehors de quelques modèles DIY, il faudra en général ouvrir et souder pour flasher. Heureusement il existe une intégration qui permet leur utilisation en local / cloud. En gros l'intégration mets à jour à intervalles réguliers ce qu'il trouve sur le cloud Sonoff et les actions sont ensuite locales.
  • L'écosystème Tuya : de base 100% cloud et géré nativement par HA, mais on va voir plus loin comment contourner ça.
  • L'écosystème Shelly : Cloud ou 100% nativement local et MQTT, flashable si vous aimez ça. C'est clairement ce que je vous conseille pour de nouveaux achats.

Tuya sans cloud

Heureusement il y a des petits malins qui adorent faire du reverse engineering, ce qui va nous permettre d'utiliser nos produits Tuya localement avec bien souvent plus de fonctionnalités, comme par exemple la remontée des information de consommation qui ne se fait pas de base sous HA.

Dans tous les cas, comme pour les produits Xiaomi/Aqara, il faudra trouver la clé... Au fil du temps les méthodes changent, mais aujourd'hui ça n'a jamais été aussi facile. Je vous conseille donc de récupérer vos clés, même si vous ne comptez pas les utiliser tout de suite.

On part du principe que vous avez un compte Tuya/ SmartLife (ou une application OEM comme celle de Konyks, c'est la même chose) et que vos équipements y sont enregistrés. En substance on va passer par la plateforme IoT de Tuya sur lequel vous allez vous créer un compte développeur et suivre les instructions de cet article dont je me suis inspiré. (Je ne suis pas sur que tout soit utile, vous me direz...).

  1. Créez un nouveau compte sur iot.tuya.com et assurez-vous que vous êtes connecté. Allez dans Cloud -> Projet dans le tiroir de navigation de gauche et cliquez sur "Create". Après avoir créé un nouveau projet, cliquez dessus. L'ID d'accès et la clé d'accès sont équivalents à la clé d'API et aux valeurs secrètes d'API requises.
  2. Allez dans App -> App SDK -> Development dans le tiroir de navigation. Cliquez sur "Create" et entrez ce que vous voulez pour les noms de package et Channel ID (pour le nom du package Android, vous devez entrer une chaîne commençant par com.). Prenez note de l' ID de chaîne que vous avez entré. Cela équivaut à la valeur schema requise plus loin. Ignorez les clés d'application et les valeurs secrètes d'application que vous voyez dans cette section car elles ne sont pas utilisées.
  3. Allez dans Cloud -> Projet et cliquez sur le projet que vous avez créé précédemment. Cliquez ensuite sur "Link Device". Cliquez sur l'onglet «Link devices by Apps», puis sur «Add Apps». Vérifiez l'application que vous venez de créer et cliquez sur "Ok".
  4. Toujours dans Cloud -> Projet et cliquez sur le projet que vous avez créé précédemment. Cliquez ensuite sur "Link Device". Cliquez sur l'onglet «Link devices by App Account», puis Add App Account et ajouter votre compte Tuya/SmartLife et vous devriez retrouver vos petits....
  5. Sur la même page, cliquez sur "Groupe d'API" sur le côté gauche. Modifiez le statut en Ouvert pour les trois groupes d'API suivants en cliquant sur "Appliquer" pour chaque ligne, en saisissant une raison quelconque et en cliquant sur "OK": "Authorization Management", "Device Management", "Device Control", "User Management", "Network Management", "Data Service", "Home Management", "Device User Mangement" and "Device Statistics".. Cela peut prendre 10 à 15 minutes pour que ces modifications prennent effet.
  6. Ensuite sur Device List / App Account / Europe vous listez vos devices et vous récupérez les devices ID
  7. Enfin on va dans API Explorer / Get Device details, on choisit Europe et on rentre le device ID et par magie la local_key apparaitra.
{
  "result": {
    "active_time": 1609598200,
    "biz_type": 0,
    "category": "cz",
    "create_time": 1609598200,
    "icon": "smart/icon/154028815822y4yx2k5jz_0.jpg",
    "id": "871720fsdfsdfsfd8e997fec",
    "ip": "70.22.16.3",
    "local_key": "8dfsdfsdfsgggsg10ecb6",
    "name": "Konyks Priska Plus 6",
    "online": true,
    "owner_id": "19956557",
    "product_id": "j6cVsdgfsdfgsdfsdfeYpli",
    "product_name": "Konyks Priska Plus",
    "status": [
      {
        "code": "switch_1",
        "value": false
      },
      {
        "code": "countdown_1",
        "value": 0
      },
      {
        "code": "cur_current",
        "value": 0
      },
      {
        "code": "cur_power",
        "value": 0
      },
      {
        "code": "cur_voltage",
        "value": 2339
      }
    ],
    "sub": false,
    "time_zone": "+01:00",
    "uid": "eu15345fgsdfsdfdsf9crK3G",
    "update_time": 1609565564,
    "uuid": "8717244465sd6f46sdf7fec"
  },
  "success": true,
  "t": 1609606041296
}

Ceux qui sont familiers de Node JS pourront lancer le script comme décrit ici et obtenir toute les clés en une seule manipulation.

Ensuite on a deux solutions :

  • La première, Trade Face Tuya Gateway est indépendante de la solution domotique choisie car full MQTT, elle peut s'installer dans un Docker et nos amis encore sous Jeedom pourront ainsi en profiter.
  • La seconde, Local Tuya, est une simple intégration pour Home Assistant qui permettra de reconnaitre nos équipements en quelques clics et s'installe depuis HACS. Le discovery fera le reste et il faudra juste tâtonner un peu quand on configure un équipement Tuya pour faire correspondre les bonnes valeurs, mais c'est expliqué ici.

Vous aurez compris, ce qui compte encore une fois c'est d'avoir les clés. Ensuite il existe surement d'autre solutions pour exploiter. Attention : Pour toutes ces manips pensez à fermer l'application mobile (Tuya/SmartLife) car un équipement Tuya ne supporte qu'une seule connexion simultanée.

Merci Yvon pour cette exploration nocturne et conjointe d'un jour de l'an sous couvre-feu !

EDIT 04/01/2021 : Il y a un soucis dans le v3.2 ou on perd certains équipement au reboot. Revenir à la 3.1 résout le problème en attendant mieux.

EDIT 21/02/2021 : Contrairement aux Shelly les appareils Tuya ne fournissent que la consommation instantanée. Donc pas exploitable directement avec un utility_meter: par exemple. Il va donc falloir ruser un peu :

  1. Sortir la consommation instantanée (j'ai laissé le reste en exemple) disponible en attribut pour en faire un sensor :
    sensor:
      - platform: template
        sensors:
          # tuya-sw01_voltage:
          #   value_template: >-
          #     {{ states.switch.sw01.attributes.voltage }}
          #   unit_of_measurement: 'V'
          # tuya-sw01_current:
          #   value_template: >-
          #     {{ states.switch.sw01.attributes.current }}
          #   unit_of_measurement: 'mA'
          tuya_plug_1_current_consumption:
            value_template: >-
              {{ states.switch.tuya_plug_1.attributes.current_consumption }}
            unit_of_measurement: 'W'
  2. Utiliser l'intégration Riemann pour convertir la la consommation instantanée (en Watts) en consommation cumulée (en kW/h)
    sensor:
      - platform: integration
        source: sensor.tuya_plug_1_current_consumption
        name: 'Tuya Plug 1 : Cumul'
        unit_prefix: k
        round: 2
        method: left
  3. Si l'on souhaite conserver l'historique (ici année et année précédente) on va utiliser un utility_meter:
    utility_meter:
      tuya_plug_1_energy_yearly:
        source: sensor.tuya_plug_1_cumul
        cycle: yearly


Enjoy ;-)