1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
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)
|
