Home Assistant & Visonic

Jadis, quand j'ai commencé à m'intéresser à la domotique, avec une Zibase, j'avais intégré les capteurs de mon système d'alarme Visonic Powermaster Pro. Ensuite sous Jeedom je les ai perdus, j'ai bien tenté avec un RFPLayer, qui dans l'absolu intégrait la techno ZiBase, de les retrouver, mais sans succès tant le plugin dédié et payant étant en dessous de tout. Un échec de plus pour Jeedom, peu importe que ce soit de leur faite ou celle de ZiBlue qui ne fournissait que peu d'informations, le résultat était négatif.

Sous Home Assistant j'ai bien essayé de me servir de la ZiBase pour récupérer ces informations, mais je n'ai pas trop insisté et j'ai fini par tout doubler avec des capteurs Xiaomi/Aqara.

Jusqu'à ce que je découvre la semaine dernière qu'il existait une intégration Visonic ! Mais pour ça il faut que ça communique. La centrale a des options que je n'ai pas et j'étais moyennement chaud pour commander une option RS232 à 80 € sur un site exotique. En lisant un peu j'ai fini par découvrir que cette option ne faisait qu'exposer physiquement le signal qui existe en TTL sur des broches accessibles. Alors j'ai fait des tests avec un câble RS232, USB/RS232 et j'ai même acheté un adaptateur Ethernet / RS232 (USR-TCP232-302) mais ça succès alors que certains disent y être parvenus, et même une pince pour sertir des connecteurs Dupont (l'enfer !), bref je me suis cassé le crane tout un week-end sans succès.

Reste une solution que je n'ai jamais explorée, utiliser un ESP_01 avec le firmware ESP-Link qui convertir les signaux TTL série afin de pouvoir les utiliser en Ethernet depuis l'intégration sous Home Assistant.

Communication

Alors d'abord il faut se procurer le module ESP NodeMCU. Ca doit pouvoir fonctionner avec d'autres ESP et d'autres firmwares mais je me suis contenté de suivre ce que j'ai trouvé. Ca vaut 1 €, c'est minuscule et ca peut tenir dans la centrale qui ainsi devient "WI-FI" !

Pour flasher le firmware ESP-Link il faut un adaptateur USB que je n'avais pas commandé pensant pouvoir le faire avec mon adaptateur USB éclaté. Certains ESP ont un bouton pour les passer en mode flashage, sur celui ci rien de tel, pas plus que sur l'adaptateur... C'est un peu le mystère laissé par les barbus, ne pas tout documenter sans quoi ce serait trop facile, ce genre de montage ça se mérite ! Bref, il faut shunter IO0 et GND avant d'insérer l'objet dans le port USB, ça permet de passer en mode programmation (je l'ai fait juste avec un câble Dupont...).

Maintenant il va falloir trouver un outil de flashage. Mais les barbus bossent sous Linux, et même s'il est possible de faire du Bash ou du Python sous Windows, ma machine ne s'est pas avérée très coopérative...

curl -L https://github.com/jeelabs/esp-link/releases/download/v2.2.3/esp-link-v2.2.3.tgz | \
    tar xzf -
cd esp-link-v2.2.3
esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash -fs 4m -ff 40m \
    0x00000 boot_v1.5.bin \
    0x1000 user1.bin \
    0x7C000 esp_init_data_default.bin \
    0x7E000 blank.bin

Si la plupart des outils de flashage sous Windows fonctionnent, et même Tasmotizer, (Mathieu si tu me lis...), on va avoir besoin ici de flasher plusieurs fichiers .bin à des adresses particulières et le seul utilitaire qui a fonctionné est NodeMCU Firmware Programmer, qui selon les ESP utilisés permet de les fichiers flasher au bon endroit...

Une fois cette opération réussie (YES ! Ca m'a pris l'après midi...), on peu détacher l'ESP_01 de son support USB et aller le brancher dans la centrale. Il sera alimenté en 3.5 v par elle et servira d'interface TCP/Serie. Visonic a prévu des connecteurs dans la centrale afin d'y connecter des cartes optionnelles et couteuses, sauf que les signaux sont disponibles sur les connecteurs et que les cartes ne servent qu'à supporter des connecteurs... Des petits malins on fait un joli travail de recherche (voir les sources). Le connecteur qui nous intéresse est celui de gauche et en branchant un petit câble Dupont à 4 fils sur les 4 du haut à droite on sortira aisément GND TX RX et les 3.75 v nécessaires à l'alimentation de notre ESP.

