Smart Sensor WiFi : Différence entre versions

Version du 28 février 2014 à 09:50

Informations générales

Page de wiki du projet Smart Sensor WiFi

Étudiants Thomas Maurice et Benoit Maliar

Tuteurs Alexandre Boé et Thomas Vantroys

Les fichiers sources du projet sont disponibles via Git. Alexandre : Il n'est pas possible de faire un Git en interne à Polytech ? Thomas M: Pas pour le moment, l'école n'a pas la machine qui va bien. Alexandre : Faut raler ;-)

Liste du matériel nécessaire

Liste non exhaustive, pourra être modifiée !

Énoncé initial du projet

L'objectif du projet consiste en la conception et la réalisation de capteurs autonomes communiquant en WiFi afin de pouvoir remonter régulièrement des informations sur l'état des salles de cours. Les capteurs seront par exemple des détecteurs de lumières, de pression, de qualité de l'air, ...

La communication sera obligatoirement réalisée en WiFi sur le réseau de l'université en respectant les contraintes de sécurité (WPA2, ...).

Deux options sont possibles :

• Refaire complètement une carte avec un microcontroleur et une puce wifi (comme par exemple les spark)
• Réaliser un shield pour raspberry pi contenant les différents capteurs.

Analyse du sujet

On a ici affaire à un réseau de capteurs reliés à une base de donnée centrale qui est chargée de recevoir les données des différents capteurs de manière à pouvoir présenter à un utilisateur un état des différentes pièces dans lesquelles on aura disposé les capteurs. Cela peut notamment impliquer :

• Un accès à ces données via une interface web
• Un accès à ces données via une application mobile

Alexandre : On pourrait tout rassembler en une BDD avec un accès à travers un navigateur ?

On identifie donc deux parties au projet :

• La partie capteur
• La partie serveur

Cahier des charges

Spécifications des capteurs

Les caractéristiques souhaitées pour les capteurs sont :

• Être capable de mesurer l'environnement dans lequel évolue le capteur (Pression, température, lumière, présence, ouverture de porte...)
• Contacter le serveur via le WiFi pour actualiser la base. Alexandre : ce qui implique la prise en compte de la sécurité type WPA2
• Éventuellement, être reconfigurable à distance (via un serveur web embarqué dans le microcontrôleur)
• Être capable de gérer sa consommation d'énergie.
• Agir en temps que datalogger si le réseau n'est pas accessible.

Spécifications du serveur

Les caractéristiques souhaitées pour le serveur sont :

• Être capable de contacter ou d'être contacté par les capteurs via le réseau.
• Respecter les contraintes de sécurité (WPA2)
• Être capable d'authentifier les clients
• Stocker les données reçues dans une base de données et éventuellement faire des calculs et des statistiques sur ces données.
• Présenter sous format compréhensibles les données au client (web ou appli)
• Vérifier l'état des capteurs et notifier un responsable en cas d'anomalie (déconnexion du réseau, valeur anormale d'un capteur...)

Propositions de solutions technologiques

Les capteurs

Nous proposons de réaliser une carte basée sur un ATmega328 dans lequel on pourra flasher du code Arduino. Pour gérer le WiFi, nous proposons une solution utilisant le shield TEL 0047 de Wiznet utilisant la puce WiFi WizFi210.

Cette puce gère le WPA2-PEAP mais malheureusement pas dans son firmware natif. Il va donc falloir s'arranger avec Wiznet pour obtenir le firmware qui nous permettra de faire de l'EAP.

Dans un premier temps, on se concentrera sur la mise en place d'un prototype fonctionnel a base d'un simple capteur de température. On étendra ensuite les capacités de la chose à des capteurs peut être plus complexes style I2C ou SPI.

Pour la reconfiguration du capteur, on le fera via un serveur web embarqué dans le microcontrôleur.

Le serveur

On propose une solution à base d'une machine sous Linux hébergeant un serveur MySQL et PHP.

Le SGBD utilisé sera MySQL.

La partie web du serveur destinée à présenter à l'utilisateur une vue des données serait développée en PHP/HTML5/CSS3. Les capteurs enverront les données sous forme JSON au serveur web qui se chargera du traitement.

Travail à effectuer dans un premier temps

Pour la partie BDD/Web

• Structurer les tables dans un diagramme UML qui va bien
• Déterminer une architecture de site (MVC)
• Traiter les données envoyées par les capteurs au format JSON
• Incorporer une interface admin
• Faire un design swag

Pour les capteurs

Avant la réception du matos WiFi:

• Réaliser la lecture d'une température et la formater en JSON Quasiment fait, on peut lire sur les ADC, le formattage n'est qu'une formalité
• L'envoyer sur un port série à interval régulier Pareil mes routines d'envoi de strings sont écrites
• Parser et répondre à des requêtes HTTP sur le port série Fait, mais en série, pas encore adapté au wifi
• Faire fonctionner une RTC pour agir en tant que datalogger En cours mais il manque l'interface avec la carte SD

Après réception du matos WiFi:

• Envoyer les requêtes JSON directement en POST au serveur Web
• Traiter les requêtes client
• Adapter une nouvelle carte avec juste la puce WiFi

Point sur la partie capteurs au 28 février 2014

Shield Arduino avec la RTC et photo-résistance

Ce qui a été fait

• L'appareil peut lire l'ADC câblé sur une photodiode et un capteur de température et convertir ça en chaine pour l'envoyer.
• Stocker des infos de config en EEPROM et y accéder sur demande.
• Il peut envoyer des choses au monde extérieur sur le port série et en lire.
• Il gère quasiment parfaitement l'horloge temps réelle DS1302 (aux burst-modes près, mais c'est pas indispensable pour le moment).
• L'intégralité du code est documenté, fonction par fonction et une doc au format Doxygen est générable.
• Le PCB est en cours de création sous Eagle.

Ce qui ne sera pas fait

• L'interface avec une carte SD, puisque on a opté pour une mémoire Flash.

Ce qui est en train d'être repensé mais qui doit être discuté avec les enseignants

• Implanter un serveur Web dans l'atmega328p. Je doute que ça soit pertinent d'un point de vue énergétique, dans la mesure ou l'appareil devra être up H24 si on veut faire ça. Je pense qu'il est plus malin d'enregister les changements de config à faire dans la BDD et de les comitter au senseur dans la page de réponse qui suivra sa mise à jour des données de température/lumière. L'avantage est double, on a des écolomies d'énergies, et un cout de traitement moindre dans la mesure ou on peut déterminer le format de la chaine de màj et de le faire simple, au lieu de parser l'intégralité d'une requête HTTP.
• Je pense qu'il est intéressant d'implanter un mode de "config initiale" par le port série pour qu'on puisse mettre manuellement les infos du capteur avant le permier déploiement (de toutes façons il faut bien entrer une conf initiale) quitte à le vérouiller logiciellement (via un bit en EEPROM par exemple) lorsqu'on en a fini avec lui. De cette manière il ne sera plus reprogrammable que par le serveur de BDD ou par un re-flashage de l'EEPROM.