Home Assistant, ZHA & Legrand

Il existe des devices plus ou moins bien intégrés et c'est le cas du contacteur Legrand 412170 (16A) ou 412171 (20A) qui de base est configuré en HP/HC via le signal fourni par le compteur et ou rien dans l'intégration ne permet à ce jour de la passer en mode on/off. On verra plus loin qu'il existe également une sortie de câble connectée avec ses particularités...

Vous allez me dire qu'il y est très bien géré en Zigbee2MQTT, ou que je pourrais utiliser quelque chose de moins cher (120 €). Là n'est pas la question, mon client (et ami) ne veut que du Legrand dans son tableau et pour simplifier au maximum je ne veux pas de modules externes, d'où ZHA.

L'intégration du contacteur sous ZHA se fait avec le petit bouton qui passe en rouge.

  • Assurez-vous que la passerelle (ZHA) n'est pas en mode d'appairage
  • Appuyez 8 secondes environ jusqu'à ce qu'il devienne rouge (reset)
  • Passez maintenant votre passerelle ZHA en mode d'appairage
  • Appuyez sur le bouton de réinitialisation 8 secondes environ pour lancer la procédure d'appairage
  • Effectuez des clics successifs sur ce bouton toutes les secondes, jusqu'à ce que la LED devienne verte

La légende dit que les produits Legrand ne fonctionneraient que sur le canal 11, mon réseau est en 15 et d'autres l'on fait fonctionner en 25...

En cherchant sur la toile je me suis aperçu que nos collègues amateurs de Jeedom avaient réussit à changer les choses via deconz/Phoscon. J'avais donc les valeurs à changer, mais je n'ai pas réussit à les intégrer. 

Pour info le cluster 64513 (en décimal) = FC01 (en hexa)

{"endpoint" : 1,"cluster":64513,"attribute":0,"manufacturer":64513,"name":"Mode","type":"select","values":[{"value":3,"name":"on/off"},{"value":4,"name":"hp/hc"}]},

Sous ZHA en natif on ne peut rien faire sur les clusters à ce niveau. Avec l'excellent ZHA Toolkit il y beaucoup plus de possibilités. Encore fallait t'il bien connaitre le domaine Zigbee afin de trouver le type de valeur d'attribut à configurer. Et là je remercie mdeweerd pour sa gentillesse et sa patience (je vous laisse lire l'échange ici).

Mise en place

