THZReader, un lecteur NFC Zigbee

Mon usage pressenti est l'armement / désarmement de mon système d'alarme. Actuellement j'utilise un clavier qui me donne satisfaction, par contre l'usage de plusieurs codes pour des personnes différentes n'est pas des plus aisés et devient complexe. J'ai besoin de savoir qui arme ou désarme afin d'exécuter, ou pas, des actions sous-jacentes (chauffage, climatisation, volets, mise en veille d'un PC, etc...). Avec un tag personnalisé on résous facilement cette problématique et on peut même accueillir le visiteur avec un message vocal. Et rien n'empeche de laisser le clavier place en lien avec le système d'alarme.

Plusieurs points essentiels sont à appréhender pour une intégration réussie.

Le choix du matériel NFC

Le premier point crucial est la sélection du lecteur NFC lui-même (un sous ensemble du RFID). Tous les lecteurs ne sont pas égaux en termes de performances et de compatibilité avec Home Assistant.

• Lecteurs USB classiques : Ils se connectent directement à l'appareil exécutant Home Assistant (Raspberry Pi, mini PC, etc.) et sont généralement reconnus. Des modèles comme l'ACR122U seraient des valeurs sûres, mais je n'ai pas eu l'occasion de tester.
• Lecteurs intégrés/modules GPIO : Certains modules NFC peuvent être connectés directement aux broches GPIO d'un Raspberry Pi (par exemple, le RC522). En général plus complexes à mettre en œuvre.
• Lecteurs basés sur ESPHome : Une approche de plus en plus populaire consiste à utiliser un microcontrôleur ESP32 (ou ESP8266) avec un module NFC (comme le PN532 ou le RC522) et à flasher le tout avec ESPHome. Cette solution offre une grande flexibilité, permettant un lecteur NFC déporté et connecté au réseau Wi-Fi. J'ai testé le kit Adonno qui fonctionne plutôt bien et accepte pas mal de types de cartes, dont celles fournie par les hôtels que j'ai pu récupérer. Par contre, et de ce fait, on peu le faire crasher à la lecture de certaines cartes de crédit.
• Lecteurs basés sur Zigbee : Je n'en connais qu'un seul, et ce sera l'objet de cet article. Son créateur, Thomas, a fait le choix de tout miser sur la fiabilité en ne supportant que les tags à la norme ISO 15693.

Intégration Logicielle dans Home Assistant

Une fois le matériel choisi, l'intégration logicielle est l'étape suivante.

• Intégration native (NFC Tag) : Home Assistant dispose d'une intégration native pour la lecture de tags NFC. Cela permet de créer des automatisation directement depuis l'interface utilisateur en scannant un tag. C'est la méthode la plus simple pour les automatisations basiques (déclenchement d'une scène, activation/désactivation d'une lumière, etc.).
• ZHA Events : C'est la méthode native afin de lire les remontées d'un objet Zigbee objet connecté nativement à Home Assistant via ZHA. Il est facile d'exploiter ces données brutes comme je l'ai déjà expliqué.
• MQTT : Pour des configurations plus avancées, MQTT peut être une option plus adaptée, en tout cas appréciée par les geeks. Le lecteur NFC publie les identifiants des tags lus sur un topic MQTT, et Home Assistant s'y abonne pour déclencher les actions correspondantes. Cela permet également une une communication bidirectionnelle si nécessaire, pour écrire par exemple. De plus MQTT peut communiquer avec plusieurs systèmes en parallèle.
• Node-RED ou AppDaemon : Je déteste NodeRed et je pense que l'on peut tout faire nativement en YAML. Mais ceux qui n'ont jamais connu le mode CLI apprécieront peut être l'aproche graphique. AppDaemon j'adore, mais c'est en perte de vitesse et aujourd'hui j'évirerais de démarrer un projet avec cette approche.

Le lecteur THZReader

Comme je le disais plus haut Thomas a fait le choix de maximiser la fiabilité, ce lecteur qui utilise la technologie radio Zigbee 3.0 n'est compatible qu'avec les tags ISO 15693, cette norme présente également d'avantge d'avoir une portée légèrement plus longue. On peut ainsi vraiment parler de sans contact car il n'est pas utile de vraiment coller le tag sur le lecteur. Cela permettra par example de le laisser dans un sac ou un portefeuille.

Comme son nom l'indique le THZReader (vendu sur Tindie) est uniquement un lecteur et en l'état il ne sait lire que l'UID du tag, en clair son numéro de série unique. Une évolution permettra peut être de lire d'autres informations que l'on pourrait écrire avec des applications mobile disponibles sur les différents stores, mais également ce que l'on peut écrire avec l'application Home Assistant.

