Comprendre l’IOT avec une boule… mais pas que...

J’ai eu l’immense plaisir (et l’honneur) d’intervenir à la session 2015 de Devoxx France pour faire une présentation sur l’Internet des objets, intitulée “Comprendre l’IOT avec une boule… mais pas que…”, en collaboration avec un autre speaker, Laurent Huet @lhuet35 de la team BreizhCamp.

L’objectif de notre présentation était de présenter notre vision de l’“internet of things” en parlant des grands principes (définitions, protocoles, objets, architectures, outils…), tout en les illustrant par 4 démonstrations avec de vrais objets connectés (montrer comment faire son propre internet of things). Le 3ème protagoniste de cette présentation était une Sphero (une boule lumineuse et colorée, télécommandée par smartphone) qui a participé à 2 des 4 démonstrations. Chacune des démonstrations permettait de montrer différentes configurations d’objets connectés plus ou moins complexes et autonomes.

IoT et objets connectés : démonstration avec Sphero

Je vais tenter dans cet article d’extraire les idées les plus significatives de cette présentation. Je définirai donc ce qu’est (selon moi) un objet connecté, ce qu’est l’internet des objets et expliquerai de quelle manière et avec quels outils nous avons réalisé certaines de nos démonstrations.

Qu’est-ce qu’un objet connecté ?

On parle aussi de “Thing”. Donc, un objet connecté c’est une “chose” constituée d’un ensemble de composantes (des propriétés et des API). Cet objet a généralement une sensibilité à l’environnement par le biais de capteurs : position, température, humidité, hygrométrie, pulsations cardiaque (pensez aux montres connectées ou aux bracelets connectés).

Ensuite par différents moyens, ce même objet est relié à un mode de visualisation embarqué (les informations de la montre par exemple, la couleur de la Sphero…) ou distant (des dashboards pour afficher la température de votre maison dans un navigateur ou sur votre smartphone). Cet objet va avoir également une interactivité plus ou moins poussée avec d’autres objets (la Sphero ou la montre connectée avec un smartphone, un maillage de capteurs…), mais aussi une autonomie plus ou moins grande (durée de vie d’une batterie, piles, secteur), et enfin, mais non des moindres, une identité : pour gérer et reconnaître les objets il faut savoir les identifier.

L'identification des objets connectés est primordiale

Qu’est-ce que l’internet of things ?

On parle de “Internet of Things”, mais aussi de “Web of Things”, et même d’“Internet of Everything”. Essayons d’expliquer ce que c’est en replaçant les “Things” dans leur contexte.

Machine to machine et internet of things

Dans un premier temps, nous avions des objets isolés (bien que ce soit discutable pour une télévision), puis est apparu le concept du “Machine To Machine” où la technologie permet de faire “discuter” les machines entre elles et de les contrôler à distance (pensez à tout ce qui est surveillance à distance par exemple), et enfin depuis peu, est apparu l’IOT : des objets du monde réel transmettent (et reçoivent pour certains) des informations à travers le réseau internet, permettant ainsi de construire des “maillages d’objets” même à grande distance pour élaborer des systèmes de plus en plus intelligents (par exemple: les smart grids ou la distribution intelligente de l’électricité). Retenez, que tout est potentiellement “connectable” et en mouvement avec l’arrivée des montres connectées, des vêtements connectés… que votre domotique est en pleine mutation, et qu’il reste encore de nombreux cas d’usage à inventer.

Un marché en pleine expansion

L’IOT représente un marché à expansion rapide, notamment grâce à des modes de connectivité accrue : en effet, nous disposons tous du Wifi, de la 3G, de la 4G et d’appareils Bluetooth. Mais d’autres facteurs techniques, tels que l’augmentation des performances et de la puissance de calcul, la miniaturisation, l’autonomie (pensez à votre smartphone) contribuent aussi fortement à cette expansion. Les facteurs économiques sont également favorables, nous pouvons observer une baisse des coûts de production de matériel (regardez les prix des composants électroniques, des micro-controllers comme Arduino ou encore des nano-computers comme le Raspberry PI). Le phénomène du Crowdfunding permet aussi l’émergence de nombreux projets qu’il n’y a encore pas si longtemps, n’auraient pu voir le jour.

La diversité des “Things” remporte l’adhésion du grand public et contribue donc grandement au marché de l’IOT.

Sphero, Raspberry PI : les objets connectés sont de plus en plus puissants

Les objets connectés deviennent de plus en plus complets et puissants, avec des usages multiples (de l’utile au purement récréatif, la Sphero par exemple, qui est une boule télécommandée par votre smartphone) et, j’en parlais plus haut, certains ont la capacité d’utiliser des langages et des technologies avancées ; prenez par exemple le Raspberry PI, c’est un ordinateur pas plus gros qu’un paquet de cartes à jouer qui embarque un système d’exploitation Linux complet, ou même du Windows 10 dans sa dernière version.

Mais comment ça fonctionne ? Et comment le faire soi-même ?

