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

P4 IOT 2018

2019-01-24T13:35:34Z

Ael-mess : /* Amélioration si plus temps */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

Pour alimenter le device, nous avons ajouter à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter le leds, plus un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds, et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finaliser le programme de la Raspberry et installer les librairies qui permettent d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est crée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en Entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initial et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parser en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoie et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieurs à 99 secondes en minutes et celle inférieurs à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.

- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-24T13:35:12Z

Ael-mess : /* Séance 5 */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

Pour alimenter le device, nous avons ajouter à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter le leds, plus un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds, et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finaliser le programme de la Raspberry et installer les librairies qui permettent d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est crée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en Entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initial et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parser en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoie et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieurs à 99 secondes en minutes et celle inférieurs à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.
- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-24T13:34:49Z

Ael-mess :

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

Pour alimenter le device, nous avons ajouter à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter le leds, plus un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds, et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finaliser le programme de la Raspberry et installer les librairies qui permettent d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est crée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en Entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initial et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parser en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoie et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieurs à 99 secondes en minutes et celle inférieurs à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

====Séance 6====

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.
- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

====Flyer====
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-24T12:55:40Z

Ael-mess : /* Flyer */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

Pour alimenter le device, nous avons ajouter à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter le leds, plus un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds, et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Flyer===
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-24T12:54:58Z

Ael-mess : /* Structuration du projet */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

Pour alimenter le device, nous avons ajouter à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter le leds, plus un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds, et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Flyer===
<div style="
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-24T12:52:05Z

Ael-mess : /* Séance 2 */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

Pour alimenter le device, nous avons ajouter à notre liste de matériel un transformateur

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Flyer===
<div style="
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-24T12:50:36Z

Ael-mess : /* Séance 3 */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Flyer===
<div style="
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-24T12:42:56Z

Ael-mess : /* Carte électronique */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Flyer===
<div style="
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-24T12:37:02Z

Ael-mess : /* Structuration du projet */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmer à travers elle.

==Séance 3==

===Carte électronique===

Après avoir bien avancé sur la carte, nous nous sommes rendu compte que les afficheurs utilisés étaient à cathode commune. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des multiplexeurs. Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Flyer===
<div style="
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-21T10:14:29Z

Ael-mess : /* Séance 2 */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds que nous contrôlerons avec 3 GPIO de la Raspberry

==Séance 3==

===Carte électronique===

Après avoir bien avancé sur la carte, nous nous sommes rendu compte que les afficheurs utilisés étaient à cathode commune. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des multiplexeurs. Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

P4 IOT 2018

2019-01-21T10:07:09Z

Ael-mess : /* Recherche d'un sujet et clarification du cahier des charges */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous avons passé du temps lors de cette séance à trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds

==Séance 3==

===Carte électronique===

Après avoir bien avancé sur la carte, nous nous sommes rendu compte que les afficheurs utilisés étaient à cathode commune. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des multiplexeurs. Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

P4 IOT 2018

2019-01-21T08:44:03Z

Ael-mess : /* Séance 2 */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous avons passé du temps lors de cette séance à trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds

==Séance 3==

===Carte électronique===

Après avoir bien avancé sur la carte, nous nous sommes rendu compte que les afficheurs utilisés étaient à cathode commune. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des multiplexeurs. Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

P4 IOT 2018

2019-01-21T08:38:55Z

Ael-mess : /* Recherche d'un sujet et clarification du cahier des charges */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous avons passé du temps lors de cette séance à trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

==Séance 3==

===Carte électronique===

Après avoir bien avancé sur la carte, nous nous sommes rendu compte que les afficheurs utilisés étaient à cathode commune. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des multiplexeurs. Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

Option Internet des objets 2018/2019

2019-01-07T17:20:27Z

Ael-mess : /* Matériel à acquérir */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Poubelle connectée]] || Raphael Morin, Brahim Ahammou
|-
| [[Cadenas connecté|Cadenas connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Rideau connecté]] || Lijie YAO, Ji YANG
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018| Noeud papillon connecté]] || Moustafa THIAM, Nicolas HAVARD
|-
| [[P6_IOT_2018|Localisation pour Malvoyant ]] || Quentin Hochart, Baptiste Cartier
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

