Il y a un sujet sur lequel je ne m’étais jamais penché, la domotique. C’est maintenant chose faite, et je vous partage mon expérience, dans un premier article.

Pour éviter les articles de 10 pages, d’autres suivront :D

Si vous avez des suggestions ou commentaires, n’hésitez pas à m’écrire sur le journal du hacker où j’ai publié cet article

La domotique, KESAKO ?

Beaucoup diront que la domotique c’est rendre sa maison intelligente. Perso je n’irais pas jusqu’à là.

Je dirais plutôt que le but, est d’automatiser certaines actions, souvent autour des mêmes thématiques (lumières, chauffage, ouvertures de portes, détection de présence…).

Les cas pratiques sont très variés, mais surtout, dépendent du besoin de chacun, et du périmètre sur lequel on veut travailler.

Technos et protocoles

Aie, là on rentre dans le vif du sujet, et clairement pas des moindres.

On va faire simple, des technos, il y en a plein. Des tas. Plein de constructeurs ont sorti des technos, en espérant que chacun serait privilégié, et au final, rien n’était compatible avec tout, et tout avec rien. C’est surtout ça qui m’a repoussé du sujet au départ.

Certains protocoles sont sortis du lot au fil du temps, comme Zigbee, ou Z-wave, bien plus économes en ressources, en énergie et coût de production que du Wifi ou bluetooth.

Néamoins, avec le temps, les choses ont commencé à bouger, et un nouveau protocole, nommé Matter, commence à sortir la tête de l’eau. Celui-ci serait porté par beaucoup de géants (Apple, Google, Amazon), et mené par la “Zigbee Alliance”, afin de sortir un protocole standard. L’avantage est qu’à terme, tous les équipements pourraient être compatibles, et ça c’est le pied.

De mon côté j’ai mixé en l’utilisation d’équipements Wifi (car directement alimentés), ou du Zigbee qui est vraiment stable et peu couteux.

Premiers besoins

Vu que je suis une tête en l’air, enfin parfois, la première chose dont j’ai besoin serait d’automatiser l’ouverture de porte de garage, ou de portail, sans utiliser la télécommande d’origine.

Cela implique déjà plusieurs difficultés : valider que les centrales de gestion de ces portes puissent gérer un pilotage annexe, ou l’ajout d’un équipement. Dans mon cas, malgré trois technologies différentes, toutes ont la possibilité d’avoir un “contact sec” qui permet de déclencher l’ouverture/fermeture via un bouton poussoir.

Autre besoin, gérer l’allumage automatique de lumières, que ce soit via un interrupteur, ou de lampes déplaçables, donc plutôt via l’automatisation de la prise électrique. Bien pratique quand on rentre en moto/voiture dans un garage et qu’il fait nuit.

Reste à trouver la techno qui pourrait allumer la lumière, sans changer toutes les ampoules par des connectées, dans un coût raisonnable : Shelly.

Si on veut automatiser l’allumage il faut coupler ça sur des capteurs de portes (pour savoir l’état d’une porte : ouvert/fermé), ou des détecteurs de mouvements.

Dans ce cas, l’accès à une source de courant en continu est plus problématique, il faut partir sur des équipements à pile, le Zigbee est donc le parfait candidat. Pour ces besoins j’ai donc utilisé plusieurs équipements.

Shelly

Shelly est une marque plutôt interessante qui fourni des équipements embarqués, connectables en Wifi, et manageables. Par défaut, ils sont pilotables après connexion à votre Wifi, par une application Cloud.

Néanmoins, on peut désactiver le cloud, et chaque équipement, via sa petite interface web pratique, permet de gérer un protocole tel que MQTT, de quoi discuter avec l’équipement via le Wifi, depuis un contrôleur.