Mon point de vue est qu'il faut considérer un tag comme une clé, à ma connaissance on ne peu pas modifier l'UID, par contre il doit être possible de le copier ou de l'émuler, tout comme on peut copier une clé chez un serrurier. Dans le cas d'un tag on peut imaginer un usage à deux facteurs si on cherche à augmenter son niveau de sécurité. Ajouter un PIN, valider une localisation, à chacun de voir selon l'usage et le niveau de contrôle souhaité.

Cependant, et d'après mes recherches, il n'est pas possible actuellement d'émuler un tag ISO 15693 sur un mobile Android ou Apple. Mais rien n'empeche de glisser un tag sous la coque, et vu que le mobile ne le reconnait pas il y ne devrait pas y avoir de de risque de conflit.

ZHA ou Zigbee2MQTT ?

Au départ Thomas avait prévu l'intégration de son lecteur uniquement via Zigbee2MQTT. C'ets une bonne approche plutôt universelle qui ne se limite pas à Home Assistant. Sauf que je lui ai fait remarquer que le Zigbee de base dans Home Assistant est ZHA, une approche plus simple et à la portée de tout le monde, mais qui reconnait moins d'objets.

Personnellement j'utilise ZHA, Z2M, Deconz et même d'autres passerelles, mais chez moi c'es un peu un labo et sur les installation Home Assistant que je supervise pour des amis je me refuse à installer autre chose que ZHA.

Sur les groupes de discutions il existe une sorte de prosélytisme pro Z2M et la réponse aux questions posée sur ZHA se solde trop souvent par : t'a qu'à passer sur Z2M. Je trouve cela detestable et contre productif car passer sous Z2M qui est plus complexe va certainement poser d'autres questions pour l'utilisateur débutant. Un autre débat !

Bref, c'est ainsi que j'ai facilement convaincu Thomas de rendre son lecteur également compatible avec ZHA.

Intégration avec ZHA

Dans cet article je ne parlerais donc que de cette intégration.

Bien sur le lecteur n'est pas reconnu de base par ZHA (pas plus sous Z2M) et pour y remédier il faut installer un Quirk dans ZHA. Il s'agit en fait d'une sorte de driver (pilote) adapté. Une IA ou les liens en bas de page vous aideront. Tous les fichiers utiles sont disponibles sur GitHub.

Une fois le Quirk installé et reconnu et après un redémarrage de Home Assistant on peu appairer le lecteur comme n'importe quel objet et il sera reconnu. Le lecteur est livré en mode appairage mais s'il est nécessaire de faire un reset, le bouton se trouve à l'intérieur du boitier ainsi que la led qui indiquera ce mode.

Quand le lecteur est reconnu par ZHA on dispose d'un unique sensor qui permet de vérifier la lecture de n'importe quel tag ISO 15693 :

Mais également d'un event ZHA ou on retrouve deux informations, la lecture du tag avec son UID ainsi qu'un second event lors du retrait du tag.

A partir de ces events l'utilisateur avancé pour réaliser directement des automatisations ou créer un sensor: ou un binary_sensor: pour une exploitation simplifiée.

Il existe toutefois une façon plus simple et native pour exploiter les tags dans Home Assistant et ensuite les utiliser dans des automatisations en mode GUI. Pour que cela fonctionne il faut juste activer un BluePrint avec un simple OK qui convertira l'UDI reçu dans l'event vers un tag natif home Assistant que l'on va devoir créer (en l'état, seule l'application companion disposant de sa propre API et ESPHome avec la sienne seraient capable de créer un tag directement dans Home Assistant, sauf qu' ESPHome ne gère pour l'instant pas le Zigbee et encore moins le chipset RFID PN5180, d'ou le BP et l'obigation de créer manuellement le tag après avoir repéré son UID dans l'event ZHA).

Cas pratique

Un tag: , ou un binary_sensor: créé depuis un event est toujours binaire. Donc une seule position active, peut être si on tiens compte du fait que l'on peu évaluer l'action quand on le retire du lecteur, mais ça ne sera pas utilisable dans tous les cas. Dans une automatisation il va donc falloir conditionner son usage à l'état que l'on veut changer.

Pour faire court, dans le cas d'une alarme par exemple on va tester l'état de l'alarme, si elle est désarmé (ou dans un état transitoire) on peu armer, et dans un autre choose: l'inverse pour désarmer, exemple (la ligne "conditions" est éclatée sur plusieurs lignes, mais tout cela peut tenir sur une ligne unique) :

- choose:
    - conditions: "{{ trigger.id in ['Keypad Armed Away', 'Tag Marie']
                   and is_state('alarm_control_panel.alarmo',
                   ['disarmed', 'armed_home', 'triggered', 'arming', 'pending'])
                   }}"
      sequence:
        - action: alarm_control_panel.alarm_arm_away
          target:
            entity_id: alarm_control_panel.alarmo
        - action: input_text.set_value
          target:
            entity_id: input_text.last_arm
          data:
            value: "{{now().strftime('%d/%m %H:%M:%S')}} > Armed Away : {{ trigger.id }}"

