Problématique

Lorsque le système de climatisation d’une salle serveur s’arrête alors la température monte dangereusement, et après avoir perdu quelques routeurs coûtants plusieurs milliers d’euros , nous avons décidé d’agir et mettre en place un système de surveillance.

N’ayant pas trouvé de système / solution comparable dans le commerce.
Nous avons donc décidé de suivre les conseils de mon cousin Piotr Adamski.

Solution

Nous avons donc mis en place la solution suivante :

Composants

Les composants matériels suivants sont nécessaire :

• Un compteur avec sortie impulsion sur le circuit d’eau ;
• Compteur d’impulsion sur bus 1-Wire ;
• Serveur Ethernet 1-wire ;
• Quelques Connecteurs 3M™ Scotchlok™.

L’ensemble des composants sont disponibles en France, chez Planet Domotique et sont produits par Embedded DATA Systems.

Pour la partie logiciel vous avez plusieurs choix possibles pour :

• Faire des graphiques de la consommation d’eau à l’aide du protocole SNMP avec Munin ou Cacti ;
• Surveiller l’écoulement de l’eau à l’aide de Nagios ou Monit ;

Budget

• 40 euros TTC pour le compteur d’eau ;
• 56 euros TTC pour le compteur d’impulsion ;
• 130 euros TTC pour le serveur Ethernet / 1-wire ;
• 100-200 euros TTC pour l’installation du compteur par un plombier ;

Total : de 326 à 426 euros TTC

Photos du montage

Voici quelques photos du montage en action :

Surveillance avec Monit

Le script de surveillance pour Monit est disponible sur github :

Simple water watchdog script for OW-SERVER / DS2423 and Monit

Il se lance via monit de la manière suivante :

check process water_watchdog with pidfile water_watchdog.pid
    	start program  = water_watchdog

check file water_watchdog.status with path water_watchdog.status
	ignore match OK
	if match ^KO then alert

Il faut ajouter le chemin absolut aux noms de fichiers.

Le script de surveillance fonctionne sur le principe suivant :

Un lanceur de deamon water_watchdog, lance le script water_watchdog.pl et le surveille en permanence.

Celui-ci interroge toutes les 60 secondes la compteur d’eau et vérifie que la quantité d’eau consommée a bien augmentée dans l’intervalle.

Écrit le résultat dans le fichier water_watchdog.status qui est surveillé par monit.

En cas de coupure d’eau, le nombre de litres d’eau consommée n’évolue pas et une alerte monit est lancée.

Le système est très fiable, mais il est nécessaire de le paramétrer en fonction du débit de votre installation.
Voici ma configuration pour 10 000 l/j :

• FLOW_ALERT_LOWER_LIMIT = 1
• RATE = 60

Conclusion

Le script fonctionne en production depuis plusieurs semaines. Il permet d’intervenir très rapidement en cas de coupure et donc de sauver la vie de quelques serveurs

Références

• OW-SERVER – 1-Wire to Ethernet Server ;
• Une autre exemple de Suivi de la Consommation D’Eau ;
• Le logiciel Monit ;
• Le compteur d’impulsion : DS2423 chez Maxim ;
• La PME de mon cousin.

EDF R&D, Tinker London et l’ Université de Lancaster ont lancer le projet HomeSense.

L’objectif de celui-ci, est de mettre à disposition de plusieurs maisons réparties en Europe un kit de développement électronique basé sur la carte Arduino et un expert référent.

L’idée de projet est d’accompagner des personnes sans compétences particulières dans le domaine de l’électronique et la domotique dans une démarche de maison intelligente.

La démarche m’a beaucoup plus et j’ai donc décidé de participer au projet pour les raisons suivantes :

• Je m’intéresse un peu à la domotique ;
• Le matériel libre me passionne ;
• J’aime beaucoup le rapprochement interdisciplinaire créé par la communauté Arduino, en effet, ce n’est pas simplement encore une carte de prototypage électronique rapide créée par l’industrie, mais bel et bien un rapprochement entre les “gens” du hardware, du software et du design ;
• Cela me fait une excuse officielle pour bidouiller

Le Kit

L’Université de Lancaster a mis au point un Kit électronique basé sur la carte Arduino, il s’agit d’un kit sans soudure, un peu comme dans une boite de LEGO, l’ensemble des connections se font très simplement. Le kit est très semblable à l’Electronic Brick de SeeedStudio

Le kit contient les briques suivantes :

• carte Arduino ;
• alimentation ;
• “sensor shield” ;
• un émulateur de clavier ;
• des câbles ;
• des boutons poussoirs ;
• des capteurs de pression ;
• des potentiomètres ;
• des LEDs ;
• servomoteur ;
• un écran LCD.

Le kit est fourni avec des nombreux exemples pour exploiter ces composants.

Les Projets

Durant les trois mois du projet, nous nous sommes mis d’accord avec Maëlle pour réaliser des projets suivants :

• La gestion des différentes radios de l’appartement pour “Écoutez la différence”
• Le système d’illumination de l’appartement.

Nous documenterons notre démarche et l’avancement des travaux sur les différents blogs.

Références

Voici quelques références intéressantes :

• La page du projet Homesense ;
• Les slides de la présentation du projet à la Cantine ;
• Le flux photo Flickr du projet ;
• La philosophie de recherche vue par Tinker London : Doing research, the open way.

Dans ce billet, je vais essayer d’expliquer le rôle que pourrait jouer les technologies domotique dans l’économie d’énergie.

Je vais décrire mes expérimentations et quelques ressources intéressantes sur le sujet.

Le suivi de la consommation en temps réel

C’est l’étape la plus simple à mettre en oeuvre, elle consiste à mettre en place un système de suivi de la consommation qui affiche l’information en temps réel.

Il existe de nombreuses techniques pour mesurer :

• l’électricité : à l’aide du dispositif téléinfo, de pinces ampermétriques ou bien d’un watt mètre ;
• l’eau : à l’aide d’un compteur d’eau avec sortie à impulsion ;
• le gaz : à l’aide des mêmes techniques que l’eau ;

Le rôle de la mesure

J’ai tout d’abord été très septique sur l’utilité de ces techniques et à part faire de jolis graphiques et des calculs sur ces données, cela ne me semblait pas être vraiment utile.

Pourtant, le fait d’afficher la consommation en temps réel aux utilisateurs permet d’influencer son comportement.

En effet, le fait qu’un appareil consomme de l’énergie n’est pas perceptible par un humain et il est donc nécessaire de mettre en place des outils de mesure.

L’affichage en temps réel permet de notifier les utilisateurs sur la quantité d’énergie consommée et le coût de celle-ci;
ce qui influence directement leur comportement et permet de réaliser des économies tangibles et chiffrables.

D’après une étude de l’université d’Oxford , l’affichage en temps réel de la consommation permet de la faire baisser de 7 à 15%. Pour un investissement de départ faible. ( voir la liste des solutions de Mesure de consommation électrique )

Pour ma part, le Current cost m’a permis de réduire ma facture d’électricité de 10% sur un an.

Optimisations possibles

Dans un second temps, il faut s’attaquer aux pertes d’énergie et optimiser au maximum son usage.

Électricité

Dans une maison, comme chez vous, il y a de nombreux appareils inutiles qui consomment de l’énergie électrique sans être utilisés : les veilles, les transformateurs, etc…

La plupart des veilles sans trompeuses.En effet, certains appareils électriques mal concus consomment presque autant d’énergie en veille qu’en fonctionnement normal.
Comme par exemple, les “Box Internet”.

Il est donc nécessaire d’éteindre complètement ces appareils lorsque vous ne les utilisez pas.

Pour ce faire, les moyens les plus simple sont les multiprises de type maître-esclave qui fonctionnent à l’aide du port USB, d’un système de seuil de consommation ou bien à l’aide d’un interrupteur.

Pour les autres appareils, il est aussi possible d’utiliser des relais (X10, Plugwise, PLCBUS, EasyDAQ, 1-wire, etc… ) pour couper à distance un appareil, durant les périodes ou ils ne doivent pas être utilisés.

L’idée est de coupler ces systèmes avec un ordonnanceur de tâches (tel que Job scheduler, fcron, cron… ) pour prendre en charge l’effacement des différents appareils de manière cohérente.

Vous pouvez ensuite optimiser votre consommation en fonction de facteurs extérieurs tels que :

