Wiki d'activités IMA - Contributions de l’utilisateur [fr]

Projets IMA5 2014/2015

2015-02-24T10:14:46Z

Froyer : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<tr>
<td>[[P1 Modélisation et commande de l'auto-ignition d'un moteur HCCI]]</td>
<td>Moulé Alexandre / Taché Clément </td>
<td> Anne-Lise Gehin / Jean-Yves Dieulot </td>
<td>[[Fichier:Rapport decembre moule tache.pdf]] </td>
<td>[[Fichier: RapportFinPFE.pdf]]</td>
</tr>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td>[[Fichier:rapport_Z.pdf]]</td>
<td>[[Fichier:Rapport PFE ZIOU HAMZAOUI.pdf]]</td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> [[Fichier:Rapport_Intermédiaire_Royer_Assaieb.pdf]] </td>
<td> [[Fichier:Rapport_Final_PFE_ProjetP6.pdf]] </td>
</tr>
<tr><td>[[P7 Utilisation d'un Robot Nao pour les enfants autistes]]</td>
<td> Rodriguez Loïc/Ismaïl Tahry</td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Projetpfenaomi.pdf]]</td>
<td>[[Fichier:Rapport PFE RodriguezTahry.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td>[[Fichier:Rapport decembre PFE pilulier mercier pinet.pdf]]</td>
<td>[[Fichier:Rapport PFE Pinet Mercier.pdf]]</td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Rapport_MiSoutenance_DESPREZ_HADDAOUI.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td> [[Fichier:Rapport_Intermédiaire_PFE_GAPAS_Rose_Tixier.pdf]]
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td>[[Fichier:rapport_presoutenance.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td> [[Fichier:rapportJebbek.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P19 Contrôle et synchronisation d'instruments en microscopie]]</td>
<td> Simon Duthoit</td>
<td> Samuel Hym </td>
<td></td>
<td>[[Fichier:RapportPFESimonDuthoit.pdf]]</td>
</tr>
<tr><td>[[P21 Balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td> [[ Fichier:ProjetBLE 1 pdf.pdf]]</td>
<td>[[Fichier:Rapport_PFE_Yanmaz_Chalono2.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P21 Bis Prototypage d'interactions localisées et contextualisées ]]</td>
<td> Olivier Tailliez</td>
<td> Thomas Vantroys / Yvan Peter </td>
<td></td>
<td>[[Fichier: PFE_Olivier_Tailliez.pdf‎]]</td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td>[[Fichier:Rapport_intermediaire_Gondry_Meunier.pdf]]</td>
<td>[[Fichier:Rapport_final_PFE_Meunier_Gondry.pdf]]</td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_P24_Deltombe.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P25 SmartMeter]]</td>
<td> Thomas Ederlé / Sylvain Fossaert</td>
<td> Guillaume Renault / Xavier Redon / Alexandre Boé </td>
<td> [[Fichier:RapportFossaertEderle.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P26 Vehicule Electrique ]]</td>
<td> Smain Labdouni / Adnane Jaoui </td>
<td> Arnaud Chielens / Philippe Delarue </td>
<td> [[Fichier:RAPPORT_VE_DEC.pdf]]</td>
<td> [[Fichier:Rapport_pfe_Jaoui_Labdouni_Fevrier.pdf]] </td>
</tr>
<tr><td>[[P27 Controle Direct de Puissance d'un Convertisseur Matriciel ]]</td>
<td> Quentin Pesqueux / Nicolas Alexandre </td>
<td> Philippe Delarue </td>
<td> [[Fichier:PFE_IMA5_MATRIX_CONVERTER_Alexandre_Pesqueux.pdf]]</td>
<td> [[Fichier:Rapport_PFE_Alexandre_Pesqueux.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td> [[Fichier:-BRICOUT MARTIN--Rapport PFE.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / "wireless"]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td> [[Fichier:Rapport_Benjamin_Lafit.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P35 Hack-a-Wii : Emulation de wiimote pour rendre la Wii accessibles aux personnes handicapées ]]</td>
<td> Fabien Violier </td>
<td> Laurent Grisoni </td>
<td> </td>
<td></td>
</tr>
<tr><td>[[P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA ]]</td>
<td> Jérôme Vaessen </td>
<td> Julien Cartigny / Pierrick Buret </td>
<td> [[Fichier:Rapport_VAESSEN_presoutenance.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td> [[Fichier:RapportMaliarMauriceDecembre.pdf]] </td>
<td> [[Fichier:Rapport_final_Maliar_Maurice.pdf]]</td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
<td></td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
<td></td>
</tr>
<tr><td>[[P57 CHRU Lille : Smart Picking]]</td>
<td> Mathieu Bossennec / Florian Caron</td>
<td> Gwénaëlle Maton / Alexandre Boé / Thomas Vantroys </td>
<td></td>
<td></td>
</tr>
<tr>
<td>[[P58 Transformation des spectateurs d’un concert en afficheur géant interactif]]</td>
<td> Hautecoeur Mélanie </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td>[[Fichier : PFE_Rapport_Hautecoeur_Melanie.pdf‎]]</td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td></td>
<td></td>
</tr>
</table>

Fichier:Rapport Final PFE ProjetP6.pdf

2015-02-24T10:13:00Z

Froyer : Rapport final du Projet P6 : Régulation thermique des salles de Polytech. --- Zohour Assaieb & Florian Royer - IMA5 ---

Rapport final du Projet P6 : Régulation thermique des salles de Polytech.

--- Zohour Assaieb & Florian Royer - IMA5 ---

P6 Gestion des flux thermiques du bâtiment Polytech

2015-02-09T17:22:36Z

Froyer : /* Déroulement du projet */

== Liens ==
Il vous est possible de visualiser les différents travaux effectués sur le cloud oneDrive au lien suivant : [http://1drv.ms/1pBsiu6 lien OneDrive]
Il contient notamment les fichiers matlab, le PowerPoint présentation comparatives des offres pour le matériel, les devis et le MS Project contenant l'ensemble des tâches.

== Présentation du projet ==
===Contexte===
Ce projet s'inscrit dans la continuité d'un projet entamé en IMA4 et qui consiste en la réalisation d'un système intelligent de régulation des flux thermiques des radiateurs installés à Polytech Lille pour essayer de réduire au maximum les pertes d'énergie engendrées. Il est réalisé dans le cadre du projet de développement durable initié par la direction de l'école.
===Objectif===
Réaliser un système intelligent capable de réguler le flux thermique d'un radiateur d'une salle à Polytech Lille, afin de maintenir la température de cette dernière à valeur constante, en prenant compte certains paramètres parmi lesquels: planning des salles, données météo ou température extérieure … , ainsi que les situations: fenêtre ouverte, utilisation imprévue de salle ... .

Le résultat final est un démonstrateur sur la plateforme de test constitué du radiateur équipé de l'électrovanne automatisé. Par ailleurs, une interface de supervision doit être établi, une interface homme-machine à destination des utilisateurs de la salle peut aussi être envisageable.
===Cahier des charges===
*Choix logistique et installation de l'équipement: électrovanne, capteurs, API

*Régulation et commande du radiateur : modélisation, simulation, mises en places des algorithmes et implémentation dans l'API

*Supervision : Simulation du système de défaillance et réalisation de l'interface

*Établir la connexion aux données du planning des salles et données météo

*IHM : Réaliser une interface conviviale avec authentification et gestion des modes de chauffage

==Déroulement du projet==
===Semaine 1 : 15/09 - 21/09===
* Analyse du projet

* Réalisation du cahiers des charges et définition des taches

* Etudes comparative des différents équipements

* Comparaisons des entreprises collaboratrices

* Etudes des solutions envisagées

===Semaine 2 : 22/09 - 28/09===
* Réalisation du diagramme Gant du projet

* Commande des composants chez wago

* Communication avec le directeur technique de Polytech pour diverses informations techniques vis-à-vis des radiateurs

* Analyse du système de commande existant ( projet IMA4 )

===Semaine 3 : 29/09 - 05/10===
* Modélisation du système

* Contact avec WAGO pour le suivi de la commande des pièces

----

==Partie Commerciale==

Cette partie du projet consistait à créer un appel d'offre pour savoir quelles entreprises seraient intéressées et ce qu'elles pourraient apporter au projet.
3 entreprises ont été contactées :
* Festo
* Wago
* Schneider Electronics (qui ne se sont pas montrés intéressés).

Festo a proposé du matériel haut de gamme et monté sur mesure, incluant un service technique dédié à Polytech, ce qui se voulait rassurant, mais qui ne nous intéressait pas dans le cadre du projet (ils prévoyaient en effet de développer le programme à embarquer dans l'automate).
Wago a proposé du matériel à monter nous même mais 4000€ de moins que Festo. Au final, un ingénieur Wago est venu une journée expliquer comment l'automate fonctionnait et l'utilisation des bibliothèque du matériel.

'''Conclusion''' : dans cette partie nous avons été confronté à un choix de fournisseur, établissement de bon de commande et étude des datasheets afin de savoir quel matériel on allait recevoir et surtout bien choisir le fournisseur.

==Partie Théorique==

Cette partie du projet avait pour but de démontrer la faisabilité du projet et le gain réel (économique et en confort) de l'utilisation du système qui en résulterait.
L'objectif principale était de modéliser les échanges mécano-thermo-hydroliques mis en jeux dans un système de chauffage afin de pouvoir modéliser l'effet d'une commande régulée.

==Partie Pratique 1 : Mise en place du programme embarqué==

==Partie Pratique 2 : Programmation des interfaces graphiques==

Durant cette partie du projet nous tentons de mettre en place une interface graphique permettant de visualiser les différentes erreurs que pourrait rencontrer le système pour fonctionner (supervision), et nous allons récupérer les valeurs de température de la pièce ainsi que d'ouverture de la vanne sur les 72 dernières heures.

P6 Gestion des flux thermiques du bâtiment Polytech

2015-02-09T17:22:01Z

Froyer : /* Partie Commerciale */

== Liens ==
Il vous est possible de visualiser les différents travaux effectués sur le cloud oneDrive au lien suivant : [http://1drv.ms/1pBsiu6 lien OneDrive]
Il contient notamment les fichiers matlab, le PowerPoint présentation comparatives des offres pour le matériel, les devis et le MS Project contenant l'ensemble des tâches.

== Présentation du projet ==
===Contexte===
Ce projet s'inscrit dans la continuité d'un projet entamé en IMA4 et qui consiste en la réalisation d'un système intelligent de régulation des flux thermiques des radiateurs installés à Polytech Lille pour essayer de réduire au maximum les pertes d'énergie engendrées. Il est réalisé dans le cadre du projet de développement durable initié par la direction de l'école.
===Objectif===
Réaliser un système intelligent capable de réguler le flux thermique d'un radiateur d'une salle à Polytech Lille, afin de maintenir la température de cette dernière à valeur constante, en prenant compte certains paramètres parmi lesquels: planning des salles, données météo ou température extérieure … , ainsi que les situations: fenêtre ouverte, utilisation imprévue de salle ... .

Le résultat final est un démonstrateur sur la plateforme de test constitué du radiateur équipé de l'électrovanne automatisé. Par ailleurs, une interface de supervision doit être établi, une interface homme-machine à destination des utilisateurs de la salle peut aussi être envisageable.
===Cahier des charges===
*Choix logistique et installation de l'équipement: électrovanne, capteurs, API

*Régulation et commande du radiateur : modélisation, simulation, mises en places des algorithmes et implémentation dans l'API

*Supervision : Simulation du système de défaillance et réalisation de l'interface

*Établir la connexion aux données du planning des salles et données météo

*IHM : Réaliser une interface conviviale avec authentification et gestion des modes de chauffage

==Déroulement du projet==
===Semaine 1 : 15/09 - 21/09===
* Analyse du projet

* Réalisation du cahiers des charges et définition des taches

* Etudes comparative des différents équipements

* Comparaisons des entreprises collaboratrices

* Etudes des solutions envisagées

===Semaine 2 : 22/09 - 28/09===
* Réalisation du diagramme Gant du projet

* Commande des composants chez wago

* Communication avec le directeur technique de Polytech pour diverses informations techniques vis-à-vis des radiateurs

* Analyse du système de commande existant ( projet IMA4 )

===Semaine 3 : 29/09 - 05/10===
* Modélisation du système

* Contact avec WAGO pour le suivi de la commande des pièces

----

===Partie Commerciale===

Cette partie du projet consistait à créer un appel d'offre pour savoir quelles entreprises seraient intéressées et ce qu'elles pourraient apporter au projet.
3 entreprises ont été contactées :
* Festo
* Wago
* Schneider Electronics (qui ne se sont pas montrés intéressés).

Festo a proposé du matériel haut de gamme et monté sur mesure, incluant un service technique dédié à Polytech, ce qui se voulait rassurant, mais qui ne nous intéressait pas dans le cadre du projet (ils prévoyaient en effet de développer le programme à embarquer dans l'automate).
Wago a proposé du matériel à monter nous même mais 4000€ de moins que Festo. Au final, un ingénieur Wago est venu une journée expliquer comment l'automate fonctionnait et l'utilisation des bibliothèque du matériel.

'''Conclusion''' : dans cette partie nous avons été confronté à un choix de fournisseur, établissement de bon de commande et étude des datasheets afin de savoir quel matériel on allait recevoir et surtout bien choisir le fournisseur.

===Partie Théorique===

Cette partie du projet avait pour but de démontrer la faisabilité du projet et le gain réel (économique et en confort) de l'utilisation du système qui en résulterait.
L'objectif principale était de modéliser les échanges mécano-thermo-hydroliques mis en jeux dans un système de chauffage afin de pouvoir modéliser l'effet d'une commande régulée.

===Partie Pratique 1 : Mise en place du programme embarqué===

===Partie Pratique 2 : Programmation des interfaces graphiques===

Durant cette partie du projet nous tentons de mettre en place une interface graphique permettant de visualiser les différentes erreurs que pourrait rencontrer le système pour fonctionner (supervision), et nous allons récupérer les valeurs de température de la pièce ainsi que d'ouverture de la vanne sur les 72 dernières heures.

P6 Gestion des flux thermiques du bâtiment Polytech

2015-02-09T17:20:37Z

Froyer : /* Déroulement du projet */

== Liens ==
Il vous est possible de visualiser les différents travaux effectués sur le cloud oneDrive au lien suivant : [http://1drv.ms/1pBsiu6 lien OneDrive]
Il contient notamment les fichiers matlab, le PowerPoint présentation comparatives des offres pour le matériel, les devis et le MS Project contenant l'ensemble des tâches.

== Présentation du projet ==
===Contexte===
Ce projet s'inscrit dans la continuité d'un projet entamé en IMA4 et qui consiste en la réalisation d'un système intelligent de régulation des flux thermiques des radiateurs installés à Polytech Lille pour essayer de réduire au maximum les pertes d'énergie engendrées. Il est réalisé dans le cadre du projet de développement durable initié par la direction de l'école.
===Objectif===
Réaliser un système intelligent capable de réguler le flux thermique d'un radiateur d'une salle à Polytech Lille, afin de maintenir la température de cette dernière à valeur constante, en prenant compte certains paramètres parmi lesquels: planning des salles, données météo ou température extérieure … , ainsi que les situations: fenêtre ouverte, utilisation imprévue de salle ... .

Le résultat final est un démonstrateur sur la plateforme de test constitué du radiateur équipé de l'électrovanne automatisé. Par ailleurs, une interface de supervision doit être établi, une interface homme-machine à destination des utilisateurs de la salle peut aussi être envisageable.
===Cahier des charges===
*Choix logistique et installation de l'équipement: électrovanne, capteurs, API

*Régulation et commande du radiateur : modélisation, simulation, mises en places des algorithmes et implémentation dans l'API

*Supervision : Simulation du système de défaillance et réalisation de l'interface

*Établir la connexion aux données du planning des salles et données météo

*IHM : Réaliser une interface conviviale avec authentification et gestion des modes de chauffage

==Déroulement du projet==
===Semaine 1 : 15/09 - 21/09===
* Analyse du projet

* Réalisation du cahiers des charges et définition des taches

* Etudes comparative des différents équipements

* Comparaisons des entreprises collaboratrices

* Etudes des solutions envisagées

===Semaine 2 : 22/09 - 28/09===
* Réalisation du diagramme Gant du projet

* Commande des composants chez wago

* Communication avec le directeur technique de Polytech pour diverses informations techniques vis-à-vis des radiateurs

* Analyse du système de commande existant ( projet IMA4 )

===Semaine 3 : 29/09 - 05/10===
* Modélisation du système

* Contact avec WAGO pour le suivi de la commande des pièces

===Partie Commerciale===

Cette partie du projet consistait à créer un appel d'offre pour savoir quelles entreprises seraient intéressées et ce qu'elles pourraient apporter au projet.
3 entreprises ont été contactées :
* Festo
* Wago
* Schneider Electronics (qui ne se sont pas montrés intéressés).

Festo a proposé du matériel haut de gamme et monté sur mesure, incluant un service technique dédié à Polytech, ce qui se voulait rassurant, mais qui ne nous intéressait pas dans le cadre du projet (ils prévoyaient en effet de développer le programme à embarquer dans l'automate).
Wago a proposé du matériel à monter nous même mais 4000€ de moins que Festo. Au final, un ingénieur Wago est venu une journée expliquer comment l'automate fonctionnait et l'utilisation des bibliothèque du matériel.
'''
Conclusion :''' dans cette partie nous avons été confronté à un choix de fournisseur, établissement de bon de commande et étude des datasheets afin de savoir quel matériel on allait recevoir et surtout bien choisir le fournisseur.

===Partie Théorique===

Cette partie du projet avait pour but de démontrer la faisabilité du projet et le gain réel (économique et en confort) de l'utilisation du système qui en résulterait.
L'objectif principale était de modéliser les échanges mécano-thermo-hydroliques mis en jeux dans un système de chauffage afin de pouvoir modéliser l'effet d'une commande régulée.

===Partie Pratique 1 : Mise en place du programme embarqué===

===Partie Pratique 2 : Programmation des interfaces graphiques===

Durant cette partie du projet nous tentons de mettre en place une interface graphique permettant de visualiser les différentes erreurs que pourrait rencontrer le système pour fonctionner (supervision), et nous allons récupérer les valeurs de température de la pièce ainsi que d'ouverture de la vanne sur les 72 dernières heures.

Projets IMA5 2014/2015

2014-12-17T20:50:25Z

Froyer : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<tr>
<td>[[P1 Modélisation et commande de l'auto-ignition d'un moteur HCCI]]</td>
<td>Moulé Alexandre / Taché Clément </td>
<td> Anne-Lise Gehin / Jean-Yves Dieulot </td>
<td>[[Fichier:Rapport decembre moule tache.pdf]] </td>
</tr>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td>[[Fichier:rapport_Z.pdf]]</td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> [[Fichier:Rapport_Intermédiaire_Royer_Assaieb.pdf]] </td>
</tr>
<tr><td>[[P7 Utilisation d'un Robot Nao pour les enfants autistes]]</td>
<td> Rodriguez Loïc/Ismaïl Tahry</td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Projetpfenaomi.pdf]]</td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td>[[Fichier:Rapport decembre PFE pilulier mercier pinet.pdf]]</td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Rapport_MiSoutenance_DESPREZ_HADDAOUI.pdf]]</td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td>[[Fichier:rapport_presoutenance.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td> [[Fichier:rapportJebbek.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P21 Balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td> [[ Fichier:ProjetBLE 1 pdf.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td>[[Fichier:Rapport_intermediaire_Gondry_Meunier.pdf]]</td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_P24_Deltombe.pdf]]</td>
</tr>
<tr><td>[[P25 SmartMeter]]</td>
<td> Thomas Ederlé / Sylvain Fossaert</td>
<td> Guillaume Renault / Xavier Redon / Alexandre Boé </td>
<td> [[Fichier:RapportFossaertEderle.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P26 Vehicule Electrique ]]</td>
<td> Smain Labdouni / Adnane Jaoui </td>
<td> Arnaud Chielens / Philippe Delarue </td>
<td> [[Fichier:RAPPORT_VE_DEC.pdf]]</td>
</tr>
<tr><td>[[P27 Controle Direct de Puissance d'un Convertisseur Matriciel ]]</td>
<td> Quentin Pesqueux / Nicolas Alexandre </td>
<td> Philippe Delarue </td>
<td> [[Fichier:PFE_IMA5_MATRIX_CONVERTER_Alexandre_Pesqueux.pdf]]</td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / "wireless"]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td> [[Fichier:Rapport_Benjamin_Lafit.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA ]]</td>
<td> Jérôme Vaessen </td>
<td> Julien Cartigny / Pierrick Buret </td>
<td> [[Fichier:Rapport_VAESSEN_presoutenance.pdf]] </td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td> [[Fichier:RapportMaliarMauriceDecembre.pdf]] </td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
</tr>
<tr><td>[[P57 CHRU Lille : Smart Picking]]</td>
<td> Mathieu Bossennec / Florian Caron</td>
<td> Gwénaëlle Maton / Alexandre Boé / Thomas Vantroys </td>
<td></td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td></td>
</tr>
</table>

Fichier:Rapport Intermédiaire Royer Assaieb.pdf

2014-12-17T20:48:24Z

Froyer :

P6 Gestion des flux thermiques du bâtiment Polytech

2014-10-13T12:26:15Z

Froyer : /* Liens */

P6 Gestion des flux thermiques du bâtiment Polytech

2014-10-13T12:24:32Z

Froyer : /* Présentation du projet */

== Liens ==
Il vous est possible de visualiser les différents travaux effectués sur le cloud oneDrive au lien suivant : [http://1drv.ms/1pBsiu6]
Il contient notamment les fichiers matlab, le PowerPoint présentation comparatives des offres pour le matériel, les devis et le MS Project contenant l'ensemble des tâches.

== Présentation du projet ==
===Contexte===
Ce projet s'inscrit dans la continuité d'un projet entamé en IMA4 et qui consiste en la réalisation d'un système intelligent de régulation des flux thermiques des radiateurs installés à Polytech Lille pour essayer de réduire au maximum les pertes d'énergie engendrées. Il est réalisé dans le cadre du projet de développement durable initié par la direction de l'école.
===Objectif===
Réaliser un système intelligent capable de réguler le flux thermique d'un radiateur d'une salle à Polytech Lille, afin de maintenir la température de cette dernière à valeur constante, en prenant compte certains paramètres parmi lesquels: planning des salles, données météo ou température extérieure … , ainsi que les situations: fenêtre ouverte, utilisation imprévue de salle ... .

Le résultat final est un démonstrateur sur la plateforme de test constitué du radiateur équipé de l'électrovanne automatisé. Par ailleurs, une interface de supervision doit être établi, une interface homme-machine à destination des utilisateurs de la salle peut aussi être envisageable.
===Cahier des charges===
*Choix logistique et installation de l'équipement: électrovanne, capteurs, API

*Régulation et commande du radiateur : modélisation, simulation, mises en places des algorithmes et implémentation dans l'API

*Supervision : Simulation du système de défaillance et réalisation de l'interface

*Établir la connexion aux données du planning des salles et données météo

*IHM : Réaliser une interface conviviale avec authentification et gestion des modes de chauffage

==Déroulement du projet==
===Semaine 1 : 15/09 - 21/09===
* Analyse du projet

* Réalisation du cahiers des charges et définition des taches

* Etudes comparative des différents équipements

* Comparaisons des entreprises collaboratrices

* Etudes des solutions envisagées

===Semaine 2 : 22/09 - 28/09===
* Réalisation du diagramme Gant du projet

* Commande des composants chez wago

* Communication avec le directeur technique de Polytech pour diverses informations techniques vis-à-vis des radiateurs

* Analyse du système de commande existant ( projet IMA4 )

===Semaine 3 : 29/09 - 05/10===
* Modélisation du système

* Contact avec WAGO pour le suivi de la commande des pièces

Consommation maison

2014-06-18T15:44:35Z

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

<include nopre noesc src="/home/pedago/pimasc/include/video-MesureConsommation-iframe.html" />
__TOC__
 
== Fichiers ==

* IHM visible sur http://renard.familyds.com/projet
* Codes téléchargeables : [[Fichier:Codes_finaux.zip]]
* Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA

== É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.
* Avoir une supervision du système.
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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! Matériel !! Disponibilité à Polytech ? !! Récupéré ?
|-
|Une Raspberry Pi et sa carte SD
|OUI
|RENDU
|-
|3 modules XBee '''Série 2''' disponibles ici : http://fr.mouser.com/ProductDetail/Digi-International/XB24-BPIT-004/?qs=sGAEpiMZZMtJacPDJcUJY%2fSAm9tUtP8ewOJx%2fVkeOXY%3d
|Commandé
|RENDU
|-
|adaptateurs USB pour XBee
|OUI
|RENDU
|-
|2 Breadboards
|
|RENDU
|-
|2 shield XBee avec pins permettant de la positionner sur un Breadboard http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|RENDU
|-
|2 Arduino Uno
|
|RENDU
|-
|Quelques fils, LED, résistances.
|
|RENDU
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|Commandé
|RENDU
|-
|}

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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

----

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

==== semaine 1 Mars ====

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

==== semaine 2 Mars ====

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

==== semaine 3 Mars ====

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

==== semaine 4 de Mars ====

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

==== première semaine de Avril ====

===== Le design de la carte =====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

----

=== Partie Module de chauffage ===

Cette partie a été traité sur les 3 dernières semaines du projet en parallèle avec la partie IHM et Réseau de Capteur.
Nous avons élaboré une carte sur laquelle se branchera le réseau EDF, le radiateur et la consigne délivrée par une carte similaire à celle cu capteur mais sans celui-ci.

[[Fichier:CommandeRad.jpg]]

La carte sera aussi capable de ce servir du réseau EDF pour alimenter le µContrôleur, nous avons donc prévu une alimentation (de type transformateur) pour passer du 220V AC à 3.3V DC. Pour plus de sécurité, il est important d'avoir un régulateur de tension en aval, d'où le régulateur sur le module capteur (Cf. Partie réseaux de capteurs).

[[Fichier:Schematic-CBT-correct.JPG]]

Fonctionnement de la carte :
* Alimentation du transformateur par la phase et le neutre
* Un fusible est placé sur la phase en cas de pépins
* En parallèle du 220V on alimente aussi :
** Le radiateur (Phase, Neutre et Terre)
** L'optocoupleur (sur les broches 4 et 5) qui n'est rien d'autre qu'un interrupteur.
* Les Pins 7 et 9 de l'alim permettent d'alimenter le µC en +3.3V.
* Le PIN C de la partie Ultra Basse Tension (UBT) est un PIN d'entré ici (et de sortie %au µC). Ce PIN détermine si la Diode de l'optocoupleur sera allumée ou éteinte.
* Concernant l'optocoupleur : Il s'agit d'un composant permettant de bien distinguer la partie UBT de la carte, de la partie BT. Le photoTriac n'est passant que si la diode (PIN 1 et 2) est allumée.
* L'optocoupleur ne supportant pas les courants élevés (limité à 1A), on utilise un triac de puissance (20A sur 600V). La gâche en sortie de l'optocoupleur est donc soit à 0A soit à +8mA). Sur 0, le triac n'est pas passant, sur 8mA, il est passant.

On obtient alors soit aucun signal (marche) sur le fil pilote, soit un signal pleine alternance (arrêt).

N.B: Une erreur de conception : La gâche du triac de puissance alimentée par un voltage de 3.3V, la masse est "flottante" dans ce cas, le Triac est tjs à l'état bas. De plus le circuit UBT et BT ne sont pas séparé, l'optocoupleur ne sert à rien...

[[Fichier:Schematic-CBT.JPG]]

== Bilan ==
Le module capteur envoie régulièrement des informations à destination de la Raspberry, qui est capable de les
traiter. Il est également ajouté dans la Base de Donnée sur intervention de l'utilisateur (appui d'un bouton poussoir sur un module).
La Raspberry peut envoyer et recevoir des informations avec les modules chauffages et capteurs.
Mais le code de réception/interpretation d'une trame API du coté Arduino reste à peaufiner, (ils ne donnent pas encore
,dans certains cas, des résultats constamment exploitables).

= Matériel récupéré =

* 6 arduino UNO
* 8 xbee
* 3 adaptateurs simple
* 1 adaptateur usb
* 3 shield xbee
* 1 raspberry
* 1 carte "maison" pour le projet
* 1 "boitier" secteur/banane
* 1 modem/routeur WiFi ADSL

Consommation maison

2014-06-18T15:43:50Z

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

<include nopre noesc src="/home/pedago/pimasc/include/video-MesureConsommation-iframe.html" />
__TOC__
 
== Fichiers ==

* IHM visible sur http://renard.familyds.com/projet
* Codes téléchargeables : [[Fichier:Codes_finaux.zip]]
* Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA

== É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.
* Avoir une supervision du système.
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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! Matériel !! Disponibilité à Polytech ? !! Récupéré ?
|-
|Une Raspberry Pi et sa carte SD
|OUI
|RENDU
|-
|3 modules XBee '''Série 2''' disponibles ici : http://fr.mouser.com/ProductDetail/Digi-International/XB24-BPIT-004/?qs=sGAEpiMZZMtJacPDJcUJY%2fSAm9tUtP8ewOJx%2fVkeOXY%3d
|Commandé
|RENDU
|-
|adaptateurs USB pour XBee
|OUI
|RENDU
|-
|2 Breadboards
|
|RENDU
|-
|2 shield XBee avec pins permettant de la positionner sur un Breadboard http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|RENDU
|-
|2 Arduino Uno
|
|RENDU
|-
|Quelques fils, LED, résistances.
|
|RENDU
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|Commandé
|RENDU
|-
|}

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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

----

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

==== semaine 1 Mars ====

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

==== semaine 2 Mars ====

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

==== semaine 3 Mars ====

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

==== semaine 4 de Mars ====

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

==== première semaine de Avril ====

===== Le design de la carte =====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

----

=== Partie Module de chauffage ===

Cette partie a été traité sur les 3 dernières semaines du projet en parallèle avec la partie IHM et Réseau de Capteur.
Nous avons élaboré une carte sur laquelle se branchera le réseau EDF, le radiateur et la consigne délivrée par une carte similaire à celle cu capteur mais sans celui-ci.

[[Fichier:CommandeRad.jpg]]

La carte sera aussi capable de ce servir du réseau EDF pour alimenter le µContrôleur, nous avons donc prévu une alimentation (de type transformateur) pour passer du 220V AC à 3.3V DC. Pour plus de sécurité, il est important d'avoir un régulateur de tension en aval, d'où le régulateur sur le module capteur (Cf. Partie réseaux de capteurs).

[[Fichier:Schematic-CBT-correct.JPG]]

Fonctionnement de la carte :
* Alimentation du transformateur par la phase et le neutre
* Un fusible est placé sur la phase en cas de pépins
* En parallèle du 220V on alimente aussi :
** Le radiateur (Phase, Neutre et Terre)
** L'optocoupleur (sur les broches 4 et 5) qui n'est rien d'autre qu'un interrupteur.
* Les Pins 7 et 9 de l'alim permettent d'alimenter le µC en +3.3V.
* Le PIN C de la partie Ultra Basse Tension (UBT) est un PIN d'entré ici (et de sortie %au µC). Ce PIN détermine si la Diode de l'optocoupleur sera allumée ou éteinte.
* Concernant l'optocoupleur : Il s'agit d'un composant permettant de bien distinguer la partie UBT de la carte, de la partie BT. Le photoTriac n'est passant que si la diode (PIN 1 et 2) est allumée.
* L'optocoupleur ne supportant pas les courants élevés (limité à 1A), on utilise un triac de puissance (20A sur 600V). La gâche en sortie de l'optocoupleur est donc soit à 0A soit à +8mA). Sur 0, le triac n'est pas passant, sur 8mA, il est passant.

On obtient alors soit aucun signal (marche) sur le fil pilote, soit un signal pleine alternance (arrêt).

N.B: Une erreur de conception : La gâche du triac de puissance alimentée par un voltage de 3.3V, la masse est "flottante" dans ce cas, le Triac est tjs à l'état bas. De plus le circuit UBT et BT ne sont pas séparé, l'optocoupleur ne sert à rien...

[[Fichier:Schematic-CBT.JPG]]

== Bilan ==
Le module capteur envoie régulièrement des informations à destination de la Raspberry, qui est capable de les
traiter. Il est également ajouté dans la Base de Donnée sur intervention de l'utilisateur (appui d'un bouton poussoir sur un module).
La Raspberry peut envoyer et recevoir des informations avec les modules chauffages et capteurs.
Mais le code de réception/interpretation d'une trame API du coté Arduino reste à peaufiner, (ils ne donnent pas encore
,dans certains cas, des résultats constamment exploitables).

= Matériel récupéré =

* 6 arduino UNO
* 8 xbee
* 3 adaptateurs simple
* 1 adaptateur usb
* 3 shield xbee
* 1 raspberry
* 1 carte "maison" pour le projet
* 1 "boitier" secteur/banane
* 1 modem/routeur WiFi ADSL

Consommation maison

2014-06-17T19:38:18Z

Froyer : /* Fichiers */

<include nopre noesc src="/home/pedago/pimasc/include/video-MesureConsommation-iframe.html" />
__TOC__
 
== Fichiers ==

* IHM visible sur http://renard.familyds.com/projet
* Codes téléchargeables : [[Fichier:Codes_finaux.zip]]
* Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA

== É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.
* Avoir une supervision du système.
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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

----

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

==== semaine 1 Mars ====

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

==== semaine 2 Mars ====

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

==== semaine 3 Mars ====

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

==== semaine 4 de Mars ====

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

==== première semaine de Avril ====

===== Le design de la carte =====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

----

=== Partie Module de chauffage ===

Cette partie a été traité sur les 3 dernières semaines du projet en parallèle avec la partie IHM et Réseau de Capteur.
Nous avons élaboré une carte sur laquelle se branchera le réseau EDF, le radiateur et la consigne délivrée par une carte similaire à celle cu capteur mais sans celui-ci.

[[Fichier:CommandeRad.jpg]]

La carte sera aussi capable de ce servir du réseau EDF pour alimenter le µContrôleur, nous avons donc prévu une alimentation (de type transformateur) pour passer du 220V AC à 3.3V DC. Pour plus de sécurité, il est important d'avoir un régulateur de tension en aval, d'où le régulateur sur le module capteur (Cf. Partie réseaux de capteurs).

[[Fichier:Schematic-CBT-correct.JPG]]

Fonctionnement de la carte :
* Alimentation du transformateur par la phase et le neutre
* Un fusible est placé sur la phase en cas de pépins
* En parallèle du 220V on alimente aussi :
** Le radiateur (Phase, Neutre et Terre)
** L'optocoupleur (sur les broches 4 et 5) qui n'est rien d'autre qu'un interrupteur.
* Les Pins 7 et 9 de l'alim permettent d'alimenter le µC en +3.3V.
* Le PIN C de la partie Ultra Basse Tension (UBT) est un PIN d'entré ici (et de sortie %au µC). Ce PIN détermine si la Diode de l'optocoupleur sera allumée ou éteinte.
* Concernant l'optocoupleur : Il s'agit d'un composant permettant de bien distinguer la partie UBT de la carte, de la partie BT. Le photoTriac n'est passant que si la diode (PIN 1 et 2) est allumée.
* L'optocoupleur ne supportant pas les courants élevés (limité à 1A), on utilise un triac de puissance (20A sur 600V). La gâche en sortie de l'optocoupleur est donc soit à 0A soit à +8mA). Sur 0, le triac n'est pas passant, sur 8mA, il est passant.

On obtient alors soit aucun signal (marche) sur le fil pilote, soit un signal pleine alternance (arrêt).

N.B: Une erreur de conception : La gâche du triac de puissance alimentée par un voltage de 3.3V, la masse est "flottante" dans ce cas, le Triac est tjs à l'état bas. De plus le circuit UBT et BT ne sont pas séparé, l'optocoupleur ne sert à rien...

[[Fichier:Schematic-CBT.JPG]]

== Bilan ==
Le module capteur envoie régulièrement des informations à destination de la Raspberry, qui est capable de les
traiter. Il est également ajouté dans la Base de Donnée sur intervention de l'utilisateur (appui d'un bouton poussoir sur un module).
La Raspberry peut envoyer et recevoir des informations avec les modules chauffages et capteurs.
Mais le code de réception/interpretation d'une trame API du coté Arduino reste à peaufiner, (ils ne donnent pas encore
,dans certains cas, des résultats constamment exploitables).

= Matériel récupéré =

* 6 arduino UNO
* 8 xbee
* 3 adaptateurs simple
* 1 adaptateur usb
* 3 shield xbee
* 1 raspberry
* 1 carte "maison" pour le projet
* 1 "boitier" secteur/banane
* 1 modem/routeur WiFi ADSL

Fichier:Codes finaux.zip

2014-06-17T19:31:43Z

Froyer : a téléversé une nouvelle version de « Fichier:Codes finaux.zip » : Version du 23 avril 2014 à 20:17 rétablie

Fichier:Codes finaux.zip

2014-06-17T19:31:10Z

Froyer : a téléversé une nouvelle version de « Fichier:Codes finaux.zip »

Discussion utilisateur:Froyer

2014-06-16T22:17:23Z

Froyer : Page créée avec « Erreur lors du dépôt à la date butoir, désolé pour le désagrément »

Erreur lors du dépôt à la date butoir, désolé pour le désagrément

Fichier:Royer-Gondry.pdf

2014-06-16T22:15:48Z

Froyer :

Consommation maison

2014-04-22T12:33:31Z

Froyer : /* Introduction */

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

Encadrants :
M. Alexandre Boé
M. Thomas Vantroy

----

== Fichiers ==

* IHM visible sur http://renard.familyds.com/projet
* Codes téléchargeables :
* Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA

== É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.
* Avoir une supervision du système.
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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

----

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

==== semaine 1 Mars ====

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

==== semaine 2 Mars ====

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

==== semaine 3 Mars ====

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

==== semaine 4 de Mars ====

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

==== première semaine de Avril ====

===== Le design de la carte =====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

----

=== Partie Module de chauffage ===

Cette partie a été traité sur les 3 dernières semaines du projet en parallèle avec la partie IHM et Réseau de Capteur.
Nous avons élaboré une carte sur laquelle se branchera le réseau EDF, le radiateur et la consigne délivrée par une carte similaire à celle cu capteur mais sans celui-ci.

[[Fichier:CommandeRad.jpg]]

La carte sera aussi capable de ce servir du réseau EDF pour alimenter le µContrôleur, nous avons donc prévu une alimentation (de type transformateur) pour passer du 220V AC à 3.3V DC. Pour plus de sécurité, il est important d'avoir un régulateur de tension en aval, d'où le régulateur sur le module capteur (Cf. Partie réseaux de capteurs).

[[Fichier:Schematic-CBT-correct.JPG]]

Fonctionnement de la carte :
* Alimentation du transformateur par la phase et le neutre
* Un fusible est placé sur la phase en cas de pépins
* En parallèle du 220V on alimente aussi :
** Le radiateur (Phase, Neutre et Terre)
** L'optocoupleur (sur les broches 4 et 5) qui n'est rien d'autre qu'un interrupteur.
* Les Pins 7 et 9 de l'alim permettent d'alimenter le µC en +3.3V.
* Le PIN C de la partie Ultra Basse Tension (UBT) est un PIN d'entré ici (et de sortie %au µC). Ce PIN détermine si la Diode de l'optocoupleur sera allumée ou éteinte.
* Concernant l'optocoupleur : Il s'agit d'un composant permettant de bien distinguer la partie UBT de la carte, de la partie BT. Le photoTriac n'est passant que si la diode (PIN 1 et 2) est allumée.
* L'optocoupleur ne supportant pas les courants élevés (limité à 1A), on utilise un triac de puissance (20A sur 600V). La gâche en sortie de l'optocoupleur est donc soit à 0A soit à +8mA). Sur 0, le triac n'est pas passant, sur 8mA, il est passant.

On obtient alors soit aucun signal (marche) sur le fil pilote, soit un signal pleine alternance (arrêt).

N.B: Une erreur de conception : La gâche du triac de puissance alimentée par un voltage de 3.3V, la masse est "flottante" dans ce cas, le Triac est tjs à l'état bas. De plus le circuit UBT et BT ne sont pas séparé, l'optocoupleur ne sert à rien...

[[Fichier:Schematic-CBT.JPG]]

Consommation maison

2014-04-22T12:32:01Z

Froyer : /* Avancement du projet */

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

Encadrants :
M. Alexandre Boé
M. Thomas Vantroy

----

== Fichiers ==

* IHM visible sur http://renard.familyds.com/projet
* Codes téléchargeables :
* Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : [http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA]

== É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.
* Avoir une supervision du système.
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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

----

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

==== semaine 1 Mars ====

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

==== semaine 2 Mars ====

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

==== semaine 3 Mars ====

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

==== semaine 4 de Mars ====

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

==== première semaine de Avril ====

===== Le design de la carte =====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

----

=== Partie Module de chauffage ===

Cette partie a été traité sur les 3 dernières semaines du projet en parallèle avec la partie IHM et Réseau de Capteur.
Nous avons élaboré une carte sur laquelle se branchera le réseau EDF, le radiateur et la consigne délivrée par une carte similaire à celle cu capteur mais sans celui-ci.

[[Fichier:CommandeRad.jpg]]

La carte sera aussi capable de ce servir du réseau EDF pour alimenter le µContrôleur, nous avons donc prévu une alimentation (de type transformateur) pour passer du 220V AC à 3.3V DC. Pour plus de sécurité, il est important d'avoir un régulateur de tension en aval, d'où le régulateur sur le module capteur (Cf. Partie réseaux de capteurs).

[[Fichier:Schematic-CBT-correct.JPG]]

Fonctionnement de la carte :
* Alimentation du transformateur par la phase et le neutre
* Un fusible est placé sur la phase en cas de pépins
* En parallèle du 220V on alimente aussi :
** Le radiateur (Phase, Neutre et Terre)
** L'optocoupleur (sur les broches 4 et 5) qui n'est rien d'autre qu'un interrupteur.
* Les Pins 7 et 9 de l'alim permettent d'alimenter le µC en +3.3V.
* Le PIN C de la partie Ultra Basse Tension (UBT) est un PIN d'entré ici (et de sortie %au µC). Ce PIN détermine si la Diode de l'optocoupleur sera allumée ou éteinte.
* Concernant l'optocoupleur : Il s'agit d'un composant permettant de bien distinguer la partie UBT de la carte, de la partie BT. Le photoTriac n'est passant que si la diode (PIN 1 et 2) est allumée.
* L'optocoupleur ne supportant pas les courants élevés (limité à 1A), on utilise un triac de puissance (20A sur 600V). La gâche en sortie de l'optocoupleur est donc soit à 0A soit à +8mA). Sur 0, le triac n'est pas passant, sur 8mA, il est passant.

On obtient alors soit aucun signal (marche) sur le fil pilote, soit un signal pleine alternance (arrêt).

N.B: Une erreur de conception : La gâche du triac de puissance alimentée par un voltage de 3.3V, la masse est "flottante" dans ce cas, le Triac est tjs à l'état bas. De plus le circuit UBT et BT ne sont pas séparé, l'optocoupleur ne sert à rien...

[[Fichier:Schematic-CBT.JPG]]

Fichier:Schematic-CBT.JPG

2014-04-22T12:31:49Z

Froyer :

Fichier:Schematic-CBT-correct.JPG

2014-04-22T12:17:39Z

Froyer :

Fichier:CommandeRad.jpg

2014-04-22T12:13:06Z

Froyer :

Consommation maison

2014-04-22T12:06:55Z

Froyer : /* Avancement du projet */

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

Encadrants :
M. Alexandre Boé
M. Thomas Vantroy

----

== Fichiers ==

* IHM visible sur http://renard.familyds.com/projet
* Codes téléchargeables :
* Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : [http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA]

== É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.
* Avoir une supervision du système.
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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

==== semaine 1 Mars ====

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

==== semaine 2 Mars ====

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

==== semaine 3 Mars ====

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

==== semaine 4 de Mars ====

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

==== première semaine de Avril ====

===== Le design de la carte =====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

Consommation maison

2014-04-16T11:44:56Z

Froyer : /* Objectifs principaux */

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

Encadrants :
M. Alexandre Boé
M. Thomas Vantroy

----

== Fichiers ==

* IHM visible sur http://renard.familyds.com/projet
* Codes téléchargeables :
* Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : [http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA]

== É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.
* Avoir une supervision du système.
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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

=== semaine 1 Mars ===

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

=== semaine 2 Mars ===

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

=== semaine 3 Mars ===

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

=== semaine 4 de Mars ===

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

=== première semaine de Avril ===

==== Le design de la carte ====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

Consommation maison

2014-04-16T01:17:57Z

Froyer : /* Fichiers */

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

Encadrants :
M. Alexandre Boé
M. Thomas Vantroy

----

== Fichiers ==

* IHM visible sur http://renard.familyds.com/projet
* Codes téléchargeables :
* Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : [http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA]

== É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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

=== semaine 1 Mars ===

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

=== semaine 2 Mars ===

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

=== semaine 3 Mars ===

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

=== semaine 4 de Mars ===

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

=== première semaine de Avril ===

==== Le design de la carte ====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

Consommation maison

2014-04-16T01:17:21Z

Froyer : /* Introduction */

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

Encadrants :
M. Alexandre Boé
M. Thomas Vantroy

----

== Fichiers ==

IHM visible sur [http://renard.familyds.com/projet]
Codes téléchargeables :
Rapport écrit : [[Fichier:Royer-Gondry.pdf]]

==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 : [http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA]

== É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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

=== semaine 1 Mars ===

Souhaitant créer un réseau maillé, notre choix s’est porté sur l’utilisation de Xbee Serie 2.
Un réseau Xbee 2 se définit par un channel et un PAN ID (Personal Area Network).
Les Xbee peuvent y jouer 3 types de rôle : Coordinateur, Routeur, et End Device (dispositif en fin de ligne).

*Le Coordinateur est « le médecin » du réseau, c’est celui qui :
**Attribue les adresses logiques.
**Assaissinit le réseau, lorsqu’un périphérique, il redistribue son adresse logique à un autre périphérique existant et lui attribue une autre adresse lorsqu’il rentre dans le réseau.

*Le Routeur envoie des informations le concernant et sert de relais pour les End Device qui sont trop éloignés des autres modules pour communiquer avec eux.

*Le End Device, joue un rôle mineur dans le réseau il envoie ses propres messages router ceux des autres.

Nous avons décidé que les modules chauffage seront des routeurs, (de par leur rôle les routeurs ne sont pas censés être endormis).
Les modules capteur seront des end devices. La Raspberry sera le coordinateur.

Durant les séances précédentes, nous travaillons avec les Xbee Series 1, et avions commencé à expérimenter les communications en mode transparent, et à nous pencher sur les communications en API.
Nous recevons la commande des Xbee Series 2, il faut flasher leur firmware, si nous voulons pouvoir communiquer avec ces modules en API.
Pour cela nous utilisons X-CTU, un utilitaire jouant le rôle de gestionnaire de firmware, de moniteur série et de configuration des modules Xbee.
Un choix s'impose : les modules ne peuvent pas être utilisé à la fois avec des commandes AT ou à la fois avec des commandes API.
Nous choisissons de flasher les modules avec des firmwares exclusivement API.

Pour la configuration des Xbee, les principaux registres qui ont été concernés sont

*registre SM=1
Sleep Mode veille activé sur stimulus de la broche DTR)
*registre ID=222
Configure le PAN ID : Personal Area Network Identifiant, indique l'Id du réseau que le module rejoindra de préférence )
*registre CH
Le Channel, sur les Series 2, ce registre est en lecture seule, le coordinateur scanne le réseau et choisi le canal optimal, les
autres Xbee le rejoindront sur son canal, grâce au choix du PAN ID (222) et à la présence d'un coordinateur sur le réseau
Tout ce qui concerne les adresses MY, sont des adresses logiques donc nous n'y avons pas accès, étant donné que c'est le coordinateur qui s'occupe de les gérer.

=== semaine 2 Mars ===

Elaboration des fonctions en C et en Arduino permettant l'envoi et la réception de données par trame sur le prototype Arduino et sur la Raspberry.
Nous avons été ralentis sur cette partie.
Ces fonctions ne fonctionnaient pas pour plusieurs raisons, d'abord électriques, le Xbee pouvait envoyer mais jamais recevoir, cela venait du fait qu'il était endormi et
réveillé à une fréquence trés élevé. (les fonctions de mise en veille et de réveil n'étant pas encore utilisée du Xbee)
Un montage en strong pull up était indispensable pour réveiller constamment le module Xbee.
Une autre raison, était la construction de la trame. Il y avait des imperfections dans notre compréhension du protocole.

Comme nous avions l'intention de réaliser une carte du module capteur, nous avancions en parallèle, sur le design de la carte.

[[Fichier:Schematic premiere version.png|400px]]

=== semaine 3 Mars ===

Aprés avoir des primitives de communications fonctionnelles, nous avons implémenté et tester sur l'Arduino, le mode de Veille Watchdog. L'interruption d'ajout, provoqué par un bouton poussoir, elle permet de réveiller manuellement un module afin d'envoyer, en réaction, un message à destination du coordinateur, ce message lui indique que le module doit être ajouté dans la base de donnée. Cela permet dans une utilisation ultérieure de rafraichir plus vite, la mesure de la température

=== semaine 4 de Mars ===

Grâce à l'implémentation de fonctions C d'ajout dans la base de données, au niveau du programme tournant sur la Raspberry,
le prototype du module de capteur envoie une mesure, et cette mesure est stockée dans la base de donnée.
La phase de prototype est quasiment finie, tout comme l'essentiel de la partie logicielle.
Nous rencontrons un problème au niveau de la programmation de l'atmega 328p.
Nous essayons les solutions suivantes:

Téléverser un programme sur un Arduino Uno utilisé en programmateur ISP et relié à l'atmega328p.
Téléverser un programme à l'aide d'un programmateur AVR ISP Mkll toujours à partir de l'environnement Arduino sur l'atmega328p.
Nous décidons alors de programmer un Arduino pour ensuite en retirer l'atmega328P.
Cependant pour des soucis d'autonomie, nous souhaitons modifier les fusibles "les fuses" pour changer
la fréquence de fonctionnement ainsi que la clock source. En effet, l'atmega sur un Arduino est configuré pour fonctionner
avec une clock externe 16MHz.
Après utilisations d'AVR Burn O Mat et d'AVR studio, deux utilitaires pour uploader et flasher les produits AVR, des messages d'erreurs nous indiquent que la source du problème se situe plutôt du coté de nos drivers USB.
Après plusieurs téléchargement de drivers et manipulations, il n'y a pas de solution.

Nous incluons alors sur la carte des connecteurs, destinés à la reprogrammation ISP dans le cas, où nous réglerons le problème.

=== première semaine de Avril ===

==== Le design de la carte ====

Voici le schematic de la carte avec son régulateur de tension externe, nous avons corrigé certaines choses, comme l'ajout
d'un crystal externe à 16 MHz pour pouvoir utiliser l'atmega328p en dépit du problème d'upload du programme.

Voici, la version finale de la carte.

[[Fichier:Schematic_avec_regulateur_et_crystal.png|400px]] Le schéma complet de la carte avec des mises à jour, comme l'ajout du Crystal, le régulateur de tension, des connecteurs pour la programmer directement, ou ajouter des capteurs numériques.

[[Fichier:top.png|400px]] La surface Top du PCB

[[Fichier:bottom.png|400px]] La surface Bottom du PCB

Voici la version finale de la carte,

[[Fichier:Cartefinale.jpg|800px]]

Testé sur Alimentation Stabilisée, puis ensuite directement sur pile.
En veille la carte consomme 0,8 mA , en communication la carte consomme 25mA.
Si elle se met en veille toutes les 16 secondes, on peut prétendre à une autonomie théorique de 7 mois, avec
2 piles AA 1,5 V (2*2000mAh).
Ici, nous n'avons pas eu des relevés de températures corrects avec l'alimentation parasite du capteur, donc nous l'alimentons
un certain moment avant de l'interroger, ceci impactera sur l'autonomie de la carte.
En ayant réussi à flasher les fusibles de l'atmega pour abaisser sa fréquence de fonctionnement, nous aurions baissé encore plus significativement sa consommation

Consommation maison

2014-04-15T20:22:30Z

Froyer : /* A concevoir */

É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 : [http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA]

== É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) ;
* 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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png|texte descriptif]]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

Consommation maison

2014-04-15T16:26:34Z

Froyer : /* Partie IHM */

É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 : [http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA]

== É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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

==== Séance 1 : Cahier des charges spécifiques à l'IHM ====
La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.

La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png]|texte descriptif]

Une fois cette liste établie, j'ai pu passé la séance suivante à la recherche d'outils de conception.

==== Séance 2 : Listing d'outils utiles à la conception ====

Pour la page générale, j'utiliserai le langage PHP et HTML. Durant cette séance j'ai pris en main le langage grâce à quelques tutoriels sur internet et découvert le Bootstrap twitter qui permet d'avoir des classes CSS et des effets JavaScript pré-faits. De plu, je me suis orienté vers un framework CakePHP pour simplifier le code, cependant, se relevant assez complexe à mettre en oeuvre, j'ai préféré ne pas perdre de temps.
Le second outil sont fonctions mysql spécifiques à PHP, la doc sur le site de MySQL s'est révélée précieuse.
Création de l'architecture des fichiers et arborescence du site :
* fichiers include (header et footer)
* fichiers de config
* fichiers CSS et JS

Concernant la météo, on utilisera le site tameteo, qui fournira un fichier XML à parser. On aura donc besoin de libxml2 librairie à étudier.

==== Séance 3 : Mise en place du serveur SQL et des compléments ====

Je connaissais déjà PHPMyadmin, la mise en place de la structure de la base de donnée a donc été assez facile. Le fichier base.sql correspond au fichier importé dans phpmyadmin alors que projet.sql est l'exporté.
Installation des librairies libxml2-dev php5 et libmysqlclient-dev.
Commencement du développement php de l'IHM.

==== Séance 4,5,6,7 : Développement de l'IHM ====

Pas de problèmes particuliers.
Création d'un fichier .inc pour les paramètres de connexion à la BdD. Le programme d'arrière plan utilisera ce même fichier.
Création d'un fichier "station.conf" où sera enregistré le numéro de la station météo et qui sera aussi utilisé par le programme pour récupérer les infos météo.
Enfin le fichier new_modul.conf contiendra les adresses des nouveaux modules détectés mais non ajoutés au réseau. L'utilisateur pourra ajouter ce module et la pièce correspondante grâce à l'IHM.
Codage d'un mini parser php pur récupérer les infos de géolocalisation fournie par tameteo.

==== Séance 8,9 et 10: Développement du parser.c pour la météo - et codage des fonctions qui agissent sur la BdD====

Ce petit programme aura pour but de mettre à jour les infos météo dans la BdD. Il lira le fichier station.conf pour connaître la station pour laquelle il doit lire les infos.
Voir parser.c et parser.h. Ce programme regroupe les fonctions qui ajouteront les infos reçues par les capteurs dans la BdD, et de lecture de la BdD pour envoyer une consigne au radiateur (Consigne déterminée par le programme principal).

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

Consommation maison

2014-04-15T12:07:46Z

Froyer : /* Avancement du projet */

É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 : [http://www.youtube.com/watch?v=6NVIcO7KxJQ&feature=c4-overview-vl&list=PLC3A349454A304FEA]

== É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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 :

{| class="wikitable"
! 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 http://fr.mouser.com/ProductDetail/Parallax/32403/?qs=sGAEpiMZZMuDQH1m5567YR8YnxbMMLjQ
|
|NON
|-
|2 Arduino Uno
|
|NON
|-
|Quelques fils, LED, résistances.
|
|NON
|-
|2 thermomètres numeriques DS18B20+TAR http://fr.mouser.com/ProductDetail/Maxim-Integrated/DS18B20+PAR/?qs=sGAEpiMZZMusbZ2pNxAMx0uevd2%2fnJAJ79Ghy2YiFms%3d
|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 :
[[Fichier:Architecture-Complète.png|800px|center]]

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 :

[[Fichier:UML-BdD.png|600px|center]]

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.

== Avancement du projet ==

=== Partie IHM ===

La Raspberry Pi utilisée dans le projet permettra de recevoir une base de donnée MySQL, une interface Web accessible depuis tablette, smartphone et PC, un programme principal permettant la coordination des données.
Concernant l'interface Homme-Machine (IHM), nous voyons le projet comme un futur produit commercial, l'IHM doit donc être simple, facile et intuitive.
La première étape de conception consiste à établir une liste des éléments qui devront être présent sur l'IHM. A savoir :
* Un affichage de la température extérieur (facultatif) ;
* La température relevée par les capteurs par pièce ;
* La modification manuelle du mode de confort thermique dans une pièce (Hors-gel, Arret, Economique et confort) ; // chaque mode correspondra à une température
* Un panneau de configuration permettant de :
** spécifier la ville pour la météo ;
** rentrer les identifiants de connexion à la base de donnée ;
** ajouter un nouveau module au réseau ;
* Un programmeur pour spécifier les modes de confort à différents moments de la journée ;

[[Fichier:schedulr.png]]

=== Partie réseaux de capteurs ===

Aprés s'être documentés, nous avons:

* Pris en main la communication entre 2 Zigbees, un problème se pose dés lors, comment dissocier les paquets envoyés par le module capteur (arduino+zigbee+capteur de température) de ceux envoyés par le module chauffage au niveau du module coordinateur (la puce Xbee reliée à la Raspberry)
Des soucis de connexion entre la puce Xbee et l'adaptateur xbee pour breadboard ralentissent la phase de protypage.
* Commencé le programme de gestion de la communication entre la puce xbee qui servira de coordinateur et la Raspberry
* Anticipé le futur montage sur carte du module capteur et chauffage qui ajoute certaines problématiques
** Détection de l'autonomie : On pourrait connecter l'alimentation à une entrée CAN pour détecter un seuil de basse tension cependant, lorsque
la tension d'alimentation diminue, le voltage de référence diminuera (pin AREF) qu'il soit paramétré en interne ou en externe.
La solution retenue à ce jour consiste en l'utilisation d'une batterie 3 V, un régulateur step up 3V vers 3,3v - la sortie du régulateur alimentera le Xbee et l'atmega328p tandis qu'on branchera directement sur une entrée CAN l'alimentation 3v. Ainsi le voltage de référence sera constant et on pourra
détecter la baisse de tension d'alimentation).
** Gestion de l'autonomie: Etant donné, que l'on fonctionne en batterie, il faudra minimiser la consommation du module capteur.
Le module de chauffage sera branché sur le secteur (puisqu'une forte tension sera censée alimenter un relai qui permettra d'élever la tension de commande généré à l'aide d'une PWM par l'atmega).
On peut procéder à quelques concessions qui agrandiront l'autonomie:
*** La fréquence du module de capteur pourra être, au minimum, de 1MHz, en effet nous utilisons la technologie OneWire pour communiquer avec notre capteur de température, celle nécessite des timings de l'ordre de la microseconde.
*** Alimenter le capteur de température par son port de donnée, celui-ci consommera seulement lorsqu'il sera interrogé (Alimentation parasite sur Capteur DS18B20)
*** Mettre en veille le module Xbee et le réveiller périodiquement, la consommation passera d'environ 40mA à quelques nA
*** Mettre en veille l'atmega à l'aide d'un watchdog timer ce qui divisera sa consommation par un facteur d'environ 5.

==== Au programme des prochaines séances en Mars: ====

En salle de TP électronique, du batiment C.
* Test du montage d'alimentation parasite du capteur. Intégration sur breadbord avec le DS18B20 en vue d'une validation pour le PCB actuel.
* Test et visualisation de la commande de chauffage en sortie du module chauffage. Commande réalisée par interruptions puisqu'envoyée en continue. Cela implique de rechercher la fréquence d'interruption optimale pour avoir un signal correspondant au signaux de commande types pour un fil pilote (sur chauffage).
* Test des montages de régulation d'alimentation 3,3v pour l'atmega.

Au niveau du Raspberry:
Pour identifier les adresses sources des paquets reçus, la solution serait d'utiliser le Xbee connecté en mode API : un protocole de communication plus bas niveau que le mode transparent, permettant à la Raspberry de communiquer avec le Zigbee à l'aide de trames.
Il permet également de récupérer l'adresse source des trames reçues, indispensables pour différencier les informations de température dans chaque pièces et les alertes de basse autonomie des différents modules.

Fichier:Schedulr.png

2014-04-15T11:02:37Z

Froyer : Exemple de programmeur envisagé

Exemple de programmeur envisagé

Consommation maison

2014-02-12T13:41:34Z

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

Consommation maison

2014-02-10T23:13:55Z

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

Consommation maison

2014-02-10T23:06:51Z

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

Consommation maison

2014-02-09T17:54:30Z

Froyer : /* Introduction */

Consommation maison

2014-02-09T17:53:36Z

Froyer : /* Introduction */

Consommation maison

2014-02-09T17:47:44Z

Froyer : /* Introduction */

Consommation maison

2014-02-09T17:35:13Z

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

Consommation maison

2014-02-09T17:29:37Z

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

Consommation maison

2014-02-09T17:25:58Z

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

Consommation maison

2014-02-09T17:25:21Z

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

Consommation maison

2014-02-09T17:15:57Z

Froyer : /* Développement de la structure de données */

Consommation maison

2014-02-09T17:15:15Z

Froyer : /* Début du projet */

Consommation maison

2014-02-09T17:09:06Z

Froyer : /* Développement de la structure de données */

Fichier:UML-BdD.png

2014-02-09T17:08:12Z

Froyer :

Consommation maison

2014-02-09T17:01:46Z

Froyer : /* Étape 1 : Cahier des charges */

Consommation maison

2014-02-09T17:00:38Z

Froyer : /* Étape 1 : Cahier des charges */

Consommation maison

2014-02-05T13:53:51Z

Froyer : /* Développement de la structure de données */

== É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 pression 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 ===

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.

== É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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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 :

{| class="wikitable"
! 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 ;
|
* Pas sécurisé ;
* 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 :

* Une Raspberry Pi avec câble HDMI verx VGA si possible + une carte SD + câble d'alimentation microUSB
* 2 Adaptateurs USB pour Zigbee (pour pouvoir faire communiquer 2 PC)
* 2 Breadboards
* 2 Adaptateurs Bread Board pour Zigbee
* 2 Arduino Uno avec câble série.
* Quelques fils, LED, résistances.

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 :
[[Fichier:Architecture-Complète.png]]

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 :

[[Fichier:UML-BdD.jpg|800px]]

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.

Fichier:Architecture-Complète.png

2014-02-05T13:49:39Z

Froyer :

Consommation maison

2014-02-04T17:59:40Z

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

== Étape 1 : Cahier des charges ==

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

=== Objectifs principaux===

* Les températures et pression devront être récupérées dans plusieurs pièces. Ces mesures devront être classées et organisées dans une base de donnée ou structure.
* On compte principalement réduire la consommation due au chauffage dans une habitation ou infrastructure ;
* La consigne sera fournie aux chauffages par un calculateur central (différents types de chauffage : Eau ou radiateur électrique) ;
* Il existera différents modules :
** capteurs seuls ;
** capteurs + contrôleur d'électrovanne (chauffage à eau) -> la partie commande sera liée au projet 43 ;
** capteurs + contrôleur pour un radiateur électrique à fil pilote ;
* Ajouter un système d’arrêt d'urgence du chauffage (exemple : à l'ouverture d'une fenêtre) ;

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

=== 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 ===

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.

== É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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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é, 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é).

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é.
Le tableau ci-dessous montre les avantages et inconvénients de chacun :

{| class="wikitable"
! 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 ;
|
* Pas sécurisé ;
* 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 :

* Une Raspberry Pi avec câble HDMI verx VGA si possible + une carte SD + câble d'alimentation microUSB
* 2 Adaptateurs USB pour Zigbee (pour pouvoir faire communiquer 2 PC)
* 2 Breadboards
* 2 Adaptateurs Bread Board pour Zigbee
* 2 Arduino Uno avec câble série.
* Quelques fils, LED, résistances.

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 ==

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 :

[[Fichier:UML-BdD.jpg|800px]]

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.

Consommation maison

2014-02-04T17:57:07Z

Froyer : /* Développement de la structure de données */

== Étape 1 : Cahier des charges ==

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

=== Objectifs principaux===

* Les températures et pression devront être récupérées dans plusieurs pièces. Ces mesures devront être classées et organisées dans une base de donnée ou structure.
* On compte principalement réduire la consommation due au chauffage dans une habitation ou infrastructure ;
* La consigne sera fournie aux chauffages par un calculateur central (différents types de chauffage : Eau ou radiateur électrique) ;
* Il existera différents modules :
** capteurs seuls ;
** capteurs + contrôleur d'électrovanne (chauffage à eau) -> la partie commande sera liée au projet 43 ;
** capteurs + contrôleur pour un radiateur électrique à fil pilote ;
* Ajouter un système d’arrêt d'urgence du chauffage (exemple : à l'ouverture d'une fenêtre) ;

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

=== 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 ===

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.

== É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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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é, 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é).

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é.
Avantages et inconvénients de chacun :

{| class="wikitable"
! 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 ;
|
* Pas sécurisé ;
* 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 :

* Une Raspberry Pi avec câble HDMI verx VGA si possible + une carte SD + câble d'alimentation microUSB
* 2 Adaptateurs USB pour Zigbee (pour pouvoir faire communiquer 2 PC)
* 2 Breadboards
* 2 Adaptateurs Bread Board pour Zigbee
* 2 Arduino Uno avec câble série.
* Quelques fils, LED, résistances.

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 ==

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 :

[[Fichier:UML-BdD.jpg|800px]]

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.

Consommation maison

2014-02-04T17:51:02Z

Froyer : /* Développement de la structure de données */

== Étape 1 : Cahier des charges ==

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

=== Objectifs principaux===

* Les températures et pression devront être récupérées dans plusieurs pièces. Ces mesures devront être classées et organisées dans une base de donnée ou structure.
* On compte principalement réduire la consommation due au chauffage dans une habitation ou infrastructure ;
* La consigne sera fournie aux chauffages par un calculateur central (différents types de chauffage : Eau ou radiateur électrique) ;
* Il existera différents modules :
** capteurs seuls ;
** capteurs + contrôleur d'électrovanne (chauffage à eau) -> la partie commande sera liée au projet 43 ;
** capteurs + contrôleur pour un radiateur électrique à fil pilote ;
* Ajouter un système d’arrêt d'urgence du chauffage (exemple : à l'ouverture d'une fenêtre) ;

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

=== 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 ===

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.

== É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 :
[[Fichier:Reseaux.jpg|400px|thumb|left|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é, 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é).

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é.
Avantages et inconvénients de chacun :

{| class="wikitable"
! 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 ;
|
* Pas sécurisé ;
* 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 :

* Une Raspberry Pi avec câble HDMI verx VGA si possible + une carte SD + câble d'alimentation microUSB
* 2 Adaptateurs USB pour Zigbee (pour pouvoir faire communiquer 2 PC)
* 2 Breadboards
* 2 Adaptateurs Bread Board pour Zigbee
* 2 Arduino Uno avec câble série.
* Quelques fils, LED, résistances.

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 ==

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 :

[[Fichier:UML-BdD.jpg|800px]]