Christophe Nowicki

Je reviens des mercredis de la RFID organisé par filrfid, le sujet de la présentation était le protocole ZigBee. Lors de la présentation faite par Véranith Ly de la société oRFIDée, j’ai appris beaucoup de choses sur ce protocole. J’aimerai donc vous en faire profiter et parler des domaines qui m’intéressent à savoir la domotique, la robotique et la topologie des réseaux maillés.

Description rapide du standard

ZigBee, est un standard de communication sans-fils comme le Wifi ou le Bluetooth.
Les principaux avantages du standard sont :

• Autonomie de l’émetteur, il est possible de le faire fonctionner durant plusieurs années à l’aide d’une batterie ;
• La possibilité de mettre en place une topologie de réseaux maillés ;
• 65535 nœuds sont addressable sur le réseau ;
• le standard définie : les méthodes de communication sur le réseau, mais aussi les fonctionnement des applications ;
• l’ensemble des produits sont certifiés par l’Alliance ZigBee et soutenus par de nombreuses entreprises industriels ;

Ce qui est intéressant, c’est que le standard définit un ensemble de caractéristiques pour un équipement.
Regroupé sous forme de famille :

• ZigBee Smart Energy ;
• ZigBee Remote Control ;
• ZigBee Home Automation ;
• ZigBee Health Care, non disponible;
• ZigBee Building Automation, pas encore définie ;
• ZigBee Telecommunication Services, non encore définie.

Domaines d’application du protocole

Les domaines d’applications du protocole sont les suivants :

• la gestion de l’énergie et les réseaux de distribution d’électricité « intelligent » ;
• la médecine, avec le suivi des indicateurs physiologiques sur le long terme pour les maladies chroniques.
• Les réseaux de capteurs en général : WSN ;
• Les télécommandes, le protocole est amené à remplacer les télécommandes infrarouge à moyen terme.
• La domotique, pour le contrôle et la gestion des appareils dans une maison ;
• La localisation en temps réel ;
• Et enfin la robotique, pour le contrôle à distance ;

La promesse du standard

Les équipements qui respectent le standard et sont certifiés par l’Alliance ZigBee sont théoriquement interchangeable et peuvent communiquer ensemble.

Cela signifie, qu’il est possible d’allumer à l’aide d’une télécommande de marque A, une douille d’ampoule de marque B et un lecteur de DVD de marque C.

Cela parait trivial dit comme cela, mais dans l’état actuel de développement de la domotique, cela releve du miracle …

Même, s’il existe des protocoles propriétaires pour faire cela, il est nécessaire de vendre son âme à un constructeur (Vendor lock-in garantie sur facture ;-) ) ou bien mettre en place des protocoles de Middleware comme xPL et une belle galaxie de protocoles hétérogènes. (cf. le schéma de ma petite installation perso ;-) ).

La gestion des binding

La couche applicatif du standard ZigBee, inclut une possibilité très intéressante pour la domotique : le binding.

L’idée est de relier deux équipements du réseau de manière automatique et transparente pour l’utilisateur.

L’un des meilleur exemple pour comprendre est celui d’une ampoule et un d’un interrupteur.

Lorsque l’utilisateur active physiquement le binding, à l’aide d’un bouton par exemple.

Les deux devices se mettent en relation avec le coordinateur du réseau, qui détermine si oui ou non les profils applicatifs sont compatibles et de les lier.

Ce qui permet aux équipements d’être liés automatiquement et il n’est pas nécessaire de configurer les adresses des équipements, etc…

L’état actuel de la certification

Pour l’instant, il y a peu d’équipements qui sont certifiés par l’Alliance :

• ZigBee Smart Energy Certified Products ;
• ZigBee Home Automation Certified Products.

Mais on trouve pas mal de vendeurs d’autres produits que ne sont pas forcement entièrement certifiés mais qui respectent la partie communication du standard.

Problématique du sans-fils

Comme toutes technologies sans-fils, elle présente quelques problématiques particulières :

La source d’énergie

Bien que le module ZigBee nécessite très peu d’énergie pour fonctionner (20mA pour émettre une trame sur le réseau), se pose la question de la source d’énergie.

Lorsque celle-ci est fournie par une pile cela pose de problématique de :

• fiabilité / qualité de la source d’énergie ;
• la nécessité de remplacer régulièrement la source d’énergie ;
• la nécessité de mettre en place un dispositif pour notifier l’utilisateur du statut de la pile.

