Édito

À la fin de la lecture de cet article, le lecteur comprendra que ce n'est finallement pas l'installation que je souhaitais ni peut-être celle qu'il faut recommander. Je laisse cet article intouché pour archivage.

En juillet 2018, il semble que Hass.io soit le point de départ de HA (aka Home-Assistant). D'après la documentation officielle, Hass.io est un système d'exploitation à part entière, basé sur ResinOS et Docker. En installant Hass.io sur le host, deux containers sont créés, baptisés hassio_supervisor et homeassistant. Dans cette architecture, Hass.io se charge d'installer et de mettre à jour HA. Il est lui même administrable depuis l'interface de HA, permet de prendre des instantanés de la configuration et permet d'étendre facilement la configuration grâce à un catalogue d'extension. Je me aperçu de cela en ayant besoin d'installer ma première extension.

La doc officielle

Lien vers la page d'installation officielle

Néanmoins, j'ai personnalisé mon installation de la façon suivante.

Docker

Une petite vérification avant de se lancer :

stephan@tinas:/home/stephan$ docker --version
Docker version 18.03.1-ce, build 9ee9f40

Docker est bien installé, dans une version récente. On y va !

Création d'un Volume Docker

En ligne de commande, de la façon suivante :

stephan@tinas:/home/stephan$ docker volume create homeassistant_data

Installation de Home-Assistant

Instanciation n'est peut-être pas le mot du vocable Docker mais c'est celui qui me vient à l'esprit quant au résultat de la commande suivante :

stephan@tinas:/home/stephan$ docker run -d --name="home-assistant" -v homeassistant_data:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/home-assistant

Cette commande télécharge les éléments (le container ?) depuis le repo central et assure la correspondance (mapping en bon globish) des éléments suivants :

• le volume créé précédemment sera mappé en /config dans le filesystem du container,
• le container aura la même horloge que le host mais ne pourra pas la modifier,
• le container aura la même adresse IP et utilisera les ports accessibles du host (pas de proxy/routage donc)

Gestion des containers

J'ai cherché une interface graphique un peu plus directive et intuitive que la bonne ligne de commande, et je suis tombé sur Portainer dont l'installation sur le host est aussi simple que :

stephan@tinas:/home/stephan$ docker volume create portainer_data
stephan@tinas:/home/stephan$ docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

C'est d'ailleurs ces lignes d'installation qui m'ont incité à modifier ainsi les commandes pour installer le container Home assistant.

Désormais, depuis n'importe quel navigateur au sein de mon réseau local, je peux pointer l'URL http://tinas:9000 et arriver sur l'interface de Portainer.

Lors de la toute première connexion, Portainer réclamme un mot de passe pour le compe admin et permet de créer au besoin d'autres comptes utilisateurs. Pour ma part, admin suffira. Il faut ensuite ndiquer comment le container Portainer doit accèder au daemon Docker. En ce qui me concerne, j'ai opté pour l'option la plus à gauche de la liste proposée qui précisait que mon container Portainer et le daemon Docker à administrer sont sur le même host.

Une fois cette étape passée, je peux alors voir toutes les différents éléments de Docker :

• les volumes (dont ceux de Portainer et de Home-Assistant),
• les containers,
• etc.

Configuration de Home-Asistant

Une des premières choses à faire est de s'assurer qu'en cas de redémarrage du host, les containers seront bien redémarrés. Facile à faire sur une machine perso sans services critiques 24/7 ;-)

Un petit reboot plus tard, je peux constater que si daemon Docker est bien relancé ainsi que le container Portainer, ce n'est pas le cas du container Home-Assistant. En naviguant à travers l'interface de portainer, je trouve les paramètres de redémarrage disponibles : pour mon container Home-Assistant, je choisis l'option Restart-Policy=Unless stopped

En farfouillant dans l'interface, je trouve d'autres paramètres intéressants comme la quantité de mémoire autorisée pour le container, le nombre de CPU, etc... Je personnalise ces paramètres compte tenu de mon host et des capacités à Home-Assistant à opérer sur un Raspberry Pi 3.

Installation du sniffer ZigBee

Après avoir flashé le sniffer ZigBee avec un nouveau firmware, ce qui fera probablement l'objet d'un autre article, je vais devoir le brancher sur mon NAS hébergeant le container Home-Assistant.

En téléchargeant les sources de cc-tool, l'utilitaire permettant de flasher le sniffer ZigBee, j'avais noté la présence d'un fichier README. Si quelqu'un a pris la peine d'écrire ce fichier, c'est pour une bonne raison : il indique la présence d'une règle udev destinée à autoriser l'accès au device pour les comptes non-privilégiés. Je recopie donc cette règle dans le dossier de configuration de udev, c'est à dire dans /etc/udev/rules.d/

Le sniffer étant livré sans packaging, j'improvise une enveloppe protectrice et le branche via une petite rallonge USB Mâle/Femelle pour le déposer sur le boîtier du NAS afin d'éviter que ce composant un peu fragile ne serve de buttée en cas de mauvaise manipulation du serveur.

Et qu'en pense la vache ? Interrogeons la...

stephan@tinas:~$ ls -l /dev/ttyA* | cowsay -W80
 ______________________________________________________________
< crw-rw---- 1 root dialout 166, 0 juil. 20 11:40 /dev/ttyACM0 >
 --------------------------------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

stephan@tinas:~$

Le périphérique ZigBee est bien présent !

Et maintenant, il faut rendre ce périphérique accessible depuis le container. Un recours au moteur de recherche s'impose. La réponse vient tout de suite : à partir d'une vesion déjà ancienne de Docker, il est possible de passer le périphérique lors de l'instanciation du container, grâce au paramètre --device=/dev/ttyACM0. Pour le coup, la ligne de commande me paraissant encore une fois plus simple d'usage sur ce coup-là, je renvoie ma commande, enrichie de la déclaration du périphérique :

stephan@tinas:~$ docker run -d --name="home-assistant" -v homeassistant_data:/config -v /etc/localtime:/etc/localtime:ro --device=/dev/ttyACM0  --net=host homeassistant/home-assistant
docker: Error response from daemon: Conflict. The container name "/home-assistant" is already in use by container "335cad5e3971b7c209bb950e67d51e39b1e53f48764d9a3145683c4aeeef16ca". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
stephan@tinas:~$

Stupeurs et tremblements ! Docker essaie de m'instancier un nouveau container. Mais ce n'est pas ce que je veux : je veux juste mettre à jour la config existante du container "/home-assistant".

Nouvelles recherches : dans un message relativement récent, je découvre ... que l'on ne peut pas ! Il faut détruire le container et le recréer. Un peu lourdingue je trouve. Pourquoi cette limitation ? Docker évolue vite et une solution sera apportée, mais pour l'heure, il semble que la marche à suivre soit bien de détruire le container existant. Heureusement 100% des bits sont recyclés !

Ayant repéré dans le clickodrome (portainer) les boutons pour Stopper et Détruire le container, je passe le GUI qui me propose si nécessaire de supprimer également les données non persistées du container. Euh... Pour l'heure, c'est la conf de base et je répond OK. Mais demain, quand j'aurais une config aboutie et que je voudrais mettre à jour le container avec une nouvelle version de Home-Assistant ? Il ne faudra pas oublier de faire une sauvegarde du volume créé initialement pour la config justement. Penser à voir comment backuper un volume.

Pour recréer le container, je passe par la CLI avec la même commande ci-dessus. Cette fois-ci, le résultat est satisfaisant. La création est même plutôt rapide : Docker a dû comparer le checksum de l'image de Home-Assistant déjà téléchargée précédemment avec celle dispo en ligne et constater qu'aucune mise à jour en ligne n'avait été faite et du coup, il a réutiliser le téléchargement précédent. J'en aurais le cœur net lors de la prochaine mise à jour de Home-Assistant.

Vérifions que le périphérique est bien présent dans le container. Depuis le GUI, j'ai facilement repéré comment ouvrir un shell au sein de container. Je passe par là et mon périphérique ZigBee apparait bien dans la liste des périphériques sous /dev

Configuration de Home-Assitant

Fichiers de config

Depuis le container, ces fichiers sont dans le dossier /config, qui rappelons-le, correspond au volume créé au début de cet article. Depuis le host, ces fichiers apparaissent sous /var/lib/docker/volumes/homeassistant_data/_data. Puis-je définir ma config à partir de là avec les outils d'édition (un bête nano en ce qui me concerne, un emacs ou un vim (ou plutôt un vim ou un emacs)) sans risque ? Je vais tenter un petit touch toto dans le dossier pour voir... Le fchier est bien créer. echo "Hello World" > toto : le fichier est bien mis à jour. Depuis le container, je vois bien le fichier toto et son contenu. Est-ce que BTRFS gère bien les accès concurrents ? J'ose croire que oui...

Quoi qu'il soit, je vais passer l'interface de Home-Assistant pour éditer la config. Ça sera l'occasion de la prendre en main.

Petite note perso

J'ai dû recharger la configuration de systemD au cours de ces manips. Cela se fait avec la commande :

root@tinas:~# systemctl daemon-reload

Interface graphique de Home-Assistant

L'application web est dispo sur le port 8123 du host. L'appli est responsive design, destinée à servir de télécommande pour contrôler l'installation dommotique. Pour la configuration, je préfère nettement un navigateur sur une machine avec un vrai clavier. Let's go : http://tinas:8123

Firefos vs Google

TODO

Read the doc

Je m'oriente vers la doc accessible depuis un cartouche bien en vue, que l'on pourra faire disparaitre par la suite.

Je souhaite accéder à l'application depuis mon réseau local mais aussi depuis l'extérieur (depuis l'Internet donc). Home-Assistant propose une extension permettant d'utiliser les services (gratuits) de DuckDNS. Et là, c'est le gag ! Pour installer cette extension (et les autres qui m'intéresent), il faut cliquer sur une option de menu que je ne vois. Après recherches, doutes, recherches, doutes, craintes et confirmation, je n'ai pas pris la route idéale. j'ai bien installé Home-Assistant mais depuis un certain temps, l'application a vu son architecture considérablement évoluée et ce n'est pas la voie préconisée...

Suite dans un nouvel article...