Version actuelle datée du 3 mai 2020 à 18:35

Sommaire

1 Présentation générale
- 1.1 Description
- 1.2 Objectifs
2 Analyse du projet
3 Préparation du projet
4 Réalisation du Projet

Présentation générale

Administration système, déploiement et surveillances de logiciels dans un réseau de capteurs

Description

Dans le cadre de recherches dans le domaine des réseaux de capteurs et des objets connectés, notre projet consiste à développer une solution de maintenance et de reconfiguration à distance d'un ensemble de nœuds déployés dans un environnement réel. Afin de faciliter la vie de ces chercheurs sur le test de leurs hypothèses, ils pourront facilement et rapidement déployer leurs créations sur tout les nœuds souhaités grâce à un système de sélection ou au téléchargement du nouveau code sur tous les nœuds du réseau.

Objectifs

L'objectif principal de notre projet est de créer une interface permettant de tester des programmes ou logiciels en les déployant sur le vaste réseau de capteurs. Nous devons rendre accessible chaque nœud indépendamment des autres, tout en permettant un lien entre tous, afin d'envoyer le contenu vers tout ou une partie des nœuds disponibles.

Enfin, nous allons permettre la mise à jour et l'adaptation du chemin d'envoi des données des nœuds, entre eux, et avec l'application de gestion.

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent

Logo du Laboratoire

Logo du LRI

Notre concurrent principal reste le FIT(Future Internet Testing Falicity)/IoT-Lab. Il s'agit d'un laboratoire dont les recherches se portent sur les différents domaines scientifiques tel que les adresses de communications sans fils, des réseaux de capteurs, des protocoles de routages basse consommation et applications embarquées. Ce laboratoire dispose de plus de 1500 de nœuds de capteurs sans fils propagés à travers les six sites différents en France qui sont : Inria Grenoble (640), Inria Lille (293), Inria Saclay (264), ICube Strasbourg (400), Institut Mines-Télécom Paris (160) and CITI Lab Lyon (29). Chaque site dispose de capacités matérielles et de nœuds différentes, mais tous les sites sont interconnectés et disponibles via le même portail Web,

Analyse du second concurrent

Il y aussi une autre équipe au sein du laboratoire de recherches en informatique(LRI) qui est en train de faire un projet sur les capteurs de réseaux. Les questions abordées par l’équipe concernent les réseaux ad hoc sans fil et mobiles, les réseaux de capteurs et les réseaux fixes, et concernent la qualité de service, la sécurité, le contrôle d’admission, la réservation de ressources, le calcul des limites déterministes et la consommation d’énergie. L'analyse de la performance est donnée à la fois théoriquement, pour déterminer les limites, et par simulation, pour enrichir l'analyse et inclure un support pour un environnement dynamique.

Scénario d'usage du produit ou du concept envisagé

Schéma Complet

De nombreux chercheurs et développeurs créent de nouveaux codes adaptés à l'utilisation d'un réseau de capteurs. Ces codes doivent être facilement déployés sur le réseau afin de pouvoir y réaliser des essais rapides. Cela permet de corriger rapidement les erreurs liées à leur mauvais fonctionnement.

Supposons que notre réseau est réparti sur une très grande surface. Le chercheur voulant tester son code doit l'envoyer à partir de son ordinateur sur le réseau. Notre projet va lui permettre de rester assis dans son bureau et de ne pas devoir charger le code sur chaque nœud de capteurs un par un.

A travers notre projet, nous voulons rendre possible ces exports rapides de données. Il nous faudra utiliser un routeur qui permettra la liaison entre chaque nœud et un serveur de données. Dans chacun de ses nœuds, on trouve plusieurs nœuds de mesures comportant chacun un microcontrôleur associé à des capteurs.

Pour pouvoir envoyer ses codes sur le réseau, le chercheur dispose d'une interface web graphique connectée au même serveur que les nœuds de collecte et le routeur. Cette interface permettra la sélection de tout ou d'une partie du réseau sur laquelle il doit effectuer les modifications. Ceci se fera à l'aide des microcontrôleurs du réseau et de Raspberry Pi gérant chaque nœud. Une fois la zone d'export choisie, il pourra envoyer ses codes et les mettre à jour en quelques clics. Le code sera envoyé sur le serveur et distribué par le routeur sur les nœuds sélectionnés. Les différents nœuds feront un retour sur la réception à travers le serveur via le routeur, et le chercheur pourra ainsi tester rapidement sa réalisation.

Dans le cas où le chercheur veut tester l'envoi de données par radio par exemple, il pourra placer un grand nombre de nœuds communiquant en filaire avec le routeur et par radio entre eux. Les nœuds seront capables de transmettre l'information au suivant et de choisir un autre chemin (contourner un nœud par exemple) en cas de perturbations (présence de réseau Wi-Fi à proximité, etc...), pour envoyer l'information. Ces nœuds seront capables de communiquer avec le serveur pour indiquer la bonne réception des données, les résultats obtenus ou éventuellement le mauvais fonctionnement d'un ou plusieurs capteurs.

Bibliographie et webographie

S6

Equipe 1

DataSheet
- https://www.electronicsdatasheets.com/datasheet/BPI-R1.pdf

OpenWRT
- https://openwrt.org/

Banana Pi
- http://wiki.banana-pi.org/Banana_Pi_BPI-R1

Equipe 2

Pin Raspberry
- https://pi4j.com/1.2/pins/model-3b-plus-rev1.html

Configuration
- https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018

Clignotement d’une LED
- https://www.framboise314.fr/la-saga-blink-un-raspberry-pour-faire-clignoter-une-led/
- http://nagashur.com/blog/2013/01/01/controler-une-led-depuis-les-ports-gpio-du-raspberry-pi/

Installation Raspbian
- https://raspbian-france.fr/installer-raspbian-premier-demarrage-configuration/

Equipe 3

Protocole XMLHttpRequest
- https://openclassrooms.com/fr/courses/1085676-upload-de-fichiers-par-formulaire

S7

Equipe 1

Banana Pi
- http://hardware-libre.fr/2015/01/bpi-r1-open-router-first-look/

Equipe 2

Passage en mode DFU
- https://www.arduino.cc/en/Hacking/DFUProgramming8U2

Flasher un Arduino sans programmer
- https://welldoneblog.fedevel.com/2015/04/13/how-to-flash-arduino-bootloader-without-a-programmer/

Datasheets

Connexion entre RPI & Atmega328p

Arduino UNO & Raspberry Pi SPI
- http://ozzmaker.com/program-avr-using-raspberry-pi-gpio/
- https://davecturner.github.io/2019/02/23/programming-avr-microcontrollers.html

S8

Equipe 1

Connexion SPI
- https://www.arduino.cc/en/reference/SPI
- https://zestedesavoir.com/forums/sujet/2574/communication-via-rx-et-tx/

TX/RX à partir de GPIO
- https://github.com/adrianomarto/soft_uart
- https://oscarliang.com/raspberry-pi-and-arduino-connected-serial-gpio/

Script Python
- https://www.quennec.fr/trucs-astuces/langages/python/python-modifier-la-valeur-dune-balise-dun-xml-en-fonction-de-la-valeur-de-son-attribut
- http://dridk.me/python-requests.html

Equipe 2

Communication SSH
- https://geekeries.org/2016/10/transferts-scp-sans-mot-de-passe/?cn-reloaded=1

Equipe 3

Script PhP

Préparation du projet

Cahier des charges du groupe

Nous allons devoir répondre à plusieurs problématiques.

Tout d'abord nous devons créer un site web dynamique permettant l'envoi des données au serveur et finalement, aux nœuds de capteurs sélectionnés. Pour cela, nous allons devoir implémenter un système d'envoi de fichiers vers un routeur. Le routeur (Banana Pi) va filtrer les informations reçues, et donner un accès internet aux différents nœuds représentés par des Raspberry Pi et des microcontrôleurs.

Ensuite, il faudra que les Raspberry récupèrent les fichiers C sur le serveur et les envoient correctement aux différents capteurs de leur nœud et puissent récupérer les informations à retourner. Pour se faire, on utilise l'utilitaire Python Ansible, permettant la gestion et la configuration des nœuds de capteurs. Celui-ci va récupérer les fichiers C et les distribuer sur les différents capteurs affectés. Le retour d'information se fera par requêtes envoyant les informations mises à jour au serveur.

Cahier des charges des équipes

Equipe 1 : Ziyad HOUSSAINI (S6), Loris AHOUASSOU (S8)

S6

Dans notre équipe, il faudra configurer le routeur afin de pouvoir assurer la communication entre les Rasberry Pi qui seront configurées par l'équipe 2 et le serveur web qui sera mise en place par l'équipe 3 ;
Pour se faire, on va utiliser une Banana pi sur laquelle sera installé OpenWRT ;
Le routeur servira également de point d'accès internet pour les différentes Raspberry ;
Il devra scruter le serveur web et récupérer les fichiers qui s'y trouvent avant de les envoyer sur les bonnes Raspberry à l'aide de scripts Shell.

S8

Créer des scripts permettant d'automatiser la compilation et le lancement les codes reçus depuis le serveur ;
Créer les codes pour les différents capteurs disponibles ;
Créer un script permettant l'envoi des données au serveur.

Equipe 2 : Eymeric CAPRONNIER, Loris AHOUASSOU (S7), Guillaume ROUILLÉ (S7), Thomas MERTZ (S8)

S6, S7

Une fois que le routeur aura envoyé les fichiers aux Raspberry demandées, et donc en fonction des capteurs qui s'y trouvent, celles-ci pourront commencer leur traitement ;
Les Raspberry vont commencer par compiler les codes reçus, puis vont les envoyer sur les microcontrôleurs représentant les capteurs ;
Les microcontrôleurs devront pouvoir être reconfigurer directement à partir de la Raspberry. Ils vont exécuter les codes reçus ;
Ils vont ensuite générer des fichiers résultat qui seront envoyés sur le serveur.

S8

Configurer Ansible pour envoyer les données du serveur vers les Raspberrys.

Equipe 3 : Guillaume ROUILLÉ

Dans un premier temps, notre équipe devra réaliser une interface web utilisateur permettant la connexion au serveur de données. Pour se faire, on va utiliser les langages HTML et CSS pour la forme du site, et les langages PhP et SQL pour lier le site à la base de données ;
Ensuite, il faudra créer un système de sélection des capteurs sur lesquels envoyer le ou les fichiers. Il faudra faire correspondre chaque capteur des différents nœuds avec un type prédéfini et créer une page de sélection sur le site ;
Puis, nous devrons envoyer les fichiers sur le serveur, où ils seront récupérés par ce qui est mis en œuvre par l'équipe 2. Il faudra créer une page permettant la mise en ligne de fichiers. Cette page affichera la bonne réception des données ;
Enfin, une dernière partie du site permettra l'affichage des résultats reçus depuis les capteurs sous plusieurs formes.

Choix techniques : matériel et logiciel

Banana PI R1

Raspberry PI 3

Equipe 1

S6

Une Banana Pi ;
Une image (OS) de type Debian ou OpenWrt afin de pouvoir utiliser la carte ;
Un carte SD sur laquelle on va charger l'image ;
Un cable HDMI afin de pouvoir visualiser l'interface.

S7, S8

3x Raspberry Pi ;
5x Arduino UNO ;
1x Nucleo-F401RE ;
4x Câble RJ45 ;
6x Câble USB type A mâle - type B mâle ;
6x Câble électrique femelle - femelle ;
3x Capteurs de distance HC-SR04: https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm ;
2x Capteurs de température LM35 : https://www.gotronic.fr/art-module-capteur-de-t-lm35-st039-26113.htm#complte_desc ;
18x Câble électrique mâle - mâle.

Equipe 2

1x Raspberry Pi ;
1x câble Ethernet ;
4x diodes et résistances (S6);
1x câble HMDI/VGA ;
1x clavier et une souris afin d'utiliser la Raspberry (interface graphique).

Equipe 3

Une base de données PostgreSQL pour le stockage des données ;
Un interpréteur PhP et un serveur web (Apache).

Liste des tâches à effectuer

Equipe 1

S6

Déploiement d'un routeur à base de Banana Pi R1 permettant l'accès à internet aux différentes Raspberry Pi ;
- Déploiement de OpenWRT sur le routeur et configuration ;
- Création d'un point d'accès internet sur la carte routeur ;
- Récupération des fichiers sur le serveur web ;
- Envoi des fichiers sur les bonnes Raspberry.

S8

Scripts permettant d'automatiser la compilation et le lancement les codes reçus depuis le serveur ;
- Création d'un Makefile ;
- Création d'un script de lancement global.
Codes pour les différents capteurs disponibles ;
- Créer un code pour chaque capteur (température, distance) ;
- Créer une lib contenant une fonction permettant le retour de données via liaison série.
Script permettant l'envoi des données au serveur.
- Créer un script Python permettant la récupération des données sur le port série et l'envoi au serveur par requête POST.

Equipe 2

S6, S7

Récupération des fichiers sur le serveur ;
- Créer un script pour récupérer les fichiers sur le serveur ;
Compilation et lancement du code.
- Créer un Makefile ;
- Créer un script pour lancer le Makefile de manière automatique.

S8

Déploiement des logiciels sur les Raspberry Pi grâce à Ansible.
- Configuration de la Raspberry PI 3 pour qu'elle soit accessible sur le réseau (adresse IP, routeur, DNS) ;
- Création du script afin d'envoyer le code reçu aux différents capteurs ;
- Configuration à distance du microcontrôleur, peut importe son type.

Equipe 3

S6

Déploiement du serveur Web ;
- Création d'une base de données PostgreSQL ;
- Création d'un site web ;
- Création d'une interface web utilisateur ;
- Création d'une page d'envoi des fichiers vers le serveur.
Envoi des fichiers sur le serveur ;
- Créer un script d'envoi du fichier choisit par l'utilisateur sur le serveur.
Envoi du numéro et type des capteurs sélectionnés sur le serveur ;
Envoi du numéro de la demande sur le serveur ;

S8

Ajout de différentes pages ;
- Page permettant la visualisation de l'historique des données des capteurs ;
- Page permettant l'affichage de graphes fabriqués à l'aide des données des capteurs ;
- Pages permettant l'ajout de raspberrys et de capteurs ;
- Page permettant la visualisation du réseau global.
Modification de la base de données ;
- Ajout d'une table d'historique ;
- Ajout d'une table de groupes ;
- Mise à jour des tables contenant les capteurs et les raspberrys.
Envoi du fichier de configuration (.ini) sur le serveur ;
Permettre aux administrateurs d'ajouter et de supprimer des comptes ;
Permettre le lancement d'Ansible via le site.

Calendrier prévisionnel

Equipe 1

Dates	Objectifs
05/02/19	Analyse des concurrents ; Scénario d'usage.
19/02/19	Cahier des charges ; Répartition du travail entre équipes.
05/03/19	Recherche sur Internet sur quel type de carte on pourra utiliser pour configurer le routeur, qui sera un point d'accès wifi pour le noeud de collecte qui sera la Rasberry Pi.
19/03/19	Recherche de la datasheet du routeur Banana PI-R1, afin de pouvoir comprendre les configurations de la carte et aussi les branchements.
02/04/19	Trouver l'open source me permettant de visuliser l'interface de la BPI-R1, et en l'occurrence l'OS OpenWrt.
16/04/19	Faire fonctionner la carte et comprendre les fonctionnalités qu'offrent l'OpenWrt.
30/04/19	Configurer la carte en tant que point d'accès wi-fi en utilisant cette fois l'OS Debian car la semaine dernière l'image OpenWrt ne fonctionnait pas.
07/05/19	Résoudre le problème de la carte car elle ne fonctionnait pas et demander à mes tuteurs la raison pour laquelle elle ne marche pas.
14/05/19	Mettre une nouvelle image (Armbian) et rattraper le retard pour le configurer en tant que point d'accès wi-fi pour la rasberry pi.
28/05/19	Faire en sorte que la BPI-R1 arrive à jouer le rôle de point d'accès wifi pour que la Rasberry PI puisse se connecter au serveur via internet.
14/11/19	Reprendre la configuration de la Banana Pi à zéro ; Faire de cette carte un point d'accès Wi-Fi.
29/01/20	Faire communiquer l'Arduino UNO et la Raspberry Pi dans les 2 sens.
12/02/20	Créer le code pour le capteur de température et visualisation des données sur le port série avec minicom.
19/02/20	Créer le code pour le capteur de distance et visualisation des données sur le port série avec minicom.
04/03/20	Créer le script Python permettant le retour de données vers le serveur.
25/03/20	Créer le Makefile générique.
08/04/20	Faire correspondre un port USR de Raspberry Pi à un capteur.

Equipe 2

Dates	Objectifs
05/02/19	Analyse des concurrents ; Scénario d'usage.
19/02/19	Cahier des charges ; Répartition du travail entre équipes.
05/03/19	Documentation sur les différents outils : Raspberry et Ansible.
19/03/19	Documentation sur l'allumage d'une LED et création des premiers scripts d'allumage de LED.
02/04/19	Installation de Raspbian sur la Raspberry PI 3 et début de configuration de la Raspberry PI 3.
16/04/19	Configuration de la Raspberry PI 3.
30/04/19	Installation de la bibliotèque wiringPI permettant le lancement du script écrit en C permettant l'allumage des différentes LED.
14/05/19	Installation d'un premier cablage de LED afin de tester le script d'allumage des LED.
28/05/19	Récupération du fichier C et XML envoyé sur le site ; Création des commandes de récupération de ces fichiers ; Création du script permettant de lire le fichier XML envoyé par le serveur qui indique le nom et le numéro du capteur sélectionné.
04/06/19	Permettre une récupération rapide des fichiers à partir du serveur ; Permettre une scrutation régulière du serveur sur la Raspberry ; Permettre l'exécution unique du programme ; Création du script permettant le lancement automatique des différents scripts créés lorsque le serveur effectue une demande.
14/11/19	Réinstaller une image sur la Raspberry Pi sans interface graphique ; Permettre l'accès à internet sur la Raspberry.
21/11/19	Permettre la connexion entre la Raspberry Pi et un Arduino Atmega328p.
20/12/19	Permettre l'exécution de code sur l'ATMega328p.
08/04/20	Rendre Ansible fonctionnel ; Rendre Cron fonctionnel.

Equipe 3

Dates	Objectifs
05/02/19	Analyse des concurrents ; Scénario d'usage.
19/02/19	Cahier des charges ; Répartition du travail entre équipes.
05/03/19	Création de la base de données associée au projet ; Documentation Php et lancement du site web.
19/03/19	Création du système de connexion du site.
02/04/19	Mise en forme correcte du site : page de connexion, d'inscription et d'accueil.
16/04/19	Création de l'interface de sélection du capteur.
30/04/19	Documentation sur la création d'un fichier XML à partir d'un site web ; Création du fichier XML permettant de regrouper les informations concernant le capteur choisi.
14/05/19	Création de la section de sélection du fichier à envoyer sur le serveur (fichier C) ; Documentation sur le protocole XMLHttpRequest qui permet l'envoi du fichier sur le serveur ; Envoi du fichier C sur le serveur.
28/05/19	Récupération du fichier C et XML envoyé sur le site ; Création des commandes de récupération de ces fichiers.
04/06/19	Permettre une récupération rapide des fichiers à partir du serveur ; Permettre une scrutation régulière du serveur sur la Raspberry ; Permettre l'exécution unique du programme.
01/04/19	Créer la table pour le retour d'informations dans la base de données ; Créer un page d'affichage des données de cette nouvelle table.
29/01/20	Mise à jour de la table capteurs ; Mise à jour de la page de sélection des capteurs.
05/02/20	Créer la page permettant de récupérer les données des capteurs par requête POST ; Créer la fonction de mise à jour de la base de données.
12/02/20	Créer la table qui contiendra l'historique de valeurs ces capteurs ; Créer les pages de recherche dans cet historique ; Modifier la fonction de mise à jour de la base de données pour intégrer l'historique.
19/02/20	Création des pages permettant l'ajout d'une raspberry ou d'un capteur ; Création des fonctions associées.
04/03/20	Créer le fichier inventaire.ini utile à l'équipe 2 à partir du site à l'ajout d'un capteur ou l'envoi d'un code ; Migration du site et de la base données sur un nouveau serveur sur plil.fr.
18/03/20	Créer les pages permettant l'affichage des graphes de valeurs des capteurs ; Création des fonctions associées.
25/03/20	Permettre le lancement d'Ansible depuis le site.
08/04/20	Créer une page permettant la visualisation graphique de l'ensemble du réseau de capteurs et des caractéristiques de chaque nœud.

Réalisation du Projet

Projet S6

Semaine 4 - 05/03

Pour l'équipe 1 :

Première recherche sur la carte Banana PI, à l'aide de la datasheet, dont le lien est ci-dessous.
L'utilisation de la datasheet va nous permettre de voir l'intégralité des données de la carte BPI-R1
c'est à dire les branchements, le courant d'alimentaion et les composants.
https://www.electronicsdatasheets.com/datasheet/BPI-R1.pdf

Pour l'équipe 2 :

Documentation sur l'utilisation d'Ansible et sur les Raspberry Pi

Afin d'installer Ansible, deux lignes de commande ont dû être lancé dans le terminal d'un pc en E306 ( car l'installation d'ansible n'était pas possible dans les autres salles) :

apt install ansible

Connexion internet sur la Raspberry :

Partie Raspberry

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

OU :

export https_proxy=https://proxy.plil.fr:3128
export http_proxy=http://proxy.plil.fr:3128

Puis, dans /etc/resolv.conf

nameserver 193.48.57.48

Ensuite dans /etc/network/interfaces :

auto eth0
iface eth0 inet static
   address 172.26.145.111
   netmask 255.255.255.0
   gateway 172.26.145.254

Enfin :

ipdown eth0
ifup eth0

Sur le pc :

iptables -F
iptables -tnat -F
iptables -PFORWARD ACCEPT

L'utilisation d'ansible se fera ensuite de la manière suivante : Ecriture d'un fichier .yml contenant les différentes tâches à effectuer sur un serveur (réseau de capteur) spécifique puis le lancement s'effectuera ensuite en lanceant la commande ansible suivi du nom du serveur sur lequel on souhaite travailler.

Concernant la Raspberry PI 3, la Raspberry PI 3 est un ordinateur miniature que l'on peut brancher à un écran et un clavier afin de l'utiliser comme un ordinateur normal. Le stockage des données s'effectue sur une carte SD ce qui permet à la Raspberry d'être très petite (l'utilisation d'un disque dur interne augmenterait grandement sa taille)

Pour l'équipe 3 :

Première recherche sur la création du site web. Recherche des ressources PhP, HTML, CSS nécessaires (Bootstrap).
J'ai laissé de côté la partie JavaScript et Vue.js car elles ne sont pas utiles pour commencer le site.

Création de la base de données projetCapteurs sur Houplin et des fonctions de connexion du site à celle-ci.
La base contient 3 tables :

capteurs : numéro du capteur | nom du capteur | Raspberry à laquelle le capteur est relié | type de capteur
membres : numéro du membre | nom | prénom | mot de passe | identifiant de connexion
verif : numéro de la demande

La table capteurs stocke les informations concernant les capteurs et permettra la sélection au moment de l'envoi du fichier C.
La table membres répertorie les informations concernant les membres et permettra la connexion sur le site web.
La table verif contient le numéro de la demande.

Semaine 5 - 19/03

Pour l'équipe 1 :

Après avoir effectué des recherches sur la carte BPI R1, cette séance va me permettre de faire des recherches sur l'image qui va me permettre de faire visualiser l'interface de la BPI R1.
D'après le cahier de charge imposé, il faut mettre l'image OpenWrt.
Open Wrt est une distribution GNU/Linux minimaliste pour matériel embarqué. Après avoir fait des recherches, on a finalement retrouvé le site qui a l'image OpenWrt.
La première que je devais faire était d'installer un fichier OpenWrt dans une carte SD, et ce fichier servait à faire fonctionner la banana pi.
Voici le lien qui nous a permis de trouver l'image:

https://openwrt.org/toh/view/toh_fwdownload?dataflt%5B0%5D=supported%20current%20rel_%3D18.06.2.

Voici une image du site d'openwrt :

Openwrt

Pour l'équipe 2 :

Au cours de cette séance, je me suis documenté sur l'allumage d'une LED. Cela m'a amené à créer un organigramme afin de réaliser le code plus simplement par la suite.

Organigramme

Le câblage s'effectuera de façon très simple en connectant une LED puis une résistance à chaque sortie GPIO en fonction du nombre de capteurs souhaités par Raspberry (nous utilisons des LED pour cette année pour simuler et voir que le code envoyé par le serveur est bien traité et reçu par les LED s'allumant lorsque le capteur associé a été sélectionné).

Cablage LED