Il ne reste plus qu'à connecter ça à notre ESP aux bons endroits, en inversant RX/TX et en faisant attention au connecteur d'alimentation car il n'y a pas de fusible...

Ensuite on se connecte en WI-FI sur son SSID (ESPxxx) et on renseigne le réseau WI-FI que l'on consacre aux IoT dans l'onglet WI-FI Station, il redémarre et on peu le pinguer... On pense à le mettre en réservation DHCP... Le seul réglage qui nous intéresse est la vitesse (9600 ou 38400 selon les modèles de centrales), et même si ce firmware permet de faire du MQTT et autres joyeusetées on désactive tout, il ne servira qu'à ça !

Intégration à Home Assistant

Cette intégration j'ai du la lancer 50 fois, mais quand on a la bonne communication ça fonctionne du premier coup. Elle permet beaucoup de choses, mais le mode standard qui me permet de voir et utiliser mes capteurs est suffisant. Je m'en contenterais car dans mes bricolages j'ai perdu le code installateur de la centrale ce qui va me limiter à l'avenir ! (code impossible à reseter). EDIT : Je viens d'apprendre qu'on peut justement le récupérer, grâce à une fonction non documentée de cette intégration...

On installe donc l'intégration Visonic, encore un excellent travail d'un passionné, et on renseigne l'IP et le port (23) de notre ESP. Et c'est tout, comme par magie les capteurs remontent ainsi que le panneau de commande. Il sera ainsi possible d'armer et désarmer la centrale depuis Home Assistant (Géoloc, présence pour l'armement et tag NFC pour le désarmement dans mon cas) et de savoir quel capteur à déclenché l'alarme dans une notification (Slack, TG ou SMS), mais aussi de conserver un log (CSV et/ou XML).

Ce qui m'embête c'est que je me retrouve avec d'un coté mes capteurs Xiaomi / Aqara qui me servaient à l'alarme HA, à couper le chauffage quand on ouvre les fenêtre ou allumer une lampe en cas de passage, et mes capteurs Visonic qui peuvent faire la même chose... Bref, j'aurais su avant je ne me serait pas lâché sur Ali Express...

Sources

J'ai écrit ça rapidement, mais voici mes sources qui contiennent pas mal d'informations pour qui voudra se lancer dans l'expérience

 

Jeedom : RFPlayer et génériques...

Les RFPlayer est une interface USB qui raccordé à Jeedom va permettre de décoder une multitude d’équipement, un peu à la matière du RFX-Com mais sur deux fréquences (433 et 868 MHz) et avec bien plus d’équipement reconnus. Dans la pratique ce n’est jamais que la technologie liée à l’héritage de la feu ZiBase dans une clé USB. Sur le papier glacé c’est génial, dans la pratique pour en tirer le meilleur parti c’est la qualité du plugin assurant l’interface avec la solution domotique retenue qui fera la différence. Sous Jeedom il y a d’abord eu une première version du plugin avec pas mal de problèmes, mais qui reconnaissait nativement les équipements. Ensuite nous avons eu une v2 bien plus stable mais qui fonctionne sur mode générique, dans l’absolu sans limites, mais qui déroute un peu au départ et rebutera plus d’un débutant. D’autant plus que l’équipe Jeedom n’est pas des plus prolixe en matière d’explications. Un peu comme si les nouveaux venus devaient mériter la solution !

Ça n’a donc pas été simple, mais au final le résultat est étonnamment plutôt stable. Si certains équipements sont reconnus nativement (les sondes Oregon par exemple), l’affaire est un peu plus complexe des lors qu’il s’agit d'exploiter des équipement X2D ou Visonic. Je vais essayer de vous donner ici quelques explications. On considère que le RFPlayer est installé, son firmware à jour et le plugin installé dans sa dernière version.

Visonic