La sécurité

La sécurité du standard ZigBee repose tout d’abord, sur la sécurité du protocole de communication IEEE 802.15.4. Pour mieux comprendre les méthodes de sécurisation mises en place par le protocole, vous pouvez lire cet article de vulgarisation : Security in 802.15.4 and ZigBee networks ; ou bien cet excellent papier Security Considerations for IEEE 802.15.4 Networks. Mais dans ce domaine, rien de nouveau, ce sont toujours les mêmes principes qui s’appliquent, à savoir :

• Plus la puce dispose de puissance et plus le niveau de chiffrement est fort (au maximum AES128 pour ZigBee) ;
• La qualité des composants et du générateur de nombre aléatoire ( merci de ne pas utiliser le PID du programme ;-) ) ;
• La qualité de l’implémentation du code de chiffrement.

Bref, vous vous doutez bien que les modules ZigBee qui seront vendus au grand publique ne seront pas d’un niveau de sécurité militaire et n’embarqueront sûrement pas pas un compteur Geiger comme source d’entropie ;-)

D’autant plus que le standard n’impose pas forcement un niveau de chiffrement fort à tous les profils applicatifs.

Robotique

Pour la robotique, il n’existe pas de profil dans le standard, mais la plupart des amateurs dans le domaine ont déjà compris les nombreux intérêts de ZigBee et on voit de plus en plus d’interfaces apparaître (Bioloid, WowWee, etc… )

Logiciels libres

Du coté des logiciels libres, nous avons :

• Un projet mort : ZigBuzz ;
• Le projet IEEE802.15.4/ZigBee Stack for Linux, dont l’objectif est l’intégration de la pile ZigBee dans le noyau Linux, commiter dans la version 2.6.30-rc7 ;
• Le projet FreakZ, dont l’objectif est l’implémentation du pile ZigBee libre pour l’embarque ;

Malheureusement, il y a une incompatibilité entre la licence des spécifications du standard ZigBee et la licence GPL. en effet celle-ci ne prend pas en compte un usage non commercial.

Pour plus de détails sur ce point : Zigbee, Linux, and the GPL.

Néanmoins, le code du protocole IEEE 802.15.4 est déjà le noyau et bénéficie d’un niveau de protection ;-)

Matériel

Le matériel ZigBee disponible se découpe en plusieurs familles de la plus simple à la plus complexe :

Émetteur-récepteur

Les principaux constructeurs d’émetteur-récepteur sont Texas instruments et Freescale.

Puce

Les puces prennent en charge la norme IEEE 802.15.4, elles sont produites par : Ember, Jennic, Texas instruments et Freescale.

Modules

Les modules prennent en charge le standard ZigBee et sont produites par : Digi, One-RF, Telegesis, Meshnetrics, Radiocrafts…

Produit fini

• Tritech : dongles USB et routeurs Ethernet/Zigbee ;
• Digi : passerelles RS232/485, USB, Ethernet, GPIO, routeurs autonomes
• Telegesis : dongles USB et CF, routeurs autonomes et Ethernet
• Alektrona : gateway ethernet / zigbee;
• Libelium : capteurs et routeurs multi-protocoles Wifi, Bluetooth, GPRS et GPS ;
• Des shields pour la carte Arduino et ses dérivées.

Offre packagée

Pour les produits packagés, il existe les solutions suivantes :

• Control4 : gamme de produits domotiques ;
• AlerteMe : système de suivi de la consommation électrique et alarme.

Déploiements importants de ces technologies

Il y a pas mal de déploiements de ces technologies aux USA dans le cadre des réseau de distribution d’électricité « intelligent » en Californie et au Texas principalement.

En Europe, le ville de Gothenburg en Suède a déployé un réseau de 90 000 compteurs intelligents.

En France, le déploiement est encore à l’état de recherche avec le projet SensLab, le projet de localisation fait par Orfidée pour la Marine Nationale.

Et d’autres projets couverts par des accords de non divulgation ;-)

Références

Voici quelques références pour approfondir le sujet :

• Le site de la ZigBee Alliance ;
• le site sensor-networks ;
• l’article de Sensor-networks sur les différence entre 802.15.4 vs ZigBee ;
• le site du projet IEEE802.15.4/ZigBee Stack for Linux ;

Conclusion

