Consommation maison

Élèves sur le projet : Jérémy Gondry IMA4 Florian Royer IMA4

Encadrants : M. Alexandre Boé M. Thomas Vantroy

---

Introduction

La consommation énergétique d'une maison ou d'une entreprise est souvent un gros problème car on est la plupart du temps en manque de moyens techniques ou de systèmes assez modulaires pouvant s'adapter à tout type d'installation. Ce projet a donc été initié pour pouvoir offrir un système complet permettant de connaître et de réduire fortement la consommation énergétique due aux radiateurs (qu'ils soient électriques ou à eau chaude). A terme, ce projet pourrait être joint au projet 43 initié par la direction de Polytech afin de réduire la consommation énergétique des radiateurs de l'école. A titre d'exemple, Polytech chauffe les salles jour et nuit, notre devrait permettre de chauffer les salles qui sont utilisées uniquement à des heures prévues, et ainsi économiser au moins 40% de l'énergie.

Le but final de ce projet devrait ressemblé au système de Schneider suivant : [1]

Étape 1 : Cahier des charges

Voici un récapitulatif de ce qui est attendu du projet.

Alexandre : Très bien pour la réactivité, dans l'ensemble tout y est.

Objectifs principaux

• On compte principalement réduire la consommation due au chauffage dans une habitation ou infrastructure ;
• Les températures et pressions devront être récupérées dans plusieurs pièces à l'aide d'un réseau de capteurs.
• Ces données seront récupérées par un dispositif centralisé communicant en Ethernet.
  • Ce dispositif servira à élaborer et transmettre, à distance, les commandes aux dispositifs de chauffage.
  • La régulation opérée sur la température, sera modulaire, on pourra étendre la commande à différents types de chauffage (sans modifier fondamentalement le programme embarqué sur le dispositif)
• Elles seront classées selon une structure de donnée adaptée.
• Une application android sera développée, elle fera office d'interface utilisateur.

Elle permettra à l'utilisateur de connaître la température dans l'habitation et d'envoyer une température de consigne.

Phase prototypage:

Elaboration d'un réseau de capteurs.

Ecarter les problématiques liés à l'électronique (alimentation des dispositifs communicants) pour se concentrer sur la partie logiciel du réseau de capteurs.

Phase implémentation en dur:

Elaboration d'une carte électronique pour implémenter les modules capteurs, modules chauffage.

Alexandre : Section à reprendre pour faire apparaître les différents niveaux du projets. Ici vous mélangez les parties générales et le détail, voire même un début de solution. Par ailleurs, il semble intéressant d'inclure une partie pour étudier la faisabilité de récupération de données météo sur Internet.

A concevoir

• Réseau de capteurs (sans fil) (technologie à déterminer) ;
• La base de données où seront enregistrés les différentes mesures et consignes à envoyer aux modules ;
• Supervision complète sur serveur Apache (HTML, PHP) ;
• Supervision minimale : applications mobile Androïd ;
• Programmeur de mise en veille afin d'économiser la pile ou batterie qui alimentera le capteur ;
• un protocole de communication entre les capteurs et un "appareil central" (de type Raspberry Pi, Fox Board...) ;
• Création du capteur qui comprendra :
  • La récupération de la température ;
  • Récupération de la pression (pour détecter les chutes suite à l'ouverture d'une fenêtre) ;

• Possibilité d'ajout de "modules", qui se pluggeront sur les capteurs, correspondant au chauffage commandé par fil pilote, au chauffage commandé par électrovanne (pour les dispositifs utilisant une chaudière) ;
• Établir un système permettant la consommation réduite des capteurs (pour l'alimentation : pile, secteurs, pourquoi pas un système de récupération de l'énergie thermique), problématique de la fréquence de rechargement du dispositif d'alimentation des capteurs ;
• Mise en veille des capteurs / fréquence de consultation des données. Une mesure toutes les heures ou toutes les demi-heures ne seraient-elles pas suffisantes ?
• Une récupération sur un serveur NTP (Network Time Protocol), de l'heure pour gérer les mises en veille et les heures creuses / heures pleines ;

La problématique d'adaptabilité du dispositif de chauffage commandé doit être prise en compte : changement de milieu (maison ou bâtiment d'entreprise, le type de chauffage (eau ou électrique), la disponibilité de prises secteurs ou pas.

Alexandre : Ici aussi vous mélangez allégrement différents niveaux de réflexion. Par ailleurs, la pression est dans un premier temps pas forcément pertinente (manque de capteur simple a priori). L'idée sera de faire un capteur suffisamment générique pour pouvoir ajouter simplement un capteur ou un autre. La gestion des phases de réveil / endormissement ne doit pas être trop énergivore, une simple RTC (Real Time Clock) devrait être suffisante.

N.B

Ceci est une conclusion de la première réunion avec A. Boé et B. Bouhamama. Il y a de fortes probabilités pour que ce cahier des charges soit complété.

Début du projet et découpage du travail

La prochaine étape consiste à trouver une architecture optimale du capteur et définir la structure de données. On peut alors commencer par diviser le travail, un s'occupera de la mise en place d'un réseau de capteurs et modules, le second de la base de donnée et les outils de supervisions les plus adéquates au système.

Jérémy s'occupera de la conception des capteurs et des modules pour chauffage (cartes électroniques) ainsi que des codes à implémenter permettant la communication. Florian se chargera quant à lui de la supervision Web dans un premier temps, de la base de données ainsi que des programmes à mettre sur la RPI afin de récupérer et stocker les valeurs des données fournies par les capteurs.

Étape 2 : Architecture Optimale du capteur / Mise en réseau

Introduction : cahier des charges spécifiques

L'objectif final est de réaliser un réseau de capteurs/actionneurs que nous appellerons ici Modules. Ces modules devront permettre de mesurer une température, capter des chutes de pressions et actionner le radiateur. De plus, dans un soucis d'économie d'énergie, les modules devront consommer que très peu d'énergie. Enfin, les modules s'installeront dans une maison ou une infrastructure, impossible de prévoir un câblage entre les modules, il faut donc opter pour une architecture réseau Sans-fil.

Norme Wireless

Il existe principalement 2 catégories de réseaux :

A gauche un exemple de réseau en étoile, à droite un réseau maillé

• Les réseaux de type "star" (ou "en étoile"), utilisent une machine centrale sur laquelle se connectent les périphériques du réseau.

• Alors que les réseaux de type "mesh" (ou "maillés"), transmettent par le biais d'un coordinateur les données aux différents périphériques connectés. Si le 1er périphérique "comprend" que les données lui sont destinées, il les enregistre, sinon il agit comme un répéteur et transmet au 2ème périphérique et ainsi de suite jusqu'à ce que le nombre maximal de répéteurs parcourus soit atteint ou bien que les données aient trouvées leur destinataire.

Comme on souhaite économiser un maximum d'énergie, il convient d'utilisé un réseau maillé Alexandre : Pas sur que ça soit compatible en terme d'énergie : comment s'assurer que le noeud est réveillé au bon moment pour servir de passerelle ?, on se sert de chaque module comme un bridge pour envoyer les données, ce qui fait économiser l'amplitude du signal (en utilisant un réseau en étoile, il faudrait un signal très amplifié pour parcourir la distance que peut parcourir un réseau maillé). Alexandre : Du zigbee classique, même à faible puissance a une porté largement compatible avec l'application visée à mon avis

Il existe différentes normes Wireless. On retient ici le Wi-Fi classique 802.11 qui peut être utilisé en étoile (classique) ou en ad-hoc (mesh, un peu compliqué à mettre en place), et la norme Zigbee 802.15 qui ne peut être utilisé qu'en réseau maillé. Alexandre : On peut utiliser 802.15.4 en réseau point à point. Le tableau ci-dessous montre les avantages et inconvénients de chacun :

Norme	Avantages	Inconvénients
Wi-Fi 802.11	Très répandue, on pourrait ainsi utiliser un routeur ou une box dans une maison comme coordinateur ; Protocole TCP/IP, on pourrait utiliser un serveur DHCP pour faciliter la mise en place du réseau ; Sécurisé par cryptage (WEP ou WPA-PSK)	le type ad-hoc et répéteur est compliqué à mettre en place ; Trame de transmission inadaptée au projet. Le Wi-Fi a été principalement développé pour des transferts à grande vitesse de beaucoup de données, or nous souhaitons juste envoyer 2 ou 3 octets à intervalle de temps assez longue ; Très gourmande en ressource, l'alimentation par pile est inenvisageable avec cette technologie ; La portée diffère suivant la norme a/b/g/n/ac mais, elle sera tout de même très limitée par rapport à ce que peut atteindre le Zigbee ; Très grande probabilité interférences avec d'autres appareils, et risque de saturation du réseau si on utilise la bande des 2.4 GHz (limité à 4 ou 5 appareils sur une box par exemple, trop peu).
Zigbee 802.15	Semblable à une communication série, mais sans-fil ; Trame très simple, nécessite en moyenne que 10% des lignes de codes Wi-Fi ; Portée pouvant atteindre 1 km avec un appareils tout les 30m ; Nous allons utiliser des modules XBee Pro qui ne coûtent que 20€ ; On peut mettre jusque plus de 65 000 appareils en réseau ! ; Consomme très peu. Avec les mode de réveil du module, on peut descendre à 1mA ;	Vitesse limitée à 250 kbit/s, mais très suffisant dans le cadre de notre projet ; La portée entre 2 modules est inférieure à 30 m ;

Conclusion : Nous utiliserons la norme Zigbee et un réseau maillé pour construire le réseau de capteurs. A noter que l'inconvénient majeur est la portée (environ 30 m).

Étape 3 : Matériel nécessaire (pour le prototypage)

Après avoir déterminé l'architecture que nous souhaitons mettre en œuvre, nous pouvons prévoir le matériel dont nous aurons besoin pour le projet :

Matériel	Disponibilité à Polytech ?	Récupéré ?
Une Raspberry Pi et sa carte SD	OUI	Déjà Récupérée
3 modules XBee Série 2 disponibles ici : http://fr.mouser.com/ProductDetail/Digi-International/XB24-BPIT-004/?qs=sGAEpiMZZMtJacPDJcUJY%2fSAm9tUtP8ewOJx%2fVkeOXY%3d	Non, à commander	NON
adaptateurs USB pour XBee	OUI	NON
2 Breadboards		NON
2 shield XBee avec pins permettant de la positionner sur un Breadboard		NON
2 Arduino Uno		NON
Quelques fils, LED, résistances.		NON
2 thermomètres numeriques 18S20 TO-92-3 http://fr.farnell.com/maxim-integrated-products/ds18s20/thermometre-numerique-18s20-to/dp/9724761	Non, à commander	NON

La Raspberry embarquera un serveur Web pour l'application mobile/supervision qui s'adaptera suivant le type de plateforme qui se connectera dessus (smartphone/tablette/PC). Le dashboard sera différent suivant la plateforme. Elle embarquera aussi un serveur de BdD MySQL afin d'y enregistrer les données des modules et des consignes que souhaitent appliquer les utilisateurs finaux (BdD, voir plus bas).

Développement de la structure de données

Après quelques recherches et plusieurs solutions envisagées, nous sommes parvenus à cette architecture :

Pour enregistrer les informations récupérées au niveau des modules, nous aurons besoin d'une structure de données ou BdD. Voici le graphique UML de la BdD :

Nous avons prévu de développer un programme qui tournera sur la Raspberry, celle-ci agira comme un relai. Les différents capteurs enverront la température et les alertes de chute de pression au programme tournant sur la Raspberry (RPI), et la RPI enregistrera ensuite dans la base de donnée les différentes valeurs de température. La base de données offre de nombreux avantages, comme une facilité d'accès tout en étant sécurisée, le stockage régulier de valeurs, la possibilité de suivre la consommation sur plusieurs jours, semaines, années, accessible grâce à des bibliothèques en C, et naturellement en php pour la supervision.