En  passant par le plugin en mode inclusion il est aisé de détecter les équipements, il faudra ensuite les localiser physiquement, mais ça on le fera plus tard. Pour l’instant ce qui importe c’est de détecter l’ensemble de capteurs. Ce qui va nous intéresser ici c’est la valeur qualifier qui est une information numérique que l’on exploitera avec un script ou un virtuel. Voici les valeurs pour un détecteur d’ouverture (MCT-302 ou un IR) et ce que j’en ai déduit d’après les informations que j’ai pu trouver sur les forums :

0 Fermé (action immédiate)
2 Ouvert (action immédiate)
4 Warning ? défaut sur le capteur, autoprotection ?
8 Fermé (en veille ou pour supervision par la centrale)
10 Ouvert (en veille ou pour supervision par la centrale)
12 Batterie faible

Ces valeurs n’étant pas binaires il sera impossible de les exploiter directement pour détecter une fenêtre ouverte dans une thermostat ou avec le plugin Alarme. Tout au plus il est possible de programmer une (et une seule) action sur la valeur directement dans les paramètres avancés du qualifier, mais ce n’est pas très propre et limitatif. On peu également créer un widget qui affichera les divers états, c’est ce que l’avait expliqué le support Jeedom, c’est joli, didactique, mais ça ne sert à rien. J’ai donc créé un équipement virtuel, qui pour chaque sonde Visonic va transformer ces informations numériques en informations binaires, après tout ce dont j’ai besoin c’est de savoir si ma fenêtre est ouverte ou fermé !

(#[Alarmes][Chambre Lionel][qualifier]# & 2) == 2 or (#[Alarmes][Chambre Lionel][qualifier]# & 10) == 10

Ce qui nous donne ça en fignolant un peu... 

A partir de là cette information étant binaire elle est directement exploitable dans d’autres plugins ou scénarios.

EDIT : Cette solution permet d’avoir une visibilité globale des capteurs, et je dois bien avouer que je ne savais pas trop faire autrement. J’avais pourtant posé la question tant sur le forum que directement au support Jeedom sans réponse satisfaisante. Jusqu’à ce qu’un développeur de passage sur mes posts du forum m’explique qu’il est possible de faire bien plus simple en ajoutant une commande data::qualifier de type info directement sur l’équipement :

Et ensuite la formule de calcul idoine (#[Alarmes][Test][qualifier]# & 2) == 2 or (#[Alarmes][Test][qualifier]# & 10) == 10 dans la configuration avancée :

Il est également possible de simplifier la formule ainsi (#[Alarmes][Chambre Lionel][qualifier]# & 2) == 2, mais on aura alors que l'état instantané et non l'état en veille, mais c'est généralement suffisant et le résultat est identique. On évite ainsi le Virtuel et on obtient un résultat simplifié et directement exploitable. Je me demande juste pourquoi cette info n'est pas crée lors de la détection de l'équipement et pourquoi les auteurs du plugin ne l'ont documenté nulle part. Et ce n'est pas faute d'avoir cherché !

XD2

Pour récupérer des informations on doit pouvoir procéder de façon à peu près identique. Moi j’avais besoin que de commander un seul actionneur RP600 de chez DeltaDore qui actionne un fil pilote. Dans mon cas je gère ce sèche serviettes avec un thermostat Jeedom, donc ce que je voulais c’est uniquement faire du ON/OFF tout en laissant la possibilité d’utiliser la marche forcée physique du sèche serviettes. (Voir les détails ici). J’ai donc créé un équipement virtuel qui va transmettre ses ordres à l’équipement du RFPLayer et nous donner un retour d’état tout aussi virtuel. J’exécute donc une Action après exécution de la commande ou pour ON j’envoie #[Hardware][X2D RP600 SdB][Confort]# au RFPlayer, et #[Hardware][X2D RP600 SdB][Hors Gel Low]# pour OFF. Chacun adaptera à ses besoins et ça marche à l’identique pour les autres protocoles.

Conclusion

Contrairement aux habitudes, il est bien souvent impossible d’utiliser seul le nouveau plugin du RFPlayer. Il faudra soit écrire du code, des scripts ou des scénarios, soit se simplifier la tâche en exploitant intensément le plugin Virtuel. Quoi que...