Shelly propose plein de modules, dont dans mon cas, de contacteurs “secs”, relativement petits, alimentables en 220V AC, ou 12-36V DC/AC ; Shelly 1. Ceci me permet de les brancher dans mes boitiers de gestion de portes, et de fermer le circuit du contact sec ponctuellement pour activer la porte.

On peut aussi s’en servir pour les interrupteurs de lumière, donc c’est parfait.

Après allumage chaque Shelly génère un réseau wifi dédié, et le shelly est joignable sur http://192.168.33.1. Il suffit ensuite de parcourir les menus pour changer son nom, son réseau SSID, la configuration du relai.. C’est très intuitif.

Câblage contacteur sec “simple”

Dans ce cas le câblage est simplissime. La question à se poser c’est surtout l’alimentation. Dans mon cas les portails gèrent une sortie 24V alternatif, ou je me branche directement sur le 220V. Attention juste sur le Shelly à changer le cavalier si vous passez sur du 12V DC.

On branche sur les ports L et N et le Shelly est alimenté.

Le contacteur sec est à connecter sur le port 0 et 1 du Shelly. A noter qu’aucun courant ne transite entre l’alimentation du shelly et le contacteur sec, ce sont deux circuits isolés.

Dans le cas d’un contact “rapide”, il faut configurer le shelly pour le mettre en “Auto-OFF” à 0.5 sec. Ceci permet qu’il se comporte comme un bouton poussoir.

Câblage interrupteur de lumière

J’ai utilisé le même module pour l’intégrer dans des interrupteurs de lumière. Ce câblage nécessitera par contre la présence d’un fil de neutre dans vos interrupteurs (ce n’est pas le cas des anciennes installations).

La configuration électrique est un peu différente. Attention, ne jouez pas avec l’électricité, hein. On ne le fait pas si on ne s’en sent pas capable, et encore moins sans couper le courant ;)

En gros le câblage (prévoir de quoi dupliquer la phase) est le suivant.

• La phase (partant initialement vers l’interrupteur) va vers la borne L du shelly (pour l’alimenter)
• La phase va aussi sur le port “I”
• La phase va sur la borne L de l’interrupteur
• Le neutre est sur le port N du Shelly (pour l’alimenter)
• Le retour de l’interrupteur, va sur le port “SW” du Shelly
• Enfin, le retour original de l’interrupteur, va sur le port “O” du Shelly

Je n’ai pas créé ce schéma mais en gros c’est ça :

Une fois démarré, le shelly est à configurer.

La configuration est un peu différente, il faut utiliser le mode “Edge”.

Ceci permet à l’interrupteur physique d’avoir le rôle d’un va-et-vient. On peut allumer/éteindre via le shelly ou via l’interrupteur.

Equipements Zigbee

L’utilisation du Zigbee nécessite d’avoir un controleur. On en trouve plein sous la forme de clés USB avec une petite antenne (type wifi) pour du 2,4Ghz.

Celle que j’utilise est une Sonoff Zigbee 3.0 v2.

Au niveau des équipements, j’ai trouvé sur le net :

• des plugs power Tuya :

• des détecteurs de mouvement et de lumière Aqara :

• des contacteurs de portes Tuya :

• des boutons basiques Aqara :

Leur appairage se fera via l’application Home Assistant. Je n’en ai pas encore parlé de Home Assistant mais j’ai spoilé dans le titre !

Cloud perso

C’est chouette, mais me voilà avec plusieurs Shelly autonomes. Je ne veux pas utiliser le cloud, donc je fais comment pour aller plus loin ?

Plusieurs solutions existent actuellement dans le monde de l’open source pour avoir un contrôleur en auto hébergement. Perso je n’ai pas gratté toutes les solutions, deux principalement venaient à mon esprit, Jeedom et Home Assistant.

J’ai commencé par Home Assistant, et via sa simplicité d’utilisation, la quantité de documentation, et son interface moderne, je n’ai pas testé Jeedom.

Le matériel nécessaire

