Bonjour,

Dans le cadre d'un projet de master sur l'Internet des objets, je cherche à mettre en place l'idée suivante :

- plusieurs "objets" (ex: chaudière, sonde de température, caméra, etc...) sont connectés en réseaux à un serveur local par wifi ou ethernet.

- ces objets envoient en flux constant des données au serveur. Par exemple, une sonde de température, enverra chaque secondes la température d'une pièce en dégrées C au serveur.

- le serveur traite et stocke ces données.

- le serveur peut aussi envoyer des informations aux "objets" et les paramétrer.

Hors, il semblerait que le mieux pour ce genre d'application soit une carte Arduino.

Confirmez vous cela ? Si oui quelle modèle me conseilleriez vous ?

• http://store.arduino.cc/eu/index.php?main_page=product_info&cPath=11&products_id=197
• http://store.arduino.cc/eu/index.php?main_page=product_info&cPath=11&products_id=313
• un autre ?

Autant le dire tout de suite, je n'ai aucune expérience avec, mais j'ai de solides connaissances en programmation, et souhaite bien m'y mettre à fond. D'ailleurs, le tutoriel SDZ sur Arduino n'a pas encore de partie sur Arduino et l'ethernet, auriez vous d'autres liens vers des tutos (l'anglais ne me gène pas) ?

Merci d'avance pour votre aide.

EDIT : est-ce que le logiciel du tutoriel SDZ est le même pour une carte Arduino ethernet ?

-
Edité par lifaon74 1 octobre 2013 à 21:41:09

 L'internet des objets est quand même une notion d'électronique embarquée, où la problématique de la consommation d'énergie est souvent présente (mais pas obligatoire).

Autant une chaudière on peut se permettre de lui rajouter quelques watts de consommation électrique pour avoir une carte qui transmet des informations, autant pour une sonde température/humidité/etc. qui en général fonctionne sur batterie, lui rajouter 2-3W pour la transmission des informations est un peu ridicule. Pour une caméra alimentée en PoE le problème de l'alimentation et de la transmission des images ne se pose pas.

De même la stratégie de "l'esclave" qui envoie des données en permanence est-elle pertinente ? Une transmission à la demande du serveur ne sera-t-elle pas meilleure en terme de consommation de bande passante ? Quelle serait la méthode la plus simple pour la maintenance ? Changer le code du serveur qui demande la température toutes les secondes pour passer à 2 secondes ? Ou faire une mise à jour du capteur de température (ce qui rajoute en développement sur le capteur) ?

 Tu ne donne pas vraiment d'information sur ton projet, notamment ses perspectives et objectifs, donc je parle plutôt en terme "embarqué"

Si tu veux absolument travailler avec de l'IP, tu peux t'intéresser au 6LowPAN basé sur IPv6. ( http://fr.wikipedia.org/wiki/6LoWPAN )

Si tu pouvais donner un peu plus d'infos sur ton projet, on pourrait t'orienter sur des technologies peut-être un peu plus adaptées à des problématiques "Internet of things" que des Arduino (qui peuvent être adaptées).

Merci pour toutes ces précisions.

"L'internet des objets est quand même une notion d'électronique embarquée, où la problématique de la consommation d'énergie est souvent présente (mais pas obligatoire).

Autant une chaudière on peut se permettre de lui rajouter quelques watts de consommation électrique pour avoir une carte qui transmet des informations, autant pour une sonde température/humidité/etc. qui en général fonctionne sur batterie, lui rajouter 2-3W pour la transmission des informations est un peu ridicule. Pour une caméra alimentée en PoE le problème de l'alimentation et de la transmission des images ne se pose pas."

Dans le cadre d'un prototype, l'aspect de la consommation d'énergie ne sera pas pris en compte (en tout cas dans un premier temps). L'objectif est avant tout de mettre en place un système fonctionnel, sans se soucier de la taille ni de la consommation. Bien entendu, si de tels "objets" devaient voire le jour demain, il faudrait considérablement miniaturiser les composants et diminuer leur consommation d’énergie.

Dans mon prototype, la carte sera alimentée par batterie, bloc d'alimentation 12v et éventuellement  POE (si la carte le supporte, et si j'ai le budget pour m'acheter un tel switch).

De plus, je privilégie le wifi, plus gourmand en électricité, mais me permettant de déplacer la carte facilement sans avoir à tirer des câbles partout.

"De même la stratégie de "l'esclave" qui envoie des données en permanence est-elle pertinente ? Une transmission à la demande du serveur ne sera-t-elle pas meilleure en terme de consommation de bande passante ? Quelle serait la méthode la plus simple pour la maintenance ? Changer le code du serveur qui demande la température toutes les secondes pour passer à 2 secondes ? Ou faire une mise à jour du capteur de température (ce qui rajoute en développement sur le capteur) ?

 Tu ne donne pas vraiment d'information sur ton projet, notamment ses perspectives et objectifs, donc je parle plutôt en terme "embarqué""

Quelques détails supplémentaires :

- L'objectif est aussi de définir un protocole de communication et de paramétrisation avec standardisation des types de données

- La carte pourras être donc paramétrée pour envoyer toutes les X secondes des infos au serveur, ou n'en envoyer qu'à la demande, en effet, certain "objets" pourrait avoir besoin d'être actualisés toutes les secondes voire moins (ex : consommation électrique de la maison en temps réel), et d'autres sur un temps beaucoup plus long (ex : température extérieure)

=> Pour l'instant rien de tout cela n'a encore été étudié/examiné, toutes les questions pertinentes que tu poses feront bien entendu l'objet d'un point dans le rapport, mais je ne suis qu'au tout début du projet.

Sinon, j'ai pu observer que la raspberry pi pouvait aussi faire plus ou moins la même chose, sauf qu'elle ne propose pas d'interface aussi intuitive, ni d'API comme cella de l'arduino. Bref, que me conseilleriez vous ? Quelles modèles d'arduino, de raspberry ? Des tutos pour la communication avec le serveur ?

-
Edité par lifaon74 2 octobre 2013 à 14:44:18

> plusieurs "objets" (ex: chaudière, sonde de température, caméra, etc...)

> sont connectés en réseaux à un serveur local par wifi ou ethernet.

Tu as plusieurs problèmes :

1- Tu parles de "réseau" ce qui sous-entend un groupe de bidules à peu près "égaux", comme des PC sur un LAN, mais peut-être que ce serait plus simple ou moins cher d'avoir une étoile ou un système maître/esclave (par exemple un maître et des capteurs/effecteurs stupides).

2- Tu pars cash sur de l'ethernet. C'est un choix technique justifié ou défendable ou bien c'est juste que tu ne connais que cette solution ? Il y en a d'autres, potentiellement beaucoupplus adaptées à ton projet (et moins chères et plus pratiques)...

3- L'embarqué c'est en grande partie du hardware, donc décider de l'organisation hardware (avec ou sans fil, où sont les alims, avec ou sans pile, etc)  avant de parler de protocole ou autre, influence fortement le coût et la complexité.

Par exemple, si tu as un classique capteur, mettons, température ou autre, les décisions à prendre et les choix qui s'offrent à toi sont nombreux :

- avec ou sans fil pour les données ? la transmission sans fil c'est bien, mais il y a aussi des inconvénients...

- alimenté par batterie ? pile ? cellule solaire ? secteur ? ou par le fil qui transmet les données ?

- le capteur est idiot ? (genre il envoie une trame toutes les 10 secondes et c'est tout) ou un peu moins con (transmission avec confirmation et répétitions, paramétrage à distance, etc ?)

Par exemple :

alimentation par pile + transmission sans fil : tu vas devoir optimiser sérieusement la consommation. Ce n'est pas forcément simple... le Wifi est out, reste le bluetooth low power et autres variantes, ou une transmission unidirectionnelle, c'est ce qui consomme le moins, on transmet une trame toutes les X secondes sans possibilité de dialogue. 

alimentation par pile + transmission avec fil = idiot

alimentation par secteur + transmission sans fil : est-ce bien raisonnable de mettre une alim secteur (1W en veille, plus cher que le capteur) pour chaque capteur qui va consommer 0.1W ?

Si tu comptes avoir beaucoup de "machins" à interfacer, il faut compter le prix et la complexité du machin "de base", qui gère la logistique et la transmission, sur lequel tu vas rajouter le capteur proprement dit. Chaque machin peut d'ailleurs gérer plusieurs capteurs si ils sont proches physiquement.

Une fois ces points élucidés, tu peux décider du protocole de ton "réseau".

Si tu as beaucoup de capteurs pas chers, le bus CAN est un excellent choix. 2 fils pour le bus et 2 fils pour l'alim. Comme candidat pour le capteur, un LPC11C14 : transceiver CAN intégré, Cortex-M0 32 bits puissant, prix ridicule. Tu peux descendre le coût de ton "machin de base" à quelques euros.

L'ethernet est AMHA beaucoup trop lourd, cher et énergivore pour ce genre d'application.

-
Edité par Lord Casque Noir 2 octobre 2013 à 11:31:01

lifaon74 a écrit:

Dans le cadre d'un prototype, l'aspect de la consommation d'énergie ne sera pas pris en compte (en tout cas dans un premier temps). L'objectif est avant tout de mettre en place un système fonctionnel, sans se soucier de la taille ni de la consommation. Bien entendu, si de tels "objets" devaient voire le jour demain, il faudrait considérablement miniaturiser les composants et diminuer leur consommation d’énergie.

Dans mon prototype, la carte sera alimentée par batterie, bloc d'alimentation 12v et éventuellement  POE (si la carte le supporte, et si j'ai le budget pour m'acheter un tel switch).

De plus, je privilégie le wifi, plus gourmand en électricité, mais me permettant de déplacer la carte facilement sans avoir à tirer des câbles partout.

Sans vouloir être méchant, tu n'as donc pas vraiment compris l'enjeu de l'internet des objets. Si tu enlève de tes contraintes la consommation d'énergie, tu pars plus sur un internet des PC/Frigo/Four/trucalimentésurle220V que des objets de manière globale.

Partir sur une Raspberry comme tu le sous-entend à la fin, fera que tu va t'embarquer dans un domaine de microcontroleurs puissant et assez énergivore par rapport à d'autres microcontroleurs. Entre un microcontroleur de Raspberry Pi et celui de l'Arduino Uno ou Mega il y a un monde de différence.

Donc, non on ne peut pas prendre la première carte venue en se disant que je m'occuperai de la miniaturisation après. Pourquoi ? Imaginons que tu prenne une Raspberry Pi, qui est capable de faire tourner un linux sans problème et que tu donc tu développe ton projet sous linux, et puisque Python est à la mode, bah tu développe ton projet en Python. Tout fonctionne et tout, c'est bien. 

Maintenant tu te dit que tu va passer à l'étape suivante, réduire la consommation : ok passons sur un microcontroleur type Atmel 8 bits pour les petits modules peu complexes : premièrement, ton code python, bah il ne fonctionnera pas, il te faudra faire du C/Java (le langage Arduino est un mix des deux), ou du C si tu choisis un microcontroleur non Arduino. Et tu devras ensuite revérifier toutes les performances ainsi que tout ce qui va concerner le hardware : le wifi ? Ah bah mince il consomme X Watts, ca double la consommation de mon Arduino, c'est dommage, il faudrait un autre protocole.

Pour ton serveur une Raspberry Pi (ou plutôt une BeagleBone Black) est pertinent pour profiter, via un linux embarqué, de fonctionnalités réseaux avancées. Maintenant pour un module esclave, ce n'est pas un choix pertinent.

Concernant le Wifi, ce n'est pas le protocole le plus adapté, renseignes-toi sur la norme IEEE 802.15.4 et notamment le ZigBee. Qui permet de faire du réseau en étoile ou en peer-to-peer. Les débits ne sont pas à la mesure du Wifi (250kbps voire 1Mbps contre 54 Mbps/300Mbps), mais niveau portée tu fais aussi bien voire même mieux (grâce au module peer-to-peer, en théorie tu peux contacter un module à l'autre bout de la terre, s'il y a une route de modules entre qui vont relayer la communication, le Wifi n'est absolument pas fait pour ca).

Tout ca pour dire, prend le temps de faire des recherche sur l'existant et ne te focalise pas sur des protocoles/technologies conçus pour des PC de 500W et surpuissants (et couteux).

Par exemple à l'exemple j'ai bossé avec l'OS Contiki : http://en.wikipedia.org/wiki/Contiki

serait t'il pratique pour ce type de projet d'utiliser directement le réseau 220V pour être interconnecté ? une sorte de CPL sans LAN

pas besoin de câble supplémentaire ...

boah, pour un capteur de température comme tu veux faire, sur un bus CAN tu t'en sors avec un budget de 5€ et c'est facile, avec ta dernière proposition disons 10x plus (en bonus, le CPL ça marche quand ça veut) et c'est pas mal plus compliqué...

-
Edité par Lord Casque Noir 3 octobre 2013 à 16:44:38

Bonjour, voici encore quelques précisions :

Je suis en master de sciences informatique, par conséquent, la programmation et l'échange de données HTTP ou par socket c'est mon point fort. Par contre l'électronique ou la domotique pas du tout (disons que je me suis arrêté au kits pour débutants : création d'une alimentation 12v, d'un haut parleur partant d'une prise jack 3.5mm, étude rapide des puces électroniques). Mais je viens juste de découvrir les microcontrôleurs et toutes leurs possibilités absolument fabuleuses 