= Matériel à acquérir =

{| class="wikitable"
! Projet !! Matériel
|-
| [[P4_IOT_2018|Timer connecté]]
|
* 2*TLC5947 (disponible).
* Raspberry pi 3 (disponible).
* [https://www.mouser.fr/ProductDetail/Hammond-Manufacturing/229D12?qs=sGAEpiMZZMumryolnogYRpD5mAKdvhRQ 229D12 transformateur].
* [https://www.mouser.fr/ProductDetail/STMicroelectronics/L78S05CV?qs=%2fha2pyFaduiWO8JtUWKMAZnjtu7hdXWcILElZCfVsnk%3d L78S05CV regulateur].
|-
|}

Option Internet des objets 2018/2019

2019-01-07T17:20:05Z

Ael-mess : /* Matériel à acquérir */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Poubelle connectée]] || Raphael Morin, Brahim Ahammou
|-
| [[Cadenas connecté|Cadenas connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Rideau connecté]] || Lijie YAO, Ji YANG
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018| Noeud papillon connecté]] || Moustafa THIAM, Nicolas HAVARD
|-
| [[P6_IOT_2018|Localisation pour Malvoyant ]] || Quentin Hochart, Baptiste Cartier
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

= Matériel à acquérir =

{| class="wikitable"
! Projet !! Matériel
|-
| [[P4_IOT_2018|Timer connecté]]
|
* 2*TLC5947 (disponible).
* Raspberry pi 3 (disponible).
* [[https://www.mouser.fr/ProductDetail/Hammond-Manufacturing/229D12?qs=sGAEpiMZZMumryolnogYRpD5mAKdvhRQ 229D12 transformateur]].
* [[https://www.mouser.fr/ProductDetail/STMicroelectronics/L78S05CV?qs=%2fha2pyFaduiWO8JtUWKMAZnjtu7hdXWcILElZCfVsnk%3d L78S05CV regulateur]].
|-
|}

Option Internet des objets 2018/2019

2019-01-07T17:19:44Z

Ael-mess : /* Matériel à acquérir */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Poubelle connectée]] || Raphael Morin, Brahim Ahammou
|-
| [[Cadenas connecté|Cadenas connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Rideau connecté]] || Lijie YAO, Ji YANG
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018| Noeud papillon connecté]] || Moustafa THIAM, Nicolas HAVARD
|-
| [[P6_IOT_2018|Localisation pour Malvoyant ]] || Quentin Hochart, Baptiste Cartier
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

= Matériel à acquérir =

{| class="wikitable"
! Projet !! Matériel
|-
| [[P4_IOT_2018|Timer connecté]]
|
* 2*TLC5947 (disponible).
* Raspberry pi 3 (disponible).
* [[https://www.mouser.fr/ProductDetail/Hammond-Manufacturing/229D12?qs=sGAEpiMZZMumryolnogYRpD5mAKdvhRQ|229D12 transformateur]].
* [[https://www.mouser.fr/ProductDetail/STMicroelectronics/L78S05CV?qs=%2fha2pyFaduiWO8JtUWKMAZnjtu7hdXWcILElZCfVsnk%3d|L78S05CV regulateur]].
|-
|}

Option Internet des objets 2018/2019

2019-01-07T17:19:07Z

Ael-mess : /* Matériel à acquérir */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Poubelle connectée]] || Raphael Morin, Brahim Ahammou
|-
| [[Cadenas connecté|Cadenas connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Rideau connecté]] || Lijie YAO, Ji YANG
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018| Noeud papillon connecté]] || Moustafa THIAM, Nicolas HAVARD
|-
| [[P6_IOT_2018|Localisation pour Malvoyant ]] || Quentin Hochart, Baptiste Cartier
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

= Matériel à acquérir =

