Titre: Capteurs et domotique
Auteur: Bruno
Date: Sun 24 Feb 2013 22:17:57 +0100
Lien: https://blog.spyou.org/wordpress-mu/2013/02/24/capteurs-et-domotique/

Nombre d’entre vous connaissent déjà la @maisonquitweet[1]. J’avais promis il y
a un moment[2] 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.

[image 3]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 ;)

Liens:
[1]: https://twitter.com/Maisonquitweet (lien)
[2]: http://blog.spyou.org/wordpress-mu/2012/09/06/ma-petite-domotique/ (lien)
[3]: http://blog.spyou.org/wordpress-mu/files/2013/02/20130202_203300-e1361617593593-225x300.jpg (image)