Le projet n'est pour l'instant qu'à l'état d'idée, mais je compte bien me lancer à fond dessus. J'ai dévoré entièrement le tuto arduino (j’attendais de l'avoir terminé pour répondre à ce post, d'où une légère attente) et j'ai finalement commandé une carte arduino YUN avec wifi + ethernet (+ tout un tas de capteurs). Certes elle est bien plus chère (3 fois le prix d'une uno), mais me permettra dans l'avenir (proche) de m'en servir en réseaux.

- D'ailleurs à ce propos pourquoi le chois de l’Ethernet et du wifi ?

La réponse est simple : car tout le monde (ou presque) a chez sois le wifi, des câbles ethernet à travers la maison ou des prises CPL. Et surtout, il ne serait pas du tout pratique de brancher tous ses objets par câble. Une solution par onde me semble donc être la meilleure.

Certains "objets" sont sensés pouvoir être déplacés (d'ou le wifi), d'autres seront fixes (ex : module de contrôle thermostat), mais dans tout les cas, il est impensable de demander à des particuliers de tirer des câbles (bus CAN, I2P, USB, etc...) à travers toute leur maison, ni de leur montre à celle du voisin dans le métro. Bref vive les ondes  !

J'ajouterai aussi que certains objets "spéciaux", pourraient très bien avoir en plus ou en remplacement de leur module wifi, un module bluetooth ou radio longue portée (ex : un capteur tout au fond du jardin)

Centraliser toutes les commandes et les STANDARDISER est aussi un objectif, de ce fait n'importe qui peut installer facilement tous ces "objets", puis le serveur permet aux utilisateurs de visualiser des données recueillies, de paramétrer les cartes, et bien sûr permet aussi aux cartes de communiquer entre elles ! La partie protocoles et interface sera donc très importante dans mon projet.

Finalement, je commence à entrevoir aussi la possibilité de modules à brancher à la carte (ex: sonde température, sonde luminosité, capteurs de pressions), puis à les ajouter manuellement via une interface sur le serveur ou en ajoutant un module "écran + boutons" avec menu directement sur la carte. Voire encore mieux, on branche le module et il est reconnu tout de suite par la carte. Attention, tout cela reste fort hypothétique.

Pour ce qui est de la taille et de la consommation maintenant : 

Le prototype n'a pas du tout pour but de montrer des prouesse technologiques, mais bel est bien à illustrer que le concept d'"objets" interconnectés, très très peu rependu actuellement, est viable et pourrait être facile à mettre en place (attention, je parle d'"objets" et non pas de smartphones, pc, etc...). Si mon prototype devait être implémenté réellement dans de petits objets, il faudrait alors bien sûr faire appel à une entreprise spécialisée dans la micro-électronique qui s'occuperait de diminuer radicalement la taille des composants, ainsi que leur consommation. C'est donc aussi pour cela que je donne des exemple de gros objets, parce que je ne possède pas les moyens techniques pour implémenter tout ça dans une montre, pour laquelle il faudrait inventer une technologie de captage d'énergie corporelle par exemple !

Mais pour sûr, je vais me renseigner sur toutes es technologies, protocoles, etc... mais pas en un jour. Sans oublier que je vais surement découvrir de nouveaux articles/éléments qui vont peut être radicalement changer mon prototype ou ma façon de voire les choses.

S'il vous reste des remarques, idées, etc.. n'hésitez pas à m'en faire part, elles ne pourront que m'être bénéfiques.

J'ai quelques mots clefs pour toi pour tout ce qui est interconnexion : uPnP, Wifi Direct, Bluetooth, Bluetooth Low Energy (ou bluetooth 4.0), NFC. Ce sont les technos sur lesquelles tout le monde se base aujourd'hui pour faire des produits connecté (plus, éventuellement, les technos genre HSDPA et LTE).

Pour interroger des capteurs, le Bluetooth low-energy, c'est idéal, et tout le monde a déjà un lecteur : son smartphone.

Les implantations domotiques sont encore chères , et je ne suis plus étudiant . Implanter des modules dans des prises murales est à la portée de l'électricien .

Mais ensuite composer le scénario , avec un  serveur rapide et performant , tout un business .

Si j'étais étudiant , je commencerai par du concrêt :

- je rentre en fin de journée et presse un bouton pour obtenir :

1 / La fermeture des volant roulant des chambres

2 / La commande électrique du four ( pizza )

3 / L'éclairage du salon et de l'écran tv

- je peux ainsi rester caler avec une boisson après

la séance de sport de la salle de muscu , qui a été intense

voir ici pour la suite >>  http://www.domogy.fr/

 Domodoo , z-wave , raspberry pi ( les modules sont à 50 eur pièce , c'est le prix du marché .. )

 http://www.domadoo.fr/media/CGV_DOMADOO_ENSEIGNEMENT_2011.pdf

-
Edité par Anonyme 7 octobre 2013 à 11:32:09