Nous disposons ainsi de nombreux objets susceptibles de communiquer et d’agir, mais pour que cela ait une quelconque utilité, il faut mettre en place des systèmes, des architectures capables d’échanger des informations avec les things, de les identifier mais aussi capables de stocker, chiffrer, restituer… toutes les données générées par les things (des capteurs de température qui émettent toutes les 30 secondes pendant des mois, des montres connectées couplées à des smartphones qui comptent des pas, qui enregistrent des pulsations cardiaques, qui diffusent des coordonnées géographiques…).

Lors de notre présentation, nous avons illustré ce qu’était un projet IOT à partir de démonstrations avec des objets réels et notamment en commençant (et finissant) avec une Sphero (d’où le titre de notre présentation). La Sphero, dont nous avons détourné l’usage initialement ludique, était donc l’objet connecté parfait pour une présentation. Vous allez comprendre pourquoi.

Un projet “IOT”, peut être découpé en 4 parties principales :

  • les things (objets, périphérique…),
  • les infrastructures (les serveurs qui vont communiquer avec les things, dans le cloud ou ailleurs),
  • le stockage des données,
  • l’utilisation des données.

Etapes d'un projet IOT

Pour les besoins de la présentation, une des démonstrations mettait en œuvre ces 4 parties, de manière plus ou moins avancée, pour illustrer et faire comprendre les concepts.

Remarque :  pour simuler internet, nous avions notre propre routeur wifi.

Echanger des données avec une Sphero à travers le Web

Partie 1 : les “Things”

Dans le rôle de l’objet connecté, nous avions choisi la Sphero pour les avantages suivants :

  • elle peut se déplacer et changer de couleur lorsqu’elle reçoit des informations, elle peut donc recevoir des informations,
  • elle embarque des capteurs (gyroscope, accéléromètre…) et peut transmettre des données,
  • elle communique avec l’extérieur en Bluetooth Low Energy qui est un des protocoles de communication de l’IOT (mais vous avez aussi le wifi, zigbee, etc.).

Le plus souvent, les Things n’ont pas la capacité de communiquer directement avec les infrastructures (donc se connecter à internet), il est donc nécessaire de mettre en place une “Gateway” ou “Hub”, pouvant à la fois communiquer avec les Things et les infrastructures.

Dans le rôle de la “Gateway”, nous avions choisi un Raspberry PI allié aux éléments suivants :

  • un dongle bluetooth afin de communiquer avec la Sphero,
  • un dongle wifi (ou un cable RJ45) pour se connecter “à l’extérieur”.

Communication entre la Sphero et la Gateway