• le type d’abonnement du fournisseur d’énergie (EDF Tempo, Heure Creuses, etc… ) ;
• le nombre de personnes présent dans habitat (RFID is your friend) ;
• les demandes de votre fournisseur d’énergie ( SmartGrid : Peak curtailment/levelling ) ;
• les prévisions météo ;
• votre propre production d’énergie ;

Eau et Gaz

Pour les liquides, il existe des solutions de vannes équipées de Servomoteur, permettant de couper l’eau ou le gaz en cas de fuite.

Domotique = Informatique

Comme la domotique consiste à utiliser l’informatique au sein de habitat, il est donc nécessaire de mettre en place des services qui fonctionnent en permanence sans trop consommer d’énergie.

Les choix les plus importants dans ce domaine sont la plate-forme matériel et logiciel.
Pour ceux qui ont opté pour une solution basée sur GNU/Linux, il existe de très nombreuses solutions embarquées qui allient puissance de calcul et faible consommation.

Pour les autres, le serveur Microsoft Windows, peut toujours servir de radiateur
Et le Mac de lampe de chevet

Futur

Comme vous pouvez le constater, il existe de nombreuses solutions pour réduire sa consommation d’énergie à l’aide de la domotique. La plupart sont faciles à mettre en place et nécessite un faible investissement. Il est clair que les solutions de compteurs intelligents vont se démocratiser et ouvrir la voix au réseau électrique intelligent. Ces réseaux doivent normalement rester à la porte de votre appartement, car ils présentent un risque important pour la vie privé.

En effet, le marché du suivi de l’énergie intéresse beaucoup de monde car la simple observation de votre consommation permet de déterminer vos habitudes et la marque de votre frigidaire.

Références

• L’étude “The Effectiveess of Feedback on energy consumption” de l’université d’Oxford ;
• Ask Slashdot: Low-Power Home Linux Server? ;
• Less Watts : saving power with Linux ;
• La technologie des “Smart Grid” est-elle une menace pour la vie privée ? chez 422.
• Des réseaux intelligents pour économiser l’énergie dans Le Figaro ;
• La page sur la Gestion de l’énergie sur le DomoTiki ;
• Le blog Earth2Tech ;
• Présentaton de enPowerMe chez Enerzine.com : une solution capable d’identifier les principales sources de consommation, uniquement à partir de la courbe de charge ;
• Smart Energy and the End of Privacy de Toby Considine ;

Par contre, les LEDs disposent de plus de fonctionnalités que les ampoules classiques.
En effet, en plus d’un bouton d’allumage, vous avez la possibilité de changer la couleur de la lumière, la faire varier dans le temps, modifier son intensité, jouer une séquence, etc…

Avec un nombre de possibilités plus grand, les interfaces de contrôle classique (X10, PLCBUS, etc…) ne suffisent pas.

Il est donc nécessaire de placer un peu plus d’intelligence dans le réseau d’illumination à l’aide du protocole DMX.

Ce protocole est utilisé dans le monde des concerts, des plateaux de télévision et des spectacles.
Néanmoins, il est tout à fait possible de le détourner pour un usage domotique.

Dans ce billet, je vais décrire l’utilisation d’un contrôleur LED RGB DMX et de l’interface OpenDMX de chez ENTTEC, à l’aide du projet OLA sous Debian GNU/Linux.

Principe de fonctionnement

Voici le schéma du montage:

• le PC communique à l’aide du port USB avec un contrôleur DMX ;
• les contrôleurs LEDs mis en série convertissent les ordres en instructions RGB ;

Et voici ce que cela donne :

Matériel

Voici le matériel nécessaire pour un bandeau à LED, le tout fonctionne bien sûr sous Debian GNU/Linux est FOSS Friendly

Pour le câblage, entre le bandeau lumineux et le contrôleur à LED, Il faut couper une extrémité du cable de raccord et la dénuder pour brancher sur le bornier à quatre vis de sortie RGB.

Installation du matériel

Une fois que vous avez branché l’OpenDMX au PC, vous devez voir un convertisseur USB-Serial (UART) à l’aide de lsusb :

$ lsusb
Bus 002 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC


Pour faire fonctionner l’OpenDMX, vous avez besoin du module noyau dmx-usb et d’un environnement de compilation pour les modules. (paquet linux-headers*, etc…).

# cd /usr/src
# git-clone http://www.erwinrol.com/git/dmx_usb_module/
# cd dmx_usb_module
# make
# cp ./dmx_usb.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial
# depmod -a


Comme, l’OpenDMX est un convertisseur USB-Serial, le noyau par défaut le présente comme une interface /dev/ttyUSB.
Il est donc nécessaire de blacklister les modules usbserial dans le fichier /etc/modprobe.d/blacklist, en ajoutant les lignes suivantes :

blacklist usbserial
blacklist usb-serial
blacklist ftdi_sio

Ensuite, ajouter le module dmx_usb dans le fichier /etc/modules et rebooter la machine.
Au reboot, vous devez avoir une interface /dev/dmx0, qu’il faut rendre accessible pour tous les utilisateurs :

# ls -l /dev/dmx0
crw-rw---- 1 root root 180, 192 2010-01-30 00:37 /dev/dmx0
# chmod a+rw /dev/dmx0


Installation du logiciel pour la gestion de la lumière : Open Lighting Architecture (OLA)

Comme, il n’y a pas de paquets Debian disponibles pour ce programme, je vais décrire une procédure d’installation à partir des sources. Ces instructions ont été valider à l’aide de la version 0.7.3 de OLA :

Dépendances

Vous allez avoir besoin des dépendances suivantes pour la compilation :

# apt-get install build-essential uuid-dev libcppunit-dev libgcrypt-dev uuid-dev


Compilation de Protocol Buffers de Google

Vous avez besoin de protobuf, pour la gestion de l’échange de données :

# cd /usr/src
# wget http://protobuf.googlecode.com/files/protobuf-2.3.0.tar.bz2
# tar xjf protobuf-2.3.0.tar.bz2
# cd protobuf-2.3.0
# ./configure ; make ; make install


Compilation de google-ctemplate

Vous avez besoin du système ctemplate :

# cd /usr/src
# wget http://google-ctemplate.googlecode.com/files/ctemplate-0.96.tar.gz
# tar xzf ctemplate-0.96.tar.gz
# cd ctemplate-0.96
# ./configure; make ; make install


Compilation de microhttpd (optionnel)

Vous avez besoin de la libmicrohttpd version > à 0.4 (non disponible dans Debian) pour l’interface web de gestion :

# cd /usr/src
# wget ftp://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-0.4.5.tar.gz
# tar xzf libmicrohttpd-0.4.5.tar.gz
# cd libmicrohttpd-0.4.5
# ./configure; make ; make install


Compilation de OLA

Le projet OLA se découpe en deux parties : un serveur et des clients, dont voici la procédure de compilation. Vous devez remplacer x.y.z, par la version stable la plus récente du programme. (0.7.3 dans mon cas)
Pour le serveur :

# cd /usr/src
# wget http://linux-lighting.googlecode.com/files/ola-x.y.z.tar.gz
# tar xzf ola-x.y.z.tar.gz
# cd ola-x.y.z
# ./configure; make ; make install

Pour le client en C++ :

# cd /usr/src
# wget http://linux-lighting.googlecode.com/files/ola-examples-x.y.x.tar.gz
# tar xzf ola-examples-x.y.z.tar.gz
# cd ola-examples-x.y.z
# ./configure; make ; make install


Lancement d’OLAd

Vous pouvez lancer olad, avec un utilisateur qui dispose des droits de lecture / écriture du /dev/dmx0 :

$ olad -l 3
...

Vous pouvez ensuite vérifier si l’OpenDMX a bien été détecté par le serveur à l’aide du client ola_dev_info :

$ ola_dev_info
...
Device 3: OpenDmx USB Device
port 0, OUT Open Dmx at /dev/dmx0
...


Et si vouz avez compilé libmicrohttpd, vous devez pouvoir accèder à l’interface web du daemon, sur le port 9090 :

Test et validation du bon fonctionnement

Avant de pouvoir manipuler les LEDs, il est nécessaire d’attribuer ununivers au contrôleur OpenDMX à l’aide de la commande ola_patch :

$ ola_patch -d 3 -p 0 -u 0