Très simple !

  1. On commence par installer ZHA Toolkit
  2. Ensuite il n'y a qu'à lancer cette séquence dans les outils de développement (et on replace la valeur de l'attribut à 4 si on veut revenir au mode HP/HC)
service: zha_toolkit.attr_write
data:
  ieee: 00:04:74:00:00:83:f4:f6
  endpoint: 1
  cluster: 64513
  attribute: 0
  attr_val: [3, 0]
  attr_type: 0x09  # Devrait être facultatif si la lecture précède l'écriture.
  # manf: 4129     # Ne pas définir le fabricant car cela ne semble pas nécessaire dans le cas présent.
  event_done: legrand_done
  write_if_equal: false

Bonus

Sur le même principe il est possible de configurer le comportement de la Led. Ca ne m'a pas intéressé mais voici les valeurs.

    {"endpoint" : 1,"cluster":64513,"attribute":1,"manufacturer":64513,"name":"Led dark","type":"select","values":[{"value":0,"name":"Off"},{"value":1,"name":"On"}]}
    {"endpoint" : 1,"cluster":64513,"attribute":2,"manufacturer":64513,"name":"Led if on","type":"select","values":[{"value":0,"name":"Off"},{"value":1,"name":"On"}]}

Consommation

Pour l'instant l'intégration ne présente que la puissance en W ou A (encore que je n'ai pas testé). Je vais voir quand j'aurais du temps si on peut ajouter le cumul en kWh, mais c'ets toujours possible sous HA avec Reiman ou Powercalc. Voici avec Powercalc qui s'il est bien configuré a l'avantage de créer les utilility_meter: à coller dans Energy...

sensor:
  - platform: powercalc
    name: ECS
    entity_id: switch.legrand_ecs
    power_sensor_id: sensor.legrand_ecs_active_power

J'ai passé pas mal de temps (trop car j'ai aussi un job...) sur cette affaire, mais ça m'a permis d'explorer un peu les possibilité de ZHA Toolkit et comprendre qu'il est possible d'intégrer des objets ou des fonctions non reconnues.

Le cas de la sortie de câble connectée

Dans le même genre on trouve une sortie de câble connectée sous différentes références (0 648 79/82/83/98). Ici encore l'intégration ZHA est très incomplète, contrairement à Z2M comme on peut le voir ici. En effet ce module supporte plusieurs modes, alors que le seul appairage est géré directement sous ZHA, ainsi que la puissance instantanée en watts.

Mode dimmer : (ce mode nécessite un firmware récent)

  • 0x0100 : dimmer_on :
  • 0x0100 : dimmer_off

Mode contacteur :

  • 0x0003 : mode switch : Fonctionnement en on/off
  • 0x0004 : mode auto : Fonctionnement en auto, je suppose en HP/HC mais il n'y a pas d'entrée pour le pilotage. Ou domotique Legrand...

Mode fil pilote : (pilot wire)

  • 0x0002 : pilot_on :  Attente des commandes
  • 0x0001 : pilot_off :  Désactivation, on repasse en on/off ?

L'idée est bien sur de contourner ce manque, et si c'est faisable avec Z2M, il n'y a pas de raisons de ne pas y parvenir avec ZHA afin de pouvoir soutenir cet objet sur des installations les plus légères possible.

Changer de mode

service: zha_toolkit.attr_write
data:
  ieee: 00:04:74:00:00:23:3d:b5
  cluster: 64513
  attribute: 0
  manf: 4129
  attr_type: 9
  attr_val:
    - 2      #  Pilot Wire mode
    - 0
  event_done: legrand_done

Piloter un convecteur disposant d'un fil pilote

Le fil pilote est un truc bien Français né de l'abondance de l'électricité atomique qu'il fallait alors promouvoir. Pour faire simple on envoie des commandes qui vont faire adopter une consigne pré réglée sur le convecteurs et qui interagira avec la sonde interne. Bien sur la sonde interne est nécessairement faussée car trop proche des éléments d chauffe. C'est pourquoi sous Home Assistant on dispose de plusieurs composant de thermostats virtuel (le tout dernier est ici) plus ou moins évolués, mais qui se basent sur une sonde externe bin plus réaliste de la température ambiante.

Avec un convecteur ainsi piloté, on peu don soit envoyer des commandes prédéfinie, soit faire un fake switch avec confort (une sorte de on avec un préréglage haut sur le convecteur) et off et le piloter avec un thermostat virtuel.

Il faut savoir qu'un convecteur avec fil pilote ne répond pas à un simple on/off (sauf à insérer une diode dans le circuit). Il va donc falloir sous ZHA pouvoir envoyer les bonnes commandes, et à minima Confort et Off.

Commandes disponibles :

  • 0x00 : Confort
  • 0x01 : Confort -1
  • 0x02 : Confort -2
  • 0x03 : Eco
  • 0x04 : Hors Gel
  • 0x05 : Off

Il ne s'agit pas ici d'écrire un attribut comme pour changer le mode, mais d'envoyer une commande. Et c'est ici que ça se complique

service: zha_toolkit.zcl_cmd
data:
  ieee: 00:04:74:00:00:23:3d:b5
  cmd: 0
  args: [3]
  cluster: 64576
  endpoint: 1
  manf:  0x1021
  event_done: legrand_done

Ensuite on peut lire l'attribut afin de considérer que la commande est acceptée :

service: zha_toolkit.attr_read
data:
  ieee: 00:04:74:00:00:23:3d:b5
  endpoint: 1
  cluster: 64576
  attribute: 0
  event_done: legrand_done

Ce qui va nous retourner :

event_type: legrand_done
data:
  zha_toolkit_version: v0.8.35
  zigpy_version: 0.53.0
  zigpy_rf_version: 0.9.2
  ieee_org:
    - 181
    - 61
    - 35
    - 0
    - 0
    - 116
    - 4
    - 0
  ieee: 00:04:74:00:00:23:3d:b5
  command: attr_read
  command_data: null
  start_time: "2023-02-17T14:54:41.625317+00:00"
  errors: []
  params:
    cluster_id: 64576
    attr_id: 0
    dir: 0
    manf: 4129
    tries: 1
    expect_reply: true
    args: []
    state_id: var.legrand
    state_attr: unique_attr_name_for_ieee
    allow_create: true
    event_done: legrand_done
    read_before_write: true
    read_after_write: true
  attr_type: "0x30"
  write_is_equal: false
  result_read:
    - "0": 5
    - {}
  success: true
origin: LOCAL
time_fired: "2023-02-17T14:54:41.737600+00:00"
context:
  id: 01GSFXXJJ9GYVB5E0S54DVB2YP
  parent_id: null
  user_id: null

Afin de pouvoir l'exploiter on va écrire le résultat dans un état :

service: zha_toolkit.attr_read
data:
  ieee: 00:04:74:00:00:23:3d:b5
  cluster: 0xFC40
  attribute: 0
  manf:  0x1021
  event_done: legrand_done
  state_id: var.legrand
  state_attr: unique_attr_name_for_ieee
  allow_create: true          

Que l'on pourra plus facilement lire :

"{{ is_state_attr('var.legrand', 'unique_attr_name_for_ieee', 5) }}"

Fake Switch

Etant donné que je ne vais pas utiliser le fil pilote autrement que pour faire du on/off afin de commander mon convecteur par un thermostat virtuel associé à une sonde externe, il me faut un switch: à associer au thermostat.

Je vais commencer par faire deux scripts: ON et OFF. Ceux ci ont deux fonction :

  • Envoyer la commande Confort ou OFF
  • Lire l'état afin de confirmer sa prise en compte
script:
  pilot_wire_on:
    alias: "Pilot Wire ON"
    sequence:
      - service: zha_toolkit.zcl_cmd
        data:
          ieee: 00:04:74:00:00:23:3d:b5
          cmd: 0
          args: '0'
          cluster: 64576
          endpoint: 1
          manf:  0x1021
          event_done: legrand_done     
      - service: zha_toolkit.attr_read
        data:
          ieee: 00:04:74:00:00:23:3d:b5
          cluster: 0xFC40
          attribute: 0
          manf:  0x1021
          event_done: legrand_done
          state_id: var.legrand
          state_attr: unique_attr_name_for_ieee
          allow_create: true

Ensuite je crée mon switch: virtuel (pour l'instant je n'ai pas trouvé mieux que de l'associer à un input_boolean: ... à retravailler) :

input_boolean:
  dummy:

switch:
  - platform: template
    switches:
      pilot_wire_sdb:
        friendly_name: 'Convecteur : Salle de Bain'
        # value_template: "{{ is_state('switch.pilot_wire_sdb', 'on') }}"
        value_template: "{{ is_state('input_boolean.dummy', 'on') }}"
        turn_on:
          - service: input_boolean.turn_on
            entity_id: input_boolean.dummy
          - service: script.pilot_wire_on

        turn_off:
          - service: input_boolean.turn_off
            entity_id: input_boolean.dummy          
          - service: script.pilot_wire_off

Et pour terminer je vais créer un binary_sensor: qui va me permettre d'afficher l'état réel en fonction de la lecture :

template:
  - trigger:
      - platform: event
        event_type: legrand_done
        event_data:
          ieee: 00:04:74:00:00:23:3d:b5
          command: attr_read
      - platform: state
        entity_id: binary_sensor.pilot_wire_3
        to: "off"
    binary_sensor:
      name: pilot_wire_3
      icon: "{{ (is_state_attr('var.legrand', 'unique_attr_name_for_ieee', 5)) | iif('mdi:radiator', 'mdi:radiator-off') }}"
      state: "{{ is_state_attr('var.legrand', 'unique_attr_name_for_ieee', 5) }}"

Pour l'instant la puissance en watts (entre autres mais c'est celle ci qui serait utile) ne remonte pas. Je continue à chercher, mais sur une charge fixe, un convecteur par exemple, le contournement simple consiste à utiliser PowerCalc pour la déduire...

Tout cela est certainement perfectible, mais ça nous donne les base pour exploiter totalement ce couteux objet ! En attendant une hypothétique réelle intégration, comme cela a été fait sous Z2M.

Un grand merci à Mario, l'auteur de ZHA Toolkit, pour sa grande patience !

Liens

En vrac, mes sources :

 

Home Assistant & Remote Alarm

Ici je vais explorer un nouvel objet qui paraissait simple à exploiter mais s'est avéré un peu compliqué. J'ai acheté une télécommande d'alarme Heiman HS1RC en me disant que l'intégration allait être simple. Sauf que, comme ce clavier, sous ZHA cette télécommande n'est pas vue comme une classique télécommande mais comme un panneau de contrôle d'alarme. A noter que l'on retrouve le même comportement sur la télécommande Woox ou Linkind.

Pourquoi pas, il doit y avoir une raison à ce choix (probablement le bouton du bas qui passe en mode "triggered" quelque soit l'état). Sauf que pour gérer les clavier on configure un code dans ZHA, code que va attendre cette télécommande pour se désarmer. Dans ZHA on peu se passer de code pour armer, mais pas pour désarmer. Et comme le bouton désarmer de la télécommande n'envoie pas ce code elle ne désarme pas. De fait on ne peut pas se servir de sont état "disarmed" pour désarmer Alarmo...

Il va donc falloir passer par une petite automation intermédiaire afin de lui faire manger ce code et ensuite avoir un comportement normal de ce panneau d'alarme pour le désarmement... enfin je pensais que ça suffirait....

- id: '2bd0ertyyf-43fa-45f98f-aed0-heiman-001'
  alias: "Alarm @ Heiman RC Home"
  description: 'Disarm RC Control Panel to use events'
  mode: single
  trigger:
    - platform: event
      event_type: zha_event
      event_data:
        device_ieee: 5c:02:72:ff:fe:e9:2f:ff
        command: 'arm'
        args:
          arm_mode: 0
          arm_mode_description: 'Disarm'
          code: ''
          zone_id: 255
      id: "rc_1"
  condition: []
  action:
    - service: alarm_control_panel.alarm_disarm
      data:
        code: !secret alarm_code_zha
      target:
        entity_id: alarm_control_panel.heiman_rc_ef_3_0_alarmcontrolpanel
    - delay : '00:00:05'

A noter qu'il y a une particularité, quand on appuie sur un des 3 boutons du haut ça envoie 3 event's identiques. Bug ou sécurité supplémentaires liée à l'usage original de cette télécommande ? Je n'ai pas trouvé d'explications vraiment acceptables, certains disent qu'il s'agit d'event's transmis par des équipements relais, d'autres non.... Et le seul contournement que j'ai trouvée pour l'instant consiste à passer mon automation en mode single et d'ajouter un petit delay à la fin afin de ne pas exécuter cette automation trois fois de suite...

A noter que si on utilise plusieurs télécommandes (celle ci ou celle de chez Woox, ou un clavier), il conviendra de tout désarmer toutes les autres unités qui auraient pu êtres utilisées pour l'armement.

Bon, c'est une solution, mais on ne peut pas dire que ce soit très propre...

A noter que ces mêmes télécommandes sous Z2M transmettent des informations exploitables...

> arm_day_zones
> arm_all_zones
> disarm
> emergency

Alternative

En attendant que les développeurs prennent en compte nos demandes, j'ai peut être trouvé une alternative un peu moins sale. J'utilise ControllerX sous AppDaemon pour gérer toutes mes télécommandes et il se trouve qu'il sait traiter les Events sous forme de template. Je peux donc facilement remplacer mon automation par ce code :

remote_alarm:
  module: controllerx
  class: Controller
  controller: 
    - "a4:c1:48:96:0c:cf:c9:68:1:0x0501"  # Woox RC
    - "58:8e:81:zz:fe:26:12:64:1:0x0501"  # Linkind RC
    - "5c:02:72:xx:fe:e9:2f:9a:1:0x0501"  # Heiman RC
    - "68:0a:e2:af:fe:ea:89:22:1:0x0501"  # Linkind Keypad
  light: light.my_fake_light
  integration:
    name: event
    event_type: zha_event
    controller_key: unique_id
    action_template: "{command}_{args[arm_mode]}_{args[arm_mode_description]}_{args[code]}#"    # Ici il n' a pas de code reçu
  mapping:
    arm_0_Disarm_#:   # Ici il n' a pas de code reçu
      - service: input_button.press
        target:
          entity_id: input_button.disarm_alarm    
      - service: alarm_control_panel.alarm_disarm
        data:
          code: !secret alarm_code_zha
          entity_id:
            - alarm_control_panel.lk_zb_keypad 
            - alarm_control_panel.lk_zb_remote
            - alarm_control_panel.heiman_remote
            - alarm_control_panel.woox_01

    arm_0_Disarm_1234#:   # Ici on a le code du clavier défini dans ZHA
      - service: input_button.press
        target:
          entity_id: input_button.disarm_alarm          
      - service: alarm_control_panel.alarm_disarm
        data:
          code: !secret alarm_code_zha
          entity_id: 
            - alarm_control_panel.lk_zb_remote
            - alarm_control_panel.heiman_remote
            - alarm_control_panel.woox_01

    arm_0_Disarm_314#:   # Ici on peut traiter n'importe quel code reçu par le clavier et générer une action...
      - service: notify.slack_hass_canaletto
        data:
          message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Keyboard 314" 

Ici je désarme en plus le sirènes (une sous Z2M qui ne l'expose pas en tant que sirène et les autres en ZHA. Ensuite je notifie Slack qui me sert de log et me permettra de savoir quelle télécommande à désarmé le système. En ce qui concerne le clavier il est également possible d'utiliser plusieurs codes pour désarmer, les traiter via les events et ainsi savoir quel code (confié à une seule personne) à désarmé le système...

    - 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        
    - delay : '00:00:08'
    - service: notify.slack_hass_canaletto
      data:
        message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Disarm all remotes by : {{ trigger.id }}" 

Exploitation

Armement de l'alarme

Dans l'automation qui sert à armer on va utiliser l'état de l'entité Alarm Control Panel de la télécommande avec un ID afin de dérouler la séquence souhaitée et tout ce qui s'en suit (on peu imaginer faire de choses différentes selon le bouton sur lequel on appuie) :

    - platform: state
      entity_id: alarm_control_panel.heiman_rc_ef_3_0_alarmcontrolpanel
      to: "armed_home"
      id: "rc_1_home"

A noter que l'on peut également au besoin utiliser to : "triggered" afin de déclencher une autre action immédiate. Genre je me fait agresser quand j'ouvre la porte....

Désarmement de l'alarme

Paradoxalement c'est un peu plus compliqué. En effet si on a armé avec la télécommande et qu'elle se trouve en armed_home il n'y aura pas de soucis quand on va désarmer avec cette même télécommande car elle enverra un disarmed. Par contre si on veut désarmer avec une seconde télécommande ou un clavier qui n'aura pas servi à armer, celui-ci se trouvant déjà en disarmed il n'y aura pas de changement d'état et il ne se passera rien.

Donc dans l'automation qui sert à désarmer on ne va donc pas utiliser l'état de l'entité Alarm Control Panel des différents devices (télécommandes, claviers) mais un input_button: (à créer) :

    - platform: state
      entity_id: input_button.disarm_alarm
      id: "button"

Et cet input_button: sera commandé par l'automation de départ (plus haut) que j'ai adaptée :

  1. Elle se déclenche à partir des event's des différents devices
  2. Elle change l'état de l'entité Alarm Control Panel des différents devices
  3. Elle envoie un input_button.press qui va déclencher l'automation de désarmement.

Ainsi quand on désarme une télécommande on désarme les autres qui seront disponibles pour un futur armement. Et vu qu'on désarme avec un push button, on peu également envoyer depuis Lovelace ou toute autre automation.

Bref, voilà comment perdre un après midi... J'ai réédité cet article plusieurs fois et j'y reviendrait certainement.

Les commentaires de mon blog n'étant pas des plus pratiques, il est également possible d'échanger sur cet article ici, sur HACF.

Sources

 

Home Assistant & Keypad

Notre serveur domotique préféré inclus un système de sécurité intrusion, communément appelé alarme. Attention, c'est du DIY, ça fait le job, mais ça ne répond pas aux normes en vigueur :

Les systèmes d'alarmes sont évalués en fonction de divers critères donnant lieu à l'attribution d'une certification appelée "norme alarme". En France, les alarmes sont certifiées par le CNPP, qui leur attribue des normes : NFA2P bouclier 1, NFA2P bouclier 2, NFA2P bouclier 3, suivant le degré de sécurité. Au niveau européen, il existe également une norme alarme : la norme EN 50131.

Ceci étant posé, rappelons de Home Assistant intègre un panneau d'alarme basic que l'intégration Alarmo vient avantageusement compléter, et dans l'absolu ça fait mieux que beaucoup de produit du marché.

Pour une bonne efficacité on part du principe que l'installation Home Assistant est fiable et secourue par un UPS.

Dans cet article je ne vais pas détailler le fonctionnement de cette alarme mais m'intéresser aux différentes façons de l'activer / désactiver :

  • Via l'application mobile : facile, mais fastidieux à l'usage. Tous les occupants ne disposent pas nécessairement de l'application mobile Home Assistant.
  • Avec un bouton ou une télécommande : facile, mais il faut transporter l'objet et les distribuer.
  • Avec un badge ou tag RFID sur un lecteur : lecteur esp32 à configurer, il faut transporter l'objet. Facile à distribuer et à révoquer.
  • Avec un badge et un téléphone mobile : facile et sécurisé, il faut enregistrer au préalable les mobiles qui devront disposer de l'application Home Assistant..
  • Avec un clavier numérique : le mode classique et universel, changement des codes faciles, encore faut t'il trouver un clavier, et c'est l'objet de cet article.

Un keypad Zigbee compatible

Il y a quelques jours j'ai vu passer une vidéo qui parle d'un kit alarme Linkind qui utlise Zigbee. Ce kit est composé d'une sirène qui est en fait un hub Zigbee qui se connecte au cloud du fabricant chinois pour gérer l'ensemble, d'un clavier et de quelques détecteurs. L'auteur de la vidéo à utilisé zigbee2mqtt et Node Red (je n'aime pas) pour l'intégrer à Home Assistant, moi je vais essayer de faire ça via ZHA.

J'ai commandé ce kit chez Amazon (28 €) en me disant qu'au pire ce serait un retour de plus, mon idée étant d'utiliser le clavier. Il y a des travaux en cours sur le Hub / Sirène mais c'est loin d'être aboutit. En ce qui concerne les capteurs il est possible de les associer via ZHA (ou z2m et Deconz).

Premier problème que je n'ai pas résolu, le code (1234 par défaut) qui se change via l'application du constructeur. Sauf que quand on l'intègre avec ZHA ça passe par un reset et on se retrouve avec le code par défaut. Bref un clavier avec comme code 1234 ça ne servirait pas à grand chose. Mais il y a une astuce, et la voici : (et une info à la fin de cet article)

Quand on entre une information sur le clavier, celle ci est envoyée à Home Assistant via ZHA (ça doit fonctionner à l'identique avec Deconz, sauf que pour l'instant il n'est pas reconnu) et on peut la récupérer via les "events". Voici un exemple si je saisit Disarm + 1234 + Valid sur ce clavier :

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "69:0a:x2:ff:fe:xa:x8:22",
        "unique_id": "69:0a:e2:xf:xe:xa:88:2x:1:0x05xx",
        "device_id": "c036fgqd qfdqs56hshs56shsdd06152267ab",
        "endpoint_id": 1,
        "cluster_id": 1281,
        "command": "arm",
        "args": {
            "arm_mode": 0,
            "arm_mode_description": "Disarm",
            "code": "1111",
            "zone_id": 0
        }
    },
    "origin": "LOCAL",
    "time_fired": "2022-02-21T23:27:45.169891+00:00",
    "context": {
        "id": "edada8770ddfd7045b1835acb0888bad",
        "parent_id": null,
        "user_id": null
    }
}

A partir de là il est facilement possible de traiter cette information dans une automation et de générer une action, ici un message :

automation:
- alias: Keypad Test
  description: 'Triggers an Event When code 1111 is entered into any keypad.
  trigger:
    - platform: event
      event_type: zha_event
      event_data:
        command: 'arm'
        args:
          arm_mode: 0
          arm_mode_description: 'Disarm'
          code: '1111'
          zone_id: 0
  condition: []
  action:
    - service: notify.slack_hass_canaletto
      data:
        message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > ENTER HOME | Code 1111 | State : {{ states.alarm_control_panel.alarmo.state }}"

Et là ou ça devient intéressant, c'est que l'on peut saisir n'importe quoi et que ça sera toujours remonté via un event. A partir de là on peu faire passer tous les codes possibles via 2 pseudos modes d’armement, voire même le disarm.

  • Arm_All_Zones
  • Arm_Day_Home_Only

Bon c’est un peu du bricolage… mais ça fait le taff. Dans la pratique, de base le désarmement demande le code enregistré dans le clavier (1234 par défaut) on peu armer les deux modes à la volée avec n'importe quel code, par exemple :

Touche Arm Home + 4444 + Valid va envoyer un event avec :

"args": {
            "arm_mode": 1,
            "arm_mode_description": "Arm_Day_Home_Only",
            "code": "4444",
            "zone_id": 0

Touche Arm Away + 5555 + Valid va envoyer un event avec :

"args": {
            "arm_mode": 3,
            "arm_mode_description": "Arm_All_Zones",
            "code": "5555",
            "zone_id": 0

A partir de là on interprète le code avec une automation et on lui fait faire ce que l’on veut très simplement.

automation:
  alias: Keypad Test
  description: 'Triggers an Event When code 1111 is entered into any keypad.'
  trigger:
    - platform: event
      event_type: zha_event
      event_data:
        command: 'arm'
        args:
          arm_mode: 0
          arm_mode_description: 'Disarm'
          code: '1111'
          zone_id: 0
  condition: []
  action:
  - service: alarm_control_panel.alarm_disarm
    data:
      code: !secret alarm_code
    entity_id: alarm_control_panel.alarmo
  - service: alarm_control_panel.alarm_disarm
    data:
      code: !secret alarm_code_visonic
    entity_id: alarm_control_panel.visonic_alarm
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > ENTER HOME | DISARM ALARM's | State : {{ states.alarm_control_panel.alarmo.state }}" 

Bonus

Rester appuyé 3 secondes sur SOS, ça active le Panel alarme Linkind dans HA et on peut traiter l'information.

Edit 05/07/2022

Je ne m'étais pas repenché sur la question de ce code 1234 par défaut depuis l'écriture de cet article. Mais Aurel RV a creusé un peu plus et à découvert par hasard que ZHA sait gérer ce code par défaut. Depuis quand je ne sais pas.

Le clavier étant vu comme un panneau de contrôle d'alarme, on pourra interagir avec Alarmo ou continuer à se servir des autres codes vie les events pour commander d'autres actions...

Conclusion

Ce résultat n'est pas totalement satisfaisant (mais qui le devient depuis que ZHA gère ce code), mais ça permet de faire passer les bons codes à Alarmo et c'est utilisable. De plus on peut utiliser d'autres codes pour déclencher d'autres actions, ouvrir un portail, allumer des projecteurs, etc....

 

 

 

 
 

 

 

Home Assistant, Zigbee, encore...

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

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

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

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

Clé USB à base de cc2652P

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

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

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

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

La passerelle Xiaomi V3

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

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

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

Ensuite sous Home Assistant :

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

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

Modes de fonctionnement

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

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

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

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

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

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

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

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

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

 

Home Assistant, RC & Lights

Me voici bien installé sous Home Assistant, j'ai choisi au départ Zigbee pour les capteurs de température et d'ouverture, puis au hasard des pubs sur Ali Express et de mes passages chez Ikea j'ai acheté diverses télécommandes en me disant que j'en ferait bien quelque chose... L'usage principal étant de piloter des éclairages ou des scènes, du son, ou encore une action du genre "chauffe la salle de bain" et dis à Alexa de me prévenir quand la température sera idéale". Bien sur on peut remplacer les télécommandes par Alexa ou GH, mais ça me fait toujours bizarre de parler à ces objets, surtout quand je ne suis pas seul...

Bref, pour piloter un éclairage depuis une télécommande Zigbee il existe plusieurs approches plus ou moins facile à mettre en œuvre. On part du principe que Zigbee s'appuie sur ZHA, Zigbee2Mqtt, Deconz ou directement en MQTT.

Phoscon

Il s'agit ici de l'interface de Deconz qui est la solution la plus répandue et à mon gout la plus performante. Cette passerelle va plus loin que les autres en ce sens qu'elle intègre une interface qui permet facilement d'associer les touches d'une télécommande à des ampoules ou des prises. En fait au départ Phoscon est juste fait pour remplacer les passerelles propriétaires (Hue, Ikea, etc.) sans pour autant disposer de Home Assistant et il est même possible de créer des scènes et de disposer des fonctionnalités des passerelles émulées.

C'est donc la solution idéale quand on ne dispose que d'ampoules ou prises Zigbee, d'autant plus que ces éléments seront toujours disponibles sous HA pour d'autres actions et que cette passerelle est compatible Alexa. Personnellement je recommande l'installer sur un vieux RPI à part et ainsi la placer au centre du logement.

Automations

Mais, ça va se compliquer quand on va vouloir associer une télécommande Zigbee à un équipement non Zigbee. J'ai par exemple quelques variateurs Shelly et je voulais y associer une télécommande Opple afin de plus bouger mon cul du canapé, bien que dans la vraie vie je passe tout de même plus de temps dans mon fauteuil de bureau.

La solution consiste donc à écrire des automations en se basant sur les devices et les codes retournées par ces télécommandes. C'est long, fastidieux et encombrant quand on sait qu'il faut 4 automations pour gérer les fonctions de base d'une ampoule variable , et je ne parle pas de la gestion des couleurs. C'est lourd, mais ça fonctionne à coup de copié / collé, et le faire sous NodeRed sera tout aussi fastidieux.

ControllerX

Alors j'ai longtemps laissé ces télécommandes en déshérence, puis un soir je me suis mis à explorer la communauté HA (celle en anglais) à la recherche d'une alternative, et je suis tombé sur ControllerX. Au départ je n'ai pas aimé car ça s'appuie sur AppDaemon qu'il me fallait installer, ce qui alourdit mon serveur HA. Et puis en lisant je me suis dit que ça valait le coup de creuser la chose.

Je vous laisse installer AppDaemon 4, c'est un AddOn qui s'installe comme les autres depuis le superviseur sur Hassio. On peu aussi l'installer en Docker pour ceux qui aiment se compliquer la vie. Il faut juste créer un fichier de config basic qui sera suffisant pour ce que l'on va en faire dans :

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

/config/appdaemon/appdaemon.yaml

Ensuite on va installer ControllerX depuis HACS et une fois fait créer le fichier de config, non pas de ControllerX mais des apps AppDaemon :

sejour_halogène: 
  module: controllerx
  class: WXCJKG13LMLightController
  controller: aqara_opple
  integration: deconz
  automatic_steps: 30
  mapping:
    3001: hold_brightness_toggle
    3002: toggle
    3003: release
    3004: toggle_full_brightness
    3005: toggle_min_brightness
  light: light.shelly_shdm_1_f3758  

/config/appdaemon/apps/apps.yaml

Et la lumière fut ! Ces quelques lignes assurent les 5 fonctions d'une touche de ma télécommande qui en comporte 6. Et encore ici j'ai choisit un mapping personnalisé car je souhaite que chaque touche ne commande qu'un seul point lumineux en me servant du multiclic, mais ça serait encore plus simple si je voulais juste reproduire les fonction d'une télécommande Ikea ou Hue avec l'ampoule ivrée avec.

Explications lignes par lignes :

  1. un nom d'app que vous choisissez.
  2. le nom du module AppDaemon, ici ControllerX.
  3. le code de la télécommande utilisée : ici le controleur Opple avec 6 boutons (ici la liste des contrôleurs supportés).
  4. l'ID du device fournit par la passerelle (controller_id ou adresse IEEE (voir ici comment récupérer cette information).
  5. L'intégration utilisée (deconz, mqtt, zha, state) (plus d'informations ici).
  6. Des options (multiple_click_delay: 500, delay: 50, automatic_steps: 30, manual_steps: 10 (je vous laisse cherche run peu car il y en d'autres).
  7. Les mapping, ce qui qui va consister à associer les codes envoyés par la télécommande aux fonctions possibles.
  8. Enfin, on pointe sur l'éclairage déclaré dans Home Assistant, ici un Dimmer Shelly.

Je n'ai parlé ici que de ce que j'ai utilisé. Mais ControllerX va beaucoup plus loin. Il est bien sur possible de piloter des scènes, des automation ou encore des lecteurs multimédia, et par exemple d'associer le bouton rotatif Ikea à votre lecteurs Sonos. Je vous conseille la lecteur du sujet dédié et bien sur de la doc sur GitHub, même si ce développeur est bien dans le codage de ses url qu'il faudra souvent reconstituer...

Bonus

Il existe deux intégration intéressantes à associer à ces problématiques, d'abord Light Switch qui va permettre de créer une entité de type lampe à partir d'un switch, et ensuite Light Group qui va permettre de grouper plusieurs lampes pour en faire une seule...

Edit

Alors depuis que j'ai écrit cet article il y une nouveauté dans Home Assistant : Blue Print. Cela va permettre de télécharger des automations (partagées ici par exemple, et bientôt sur HACF) qui vont permettre de gérer des télécommandes en quelques clics et sans rentre dans le code. Le catalogue s'étoffe de jours en jours, donc n'hésitez pas à y retourner.

Il n'en reste pas moins qu'il y a une chose que je n'ai pas trouvé en Blue Print. Je voulais avec une télécommande Ikea 5 boutons, pouvoir passer d'une ampoule à une autre avec les touches directionnelles.  Et ça je n'ai réussit à le faire qu'avec ControllerX, en créant un input_select: et en me servant des options de contrainte, voilà un exemple pour deux lampes :

select_light_app:
  module: controllerx
  class: CallServiceController
  controller: ikea_tradfri_rc
  integration: deconz
  mapping:
    4002:
      service: input_select.select_previous
      data:
        entity_id: input_select.rc_ikea_1
    5002:
      service: input_select.select_next
      data:
        entity_id: input_select.rc_ikea_1

light_app_1:
  module: controllerx
  class: E1810Controller
  controller: ikea_tradfri_rc
  integration: deconz
  light: light.shelly_shdm_1_f3d426
  constrain_input_select: input_select.rc_ikea_1,light_1
  excluded_actions: [4002, 5002]

light_app_2:
  module: controllerx
  class: E1810Controller
  controller: ikea_tradfri_rc
  integration: deconz
  light: light.shelly_shdm_1_f3a100
  constrain_input_select: input_select.rc_ikea_1,light_2
  excluded_actions: [4002, 5002]

Home Assistant & ZigBee

ZigBee est un protocole de haut niveau permettant la communication d'équipements personnels ou domestiques équipés de petits émetteurs radios à faible consommation ; il est basé sur la norme IEEE 802.15.4 pour les réseaux à dimension personnelle (Wireless Personal Area Networks : WPAN). Wikipédia et Google vous raconteront le reste... Mais sous Home Assistant il y (principalement) trois façons d'approcher Zigbee :

Deconz / Phoscon

La clé Combee II dépend ici de l’environnement logiciel de son éditeur, qu'il soit installé de façon indépendante ou plus ou moins mergé à Home Assistant (ou une autre solution). C'est donc une une solution qui peut s'utiliser de façon autonome, ce qui était leur but de départ, remplacer simplement quelques passerelles propriétaires (Hue, Ikea, etc..). ils fournisse d'ailleurs des images RPI pour se passer de leur boitier et c'’est d'ailleurs ainsi que je l'avait monté sur un RPI2 auquel j'accédait depuis Jeedom, et auquel j'accède maintenant avec Home Assistant.

Le fait que ce soit autonome permet de réaliser des opérations sans passer par une plateforme domotique, tout en disposant des équipements sur une ou plusieurs solutions domotique. Par exemple, pour associer un interrupteur avec une ampoule, il est plus simple de le faire sous Phoscon, sachant que de toutes façons l'état de l'ampoule remontera dans Home Assistant et que je pourrais toujours l'éteindre avec une automation...

Enfin, les équipements sont également accessibles en parallèle depuis Alexa...

C’est donc la solution la plus proche d'une passerelle propriétaire, de ses avantages, de sa façon de fonctionner et d'évoluer. C’est celle que je conseillerais pour installer un HA chez un tiers, la plus grand public qui s'appuie sur des équipements l'ont peut facilement acquérir dans le commerce.

ZHA

Zigbee Home Automation est la solution la plus intégrée à Home Assistant. Elle s'appuie sur à peu près toutes les clés Zigbee du marché et fonctionne plutôt bien. Par contre ici on est sur une intégration fermée dans et pour HA. Elle supporte (à titre expérimental) même la Zigate dont j'avais fini par me débarrasser sous Jeedom...

Rien à ajouter de plus, pour faire simple et rester dans HA c’est la solution à adopter et l'on retrouvera les menus de configurations dans la configuration HA

zigbee2mqtt

C'est la solution à la mode, parce que MQTT est à la mode. Mais au delà de l'effet de mode, MQTT est le protocole qui fait son chemin et risque de devenir un standard bien au delà de nos petits bricolages domotique. Ici on passe par une passerelle que l'on va monter ou on le souhaite (RPI Zero indépendant, HA remote, etc...), qui va transmettre ses infos à un brooker qui lui aussi peut être n'importe ou (LAN/WAN) et notre HA ne sera qu'un client de ce brooker. L'étape suivante étant bien sur que les équipements intègrent ce protocole, ça arrive, notamment sur du DIY avec le firmware Tasmota et on peut imaginer que le marché adopte MQTT, c’est d'ailleurs le cas des équipements Shelly en WI-FI qui proposent (timidement) ce protocole de façon native, ou d'autres passerelles comme ble2mqtt...

Pour revenir à zigbee2mqtt le projet est très actif, plutot stable et c'est par exemple le seul qui propose les mises à jours bios de certains équipements. Pour ce test je l'ai monté sur un HA remote et j'ai utilisé une intégration sous forme d'addon. En fait simplement parce que j'avais ce HA remote sous la main, mais pour le coup la com ne se fait pas en remote mais en MQTT. C'est une solution ultra paramétrable, chaque équipement est ajustable à la source et les infos remonteront vers les clients, je dis bien les clients car on peut tout à fait imaginer qu'in équipement soit utilisable avec plusieurs solutions, un capteur de température vu par HA mais aussi par une solution externe, etc...

A noter que contrairement aux deux précédentes solution j'ai bien la remontée de l'état des piles sur les révisions récentes (fin 2019) des capteurs Aqara, ce n'est toujours pas les cas des deux solutions concurrentes, preuve de plus que le projet est très actif.

Enfin zigbee2mqtt s'appuie sur une clé DIY, ce qui veut dire qu'il faudra bricoler un peu et acheter quelques accessoires. Mais ça reste easy !

EDIT 22/01/2021 : Pensez à mettre à jour le firmware de vos clés, ça fonctionnera mieux avec les dernières versions...

Alternatives...

D'autres continuent à utiliser l'intégration Xiaomi avec la passerelle de première génération. Ça fonctionne, mais pour moi ce n'est pas une solution Zigbee, mais une solution Xiaomi qui repose sur l'utilisation d'un serveur Chinois, dépendant de la volonté de Xiaomi d'en laisser l'usage détourné possible, voire de la Chine de laisser passer ou non les flux. Si le fonctionnement se fait en local, c’est également un potentiel cheval de Troie, mais ça c'est un autre débat. Vous aurez compris que je ne suis pas fan.

EDIT 22/01/2021 : SLS, vous risquez d'en entendre parler cette année...

Conclusion

Conclusion il faut choisir. Choisir n'est jamais simple, et en l'espèce ce n'est pas moi qui vais vous dire quoi choisir ! Il faut tout de même savoir que si les produits les plus courants sont supportés par toutes les solutions, d'autres plus confidentiels ne le seront que par l'une ou l'autre.

Sources