Voilà, ceci est une petite présentation standard ZigBee, que j’ai voulu la plus succincte possible. Le sujet étant très vaste et passionnant. J’ai forcement fait des erreurs et oublié des références. Merci de m’en faire part par mail ou via les commentaires.

J’ai configuré mon instance de Nagios pour recevoir une notification par téléphone en cas d’incident. (déclenchement d’une alarme ou d’un détecteur d’eau / fumée dans mon installation domotique).

Ce billet décrit comment mettre en place un système de la notification par téléphone avec Nagios.

Pré-requis

Vous avez besoin des composants suivants :

• Une distribution Debian GNU/Linux ;
• Une installation fonctionnelle de Nagios ;
• Une PABX IP avec le support du protocole SIP, comme Asterisk ;
• Un système de Synthèse vocale fonctionnelle, comme eSpeak + MBROLA ;
• Un client SIP en ligne de commande comme PJSUA.

Installation

Le client SIP en ligne de commande PJSUA n’est pas disponible dans les paquets du projet Debian.
Il est donc nécessaire de l’installer manuellement à l’aide du classique : configure, make, make install.
La procédure est décrite dans ce billet : Un client SIP en ligne de commande.

Pour l’installation du système de synthèse vocale, vous pouvez vous référer à mon précèdent billet sur le sujet : Text-to-Speech avec eSpeak, MBROLA et Speech Dispatcher.

Configuration

Vous devez créer un compte SIP pour Nagios sur votre PABX et tester que l’enregistrement est fonctionnel.

Pour cela vous avez besoin d’un fichier de configuration spécifique à Nagios pour PJSUA, dans /etc/nagios/sip.cfg par exemple :

--id sip:nagios@pabx.csquad.lan
--registrar sip:pabx.csquad.lan
--realm *
--username nagios
--password secret


Vous pouvez ensuite tester l’enregistrement en ligne de commande :
$ pjsua --config-file /etc/nagios/sip.cfg
...
11:17:05.376 pjsua_acc.c sip:nagios@pabx.csquad.lan: registration success, status=200 (OK), will re-register in 300 seconds

Un appel de test :
$ pjsua --config-file /etc/nagios/sip.cfg --null-audio sip:secretariat@pabx.csquad.lan

Ensuite un appel de test audio avec un message :
$ espeak -v mb/mb-fr1 "E.T. téléphone maison" | /usr/local/bin/mbrola /usr/share/mbrola/fr1/fr1 - test.wav
$ pjsua --config-file /etc/nagios/sip.cfg --play-file=test.wav --auto-play --null-audio sip:secretariat@pabx.csquad.lan
$ rm -f test.wav


On met le tout dans un petit script expect pour prendre en charge la déconnections de manière polie :

#!/usr/bin/expect --
set timeout 45
set addr [lindex $argv 0]
set text [lindex $argv 1]
exec /usr/bin/espeak -v mb/mb-fr1 $text | /usr/local/bin/mbrola /usr/share/mbrola/fr1/fr1 - /tmp/phone-call.wav;
spawn /usr/local/bin/pjsua --app-log-level=3 --config-file /etc/nagios/sip.cfg --play-file /tmp/phone-call.wav --auto-play --null-audio --max-calls 1 sip:$addr
expect {
"DISCONNCTD" {
exit
}
timeout {
send "h\n"
exit
}
eof {
exit
}
}

Et voilà ;-)

Il ne nous reste plus qu’à configurer ce type de notification dans Nagios.
Pour cela, il faut modifier le fichier contacts.cfg :
# 'nagios-phone' contact definition
define contact{
contact_name nagios-phone
alias Nagios Admin via Phone
service_notification_period 24x7 ; mouahahahahahaha
host_notification_period 24x7 ; moiahahahahahahah
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-phone
host_notification_commands host-notify-by-phone
email sip:secretariat@pabx.csquad.lan
}

Puis le fichier misccommands.cfg :
# 'notify-by-phone' personnal command definition
define command{
command_name notify-by-phone
command_line /usr/local/bin/phone-call.sh $CONTACTEMAIL$ "$NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$"
}
# 'host-notify-by-phone' personnal command definition
define command{
command_name host-notify-by-phone
command_line /usr/local/bin/phone-call.sh $CONTACTEMAIL$ "Host $HOSTSTATE$ alert for $HOSTNAME$!"
}

Ensuite, vous pouvez définir nagios-phone comme un contact pour des services ou hosts.