Ensuite vous pouvez lancer dans deux terminaux les commandes ola_dmxmonitor et ola_dmxconsole.
La première permet de suivre le statut des diffèrents composants et la seconde permet de les controler à l’aide d’un interface graphique en curses.

L’identifiant du contrôleur LED RGB sur le réseau DMX, est fonction de la valeur prise par le petit switch qui se situe sur celui-ci.
Et se découpe de la manière suivante :

• Rouge = valeur du switch ;
• Vert = valeur du switch + 1 ;
• Bleu = valeur du switch + 2.

Vous pouvez faire varier les trois valeurs pour obtenir les diffèrentes couleurs possibles.

Allez plus loin avec l’Open Lighting Architecture (OLA)

OLA supporte de nombreux contrôleurs USB et Ethernet.
Il dispose d’une API Client C++ et Python, ce qui rend son intégration possible et facile dans d’autres projets et offre de nombreuses possiblités.

La diffusion d’informations à l’aide de la lumière d’ambiance et ses possiblités

L’idée de pouvoir contrôler l’intensité et la couleur d’un bandeau à LED qui se situe dans n’importe quel endroit de la maison, offre des possiblités interessantes en matière de diffusion d’informations.

En effet, la lumière permet de diffuser l’information de manière non intrusive.
Voici quelques exemples des possibilités offertes :

• comme la lampe DAL de Violet, se connecter à l’Internet pour exploiter des ressources ;
• Pour ceux qui disposent de l’option Tempo d’EDF, il est possible de diffuser la couleur du jour ;
• Modifier l’Intensité lumineuse en fonction de nombreux paramètres : tempèrature, l’ensoleillement, nombre de personnes présentes dans la pièces, activation d’une alarme, réveil du bébé, etc…

Ce sont quelques exemples des possiblités offertes. Pour le reste vous pouvez faire marcher votre imagination pour créer des nouvelles manières d’inter-agir avec les machines et cette Intelligence ambiante.

Réferences

Voici mes réferences :

• Le Wiki d’OpenDMX.net ;
• La page OLA on Linux du Wiki ;
• Le site du constructeur ENTTEC ;
• Le tutorial LLA, OpenDMX USB and Q Light Controller Tutorial ;
• L’article Comprendre: Le DMX, chez SONOMag ;
• Hippy’s Open DMX USB Resources ;
• Le site du projet DMX4Linux ;
• La présentation du DMX, chez Automated Home.

Conclusion

Le protocole DMX est ancien et souffre de nombreux défaults, mais il présente encore de nombreux avantages tels que :

• la disponiblité de nombreux équipements à prix abordable ;
• sa simplicité.

Il faut noter qu’il existe une alternative plus récente au protocole DMX : Digital Addressable Lighting Interface (DALI).

Il est aussi possible de remplacer le contôleur OpenDMX par une carte Arduino, comme décrit ici.

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.

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 :

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).

Setup

The setup is very simple on Debian GNU/Linux, at first you need the Net::Pachube module :
$ wget http://search.cpan.org/CPAN/authors/id/B/BE/BEANZ/Net-Pachube-0.01.tar.gz
$ tar xzf Net-Pachube-0.01.tar.gz
$ cd Net-Pachube-0.01
$ perl Makefile.PL
$ make
...
# make install

Note: the dh-make-perl method does not work, with this package ;-(

Then you can grab, my xpl-pachube script :

$ svn co http://svn.csquad.org/xpl-pachube/
..
# chmod +x xpl-pachube/xpl-pachube
# mv xpl-pachube/xpl-pachube /usr/local/bin


Run

You can start the xpl-pachube script in verbose this way :

$ xpl-pachube -key 52b37888404598851de -verbose -feed_id 1934 class=sensor device=cc128.01189.0.1


You need to change the -key and -feed_id arguments.

That’s all folks!

Définition du besoin

L’accumulation des télécommandes sur mon installation domotique, fait chuter mon WAF de manière dramatique.
En effet, pour regarder une chaîne de télévision ou allumer la lumière.
Il est nécessaire d’utiliser deux ou trois télécommandes différentes.
Naviguer dans des interfaces, etc…
Bref, pour des technologies donc l’objectif est d’améliorer la qualité de vie et rendre les taches quotidienne plus facile, j’avais un gros problème
Après un petite discussion et une mise au point avec ma moitié, j’ai réussi à vendre la solution de contrôle par la voix.
Belle connerie me voilà parti dans un domaine que je ne connais pas

Première Approche

Je lance une boue à la mer sur le forum “toute la domotique”.

Visiblement, je ne suis pas le seul à chercher ce genre de fonctionnalité. Actuellement, nous avons dans le domaine :

• l’abominable HomeSeer qui fonctionne très mal en Anglais à l’aide de l’interface de reconnaissance vocale inclue dans Microsoft Windows et la SAPI ;
• Rien de spécifique à la domotique sous GNU/Linux, mais une belle galaxie de programmes dans le domaine.

Le choix du microphone

Ma petite dame voulais parler librement sans aucune contrainte et il n’étais pas question de l’équiper d’un microphone.
J’ai donc cherché une solution qui permet de capter la parole dans une pièce sans microphone sur la personne.
La solution magique s’appelle la technique du Microphone array.
Le principe est très simple, mettre en commun plusieurs microphones reliés à un DSP qui permet de faire le traitement du signal en fonction de l’orientation physique des microphones.
J’ai donc proposé de mettre en place chez moi le LOUD (non ce n’est pas un radiateur ).
Bon vous vous doutez bien que lorsque j’ai proposé la solution du LOUD, j’ai faillit passer par la fenêtre

Heureusement, il existe des solutions plus simples telles que le Voice Tracker de chez Acoustic Magic. Celui-ci permet de capter la parole dans une pièce, retraite le signal et permet d’obtenir sur une prise Jack classique la voix et rien que la voix dans une pièce. Magique

Je peux parler le dos tourner au microphone dans une pièce de 20m^2 et l’ordinateur capte ma voix de manière impressionnante

Le logiciel de reconnaissance vocale

Il y a principalement deux solutions dans le domaine sous GNU/Linux :

• Le projet CMU Sphinx avec PocketSphinx, Sphinx-[234], etc…
• Julius, Open-Source Large Vocabulary CSR Engine Julius.

Sur ces deux moteurs de reconnaissance vocale, reposent de nombreux Dialog Manager, qui permettent d’exploiter le moteurs pour faire de la téléphonie, de contrôle vocale, etc…

Ma méthode

Soyons claire, je ne suis pas un expert en reconnaissance vocale et ce domaine est vraiment très difficile d’accès et nécessite la compréhension de nombreuses notions.
J’ai donc adopté la technique EPITECH : c’est à dire faire en sorte que cela fonctionne. ( sans comprendre tout le contexte )

Un bon informaticien est un informaticien feignant

Pour faire fonctionner Julius, il est nécessaire de lire à haute voix de nombreux mots pour enregistrer les différents phonèmes qui les composent. Afin de créer un Modèle de Markov caché exploitable par le logiciel.
Voici donc comment je m’y suis pris pour éviter cette phase fastidieuse du projet.

Utilisation d’un logiciel de synthèse vocale

1 ère approche une solution assez “laide“, qui consiste à faire lire ces mots par un logiciel de synthèse vocale comme eSpeak. Mais le résultat n’était pas très bon.

Utilisation d’une collection d’enregistrement audio

J’ai par la suite découvert le projet Shtooka, qui est une collection audio libre de mots français.
Tous les termes liés à la domotique ne sont pas disponible dans le projet mais il est très facile d’ajouter ces termes à sa base de données locale.

Conversion texte vers Phonème

Une des étapes de l’apprentissage de Julius est la conversion du texte en Phonèmes, pour résoudre ce problème, j’ai utilisé l’option -X de eSpeak dont voici un exemple de sortie :

$espeak -v fr -q -X "lumière"
Translate 'lumière'
  1     l        [l]

  1     u        [y]

  1     m        [m]

 21     i (A     [j]
  1     i        [i]

 43     è       [E]

  1     r        [r]

 22     e (_     []
  1     e        [@]

 lymj'Er

Un peu de glu

Pour faire fonctionner tout ces éléments ensemble, je me suis fait un script Perl (très sale pour le moment) permettant de réaliser automatiquement toutes ces étapes :

• analyse des questions posées au robot ;
• la conversion des mots en phonèmes ;
• la diction des mots ;
• la création du modèle accoustique.

Il s’agit de l’automatisation de toutes les étapes de la création d’un modèle acoustique du projet VoxForge.

Les travaux en cours

Mon projet est disponible à cette adresse : Alfred
Il est en cours de développement mais pour l’instant il est possible de donner des ordres simples.

J’utilise RiveScript pour la définition des tâches et de la conversation. Ce langage de chatbot est plus puissant que AIML. Car il permet d’inclure du code Perl assez puissant dans le code de la conversation. Voici un exemple :
$ more lib/Alfred/languages/en/x10.rs
+ switch * on
- do you want me to switch <star> on?
+ yes
% do you want me to switch * on
- <call>xpl_x10_send_on <botstar></botstar></call>
$more lib/Alfred/modules/x10.rs
> object xpl_x10_send_on perl
my ($obj,$method,@args) = @_;
$obj->{'xpl'}->send(
message_type => 'xpl-cmnd', class => 'x10.basic',
body => { command => 'on', device => 'a3' });
< object


Un petit appel à contribution

J'aurais gagné énormément de temps si le projet VoxForge avait reçu plus de contribution de la part des utilisateurs francophones.

En effet, il n'y a pas assez de contribution pour pouvoir faire un modèle accoustique en Français.
Cela permettra de disposer d'un système de reconnaissance vocale libre en Français.
Ce qui intéresse beaucoup de monde à mon avis
C'est donc un petit appel à contribution aux projets VoxForge et Shtooka.

Références intéressantes

• Ensemble de liens intéressants sur le sujet de la reconnaissance vocale sous GNU/Linux.
• Un exemple d'utilisation de Julius : Querying a database using open source voice control software ;
• Les tutoriels du projet VoxForge ;
• Le Julius Book.

Je viens de finir la lecture de l’étude suivante :
A Spotlight on Security and Privacy Risks with Future Household Robots: Attacks and Lessons.

Celui-ci parle des risques et de la sécurité liés aux robots ménagers (je crois que c’est pas le bon lien ).

Pour résumer rapidement l’article, celui-ci a évalué le niveau de sécurité des robots : Rovio, Spykee et RoboSapien V2.
Le résultat est une véritable catastrophe d’un point de vue de la sécurité :

• des connexions sans fil, pas ou faiblement sécurisées ;
• non chiffrement des informations d’authentification ;
• apparition de nouvelles attaques.

Mais ce dont j’aimerais vous parler est l’idée que soulève les auteurs au début du document:

both thoses that we encountered and those that we foresee can be attributed partly to the fact that the home is becoming “accidentally” smart and that there is no dedicated, trained system administrator for the home environment.

Je vais dans ce billet illustré cette idée et me permettre de réfléchir à haute voix.

The incoming smart^Wobject

Ils sont minions, petits ou grands, utiles ou futiles.
ils s’appellent Roomba, Nabaztag ou Freebox.
Ils sont arrivés dans nos maisons progressivement.
Et les meilleurs pointent bientôt leur nez
Ils mettent en place progressivement le paradigme de l’Internet des objets et de l’Intelligence ambiante.

Early adopters

La cible 1ére de ses technologies sont les Geek, ce sont les seuls capables d’adopter ces technologies, d’accepter les problèmes liés à leur jeune âge et de les exploiter.

Les Geeks ont généralement les compétences nécessaires pour comprendre le fonctionnement de ces nouveaux objets.

Mainstream and Mrs. Michu

Ces objets arrivent progressivement chez Madame Michu et c’est la que cela devient intéressant.

Freebox

Commençons par la Freebox, voulez-vous. Car je trouve que c’est l un des meilleurs exemples d’intelligence accidentelle.

Des millions de foyers français ont reçus avec leur abonnement Internet une machin-box.
Celle-ci est équipée d’une liaison Wi-Fi qui n’est pas sécurisée, que cela soit en WEP ou WPA.
Du coup ces milliers de foyer se retrouvent propulsés dans le rôle d’un administrateur réseau.
Et s’ils n’ont pas les compétences nécessaires et que leur connexion est usurpée, ils se trouveront privé de leur droit d’accès Internet grâce à la loi HADOPI.

Roomba

Le robot aspirateur Roomba, dispose d’une forte puissance et il est capable de faire des dégâts important dans une maison si la pièce n’est pas préparée pour son passage.
Le mien dispose en plus d’une connexion Bluetooth dont je doute sérieusement du niveau de sécurité compte-tenu de la complexité du protocole.
Avec une bonne dose de Fuzzing, je pense qu’il est tout à fait envisageable de prendre le contrôle du robot à distance et de me ruiner le salon

Nabaztag

Continuons avec le Nabaztag.
J’aime beaucoup les lapins, mais je dois avouer que celui-ci me sort particulièrement par les oreilles compte-tenu des problèmes qu’il pose :

• La connexion Wifi qui pose les mêmes problèmes que la Freebox ;
• La centralisation, l’ensemble de l’intelligence du lapin se trouve sur les serveurs de Violet, ce qui signifie que si la société fait faillite, alors les lapins mourront ;
• Ce dernier point soulève de nombreux problèmes liés à la vie privé ;

The rabbit is sad, he wants to hug you

Je suis un des early adopters des ces technologies ( la domotique, la robotique, etc… ).
Mais je trouve que les utilisateurs et les constructeurs ne font pas assez attention aux implications et aux risques liés à ces technologies.

Est-ce que je ne vais pas un peu fort dans les accusations ?

Je pense qu aujourd’hui les histoires de robots qui volent des clés ou qui saccagent une maison peuvent faire sourire.
Mais imaginez les mêmes scénarios dans 5 à 10 ans et nous rigolerons un peu moins.

Mais quel est le principal problème ?

L’internet des objets va être déployé dans un nouvel environnement : votre maison.
C’est à dire un lieu privé, ou la fuite d’information et/ou les risques encourus peuvent avoir des conséquences très importantes.

We need Free hugs, free as software

Je pense que la seule voix possible pour l’Internet des objets est le logiciel libre.

Les points évoqués dans les exemples précédents peuvent être résolu qu’à l’aide de deux méthodes :

• la formation des utilisateurs ;
• et l’utilisation de logiciels libres.

Le 1er point est évident, je vais donc développer le second.
Comme le logiciel libre à largement prouvé sa supériorité en matière de sécurité informatique.
Il est donc le seul à pouvoir prétendre une place dans votre vie privé.
C’est la seule solution pour faire adopter ces évolutions.

Il existe aussi une solution basée sur le logiciel propriétaire et des nombreuses lois semblables à HADOPI permettant de cacher ces lacunes en matière de sécurité, mais je n’ai vraiment pas envie d’essayer

The goal of this xpl-perl module, is to broadcast recognised speech.

I’ve described the ASR xPL schema on the project forum : ASR.BASIC Schema proposal

You need a working Julius installation running in monitor mode (listening on the network) and an xpl-perl setup.

Here is an sample command output :
$ julius -input file -C julian.jconf
...
Stat: server-client: socket ready as server
///////////////////////////////
/// Module mode ready
/// waiting client at 10500
///////////////////////////////
In others windows, you must run xpl-asr-julius and xpl-logger.
When you speak or send a wav file to Julius, the reconised text is broadcasted on the network :
### read waveform input
enter filename-> test.wav
Stat: adin_file: input speechfile: test.wav
STAT: 180003 samples (3.75 sec.)
STAT: ### speech analysis (waveform -> MFCC)
STAT: 00 _default: 17 generated, 17 pushed, 6 nodes popped in 1123

xpl-logger output :
10.0.0.242:53922 [xpl-trig/asr.basic: bnz-julius.nux -> * - <s> éteindre lumière chambre </s>]

Installation

The setup is very simple on Debian GNU/Linux. Just fallow thoses instructions :
$ wget http://www.csquad.org/wp-content/contrib/xpl-asr-julius/xPL-ASR-Julius-0.01.tar.gz
$ tar xzf xPL-ASR-Julius-0.01.tar.gz
$ dh-make-perl xPL-ASR-Julius-0.01
$ cd xPL-ASR-Julius-0.01
$ dpkg-buildpackage -b
# dpkg -i ../libxpl-asr-julius-perl*.deb


That’s all !