Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau

Année 2014-2015
Rapport de projet - EI5 AGI – parcours IAIE
Projet Application Web De Domotique Arduino
Projet réalisé par :
Nicolas ROULLEAU
Adrien LIOTARD
Projet encadré par :
Serge TAHE
ISTIA - Université d’Angers

ISTIA l Institut des sciences et techniques de l'ingénieur d'Angers
www.istia.univ-angers.fr l istia@univ-angers.fr
62 avenue Notre-Dame du Lac l 49000 ANGERS l Tél. 02 44 68 75 00 l Fax 02 44 68 75 01
Angers,
Réf. Direction des enseignements ENGAGEMENT DE NON PLAGIAT
Et de la vie étudiante(DEVE)
Objet : Engagement de non Plagiat
Je soussigné(e) …………………………………………………………………………………. , être pleinement conscient(e) que le
plagiat de documents ou d’une partie d’un document publiés sur toutes formes de support, y compris
l’internet, constitue une violation des droits d’auteur ainsi qu’une fraude caractérisée. En conséquence,
je m’engage à citer toutes les sources que j’ai utilisées pour écrire ce rapport ou mémoire.
Lu et approuvé
Signature

Table des matières
1 Introduction 8
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 Système domotique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 Communication clients-serveur . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1 Les différentes actions possibles des clients . . . . . . . . . . . . . . . . . 10
1.2.2 Commande de plusieurs cartes en simultané . . . . . . . . . . . . . . . . 11
2 Structure d’une application MVC 12
2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Le rôle de chaque partie . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Les flux de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Client AngularJS 14
3.1 Implémentation du MVC avec AngularJS . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Les vues de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Design : Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Version mobile avec PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Client ASP.NET 24
4.1 Implémentation du MVC avec ASP.NET . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 La partie présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Le back-office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Les vues de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 La page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.2 Lecture de l’état d’une pin . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3 Écriture sur une pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.4 Clignotement d’une LED . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.5 Envoi d’une commande au format JSON . . . . . . . . . . . . . . . . . . 32
4.3 Design : Bootstrap + thème Material Design . . . . . . . . . . . . . . . . . . . . 32
4.4 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Gestion de projet 34
5.1 Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 Diagrammes de répartition du temps par tâches . . . . . . . . . . . . . . . . . . 35
5.3 Méthodes de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5

6 Conclusion 36
6.1 Apports professionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 Apports personnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3 Pistes d’amélioration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7 Annexes 37
7.1 Guide utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2 Intégration du thème Bootstrap Material Design . . . . . . . . . . . . . . . . . . 39
8 Bibliographie 41
6

Table des figures
1.1 Le montage électronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 L’architecture du système domotique . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 L’architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 La structure de l’application AngularJS . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 la vue Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 la vue Blink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 la vue Readpin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 la vue Temp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 la vue Writepin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 la vue Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.8 la vue MyArduinos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.9 message d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.10 barre de navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1 La structure de l’application ASP.NET MVC . . . . . . . . . . . . . . . . . . . . 24
4.2 La page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Aucune donnée entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Chaine rentrée non conforme au format d’une adresse IP . . . . . . . . . . . . . 27
4.5 La réponse du serveur est apparue . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Lecture de l’état d’une pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.7 Écriture sur une pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8 Erreur de saisie indiquée par le serveur . . . . . . . . . . . . . . . . . . . . . . . 31
4.9 Clignotement d’une LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.10 Envoi d’une commande au format JSON . . . . . . . . . . . . . . . . . . . . . . 32
4.11 L’apparence de départ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1 Le contenu des dossiers Content et Scripts . . . . . . . . . . . . . . . . . . . . . 39
7

Chapitre 1
Introduction
1.1 Contexte
Depuis quelques années, les solutions de domotique se démocratisent de plus en plus. En
effet, à une époque où il devient important de maitriser sa consommation énergétique et où
presque tout le monde dispose d’un smartphone, il est tentant de pouvoir commander ses
équipements domestiques (éclairage, chauffage, stores, etc) et de consulter l’état de l’habitation
(température, humidité, etc) via un ordinateur ou un appareil mobile. Même s’il existe bien sûr
déjà des solutions commerciales ”clés en main”, l’objectif de ce projet est de créer un système
de ce type à partir de zéro.
1.1.1 Système domotique
En principe, un système domotique est composé d’actionneurs et de capteurs reliés à un ré-
seau, afin de permettre leur gestion via une ou plusieurs interfaces homme/machine. En ce qui
concerne la partie matérielle, nous avons utilisé des cartes Arduino, très connues chez les brico-
leurs férus d’électronique pour leur grande polyvalence et leur faible coût. L’utilisation de ces
cartes rend le système extrêmement modulable. Ainsi même si dans notre cas les ”équipements”
connectés se limitent à des LED et des capteurs de température, il serait aisé de rajouter par
la suite de nouveaux éléments : autres capteurs, servomoteurs, relais ... Pour tester le système,
nous étions équipés de deux cartes Arduino Uno, chacune pourvue d’un shield Ethernet sur
lequel est fixé une LED ainsi qu’un capteur de température (voir figure ci-dessous).
8

Figure 1.1 – Le montage électronique
1.1.2 Communication clients-serveur
Afin de pouvoir gérer à distance les différents cartes Arduino composant la partie opérative
du système, ces dernières sont toutes reliées en Ethernet au même poste informatique, qui fait
donc office de serveur. C’est à ce serveur que viendront se connecter les utilisateurs, grâce à
des applications spécialement écrites pour cette occasion et compatibles aussi bien avec un
ordinateur classique qu’avec un smartphone ou une tablette.
9

Figure 1.2 – L’architecture du système domotique
1.2 Cahier des charges
Ce projet est consacré au développement de deux clients. Le premier basé exclusivement sur
les langages web (HTML, CSS, JavaScript), et le second utilisant la technologie ASP.NET de
Microsoft. La structure de ces deux clients doit être de type Modèle-Vue-Contrôleur (MVC).
1.2.1 Les différentes actions possibles des clients
Chaque client se comporte comme un site web comportant un menu permettant d’accéder
à différents formulaires. Chacun de ces formulaires est dédié à une commande particulière, qui
sera ensuite envoyée au serveur avec une requête HTTP. À partir des données contenues dans
la requête, le serveur enverra la commande correspondante vers les cartes Arduino connectées,
qui à leur tour exécuteront la commande. Au minimum, l’interface d’un client doit comporter
les formulaires suivants :
– Connexion au serveur gérant les cartes Arduino
– Lecture de la valeur d’une pin (analogique et binaire)
10

– Écriture de la valeur d’une pin (analogique et binaire)
– Clignotement d’une LED (spécification du nombre de clignotements et de leur intervalle)
– Envoi d’une commande au format JSON (JavaScript Object Notation) : en effet le ser-
veur permet d’envoyer n’importe laquelle des 3 requêtes précédentes au format JSON, en
respectant cette forme :
{"id":"identifiant","ac":"une action","pa":{"param1":"valeur1","param2":
"valeur2",...}}.
Avec :
– id : un identifiant de la commande. Peut être quelconque ;
– ac : une action. Il y en a trois :
– pw (pin write) pour écrire une valeur sur une pin,
– pr (pin read) pour lire la valeur d’une pin,
– cl (clignoter) pour faire clignoter une led ;
– pa : les paramètres de l’action. Ils dépendent de l’action.
1.2.2 Commande de plusieurs cartes en simultané
Chaque formulaire doit afficher une liste affichant toutes les cartes Arduino disponibles, afin
que l’utilisateur puisse choisir la ou les cartes sur lesquelles il souhaite envoyer la commande.
Lorsque plusieurs cartes sont sélectionnées, elles exécutent l’action demandée en simultané.
Le serveur retournant une chaine JSON après chaque requête, il faut également afficher cette
réponse dans le formulaire, sans avoir à recharger la page.
11

Chapitre 2
Structure d’une application MVC
2.1 Principe
MVC est un patron de conception qui vise à simplifier le développement et la maintenance
d’une application avec interface graphique. En effet, ce cadre normalisé permet de bien séparer
la gestion des données, la présentation de l’interface et les traitements à effectuer. Ainsi par
exemple, un développeur spécialisé dans le Web Design pourra s’occuper de la mise en page
de l’application sans toucher aux fichiers correspondant aux traitements, réalisés par un autre
développeur.
2.1.1 Le rôle de chaque partie
Le Modèle Le Modèle est chargé du traitement des données de l’application. À cet effet, il
contient plusieurs méthodes permettant de récupérer et de modifier la valeur de chaque variable
associée à une donnée. Si l’application utilise une base de données (ce qui n’est pas le cas ici),
c’est également le rôle du Modèle de gérer les accès vers la base (insertion, suppression, mise à
jour de champs).
La Vue La Vue correspond spécifiquement à ce qui est affiché par le navigateur web de
l’utilisateur. Cette page est dynamique, c’est-à-dire que la valeur de certaines des informations
affichées est obtenue à partir des données du modèle. Dans la plupart des cas, une vue contient
également un formulaire permettant à l’utilisateur de rentrer des informations grâce à divers
contrôles graphiques : champs de textes, cases à cocher, sliders, etc.
Le Contrôleur Le Contrôleur réagit aux évènements déclenchés par la vue (typiquement le
clic sur un lien ou la validation d’un formulaire par exemple). Il peut ensuite mettre à jour les
données du Modèle avec les informations entrées dans la Vue, et ensuite actualiser cette vue ou
en afficher une autre.
2.1.2 Les flux de données
Les interactions entre le modèle, la vue et le contrôleur est synthétisé dans le diagramme
ci-dessous :
12

Figure 2.1 – L’architecture MVC
13

Chapitre 3
Client AngularJS
3.1 Implémentation du MVC avec AngularJS
AngularJS est un framework JavaScript libre et open-source développé par Google. Celui-ci
est fondé sur l’extension du langage HTML par de nouveaux tags et attributs qui représente
alors la partie vue du modèle MVC. Les modèles sont appelés « scopes » et les contrôleurs
permettent de définir des fonctions en JavaScript.
Précédemment, nous avons introduit le concept de modèle MVC. Le schéma ci-dessous
illustre les interactions entres les différents composants de l’application finale AngularJS :
Figure 3.1 – La structure de l’application AngularJS
Dans ce schéma, on distinguera :
– Le module [angularduino.js] (en rouge)
Celui-ci définit les modules Angular utilisés par l’application et s’occupe de la configura-
tion des routes : grâce au module [ngRoute] utilisé pour le routage des URL, le module
14