Puis je me suis intéressé au code afin d'allumer la LED 500ms puis de l'éteindre 500ms grâce à une boucle while qui est toujours active tant que le programme tourne (control C par l'utilisateur pour stopper le programme). Pour se faire, il faut mettre le PIN connecté à la LED en mode sortie (OUTPUT) car sans cela la LED ne s'allume pas.

Script C LED

Ce code nécessite l'installation de la bibliothèque WiringPi qui permet d'allumer et d’éteindre la LED. Nous verrons l'installation de cette bibliothèque une fois les configurations faites sur la Raspberry effectuées et une fois connecté à la Raspberry.

Pour l'équipe 3 :

Début de la création du site : mise en place d'un système de connexion basique et d'un minimum de design pour rendre clair le site.
Je me suis limité à des fonctions de connexion et déconnexion sans modifier le reste des pages en fonction de l'état de connexion, et sans créer de variables de session.
Pour cela, j'ai utilisé des fonctions Php telles que pg_connect et pg_close, fonctions liées à une base de données PostgreSQL.

Création d'un formulaire de connexion ;
Création d'un formulaire d'inscription ;
Création des scripts Php de lancement de ces formulaires.

Semaine 6 - 02/04

Branchement de la carte Banana PI

Pour l'équipe 1 :

Après avoir trouvé l'image permettant de visualiser l'interface BPI-R1, de la faire marcher et de le configurer en tant que routeur de wifi pour qu'il puisse emettre pour le noeud de collecte qui est la Rasberry PI. La première étape est d'abord d'installer l'OpenWrt dans une carte SD et cette carte SD sera mis sur le port SD de la Banana PI R1. Voici les commandes qui m'ont permis de mettre l'image OpenWrt dans la carte SD :

Il faut d'abord se connecter à su sur le terminal
Mettre l'image avec la commande ci dessous :

dd if=OpenWrtimage.img of=/dev/sdb

Avec OpenWrtimage.img le nom du fichier télécharger. Après avoir branchéle port HDMI de la carte avec l'entrée VGA du moniteur on pouvait voir l'interface mais on arrivait pas écrire. Donc après avoir appeler mes tuteurs, ils m'avaient dit que la semaine prochaine, ils allaient mettre le système Debian, car il y aurait des problèmes avec le système OpenWrt.

Pour l'équipe 2 :

Tout d'abord, il faut télécharger Raspbian sur la carte SD de la Raspberry Pi 3. Pour cela, j'ai sélectionné le fichier contenant Raspbian avec des interfaces graphiques (voir photo ci-dessous) sur le site internet :

https://www.raspberrypi.org/downloads/raspbian/

Fichier Raspbian

Une fois l'archive zippée de la distribution récupérée vous pouvez l'installer sur la carte SD après l'avoir décompressée en utilisant la commande dd :

dd if=2019-04-08-raspbian-stretch-full.img of=/dev/sdb

Puis une fois tout ceci téléchargé, j'ai commencé à effectuer mes premiers pas sur la Raspberry. Une fois le clavier, la souris, l'écran et la carte SD branché et connecté à la Raspberry, j'ai pu connecter l'alimentation de la Raspberry. Le premier démarrage fut un peu long, car lors de celui-ci, la raspberry a installé le système Raspbian. Lors de ce premier démarrage, des premières configurations ont été effectué qui ont été très simplifié car étant sur une version de Raspbian avec une interface graphique. Ces quelques réglages consistaient principalement à régler la langue, l'heure, la connexion internet et le nouveau mot de passe. L'identifiant et le mot de passe ont été laissé comme initialement.

le login par défaut est « pi », et le password est « raspberry »

Pour l'équipe 3 :

Adaptation du système de connexion avec création de variables de session. Ces variables permettent de maintenir une connexion ouverte en changeant de page et à structurer les pages afin qu'elles affichent les bonnes choses.
En effet, un individu connecté ne verra pas la page de connexion par exemple.
Amélioration du système de compte avec la mise en place du hachage des mots de passe.
Amélioration du design du site, avec la création d'une barre de menu et l'utilisation de Bootstrap.

Page d'accueil en mode non connecté

Barre de menu en mode connecté

Semaine 7 - 16/04

Pour l'équipe 1 :

Dans cette séance de projet, je vois que mon cahier de charge doit être changer. En effet, vu que la séance dernière, avec l'OpenWrt
qu'il y avait un problème de visualation de l'interface. Au final, j'ai reçu par mes tuteurs une carte SD, contenant cette fois
l'image Debian. Et cette fois ci, on voit bien l'interface. Maintenant le but est de pouvoir configurer la banana PI en routeur Wifi
afin que la Rasberry PI reçoit la wifi de ce dernier. Et aussi dans cette séance, j'ai pu voir des tutoriels, afin de pouvoir comprendre le mécanisme de fonctionnement et de
programmation.

Pour l'équipe 2 : Durant cette séance, plusieurs autres configurations ont été effectuées. Pour accéder à la fenêtre de configuration, il a fallu rentrer la commande :

sudo raspi-config

Maintenant que notre système Raspbian est un peu plus sécurisé, nous allons nous assurer que le SSH est bien activé afin que nous puissions prendre le contrôle de la Raspberry à distance. Pour cela, il faut sélectionner le huitième choix, « Advanced Options ». Cette fois, après validation nous arrivons sur un autre menu ou nous allons choisir la quatrième ligne, « SSH ». Puis « Enable », et enfin « Valider ». Le système lance quelques commandes puis nous ré-affiche une fenêtre nous indiquant le succès de l’opération.

Pour l'équipe 3 :

Création de la page de sélection des capteurs sous forme d'un formulaire Php. La sélection n'est pas au point mais l'affichage est correct.
Je laisse toujours de côté la partie dynamique, en essayant de rendre possible la sélection multiple pour l'envoi du formulaire.
Cette page contiendra aussi une partie de chargement du fichier à envoyer (unique pour le moment).

Choix des capteurs et envoi du fichier

Semaine 8 - 30/04

Pour l'équipe 1 :

Dans la dernière séance, j'ai pas pu totalement assimiler l'ensemble du fonctionnement permettant de configurer
la BPI-R1 en tant que routeur de wifi. Donc toute cette séance s'est consacrés à la recherche des fonctionnalités de la carte.
Et aussi, j'ai pu énormément m'aider du site du bureau d'étude d'IMA (Robot Prédateur et Proie) de l'an dernier, surtout avec
la partie Rasberry Pi que j'ai remarqué qu'au final les fonctionnalités de la Banana PI est à peu près identique que celle de la Rasberry.
Voici le lien qui m'a principalement aidé à mieux comprendre et trouver les fonctionnalités du Debian :
https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019

Pour l'équipe 2 :

Une fois la Raspberry configuré, il a fallu installer la bibliothèque wiringPi. Pour se faire :

On installe GIT:

sudo apt-get install git-core

On met a jour le PI:

sudo apt-get update
sudo apt-get upgrade

On récupère la dernière version de WiringPi:

git clone git://git.drogon.net/wiringPi

On se place dans le bon répertoire:

cd wiringPi

On lance la compilation:

./build

Puis le lancement du code créé pour l'allumage des LED s'effectue de la manière suivante:

gcc blink.c -o blink -lwiringPi
./blink

Le fichier blink étant notre fichier contenant le script permettant l'allumage d'une led toute les 0.5s.

Pour l'équipe 3 :

Modification de la page principale (sélection d'un capteur possible). Possibilité de joindre un seul fichier C.
Un fichier XML est créé avec le numéro du capteur sélectionné. Ce fichier sera transmis avec le fichier C.
Documentation sur le protocole XMLHttpRequest : XMLHttpRequest

Le fichier XML contient le code suivant :

<?xml version='1.0' encoding='ISO-8859-1'?>

<sensor>nom_num</sensor>

Choix des capteurs et envoi du fichier

Script de remplissage du fichier XML

Semaine 9 - 14/05

Pour l'équipe 1 : Dans cette séance, je peux enfin commencer à configurer la BPI-R1 en point d'accès Wifi. Après avoir branché au moniteur la carte
je remarque qu'il n'y a aucune visualisation sur le moniteur. Et c'est là où je commence à me perdre. En effet, n'ayant aucune idée de pourquoi
on ne voit plus l'interface, j'ai décidé de rechercher les causes de ce problème, en supposant que la carte a été court-circuiter.
Donc cette séance n'a été que la recherche de ce problème et surtout pouvoir le résoudre. N'ayant aucune idée après plusieurs séances de recherche, j'ai décidé de voir mes tuteurs afin de pouvoir
résoudre ce problème car je suis vraiment en retard par rapport à mon objectif fixé qui était
de configurer la BPI-R1 en routeur wifi pour qu'elle puisse donner les informations à la Rasberrie -PI.
Après plusieurs essaies, c'est à dire changer le courant d'Alimentation, mettre de nouveau l'image Debian
au final, mes tuteurs m'ont conseillé de changer l'image et d'en mettre un nouveau mais aussi il faut que
que cette image soit récente afin de ne pas avoir de problème au niveau du noyau de la carte.

Pour l'équipe 2 :

Installation d'un premier câblage pour réaliser l'allumage d'une des 4 LED en fonction de la LED sélectionné. Il a fallu trouver grâce à différent test le bon schéma de pin de notre Raspberry car il en existait beaucoup de différent sur le numéro du pin à entrer pour allumer la led correspondante à ce numéro.

Différent PIN de sortie de notre Raspberry Pi 3

Script d'envoi du fichier C sur le serveur

Pour l'équipe 3 :

Création du script permettant l'upload d'un fichier C sur le serveur.

Le script va d'abord vérifier que le fichier à uploader vérifie les conditions (pas d'erreur, taille inférieure à la taille maximale, bonne extension).
Ensuite, on normalise le nom du fichier qui s'appellera maintenant 'binaire', et on récupère son extension.
A l'aide de la fonction move_uploaded_file, on délace le fichier de son répertoire temporaire vers le répertoire upload présent sur le serveur.

Il faut maintenant un script pour récupérer les fichiers C et XML sur la Raspberry Pi.

La partie 3 étant terminée pour le résultat attendu au S6, les équipes 2 et 3 fusionnent pour terminer la création des scripts.

Semaine 10 - 28/05

Pour l'équipe 1 : Le problème est enfin résolu mais il faut vite rattraper le retard, donc aujourd'hui, on a consacré cette séance dans l'utilisation de l'Armbian.

Pour l'équipe 2 & 3 :

Création d'un script blink.c permettant la récupération du nom du capteur et de son numéro stockés dans le fichier XML.
Création du script de récupération du fichier XML et du fichier C à partir du serveur.

Pour télécharger le fichier C et le fichier XML stockés sur le serveur, on utilise la commande wget dans un script nommé script.sh :

Script de téléchargement des fichiers

Pour exécuter un script automatique : Règle Cron

Voici le script de téléchargement automatique des fichiers toutes les minutes :

Crontab d'exécution périodique du script

Il s'agit d'une crontab qui s’exécute toutes les minutes.
Cette crontab va lancer le script de téléchargement à chaque exécution, permettant ainsi de garder le fichier C à jour.

Semaine 11 - 04/06

Pour l'équipe 1 :

Interface Armbian

Différentes configuration de la BPI R1

Donc suite au problème qui ont eu lieu ces dernières séances, et après avoir reçu des conseils de
mes tuteurs, j'ai fait une nouvelle des recherches sur l'image la plus récente qui va me permettre
de faire marcher ma carte et visualiser l'interface de l'OS. Après avoir fait un tour sur le site (lien ci dessous)
http://wiki.banana-pi.org/Banana_Pi_BPI-R1
qui propose différentes images et ne sachant vraiment lequel choisir, j'ai choisi de mettre un Armbian 2016 et
et avec la même commande me permettant de copier sur carte SD que l'OpenWrt afin de le mettre sur la carte
. Au final, cela marche, et je me connecte avec "root" qui a pour mot de passe "1234". Après s'être connecter
on obtient cette interface.
Sachant que je suis énormément en retard par rapport aux deux autres équipes, surtout celui de la
qui a presque terminé sa partie, mon objectif est finalement à ce que ma banana PI marche seulement
en tant que routeur Wifi. Et donc en partant de l'OS Armbian et que le principe de la programmation est à
peu près similaire que celle de la Rasberrie PI. Donc je me suis servi du même raisonnement que celui de ce lien :
https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019#Connexion_s.C3.A9rie

Configuration du routeur

La première chose était d'abord d'installer le packtage Hostapd, car c'est ce packtage qui contient tous les
fichiers me permettant d'activer le routeur Wifi :

apt-get install hostapd

Ensuite afin de pouvoir mofidier le fichier de configuration de hostapd qui se trouve dans le répertoire /usr/share/doc/hostapd/examples/ et le coller dans le répertoire /etc/hostapd :

 cp /usr/share/doc/hostapd/examples/hostapd.conf.gz /etc/hostapd
 gunzip /etc/hostapd/hostapd.conf.gz

Et finalement avec l'éditeur de texte nano, on peut modfier le fichier /etc/hostapd/hostapd.confles mots-clefs suivants :

ssid, indiquez le nom de réseau WiFi ;
country_code, mettez le code de la France FR ;
channel
wpa, activez l'option (mettre à 1) ;
wpa_passphrase, configurer un mot de passe pour notre réseau (au moins 8 caractères) ;
wpa_key_mgmt, à configurer à la valeur WPA-PSK.

Enfin il faut definir le chemin du fichier de configuration à l'aide du fichier /etc/default/hostapd :

DAEMON_CONF=/etc/hostapd/hostapd.conf

On relance le service avec la commande :

service hostapd restart

Au final, on arrive à faire apparaître le nom du reseau de la banana sans fil

Nom visible sur le smartphone

Mais le problème, c'est que si on tape le même mot de Passe sur le smartphone, ça nous renvoie erreur d'authentification
au lieu de l'erreur détection IP. Au final, on va de nouveau changé l'OS et de recommencer toute la procédure. Donc le problème du routeur sera résolu l'année prochaine.

Pour l'équipe 2 & 3 :

Nous avons créer le script de récupération de tous les fichiers nécessaires, à savoir :

Le fichier binaire.c ;
Le fichier sensor.xml ;
le fichier demande.txt dont l'utilité sera expliqué ci-dessous.

Ce script permet aussi la compilation du fichier C et le lancement des exécutables du programme.

Script de récupération et lancement du programme

La crontab n'étant pas fonctionnelle sur la Raspberry, nous avons choisi un autre moyen pour permettre la répétition du script.
Nous avons crée le script ci-dessous, qui boucle toutes les 15 secondes (possibilité de modifier le temps).

Script d'exécution périodique de load.sh

Pour que le code ne s'exécute que lorsqu'on envoie un nouveau fichier sur le serveur, et pas toutes les 15 secondes, on reçoit le fichier demande.txt.
Ce fichier contient le numéro de la demande (stocké dans la base de données).
En récupérant le numéro et en le comparant à la dernière version reçue (stockée dans un autre fichier texte), on peut savoir si une nouvelle demande est réalisée.
Si ce n'est pas le cas, le programme ne lance pas l'exécutable du fichier binaire.c.
Ces différentes étapes se font dans le fichier blink.c.

Il est possible de se demander pourquoi nous avons 2 exécutables, et pas un seul reçu directement du serveur. Voici les différentes raisons :

L'exécutable blink nous permet de gérer l'exécution ou non de binaire.
En supposant le projet plus avancé, il est préférable de séparer la partie récupération du capteur et le programme en lui même, car différents capteurs pourraient ne pas utiliser le même code et pourraient être placés sur différentes Raspberry.

Documents Rendus

Gitlab : Git IMA3 P10
Site web : Site
Rapport : media: Rapport_IMA3_P10.pdf

Projet S7

Objectifs

Pour l'équipe 1 :

Remplacement de Ziyad Houssaini par Loris Ahouassou.
Notre équipe s'occupe de la partie routeur, qui doit être reprise au début.
Les objectifs sont de fournir un accès internet aux Raspberrys, et de permettre l'envoi des fichiers de données aux bonnes Raspberry.

Pour l'équipe 2 :

Maintenant que nous avons réussi à scruter le serveur pour y récupérer les fichiers, et que l'allumage des LEDs est fonctionnel, il faut qu'on configure les Raspberry pour qu'elles fournissent un retour au serveur.
Parallèlement à ça, nous devons permettre la reconfiguration de plusieurs types de microcontrôleurs (Cortex M0 ou M4, Atmega328p) à partir de la Raspberry. Ainsi, peut importe le capteurs (situés sur n'importe quel type de microcontrôleurs), il sera utilisable sans besoin de le reprogrammer directement.

Pour l'équipe 3 :

Lors du S6, notre équipe à réaliser une interface Web statique permettant à l'utilisateur de dialoguer avec un serveur et une Raspberry Pi. Il faut maintenant le rendre dynamique en ajoutant un Framework Java Script (Vue.JS) et créer un nouveau système permettant l'affichage des données reçues.
Parallèlement, il faut créer une nouvelle table dans laquelle seront entrées les données reçues des capteurs. Le routeur devra donc réaliser du pré-traitement afin d'entrer les valeurs reçues dans la base.

Réalisation

Pour l'équipe 1 :

Cette partie a été mise en suspend car elle n'est pas indispensable au fonctionnement du projet.

Pour l'équipe 2 :

Ce semestre, nous avions pour objectif de faire communiquer la Raspberry Pi avec l'Arduino UNO en ICSP.
Nous devons utiliser l'Arduino UNO comme support pour les différents capteurs. Ainsi, la Raspberry n'aura qu'un rôle intermédiaire de compilation.
Il faut donc que l'on connecte ensemble ces deux cartes. Nous avons choisi de ne pas passer pas les ports USB, car dans le cas contraire, notre projet est assez simplifié. Nous avons choisi de passer par les pins SPI pour connecter l'ensemble. Ainsi, nous avons effectué quelques manipulations, expliquées ci-dessous.

Connexion SPI Raspberry Pi - Arduino UNO

Installation de avrdude

apt-get install avrdude
avrdude -v (pour vérifier l'installation)

Configuration de avrdude

cp /etc/avrdude.conf ~/avrdude_gpio.conf
nano ~/avrdude_gpio.conf

Nous avons cherché cette partie du code :

#programmer
#  id    = "linuxgpio";
#  desc  = "Use the Linux sysfs interface to bitbang GPIO lines";
#  type  = "linuxgpio";
#  reset = ?;
#  sck   = ?;
#  mosi  = ?;
#  miso  = ?;
#;

Pour la changer en :

programmer
  id    = "pi_3";
  desc  = "Use the Linux sysfs interface to bitbang GPIO lines";
  type  = "linuxgpio";
  reset = 4;
  sck   = 11;
  mosi  = 10;
  miso  = 9;
;

Test de connexion

avrdude -p atmega328p -C ~/avrdude_gpio.conf -c pi_3 -v

Nous avons néanmoins rencontré un problème concernant les pins. La Raspberry n'arrivait pas à exporter certains pins :

Erreur rencontrée

can't export GPIO 10, already exported/busy?

La même erreur survenait pour d'autres pins.

Après quelques recherches, nous avons trouvé comment régler ces problèmes.

Nous avons visualisé donc les GPIOs non exportés à l'aide de la commande suivante

gpio exports

Cela nous a permis d'exporter manuellement les GPIOs concernés.

Pour exporter manuellement les GPIOs dont nous avions besoin :

echo 4 > /sys/class/gpio/unexport
echo 10 > /sys/class/gpio/unexport
echo 11 > /sys/class/gpio/unexport

Suite à cela, la Raspberry pi était désormais capable de se connecter à l'atmega328p.

Création d'un programme test à l'aide de l'IDE Arduino

Nous avons utilisé un programme exemple disponible dans l'IDE. Nous avons activé la compilation dans les préférences et compiler le programme blink qui fait clignoter une led (GPIO 13). Ensuite, nous avons uploadé le fichier .hex créé sur l'Arduino UNO.

avrdude -p atmega328p -C ~/avrdude_gpio.conf -c pi_3 -v -U flash:w:/tmp/build4952970404801881316.tmp/Blink.cpp.hex:i

Résultats

Média:Avrdude.txt On observe bien clignoter la led branchée sur le GPIO 13, ce qui veut dire que l'upload a fonctionné.

Il nous faut maintenant compilé notre fichier C pour pour obtenir le fichier .hex.
Pour cela nous allons créer un Makefile.

Problèmes rencontrés

Nous avons tenté de compiler notre code avec le Makefile d'Arduino. La compilation s'effectue sans problème mais lorsque le code est uploadé sur la carte, la LED s'allume et ne clignote pas comme elle devrait le faire.
Nous avons essayé de faire un Makefile en partant de celui utilisé en tutorat de Système.
Après modification, nous n'arrivons pas à compiler car le compilateur n'arrive pas à accéder à la librairie wiringPi.
En effet, nous avons réfléchi à notre Makefile en considérant le code prévu pour la Raspberry Pi. Cependant, le code était destiné à l'ATMega328p, d'où l'erreur lors de la compilation.

Résolution des problèmes

Nous nous sommes rendu compte que la librairie wiringPi n'était pas utile et surtout pas utilisable sur l'ATMega328p.
En la remplaçant par les librairies avr/io et util/delay, le projet compile sans erreur et s'execute correctement sur l'ATMega328p.

Pour l'équipe 3 :

Cette partie sera traitée au S8.

L'objectif sera de créer une nouvelle table sans la base de données, permettant de récupérer les données venant des capteurs (des Raspberrys).
Il faudra également modifier le site afin d'ajouter une page permettant l'affichage de ces données.

Documents Rendus

Pré-Rapport : media: Rapport_P10_S7.pdf

Projet S8

Objectifs

Suite à la soutenance de projet en fin de S7, nous avons de nouveaux objectifs :

Equipe 1

Faire communiquer l'Arduino UNO et la Raspberry Pi dans les 2 sens ;
Créer le code pour le capteur de température et visualisation des données sur le port série avec minicom ;
Créer le code pour le capteur de distance et visualisation des données sur le port série avec minicom ;
Créer le script Python permettant le retour de données vers le serveur ;
Créer le Makefile générique ;
Intégrer la Nucléo dans le projet.

Equipe 2

Rendre Ansible fonctionel.

Equipe 3

Créer la page permettant de récupérer les données des capteurs par requête POST ;
Créer la fonction de mise à jour de la base de données.
Créer la table qui contiendra l'historique de valeurs ces capteurs ;
Créer les pages de recherche dans cet historique ;
Modifier la fonction de mise à jour de la base de données pour intégrer l'historique ;
Création des pages permettant l'ajout d'une raspberry ou d'un capteur ;
Création des fonctions associées ;
Créer le fichier inventaire.ini utile à l'équipe 2 à partir du site à l'ajout d'un capteur ou l'envoi d'un code ;
Migration du site et de la base données sur un nouveau serveur sur plil.fr ;
Créer les pages permettant l'affichage des graphes de valeurs des capteurs ;
Création des fonctions associées ;
Permettre le lancement d'Ansible depuis le site ;
Créer une page permettant la visualisation graphique de l'ensemble du réseau de capteurs et des caractéristiques de chaque nœud ;
Permettre aux administrateurs de créer et supprimer des comptes.

Réalisation

Equipe 1

Ici, il s'agira d'utiliser les capteurs afin d'obtenir des données "concrètes" à renvoyer à la RaspberryPi.
Il s'agira également, avant envoi au serveur (cf Équipe 3), de récupérer les données sur le port série de la Raspberry afin de les stocker dans les fichiers adéquats.

Objectif	État
Tester l'envoi de données sans capteurs avec la liaison USB	Fait
Tester l'envoi de données sans capteurs avec la liaison série UART TX/RX	Annulée, Obsolète
Intégrer le capteur de température et envoi des résultats au port série via USB	Fait
Intégrer le capteur ultrasons et envoi des résultats au port série via USB	Fait
Depuis la Raspberry, script de stockage des résultats dans fichier XML	Fait, Obsolète
Faire de même avec la Nucleo M4	Suspendue (qqs PBs techniques)
Depuis la Raspberry, modification du script python d'envoi des données au serveur pour distinguer automatiquement l'adresse IP et obtenir le numéro du capteur	Fait
Ajustement des codes capteur et Température de façon à ce qu'ils utilisent tout les deux une fonction généraliste de retour de données	Fait
Mise en place d'un unique makefile généraliste pouvant uploader le bon code selon le type de capteur	Terminé

Semaine 1

Retour des données

Dans un premier temps, nous devons chercher à récupérer les données issues des capteurs pour les transmettre à la RaspberryPi.
Dans un second temps, nous allons gérer la transmission des données de la RaspberryPi vers le serveur.

Pour le premier volet, nous allons commencer par réaliser un test (sans capteurs) et récupérer un caractère envoyé par l'Arduino UNO vers la Raspberry Pi en liaison série.

Pour se faire, plusieurs moyens s'offrent éventuellement à nous : l'utilisation du bus SPI ou de la liaison série par l'intermédiaire de l'USB (ou USART TX-RX). Nous avons opté pour cette dernière solution plus simple à mettre en place.

Notre premier test a été réalisé avec la liaison USB. Ainsi, nous avons flashé l'Arduino UNO avec un code (arduinoToRpi.c) permettant d'envoyer un caractère sur la liaison série et qui pourra être vu par la RaspberryPi.

Ce code est inspiré de celui utilisé dans le tutorat système du S7.

Pour lire ce qui se trouve sur la liaison série, nous avions plusieurs solutions.

La première était d'installer minicom sur la Raspberry, mais après plusieurs tentatives d'installation (car le réseau était plutôt défavorable à ce moment là), nous avons changé d'idée.
Deuxièmement, nous nous sommes penchés sur l'utilisation d'un script python minimaliste à l'aide du module "Pyserial", qui n'a pas fonctionné. Nous pensons que le problème n'est pas tant lié au code en lui-même, qui nous semble correct, mais en la configuration de la RaspberryPi.

#!/usr/bin/env python
import serial
ser = serial.Serial('/dev/ttyACM0', 9600, timeout=1)
while 1:
  print(ser.readline())

La troisième tentative fonctionnait. Nous avons récupéré un code C permettant de lire le port que nous souhaitions. Le caractère envoyé par l'Arduino a bien été récupéré.

Nous avons donc réussi à faire communiquer la Raspberry Pi et l'Atmega328P dans les deux sens.

Maintenant, l'objectif est de permettre le retour Atmega328P-->RaspberryPi non pas par USB mais en utilisant l'USART (via les broches Tx-Rx).

Semaine 2

La séance suivante, nous avons réglé le problème empêchant le script python de s'exécuter correctement. En effet, son exécution supposait un contrôle du port serie par l'intermédiaire du terminal, mais il fallait l'autoriser au préalable.

Démarrer l'utilitaire de configuration système de la Raspberry:

sudo raspi-config

Ouvrir les options d'interface serie
Choisir "oui" pour accepter le contrôle via le terminal

Nous avons ensuite mis à jour la Raspberry Pi avec la commande apt update Cette mise à jour a permis le téléchargement et l'installation de minicom. Il nous est donc plus facile de visualiser le contenu arrivant sur le port série.
Nous avons remarqué que la Raspberry Pi ne possédait qu'un unique UART. Ainsi, si nous voulons exécuter des scripts dans le terminal qui utilise le port série, nous ne pouvons pas en même temps récupérer les données via l'UART.
Pour résoudre cette difficulté, nous avons choisi de travailler avec un "soft uart". Celui-ci devrait nous permettre d'utiliser d'autre GPIOs de la Raspberry en tant que port série (TX, RX).

Nous avons donc utilisé un module créé par Adriano Marto, nous permettant de réaliser cette opération :

https://github.com/adrianomarto/soft_uart

Après le téléchargement, nous avons tenté de faire un "make" comme demandé. Cependant, il semblerait que la version du packet raspberrypi-kernel-headers que nous avons installé précedemment ne corresponde pas au noyau de notre Raspberry.
Le problème est que ce sont des téléchargements automatiques donc nous ne pouvons pas choisir la version.
La version du noyau étant inférieure à celle du packet, nous avons essayé la commande apt upgrade. Après la mise à jour, il semblerait que nous disposions déjà de la dernière version du noyau.

Semaine 3

Au démarrage de la Raspberry, nous avons lancé par hasard la commande uname -r. Nous avons été surpris de voir que la version du noyau correspondait maintenant à celle du packet raspberrypi-kernel-headers.
Nous avons donc tenté l'installation du soft uart, avec succès. Il nous fallait maintenant envoyer des données depuis l'Arduino UNO pour les récupérer via TX/RX.
Nous avons réalisé un diviseur de tension pour faire correspondre la tension des pins de l'Arduino UNO (5V) et de la Raspberry (3.3V).
Une fois les branchements faits, nous avons créé grâce à l'IDE Arduino un code utilisant la bibliothèque Serial.h. Ce code devait simplement envoyé un caractère sur la liaison TX/RX.

Là, nous avons rencontré un problème : nous ne recevions aucune donnée. Nous avons donc décidé de passer par les pins RX/TX de la Raspberry et de laisser de côté le soft uart.
Le problème persistant toujours, nous avons donc décidé de mettre provisoirement de côté la partie communication par RX/TX pour avancer sur le reste, car la communication par liaison USB série fonctionne correctement.

En étant connecté par liaison USB, l'objectif consistait maintenant à connecter les capteurs et ainsi transférer de vraies données à la Raspberry. Pour se faire, il nous fallait donc écrire les codes utiles pour tester ces capteurs en utilisant le langage C avec la librairie avr.

Test du capteur de température ST039:

Iduino ST039 (LM35)

Il est basé sur le LM35 et délivre un signal analogique variant entre 0 et 5V selon la température mesurée. La température résultante quant à elle se situe sur la plage 0-100°c avec une précision de 0.5°c.

Branchement :

Ci-dessous, le branchement avec une carte Arduino uno.

Branchement

Code :

Nous disposons déjà des fonctions d'envoi de caractères sur le port série. La principale difficulté de ce code résidait dans l'utilisation du convertisseur analogique-numérique afin de lire sur l'entrée analogique voulue.
Pour cela, nous avons créé une fonction (équivalente à AnalogRead() de L'IDE arduino) nous retournant le résultat numérique de la conversion.

int analogReadNew(uint_8 pin){
   //Selection de la fréquence du prescaler
   ADCSRA |= (1<<ADPS2)|(1<<ADPS1)|(1<<ADPS0);
   //Définition de la référence de tension
   ADMUX |= (1<<REFS0)|(1<<ADLAR);
   //Sélection de l'entrée analogique selon le pin
   ADMUX = (ADMUX&0xf0)|pin;
   //Activation de l'ADC 
   ADCSRA |= (1<<ADEN);
   //Lancement de la conversion
   ADCSRA |= (1<<ADSC);
   //On attend la fin de la conversion
   while(bit_is_set(ADCSRA, ADSC));
   //Résultat
   return ADCH;
 }

Ensuite, il nous fallait normaliser ce résultat afin d'avoir la température en degrés.

 reading=analogReadNew(0);
 temperature = reading * 1.9607843;
 //1.960743 = (5.0/1023.0)*100*4

La température était ensuite envoyée sur le port série pour être visible depuis la RaspberryPi.

Résultat

Résultats du test

Semaine 4

Cette quatrième semaine a servi à tester le capteur de distance et à intégrer les données recueillis par la Raspberry dans un fichier.

Test du capteur à ultrasons HC-SR04 :

HC-SR04

Ce capteur ultrason utilise le principe de fonctionnement d'un capteur laser mais se base sur des ondes sonores (inaudibles pour l'homme) à la place d'un faisceau lumineux. Il est beaucoup moins cher qu'un capteur laser, toutefois il reste imprécis. On note néanmoins que ses mesures restent insensibles à la luminosité ambiante et à l'opacité de la surface en face.
Le HC-SR04 fonctionne avec une tension d'alimentation de 5V, un angle de mesure d'environ 15° et permet (sur le papier) d'obtenir des mesures de distance variant de 2cm à 4m avec une précision de 3mm (en pratique, ce n'est pas si précis que cela).

Principe de fonctionnement :

En utilisant la vitesse du son, les étapes d'une prise de mesure sont les suivantes :

Une impulsion HIGH de 10µs est envoyée sur la broche TRIGGER du capteur.

Ensuite une série de 8 impulsions ultrasoniques est envoyée par le capteur

Puis, dans l'air, les ultrasons se propagent pour toucher un obstacle et font le chemin retour vers le capteur.

Enfin, le capteur capte l'écho et achève la prise de mesure.

Précisons que le signal présent sur le pin ECHO du capteur reste à HIGH durant les deux dernières étapes, permettant ainsi de connaître la durée de l'aller-retour des ultrasons et donc de déterminer la distance.

Fonctionnement

Branchement :

Branchement

Code :

Le code consiste à réaliser les étapes décrites ci-dessus et à transférer le résultat sur le port série. La seule difficulté ici réside dans la mise en place de l'acquisition du temps d'aller-retour. Pour cela, nous utiliserons un timer et nous procéderons par interruption (INT0) sur un changement logique.

 //Trigger = PIND0 et ECHO = PIND2
 DDRD = 0b11111011;
 _delay_ms(50);
 //Selection INT0
 EIMSK |= (1<<INT0);
 //Interruption sur changement logique
 EICRA = 0x01;
 sei();

Nous mettons en place le trigger :

 //TRIGGER HIGH
   PORTD |= 1<<PIND0;
   //Durée de l'impulsion TRIGGER
   _delay_us(10);
   //TRIGGER LOW
   PORTD &= ~(1<<PIND0);

À chaque interruption, nous mesurons la durée :

 ISR(INT0_vect){
   //i=1 indique l'écho HIGH
   if(i == 1)
   {
     //On arrête le timer
     TCCR1B = 0;
     //On stocke la valeur précédente du timer (l'aller-retour)
     pulse = TCNT1;
     //On reset la valeur de TCNT1 et de i à Zero
     TCNT1 = 0;
     i = 0;
   }
   
   //i=0 indique l'écho à LOW
   if(i==0)
   {
     //On set le bit CS10 à HIGH, debut du timer qui compte
     TCCR1B |= (1<<CS10);
     i = 1; 
   }
  }

La durée mesurée est ensuite normalisée et on effectue le calcul pour obtenir la distance (ici, en cm) qui sera ensuite envoyée sur le port serie.

 //On calcule la distance en cm : pulse/(58/2/10)  (en cm)
   count_a = pulse/1160.0;

La distance est ensuite envoyée sur le port serie pour être disponible sur la RaspberryPi.

Résultat :

Tout fonctionne correctement, ci-dessous un capture du résultat:

Résultat

Coté Raspberry : Préparation des résultats pour envoi au serveur

Ici, les résultats sont disponibles uniquement sur le port serie. Ce que nous voulons, c'est les stocker dans un fichier qui sera ensuite exportable vers le serveur. Pour cela, nous nous sommes entendus sur le format XML. En effet, comme il a été mentionné plus bas par l'équipe 3, nous devons avoir un fichier de cette forme :

 <capteur>
     <parametre name="ip_address">172.26.145.X</parametre>
     <parametre name="numero">Y</parametre>
     <parametre name="name">Nom</parametre>
     <parametre name="data">AB.C</parametre>
 </capteur>

Pour cela nous avons réalisé un script Python en usant du module serial et du module lxml pour créer des fichiers XML.

Installation du module lxml

 pip3 Install lxml

Le programme récupère la donnée sur le port série et la met à sa place préétablie dans un fichier xml de base existant.

 import serial
 from lxml import etree
 capteur = etree.parse("111-1.xml")
 ser = serial.Serial("/dev/ttyACM0", 9600, timeout = 1)
 
 value = ser.readline()
 while(value in ['\r', ]): 
      value = ser.readline()
 value = float(value)
 for parametre in capteur.getroot().getchildren():
      if "name" in parametre.attrib and parametre.attrib["name"] == "data":
          parametre.text = str(value)
 with open("111-1.xml", 'w') as myFile:
      capteur.write("111-1.xml")
 myFile.close()

Nous avons testé ce script et c'est fonctionnel. Nous sommes désormais capables de renvoyer les données issues des capteurs jusqu'au serveur.

Semaine 5

Retour des données par requête POST

Le retour des données étant effectif, cette cinquième semaine a été l'occasion de faire une petite démonstration à nos encadrants concernant l'aller (flash) et le retour des données.

Il en est ressorti une suggestion quant à la partie de l'équipe 1 :

- Au lieu d'utiliser un système de fichier au format XML, il nous a été suggéré d'utiliser une simple requête POST dans notre script python pour envoyer nos données. (cf Équipe 3 pour plus de détails).

Différenciation des capteurs

Pour notre retour de données, nous voulons diversifier nos cas de tests. En effet, nous aimerions avoir :

Cas 1 : un capteur de température ou de distance relié à une carte
Cas 2 : deux capteurs différents reliés à une même carte
Cas 3 : deux capteurs identiques reliés à une même carte

Il faut donc que nous soyons capables d'identifier clairement nos capteurs afin de pas confondre les données remontées.

[voir la méthode].

De cette façon, il nous sera plus facile d'identifier nos capteurs (en particulier dans les Cas 2 et 3). Le script python se chargera de découper la chaîne reçue pour extraire chacun des paramètres et ainsi faire la requête POST par la suite.

Semaine 6

Durant cette semaine, le travail consistait à trouver un moyen d'utiliser la carte nucleo, étant donné que nous n'en avons jamais manipulé.

Après s'être documenté, il est apparut qu'il y avait plusieurs solutions pour l'utiliser : Via des Environnements dédiés (tels que Mbed compiler en ligne et d'autres environnements Offline).
Seulement, la solution intéressante pour nous résiderait dans l'utilisation d'un outil pour compiler en ligne de commande. (tout comme avec les arduino). Pour se faire nous avons donc trouvé l'outil dédié, créé par ARM-MBED, à savoir mbed-cli qui comme (avr-gcc) permet la compilation et l'upload sur des architectures ARM (avec arm-gcc).

[Rajouter les portions codes pour les étapes d'installation de l'outil]

Un premier test d'upload de code pour faire clignoter une led a été concluant.

Problème

Suite à ce premier test, la carte, un fois connectée en USB, se déconnectait au bout de quelques secondes (testé sur mon pc tournant sous ubuntu 18.04). Donc impossible de re-upload à nouveau des codes.

Semaine 7

Pour cette semaine, l'objectif était de trouver une solution pour la Nucleo, et sinon mettre cette étape en attente pour avancer sur d'autres tâches.

N'ayant pas pu palier au problème de déconnexion sur mon pc personnel, Nous nous sommes dirigés directement sur la Raspberry pour effectuer les mêmes étapes. Le problème lié à la déconnexion n'en était plus un.
Cependant Nous avons rencontré quelques problèmes au début liés à la connexion, mais nous avons par la suite pu installer les composantes nécessaires. Toutefois, d'autres problèmes sont survenus, probablement liés à des dépendances de librairies incomplètes et de problèmes de versions, suite à quoi, nous avons décidé de mettre cette partie en attente, car pas strictement indispensable pour un test complet (en effet, nous pourrions d'abord nous servir d'une autre carte Arduino en remplacement).

Coté Raspberry (optimisation du script)

Dans cette partie, il s'agissait d'optimiser le code du script python d'envoi des données au serveur afin qu'il puisse identifier automatiquement l'adresse IP de la Raspberry et aussi identifier directement le numéro du capteur concerné (et non pas les renseignées manuellement en DUR comme nous l'avons fait lors de notre test initial).
Pour plus de précisions sur le système d'identification du numéro du capteur (voir Equipe 3, Semaine 5 et 6).

