Turb(l)o(g)

Nombre d’entre vous connaissent déjà la @maisonquitweet. J’avais promis il y a un moment de vous expliquer en détail comment tout ça fonctionne. Retour donc sur la domotique. J’aborderai un peu plus tard la partie puissance et interface homme/maison. D’ici là, un petit topo sur les capteurs, maintenant que j’ai à peu près terminé la « phase R&D » (ça claque hein, ouais, je suis à 2 doigts de réclamer un crédit impôt-recherche !).

Il s’agit donc de créer un réseau de capteurs environnementaux dispersés dans la maison, à la fois pour la surveiller, mais aussi et surtout pour adapter plus ou moins automatiquement son comportement. On parle donc de capter la température, la luminosité, et pourquoi pas le son, l’hygrométrie, le mouvement, la présence de fumée…) Quelques prérequis :

• au maximum câblé. Non pas que j’ai peur des ondes, mais je préfère la fiabilité du bon vieux cuivre et pourquoi faire du wireless sachant qu’il faudra toujours alimenter les montages et donc câbler ou bien s’emmerder avec des piles.
• WAF au top, il faut que ce soit JOLI, sinon, PAF, ça fait des chocapics.
• modulaire au possible, histoire de pas se retrouver avec un gros système monolithique qui ne pourra que très difficilement évoluer
• corollaire, éviter de réinventer la roue au maximum

Pour le câblage, j’ai fait au plus simple : un câble 4 paires arrive dans chaque pièce à une hauteur comprise entre 1m50 et 1m80, au possible éloigné des sources de chaleur (radiateur & luminaire), des fenêtres, et à un endroit pas trop saugrenu. Tous ces câbles sont regroupés dans la salle technique sur des borniers télécom, permettant de pouvoir jongler avec les interconnexions assez simplement.

Du côté du joli, je n’ai rien trouvé de mieux que de cacher mes montages dans des appliques de luminaire. Ça permet toute sorte de fantaisie, mais ça oblige à conserver des montages de petite taille.

Comme je suis un intégriste du tout-IP, j’avais d’abord prévu de câbler tout ça en RJ45. Mais il faut se rendre à l’évidence, impossible de construire une solution ethernet qui soit à la fois bon marché, de petite taille et pratique à déployer. Ce qui s’en approchait le plus consistait à équiper chaque applique murale d’une arduino avec un module ENC28J60 et de faire du faux POE pour alimenter le tout. La modularité était maximale mais l’arduino ne permet pas de grand délire dans l’interaction via ethernet, rapport à l’espace mémoire très limité. Je n’ai pas exploré la piste raspberry pi, c’est peut être un tort.

La seconde piste consistait à brancher les capteurs directement sur le câblage et centraliser l’intelligence dans la salle technique. Pratique à déployer, mais ayant prévu 4 paires de cuivre par applique, je me retrouvais de facto limité dans le nombre de sondes installables dans chaque lieu ainsi que dans les fonctionnalités.

Le premier principe consistant à déployer une intelligence minimaliste dans chaque applique me taraudant, j’ai cherché comment faire communiquer une arduino sur autrechose qu’ethernet. Prérequis : il faut supporter les quelques 500 mètres de câble utilisés par le réseau, que ce soit rapide (pouvoir faire au moins tout le tour de la quinzaine de points de mesure de la maison en une seconde maxi), et que ce soit bidirectionnel (par exemple pour accrocher une led RGB à l’arduino d’une applique pour faire une sorte de retour d’état ou d’alerte visuelle,et pouvoir la piloter depuis le central).

Exit le 1wire : rien trouvé pour qu’un arduino se fasse passer pour un composant 1wire
Exit le RS232 et le TTL : distance maxi trop courte

Et finalement exit à peu près tout… Tout sauf l’I²C. Il n’a pas été conçu pour la longue distance mais de petits produits pas cher permettent de s’en affranchir.

Pour monter un réseau I²C fiable sur un réseau en étoile de plus de 500m, il faut commencer par créer un hub central. Les amplis NXT que j’ai trouvé permettent manifestement de parler sereinement sur 2/300 mètres. Je vais donc en prévoir 5 pour être large et découper ma maison en 4 zones, une zone par ampli, plus un ampli de spare au cas où.

Derrière les 5 amplis du hub, un arduino avec un module ethernet. Sa fonction : aller interroger en permanence tous les arduinos distants et garder au chaud une table des états de tous les capteurs. En bonus : générer un appel Web lorsqu’un capteur spécifique est dans un état donné (ie un capteur de mouvement qui a vu quelqu’un bouger). Plus tard, écouter ce que le maître a à dire pour faire flasher une led ou que sais-je d’autre.

De l’autre côté du câblage, harmonieusement réparti entre les 4 amplis, on trouve un ampli local devant un arduino qui supporte les capteurs locaux.

Tests effectués : j’arrive à faire en gros 100 appels au réseau i2c par seconde, largement suffisant pour réagir rapidement à un mouvement.

Coté arduino client, rien de sorcier :

• lecture analogique de 4 broches de l’arduino (pour lire de la luminosité ou de l’humidité par exemple)
• lecture analogique d’une broche avec moyenne sur un temps donné (par exemple 5 secondes pour capter une variation sonore fugace)
• compilation dans un seul octet de 8 broches numériques (détecteur de mouvement, de fumée…)
• gestion de deux réseaux 1wire pour capter la température avec des DS18b20

Le tout retourne donc 8 octets que l’arduino client garde au chaud en attendant que le maître I²C vienne demander. La photo montre un module en cours de développement, avec un détecteur de mouvement, un capteur de lumière, et un capteur de température.

Le seul problème rencontré réside dans le 1wire. Pour effectuer la conversion de température, le ds18b20 demande entre 750 et 1000ms. Il n’était pas concevable de laisser l’arduino ne rien faire dans ce laps de temps. Elle vaque donc à ses occupations dans le temps nécessaire au ds18b20 pour faire sa conversion puis vient l’interroger.

Toujours fan de l’asynchrone, le maître garde ces 8 octets au chaud en attendant une requête TCP qui va lui demander des infos, exception faite de quelques uns des bits du 6e octet qui génèrent un appel en TCP de l’arduino vers le serveur domotique pour prise de mesure immédiate (allumer la lumière des wc si ça bouge dedans, par exemple).

Lors d’une requête du serveur domotique à l’arduino maître,  toutes les valeurs d’un capteur sont transmises. Le serveur boucle ensuite pour parcourir tous les capteurs, juste histoire d’éviter que le buffer TCP de l’arduino ne soit trop gros. Il pousse enfin les valeurs reçues dans linknx qui est le chef d’orchestre de la maison.

De là, il est assez simple d’adapter le comportement de la maison, d’afficher les infos sur la visu domotique, de lancer des alertes, etc.

Mais ceci fera l’objet d’un article suivant ;)