{| class="wikitable"
! Projet !! Matériel
|-
| [[P4_IOT_2018|Timer connecté]]
|
* 2*TLC5947 (disponible).
* Raspberry pi 3 (disponible).
* [[229D12 transformateur|https://www.mouser.fr/ProductDetail/Hammond-Manufacturing/229D12?qs=sGAEpiMZZMumryolnogYRpD5mAKdvhRQ]].
* [[L78S05CV regulateur|https://www.mouser.fr/ProductDetail/STMicroelectronics/L78S05CV?qs=%2fha2pyFaduiWO8JtUWKMAZnjtu7hdXWcILElZCfVsnk%3d]].
|-
|}

Option Internet des objets 2018/2019

2019-01-07T17:18:26Z

Ael-mess : /* Matériel à acquérir */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Poubelle connectée]] || Raphael Morin, Brahim Ahammou
|-
| [[Cadenas connecté|Cadenas connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Rideau connecté]] || Lijie YAO, Ji YANG
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018| Noeud papillon connecté]] || Moustafa THIAM, Nicolas HAVARD
|-
| [[P6_IOT_2018|Localisation pour Malvoyant ]] || Quentin Hochart, Baptiste Cartier
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

= Matériel à acquérir =

{| class="wikitable"
! Projet !! Matériel
|-
| [[P4_IOT_2018|Timer connecté]]
|
* 2*TLC5947 (disponible)
* Raspberry pi 3 (disponible)
* [229D12 transformateur | https://www.mouser.fr/ProductDetail/Hammond-Manufacturing/229D12?qs=sGAEpiMZZMumryolnogYRpD5mAKdvhRQ]
* [L78S05CV regulateur | https://www.mouser.fr/ProductDetail/STMicroelectronics/L78S05CV?qs=%2fha2pyFaduiWO8JtUWKMAZnjtu7hdXWcILElZCfVsnk%3d]
|-
|}

Option Internet des objets 2018/2019

2019-01-07T17:18:07Z

Ael-mess : /* Matériel à acquérir */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Poubelle connectée]] || Raphael Morin, Brahim Ahammou
|-
| [[Cadenas connecté|Cadenas connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Rideau connecté]] || Lijie YAO, Ji YANG
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018| Noeud papillon connecté]] || Moustafa THIAM, Nicolas HAVARD
|-
| [[P6_IOT_2018|Localisation pour Malvoyant ]] || Quentin Hochart, Baptiste Cartier
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

= Matériel à acquérir =

{| class="wikitable"
! Projet !! Matériel
|-
| [[P4_IOT_2018|Timer connecté]]
|
* 2*TLC5947 (disponible)
* Raspberry pi 3 (disponible)
* [229D12 transformateur|https://www.mouser.fr/ProductDetail/Hammond-Manufacturing/229D12?qs=sGAEpiMZZMumryolnogYRpD5mAKdvhRQ]
* [L78S05CV regulateur|https://www.mouser.fr/ProductDetail/STMicroelectronics/L78S05CV?qs=%2fha2pyFaduiWO8JtUWKMAZnjtu7hdXWcILElZCfVsnk%3d]
|-
|}

Option Internet des objets 2018/2019

2019-01-07T17:17:53Z

Ael-mess : /* Répartition des binômes */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Poubelle connectée]] || Raphael Morin, Brahim Ahammou
|-
| [[Cadenas connecté|Cadenas connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Rideau connecté]] || Lijie YAO, Ji YANG
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018| Noeud papillon connecté]] || Moustafa THIAM, Nicolas HAVARD
|-
| [[P6_IOT_2018|Localisation pour Malvoyant ]] || Quentin Hochart, Baptiste Cartier
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

= Matériel à acquérir =