Dans mon cas l’hébergement ne sera pas un problème (cf mon article sur l’auto-hébergement), mais si vous n’avez pas d’infra de virtualisation, ou autre, un simple Raspberry Pi fera l’affaire.

Beaucoup partiront sur un Pi4, mais je suis convaincu qu’un Pi2 (que je préfère amplement vis-à-vis de sa consommation/dissipation) fera l’affaire.

Si vous voulez utiliser du Zigbee, atention, utilisez bien un port USB2.0, les ports 3.0 ont fréquemment des problèmes connus d’interférences sur ce genre d’équipement.

Si vous faites de la virtualisation, pensez à rattacher l’équipement USB à la VM.

On prépare tout ?

Réseau et sécurité

Si je veux répondre à mon premier besoin, l’idée serait de pouvoir actionner mes portes avec mon tel. Cela implique surtout de le faire depuis le réseau opérateur et ne pas être dépendant du Wifi de la maison. Le truc, c’est qu’il est hors de question pour moi d’ouvrir l’accès sur Internet.

Donc, je vais faire simple, un VPN Wireguard et zou. J’ai déjà toute l’infra qui va bien, c’est donc fait rapidement.

J’ai déjà mon infra de reverse proxy, il n’y a pas grand chose à rajouter.

Par contre, j’en ai profité pour créer un VLAN dédié à la domotique, et un réseau Wifi également dédié dans ce VLAN sur mon AP, pour séparer les machines du reste de mon infra.

Ceci permet aussi de contrôler les flux vers ce VLAN, en entrée/sortie, et surtout vers Internet.

Déploiement du serveur

Bon, c’est parti. Une petite VM en Debian 11 (et pourquoi pas un LXC ?).

Hum, HomeAssistant s’installe très bien via Docker, et vu que je ne déploie rien sans Ansible, un petit rôle vite fait (un playbook simple irait aussi, mais j’utilise un rôle dans mon cas), et du docker-compose et c’est parti.

Je vous partage un peu le code. Il n’est pas entier, car il s’agit juste du main.yml de mon rôle, mais fait le taf. A adapter si vous voulez un playbook.

---
- name: HOME ASSISTANT | Create needed folders
  file:
    state: directory
    path: '{{ item }}'
    owner: home
    group: home
    mode: '0755'
  loop:
    - /opt/homeassistant
    - /opt/homeassistant/config
    - /opt/homeassistant/media
    - /opt/compose

- name: HOME ASSISTANT | Generate docker-compose.yml
  template:
    src: docker-compose.yml.j2
    dest: '/opt/compose/docker-compose.yml'
    owner: root
    group: root
    mode: '0600'

- name: HOME ASSISTANT | Compose up
  community.general.docker_compose:
    project_src: '/opt/compose'
    files: docker-compose.yml

Et le docker-compose qui va servir :

---
version: "2.1"
services:
  homeassistant:
    image: homeassistant/home-assistant:{{ homeassistant_version }}
    container_name: homeassistant
    network_mode: host
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
    volumes:
      - /opt/homeassistant/config:/config
      - /opt/homeassistant/media:/media
      - /dev/serial/by-id:/dev/serial/by-id
    devices:
      - /dev/ttyACM0:/dev/ttyACM0
    ports:
      - 8123:8123
      - 5683:5683
    restart: unless-stopped

J’utilise une variable homeassistant_version pour gérer la version que je pousse. Cf Docker hub. Dans le docker-compose, se trouve un peu de configuration pour connecter la clé Zigbee V3 que j’utilise sur l’hôte, et l’envoyer dans le docker.

Après lancement d’Ansible, me voilà avec un HomeAssistant qui répond en web.

C’est parti pour l’aventure

Dans le second article, je parlerais de la suite naturelle :

• Interface Home Assistant dans les grandes lignes
• Connexion des équipements à Home Assistant
• Création des automatisations, des scènes
• Cas concrets et problèmes associés