D’un point de vue logiciel, le Raspberry PI communiquait avec la Sphero grâce au framework CylonJS (http://cylonjs.com) qui s’appuie sur NodeJS (JavaScript est de plus en plus présent dans le monde de l’IOT, même si les Things se programment beaucoup en C, Python ou bien Lua). CylonJS est un projet qui propose les API et les drivers nécessaires pour communiquer avec de nombreux objets, tels l’AR Drone (de la société Parrot), mais aussi la Sphero.

Le “code de pilotage” ressemble à ceci :

Cylon.robot({
connections: {
sphero: {adaptor: 'sphero', port: config.spheroPort()},
},
devices: {
sphero: {driver: 'sphero'}
},
work: function (my) {
// start sphero
my.sphero.roll(5, Math.floor(Math.random() * 360));

after((1).seconds(), function () {
var opts = {n: 200, m: 1, pcnt: 0};
my.sphero.setDataStreaming(["locator", "accelOne", "velocity"], opts);
my.sphero.setBackLED(192);
my.sphero.stop();
});

my.sphero.on("data", function (data) {
// get some data
});
}
}).start();

Communication entre la Gateway et le serveur

Il existe plusieurs protocoles de communication dans le monde l’IOT, pour les besoins de notre démonstration, nous avions choisi le protocole MQTT (Message Queue Telemetry Transport), dont les initiateurs principaux sont IBM et Eurotech. MQTT a été standardisé à l’OASIS en novembre 2014. Nous l’avons choisi car c’est un standard simple et léger, reposant sur TCP/IP, utilisant un modèle évènementiel et il est “content agnostic”.

Le modèle évènementiel de MQTT repose sur l’application du pattern “publish / subscribe”, il faut donc un serveur de message (on parlera de broker MQTT) et des clients MQTT pour publier des messages ou s’abonner à des channels de messages, on parlera de topics.

Modèle événementiel MQTT

Un autre avantage de MQTT est qu’il existe déjà de nombreuses implémentations de brokers et de clients dans différents langages.

Dans le cadre de notre démonstration nous avons utilisé Mosca comme broker MQTT (il repose sur NodeJS), donc installé sur un laptop qui faisait office de serveur.

Côté “Gateway” (sur le Raspberry PI donc), il se trouve que le projet CylonJS propose aussi un driver MQTT (à retrouver ici), le code de pilotage de la Sphero a donc été très facile à modifier :

Cylon.robot({
connections: {
sphero: {adaptor: 'sphero', port: config.spheroPort()},
server: {adaptor: 'mqtt', host: mqttServer}
},
devices: {
sphero: {driver: 'sphero'}
},

work: function (my) {
// S’abonner à tous les topics de type /sphero/*
my.server.subscribe('/sphero/+');

// start sphero
my.sphero.roll(5, Math.floor(Math.random() * 360));

my.server.on('message', function (topic, data) {
// à la réception d’un message en provenance du serveur,
// je déclenche les mouvements de la Sphero
data = JSON.parse(data)
if (topic == "/sphero/move-sphero") {
my.sphero.roll(data.speed, data.angle);
}
if (topic == "/sphero/stop-sphero") {
my.sphero.stop();
}
});

my.sphero.on("data", function (data) {
// lorsque la Sphero se déplace je renvoie les informations au serveur (broker)
// sur le topic hello-sphero
my.server.publish("hello-sphero", JSON.stringify(data));
});
}
}).start();

Parties 2, 3 & 4 : le serveur, les données et les dashboards

Le serveur de la démonstration (un portable) comportait plusieurs composants :

  • NodeJS pour faire fonctionner le broker MQTT et le serveur d’application,
  • le broker MQTT Mosca, présenté plus haut,
  • une application web développée avec ExpressJS qui fournissait à la fois une API (obtenir la liste des objets connectés et leurs informations via une API REST, par exemple : http://my_iot_server/connected/things) et le front web,
  • une base Redis (qui contenait la liste des objets connectés et leurs informations),
  • une webapp développée avec Polymer qui fournissait des informations graphiques (les dashboards) à propos de la Sphero (grâce au framework Epoch à base de D3.js).

Pour permettre des échanges temps réels sur toute la chaîne de communication de la Sphero jusqu’au navigateur, nous avons utilisé côté serveur le framework socket.io et côté navigateur, le client socket.io.js du même projet : donc tous les messages MQTT en provenance de la Sphero via la Gateway et le broker étaient transmis via socket au navigateur, et de la même façon, l’interface web permettait d’envoyer des informations de pilotage à la Sphero pour la faire bouger ou changer de couleur.

Ces éléments permettaient d’illustrer un cheminement complet de l’objet vers le broker, puis le client, et ensuite renvoyer des données dans le sens inverse, vers l’objet :

Cheminement de l'objet vers le broker

Dashboard Sphero en fonctionnement

Le dashboard “Sphero” en pleine action

La Sphero est un objet ludique, mais imaginez à la place un éclairage de ville dont on pourrait facilement gérer l’intensité, la couleur (ambiance), ou même détecter des problèmes physiques (collision avec véhicule…) et vous comprendrez l’utilité de l’IOT.

Il ne faut pas oublier non plus que les objets sont plus ou moins “intelligents” (logiciels embarqués), communicants et puissants : si la Sphero a besoin d’une Gateway qui permet de faire “le pont” vers internet, mais aussi qui “embarque” le client MQTT pour échanger avec le serveur, certains objets peuvent communiquer directement en wifi et embarquer la partie logicielle (donc plus besoin de Gateway).

Ce cas de figure était l’objet d’une autre démonstration qui mettait en œuvre un micro controller ESP 8266 à peine plus gros qu’un sucre embraquant un client MQTT codé en C, et capable de communiquer directement en wifi (et pour un prix dérisoire de l’ordre de 5$).

micro controler ESP 8266

L’ESP 8266

L’ESP 8266 était relié à un capteur de température et à un écran à cristaux liquides et sur le même principe que la démonstration précédente il était possible d’interagir à distance avec l’ESP 8266 (envoyer la température vers le serveur, envoyer des informations du serveur vers l’écran : globalement nous avions un début de NEST). La seule différence était que ce nouvel objet se passe de Gateway, car il embarque à la fois les moyens de communication et l’intelligence.

Creer son propre internet des objets

Nest Like par @lhuet35

Notre objectif à travers ces démonstrations était double : illustrer l’Internet des Objets, mais aussi démontrer que, simplement, on peut être acteur de ce nouveau monde et faire son propre Internet des Objets.

Quelques idées pour aller plus loin

Il faudrait beaucoup plus de pages et de temps pour être exhaustif, mais voici quelques points supplémentaires si vous souhaitez creuser plus en profondeur le sujet :

  • il existe d’autres protocoles, et notamment CoAP (Constrained Application Protocol) pensé pour les réseaux LoWPAN (Low-Power Wireless Personal Area Network), des réseaux de “toutes petites” machines,
  • tous ces objets génèrent beaucoup de données qu’il faut pouvoir exploiter. Après avoir assisté à la présentation de Nicolas Muller à Devoxx France 2015 sur InfluxDb et Grafana, je ne saurai que trop vous conseiller de jouer avec,
  • les composants et les kits de démarrage “électroniques” avec des micro-controllers ou des nano-computers sont de plus en plus abordables et vous permettent de prototyper des objets avec des capteurs très facilement, par exemple mon prochain jouet sera certainement un “Grove Starter Kit” (ou comment faire de l’électronique façon Lego lorsque l’on n’y connait rien du tout).

 

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !