Journal Je domotise mes volets roulants (avec cron et mqtt)

Sommaire

• Le choix du matériel
  • Pourquoi du ZWave?
• Installation du logiciel
• L'interface MQTT

Je viens de déménager! (je vous l'ai déjà dit dans le journal précédent).

Dans mon nouvel appartement, c'est le grand luxe, il y a des volets roulants motorisés. Ils sont fournis avec des interrupteurs de commande filaire. Plus besoin de tourner une manivelle pour ouvrir et refermer.

Tant qu'à faire, je me suis dit que ce serait bien de pouvoir les piloter automatiquement, afin de pouvoir les fermer automatiquement la nuit et les ouvrir quand il y a du soleil (l'hiver) ou l'inverse (l'été).

J'ai donc découvert les joies de la domotique. Je vous explique comment j'ai fait.

Le choix du matériel

Comme je l'ai indiqué, mes volets sont fournis uniquement avec une commande filaire (interrupteur installé dans le mur à proximité du volet). Je ne pars donc pas d'une installation existante avec un protocole sans fil imposé.

J'ai donc commencé par me renseigner sur les différents protocoles disponibles, en évacuant tout de suite les solutions propriétaires (Somfy, Deltadore X2D/X3D, …) et en me penchant surtout sur les protocoles ouverts.

Pourquoi du ZWave?

Bon, je divulgâche le truc dans le titre, mais j'ai choisi du matériel utilisant le protocole ZWave.

Ce protocole a été initialement développé par l'entreprise Zensys en 1999. Au départ c'était un protocole fermé et les spécifications n'étaient pas publiées. Mais, petit à petit, au grès des rachats d'entreprises et des changements d'intérêts, le protocole a été publié puis finalement standardisé par l'ITU.

Aujourd'hui, de nombreux fabricants de matériel domotique utilisent ce protocole, et une organisation indépendante (ZWave Alliance) fournit une certification assurant que le protocole est correctement implémenté, ce qui limite les problèmes d'interopérabilité.

Le protocole ZWave utilise une fréquence radio de 868MHz, ce qui lui permet de ne pas entrer en conflit avec le Wifi ou avec un four à micro-ondes. Contrairement par exemple au Zigbee qui se trouve dans la bande des 2.4GHz.

Pour terminer, le protocole est chiffré avec une clé de sécurité spécifique à chaque réseau. Cela rend difficile d'envoyer une commande pour ouvrir ou fermer mes volets roulants sans mon accord (ou au moins sans avoir réussi à accéder à mon serveur qui contient les clés).

Bref, une fois le protocole choisi, il faut équiper les volets ainsi que la machine qui va piloter ce réseau. Je me suis donc équipé de 3 modules Shelly Qubino Wave Shutter ainsi que d'un dongle USB Zooz Z-Wave+ 700.

L'installation des boîtiers Shelly se fait sans trop de difficulté, le boîtier est connecté à l'alimentation électrique (phase/neutre en 220V), au moteur du volet, et aux interrupteurs (ces derniers sont optionnels si vous voulez tout télépiloter). Le boîtier est tout petit et tient sans problème dans la boîte électrique prévue à cet effet à proximité de chaque volet roulant.

Du côté du dongle Z-Wave, l'installation est encore plus simple puisqu'il est reconnu comme un simple adaptateur USB série. Pas besoin de drivers spécifiques, c'est directement géré par Linux!

Installation du logiciel

En principe, les recommandations sont d'utiliser Home Assistant ou un de ses concurrents, une solution tout-en-un avec un conteneur Docker ou même une image de SD card toute prête pour déployer sur un Raspberry Pi. Étant allergique à ces technologies modernes, j'ai plutôt regarder comment faire pour installer juste le nécessaire sur mon serveur existant fonctionnant sous Debian.

Il existe deux implémentations principales du protocole ZWave open source. La première est openzwave, le projet historique développé en C++. Il date d'avant la publication ouverte du protocole ZWave et est donc basé partiellement sur du reverse engineering par observation des trames. Il n'est plus maintenu aujourd'hui.

Son remplaçant est ZWave JS, qui est écrit en nodejs.

Il existe également quelques bibliothèques en Rust, mais ça a l'air beaucoup moins complet et facile à mettre en place pour l'instant. Je réessaierai peut-être dans quelques années.

Regardons donc du côté de ZWave JS. Le projet fournit non seulement l'implémentation du protocole, mais aussi un module d'interface web et serveur MQTT qui va être nécessaire pour interagir avec. Dirigeons nous donc vers les instructions d'installation de zwave-js-ui.

Bon, il y a plein de propositions à base de snap, Docker, et tout ces trucs compliqués. Pas envie de me compliquer la vie avec ça, mais heureusement il y a aussi des instructions pour une installation directe à l'aide d'une simple commande "npm install", qui se déroule sans problème après m'être assuré d'avoir une version à jour de nodejs sur ma machine.

On peut ensuite lancer le serveur manuellement et vérifier que l'interface web est accessible. Tout semble bon, super.

Il faut ensuite faire en sorte que le service soit lancé au démarrage de la machine et continue de tourner même quand il n'y a pas un terminal ouvert avec l'application qui tourne dedans. Les instructions officielles proposent d'utiliser pm2, je n'ai pas la moindre idée de ce que c'est, et ça a l'air de rendre les choses compliquées pour rien. Écrivons plutôt un service systemd qui fera très bien l'affaire et plaçons le dans /usr/lib/systemd/system/zwave-js-ui.service

[Unit]
Description=ZWave JS UI

[Service]
Environment="STORE_DIR=/etc/zwave-js-ui"
Type=simple
ExecStart=/home/pulkomandy/node_modules/.bin/zwave-js-ui
User=pulkomandy

[Install]
WantedBy=multi-user.target

Quelques remarques:

