Initiale releaseHEADmaster

1 files changed, 131 insertions, 0 deletions

diff --git a/Capteurs_et_domotique.txt b/Capteurs_et_domotique.txt
new file mode 100644
index 0000000..2b2cb2e
--- /dev/null
+++ b/Capteurs_et_domotique.txt
@@ -0,0 +1,131 @@
+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)