Home » 3615 my life, Domotique

Capteurs et domotique

24 février 2013 10 commentaires
tags : , , ,
Download PDF

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.

20130202_203300Coté 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 ;)

10 Comments »

  • Jkx said:

    Hum, le RS485 ou encore du CAN ne sont pas apprioprié à ce genre de chose ?

    Pour info, Elector a rédigé plusieurs articles cet hivers, sur des bus de terrains de ce type pour la domotique.

    A ++

  • Bruno (author) said:

    Les deux nécessitent plus d’électronique que l’I²C qui se contente d’un DIP8 et d’une paire de résistances … Le RS485 surtout. Le CAN j’avoue que je n’ai pas bcp cherché, mais ça peut être une piste intéressante.

  • syn,ack said:

    Pour le RS485, des composants comme le MAX485 (DIP) ça convenait pas ?

  • Raphael said:

    Pour le can, il existe un shield tout fait :

    http://code.google.com/p/canduino/

  • Bruno (author) said:

    Anéfé, mais trop gros et trop cher. Y’a les mêmes pour le RS485 d’ailleurs :)

  • Dfaure said:

    Les codes des arduino seront-il comme ce blog diffusé en licence CC?

  • Bruno (author) said:

    Ils sont très dépendant d’un tas d’autres choses dont certains resteront perso pour des bêtes questions de vie privée, mais c’est pas exclu que je banalise le maximum de chose pour le publier oui …

  • Jkx said:

    Pour info, il existe bcp de micro avec le CAN déjà intégré. Il suffit souvant du changeur de niveau, et c’est bouclé. On peut même à priori avoir une alim en mode parasite sur le bus directement.

    A ++

  • Moonchild said:

    Le bus I²C m’intéresse énormément. Je suis sous Rasberry Pi, et il cause la langue, de base. En revanche, pas moyen de trouver des infos sur les amplis NXT. Je vais essayer un peu la même chose, mais avec une collecte SNMP, je pense.

  • @cypou said:

    Savais-tu qu’il existe un petit composant « TP=UART » qui permet de relier n’importe quel micro-controleur à un bus KNX ? Au choix, tu pourrais remplacer la liaison ethernet/TCP de l’arduino « hub » par une intégration directe sur le bus. Ou bien encore si c’est suffisamment petit (arduino + carte TPUART) te brancher sur n’importe quel point où tu as déjà du KNX ;-)

    http://dka.web-republic.de/2013/04/prototype-pcbs-of-the-arduino-tpuart-interface/

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.


six + 6 =