{| class="wikitable"
! Projet !! Matériel
|-
| [[P4_IOT_2018|Timer connecté]]
|
* 2*TLC5947 (disponible)
* Raspberry pi 3 (disponible)
* [229D12 transformateur| https://www.mouser.fr/ProductDetail/Hammond-Manufacturing/229D12?qs=sGAEpiMZZMumryolnogYRpD5mAKdvhRQ]
* [L78S05CV regulateur| https://www.mouser.fr/ProductDetail/STMicroelectronics/L78S05CV?qs=%2fha2pyFaduiWO8JtUWKMAZnjtu7hdXWcILElZCfVsnk%3d]
|-
|}

TP sysres IMA5sc 2018/2019

2018-12-02T19:32:47Z

Ael-mess : /* Plan d'adressage */

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA5sc 2018/2019 G1 | Cahier groupe n°1]]
| Taky Djeraba & Baptiste Cartier
|-
| [[ TP sysres IMA5sc 2018/2019 G2 | Cahier groupe n°2]]
| Jade Dupont & Quentin Boëns
|-
| [[ TP sysres IMA5sc 2018/2019 G3 | Cahier groupe n°3]]
| Antoine Duquenoy & Anthony Durot
|-
| [[ TP sysres IMA5sc 2018/2019 G4 | Cahier groupe n°4]]
| Paul Ribeiro & Antoine Untereiner
|-
| [[ TP sysres IMA5sc 2018/2019 G5 | Cahier groupe n°5]]
| Delobelle Matthieu
|-
| [[ TP sysres IMA5sc 2018/2019 G6 | Cahier groupe n°6]]
| Simon Feutrier & Antoine Gosse
|-
| [[ TP sysres IMA5sc 2018/2019 G7 | Cahier groupe n°7]]
| Naif Mehanna & Maxime Créteur
|-
| [[ TP sysres IMA5sc 2018/2019 G8 | Cahier groupe n°8]]
| Justine Senellart & Rodolphe Toin
|-
| [[ TP sysres IMA5sc 2018/2019 G9 | Cahier groupe n°9]]
| Amine El Messaoudi & Thibault Cattelain
|-
| [[ TP sysres IMA5sc 2018/2019 G10 | Cahier groupe n°10]]
| Etienne Profit & Olivier Mahieux
|-
| [[ TP sysres IMA5sc 2018/2019 G12 | Cahier groupe n°11]]
| Benjamin Canu & Amaury Carval
|-
| [[ TP sysres IMA5sc 2018/2019 G13 | Cahier groupe n°12]]
| Ji YANG
|-
|}

== Plan d'adressage ==
{| class="wikitable"
! Nom !! VLAN !! Réseau IPV4 !! Réseau IPV6 !! IP routeur 1 !! IP routeur 2 !! Routeur virtuel !! Nom VM !! IP VM
|-
|XEN
|43
|193.48.57.176/28
|2001.660.4401.60C0::/64
|193.48.57.188/28
|193.48.57.189/28
|193.48.57.190/28
|-
|Groupe 1
|11
|10.60.11.0/24
|2001.660.4401.60C1::/64
|10.60.11.252/24
|10.60.11.253/24
|10.60.11.254/24
|Thot
|193.48.57.177/28
|-
|Groupe 2
|12
|10.60.12.0/24
|2001.660.4401.60C2::/64
|10.60.12.252/24
|10.60.12.253/24
|10.60.12.254/24
|Dionysos
|193.48.57.178/28
|-
|Groupe 3
|13
|10.60.13.0/24
|2001.660.4401.60C3::/64
|10.60.13.252/24
|10.60.13.253/24
|10.60.13.254/24
|Pegase
|193.48.57.179/28
|-
|Groupe 4
|14
|10.60.14.0/24
|2001.660.4401.60C4::/64
|10.60.14.252/24
|10.60.14.253/24
|10.60.14.254/24
|Hades
|193.48.57.180/28
|-
|Groupe 5
|15
|10.60.15.0/24
|2001.660.4401.60C5::/64
|10.60.15.252/24
|10.60.15.253/24
|10.60.15.254/24
|Chronos
|193.48.57.181/28
|-
|Groupe 6
|16
|10.60.16.0/24
|2001.660.4401.60C6::/64
|10.60.16.252/24
|10.60.16.253/24
|10.60.16.254/24
|Poseidon
|193.48.57.182/28
|-
|Groupe 7
|17
|10.60.17.0/24
|2001.660.4401.60C7::/64
|10.60.17.252/24
|10.60.17.253/24
|10.60.17.254/24
|Hercule
|193.48.57.183/28
|-
|Groupe 8
|18
|10.60.18.0/24
|2001.660.4401.60C8::/64
|10.60.18.252/24
|10.60.18.253/24
|10.60.18.254/24
|Nyx
|193.48.57.184/28
|-
|Groupe 9
|19
|10.60.19.0/24
|2001.660.4401.60C9::/64
|10.60.19.252/24
|10.60.19.253/24
|10.60.19.254/24
|Aphrodite
|193.48.57.185/28
|-
|Groupe 10
|20
|10.60.20.0/24
|2001.660.4401.60CA::/64
|10.60.20.252/24
|10.60.20.253/24
|10.60.20.254/24
|Hermes
|193.48.57.186/28
|-
|Groupe 11
|21
|10.60.21.0/24
|2001.660.4401.60CB::/64
|10.60.21.252/24
|10.60.21.253/24
|10.60.21.254/24
|NOM MACHINE VIRTUELLE
|193.48.57.187/28
|-
|Interconnexion
|131
|192.168.222.8/29
|Router1 : fe80:0000:0042:0002 // Router2 : fe80:0000:0042:0003 // Ecole : fe80:0000:0042:0001
|192.168.222.9/29
|192.168.222.10/29
|}

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:41:20Z

Ael-mess : /* Activation des interfaces sur les containers> */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

export http_proxy=http://proxy.polytech-lille.fr:3128/

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

Et donc :
root@zabeth04:/home/pifou# brctl show
bridge name bridge id STP enabled interfaces
br-d8330a30a134 8000.0242b8ae38c5 no
bridge 8000.00224d7aeaa1 no eth0
eth1
vif4
docker0 8000.0242ad165937 no veth0b1f71b
interne 8000.3ee68d5b1e14 no vif1
vif2
vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP XXXXXX, ses caractéristiques sont les suivantes :

XX
XX
XX
XX
XX
XX

Le SAS est un HP XXXXXXX.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

export http_proxy=http://proxy.polytech-lille.fr:3128

Une fois fait, notre serveur avait accès au réseau de polytech.

==Installation des outils HP==

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

IMAGE

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:39:45Z

Ael-mess : /* Configuration de apache2 : */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

export http_proxy=http://proxy.polytech-lille.fr:3128/

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP XXXXXX, ses caractéristiques sont les suivantes :

XX
XX
XX
XX
XX
XX

Le SAS est un HP XXXXXXX.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

export http_proxy=http://proxy.polytech-lille.fr:3128

Une fois fait, notre serveur avait accès au réseau de polytech.

==Installation des outils HP==

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

IMAGE

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:39:35Z

Ael-mess : /* Configuration de apache2 : */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

export http_proxy=http://proxy.polytech-lille.fr:3128/

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP XXXXXX, ses caractéristiques sont les suivantes :

XX
XX
XX
XX
XX
XX

Le SAS est un HP XXXXXXX.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

export http_proxy=http://proxy.polytech-lille.fr:3128

Une fois fait, notre serveur avait accès au réseau de polytech.

==Installation des outils HP==

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

IMAGE

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:38:01Z

Ael-mess : /* Configuration de apache2 : */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

export http_proxy=http://proxy.polytech-lille.fr:3128/

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP XXXXXX, ses caractéristiques sont les suivantes :

XX
XX
XX
XX
XX
XX

Le SAS est un HP XXXXXXX.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

export http_proxy=http://proxy.polytech-lille.fr:3128

Une fois fait, notre serveur avait accès au réseau de polytech.

==Installation des outils HP==

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

IMAGE

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:37:03Z

Ael-mess : /* Création d'un container avec Docker : */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

export http_proxy=http://proxy.polytech-lille.fr:3128/

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :
root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP XXXXXX, ses caractéristiques sont les suivantes :

XX
XX
XX
XX
XX
XX

Le SAS est un HP XXXXXXX.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

export http_proxy=http://proxy.polytech-lille.fr:3128

Une fois fait, notre serveur avait accès au réseau de polytech.

==Installation des outils HP==

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

IMAGE

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:11:21Z

Ael-mess : /* Création d'un container avec Docker : */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:10:26Z

Ael-mess : /* = */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:09:28Z

Ael-mess : /* Séance 2 : TP ASR (suite) */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:08:26Z

Ael-mess : /* Création d'un container unshare */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:08:09Z

Ael-mess : /* Séance 1 : TP ASR */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

export http_proxy=http://proxy.polytech-lille.fr:3128/

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP XXXXXX, ses caractéristiques sont les suivantes :

XX
XX
XX
XX
XX
XX

Le SAS est un HP XXXXXXX.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :
XXX

Ensuite, nous avons configuré les DNS :
XXX

Et enfin nous avons ajouté le proxy polytech :
XXX

Une fois fait, notre serveur avait accès au réseau de polytech.

==Installation des outils HP==

=Séance 4 : TP PRA (Suite)=

TP sysres IMA5sc 2018/2019

2018-11-12T14:51:27Z

Ael-mess : /* Répartition des binômes */