[angularduino.js] désigne pour chaque URL demandé, la page HTML et le contrôleur
associés.
– Les contrôleurs (en orange)
Un contrôleur principal, [mainController.js], constitué des scopes enfants, des variables
globales ainsi que des fonctions gérant l’appel des différentes pages. On remarquera que
les modèles des vues sont déclarés dans ce contrôleur.
Un contrôleur pour chacune des vues :
pageblinkledController.js
pagecommandController.js
pagemesarduinosController.js
pagereadpinController.js
pagetempController.js
pagewelcomeController.js
pagewritepinController.js
– Les vues (en jaune)
La page principale [home.html] référence les fichiers du projet et appelle le menu ainsi
que la vue d’accueil.
[menu.html] contient le code HTML du menu qui permet de naviguer entre les différentes
fonctions de l’application.
Enfin, les pages [pageblinkled.html], [pagecommand.html], [pagemesarduinos.html], [pa-
gereadpin.html], [pagetemp.html], [pagewelcome.html] et [pagewritepin.html] contiennent
le code HTML des formulaires et des appels JavaScript de leur fonction respective.
Chacune contient la déclaration des variables du modèle de la vue, l’initialisation des
composants utilisés (UI Grid, selectpicker, n3linechart), la fonction envoyant la requête
HTTP à l’Arduino et récupérant la réponse du serveur, ainsi que certaines spécifications
liées à la page (gestion des Arduino disponibles, gestion des menus, astuce).
De l’utilisateur au serveur, explication d’une requête : Disons que l’utilisateur souhaite
faire clignoter une LED. Après avoir affiché la vue en question, il sélectionne un ou plusieurs
Arduino, remplit le formulaire et clique sur le bouton d’exécution. Voici le code HTML du bou-
ton d’exécution contenu dans [pageblinkled.html] : <a href=””ng-click=”scopeblinkled.Blink()”
type=”button”class=”btn btn-primary”>pageblinkled.actionlabel</a> Regardons de plus près
l’argument « ng-click ». Au clic, la page [pageblinkled.html] appelle la fonction Javascript
« Blink() » contenu dans le contrôleur [pageblinkledController.js] en passant par le modèle de
la vue « scopeblinkled ». Le contrôleur exécute alors la fonction Javascript « Blink() » qui fera
une requête http en GET au serveur web.
15

3.2 Les vues de l’application
[pagewelcome.html] la vue Welcome : cette vue est la page d’accueil de l’application. Elle
permet de configurer l’adresse IP du serveur domotique.
Figure 3.2 – la vue Welcome
[pageblinkled.html] la vue Blink : cette vue permet à l’utilisateur de faire clignoter une
LED en sélectionnant un ou plusieurs Arduino, un numéro de pin, une durée et un nombre de
clignotement.
Figure 3.3 – la vue Blink
16

[pagereadpin.html] la vue Readpin : cette vue permet à l’utilisateur de lire la valeur d’une
pin, en sélectionnant un ou plusieurs Arduino, un mode et une pin.
Figure 3.4 – la vue Readpin
[pagetemp.html] la vue Temp : cette vue permet à l’utilisateur de visualiser la valeur ana-
logique d’un capteur de température sur un graphe, en sélectionnant jusqu’à deux Arduino et
la valeur d’une pin analogique.
17

Figure 3.5 – la vue Temp
[pagewritepin.html] la vue Writepin : cette vue permet à l’utilisateur d’écrire la valeur
d’une pin, en sélectionnant un ou plusieurs Arduino, un mode, une pin et la valeur à écrire.
18

Figure 3.6 – la vue Writepin
[pagecommand.html] la vue Command : cette vue permet `a l’utilisateur d’envoyer une
commande JSON, en s´electionnant un ou plusieurs Arduino et en saisissant une commande
sous forme de chaine JSON.
19

Figure 3.7 – la vue Command
[pagemesarduinos.html] la vue MyArduinos : cette vue permet à l’utilisateur d’avoir une
simple liste des Arduino connectés.
Figure 3.8 – la vue MyArduinos
3.3 Design : Bootstrap
Twitter Bootstrap est une collection d’outils utile à la création de sites et d’applications
web. C’est un ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils
de navigation et autres éléments interactifs, ainsi que des extensions JavaScript en option.
20

C’est un projet très populaire sur la plate-forme de gestion de développement GitHub, ce qui
nous a permis de profiter d’une part de l’aide de la communauté, et d’autre part des nombreuses
fonctionnalités développées par ses membres.
Les éléments HTML sont stylisés grâce à un système de classes extensibles.
Exemple :
1 <div class="alert alert -success" role="alert">...</div>
Figure 3.9 – message d’information
1 <form class="navbar -form navbar -left" role="search">
2 <div class="form -group">
3 <input type="text" class="form -control" placeholder="Search">
4 </div>
5 <button type="submit" class="btn btn -default">Submit </button >
6 </form >
Figure 3.10 – barre de navigation
3.4 Version mobile avec PhoneGap
PhoneGap est un framework open source pour créer des applications mobiles multi-plateforme
avec les technologies traditionnelles du web : HTML, CSS, JavaScript. Les applications mobiles
créées à l’aide des technologies web sont appelées applications hybrides c’est à dire mélangeant
web et technologies natives. Le code HTML, CSS et JavaScript reste tel quel et l’application
PhoneGap utilise le navigateur web de l’appareil (webview) pour l’interpréter.
Après quelques modifications du code source et quelques minutes d’attente, PhoneGap nous
génère un fichier applicatif Android (.apk).
Voici un aper¸cu de la version mobile :
21

L’utilisation de PhoneGap n’est pas une solution adaptée à tous les types d’applications
mobiles mais convient parfaitement aux applications simples dont le coût d’un développement
natif est prohibitif.
3.5 Difficultés rencontrées
Lors de développement du client AngularJS, nous avons rencontrés quelques difficultés et
notamment :
La gestion des vues et de leur modèle : Outre l’organisation de l’application selon les
standards de programmation AngularJS, il nous a fallu analyser l’enchainement des évènements.
En effet, certains composants comme l’UI Grid ne mettent à jour leurs données qu’une seule
fois au chargement du modèle de la vue. Il est donc nécessaire de leur attribuer leurs données
à ce moment-là.
L’utilisation d’une librairie en version bêta : UI Grid est un tableau AngularJs permet-
tant de manipuler, de trier et de filtrer des données. Nous l’avons utilisé pour lister les Arduino
disponibles. Au cours du développement, ce composant a été mise à jour dans une nouvelle
version bêta. L’implémentation de ce composant s’est avéré être délicate étant donné la taille
restreinte de la communauté de bêta-testeurs.
L’utilisation de variables externes dans la méthode http : Afin d’afficher le nom de
l’Arduino concerné par la réponse du serveur après une requête http, nous avons exploité les
paramètres de la méthode http. Pour utiliser des données du modèle dans la fonction exécutée
lors de l’évènement .success de la méthode http, nous avons dû passer en paramètre les données
voulues, sans passer par le paramètre URL :
22

1 $http ({ method: ’GET ’, maDonn´ee: $scope.maDonn´ee , url: h t t p :// mon.url ’})
2 .success(function (thisdata , status , headers , config) {}
23

Chapitre 4
Client ASP.NET
4.1 Implémentation du MVC avec ASP.NET
ASP.NET est une technologie de développement web créée par Microsoft, et qui permet
de concevoir des applications web. Puisque nous avons décidé de développer nos clients avec
une structure MVC, nous allons donc employer la version ASP.NET MVC. Le langage choisi
pour développer la logique de l’application est le C#. Les vues sont quant à elles au format
CSHTML, qui est un des moteurs de rendu HTML utilisé par ASP.NET. Plusieurs scripts
en JavaScript sont également présents afin de rendre l’application dynamique, et notamment
pour gérer l’aspect asynchrone des interactions avec le serveur (requêtes et réponses AJAX).
La structure générale de l’application est schématisée dans le diagramme ci-dessous. Elle est
détaillée par la suite.
Figure 4.1 – La structure de l’application ASP.NET MVC
4.1.1 La partie présentation
Tous les fichiers correspondant à l’interface graphique de l’application, autrement dit les
vues, sont regroupés dans le dossier ”Views”. Ce dernier est constitué de 6 sous-dossiers : 5
24

pour les 5 ”pages” de l’application, et portant le nom de l’action associée, ainsi qu’un autre
appelé ”Shared”. Dans ce dossier on trouve un fichier commun à toutes les vues. ” Layout”, est
comme son nom l’indique, chargé de l’agencement général de la page affichée par le navigateur.
C’est en effet dans ce fichier que sont gérés les imports des différents scripts nécessaires au bon
fonctionnement de l’application, ainsi que des feuilles de styles servant à paramétrer l’apparence
visuelle du programme. Le contenu des vues est encapsulé dans le layout grâce à la balise
@RenderBody(). Le layout contient également le menu de l’interface, qui consiste en une barre
de quatre boutons renvoyant vers chacune des actions possibles.
Pour chacune des autres vues, 3 fichiers sont présents : Index.cshtml qui est chargé par le
contrôleur et qui encapsule le reste de la vue. [nom de l’action].cshtml correspond au code
du formulaire de l’action et enfin Reponse.cshtml contient le code de la <div> permettant
d’afficher la réponse du serveur.
4.1.2 Le back-office
En plus des contrôleurs et des modèles, facilement identifiables car ils portent le nom de
l’action associée, il faut noter l’importance de deux fichiers. Le script ASPDuino.js contient
toutes les fonctions permettant les appels asynchrones vers les contrôleurs. Le fichier Dao.cs
contient quant à lui toutes les fonction effectuant les requêtes HTTP vers le serveur. Ce sont
ces fonctions qui sont appelées par les différents contrôleurs.
4.2 Les vues de l’application
Techniquement, ce client domotique est composé de 5 vues : une pour chaque formulaire
indiqué dans le cahier des charges. La gestion des vues étant similaire d’une action à l’autre,
seule la première sera complètement détaillée, les autres étant décrites brièvement par la suite.
4.2.1 La page d’accueil
Au lancement de l’application, l’utilisateur se retrouve devant la page suivante :
Figure 4.2 – La page d’accueil
Cette page comporte un formulaire qui se résume à un unique champ de texte permettant
à l’utilisateur de rentrer l’adresse IP du serveur sur lequel sont connectées les cartes Arduino.
Ce formulaire correspond à la vue ”ArduinosList.cshtml” dont le code est visible ci-dessous :
1 @model client_v0.Models.ConfigModel
2
25

3 @{
4 Layout = null;
5 AjaxOptions ajaxOpts = new AjaxOptions
6 {
7 UpdateTargetId = "reponse",
8 HttpMethod = "post",
9 Url = Url.Action("GetArduinos"),
10 };
11 }
12
13 @using (Ajax.BeginForm("GetArduinos", null , ajaxOpts , new { id = "formulaire
" }))
14 {
15 <br />
16 
17 <table >
18 <tr>
19 <td>@Html.LabelFor(m => m.ipServer , new { @class = "col -lg -12
control -label" })</td>
20 <td>
21 <div class="form -group">
22 @Html.TextBoxFor(m => m.ipServer , new { @class = "form -
control floating -label", id = "focusedInput", type = "text", placeholder
= "Please enter the server IP" })
23 </div>
24 </td>
25 <td><span class="text -danger">@Html. ValidationMessageFor (m => m.
ipServer)</span ></td>
26 </tr>
27 </table >
28 <p>
29 <input class="btn btn -primary btn -raised" type="submit" value="
Valider" id="btn_valider" />
30 </p>
31
32 
33 <div id="reponse" />
34 }
Ce qu’il faut retenir de ce code, c’est que le formulaire est en fait composé d’un tableau (l17
à l27) d’une ligne de trois cases. La première case contient le label du champ (l19), la deuxième
le textbox(l22) et la dernière un message d’erreur qui s’affiche si la validation du texte tapé
échoue (l25). On remarque que ces trois champs font appel au paramètre m.ipServer, qui fait
référence à la propriété ”ipServer” du modèle associé. Ce modèle est déclaré l1, il s’agit de
”ConfigModel” (chaque vue dispose de son propre modèle). Regardons maintenant le code de
ce modèle :
1 namespace client_v0.Models
2 {
3 public class ConfigModel : IValidatableObject
4 {
5 // valeurs postées
6 [Display(Name = "IP du Serveur : ")]
7 [Required(ErrorMessage = "Information requise")]
8 [ RegularExpression (@"^(25[0 -5]|2[0 -4][0 -9]|[01]?[0 -9][0 -9]?)
.(25[0 -5]|2[0 -4][0 -9]|[01]?[0 -9][0 -9]?)
.(25[0 -5]|2[0 -4][0 -9]|[01]?[0 -9][0 -9]?)
.(25[0 -5]|2[0 -4][0 -9]|[01]?[0 -9][0 -9]?)$", ErrorMessage = "Information
26

incorrecte")]
9 public String ipServer { get; set; }
10
11 public String json { get; set; }
12
13 public IEnumerable <ValidationResult > Validate( ValidationContext
validationContext )
14 {
15 List <ValidationResult > résultats = new List <ValidationResult >();
16 // on rend la liste des erreurs
17 return résultats;
18 }
19 }
20 }
On retrouve l9 la déclaration de la propriété ipServer. Cette déclaration est précédée de trois
attributs :
– Display (l6) indique le texte du label affiché à coté du textbox.
– Required (l7) donne un message d’erreur à afficher si on valide le formulaire sans rien
avoir entré.
– RegularExpression (l8) donne un autre message d’erreur si le texte tapé n’est pas conforme
à l’expression régulière indiquée (dans ce cas il s’agit du regex d’une adresse IP).
On obtient donc déjà les deux comportements suivant de la page en cas de saisie incorrecte :
Figure 4.3 – Aucune donnée entrée
Figure 4.4 – Chaine rentrée non conforme au format d’une adresse IP
Maintenant regardons ce qui se passe dans le cas normal, où l’adresse IP donnée est correcte.
La validation du formulaire va déclencher l’action ”GetArduinos” du contrôleur, reproduite ci-
dessous :
1 [HttpPost]
2 public PartialViewResult GetArduinos(ConfigModel model , FormCollection
postedData , ApplicationModel applicationData )
3 {
27

4 // mise à jour du modèle
5 TryUpdateModel(model , postedData);
6
7 Dao.Dao dao = new Dao.Dao();
8 dao.getArduinos(model , applicationData );
9
10 return PartialView("Reponse", model);
11 }
Après avoir mis à jour la valeur de ipServer dans le modèle à partir de la chaine entrée dans
la vue (l5), on fait un appel à la couche DAO en lui passant les données du modèle ainsi que
les données de portée Application (l8). On retourne ensuite le fragment de vue ”Reponse” ainsi
que le modèle associé (l10). Ce fragment est visible ci-dessous :
1 @model client_v0.Models.ConfigModel
2
3 <div class="panel panel -primary">
4 <div class="panel -heading">Réponse du serveur </div >
5 <div class="panel -body">
6 @Model.json
7 </div >
8 </div >
On voit l6 la présence de @Model.json, qui contient maintenant la réponse du serveur. C’est
la classe DAO qui s’est chargée de cet enregistrement, comme on peut le voir en observant son
code :
1 public void getArduinos(ConfigModel model , ApplicationModel applicationData)
2 {
3 // on récupère les infos du modèle
4 string ipServer = model.ipServer;
5
6 //on enregistre l’ip dans l’application
7 applicationData .ipServer = ipServer;
8
9 // création d’un WebClient
10 WebClient webClient = new WebClient ();
11 // on précise qu ’on va envoyer du Json
12 webClient.Headers.Add("Content -Type", "application/json");
13 // l’URL
14 string uriString = "http ://" + ipServer + ":8080/ arduinos/";
15 string réponse = string.Empty;
16 try
17 {
18 // on envoie la requête et on lit la réponse
19 réponse = webClient.DownloadString(uriString);
20 model.json = réponse;
21 applicationData.json = réponse;
22 }
23 catch (WebException ex)
24 {
25 model.json = "Error : " + ex.Message;
26 }
27 }
28

En effet, après avoir récupéré l’adresse IP donnée par l’utilisateur (l4), on l’enregistre dans
l’application (l7) afin de pouvoir y accéder depuis les autres vues. Ensuite on construit la
requête HTTP (l14), puis on l’envoie au serveur (l19). On peut maintenant enregistrer la réponse
obtenue dans le modèle (l20). Dans ce cas particulier on copie également cette réponse dans
l’application (l21) car elle contient la liste des cartes Arduino qui sera proposée dans les autres
vues. Ce ne sera pas le cas pour les réponses re¸cues dans les autres vues.
À la suite de ces différentes étapes, la page affiche maintenant la réponse du serveur :
Figure 4.5 – La réponse du serveur est apparue
4.2.2 Lecture de l’état d’une pin
Figure 4.6 – Lecture de l’état d’une pin
29

Cette page permet à l’utilisateur de connaitre la valeur actuelle de n’importe quelle pin de
chaque carte connectée. Il sélectionne pour cela la ou les cartes désirées dans la liste, ensuite
il choisi le numéro de pin qui l’intéresse dans la liste déroulante, et enfin il précise le mode de
lecture. En pratique, le mode analogique sera utile si le composant branché sur la pin renvoie une
valeur proportionnelle à son état, par exemple une sonde de température ou un potentiomètre.
Le mode binaire est quand à lui dédié au composants bistables, comme un interrupteur par
exemple. On remarque que la réponse du serveur est composée de plusieurs données, celle qui
nous intéresse ici est la dernière : ”pin0 :317”indique que la valeur de la pin n˚0 est actuellement
317 (sur 1023).
4.2.3 Écriture sur une pin
Figure 4.7 – Écriture sur une pin
Ce formulaire est presque identique au précédent, à ceci près qu’ici l’utilisateur spécifie la
valeur qu’il souhaite écrire sur la pin des cartes sélectionnées. Dans cet exemple, si une LED
est branchée entre la pin GND et la pin 8, l’envoi de cette commande aura pour effet de
l’allumer. On peut noter que si la valeur spécifiée n’est pas conforme (par exemple une valeur
binaire différente de 0 ou 1), la requête sera bien traitée par le serveur mais celui-ci renverra
un message d’erreur dans sa réponse (voir ci-dessous).
30

Figure 4.8 – Erreur de saisie indiquée par le serveur
4.2.4 Clignotement d’une LED
Figure 4.9 – Clignotement d’une LED
Cette action suppose qu’une LED est présente sur la pin spécifiée. Elle va alors clignoter
autant de fois qu’indiqué dans ”Number” et avec l’intervalle donné pour ”Duration”. Dans
cet exemple elle va donc s’allumer brièvement 10 fois, avec un délai de 100ms entre chaque
impulsion. Ici, la réponse du serveur sert juste à indiquer qu’aucune erreur ne s’est produite
lors de l’exécution de la commande.
31

4.2.5 Envoi d’une commande au format JSON
Figure 4.10 – Envoi d’une commande au format JSON
Ce dernier formulaire donne la possibilité à l’utilisateur d’envoyer la commande de son choix
au format JSON, comme indiqué dans le cahier des charges. La syntaxe de ces commandes
n’étant pas évidente, un clic sur le bouton ”Need Help ?” affiche un exemple de commande
valide (en l’occurrence pour faire clignoter une LED sur la pin 8 dix fois toutes les 100ms).
4.3 Design : Bootstrap + thème Material Design
Au cours du développement de ce client, nous avions conservé l’apparence de base fournie
par Visual Studio pour une une application ASP.NET. Or cette dernière s’avère assez austère
et très figée.
Figure 4.11 – L’apparence de départ
Afin de tirer pleinement partie des possibilités offertes par Bootstrap (un framework CSS
responsive créé par Twitter et très répandu), nous avons décidé de lui ajouter un thème donnant
aux éléments de l’interface un style ”Material Design”. Material Design est le nom de la charte
graphique que Google a récemment mis en place afin d’uniformiser l’apparence des applications
accompagnant la dernière version de son système d’exploitation mobile, Android. Ses points
forts sont une bonne visibilité des contrôles grâce à des couleurs vives, ainsi que de nombreuses
animations très fluides qui visent à améliorer l’expérience utilisateur.
32

Dans la pratique, pour appliquer ce thème il suffit d’ajouter les classes CSS que l’on souhaite
aux éléments HTML afin de changer leur apparence. Ainsi par exemple le code suivant permet
d’appliquer le style au bouton de validation d’un formulaire :
1 <input class="btn btn -primary btn -raised" type="submit" value="Valider" id="
btn_valider" />
Là où les choses se compliquent un peu, c’est lorsque l’on souhaite appliquer une classe CSS
à un élément qui n’est pas codé en dur, comme c’est le cas pour les éléments générés à partir des
données d’un modèle. Au final la solution est très simple : il suffit d’ajouter comme paramètre
new { @class = ”nom de la classe” } lors de la déclaration d’un élément de formulaire. Ci-dessus
un exemple avec une liste déroulante :
1 @Html.DropDownListFor(m => m.DropDownListField , new SelectList(@Model.
DropDownListFieldItems , "Value", "Label"), new { @class = "form -control"
})
4.4 Difficultés rencontrées
Le développement de ce client n’a globalement pas posé de problèmes. Au final, le dernier
point resté sans solution concerne la manipulation du JavaScript gérant la visibilité des éléments
d’une vue via un contrôleur. Ce problème s’est présenté lorsqu’il a été question de masquer le
menu de l’application lorsque l’adresse IP n’avait pas été validée. Deux approches on été tentées :
communication entre le code ASP.NET et le JavaScript au moyen de variables globales ; et
solution orientée vue, en réagissant à certains évènements (apparition de la <div> contenant
la réponse du serveur par exemple). Malheureusement aucune méthode satisfaisante n’a été
trouvée, ce qui peut donc causer des erreurs si l’utilisateur clique sur un des boutons du menu
avant d’avoir enregistré l’IP du serveur.
33

Chapitre 5
Gestion de projet
5.1 Gantt
34

5.2 Diagrammes de répartition du temps par tâches
5.3 Méthodes de travail
L’application AngularJS :
Afin de découvrir le monde d’AngularJS et d’en comprendre les ficelles, nous avons dans
un premier temps suivi les tutoriaux présents sur le site AngularJS https://angularjs.org/
(The Basics, Add Some Control,)
Lorsqu’il a fallu structurer l’application suivant le modèle MVC, nous avons suivi la trame
du TP AngularJS de Serge Tahé http://tahe.developpez.com/angularjs-spring4/ afin de
comprendre les interactions entre les différents éléments.
Quant aux composants AngularJS, la plupart disposent d’un site dédié avec des exemples
d’application.
Client ASP.NET :
La construction du projet à été faite en suivant le cours ASP.NET de M.TAHE. Les quelques
détails qui n’étaient pas vus dans ce cours (création d’une requête HTTP, sérialisation d’une
chaine JSON, etc) se trouvent facilement dans la documentation en ligne de Microsoft, ainsi
que sur des forums d’entraide comme Stack Overflow. Globalement, la progression s’est faite
dans cet ordre : création d’une première vue simplifiée, puis création des autres vues sur le
même modèle, puis amélioration de la première vue, et enfin répercussion de ces améliorations
sur le reste de l’application.
35

Chapitre 6
Conclusion
À la fin du projet, les deux clients ont été terminés et sont complètement fonctionnels.
On peut en fait parler de trois clients, puisque grâce à PhoneGap nous avons pu créer une
application native Android directement à partir des sources du client web AngularJS, qui a été
testé avec succès sur une tablette communiquant avec le serveur via un réseau wifi local.
6.1 Apports professionnels
Ce projet a été l’occasion d’approfondir nos connaissances en programmation web. En effet,
le client AngularJS nous a permis de découvrir ce framework JavaScript MVC très puissant,
qui est de plus très apprécié dans les Entreprises de Services Numériques, comme en témoigne
l’intérêt des recruteurs rencontrés lors de la Journée des Métiers. C’est un véritable bénéfice
car AngularJS n’est pas enseigné dans le tronc commun de l’ISTIA et constitue donc un plus
sur le CV. En ce qui concerne le client ASP.NET, cela a été l’opportunité de renforcer les
connaissances vues en TD, tout en explorant la notion de communication par requêtes HTTP,
différent des appels vers une base de données vus en cours.
6.2 Apports personnels
Sur le plan personnel, ce projet nous a permis de saisir l’étendue des possibilités offertes par
les technologies du domaine du développement web, et de découvrir les interactions entre une
application web et du matériel électronique connecté. À l’heure où l’on parle de plus en plus
de l’Internet des objets, ce que nous avons vu au cours de ce projet nous a semblé tout à fait
pertinent en plus d’être un excellent moyen de se former à ces technologies d’avenir.
6.3 Pistes d’amélioration
On peut imaginer des améliorations sur 2 plans :
Côté client, on pourrait par exemple ajouter une fonction de planification et de gestion de
tâches. L’utilisateur pourrait ainsi créer des tâches qui seraient exécutées à certains moments
de la journée.
Coté serveur, on pourrait ajouter des fonctions sur le modèle de l’action Blink, adaptées à
des capteurs ou actionneurs particuliers. On pourrait notamment exploiter les sorties digitales
PWM pour contrôler des moteurs.
36

Chapitre 7
Annexes
7.1 Guide utilisateur
Étape 1 : Dans le panneau de configuration, cliquer sur « Centre Réseau et partage ».
Étape 2 : Puis sur la gauche, « Modifier les paramètres de la carte ».
Étape 3 : Choisir la carte réseau de l’ordinateur, clic droit, puis « Propriétés ».
Étape 4 : Cliquer sur le protocole IPV4, puis « Propriétés ».
Étape 5 : Renseigner les paramètres d’IP présents sur l’image.
Étape 6 : Démarrer le serveur en exécutant le fichier server.bat
Étape 7 : Une fenêtre de commande s’ouvre, attendre que le serveur soit lancé.
Étape 8a : Pour lancer le client AngularJS, ouvrir Webstorm puis cliquer sur « Open Directory »
Étape 9a : Choisir le fichier de projet « Client Domotique AngularJS »
Étape 10a : Dans l’architecture du projet, clic droit sur « home.html »
Étape 11a : Cliquer sur « Open in Browser » puis choisir un navigateur web.
Étape 8b : Pour lancer le client ASP.NET, ouvrir Visual Studio. Dans le menu « Fichier »,
cliquer sur « Ouvrir une solution/projet » et choisir le fichier de projet « Client Domotique
ASP.NET ».
Étape 9b : Voici l’architecture du projet. Un simple « Ctrl+F5 » exécutera le projet.
37

7.2 Intégration du thème Bootstrap Material Design
Cette annexe détaille la procédure à suivre afin de rajouter le thème Material Design au
projet Visual Studio. Ce thème nécessite que Bootstrap soit déjà présent dans l’application,
ce qui est le cas lorsque l’on crée un nouveau projet ASP.NET MVC. Ensuite, il faut ra-
jouter ceux correspondant au thème. L’archive récupérée sur le Github du thème (https:
//github.com/FezVrasta/bootstrap-material-design) contient de nombreux fichiers, mais
seul quelques uns sont vraiment nécessaires. Il s’agit des fichiers JavaScript material.min.js
et ripples.min.js présents dans dist/js, ainsi que des fichiers CSS material.min.css,
material-wfont.min.css et ripples.min.css trouvés dans dist/css. Il faut ensuite copier
ces fichiers dans les dossiers Content et Scripts de l’application, afin d’obtenir l’arborescence
visible ci-dessous :
Figure 7.1 – Le contenu des dossiers Content et Scripts
Il faut ensuite ajouter les lignes suivantes dans le fichier BundleConfig.cs :
1 bundles.Add(new ScriptBundle("~/ bundles/bootstrap").Include(
2 "~/ Scripts/bootstrap.js",
3 "~/ Scripts/material.min.js",
4 "~/ Scripts/ripples.min.js"));
5
6 bundles.Add(new StyleBundle("~/ Content/css").Include(
7 "~/ Content/bootstrap.css",
8 "~/ Content/site.css",
9 "~/ Content/bootstrap -responsive.css",
10 "~/ Content/material.min.css",
11 "~/ Content/ripples.min.css",
12 "~/ Content/material -wfont.min.css"));
39

Puis dans _Layout.cshtml, on importe les scripts dans le <head> :
1 <script type="text/javascript" src="~/ Scripts/material.min.js" ></script >
2 <script type="text/javascript" src="~/ Scripts/ripples.min.js" ></script >
Pour ﬁnir, toujours dans _Layout.cshtml, on ins`ere les lignes suivantes juste avant la balise
</body> :
1 @Scripts.Render("~/ bundles/jquery")
2 @Scripts.Render("~/ bundles/bootstrap")
3 @RenderSection("scripts", required: false)
40

Chapitre 8
Bibliographie
Tutoriaux et composants AngularJS : http://getbootstrap.com/
Tutoriel AngularJS / Spring 4 : http://tahe.developpez.com/angularjs-spring4/
Site Bootstrap : http://getbootstrap.com/
Introduction PhoneGap : http://www.alsacreations.com/tuto/lire/1646-introduction-
phonegap.html
Site PhoneGap : http://phonegap.com/
Th`eme Bootstrap Material Design : https://fezvrasta.github.io/bootstrap-material-
design/
Composant UI Grid : http://ui-grid.info/
Composant n3-line-chart : http://n3-charts.github.io/line-chart/#/
41

Projet réalisé par : Nicolas ROULLEAU et Adrien LIOTARD
Projet encadré par : Serge TAHE
Résumé
Ce rapport relate le développement de deux interfaces web destinées au contrôle d’un
système domotique fabriqué sur mesure : le premier écrit en Javascript avec le framework
AngularJS, le second utilisant Microsoft ASP.NET MVC. Pour nos tests de développement,
ce système était composé de deux cartes Arduino (des cartes électroniques polyvalentes et
bon marché utilisées par les bricoleurs) pourvues de DEL et de capteurs de température. Ces
cartes sont raccordées aux interfaces à travers un réseau local, dans lequel un ordinateur joue
le rôle du serveur qui re¸coit les commandes de l’utilisateur depuis un client, les envoie aux
cartes Arduino puis renvoie les informations vers l’interface. Les commandes suivantes on été
intégrées : lire/écrire une valeur sur une des pins d’un Arduino, faire clignoter une DEL avec
un nombre de pulsations et un intervalle donné, et envoyer des commandes au format JSON.
Comme ces fonctions on été testées avec succès, le système peut maintenant être amélioré pour
être utilisé comme un vrai système domotique.
Mots clés : interfaces web, domotique, cartes Arduino, réseau local, serveur
Abstract
This paper reports the development of two web interfaces aimed at the control of a custom
built home automation system : the first using JavaScript and the AngularJS framework, the
second using Microsoft ASP.NET MVC. For our development tests, this system was composed
of two Arduino boards (versatile and cheap electronic board used by hobbyists) with LED
and temperature sensors plugged on them. These electronic boards were linked to our inter-
faces through a local network, where one computer acts as a server which receive the user
commands from the client, send them to the Arduino and then send back some information
to the interface. The following commands were implemented : read/write a value on one of
the Arduino’s pins, make a LED blinks with a given number of pulses and interval, and send
commands in JSON format. As these functions were successfully tested, the system can now be
further improved to be used as an actual home automation monitoring system.
Key words : web interface, home automation, Arduino board, local network, server
42

Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau

Ähnlich wie Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau (20)

Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau