Home Assistant & Aqara Hub M3

Produit en cours de test et article en cours d'écriture.

Dans la série des clic compulsifs d'un soir, voici le dernier Hub d'Aqara, le M3. Je parle de clic car je ne reçoit pas ces produits d'un quelconque service de presse qui me presserait d'être gentil, mais je les achètes, quitte parfois à les retourner à ce cher Amazon. Et en plus, contrairement à pas mal de sites "pute à clics", je les teste vraiment.

Ca vaut 130 € et il y a un code promo de 20% qui traine.

Ce produit offre de grandes promesses sur papier glacé et il est même annoncé officiellement compatible avec Home Assistant. Mais la réalité est un peu différente...

  • Connectivité POE : la promesse est tenue et c'est bien pratique, ça permet de le poser n'importe ou sans un horrible chargeur et si le switch est secouru ça sera sans coupure électrique.
  • Du WI-FI bi bande : C'est la moindre des choses. WPA3 inside.
  • Alimentation USB C : plus pratique, et peu énergivore (1.6 W mesurés).
  • Zigbee : Ne vois y trompez pas, si la plaquette annonce bien le support de 127 devices, il s'agit de devices Aqara. N'espérez donc pas remplacer votre passerelle Zigbee habituelle. Il n'en reste pas moins que c'est intéressant, certains devices Aqara n'étant pas tout à fait à la norme Zigbee 3, ils seront mieux gérés ici (actuellement je les gère avec cette passerelle peu couteuse qui fonctionne très bien avec cette intégration).
  • Bluetooth : aucun device ne remonte (sondes Xiaomi par exemple).
  • IR : Ca fonctionne mais la fonctionnalité reste sur le Hub, l'intérêt aurait été que ça remonte sur Home Assistant via Matter ou HK.
  • HomeKit : Les devices reconnus remontent bien dans Home Assistant et probablement sur les produits Apple.
  • Matter & Thread : Si j'arrive bien à faire remonter dans Home Assistant les devices Zigbee, je n'ai pas réussit à associer de device Matter (testé avec une Nuki 4 et un capteur d'ouverture Aqara P2, ce qui est un comble).

Conclusion (temporaire)

Une fois de plus dans une industrie qui va très vite on se retrouve avec un hardware de bonne facture avec du software à la traine.

Je ne pense pas que cette passerelle acceptera des devices Zigbee d'autres marques, sauf peut être des accords avec des leaders genre Philips Hue, mais il ne faut pas trop rêver. Par contre on peu penser qu'ils termineront la partie Matter et espérer que les remontées vers Home Assistant ne se limitent pas au strict minimum.

Pour l'instant il est donc urgent d'attendre...

EDIT 16/06/2024

Comme souvent les pas mal de sites ont encensé le communiqué de presse de ce produit sans vraiment le tester. Depuis mon premier test il n'y a pas d'évolution coté firmware. Hier soir j'ai ajouté le TVOC Aqara pour voir, hélas ça ne remonte pas en Matter vers HA, heureusement qu'il y a HomeKit

 

Home Assistant & Nuki

Ca me travaillait depuis un moment, automatiser la porte d'entrée ! L'objectif étant que la porte se verrouille quand je part (process d'alarme, fermeture des volets, etc.) et se déverrouille quand j'arrive avec le process inverse. Accessoirement permettre à des tiers d'ouvrir (clavier et tags), ou moi même d'ouvrir et fermer à distance.

J'ai regardé un peu le marché et j'ai trouvé :

  • Linus Yale : un peu trop américaine, et de fait encombrante ! (lien Amazon)
  • Tedee : tentant mais un peu jeune (test ici et lien Amazon)
  • Danalock : on dirait qu'ils ne bougent plus trop...
  • Nuki : mon choix par défaut ! (lien Amazon)
  • Switchbot : La nouvelle Pro à l'air plus intéressante de l'ancienne... (lien Amazon)
  • Et enfin beaucoup de chinoiseries que je préfère éviter pour ce genre d'objets...

Après avoir bien creusé le sujet et écouté les conseils d'autrui j'ai porté mon choix sur une Nuki Pro 4.0, en y voyant comme avantage :

  • Du WIFI intégré afin d'éviter un bridge supplémentaire
  • Un bloc de batterie rechargeable
  • Une meilleure finition
  • Matter, enfin, un jour peut être...

Je fait l'impasse de l'installation qui est effectivement facile, mais qui m'a tout de même couté un cylindre débrayable (lien Amazon). Et on passe à la configuration.

Je n'ai pas grand chose à redire sur la mise en œuvre via l'application, c'est plutôt bien fait, tout comme Nuki Web ou l'accès à distance depuis un smartphone. Là ou ça va se compliquer c'est pour intégrer ça à Home Assistant, et c'était le but ! Il existe plusieurs solutions et je veux bien comprendre que les débutants soient perdus.

Intégration du Core HA

On me l'a déconseillé et j'en ai lu du mal, j'ai donc zappé.

Intégration Nuki NG

Ca semble bien fait, mais c'est un fail. Je pense qu'il vaut mieux disposer du bridge Nuki.

Intégration Nuki BT

Il s'agit d'un fork de Nuki NG qui a la particularité de se connecter directement au Nuki en Bluetooth. A priori parfait pour mon usage. Sauf que je n'ai jamais réussit à appairer le Nuki à cette intégration.

MQTT

Proposé comme la solution officielle pour connecter Nuki à Home Assistant, je me suis dit que ça serait facile. En effet la configuration est simple et les information de base (Look/Unlook et batterie) remontent bien dans Home Assistant. Il faut laisser le WIFI actif, ça consommera un peu plus mais ça devrait aller.

Oui, mais ! Il y a un tout petit problème : entre l'envoi d'une commande, l'action et le retour d'état il peut se passer de 1 à 3 minutes (quand ça fonctionne). Et je ne me voit pas passer 3 minutes à attendre devant la porte... Que se passe t'il ? Direction le forum Nuki, et la c'est le bug ! Problème plus ou moins connu, récurent, bref les utilisateurs ne sont pas contents et j'aurais du lire ça avant. Bien sur Nuki explique que ça vient du Wi-Fi des utilisateurs, sauf que j'ai testé avec mon Unifi de base et 3 AP d'autres marques, avant de me dire que si l'application Nuki connectée sur un smartphone en 4G fonctionnait bien, le problème n'était pas lié au Wi-Fi mais à l'implémentation MQTT. Un peu dégouté, je me suis dit qu'ils voulaient vendre leur bridge et que n'y couperait pas !

MQTT via ESP Nuki HUB

Dans mes pérégrinations j'a commencé par tester sans succès un projet basé sur espHome avant de tomber sur Nuki Hub, un projet très complet qui crée un bridge avec un ESP. Nuki Hub communique avec un Nuki Lock, un Opener et un clavier via Bluetooth (BLE) et utilise MQTT pour s'intégrer à d'autres systèmes. Il expose l'état de verrouillage (et bien plus encore) via MQTT et permet d'exécuter des commandes telles que le verrouillage et le déverrouillage via MQTT (n'hésitez pas à bien lire la doc qui est une mine d'informations).

Un petit flash plus loin j'ai réussit à associer mon Nuki à ce bridge DIY, il remonte toutes les informations utiles, voire plus, et surtout il permet de verrouiller / déverrouiller rapidement la serrure, ce qui est tout de même la base.

Par contre il faut savoir une chose, chez Nuki c'est fromage ou dessert, pas le deux ! En gros pour activer un bridge, qu'il soit Nuki ou DIY, il faut désactiver le Wi-Fi du Nuki. Ce qui concrètement veut dire qu'on ne pourra plus le commander à distance depuis l'application Nuki et que si on veut utiliser localement cette application il faudra se rapprocher du Nuki, la portée du Bluetooth de cet objet étant très faible (j'ai du mal dans mon bureau qui est à 3 mètres de la porte d'entrée...).

Conclusion

Ou moralité ! Je crois que j'ai acheté une version 4 et Pro pour rien. En effet le Wi-Fi intégré ne me servira à rien et une v3 standard aurait parfaitement fait le job pour pas cher (il y a plein sur le Bon Coin !

EDIT 02/09/2024

J'ai retenté quelques configurations différentes :

  • BT avec l'appli mobile : Ce mode est le seul à peu près fiable. Donc pour Nuki tout est ok et ils peuvent même faire un peu de collecte de données. Mais le but est que cette serrure sont intégrée à Home Assistant.
  • MQTT natif en WI-FI : Pas fiable, la serrure passe son temps à faire le yoyo sur le WI-FI. Nuki joue au con sur son forum en renvoyant la balle aux fournisseurs de WI-FI en disant que chez eux c'est OK. J'ai une centaine de modules WI-FI qui ne posent pas de problèmes sur mon réseau Unifi. La serrure passe son temps à se déconnecter / reconnecter, et ne réactive la connexion MQTT que longtemps plus tard. Les seuls modules qui ont le même défaut sont certains vieux objets Xiaomi, je les ait virés. Une serrure c'est stratégique et ça sous entent une fiabilité à 100%.
  • Matter : Fail, que ce soit en natif sous HA ou via la passerelle Aqara M3.
  • Nuki Hub : J'ai réinstallé la v9. Cette mise à jour nécessite de repartir à zéro. Ca reste ce que j'ai de plus fiable.

On ne peut pas imaginer devoir rester quelques minutes devant la porte pour qu'elle s'ouvre après la désactivation de l'alarme. Je suis à deux pas de revenir à la clé !

EDIT 24/09/2024

Démontage de ce produit. Trop de déconvenues, et s'il faut se balader avec la clé au risque de dormir dehors, autant l'utiliser, d'autant plus que cette serrure est lente. Donc à vendre si l'aventure vous tente. Je suis preneur de vrais retours sur les autres modèles.

INFO

Contrairement à la majorité des blogs et autres influenceurs, je ne "reçoit" pas les produits d'un quelconque service de presse, mais je les achète, ce qui me permet d'assumer ce que je pense vraiment d'un produit. Pour autant ce n'est pas une critique des blogs ou YT qui en vivent, il faut bien manger ! De plus j'ai moi même été "journaliste" dans la presse tech et ça m'a jadis fait manger !

 

Home Assistant & WebRTC

Comme d'aucuns ont pu le remarquer, le flux des caméras sous Home Assistant à tendance parfois à laguer et ne pas être très réactif. On pourrait penser que ça vient de la qualité des caméras, pourtant j'utilise un système Unifi Protect très bien intégré à Home Assistant et parfois j'ai l'impression d'avoir les mêmes lags que sur une chinoiserie achetée pas cher sur Ali ! En fait Home Assistant utilise le protocole RSTP afin de communiquer avec les caméras ou dans mon cas le NVR et en l'état le résultat n'est pas à la hauteur de ce que j'obtiens avec l'appli Unifi Protect. Sauf que je veux avoir ça dans HA car ça m'apporte plein d'options intéressantes. Voir la version simple à la fin !

Afin de contourner ce problème il y a WebRTC que les développeurs connaissent bien. Et l'un d'eux, Alex, qui est également l'auteur d'autres très bonnes intégration, a développé Go2RTC qui va de façon transparente nous permettre d'utiliser WebRTC pour visualiser nos caméras.

J'avais déjà lu quelques sujets sur WebRTC et HA, mais ce qui m'a donné subitement envie de l'intégrer est la vidéo de ce jeune homme :

Ceux qui me suivent savent que je ne suis pas fan des tutoriaux vidéo, surement une question de génération (je suis vieux !), mais passer du temps à faire play / pause m'agace et me fait perdre du temps. Ceci étant il explique clairement l'essentiel que je vais reprendre ici en l'adaptant à l'infrastructure Unifi Protect.

Le problème est documenté et sera probablement corrigé dans une prochaine version de Go2RTC, en attendant il faut le contourner. L'intégration Unifi Protect intègre les caméras en se basant sur le flux RSTPS, ce qui va nous donner ça :

"url": "rtsps://192.168.10.1:7441/2sgdfdsgdfgf3DNu5F?enableSrtp"

Sauf que Go2RTC ne supporte pas SRTP, et donc c'est le bug ! La bonne URL est donc celle ci :

"url": "rtsps://192.168.10.1:7441/2sgdfdsgdfgf3DNu5F"

Je n'ai pas trop cherché, mais je n'ai pas trouvé ou faire la modification et comme Go2RTC recrée les liens lors de chaque démarrage, j'ai contourné le problème en créant dans HA des caméras génériques basées sur la bonne URL (on pense à décocher la vérification du certificat car il est généralement bidon et on n'entre pas d'authentification puisque le lien est open bar).

On répète ça sur toutes les caméras et on pense à les renommer proprement.

L'étape suivant va consister à installer l'addon Go2RTC. Pour ça on va dans les addons HA et on ajoute l'adresse du dépôt idoine dans les sources et on installe :

https://github.com/AlexxIT/hassio-addons

Une fois cet addon installé et lancé on va ajouter l'intégration RTSPtoWebRTC à Home Assistant que l'on fera pointer sur :

http://localhost:1984

Et c'est presque tout, miracle vos caméras sont maintenant bien plus réactives !

A ce stade les barbus vont me dire, oui, mais tous ces ports passent bien en local, mais depuis l'extérieur ? Ouvrir des ports n'étant pas conseillé (j'utilise Nabu Casa ou Cloudflared), on va tuneliser en utilisant le service Ngrok sur lequel on va devoir créer un compte. Une fois le compte créé et validé , on récupère le token d'authentification que l'on vient coller dans la console de Go2RTC :

ngrok:
  command: ngrok tcp 8555 --authtoken <token>
   
webrtc:
  listen: ":8555" # external TCP/UDP port
  candidates:
    - stun:8555

Ensuite on va configurer l'option dans l'intégration RTSPtoWebRTC :

stun.l.google.com:19302

Voilà, c'est fini. La suite de la vidéo nous parle de Frigate et Fully Kiosk. Deux sujets que j'aborderais une autre fois.

Version simple

A la base je voulais juste un affichage plus fluide de mes caméras et j'ai installé toute cette usine qui a certainement un intérêt dans un contexte Frigate. Mais si l'on souhaite uniquement un peu de fluidité dans l'affichage et profiter de WebRTC simplement, et bien il y a plus simple.

Dans ce cas le seul composant à installer est l'intégration WebRTC Camera depuis HACS et de le configurer en l'ajoutant aux intégrations.

Ensuite on peu ajouter une carte Lovelace très simplement :

type: 'custom:webrtc-camera'
url: 'rtspx://192.168.6.1:7441/3jurvIekaWvpee222'

Ou aller plus loin avec quelques option :

type: custom:webrtc-camera
streams:
- url: ''
- url: 'rtspx://192.168.6.1:7441/3jurvIekaWee222'
shortcuts:
  - name: Privacy
    icon: mdi:cctv-off
    service: switch.toggle
    service_data:
      entity_id: switch.terrasse_nord_privacy_mode
ui: true
poster: https://demo.home-assistant.io/stub_config/bedroom.png
muted: true

La doc est très complète et ça remplacera efficacement la carte Picture Glance pour afficher les caméras. Ca fonctionne mais ça reste un peu pauvre, alors même si vous n'utilisez pas Frigate rien n'empêche d'utiliser leur carte qui est bien plus riche et permettra par exemple de caster le rendu vers un téléviseur...

Home Assistant & Versatile thermostat

J'ai souvent parlé ici de thermostats et de la planification de ceux ci. Si le modèle basic (climate:) a été amélioré au fil du temps, il manquait hélas toujours quelque chose, ce que le nouveau Versatile Thermostat vient combler. Je vais donc m'intéresser à celui ci afin de gérer mon climatiseur. Les intégrations de climatiseurs se calquent en général sur leur thermostat intégré, et de facto de la sonde qui y est intégré. Celle ci placée à l'intérieur de celui ci n'apporte pas la justesse d'une sonde externe qui elle sera placée à un emplacement plus idoine. On peut également imaginer une sonde virtuelle calculant la moyenne de plusieurs sondes physiques. C'est la principale utilité que je trouve à ce nouveau thermostat qui dans mon cas d'usage va commander le thermostat d'origine de mon climatiseur, mais VT peut également fonctionner de façon plus classique en commandant le switch ou le fil pilote d'un classique convecteur ou une vanne thermostatique. Et en plus c'est made in France !

Les plus du Versatile Thermostat :

  • La gestion d'une sonde externe (mais également de la température extérieure qui semble prise en compte dans son algorithme).
  • La gestion des ouvertures (encore que dans le cas d'un climatiseur je n'apprécie pas trop qu'il le passe à OFF plutôt qu'en ECO ou HG. Une évolution est en cours sur ce point).
  • La gestion de la présence et de l'occupation. Dans mon approche je gère déjà ça autrement avec proximity: et je ne vais pas m'en servir pour l'instant. Mais à terme certainement, ce qui me permettra de supprimer du code.
  • Le mode TPI (Time Proportional Interval). TPI est une fonction d'algorithme qui garantit que le dispositif s'allume le moins longtemps possible afin d'atteindre et de maintenir le bon au niveau de confort sélectionné en fonction de la sonde (très utile avec un climatiseur ou si on se contente de lui demander 21° il travaillera en fonction de sa sonde interne). Ce mode demande à faire évoluer les réglages après quelques semaines d'utilisation en fonction des résultats obtenus. De plus les climatiseurs se gèrent en général par paliers de 1°, avec VT on pourra utiliser des consignes intermédiaires.
  • La sécurisation, qui manque cruellement aux autres thermostats et peut conduire à des situations dangereuses et couteuses : si VT ne reçoit pas d'informations de la sonde dans un délais ajustable, il passe en mode sécurité et abaisse la température, voire coupe le convecteur.
  • La gestion des préréglages. Incomplet pour mon usage, mais cependant assez logique. 
  • Une carte Lovelace, qui est le fork de celle d'un autre thermostat. Louable et utile, mais j'aurais préféré que Jean-Marc fasse un fork de celle-ci qui semble laissée à l'abandon.
  • Le délestage, inutile dans mon cas, mais qui sera un gros plus quand on a que des convecteurs.

Les préréglages (preset)

Que ce soit manuellement ou avec une planification, il y a deux façons de gérer un appareil de chauffage, à la française ou on défini des modes (ECO/CONFORT/BOOST) et l'on s'en tient à ceux ci, soit on fait varier dynamiquement la température de consigne. Personnellement je fait varier la température de consigne avec la planification dont j'ai parlé plusieurs fois ici. C'est également ce qui est utilisé dans les pays nordiques ou les variation de température sont importantes.

L'objectif étant de mettre à disposition de l'utilisateur final une interface la plus claire possible, les préréglages disponibles dans VT peuvent m'être utiles. On peu par exemple imaginer l'utilisateur qui avoir besoin de booster le chauffage, il le fera alors avec le passage en mode BOOST depuis l'interface.

Se posent alors plusieurs questions :

  • Il faut désactiver la planification dynamique qui toutes les 5 minutes va réajuster le thermostat, et donc repasser le thermostat avec les paramètres planifiés.
  • Il faut également prévoir le mode de sortie du mode BOOST (que je considère comme une dérogation) :
    • Sortie manuelle immédiate : il faut un bouton
    • Sortie lors du prochain évènement (tranche horaire planifiée, couché, sortie, etc...) ou non : il faut pouvoir donner à l'utilisateur la possibilité de choisir : il faut un bouton !

Dans ma logique j'aimerais placer ces boutons dans la carte du thermostat. Mais on peut les placer ailleurs.

Sortie manuelle d'un preset

Dans mon cas je réactive simplement l'automation qui gère la planification.

L'idéal aurait été de disposer d'un preset AUTO dont je pourrais récupérer l'état et ainsi réactiver la planification. Il n'est pas possible d'utiliser le preset NONE/MANUAL car celui ci change d'état dès lors que l'on change la consigne.

Faute de disposer d'un preset AUTO (...), le seul preset que je peux détourner est donc celui du mode FROST (hors gel) dont je n'ai pas l'utilité. Je détecte l'action via l'état du VT et je réactive l'automation qui gère la planification (dans la même automation qui me permet de désactiver la planification lorsque je choisit ECO/COMFORT/BOOST), mais également les autres modes du climatiseur (FAN/DRY, etc.).

- id: 56dd275e-3f52-4d8gjk862-5eeft5708a82
  description: Comfort - AC - Mode Auto Versatile
  alias: "Comfort - AC - Mode Auto Versatile"
  mode: restart
  trigger:
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'off' }}"
      id: "off"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'dry' }}"
      id: "off"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'fan_only' }}"
      id: "off"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'heat_cool' }}"
      id: "off"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'heat' and state_attr('climate.ac_versatile', 'preset_mode') in ['boost', 'comfort', 'eco'] }}"
      id: "heat_boost_comfort_eco"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'heat' and state_attr('climate.ac_versatile', 'preset_mode') == 'frost' }}"
      id: "heat_frost"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'heat' and state_attr('climate.ac_versatile', 'preset_mode') == 'none' }}"
      id: "heat_none"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'cool' and state_attr('climate.ac_versatile', 'preset_mode') in ['boost', 'comfort', 'eco'] }}"
      id: "cool_boost_comfort_eco"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'cool' and state_attr('climate.ac_versatile', 'preset_mode') == 'frost' }}"
      id: "cool_frost"
    - platform: template
      value_template: "{{ state_attr('climate.ac_versatile', 'hvac_mode') == 'cool' and state_attr('climate.ac_versatile', 'preset_mode') == 'none' }}"
      id: "cool_none"
  action:
    - choose:
        - conditions: "{{ trigger.id in ['off', 'heat_boost_comfort_eco', 'cool_boost_comfort_eco'] }}" # Dérogation, on coupe le schedulle
          sequence:
            - service: automation.turn_off
              target:
                entity_id: automation.comfort_ac_immediate
              data:
                stop_actions: true                
    - choose:
        - conditions: "{{ trigger.id in ['heat_frost', 'cool_frost'] }}"
          sequence:
            - service: automation.turn_on
              target:
                entity_id: automation.comfort_ac_immediate
            - service: automation.trigger
              target:
                entity_id: automation.comfort_ac_immediate
              data:
                skip_condition: true

Sortie automatique d'un preset

Il s'agit ici de savoir si le prochain évènement (plage horaire, lever/coucher, géoloc, etc...) va repasser le thermostat dans le mode planifié ou pas.

Là je vais utiliser une automation déclenchée par mes différents triggers, automation qui sera ON ou OFF selon la volonté de l'utilisateur.

- id: 56efdfd5e-3f52-4ddd-a862-5e21f5708a82
  description: Comfort - AC - Restart
  alias: "Comfort - AC - Restart"
  mode: restart
  trigger:
    - platform: state
      entity_id:
        - binary_sensor.heating_ac_1
        - binary_sensor.heating_ac_2
        - binary_sensor.heating_ac_3
        - binary_sensor.heating_ac_4
        - binary_sensor.heating_ac_1_d
        - binary_sensor.heating_ac_2_d
        - binary_sensor.heating_ac_3_d
        - binary_sensor.heating_ac_4_d
        - input_boolean.to_away
        - binary_sensor.life_windows_and_doors_delayed
        - input_boolean.presence_ac
        - input_boolean.to_sleep # eco heat off cool
        - input_boolean.thermostats_ac_on_off
        - binary_sensor.lionel_geo # eco heat off cool
        - input_boolean.thermostats_away
        - input_select.comfort_ac
  condition:
    - condition: state
      entity_id: automation.comfort_ac_immediate
      state: "off"
    - condition: state
      entity_id: input_boolean.thermostats_ac_on_off
      state: "on"
  action:
    - service: automation.turn_on
      target:
        entity_id: automation.comfort_ac_immediate
    - service: automation.trigger
      target:
        entity_id: automation.comfort_ac_immediate
      data:
        skip_condition: true

Surveillance

S'agissant d'un "sur thermostat" il est intéressant de savoir ce qui se passe et si possible visuellement. Je vais donc créer deux sensor: / template: qui vont me permettre de suivre et comparer l'état de ces deux thermostats.

sensor:
- platform: template
  sensors:
    temp_up_th_ac: # Pour History Graph
      friendly_name: "TH AC"
      value_template: > 
        {% if is_state('climate.daikin', 'heat') %}
          Heat {{state_attr ('climate.daikin', 'temperature')}}°
        {% elif is_state('climate.daikin', 'cool') %}
          Cool {{state_attr ('climate.daikin', 'temperature')}}°
        {% else %}
          Off
        {% endif %}
    temp_up_th_ac_vt: # Pour History Graph
      friendly_name: "TH AC Versatile"
      value_template: > 
        {% if is_state('climate.ac_versatile', 'heat') %}
          Heat {{state_attr ('climate.ac_versatile', 'temperature')}}°
        {% elif is_state('climate.ac_versatile', 'cool') %}
          Cool {{state_attr ('climate.ac_versatile', 'temperature')}}°
        {% else %}
          Off
        {% endif %}

Visuellement ça me donne deux lignes, la première représente le vrai thermostat du climatiseur tandis que la seconde celui du VT. Et l'on voit bien que pour une consigne fixée ici à 22° le VT pousse parfois le climatiseur à 23°.

Quand je l'utilisait en direct je lui demandais généralement 23° pour obtenir 22° à la sonde. C'est plus que les recommandations étatiques me direz vous, mais il y a une raison ! Avoir 22° dans le hall / couloir me permet d'avoir de 19° à 21° dans les pièces adjacentes, dans lesquelles les convecteurs ne se déclenchent que très rarement, au point que cet hiver je les ai laissés tous OFF. Le seul cas ou ils sont maintenant utiles étant lorsque mes enfants sont présents et ferment les portes de leur chambre (il est bien connu que les ados s'isolent... Et encore le, PC gamer de mon fils doit lui assurer une part de chauffage...).

Economies

Ici on entre dans un domaine difficilement mesurable. En effet la consommation d'un climatiseur est fonction d'une multitude de paramètres, les horaires, le temps qu'il fait, le nombre d'occupants, etc... Il n'en reste pas moins que si je compare la consommation de mon climatiseur avant et après la mise e place du VT j'ai l'impression d'avoir réduit la conso de ± 10%. C'est subjectif et ça demande à être affiné. Par contre ce qui est certain c'est que le fait de ne quasiment plus activer les convecteurs constitue un gain énorme. Et conjugué à une ITE réalisée en 2022 et l'automatisation des volets roulants en fonction de l'ensoleillement, j'ai grandement gagné en confort et en cout. 

L'interface

Il y a longtemps que j'utilise la carte Simple Thermostat qui est très malléable et permet l'affichage d'une multitude d'informations.

Hélas cette carte ne semble plus maintenue et je n'ai pas les compétences pour reprendre le développement, Jean-Marc si tu me lis...

Conclusion

VT est un vrai plus pour le confort ! Je n'ai pas abordé ici la partie refroidissement du climatiseur et je le ferait cet été quand els conditions seront réunies.

En plus c'est made in France et vous pouvez communiquer facilement avec Jean-Marc qui en est l'auteur et se montre très disponible sur le forum HACF ou sur GitHub. Merci à lui !

Home Assistant, Zigbee & Legrand

On m'a demandé récemment d'intégrer des appareils Legrand dans Home Assistant, je l'avais déjà fait pour certains et j'en avais parlé dans cet article. Aujourd'hui il s'agit d'intégrer des commandes sans fil vue come des télécommandes dans HA. Vous allez me demander quel est l'intérêt quand un simple bouton Ikea (E1743) à moins de 10 fait le job pour mes volets roulants. C'est purement esthétique, quand on a un logement équipé en Legrand Céliane ou Mosaic, on veut parfois que les commandes des volets soient dans la même collection.

Soit, Legrand propose des commandes en Zigbee, il n'y a plus qu'à !

Dans la pratique on va voir que ce n'est pas si simple, en tous cas bien moins simple qu'avec mon bouton Ikea à 10 € ! Je précise le prix car les commandes Legrand sont plutôt à 80 €. Mais quand on aime on ne compte pas.

Il existe plusieurs type d'équipements Zigbee chez Legrand

  • Ceux qui sont filaires, j'en ai parlé ici (micro modules, contacteur DIN, prise connectée, etc...)
  • La gamme des commandes sans fil à pile
  • La gamme des commandes sans fil sans piles (gamme Self-e). J'y reviendrait certainement, mais d'après mes infos cette gamme supporte tous les canaux et serait mieux intégrée ZHA/Z2M.

Je me suis donc penché sur la gamme avec pile.

Première observation, ces devices sont généralement livrés avec un firmware de niveau 42 qui ne permet que l'utilisation du canal Zigbee 11. Don impossible à faire fonctionner sur mon ZHA qui est en 15. Je l'ai donc appairé sur mon Z2M en 11 et ça fonctionne. Et là je me suis dit que j'allais pouvoir mettre à jour ce firmware en OTA. Mais non, ça ne fonctionne pas et on se retrouve dans la problématique des équipements franco Français qui n'intéressent pas grand monde au niveau international (on pense par exemple à tout ce qui est lié à l'intégration Overkiz...).

Après moultes lectures des forums de diverses plateformes domotique, la conclusion est que la mise à jour du firmware ne peut se faire qu'au travers d'une passerelle officielle Legrand ! J’ai donc acheté le kit qui comprend :

  • La prise Control qui sert de passerelle
  • Un inter sans fil
  • Une ampoule

Il faut bien sur installer l’appli Legrand et ensuite tenter d’associer la prise au WIFI. Facile ? Non, ça m’a pris de plombes car vu que leur process est trop long, le mobile qui se connecte à la prise pour la configurer repasse sur le WIFI normal ou il retrouve Internet, et perd la config en cours. Solution faire ça avec un vieux mobile… Bref, un premier amateurisme car on fait facilement ce genre d'association avec la majorité des objets mobile en WIFI !

Bon, la logique de l’appli est orientée électricien très grand public, avec une logique d'électricien qui n’est pas nécessairement la notre. C'est un choix, il faut s'y faire, mais n'oublions pas que nous sommes ici uniquement pour faire un mise à jour...

Ensuite il faut ajouter les inter. Sauf que la il faut comprendre qu’on ne peut pas ajouter un inter seul. Dans la logique Legrand si tu ajoute un inter, en fin de dialogue ça te demande ce que tu veux commander, sans quoi ça bloque et il n’y a plus qu’à forcer le redémarrage de l’appli et recommencer... Je n’avais pas de prise Legrand sous la main, mais au bout d’un moment j’ai fini par penser à appairer l’ampoule. Et la je vois enfin l’inter livré et mon inter de volet roulant qui ne peut rien commander, c’est le même mais avec un firmware différent.

Mais souvenons nous que nous somme là à jouer avec ce bazar dans le seul but de mettre à jour le firmware de ces putains d’inter qui au delà de couter un rein ne fonctionnent (mal) que sur le canal 11. Hélas il n’y arien pour faire cette mise à jour, mon inter de VR apparait en 42 dans l’appli et en 002a dans z2m, donc identique l’un étant en hexa. D’après ce que j’ai pu lire, la mise à jour se fera, un jour, mais on ne peut pas la forcer. Il faut juste laisser branché, en espérant que mon inter qui n’est pas connecté à un appareil se mette à jour tout seul…

Donc je laisse branché, la suite pour bientôt…

EDIT un peu plus tard :

  • L’inter (0 677 73N) est passé de 50 à 70
  • L’inter VR (0 777 48LA) n’a pas bougé…
  • Je testerais si on peut l’appairer hors du canal 11 mais je commence à douter…

EDIT le lendemain :

  • L’inter s’appaire bien sur un autre canal après sa mise à jour. Testé en ZHA sur 15, mais ZHA ne le supporte pas et rien ne bouge, aucun event.
  • L’inter VR ne s’est toujours pas mis à jour. Un peu comme s’il lui fallait une charge...

EDIT le lendemain soir :

  • L’inter VR est bien passé de 42 à 70, mon ZHA qui est sur le canal 15 le voit mais n’en fait rien. Quand à Z2M il n’en veut plus ! Pire ça me fait planter Z2M…

EDIT le sur lendemain midi :

  • L’inter VR qui ne veut toujours pas de ZHA ou Z2M s’est appairé correctement sur deconz en canal 15, il retourne dans les event les valeurs suivantes :

Montée : 1002 / Montée puis relâché : 1002/3002
Descente : 2002 / Descente puis relâché : 2002/3003
Stop (Les deux en même temps) : 3003

Ce comportement est identique à ce qu’il était sous Z2M et contrairement à d'autres télécommandes (le on/off Ikea (E1743 par exemple) il manque le fait qu’un second appui bref provoque un stop. Il faut donc bien appuyer au milieu pour faire un « stop » et ce n’est pas toujours pris en compte (problème physique).

Qu’il ne soit pas supporté sur ZHA est un fait, il faudrait développer un quirk et ça me dépasse. Je ne sais pas pourquoi il ne veut plus s’appairer sur Z2M, mais c’est peut être lié à mon installation, ma clé, que sais-je...

Il y a des chances que l’aventure Legrand va prendre fin et je que je retourne fissa ce Kit à Amazon !

Homekit

A signaler toutefois que cette passerelle est Homekit. Ce qui veut dire que ses équipements remontent dans Home Assistant. Mais ne rêvez pas trop, si l’ampoule remonte bien, et certainement tous les actionneurs connectés (prises, modules DIN), pas les inter En fait si, il faut juste attendre un peu. Néanmoins tout ne semble pas remonter, uniquement une action par bouton ! Mais j’avais déjà remarqué ça avec les télécommandes Tuya qui ne remontent pas via une passerelle Tuya Homekit. Il y a une forme de logique, Homekit sert à commander un équipement, comme une télécommande, hors on ne commande pas une télécommande…

Par contre ça veut dire que les équipements reconnus par Legrand vont remonter dans Homekit, ce qui peut être une solution de contrôle facile pour des produit pas reconnus par HA (Profalux, Bubendorf, Aldes, etc…).

La suite

Je vous propose de poursuivre ici et que chacun y apporte ses retours.

Sources

  • https://developer.legrand.com/production-firmware-download/

Home Assistant & Mi Boxer

J'avais acheté cette télécommande Mi Boxer il y a quelques mois afin de gérer les éclairages de mon séjour, en me disant que les curseurs seraient plus pratiques que mon Opple avec ses 6 boutons actuelle. Hélas elle n'était reconnue nulle part et avait terminé sa course dans le tiroir aux oubliettes du Zigbee...

C'était sans compter sur la ténacité de quelques amateurs de reverse engineering sur lesquels je suis tombé il y a quelques semaines et qui on fait un travail formidable qui a aboutit à une extension pour Zigbee2MQTT, ce qui rend cette télécommande enfin utilisable, tout au moins partiellement pour l'instant. Mais l'essentiel est là !

Ce qui fonctionne :

  • 7 boutons avec ON et OFF (deux actions et non un toggle). Celui du bas à droite n'est pas actif et je vous déconseille de l'utiliser...
  • 1 bouton avec ON et OFF (en haut)
  • 1 bouton W (si on veut bricoler...)
  • La barre de réglage de la luminosité
  • La remontée de l'état de la batterie

Ce qui ne fonctionne pas (pour l'instant) :

  • La barre de réglage des couleurs
  • La barre de réglage de la température du blanc
  • Les touches RGB
  • Les touches de temporisation (en bas à droite)

Une fois la télécommande reconnue sous Z2M on peut commencer à créer des actions. On remarque tout de suite que l'affaire va manquer de sensor: et que certains ne fonctionnent pas. Pas de panique, il y a une solution comme je vais vous le démonter avec l'automation: qui suit. 

J'ai fait un mélange de choose: / conditions: / trigger.id . C'est un peu long, mais je la colle en entier ce qui vous évitera une fastidieuse saisie. Il faudra tout de même y coller vous id: et entity: ! Ah j'allais oublier, il faut aussi ajouter un petit input_select: ... Voir plus bas EDIT du 11/01/2024 !

J'ai tenté de faire ça avec ControllerX que j'adore et qui me sert pour toutes mes télécommandes, mais pour l'instant c'est un échec !

alias: GUI - Mi Boxer
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.mi_boxeur_brightness
    id: bright
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_1_on
    discovery_id: 0x003c84fffec29c71_zone_1_button_on
    id: 1on
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_1_off
    discovery_id: 0x003c84fffec29c71_zone_1_button_off
    id: 1off
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_2_on
    discovery_id: 0x003c84fffec29c71_zone_2_button_on
    id: 2on
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_2_off
    discovery_id: 0x003c84fffec29c71_zone_2_button_off
    id: 2off
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_3_on
    discovery_id: 0x003c84fffec29c71_zone_3_button_on
    id: 3on
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_3_off
    discovery_id: 0x003c84fffec29c71_zone_3_button_off
    id: 3off
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_4_on
    discovery_id: 0x003c84fffec29c71_zone_4_button_on
    id: 4on
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_4_off
    discovery_id: 0x003c84fffec29c71_zone_4_button_off
    id: 4off
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_5_on
    discovery_id: 0x003c84fffec29c71_zone_5_button_on
    id: 5on
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_5_off
    discovery_id: 0x003c84fffec29c71_zone_5_button_off
    id: 5off
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_6_on
    discovery_id: 0x003c84fffec29c71_zone_6_button_on
    id: 6on
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_6_off
    discovery_id: 0x003c84fffec29c71_zone_6_button_off
    id: 6off
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_7_on
    discovery_id: 0x003c84fffec29c71_zone_7_button_on
    id: 7on
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_7_off
    discovery_id: 0x003c84fffec29c71_zone_7_button_off
    id: 7off
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_8_on
    discovery_id: 0x003c84fffec29c71_zone_8_button_on
    id: 8on
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: button_short_press
    subtype: button_group_8_off
    discovery_id: 0x003c84fffec29c71_zone_8_button_off
    id: 8off
    
condition: []
action:
  - choose:
      - conditions: "{{ trigger.id in ['1on'] }}"
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: light.shellydimmer_f3d426
          - service: input_select.select_option
            data:
              option: "1"
            target:
              entity_id: input_select.mi_boxer_select
      - conditions: "{{ trigger.id in ['1off'] }}"
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.shellydimmer_f3d426

      - conditions: "{{ trigger.id in ['2on'] }}"
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: light.shellydimmer_d3e57c
          - service: input_select.select_option
            data:
              option: "2"
            target:
              entity_id: input_select.mi_boxer_select
      - conditions: "{{ trigger.id in ['2off'] }}"
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.shellydimmer_d3e57c

      - conditions: "{{ trigger.id in ['3on'] }}"
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: light.ikea_e27_tv
          - service: input_select.select_option
            data:
              option: "3"
            target:
              entity_id: input_select.mi_boxer_select
      - conditions: "{{ trigger.id in ['3off'] }}"
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.ikea_e27_tv

      - conditions: "{{ trigger.id in ['4on'] }}"
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: light.lidl_led_stand
          - service: input_select.select_option
            data:
              option: "4"
            target:
              entity_id: input_select.mi_boxer_select
      - conditions: "{{ trigger.id in ['4off'] }}"
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.lidl_led_stand

      - conditions: "{{ trigger.id in ['5on'] }}"
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: light.dimmable_sm309
          - service: input_select.select_option
            data:
              option: "5"
            target:
              entity_id: input_select.mi_boxer_select
      - conditions: "{{ trigger.id in ['5off'] }}"
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.dimmable_sm309

      - conditions: "{{ trigger.id in ['6on'] }}"
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: light.shelly_bulb_1
          - service: input_select.select_option
            data:
              option: "6"
            target:
              entity_id: input_select.mi_boxer_select
      - conditions: "{{ trigger.id in ['6off'] }}"
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.shelly_bulb_1

      - conditions: "{{ trigger.id in ['7on'] }}"
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: light.led_strip_1
          - service: input_select.select_option
            data:
              option: "7"
            target:
              entity_id: input_select.mi_boxer_select
      - conditions: "{{ trigger.id in ['7off'] }}"
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.led_strip_1

      - conditions: "{{ trigger.id in ['8on'] }}"
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: 
                - light.shellydimmer_f3d426
                - light.shellydimmer_d3e57c
                - light.ikea_e27_tv
                - light.dimmable_sm309
                - light.shelly_bulb_1
                - light.lidl_led_stand
                - light.plug_tz_10_switch
                - light.led_strip_1
          - service: input_select.select_option
            data:
              option: "8"
            target:
              entity_id: input_select.mi_boxer_select
      - conditions: "{{ trigger.id in ['8off'] }}"
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: 
                - light.shellydimmer_f3d426
                - light.shellydimmer_d3e57c
                - light.ikea_e27_tv
                - light.dimmable_sm309
                - light.shelly_bulb_1
                - light.lidl_led_stand
                - light.plug_tz_10_switch
                - light.led_strip_1
              
      - conditions: >-
          {{ is_state('input_select.mi_boxer_select', '1') and trigger.id in ['bright'] }}
        sequence:
          - service: light.turn_on
            data:
              brightness_pct: "{{ trigger.to_state.state }}"
              transition: 0.2
            target:
              entity_id: light.shellydimmer_f3d426
            enabled: true

      - conditions: >-
          {{ is_state('input_select.mi_boxer_select', '2') and trigger.id in ['bright'] }}
        sequence:
          - service: light.turn_on
            data:
              brightness_pct: "{{ trigger.to_state.state }}"
              transition: 0.2
            target:
              device_id: 1ff4112785e14b8b8cba18d45fec3b11
            enabled: true

      - conditions: >-
          {{ is_state('input_select.mi_boxer_select', '3') and trigger.id in ['bright'] }}
        sequence:
          - service: light.turn_on
            data:
              brightness_pct: "{{ trigger.to_state.state }}"
              transition: 0.2
            target:
              entity_id: light.ikea_e27_tv
            enabled: true

      - conditions: >-
          {{ is_state('input_select.mi_boxer_select', '4') and trigger.id in ['bright'] }}
        sequence:
          - service: light.turn_on
            data:
              brightness_pct: "{{ trigger.to_state.state }}"
              transition: 0.2
            target:
              entity_id: light.lidl_led_stand
            enabled: true

      - conditions: >-
          {{ is_state('input_select.mi_boxer_select', '5') and trigger.id in ['bright'] }}
        sequence:
          - service: light.turn_on
            data:
              brightness_pct: "{{ trigger.to_state.state }}"
              transition: 0.2
            target:
              entity_id: light.dimmable_sm309
            enabled: true

      - conditions: >-
          {{ is_state('input_select.mi_boxer_select', '6') and trigger.id in ['bright'] }}
        sequence:
          - service: light.turn_on
            data:
              brightness_pct: "{{ trigger.to_state.state }}"
              transition: 0.2
            target:
              entity_id: light.shelly_bulb_1
            enabled: true

      - conditions: >-
          {{ is_state('input_select.mi_boxer_select', '7') and trigger.id in ['bright'] }}
        sequence:
          - service: light.turn_on
            data:
              brightness_pct: "{{ trigger.to_state.state }}"
              transition: 0.2
            target:
              entity_id: light.led_strip_1
            enabled: true
mode: restart

EDIT 11/01/2024

Avec la dernière mise à jour Zigbee2MQTT (1.35.1-1) il n’y a plus besoin de l’extension. Par contre ce que j’avais fait sur la base de ce qui est proposé ici ne fonctionne plus (bien que toujours dans la doc).

J’ai donc biaisé en faisant du mqtt direct :

Pour la détection (trigger:) des boutons (à dupliquer) :

- platform: mqtt
    topic: zigbee2mqtt/Mi Boxer
    payload: ('on', 101)
    value_template: "{{ value_json.action , value_json.action_group }}"
    id: 1on
  - platform: mqtt
    topic: zigbee2mqtt/Mi Boxer
    payload: ('off', 101)
    value_template: "{{ value_json.action , value_json.action_group }}"
    id: 1off

Et pour la luminosité (il me reste à trouver comment ne prendre en compte que la charge action_level) :

- platform: mqtt
    topic: zigbee2mqtt/Mi Boxer
    id: bright

Ensuite on modifie dans le chose: coté action (à dupliquer bien entendu :

      - conditions:
          - condition: template
            value_template: >-
              {{ is_state('input_select.mi_boxer_select', '2') and trigger.id in ['bright'] }}
        sequence:
          - service: light.turn_on
            data_template:
              entity_id: light.shellydimmer_d3e57c
              brightness_pct: "{{ trigger.payload_json.action_level }}"

EDIT 11/01/2024

Le problème avec la solution de mon EDIT précédent est que le trigger sur la charge MQTT globale génère trop de bruit. On va donc faire deux sensor: basés sur MQTT afin d'isoler la valeur de la luminosité (merci Mathieu) ainsi que le groupe (bouton) correspondant à la light: active, ce qui va nous permettre d'éliminer l'input_select: dans le filtrage à venir :

mqtt:
  sensor:
    - name: "Mi Boxer Bright"
      unique_id: "mi_boxer_bright"
      state_topic: "zigbee2mqtt/Mi Boxer"
      value_template: "{{ value_json.action_level |int }}"

    - name: "Mi Boxxer Group"
      unique_id: "mi_boxer_group"
      state_topic: "zigbee2mqtt/Mi Boxer"
      value_template: "{{ value_json.action_group |int }}"

En trigger: on utilisera l'action : action_brightness_move_to_level qui remonte dans HA :

trigger:
  - platform: device
    domain: mqtt
    device_id: 86c1403c24491ce021ac3ee081a86308
    type: action
    subtype: brightness_move_to_level
    discovery_id: 0x003c84fffec29c71 action_brightness_move_to_level
    id: bright

Et on complète notre action déclenchée par l'id: bright et filtrée sur le sensor: correspondant au bon bouton, et j'ai ajouté le light: actif afin de ne pas risquer une fausse manœuvre :

      - conditions:
          - condition: template
            value_template: >-
              {{ is_state('sensor.mi_boxer_group', '101') and trigger.id in ['bright'] and is_state('light.shellydimmer_f3d426', 'on') }}
        sequence:
          - service: light.turn_on
            data_template:
              entity_id: light.shellydimmer_f3d426
              brightness_pct: "{{ states('sensor.mi_boxer_bright') | int}}"

Il ne reste plus qu'à attendre que Z2M remonte les informations liées à la température du blanc et la roue chromatique et on pourra les traiter avec la même méthode.

 
 

 

 

Home Assistant & Arrosage

Je n'ai pas vraiment la main verte et et mon jardin ressemble souvent à un no man's land, mais au printemps dernier une amie m'a convaincu de créer un carré d'herbes aromatiques, l'idée à fait son chemin et au centre on a même planté des plants de tomates qui produisent bien cet été ! Bon, vous imaginez bien que je ne vais pas ici vous conter ma vie privée mais plutôt la part domotique de cette réalisation !

En Provence, si on veut un peu de verdure et espérer manger ses propres tomates, il n'y a pas de secret, il faut arroser ! J'ai donc commencé par disposer un tuyau poreux sur mon carré. Ensuite j'ai acheté un robinet Zigbee et préparé un petit scheduler qui me permet facilement d'activer ou pas la plage journalière d'arrosage. J'ai fait quelque chose de simple en m'inspirant de ce que j'avais fait pour mon chauffe eau. Je publie ici le code suite à quelques demandes, même si ça n'a pas une grande valeur ajoutée.

Pour l'instant ça ne prends pas en compte les valeurs remontés sur les capteurs de plantes car je n'en suis pas satisfait.

L'offre en matière de capteurs de plantes n'est pas énorme :

  • Le capteur Xiaomi (ou ses copies) qui fonctionnent en Bluetooth et que l'on trouve sur Amazon ou Ali Express : C'est ce qui fonctionne le "mieux", mais cela nécessite un proxy BLE à l'extérieur que l'on peut facilement se bricoler avec un ESP sous ESPHome.
  • Le capteur Rehent en Zigbee que j'ai acheté chez Domadoo : Et là c'est la déconvenue. Il est un peu encombrant mais ne pose pas de soucis particulier pour l'appairer en ZHA ou Z2M (ou sur une passerelle Tuya), sauf que si ce capteur remonte parfaitement la température du sol, l'humidité du sol reste invariablement entre 75% et 85% (voir les sources au bas de cet article). Et bien sur chez Domadoo on est pas chez Amazon, le client a tort et l'éventuel retour est à votre charge. Bref capteur et fournisseur à éviter ! Il semblerait qu'autres séries de ce capteur que l'on trouve chez AliExpress fonctionnent, mais là il faudra aussi oublier le retour...

J'utilise une vanne Zigbee Woox qui alimente le tuyaux poreux (que je devrais remplacer par un un goute à goute). Pour avoir un réseau Zigbee fiable à l'extérieur, j'ai installé sous la toiture de la terrasse des prises Zigbee dont le relais est HS mais qui continuent à remplir parfaitement leur rôle de routeur Zigbee.

Tout cela reste très expérimental... Coté intégration j'utilise Home Assistant Plant et la carte qui va avec.

Automation

Une automation de schedule simple et visuelle :

input_datetime:
  watering_start:
    has_date: false
    has_time: true
  watering_stop:
    has_date: false
    has_time: true

input_boolean:
  watering_day_monday:
    name: "WATERING : Lundi"
    icon: mdi:toggle-switch
  watering_day_tuesday:
    name: "WATERING : Mardi"
    icon: mdi:toggle-switch
  watering_day_wednesday:
    name: "WATERING : Mercredi"
    icon: mdi:toggle-switch
  watering_day_thursday:
    name: "WATERING : Jeudi"
    icon: mdi:toggle-switch
  watering_day_friday:
    name: "WATERING : Vendredi"
    icon: mdi:toggle-switch
  watering_day_saturday:
    name: "WATERING : Samedi"
    icon: mdi:toggle-switch
  watering_day_sunday:
    name: "WATERING : Dimanche"
    icon: mdi:toggle-switch

automation:

- id: 'xx8d0e1-fcb6-4412-abvxx-99c4d37be5xx'
  alias: 'WATERING ON'
  trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.watering_start.state[0:5] }}'
  condition:
    condition: or
    conditions:
      - '{{ (now().strftime("%a") == "Mon") and is_state("input_boolean.watering_day_monday", "on") }}'
      - '{{ (now().strftime("%a") == "Tue") and is_state("input_boolean.watering_day_tuesday", "on") }}'
      - '{{ (now().strftime("%a") == "Wed") and is_state("input_boolean.watering_day_wednesday", "on") }}'
      - '{{ (now().strftime("%a") == "Thu") and is_state("input_boolean.watering_day_thursday", "on") }}'
      - '{{ (now().strftime("%a") == "Fri") and is_state("input_boolean.watering_day_friday", "on") }}'
      - '{{ (now().strftime("%a") == "Sat") and is_state("input_boolean.watering_day_saturday", "on") }}'
      - '{{ (now().strftime("%a") == "Sun") and is_state("input_boolean.watering_day_sunday", "on")}}'
  action:
  - service: switch.turn_on
    entity_id: switch.vanne_woox_switch
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M')}} > WATERING | START | Soil : {{ states.sensor.soil_01_soil_moisture.state }}%" 


- id: 'zz9csdfsef-76dd-4fdd-9dzz-40bfsdq158zz'
  alias: 'WATERING OFF'
  trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.watering_stop.state[0:5] }}'
  action:
  - service: switch.turn_off
    entity_id: switch.vanne_woox_switch
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M')}} > WATERING | STOP | Soil : {{ states.sensor.soil_01_soil_moisture.state }}%"   

La carte Lovelace :

type: vertical-stack
cards:
  - type: entities
    entities:
      - entities:
          - entity: automation.watering_on
            name: false
          - entity: sensor.energy_total_yearly_1pm_watering
            name: false
            unit: kWh
            format: precision2
          - entity: sensor.soil_01_soil_moisture
            name: false
        entity: switch.vanne_woox_switch
        name: Arrosage
        icon: mdi:watering-can-outline
        show_state: false
        state_color: true
        type: custom:multiple-entity-row
  - type: horizontal-stack
    cards:
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_monday
        name: Lundi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_tuesday
        name: Mardi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_wednesday
        name: Mercredi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_thursday
        name: Jeudi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_friday
        name: Vendredi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_saturday
        name: Samedi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_sunday
        name: Dimanche
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
  - type: conditional
    conditions:
      - entity: automation.watering_on
        state: 'on'
    card:
      type: custom:vertical-stack-in-card
      cards:
        - type: horizontal-stack
          cards:
            - type: markdown
              content: '#### <center> Heure de début'
            - type: markdown
              content: '#### <center> Arrosage'
            - type: markdown
              content: '#### <center> Heure de Fin'
        - type: horizontal-stack
          cards:
            - entity: input_datetime.watering_start
              type: custom:time-picker-card
              name: Début
              layout:
                align_controls: center
                embedded: true
              hide:
                name: true
                icon: true
            - type: glance
              show_state: true
              show_name: false
              entities:
                - switch.vanne_woox_switch
            - entity: input_datetime.watering_stop
              type: custom:time-picker-card
              layout:
                align_controls: center
                embedded: true
              hide:
                name: true
                icon: true
  - color_thresholds:
      - color: '#039BE5'
        value: 0
      - color: '#0da035'
        value: 19
      - color: '#e0b400'
        value: 25
      - color: '#e45e65'
        value: 2400
    color_thresholds_transition: hard
    entities:
      - entity: sensor.plant_01_moisture
        name: Humidité du sol
      - entity: sensor.plant_01_temperature
        name: Températire du sol
      - color: rgba(0,0,255,1)
        entity: binary_sensor.night_reworked
        name: Nuit
        show_line: false
        y_axis: secondary
    group: false
    hour24: true
    hours_to_show: 24
    line_width: 2
    name: Humidité et température du sol
    points_per_hour: 4
    show:
      extrema: true
      fill: fade
      icon: true
      labels: false
      name: true
      state: true
    state_map:
      - label: Day
        value: 'off'
      - label: Night
        value: 'on'
    type: custom:mini-graph-card
  - type: custom:flower-card
    entity: plant.jardin
    show_bars:
      - illuminance
      - humidity
      - moisture
      - conductivity
      - temperature
      - dli
    battery_sensor: sensor.demo_battery

Souces

Capteur Rehent

 

Home Assistant & Plug Security

On utilise souvent des prises commandées uniquement pour mesurer la consommation de certains appareils. Ces prises sont toujours en position ON. Ces prises, si elles ne sont pas de trop mauvaise qualité un mécanisme de sécurité intégré qui les passent OFF en cas de surtension ou de surcharge. Et dans la pratique ça arrive parfois et on constate plus tard que le lave linge ou le lave vaisselle s'est arrêté, ou pire dans le cas d'un congélateur.

Pour palier à cet inconvénient on va créer une automation qui va réarmer la prise après quelques minutes en OFF. Jusque là c'est simple, mais il se peut également que le problème soit plus grave et qu'il ne faille pas forcer indéfiniment ce réarmement automatique. Etant donné qu'on ne dispose généralement pas d'information sur la cause de ce passage en sécurité on va considérer qu'au bout de "n" tentatives sur un temps donné on ne réarme plus. Pour ça on va utiliser des compteurs (à créer avec un minimum à 0 et un maximum à 10) et on fera un reset de ceux-ci toutes les nuits...

J'ai fixé ici arbitrairement à 5 le nombre de réarmements possibles.

Attention : Je vous explique ici comment j'ai fait, mais un risque existe toujours et la mise en œuvre de cette solution est à vos risques (et périls). Je me dégage ainsi de toute responsabilité.

On va faire ça avec une seule automation que j'ai voulue la plus concise et qui servira également à notifier :

automation:
- id: '2bd0ertyyf-2687-45f98f-aed0-to-off'
  alias: "Notify Plug Off"
  description: "Notification mise en sécurité des prises"
  mode: single
  trigger:
    - platform: state
      entity_id: switch.bw_1
      to: "off"
      id: "Lave Vaisselle"
    - platform: state
      entity_id: switch.bw_2
      to: "off"
      id: "Lave Linge"
    - platform: state
      entity_id: switch.bw_3
      to: "off"
      id: "Seche Linge"
    - platform: state
      entity_id: switch.bw_4
      to: "off"
      id: "Congelateur"
    - platform: time
      at: "00:05:00"
      id: "Reset"
  condition: []
  action:
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0  
  - choose:
      - conditions: "{{ trigger.id in ['Lave Vaisselle'] and states('counter.plug_bw_1') | int < 5 }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.bw_1
          - service: counter.increment
            target:
              entity_id: counter.plug_bw_1
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Réarmement n°{{ states('counter.plug_bw_1')}} du {{ trigger.id }}"               

      - conditions: "{{ trigger.id in ['Lave Linge'] and states('counter.plug_bw_2') | int < 5 }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.bw_2
          - service: counter.increment
            target:
              entity_id: counter.plug_bw_2
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Réarmement n°{{ states('counter.plug_bw_2')}} du {{ trigger.id }}" 

      - conditions: "{{ trigger.id in ['Seche Linge'] and states('counter.plug_bw_3') | int < 5 }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.bw_3
          - service: counter.increment
            target:
              entity_id: counter.plug_bw_3
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Réarmement n°{{ states('counter.plug_bw_3')}} du {{ trigger.id }}" 

      - conditions: "{{ trigger.id in ['Congelateur'] and states('counter.plug_bw_4') | int < 5 }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.bw_4
          - service: counter.increment
            target:
              entity_id: counter.plug_bw_3
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Réarmement n°{{ states('counter.plug_bw_4')}} du {{ trigger.id }}" 

      - conditions: 
          - condition: or
            conditions:
              - "{{ trigger.id in ['Lave Vaisselle'] and states('counter.plug_bw_1') | int >= 5 }}"
              - "{{ trigger.id in ['Lave Linge'] and states('counter.plug_bw_2') | int >= 5 }}"
              - "{{ trigger.id in ['Seche Linge'] and states('counter.plug_bw_3') | int >= 5 }}"
              - "{{ trigger.id in ['Congelateur'] and states('counter.plug_bw_4') | int >= 5 }}"
        sequence:
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Problème avec le {{ trigger.id }}. On ne réarme plus, une vérification s'impose." 

      - conditions: "{{ trigger.id in ['Reset'] }}"
        sequence:
          - service: counter.reset
            target:
              entity_id:
                - counter.plug_bw_1
                - counter.plug_bw_2
                - counter.plug_bw_3
                - counter.plug_bw_4

Home Assistant & Alarm, encore...

J'ai souvent parlé d'alarme ici, de télécommandes, de claviers et de sirènes. Je pense cette fois être parvenu à quelque chose de fonctionnel et je vais vous en parler. Pour faire face aux différentes contraintes, notamment la gestion bizarre des télécommandes sous ZHA, il va falloir un peu ruser. Avant que vous me demandiez pourquoi je m'obstine sous ZHA alors que ces mêmes télécommandes sont bien gérées sous Z2M, je vous répondrait que mon objectif est la simplification et donc d'éviter le plus possible les adons qui complexifient une installation, pas forcément pour moi ou je dispose de toutes les passerelles possibles, mais sur des installations que je gère à distance ou je me dois de faire simple et fiable.

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

Afin de gérer toutes les contraintes, je vais principalement m'appuyer sur deux automations:, quelques scripts: et un alarm_control_panel: virtuel.

L'objectif est de gérer :

  • Un mode absent (away) (avec une variable pour simuler un peu de présence).
  • Un mode présent/nuit armé (home) (plus ou moins utile mais mais ça fait partie de tout système d'alarme face au home jacking.
  • Un mode alerte (emergency) qui va permettre de déclencher une action d'urgence en appuyant sur un bouton de télécommande ou médaillon (je pense à mes vieux jours).

De l'armement / désarmement vont également découler :

  • La fermeture complète ou partielle des volets roulants, leur réouverture cohérente avec la programmation en cours et éventuellement le passage en manuel des volets des chambres des enfants / invités s'ils sont présents.
  • La gestion du climatiseur et des convecteurs avec passage en mode éco ou absent en fonction du type d'armement).
  • La gestion du chauffe eau en cas d'absence de longue durée.
  • La gestion des éclairages et la mise en veille des écrans et ordinateurs.
  • ...

Etant donné que j'ai deux systèmes d'alarme qui fonctionnent en parallèle (Alarmo et Visonic), j'ai commencé par créer une alarme virtuelle et je me servirait d'elle pour les différentes actions.

alarm_control_panel:
  - platform: manual
    name: Home Alarm Command
    code: 1234
    code_arm_required: false
    disarm_after_trigger: false
    arming_time: 0
    delay_time: 0
    trigger_time: 600
    disarmed:
      trigger_time: 0
    armed_home:
      arming_time: 0
      delay_time: 0

L'Armement / Désarmement

L'armement / désarmement va pouvoir se faire de plusieurs façons :

  • Clavier à code
  • Télécommande dédiée
  • Application mobile
  • Tag RFID (pour désarmer dans mon cas)

J'ai volontairement écarté les télécommandes radio en 433 Mhz dont j'avais parlé ici, d'une part parce qu'elles sont facilement piratables, et d'autre part parce qu'elles ne permettent pas de savoir qui a désarmé le système.

Je vais utiliser deux automations et les découper ce dessous/

  • La première pour gérer les armements / désarmements
  • La seconde pour gérer le désarmement des télécommandes, claviers à code afin d'intégrer les particularités ZHA (en attendant une amélioration de la part des développeurs de Home Assistant qui pour l'instant font la sourde oreille, parfois plus concentrés sur les nouveautés que l'affinage de l'existant).

Gestion de l'armement / désarmement et des boutons d'urgence

Les déclencheurs : Ici on va empiler nos déclencheurs d'armement, qu'ils soient gérés par ZHA, Z2M ou toute autre source. 3 par fonction, armed_away, armed_home, triggered, mais cela peut également être un bouton virtuel pour Lovelace, voire n'importe quelle télécommande ou bouton poussoir.

- id: 078fsdg412-3545-4f37-ba02-bccsfds5646sf
  alias: "Alarm : Global ON/OFF"
  mode: restart
  trigger:
    - platform: device
      device_id: c036b6547a0347878dcc6d06152267ab
      domain: alarm_control_panel
      entity_id: alarm_control_panel.lk_zb_keypad
      type: armed_away
      id: "KeyPad Away"
    - platform: device
      device_id: c036b6547a0347878dcc6d06152267ab
      domain: alarm_control_panel
      entity_id: alarm_control_panel.lk_zb_keypad
      type: armed_home
      id: "KeyPad Home"
    - platform: device
      device_id: c036b6547a0347878dcc6d06152267ab
      domain: alarm_control_panel
      entity_id: alarm_control_panel.lk_zb_keypad
      type: triggered
      id: "KeyPad Triggered"
    - platform: state
      entity_id: input_button.arm_alarm_away
      id: "Push Button Away"

Et un déclencheur de désarmement activé par une seconde automation que l'on verra plus loin :

    - platform: state
      entity_id:
        - alarm_control_panel.home_alarm_command
      to: disarmed
      id: "Remote or Keypad"

Les conditions : Dans mon cas je n'en ai pas utilisé. Chacun adaptera.

  condition:

Les actions

Je commence par arrêter les éventuels scripts en cours. Cela est principalement utile quand on a fermé la porte, armé le système et que l'on doit rapidement désarmer car on a oublié quelque chose dans la maison.

  action:
    - service: homeassistant.turn_off
      target:
        entity_id:
          - script.privacy_on
          - script.privacy_off
          - script.alarmo_after_arm
          - script.alarmo_after_disarm
          - script.alarm_actions_on_leave_common_tasks
          - script.alarm_actions_on_return_common_tasks

Ensuite on va utiliser chose: pour exécuter les différentes actions en fonction de la source et de l'état.

On commence par l'armement en mode absent :

  • On envoie les bips d'armement sur la sirène. En MQTT pour l'instant car elle aussi est très mal gérée sous ZHA
  • On arme Alarmo
  • On arme Visonic (en mode Home sans les PIR qui déraillent).
  • On arme notre panneau d'alarme virtuel qui nous servira au désarmement
  • On arme également le clavier, ça ne change rien à l'usage mais quand on se présentera pour désarmé il apparaitra comme étant armé. Dans la pratique ça relance de fait l'automation avec la même automation, et donc ça fausse le message, j'ai donc retiré cette option pour l'instant. (D'ailleurs si vous êtes sous Z2M il le développeur d'Alarmo a fait un joli travail pour ce clavier).
  • On inscrit un message texte dans un input_text: que l'on affiche dans Lovelace et qui nous permet de savoir qui fait quoi. A terme je remplacerait les id: par le prénom de l'utilisateur pour plus de lisibilité.
    - choose:
        - conditions: "{{ trigger.id in ['KeyPad Away', 'Heiman RC1 Away', 'Heiman RC2 Away', 'Woox RC1 Away'] }}"
          sequence:
            - service: mqtt.publish
              data:
                topic: zigbee2mqtt/Sirène SMaBiT/set
                payload: >-
                  {"squawk": {"state": "system_is_armed", "level": "veryhigh", "strobe": "true"}}     
            - service: alarm_control_panel.alarm_arm_away # ALARMO Away
              data:
                code: !secret alarm_code
              entity_id: alarm_control_panel.alarmo
            - service: alarm_control_panel.alarm_arm_home # VISONIC Home (ne jamais armer AWAY à cause des détecteurs HS)
              data:
                code: !secret alarm_code_visonic
              entity_id: alarm_control_panel.visonic_alarm
            - service: script.alarm_actions_on_leave_common_tasks
            - service: alarm_control_panel.alarm_arm_away # FAKE ALARM PANEL Away
              target:
                entity_id: alarm_control_panel.home_alarm_command
            - service: alarm_control_panel.alarm_arm_away # On arme le clavier afin qu'il apparaisse armé
              data:
                code: !secret alarm_code_zha
              target:
                entity_id: 
                  - alarm_control_panel.lk_zb_keypad
            - service: input_text.set_value
              target:
                entity_id: input_text.last_arm
              data:
                value: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Arm Away by : {{ trigger.id }}"                            

On fait la même chose pour le mode home. Je fais l'impasse sur Visonic, par contre j'émet un son de confirmation sur un buzzer (on verra plus loin l'utilisation possible d'un TTS sur une enceinte.

        - conditions: "{{ trigger.id in ['KeyPad Home', 'Heiman RC1 Home', 'Heiman RC2 Home', 'Woox RC1 Home'] }}"
          sequence:
            - service: alarm_control_panel.alarm_arm_home # ALARMO Home
              data:
                code: !secret alarm_code
              entity_id: alarm_control_panel.alarmo
            - service: alarm_control_panel.alarm_arm_home # FAKE ALARM PANEL Home
              target:
                entity_id: alarm_control_panel.home_alarm_command
            - service: alarm_control_panel.alarm_arm_home # On arme le clavier afin qu'il apparaisse armé
              data:
                code: !secret alarm_code_zha
              target:
                entity_id: 
                  - alarm_control_panel.lk_zb_keypad

            - service: button.press
              target:
                entity_id: button.up_chime_play_buzzer
            - service: input_text.set_value
              target:
                entity_id: input_text.last_arm
              data:
                value: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Arm Home by : {{ trigger.id }}"                                    

Ensuite on passe au désarmement du mode absent. On remarque que l'on écrit pas d'input_text: car ici on ne sait pas qui a fait quoi car l'ordre vient de la seconde automation que l'on verra plus loi. C'est donc elle qui écrira. Par contre on émet le son de désarmement sur la sirène.

        - conditions: "{{ trigger.id in ['Remote or Keypad'] and is_state('alarm_control_panel.alarmo', 'armed_away') }}"
          sequence:              
            - service: alarm_control_panel.alarm_disarm
              data:
                code: !secret alarm_code
              entity_id:  
                - alarm_control_panel.alarmo
                - alarm_control_panel.visonic_alarm
            - service: mqtt.publish
              data:
                topic: zigbee2mqtt/Sirène SMaBiT/set
                payload: >-
                  {"squawk": {"state": "system_is_disarmed", "level": "veryhigh", "strobe": "true"}}       

Pareil pour le mode Home. Ici on joue un son sur le buzzer.

        - conditions: 
            - "{{ trigger.id in ['Push Button'] }}"
            - "{{ is_state('alarm_control_panel.alarmo', 'armed_home') }}"
          sequence:              
            - service: alarm_control_panel.alarm_disarm
              data:
                code: !secret alarm_code
              entity_id:  
                - alarm_control_panel.alarmo
            - service: button.press
              target:
                entity_id: button.up_chime_play_buzzer

On continue avec la gestion du bouton d'urgence :

  • On joue un son pour confirmer
  • On arme notre panneau d'alarme virtuel dans un mode inutilisé (Nuit) pour ensuite pouvoir désarmer.
  • On envoie un SMS d'Au Secours, ou toute autre action à imaginer.
  • On écrit un input_text: pour avoir une trace.
        - conditions: "{{ trigger.id in ['KeyPad Triggered', 'Heiman RC1 Triggered', 'Heiman RC2 Triggered', 'Woox RC1 Triggered'] and is_state('alarm_control_panel.alarmo', 'disarmed') }}"
          sequence:              
            - service: button.press
              target:
                entity_id: button.up_chime_play_chime
            - service: alarm_control_panel.alarm_arm_night # FAKE ALARM PANEL Night pour pouvoir désarmer
              target:
                entity_id: alarm_control_panel.home_alarm_command
            - service: notify.free_mobile_andre
              data:
                message: "{{ states.sensor.date_time.state}} > TEST Alerte au secours par télécommande TEST"
            - service: input_text.set_value
              target:
                entity_id: input_text.last_arm
              data:
                value: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Triggered by : {{ trigger.id }}"   

Enfin, on désarme cette alerte. A ce stade on peut aussi envoyer un SMS pour dire que c'était une fausse alerte... Je vais me contenter de jouer du buzzer...

        - conditions: 
            - "{{ trigger.id in ['Remote or Keypad'] and is_state('alarm_control_panel.alarmo', 'disarmed') }}"
          sequence:              
            - service: button.press
              target:
                entity_id: button.up_chime_play_buzzer

Le cas des tag RFID

Les tags RFID c'est sympa, mais hormis en coller deux cote à cote on ne pourra basiquement gérer qu'un seule information : tag_scanned

Hors, l'idée est de se servir d'un même tag collé à la porte pour armer ou désarmer. S'il s'agissait d'un switch on ferait un switch.toggle, mais pas pour une alarme. Il va falloir ruser.

Bien sur on pourrait mettre une condition pour savoir connaitre l'état de l'alarme, mais je ne veux pas utiliser de condition et uniquement un trigger avec son id:. J'ai passé des heures à essayer de faire un trigger template pour combiner le scan du tag + l'état de alarm_control_panel, mais sans succès car le tag n'est pas un device ou un entity ou l'on peut facilement lire l'état.

La solution consiste à créer un binary_sensor: temporisé :

template:
  - trigger:
      - platform: event
        event_type: tag_scanned
        event_data:
          tag_id: bf5018c7-c1a9-4220-a01a-66f885176795
#          name: Tag Green
#          device_id: 1d3ddfgy45805354ce090774e3f22510
    binary_sensor:
      name: Tag Green
      state: "{{ trigger.platform == 'event' }}"
      auto_off:
        seconds: 1

A noter que name: peut être utilisé à la place de tag_id: et que l'on peut jouer avec les autres informations que l'on trouve dans l'event afin par exemple de savoir quel appareil a scanné le tag et ainsi savoir qui a armé ou désarmé... 

Et ensuite il sera facile de créer un trigger basé sur un petit template et se servir de son id: pour action dans le chose:

  - platform: template
    value_template: "{{ is_state('binary_sensor.tag_green', 'on') and is_state('alarm_control_panel.alarmo', 'armed_home') }}"
    id: tag_to_disarm

Gestion des commandes de désarmement

Au risque de me répéter, cette partie aurait pu être intégrée à la première automation, si ZHA ne posait pas problème... Je le ferait probablement, mais pour l'exemple on va pour l'instant scinder cette partie.

Donc, pour les télécommandes d'alarme sous ZHA on va devoir écouter un event:, s'en servir pour désarmer nos système d'alarme mais également pour la désarmer et désarmer ses copines ainsi que le clavier. Simple ! J'avais exploré dans un précédent article plusieurs pistes afin de ne prendre en compte qu'un seul de ses "events" (en + elle en envoie 3 ou 4 identiques selon l'humeur et le modèle). J'ai un peu avancé et on ne va pas les écouter dans l'automation, mais se servir de l'état temporaire d'un binary_sensor: que l'on va pouvoir temporiser et ainsi ne prendre en compte qu'un seul event:

template:
  - trigger:
      - platform: event
        event_type: zha_event
        event_data:
          device_ieee: a4:c1:38:96:0b:cf:c9:61 # Woox RC1
          command: 'arm'
          args:
            arm_mode: 0
            arm_mode_description: 'Disarm'
            code: ''
            zone_id: 0
    binary_sensor:
      name: Woox RC1 to Disarmed
      icon: "{{ (trigger.platform == 'event') | iif('mdi:remote-off', 'mdi:remote') }}"
      state: "{{ trigger.platform == 'event' }}"
      auto_off:
        seconds: 5

Les déclencheurs : Ici on va écouter des actions de désarmement, que cela provienne d'un clavier, une télécommande (via leur binary_sensor:), ou en direct pour une source classique (tag RFID, MQTT, ...).

- id: '2bd0ertyyf-43fa-45f98f-aed0-disarm'
  alias: "Alarm @ Remote Disarm"
  description: 'Disarm Remote Control panel'
  mode: single
  trigger:
    - platform: state
      entity_id: binary_sensor.heiman_rc1_to_disarmed
      to: "on"
      id: "Heiman RC 1"  
    - platform: tag
      tag_id: 2b855225-c999-4b5558123-6c7d12345641
      id: "TAG Jaune"
    - platform: device
      domain: mqtt
      device_id: 139eb4ce27246465b0d5aa7560a953601
      type: action
      subtype: disarm
      discovery_id: 0x84fd27fffe915905 action_disarm
      id: "Heiman RC2"

Les conditions : Aucune, mais on pourrait imagine un flag de blocage activé à distance après une alerte...

condition:

Les actions : On utilise un chose: et on commence par :

  • Désarmer le panneau d'alarme virtuel, ce qui déclenchera l'action idoine dans la première automation.
  • Désarmer les télécommandes et claviers qui sont également des panneaux d'alarme, avec cette particularité ZHA qui fait qu'il faut un code pour désarmer une télécommande...
  • Ecrire un input_text: afin de savoir qui a désarmé.
  • J'envoie un message dans Slack qui me sert de log. Ca va également m'informer à distance que quelqu'un est arrivé et a désarmé 
  action:
    - choose: # DISARM
        - conditions: "{{ trigger.id in ['Push Button', 'KeyPad', 'Linkind RC', 'Heiman RC 1', 'Woox RC 1', 'TAG Porte', 'TAG Jaune', 'TAG Clé', 'TAG Carte', 'Heiman RC2' ] }}"
          sequence:
            - service: alarm_control_panel.alarm_disarm   # FAKE ALARM PANEL to Command
              data:
                code: "1234"
              target:
                entity_id: alarm_control_panel.home_alarm_command
            - service: alarm_control_panel.alarm_disarm
              data:
                code: !secret alarm_code_zha
              target:
                entity_id: 
                  - alarm_control_panel.lk_zb_keypad
                  - alarm_control_panel.lk_zb_remote
                  - alarm_control_panel.heiman_remote
                  - alarm_control_panel.woox_01
            - service: input_text.set_value
              target:
                entity_id: input_text.last_disarm
              data:
                value: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Disarm by : {{ trigger.id }}"
            - service: notify.slack_hass_canaletto
              data:
                message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Disarmed by : {{ trigger.id }}" 

On peut également faire une place à une fonctionnalité détournée du clavier. En effet au delà de l'amenée Home, Away et Emergency, on peut également lui faire avaler n'importe quel code et effectuer une action précise en fonction de celui ci. Ici si je saisit 33 et valide je vais allumer les projecteurs.

    - choose:
        - conditions: "{{ trigger.id in ['KeyPad 33'] }}"
          sequence:
            - service: light.turn_off
              target:
                entity_id:
                  - light.groupe_de_projecteurs          

Enfin j'ai quelques actions par défaut, comme éteindre les sirènes au cas ou... (ça sent le debug...).

    - service: mqtt.publish
      data:
        topic: zigbee2mqtt/Sirène SMaBiT/set
        payload: >-
          {"warning": {"mode": "stop"}}
    - service: siren.turn_off
      target:
        entity_id:
          - siren.heiman_sirene_1
          - siren.heiman_sirene_2
          - siren.sirene_terrasse                

Et surtout on ajoute un délai car ces télécommandes ont la fâcheuse idée d'envoyer 3 ou 4 event: identique pour chaque appui. Donc combiné au mode: single de cette automation, on va en capturer qu'un seul. Ce délais est bien sur à ajuster plus ou moins au pif... Maintenant que je passe par des binary_sensor: temporisés, je pense que ce délai est devenu inutile.

    - delay : '00:00:08'

Les actions POST Armement / Désarmement

On va utiliser deux scripts qui seront exécutés par Alarmo après l'armement et après le désarmement. Chez moi ils vont servir à :

  • Jouer une annonce vocale en TTS sur une enceinte extérieure pour annoncer l'état armé ou désarmé.
  • Activer ou désactiver la vidéo surveillance.
  • Passer les volets en mode manuel et automatique au retour (voir l'automatisation des volets).
  • Gérer le mode ECO/Absent du climatiseur et des convecteurs.
  • Gérer les éclairages et le mode veille de mon PC.
  • Et plus encore selon votre imagination....

Les notifications d'alarme et sirènes

  • Notifications SMS pour l'intrusion, la détection incendie ou fuite d'eau. (notifications gérées par Alarmo).
  • Sirènes et projecteurs en cas d'intrusion :
    • la législation autorise au maximum 3 minutes pour chaque lancement de sirène.
    • Pas de limite pour les projecteurs. Et éclairer comme en plein jour peut également faire fuir et permettra d'avoir des images bien nettes sur les caméras.
    • Si vous avez un système audio multi room bien puissant, vous pouvez également envoyer une bonne salve d'AC-DC, ça peu perturber... ou inciter les voisins à appeler la maréchaussée.
    • Les armes, explosifs et autres gaz toxiques sont à proscrire.

Pour cela on va utiliser des scripts: qui seront lancés par Alarmo selon les conditions choisies (voir ici).

Etant donné que j'ai des détecteurs d'ouverture sur mes volets roulants, je peux également imaginer l'éclairage extérieur avant de déclencher l'alarme si un de ces volets est touché. Il faut être prévenant et éclairer l'intrus. Cela peut se gréer dans une partition secondaire d'Alarmo, ou simple une automation. Les caméras Unifi Protect (G4) font également de la détection de personne qui remonte dans Home Assistant.

Voilà, ce n'est pas exhaustif, vos idées son les bienvenues, ici ou sur HACF.

 

 

Home Assistant & Sirènes

J'ai déjà parlé ici du système d'alarme Alarmo pour Home Assistant et notamment des commandes possibles pour armer et désarmer le système. Aujourd'hui il s'agira des sirènes.

J'ai trois modèles

  • La plus basique est juste branchée sur une prise commandée Zigbee ondulée. Donc un switch: vu en tant que siren:.
  • Une sirène Heiman qui sous ZHA décroche régulièrement et que j'ai du appairer à ma seconde passerelle sous Z2M.
    • Sous ZHA elle était vue en tant que siren:.
    • Sous Z2M elle est vue en tant que rien du tout...
  • Une sirène SMaBit sous Z2M également vue en rien du tout...

Pour commander une sirène via ZHA HA propose :

    - service: siren.turn_on
      target:
        entity_id:
          - siren.heiman_sirene

Pour commander une sirène sous Z2M il faut lui envoyer le payload correspondant :

    - service: mqtt.publish
      data:
        topic: zigbee2mqtt/Sirène SMaBiT/set
        payload: >-
          {"warning": {"mode": "fire", "level": "very_high", "strobe_level": "low", "strobe": "false", "strobe_duty_cycle": "10", "duration": "360"}}

Un peu plus compliqué et moins facile à mémoriser, mais ça fonctionne.

Mon objectif a donc été de faire en sorte qu'une sirène Z2M soit vue par Home Assistant comme une sirène ZHA et ainsi pouvoir la commander par un siren.turn_on comme les autres... Et voici ce que ça donne :

mqtt:
  siren:
    - unique_id: heiman_sirene_1s
      name: Heiman Sirène 1s
      state_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      optimistic: false
      qos: 0
      retain: true
      state_value_template: "{{ value_json.warning['mode'] }}"
      command_template: '{"warning": {"duration": 2, "mode": "burglar", "level": "very_high", "strobe": true}}'
      command_off_template: '{"warning": {"duration": 2, "mode": "stop", "level": "very_high", "strobe": true}}'
      state_on: "burglar"
      state_off: "stop"

Problème, car il y en a un, la sirène Heiman ne retourne aucun état sous Z2M. Il y a beaucoup d'articles à ce sujet, et l'intégration ne semble pas vraiment terminée. Hors dans l'activation il y a une durée, le principe étant d'activer la sirène pour x secondes. Et donc comme elle ne retourne pas son état, son commutateur restera sur ON alors que le délais d'activation est terminé et la prochaine action n'aura aucun effet... De plus certaines sirènes proposent plusieurs fonctions et tonalités (les bips de délais d'armement et désarmement par exemple).

Donc contrairement à ZHA ou l'intégration siren: peut gérer tous les modes, chercher à gérer une sirène Z2M en tant que siren: n'a pas de sens... (hormis peut être de bricoler un template: qui en fonction de la durée d'activation repasserait le commutateur à off, on peut aussi le faire via une automation: mais là ça va alourdir la chose...).

Alternative

S'agissant d'envoyer un payload à une sirène Z2M, ce que j'ai trouvé de plus logique est un mqtt:/button: et il faut donc en faire deux :

mqtt:
  button:
    - unique_id: siren_heiman_1_warning
      name: "Sirène Heiman 1 : Waraning"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      payload_press: '{"warning": {"duration": 2000, "mode": "burglar", "level": "very_high", "strobe": true}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_heiman_1_stopped
      name: "Sirène Heiman 1 : Stopped"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      payload_press: '{"warning": {"duration": 2, "mode": "stop", "level": "very_high", "strobe": true}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"   

Ou plusieurs pour gérer les différents mode de la SMaBit :

mqtt:
  button:
    - unique_id: siren_smabit_armed
      name: "Sirène SMaBit : Armed"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"squawk": {"state": "system_is_armed", "level": "veryhigh", "strobe": "true"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_disarmed
      name: "Sirène SMaBit : Disarmed"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"squawk": {"state": "system_is_disarmed", "level": "veryhigh", "strobe": "true"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_warning
      name: "Sirène SMaBit : Warning"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"warning": {"mode": "fire", "level": "very_high", "strobe_level": "low", "strobe": "false", "strobe_duty_cycle": "10", "duration": "360"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_stopped
      name: "Sirène SMaBit : Stopped"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"warning": {"mode": "stop"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

Vous l'aurez compris, il s'agit plus d'un exercice de style qu'autre chose. Mais ça m'aura permis de comprendre comment créer des devices MQTT non reconnus par le discovery:. Merci @Mathieu pour ta participation !

Sources