Rapport

Universit de Lige
Facult des Sciences Appliques
Travail de fin dtudes
Implmentation dun Systme de Contrle Domotique
Travail ralis par Tom Barbette

2e Master en Sciences Informatiques finalit approfondie
Anne acadmique 2012-2013
Promoteur : Pr. Benoit Donnet

Jury : B. Boigelot (Prsident), Laurent Mathy, Quentin Louveaux
Travail de fin dtudes prsent en vue de lobtention du grade de Master en Sciences

Informatiques finalit approfondie
Rsum
Ce document prsente le fonctionnement, le contexte, et les perspectives de la
ralisation dune interface de contrle domotique. Linterface est flexible, pouvant
sadapter toutes les nergies et tous les types de compteurs. Elle a t pense
pour une utilisation facile, guidant lutilisateur par tape dans la configuration de
linterface, tout en permettant une dfinition relativement prcise de lenveloppe
nergtique de la maison. Elle rpond galement un souci de performance devant
tre utilisable sur les ordinateurs mais aussi sur les smartphones et tablettes. Par la
combinaison de ces caractristiques, linterface se dmarque par rapport ce qui se
fait actuellement en la matire.
Ce travail envisage galement quelques perspectives de recherche lie linterface,
comme lutilisation des informations fournies par les divers appareils intelligents de
la maison pour calculer des mesures approximes plutt que dutiliser des capteurs
physiques, souvent coteux.
Abstract
This paper presents the realization, the context, and the prospects of an automation control interface. The interface is flexible, capable of adapt to all energy and
all types of meters. It has been designed for easy use, guiding the user by steps in
the configuration of the interface, while allowing a relatively precise definition of
the energy envelope of the house. It also responds to performance issues, allowing
it to be used on computers but also smartphones and tablets. By combining these
characteristics, the interface differs from what is currently being done in this area.
This work is also considering some research perspectives related to the interface,
such as the use of information provided by the various smart devices in the house to
compute approximated consumption data, rather than using real meters, which are
often expensive.
Interface de dmonstration et code source

Une version de dmonstration de linterface est disponible ladresse http:
//www.usemonitoring.be. Le code source est tlchargeable ladresse http://
www.usemonitoring.be/static/source.tar.gz. Une version lectronique de ce
rapport est galement disponible votre meilleure convenance ladresse http:
//www.usemonitoring.be/static/rapport.pdf . Comme prcis plus loin dans
ce travail, veuillez noter que les donnes des compteurs visibles sur linterface de
dmonstration ne sont pas des donnes relles et les anciennes donnes ne sont que
trs disparates provoquant des erreurs uniquement des au fait que certains relevs
ont t envoys un stade avanc de linterface. Elles sont cependant laisses pour
que vous puissiez voir, cher lecteur, des aperus des statistiques disponibles.
Le nom dutilisateur est "tfe" et le mot de passe est "tombarbette2013".
Remerciements
Je tiens particulirement remercier mon promoteur, le professeur Benoit Donnet
pour laide apporte, spcialement quant aux conseils concernant la rdaction.
Je dsire galement remercier lquipe dIngnieurs de Projet qui a encadr le
projet dans son ensemble. Elle a apport la ralisation de ce TFE, une exprience
trs particulire dans le cadre dun travail en quipe pluridisciplinaire, avec ses forces
et ses fragilits. Cela ma permis de vivre une exprience unique au regard des travaux
de fin dtudes abords de faon plus classique.
Je tiens aussi remercier ma famille pour laide apporte au niveau de la relecture
de ce manuscrit.
Enfin, je remercie lICEDD pour son autorisation de reproduction des figures du
bilan nergtique de la Rgion Wallonne.
Table des matires

1 Introduction
2 Systme dacquisition et objectifs

2.1 Acquisition . . . . . . . . . . . .
2.1.1 Gaz et eau . . . . . . . . .
2.1.2 lectricit et temprature
2.2 Etude de march . . . . . . . . .
2.2.1 Smartbox . . . . . . . . .
2.2.2 Open Energy Monitor . .
2.2.3 Efergy Elite . . . . . . . .
2.2.4 Wattvision . . . . . . . . .
2.2.5 EKM Metering . . . . . .
2.2.6 Chacon ecowatt . . . . . .
3 Choix logiciels
3.1 Langage : Python . . . . . .
3.2 framework : Django . . . . .
3.2.1 Scurit dans Django
3.2.2 Base de donnes . . .
3.2.3 Technologies Web . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Structure de linterface
4.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Structure de la base de donne . . . . . . . . . . . . . . . . . . .
4.2.1 Structure de la maison . . . . . . . . . . . . . . . . . . .
4.2.2 Alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Authentification . . . . . . . . . . . . . . . . . . . . . . .
4.3 Transfert de donnes entre Django et les applications Javascript
4.4 Systme de dessin du plan . . . . . . . . . . . . . . . . . . . . .
4.5 Protocole de communication . . . . . . . . . . . . . . . . . . . .
4.6 Traitement des donnes . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Pre-processing . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2 Post-processing . . . . . . . . . . . . . . . . . . . . . . .
4.7 Systme dalertes . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Compression et concatnation du texte . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
12
12
14
16
16
17
17
17
17
18
.
.
.
.
.
19
19
21
23
24
24
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
28
30
31
32
33
37
40
42
42
43
44
45
TABLE DES MATIRES
5 Compteurs virtuels
47
5.1 Gnration de donnes alatoires . . . . . . . . . . . . . . . . . . . . 47
5.2 Temprature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Consommation dun ordinateur . . . . . . . . . . . . . . . . . . . . . 49
6 Rsultats
6.1 Modlisation - Builder . . . . . . . . . . . . . . . . .
6.2 Consommation - Consumption . . . . . . . . . . . . .
6.3 Alertes - Alerts . . . . . . . . . . . . . . . . . . . . .
6.4 Statistiques - Statistics . . . . . . . . . . . . . . . . .
6.4.1 Recherche en matire nergtique . . . . . . .
6.5 Paramtres - Settings . . . . . . . . . . . . . . . . . .
6.6 Compatibilit et smartphones . . . . . . . . . . . . .
6.7 Modularit . . . . . . . . . . . . . . . . . . . . . . . .
6.7.1 Ajout dune nergie et dun nouvel appareil de
6.8 Performances . . . . . . . . . . . . . . . . . . . . . .
6.8.1 Base de donne . . . . . . . . . . . . . . . . .
6.8.2 Tailles de transferts et temps de rendu . . . .
6.8.3 valuation quantitative . . . . . . . . . . . . .
7 Perspectives et travail futur
7.1 Alertes . . . . . . . . . . . . . . . . . . . . . . .
7.2 Statistiques et suppression des relevs . . . . . .
7.3 Image des appareils . . . . . . . . . . . . . . . .
7.4 Application SmartPhone native . . . . . . . . .
7.5 Modle nergtique . . . . . . . . . . . . . . . .
7.6 Interfaage avec un systme domotique existant
7.7 Prsence des habitants . . . . . . . . . . . . . .
8 Conclusion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
consommation
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
55
56
63
65
66
66
68
70
72
73
75
75
77
80
.
.
.
.
.
.
.
81
81
81
82
82
82
84
84
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
Chapitre 1
Introduction
Depuis la rvolution industrielle, lhumanit ne cesse dinventer de nouvelles machines. De la voiture llectromnager, de lampoule lordinateur, nous produisons
sans cesse de nouveaux objets pour satisfaire de nouveaux besoins, et de nouveaux
besoins pour ensuite les satisfaire avec de nouvelles inventions. La consommation des
mnages a ainsi augment de 12% en 15 ans, en grande partie de une hausse de
plus de 50% de la consommation dlectricit [23] pousse par une hausse de plus de
50% du pouvoir dachat ces trente dernires annes[12]. Un cours dconomie basique
nous indique que le marketing consiste promouvoir un produit pour en vendre plus.
Ce mme cours dconomie nous apprendra ensuite le rapport existant entre loffre
et la demande. Lorsquil ny a pas assez doffre pour la demande, le prix augmente.
Multiplier la quantit de besoins ne serait pas un problme si la terre sagrandissait
une vitesse proportionnelle lutilisation de ses ressources. Malheureusement, notre
plante nest pas en expansion et la presse nous informe quasi quotidiennement de
laugmentation des prix de lnergie - tantt du gaz, tantt de lessence, tantt de
llectricit.
Le sicle dernier a connu une forte industrialisation. Celle-ci en lien avec lvolution
dmographique a entran une prise de conscience un niveau plantaire : le monde
que nous habitons a ses limites, mme si cette prise de conscience ne suffit pas encore
toujours provoquer les changements ncessaire la lutte contre le rchauffement
climatique (Echec de Copenhague en 2009[32] ou encore retrait du Canada de Kyoto
en 2011[33]). Cette prise de conscience ne date pas dhier. Juridiquement la grande
Bretagne en ft sans doute pionnire avec le Smoke Nuisance Abatement Act de 1853
[6]. En 1970, cette prise de conscience saffinait, avec notamment ltablissement de la
journe internationale de la terre [52] et lanne suivante la naissance de greenpeace
[55]. Le rchauffement climatique, la pollution, la consommation tort et travers
sont clairement les ingrdients qui entrent en ligne de compte dans le problme
majeur auquel doit faire face notre socit si elle dsire passer au sicle suivant. En
dautres termes, la gestion de notre consommation est un dfi majeur au regard
duquel lhistoire ne peut nous aider. Un dfi relever en recherchant des solutions
dans linnovation.
5
CHAPITRE 1. INTRODUCTION
Que ce soit par souci cologique ou par souci conomique, actuellement la plupart
des gens souhaitent diminuer leur consommation. Le politique passe progressivement
de laide la production laide la rduction de consommation. En Belgique, on
notera notamment la suppression de la prime lachat de panneau photovoltaque
[39] qui a laiss place aux primes lisolation. En effet, lnergie la moins chre (et
la moins polluante, selon les sensibilits) est celle que lon ne consomme pas.
Plusieurs tudes ont montr que la simple connaissance de sa consommation
par lutilisateur a un impact non-ngligeable sur la consommation globale. Nous
noterons par exemple ltude de Kohlenberg, R et al.[29] qui pointe un des principes
de consommation qui cause le plus de pollution : les pics. En effet, pour pouvoir
fournir de llectricit tous les foyers aux heures de pointes, il est ncessaire de
pouvoir fournir une nergie gale au maximum du pic de consommation. Lnergie
tant difficilement stockable, il est ncessaire de construire de nouvelles centrales ou
den faire tourner de plus anciennes et plus polluantes (souvent au charbon) plusieurs
mois par an toute la journe mais seulement pour ces quelques heures de pointes par
jour. Ltude montre que la simple information des utilisateurs rduisait leffet de
pic de 50%.
Quant aux missions de CO2, si des efforts defficacit nergtique taient entrepris
dici 2030, nous pourrions diminuer de 23% notre consommation par rapport un
scnario suivant les consommations actuelles [31]. Le scnario prvoit principalement
une amlioration de lisolation, sachant que la consommation dans les btiments
rsidentiels en Belgique se situe environ 70% au dessus de la moyenne europenne.
Au niveau des btiments rsidentiels, une action significative ne pourra tre
prise en compte que moyennant une implication en terme dinvestissement et de
conscientisation des utilisateurs. Un moyen efficace pour aider la population rduire
sa consommation dnergie, et ne demandant quun investissement limit de la part
des consommateurs, consiste quiper les mnages des outils ncessaires une
visualisation et une matrise de leur consommation.
Plusieurs possibilits soffrent lutilisateur pour trouver les failles lies sa
consommation :
quant lisolation de sa maison, il peut faire appel un professionnel pour
procder un audit nergtique de sa maison (ce qui est rendu obligatoire pour
la vente dun bien immobilier).
en ce qui concerne les appareils lectromnagers, il peut se fier au classement
nergtique des appareils.
il peut aussi intgrer une installation de domotique, permettant doffrir un profil
de consommation lectrique. La domotique dsigne lensemble des techniques,
souvent lectroniques, permettant de centraliser le contrle et la surveillance
des appareils mnagers, la gestion de lnergie et les systmes dalarmes.
Mais ces solutions sont coteuses, ou peu flexibles. Au del des bonnes pratiques,
7
vaut-il mieux isoler un mur, acheter un meilleur frigo, changer le systme de chauffage
ou installer un panneau solaire ?
Pour tenter de rpondre ces questions, jai pris part la ralisation dun projet
collectif dans le cadre du concours Ingnieur de Projet ( IdP ) runissant des tudiants
de plusieurs disciplines (Electro-Mcanique, Electronique et Informatique). Nous
avons construit un systme abordable tant du point de vue accessibilit que financier.
Celui-ci permet dtudier la consommation dun mnage et de sensibiliser ses habitants en fonctions de leurs propres consommations. En effet une tude du SEREC
sur les changements dhabitudes des Belges dans leur consommation montre parmis
plusieurs dispositifs essays, les plus efficaces taient ceux dont la communication tait
personnalise. Ainsi plus lutilisateur reoit une information individualise, plus il
est enclin agir sur ses mauvaises habitudes de consommation et investir [21, p. 133].
Le systme dans son ensemble prvoit une srie de capteurs et une interface.
Nous avons choisi dappeler lensemble du systme USE Monitoring pour ULg
Smart Energy Monitoring. Un premier type de capteurs est fait base de vision par
ordinateur : des webcams sont places devant les compteurs deau et de gaz, lisent les
chiffres du compteur et lenvoient au serveur. Le deuxime type de capteur mesure
les consommations lectriques de la maison grce des pinces ampremtriques
et un circuit lectronique, et la consommation de deux appareils lectriques de la
maison. Ces derniers ont galement la possibilit dtre coup distance. Toutes ces
donnes sont traites par le serveur et affiches sur une interface. Linterface permet
de visualiser la consommation actuelle de la maison, mais aussi quelques statistiques
sur les consommations passes. Les utilisateurs verront les dfauts de leurs habitudes
de consommation et seront alerts dans certains cas quils auront dfini, comme
par exemple le dpassement dun certain seuil de consommation. Linterface a t
particulirement adapte pour fonctionner sur tout type dcran, disposant dune
souris ou non. Ds lors lutilisateur pourra tre averti sil oublie un appareil allum
ou simplement dtecter loubli en se connectant linterface via son smartphone par
exemple.
Linterface permet la modlisation de la maison, afin dintgrer un ventuel futur
modle nergtique qui sera discut dans les perspectives. Actuellement, cela na
donc dutilit que pour laffichage des appareils et des compteurs sur le plan de la
maison de lutilisateur. Jai galement dvelopp une srie de compteurs "virtuels".
En effet, la temprature extrieure na par exemple, pas besoin dun capteur rel
et peut directement tre rcupre en ligne. Jai galement dvelopp un script
tournant sur un ordinateur et envoyant des donnes de consommation simule. En
effet, la consommation dun ordinateur peut tre relativement correctement estime
et lordinateur peut videmment utiliser sa connexion internet pour envoyer ces
donnes simules. Jtudie galement quelques autres cas possibles dans la suite de ce
travail. En effet, nos appareils lectromnagers deviennent de plus en plus intelligents
et il est vident que toute mesure pouvant tre faite sans lajout dun quelconque
CHAPITRE 1. INTRODUCTION
capteur est utile.

Lide dune interface de monitoring nergtique dans le cadre rsidentiel nest pas
neuve, et plus globalement le domaine de la domotique fait dj lobjet de plusieurs
recherches. Cependant comme nous le verrons dans ltude de march, il nexiste
pas de systme combinant la configuration de lenveloppe nergtique de la maison,
la surveillance de la consommation lectrique mais aussi deau, de gaz, de mazout
et plus globalement de toutes nergies. De plus ils ne permettent que rarement le
monitoring aussi bien au niveau global, sur la consommation de toute la maison,
quau niveau local sur un appareil cibl. Enfin, seuls certains produits permettent le
contrle et lextinction des appareils. Ces systmes ont chacun isolment dautres
avantages, mais linterface telle que prsente dans ce travail est la seule a runir
toutes ces caractristiques et particulirement la seule tre aussi flexible.
Ce document prsentera en premier lieu le systme dans son ensemble, avec notamment une description des capteurs construits par les autres membres dIngnieur
de Projet, devant fournir les donnes notre interface (le protocole de communication
tant ma charge galement). Le cahier des charges prvoit le fonctionnement avec
ces capteurs, mais linterface est modulable et comme dmontr dans les parties
compteurs virtuels et perspectives, elle est trs flexible et peut se voir greffe tout
type de capteurs pour plusieurs types dnergies. Le chapitre se termine par une
tude des produits existants.
Le chapitre suivant traite des choix logiciels, du langage utilis et du framework.
Il est suivi de la description des structures internes, et de certains algorithmes plus
complexes mritant une attention particulire. Il sen suivra ltude des compteurs
virtuels et la prsentation des rsultats, comprenant notamment une analyse de
la performance. Le chapitre 7 prsentera les perspectives du travail et quelques
spculations sur les diverses intgrations dautres produits imaginables.
Chapitre 2
Systme dacquisition et objectifs
Ce chapitre prsentera le fonctionnement gnral du systme dacquisition pour
lequel linterface a t prioritairement conue. Bien que mon travail de fin dtude
vise uniquement linterface, elle a largement influenc la conception des capteurs et
inversment. Comme nous le verrons, ce systme est cependant destin sadapter
tous types de capteurs et tous types de btiments. Une partie de mon travail tait
donc daider la conception de ces capteurs (mais non la ralisation). Le chapitre se
clturera par une tude de march couvrant ce qui existe dj comme systmes de
monitoring nergtiques.
Lensemble du systme poursuit trois objectifs : il se veut flexible, peu coteux,
et non-intrusif. La flexiblit concerne la possibilit dutiliser dautre capteurs, et de
facilement sadapter dautres maisons, comprenant dautres appareils ou consommant dautres nergies comme le mazout. Le systme doit tre peu coteux en prix,
mais galement en nergie. Il faut videmment que le gain permi par linformation
de lutilisateur sur sa consommation soit plus grand que lnergie consomme par le
systme. Enfin, il nest pas acceptable de demander lutilisateur de modifier son
installation lectrique ou de changer son compteur, le systme devant donc tre non
intrusif.
Lensemble de USE Monitoring est divis en 3 parties :
Lacquisition des mesures par webcam (gaz et eau)
Lacquisition des mesures lectriques
Linterface
Lacquisition se fait par des camras qui observent les compteurs de gaz et deau.
Ces camras sont connectes un ordinateur. Comme les compteurs sont souvent
dans une cave, elles seront connectes un mini-ordinateur ARM : un Raspberry Pi
(Fig. 2.2).
Le Raspberry Pi est un ordinateur de 30A
C, un peu plus grand quune carte
de crdit. Il est fourni avec une distribution linux : Raspbian, base sur Debian
[45]. Il dispose de deux ports USB, dun port HDMI, dun port ethernet et dun
9
10
CHAPITRE 2. SYSTME DACQUISITION ET OBJECTIFS
Figure 2.1 Vue globale du systme

emplacement pour une carte SD. Il est donc le candidat idal pour centraliser les
informations de plusieurs capteurs et les envoyer un serveur distant sans devoir
r-implmenter les divers protocoles rseaux, tout en permettant de se baser sur la robustesse des systmes Unix et faire tourner directement des scripts Python sur celui-ci.
Mme si elle peut galement se faire par webcam, la mesure de la consommation
lectrique globale se fait par un wattmtre, connect galement au Raspberry Pi.
Afin dtendre les possibilits du systme et de montrer sa flexibilit, il possde
galement deux wattmtres sans-fil pour rapporter la consommation prcise de deux
appareils lectriques et offrir la possibilit de les couper. Deux capteurs de tempratures sans-fil font galement partie de lensemble.
Le Raspberry Pi envoie les donnes un serveur de stockage. Notons que ce
serveur pourrait tre sur le Raspeberry lui-mme. Il sagit ici doprer un choix de
sparation des lments : le serveur peut grer et stocker les statistiques de consommation de plusieurs maisons. De plus, laffichage de ces donnes se fait par un serveur
web qui prsentera des difficults daccs sil est hberg chez un particulier derrire
un routeur disposant dune adresse IP dynamique, dautant plus si celui-ci fait du
NAT.
Dans le projet original, lensemble devait comporter un modle nergtique utilisant lenveloppe nergtique de la maison dfinie via linterface et les mesures faites
par les capteurs pour tablir une srie de prdictions. Le modle a cependant d
tre abandonn en cours danne, mais linterface garde quand mme sa partie sur la
11
Figure 2.2 Raspberry PI
configuration de lenveloppe de la maison pour une ventuelle future intgration qui

sera discute dans le chapitre 7 perspectives et travail futur.
Linterface web a deux rles majeurs. Elle permet dafficher de faon conviviale
et comprhensible les donnes gnres par le modle (Fig. 2.1), notamment sous
forme de graphiques. Mais elle sert galement paramtrer la maison de lutilisateur
en lui demandant de rpondre une srie de questions ayant trait au type de maison
(appartement, habitation mitoyenne,date de construction, etc...) et de tracer un
schma trs simplifi de lhabitation. Linterface doit galement tre capable de
sadapter tous les types de maisons. Elle doit permettre lajout dventuels futurs
capteurs qui ne seraient pas pris en compte ici, comme un capteur sur des panneaux
solaires, la mesure du mazout consomm par une chaudire, ou le placement dune
pompe chaleur.
Notons ici la modularit du systme : il fonctionne aussi bien pour un utilisateur