Vous aurez remarqué que le colle le trigger_id: dans un input_text: avec l'horodatage. Au début à des fin de debug, et puis je m'en suis servi pour extraire le prénom de celui qui a badgé pour jouer un message de bienvenue personnalisé.

script:
  alarm_tts_outside_smart_disramed:
    alias: "Alarm - TTS Sonos Terrasse : Smart DISARMED"
    sequence:
    - variables:
        content_last_disarm: "{{ states('input_text.last_disarm') }}"
    - choose:
        - conditions: "{{ 'Marie' in content_last_disarm }}"
          sequence:
            - service: tts.cloud_say
              data:
                message: "Bienvenue Marie, je suis content de vous revoir. Alarme désactivée."
              target:
                entity_id: media_player.sonos_ma_terrasse

        - conditions: "{{ 'André' in content_last_disarm }}"
          sequence:
            - service: tts.cloud_say
              data:
                message: "Le système a été désarmé. Bienvenue André."
              target:
                entity_id: media_player.sonos_ma_terrasse
        
      default: # Si aucun de nom n'est reconnu
        - service: tts.cloud_say
          data:
            message: "Alarme désactivée."
          target:
            entity_id: media_player.sonos_ma_terrasse
    mode: single

Ce script est lancé par une automation qui gère pas mal d'autres choses (volets, éclairages, etc...) en fonction de l'état de l'alarme.

Carence

Si ce lecteur fonctionne parfaitement, je ne l'ai jamais pris en défaut, il manque à mon sens un buzzer intégré au lecteur qui validerait la lecture et le retrait du badge. On peut bien sur y remédier avec une petite automatisation, mais cela sera forcément un peu moins réactif.

alias: GUI - Tag Buzzer
triggers:
  - trigger: tag
    tag_id: 77F123456789123456789
conditions: []
actions:
  - action: music_assistant.play_announcement
    metadata: {}
    data:
      url: https://ha.canaletto.fr:8123/local/mixkit-classic-short-alarm-993.wav
      announce_volume: 50
      use_pre_announce: false
    target:
      entity_id: media_player.sonos_ma_hall
mode: single

Vous aurez noté que j'utilise Music Assistant. Si cette intégration n'est pas encore parfaite, elle permet au media player de reprendre la lecture musicale en cours après avoir joué une annonce ou un son.

Scénarios d'Utilisation et Automatisation

La réflexion sur les scénarios d'utilisation est essentielle pour maximiser la valeur ajoutée du lecteur NFC. Ce sera surtout une question de besoin et d'imagination...

• Armement/Désarmement d'alarme : Un tag pour armer l'alarme en quittant la maison, et la désarmer en rentrant.
• Gestion des lumières : Un tag sur la table de nuit pour éteindre toutes les lumières, un autre à l'entrée pour les allumer.
• Activation de scènes : Un tag pour passer en "mode cinéma" (lumières tamisées, volets fermés, TV allumée), un autre pour le "mode lecture".
• Contrôle parental: Des tags spécifiques pour activer ou désactiver l'accès à certains contenus multimédias ou jeux.
• Automatisation contextuelle: Un tag sur une bouteille pour ajouter le produit à une liste de courses, un tag sur un vêtement pour lancer un cycle de lavage spécifique.

Aspects Réseau et Positionnement

• Connexion physique : Qu'il soit WI-FI ou Zigbee un lecteur fonctionne en permanence afin d'être réactif. En ce sens il doit être alimenté par un adaptateur secteur et on ne peut pas imaginer un fonctionnement sur piles, mais peut être avec une grosse batterie portable...
• Connectivité : En WI-FI ou Zigbee le lecteur doit être à portée et disposer d'une bonne connection.
• Positionnement du lecteur : Le positionnement physique du lecteur est important pour l'expérience utilisateur. Il doit être facilement accessible et visible (ou discrètement intégré) à l'endroit où vous souhaitez déclencher l'automatisation. Pensez à la portée de lecture du lecteur et à l'orientation du tag, avantage au THZReader qui permet une lecture jusqu'à 12 centimètres (selon le type de tag).

Conclusion

La mise en place d'un lecteur NFC dans Home Assistant est une démarche enrichissante qui ouvre la porte à des automatisation intuitives et pratiques. En choisissant le bon matériel, en maîtrisant l'intégration logicielle, en gérant judicieusement vos tags et en imaginant des scénarios d'utilisation pertinents, vous transformerez votre maison connectée en un environnement encore plus intelligent et réactif. N'hésitez pas à consulter la documentation officielle de Home Assistant et les nombreux tutoriels disponibles en ligne pour vous guider à chaque étape.

Sources