Le script était parfaitement fonctionnel.

Semaine 8 | Confinement

Durant cette semaine, comme l'a expliqué l'Equipe 3, nous avons branché des Raspberry avec quelques capteurs en salle de projet.

Nous (Equipe 1 et 3) avons repensé quelques détails de notre circuit de travail de manière à mieux se connecter avec l'Equipe 2 (Ansible), vous pourrez voir l'Equipe 3 (Semaine 5-6) pour des détails sur le système d'identification des capteurs.

Raspberry : Création d'un makefile générique

L'idée est d'automatiser l'attribution (upload) d'un code au capteur adéquat. Pour cela nous avons mis en place la base du fichier makefile qui est fonctionnelle.
Pour que cette partie soit complète il nous reste à rajouter les directives nécessaires en fonction du numéro du capteur (qui est une variable extérieure au makefile, vu que ce dernier est générique) et lancer l'upload adéquat.

Nous avons donc modifié le makefile (disponible sur le Git) afin qu'il lance un Upload spécifique en fonction du numéro du capteur et de la méthode d'upload (via USB ou via SPI pour des cartes Arduino).
Nous avons volontairement omis de gérer la carte Nucléo dans le Makefile pour le moment. Nous allons donc passer en phase de test (avec les autres équipes).

Confinement (Suite)

Durant cette semaine, il a été question de tester les fonctionnalités développées par cette équipe en l'interconnectant avec celles des autres équipes. Nous avons effectué une démonstration en live sur Discord en présence de M. Vantroys. La démonstration a été concluante, et nous avons tenu compte des remarques données afin d'optimiser notre travail.

Fixer précisément des capteurs à des Ports USB de la Raspberry

Prenons le scénario suivant : Lorsque nous avons plusieurs périphériques (ici ce sont les capteurs via les microcontrôleurs) connectés aux différents ports USB de notre Raspberry. Supposons qu'il y ait un redémarrage de la Raspberry ou simplement un débranchement suivi d'un branchement de nos périphériques, là, nous ne pourrons pas déterminer quels ports USB (ttyACMX) leurs seront attribués à nouveau.
Ainsi, un capteur précédemment branché sur ttyACM0 pourrait se voir attribuer le port ttyACM1 et donc les remontées de données poseraient de sérieux problème à notre système. Nous devions donc trouver un moyen de lier un capteur (plus exactement un microcontrôleur) à un port USB bien déterminé, afin qu'aucun redémarrage ni re-branchement ne puisse lui en attribuer un autre.

Pour se faire, voici comment procéder :

Déterminer les périphériques branchés

Le but ici est de déterminer quel périphérique a été lié à quel port USB. La meilleure façon c'est de débrancher les périphériques et de les rebrancher un par un. Dans un cadre de test, nous avons travailler avec l'une des Raspberry branchées en salle projet (172.26.145.113 sur laquelle il est connecté un Arduino avec un capteur).

 dmesg | grep ttyACM

Périphérique connecté

Sur le résultat de cette commande, nous allons noter quelques informations utiles pour la suite. La première chose à noter ce sont les chiffres juste après "cdc_acm" (1-1.5) et la deuxième consiste à retenir le numéro de port attribué (ici ttyACM0). Nous devons aussi penser à donner un nom qui nous permettra de reconnaître notre périphérique à chaque fois qu'il sera connecté : ici je lui donnerai le nom "ttyACM_ARDUINO_TEMP" car un capteur de température y est lié.

Recherche d'attributs

Afin de reconnaître plus tard de façon unique notre périphérique, il nous faudra nous servir d'attributs spécifiques permettant d'identifier ce périphérique parmi tant d'autres. Cela peut être l'identifiant du fournisseur ou le numéro de série.

 udevadm info --name=/dev/ttyACM0 --attribute-walk

Attributs