• On fournit un dossier via la variable d'environnement STORE_DIR, dans lequel zwave-js-ui va stocker ses clés de chiffrement, la liste des appareils associés, les "scenes" (préconfiguration de différents devices avec une liste de commandes à envoyer, …). Par défaut ce dossier de stockage est directement dans le dossier node_modules, mais cela fait qu'il est effacé lors de mises à jour du logiciel
• Le service est de type "simple" (systemd a juste à lancer l'exécutable et le laisser tourner)
• J'ai lancé la commande npm avec mon utilisateur "pulkomandy" sur le serveur, donc les fichiers sont dans mon home et m'appartiennent. Il convient donc de lancer le service avec ce même utilisateur
• On ajoute ce service dans la target multi-user pour qu'il soit lancé au démarrage de la machine.

Voilà, c'est tout pour l'installation. On prévient systemd qu'il y a un nouveau service, puis on peut le démarrer:

systemctl daemon-reload
systemctl start zwave-js-ui

Une fois le service lancé, il est possible d'accéder à l'interface graphique (bon, pas pour vous, puisque c'est sur mon réseau local, mais je vous assure que ça fonctionne).

La prochaine étape est d'appairer les modules ZWave avec ce nouveau serveur. Il faut d'abord sélectionner le port série correspondant au module ZWave (en s'assurant d'avoir les droits pour le faire, mon utilisateur est dans le groupe dialout qui est propriétaire des ports série sous Debian par défaut). Il faut ensuite générer les différentes clés de chiffrement (il y en a plusieurs, pour différentes versions du protocole) ce qui se fait en quelques clics dans l'interface. On est maintenant prêts à communiquer.

Chaque modules doit être appairé avec le réseau. Pour cela, le module est fourni avec un QR code qu'il faut entrer dans l'application. Ce code contient une identification du matériel ainsi qu'une clé d'appairage (si j'ai bien tout compris). Il est important de le conserver si on veut changer de contrôleur de réseau plus tard et ré-appairer les appareils plus tard.

Pour introduire le code dans l'application, comme mon serveur n'a pas de webcam, je l'ai scanné avec mon téléphone (avec l'application Binary Eye, très pratique pour ça) puis copié collé le texte dans l'interface web. J'ai gardé un backup de ce texte si jamais je perds l'étiquette avec le QR code.

Il faut également placer les modules en mode appairage, ce qui se fait soit en leur coupant le courant, soit en appuyant plusieurs fois sur l'un des interrupteurs par exemple (cela dépend du type de module). L'appairage peut être assez long, il faut donc attendre plusieurs minutes sans s'inquiéter.

Au bout d'un moment, les modules sont bien reconnus! Enfin presque: deux d'entre eux s'affichent comme du matériel inconnu alors que le troisième est bien identifié. Pour ce dernier, zwave-js-ui me propose même une mise à jour de firmware qui se fait "over the air" (c'est là encore un peu long, vu le débit faible du réseau zwave). L'installation du firmware se passe sans problème.

Bien que les deux autres modules ne sont pas identifiés, le protocole ZWave semble s'auto-décrire, je vois donc bien apparaître tous les points d'entrée permettant de piloter le volet, de lancer une calibration, et de configurer divers réglages (inverser les boutons, inverser la direction du moteur, configurer l'utilisation d'interrupteurs momentanés ou persistants, …). Le volet qui a été mis à jour en version 14 inverse la direction du moteur par rapport aux autres (c'est indiqué dans les notes de versions du firmware). Je le reconfigure donc pour être dans le même sens que les autres: la valeur 0 correspond à un volet ouvert, et 99 à un volet fermé. Le 50% se trouve à peu près aux 2/3 de la fenêtre.

Le pilotage se fait en envoyant une "target value" entre 0 et 99 dans la section "multilevel switch" de l'interface web. Le but de zwave-js-ui n'est pas de proposer une jolie interface facile (pour ça il vous faudra la développer vous-même ou utiliser une surcouche comme home assistant). C'est donc assez technique avec beaucoup d'infos exposées de façon assez brute. Mais ça marche!

L'interface MQTT

Le but de l'escercice est de pouvoir piloter mes volets automatiquement. Passer par une interface web ne m'intéresse donc pas trop. Mais zwave-js-ui ne fait pas que ça, il peut aussi communiquer en MQTT!

Pour ce faire il y a encore un petit peu de configuration:

• Installer mosquitto et mosquitto-clients (avec apt ou votre gestionnaire de paquets préféré)
• Dans les paramètres de zwave-js-ui, cocher la case "MQTT gateway". Redémarrer le serveur ZWave lorsque c'est proposé à l'enregistrement des paramètres.

La version de mosquitto packagée dans Debian écoute déjà sur le port MQT standard (1883) donc il n'y a pas de configuration particulière à faire). On peut ensuite observer les informations disponibles:

Observer les infos disponibles (s'abonner à tous les topics et afficher le topic et la valeur reçus):

mosquitto_sub -h localhost -t "#" -d

• -h localhost: écouter sur la machine locale
• -t "#": s'abonner à tous les topics
• -d: afficher le topic en plus de la valeur reçue

On voit que toute la liste de paramètres accessibles dans l'interface web est également disponible.

Il ne reste plus qu'à envoyer des commandes pour ouvrir et fermer les volets. Le topic est configuré à partir de la localisation et du nom de l'appareil préalablement configurés dans l'interface web. Le pilotage d'un volet se fait donc avec une simple ligne de commande:

mosquitto_pub -t
zwave/Salon_Ouest/Shutter_Salon_Ouest/switch_multilevel/endpoint_1/targetValue/set -m '0'

mosquitto_pub -t zwave/Salon_Ouest/Shutter_Salon_Ouest/switch_multilevel/endpoint_1/targetValue/set -m '0'

On peut bien sûr utiliser toute autre valeur entre 0 et 99. Une fois le module calibré (ce qu'il faut lancer soit via une commande zwave, soit via un motif de pressions répétées sur les boutons du store), il a détecté où se trouvent les fins de course du moteur de chaque côté et peut donc suivre la position du volet en fonction du temps d'ouverture et de fermeture.

Et voilà, y'a plus qu'à faire quelques scripts et tâches cron pour déclencher les ouvertures et fermetures à l'heure et à la saison choisies. En faisant en sorte de ne pas me retrouver coincé sur la terrasse parce que les volets se sont fermés automatiquement pendant que j'étais dehors. Je vais peut-être compléter cette installation par un interrupteur de pilotage installé à l'extérieur, ou des capteurs de présence…