Il faut aussi modifier la valeur de la variable notification_timeout dans le fichier de configuration nagios.cfg, pour avoir le temps de décrocher le téléphone et d’en tendre le message.

Conclusion

Vous n’avez plus aucune excuse pour ne pas brancher vos esclaves^Wéquipe d’administrateurs systèmes directement sur le système de surveillance de vos serveurs ;-)

Plus sérieusement, la notification par téléphone est une méthode très intrusive. Il est nécessaire de décrocher le téléphone. Il faut donc l’utiliser avec parcimonie.

Après la lecture de plusieurs livres de Jean-Marc Jancovici (merci Nicolas ;-) ),
je me suis intéressé à la concentration de dioxyde de carbone dans l’air.
En effet, cette concentration afflue directement sur le climat de la planète.
Je me suis donc mis à la recherche d’un capteur de CO2 abordable pour ma station météo.

La recherche du capteur

Mes critères pour le capteur de dioxyde de carbone de ma station météo étaient les suivants : communicant avec le pc à l’aide d’un protocole standard ; fonctionnant sous Debian GNU/Linux ; petit budget, moins de 150 euros. Après plusieurs jours recherche, je me suis retrouvé le bec dans l’eau.

En effet, ce genre de capteur est visiblement réservé aux équipements scientifiques et la plupart des devis que j’ai réussi à obtenir sont bien au dessus de mon budget.
Mais dernièrement, j’ai trouvé un revendeur de matériel 1-wire en Suède : m.nu.
Celui-ci propose un capteur de CO2 abordable : CO2-meter.
Ce capteur est basé sur le capteur K30 de chez SenseAir et un DS2450.
Ce capteur peut être utilisé en intérieur ou bien à l’extérieur.
Par contre dans le cas d’une utilisation extérieur, il faut le protéger des précipitations.

Matériel

Pour faire fonctionner le capteur vous avez besoin des composants suivants :

Produit	Prix
CO2-meter	139,93€
5V Power injectors	19,96€
Alimentation 5V	14,95€

Exploitation du capteur

Avec OWFS

Une fois le capteur branché sur le réseau 1-wire, il est vu par owfs :

$ tree /mnt/owfs/20.C17E0D000000
/mnt/owfs/20.C17E0D000000
|-- PIO.A
|-- PIO.ALL
|-- PIO.B
|-- PIO.C
|-- PIO.D
|-- address
...
|-- type
|-- volt.A
|-- volt.ALL
|-- volt.B
|-- volt.C
|-- volt.D
|-- volt2.A
|-- volt2.ALL
|-- volt2.B
|-- volt2.C
`-- volt2.D
3 directories, 74 files
$ cat /mnt/owfs/20.C17E0D000000/type
DS2450%

Les informations intéressantes se trouvent dans les fichiers :

• volt.A : sortie du capteur de CO^2, donne la concentration de CO2 en ppm. Il faut multiplier la valeur par 1000. Ex: 0.772277 * 1000 = 772 ppm ;
• volt.B : statut du capteur de CO^2, le voltage doit être au alentour de 3.2V ;
• volt.D : voltage du DS2450S, doit être aux alentours de 5V ;

Avec Munin

Pour faire un graphique de la concentration de dioxyde de carbone, j’utilise munin et un petit plugin fait maison :

$ svn co http://svn.csquad.org/owcarbondioxide
A owcarbondioxide/owcarbondioxide
...
$ chmod a+x owcarbondioxide/owcarbondioxide
# mv owcarbondioxide/owcarbondioxide /usr/share/munin/plugins/
# ln -s /usr/share/munin/plugins/owcarbondioxide /etc/munin/plugins/owcarbondioxide
$ /etc/munin/plugins/owcarbondioxide config
graph_title Carbon dioxide 1-wire sensor
graph_args --base 1000 --lower-limit 0 --upper-limit 5000
graph_vlabel Carbon dioxide in ppm
graph_category sensors
graph_info This graph shows the Carbon dioxide on the one-wire network.
Chambre.label Chambre
$ /etc/munin/plugins/owcarbondioxide get
Chambre.value 786.184


Vous devriez obtenir ce type de graphique :

Références

Voici quelques références intéressantes sur le sujet :

• [en] Carbon dioxide in Earth’s atmosphere ;
• [fr] Quels sont les gaz à effet de serre ? ;
• [en] Carbon Dioxide (CO2).