Il faut retrouver les chiffres notés précédemment "1-1.5". Nous avons choisi de baser notre identification uniquement sur les attributs Serial, idVendor et idProduct (bien évidemment il est possible d'en rajouter plus). Nous notons les noms et les valeurs des attributs pour les utiliser par la suite.

Création du fichier de règles de noms de ports

Ici nous allons faire la liaison entre le périphérique et le port USB. Pour se faire, il nous faut créer un fichier qui encapsulera les règles nécessaires pour l'attribution d'un port spécifique à notre périphérique en fonction des attributs.

 sudo nano /etc/udev/rules.d/usb-serial.rules

Fichier de règles

Chargement des nouvelles règles

Pour rendre effectif les règles

 sudo udevadm trigger

Vérification des nouveaux noms de ports

 ls -l /dev/ttyACM*

Fichier de règles

Ainsi nous pouvons voir le nouveau nom apparaître à la place du nom classiquement attribué "/dev/ttyACMX". Ce nom peut désormais être utiliser dans nos scripts pour désigner ce périphérique, et cela même après un redémarrage. De cette manière la gestion des ports USB peut donc être beaucoup plus stabilisée désormais.

Script generique de fixation des périphériques aux ports

Pour terminer, nous avons devéloppé un script générique qui pourra être déployer depuis ansible sur les Raspberry Pi. Ainsi, au lieu de le faire manuellement pour chacun des périphériques, il suffira de la lancer depuis ansible pour que le script puisse écrire lui même les fichiers de règles selon le périphérique correspondant.

Vous pourrez voir le détail du code dans le git (fichier port.sh).

Récupération du code d'identification du périphérique

 data=$(dmesg | grep ttyACM | cut -f 7 -d " " | cut -f 1 -d : )
 code=$(echo $data | cut -f 1 -d " ")

On détermine quel numéro de port lui attribuer (Ex: capteur1-1 -> port 0)

 port=$(pwd | cut -c 17)
 let port--
 dev="/dev/ttyACM"
 name="$dev$port"

Récupération des attributs

 commande=$(udevadm info --name=$name --attribute-walk | egrep "idVendor|idProduct|serial")
 idProduct=$(echo $commande | cut -f 1 -d " ")
 idVendor=$(echo $commande | cut -f 2 -d " ")
 serial=$(echo $commande | cut -f 3 -d " ")

Attribution d'un nouveau nom de port (ttyPRX à la place ttyACMX)

 newdev="ttyPR"
 newname="$newdev$port"

Écriture des règles

 rule="SUBSYSTEM==\"tty\", $serial, $idVendor, $idProduct, SYMLINK+=\"$newname\""
 echo $rule >> /etc/udev/rules.d/usb-serial.rules
 udevadm trigger

Nous avons donc testé notre script depuis Ansible sur une Raspberry Pi à laquelle est fixé un capteur (via une carte Arduino) mais également sur une Raspberry Pi avec deux périphériques (deux capteurs sur deux Arduino). Les tests sont concluants.

Equipe 2

Semaine 1

Recherches concernant Ansible

Interet d'utiliser Ansible par rapport à d'autres logiciels : Il fonctionne en python (Chef et Puppet utilisent ruby) Si nous voulons utiliser Python 3 (car python 2 n'est plus maintenu depuis le premier janvier) il nous faut Ansible 2.5 ou supérieur.

On pourrait utiliser "python-virtualenv" pour faciliter la compatibilité de nos scripts entre les versions de nos logiciels ou utiliser docker

Il n'est pas nécessaire d'installer Ansible sur chaque nœud (dans notre cas les raspberry pi) seulement sur un serveur qui sera notre "node manager" (Ce dernier devant etre un système UNIX). Les noeuds devront juste permettre le ssh. Le reste pourra etre installé grace à Ansible.

le node manager doit pouvoir connaître les adresses IP de ses nodes. (dns ou fichier /ect/hosts) Utilisation de clé ssh pour sécuriser la communication (ex : ssh-keygen -t ecdsa)

Semaine 2

Ce qu'il faut définir pour aller plus loin :

Comment récupère-t-on la liste des adresses des nodes à paramétrer
Quels sont les logiciels à installer ainsi que les paramétrages à effectuer pour notre application.
Ansible doit il également déployer les codes sur les raspberry pi, si c'est le cas, peut il etre appelé automatiquement par le serveur web ?

Les commandes ansibles pourront être exécutée par script bash (faut-il séparer le setup des cartes et l'update de code ?)

On peut copier le code sur chaque machine (ou groupe de machine) en utilisant le module "copy" d'ansible.

Ansible peut également exécuter des scripts shell sur les machines distantes : module "shell".

Il serait utile d'utiliser le module "docker_container" pour permettre un versioning facile et supprimer les problèmes de compatibilité.

Ensuite il semblerait qu'Ansible puisse réagir à des événements grâce à l'utilisation de "wait_for". Dans notre cas, cela serait utile pour envoyer les codes au raspberry pi lorsqu'on le souhaite.

Dans mon idée actuelle :

Ansible met en place les raspberry pi pour qu'ils soient pret à exécuter du code
Ansible envoi le code sur les raspberry pi (Quand un utilisateur le demande).
Les raspberry pi renvoient leurs données directement au serveur principal.

Semaine 3

Premiers pas avec Ansible :

Installation de la dernière version d'Ansible à l'aide de pip :

pip3 install ansible

Il faut donc avoir python 3.5+ installé, possibilité de choisir la version d'ansible (pip3 install ansible==2.9.4)

On peut vérifier si l'installation est correcte avec la commande :

ansible --version

Pour communiquer avec nos nœuds on va les renseigner dans le fichier /etc/hosts. Exemple dans notre cas on ajoute les lignes:

172.26.145.112  rasp1
172.26.145.113  rasp2

Il faut enfin créer un fichier inventaire.ini pour référencer nos nœuds, il est pour le moment très simple :

rasp1
rasp2

La seule chose qu'il y a à faire sur le raspberry pi est d'activer le ssh, de régler son adresse ip et de lui donner une connexion internet.

Première commande Ansible. Un simple ping permet de voir si on arrive bien a communiquer avec notre nœud :

ansible -i inventaire.ini -m ping rasp1 --user pi --ask-pass

-i inventaire.ini : chemin vers le fichier d'inventaire

-m ping rasp1 : action à effectuer sur la cible

--user pi : choix de l'utilisateur qui se connecte

--ask-pass : demande du mot de passe ssh

On peut commencer à paramétrer nos nodes. On utilisera pour le moment des lignes de commandes et pas des fichiers playbooks.

Installation de python3 :

ansible -i inventaire.ini -m raw -a "sudo apt-get install python3 -y" rasp1 --user pi --ask-pass

Installation de WiringPi :

ansible -i inventaire.ini -m raw -a "sudo apt-get install wiringpi -y" rasp1 --user pi --ask-pass

-m raw : pour envoyer une ligne de commande à lancer sur la cible

-y dans le apt-get : permet de valider la demande d'utilisation d'espace sur le disque

Autre possibilité pour la connexion :

On utilise sudo car l'utilisateur pi peut avoir les droits administrateur. On pourrait également utiliser cette commande en demandant une élévation de privilèges :

ansible -i inventaire.ini -m raw -a "apt-get install python3 -y" rasp2 --user pi --ask-pass --become --ask-become-pass

On pourrait enfin se connecter directement en utilisateur root, mais cela demanderait plus de préparation sur le raspberry pi :

-Editer le fichier: sudo nano /etc/ssh/sshd_config
-Trouver la ligne: PermitRootLogin without-password
-Editer: PermitRootLogin yes (enlever le # de commentaire)
-Fermer et sauvegarde le fichier
-restart du service sshd: /etc/init.d/ssh restart
-Mettre un mot de passe root: sudo passwd root

L'idée maintenant serait de supprimer la demande de mot de passe en utilisant le système des clé de sécurité ssh.

Pour créer une clé ssh de type rsa 2048 bits :

ssh-keygen

On n'indiquera pas de passphrase pour permettre un reboot automatique du serveur ansible.

On va ensuite envoyé notre clé publique sur nos noeuds :

ansible -i inventaire.ini -m authorized_key -a 'user=pi state=present key="{{ lookup("file", "/home/pifou/.ssh/id_rsa.pub") }}"' --user pi --ask-pass --become --ask-become-pass all

user=pi correspond à l'utilisateur auquel on donne notre clé

/home/pifou/.ssh/id_rsa.pub correspond au chemin où la clé à été enregistré

all que l'on envoie à toutes les nœuds du fichier inventaire.ini

Maintenant on n'a plus besoin d'utiliser l'option --ask-pass.

Semaine 4

Un des buts de cette semaine est de créer le fichier d'inventaires de nos nodes Ansible. Cependant nous voulons le rendre dynamique : le fichier contiendrait uniquement la liste des nodes à mettre à jour.

Une idée pourrait être que le site web, lors d'une demande de modification des nœuds, envoi le fichier d'inventaire par scp en utilisant par exemple la commande php : "ssh2_scp_send"

L'idée serait, sur le serveur Ansible, de vérifier si le fichier inventaire.ini à bien été déposé. On utilisera un playbook contenant :

---
- name: Wait until the file /home/pifou/inventaire.ini
  hosts: 127.0.0.1
  tasks:
    - wait_for:
       path: /home/pifou/inventaire.ini

Ansible va attendre d'avoir le fichier inventaire.ini avant de continuer son exécution.

On pourra ensuite appeler nos playbook de paramétrage. Exemple avec un simple ping :

---
- name: Ping
  hosts: all
  remote_user: pi
  tasks:
    - ping:

Pour le lancement du code on pourra utiliser un script bash :

#!/bin/bash
trap exit SIGINT
while [ 1 ]
do
ansible-playbook playbooktest.yml
ansible-playbook taskPing.yml -i inventaire.ini
rm inventaire.ini
done

Semaine 5

Cette semaine nous allons essayer d'avancer sur les playbooks pour l’installation de tous les composants sur nos nœuds Ansible.

On voudrait que le fichier inventaire.ini nous donne les informations sur les choses à installer : cela devrait surtout dépendre de ce qui est connecté à la raspberry pi (Arduino ou autre).

Dans l'idée le fichier devrait contenir des groupes tel que [arduino] ou [nucleo] et contenant les ip des machines qu'il faut mettre à jour.

On veut donc que les playbooks s'exécutent suivant le groupe (le type) de machine.

Résultat :

Plusieurs rôles ont été créé : arduino_Setup/nucleo_Setup/arduino/nucleo

Les deux premiers serviront pour préparer les cartes arduino pour pouvoir utiliser des arduino ou des nucleo.

Les deux suivant sont les rôles de production : ils copieront les fichiers, lanceront la compilation pour les scripts d’exécution.

Un premier playbook de mise en place pour les arduino à été commencé. Il permet de mettre en place le proxy, installe python3, minicom, wiringpi, avrdude.

---
- name: Copy file for proxy setup
  copy:
    src: ../files/proxy.conf
    dest: /etc/apt/apt.conf.d/proxy.conf
    owner: root
    group: root
    mode: '0644'

- name: "verif install python3"
  apt:
    name: python3
    state: present

- name: "verif install minicom"
  apt:(sûrement un ou plusieurs codes C)
    name: minicom
    state: present

- name: "verif install wiringpi"
  apt:
    name: wiringpi
    state: present

- name: "verif install avrdude"
  apt:
    name: avrdude
    state: present

Semaine 6

La totalité des logiciels et packages à installer sur le raspberry pi ont été ajoutés sur le playbook d'installation (un fichier yaml séparé pour mieux se retrouver dans le code ) : python3, pip3, wiringpi,avrdude, lxml pkg, requests pkg, pyserial pkg.

Il sera très facile d'ajouter un nouveau paquet si nécessaire.

Pour la partie installation il faut encore transférer les fichiers sur les raspberry pi (makefile ...)

Le rôle de fonctionnement en "production" à été ajouté. Il aura pour but de transférer le fichier binaire à compiler et de lancer le script bash de fonctionnement. Avec le fonctionnement conditionnel on peut également avoir plusieurs capteurs qui travaillent en même temps.

Pour l'instant le fichier est récupéré sur le site web. Cela pourrait changer si nécessaire (utilisation de la fonction "copy").

---
- name: "envoyer du fichier binaire.c"
  get_url:
    url:  http://serveur-etu.polytech-lille.fr/~grouille/PROJET/upload/binaire.c
    dest: /home/pi/capteur{{capteur}}/binaire.c
    mode: '0644'

Enfin le fichier inventaire.ini a prit sa forme "définitive". On retrouvera ainsi les adresses IP des raspberry pi à mettre à jour (setup ou prod) avec l'information du capteur.

[Arduino_init]
172.26.145.112 capteur=1
172.26.145.113 capteur=2

[Arduino]
172.26.145.112 capteur=1

Pour l'instant nous n'arrivons pas à utiliser correctement ansible pour le lancement de nos scripts bash. Cela vient du fait qu'ils contiennent des boucles infini et que Ansible attend la fin de l'exécution.

Semaine 7

Nous arrivons à bien envoyer les fichiers sur les raspberry pi. Pour chaque capteur on va donc créer un dossier qui contiendra tous les fichiers de code et de lancement. Pour le moment on récupère également le fichier zip sur le serveur.

- name: "Creation des dossiers pour le capteur"
  file:
    path: /home/pi/capteur{{capteur}}
    state: directory

- name: "Download and unzip files"
  unarchive:
     src: http://serveur-etu.polytech-lille.fr/~grouille/PROJET/fichiersRPI/fichiersRPI.zip
     dest: /home/pi/capteur{{capteur}}
     remote_src: yes

Nous avons enfin réussi à lancer correctement les fichiers bash avec ansible. Le problème était la boucle infini et également que le processus s’arrêtait lorsque ansible quittait le nœud.

Du coté ansible l'appel est assez classique :

---
- name: Lancer le fichier bash
  hosts: all
  remote_user: pi
  become: yes
  tasks:
     - shell: /home/pi/capteur3/lancer.sh

La modification importante est la création du fichier lancer.sh qui va lui appeler le script en mode nohup ( et kill le processus s'il existait déjà) :

#!/bin/sh

kill $(cat /var/run/script.pid)
base=`dirname $0`
nohup $base/script.sh &

Pour récupérer le pid de script.sh il faut ajouter en haut dans ce script la ligne :

echo $$ > /var/run/script.pid

Confinement

Avec l'arrivée du Coronavirus nous avons besoin de migrer notre projet sur un autre serveur. Il est disponible au 172.26.189.200 avec nos fichiers dans /var/www/html/P10.

Les fichiers seront mis à jour en utilisant notre repository git.

Les différents fichiers envoyé sur les Rpi étaient tout d'abord téléchargé sur le site. Puisque nous travaillons en local ce n'est plus nécessaire, les téléchargements ont été remplacé par de simple copier/coller.

Ajout des fichiers et logiciels à installer sur les cartes lors de la première mise en place. (avr-dude/avr-gcc/avr-libc et fichier de config pour les GPIO)

Un problème qu'il nous reste à régler est l'automatisation du transfert des clés ssh du serveur vers les cartes raspberry. Actuellement ce processus n'est pas automatique. (Après discution avec M.Redon et M. Vantroy ce ne serait finalement pas nécessaire de réaliser cette tache.)

Début de la rédaction du rapport et corrections de quelques erreurs présent du côté de Ansible.

Utilisation de Cron afin d'automatiser le lancement du fichier Rpi_to_server.py

Nous nous sommes intéressés à Cron afin d’améliorer un peu plus notre projet. L’objectif de l’utilisation de Cron est d’automatiser le lancement du fichier Rpi_to_server, initialement lancé grâce à une boucle infinie.

Tout d’abord, Cron est un programme qui permet aux utilisateurs d'exécuter automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiée à l'avance, ou selon un cycle prédéfini.

Il a fallu dans un premier temps se renseigner sur l’utilisation de Cron. Dans la table appelée Crontab, chaque ligne correspond à une tâche à exécuter et doit respecter cette notation : mm hh jj MMM JJJ tâche

mm représente les minutes (de 0 à 59)
hh représente l'heure (de 0 à 23)
jj représente le numéro du jour du mois (de 1 à 31)
MMM représente l'abréviation du nom du mois (jan, feb, ...) ou bien le numéro du mois (de 1 à 12)
JJJ représente l'abréviation du nom du jour ou bien le numéro du jour dans la semaine

Pour chaque valeur numérique (mm, hh, jj, MMM, JJJ) les notations possibles sont :

* : à chaque unité (0, 1, 2, 3, 4…)
5,8 : aux unités 5 et 8
2-5 : aux unités de 2 à 5 (2, 3, 4, 5)
*/3 : toutes les 3 unités (0, 3, 6, 9…)
10-20/3 : toutes les 3 unités, entre la dixième et la vingtième (10, 13, 16, 19)

Exemple :

0 0 13 1 5 tâche

La tâche sera exécutée le 13 janvier et tous les vendredis.

Il a fallu tout d’abord tester l’utilisation de la Crontab. Pour cela, nous avons créé un script très simple composé seulement d’un echo afin d’afficher "Bonjour". Puis nous avons modifié la Crontab à l’aide de la commande crontab -e. Nous avons donc ajouté une tâche à celle-ci et nous avons redirigé la sortie du script vers un fichier sauvegarde.txt afin de s’assurer de son bon fonctionnement.

Tâche ajoutée :

* * * * * /home/eymeric/test.sh >> /home/eymeric/sauvegarde.txt

Une fois les premiers pas sur Crontab effectués, il nous a fallu trouver un moyen de lancer celle-ci sans passer par la commande crontab -e. Nous avons donc utilisé dans un premier temps la commande

crontab <<<"* * * * * /home/pi/capteur1-0/python.sh /home/pi/capteur1-0"

Cette commande se lançant dans un script shell et permettant de mettre à jour la Crontab. Le lancement du fichier Rpi_to_server.py se faisait de manière automatique comme souhaité initialement et le serveur recevait les données du capteur tous les intervalles de temps définis.

Un seul problème restait en suspens qui était : comment ajouter ou supprimer une ligne de la Crontab lors de l’ajout ou la suppression d’un capteur par le serveur car cette commande supprimait le contenu de la Crontab puis écrivait dans celle-ci.

Suppression d’une ligne :

crontab -l | grep -v $pwd | crontab -

Ajout d’une ligne :

(crontab -l ; echo "*/$tps * * * * $pwd/python.sh $pwd") | crontab -

Cette nouvelle option de suppression de ligne nous permettant d’ajouter une nouvelle option pour les chercheurs sur le serveur permettant de supprimer un capteur qui avait été lancé préalablement. Cela permet au chercheur d’arrêter le script une fois que celui-ci n’en a plus besoin.

L’utilisation de la Crontab nous a permis d’automatiser le lancement du fichier Rpi_to_server.py et ainsi de contourner l’ancienne utilisation d’une boucle infinie dans le script shell lancé par Ansible. L’ajout de deux lignes de commandes dans le fichier shell, une permettant la suppression et l’autre permettant l’ajout d’une tâche dans la Crontab, a permis le fonctionnement de plusieurs capteurs en simultané mais aussi la suppression d’un capteur sans impacter le retour des valeurs d’un autre capteur actif.

Equipe 3

Objectif	Etat
Créer une page web dynamique (rafraîchissement des données).	Fait
Créer des fichiers "de retour" vides sur le serveur pour chaque capteur.	Fait
Créer un Makefile pour automatiser l'envoi jusqu'au microcontrôleur.	Fait
Créer un script permettant la compilation et l'upload des fichiers grâce au Makefile.	Fait
Permettre l'ajout d'un capteur sur le site.	Fait
Créer un script PhP permettant d'entrer les données présentes dans les fichiers dans la base de données (lié au dynamisme de la page).	Obsolète
Modifier le script shell pour lui permettre d'envoyer les fichiers de données des capteurs en ssh sur le serveur.	Obsolète
Mettre sous forme de fichier .ini les données relatives à l'identification des Raspberry Pi et des capteurs sélectionnés sur le site.	Fait
Faire un requête POST depuis les Raspberry pour envoyer les données sur le serveur.	Fait
Modifier le site et la base de données pour créer un historique des valeurs des capteurs.	Fait
Rendre accessibles depuis le site les données historiques des capteurs, et créer un système de filtre.	Fait
Permettre la sélection de plusieurs capteurs de même type depuis le site.	Fait
Migrer le site sur le nouveau serveur 172.26.189.200.	Fait
Lancer Ansible depuis le site.	Fait
Créer un graphe pour chaque capteur en fonction des X dernières valeurs.	Fait
Ajouter une page plus "graphique" sur le site permettant l'affichage des différents noeuds de capteurs et de leurs caractéristiques.	Fait
Permettre l'ajout et la suppression de comptes depuis les comptes administrateurs.	Fait
Remonter les erreurs aux utilisateurs.	Fait
Permettre l'arrêt d'un capteur.	Fait

Semaine 1

Makefile et script shell

Nous avons créé un Makefile à l'aide du cours de PSR.
De ce fait, il nous suffit maintenant de faire un make upload pour envoyer le code sur l'Arduino UNO.
Le script load.sh a été légèrement modifié pour que le programme fonctionne correctement (voir le git).

Maintenant, tout est automatisé de l'envoi du fichier à partir du site web jusqu'à l'exécution du programme sur l'ATMega328p.

Semaine 2

Modification du site Web

L'objectif de cette partie est de mettre à jour le site pour qu'il puisse afficher les données reçues par les capteurs.
Pour se connecter à la base de données depuis un terminal, il est maintenant nécessaire d'entrer la commande : psql -h serveur-etu.polytech-lille.fr -U grouille projetCapteurs avec le mot de passe postgres.
Depuis un navigateur Web : https://pgsql.polytech-lille.fr/
Dans un premier temps, il faut ajouter une nouvelle table dont le contenu reste à déterminer en fonction de ce que retourne les Raspberry comme données.

Nous avons décidé de choisir d'utiliser 3 Raspberry Pi, sur lesquelles se trouvent respectivement :

Un Arduino UNO avec un capteur de température et un capteur de distance ;
Un Arduino UNO avec un capteur de température ;
Un Nucléo M4 avec un capteur de distance.

Pour repérer les capteurs depuis le site, au travers des Raspberry, elles sont maintenant liées à leur adresse IP et chaque capteur a un numéro sur la Raspberry.
Il serait intéressant de permettre l'ajout d'une Raspberry depuis le site, en permettant l'ajout de celle-ci dans la liste ainsi que des capteurs qui lui seraient liés.

Envoi des données sur le serveur

La première idée que nous avons eu était de passer par une connexion ssh entre la Raspberry envoyant les données et le serveur.
Les données seraient ainsi toujours stockées au même endroit sur le serveur et l'envoi serait conditionné d'une simple connexion internet, de la même manière que pour la réception du code.
Il reste à voir avec l'équipe 2 comment Ansible gère le déploiement des codes et le retour de données.

La deuxième idée est de créer un script PhP directement sur les Raspberry (déployé par Ansible).
Ce script permettrait la connexion au serveur et mettrait automatiquement la base de données à jour.
Plusieurs questions se posent alors :

Peut-on exécuter un script PhP directement dans le shell ?
Peut-on utiliser un code HTML pour l'exécuter dans le cas contraire ?
Serait-il plus propre d'envoyer les données au serveur en ssh et de les traiter par un script qui s'y trouve ?

Le plus intéressant et pratique serait la dernière option. Une connexion ssh entre chaque Raspberry Pi et le serveur s’établirait à chaque fois qu'une valeur de capteur est mise à jour.
Ainsi, lorsqu'on se trouve sur la page de site où se trouvent les valeurs affichées, il faudrait trouver un moyen dynamique de rafraîchir les données pour que les dernières arrivées soient prises en compte.

Semaine 3

Script d'envoi de données par SSH - Obsolète

Pour envoyer les données par SSH, nous allons utiliser le protocole SCP.
Pour se faire, nous devons configurer pour chaque raspberry une connexion SSH via des clés RSA, afin de ne pas devoir entrer manuellement un mot de passe.
Nous avons suivi ce tutoriel : https://geekeries.org/2016/10/transferts-scp-sans-mot-de-passe/?cn-reloaded=1&cn-reloaded=1. Il faudra que cette opération soit effectuée sur chaque Raspberry via Ansible.

Nous allons copier les données vers le serveur. Ces données seront sous forme de fichier XML ayant un nom précis : ip-capteur.xml, de manière à pouvoir avoir plusieurs fichiers de données.
Le fichier XML sera de la forme :

<?xml version='1.0' encoding='UTF-8'?>
<capteur>
    <parametre name="ip_address">172.26.145.X</parametre>
    <parametre name="numero">Y</parametre>
    <parametre name="data">AB.C</parametre>
    <parametre name="date">Date</parametre>
</capteur>

Les données y seront entrées par un script Python.

La commande SCP est la suivante :

SCP /home/pi/Desktop/ip-capteur.xml grouille@houplin.studserv.deule.net:/home/peipa1/grouille/public_html/PROJET/data/

Pour que la copie par SCP fonctionne, il faut retirer tous les 'echo' dans le bashrc sur le serveur.

Nouvelle manière de mettre à jour la base de données

Il nous a été proposé d'utiliser une requête POST pour mettre à jour la base de données, à la place du système décrit précédemment.
Nous avons donc modifié le script Python de l'équipe 1 pour y intégrer cette requête :

params = {"ip_address":"172.26.145.111", "numero":"2", "data": data, "date": Date}
r = requests.post("http://serveur-etu.polytech-lille.fr/~grouille/PROJET/requests.php", data = params)

Cette requête permet l'envoi des données sur le serveur. Un script PhP (requests.php) récupère les données et utilise la fonction update_bdd(), qui met à jour la base de données.
De cette manière, chaque Raspberry est indépendante et peut envoyer des données lorsqu'elle le souhaite.
Les requêtes SQL d'update s'exécuteront tour à tour grâce au système de verrous.

Semaine 4

Script PhP/SQL permettant la mise à jour de la base de données

Pour permettre la modification de la base de données et l'affichage de celle-ci sur le site, il nous faut 2 fichiers PhP supplémentaires et une fonction.
Le premier (data.php) sert "seulement" à vérifier que l'utilisateur est bien connecté au site, et à importer le fichier PhP contenant les fonctions utiles.
Il permet également le rafraîchissement de la page toutes les 10 secondes (balise meta).

Le second fichier (values.php) contient deux choses :

Un tableau fabriqué à partir de requêtes SQL permettant l'affichage des données ;
L'appel à la fonction de mise à jour update_bdd().

Nouvelle manière de mettre à jour la base de données

Il nous a été proposé d'utiliser une requête POST pour mettre à jour la base de données, à la place du système décrit précédemment.
Nous avons donc modifié le script Python de l'équipe 1 pour y intégrer cette requête :

params = {"ip_address":"172.26.145.111", "numero":"2", "name":"Solaris", "data": data}
r = requests.post("http://serveur-etu.polytech-lille.fr/~grouille/PROJET/requests.php", data = params)

Cette requête permet l'envoi des données sur le serveur. Un script PhP (requests.php) récupère les données et utilise la fonction update_bdd(), qui met à jour la base de données de la même manière que update_values().
De cette manière, chaque Raspberry est indépendante et peut envoyer des données lorsqu'elle le souhaite.
Les requêtes SQL d'update s'executeront tour à tour grâce au système de verrous.

Semaine 5

Historique des capteurs

Table history

Nous avons créé un système d'historique qui enregistre la date et l'heure de chaque relevé dans une nouvelle table.
Nous allons créer un système de recherche et rendre accessible ces données à partir du site.

En arrivant sur la page de recherche, plusieurs possibilités :

Sélectionner un capteur spécifique ;
Sélectionner un type de capteur ;
Sélectionner une adresse IP ;
Sélectionner un intervalle de dates ;
Sélectionne un nombre maximum de résultats.

Il est possible de combiner tous ces critères pour affiner les recherches.
On obtient un tableau contenant les informations utiles des capteurs.

Ajout d'un capteur depuis le site

Nous avons créé une page permettant d'ajouter un capteur à la liste des présents.
La requête est fonctionnelle et gère les doublons dans la table.
Il reste à utiliser Ansible dans cette partie pour ajouter les fichiers de base sur une Raspberry si elle n'existait pas avant.

Semaine 6

Migration sur un autre serveur

Lien du site : http://projet-p10.plil.fr/IMA3_P10/site
Fichiers raspberry : http://projet-p10.plil.fr/IMA3_P10/site/fichiersRPI

Pour continuer d'utiliser la base de données liée à notre projet, nous avons choisi d'installer PostgreSQL sur le nouveau serveur et d'y recopier l'ancienne base de données.
Elle est maintenant accessible depuis le serveur 172.26.189.200 avec la commande : psql -h localhost -U grouille projetCapteurs et le mot de passe postgres.

Par ailleurs, nous avons ajouté dans la table capteurs le numéro de version du capteur (en lien avec la connectique utilisée) :

0 : le capteur est branché en USB sur un Arduino UNO ;
1 : le capteur est branché en SPI sur un Arduino UNO ;
2 : le capteur est branché en USB sur une Nucléo M4 (optionnel pour le moment).

Création du fichier .ini à partir du serveur

Pour l'utilisation d'Ansible, il nous faut créer un fichier inventaire.ini lorsque l'on crée un nouveau capteur et lorsque l'on veut envoyer du code sur un ensemble de capteurs.
Pour cela, on a défini des balises :

[Arduino], [Arduino_spi] et [Nucleo] pour l'envoi de code ;
[Arduino_init], [Arduino_spi_init] et [Nucleo_init] pour la création de capteurs.

Nous avons différencié 3 versions de capteurs selon la carte sur laquelle ils sont branchés et selon la connectique utilisée entre la carte et la raspberry. Ces versions sont stockées dans la base de données sous forme numérique (0, 1 ou 2) et vont permettre le choix du bon mode de transfert du code sur les cartes (choix du bon Makefile ou choix de version dans un même Makefile, à déterminer par l'équipe 1).

De plus, nous considérons qu'au premier ajout de capteur sur une raspberry, il faudra faire des installations sur celle-ci (appelées "setup" par l'équipe 2). De ce fait, si le setup a déjà été effectué sur une raspberry, la variable setup sera égale à 0. Elle vaudra 1 dans le cas contraire et permettra le setup.

Admettons que l'on veuille envoyer un code sur le capteur 2 connecté en SPI à la raspberry d'adresse 172.26.145.111.
Le fichier inventaire.ini ressemblerait à ça :

[Arduino_spi]
172.26.145.111 capteur=2-1 setup=0

De cette manière, on pourra récupérer facilement le numéro du capteur et sa version sur la raspberry pour le traitement des données.
On saura également si la Raspberry sur laquelle est le capteur est déjà prête à recevoir les codes.

Confinement

Durant ces semaines de confinement, nous voulions continuer de travailler sur le projet.
Nous avons connecté 2 raspberry (172.26.145.111 et 172.26.145.113) sur le réseau de l'école avec les capteurs qui leur sont liés.
De plus, nous avons mis en place un dépôt git sur le serveur qui nous permet de travailler chez nous et de mettre à jour nos données avec un simple git pull.

Lancement d'Ansible depuis le site

La commande à lancer est du type :
ansible-playbook /path/to/the/file/MainTask.yml -i /path/to/the/file/inventaire.ini

La fonction PhP exec(String $cmd) devrait nous permettre de la lancer depuis le site aux endroits appropriés :

A la création d'un nouveau capteur ;
A l'envoi d'un code sur un ensemble de capteurs.

Pour que le serveur puisse lancer Ansible, et pour qu'Ansible ait accès à la clé ssh de root, nous allons utiliser la commande super.
L'équipe 2 a créé un script bash dans lequel se trouve la commande : ansible-playbook ../Ansible/MainTask.yml -i upload/inventaire.ini.

Nous devons lancer ce script en tant que root. Pour cela, après avoir installé super, nous avons configurer le fichier /etc/super.tab pour qu'il permette à l'utilisateur www-data de lancer le script en tant que root.
Pour se faire, nous avons ajouté cette ligne à la fin du fichier :

cmd.sh /var/www/html/P10/IMA3_P10/site/cmd.sh www-data uid=root .*

De ce fait, au niveau du site, une seule ligne a été ajoutée : exec("super cmd.sh");

Nous pouvons maintenant lancer Ansible depuis le site, au moment de la création d'un capteur et au moment de l'upload d'un fichier.

Prise en compte des remarques

Le compte d'identifiant admin et de mot de passe admin a été supprimé.
Il n'est plus possible de s'inscrire seul sur le site.

Mise en place des graphes

Notre équipe a travaillé sur la mise en place de graphes modélisant l'historique de données des capteurs.
Nous avons choisi de proposer un formulaire permettant de saisir :

Le capteur souhaité ;
Un intervalle de dates si besoin ;
Un nombre de valeurs à afficher.

Les valeurs affichées sont les valeurs les plus récentes. Si l'utilisateur veut afficher 100 valeurs entre 2 dates et qu'entre ces dates, il y a 150 valeurs, ce sont les 100 dernières qui seront affichées.
Le graphe étant statique, si un grand nombre de points est affiché (>100), nous aurons probablement des chevauchements dans l'affichage. Nous avons tout de même choisi de ne pas limiter le nombre de valeurs pour afficher une tendance.
Cependant, au dessus de 25 points, les valeurs n’apparaîtront pas sur chaque point mais il faudra les lire sur l'axe des ordonnées.
De la même manière, si le nombre de valeurs pour ce capteur dans l'historique est nul, le graphe ne sera pas affiché et vous serez redirigés sur le formulaire.

Pour la réalisation des graphes, nous avons choisi d'utiliser la librairie PHP JpGraphe dédiée à la représentation graphique. JpGraphe fournit des images qu'il reste à inclure dans le code HTML ou PHP. La construction de cette image se fait à partir d'un code PHP. Dans notre cas, nous devons renseigner les paramètres du formulaire dans ce code pour qu'il les prenne en compte. Pour se faire, on récupère les données du formulaire POST sur une nouvelle page (graphique.php). Cette page envoie par REQUEST les données à la page graphe.php qui retourne une image à l'aide d'un code que nous avons écrit à l'aide des fonctions de la librairie.

Création et suppression de comptes depuis les comptes administrateurs

Nous avons commencé par créer une table groupes dans laquelle on trouve le noms des groupes (Administrateur et Membre) et un id qui leur est relatif. La table membres a été modifiée pour ajouter à chaque membre un groupe.
Nous avons créé une fonction permettant de savoir à quel groupe un membre appartient. De ce fait, on pourra permettre à un utilisateur d'accéder ou non à certaines pages du site.

Ensuite, nous avons créé un ensemble de pages contenant des formulaires pour permettre aux comptes administrateurs d'ajouter et de supprimer des comptes.

Remonter les erreurs aux utilisateurs

Les erreurs lors de la connexion, de la création ou de la suppression d'un compte sont maintenant remontées à l'utilisateur.

Page permettant la visualisation du réseau complet

Nous avons commencé une page permettant une visualisation graphique mais le rendu n'est pas terrible.
Nous allons sûrement nous rabattre sur une page un peu moins "graphique" mais plus lisible.

La page d'accueil où se trouvait un simple logo a été remplacée par la page de visualisation du réseau.

Suppression de Raspberry et de capteurs

De la même manière que pour les comptes, nous voulions que les utilisateurs puissent ajouter et supprimer des Raspberry et des capteurs.
Nous avons donc ajouter cette possibilité.

Protocole d'ajout manuel d'un Raspberry Pi

Lors de l'ajout d'un Raspberry Pi depuis le site, l'utilisateur dispose maintenant du protocole pour l'ajouter manuellement au réseau, avec les différentes commandes utiles.

Lancement d'Ansible

Pour permettre l'arrêt d'un capteur, l'envoi du temps de boucle de la règle Cron associée à un capteur ou encore la suppression du dossier d'un capteur, nous avons modifié le code PHP pour lancer Ansible avec les fichiers inventaire.ini correspondant.

Par ailleurs, nous avons modifié la page values.php pour y intégrer un formulaire d'arrêt des capteurs.

Récupération du résultat d'exécution d'Ansible

Pour permettre un maximum de débug et davantage de fiabilité lors de l'envoi des codes, nous avons voulu remonter les erreurs d'Ansible.
Pour se faire, nous avons tout simplement utilisé la fonction exec() dans sa globalité en lui donnant 2 autres paramètres :

Un tableau dans lequel sera stocké les valeurs de retours ;
Un entier qui contiendra le statut de l'exécution (égal à 0 si l'exécution se passe correctement).

Avancement du projet pendant le confinement

Le détail de l'avancement de chaque équipe est disponible dans la section 4.3.4.

Confinement - Semaine 1

Nous avons pris la liberté de brancher au réseau de l'école 2 Raspberry et les capteurs qui vont avec. Nous avons emprunté dans une boîte des tutorat Système un Arduino UNO car nous n'en avions pas assez pour en avoir chez nous dans le cas d'une coupure à Polytech.
Nous avons également tout le matériel nécessaire chez nous et accès au serveur depuis chez nous.

Nous considérons que nos raspberry ont une pré-configuration avant leur installation (faite par nos soins).
Elle inclut la modification du DNS et de l'adresse IP de la raspberry pour être accessible depuis le site et Ansible.

Equipe 1 : Raspberry, Arduino, Capteurs
- Les Raspberry communiquent parfaitement avec le site par wget et requete POST ;
- Les codes sont modifiés et prêts (code température et code distance) ;
- Un Makefile générique est en cours de finition ;
- Le Makefile choisira d'abord quel commande d'upload il va effectuer (en fonction du numéro de version) puis spécifiera le port dans la commande avrdude ;
- La carte Nucléo M4 est en suspend tant que le reste n'est pas fonctionnel.

Equipe 2 : Ansible
- Gestion au niveau des Arduino (Nucléo laissée de côté) ;
- L'installation des logiciels et bibliothèques nécessaire au fonctionnement des codes est ok ;
- La transmission des fichiers et le lancement du script fonctionne ;
- Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
- Il faudrait récupérer le code envoyé depuis le site sans le télécharger (car Ansible est aussi sur le serveur).

Equipe 3 : Site Web
- Site 95% terminé par rapport à ce qui a été demandé ;
- Reste le lancement des scripts Ansible depuis le site.

Remarques sur chat.plil.fr
- Mot de passe admin par défaut pour le site internet. Favoriser le mot de passe root habituel à la place ou un mot de passe plus compliqué afin de limiter les risques.
- Ajouter la possibilité sur le site de visualiser pour chaque capteur, un graphe de l'évolution temporelle des valeurs renvoyées.

Confinement - Semaine 2

Equipe 1 : Raspberry, Arduino, Capteurs
- Les Raspberry communiquent parfaitement avec le site via des requêtes POST ;
- Les codes sont modifiés et prêts (code température et code distance) ;
- Un Makefile générique est opérationnel (mais ne gère pas encore la Nucléo) ;
- La carte Nucléo M4 est en suspend tant que le reste n'est pas fonctionnel ;
- Il faut utiliser Cron pour lancer le processus d'envoi des données des capteurs de températures toutes les 5 minutes et toutes les 5 secondes pour les capteurs de distance ;
- Éviter l'attente active des capteurs (boucle infinie) ;
- Début du rapport final.

Equipe 2 : Ansible
- Ansible est opérationnel pour gérer les Arduino ;
- L'installation des logiciels et bibliothèques nécessaires au fonctionnement des codes est fonctionnelle ;
- La transmission des fichiers et le lancement du script fonctionne ;
- Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
- Il faut récupérer le code envoyé depuis le site sans le télécharger (car Ansible est aussi sur le serveur) ;
- Début du rapport final.

Equipe 3 : Site Web
- Site 98% terminé par rapport à ce qui a été demandé ;
- Il faut ajouter une page permettant la visualisation graphique de l'ensemble du réseau.

Remarques sur chat.plil.fr
- Ajouter une page permettant la visualisation graphique de l'ensemble du réseau de capteurs ;
- Correction de la syntaxe wiki ;
- Début du rapport final.

Confinement - Semaine 3

Equipe 1 : Raspberry, Arduino, Capteurs
- Il faut utiliser Cron pour lancer le processus d'envoi des données des capteurs de températures toutes les 5 minutes et toutes les 5 secondes pour les capteurs de distance ;
- Éviter l'attente active des capteurs (boucle infinie) ;
- Faire correspondre un capteur à un port USB physique de chaque raspberry ;
- Début du rapport final.

Equipe 2 : Ansible
- Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
- Les fichiers envoyés depuis le site sont récupérés directement par Ansible via leur chemin ;
- Début du rapport final.

Equipe 3 : Site Web
- Il faut ajouter une page permettant la visualisation graphique de l'ensemble du réseau ;
- Il faut remonter les erreurs à l'utilisateur ;
- Il faut permettre aux administrateurs de créer et supprimer des comptes.

Remarques sur chat.plil.fr
- Démonstration ok.

Confinement - Semaine 4 à 6

Equipe 1 : Raspberry, Arduino, Capteurs
- Un capteur correspond à un port USB unique du Raspberry Pi ;
- Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
- Diaporama de soutenance en cours ;
- Partie du rapport final terminée.

Equipe 2 : Ansible
- Cron est fonctionnel ;
- Envoi du fichier temps.txt à la création d'un capteur ;
- Le script script.sh lance maintenant Cron ;
- Suppression du dossier des capteurs via Ansible ;
- Lancement du script d'arrêt de Cron via Ansible ;
- Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
- Diaporama de soutenance en cours ;
- Rapport final en cours.

Equipe 3 : Site Web
- L'ensemble du réseau de capteurs est visualisable sur la page d'accueil;
- Les erreurs sont remontées à l'utilisateur ;
- Les administrateurs peuvent créer et supprimer des comptes ;
- Un utilisateur peut arrêter un capteur ;
- La suppression d'un capteur entraîne la suppression du dossier sur le Raspberry Pi via Ansible ;
- Les résultats d'exécution d'Ansible sont remontés à l'utilisateur ;
- Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
- Partie du diaporama de soutenance terminée ;
- Partie du rapport final terminée.

Remarques sur discussion
- Corriger les coquilles.

Confinement - Semaine 7

Equipe 1 : Raspberry, Arduino, Capteurs
- Diaporama de soutenance terminé ;
- Partie du rapport final terminée.

Equipe 2 : Ansible
- Diaporama de soutenance en cours ;
- Rapport final en cours.

Equipe 3 : Site Web
- Partie du diaporama de soutenance terminée ;
- Partie du rapport final terminée.

Confinement - Semaine 8

Projet terminé.

Documents Rendus

Gitlab : Git P10
Site web : Site
Rapport : media: Rapport_final_P10_2019_2020.pdf
Diaporama : media: Diapo_final_P10_2019_2020.pdf

@@ Ligne 58 : / Ligne 58 : @@
 ==Bibliographie et webographie==
+===S6===
+'''Equipe 1'''
+*DataSheet
+**https://www.electronicsdatasheets.com/datasheet/BPI-R1.pdf
+*OpenWRT
+**https://openwrt.org/
+*Banana Pi
+**http://wiki.banana-pi.org/Banana_Pi_BPI-R1
+'''Equipe 2'''
+*Pin Raspberry
+**https://pi4j.com/1.2/pins/model-3b-plus-rev1.html
+*Configuration
+**https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018
+*Clignotement d’une LED
+**https://www.framboise314.fr/la-saga-blink-un-raspberry-pour-faire-clignoter-une-led/
+**http://nagashur.com/blog/2013/01/01/controler-une-led-depuis-les-ports-gpio-du-raspberry-pi/
+*Installation Raspbian
+**https://raspbian-france.fr/installer-raspbian-premier-demarrage-configuration/
+'''Equipe 3'''
+*Protocole XMLHttpRequest
+**https://openclassrooms.com/fr/courses/1085676-upload-de-fichiers-par-formulaire
+===S7===
+'''Equipe 1'''
+*Banana Pi
+**http://hardware-libre.fr/2015/01/bpi-r1-open-router-first-look/
+'''Equipe 2'''
+*Passage en mode DFU
+**https://www.arduino.cc/en/Hacking/DFUProgramming8U2
+*Flasher un Arduino sans programmer
+**https://welldoneblog.fedevel.com/2015/04/13/how-to-flash-arduino-bootloader-without-a-programmer/
+*Datasheets
+**https://produktinfo.conrad.com/datenblaetter/175000-199999/191789-an-01-fr-plat_uno.pdf
+**https://www.farnell.com/datasheets/1682209.pdf
+**https://www.mouser.com/pdfdocs/Gravitech_ATMEGA328_datasheet.pdf
+**http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf
+**http://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdf
+**http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/DDI0432C_cortex_m0_r0p0_trm.pdf
+**http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439b/DDI0439B_cortex_m4_r0p0_trm.pdf
+*Connexion entre RPI & Atmega328p
+**http://hardware-libre.fr/2014/04/rapberry-pi-atmega-bridge-presentaion/
+**http://hardware-libre.fr/2014/04/raspberry-pi-atmega-bridge-branchements/
+**http://hardware-libre.fr/2014/04/raspberry-pi-atmega-bridge-installation/
+**https://www.instructables.com/id/Connect-Your-Raspberry-Pi-and-Arduino-Uno/
+**https://learn.adafruit.com/program-an-avr-or-arduino-using-raspberry-pi-gpio-pins/overview
+*Arduino UNO & Raspberry Pi SPI
+**http://ozzmaker.com/program-avr-using-raspberry-pi-gpio/
+**https://davecturner.github.io/2019/02/23/programming-avr-microcontrollers.html
+===S8===
+'''Equipe 1'''
+*Connexion SPI
+**https://www.arduino.cc/en/reference/SPI
+**https://zestedesavoir.com/forums/sujet/2574/communication-via-rx-et-tx/
+*TX/RX à partir de GPIO
+**https://github.com/adrianomarto/soft_uart
+**https://oscarliang.com/raspberry-pi-and-arduino-connected-serial-gpio/
+*Script Python
+**https://www.quennec.fr/trucs-astuces/langages/python/python-modifier-la-valeur-dune-balise-dun-xml-en-fonction-de-la-valeur-de-son-attribut
+**http://dridk.me/python-requests.html
+'''Equipe 2'''
+*Communication SSH
+**https://geekeries.org/2016/10/transferts-scp-sans-mot-de-passe/?cn-reloaded=1
+'''Equipe 3'''
+*Script PhP
+**http://www.manuelphp.com/php/function.ssh2-connect.php
+**https://www.developpez.net/forums/d702424/bases-donnees/mysql/debuter/remplir-base-fichier-texte/
+**https://www.php.net/manual/fr/function.scandir.php
+**https://www.php.net/manual/fr/function.array-diff.php
+**https://www.php.net/manual/fr/function.shell-exec.php
 =Préparation du projet=
@@ Ligne 65 : / Ligne 163 : @@
 Nous allons devoir répondre à plusieurs problématiques.
-Tout d'abord nous devons créer un site web dynamique permettant l'envoi des données au serveur et au final, aux nœuds de capteurs sélectionnés.
+*Tout d'abord nous devons créer un site web dynamique permettant l'envoi des données au serveur et finalement, aux nœuds de capteurs sélectionnés. Pour cela, nous allons devoir implémenter un système d'envoi de fichiers vers un routeur. Le routeur (Banana Pi) va filtrer les informations reçues, et donner un accès internet aux différents nœuds représentés par des Raspberry Pi et des microcontrôleurs.
-Pour cela, nous allons devoir implémenter un système d'envoi de fichiers vers un routeur.
-Le routeur (Banana Pi) va filtrer les informations reçues, et envoyer les fichiers C aux différents nœuds représentés par des Raspberry Pi.
+*Ensuite, il faudra que les Raspberry récupèrent les fichiers C sur le serveur et les envoient correctement aux différents capteurs de leur nœud et puissent récupérer les informations à retourner. Pour se faire, on utilise l'utilitaire Python Ansible, permettant la gestion et la configuration des nœuds de capteurs. Celui-ci va récupérer les fichiers C et les distribuer sur les différents capteurs affectés. Le retour d'information se fera par requêtes envoyant les informations mises à jour au serveur.
-Ensuite, il faudra que les Raspberry envoient correctement le code reçu aux différents capteurs de leur nœud et puissent récupérer les informations à retourner.
+==Cahier des charges des équipes==
-Pour se faire, on utilise l'utilitaire Python Ansible, permettant la gestion et la configuration des nœuds de capteurs.
+===Equipe 1 : Ziyad HOUSSAINI (S6), Loris AHOUASSOU (S8)===
-Celui-ci va récupérer les fichiers C et les distribuer sur les différents capteurs affectés.
-Le retour d'information se fera par le chemin inverse jusqu'au serveur web sous forme de fichiers contenant les données issues des capteurs.
-==Cahier des charges des équipes==
+'''S6'''
-===Equipe 1 : Ziyad HOUSSAINI===
+*Dans notre équipe, il faudra configurer le routeur afin de pouvoir assurer la communication entre les Rasberry Pi qui seront configurées par l'équipe 2 et le serveur web qui sera mise en place par l'équipe 3 ;
+*Pour se faire, on va utiliser une Banana pi sur laquelle sera installé OpenWRT ;
+*Le routeur servira également de point d'accès internet pour les différentes Raspberry ;
+*Il devra scruter le serveur web et récupérer les fichiers qui s'y trouvent avant de les envoyer sur les bonnes Raspberry à l'aide de scripts Shell.
-Dans notre équipe, il faudra configurer le routeur afin de pouvoir assurer la communication entre la Rasberry Pi qui sera configurée par l'équipe 1 et le serveur web qui sera mise en place par l'équipe 3.
+'''S8'''
-Pour ce faire, on va utiliser une banana pi sur laquelle sera installer OpenWRT (fonctionnement à revoir).
-===Equipe 2 : Eymeric CAPRONNIER===
+*Créer des scripts permettant d'automatiser la compilation et le lancement les codes reçus depuis le serveur ;
+*Créer les codes pour les différents capteurs disponibles ;
+*Créer un script permettant l'envoi des données au serveur.
-* Dans un premier temps, il faudra que les Raspberry Pi envoient correctement le code reçu aux différents capteurs sélectionnés.
+===Equipe 2 : Eymeric CAPRONNIER, Loris AHOUASSOU (S7), Guillaume ROUILLÉ (S7), Thomas MERTZ (S8)===
-* Puis il faudra retourner le fichier contenant les différentes données générés par les capteurs.
+'''S6, S7'''
-===Equipe 3 : Guillaume ROUILLÉ===
+*Une fois que le routeur aura envoyé les fichiers aux Raspberry demandées, et donc en fonction des capteurs qui s'y trouvent, celles-ci pourront commencer leur traitement ;
+*Les Raspberry vont commencer par compiler les codes reçus, puis vont les envoyer sur les microcontrôleurs représentant les capteurs ;
+*Les microcontrôleurs devront pouvoir être reconfigurer directement à partir de la Raspberry. Ils vont exécuter les codes reçus ;
+*Ils vont ensuite générer des fichiers résultat qui seront envoyés sur le serveur.
-Dans un premier temps, notre équipe devra réaliser une interface web utilisateur permettant la connexion au serveur de données.
+'''S8'''
-Pour se faire, on va utiliser les langages HTML et CSS pour la forme du site, et les langages PhP et SQL pour lier le site à la base de données.
-Ensuite, il faudra créer un système de sélection des capteurs sur lesquels envoyer le ou les fichiers.
+*Configurer Ansible pour envoyer les données du serveur vers les Raspberrys.
-Il faudra faire correspondre chaque capteur des différents nœuds avec un type prédéfini et créer une page de sélection sur le site.
-Enfin, nous devrons envoyer les fichiers sur le serveur, où ils seront récupérés par le routeur pour être traiter.
+===Equipe 3 : Guillaume ROUILLÉ===
-Il faudra créer une page permettant la mise en ligne de fichiers. Cette page affichera la progression de l'envoi et sera capable de valider la bonne réception des données.
+*Dans un premier temps, notre équipe devra réaliser une interface web utilisateur permettant la connexion au serveur de données. Pour se faire, on va utiliser les langages HTML et CSS pour la forme du site, et les langages PhP et SQL pour lier le site à la base de données ;
+*Ensuite, il faudra créer un système de sélection des capteurs sur lesquels envoyer le ou les fichiers. Il faudra faire correspondre chaque capteur des différents nœuds avec un type prédéfini et créer une page de sélection sur le site ;
+*Puis, nous devrons envoyer les fichiers sur le serveur, où ils seront récupérés par ce qui est mis en œuvre par l'équipe 2. Il faudra créer une page permettant la mise en ligne de fichiers. Cette page affichera la bonne réception des données ;
+*Enfin, une dernière partie du site permettra l'affichage des résultats reçus depuis les capteurs sous plusieurs formes.
 ==Choix techniques : matériel et logiciel==
+[[Fichier:BananapiR1.jpg|150px|thumb|right|Banana PI R1]]
+[[Fichier:Raspberry2.jpg|150px|thumb|right|Raspberry PI 3]]
 ===Equipe 1===
-[[Fichier:bobi.png|200px|thumb|right]]
+'''S6'''
-[[Fichier:BananapiR1.jpg|150px|thumb|right|BPI_R1]]
-*Une Banana Pi de type comme routeur ;
+*Une Banana Pi ;
-*Une image (OS) de type Debian ou OpenWrt afin de pouvoir utiliser la carte.
+*Une image (OS) de type Debian ou OpenWrt afin de pouvoir utiliser la carte ;
-*Un carte SD à laquelle on va mettre l'image ;
+*Un carte SD sur laquelle on va charger l'image ;
 *Un cable HDMI afin de pouvoir visualiser l'interface.
+'''S7, S8'''
+*3x Raspberry Pi ;
+*5x Arduino UNO ;
+*1x Nucleo-F401RE ;
+*4x Câble RJ45 ;
+*6x Câble USB type A mâle - type B mâle ;
+*6x Câble électrique femelle - femelle ;
+*3x Capteurs de distance HC-SR04: https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm ;
+*2x Capteurs de température LM35 : https://www.gotronic.fr/art-module-capteur-de-t-lm35-st039-26113.htm#complte_desc ;
+*18x Câble électrique mâle - mâle.
 ===Equipe 2===
-*Une Raspberry Pi et son alimentation ;
+*1x Raspberry Pi ;
-*Un câble Ethernet ;
+*1x câble Ethernet ;
-*4 diodes et résistances ;
+*4x diodes et résistances (S6);
-*Un câble HMDI/VGA ;
+*1x câble HMDI/VGA ;
-*Un clavier et une souris afin d'utiliser la Raspberry (interface graphique) ;
+*1x clavier et une souris afin d'utiliser la Raspberry (interface graphique).
-*Ansible pour faciliter le déploiement des fichiers C sur les nœuds.
 ===Equipe 3===
 *Une base de données PostgreSQL pour le stockage des données ;
-*Un interpréteur PhP et un serveur web (Apache) ;
+*Un interpréteur PhP et un serveur web (Apache).
-*Un site moderne basé sur les Frameworks CSS Bootstrap et Vue.js.
 ==Liste des tâches à effectuer==
 ===Equipe 1===
-Déploiement d'un routeur à base de Banana Pi R1.
+'''S6'''
-Ce routeur permettra l'accès internet aux différentes Raspberry Pi et il filtrera les accès.
-Déploiement de OpenWRT sur ce routeur.
-*Documentation sur le fonctionnement du routeur Banana Pi ;
+*Déploiement d'un routeur à base de Banana Pi R1 permettant l'accès à internet aux différentes Raspberry Pi ;
-*Documentation sur le fonctionnement de OpenWRT ;
+**Déploiement de OpenWRT sur le routeur et configuration ;
-*Déploiement de OpenWRT sur le routeur et configuration ;
+**Création d'un point d'accès internet sur la carte routeur ;
-*Création d'un point d'accès filaire sur la carte routeur.
+**Récupération des fichiers sur le serveur web ;
+**Envoi des fichiers sur les bonnes Raspberry.
+'''S8'''
+*Scripts permettant d'automatiser la compilation et le lancement les codes reçus depuis le serveur ;
+**Création d'un Makefile ;
+**Création d'un script de lancement global.
+*Codes pour les différents capteurs disponibles ;
+**Créer un code pour chaque capteur (température, distance) ;
+**Créer une lib contenant une fonction permettant le retour de données via liaison série.
+*Script permettant l'envoi des données au serveur.
+**Créer un script Python permettant la récupération des données sur le port série et l'envoi au serveur par requête POST.
 ===Equipe 2===
-Déploiement des logiciels sur les Raspberry Pi avec la création de différents scripts pour faciliter ce déploiement, en utilisant notamment Ansible.
+'''S6, S7'''
+*Récupération des fichiers sur le serveur ;
+**Créer un script pour récupérer les fichiers sur le serveur ;
+*Compilation et lancement du code.
+**Créer un Makefile ;
+**Créer un script pour lancer le Makefile de manière automatique.
+'''S8'''
-*Documentation sur le fonctionnement des Raspberry pi ;
+*Déploiement des logiciels sur les Raspberry Pi grâce à Ansible.
-*Documentation sur Ansible ;
+**Configuration de la Raspberry PI 3 pour qu'elle soit accessible sur le réseau (adresse IP, routeur, DNS) ;
-*Configuration de la Raspberry PI 3 ;
+**Création du script afin d'envoyer le code reçu aux différents capteurs ;
-*Création du script afin de vérifier que le capteur sélectionné par le serveur se trouve bien dans la liste de capteur connecté à la Raspberry ;
+**Configuration à distance du microcontrôleur, peut importe son type.
-*Création du script afin d'envoyer le code reçu aux différents capteurs ;
-*Création du script permettant de créer le fichier résultat afin d'envoyer les données issus des capteurs.
 ===Equipe 3===
-Déploiement d'un serveur permettant de récupérer les différentes données issues des capteurs (création d'une base de données et d'un site web dynamique pour l'affichage).
+'''S6'''
-*Documentation sur les Frameworks Web Bootstrap.css et Vue.js ;
+*Déploiement du serveur Web ;
-*Documentation sur PhP et Apache ;
+**Création d'une base de données PostgreSQL ;
-*Création d'une interface web utilisateur ;
+**Création d'un site web ;
-*Création d'une base de données relationnelle pour gérer les nœuds ;
+**Création d'une interface web utilisateur ;
-*Envoi du fichier C sur le serveur ;
+**Création d'une page d'envoi des fichiers vers le serveur.
-*Envoi du numéro du capteur sur le serveur ;
+*Envoi des fichiers sur le serveur ;
-*Envoi du numéro de la demande sur le serveur.
+**Créer un script d'envoi du fichier choisit par l'utilisateur sur le serveur.
+*Envoi du numéro et type des capteurs sélectionnés sur le serveur ;
+*Envoi du numéro de la demande sur le serveur ;
+'''S8'''
+*Ajout de différentes pages ;
+**Page permettant la visualisation de l'historique des données des capteurs ;
+**Page permettant l'affichage de graphes fabriqués à l'aide des données des capteurs ;
+**Pages permettant l'ajout de raspberrys et de capteurs ;
+**Page permettant la visualisation du réseau global.
+*Modification de la base de données ;
+**Ajout d'une table d'historique ;
+**Ajout d'une table de groupes ;
+**Mise à jour des tables contenant les capteurs et les raspberrys.
+*Envoi du fichier de configuration (.ini) sur le serveur ;
+*Permettre aux administrateurs d'ajouter et de supprimer des comptes ;
+*Permettre le lancement d'Ansible via le site.
 ==Calendrier prévisionnel==
-Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
 ===Equipe 1===
@@ Ligne 167 : / Ligne 319 : @@
 |-
 |
-/02
+/02/19
 |
@@ Ligne 175 : / Ligne 327 : @@
 |-
 |
-/02
+/02/19
 |
 *Cahier des charges ;
-*Répartition du travail entre équipes
+*Répartition du travail entre équipes.
 |-
 |
-/03
+/03/19
 |
-*Recherche sur Internet sur quel type de carte on pourra utiliser pour configurer le routeur, qui sera un point d'accès wifi
+*Recherche sur Internet sur quel type de carte on pourra utiliser pour configurer le routeur, qui sera un point d'accès wifi pour le noeud de collecte qui sera la Rasberry Pi.
-pour le noeud de collecte qui sera la Rasberry Pi
 |-
 |
-/03
+/03/19
 |
-*Recherche de la datasheet du routeur Banana PI-R1, afin de pouvoir comprendre les configurations de la carte
+*Recherche de la datasheet du routeur Banana PI-R1, afin de pouvoir comprendre les configurations de la carte et aussi les branchements.
-et aussi les branchements
 |-
 |
-/04
+/04/19
+|
+*Trouver l'open source me permettant de visuliser l'interface de la BPI-R1, et en l'occurrence l'OS OpenWrt.
+|-
 |
-objectif
+/04/19
+|
+*Faire fonctionner la carte et comprendre les fonctionnalités qu'offrent l'OpenWrt.
 |-
 |
-/04
+/04/19
+|
+*Configurer la carte en tant que point d'accès wi-fi en utilisant cette fois l'OS Debian car la semaine dernière l'image OpenWrt ne fonctionnait pas.
+|-
+|
+/05/19
 |
-objectif
+*Résoudre le problème de la carte car elle ne fonctionnait pas et demander à mes tuteurs la raison pour laquelle elle ne marche pas.
 |-
 |
-/04
+/05/19
+|
+*Mettre une nouvelle image (Armbian) et rattraper le retard pour le configurer en tant que point d'accès wi-fi pour la rasberry pi.
+|-
 |
-objectif
+/05/19
+|
+*Faire en sorte que la BPI-R1 arrive à jouer le rôle de point d'accès wifi pour que la Rasberry PI puisse se connecter au serveur via internet.
 |-
 |
-/05
+/11/19
+|
+*Reprendre la configuration de la Banana Pi à zéro ;
+*Faire de cette carte un point d'accès Wi-Fi.
+|-
+|
+/01/20
 |
-objectif
+*Faire communiquer l'Arduino UNO et la Raspberry Pi dans les 2 sens.
 |-
 |
-/05
+/02/20
+|
+*Créer le code pour le capteur de température et visualisation des données sur le port série avec minicom.
+|-
 |
-objectif
+/02/20
+|
+*Créer le code pour le capteur de distance et visualisation des données sur le port série avec minicom.
 |-
 |
-/06
+/03/20
+|
+*Créer le script Python permettant le retour de données vers le serveur.
+|-
+|
+/03/20
 |
-objectif
+*Créer le Makefile générique.
+|-
+|
+/04/20
+|
+*Faire correspondre un port USR de Raspberry Pi à un capteur.
 |}
@@ Ligne 245 : / Ligne 434 : @@
 |-
 |
-/02
+/02/19
 |
@@ Ligne 253 : / Ligne 442 : @@
 |-
 |
-/02
+/02/19
 |
@@ Ligne 261 : / Ligne 450 : @@
 |-
 |
-/03
+/03/19
 |
@@ Ligne 268 : / Ligne 457 : @@
 |-
 |
-/03
+/03/19
 |
 *Documentation sur l'allumage d'une LED et création des premiers scripts d'allumage de LED.
 |-
 |
-/04
+/04/19
 |
@@ Ligne 280 : / Ligne 469 : @@
 |-
 |
-/04
+/04/19
 |
@@ Ligne 286 : / Ligne 475 : @@
 |-
 |
-/04
+/04/19
 |
@@ Ligne 293 : / Ligne 482 : @@
 |-
 |
-/05
+/05/19
 |
@@ Ligne 300 : / Ligne 489 : @@
 |-
 |
-/05
+/05/19
 |
+*Récupération du fichier C et XML envoyé sur le site ;
+*Création des commandes de récupération de ces fichiers ;
 *Création du script permettant de lire le fichier XML envoyé par le serveur qui indique le nom et le numéro du capteur sélectionné.
+|-
+|
+/06/19
+|
+*Permettre une récupération rapide des fichiers à partir du serveur ;
+*Permettre une scrutation régulière du serveur sur la Raspberry ;
+*Permettre l'exécution unique du programme ;
+*Création du script permettant le lancement automatique des différents scripts créés lorsque le serveur effectue une demande.
 |-
 |
-/06
+/11/19
+|
+*Réinstaller une image sur la Raspberry Pi sans interface graphique ;
+*Permettre l'accès à internet sur la Raspberry.
+|-
 |
-*Création du script permettant le lancement automatique des différents scripts créés lorsque le serveur effectue une demande.
+/11/19
+|
+*Permettre la connexion entre la Raspberry Pi et un Arduino Atmega328p.
+|-
+|
+/12/19
+|
+*Permettre l'exécution de code sur l'ATMega328p.
+|-
+|
+/04/20
+|
+*Rendre Ansible fonctionnel ;
+*Rendre Cron fonctionnel.
 |}
@@ Ligne 320 : / Ligne 538 : @@
 |-
 |
-/02
+/02/19
 |
@@ Ligne 328 : / Ligne 546 : @@
 |-
 |
-/02
+/02/19
 |
@@ Ligne 336 : / Ligne 554 : @@
 |-
 |
-/03
+/03/19
 |
@@ Ligne 344 : / Ligne 562 : @@
 |-
 |
-/03
+/03/19
 |
@@ Ligne 351 : / Ligne 569 : @@
 |-
 |
-/04
+/04/19
 |
@@ Ligne 358 : / Ligne 576 : @@
 |-
 |
-/04
+/04/19
 |
@@ Ligne 365 : / Ligne 583 : @@
 |-
 |
-/04
+/04/19
 |
@@ Ligne 373 : / Ligne 591 : @@
 |-
 |
-/05
+/05/19
 |
@@ Ligne 382 : / Ligne 600 : @@
 |-
 |
-/05
+/05/19
 |
@@ Ligne 390 : / Ligne 608 : @@
 |-
 |
-/06
+/06/19
 |
@@ Ligne 397 : / Ligne 615 : @@
 *Permettre l'exécution unique du programme.
+|-
+|
+/04/19
+|
+*Créer la table pour le retour d'informations dans la base de données ;
+*Créer un page d'affichage des données de cette nouvelle table.
+|-
+|
+/01/20
+|
+*Mise à jour de la table capteurs ;
+*Mise à jour de la page de sélection des capteurs.
+|-
+|
+/02/20
+|
+*Créer la page permettant de récupérer les données des capteurs par requête POST ;
+*Créer la fonction de mise à jour de la base de données.
+|-
+|
+/02/20
+|
+*Créer la table qui contiendra l'historique de valeurs ces capteurs ;
+*Créer les pages de recherche dans cet historique ;
+*Modifier la fonction de mise à jour de la base de données pour intégrer l'historique.
+|-
+|
+/02/20
+|
+*Création des pages permettant l'ajout d'une raspberry ou d'un capteur ;
+*Création des fonctions associées.
+|-
+|
+/03/20
+|
+*Créer le fichier inventaire.ini utile à l'équipe 2 à partir du site à l'ajout d'un capteur ou l'envoi d'un code ;
+*Migration du site et de la base données sur un nouveau serveur sur plil.fr.
+|-
+|
+/03/20
+|
+*Créer les pages permettant l'affichage des graphes de valeurs des capteurs ;
+*Création des fonctions associées.
+|-
+|
+/03/20
+|
+*Permettre le lancement d'Ansible depuis le site.
+|-
+|
+/04/20
+|
+*Créer une page permettant la visualisation graphique de l'ensemble du réseau de capteurs et des caractéristiques de chaque nœud.
 |}
@@ Ligne 411 : / Ligne 690 : @@
 c'est à dire les branchements, le courant d'alimentaion et les composants.<br/>
 https://www.electronicsdatasheets.com/datasheet/BPI-R1.pdf
 ----
@@ Ligne 420 : / Ligne 700 : @@
 Afin d'installer Ansible, deux lignes de commande ont dû être lancé dans le terminal d'un pc en E306 ( car l'installation d'ansible n'était pas possible dans les autres salles) :
   apt install ansible
-puis
+Connexion internet sur la Raspberry :
+Partie Raspberry
   export https_proxy=https://proxy.polytech-lille.fr:3128
+ export http_proxy=http://proxy.polytech-lille.fr:3128
+OU :
+ export https_proxy=https://proxy.plil.fr:3128
+ export http_proxy=http://proxy.plil.fr:3128
+Puis, dans /etc/resolv.conf
+ nameserver 193.48.57.48
+Ensuite dans /etc/network/interfaces :
+ auto eth0
+ iface eth0 inet static
+    address 172.26.145.111
+    netmask 255.255.255.0
+    gateway 172.26.145.254
+Enfin :
+ ipdown eth0
+ ifup eth0
+Sur le pc :
+ iptables -F
+ iptables -tnat -F
+ iptables -PFORWARD ACCEPT
 L'utilisation d'ansible se fera ensuite de la manière suivante : Ecriture d'un fichier .yml contenant les différentes tâches à effectuer sur un serveur (réseau de capteur) spécifique puis le lancement s'effectuera ensuite en lanceant la commande ansible suivi du nom du serveur sur lequel on souhaite travailler.
 Concernant la Raspberry PI 3, la Raspberry PI 3 est un ordinateur miniature que l'on peut brancher à un écran et un clavier afin de l'utiliser comme un ordinateur normal. Le stockage des données s'effectue sur une carte SD ce qui permet à la Raspberry d'être très petite (l'utilisation d'un disque dur interne augmenterait grandement sa taille)
-[[Fichier:Raspberry2.jpg|500px|thumb|center|Raspberry PI 3]]
 ----
@@ Ligne 438 : / Ligne 743 : @@
 La base contient 3 tables :
 *capteurs : numéro du capteur | nom du capteur | Raspberry à laquelle le capteur est relié | type de capteur
-*membres : numéro du membre | nom | prénom | mot de passe
+*membres : numéro du membre | nom | prénom | mot de passe | identifiant de connexion
-*verif : num
+*verif : numéro de la demande
 La table capteurs stocke les informations concernant les capteurs et permettra la sélection au moment de l'envoi du fichier C. <br/>
@@ Ligne 469 : / Ligne 774 : @@
 Au cours de cette séance, je me suis documenté sur l'allumage d'une LED. Cela m'a amené à créer un organigramme afin de réaliser le code plus simplement par la suite.
-[[Fichier:Organigramme1.png|150px|thumb|center|Organigramme]]
+[[Fichier:Organigramme1.png|150px|thumb|right|Organigramme]]
-Le câblage s'effectuera de façon très simple en connectant une LED puis une résistance à chaque sortie GPIO en fonction du nombre de capteur souhaité par Raspberry ( nous utilisons des LED pour cette année pour simuler et voir que le code envoyé par le serveur est bien traité et reçu par les LED s'allumant lorsque le capteur associé a été sélectionné.
+Le câblage s'effectuera de façon très simple en connectant une LED puis une résistance à chaque sortie GPIO en fonction du nombre de capteurs souhaités par Raspberry (nous utilisons des LED pour cette année pour simuler et voir que le code envoyé par le serveur est bien traité et reçu par les LED s'allumant lorsque le capteur associé a été sélectionné).
-[[Fichier:Cablage1.png|500px|thumb|center|Cablage LED]]
+[[Fichier:Cablage1.png|300px|thumb|center|Cablage LED]]
 Puis je me suis intéressé au code afin d'allumer la LED 500ms puis de l'éteindre 500ms grâce à une boucle while qui est toujours active tant que le programme tourne (control C par l'utilisateur pour stopper le programme). Pour se faire, il faut mettre le PIN connecté à la LED en mode sortie (OUTPUT) car sans cela la LED ne s'allume pas.
 [[Fichier:codeLED.png|500px|thumb|center|Script C LED]]
+Ce code nécessite l'installation de la bibliothèque WiringPi qui permet d'allumer et d’éteindre la LED. Nous verrons l'installation de cette bibliothèque une fois les configurations faites sur la Raspberry effectuées et une fois connecté à la Raspberry.
 ----
@@ Ligne 494 : / Ligne 802 : @@
 ===Semaine 6 - 02/04===
+[[Fichier:Exemple.jpg|thumb|right|100px|Branchement de la carte Banana PI]]
+Pour l'équipe 1 :
-Pour l'équipe 1 :
-[[Fichier:Exemple.jpg|thumb|right|100px|Branchement de la carte Banana PI]]
 Après avoir trouvé l'image permettant de visualiser l'interface BPI-R1, de la faire marcher et de le configurer en tant que routeur de wifi pour qu'il puisse emettre pour le noeud de collecte qui est la Rasberry PI.
 La première étape est d'abord d'installer l'OpenWrt dans une carte SD et cette carte SD sera mis sur le port SD de la Banana PI R1. Voici les commandes qui
@@ Ligne 508 : / Ligne 816 : @@
 Après avoir branchéle port HDMI de la carte avec l'entrée VGA du moniteur on pouvait voir l'interface mais on arrivait pas écrire.
 Donc après avoir appeler mes tuteurs, ils m'avaient dit que la semaine prochaine, ils allaient mettre le système Debian, car il y aurait des problèmes avec le système OpenWrt.
 ----
 Pour l'équipe 2 :
+Tout d'abord, il faut télécharger Raspbian sur la carte SD de la Raspberry Pi 3. Pour cela, j'ai sélectionné le fichier contenant Raspbian avec des interfaces graphiques (voir photo ci-dessous) sur le site internet :
+ https://www.raspberrypi.org/downloads/raspbian/
+[[Fichier:Raspbian.png|500px|thumb|center|Fichier Raspbian]]
+Une fois l'archive zippée de la distribution récupérée vous pouvez l'installer sur la carte SD après l'avoir décompressée en utilisant la commande dd :
+ dd if=2019-04-08-raspbian-stretch-full.img of=/dev/sdb
+Puis une fois tout ceci téléchargé, j'ai commencé à effectuer mes premiers pas sur la Raspberry. Une fois le clavier, la souris, l'écran et la carte SD branché et connecté à la Raspberry, j'ai pu connecter l'alimentation de la Raspberry. Le premier démarrage fut un peu long, car lors de celui-ci, la raspberry a installé le système Raspbian. Lors de ce premier démarrage, des premières configurations ont été effectué qui ont été très simplifié car étant sur une version de Raspbian avec une interface graphique. Ces quelques réglages consistaient principalement à régler la langue, l'heure, la connexion internet et le nouveau mot de passe. L'identifiant et le mot de passe ont été laissé comme initialement.
+ le login par défaut est « pi », et le password est « raspberry »
@@ Ligne 546 : / Ligne 866 : @@
 Pour l'équipe 2 :
-Création du script de base d'allumage d'une led en fonction du fichier C envoyé par le serveur.
+Durant cette séance, plusieurs autres configurations ont été effectuées. Pour accéder à la fenêtre de configuration, il a fallu rentrer la commande :
+ sudo raspi-config
+Maintenant que notre système Raspbian est un peu plus sécurisé, nous allons nous assurer que le SSH est bien activé afin que nous puissions prendre le contrôle de la Raspberry à distance. Pour cela, il faut sélectionner le huitième choix, « Advanced Options ». Cette fois, après validation nous arrivons sur un autre menu ou nous allons choisir la quatrième ligne, « SSH ». Puis « Enable », et enfin « Valider ». Le système lance quelques commandes puis nous ré-affiche une fenêtre nous indiquant le succès de l’opération.
@@ Ligne 572 : / Ligne 895 : @@
 Voici le lien qui m'a principalement aidé à mieux comprendre et trouver les fonctionnalités du Debian : <br/>
 https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019
 ----
 Pour l'équipe 2 :
-Documentation sur le montage qui permet de contrôler une led grâce à une raspberry et à un code créé permettant d'allumer ou d'éteindre la led
+Une fois la Raspberry configuré, il a fallu installer la bibliothèque wiringPi. Pour se faire :
+On installe GIT:
+ sudo apt-get install git-core
+On met a jour le PI:
+ sudo apt-get update
+ sudo apt-get upgrade
+On récupère la dernière version de WiringPi:
+ git clone git://git.drogon.net/wiringPi
+On se place dans le bon répertoire:
+ cd wiringPi
+On lance la compilation:
+ ./build
+Puis le lancement du code créé pour l'allumage des LED s'effectue de la manière suivante:
+ gcc blink.c -o blink -lwiringPi
+ ./blink
+Le fichier blink étant notre fichier contenant le script permettant l'allumage d'une led toute les 0.5s.
@@ Ligne 604 : / Ligne 946 : @@
 on ne voit plus l'interface, j'ai décidé de rechercher les causes de ce problème, en supposant que la carte a été court-circuiter. <br/>
 Donc cette séance n'a été que la recherche de ce problème et surtout pouvoir le résoudre.
+N'ayant aucune idée après plusieurs séances de recherche, j'ai décidé de voir mes tuteurs afin de pouvoir <br/>
+résoudre ce problème car je suis vraiment en retard par rapport à mon objectif fixé qui était <br/>
+de configurer la BPI-R1 en routeur wifi pour qu'elle puisse donner les informations à la Rasberrie -PI.<br/>
+Après plusieurs essaies, c'est à dire changer le courant d'Alimentation, mettre de nouveau l'image Debian <br/>
+au final, mes tuteurs m'ont conseillé de changer l'image et d'en mettre un nouveau mais aussi il faut que <br/>
+que cette image soit récente afin de ne pas avoir de problème au niveau du noyau de la carte.
 ----
 Pour l'équipe 2 :
+Installation d'un premier câblage pour réaliser l'allumage d'une des 4 LED en fonction de la LED sélectionné.
+Il a fallu trouver grâce à différent test le bon schéma de pin de notre Raspberry car il en existait beaucoup de différent sur le numéro du pin à entrer pour allumer la led correspondante à ce numéro.
+[[Fichier:Pin.png|200px|thumb|center|Différent PIN de sortie de notre Raspberry Pi 3]]
@@ Ligne 635 : / Ligne 988 : @@
 Pour l'équipe 1 :
-Le problème persiste toujours, ne sachant toujours pas les raisons de ce problème, cette séance sera consacrée aussi à<br/>
+Le problème est enfin résolu mais il faut vite rattraper le retard, donc aujourd'hui, on a consacré cette séance dans l'utilisation de l'Armbian.
-la recherche sachant que le retard commence à peser et que je n'ai toujours pas configurer la BPI-R1 en routeur <br/>
-et que je sais que je suis en retard par rapport aux deux autres équipes.
@@ Ligne 664 : / Ligne 1 015 : @@
 Pour l'équipe 1 :
+[[Fichier:Ahb.jpg|thumb|100 px|right|Interface Armbian]]
+[[Fichier:glopi.jpg|thumb|100 px|right|Interface Armbian|Différentes configuration de la BPI R1]]
+Donc suite au problème qui ont eu lieu ces dernières séances, et après avoir reçu des conseils de <br/>
+mes tuteurs, j'ai fait une nouvelle des recherches sur l'image la plus récente qui va me permettre <br/>
+de faire marcher ma carte et visualiser l'interface de l'OS. Après avoir fait un tour sur le site (lien ci dessous)<br/>
+http://wiki.banana-pi.org/Banana_Pi_BPI-R1<br/>
+qui propose différentes images et ne sachant vraiment lequel choisir, j'ai choisi de mettre un Armbian 2016 et <br/>
+et avec la même commande me permettant de copier sur carte SD que l'OpenWrt afin de le mettre sur la carte<br/>.
+Au final, cela marche, et je me connecte avec "root" qui a pour mot de passe "1234". Après s'être connecter <br/>
+on obtient cette interface.<br/>
+Sachant que je suis énormément en retard par rapport aux deux autres équipes, surtout celui de la <br/>
+qui a presque terminé sa partie, mon objectif est finalement à ce que ma banana PI marche seulement <br/>
+en tant que routeur Wifi. Et donc en partant de l'OS Armbian et que le principe de la programmation est à <br/>
+peu près similaire que celle de la Rasberrie PI. Donc je me suis servi du même raisonnement que celui de ce lien :<br/>
+https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019#Connexion_s.C3.A9rie <br/>
+[[Fichier:Exempled.jpg|thumb|100px|right|Configuration du routeur]]
+La première chose était d'abord d'installer le packtage Hostapd, car c'est ce packtage qui contient tous les <br/>
+fichiers me permettant d'activer le routeur Wifi :
+ apt-get install hostapd
+Ensuite afin de pouvoir mofidier le fichier de configuration de <code>hostapd</code> qui se trouve dans le répertoire <code>/usr/share/doc/hostapd/examples/</code>  et le coller dans le répertoire <code>/etc/hostapd</code> :
+  cp /usr/share/doc/hostapd/examples/hostapd.conf.gz /etc/hostapd
+  gunzip /etc/hostapd/hostapd.conf.gz
+Et finalement avec l'éditeur de texte nano, on peut modfier le fichier <code> /etc/hostapd/hostapd.conf</code>les mots-clefs suivants :
+* <code>ssid</code>, indiquez le nom de réseau WiFi ;
+* <code>country_code</code>, mettez le code de la France <code>FR</code> ;
+* <code>channel</code>
+* <code>wpa</code>, activez l'option (mettre à 1) ;
+* <code>wpa_passphrase</code>, configurer un mot de passe pour notre réseau (au moins 8 caractères) ;
+* <code>wpa_key_mgmt</code>, à configurer à la valeur <code>WPA-PSK</code>.
+Enfin il faut definir le chemin du fichier de configuration à l'aide du fichier <code>/etc/default/hostapd</code> :
+ DAEMON_CONF=/etc/hostapd/hostapd.conf
+On relance le service avec la commande  :
+ service hostapd restart
+Au final, on arrive à faire apparaître le nom du reseau de la banana sans fil
+[[Fichier:klkl.png|thumb|100px|right|Nom visible sur le smartphone]]
+Mais le problème, c'est que si on tape le même mot de Passe sur le smartphone, ça nous renvoie erreur d'authentification <br/>
+au lieu de l'erreur détection IP. Au final, on va de nouveau changé l'OS et de recommencer toute la procédure. Donc le problème du routeur sera résolu l'année prochaine.
-N'ayant aucune idée après plusieurs séances de recherche, j'ai décidé de voir mes tuteurs afin de pouvoir <br/>
-résoudre ce problème car je suis vraiment en retard par rapport à mon objectif fixé qui était <br/>
-de configurer la BPI-R1 en routeur wifi pour qu'elle puisse donner les informations à la Rasberrie -PI.<br/>
-Après plusieurs essaies, c'est à dire changer le courant d'Alimentation, mettre de nouveau l'image Debian <br/>
-au final, mes tuteurs m'ont conseillé de changer l'image et d'en mettre un nouveau mais aussi il faut que <br/>
-que cette image soit récente afin de ne pas avoir de problème au niveau du noyau de la carte.
@@ Ligne 702 : / Ligne 1 091 : @@
 -----
-===Semaine 12 - A RETIRER===
+===Documents Rendus===
-[[Fichier:Ahb.jpg|thumb|100 px|right|Interface Armbian]]
-Pour l'équipe 1 :
+*Gitlab : [https://archives.plil.fr/grouille/IMA3_P10 Git IMA3 P10]
-[[Fichier:glopi.jpg|thumb|100 px|right|Interface Armbian|Différentes configuration de la BPI R1]]
+*Site web  : [http://houplin.studserv.deule.net/~grouille/PROJET/ Site]
-Donc suite au porblèe qui ont eu lieu ces dernières séances, et après avoir reçu des conseils de <br/>
+*Rapport : [[media: Rapport_IMA3_P10.pdf]]
-mes tuteurs, j'ai fait une nouvelle des recherches sur l'image la plus récente qui va me permettre <br/>
-de faire marcher ma carte et visualiser l'interface de l'OS. Après avoir fait un tour sur le site (lien ci dessous)<br/>
+==Projet S7==
-http://wiki.banana-pi.org/Banana_Pi_BPI-R1<br/>
-qui propose différentes images et ne sachant vraiment lequel choisir, j'ai choisi de mettre un Armbian 2016 et <br/>
+===Objectifs===
-et avec la même commande me permettant de copier sur carte SD que l'OpenWrt afin de le mettre sur la carte<br/>.
-Au final, cela marche, et je me connecte avec "root" qui a pour mot de passe "1234". Après s'être connecter <br/>
+Pour l'équipe 1 :
-on obtient cette interface.<br/>
-------------------
+*Remplacement de Ziyad Houssaini par Loris Ahouassou.
+*Notre équipe s'occupe de la partie routeur, qui doit être reprise au début.
+*Les objectifs sont de fournir un accès internet aux Raspberrys, et de permettre l'envoi des fichiers de données aux bonnes Raspberry.
+----
+Pour l'équipe 2 :
+*Maintenant que nous avons réussi à scruter le serveur pour y récupérer les fichiers, et que l'allumage des LEDs est fonctionnel, il faut qu'on configure les Raspberry pour qu'elles fournissent un retour au serveur.
+*Parallèlement à ça, nous devons permettre la reconfiguration de plusieurs types de microcontrôleurs (Cortex M0 ou M4, Atmega328p) à partir de la Raspberry. Ainsi, peut importe le capteurs (situés sur n'importe quel type de microcontrôleurs), il sera utilisable sans besoin de le reprogrammer directement.
+----
+Pour l'équipe 3 :
+*Lors du S6, notre équipe à réaliser une interface Web statique permettant à l'utilisateur de dialoguer avec un serveur et une Raspberry Pi. Il faut maintenant le rendre dynamique en ajoutant un Framework Java Script (Vue.JS) et créer un nouveau système permettant l'affichage des données reçues.
+*Parallèlement, il faut créer une nouvelle table dans laquelle seront entrées les données reçues des capteurs. Le routeur devra donc réaliser du pré-traitement afin d'entrer les valeurs reçues dans la base.
+----
+===Réalisation===
+Pour l'équipe 1 :
+Cette partie a été mise en suspend car elle n'est pas indispensable au fonctionnement du projet.
+----
+Pour l'équipe 2 :
+Ce semestre, nous avions pour objectif de faire communiquer la Raspberry Pi avec l'Arduino UNO en ICSP.<br/>
+Nous devons utiliser l'Arduino UNO comme support pour les différents capteurs. Ainsi, la Raspberry n'aura qu'un rôle intermédiaire de compilation.<br/>
+Il faut donc que l'on connecte ensemble ces deux cartes. Nous avons choisi de ne pas passer pas les ports USB, car dans le cas contraire, notre projet est assez simplifié. Nous avons choisi de passer par les pins SPI pour connecter l'ensemble.
+Ainsi, nous avons effectué quelques manipulations, expliquées ci-dessous.
+[[Fichier:RaspberryPiArduino2.png|500px|thumb|right|Connexion SPI Raspberry Pi - Arduino UNO]]
+*Installation de avrdude
+ apt-get install avrdude
+ avrdude -v (pour vérifier l'installation)
+*Configuration de avrdude
+ cp /etc/avrdude.conf ~/avrdude_gpio.conf
+ nano ~/avrdude_gpio.conf
+Nous avons cherché cette partie du code :
+ #programmer
+ #  id    = "linuxgpio";
+ #  desc  = "Use the Linux sysfs interface to bitbang GPIO lines";
+ #  type  = "linuxgpio";
+ #  reset = ?;
+ #  sck   = ?;
+ #  mosi  = ?;
+ #  miso  = ?;
+ #;
+Pour la changer en :
+ programmer
+   id    = "pi_3";
+   desc  = "Use the Linux sysfs interface to bitbang GPIO lines";
+   type  = "linuxgpio";
+   reset = 4;
+   sck   = 11;
+   mosi  = 10;
+   miso  = 9;
+ ;
+*Test de connexion
+ avrdude -p atmega328p -C ~/avrdude_gpio.conf -c pi_3 -v
+Nous avons néanmoins rencontré un problème concernant les pins. La Raspberry n'arrivait pas à exporter certains pins :
+*Erreur rencontrée
+ can't export GPIO 10, already exported/busy?
+La même erreur survenait pour d'autres pins.
+Après quelques recherches, nous avons trouvé comment régler ces problèmes.
+*Nous avons visualisé donc les GPIOs non exportés à l'aide de la commande suivante
+ gpio exports
+Cela nous a permis d'exporter manuellement les GPIOs concernés.
+*Pour exporter manuellement les GPIOs dont nous avions besoin :
+ echo 4 > /sys/class/gpio/unexport
+ echo 10 > /sys/class/gpio/unexport
+ echo 11 > /sys/class/gpio/unexport
-===Semaine 13 - A RETIRER===
+Suite à cela, la Raspberry pi était désormais capable de se connecter à l'atmega328p.
-Pour l'équipe 1 :
-Sachant que je suis énormément en retard par rapport aux deux autres équipes, surtout celui de la <br/>
+*Création d'un programme test à l'aide de l'IDE Arduino
-qui a presque terminé sa partie, mon objectif est finalement à ce que ma banana PI marche seulement <br/>
+Nous avons utilisé un programme exemple disponible dans l'IDE. Nous avons activé la compilation dans les préférences et compiler le programme blink qui fait clignoter une led (GPIO 13).
-en tant que routeur Wifi. Et donc en partant de l'OS Armbian et que le principe de la programmation est à <br/>
+Ensuite, nous avons uploadé le fichier .hex créé sur l'Arduino UNO.
-peu près similaire que celle de la Rasberrie PI. Donc je me suis servi du même raisonnement que celui de ce lien :<br/>
+ avrdude -p atmega328p -C ~/avrdude_gpio.conf -c pi_3 -v -U flash:w:/tmp/build4952970404801881316.tmp/Blink.cpp.hex:i
-https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019#Connexion_s.C3.A9rie <br/>
-[[Fichier:Exempled.jpg|thumb|100px|right|Configuration du routeur]]
-La première chose était d'abord d'installer le packtage Hostapd, car c'est ce packtage qui contient tous les <br/>
-fichiers me permettant d'activer le routeur Wifi :
- apt-get install hostapd
-Ensuite afin de pouvoir mofidier le fichier de configuration de <code>hostapd</code> qui se trouve dans le répertoire <code>/usr/share/doc/hostapd/examples/</code>  et le coller dans le répertoire <code>/etc/hostapd</code> :
+*Résultats
-  cp /usr/share/doc/hostapd/examples/hostapd.conf.gz /etc/hostapd
+[[Média:Avrdude.txt]]
-  gunzip /etc/hostapd/hostapd.conf.gz
+On observe bien clignoter la led branchée sur le GPIO 13, ce qui veut dire que l'upload a fonctionné.
-Et finalement avec l'éditeur de texte nano, on peut modfier le fichier <code> /etc/hostapd/hostapd.conf les mots-clefs suivants :
+Il nous faut maintenant compilé notre fichier C pour pour obtenir le fichier .hex.<br/>
-* <code>ssid</code>, indiquez votre nom de réseau WiFi ;
+Pour cela nous allons créer un Makefile.
-* <code>country_code</code>, mettez le code de la France <code>FR</code> ;
-* <code>channel</code>, faites en sorte que les Raspberry n'écoutent pas toutes sur le même canal ;
-* <code>wpa</code>, activez l'option (mettre à 1) ;
-* <code>wpa_passphrase</code>, donnez le mot de passe de votre réseau (au moins 8 caractères) ;
-* <code>wpa_key_mgmt</code>, à configurer à la valeur <code>WPA-PSK</code>.
-Enfin il faut definir le chemin du fichier de configuration à l'aide du fichier <code>/etc/default/hostapd</code> :
+*Problèmes rencontrés
- DAEMON_CONF=/etc/hostapd/hostapd.conf
+Nous avons tenté de compiler notre code avec le Makefile d'Arduino. La compilation s'effectue sans problème mais lorsque le code est uploadé sur la carte, la LED s'allume et ne clignote pas comme elle devrait le faire.<br/>
-On relance le service avec la commande  :
+Nous avons essayé de faire un Makefile en partant de celui utilisé en tutorat de Système.<br/>
- service hostapd restart
+Après modification, nous n'arrivons pas à compiler car le compilateur n'arrive pas à accéder à la librairie wiringPi.<br/>
+En effet, nous avons réfléchi à notre Makefile en considérant le code prévu pour la Raspberry Pi. Cependant, le code était destiné à l'ATMega328p, d'où l'erreur lors de la compilation.
-Au final, on arrive à faire apparaître le nom du reseau de la banana sans fil
+*Résolution des problèmes
-[[Fichier:klkl.png|thumb|100px|right|Nom visible sur le smartphone]]
+Nous nous sommes rendu compte que la librairie wiringPi n'était pas utile et surtout pas utilisable sur l'ATMega328p.<br/>
+En la remplaçant par les librairies avr/io et util/delay, le projet compile sans erreur et s'execute correctement sur l'ATMega328p.
+[[File:Video_test.mp4|500px]]
+----
-Mais le problème, c'est que si on tape le même mot de Passe sur le smartphone, ça nous renvoie erreur d'authentification <br/>
+Pour l'équipe 3 :
-au lieu de l'erreur détection IP. Sur le coup encore perdu, j'ai du demander de l'aide à mon tuteur et au final, il s'est avéré <br/>
-que j'ai mis un mauvais OS et que j'ai détruit le noyau de la carte. Du coup, le problème du routeur sera résolu l'année prochaine.
-===Documents Rendus===
+Cette partie sera traitée au S8.
-*Gitlab : [https://archives.plil.fr/grouille/IMA3_P10 Git IMA3 P10]
+L'objectif sera de créer une nouvelle table sans la base de données, permettant de récupérer les données venant des capteurs (des Raspberrys).<br/>
-*Site web  : [http://houplin.studserv.deule.net/~grouille/PROJET/ Site]
+Il faudra également modifier le site afin d'ajouter une page permettant l'affichage de ces données.
-==Projet S7==
+----
 ===Documents Rendus===
+*Pré-Rapport : [[media: Rapport_P10_S7.pdf]]
+<br/>
+<br/>
 ==Projet S8==
+===Objectifs===
+Suite à la soutenance de projet en fin de S7, nous avons de nouveaux objectifs :
+'''Equipe 1'''
+*Faire communiquer l'Arduino UNO et la Raspberry Pi dans les 2 sens ;
+*Créer le code pour le capteur de température et visualisation des données sur le port série avec minicom ;
+*Créer le code pour le capteur de distance et visualisation des données sur le port série avec minicom ;
+*Créer le script Python permettant le retour de données vers le serveur ;
+*Créer le Makefile générique ;
+*Intégrer la Nucléo dans le projet.
+'''Equipe 2'''
+*Rendre Ansible fonctionel.
+'''Equipe 3'''
+*Créer la page permettant de récupérer les données des capteurs par requête POST ;
+*Créer la fonction de mise à jour de la base de données.
+*Créer la table qui contiendra l'historique de valeurs ces capteurs ;
+*Créer les pages de recherche dans cet historique ;
+*Modifier la fonction de mise à jour de la base de données pour intégrer l'historique ;
+*Création des pages permettant l'ajout d'une raspberry ou d'un capteur ;
+*Création des fonctions associées ;
+*Créer le fichier inventaire.ini utile à l'équipe 2 à partir du site à l'ajout d'un capteur ou l'envoi d'un code ;
+*Migration du site et de la base données sur un nouveau serveur sur plil.fr ;
+*Créer les pages permettant l'affichage des graphes de valeurs des capteurs ;
+*Création des fonctions associées ;
+*Permettre le lancement d'Ansible depuis le site ;
+*Créer une page permettant la visualisation graphique de l'ensemble du réseau de capteurs et des caractéristiques de chaque nœud ;
+*Permettre aux administrateurs de créer et supprimer des comptes.
+===Réalisation===
+====Equipe 1====
+Ici, il s'agira d'utiliser les capteurs afin d'obtenir des données "concrètes" à renvoyer à la RaspberryPi.<br/>
+Il s'agira également, avant envoi au serveur (cf Équipe 3), de récupérer les données sur le port série de la Raspberry afin de les stocker dans les fichiers adéquats. <br/>
+{| class="wikitable"
+! Objectif !! État
+|-
+|
+Tester l'envoi de données sans capteurs avec la liaison USB
+|
+<font color='green'>Fait</font>
+|-
+|
+Tester l'envoi de données sans capteurs avec la liaison série UART TX/RX
+|
+<font color='Blue'>Annulée, Obsolète</font>
+|-
+|
+Intégrer le capteur de température et envoi des résultats au port série via USB
+|
+<font color='green'>Fait</font>
+|-
+|
+Intégrer le capteur ultrasons et envoi des résultats au port série via USB
+|
+<font color='green'>Fait</font>
+|-
+|
+Depuis la Raspberry, script de stockage des résultats dans fichier XML
+|
+<font color='green'>Fait, </font><font color='blue'>Obsolète</font>
+|-
+|
+Faire de même avec la Nucleo M4
+|
+<font color='orange'>Suspendue (qqs PBs techniques)</font>
+|-
+|
+Depuis la Raspberry, modification du script python d'envoi des données au serveur pour distinguer automatiquement l'adresse IP et obtenir le numéro du capteur
+|
+<font color='green'>Fait</font>
+|-
+|
+Ajustement des codes capteur et Température de façon à ce qu'ils utilisent tout les deux une fonction généraliste de retour de données
+|
+<font color='green'>Fait</font>
+|-
+|
+Mise en place d'un unique makefile généraliste pouvant uploader le bon code selon le type de capteur
+|
+<font color='Green'>Terminé</font>
+|-
+|}
+======Semaine 1======
+*'''Retour des données'''<br/>
+Dans un premier temps, nous devons chercher à récupérer les données issues des capteurs pour les transmettre à la RaspberryPi.<br/>
+Dans un second temps, nous allons gérer la transmission des données de la RaspberryPi vers le serveur.<br/>
+Pour le premier volet, nous allons commencer par réaliser un test (sans capteurs) et récupérer un caractère envoyé par l'Arduino UNO vers la Raspberry Pi en liaison série.
+Pour se faire, plusieurs moyens s'offrent éventuellement à nous : l'utilisation du bus SPI ou de la liaison série par l'intermédiaire de l'USB (ou USART TX-RX). Nous avons opté pour cette dernière solution plus simple à mettre en place.
+Notre premier test a été réalisé avec la liaison USB. Ainsi, nous avons flashé l'Arduino UNO avec un code (arduinoToRpi.c) permettant d'envoyer un caractère sur la liaison série et qui pourra être vu par la RaspberryPi.
+Ce code est inspiré de celui utilisé dans le tutorat système du S7.
+Pour lire ce qui se trouve sur la liaison série, nous avions plusieurs solutions.
+*La première était d'installer minicom sur la Raspberry, mais après plusieurs tentatives d'installation (car le réseau était plutôt défavorable à ce moment là), nous avons changé d'idée.<br/>
+*Deuxièmement, nous nous sommes penchés sur l'utilisation d'un script python minimaliste à l'aide du module "Pyserial", qui n'a pas fonctionné. Nous pensons que le problème n'est pas tant lié au code en lui-même, qui nous semble correct, mais en la configuration de la RaspberryPi.
+ #!/usr/bin/env python
+ import serial
+ ser = serial.Serial('/dev/ttyACM0', 9600, timeout=1)
+ while 1:
+   print(ser.readline())
+*La troisième tentative fonctionnait. Nous avons récupéré un code C permettant de lire le port que nous souhaitions. Le caractère envoyé par l'Arduino a bien été récupéré.
+Nous avons donc réussi à faire communiquer la Raspberry Pi et l'Atmega328P dans les deux sens.
+Maintenant, l'objectif est de permettre le retour Atmega328P-->RaspberryPi non pas par USB mais en utilisant l'USART (via les broches Tx-Rx).
+------
+<br/>
+======Semaine 2======
+La séance suivante, nous avons réglé le problème empêchant le script python de s'exécuter correctement. En effet, son exécution supposait un contrôle du port serie par l'intermédiaire du terminal, mais il fallait l'autoriser au préalable.<br/>
+*'' Démarrer l'utilitaire de configuration système de la Raspberry:''
+ sudo raspi-config
+*'' Ouvrir les options d'interface serie''<br/>
+*'' Choisir "oui" pour accepter le contrôle via le terminal''<br/>
+Nous avons ensuite mis à jour la Raspberry Pi avec la commande <b>apt update</b>
+Cette mise à jour a permis le téléchargement et l'installation de minicom. Il nous est donc plus facile de visualiser le contenu arrivant sur le port série.<br/>
+Nous avons remarqué que la Raspberry Pi ne possédait qu'un unique UART. Ainsi, si nous voulons exécuter des scripts dans le terminal qui utilise le port série, nous ne pouvons pas en même temps récupérer les données via l'UART.<br/>
+Pour résoudre cette difficulté, nous avons choisi de travailler avec un "soft uart". Celui-ci devrait nous permettre d'utiliser d'autre GPIOs de la Raspberry en tant que port série (TX, RX).
+Nous avons donc utilisé un module créé par Adriano Marto, nous permettant de réaliser cette opération :
+ https://github.com/adrianomarto/soft_uart
+Après le téléchargement, nous avons tenté de faire un "make" comme demandé. Cependant, il semblerait que la version du packet <b>raspberrypi-kernel-headers</b> que nous avons installé précedemment ne corresponde pas au noyau de notre Raspberry.<br/>
+Le problème est que ce sont des téléchargements automatiques donc nous ne pouvons pas choisir la version. <br/>
+La version du noyau étant inférieure à celle du packet, nous avons essayé la commande <b>apt upgrade</b>. Après la mise à jour, il semblerait que nous disposions déjà de la dernière version du noyau.
+----
+<br/>
+=====Semaine 3=====
+Au démarrage de la Raspberry, nous avons lancé par hasard la commande <b>uname -r</b>. Nous avons été surpris de voir que la version du noyau correspondait maintenant à celle du packet <b>raspberrypi-kernel-headers</b>.<br/>
+Nous avons donc tenté l'installation du soft uart, avec succès. Il nous fallait maintenant envoyer des données depuis l'Arduino UNO pour les récupérer via TX/RX.<br/>
+Nous avons réalisé un diviseur de tension pour faire correspondre la tension des pins de l'Arduino UNO (5V) et de la Raspberry (3.3V).<br/>
+Une fois les branchements faits, nous avons créé grâce à l'IDE Arduino un code utilisant la bibliothèque <b>Serial.h</b>. Ce code devait simplement envoyé un caractère sur la liaison TX/RX.<br/>
+Là, nous avons rencontré un problème : nous ne recevions aucune donnée. Nous avons donc décidé de passer par les pins RX/TX de la Raspberry et de laisser de côté le soft uart.<br/>
+Le problème persistant toujours, nous avons donc décidé de mettre provisoirement de côté la partie communication par RX/TX pour avancer sur le reste, car la communication par liaison USB série fonctionne correctement.<br/><br/>
+En étant connecté par liaison USB, l'objectif consistait maintenant à connecter les capteurs et ainsi transférer de vraies données à la Raspberry.
+Pour se faire, il nous fallait donc écrire les codes utiles pour tester ces capteurs en utilisant le '''langage C''' avec la librairie '''avr'''.<br/>
+*'''Test du capteur de température ST039:''' <br/>
+[[Fichier:Temperature_capteur.jpg|200px|thumb|center|Iduino ST039 (LM35)]]
+Il est basé sur le LM35 et délivre un signal analogique variant entre 0 et 5V selon la température mesurée. La température résultante quant à elle se situe sur la plage 0-100°c avec une précision de 0.5°c.<br/><br/>
+*''Branchement'' :<br/>
+Ci-dessous, le branchement avec une carte Arduino uno.
+[[Fichier:Temperature_branchement.png|400px|thumb|center|Branchement]]
+<br/>
+*''Code '':<br/>
+Nous disposons déjà des fonctions d'envoi de caractères sur le port série. La principale difficulté de ce code résidait dans l'utilisation du convertisseur analogique-numérique afin de lire sur l'entrée analogique voulue.<br/>
+Pour cela, nous avons créé une fonction (équivalente à AnalogRead() de L'IDE arduino) nous retournant le résultat numérique de la conversion.
+ '''''int analogReadNew(uint_8 pin)'''''{
+    //Selection de la fréquence du prescaler
+    ADCSRA |= ('''1'''<<ADPS2)|('''1'''<<ADPS1)|('''1'''<<ADPS0);
+    //Définition de la référence de tension
+    ADMUX |= ('''1'''<<REFS0)|('''1'''<<ADLAR);
+    //Sélection de l'entrée analogique selon le pin
+    ADMUX = (ADMUX&'''0xf0''')|pin;
+    //Activation de l'ADC
+    ADCSRA |= ('''1'''<<ADEN);
+    //Lancement de la conversion
+    ADCSRA |= ('''1'''<<ADSC);
+    //On attend la fin de la conversion
+    while(bit_is_set(ADCSRA, ADSC));
+    //Résultat
+    return ADCH;
+  }
+Ensuite, il nous fallait normaliser ce résultat afin d'avoir la température en degrés.
+  reading=analogReadNew(0);
+  temperature = reading * 1.9607843;
+  //1.960743 = (5.0/1023.0)*100*4
+La température était ensuite envoyée sur le port série pour être visible depuis la RaspberryPi.<br/>
+*''Résultat ''<br/>
+[[Fichier:Temperature_resultat.png|500px|thumb|center|Résultats du test]]
+<br/><br/>
+=====Semaine 4=====
+Cette quatrième semaine a servi à tester le capteur de distance et à intégrer les données recueillis par la Raspberry dans un fichier.<br/>
+*'''Test du capteur à ultrasons HC-SR04''' : <br/>
+[[Fichier:Distance_capteur.jpg|200px|thumb|center|HC-SR04]]
+Ce capteur ultrason utilise le principe de fonctionnement d'un capteur laser mais se base sur des ondes sonores (inaudibles pour l'homme) à la place d'un faisceau lumineux. Il est beaucoup moins cher qu'un capteur laser, toutefois il reste imprécis. On note néanmoins que ses mesures restent insensibles à la luminosité ambiante et à l'opacité de la surface en face.<br/>
+Le HC-SR04 fonctionne avec une tension d'alimentation de 5V, un angle de mesure d'environ 15° et permet (sur le papier) d'obtenir des mesures de distance variant de 2cm à 4m avec une précision de 3mm (en pratique, ce n'est pas si précis que cela).<br/><br/>
+*''Principe de fonctionnement '':<br/>
+En utilisant la vitesse du son, les étapes d'une prise de mesure sont les suivantes : <br/>
+* Une impulsion HIGH de 10µs est envoyée sur la broche TRIGGER du capteur.
+* Ensuite une série de 8 impulsions ultrasoniques est envoyée par le capteur
+* Puis, dans l'air, les ultrasons se propagent pour toucher un obstacle et font le chemin retour vers le capteur.
+* Enfin, le capteur capte l'écho et achève la prise de mesure.
+Précisons que le signal présent sur le pin ECHO du capteur reste à HIGH durant les deux dernières étapes, permettant ainsi de connaître la durée de l'aller-retour des ultrasons et donc de déterminer la distance.
+[[Fichier:Distance_signal.jpg|400px|thumb|center|Fonctionnement]]
+<br/>
+*''Branchement '':
+[[Fichier:Distance_branchement.jpg|300px|thumb|center|Branchement]]
+<br/>
+*''Code '':
+Le code consiste à réaliser les étapes décrites ci-dessus et à transférer le résultat sur le port série. La seule difficulté ici réside dans la mise en place de l'acquisition du temps d'aller-retour.
+Pour cela, nous utiliserons un timer et nous procéderons par interruption (INT0) sur un changement logique.
+  //Trigger = PIND0 et ECHO = PIND2
+  DDRD = '''0b11111011''';
+  _delay_ms('''50''');
+  //Selection INT0
+  EIMSK |= ('''1'''<<INT0);
+  //Interruption sur changement logique
+  EICRA = '''0x01''';
+  sei();
+Nous mettons en place le trigger :
+  //TRIGGER HIGH
+    PORTD |= 1<<PIND0;
+    //Durée de l'impulsion TRIGGER
+    _delay_us('''10''');
+    //TRIGGER LOW
+    PORTD &= ~('''1'''<<PIND0);
+À chaque interruption, nous mesurons la durée :
+  '''''ISR(INT0_vect)'''''{
+    //i=1 indique l'écho HIGH
+    if(i == '''1''')
+    {
+      //On arrête le timer
+      TCCR1B = '''0''';
+      //On stocke la valeur précédente du timer (l'aller-retour)
+      pulse = TCNT1;
+      //On reset la valeur de TCNT1 et de i à Zero
+      TCNT1 = '''0''';
+      i = '''0''';
+    }
+    //i=0 indique l'écho à LOW
+    if(i=='''0''')
+    {
+      //On set le bit CS10 à HIGH, debut du timer qui compte
+      TCCR1B |= ('''1'''<<CS10);
+      i = '''1''';
+    }
+   }
+La durée mesurée est ensuite normalisée et on effectue le calcul pour obtenir la distance (ici, en cm) qui sera ensuite envoyée sur le port serie.
+  //On calcule la distance en cm : pulse/(58/2/10)  (en cm)
+    count_a = pulse/'''1160.0''';
+La distance est ensuite envoyée sur le port serie pour être disponible sur la RaspberryPi.
+*''Résultat '':
+Tout fonctionne correctement, ci-dessous un capture du résultat:
+[[Fichier:Distance_resultat.png|500px|thumb|center|Résultat]]
+<br/>
+*'''Coté Raspberry : Préparation des résultats pour envoi au serveur'''
+Ici, les résultats sont disponibles uniquement sur le port serie. Ce que nous voulons, c'est les stocker dans un fichier qui sera ensuite exportable vers le serveur.
+Pour cela, nous nous sommes entendus sur le format XML. En effet, comme il a été mentionné plus bas par l'équipe 3, nous devons avoir un fichier de cette forme :
+  <capteur>
+      <parametre name="ip_address">172.26.145.X</parametre>
+      <parametre name="numero">Y</parametre>
+      <parametre name="name">Nom</parametre>
+      <parametre name="data">AB.C</parametre>
+  </capteur>
+Pour cela nous avons réalisé un script Python en usant du module serial et du module lxml pour créer des fichiers XML.
+Installation du module lxml
+  pip3 Install lxml
+Le programme récupère la donnée sur le port série et la met à sa place préétablie dans un fichier xml de base existant.
+  import serial
+  from lxml import etree
+  capteur = etree.parse("111-1.xml")
+  ser = serial.Serial("/dev/ttyACM0", '''9600''', timeout = '''1''')
+  value = ser.readline()
+  while(value in ['\r', '']):
+       value = ser.readline()
+  value = float(value)
+  for parametre in capteur.getroot().getchildren():
+       if "name" in parametre.attrib and parametre.attrib["name"] == "data":
+           parametre.text = str(value)
+  with open("111-1.xml", 'w') as myFile:
+       capteur.write("111-1.xml")
+  myFile.close()
+Nous avons testé ce script et c'est fonctionnel. Nous sommes désormais capables de renvoyer les données issues des capteurs jusqu'au serveur.
+=====Semaine 5=====
+*'''Retour des données par requête POST'''
+Le retour des données étant effectif, cette cinquième semaine a été l'occasion de faire une petite démonstration à nos encadrants concernant l'aller (flash) et le retour des données.<br/>
+Il en est ressorti une suggestion quant à la partie de l'équipe 1 :<br/>
+- Au lieu d'utiliser un système de fichier au format XML, il nous a été suggéré d'utiliser une simple requête POST dans notre script python pour envoyer nos données.
+(cf Équipe 3 pour plus de détails).
+*'''Différenciation des capteurs'''
+Pour notre retour de données, nous voulons diversifier nos cas de tests. En effet, nous aimerions avoir : <br/>
+*''Cas 1'' : un capteur de température ou de distance relié à une carte <br/>
+*''Cas 2'' : deux capteurs différents reliés à une même carte <br/>
+*''Cas 3'' : deux capteurs identiques reliés à une même carte <br/>
+Il faut donc que nous soyons capables d'identifier clairement nos capteurs afin de pas confondre les données remontées.
+[voir la méthode].<br/>
+De cette façon, il nous sera plus facile d'identifier nos capteurs (en particulier dans les Cas 2 et 3). Le script python se chargera de découper la chaîne reçue pour extraire chacun des paramètres et ainsi faire la requête POST par la suite.
+=====Semaine 6=====
+Durant cette semaine, le travail consistait à trouver un moyen d'utiliser la carte nucleo, étant donné que nous n'en avons jamais manipulé.<br/><br/>
+Après s'être documenté, il est apparut qu'il y avait plusieurs solutions pour l'utiliser : Via des Environnements dédiés (tels que Mbed compiler en ligne et d'autres environnements Offline).<br/>
+Seulement, la solution intéressante pour nous résiderait dans l'utilisation d'un outil pour compiler en ligne de commande. (tout comme avec les arduino). Pour se faire nous avons donc trouvé l'outil dédié, créé par ARM-MBED, à savoir mbed-cli qui comme (avr-gcc) permet la compilation et l'upload sur des architectures ARM (avec arm-gcc).<br/><br/>
+[Rajouter les portions codes pour les étapes d'installation de l'outil]
+Un premier test d'upload de code pour faire clignoter une led a été concluant.
+*'''Problème'''
+Suite à ce premier test, la carte, un fois connectée en USB, se déconnectait au bout de quelques secondes (testé sur mon pc tournant sous ubuntu 18.04). Donc impossible de re-upload à nouveau des codes.
+=====Semaine 7=====
+Pour cette semaine, l'objectif était de trouver une solution pour la Nucleo, et sinon mettre cette étape en attente pour avancer sur d'autres tâches. <br/>
+N'ayant pas pu palier au problème de déconnexion sur mon pc personnel, Nous nous sommes dirigés directement sur la Raspberry pour effectuer les mêmes étapes. Le problème lié à la déconnexion n'en était plus un.<br/>
+Cependant Nous avons rencontré quelques problèmes au début liés à la connexion, mais nous avons par la suite pu installer les composantes nécessaires.
+Toutefois, d'autres problèmes sont survenus, probablement liés à des dépendances de librairies incomplètes et de problèmes de versions, suite à quoi, nous avons décidé de mettre cette partie en attente, car pas strictement indispensable pour un test complet (en effet, nous pourrions d'abord nous servir d'une autre carte Arduino en remplacement).<br/>
+*'''Coté Raspberry (optimisation du script)'''
+Dans cette partie, il s'agissait d'optimiser le code du script python d'envoi des données au serveur afin qu'il puisse identifier automatiquement l'adresse IP de la Raspberry et aussi identifier directement le numéro du capteur concerné (et non pas les renseignées manuellement en DUR comme nous l'avons fait lors de notre test initial).<br/>
+Pour plus de précisions sur le système d'identification du numéro du capteur (voir Equipe 3, Semaine 5 et 6).
+Le script était parfaitement fonctionnel.
+=====Semaine 8 | Confinement=====
+Durant cette semaine, comme l'a expliqué l'Equipe 3, nous avons branché des Raspberry avec quelques capteurs en salle de projet.<br/>
+Nous (Equipe 1 et 3) avons repensé quelques détails de notre circuit de travail de manière à mieux se connecter avec l'Equipe 2 (Ansible), vous pourrez voir l'Equipe 3 (Semaine 5-6) pour des détails sur le système d'identification des capteurs.<br/>
+*'''Raspberry : Création d'un makefile générique'''
+L'idée est d'automatiser l'attribution (upload) d'un code au capteur adéquat. Pour cela nous avons mis en place la base du fichier makefile qui est fonctionnelle.<br/>
+Pour que cette partie soit complète il nous reste à rajouter les directives nécessaires en fonction du numéro du capteur (qui est une variable extérieure au makefile, vu que ce dernier est générique) et lancer l'upload adéquat.<br/>
+Nous avons donc modifié le makefile (disponible sur le Git) afin qu'il lance un ''Upload'' spécifique en fonction du numéro du capteur et de la méthode d'upload (via USB ou via SPI pour des cartes Arduino).<br/>
+Nous avons volontairement omis de gérer la carte Nucléo dans le Makefile pour le moment. Nous allons donc passer en phase de test (avec les autres équipes).
+=====Confinement (Suite)=====
+Durant cette semaine, il a été question de tester les fonctionnalités développées par cette équipe en l'interconnectant avec celles des autres équipes. Nous avons effectué une démonstration en live sur Discord en présence de M. Vantroys. La démonstration a été concluante, et nous avons tenu compte des remarques données afin d'optimiser notre travail.<br/>
+*'''Fixer précisément des capteurs à des Ports USB de la Raspberry'''
+Prenons le scénario suivant : Lorsque nous avons plusieurs périphériques (ici ce sont les capteurs via les microcontrôleurs) connectés aux différents ports USB de notre Raspberry. Supposons qu'il y ait un ''redémarrage'' de la Raspberry ou simplement un ''débranchement'' suivi d'un ''branchement'' de nos périphériques, là, nous ne pourrons pas déterminer quels ports USB (ttyACMX) leurs seront attribués à nouveau.<br/>
+Ainsi, un capteur précédemment branché sur ttyACM0 pourrait se voir attribuer le port ttyACM1 et donc les remontées de données poseraient de sérieux problème à notre système. Nous devions donc trouver un moyen de lier un capteur (plus exactement un microcontrôleur) à un port USB bien déterminé, afin qu'aucun redémarrage ni re-branchement ne puisse lui en attribuer un autre.<br/>
+Pour se faire, voici comment procéder :<br/>
+*''Déterminer les périphériques branchés''
+Le but ici est de déterminer quel périphérique a été lié à quel port USB. La meilleure façon c'est de débrancher les périphériques et de les rebrancher un par un. Dans un cadre de test, nous avons travailler avec l'une des Raspberry branchées en salle projet (172.26.145.113 sur laquelle il est connecté un Arduino avec un capteur).<br/>
+  dmesg | grep ttyACM
+[[Fichier:Dmesg.png|400px|thumb|center|Périphérique connecté]]
+Sur le résultat de cette commande, nous allons noter quelques informations utiles pour la suite. La première chose à noter ce sont les chiffres juste après "cdc_acm" (1-1.5) et la deuxième consiste à retenir le numéro de port attribué (ici ''ttyACM0'').
+Nous devons aussi penser à donner un nom qui nous permettra de reconnaître notre périphérique à chaque fois qu'il sera connecté : ici je lui donnerai le nom "ttyACM_ARDUINO_TEMP" car un capteur de température y est lié.<br/>
+*''Recherche d'attributs''
+Afin de reconnaître plus tard de façon unique notre périphérique, il nous faudra nous servir d'attributs spécifiques permettant d'identifier ce périphérique parmi tant d'autres. Cela peut être l'identifiant du fournisseur ou le numéro de série.<br/>
+  udevadm info --name=/dev/ttyACM0 --attribute-walk
+[[Fichier:Attributes.png|400px|thumb|center|Attributs]]
+Il faut retrouver les chiffres notés précédemment "1-1.5". Nous avons choisi de baser notre identification uniquement sur les attributs Serial, idVendor et idProduct (bien évidemment il est possible d'en rajouter plus). Nous notons les noms et les valeurs des attributs pour les utiliser par la suite.<br/>
+*''Création du fichier de règles de noms de ports''
+Ici nous allons faire la liaison entre le périphérique et le port USB. Pour se faire, il nous faut créer un fichier qui encapsulera les règles nécessaires pour l'attribution d'un port spécifique à notre périphérique en fonction des attributs.
+  sudo nano /etc/udev/rules.d/usb-serial.rules
+[[Fichier:Rules2.png|800px|thumb|center|Fichier de règles]]
+*''Chargement des nouvelles règles''
+Pour rendre effectif les règles
+  sudo udevadm trigger
+*''Vérification des nouveaux noms de ports''
+  ls -l /dev/ttyACM*
+[[Fichier:ArduinoPort.png|400px|thumb|center|Fichier de règles]]
+Ainsi nous pouvons voir le nouveau nom apparaître à la place du nom classiquement attribué "/dev/ttyACMX". Ce nom peut désormais être utiliser dans nos scripts pour désigner ce périphérique, et cela même après un redémarrage. De cette manière la gestion des ports USB peut donc être beaucoup plus stabilisée désormais.
+*''Script generique de fixation des périphériques aux ports''
+Pour terminer, nous avons devéloppé un script générique qui pourra être déployer depuis ansible sur les Raspberry Pi.
+Ainsi, au lieu de le faire manuellement pour chacun des périphériques, il suffira de la lancer depuis ansible pour que le script puisse écrire lui même les fichiers de règles selon le périphérique correspondant.
+Vous pourrez voir le détail du code dans le git (fichier ''port.sh'').
+Récupération du code d'identification du périphérique
+  data=$(dmesg | grep ttyACM | cut -f 7 -d " " | cut -f 1 -d : )
+  code=$(echo $data | cut -f 1 -d " ")
+On détermine quel numéro de port lui attribuer (Ex: capteur1-1 -> port 0)
+  port=$(pwd | cut -c 17)
+  let port--
+  dev="/dev/ttyACM"
+  name="$dev$port"
+Récupération des attributs
+  commande=$(udevadm info --name=$name --attribute-walk | egrep "idVendor|idProduct|serial")
+  idProduct=$(echo $commande | cut -f 1 -d " ")
+  idVendor=$(echo $commande | cut -f 2 -d " ")
+  serial=$(echo $commande | cut -f 3 -d " ")
+Attribution d'un nouveau nom de port (ttyPRX à la place ttyACMX)
+  newdev="ttyPR"
+  newname="$newdev$port"
+Écriture des règles
+  rule="SUBSYSTEM==\"tty\", $serial, $idVendor, $idProduct, SYMLINK+=\"$newname\""
+  echo $rule >> /etc/udev/rules.d/usb-serial.rules
+  udevadm trigger
+Nous avons donc testé notre script depuis Ansible sur une Raspberry Pi à laquelle est fixé un capteur (via une carte Arduino) mais également sur une Raspberry Pi avec deux périphériques (deux capteurs sur deux Arduino). Les tests sont concluants.
+----
+<br/>
+====Equipe 2====
+=====Semaine 1 =====
+Recherches concernant Ansible
+Interet d'utiliser Ansible par rapport à d'autres logiciels : Il fonctionne en python (Chef et Puppet utilisent ruby)
+Si nous voulons utiliser Python 3 (car python 2 n'est plus maintenu depuis le premier janvier) il nous faut Ansible 2.5 ou supérieur.
+On pourrait utiliser "python-virtualenv" pour faciliter la compatibilité de nos scripts entre les versions de nos logiciels ou utiliser docker
+Il n'est pas nécessaire d'installer Ansible sur chaque nœud (dans notre cas les raspberry pi) seulement sur un serveur qui sera notre "node manager" (Ce dernier devant etre un système UNIX).
+Les noeuds devront juste permettre le ssh. Le reste pourra etre installé grace à Ansible.
+le node manager doit pouvoir connaître les adresses IP de ses nodes. (dns ou fichier /ect/hosts)
+Utilisation de clé ssh pour sécuriser la communication (ex : ssh-keygen -t ecdsa)
+----
+<br/>
+=====Semaine 2 =====
+Ce qu'il faut définir pour aller plus loin :
+* Comment récupère-t-on la liste des adresses des nodes à paramétrer
+* Quels sont les logiciels à installer ainsi que les paramétrages à effectuer pour notre application.
+* Ansible doit il également déployer les codes sur les raspberry pi, si c'est le cas, peut il etre appelé automatiquement par le serveur web ?
+Les commandes ansibles pourront être exécutée par script bash (faut-il séparer le setup des cartes et l'update de code ?)
+On peut copier le code sur chaque machine (ou groupe de machine) en utilisant le module "copy" d'ansible.
+Ansible peut également exécuter des scripts shell sur les machines distantes : module "shell".
+Il serait utile d'utiliser le module "docker_container" pour permettre un versioning facile et supprimer les problèmes de compatibilité.
+Ensuite il semblerait qu'Ansible puisse réagir à des événements grâce à l'utilisation de "wait_for". Dans notre cas, cela serait utile pour envoyer les codes au raspberry pi lorsqu'on le souhaite.
+Dans mon idée actuelle :
+* Ansible met en place les raspberry pi pour qu'ils soient pret à exécuter du code
+* Ansible envoi le code sur les raspberry pi (Quand un utilisateur le demande).
+* Les raspberry pi renvoient leurs données directement au serveur principal.
+----
+<br/>
+=====Semaine 3 =====
+Premiers pas avec Ansible :
+*Installation de la dernière version d'Ansible à l'aide de pip :
+ pip3 install ansible
+Il faut donc avoir python 3.5+ installé, possibilité de choisir la version d'ansible (pip3 install ansible==2.9.4)
+On peut vérifier si l'installation est correcte avec la commande :
+ ansible --version
+Pour communiquer avec nos nœuds on va les renseigner dans le fichier '''/etc/hosts'''. Exemple dans notre cas on ajoute les lignes:
+.26.145.112  rasp1
+.26.145.113  rasp2
+Il faut enfin créer un fichier '''inventaire.ini''' pour référencer nos nœuds, il est pour le moment très simple :
+ rasp1
+ rasp2
+''La seule chose qu'il y a à faire sur le raspberry pi est d'activer le ssh, de régler son adresse ip et de lui donner une connexion internet.''
+*Première commande Ansible. Un simple ping permet de voir si on arrive bien a communiquer avec notre nœud :
+ ansible -i inventaire.ini -m ping rasp1 --user pi --ask-pass
+'''-i inventaire.ini''' : chemin vers le fichier d'inventaire
+'''-m ping rasp1''' : action à effectuer sur la cible
+'''--user pi''' : choix de l'utilisateur qui se connecte
+'''--ask-pass''' : demande du mot de passe ssh
+On peut commencer à paramétrer nos nodes. On utilisera pour le moment des lignes de commandes et pas des fichiers playbooks.
+*Installation de python3 :
+ ansible -i inventaire.ini -m raw -a "sudo apt-get install python3 -y" rasp1 --user pi --ask-pass
+*Installation de WiringPi :
+ ansible -i inventaire.ini -m raw -a "sudo apt-get install wiringpi -y" rasp1 --user pi --ask-pass
+'''-m raw''' : pour envoyer une ligne de commande à lancer sur la cible
+'''-y''' dans le apt-get : permet de valider la demande d'utilisation d'espace sur le disque
+'''Autre possibilité pour la connexion :'''
+On utilise sudo car l'utilisateur pi peut avoir les droits administrateur. On pourrait également utiliser cette commande en demandant une élévation de privilèges :
+ ansible -i inventaire.ini -m raw -a "apt-get install python3 -y" rasp2 --user pi --ask-pass --become --ask-become-pass
+On pourrait enfin se connecter directement en utilisateur root, mais cela demanderait plus de préparation sur le raspberry pi :
+ -Editer le fichier: sudo nano /etc/ssh/sshd_config
+ -Trouver la ligne: PermitRootLogin without-password
+ -Editer: PermitRootLogin yes (enlever le # de commentaire)
+ -Fermer et sauvegarde le fichier
+ -restart du service sshd: /etc/init.d/ssh restart
+ -Mettre un mot de passe root: sudo passwd root
+*L'idée maintenant serait de supprimer la demande de mot de passe en utilisant le système des clé de sécurité ssh.
+Pour créer une clé ssh de type rsa 2048 bits :
+ ssh-keygen
+On n'indiquera pas de passphrase pour permettre un reboot automatique du serveur ansible.
+On va ensuite envoyé notre clé publique sur nos noeuds :
+ <nowiki>ansible -i inventaire.ini -m authorized_key -a 'user=pi state=present key="{{ lookup("file", "/home/pifou/.ssh/id_rsa.pub") }}"' --user pi --ask-pass --become --ask-become-pass all</nowiki>
+'''user=pi''' correspond à l'utilisateur auquel on donne notre clé
+'''/home/pifou/.ssh/id_rsa.pub''' correspond au chemin où la clé à été enregistré
+'''all''' que l'on envoie à toutes les nœuds du fichier inventaire.ini
+Maintenant on n'a plus besoin d'utiliser l'option '''--ask-pass'''.
+----
+<br/>
+=====Semaine 4 =====
+Un des buts de cette semaine est de créer le fichier d'inventaires de nos nodes Ansible. Cependant nous voulons le rendre dynamique : le fichier contiendrait uniquement la liste des nodes à mettre à jour.
+Une idée pourrait être que le site web, lors d'une demande de modification des nœuds, envoi le fichier d'inventaire par scp en utilisant par exemple la commande php : "ssh2_scp_send"
+L'idée serait, sur le serveur Ansible, de vérifier si le fichier inventaire.ini à bien été déposé. On utilisera un playbook contenant :
+ ---
+ - name: Wait until the file /home/pifou/inventaire.ini
+   hosts: 127.0.0.1
+   tasks:
+     - wait_for:
+        path: /home/pifou/inventaire.ini
+Ansible va attendre d'avoir le fichier inventaire.ini avant de continuer son exécution.
+On pourra ensuite appeler nos playbook de paramétrage. Exemple avec un simple ping :
+ ---
+ - name: Ping
+   hosts: all
+   remote_user: pi
+   tasks:
+     - ping:
+Pour le lancement du code on pourra utiliser un script bash :
+ #!/bin/bash
+ trap exit SIGINT
+ while [ 1 ]
+ do
+ ansible-playbook playbooktest.yml
+ ansible-playbook taskPing.yml -i inventaire.ini
+ rm inventaire.ini
+ done
+----
+<br/>
+=====Semaine 5 =====
+Cette semaine nous allons essayer d'avancer sur les playbooks pour l’installation de tous les composants sur nos nœuds Ansible.
+On voudrait que le fichier inventaire.ini nous donne les informations sur les choses à installer : cela devrait surtout dépendre de ce qui est connecté à la raspberry pi (Arduino ou autre).
+Dans l'idée le fichier devrait contenir des groupes tel que [arduino] ou [nucleo] et contenant les ip des machines qu'il faut mettre à jour.
+On veut donc que les playbooks s'exécutent suivant le groupe (le type) de machine.
+Résultat :
+Plusieurs rôles ont été créé : arduino_Setup/nucleo_Setup/arduino/nucleo
+Les deux premiers serviront pour préparer les cartes arduino pour pouvoir utiliser des arduino ou des nucleo.
+Les deux suivant sont les rôles de production : ils copieront les fichiers, lanceront la compilation pour les scripts d’exécution.
+Un premier playbook de mise en place pour les arduino à été commencé. Il permet de mettre en place le proxy, installe python3, minicom, wiringpi, avrdude.
+ ---
+ - name: Copy file for proxy setup
+   copy:
+     src: ../files/proxy.conf
+     dest: /etc/apt/apt.conf.d/proxy.conf
+     owner: root
+     group: root
+     mode: '0644'
+ - name: "verif install python3"
+   apt:
+     name: python3
+     state: present
+ - name: "verif install minicom"
+   apt:(sûrement un ou plusieurs codes C)
+     name: minicom
+     state: present
+ - name: "verif install wiringpi"
+   apt:
+     name: wiringpi
+     state: present
+ - name: "verif install avrdude"
+   apt:
+     name: avrdude
+     state: present
+----
+<br/>
+=====Semaine 6 =====
+La totalité des logiciels et packages à installer sur le raspberry pi ont été ajoutés sur le playbook d'installation (un fichier yaml séparé pour mieux se retrouver dans le code ) : python3, pip3, wiringpi,avrdude, lxml pkg, requests pkg, pyserial pkg.
+Il sera très facile d'ajouter un nouveau paquet si nécessaire.
+Pour la partie installation il faut encore transférer les fichiers sur les raspberry pi (makefile ...)
+Le rôle de fonctionnement en "production" à été ajouté. Il aura pour but de transférer le fichier binaire à compiler et de lancer le script bash de fonctionnement. Avec le fonctionnement conditionnel on peut également avoir plusieurs capteurs qui travaillent en même temps.
+Pour l'instant le fichier est récupéré sur le site web. Cela pourrait changer si nécessaire (utilisation de la fonction "copy").
+ ---
+ - name: "envoyer du fichier binaire.c"
+   get_url:
+     url:  http://serveur-etu.polytech-lille.fr/~grouille/PROJET/upload/binaire.c
+     dest: <nowiki>/home/pi/capteur{{capteur}}/binaire.c</nowiki>
+     mode: '0644'
+Enfin le fichier inventaire.ini a prit sa forme "définitive". On retrouvera ainsi les adresses IP des raspberry pi à mettre à jour (setup ou prod) avec l'information du capteur.
+ [Arduino_init]
+.26.145.112 capteur=1
+.26.145.113 capteur=2
+ [Arduino]
+.26.145.112 capteur=1
+Pour l'instant nous n'arrivons pas à utiliser correctement ansible pour le lancement de nos scripts bash. Cela vient du fait qu'ils contiennent des boucles infini et que Ansible attend la fin de l'exécution.
+----
+<br/>
+=====Semaine 7 =====
+Nous arrivons à bien envoyer les fichiers sur les raspberry pi. Pour chaque capteur on va donc créer un dossier qui contiendra tous les fichiers de code et de lancement. Pour le moment on récupère également le fichier zip sur le serveur.
+ - name: "Creation des dossiers pour le capteur"
+   file:
+     path: <nowiki>/home/pi/capteur{{capteur}}</nowiki>
+     state: directory
+ - name: "Download and unzip files"
+   unarchive:
+      src: http://serveur-etu.polytech-lille.fr/~grouille/PROJET/fichiersRPI/fichiersRPI.zip
+      dest: <nowiki>/home/pi/capteur{{capteur}}</nowiki>
+      remote_src: yes
+Nous avons enfin réussi à lancer correctement les fichiers bash avec ansible. Le problème était la boucle infini et également que le processus s’arrêtait lorsque ansible quittait le nœud.
+Du coté ansible l'appel est assez classique :
+ ---
+ - name: Lancer le fichier bash
+   hosts: all
+   remote_user: pi
+   become: yes
+   tasks:
+      - shell: /home/pi/capteur3/lancer.sh
+La modification importante est la création du fichier lancer.sh qui va lui appeler le script en mode nohup ( et kill le processus s'il existait déjà) :
+ #!/bin/sh
+ kill $(cat /var/run/script.pid)
+ base=`dirname $0`
+ nohup $base/script.sh &
+Pour récupérer le pid de script.sh il faut ajouter en haut dans ce script la ligne :
+ echo $$ > /var/run/script.pid
+----
+<br/>
+===== Confinement =====
+Avec l'arrivée du Coronavirus nous avons besoin de migrer notre projet sur un autre serveur. Il est disponible au 172.26.189.200 avec nos fichiers dans  /var/www/html/P10.
+Les fichiers seront mis à jour en utilisant notre repository git.
+*Les différents fichiers envoyé sur les Rpi étaient tout d'abord téléchargé sur le site. Puisque nous travaillons en local ce n'est plus nécessaire, les téléchargements ont été remplacé par de simple copier/coller.
+*Ajout des fichiers et logiciels à installer sur les cartes lors de la première mise en place. (avr-dude/avr-gcc/avr-libc et fichier de config pour les GPIO)
+*Un problème qu'il nous reste à régler est l'automatisation du transfert des clés ssh du serveur vers les cartes raspberry. Actuellement ce processus n'est pas automatique. (''Après discution avec M.Redon et M. Vantroy ce ne serait finalement pas nécessaire de réaliser cette tache.'')
+*Début de la rédaction du rapport et corrections de quelques erreurs présent du côté de Ansible.<br/>
+'''Utilisation de Cron afin d'automatiser le lancement du fichier Rpi_to_server.py'''
+Nous nous sommes intéressés à Cron afin d’améliorer un peu plus notre projet. L’objectif de l’utilisation de Cron est d’automatiser le lancement du fichier Rpi_to_server, initialement lancé grâce à une boucle infinie.
+Tout d’abord, Cron est un programme qui permet aux utilisateurs d'exécuter automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiée à l'avance, ou selon un cycle prédéfini.
+Il a fallu dans un premier temps se renseigner sur l’utilisation de Cron. Dans la table appelée Crontab, chaque ligne correspond à une tâche à exécuter et doit respecter cette notation :
+mm hh jj MMM JJJ tâche
+* mm représente les minutes (de 0 à 59)
+* hh représente l'heure (de 0 à 23)
+* jj représente le numéro du jour du mois (de 1 à 31)
+* MMM représente l'abréviation du nom du mois (jan, feb, ...) ou bien le numéro du mois (de 1 à 12)
+* JJJ représente l'abréviation du nom du jour ou bien le numéro du jour dans la semaine
+Pour chaque valeur numérique (mm, hh, jj, MMM, JJJ) les notations possibles sont :
+* * : à chaque unité (0, 1, 2, 3, 4…)
+* 5,8 : aux unités 5 et 8
+* 2-5 : aux unités de 2 à 5 (2, 3, 4, 5)
+* */3 : toutes les 3 unités (0, 3, 6, 9…)
+* 10-20/3 : toutes les 3 unités, entre la dixième et la vingtième (10, 13, 16, 19)
+Exemple :
+0 13 1 5 tâche
+La tâche sera exécutée le 13 janvier et tous les vendredis.
+Il a fallu tout d’abord tester l’utilisation de la Crontab. Pour cela, nous avons créé un script très simple composé seulement d’un echo afin d’afficher "Bonjour". Puis nous avons modifié la Crontab à l’aide de la commande crontab -e. Nous avons donc ajouté une tâche à celle-ci et nous avons redirigé la sortie du script vers un fichier sauvegarde.txt afin de s’assurer de son bon fonctionnement.
+Tâche ajoutée :
+ * * * * * /home/eymeric/test.sh >> /home/eymeric/sauvegarde.txt
+Une fois les premiers pas sur Crontab effectués, il nous a fallu trouver un moyen de lancer celle-ci sans passer par la commande crontab -e. Nous avons donc utilisé dans un premier temps la commande
+ crontab <<<"* * * * * /home/pi/capteur1-0/python.sh /home/pi/capteur1-0"
+Cette commande se lançant dans un script shell et permettant de mettre à jour la Crontab. Le lancement du fichier Rpi_to_server.py se faisait de manière automatique comme souhaité initialement et le serveur recevait les données du capteur tous les intervalles de temps définis.
+Un seul problème restait en suspens qui était : comment ajouter ou supprimer une ligne de la Crontab lors de l’ajout ou la suppression d’un capteur par le serveur car cette commande supprimait le contenu de la Crontab puis écrivait dans celle-ci.
+Suppression d’une ligne :
+ crontab -l | grep -v $pwd | crontab -
+Ajout d’une ligne :
+ (crontab -l ; echo "*/$tps * * * * $pwd/python.sh $pwd") | crontab -
+Cette nouvelle option de suppression de ligne nous permettant d’ajouter une nouvelle option pour les chercheurs sur le serveur permettant de supprimer un capteur qui avait été lancé préalablement. Cela permet au chercheur d’arrêter le script une fois que celui-ci n’en a plus besoin.
+L’utilisation de la Crontab nous a permis d’automatiser le lancement du fichier Rpi_to_server.py et ainsi de contourner l’ancienne utilisation d’une boucle infinie dans le script shell lancé par Ansible. L’ajout de deux lignes de commandes dans le fichier shell, une permettant la suppression et l’autre permettant l’ajout d’une tâche dans la Crontab, a permis le fonctionnement de plusieurs capteurs en simultané mais aussi la suppression d’un capteur sans impacter le retour des valeurs d’un autre capteur actif.
+----
+<br/>
+====Equipe 3====
+{| class="wikitable"
+! Objectif !! Etat
+|-
+|
+Créer une page web dynamique (rafraîchissement des données).
+|
+<font color='green'>Fait</font>
+|-
+|
+Créer des fichiers "de retour" vides sur le serveur pour chaque capteur.
+|
+<font color='green'>Fait</font>
+|-
+|
+Créer un Makefile pour automatiser l'envoi jusqu'au microcontrôleur.
+|
+<font color='green'>Fait</font>
+|-
+|
+Créer un script permettant la compilation et l'upload des fichiers grâce au Makefile.
+|
+<font color='green'>Fait</font>
+|-
+|
+Permettre l'ajout d'un capteur sur le site.
+|
+<font color='green'>Fait</font>
+|-
+|
+Créer un script PhP permettant d'entrer les données présentes dans les fichiers dans la base de données (lié au dynamisme de la page).
+|
+<font color='blue'>Obsolète</font>
+|-
+|
+Modifier le script shell pour lui permettre d'envoyer les fichiers de données des capteurs en ssh sur le serveur.
+|
+<font color='blue'>Obsolète</font>
+|-
+|
+Mettre sous forme de fichier .ini les données relatives à l'identification des Raspberry Pi et des capteurs sélectionnés sur le site.
+|
+<font color='green'>Fait</font>
+|-
+|
+Faire un requête POST depuis les Raspberry pour envoyer les données sur le serveur.
+|
+<font color='green'>Fait</font>
+|-
+|
+Modifier le site et la base de données pour créer un historique des valeurs des capteurs.
+|
+<font color='green'>Fait</font>
+|-
+|
+Rendre accessibles depuis le site les données historiques des capteurs, et créer un système de filtre.
+|
+<font color='green'>Fait</font>
+|-
+|
+Permettre la sélection de plusieurs capteurs <b>de même type</b> depuis le site.
+|
+<font color='green'>Fait</font>
+|-
+|
+Migrer le site sur le nouveau serveur 172.26.189.200.
+|
+<font color='green'>Fait</font>
+|-
+|
+Lancer Ansible depuis le site.
+|
+<font color='green'>Fait</font>
+|-
+|
+Créer un graphe pour chaque capteur en fonction des X dernières valeurs.
+|
+<font color='green'>Fait</font>
+|-
+|
+Ajouter une page plus "graphique" sur le site permettant l'affichage des différents noeuds de capteurs et de leurs caractéristiques.
+|
+<font color='green'>Fait</font>
+|-
+|
+Permettre l'ajout et la suppression de comptes depuis les comptes administrateurs.
+|
+<font color='green'>Fait</font>
+|-
+|
+Remonter les erreurs aux utilisateurs.
+|
+<font color='green'>Fait</font>
+|-
+|
+Permettre l'arrêt d'un capteur.
+|
+<font color='green'>Fait</font>
+|}
+=====Semaine 1=====
+'''Makefile et script shell'''
+Nous avons créé un Makefile à l'aide du cours de PSR.<br/>
+De ce fait, il nous suffit maintenant de faire un make upload pour envoyer le code sur l'Arduino UNO.<br/>
+Le script load.sh a été légèrement modifié pour que le programme fonctionne correctement (voir le git).
+Maintenant, tout est automatisé de l'envoi du fichier à partir du site web jusqu'à l'exécution du programme sur l'ATMega328p.
+----
+<br/>
+=====Semaine 2=====
+'''Modification du site Web'''
+L'objectif de cette partie est de mettre à jour le site pour qu'il puisse afficher les données reçues par les capteurs.<br/>
+Pour se connecter à la base de données depuis un terminal, il est maintenant nécessaire d'entrer la commande : <b>psql -h serveur-etu.polytech-lille.fr -U grouille projetCapteurs</b> avec le mot de passe <b>postgres</b>.<br/>
+Depuis un navigateur Web : <b>https://pgsql.polytech-lille.fr/</b><br/>
+Dans un premier temps, il faut ajouter une nouvelle table dont le contenu reste à déterminer en fonction de ce que retourne les Raspberry comme données.
+Nous avons décidé de choisir d'utiliser 3 Raspberry Pi, sur lesquelles se trouvent respectivement :
+* Un Arduino UNO avec un capteur de température et un capteur de distance ;
+* Un Arduino UNO avec un capteur de température ;
+* Un Nucléo M4 avec un capteur de distance.
+Pour repérer les capteurs depuis le site, au travers des Raspberry, elles sont maintenant liées à leur adresse IP et chaque capteur a un numéro sur la Raspberry.<br/>
+Il serait intéressant de permettre l'ajout d'une Raspberry depuis le site, en permettant l'ajout de celle-ci dans la liste ainsi que des capteurs qui lui seraient liés.
+'''Envoi des données sur le serveur'''
+La première idée que nous avons eu était de passer par une connexion ssh entre la Raspberry envoyant les données et le serveur.<br/>
+Les données seraient ainsi toujours stockées au même endroit sur le serveur et l'envoi serait conditionné d'une simple connexion internet, de la même manière que pour la réception du code.<br/>
+Il reste à voir avec l'équipe 2 comment Ansible gère le déploiement des codes et le retour de données.<br/>
+La deuxième idée est de créer un script PhP directement sur les Raspberry (déployé par Ansible).<br/>
+Ce script permettrait la connexion au serveur et mettrait automatiquement la base de données à jour.<br/>
+Plusieurs questions se posent alors :
+#Peut-on exécuter un script PhP directement dans le shell ?
+#Peut-on utiliser un code HTML pour l'exécuter dans le cas contraire ?
+#Serait-il plus propre d'envoyer les données au serveur en ssh et de les traiter par un script qui s'y trouve ?
+Le plus intéressant et pratique serait la dernière option. Une connexion ssh entre chaque Raspberry Pi et le serveur s’établirait à chaque fois qu'une valeur de capteur est mise à jour.<br/>
+Ainsi, lorsqu'on se trouve sur la page de site où se trouvent les valeurs affichées, il faudrait trouver un moyen dynamique de rafraîchir les données pour que les dernières arrivées soient prises en compte.
+----
+<br/>
+=====Semaine 3=====
+'''Script d'envoi de données par SSH - Obsolète'''
+Pour envoyer les données par SSH, nous allons utiliser le protocole SCP.<br/>
+Pour se faire, nous devons configurer pour chaque raspberry une connexion SSH via des clés RSA, afin de ne pas devoir entrer manuellement un mot de passe.<br/>
+Nous avons suivi ce tutoriel : https://geekeries.org/2016/10/transferts-scp-sans-mot-de-passe/?cn-reloaded=1&cn-reloaded=1. Il faudra que cette opération soit effectuée sur chaque Raspberry via Ansible.
+Nous allons copier les données vers le serveur. Ces données seront sous forme de fichier XML ayant un nom précis : <b>ip-capteur.xml</b>, de manière à pouvoir avoir plusieurs fichiers de données.<br/>
+Le fichier XML sera de la forme :
+ <?xml version='1.0' encoding='UTF-8'?>
+ <capteur>
+     <parametre name="ip_address">172.26.145.X</parametre>
+     <parametre name="numero">Y</parametre>
+     <parametre name="data">AB.C</parametre>
+     <parametre name="date">Date</parametre>
+ </capteur>
+Les données y seront entrées par un script Python.<br/>
+La commande SCP est la suivante :
+ SCP /home/pi/Desktop/ip-capteur.xml grouille@houplin.studserv.deule.net:/home/peipa1/grouille/public_html/PROJET/data/
+Pour que la copie par SCP fonctionne, il faut retirer tous les 'echo' dans le bashrc sur le serveur.<br/>
+'''Nouvelle manière de mettre à jour la base de données'''
+Il nous a été proposé d'utiliser une requête POST pour mettre à jour la base de données, à la place du système décrit précédemment.<br/>
+Nous avons donc modifié le script Python de l'équipe 1 pour y intégrer cette requête :
+ params = {"ip_address":"172.26.145.111", "numero":"2", "data": data, "date": Date}
+ r = requests.post("http://serveur-etu.polytech-lille.fr/~grouille/PROJET/requests.php", data = params)
+Cette requête permet l'envoi des données sur le serveur. Un script PhP (requests.php) récupère les données et utilise la fonction update_bdd(), qui met à jour la base de données.<br/>
+De cette manière, chaque Raspberry est indépendante et peut envoyer des données lorsqu'elle le souhaite.<br/>
+Les requêtes SQL d'update s'exécuteront tour à tour grâce au système de verrous.
+----
+<br/>
+=====Semaine 4=====
+'''Script PhP/SQL permettant la mise à jour de la base de données'''
+Pour permettre la modification de la base de données et l'affichage de celle-ci sur le site, il nous faut 2 fichiers PhP supplémentaires et une fonction.<br/>
+Le premier (data.php) sert "seulement" à vérifier que l'utilisateur est bien connecté au site, et à importer le fichier PhP contenant les fonctions utiles.<br/>
+Il permet également le rafraîchissement de la page toutes les 10 secondes (balise meta).<br/>
+Le second fichier (values.php) contient deux choses :
+* Un tableau fabriqué à partir de requêtes SQL permettant l'affichage des données ;
+* L'appel à la fonction de mise à jour update_bdd().
+'''Nouvelle manière de mettre à jour la base de données'''
+Il nous a été proposé d'utiliser une requête POST pour mettre à jour la base de données, à la place du système décrit précédemment.<br/>
+Nous avons donc modifié le script Python de l'équipe 1 pour y intégrer cette requête :
+ params = {"ip_address":"172.26.145.111", "numero":"2", "name":"Solaris", "data": data}
+ r = requests.post(<nowiki>"http://serveur-etu.polytech-lille.fr/~grouille/PROJET/requests.php"</nowiki>, data = params)
+Cette requête permet l'envoi des données sur le serveur. Un script PhP (requests.php) récupère les données et utilise la fonction update_bdd(), qui met à jour la base de données de la même manière que update_values().<br/>
+De cette manière, chaque Raspberry est indépendante et peut envoyer des données lorsqu'elle le souhaite.<br/>
+Les requêtes SQL d'update s'executeront tour à tour grâce au système de verrous.
+----
+<br/>
+=====Semaine 5=====
+'''Historique des capteurs'''
+[[Fichier:history.png|200px|thumb|right|Table history]]
+Nous avons créé un système d'historique qui enregistre la date et l'heure de chaque relevé dans une nouvelle table.<br/>
+Nous allons créer un système de recherche et rendre accessible ces données à partir du site.
+En arrivant sur la page de recherche, plusieurs possibilités :
+* Sélectionner un capteur spécifique ;<br/>
+* Sélectionner un type de capteur ;<br/>
+* Sélectionner une adresse IP ;<br/>
+* Sélectionner un intervalle de dates ;<br/>
+* Sélectionne un nombre maximum de résultats.<br/>
+Il est possible de combiner tous ces critères pour affiner les recherches.<br/>
+On obtient un tableau contenant les informations utiles des capteurs.
+'''Ajout d'un capteur depuis le site'''
+Nous avons créé une page permettant d'ajouter un capteur à la liste des présents.<br/>
+La requête est fonctionnelle et gère les doublons dans la table.<br/>
+Il reste à utiliser Ansible dans cette partie pour ajouter les fichiers de base sur une Raspberry si elle n'existait pas avant.
+----
+<br/>
+=====Semaine 6=====
+'''Migration sur un autre serveur'''
+Lien du site : http://projet-p10.plil.fr/IMA3_P10/site<br/>
+Fichiers raspberry : http://projet-p10.plil.fr/IMA3_P10/site/fichiersRPI
+Pour continuer d'utiliser la base de données liée à notre projet, nous avons choisi d'installer PostgreSQL sur le nouveau serveur et d'y recopier l'ancienne base de données.<br/>
+Elle est maintenant accessible depuis le serveur 172.26.189.200 avec la commande : <b>psql -h localhost -U grouille projetCapteurs</b> et le mot de passe <b>postgres</b>.
+Par ailleurs, nous avons ajouté dans la table capteurs le numéro de version du capteur (en lien avec la connectique utilisée) :<br/>
+* 0 : le capteur est branché en USB sur un Arduino UNO ; <br/>
+* 1 : le capteur est branché en SPI sur un Arduino UNO ; <br/>
+* 2 : le capteur est branché en USB sur une Nucléo M4 (optionnel pour le moment).
+'''Création du fichier .ini à partir du serveur'''
+Pour l'utilisation d'Ansible, il nous faut créer un fichier inventaire.ini lorsque l'on crée un nouveau capteur et lorsque l'on veut envoyer du code sur un ensemble de capteurs.<br/>
+Pour cela, on a défini des balises :<br/>
+* [Arduino], [Arduino_spi] et [Nucleo] pour l'envoi de code ; <br/>
+* [Arduino_init], [Arduino_spi_init] et [Nucleo_init] pour la création de capteurs.
+Nous avons différencié 3 versions de capteurs selon la carte sur laquelle ils sont branchés et selon la connectique utilisée entre la carte et la raspberry. Ces versions sont stockées dans la base de données sous forme numérique (0, 1 ou 2) et vont permettre le choix du bon mode de transfert du code sur les cartes (choix du bon Makefile ou choix de version dans un même Makefile, à déterminer par l'équipe 1).
+De plus, nous considérons qu'au premier ajout de capteur sur une raspberry, il faudra faire des installations sur celle-ci (appelées "setup" par l'équipe 2). De ce fait, si le setup a déjà été effectué sur une raspberry, la variable setup sera égale à 0. Elle vaudra 1 dans le cas contraire et permettra le setup.
+Admettons que l'on veuille envoyer un code sur le capteur 2 connecté en SPI à la raspberry d'adresse 172.26.145.111.<br/>
+Le fichier inventaire.ini ressemblerait à ça :
+ [Arduino_spi]
+.26.145.111 capteur=2-1 setup=0
+De cette manière, on pourra récupérer facilement le numéro du capteur et sa version sur la raspberry pour le traitement des données.<br/>
+On saura également si la Raspberry sur laquelle est le capteur est déjà prête à recevoir les codes.
+----
+<br/>
+=====Confinement=====
+Durant ces semaines de confinement, nous voulions continuer de travailler sur le projet.<br/>
+Nous avons connecté 2 raspberry (172.26.145.111 et 172.26.145.113) sur le réseau de l'école avec les capteurs qui leur sont liés.<br/>
+De plus, nous avons mis en place un dépôt git sur le serveur qui nous permet de travailler chez nous et de mettre à jour nos données avec un simple <b>git pull</b>.<br/>
+'''Lancement d'Ansible depuis le site'''
+La commande à lancer est du type :<br/>
+''ansible-playbook /path/to/the/file/MainTask.yml -i /path/to/the/file/inventaire.ini''
+La fonction PhP <b>exec(String $cmd)</b> devrait nous permettre de la lancer depuis le site aux endroits appropriés :<br/>
+* A la création d'un nouveau capteur ;<br/>
+* A l'envoi d'un code sur un ensemble de capteurs.
+Pour que le serveur puisse lancer Ansible, et pour qu'Ansible ait accès à la clé ssh de root, nous allons utiliser la commande <b>super</b>.<br/>
+L'équipe 2 a créé un script bash dans lequel se trouve la commande : <b>ansible-playbook ../Ansible/MainTask.yml -i upload/inventaire.ini</b>.
+Nous devons lancer ce script en tant que root. Pour cela, après avoir installé super, nous avons configurer le fichier /etc/super.tab pour qu'il permette à l'utilisateur www-data de lancer le script en tant que root.<br/>
+Pour se faire, nous avons ajouté cette ligne à la fin du fichier :
+ cmd.sh /var/www/html/P10/IMA3_P10/site/cmd.sh www-data uid=root .*
+De ce fait, au niveau du site, une seule ligne a été ajoutée : exec("super cmd.sh");
+Nous pouvons maintenant lancer Ansible depuis le site, au moment de la création d'un capteur et au moment de l'upload d'un fichier.
+'''Prise en compte des remarques'''
+Le compte d'identifiant <b>admin</b> et de mot de passe <b>admin</b> a été supprimé.<br/>
+Il n'est plus possible de s'inscrire seul sur le site.
+'''Mise en place des graphes'''
+Notre équipe a travaillé sur la mise en place de graphes modélisant l'historique de données des capteurs.<br/>
+Nous avons choisi de proposer un formulaire permettant de saisir :
+* Le capteur souhaité ;
+* Un intervalle de dates si besoin ;
+* Un nombre de valeurs à afficher.
+Les valeurs affichées sont les valeurs les plus récentes. Si l'utilisateur veut afficher 100 valeurs entre 2 dates et qu'entre ces dates, il y a 150 valeurs, ce sont les 100 dernières qui seront affichées.<br/>
+Le graphe étant statique, si un grand nombre de points est affiché (>100), nous aurons probablement des chevauchements dans l'affichage. Nous avons tout de même choisi de ne pas limiter le nombre de valeurs pour afficher une tendance.<br/>
+Cependant, au dessus de 25 points, les valeurs n’apparaîtront pas sur chaque point mais il faudra les lire sur l'axe des ordonnées.<br/>
+De la même manière, si le nombre de valeurs pour ce capteur dans l'historique est nul, le graphe ne sera pas affiché et vous serez redirigés sur le formulaire.
+Pour la réalisation des graphes, nous avons choisi d'utiliser la librairie PHP JpGraphe dédiée à la représentation graphique. JpGraphe fournit des images qu'il reste à inclure dans le code HTML ou PHP. La construction de cette image se fait à partir d'un code PHP. Dans notre cas, nous devons renseigner les paramètres du formulaire dans ce code pour qu'il les prenne en compte. Pour se faire, on récupère les données du formulaire POST sur une nouvelle page (graphique.php). Cette page envoie par REQUEST les données à la page graphe.php qui retourne une image à l'aide d'un code que nous avons écrit à l'aide des fonctions de la librairie.
+'''Création et suppression de comptes depuis les comptes administrateurs'''
+Nous avons commencé par créer une table <b>groupes</b> dans laquelle on trouve le noms des groupes (Administrateur et Membre) et un id qui leur est relatif. La table membres a été modifiée pour ajouter à chaque membre un groupe.<br/>
+Nous avons créé une fonction permettant de savoir à quel groupe un membre appartient. De ce fait, on pourra permettre à un utilisateur d'accéder ou non à certaines pages du site.
+Ensuite, nous avons créé un ensemble de pages contenant des formulaires pour permettre aux comptes administrateurs d'ajouter et de supprimer des comptes.
+'''Remonter les erreurs aux utilisateurs'''
+Les erreurs lors de la connexion, de la création ou de la suppression d'un compte sont maintenant remontées à l'utilisateur.
+'''Page permettant la visualisation du réseau complet'''
+Nous avons commencé une page permettant une visualisation graphique mais le rendu n'est pas terrible.<br/>
+Nous allons sûrement nous rabattre sur une page un peu moins "graphique" mais plus lisible.
+La page d'accueil où se trouvait un simple logo a été remplacée par la page de visualisation du réseau.
+'''Suppression de Raspberry et de capteurs'''
+De la même manière que pour les comptes, nous voulions que les utilisateurs puissent ajouter et supprimer des Raspberry et des capteurs.<br/>
+Nous avons donc ajouter cette possibilité.
+'''Protocole d'ajout manuel d'un Raspberry Pi'''
+Lors de l'ajout d'un Raspberry Pi depuis le site, l'utilisateur dispose maintenant du protocole pour l'ajouter manuellement au réseau, avec les différentes commandes utiles.
+'''Lancement d'Ansible'''
+Pour permettre l'arrêt d'un capteur, l'envoi du temps de boucle de la règle Cron associée à un capteur ou encore la suppression du dossier d'un capteur, nous avons modifié le code PHP pour lancer Ansible avec les fichiers inventaire.ini correspondant.
+Par ailleurs, nous avons modifié la page values.php pour y intégrer un formulaire d'arrêt des capteurs.
+'''Récupération du résultat d'exécution d'Ansible'''
+Pour permettre un maximum de débug et davantage de fiabilité lors de l'envoi des codes, nous avons voulu remonter les erreurs d'Ansible.<br/>
+Pour se faire, nous avons tout simplement utilisé la fonction exec() dans sa globalité en lui donnant 2 autres paramètres :
+*Un tableau dans lequel sera stocké les valeurs de retours ;
+*Un entier qui contiendra le statut de l'exécution (égal à 0 si l'exécution se passe correctement).
+----
+<br/>
+====Avancement du projet pendant le confinement====
+Le détail de l'avancement de chaque équipe est disponible dans la section 4.3.4.
+=====Confinement - Semaine 1=====
+Nous avons pris la liberté de brancher au réseau de l'école 2 Raspberry et les capteurs qui vont avec. Nous avons emprunté dans une boîte des tutorat Système un Arduino UNO car nous n'en avions pas assez pour en avoir chez nous dans le cas d'une coupure à Polytech. <br/>
+Nous avons également tout le matériel nécessaire chez nous et accès au serveur depuis chez nous.<br/>
+Nous considérons que nos raspberry ont une pré-configuration avant leur installation (faite par nos soins).<br/>
+Elle inclut la modification du DNS et de l'adresse IP de la raspberry pour être accessible depuis le site et Ansible.
+*Equipe 1 : Raspberry, Arduino, Capteurs
+**Les Raspberry communiquent parfaitement avec le site par wget et requete POST ;
+**Les codes sont modifiés et prêts (code température et code distance) ;
+**Un Makefile générique est en cours de finition ;
+**Le Makefile choisira d'abord quel commande d'upload il va effectuer (en fonction du numéro de version) puis spécifiera le port dans la commande avrdude ;
+**La carte Nucléo M4 est en suspend tant que le reste n'est pas fonctionnel.
+*Equipe 2 : Ansible
+**Gestion au niveau des Arduino (Nucléo laissée de côté) ;
+**L'installation des logiciels et bibliothèques nécessaire au fonctionnement des codes est ok ;
+**La transmission des fichiers et le lancement du script fonctionne ;
+**Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
+**Il faudrait récupérer le code envoyé depuis le site sans le télécharger (car Ansible est aussi sur le serveur).
+*Equipe 3 : Site Web
+**Site 95% terminé par rapport à ce qui a été demandé ;
+**Reste le lancement des scripts Ansible depuis le site.
+*Remarques sur chat.plil.fr
+**Mot de passe admin par défaut pour le site internet. Favoriser le mot de passe root habituel à la place ou un mot de passe plus compliqué afin de limiter les risques.<br/>
+**Ajouter la possibilité sur le site de visualiser pour chaque capteur, un graphe de l'évolution temporelle des valeurs renvoyées.
+=====Confinement - Semaine 2=====
+*Equipe 1 : Raspberry, Arduino, Capteurs
+**Les Raspberry communiquent parfaitement avec le site via des requêtes POST ;
+**Les codes sont modifiés et prêts (code température et code distance) ;
+**Un Makefile générique est opérationnel (mais ne gère pas encore la Nucléo) ;
+**La carte Nucléo M4 est en suspend tant que le reste n'est pas fonctionnel ;
+**Il faut utiliser Cron pour lancer le processus d'envoi des données des capteurs de températures toutes les 5 minutes et toutes les 5 secondes pour les capteurs de distance ;
+**Éviter l'attente active des capteurs (boucle infinie) ;
+**Début du rapport final.
+*Equipe 2 : Ansible
+**Ansible est opérationnel pour gérer les Arduino ;
+**L'installation des logiciels et bibliothèques nécessaires au fonctionnement des codes est fonctionnelle ;
+**La transmission des fichiers et le lancement du script fonctionne ;
+**Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
+**Il faut récupérer le code envoyé depuis le site sans le télécharger (car Ansible est aussi sur le serveur) ;
+**Début du rapport final.
+*Equipe 3 : Site Web
+**Site 98% terminé par rapport à ce qui a été demandé ;
+**Il faut ajouter une page permettant la visualisation graphique de l'ensemble du réseau.
+*Remarques sur chat.plil.fr
+**Ajouter une page permettant la visualisation graphique de l'ensemble du réseau de capteurs ;
+**Correction de la syntaxe wiki ;
+**Début du rapport final.
+=====Confinement - Semaine 3=====
+*Equipe 1 : Raspberry, Arduino, Capteurs
+**Il faut utiliser Cron pour lancer le processus d'envoi des données des capteurs de températures toutes les 5 minutes et toutes les 5 secondes pour les capteurs de distance ;
+**Éviter l'attente active des capteurs (boucle infinie) ;
+**Faire correspondre un capteur à un port USB physique de chaque raspberry ;
+**Début du rapport final.
+*Equipe 2 : Ansible
+**Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
+**Les fichiers envoyés depuis le site sont récupérés directement par Ansible via leur chemin ;
+**Début du rapport final.
+*Equipe 3 : Site Web
+**Il faut ajouter une page permettant la visualisation graphique de l'ensemble du réseau ;
+**Il faut remonter les erreurs à l'utilisateur ;
+**Il faut permettre aux administrateurs de créer et supprimer des comptes.
+*Remarques sur chat.plil.fr
+**Démonstration ok.
+=====Confinement - Semaine 4 à 6=====
+*Equipe 1 : Raspberry, Arduino, Capteurs
+**Un capteur correspond à un port USB unique du Raspberry Pi ;
+**Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
+**Diaporama de soutenance en cours ;
+**Partie du rapport final terminée.
+*Equipe 2 : Ansible
+**Cron est fonctionnel ;
+**Envoi du fichier temps.txt à la création d'un capteur ;
+**Le script script.sh lance maintenant Cron ;
+**Suppression du dossier des capteurs via Ansible ;
+**Lancement du script d'arrêt de Cron via Ansible ;
+**Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
+**Diaporama de soutenance en cours ;
+**Rapport final en cours.
+*Equipe 3 : Site Web
+**L'ensemble du réseau de capteurs est visualisable sur la page d'accueil;
+**Les erreurs sont remontées à l'utilisateur ;
+**Les administrateurs peuvent créer et supprimer des comptes ;
+**Un utilisateur peut arrêter un capteur ;
+**La suppression d'un capteur entraîne la suppression du dossier sur le Raspberry Pi via Ansible ;
+**Les résultats d'exécution d'Ansible sont remontés à l'utilisateur ;
+**Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
+**Partie du diaporama de soutenance terminée ;
+**Partie du rapport final terminée.
+*Remarques sur discussion
+**Corriger les coquilles.
+=====Confinement - Semaine 7=====
+*Equipe 1 : Raspberry, Arduino, Capteurs
+**Diaporama de soutenance terminé ;
+**Partie du rapport final terminée.
+*Equipe 2 : Ansible
+**Diaporama de soutenance en cours ;
+**Rapport final en cours.
+*Equipe 3 : Site Web
+**Partie du diaporama de soutenance terminée ;
+**Partie du rapport final terminée.
+=====Confinement - Semaine 8=====
+Projet terminé.
+----
+<br/>
 ===Documents Rendus===
+*Gitlab : [https://archives.plil.fr/grouille/IMA3_P10 Git P10]
+*Site web  : [http://projet-p10.plil.fr/IMA3_P10/site/index.html Site]
+*Rapport : [[media: Rapport_final_P10_2019_2020.pdf]]
+*Diaporama : [[media: Diapo_final_P10_2019_2020.pdf]]

IMA3/IMA4 2018/2020 P10 : Différence entre versions

Version actuelle datée du 3 mai 2020 à 18:35

Sommaire

Présentation générale

Description

Objectifs

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent

Analyse du second concurrent

Scénario d'usage du produit ou du concept envisagé

Bibliographie et webographie

S6

S7

S8

Préparation du projet

Cahier des charges du groupe

Cahier des charges des équipes

Equipe 1 : Ziyad HOUSSAINI (S6), Loris AHOUASSOU (S8)

Equipe 2 : Eymeric CAPRONNIER, Loris AHOUASSOU (S7), Guillaume ROUILLÉ (S7), Thomas MERTZ (S8)

Equipe 3 : Guillaume ROUILLÉ

Choix techniques : matériel et logiciel

Equipe 1

Equipe 2

Equipe 3

Liste des tâches à effectuer

Equipe 1

Equipe 2

Equipe 3

Calendrier prévisionnel

Equipe 1

Equipe 2

Equipe 3

Réalisation du Projet

Projet S6

Semaine 4 - 05/03

Semaine 5 - 19/03

Semaine 6 - 02/04

Semaine 7 - 16/04

Semaine 8 - 30/04

Semaine 9 - 14/05

Semaine 10 - 28/05

Semaine 11 - 04/06

Documents Rendus

Projet S7

Objectifs

Réalisation

Documents Rendus

Projet S8

Objectifs

Réalisation

Equipe 1

Semaine 1

Semaine 2

Semaine 3

Semaine 4

Semaine 5

Semaine 6

Semaine 7

Semaine 8 | Confinement

Confinement (Suite)

Equipe 2

Semaine 1

Semaine 2

Semaine 3

Semaine 4

Semaine 5

Semaine 6

Semaine 7

Confinement

Equipe 3

Semaine 1

Semaine 2

Semaine 3

Semaine 4

Semaine 5

Semaine 6

Confinement

Avancement du projet pendant le confinement

Confinement - Semaine 1