ne possdant que deux webcams (gaz et eau) et le module wattmtre (lectricit), que
pour lutilisateur disposant de trois webcams pour chacun des compteurs. De mme,
lutilisateur nest nullement oblig dactiver un Raspberry Pi et peut faire tourner le
collecteur de donnes sur un vieil ordinateur quil met au fond de sa cave. Le serveur
peut se trouver galement sur celui-ci sans aucun problme. Par souci de simplicit,
nous utiliserons comme exemple le schma de la figure 2.1, o le Raspberry PI est
utilis comme collecteur de donnes, charg de les envoyer au serveur, qui lui est un
ordinateur distinct.
12
Figure 2.3 Photo de linterface
2.1
2.1.1
Acquisition
Gaz et eau
Obliger un utilisateur installer un compteur de gaz numrique est videmment trs compliqu, voire dangereux. De mme, le placement dun compteur deau
gnrerait des travaux de plomberie importants et coteux. Ces types de compteurs
sont dailleurs trs chers. La solution propose ici est donc de prendre en image
le compteur existant que tout un chacun possde, dcoder les chiffres grce un
OCR (Optical Character Recognition - logiciel de reconnaissance de caractres) et
transmettre cette information au serveur.
Figure 2.4 Systme de capture directement coll au compteur

Les tudiants en lectro-mcanique charg de cette partie de USE Monitoring ont
utilis une webcam USB (Fig . 2.4) quils ont fixe dans un botier en dtournant
lalimentation USB pour alimenter quelques LEDs servant illuminer le compteur.
Le tout vient donc se brancher sur le Raspberry PI. Si nous avons choisi de dmonter
une webcam USB, ce nest pas par facilit mais parce quil est toujours plus coteux
2.1. ACQUISITION
13
de la fabriquer soi-mme sur un PCB (Printed Circuit Board - Circuit imprim),

moins den produire plusieurs centaines voir milliers.
Figure 2.5 Photo telle que prise par la webcam. On aperoit le reflet des LEDs
en haut de la photo
Figure 2.6 Image des numros aprs filtrage

Le procd se droule en 8 tapes :
Prise de la photo de 640x480 par la webcam logitech c210 (Fig. 2.5)

Identification de la zone intressante de limage
Identification du nombre de numros lire
Application dun premier filtre pour faire ressortir les parties de limage les
plus claires
Application du 2me filtre pour liminer le bruit(Fig. 2.6)
Centrage de limage (Fig. 2.7)
Comparaison des numros aux templates
Envoi des numros au serveur (le protocole est discut dans la section 4.5 sur
le protocole de communication.)
Figure 2.7 Image des numros aprs filtrage

Cette srie dvnements est implmente laide du Python (le langage sera
discut dans la section 3.1). Le script est dclench toutes les deux minutes via le
service Cron de la distribution. Cron est un programme qui permet aux utilisateurs
14
dexcuter des scripts automatiquement un interval dfini [11].

Le systme dacquisition possde une rsolution maximale de 0,01 m3, le dernier
chiffre tant trop mouvant pour tre lisible. Le traitement logiciel doit encore tre
amlior car il prend 20 secondes.
2.1.2
lectricit et temprature
Les compteurs lectriques ne possdent pas une grande prcision, ds lors il tait
intressant davoir un wattmtre mesurant plus prcisment la consommation globale
de la maison. Afin dtendre les possibilits de notre projet, nous avons intgr une
quipe dlectroniciens qui en plus du wattmtre placer sur larrive lectrique
gnrale de la maison ont fabriqu deux capteurs de tempratures et deux wattmtres
pour des appareils lectro-mnagers spcifiques qui intgrent galement des relais
ayant la facult de couper les appareils distance.
Cette partie se prsente sous la forme dun botier contenant une carte mre (cP
sur le schma 2.8) qui se connecte au Raspberry PI. Les autres lments communiquent par radiofrquence avec la carte mre.
Trois modules diffrents sont visibles sur la figure 2.9 :
Le module mT mesure la temprature et renvoie les donnes la carte principale
cP.
Le module mWcc transmet une mesure de la consommation lectrique dun
appareil cP (ce module se branche entre la prise lectrique et lappareil) tout
en donnant la possibilit lutilisateur de couper lalimentation distance.
cP est la carte mre, qui sera branche directement sur le Raspberry PI. Elle
possde galement 3 pinces pour mesurer lintensit lectrique des 3 phases de
courant larrive de la maison. Cette carte sera donc galement ct du
compteur lectrique.
Chacune des cartes est contrle par des microprocesseurs PIC.
Pour les mWcc, ces derniers utilisent un capteur de courant industriel et la tension
est lue au moyen dun transformateur par un des convertisseurs analogique-digital
du pic. Il suffit alors de multiplier la tension par le courant pour obtenir la puissance
consomme. La coupure du courant se fait elle grce un triac et son optocoupleur.
Pour le capteur de puissance principal, le systme est identique si ce nest que
des pinces sont utilises plutt que des bornes dentre-sortie. En effet, le systme se
voulant non-intrusif, il ntait pas acceptable ni lgal de demander lutilisateur de
couper son arrive de courant pour dnuder les fils et faire traverser le courant par
la carte.
2.1. ACQUISITION
15
Concernant la temprature, le PIC est branch un simple capteur dont la tension

varie en fonction de la chaleur. Il suffit donc de convertir la tension avec un port
ADC (Analog to Digital Converter - un port pour convertir une valeur analogique en
un signal digital de 10 bits) du PIC.
Figure 2.8 Schma gnral de la communication des modules de mesure lectrique

et thermique
Pour la communication radio, les lectroniciens ont utilis des cartes XBee [58],
qui sont des modules trs faciles utiliser avec les PIC qui analysent les donnes des
capteurs. Pour communiquer les donnes de chacun des modules la carte mre, un
multiplexage temporel est utilis. La carte mre envoie un signal toutes les minutes
indiquant quel module a le droit dutiliser le canal. Chaque Xbee a donc droit de
parole tour tour pour envoyer ses donnes la carte mre. Lorsque la carte mre a
reu tous les rsultats, elle communique ceux-ci lordinateur via un port srie gr
par une puce MAX232.
De la mme faon que pour les capteurs lis la webcam, les donnes collectes
par la carte mre qui ont t transmises au Raspberry Pi sont envoyes au serveur
par la mthode discute dans la section 4.5 sur le protocole de communication.
16
Figure 2.9 Schma des modules thermiques, du wattmtre, et de la carte mre
2.2
Etude de march
Cette section prsente une analyse de ce qui existe dj, autant au niveau de
linterface que pour le systme de capture et de monitoring dans son ensemble, comme
ceux-ci vont souvent de paire. Il est important danalyser les diffrences avec nos
objectifs et de comparer les avantages et faiblesses de chaque systmes (ou du moins
dun panel assez large)
2.2.1
Smartbox
Cet appareil[49] dElectrabel permet la mesure de la consommation de 4 appareils lectriques via des capteurs sans fil. Il est possible dacheter dautres capteurs
lectriques, et un capteur thermique en option. Les donnes sont envoyes par la
smartbox Electrabel qui propose une interface en ligne pour consulter diverses
statistiques sur celles-ci. Les appareils surveilles peuvent galement tre coups ou
teint.
Avantages :
Application SmartPhone native
Inconvnients :
Consommation dappareils lectriques uniquement.
Pas de mesures globales ou de fort amprage.
Cot dachat non ngligeable (139A
C), et abannement mensuel de 3A
C.
2.2. ETUDE DE MARCH
2.2.2
17
Open Energy Monitor
Open Energy Monitor[37] est une solution de monitoring Open Source. Aucun
systme matriel nest produit, mais des schmas sont distribus pour fabriquer des
capteurs. Comme notre systme, celui-ci utilise des pinces ampermtriques pour
mesurer la consommation lectrique. Cependant, le systme ncessite des comptences
en lectronique, et est limit llectricit et les tempratures uniquement. Linterface
est en PHP.
Avantages :
Open source
Inconvnients :
Electricite uniquement
Monitoring uniquement (pas de contrle)
2.2.3
Efergy Elite
La solution propose par efergy[18] consiste en un petit boitier de mesure connect

au rseau sans fil, utilisant lui aussi des pinces pour mesurer les trois phases dentres.
Le boitier coute une 50aine deuros et envoie les donnes au serveur defergy qui
propose un interface web et une application Android et iPhone.
Avantages :
Applications SmartPhone natives
Inconvnients :
Une seule mesure globale de llectricit uniquement
Propritaire
2.2.4
Wattvision
Wattvision[53] est un appareil de mesure de la consommation lectrique globale.

Il propose plusieurs types de capteurs pour diffrents modles de compteur, mais
ncessite un compteur compatible.
Avantages :
Support de plusieurs maisons
Inconvnients :
USA Uniquement
Propritaire et chre (250$)
Une seule mesure de llectricit globale uniquement
Interface semble trs limite
2.2.5
EKM Metering
EKM Metering[19] propose une solution de monitoring de llectricit, du gaz et

de leau, mais des consommations globales uniquement. EKM propose un logiciel
18
compatible Windows, Linux et Mac pour lire les donnes mesures.

Avantages :
Gaz, eau et lectricit
Inconvnients :
Pas dappareils individuels
Logiciel 30$, systme complet entre 300$ et 1000$
2.2.6
Chacon ecowatt
Chacon ecowatt permet la mesure de consommation lectriques globale de la

maison. Le systme de capteurs est compos de pinces ampermtriques et cote
environ 80A
C.
Avantages :
Ecran LCD
Inconvnients :
Electricit globale uniquement
Logiciel uniquement windows
Cette liste nest videmment pas exhaustive, jai galement trouv de nombreux
autres appareils et fournisseurs tel que OWL, Ewgeco, GEO, rmoni et bien dautres,
mais ceux-ci noffrent pas spcialement plus de possibilits que ceux prsents cidessus.
Aucun des systmes ne combine la fois la possibilit de mesurer tous types
dnergies, de contrler des appareils en plus du monitoring de ceux-ci et daccder
aux donnes distance sur internet. De plus, tous ces systmes de monitoring ne
permettent lutilisation dun modle nergtique. Si cet objectif peut tre men bien,
nous aurons un systme encore plus dmarqu, pouvant tir parti de simulations que
je nai vu sur aucun systme disponible dans le commerce, ou mme ltat de projet.
Jai en effet cherch des solutions de modlisations nergtiques de maisons, mais
tous les logiciels sont trs complexes. On notera par exemple PEB[] logiciel officiel de
la rgion wallonne destin cet usage, qui est trs compliqu en matire dutilisation,
impliquant le recours aux services dun professionnel.
La difficult datteindre le mme niveau se situe au niveau de la finition de
certaines interfaces, conues par des graphistes, et comprenant de nombreuses statistiques diffrentes. Evidemment, linterface permettra lajout de divers graphiques
parmis les diffrentes perspectives, mais ces interfaces font lobjet dun dveloppement
par une quipe de designers que je ne peux videmment galer dans le temps qui
mest imparti. Certains systmes disposent galement dapplications natives, nous
verrons que celles-ci peuvent avoir de petits avantages sur une simple version mobile
dun interface web.
Chapitre 3
Choix logiciels
Nous allons analyser dans ce chapitre les divers choix de logiciels et les choix
dimplmentation.
Nous voulions un systme livrable "cl sur porte", galement compatible avec
du matriel de rcupration et divers systmes dexploitations. Nous pourrions recompiler nos excutables et les adapter ces derniers ainsi qu diverses architectures,
mais ceci constitue un travail plutt lourd.
Le choix du langage est en fait parti du module de calcul. Le modle nergtique a
t dvelopp sous Matlab, qui prsente une possibilit dinterfaage plutt complexe
et une utilisation des ressources plutt gourmandes. Nous verrons que parmi ces
alternatives, lutilisation du langage Python[41] ressort du lot.
Le module dacquisition pour les webcams tait lui aussi bas sur du code Matlab
(finalement abandonn au profit dune librairie Python). En effet, ce code laissait apparatre des problmes similaires au module de calcul (extrmement lent, interfaage
difficile, ...) et pour garder un mme co-systme, les membres du projet IdP ont
dcid dcrire tous les codes en Python.
3.1
Langage : Python
Un des premiers avantages du Python est donc quil convient toutes les parties
du systme :
Pour les scripts : Notamment utile pour lOCR et le contrle des webcams,
mais galement pour les compteurs virtuels qui seront discuts dans la section
5
Pour le modle, la librairie numpy [35] permet le calcul matriciel et scientifique
Pour linterface, de nombreux frameworks et plugins sont disponibles en Python
19
20
CHAPITRE 3. CHOIX LOGICIELS
Le Python est un langage interprt, cest dire quil nest pas compil. Linterprteur Python excute directement des instructions crites dans un fichier source
contenant du texte. Bien-sr des sries doptimisations permettent de garder une
version entre le binaire et la source pour ne pas rinterprter tout le texte chaque
excution. Les applications Python sont donc directement cross-platform puisquil
suffit dinstaller linterprteur Python sur un des trs nombreux systmes supports
[43] pour que lapplication puisse tourner.
Le Python est un langage orient objet. En quelques mots, cela signifie que lcriture dune application est faite en petits modules auxquels sont dlgus certaines
fonctionnalits et ces modules sappellent entre eux pour former lapplication. Le
Python est souvent dcrit comme "hautement" orient objet, dans le sens o il ne
dispose pas de types primitifs : les entier ou caractres sont des objets. Il est galement dit de haut niveau, dans le sens o il est considr "loin du code machine",
lutilisation ne requiert aucune connaissance sur la structure de son ordinateur, et
particulirement de la mmoire : il ny aura jamais en Python dutilisation de malloc
ou autre. Lutilisation mme de tableaux taille fixe est trs limite, car ceux-ci sont
souvent remplacs par des listes dynamiques.
Python convient trs bien pour des petits scripts notamment grce ses nombreux
plugins qui permettent dcrire rapidement de petites applications sans rinventer
la roue (Voir notamment la Python Package Index [44]), mais il convient aussi
lcriture dapplications modestes. Il est utilis par des grands noms tels que Google
(bien que son utilisation au sein de la socit ait tendance disparatre au fur et
mesure du dveloppement de lentreprise) [46]. En effet le Python tant interprt, il
est forcment plus lent [42] et tend tre abandonn lorsque des projets dpassent
une certaine taille. Est-ce une raison pour ignorer le Python ? Non, puisque beaucoup
dapplications ne requirent pas de travail lourd, le Python permettant presque
toujours un code plus concis [38], gagnant ainsi du temps de programmation. Ainsi, le
Python convient lappel de fonction natives ou dautres applications. Sil est de plus
en plus utilis dans le calcul scientifique via numpy[35] ou SciPy[48], cest notamment
parce que les performances ne sont pas tant impactes, car ces modules font appel
des librairies crites en C ou fortran. Lutilisation du Python permet des codes
concis, facilement comprhensibles qui sont en outre trs utiles la communaut
scientifique. Celle-ci appelle tout particulirement un grand partage des applications
dans un langage facilement lisible et universel. Il est galement beaucoup utilis
comme langage de plugins dans plusieurs applications connues tels que Blender [4]
ou Inkscape [25] pour ces mmes raisons.
Lutilisation du Python reprsente aussi un choix personnel parmi les autres
possibilits offertes en matire de langage pour implmenter une interface web. En
effet, je souhaitais opter pour un autre langage que le PHP avec lequel javais dj
beaucoup travaill au travers la conception de nombreux sites. Je dsirais donc varier.
Le Java aurait galement bien convenu grce ses framewsork pour le Web mais son
3.2. FRAMEWORK : DJANGO
21
utilisation tait dej fort rpandue dans le cadre de lUniversit. Je lavais galement
utilis lors de mon stage.
3.2
framework : Django
Bien quil soit envisageable de gnrer directement du code HTML en Python,

lutilisation dun framework a plusieurs utilits :
La gestion plus fine de lHTTP, des codes derreurs, des donnes envoyes via
des requtes POST, etc
Un framework vient souvent avec une srie de mcanismes ou darchitectures,
comme le Modle-Vue-Contrleur (MVC) qui permet de sparer la gestion de
la reprsentation de linformation, et les interactions de lutilisateur.
Souvent, les frameworks fournissent un systme de template prenant part au
cadre de larchitecture MVC. Les templates sont des pages crites en HTML
o le progammeur indique lemplacement o viendront sinscrire les donnes,
calcules ailleurs dans le code.
Respecter la structure propose par un framework permet galement dassurer
la continuit dun projet. Un framework est plus facile utiliser lorsquil est
dj familier des milliers de programmeurs : sil faut rajouter une page au
site, ils nauront pas besoin de chercher quelle fonction gre les url, quelles
fonctions grent le rendu de cette page, o placer les images, etc.
Les frameworks intgrent galement presque tous un systme de dploiement
et de test pour la mise en production avec, par exemple, un mode de dbogage
pour le dveloppeur.
Lintgration de mcanismes de scurit comme la gestion de lauthentification
de lutilisateur ou la protection contre certains types dattaques courants
Jai donc tudi diverses possiblits en matire de framework Python. Mes
recherches prliminaires ont fait ressortir deux frameworks qui sont les plus connus
et les plus cits : Pylons[40] et Django[13]. Le web ne manque pas de littrature sur
le sujet "Pylons vs Django", mais peu de sources sont scientifiquement fiables car
elles sont souvent bases sur des opinions et des points de vue subjectifs. Django
est sans doute plus orient "modules". Nous verrons quil spare les applications
et permet den rutiliser certaines, l o Pylons dispose dun dossier modles, un
dossier contrleur et un dossier templates. En ralit, il serait difficile de justifier mon
choix sans refaire lintgralit du projet sur ces deux frameworks. Jai choisi Django
notamment par sa plus grande popularit. Une communaut trs large garantit plus
de sources de documentations et offre de nombreux petits modules qui permettent
de ne pas rinventer leau chaude.
Django a t cr en 2005 et a beaucoup volu depuis. Il dispose dune bonne
maturit, et dune bonne stabilit grce son systme de branche test, et stable. La
documentation est claire quant aux versions et branches, ce qui est souvent oubli
dans les documentations de logiciels informatiques. Les dveloppeurs veulent souvent
22
garder la documentation au niveau de la dernire version.

Django suit le modle MVC, garantissant une sparation claire de la partie logique,
de la partie affichage, et de la partie donne/modle. Il dispose dun systme de
template simple et puissant. Celui-ci permet de dfinir rapidement la structure de la
page en HTML et de choisir lemplacement de laffichage du contenu dune variable,
ou lexcution de boucles simples sur une liste, pour afficher un tableau par exemple.
Il dispose du support pour plusieurs bases de donnes, mais dans tous les cas les
donnes sont dfinies grce un modle (un objet Python) qui sera enregistr comme
une ligne de la base de donne. Django gnre dailleurs automatiquement la base de
donnes en fonction des modles dfinis en Python. Il permet galement de gnrer
automatiquement des formulaires en fonction du modle et la validation de ceux-ci.
Lors de la dfinition dun modle "Article" par exemple, le progammeur peut dfinir
que le champ "titre" a une longueur maximale de 15 caractres. La base de donne
sera cre avec ce paramtre garantissant une optimisation maximale du stockage
des donnes de la base, mais le formulaire affichera galement un message derreur
sil dpasse le paramtre, tout cela avec une intervention trs limite du programmeur.
Un "site web" utilisant Django est divis en plusieurs applications qui correspondent en gnral un set de pages visant laccomplissement dune mme fonctionnalit.
Par exemple un blog simple aura probablement une application "messages" et une
application "commentaires". Lappel de lapplication correcte sopre en fonction de
lURL entre par lutilisateur sur base dexpressions rgulires (regex). Pour ce mme
exemple, deux regex du type " message" et " comments" re-dirigeront vers les
deux applications. Chaque application dispose galement dune gestion dURLs. Par
exemple, /message/ re-dirigera vers la liste des messages du blog mais /message/id
permettra de voir un message particulier. Lutilisation dexpressions rgulires offre
la possibilit de dfinir sa propre structure durl, en saffranchissant du traditionnel
page ?var=value&var2=value2 peu "user-friendly".
Django inclut un serveur de dveloppement. Mme sil est compatible avec presque
tous les serveurs web, Django permet ainsi de dployer trs rapidement un environnement pour commencer programmer. Le serveur intgr est galement adapt au
dveloppement avec Django, facilitant notamment le dbuggage.
Enfin, il inclut pas mal de "modules", de fonctionnalits quil suffit dimporter,
comme par exemple une interface dadministration. En effet, pour beaucoup de sites,
il est ncessaire davoir une interface dadministration qui suivra presque toujours
la mme logique. Dans lexemple du blog, il faudra une interface administrateur
pour crer le message et une autre pour modrer les commentaires. Il suffit dinclure
lapplication admin django, et de paramtrer celle-ci en quelques lignes de codes
pour avoir automatiquement cette srie de formulaires dajout ou de suppression
de messages et de modration de commentaires. De la mme faon, Django inclut
un systme dauthentification, de gestion des utilisateurs et surtout de permissions
23
pour chacun de ses utilisateurs. Il dispose galement de groupes pour runir certains
utilisateurs en catgories, avec les mmes permissions par dfaut. Plus globalement,
il existe beaucoup de packages ( ce jour 1766 rpertoris sur [16]) qui permettent
lajout de ce genre de fonctionnalits en quelques lignes de code.
3.2.1
Scurit dans Django
Django dispose de plusieurs mcanismes de scurit intgrs, tous utiliss dans

linterface et absolument ncessaires pour une interface web dont les principales sont :
XSS : Par plusieurs techniques, un utilisateur pourrait introduire du code
javascript sur une page web. Un exemple classique est une requte GET
faite aussi avec un paramtre qui est affich directement sur la page. Une
personne mal intentionne peut alors renvoyer vers notre site en mettant du
code javascript dans cette requte, pouvant donc altrer la page et changer
ladresse denvoi du mot de passe de lutilisateur qui sidentifierait. Django
chappe les caractres spciaux des variables imprimes dans les templates,
empchant ce genre de techniques.
CSRF : Il sagit ici de se protger contre une attaque de type replay. Il serait
possible de renvoyer la requte HTTP faite par un utilisateur plusieurs fois, en
altrant les donnes et se faisant passer pour lui. La technique de protection
est ici de passer un code unique avec toutes les requtes. Ce code unique nest
valide quune seule fois. La requte ne peut donc pas tre rejoue.
SQL injection : sans doute lattaque Web la plus populaire, et pourtant encore
bien trop souvent prsente. Ainsi,(mais dautres cas sont possibles), lurl dun
site affiche lidentifiant dun message afficher, par exemple www.site.compostid5
. Si le dveloppeur ne fait pas attention et introduit la variable "id" la fin dune
requte SQL tel que "SELECT * FROM posts WHERE id = " + id, un utilisateur pourrait en profiter pour changer lurl par www.site.com/postsid=5 OR 1 = 1,
entrainant laffichage de tous les messages du site ! Dans Django, lutilisation
dobjets appels Modles est toujours de mise, on ne fait presque jamais appel
une requte SQL mais plutt des injonctions telles que "Meter.objects.all()"
qui retournent tous les compteurs. Toutes les requtes sont chappes et, comme
les modles dfinissent le type de donnes, elles sont converties. Dans lexemple
prcdent, Django aurait retourn une erreur de au fait que lID du message
nest pas un nombre.
Le systme dauthentification dj prsent plus haut peut galement tre considr comme faisant partie de la scurit.
24
3.2.2
Base de donnes
Django supporte plusieurs backend pour diffrentes base de donnes. Le ct standard de mySql, mes connaissances de celui-ci et sa relative rapidit ont rapidement
orient mon choix vers lui. Oracle serait un peu trop gourmand en ressource pour un
tel systme, sa configuration tant beaucoup moins simple. Lalternative mySql
souvent prsente est SQLite, un systme de base de donnes SQL qui stocke les
donnes dans un fichier. Le problme est que je voulais garder un accs la base
de donnes depuis lextrieur pour dventuels ajouts de donnes sans passer par
linterface. De plus,si la base de donnes nest pas assez importante pour justifier
Oracle, il ne faut pas oublier quen moyenne 10 compteurs (en ce y compris les
virtuels) envoient des donnes toutes les 5 minutes, soit 2880 lignes par jour, soit
environ 86400 entres par mois. Ceci invite dailleurs lajout dune deuxime table
charge de garder la consommation journalire agrge de chaque compteur. Un
nettoyage automatique de la table "brute" serait opportun mais en labsence du
modle, il est prfrable de laisser toutes les donnes.
Concernant le choix du moteur, nous verrons en dtail les diverses tables et la
structure gnrale de la base de donnes. Linterface doit pouvoir supporter plusieurs
maisons, composes chacunes de plusieurs tages comportant plusieurs murs, euxmmes quips de plusieurs fentres, ... Mon choix sest donc port vers InnoDB qui
intgre la gestion des cls trangres et permet une grande efficacit dans lapplication
des multiples jointures que nous aurons faire.
3.2.3
Technologies Web
Linterface fait un usage extensif de lHTML5 et du javascript. Elle utilise principalement la librairie jQuery, et quelques-uns de ses plugins. Le systme le plus
complexe, cest--dire le dessin des plans (et la modlisation en gnrale), a t crit
entirement en Javascript, dessinant grce llment Canvas introduit avec lHTML
5.
HTML5/CSS3
LHTML nest plus prsenter. Sa version 5 apporte cependant son lot de nouveauts permettant denvisager les fonctionnalits de linterface sans recours un
plugin dans le navigateur tel que le flash ou les applets Java. Si lHTML permet des
modifications faciles du design sans recourir des images, la nouveaut la plus utile
dans notre cas est llment canvas, qui permet de dessiner sur un plan 2D avec des
instructions de base telless que des points, des arcs de cercles, des lignes, etc. Un
autre lment, le SVG, aurait t envisageable. Au niveau de la compatibilit avec
les navigateurs : ils sont au mme niveau. La diffrence est que le SVG permet de
dessiner de faon vectorielle et le canvas de dessiner sur un bitmap. Cependant le
canvas peut aussi bien dessiner en 2D quen 3D (sur les navigateurs compatibles)
25
tandis que le SVG nest quen 2D. Jai choisi dutiliser le canvas pour me laisser la
possibilit dafficher le plan en 3D. Au final, jai modularis totalement le systme
de rendu en un objet Javascript qui reoit des instructions de dessins de fentres ou
de murs, et qui se charge de les traduire pour dessiner sur le systme sous-jacent.
Au final, le SVG aurait donc mieux convenu au module uniquement 2D, puisqu
chaque re-dimensionnement de la page le plan doit tre redessin, mais il tait trop
tard pour changer lorsque jai abandonn lide du plan 3D.
Les problmes de compatibilit sont discuts dans la section 6.6.
Javascript
Une grande difficult a t de grer un code Javascript relativement gros et qui se
veut modulable pour rpondre lobjectif de flexibilit, malgr le ct particulier de
la gestion des objets en Javascript. En effet, le Javascript ne permet pas nativement
dtendre les objets. Il permet en revanche de copier les fonctions dun objet un
autre. Ceci prsente lavantage davoir un mcanisme dhritage mais pas dtendre
une fonction puisque celle-l mme de lobjet parent sera remplace par celle de
lenfant.
Pour combler ces manquements du Javascript, nombreux sites ont recours un
framework. Jai port mon choix sur jQuery [28] car il permet daccder facilement
des lments de la page web, den modifier le contenu, de les animer, et facilite
grandement la gestion de lAJAX... Environ 45% des 100 000 cites les plus populaires
du monde utilisent un framework, et 28% de ceux-ci utilisent jQuery, loin devant les
autres [1].
Lutilisation de jQuery permet aussi dassurer la compatibilit des instructions
sur un trs grand nombre dappareils car certaines instructions se comportent diffrement dun navigateur lautre et jQuery sassure dutiliser les bonnes mthodes.
Techniquement, jQuery najoute videmment aucune fonctionnalit Javascript,
mais il permet de faire beaucoup plus en beaucoup moins de lignes de code et moins
de temps.
Pour les graphiques, cest la librairie Highcharts qui a attir mon attention. Elle
nest cependant pas libre (mais gratuite pour un usage limit tel quil se prsente
dans le cadre de mon TFE). Il existe de trs nombreuses librairies, mais Highcharts
tait une des rares comprenant toutes les fonctionnalits que je dsirais.
26
Chapitre 4
Structure de linterface
Ce chapitre passera en revue la structure de la base de donnes, et les mthodes
utilises pour transfrer les lments de la base de donnes via Django, au client
Javascript. Les lments importants de linterface seront ensuite expliqus comme le
systme de plan, de traitement des donnes ou encore le protocole de communication
entre les capteurs et le serveur.
4.1
Applications
Comme expliqu dans la section 3.2, Django fonctionne en combinant plusieurs

applications. Chaque application est un package Python (un dossier de fichiers
Pythons). Les diffrentes applications sont :
Alert : La page de gestion des alertes
Builder : Les diverses tapes de modlisation
Consumption : La page de consommation
Data : Lchange des donnes avec les capteurs mais aussi lextraction de
donnes brutes pour des statistiques pour les graphiques
Historic : Les pages des statistiques
Main : La page daccueil et de le systme dauthentification
Settings : Les pages de paramtres
Le dossier principal contient galement un package monitoring qui contient les
scripts de Django et la configuration de celui-ci ainsi quun dossier static qui comprend tous les fichiers statiques (les images, les feuille de styles css, et les scripts
javascripts) et un dossier templates qui reprend toutes les templates telles que dcrites
prcdemment.
Chaque application est compose de plusieurs fichiers Pythons :
views.py : Ce fichier contient toutes les fonctions "contrleur" qui reoivent en
paramtre un objet HttpRequest, contenant les informations sur la requte de
lutilisateur. Ces fonctions sont charges de retourner un objet HttpResponse
qui contiendra le code HTML renvoyer au navigateur, et le code de rponse
HTTP
27
28
CHAPITRE 4. STRUCTURE DE LINTERFACE
Figure 4.1 Structure des donnes relatives la maison

models.py : Ce fichier contient les modles. Ceux-ci dcrivent les objets et
chacun de leurs champs qui seront enregistrs dans la base de donnes. Seules
certaines applications ont des modles. Tous les modles relatifs la maison sont
dans le models.py de builder. Ceux qui sont relatifs aux relevs des compteurs
se trouvent dans data, et le profil utilisateur est dfini dans main.
urls.py : Ce fichier associe des expressions rgulires aux vues dfinies dans
views.py, permettant ainsi de dfinir quelle vue sera utilise en fonction de
lURL
Le fichier urls.py du dossier monitoring permet de dfinir quelles applications
seront appeles en fonction de lURL. La partie matche de lexpression rgulire
est enleve et la partie restante est vrifie en fonction dun fichier urls.py dans le
dossier de lapplication, pour lancer la vue correspondante.
4.2
Structure de la base de donne
La base de donnes peut tre divise en 3 parties distinctes : la structure de la

maison 4.1, les alertes 4.2 et lauthentification 4.3.
4.2. STRUCTURE DE LA BASE DE DONNE
Figure 4.2 Structure des donnes relatives aux alertes
Figure 4.3 Structure des donnes relatives aux utilisateurs
29
30
Pour rappel, Django cre automatiquement la base de donnes et lextension

django-extensions[15] permet galement de gnrer les graphiques des figures 4.1, 4.2
et 4.3. Il gre galement les cls trangres et cre des relations inverses dans lobjet
Python. Ds lors, si lobjet maison possde plusieurs tages, la relation etage.house,
permet de remonter la relation en sens inverse.
4.2.1
Structure de la maison
Linterface supporte plusieurs maisons reprsentes par lobjet maison (House).

Les champs de lobjet maison correspondent ceux que lutilisateur doit encoder
ltape 1 dcrite dans la section 6.1. Une maison est compose de plusieurs tages
(Floor), eux-mmes composs de plusieurs murs (Wall), et de fentres (Window).
Les fentres ne sont donc pas lies au mur mais ltage. Les murs sont dfinis par
deux positions, ils ont une paisseur disolant et une paisseur totale du mur. Les
fentres sont dfinies par une position et une orientation et disposent galement
dune information de largeur et de hauteur. Uune srie de personnes (Person) sont
associes la maison. Le fait de crer des relations vers des objets Position plutt
que de crer des champs x et y au sein des murs et fentres est d la gestion directe
de la base de donnes par Django. Pour pouvoir garder un objet Position Python,
les tables doivent tre spares, ce qui imposera malheureusement de nombreuses
jointures qui auraient pu tre vites.
Chaque tage peut contenir plusieurs appareils (ApplianceType). Le lien entre un
type dappareil et un tage est fait par la relation ApplianceLink. Chaque appareil
fonctionne avec une ou plusieurs nergies, cest donc une relation multiple gre
automatiquement par Django. En ralit, il cre une table comprenant une rfrence
vers un ApplianceType et un objet Energy, afin de pouvoir lier plusieurs nergies
plusieurs appareils.
Les compteurs sont relis soit un appareil (via son lien ApplianceLink) soit
une maison (House). En effet, les compteurs peuvent tre li un appareil, ou tre
dfini en tant que compteur global de la maison. Chaque compteur est aussi li
une nergie, on peut ainsi dterminer quelle nergie de lappareil ou de la maison il
est charg de mesurer.
Le compteur dispose dun champs "mode" qui peut prendre 3 valeurs :
Instantan (INS) : le compteur envoie la consommation instantane
Total (TOT) : le compteur envoie la consommation totale depuis sa mise en
activit
Diffrentiel (DIF) : le compteur envoie lnergie totale consomme depuis son
dernier envoi
Les nergies disposent galement dun champs type, qui peut prendre 3 valeurs
galement :
4.2. STRUCTURE DE LA BASE DE DONNE
31
Puissance (POWER) : ce sont les nergies qui peuvent produire un travail,

comme llectricit, le gaz, ou le fuel
Consommable (CONS) : ce type est fait pour ce que lon voudrait mesurer,
mais qui nentre pas dans la consommation dnergie, comme leau. Leau nest
pas une nergie et nest pas convertissable en tant que telle. Cependant la
consommation deau est une information ncessaire pour lutilisateur et est
souvent considre comme facteur cologique. Elle a donc toute sa place dans
notre interface.
Etat (STATE) : ceci concerne les compteurs qui reprsentent un tat, comme
la temprature. On ne consomme pas de la temprature, cependant elle est
galement utile dans lvaluation de la consommation en chauffage
Lactivateur on/off (nergie "switch") est galement considr comme un tat. Ici,
le systme de compteur est abus et ce sera linterface qui permettra de dfinir une
valeur au compteur "switch", dont le relais, qui est charg dallumer effectivement
ou teindre un appareil, viendra lire la valeur.
Les changements de traitement que cela induit seront discuts dans la section 4.6
Traitement des donnes.
Les relevs sont lis au compteur, ils contiennent lheure et la date du relev, et
la valeur (amount) lue sur le compteur. Notons quil y a aussi une table charge de
retenir le relev par jour. Lopration sera dcrite en dtail dans la section 4.6, mais
les calculs en fonctions du modes de compteurs tant trs nombreux, lajout dune
donne, la consommation du jour est calcule et enregistre pour pouvoir afficher
rapidement les donnes sur une anne complte par exemple, permettant de traiter
uniquement 365 relevs et non plus de 100000.
4.2.2
Alertes
Le cahier des charges imposait une interface simple mais puissante. Cette recherche
ma orient vers un systme de puzzle (Voir fig. 4.4) o lutilisateur voit directement
quelles pices il peut emboiter, et crer une logique en assemblant des lments du
puzzle. Toutes les pices du systme de "puzzle" appartiennent lune des 4 classes
suivantes :
AnalogMeter : Reprsente une pice qui est la premire entre : le relev dun
compteur. Elle contient donc un lien vers un objet Meter tel que prsent dans
la section prcdente.
ADC : Elle reprsente une pice qui convertit une entre analogique en une
sortie digitale. Elle dispose dun champs seuil (threshold). Le champs Lastvalue
permet de garder en mmoire la dernire valeur lue afin de permettre de reprer
le moment o une donne traverse le seuil, sans devoir remonter la chaine
jusquau compteur.
32
Figure 4.4 Gestion des alertes lutilisateur.

Logic : ce sont les pices digital vers digital qui servent filtrer des vnement
selon certaines conditions.
Alert : ce sont les pices finales, charges de dclencher une action comme une
notification ou un mail
Chacune de ces pices tend (dispose dun lien vers) un objet AlertModel. Cet
objet sert dfinir quelles pices sont lies quels autres via une relation multiple.
La base de donne permet donc des pices avec plusieurs sorties et plusieurs entres,
mais linterface ne le permet pas, par manque de temps et de rel intrt. Le systme
est dj puissant comme a, et la priorit serait plutt de dfinir de nouvelle pices
comme de nouvelles entres sur la consommation journalire dun compteur, lheure
de la journe ou tout autre donne numrique, et dautres sorties comme laisser
la possibilit de lancer une requte HTTP en cas dalerte, un SMS, etc. Notons
simplement que toutes ces pices sont donc possibles, mais il fallait bien mettre une
limite au champs de la prsente recherche.
4.2.3
Authentification
La plupart des modles sont ici fournis directement par le package dauthentification Django. Le seul cr par mes soins est lobjet profile, permettant de dfinir
si lutilisateur est en mode avanc (advanced) et sil dsire loption de dfilement
automatique (autoscroll). Les groupes ne sont pas utiliss dans linterface, par contre
les permissions le sont.
4.3. TRANSFERT DE DONNES ENTRE DJANGO ET LES APPLICATIONS JAVASCRIPT33
4.3
Transfert de donnes entre Django et les applications Javascript
De nombreuses donnes extraites de la base doivent tre transfres telles quelles

lapplication Javascript. En effet, si Django est particulirement efficace pour aller
rcuprer des donnes dans la base et les traiter pour les afficher dans une template,
il ne prvoit pas spcialement de passage des donnes une application Javascript.
La diffrence rside dans lutilisation de ces donnes qui doivent tre passes brutes
au sein dune application Javascript. Par exemple, il nest pas question de gnrer
ct serveur le plan en HTML, puisque celui-ci doit pouvoir tre modifi.
Pour le transfert dans le sens serveur vers Javascript, cest le JSON qui a t choisi.
En effet, il peut tre directement crit sur la page dans une balise <script>, puisque
le JSON est le format de description dobjets et de tableaux natifs du JavaScript. Le
traitement de celui-ci est donc particulirement performant.
Il reste dcider comment grer les relations entre les objets. Il y a deux possibilits :
soit Django donne la page un objet House, une liste dobjet Meter, Energy,
etc. Pour trouver les informations sur lnergie que mesure le compteur, il suffit
alors de parcourir la liste des nergies pour trouver lnergie identifie par lid
contenue dans le champ energy_id du compteur.
soit crire toute la structure tendue en JSON, en remplaant le champs
energy_id de lobjet Meter qui identifie lnergie quil mesure directement, par
un champs energy qui contient lobjet reprsentant lnergie.
Cette dernire relation introduit une redondance, puisque si trois compteurs mesurent
la mme nergie comme llectricit, lobjet Energy pour llectricit sera crit trois
fois. La premire mthode elle, implique la gestion dun systme dindex et un
traitement plus lourd pour la gestion de nombreuses relations. Cest la deuxime
mthode, o il sagit de suivre la structure que jai choisie. En effet, tant que les
donnes ne sont pas modifies, la redondance nest pas trs grave, et cela simplifie
grandement la gestion des relations, puisquon peut accder directement un sous
objet en utilisant par exemple meter.energy.color. Afin dillustrer le processus, la
figure 4.5 reprsente les donnes des compteurs transfrer lapplication Javascript
de dessin du plan. La figure 4.6 montre le code du contrleur Python et la figure
4.7 le code du template HTML contenant linstruction {{meters|safe}} qui sera
remplace par le contenu de la variable meters dans le code HTML (dans une balise
script). Le filtre |safe permet de ne pas activer lchappement automatique que fait
Django pour les caractres spciaux.
Pour crire ces donnes, Django possde un mcanisme de srialisation, mais qui
ne permet malheureusement pas la srialisation en profondeur. En dautres termes,
si on lui demande de srialiser lobjet Floor, il ne dcrira pas lobjet House, mais
dfinira un champs house_id avec pour contenu lindex de la maison. Pour cela
34
Figure 4.5 Exemple de traverse des donnes - Donnes des compteurs tels
quenregistrs dans la base de donne mySQL
Figure 4.6 Exemple de traverse des donnes - Code Python charg daller
rcuprer les donnes dans la base. Le contexte associe des variables qui seront
utilises dans une template pour tre remplac par les donnes.
Figure 4.7 Exemple de traverse des donnes - Template contenant la variable

meters qui sera remplace par le code JSON par Django
4.3. TRANSFERT DE DONNES ENTRE DJANGO ET LES APPLICATIONS JAVASCRIPT35
Figure 4.8 Exemple de traverse des donnes - Objets reprsents en JSON tel
que gnr par le plugin FullSerializer
jai utilis le plugin Django FullSerializers qui ajoute la possibilit dnoncer quels
modles identifis par des cls trangres il faut dvelopper.
Notons que les objets JSON sorti par Django sont nettoys par la fonction
jsonStripModel() du fichier global.js. En effet les objets JSON gnrs par Django
contiennent quelques champs qui dfinissent le type de modle et des mta-donnes
sur la classe (Voir fig. 4.9). Les donnes elle-mmes sont dans un objet fields. Cette
fonction cre un objet de classe correspondant au modle en fonction des mtadonnes, avec pour champs, les variables du modles et comme valeurs des champs,
leur contenu (Voir fig. 4.10). En Javascript, mme les objets spcialement dfinis
sont anonymes. Il ny a pas de diffrence entre linstruction var person = new
Person(22,Tom,STUDENT) ; et var person = {age :22,name :Tom,work :STUDENT ;}. En effet, demander quel est la classe de ces deux objets retournera toujours
"object". Ainsi, seuls certains objets pour lesquels des fonctions sont spcifiquement
dfinies, par exemple les murs, possdent une fonction getOrientation() qui retourne
lorientation du mur ; ceux l sont dfinis dans models.js. Les autres sont donc crs
de faon anonyme.
Lorsque les donnes sont modifies, lenvoi du Javascript vers Django ne se fait pas
en JSON mais directement par la fonction objects_to_request() qui gnre les donnes
formates pour une requte POST standard. Les donnes de plusieurs positions
sont ainsi renvoyes sous la forme num_positions=X&position_x1=X1&position_y1=Y1&position_x2=X2&.... La d-srialisation tant de toute faon impossible
faire automatiquement ct serveur puisque les objets sont anonymes, leur classe
36
Figure 4.9 Exemple de traverse des donnes - Reprsentation interne aprs

parsing par le navigateur du code JSON reprsent dans la figure 4.8. On observe
que les donnes utiles sont dans un sous-objet fields de lobjet Meter, et que son
type est contenu dans model.
Figure 4.10 Exemple de traverse des donnes - Objets aprs transformation par
jsonStripModel() de la liste de structure Meter. Par rapport la figure 4.9, il ny
a plus de sous-structure fields, et le champs model a t utilis pour instancier des
objets de la classe correspondante.
4.4. SYSTME DE DESSIN DU PLAN
37
tant perdue il ntait pas spcialement avantageux dutiliser le JSON plutt quune
boucle rcuprant les requtes. Si le JSON peut tre pars nativement par tous
les navigateurs, il ne peut pas tre cris nativement et doit donc faire lobjet dun
traitement plus lourd par une librairie externe. De plus le Python est moins dynamique
que le JavaScript et il est plus compliqu de faire les transformations cites dans les
paragraphe prcdent en sens inverse.
4.4
Systme de dessin du plan
La partie la plus complexe du travail a sans doute t dcrire le systme capable

dutiliser un lment HTML canvas (tel que prsent dans la section 3.2.3) pour
dessiner le plan dune maison dont les lments sont enregistrs suivant la structure
prsente dans la section 4.2.1, mais surtout permettre la dfinition de ces lments,
cest dire le placements des murs, des fentres, des objets composant la maison, et
des compteurs. Il faut galement viser une modularit plusieurs niveaux : que le
systme de rendu sous-jacent soit facilement inter-changeable, et que les fonctionnalits du plan puissent tre ajoutes et modifies souhait. En effet, il faudrait
pouvoir ajouter une tape de dfinition des portes aprs celle des fentres par exemple.
Comme expliqu dans la section 3.2.3, le Javascript ne prvoit pas de mcanisme
dextension des fonctions (sauf par copie de celles-ci, ce qui est peu performant).
Jai donc implment un gestionnaire dvnement EventManager (implment dans
eventmanager.js), qui permet dinscrire des fonctions appeler lorsquun vnement
est dclench. Par exemple le plugin de dessin des murs inscrira sa fonction de dessin
des murs lvnement "refresh" du plan. Ainsi lorsque le plan doit tre redessin,
il dessine les lments de base comme la grille ou larrire plan, et appelle ensuite
toutes les fonctions inscrites lvnement "refresh".
Les pages HTML utilisant le systme de plan ne contiennent que le code et
les donnes ncessaires au dessin du plan vide, tel que la liste des tages. Chaque
plugin se charge daller rcuprer le contenu ncessaire au dessin de ses lments en
AJAX, permettant la page de se dessiner rapidement, pendant que le chargement
des donnes se fait. Le plugin de gestion des murs du plan (plan_walls.js) inscrira
sa fonction de chargement lvnement "floorChanged", ainsi, chaque fois que
lutilisateur change dtage, les murs seront rechargs. Ce plugin dfinit aussi un
nouvel vnement "wallLoaded",appel lorsquil a termin de charger la liste des
murs. Le dessin des fentre sinscrira ce dernier vnement mais celui des appareils
galement. En effet, il semble logique de charger et dafficher les murs avant les
fentre, mais les fentres et les objets peuvent se dessiner dans un ordre quelconque
aprs les murs. Ce systme permet galement de navoir quun dessin partiel. En
effet, lorsque lutilisateur dsire modifier les murs de sa maison, il est intressant
de nafficher que les murs sil na pas besoin des appareils et des compteurs par
exemple. Il suffit de ne pas inscrire les vnements de dessins de ces derniers pour ne
pas les afficher. Les fonctions concernant les compteurs, les fentres, les appareils
38
et les murs sont groupes respectivement dans des groupes de fichiers JavaScript
spars par fonctions, afin de permettre un chargement minimal en accord avec les
fonctionnalits demandes.
Comme certains vnements sont asynchrones, ils peuvent finir en mme temps ou
des moments trs proche. La fonction refresh() inclu donc un mutex plan.refreshing
pour empcher plusieurs rafraichissements simultan. De plus, il serait inutile de
rafraichir le plan plus de 15 fois par secondes (nous parlons bien ici de changer le
contenu des pixels, pas de la frquence daffichage de ces pixels lcran). Mme
quand lutilisateur passe sa souris au dessus du plan et que lon doit dessiner la
position dune future fentre qui change constamment de position par exemple. Le
mutex nest donc ractiv que 66ms aprs la fin du rafraichissement du plan. Si une
demande de rafraichissement du plan est faite pendant ce temps, elle ne sera excute
quaprs les 66ms. Si une deuxime demande de rafraichissement, elle sera ignore.
Le schma gnral est visible sur la figure 4.11. Plutt que d adresser directement llment canvas, un objet charg du rendu (renderer.js) est responsable de
la translation dobjets complexes en primitives 2D. Ainsi, le plugin de gestion des
murs demandera au Renderer de dessiner un mur avec son paisseur et sa position
"relle" en mtre, et le Renderer se chargera de traduire ces donnes en une srie
de fonctions de dessin de rectangles pour llment canvas, tout en se chargeant de
convertir les positions relles en positions lchelle du plan en pixels. Lide est
ici que ce Renderer soit totalement interchangeable, pour pouvoir utiliser un autre
lment sous-jacent que le canvas, ou dessiner en 3D grce WebGL par exemple. Le
JavaScript ne permet pas dimplmenter des interfaces au sens Java du terme, mais il
faut considrer que le Renderer en utilise un. Notons que le dessin des compteurs se
fait en HTML et non directement sur le canvas, notamment pour pouvoir utiliser des
librairies de graphiques en JavaScript. L aussi, les positions des lments sur le plan
sont calcules par Renderer, sans faire de traduction par lchelle dun pixel/mtre
directement afin de ne pas casser la modularit.
Tous les plugins ont plus ou moins la mme structure : la fonction registerYYYPlugin() o YYY est Wall, Window, Appliance ou Meter se chargent denregistrer les
vnements ncessaires au fonctionnement du plugin. En gnral, il y en a un pour
le chargement des donnes ncessaires qui sinscrit lvnement "floorChanged" ou
"wallLoaded" et un autre pour laffichage sur le plan qui sinscrit lvnement "refresh". Les pages qui se contentent dafficher le plan appellent les 4 fonctions register.
Les pages de lapplication builder inscrivent en plus, des fonctions aux vnements
"click" et "move" pour interagir avec lutilisateur lorsquil clique sur le plan (ou
le touche du doigt pour les smartphone) et lorsque la souris bouge au dessus de celui-ci.
La plupart des maisons ont la mme enveloppe extrieure chaque tage. Pour ne
pas que lutilisateur aie recopier les murs extrieurs lorsquil change dtage, lors de
ltape de dfinition des murs, et que ltage infrieur est dj dfini, un algorithme
4.4. SYSTME DE DESSIN DU PLAN
39
Figure 4.11 Organisation du dessin du plan
Figure 4.12 Copie automatique des murs extrieurs. Les murs de ltages du
dessous sont visibles en rouge. Les murs extrieurs sont automatiquement copis.
40
danalyse en composante connexe en deux passe sera appliqu sur le plan du mur
(fonction plan_labelize() dans plan.js) pour trouver les murs extrieurs (Voir fig.
4.12). Pour rappel, la mthode consiste simplement analyser les cases dans lordre
gauche-droite, haut-bas et leurs attribuer un numro appel label qui commence
0. Le numro est choisi comme le plus petit des numros en haut et gauche de
la case analyse, sauf si elles sont spares par un mur. Si les deux sont spares
par un mur, alors on augmente le label puisquon entre dans une nouvelle zone. La
seconde passe se fait en sens inverse, et consiste attribuer le plus petit des label
des zones droite et en dessous de chacune de chacune des cases du plan si elles
sont dans la mme zone. Le rsultat est un tableau correspondant chaque case
de la grille du plan, contenant le numro de la zone laquelle appartient la case.
Les zones correspondant aux pices, et la partie extrieure tant toujours la zone
numro 0. Il suffit alors de copier les murs ayant une zone positive et une zone gale 0.
Cet algorithme est galement utilis pour colorer les pices de la maison de faon
diffrentes pour un rendu plus agrable.
4.5
Protocole de communication
Cette section discutera du protocole denvoi des donnes des capteurs vers le
serveur web. Plusieurs possibilits soffraient moi : lutilisation dun protocole de
monitoring spcialis comme SNMP, implmenter moi-mme un protocole bas sur
TCP ou UDP, ou utiliser le protocole HTTP pour directement communiquer avec
linterface. Cest ce dernier que jai choisi.
Pour rappel, ce travail se faisait dans le cadre dun projet plus global, o dautres
quipes de personnes nayant presque aucune comptence en informatique devaient
menvoyer des donnes via leurs capteurs prsents dans la section 2.1. Il fallait
donc un systme trs simple, limplmentation dun agent SNMP, lauthentification
dSNMPv3 ncessaire la scurit de ce projet, ou encore la connaissance du principe
des MIB excluant doffice le choix de ce protocole. Quant limplmentation dun
protocole via TCP ou UDP, la question tait de dterminer lavantage rel, puisque
javais de toute faon un serveur HTTP disposition (celui charg de linterface),
prenant en charge tout ce dont javais besoin. De plus, les divers clients peuvent
faire appel aux librairies HTTP disponibles dans tous les langages, ou utiliser des
programmes Linux comme WGET directement appels par un script.
Chaque compteur (reprsent par lobjet Meter) dispose dun hash, une squence
de 12 lettres majuscules, minuscules et chiffres, donne lutilisateur lorsquil dfinit
un compteur dans sa maison. Lutilit de ce hash est de disposer dun identifiant
"secret" pour le compteur quun logiciel ne pourrait pas trouver par force brute pour
envoyer ou lire de fausses donnes. Pour ajouter un relev, le client na qu mettre
une requte HTTP(s) sous la forme :
4.5. PROTOCOLE DE COMMUNICATION
41
https ://server.com/data/put/HASH/123,456 o 123,456 est la valeure lue dans

lunit standard tel que dfinie dans les paramtres de linterface.
Linterface dispose dun systme dauthentification avec nom dutilisateur et
mot de passe, mais /data en est dpourvu, car le hash est suffisant pour garantir
lauthentification de la source. Lauthentification requiert un envoi via une requte
POST.
Cependant, le protocole http est interceptable : cest pour cette raison quil est
conseill dutiliser lHTTPS et non lHTTP, afin dempcher quiconque de lire les
donnes en coutant le trafic sur le rseau, mais surtout de trouver le hash. Notons
quil faut galement un certificat authentifi si lon veut se protger de lattaque
de lhomme au milieu. En effet, un ordinateur pourrait se mettre entre le client et
linterface, et utiliser un serveur HTTPS qui comprend la requte et la renvoie
linterface de faon invisible. Cependant, il ne pourra pas avoir un certificat authentifi
par une autorit valable pour notre serveur.
Pour lire la dernire donne en date, le client peut utiliser :
https ://server.com/data/get/hash/
Cela est notamment utile pour les boutons qui doivent lire la valeur du compteur
afin de savoir si lappareil est sens tre allum ou teint. Pour avoir une bonne
ractivit, il doit donc le faire souvent. La mthode peut tonner premire vue
puisque une requte de la part du serveur au client linstant mme du changement
mnerait une bien plus grande ractivit. L encore, le choix vient de lexprience
relle : le client sera derrire un routeur, pratiquant le NAT. Nous voulions un systme
non intrusif ne requrant pas de comptences, excluant donc la redirection de port
manuelle. La redirection de port pourrait se faire en UPNP automatiquement, mais
de nouveau cela impose un client assez comptent. Ici, lutilisateur na qua configurer
le serveur de linterface et le hash.
Un dernier avantage de lHTTP est quil passe trs bien les firewall, mieux quun
protocole TCP maison sur un port inconnu (bloqu par exemple luniversit ou
tait notre serveur), ou quun protocole UDP, lui aussi souvent refus. Le dsavantage premier est quil rend plus difficile le monitoring. En effet, de plus en plus de
dveloppeurs aboutissent la mme conclusion et utilisent lHTTP, obligeant les
administrateurs faire du "deep packet inspection", pour voir quels sont rellement
les types de donnes changes.
De plus, cette simplicit permet de mettre rapidement en place des compteurs
virtuels qui seront prsents dans le chapitre 5, ou mme de parser les donnes
dautres capteurs ou de systmes semblable au ntre pour les envoyer notre
interface, permettant ainsi des "couches de compatibilit".
42
4.6
Traitement des donnes
A la rception dune donne, lapplication data se charge de lenregistrer, tout en

mettant jour le compteur de consommation de la journe.
Le calcul de la consommation totale doit se faire en fonction du type du compteur.
En effet, si le compteur est en mode instantan, la consommation totale ajouter
sera la valeur indique en instantan, multiplie par le temps depuis le dernier relev.
Pour les compteurs qui envoient un total de consommation depuis la mise en service, il suffit de soustraire la dernire valeur envoye celle de la dernire valeur
envoye la veille, pour avoir la consommation de la journe. Quant aux compteurs
diffrentiels, il suffit dajouter la consommation envoye la journe courante. Tous
ces calculs se font en interceptant la fonction save() du modle des relev, Reading
(voir data/models.py).
Un choix plus correct pour lenvoi de la mesure en mode instantan consisterait
considrer la moyenne de la valeur envoye et celle de la dernire valeur, et de
multiplier cette consommation instantane par le temps entre les deux consommations.
En ralit, considrer que la consommation de la dernire priode est celle du dernier
relev permet au client de dfinir la consommation qui est apparue en cas de panne
ou darrt du compteur. Imaginons quun compteur envoie des consommations
instantanes toutes les 5 minutes. Si la connexion est coupe 30 minutes mais que
lappareil continue de consommer, alors la consommation instantane sera multiplie
par 30 minutes ds le rtablissement de la connexion et le total sera correct. Cependant
dans le cas dune panne lectrique gnrale o lappareil sest teint galement, il ne
faut pas que lorsque lappareil et son compteur redmarrent, le systme considre
que lappareil a consomm pendant cette priode. La solution est denvoyer une
consommation instantane de 0 au redmarrage de la machine, et reprendre ensuite
normalement. Ainsi la priode darrt sera multiplie par 0, et les priodes suivantes
seront multiplies normalement. Cette mthode permet de saffranchir de systmes de
timeout, et de laisser le client grer la reprise en cas dchec, en fonction du scnario.
Cette mthode est utilise pour la consommation dun ordinateur qui se mesure
lui-mme. Lorsquil dmarre, il envoie un 0 pour signifier quil na rien consomm
depuis le dernier relev (en pratique, il envoie une valeur trs faible pour signifier
une consommation de veille).
4.6.1
Pre-processing
Certaines donnes peuvent cependant tre ignores pour allger la base de donnes.
Par exemple, si le compteur est en mode total, il est inutile denregistrer plus de
deux fois la mme valeur. Il est cependant utile de garder en mmoire la premire et
la dernire fois que cette valeur a t lue, afin que lutilisateur puisse constater quil
y a eu un palier (en thorie la consommation deau en comporte beaucoup, lorsquil
ny a personne dans la maison). Sur la figure 4.13 reprsentant une consommation
instantane dune telle situation, les trois points au centre du palier sont inutiles.
Pour ne pas les enregistrer, le systme vrifie avant denregistrer un relev, que les
4.6. TRAITEMENT DES DONNES
43
Figure 4.13 Exemple de donnes de consommations instantane reues. Les 3

points centraux du plateau sont ignors.
deux prcdents ne sont pas quivalents. Si cest le cas, il supprime le dernier en
date et ajoute un nouveau relev lheure actuelle. Ainsi, trois valeurs identiques
napparaissent jamais daffile, et la premire apparition du relev est conserve, ainsi
que la dernire en date.
Remarquons que la mthode sapplique aux compteurs instantans, mais pas aux
compteurs diffrentiels, puisque la suppression dune valeur impliquerait un recalcul
du total de la journe incorrecte. Les valeurs pouvant tre ignores pour ce dernier
tant le 0.
Il est important de noter que les relevs enregistrs comme Reading sont dans
le format original du compteur, mais ceux de ReadingDay prsentent toujours la
consommation totale de la journe. Lobjet Energy contient les sigles des units de
consommation instantane et de consommation totale pour laffichage de celle-ci (ie.
pour llectricit, la consommation instantane est en kW, la consommation totale
en kWh).
4.6.2
Post-processing
A laffichage des donnes dans linterface, certains traitements sont galement

effectus sur la page daffichage des consommations. Ce qui importe sur cette page
( loppos de la page statistique), cest de donner un aperu de sa consommation
lutilisateur en un seul coup doeil : il doit voir une tendance et non une courbe exacte.
Ainsi, on prfrera les graphiques de la figure 4.15 ceux de la figure 4.14. Pour cette
raison, sil y a plus de 30 relevs pour les dernires 24 heures, elles seront moyennes
par tranche de N/20 arrondies au chiffre suprieur. Etant donn que les valeurs de
tempratures dune journe sont souvent discrtes, les compteurs de temprature
sont toujours moyenns, quelque soit le nombre de relevs, afin de supprimer leffet
de palier qui ne reprsente pas la ralit. Notons que la dernire valeur est copie en
cas de moyennage afin que lutilisateur ait lheure du dernier relev et la dernire
valeur exacte sur le graphique.
44
Figure 4.14 Donnes des dernires 24 heures sans moyennage
Figure 4.15 Donnes des dernires 24 heures avec moyennage
4.7
Systme dalertes
La page servant la dfinition du systme dalertes est compose dune part des
plans de chaque tage de la maison pour que lutilisateur clique sur le compteur
mesurer, et dautre part de la zone de placement des pices, qui contient toujours
une pice AnalogMeter lie au compteur slectionn.
Lorsque lutilisateur choisit un compteur, la chaine de pices existantes est charge
depuis le serveur en AJAX par une requte GET. La vue Django correspondante
(fonction get dans alert/views.py) imprime toute la structure de la chaine en JSON,
en crant une liste "outputs" contenant tous les lments pointant vers lAnalogMeter
correspondant au Meter slectionn. Il fait de mme pour chacune des pices trouves,
suivant ainsi toute la chaine.
Comme pour le transfert des donnes de la structure de la maison, les objets
anonymes reus en JSON sont lus et changs par des objets JavaScript correspondant
chacun des types de pices (voir js/alert/alert.js). Chacune de ces pices tend
galement, comme pour limplmentation de la base de donnes, un objet AlertModel.
Chacune de ces classes implmente des fonctions tels que getImage() qui retournera
limage de la pice du puzzle, getText() qui retournera un texte ventuel afficher, etc.
Lobjet Board est charg dimprimer sur un canvas la chaine de pices, en appelant
ces fonctions.
Lenregistrement de la chaine de pices se fait cette fois en JSON, la structure
tant trs commune avec les modles Django. Une requte post contenant la structure au format JSON est envoye au serveur et traite par la fonction save (Voir
alert/views.py). Cette vue excute un travail trs comparable celui que fait le
code JavaScript. Le format JSON est transform en une srie de liste Python et de
structures du type dictionnaires, quil faut enregistrer en Modles (qui sont pour
4.8. COMPRESSION ET CONCATNATION DU TEXTE
45
Figure 4.16 Code JavaScript avant minification

rappel des objets Python tout fait normaux) et enregistrer dans la base de donnes
avant denregistrer chacun des ses "outputs".
Pour la gnration des alertes et le suivi de la chaine proprement dit, lorsquun
relev est enregistr, la fonction save() vrifie si un AnalogMeter est associ au compteur. Si cest le cas, sa fonction fire() est appele avec la valeur de la consommation
instantane en paramtre. Cet objet AnalogMeter appelera la fonction fire() de tous
les AlertModel pointant vers lui, en toute logique des ADC. Les fonctions fire() des
ADC vrifieront que la consommation antrieure est au del, gale ou en de du
seuil en fonction du type choisi. Sil y a un vnement, il appellera la fonction fire()
de tous ses enfants, et ainsi de suite pour toute la chaine jusquaux pices Alert, qui
produiront la notification dfinie par lutilisateur.
4.8
Compression et concatnation du texte
Bien que le JavaScript ne permette pas dinclusion nativement, il est ncessaire

de sparer le code en plusieurs fichiers qui seront inclus via des balises HTML pour
conserver une organisation propre. En effet, le code de dessin du plan par exemple
contient plus de 1800 lignes.
Le problme de la sparation des fichiers JavaScript et CSS, est qu chaque fichier, il
faut effectuer une requte HTTP supplmentaire. Mme si ces requtes peuvent tre
faites en parallle, elle ne peuvent tre plus courtes quun RTT (RoundTripTime,
temps quil faut pour quune requte soit envoye au serveur et que la rponse soit
reue). Ds lors, il faut en thorie, faire le choix de la performance (en crivant tout le
code dans le mme fichier), ou de la lisibilit (en sparant le code en plusieurs fichiers).
La solution, apporte par le plugin django-pipeline[17] est la concatnation des
fichiers en groupes. Par exemple, le groupe plan combine tous les fichiers relatifs au
dessin du plan en un seul fichier.
De plus, ces fichiers sont au passage minifis. La minification est un procd
46
Figure 4.17 Code JavaScript aprs minification

permettant la compression en taille dun fichier. Le minificateur (yuglify [59]) supprime tous les espaces et retours la ligne inutiles du fichier et les commentaires. En
JavaScript, il renomme galement toutes les variables locales avec des noms courts
tel que a, b, c... Ainsi, le code de la figure 4.16 est transform en code de la figure
4.17. Les fichiers CSS sont galement minifis.
Le code HTML gnr par les diffrentes vues Django est galement minifi, et
tous les fichiers servis sont compresss au format gzip pour diminuer au maximum la
taille des nombreux changes.
Chapitre 5
Compteurs virtuels
Pour certains compteurs il est possible dapproximer une consommation de faon
trs correcte. Pour cela jai mis en place sur le serveur quelques petits scripts appels
toutes les 5 minutes via lchanceur Cron dj prsent dans la section 2.1.1.
Tous les scripts impriment sur la sortie standard, une valeur de consommation
envoyer un compteur. Il suffit ensuite dutiliser le programme wget[56] pour
lancer la requte HTTPS au serveur. Un exemple dappel est la commande wget
spider https ://server.com/data/hash/Python path/temperature.py BEXX0011. Le
paramtre spider de wget permet de ne pas rellement tlcharger la page (envoie
une requte HEAD plutt que GET) puisque le rsultat ne nous intresse pas.
Lutilisation des symboles apostrophe franaise permet de remplacer la commande
entre les symboles par la sortie que celle-ci aura produite, et donc de remplacer la
fin de lURL par la sortie du script temperature.py.
Pour envoyer des donnes toutes les 5 minutes, il suffit dajouter la ligne suivante
au fichier de configuration de cron (en gnral /etc/crontab) :
*/5 * * * * root commande o commande est remplacer par la ligne cite ci-dessus.
5.1
Gnration de donnes alatoires
Les premiers scripts servaient gnrer des donnes alatoires (en fonction des
heures de pointe tout de mme), afin de tester linterface, tandis que les quipes
IdP terminaient les capteurs. Ils sont disponibles dans le dossier scripts du code source.
Le premier est ranval.py qui prend en paramtre une valeur, et multipliera cette
valeur par deux nombres variant tous deux entre 0.5 et 1.5. Le premier multiplicateur
est en fonction de la journe, cest une simple fonction qui permettra de gnrer 3
pics 8h, 12h, 16h et 20h comme sur le profil de consommation typique de la figure
5.1. Le multiplicateur final est visible sur la figure 5.2. Le deuxime multiplicateur
est simplement un nombre alatoire entre 0.5 et 1.5, ce qui permet de donner un air
plus raliste aux valeurs, bien que beaucoup plus oscillantes puisque lors de chaque
47
48
CHAPITRE 5. COMPTEURS VIRTUELS
Figure 5.1 Profil de consommation typique dune journe. Source :[51]
Figure 5.2 Premier multiplicateur. En fonction de lavancement de la journe

et en fonction de lheure (version utilise)). Axes verticaux : valeur gnre. Axes
horizontaux : heure de la journe.
5.2. TEMPRATURE
49
Figure 5.3 Profil final gnr avec une valeur de base de consommation de 15.
Axe vertical : valeur gnre. Axe horizontal : heure de la journe.
appel du script la nouvelle valeur naura aucun lien avec la prcdente, si ce nest la
base et lheure. La figure 5.3 montre le rsultat pour une valeur de base de 15.
Le script getval.py qui permet de rcuprer la valeur courante dun compteur
grce un appel GET via la librairie httplib, et rangetval.py combine les deux afin
de rcuprer la valeur actuelle dun compteur et lui ajouter la valeur gnre. Ce
script est utile pour simuler une consommation sur un compteur en mode "total",
puisque les consommations envoyes doivent tre ajoutes au dernier total.
5.2
Temprature
Jai galement fait un script qui va chercher la temprature extrieure sur

weather.com grce la librairie pywapi. En effet, il serait inutile de placer un
thermomtre intelligent lextrieure pour mesurer la temprature, puisque la temprature extrieure est dj disponible en ligne. Il est utilis de la mme faon que
les autres au sein de cron pour publier la temprature toutes les 5 minutes sur un
compteur "global" de temprature de la maison.
5.3
Consommation dun ordinateur
Lide ici repose sur la capacit de lordinateur estimer sa propre consommation.

Lorsquil est allum, il envoie une consommation instantane en fonction de ltat de
50
ses appareils, de son nombre de disque dur, de son cran, etc... Lorsquil dmarre, il
est ncessaire denvoyer la valeur moyenne de la consommation en veille. Comme
expliqu dans la section 4.2, la consommation totale est calcule en fonction de la
consommation instantane pour la priode prcdent lenvoi. Ainsi, si lordinateur a
t teint 3 heures, sil dmarre en envoyant 1.5 Watts, le systme considrera que
lordinateur a consomm 1.5 Watts pendant 3 heures.
Ma recherche en matire de documentation sur la consommation dun ordinateur
a t peu fructueuse. Je me suis bas sur quelques analyses gnrales dont larticle
[5], mais soit ce sont des analyses de profil sur lanne ou de la consommation totale
de lordinateur, soit ce sont des analyses trs fines dun composant prcis dont laccs
aux paramtres comme le temps de "spin-up" dun disque dur (dmarrage dun
disque dur) nest pas accessible de faon automatique.
Jai donc tudi chacun des composants dun ordinateur un par un pour essayer
dobtenir une consommation totale approxime de lordinateur. Le but de cette
recherche est surtout de montrer les possibilits dextensions que la facilit du protocole permet, et dexplorer quelques pistes pour se passer de certains capteurs.
Beaucoup dautres ides seraient ralisables, telle quactiver la webcam dun ordinateur pour vrifier si la lumire de la pice est allume toutes les 5 minutes et envoyer
alors la consommation dune ampoule. Le script final scripts/computer.py na donc
pas pour vocation dtre complet et nest test que sur quelques machines. Il ne
supporte que les systmes Unix.
Le premier lment prendre en compte est le type dordinateur. En pratique, il
faudrait au moins sparer les ultra portables, les portables, les ordinateurs de bureau
et les serveurs. Jai dcid de ne garder que deux catgories les plus courantes dans
une maison : les portables et les ordinateurs de bureau. Pour dtecter si lordinateur
est un mobile, le script teste lexistence du dossier /proc/acpi/button/lid/ qui indique
si lcran de lordinateur portable est ouvert ou ferm. Si ce dossier nexiste pas,
cest quil ne sagit probablement pas dun ordinateur portable. Le type dordinateur
nimplique pas de consommation mais sera utilis par le reste du script.
Ltape suivante est le calcul de la consommation des disques durs. Le script
liste les priphriques dans /dev/sd* et utilise hdparm pour voir si cest un SSD, un
HDD ou autre chose. En ralit, on utilisera le fait que hdparm retourne une erreur
si le disque nest ni un SSD ou un HDD, Il sagit alors probablement dune cl usb
ou dun lecteur CD. Les consommations sont les moyennes tires des produits de
WesternDigital[54] des consommations de ses disques durs 3.5 pouces(6W) pour les
ordinateurs de bureau et 2.5 pouces (2W) pour les portables. Concernant les SDD,
ce sont celles dOCZ[36] qui ont t calcules (0.8W) et une moyenne de 0.5W pour
les autres appareils pour indiquer en moyenne une lgre consommation de la cl usb
ou du lecteur cd, la plupart du temps en veille.
5.3. CONSOMMATION DUN ORDINATEUR
51
Pour la carte mre et la mmoire, aprs quelques recherches il semble correct

de considrer 8 Watts pour les cartes mres dordinateurs portables, 20 Watts pour
celles des ordinateurs de bureau dentre de gamme et 30 Watts pour les plus grosses
avec les derniers chipsets. Ne pouvant pas dtecter si la carte mre est "grosse",
je compte le nombre de slot de RAM quelle possde en parseant le retour de la
commande dmidecode. Je la considre petite si elle a 2 RAM ou moins, et elle
sera considre comme grosse si elle a plus de 2 RAM. Je compte galement 2
Watts par Go de mmoire pour les desktops et 1W par Go de mmoire pour les
mobiles. Lutilisation en lectricit dune mmoire RAM ne varie pas normment
en fonction de la charge puisquelle se rcrit perptuellement de toute faon. Il est
de plus difficile de mesurer le nombre doprations IO de mmoire sans accs au kernel.
Concernant lcran, jai observ une diffrence de 3 Watts entre un cran teint
(en veille profonde) ou allum sur les deux ordinateurs portables ma disposition
et denviron 8 Watts de consommation pour mes trois LCD. Ltat de lcran est
rcupr via la sortie de "wset -q dpms", indiquant si lcran est en veille ou non.
Cependant cette commande ne fonctionne que si laccs lcran est configur via la
variable denvironnement Unix DISPLAY, ce qui nest pas le cas avec Cron, moins
deffectuer un export DISPLAY avant de lancer le script via Cron.
Pour la carte graphique, la variation peut bouger beaucoup selon le modle. Je me
suis uniquement focalis sur les cartes NVIDIA nayant que des ordinateurs quips
de celles-ci ou de chipsets graphiques intgrs. Les autres cartes que les NVIDIA
sont considrs comme des chipsets graphiques intgrs (1.5W pour un mobile, 3W
pour un desktop). Le modle de la carte graphique est dtect grce lspci. Notons
que le script supporte plusieurs cartes graphiques (une configuration dite SLI). La
consommation des cartes est peu prcise sur le site des constructeurs, en revanche
on dispose souvent du TDP (Thermal Design Power) des chipsets qui indique la
puissance dissipe. Ce nest pas quivalent la puissance consomme, mais cela peut
tre utilis pour avoir un ordre de grandeur ou une proportion. En parcourant la
liste des cartes graphiques NVIDIA sur Wikipedia - Comparison of Nvidia graphics
processing units [57], on observe que de faon gnrale la puissance dissipe augmente
avec le numro du modle au sein de la srie, et que les maxima de chaque srie
augmentent avec au fur et mesure du renouvellement des sries. A lobservation du
rsultat, jai considr que la consommation maximale dune carte mobile tait de
5W 60W en fonction de la gamme, et de 20W 200W pour les desktops. Les cartes
plus anciennes (les modles disposant de 4 chiffres) sont considrs comme ayant
une consommation maximale 70% plus petite. Les modles mobiles finissent tous par
M aprs les chiffres du modle ceci permettant de les dtecter. La consommation
de la carte ( charge pleine) tant choisi dans lintervalle cit en proportion de la
gamme. Par exemple, un modle 8600M a pour numro de srie 8, de gamme 6 et est
mobile. La gamme 8 tant une ancienne, on cosidre que le plus petit modle (la 8000)
consomme 5W, et la 8900 consomme 60W. Comme cest un ancien modle (4 chiffres)
cette consommation est rabaisse de 30%, la consommation de la srie variant donc
52
entre 4W et 42W. Comme la gamme est 6, on utilisera comme consommation une

proportion de 6/10 entre 4 et 42W, soit 26W. Il conviendrait en pratique dutiliser
la mme mthode au moins pour les cartes AMD ATI.
Ceci nous donne une information sur la consommation maximale de la carte,
mais il est difficile de trouver la charge du GPU. A la place, jai utilis la constante
de 10%. Puisque le script tourne sur un systme Unix, il est rare que la carte soit
rellement utilise, hormis pour la lecture dune vido.
La dtection des ventilateurs se fait par le nombre doccurences de sysclassthermal cooling_device/cur_state 1. Il se peut que le driver de support des ventilateurs ne soit pas
compatible avec le systme. Si aucun ventilateur nest dtect, on considre quil y en
a au moins 1 (pour le processeur). Les desktops ont galement un ventilateur ajout
pour lalimentation. En effet celui-ci nest presque jamais monitor et donc indtect
par cette mthode. Chaque ventilateur est considr comme consommant 1.5 Watts.
La consommation finale est divise selon lefficience de lalimentation. En effet
la conversion du 220V en 12V et 5V a un cot. Sur les desktops, lefficacit est en
moyenne de 80%, cest dire que si le rsultat de notre calcul de consommation est de
80 Watts, lalimentation en consommera en ralit 100. De plus, lalimentation induit
une lgre perte constante (assume de 3 Watts). Sur les mobiles, lalimentation est
considre comme, en moyenne, plus efficace : 90% avec une perte constante de 0.5
Watts.
La partie la plus difficile est probablement le CPU. Jai tudi le profil de consommation de 4 ordinateurs ma disposition. De faon gnrale, jai envisag deux
cas de consommation : la consommation lorsque lordinateur ne travaille pas et la
consommation lorsque tous les corps du CPU sont 100%. Jai utilis un wattmtre
pour mesurer la consommation de certains ordinateurs en ma possession et le logiciel
cpuburn [10] pour faire tourner le processeur au besoin. Ltablissement dun profil
de consommation en fonction de lutilisation du CPU ma permis de voir que la
consommation tait proportionnelle la charge du CPU, sauf quand un mcanisme
de down-clocking est utilis (descente de frquence du CPU sil nest pas utilis)
auquel cas la consommation a plus lallure dune courbe exponentielle. Ceci est
confirm par dautres observateurs tels que [22]. En pratique, il est difficile de voir
avec un simple script si le processeur possde un tel mcanisme (il serait possible
danalyser dans le temps le processeur pour voir si la frquence diminue parfois).
Jassume donc que le mcanisme dconomie dnergie est actif sur les ordinateurs
portables mais pas sur les ordinateurs de bureau. Il reste trouver la consommation
maximale du processeur, le script parcourt /proc/cpuinfo la recherche du nom du
modle. La consommation dun processeur peut varier normment dun modle
lautre, et aucune caractristique ne peut en laisser deviner la consommation. Je me
suis uniquement focalis sur les processeurs Intel , nayant aussi que ceux-ci sous la
main (tout comme les GPU, il conviendrait en pratique dappliquer la mthode pour
tous les constructeurs). Le script recherche sur le site ARK dintel [26] le modle du
5.3. CONSOMMATION DUN ORDINATEUR
53
processeur. Il parse la page pour trouver le lien vers la page daspect technique et
charge cette deuxime page. Sur cette dernire est indiqu le TDP du processeur dj
discut concernant les GPU. Cest sur base de ce TDP que lon pourra considrer la
consommation du processeur. En ralit, je considre que la consommation maximale
du processeur est de 60% du TDP pour un mobile et 75% pour un desktop. Cette
valeur est quelque peu arbitraire et elle a t choisie en regardant "ce quil manque"
entre la consommation simule de mes 4 appareils et leurs consommations relles
ainsi qu en rcoltant diverses informations sur les forums et divers articles. La
consommation actuelle dun processeur est calcule ensuite comme la somme de 10%
de sa consommation maximale (mme sans aucune charge, il consomme) et des 90%
restants majors en fonction de sa charge.
Voici le rsultat des estimations et des mesures relles :
Type
Portable Desktop Portale Desktop Mobile
Processeur T9300
i5 3550 P6200
G1610 G1610
Idle rel
20
143
20
29
Idle simul
25
123
22
65
30
Full rel
33
193
39
35
Full simul
44
195
44
119
62
Le premier mauvais rsultat du Celeron G1610 sexplique par le fait quil est
dans une plateforme utilise comme serveur. Lalimentation est une alimentation
haut de gamme trs efficace tandis que la carte mre est dentre de gamme mme si
elle comprend un bon chipset assurant une consommation minime. Le processeur
Celeron consomme trs peu malgr un TDP du CPU annonc de 55 Watts. La tour
complte sans cran ne consomme que maximum 27 Watts pleine charge, du coup,
ma prsemption sur le TDP semble incorrecte dans ce cas. Cet ordinateur particulier
peut en fait tre considr comme un ordinateur portable, jai donc dcid aprs
ces rsultats de dclarer lordinateur comme mobile galement lors de la dtection
dun CPU Celeron. Les consommations sont plus correctes mais le TDP du CPU
continue dinfluencer la consommation en charge complte en laugmentant de faon
trop lve cause du chiffre du TDP de 55W donn par Intel, mme major par la
conversion TDP vers sa consommation maximale relle.
Quelques essais mont permis dassumer que la consommation par un vrai programme (avec des accs disques, des changes mmoires, etc) ne changeait pas les
rsultats par rapport lutilisation du logiciel cpuburn pour simuler la charge. Ceci
est explicable par le fait que si effectivement un logiciel qui cre beaucoup daccs
disque augmente la consommation au sein de celui-ci, il rduit sa consommation du
processeur qui est en tat dattente.
En conclusion, le script permet davoir une ide de la consommation estime,
raisonnablement exacte. Ce qui permet lutilisateur de donner une approximation
relativement correcte sur lanne. Un utilisateur plus scrupuleux peut paramtrer
le script en fonction de son ordinateur, en lutilisant comme une base sadaptant
54
grosso modo cet ordinateur. Ici, on pourrait par exemple dclarer que les Celeron
ne consomment au maximum que 20% de leurs TDP. Il ne serait de toute faon pas
possible de trouver automatiquement la consommation exacte de lordinateur, mme
si ce compteur virtuel tait lunique sujet de ce travail. Mme en envisageant un
parsing du site des constructeurs comme pour les CPU, nous ne pourrions jamais
avoir toutes les donnes automatiquement. La consommation dune carte mre par
exemple est trs hasardeuse et dpend de chacun de ses composants, il nest mme
pas sr que les fabricants la connaissent eux-mmes. Le boitier est galement un
problme insoluble. Certains boitiers dordinateur salimentent sur lalimentation
gnrale pour des clairages, des ventilateurs ou des petits crans LCD de contrle
mais les modles du boitier sont souvent inconnus de lordinateur lui-mme et rien
nest monitor par lordinateur lui mme mais bien par un circuit indpendant. Seul
un wattmtre permettrait de mesurer cette consommation de faon exacte.
Pour rappel, le but de ce script tait dune part de me permettre de tester mon
interface avec des donnes qui ne sont pas alatoires en attendant les capteurs des
quipes IdP, et, dautre part, dexplorer un peu plus en profondeur les possibilits de
compteurs virtuels. Je pense avoir atteint ces objectifs. Dautres ides implmenter
seraient la dtection de priphriques sur le rseau : modem, switch, imprimantes,
... et publier galement leurs consommations sur linterface. Il existe galement
beaucoup de possibilits dans le domaine de la vision par ordinateur : voir si une
lampe est allume (la consommation dune lampe tant en gnrale constante), ou,
plus largement la dtection de ltat de certains appareils mnagers. Par exemple,
beaucoup de fours micro-ondes possdent une lumire qui pourrait tre dtecte
sur une image, ou encore les leds dtat des tlvisions et dcodeurs.
Chapitre 6
Rsultats
Cette section prsentera linterface termine et la ralisation pratique des diffrents lments discuts. Les questions de performances seront discutes dans le
chapitre suivant.
Des trois objectifs du groupe IdP (Flexibilit, Accessibilit/Non-intrusif et peu
coteux), seules la flexibilit et laccessibilit concernent vraiment linterface. Le
seul lment financier est celui de ne pas requrir des performances exagres (ce
but est relativement atteint et discut dans la section valuation des performances
6.8. Concernant laccessibilit, un des objectifs majeurs de linterface est de pouvoir
fonctionner sur les smartphones, tablettes et PC. Les mcanismes mis en place
pour atteindre cet objectif sont nombreux et discuts tout au long de ce travail. La
flexibilit, elle, concerne la possibilit de pouvoir sadapter toutes les maisons, de
nouvelles nergies, ou encore de nouveaux appareils lectro-mnags. Au niveau du
code, il faut galement une totale modularit, le moins possible de "hard codage",
afin de permettre ces changements dhorizons.
Lutilisateur est catgoris comme "standard" ou "avanc", il peut tous moments changer son mode dans les paramtres.
La page daccueil affiche un menu lutilisateur lui offrant 4 possibilits, correspondant aux 4 cas dutilisation du logiciel :
Consommation - Affichage des de consommation actuelle de lutilisateur
Modlisation du btiment - Cration et configuration de la maison de lutilisateur
Alertes - Configuration du systme dalertes
Statistiques - Affichage du profil de consommation sur les dernire jours,
semaines ou mois.
La disposition des lments a t soigneusement tudie afin que lutilisateur
dbutant ne se perde pas dans les diverses possibilits du systme. Chaque icne du
menu a une couleur correspondant la page lie, et cette page est dans le mme ton,
55
56
CHAPITRE 6. RSULTATS
Figure 6.1 Accueil

assurant un effet mmoire lutilisateur.
Pour cheminer en cohrence avec lobjectif daccessibilit par lutilisateur, presque
tous les boutons ont t remplacs par des images. Cela permet galement de limiter
ladaptation ncessaire pour les smartphones : les boutons carrs sont faciles cibler
du doigt nimporte quel niveau de zoom, mme sur des smartphones pourvus de
petits crans.
Les choix oprs au niveau de la forme de linterface peuvent sembler anodins mais
la programmation a t prcde de 3 mois de rflexion, en compagnie principalement
des 3 tudiants en 2me bachelier rattachs notre groupe IdP. Ils mont aider
recueillir toutes les informations ncessaires pour le modle nergtique (voir 7.5),
ce qui tait rellement attendu de linterface, ou encore de dcider du protocole de
communication (discut dans la section 4.5). Ils mont galement aid en apportant
un avis extrieur, non-informaticien et non-initi sur mes ides (jusqualors sur
papier), pour que tant lutilisateur lambda que lutilisateur avance trouve ce quil
cherchait dans USE Monitoring. Au final, jai fabriqu plus de 55 symboles originaux
pour ne pas souffrir de copyright. Ma formation ntant absolument pas celle dun
graphiste, jai utilis un systme de silhouettes, contenant peu de couleurs et des
formes simples afin de les raliser en utilisant des courbes de bzier, tenant plus de
lart de la manipulation de la souris que de lart du pinceau (Fig 6.2).
6.1
Modlisation - Builder
La premire tche de lutilisateur lorsquil accde linterface est de dfinir

lenveloppe nergtique de la maison. Biensr la plupart des utilisateurs, mme
expriments ne connaissent pas le volume exact de leur habitation et moins encore
le coefficient de perte nergtique. La solution retenue est de guider lutilisateur
6.1. MODLISATION - BUILDER
57
Figure 6.2 Icnes, images et logos crs pour linterface

travers 7 tapes lgrement diffrentes selon son niveau dexpertise.
tape 1
La premire tape (Fig. 6.3) dfinit la maison et ses caractristiques gnrales.
Lutilisateur est invit entrer :
Un nom pour la maison : utilis uniquement pour choisir la maison active dans
la liste visible en haut dans le menu principal.
Lanne de construction : utile pour le modle, mais galement pour dfinir
automatiquement le niveau disolation des murs.
Type de maison : lutilisateur a le choix entre un appartement et une maison 2,
3 ou 4 faades. Concernant celles-ci, nous parlons ici de maisons mitoyennes.
La maison deux faades ntant pas un mur seul mais une maison coince entre
deux autres.
Situation : Urbaine, pri-urbaine ou rurale. Cette information est uniquement
destine au modle nergtique.
Longueur et largeur de la maison : ces donnes ne seront pas directement
58
utilises mais permettront de dfinir la taille du plan. La superficie exacte de

la maison est calcule partir des murs extrieurs dessins sur le plan.
Il serait galement possible de changer tous les menus droulant par une liste
dimages pour les smartphones. Lutilisateur naurait qu toucher une image pour
faire son choix. Les zones de chiffres auraient galement pu tre remplaces par des
"sliders", une barre dplacer pour choisir un nombre entre 0 et 100 par exemple.
En pratique, les derniers navigateurs mobiles affichent un pop-up pour faire le choix
aisment quand lutilisateur touche la zone du menu droulant. Concernant les zones
de chiffres, laffichage du clavier est toujours une opration pnible et peu fluide mme
sur les derniers modles, me poussant imaginer cette solution. Cette fonctionnalit
peut tre affiche au chaptre des "amliorations possibles".
Lutilisateur a galement la possibilit de supprimer la maison sil dite une
maison existante plutt quune nouvelle.
Figure 6.3 Informations principales sur la maison
Ltape 1 est la seule obligatoire pour accder a la suivante. Une fois la maison
enregistre, lutilisateur peut naviguer entre les tapes et en sauter lune ou lautre
sa guise. Toutes les pages prsentes ici souvrent naturellement en mode "dition"
ou en mode "cration", en fonction de la slection dune maison actuelle ou non.
59
tape 2
La seconde tape concerne les habitants de la maison et leur appartenance socioprofessionnelle (Fig. 6.4). Celle-ci permettra au modle dvaluer un taux de prsence
et donc dutilisation des appareils de la maison.
Lutilisateur dfinit un nom, un ge et un emploi. Il clique sur le bouton dajout
pour inscrire lhabitant la liste et peut enlever un habitant tous moments.
Figure 6.4 Habitants de la maison
tape 3
Lutilisateur doit ensuite dfinir les tages de sa maison : sil dispose dun grenier,
le nombre dtages, dune cave, etc...
Il lui suffit de cliquer sur un type dtage droite (voir fig. 6.5) et celui-ci viendra
sajouter sur le profil de la maison gauche. Il peut galement dfinir la hauteur
dun tage. Lutilisateur na pas la possibilit dintgrer des tages demi niveau. Si
cela constitue une grande simplification au niveau du code, cela ne change rien au
niveau du modle nergtique. Celui-ci nutilise que le volume globale des pices et
nest donc pas influenc par un tage un niveau dcal par rapport aux autres qui
serrait ramen au niveau infrieur ou suprieur.
tape 4
Pour les quatre dernires tapes, lutilisateur passe en mode plan (Fig. ??) afin
de dfinir les murs, les fentres, les appareils et les ventuels compteurs nergtiques
60
Figure 6.5 Dfinition du profil de la maison

installs dans la maison. Le plan est lchelle (le quadrillage est un mtre). Sur
toutes ces pages, il dispose dun menu en haut gauche pour naviguer entre les
tages. Toutes les modifications sont enregistres chaque changement dtage, et
chaque changement de page. Ces 4 tapes sont les seules de linterface qui sont moins
adaptes aux petits smartphones. En effet pour atteindre une prcision suffisante
lutilisateur devra constamment zoomer et d-zoomer. Cependant, peu dutilisateurs
configureront vraiment leur maison sur leur smartphone. Cette tape est plutt
destine tre ralise sur un PC et prcde lutilisation du smartphone pour la
consultation de la consommation.
Lutilisateur est donc amen configurer les murs de sa maison. En mode basique,
il clique simplement sur deux points du plan pour tracer un mur entre les points. Pour
simplifier les diffrentes tapes et le systme, il ne peut faire que des murs verticaux
et horizontaux et ce, sur les intersections de la grille du plan. Comme seul le volume
gnral sera utilis par le modle, cela nest pas un problme. Lorsque lutilisateur
passe ltage suprieur, une analyse en composante connexe est effectue par le
programme (sur base de la grille) afin de dtecter quels sont les murs extrieurs et
les dupliquer ltage suprieur. Ltage infrieur est affich en transparence rouge
afin que lutilisateur puisse se reprer tel que reprsent sur la figure 4.12.
En mode avanc, le menu visible sur la figure 6.6 est remplac par celui visible
sur la figure 6.7, pour quil puisse dfinir lui-mme la taille du mur et de lpaisseur
de lisolation. Le type disolant ne change que peu le facteur disolation et nest donc
pas demand lutilisateur. En mode basique, le partitionnement de lespace est
calcul aprs chaque mur afin de dtecter sil est intrieur ou extrieur. La taille du
mur et de lisolant sont choisis en fonction de lge de la maison.
61
Figure 6.6 Dfinition des murs
Figure 6.7 Menu de dfinition des murs en mode avanc

tape 5
Lutilisateur doit ensuite disposer les fentres, leurs tailles et leurs types : simple
vitrage, double vitrage, double-vitrage haute efficacit ou triple vitrage (Fig. 6.8). La
prcision de la position des fentres est ici au demi-mtre prs (bien que leur taille
soit dfinie en virgules flottantes par lutilisateur). Le fait quil ny ait pas de support
pour les fentres de toit simplifie galement linterface utilisateur sans impacter la
justesse de la perte nergtique de lenveloppe.
tape 6
Pour la partie placement des appareils lectroniques, lutilisateur dispose dun
menu par catgorie pour placer ses appareils (voir Fig. 6.9)
Les catgories ne sont pas changeables par lutilisateur (mais les diffrentes catgories ne sont mises qu un seul endroit ct serveur, donc facilement modifiables
et linterface sadaptera automatiquement), cependant lutilisateur a la possibilit
dajouter dautres appareils, de changer les nergies quil utilise, leurs noms, etc...
Ceci sera discut dans la section 6.5.
62
Figure 6.8 Exemple de murs de ltages suprieurs automatiquement crs. On

aperoit galement ltage infrieur en transparence.
Figure 6.9 Placement des appareils mnagers

Pour placer un appareil, il clique sur celui de son choix dans le menu, et clique
un endroit du plan.
Le type dnergie est indiqu pour chaque appareil. Lutilisateur doit choisir un
appareil et le placer sur le plan, tage par tage. Beaucoup dinformations drives
seront tires de ce placement comme la surface chauffe et les nergies utilises.
tape 7
Ltape suivante permet lutilisateur de cibler les compteurs dont il dispose et
les relier aux appareils dont ils mesurent la consommation. Les compteurs peuvent
galement tre identifis en tant que compteur gnral de la maison.
Pour cette dernire tape, les grilles du plan disparaissent, les pices sont colores
avec des fonds lgrement diffrents et le systme calcule la taille relle de la maison
6.2. CONSOMMATION - CONSUMPTION
63
Figure 6.10 Placement des compteurs. Comme lutilisateur dplace un compteur

gaz, seuls les appareils au gaz entrent en surbrillance et le compteur gnral de gaz.
pour lagrandir au maximum sur lcran. Nous avons voulu ainsi couper avec le reste
des tapes prcdentes, lutilisateur ne dfinissant plus le plan mais lutilisant. Ici,
lutilisateur est invit faire un drag-n-drop qui est plus intuitif. Lorsquil commence
le dplacement dun compteur, les appareils et compteurs globaux de lnergie du
compteur se mettent en vert pour indiquer lutilisateur quil peut dposer le
compteur cet endroit tel que visible sur la figure 6.10. La mthode des appareils
de ltape prcdente fonctionne toujours, savoir un clic sur un compteur et puis
sur lappareil quil mesure, notamment pour une question de compatibilit avec le
navigateur dorigine Android depuis sa version 4 qui casse le plugin javascript de
drag-n-drop (ceci sera discut plus longuement dans la section compatibilit 6.6).
Quand lutilisateur place un compteur, une boite de dialogue (fig. 6.11) lui permet
ensuite de choisir le mode du compteur tel que dfini dans la section 4.2, structure
de la base de donne.
Une fois le compteur plac sur le plan, la page affiche le "hash" utile au protocole
dchange prsent dans la section 4.5 protocole de communication. Cest un code
de 14 chiffres/caractres que lutilisateur emploiera pour paramtrer son appareil de
mesure. Le compteur physique envoie les donnes mesures associes au hash ; ainsi,
le systme peut savoir quel compteur appartiennent les donnes qui lui arrivent.
6.2
Consommation - Consumption
La page consommation est destine donner un aperu lutilisateur de la

consommation de sa maison. A ce titre, il peut voir la consommation instantane
64
Figure 6.11 Choix du type de compteur
Figure 6.12 Affichage de la consommation
6.3. ALERTES - ALERTS
65
Figure 6.13 Affichage de la consommation en mode double

de tous ses appareils monitors et un graphique de lvolution de la consommation
instantane des dernires 24 heures pour chacun deux. Notons que la consommation
sera instantane quelque soit le type du compteur. Sil est en mode diffrentiel ou
total, elle sera calcule. Lutilisateur peut galement allumer ou teindre les appareils
qui disposent dun allumage distance. Chaque compteur dispose galement dun
bouton qui renvoie vers un graphique de la consommation instantane mais non
limite dans le temps (avec une priode daffichage libre) ainsi que la consommation
totale journalire.
Pour atteindre cet objectif qui vise ce que lutilisateur ait un aperu de sa
consommation "au premier coup doeil", cette page a t lobjet dune attention
toute particulire au redimensionnement, au recoupage des zones du quadrillage vide
et au placement des lments que ce soit sur des crans dordinateur ou smartphone.
Si la taille de lcran le permet, laffichage passera en mode dual (Fig. 6.13).
6.3
Alertes - Alerts
Lutilisateur a la possibilit de spcifier des alertes en fonction de la consommation

(instantane) dun appareil. Il peut recevoir une alerte par mail ou une notification
sur la page daccueil. Nous dsirions une interface simple mais puissante, cette
recherche nous a orients vers un systme de puzzle (voir fig. 6.14) o lutilisateur
voit directement quelles pices il peut emboiter. Sil commence le glisser-dplacer,
lemplacement possible pour une pice se met en surbrillance (Voir fig. 4.4). Sur les
compteurs sortant des valeurs numriques (un bout rond), il devra forcment placer
une pice "Seuil" qui activera une sortie digitale (un bout en triangle) selon une
valeur choisie. Ensuite viendra la pice avec une entre digitale qui permet dactiver
une alerte. Il y a quelques pices logiques digitales-digitales : NOT qui inversent le
rsultat dune sortie, et deux filtres de temps. Un qui laisse passer une activation
uniquement sil est plus tt quune certaine heure dfinie et lautre uniquement sil
est plus tard. Lutilisateur en plaant ces deux pices lune aprs lautre peut donc
66
Figure 6.14 Page de dfinition des alertes

dfinir un interval.
6.4
Statistiques - Statistics
La page de statistique 6.15 permet de visualiser la consommation de chaque jour

en fonction du temps, selon une priode choisie par lutilisateur.
La page dispose galement de deux graphiques montrant la consommation totale
des 12 mois prcdents, ainsi quun diagramme circulaire pour lanne coule. Ces
deux graphiques peuvent afficher la consommation nergtique globale de la maison
sous forme de plusieurs grandeurs :
La consommation totale dans lunit de lnergie
Le montant pay pour cette consommation
Une comparaison en kWh de la consommation nergtique pure, en utilisant
le pouvoir calorifique infrieur (PCI). De faon intuitive la consommation de
chaque compteur est divise par la capacit de lnergie mesure produire
de la chaleur en fonction de son unit. Cela permet une comparaison entre les
nergies utilises dans la maison.
6.4.1
Recherche en matire nergtique
Cest dans cette catgorie que le travail au sein dune quipe pluridisciplinaire
prend son sens, puisque lexpertise de mes collgues nergticiens ma permis de
gagner pas mal de temps.
Concernant le PCI, le coefficient varie selon la puret et le type exact de lnergie
(lorsque applicable). Lutilisateur plus scrupuleux peut donc changer son PCI, quand
lutilisateur basique gardera le PCI par dfaut. En regardant le tableau 6.16, on voit
que le gaz le plus utilis est le gaz naturel et cest donc le PCI de ce dernier qui est
6.4. STATISTIQUES - STATISTICS
67
Figure 6.15 Historique de la consommation

dfini par dfaut (le choix de simplification de ne proposer dutiliser quun gaz ayant
t fait la base). Lutilisateur peut modifier le PCI des nergies ou peut rajouter
des nergies et donc des PCI diffrents pour chacune delles. En pratique, plusieurs
sources se contredisent ou visent simplement des produits lgrement diffrents mais
dont les alliages ne sont pas spcifis. Jai pris les sources se rapprochant des nergies
les plus utilises et jai fait des moyennes pour les autres cas. Les principales sources
sont Acqualys [2] et Axeiya [3].
Le problme est plus complexe pour les prix des nergies. En effet, le prix varie
beaucoup entre chaque fournisseur, il existe diffrentes offres, et pour une mme
offre dun mme fournisseur, ces prix sont souvent progressifs en fonction de la
consommation annuelle.
Figure 6.16 Consommation relle du logement en 2006. Source :ICEDD [23]
68
Ma premire ide tait dimplmenter un systme dinterpolation. Par dfaut

(et toujours modifiable par lutilisateur), en allant chercher des donnes sur le site
de la Socit Wallone Des Eaux [50] pour leau, on peut avoir le prix pay pour
chaque interval de consommation annuel comme sur la figure 6.17. On peut aussi
trouver le prix exact pay par lutilisateur en prenant sa consommation des 365
derniers jours ou en multipliant les donnes pour obtenir un quivalent annuel. A
cela il faut ajouter le prix de la redevance annuelle. Comme linterface affiche le prix
pay par jour ou par mois, il faudrait donc la diviser de faon quivalente sur les mois.
Une recherche plus pousse permettrait sans doute de trouver les catgories de
consommation automatiquement. La consommation deau est par exemple presque
proportionnelle au nombre dhabitants du mnage. Cest une information qui est
dfinie par lutilisateur en dbut de modlisation de sa maison.
Mais aucun de ces procds nest parfait car le prix varie toujours en fonction du
fournisseur ou de la rgion. En pratique je manquais de temps et je nai pas dvelopp
un systme aussi compliqu, laissant simplement une valeur unique de cot par unit.
Que mettre alors comme prix par litre deau par exemple ? Un rapide coup doeil
aux statistiques de la rgion wallonne montre quune large majorit des utilisateurs
se trouvent dans la catgorie 30 5000, sachant que la moyenne de consommation
slve 110m3 par raccordement[23]. Au final cest donc cette catgorie prix qui a
t utilise, lgrement augmente pour tenir compte de la redevance.
De faon gnrale, les autres nergies sont soumises aux mmes problmes. Il
appartient donc lutilisateur de changer le cot de ses nergies en fonction de sa
dernire facture de rgularisation annuelle par exemple. Au final, le prix unique
corrig par lutilisateur donne mme un meilleur rsultat que le systme de catgorie.
En utilisant mon avant-dernire facture de rgularisation dlectricit pour avoir
un cot au kWh et calculer le prix de la suivante, jobtiens un meilleur rsultat
quen utilisant un systme de catgorie standard utilisant une approximation des
catgories de deux fournisseurs (catgories qui sont dailleurs diffrentes), chacune
avec une moyenne des prix de 2 fournisseurs. Ceci est notamment d au fait que
llectricit est souvent sur un schma bi-horaire, et dans mon cas, un tri-horaire.
Limplmentation et la configuration dun tel systme (lui faire entrer toutes les
plages de prix de son fournisseur), ne vaudrait probablement pas lamlioration apporte et emputerait le travail fourni li la simplification de lencodage de la maison.
6.5
Paramtres - Settings
La page des paramtres permet de dfinir plusieurs prfrences de lutilisateur

et de modifier certaines parties de la base de donnes. pour rappel, lutilisateur a
2 options par rapport son profil : sil est avanc ou basique et sil dsire activer
le dfilement automatique. En effet, sur les pages qui affichent un plan, par dfaut
6.5. PARAMTRES - SETTINGS
69
Figure 6.17 Prix de leau au kWh en fonction de la consommation annuelle. Source

des donnes :Socit Wallone Des Eaux [50]
Figure 6.18 Page des paramtres
si lcran est petit et que le plan nest pas visible en entier, le navigateur va dfiler
automatiquement jusqu ne plus voir le menu et le ruban de titre.
Lutilisateur peut ensuite configurer les utilisateurs (Voir fig.6.19). Les utilisateurs
ont 3 niveau daccs :
Vue uniquement : Il a accs la page de consommation et de statistiques
uniquement
Vue et alertes : Il peut en plus voir et changer les alertes
Tous les accs : Il peut aussi accder la modlisation
De la mme faon que les utilisateurs, il peut modifier la liste dnergies et la liste
dappareils lectro-mnagers. Cette fonctionnalit sera plus facilement comprhensible
aprs la rvision de la structure interne qui est explique par lexemple dans la section
6.7.1.
70
Figure 6.19 dition des utilisateurs
Figure 6.20 Compatibilit de llement canvas avec les navigateur. Source :

caniuse.com [7]
6.6
Compatibilit et smartphones
La compatibilit avec les navigateurs de llment canvas est visible sur la figure
6.20. La compatibilit est plutt bonne, sauf pour Internet Explorer. La question est
de voir si cest rellement un problme, en fonction de la part de march des versions
incompatibles : celles avant la version 9. La figure 6.21 nous montre la part de march
des diffrents navigateurs. Malheureusement la version 8 est encore beaucoup utilise
(23%) alors que la 7 a presque disparu ( peine 1,2%). La part de march dinternet
explorer 6 est toujours de 6%, cependant ce taux lev vient en grande partie de la
Chine[24] et des entreprises qui ne mettent pas jour leurs ordinateurs. En belgique,
tout comme aux USA, la part de march est de 0,2%[24]. En rsum, il ne semble
pas utile dassurer la compatibilit pour les version 6 et 7.
Concernant llment canvas, la librairie ExCanvas[20] permet dassurer la compatibilit de llement canvas avec les navigateurs 6 8.
6.6. COMPATIBILIT ET SMARTPHONES
71
Figure 6.21 Part de march des navigateurs. Source : Net Market Share [34]
Figure 6.22 Comparaison de laffichage entre Internet Explorer 8 et 10

Enfin, un plugin de compatiblit dnomm TouchPunch [27] amne la compatibilit de jQuery ui et son sytme de dragn drop sur les smartphones.
La compatibilit est donc assure sur la plupart des systmes rcents, avec un
affichage presque unique. En effet, le CSS3 ne passe pas toujours, principalement sur
Internet Explorer mais des solutions de contournement sont mises en places. Il faut
comparer les dsavantages obliger lutilisateur upgrader son navigateur celui
dinstaller un programme inconnu et/ou dpendant dune plateforme. Un utilisateur
installera plus facilement une mise jour de son navigateur.
En pratique, sauf pour quelques lments de design, toutes les couches de compatibilit permettent le fonctionnement avec internet explorer 6 et 7. Sil tait rellement
important dassurer leur compatibilit, il suffirait dajouter des feuilles de style CSS
spcifiques ces versions et dajouter quelques vrifications au sein du code JavaScript.
Une attention toute particulire a t donne au systme de redimensionnement.
A vrai dire, presque toutes les pages sadaptent lcran et sa taille, ne modifiant pas
uniquement les tailles et les dimensions, mais galement la position des objets. La
page consommation par exemple dispose mme dun affichage en deux passes. Une
premire passe affiche les objets mais de faon invisible (ou plutt sans le contenu des
"boites" HTML div). Jutilise le rsultat pour disposer mieux les lments en fonction
de lcran et refait une deuxime passe pour rellement les afficher. Ceci implique
une certaine utilisation du processeur mais procure un rsultat trs satisfaisant au
niveau de lagencement (la performance sera discute dans la section 6.8). La taille
72
des nombreuses donnes du plan tlcharger est compense par la grande utilisation
de lAJAX. Comme expliqu dans la section 4.2.1, dans la plupart des dessins de
plan, Django ncrit directement dans le code HTML de la page que les tages. Cest
ensuite une requte AJAX qui va rcuprer la liste des murs, en parallle avec la liste
des appareils. Une fois les murs chargs, les fentres le sont galement. De mme,
les donnes des graphiques ne sont jamais crites dans le code HTML de la page,
permettant lutilisateur dobtenir un chargement progressif mais sans attente.
Concernant les navigateurs mobiles, je nai pas test liPhone et liPad, ne disposant pas de lappareil et lmulateur ntant pas accessible sur PC. Cependant,
leurs navigateurs utilisent le moteur Webkit, tout comme Google Chrome et la
compatibilit devrait tre atteignable sans trop de soucis si des problmes se manifestaient. Concernant les navigateurs mobiles sous Android, jai du faire face plusieurs
problmes au sein des navigateurs et du systme dexploitation lui-mm :
Comme discut prcdemment, jai souvent utilis les lments HTML canvas. Jai rencontr un problme tonnant sous Google Chrome Mobile avec
un mobile Samsung Galaxy S2. Tous les petits lments canvas saffichaient
correctement, mais pas les grands. En ralit, les lments canvas dune taille
infrieure 256*256 sont dessins par le CPU, tandis que ceux dune taille
suprieure sont dessins par le GPU. En dsactivant totalement le rendu GPU,
la page saffiche correctement. Le problme est report et fait lobjet dun bug
report en pleine activit [9]. Le problme en cause est clairement le rendu GPU
et non le code. Le rendu est correct sans dsactivation du GPU sur lmulateur
Android et sur un HTC Desire X. Probablement parce que ceux-ci nont pas
dacclration matrielle du navigateur.
Le navigateur Android dorigine souffre lui dun autre bug [8], de sorte quun
canvas ne peut pas tre nettoy avant dtre redessin, laissant de nombreux
artfacts sur la page. Pour contrer ce bug apparu avec la version 4 dAndroid
et qui nest toujours pas fix ce jour, jai d peindre une zone blanche sur
lentiret du canvas avant chaque rafraichissement du plan. Ce qui a pour effet
dabmer un peu le design.
La version mobile de Firefox, elle, ne prsente aucun dfaut daffichage. Bref, il
semble que Google ait encore du travail sur son systme et quil y ait eu un peu trop
de prciptation dans la publication de ses mises jours.
6.7
Modularit
Les sections prcdentes ont port leur attention sur la modularit de certains
lments tel que le plan qui pourrait avoir aisment un autre module de rendu. La
flexibilit tait un des principaux aspects du cahier des charges. Une maison peut
6.7. MODULARIT
73
Figure 6.23 Ajout dune nouvelle nergie : le bois
Figure 6.24 Ajout dun nouvel appareil : le pole bois

tre trs diffrente dune autre, certains utilisateurs peuvent avoir diffrents appareils
mnagers (cela a galement dj t trait dans la section 6.5) ou peuvent utiliser
diffrentes nergies. Cette modularit techniquement simple avec un schma de base
de donnes et une programmation respectant le paradigme MVC, requiert pas mal
dattention plusieurs niveaux de linterface. Cette section met en valeur certains
aspects et problmes auxquels il a fallu prter une attention spciale.
6.7.1
Ajout dune nergie et dun nouvel appareil de consommation
Lutilisateur peut sil le dsire, ajouter de nergies. Comme nous lavons vu le

type dnergie (avec ses units, sa couleur, sa conversion PCI ou encore le prix par
unit) est un simple modle Django. La section paramtre permet dajouter une
nergie (voir fig. 6.23). Nous allons suivre les dtails ncessaire cette flexibilit en
prenant lexemple du bois. Le pole bois ntait pas prvu dans le projet initial,
notamment parce quil est trs difficile de compter lnergie consomme (une solution
sera dveloppe la fin de la section). Une petite recherche nous apprend que le
bois relativement sec un pouvoir calorifique infrieur de 4 kWh par kg. Il se vend
environ 65A
Cle stre, et un stre de chne fait environ 700kgs, soit 9,28 cents par kg.
Lhabitation que joccupe est chauffe par un pole bois. Ceci ma permis de
crer un nouvel appareil (Fig 6.24) que jai ensuite ajout dans ma maison. Linterface
de ltape 7 sadapte automatiquement pour afficher le nouvel appareil. Comme le
74
Figure 6.25 Interface de configuration des appareils, avec le nouvel objet pole
bois"
Figure 6.26 Interface de configuration des compteurs avec la nouvelle nergie : le

bois
bois est une nergie ajoute par lutilisateur, il ny a pas dimage. Lorsque linterface
dtecte quil ny a pas dimage pour le bois, il crit la premire lettre de lnergie
dans sa couleur. Un symbole de compteur par dfaut est galement prvu pour cette
situation. Dans ltape 7 de configuration des compteurs (Voir fig. 6.26) jai ajout
un compteur de bois sur le pole en mode "diffrentiel". Cela signifie que lorsque
jenverrai une donne, elle sajoutera la consommation totale.
Concernant le problme de quantit de donnes pour le bois jai cr un raccourci
"petite buche", "moyenne buche" et "grosse buche", envoyant chacun une requte
dajout de respectivement 0.8, 1.2 et 1.6 sur le compteur que jai cr. Lunit tant
dfinie comme le kg, cela correspond aux valeurs moyennes des petites moyennes et
grosses buches. Il suffit que je clique sur le favoris de mon navigateur correspondant
la taille de la buche, lorsque je fais mon feu.
Le rsultat des statistiques aprs une soire de chauffage au bois est visible sur la
6.8. PERFORMANCES
75
Figure 6.27 Statistiques du compteur bois

figure 6.27. Nous observons que le graphique des consommations instantanes affiche
des pics trs hauts avec des valeurs improbables. Cest normal, puisque jai ajout 3
buches daffiles dans le pole. Linterface considre donc que jai consomm plusieurs
kgs de bois par seconde, donc plusieurs milliers par heure. En ralit, lerreur vient du
fait que je ne mesure pas la consommation de bois, mais bien son approvisionnement.
Ce qui devrait tre envoy dans le mode diffrentiel est la quantit de bois consomme
toutes les 5 minutes par exemple. La consommation journalire elle, est correcte
puisquelle est laddition des quantits consommes sur la journe.
6.8
6.8.1
Performances
Base de donne
Jai utilis le plugin django django-toolbar [14], permettant de voir les requtes
excutes et le temps processeur quelles ont ncessit. Cet outil magnifique combin
au manuel doptimisation des requtes Django, permet de tirer parti du systme
de cache des requtes pour minimiser celles-ci et ma permis de diviser par 3 mon
nombre de requtes. Django utilisant un systme pour construire automatiquement les
requtes, il est plus que ncessaire den connatre son fonctionnement. Par exemple,
rcuprer la liste des maisons se fait avec liste = House.objects.all(). Si on veut
vrifier quil ny a aucune maison avant de parcourir la liste des maisons, alors
il vaut mieux utiliser len(liste) que liste.count(), car dans le premier cas Django
excutera la requte complte et la mettra en cache, tandis que dans le deuxime cas,
il excutera une requte du type SELECT COUNT(*). Et lorsque le parcours de la
liste des maisons commencera, il devra alors refaire une requte du type SELECT
*. Cela semble anondin, mais apporte un gain de 0,30ms sur le chargement de la
76
page daccueil par exemple. Dans une boucle ou rpt, ce genre de dtail peut
faire toute la diffrence. Les divers temps de requtes sont pris sur mon serveur de
dveloppement local (ordinateur portable), le serveur ddi est gnralement plus
rapide.
Accueil
La page daccueil ne fait videmment presque pas de requtes si ce nest laffichage
des 10 dernires entres de la table log. Cette requte sexcute en 0.70ms. Les autres
requtes sont au nombre de 3 et sont faites sur toutes les pages : une pour laffichage
de la liste des maisons dans le menu droulant, une pour lidentification de lutilisateur
et enfin une pour la rcupration de la session dans la base de donnes. Le temps
cumul dexcution des 4 requtes est denviron 2,3ms.
Consommation
La aussi lanalyse de mon nombre de requtes ma permis de passer de 88 requtes
sur la page des consommations excutes en 120ms 19 faites en 8.2ms. Lalgorithme
qui prend un nombre important de requtes est ici celui de dtection de la taille relle
de la maison. En effet, il analyse la position de toutes les extrmits des murs pour
trouver les points extrmes de chaque tage, et finalement lespace maximal pris par
la maison afin que le plan puisse commencer le rendu. Ceci, en coupant le plan
ras bord avant davoir charg les donnes des murs ( pour rappel, les donnes sont
charges en AJAX). Lalgorithme de srialisation est en ralit le problme : pour
srialiser la liste des compteurs avec certaines donnes de cls trangres il prend 11
requtes, alors quil pourrait videmment le faire en une. Ceci est en fait d ce que
Django appelle les liens ManyToMany, soit les relations o plusieurs objets dun
mme type peuvent tre lis plusieurs autres objets dun second type, ce qui en
pratique ncessite de crer une 3me table liant un objet de la classe 1 la classe 2.
Django ne permet pas de faire une requte qui ira rechercher les donnes de la 1re
et de la deuxime classe en mme temps. Ceci dit, il nest pas possible dassurer avec
certitude que faire ces requtes en une serait forcment plus rapide, la taille du joint
unique pouvant tre trs consquente.
Voici la liste du temps dexcution des requtes de rcupration des donnes du
plan, excutes pour rpondre aux appels AJAX :
Liste des murs : 1 requte, 0.80ms
Liste des fentres : 1requte, 0.76ms
Liste des appareils : 25 requtes, 8ms
Le nombre de requtes pour les appareils dpend du nombre dobjets de la maison
rcuprer car il y a une relation ManyToMany.
La rcupration des donnes des compteurs pour les 24 dernires heures prend 2
requtes (une pour les donnes et une pour retrouver lID du Meter en fonction de
6.8. PERFORMANCES
77
son hash) et sexcute en 2.5ms.
Autres donnes importantes

La requte pour rcuprer tous les relevs bruts dun compteur (Reading) depuis
son installation prend 30ms, et les donnes agrges par jour (ReadingDay) prennent
2ms. Cependant, actuellement la table des relevs bruts ne contient que 10000 entres.
Pour lenvoi de donnes dun compteur dont la consommation fluctue (et donc dont
le preprocessing ne supprime pas de relevs) et dont les relevs sont pris toutes les 5
minutes cela ne reprsente que 34 jours de relevs. On est en droit de se demander
partir de quand il faut supprimer les relevs pour viter que la performance de cette
requte ne se dgrade. En ralit, jattends davoir les donnes des vrais capteurs
pour dcider de la suppression, mais je pense que la conservation des relevs bruts
plus de deux semaines nest pas utile lutilisateur. Plus loin, ce qui lintressera
sera sa consommation agrge par jour, voire uniquement par mois. Une solution
serait ventuellement dagrger les anciens rsultats par heure, afin de garder un
profil prcis si lutilisateur le dsire, sans toutefois surcharger la base de donnes.
Les autres pages suivent les mmes proportions et ne seront pas discutes en
dtail. Une page avec un plan prendra une vingtaine de requtes excutes en une
petite dizaine de millisecondes, les autres pages un peu moins.
6.8.2
Tailles de transferts et temps de rendu
Pour les essais de performances, jai dabord analys la taille des fichiers tlchargs
pour les principales pages. Jai fait trois analyses : le nombre total doctets transfrs
sans lutilisation de cache, le nombre total doctets transfrs lors de la premire visite
et lors de la deuxime visite (et les suivantes). Le rsultat est visible sur la figure
6.28. Les navigateurs possdent tous des caches, et la majorit du contenu ici chang
avec lutilisateur est statique : les fichiers JavaScript, le CSS, et les nombreuses
images.Ds lors, linterface tire parti au maximum du cache de ces navigateurs, pour
rduire le temps de rcupration de ces fichiers et donc le temps de rendu (nous le
verrons plus tard). Le nombre doctets tlchargs lors de la premire visite dune
page nest pas non plus gal au nombre total doctets transfrs sans aucun cache.
En effet, dune part, la librairie jQuery est incluse depuis les serveurs de google, or
nous lavons vu, le taux de pntration de jQuery atteint 30% des sites webs les plus
populaires, et beaucoup de sites utilisent la mme technique assurant que jQuery
soit dj dans le cache de lutilisateur. De plus, toutes les librairies JavaScript ne
sont pas inclues sur toutes les pages. Le systme de dessin du plan par exemple est
uniquement inclu sur les pages consommation, alertes et les 4 dernires tapes de
modlisation. Ainsi, lorsque lutilisateur arrive sur la page daccueil, il ne charge en
fait que les librairies communes toutes les pages. Lutilisateur ne tlchargera jamais
plus de 300Ko par page. Comme il passe toujours dabord par laccueil, il naura
jamais la situation sans cache de la page consommation qui demande plus de 680Ko.
78
Figure 6.28 Quantit de donnes transfres pour laffichage de diverses pages

Une fois toutes les pages visites, aucun chargement nengendre plus de 40Ko de
transfert, ce qui est trs raisonnable. A titre de comparaison, la page daccueil de
la RTBF [47] engendre un chargement de plus de 700Ko au premier chargement, et
55Ko au suivant, soit plus du double de notre situation.
Ce qui compte au final pour lutilisateur, ce nest cependant pas la taille transfre,
sagissant de si petites quantits, mais le temps de rendu. Jai donc compar le
temps de rendu de chacun des 3 grands navigateurs de bureau pour quelques pages
caractristiques galement. En ralit, les navigateurs ne donnent que le moment
o ils ont fini de tlcharger la dernire ressource. Ce moment nest pas tellement
diffrent du moment o le rendu est termin dans notre cas, puisque toutes les pages
lourdes effectuent des requtes en AJAX la fin du rendu. En effet, la page de
consommation ne charge les donnes des compteurs qu la fin de laffichage du
plan, et concernant la page statistique, les graphiques saffichent au fur et mesure
du traitement des donnes, une fois celles-ci reue. Lappel des donnes de la page
statistique ne se fait galement quau moment o toute la page et les librairies ont
t charges, soit quand le rendu est dj presque fini. Le rsultat est visible sur la
figure 6.29. Jai galement fait les mme mesures sur la page daccueil de google
titre de comparaison. Les batonnets intituls SC sont les temps de chargement sans
cache. Fatalement, les temps de chargement sans cache sont plus longs puisquil y
a plus de donnes transfrer. Il est important de noter que le temps indiqu est
celui de la fin du rendu du dernier lment. Mais le rendu est toujours progressif.
Pour les plans par exemple, jai choisi dafficher le plan chaque nouvel lment
tlcharg. Il est donc dessin, la rceptions des murs, des fentres, des appareils,
puis des compteurs. Ceci allonge le temps de rendu total mais permet lutilisateur
de voir le chargement progresser. Toutes les mesures ont t faites avec la fonction
de dfilement automatique active. Firefox est fort impact par cette option et les
autres navigateurs ne semblent pas en souffrir.
Concernant les mobiles, jai utilis Chrome dans sa version Mobile. La mthodologie est la mme. Jai compar les temps de rendu entre un Samsung Galaxy S2,
6.8. PERFORMANCES
79
Figure 6.29 Temps de rendu pour diverses pages - Moyennes de 5 rendus - Chrome
27, IE 10, Firefox 13
Figure 6.30 Temps de rendu pour diverses pages - Chrome Mobile
Smartphone haut de gamme mais datant de 2 ans et demie (la version actuelle est
le S4), et un HTC Desire X, smartphone rcent mais de bas de gamme (bien que
lun des meilleurs de sa gamme). En plus des pages du site, jai compar cette fois le
temps de chargement des pages avec le temps de chargement de la version mobile du
site du journal le Soir. Les rsultats sont visibles sur la figure 6.30. On voit ici que
les Smartphones sont plus impacts par la lourdeur du traitement JavaScript, mais
restent dans une moyenne acceptable. De plus, laffichage partiel prend ici mieux son
sens. Si la page consommation prend 7 secondes tre rendue, en ralit aprs 3,5
secondes le plan est dj affich, et la page attend simplement le chargement des
donnes du graphique. Cest important, car laisser patienter lutilisateur 7 secondes sur un cran de chargement serait par contre frustrant pour lui. Remarquons
que le HTC Desire X est lgrement plus lent que le Samsung Galaxy S2, mais ce
smartphone, quoique bas de gamme, ne sen sort pas trop mal.
80
6.8.3
valuation quantitative
Cette section prsente quelques chiffres concernant le code source.

Code Python : 2287 lignes, 6486 mots.
Code JavaScript (sans les librairies externes) : 3060 lignes, 9969mots.
Librairies JavaScript externes : 14
Modules Django externes importes : 6
Templates HTML : 2266 lignes, 5766 mots.
CSS : 1051 lignes, 1597 mots.
Scripts Pythons (compteurs virtuels) : 340 lignes, 1179 mots.
Nombre dimages : 64.
Le nombre assez restreint de lignes de code dmontre lavantage des choix dimplmentation discuts dans la section 3. Les nombreux modules permettent de se
concentrer sur le coeur des algorithmes, Python tant un langage particulirement
concis et jQuery permettant des enchainements de fonctions en une seule ligne sans
pour autant perdre en lisibilit. Cependant ce rsultat est videmment relativiser
car lcriture de chaque ligne est plus longue, puisquil y a plus dimplications et
de fonctionnalits. De plus, lutilisation dune librairie ou de lun des nombreux
imports Python requiert une tape de recherche importante, suivie de la lecture
approfondie de la documentation avant limplmentation. Django est prsent ici
comme un framework permettant de tout faire trs rapidement. Cest exact, mais
comprendre son fonctionnement, et surtout comprendre le fonctionnement de son
systme de modle, de requtes, lutilisation des templates, etc...a ncessit en ralit
presque un mois.
Chapitre 7
Perspectives et travail futur
Tout au long de llaboration du projet, lquipe IdP na cess dmettre de
nouvelles ides quant linterface, mais le temps est limit et nous avons d faire
des choix. Cependant, chaque groupe a veill garder une certaine modularit dans
la conception des lments qui leurs taient attribus. Le projet en son tat actuel,
bien que totalement fonctionnel, est encore une infime partie de ce quil peut devenir.
Je vais explorer dans ce chapitre diverses possibilits pour amliorer linterface et les
donnes qui lui parviennent.
7.1
Alertes
Un premier travail intressant serait de permettre linterface de combiner

plusieurs pices de puzzle, afin de crer des conditions sur le dpassement simultan
de deux capteurs par exemple. Rappelons que la combinaison de plusieurs pices est
dj possible au niveau de la base de donnes, mais cest le manque de temps pour
implmenter les nombreuses routines de dessin des pices combinables qui mont
empch de limplmenter du ct JavaScript/HTML.
De nombreuses pices finales intressantes pourraient galement tre imagines :
appel dune requte HTTP, notifications sur une application smartphone, lancement
dun script bash ou mme Python, ...
7.2
Statistiques et suppression des relevs
La page statistiques fera lobjet dune valuation avec le groupe IdP en septembre :
aprs deux mois denvoi de donnes avec de vrai capteurs il sera intressant de savoir
quelles seront les donnes utiles ainsi que la pertinence des graphiques.
Actuellement, aucune donne des relevs nest supprime si ce nest les doublons
81
82
CHAPITRE 7. PERSPECTIVES ET TRAVAIL FUTUR
discuts dans la section 4.6.1. En ralit, conserver plus de deux semaines la consommation prcise dune journe nest probablement pas ncessaire. Lutilisateur
sera intress par le dtail de sa consommation dans un pass proche, mais les
donnes agrges par jour sont suffisantes sur le long terme, car ce qui importe pour
lutilisateur, cest de pouvoir comparer la consommation par mois et par an, afin de
voir si ses efforts en matire de consommation ont port leurs fruits.
7.3
Image des appareils
Je prvoyais lajout dune image pour chaque appareil placer dans la maison.
Cependant, cela reprsentait un travail assez consquent, tant donn quil y a plus de
35 appareils actuellement. Je me suis dbrouill pour crer dj une cinquantaine de
symboles pour linterface, et je nai pas eu le temps de dessiner chacun des appareils
pour remplacer la vue actuelle constitue d un simple carr portant le nom de
lappareil et le symbole des nergies quil utilise.
7.4
Application SmartPhone native
Le dveloppement dune application pour Android permettrait dassurer une plus

grande fluidit, et de contourner les problmes de compatibilit rencontrs. Pour le
dveloppement de leurs applications smartphone, beaucoup dentreprises ont choisi
pour solution de dvelopper une application qui est en ralit un simple navigateur,
avec toutefois quelques ajouts comme un menu ou un systme de notification, mais
dont tous les lments sont simplement rendus en HTML par un serveur et rendus par
une librairie disponible sur le smartphone. Lutilisation de cette technique dans notre
cas permettrait davoir un menu en code natif, qui ne se recharge pas au changement
de pages, et dajouter une nouvelle pice de puzzle qui crerait une notification sur
le smartphone.
Au vu de la section performances, linterface ne souffre pas spcialement du
manque dapplication ddie, mme si cela reprsente une piste intressante.
7.5
Modle nergtique
Le projet tel que dfini en dbut danne et prsent au groupe Ingnieur de Projet
prvoyait lintgration dun modle nergtique, pour placer lutilisateur entre deux
scnarii simuls : lun au niveau de la consommation optimale, un but atteindre
pour lutilisateur, et lautre au niveau de consommation minimale. Il devait galement
permettre une dsagrgation des mesures globales en secteurs de consommation, et
la simulation de la consommation en amliorant certains paramtres de la maison
(comme lisolation dun mur). Cependant, le modle devait tre conu par des acteurs
en dehors de lquipe IdP et na pas pu mtre fournis temps. Il est donc prsent
7.5. MODLE NERGTIQUE
83
ici et pourrait faire lobjet dune intgration future linterface, notamment par
rapport au concours Ingnieur de Projet qui se termine en Novembre.
Cet abandon du modle explique pourquoi linterface possde toute une partie de
modlisation qui na actuellement dautre vocation que lesthtique de laffichage des
rsultats sur un plan. En ralit le modle a besoin dun utilisateur qui lui fournisse
des donnes relatives aux types dappareils prsents dans la maison, type de chaudire,
mais aussi des informations sur la disposition, lpaisseur des murs, des fentres, etc.
Lutilisateur doit pouvoir choisir avec quelle prcision il fournit ces donnes. Plus le
modle reoit de donnes, plus ses estimations seront prcises. Cest pour cela que
linterface prsente un mode basique et avanc. Lutilisateur basique est videmment
celui qui a le moins de donnes rentrer et qui surtout,ncessite le moins de connaissances techniques, par exemple celles concernant lisolation des murs de sa maison.
Le but principal du modle tait de dfinir , avec les informations acquises par
les composants prsents prcdemment, une srie de statistiques :
Les pertes, et le lieux des pertes (isolation, etc)

Une courbe de la consommation dans le meilleur des cas
Une courbe de la consommation dans le pire des cas
Une dsagrgation de la consommation globale en divers postes de consommation : chauffage, clairage, etc.
Le modle devait sortir 2 courbes de consommation : une courbe reprsentant la
consommation en cas dutilisation rationnelle de lnergie, lautre correspondant
un comportement abusif. En comparant la consommation provenant des mesures,
lutilisateur peut visualiser sa position et, en essayant datteindre la courbe infrieure,
trouver la motivation ncessaire pour rduire sa consommation, et donc sa facture.
Idalement, le modle serait en mesure de modifier ses prvisions en fonction de
travaux damlioration effectuer dans la maison : ceci permettrait destimer les
conomies potentielles, et de guider lutilisateur dans le choix des rnovations les
plus efficaces effectuer sur le plan nergtique.
La liste des variables ncessaires au paramtrage du modle tel que dfini avec
lencadrant est disponible en annexe 1. Techniquement, mon interface devait donc
fournir des valeurs pour toutes ces variables. Linterface aurait alors appel une
fonction matlab en passant ces donnes sous forme de matrice. En pratique, la partie
basique devait tre faite aprs la partie avance,et, comme dans la plupart des cas,
il aurait suffi de supprimer des paramtres rentrer par lutilisateur. Vu que le
modle na jamais t disponible, la version basique de linput na pas t spcialement implmente. Actuellement, linterface permet donc la dfinition des donnes
"avanc" dfinies dans lannexe, hormis lorientation du terrain (Nord/Sud/...), et
les informations associes aux objets comme le classement des lectromnagers de
lutilisateur (A, A+, ...) ou la date de la chaudire. En effet, voyant que toute
84
cette partie serait probablement inutile puisque le modle ne viendrait probablement

jamais, jai prfr me concentrer sur les compteurs virtuels et la partie alertes et
statistiques de linterface. Cependant lajout dinformations lies aux objets du plan
est prvu dans limplmentation et facilement ralisable, si ces informations devaient
tretre utilises.
Mme sans le modle, le projet reste intressant et atteint son but dinformation.
Linterface permet notamment le contrle dappareil, ce qui est une fonctionnalit
supplmentaire par rapport au cahier des charges.
7.6
Interfaage avec un systme domotique existant
Nous lavons vu dans ltude de march, la spcificit de notre systme est son
adaptation non-intrusive aux divers compteurs dj en place dans la maison. Cependant, certaines maisons sont dj quipes en matire de domotique. Ces systmes
sont extrmement chers et je nai pu men procurer. Cependant les diffrents modes
de compteurs et la simplicit du protocole permettent dintgrer facilement diverses
couches de compatibilit avec des systmes existants. Par exemple, la smartbox
dlectrabel [49] dispose dune interface web. Il ne serait pas trs compliqu de
crer un script la manire des compteurs virtuels (Voir chapitre 5) pour parser
le code de la page HTML avec des expressions rgulires et envoyer les donnes de
consommation linterface.
De faon gnrale, le chapitre 5 a dj prsent de nombreuses possibilits
quant lextraction dinformations dautres systmes pour en tirer des donnes de
consommation envoyer aux compteurs de linterface. Beaucoup dapproximations
peuvent galement tre faites via la vision par ordinateur, puisque la plupart des
appareils disposent de LED pour indiquer leur tat et que leur consommation est
souvent fixe en fonction de celui-ci.
7.7
Prsence des habitants
Pour le modle nergtique, il est important de connatre le nombre dhabitants

au sein de la maison. Avant son abandon, jai explor plusieurs possibilits pour
affiner le taux de prsence des utilisateurs, en tudiant notamment sa position et
donc sa prsence dans la maison.
Une premire ide serait dinter-connecter le systme avec un systme dalarme.
Lorsque lalarme est branche, lutilisateur nest pas chez lui (sans oublier les systmes
dalarmes de nuit). On peut galement utiliser les diffrents dtecteurs pour avoir un
fonctionnement par pice, on aurait alors la possibilit de dtecter un appareil.
7.7. PRSENCE DES HABITANTS
85
Une autre possibilit est dinstaller un logiciel sur le smartphone de lutilisateur.

La plupart de ceux-ci disposant dune puce GPS, il est possible de savoir sil est
la maison ou ailleurs. Le WiFi pourrait galement tre utilis, lutilisateur pouvant
dfinir un rseau WiFi comme celui de son travail ou de sa maison, que ce soit via
son smartphone ou son ordinateur portable.
La section prcdente envisageait un interfaage avec des installations domotiques.
Certaines nouveauts sont apparues en matire de serrures lectroniques comme
Lockitron[30]. Lockitron est une serrure activable par WiFi ou Bluetooth. Elle possde une API afin dtre contrle via nimporte quel systme connect internet.
Lutilisation de Lockitron permettrait assez facilement de savoir si lutilisateur est
chez lui ou pas.
Figure 7.1 Lockitron
86
Chapitre 8
Conclusion
Lobjectif de ce travail tait dimplmenter une interface de prsentation des
statistiques de consommation dune maison. Loriginalit rside dans sa capacit
configurer lenveloppe nergtique de la maison, sa grande flexibilit quant aux types
de compteurs, et le support de multiples entres. Paralllement, linterface devait
respecter trois axiomes :
Accessibilit : une interface facile dutilisation et intuitive mais nanmoins
complte
Flexibilit : au niveau de la maison, des objets, des capteurs, ou encore des
nergies
Performance : linterface doit tre fluide, et utilisable sur les smartphones
Linterface a t pense entirement pour une facilit daccs pour tous les utilisateurs. Le systme de plan est simple mais permet la dfinition correcte de lenveloppe
de la maison. Le placement des appareils est aussi souple et lutilisation du glisserdplac pour les compteurs permet une approche intuitive. Les nombreux symboles
procurent une vision claire pour lutilisateur de bureau, et permettent dutiliser le
doigt pour slectionner un lment sur un smartphone.
Linterface a galement t dmontre comme assez modulable : lutilisateur peut
ajouter de nouvelles nergies, de nouveaux appareils et de nouveaux compteurs. Les
nouveaux compteurs peuvent mme tre envisags pour mesurer une production. Les
diffrents modes denvoi de donnes permettent daccepter plusieurs mthodes de
consommation : autant des donnes envoyes par des compteurs de consommation
totale que des compteurs de consommation instantane. Linterface peut galement
tre utilise comme systme de contrle des appareils de lutilisateur.
La structure interne de linterface a galement t pense modulable, autant du
ct serveur grce Django et ses prceptes bien penss utilisant le paradigme MVC,
mais aussi du ct client o le code JavaScript est en gnral divis en modules
remplaables et modifiables. Jai aussi veill coder en utilisant des objets dans les
limites du JavaScript, ou du moins des mcanismes rutilisables en proscrivant le
87
88
CHAPITRE 8. CONCLUSION
copier-coller. Lajout dune nouvelle page bnficiera par exemple du systme de

rcupration automatis des Modles tablis ct serveur en objets JavaScript, et du
renvoi de ceux-ci vers le serveur. Le systme de dessin du plan est galement bas sur
un systme de "plugin", permettant lajout facile de nouvelles tapes de dfinition
du plan comme la dfinition de portes ou darbres autour de la maison pour calculer
lensoleillement si le modle nergtique le ncessitait.
Du ct des performances, les divers tests montrent que mme les pages les plus
lourdes nont quun impact lger sur le temps de rendu. La gnration et laffichage
de la page daccueil est plus rapide sur tous les navigateurs que celle de Google.
Lalgorithme de redimensionnement des plans ne souffrirait cependant pas de certaines optimisations, mais son calcul par tapes permet un affichage progressif de
la page malgr des calculs de dimensionnement importants. Linterface fonctionne
correctement sur les smartphones, moyennant quelques concessions en attendant la
publication des correctifs du systme Android.
Ce travail a galement explor les possibilits en matire de capteurs virtuels,
notamment pour dmontrer les avantages de lutilisation de lHTTP, protocole trs
mature, rarement bloqu par les firewall et dont le nombre de libraires et implmentations permet la mise en place trs rapide de petits scripts pour envoyer ou lire des
donnes depuis linterface.
Pour conclure, il me semble que les objectifs ont t atteints, mme si linterface
pourrait encore bnficier damliorations. Par exemple, au niveau de la page des
statistiques qui pourrait afficher plus de graphiques, de comparaisons par saison ou
comparer la consommation dun jour avec celle du mme jour de lanne ou de la
saison prcdente, sans toutefois noyer lutilisateur sous une trop grande quantit
dinformations. La page des alertes pourrait galement avoir de nouvelles pices
pour permettre plus dactions et dautomatisations en fonction des vnements se
produisant autour de la consommation de lutilisateur.
Au regard de ce qui existe dj, linterface de USE Monitoring semble tre la seule
combiner tous les lements cits au fur et mesure de ce travail. Certaines interfaces
sont trs belles mais ne permettent que la mesure de consommations lectriques.
Dautres permettent de mesurer toutes les nergies, mais seulement de faon globale
et ne permettent pas de mesurer la consommation des appareils mnagers. Aucune
interface ne procure une souplesse aussi dveloppe que dans ce travail. Lintgration
future du modle nergtique permettrait damener chez lutilisateur des rsultats
scientifiques jusque l rservs uniquement aux professionnels, et lui permettant de
trouver les pertes nergtiques au sein de sa maison.
Alors, est-ce que linterface et le systme complet avec les capteurs pourront
amener lutilisateur rduire sa consommation ? La rponse est positive si on en
croit les divers articles cits en introduction liant informations et rductions de
89
consommation, ou si, simplement jobserve mon rflexe lorsque je peux constater,
grce aux compteurs virtuels placs sur mes ordinateurs, ce quil men cote concrtement. Si, par exemple, il est vident que mon ordinateur portable consomme
moins que mon ordinateur de bureau, la vision de la consommation en euro force le
passage laction. Je suis intimement convaincu que cet exemple est extrapolable
la consommation de chacun des appareils mnagers, ainsi qu la consommation
gnrale de la maison, permettant ainsi datteindre les objectifs de rductions de
consommation ncessaires aux respects des accords de Kyoto, et plus largement,
ncessaire pour que lhumanit puisse perdurer dans un monde aux ressources limites.
90
CHAPITRE 8. CONCLUSION
Bibliographie
[1] 45% of the popular websites use a javascript framework. url : http : / /
elie.im/blog/web/45- of- the- popular- websites- use- a- javascriptframework/#.UaWrPOddU9t.
[2] Acqualys. Tableau comparatif PCI des nergies. url : http://www.acqualys.
fr/page/tableau-comparatif-pouvoir-calorique-inferieur-pci-desenergies.
[3] Axeiya. Comptage de lnergie : kWh, kWh PCI, kWh PCS. url : http:
//bes.axeiya.com/index.php?id=31.
[4] Blender 2.6, Python Manual. url : http://wiki.blender.org/index.php/
Doc:2.6/Manual/Extensions/Python.
[5] Megan Bray. Review of Computer Energy Consumption and Potential Savings.
url : http://dssw.co.uk/research/computer_energy_consumption.html.
[6] P. Brimblecombe. The Big Smoke (Routledge Revivals) : A History of Air
Pollution in London Since Medieval Times. Routledge revivals. Taylor & Francis
Group, 2011. isbn : 9780415671835.
[7] caniuse.com. url : http://caniuse.com/.
[8] Canvas clearRect failing to clear. url : https : / / code . google . com / p /
android/issues/detail?id=39247.
[9] Canvas line drawing on Android failure. url : https://code.google.com/p/
chromium/issues/detail?id=231082.
[10] CPU Burn. url : http://manpages.ubuntu.com/manpages/hardy/man1/
cpuburn.1.html.
[11] Cron. url : http://www.gnu.org/software/mcron/.
[12] IDD - Institut pour un Dveloppement Durable. 30 annes d volutions
des revenus et des prix. url : http://users.skynet.be/idd/documents/
indicateurs/indic05-1.pdf.
[13] Django. url : http://www.djangoproject.com/.
[14] Django Debug Toolbar. url : https://github.com/django-debug-toolbar/
django-debug-toolbar.
[15] Django Extension. url : https://github.com/django-extensions/djangoextensions.
91
92
BIBLIOGRAPHIE
[16] Django Packages database. url : https://www.djangopackages.com/.

[17] Django-Pipeline plugin. url : http://django-pipeline.readthedocs.org/
en/latest/.
[18] Efergy. url : http://www.efergy.com/index.php/default/products-uk1/energy-gateways-1/engage-hub-uk.html.
[19] EKM Metering. url : http://www.ekmmetering.com/.
[20] ExCanvas. url : https://code.google.com/p/explorercanvas/.
[21] K. Gram-Hanssen D. Maes M. Cantaert B. Spies J. Desmedt F.Bartiaux
G. Vekemans. Socio-technical factors influencing Residential Energy Consumption SEREC. 2006.
[22] the green grid. Five Ways to Save Server Power. url : http : / / www .
thegreengrid.org/~/media/TechForumPresentations2008/Five_Ways_
to_Save_Server_Power.pdf?lang=en.
[23] INSTITUT DE CONSEIL ET DETUDES EN DEVELOPPEMENT DURABLE
ASBL ICEDD. Bilan nergtique wallon 2006, consommation du secteur domestique 2006. Rapport statistique. Ministre de la Rgion Wallonne DGTRE, 2008.
url : http : / / energie . wallonie . be / servlet / Repository / baa080930 domestique_2006_1423.pdf?ID=11526&saveFile=true.
[24] ie6countdown.com. url : http://www.ie6countdown.com/.
[25] Inkscape Wiki - Python modules for extensions. url : http://wiki.inkscape.
org/wiki/index.php/Python_modules_for_extensions.
[26] Intel ARK. url : http://ark.intel.com/.
[27] jQUery UI Touch Punch. url : http://touchpunch.furf.com/.
[28] jquery.com. url : http://www.jquery.com/.
[29] R Kohlenberg, T Phillips et W Proctor. A behavioral analysis of
peaking in residential electrical-energy consumers. In : J Appl Behav Anal
9.1 (1976), p. 138.
[30] Lockitron. url : https://lockitron.com.
[31] McKinsey&Company. Vers une efficacit nergtique de niveau mondial en
Belgique. 2009.
[32] Le Monde. Dans la confusion, Copenhague sachve sur un checc. 2009.
url : http://www.lemonde.fr/le-rechauffement-climatique/article/
2009 / 12 / 18 / un - accord - non - contraignant - obtenu - in - extremis - a copenhague_1282914_1270066.html.
[33] Le Monde. Le Canada quitte le protocole de Kyoto. 2011. url : http://
www.lemonde.fr/planete/article/2011/12/13/le-canada-quitte-leprotocole-de-kyoto_1617695_3244.html.
[34] Net Market Share. url : http://www.netmarketshare.com/.
BIBLIOGRAPHIE
93
[35] NumPy. url : http://www.numpy.org/.

[36] OCZ. url : http://www.ocz.com/.
[37] Open Energy Monitor. url : http://openenergymonitor.org/emon/.
[38] Performance Comparison - C++ / Java / Python / Ruby/ Jython / JRuby
/ Groovy. url : http://blog.dhananjaynene.com/2008/07/performancecomparison-c-java-python-ruby-jython-jruby-groovy/.
[39] P.P. La fin des primes photovoltaques . In : La libre (2009). url : http:
//www.lalibre.be/actu/belgique/article/535798/la-fin-des-primesphotovoltaiques.html.
[40] Pylons. url : http://www.pylonsproject.org/.
[41] Python. url : http://www.python.org.
[42] Python 3 vs C++ g++. url : http://benchmarksgame.alioth.debian.org/
u32q/benchmark.php?test=all&lang=python&lang2=gpp&box=1.
[43] Python - Other platforms download. url : http://www.python.org/getit/
other/.
[44] Python Package Index. url : http://www.python.org/getit/other/.
[45] Raspberry Pi Website. url : http://www.raspberrypi.org/about.
[46] Recommendation against Python ? url : https : / / groups . google . com /
forum/?fromgroups#!topic/unladen-swallow/TtvEBvVEZD4.
[47] RTBF. url : http://www.rtbf.be.
[48] SciPy. url : http://www.scipy.org/.
[49] SmartBox. url : https://www.electrabel.be/fr/particulier/prix-gazelectricite-fournisseur/smartenergybox.
[50] Socit Wallone Des Eaux. url : http://www.swde.be/.
[51] UCL. Pr-Dimensionnement. url : http://www-energie.arch.ucl.ac.be/
cogeneration / CDRom / cogeneration / evaluer / frames / cbcogenepredim .
htm.
[52] UVED. Les Annes 70. . . Un tournant dcisif : dveloppement et croissance
ne vont plus de pair ! 2006. url : http://www.uved.fr/fileadmin/user_
upload/modules_introductifs/module4/site/html/1- approche_1- 2contexte_2.html.
[53] WattVision. url : http://www.wattvision.com/info/products.
[54] WesternDigital. url : http : / / www . wdc . com / fr / products / internal /
desktop/.
[55] R. Weyler. Greenpeace : How a Group of Ecologists, Journalists, and Visionaries Changed the World. Rodale Books, 2004. isbn : 9781594861062. url :
http://books.google.be/books?id=M1GW445y2n4C.
94
BIBLIOGRAPHIE
[56] Wget. url : http://www.gnu.org/software/wget/.

[57] Wikipedia - Comparison of Nvidia graphics processing units. url : http://
en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_
units.
[58] Xbee. url : http://www.digi.com/xbee/.
[59] yuglify. url : https://github.com/yui/yuglify.
Annexe 1 - Input du modle
Catgorie
Variable
Valeur commune
ge
Date de construction
Anne
Catgorie de maison
Type
Maison ou Appartement
Nombre de facade
2F - 3F - 4F
Situation
Urbain / Pri-urbain / Rural
Gomtrie
Enveloppe
Standard
Avanc
Surface chauffe totale (m)
Demande
Calcul sur le dessin
Hauteur des tages chauffs (m)
Demande
Demande
Demande pour chaque faade
Orientation du dessin
Toiture
Forme choisir parmis une liste
Espace sous-toiture chauff?
Oui/Non
Fondations
cave / vide ventil / dalle sur sol
Nombre de niveaux chauffs
1, 2 ou 3
Faades extrieures (l * h)
N - NE - E - SE - S - SO - O - NO
Composition
Isol ou non ?
Epaisseur d'isolant / paroi
Fentre - Surface
Demande du ratio de surface impos = f(layout)
Calcul par le placement des

baies sur le dessin
Fentre - Type
simple, double, double HtePerf (majoritaire)
simple, double U>2, double U<2, tripleetc
Paroi vers cave non chauffe
isol ou non ?
Choix d'paisseur d'isolant lors du dessin
Paroi vers grenier non chauff
isol ou non ?
Choix d'paisseur d'isolant lors du dessin
Zonage
Types et surfaces des zones
Slection de layout type
Dessin chelle
Emission de chaleur
Type / tage
Type d'metteur par niveau (majoritaire)
Type + placement sur dessin
Controle / metteur
Type de controle (thermostat, vanne) majoritaire
type de controle / metteur
Puissance installe (kW)
Non demand
Calcule via placement des radiateurs
Rgime de temprature (C)
Non demand
Calcule via placement des radiateurs
Production de chaleur
Temprature de consigne zones jour
Temprature de consigne zones nuit
Programmation horaire
h/jour
Central ou dcentralis
Vecteur nergtique
gaz/mazout/butane
ge de l'installation
date d'installation
type d'installation (si central)
chaudire condensation, classique
type de rgulation (si central)
aucun
thermostat
sonde extrieure
Production d'ECS
central ou dcentralis
vecteur nergtique
Occupation
Nbre d'adultes
Nombre
Profession des adultes
ouvrier
employ
indpendant
sans emploi (par adulte)
Nbre d'enfants < 6 ans
Nombre
Nbre d'enfants > 6 ans
Nombre
Eclairage
0 - 10 - 20 - 30 - 40 - 50 % (approximatif) d'ampoules conomiques

60 - 70 - 80 - 90 - 100 %
Electromnager
Rfrigrateur
0,1,2,
nombre + classe nergtique
Rfrigrateur + Conglateur combin
0,1,2,
Conglateur
0,1,2,
Lave vaisselle
0,1,2,
Four lectrique
0,1,2,
Taque de cuisson lectrique
0,1,2,
Cuisinire gaz
0,1,2,
Four micro-onde
0,1,2,
Bouilloire lectrique
0,1,2,
Machine lessiver
0,1,2,
Schoir
0,1,2,
Ordinateur de bureau
0,1,2,
Ordinateur portable
0,1,2,
Imprimante
0,1,2,
Tlvision CRT
0,1,2,
Tlvision LCD
0,1,2,
Tlvision Plasma
0,1,2,
Lecteur DVD
0,1,2,
Dcodeur numrique
0,1,2,
Chane HiFi
0,1,2,
Modem/Routeur internet
0,1,2,

Rapport

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport

Transféré par

Droits d'auteur :

Formats disponibles

Universit de Lige

Facult des Sciences Appliques

Travail de fin dtudes

Implmentation dun Systme de Contrle Domotique

Travail ralis par Tom Barbette

Anne acadmique 2012-2013

Promoteur : Pr. Benoit Donnet

Travail de fin dtudes prsent en vue de lobtention du grade de Master en Sciences

Interface de dmonstration et code source

Le nom dutilisateur est "tfe" et le mot de passe est "tombarbette2013".

Table des matires

2 Systme dacquisition et objectifs

TABLE DES MATIRES

capteur est utile.

CHAPITRE 2. SYSTME DACQUISITION ET OBJECTIFS

Figure 2.1 Vue globale du systme

Figure 2.2 Raspberry PI

configuration de lenveloppe de la maison pour une ventuelle future intgration qui

Notons ici la modularit du systme : il fonctionne aussi bien pour un utilisateur

CHAPITRE 2. SYSTME DACQUISITION ET OBJECTIFS

Figure 2.3 Photo de linterface

Figure 2.4 Systme de capture directement coll au compteur

de la fabriquer soi-mme sur un PCB (Printed Circuit Board - Circuit imprim),

Figure 2.6 Image des numros aprs filtrage

Prise de la photo de 640x480 par la webcam logitech c210 (Fig. 2.5)

Figure 2.7 Image des numros aprs filtrage

CHAPITRE 2. SYSTME DACQUISITION ET OBJECTIFS

dexcuter des scripts automatiquement un interval dfini [11].

Concernant la temprature, le PIC est branch un simple capteur dont la tension

Figure 2.8 Schma gnral de la communication des modules de mesure lectrique

CHAPITRE 2. SYSTME DACQUISITION ET OBJECTIFS

Figure 2.9 Schma des modules thermiques, du wattmtre, et de la carte mre

2.2. ETUDE DE MARCH

Open Energy Monitor

La solution propose par efergy[18] consiste en un petit boitier de mesure connect

Wattvision[53] est un appareil de mesure de la consommation lectrique globale.

EKM Metering[19] propose une solution de monitoring de llectricit, du gaz et

CHAPITRE 2. SYSTME DACQUISITION ET OBJECTIFS

compatible Windows, Linux et Mac pour lire les donnes mesures.

Chacon ecowatt permet la mesure de consommation lectriques globale de la

CHAPITRE 3. CHOIX LOGICIELS

3.2. FRAMEWORK : DJANGO

Bien quil soit envisageable de gnrer directement du code HTML en Python,

CHAPITRE 3. CHOIX LOGICIELS

garder la documentation au niveau de la dernire version.

3.2. FRAMEWORK : DJANGO

Scurit dans Django

Django dispose de plusieurs mcanismes de scurit intgrs, tous utiliss dans

CHAPITRE 3. CHOIX LOGICIELS

3.2. FRAMEWORK : DJANGO

CHAPITRE 3. CHOIX LOGICIELS

Comme expliqu dans la section 3.2, Django fonctionne en combinant plusieurs

CHAPITRE 4. STRUCTURE DE LINTERFACE

Figure 4.1 Structure des donnes relatives la maison

Structure de la base de donne

La base de donnes peut tre divise en 3 parties distinctes : la structure de la

4.2. STRUCTURE DE LA BASE DE DONNE

Figure 4.2 Structure des donnes relatives aux alertes

Figure 4.3 Structure des donnes relatives aux utilisateurs

CHAPITRE 4. STRUCTURE DE LINTERFACE

Pour rappel, Django cre automatiquement la base de donnes et lextension

Linterface supporte plusieurs maisons reprsentes par lobjet maison (House).

4.2. STRUCTURE DE LA BASE DE DONNE

Puissance (POWER) : ce sont les nergies qui peuvent produire un travail,