Version du 5 mai 2022 à 21:48 (voir la source) Fvallee (discussion | contributions) (→‎Partie S8 :) ← Modification précédente		Version actuelle datée du 6 mai 2022 à 01:47 (voir la source) Fvallee (discussion | contributions) (→‎Installation et configuration d’un network/application server en local : ChirpStack)
(33 révisions intermédiaires par le même utilisateur non affichées)
Ligne 111 :		Ligne 111 :
	*une carte STM32 Nucleo-F746ZG couplée à une Gateway Expansion Board Lora (une balise Lora)		*une carte STM32 Nucleo-F746ZG couplée à une Gateway Expansion Board Lora (une balise Lora)
−	[[Fichier:pack.jpg]]	+	[[Fichier:pack.PNG]]
	==Calendrier prévisionnel==		==Calendrier prévisionnel==
		+
		+	=== Projet S8===
		+
		+	[[Fichier:Ganttcapteur.PNG|1200px]]
	=Réalisation du Projet=		=Réalisation du Projet=
−	=Documents Rendus=	+
		+	== Projet S7==
		+
		+	===Récupération et transmission des données des capteurs===
		+
		+	Nous nous sommes d’abord penché sur une transmission des données via Lora entre deux cartes, et non à la balise LoRa de Polytech.
		+	L’objectif de notre travail était que le capteur DHT11 recueille les valeurs de température et d’humidité, les fournisse à la carte émettrice, qui transmettra les données via LoRa.
		+	La carte réceptrice recevrait les données, et les transmettrait via la liaison série au PC, grâce au câble d’alimentation USB.
		+	Le code implémenté sur les cartes a été développé sur l’IDE STM32Cube.
		+
		+	Le véritable enjeu de ce semestre était la familiarisation avec l’environnement de développement et les cartes.
		+	Pour cela, nous nous sommes concentrés sur la compréhension d’un exemple de code existant  de "Ping Pong" entre deux cartes via LoRa utilisant un HAL (hardware abstraction layer).
		+
		+	Nous avons modifié le code afin de pouvoir envoyer une trame personnalisée, puis nous avons réalisé une partie pour la carte émettrice,
		+	et une partie pour la carte réceptrice, qui envoie ensuite la trame sur la liaison série.
		+	Il a donc fallu définir un format de données avant la transmission.
		+	Pour cela, nous avons choisi d’utiliser le format suivant, stockée dans une chaîne de caractères:
		+	line = {T:xx.x,H:xx.x} sizeof(line) = 15 octets
		+
		+	Cette trame ne contenait pour le moment que des données statiques définies préalablement.
		+	Nous avons donc ensuite commencé à nous occuper de l’implémentation d’un code permettant la lecture du capteur DHT11.
		+	Pour cela, nous avons utilisé la bibliothèque STM32 dédiée (un autre HAL). Un problème de taille s’est mesuré à nous :
		+	faire en sorte qu’il n’y ait pas de conflit entre les configuration du capteur, du shield LoRa, et de la liaison série.
		+	Même s’il n’utilise électriquement pas tous les PINS du micro-contrôleur, le shield Lora occupe physiquement toutes les broches de la carte.
		+	Nous avons donc commencé par récupérer les données du capteur sans le Shield et les transmettre en série.
		+	Cela a fonctionné mais nous avons rencontré 2 problèmes :
		+	-les données capteurs (T° et Humidité) ne présentaient aucune précision au-delà de la partie entière (précision au dixième selon le constructeur)
		+	-impossible de récupérer les données sur une autre broche analogique autre que A1, malgré les modifications en conséquence du code (définition d’un autre PIN pour la variable DHT_PIN)
		+
		+	Après étude du schematic du Shield Mbed, nous avons remarqué que le shield proposait l’accès à deux broches analogiques de la carte A4 et A5.
		+
		+	[[Fichier:Shieldlora.png|center]]
		+
		+	Nous n’avons pas réussi à associer l’utilisation du LoRa et l’utilisation du capteur: avec une recherche très approfondie, nous avons pu localiser le problème ;
		+	lors de l’initialisation des ports du capteur, un des pins de celui-ci est censé changer d’état seul.
		+	Cela fonctionne lorsque le capteur est relié à la broche analogique A1 de la carte, mais pas sur les autres broches,
		+	que ce soit en câblant le capteur directement sur la carte ou par l’intermédiaire des deux PINS disponibles sur le Shield.
		+	Nous en avons alors déduit que les autres broches devaient êtres initialisées par le HAL Lora, et donc utilisées d’une manière ou d’une autre par le shield.
		+	Nous avons en  effet pu déterminer que certaines broches étaient utilisées pour la transmission radio ou autre, mais pas les broches A4 et A5 de la carte.
		+	Pourtant, nous n’avons pas réussi à faire fonctionner le capteur sur ces broches.
		+	Il est primordial que le capteur fonctionne sur une de ces broches puisque ce sont les seules redirigées par le shield LoRa pour l’utilisateur, et donc les seules utilisables par le capteur lorsque nous voulons utiliser le shield LoRa et le capteur en même temps.
		+
		+	===Transmission Lora===
		+
		+	Nous avons le montage suivant :
		+
		+
		+
		+	[[Fichier:Montagecapteur.png|500px|center]]
		+
		+
		+
		+	Pour permettre l'échange de données, nous avons du modifier le code existant du Ping-Pong en profondeur.
		+	Ci-dessous un exemple d’échange de trame entre deux cartes :
		+
		+
		+
		+	[[Fichier:Envoietrame.png|500px|center]]
		+
		+
		+
		+	Code permettant de transmettre des données en LoRa. La trame est préfaite ici pour réaliser des tests.
		+
		+
		+
		+	[[Fichier:Txlora.PNG|500px|center]]
		+
		+
		+
		+	===Récupération des données du capteur===
		+
		+	Voici le format des données reçues par la liaison série de l'ordinateur :
		+
		+
		+
		+	[[Fichier:Seriecapteur.PNG|500px|center]]
		+
		+
		+
		+	Un script Python a été choisi. Ce code est composé d’une partie qui sert à recevoir les données grâce à la bibliothèque serial.
		+	Les données reçues du port série sont ensuite stockées dans une base de données MySQL comme indiqué dans les solutions retenues, afin de rendre notre application plus  performante.
		+	Pour faire cela on importe la bibliothèque MySQLdb , après on se connecte d’abord à notre base de donnée en cas d’erreur il affiche qu’on a pas réussi à se connecter à la base de donnée. Ensuite le script va nous permettre de stocker chaque donnée reçue dans la base de donnée MySQL , et en cas d’erreur il affiche qu’il n’a pas pu stocker la donnée.
		+	On récupère également dans le script python la date et l’heure sous le format :
		+	date = ‘20xx-xx-xx’        time = ‘xx:xx’
		+
		+	===Affichage des données===
		+
		+	Pour afficher les données du capteur, un script PHP est utilisé. Voici le résultat :
		+
		+	[[Fichier:php.PNG|700px|center]]
		+
		+	==Projet S8==
		+
		+	Le schéma de principe permettant de résumer l’ensemble du projet réalisé au S8 est le suivant :
		+
		+
		+
		+	[[Fichier:Schemas8.PNG|700px|center]]
		+
		+
		+
		+	===Prise en main du Package STM32===
		+
		+	Dans un premier temps, il nous a fallu prendre en compte le package ST importé et tenté de comprendre le fonctionnement général des différentes sources et headers.
		+	En effet, en important ce package, nous avons récupéré un exemple de code permettant l’envoi classique des données du capteur à intervalle régulier, mais nous nous sommes très rapidement rendu compte que ce programme était dépendant de plusieurs dizaines d’autres fichiers pratiquement tous utiles.
		+
		+	Pour savoir dans un premier temps si les données des capteurs étaient bien récupérées et pour connaître le format de la trame envoyée, nous avons ensuite tenté d’afficher dans un terminal (à travers le port série) les données transmises au module Lora.
		+	Nous nous sommes très rapidement rendu compte qu’il allait être très difficile de réussir à faire cela (malgré de nombreuses tentatives et questions auprès de notre tuteur) étant donné que par exemple l’initialisation des USART se fait à travers de nombreuses fonctions très bas niveau imbriquées à travers des dizaines de fichiers.
		+	Même chose pour les données, qui sont récupérées de manière très complexe (fonctions bas niveau au niveau des registres) puis chiffrées quand accessibles plus facilement.
		+	Chercher à réussir à implémenter une fonction affichant les données des capteurs via la liaison série dans cet environnement à ce moment-là de la chaîne d’information s’est donc avéré inutile étant donné le temps que nous aurions perdu pour la mettre en œuvre.
		+
		+	Néanmoins, nous avons tout de même été en capacité de comprendre certaines fonctions du code et de modifier certaines constantes nécessaires à l’adaptation du code à notre projet. Par exemple, le package a été initialisé pour une utilisation en Chine et les bandes de fréquences utilisées par défaut n’étaient donc pas cohérentes avec les bandes de fréquences autorisées en Europe pour les communications Lora.
		+
		+	===Configuration de la Gateway===
		+
		+	Serveur DHCP
		+	Normalement, la balise devrait être connectée via un câble RJ45 à un routeur doté d’un service DHCP, et connecté à Internet. En effet, de nombreux Network Server sont disponibles au grand public et accessibles depuis Internet (The Things Network est un des plus connus par exemple). La balise devant communiquer avec ce serveur externe à son réseau local filaire, il lui faut donc une adresse IP valide sur son réseau pour qu’elle puisse recevoir des réponses du Network Server. D'où l'intérêt du routeur permettant de faire le lien entre le réseau LAN local de la balise Lora et Internet. Ne pouvant pas disposer de cet équipement réseau facilement lors de nos séances de TP, c’est une de nos machines personnelles qui a dû servir de routeur, sur laquelle nous avons donc dû configurer serveur DHCP.
		+	Pour cela, après avoir installer le paquet dhcp3-server, il est nécessaire de configurer 2 fichiers de configurations :
		+	*/etc/default/isc-dhcp-server : on indique l’interface réseau sur laquelle on veut que le serveur dhcp soit actif. Dans notre cas c’est l’interface ethernet eno1.
		+	*/etc/dhcp/dhcpd.conf : on renseigne toutes les informations relatives au réseau dans lequel les IP seront attribuées (masque, DNS …). Notre configuration est la suivante :
		+
		+
		+	[[Fichier:Dhcp_capteur.PNG|300px|center]]
		+
		+
		+
		+	Pour pouvoir être en même temps connecté à internet, le PC utilise donc finalement la configuration réseau suivante : la balise est connectée sur l’interface Ethernet du PC, qui lui attribue donc une adresse IP sur le sous-réseau 192.168.0.0 dans la plage 192.168.0.20 - 192.168.0.30 (le PC a lui l’adresse routeur sur ce réseau soit 192.168.0.1) et le PC est en même temps connecté à Internet via l’interface Wifi sur le réseau 192.168.1.0.
		+
		+
		+	Sur cette capture, on peut voir la configuration effectuée sur la balise.
		+	On y trouve des informations comme :
		+	*l'ID de la Gateway
		+	*L'adresse IP du serveur LoRaWan
		+	*La bande passante
		+	*Les ports UDP utilisés
		+	*Le fait que l'objet réponde lorsque l'on fait une commande AT
		+
		+
		+	[[Fichier:Gateaway.PNG|700px|center]]
		+
		+
		+
		+	On peut voir que la gateway est bien connectée en éthernet, que les ports UDP sont utilisables, puis un envoi de données.
		+
		+	Sur la capture suivante, on peut voir que les tests ont été concluants : le serveur DHCP a bien sur donner une adresse à la gateaway, puis a transmit les informations à "localhost", c'est à dire l'adresse IP 127.0.0.1, là ou est censé être le Network Server que nous avons configuré.
		+	De plus, on peut voir que les données envoyées sont bien celles reçues par la balise, la réception des données puis le routage ont bien fonctionné.
		+
		+
		+
		+	[[Fichier:Wireshark_capteurs.PNG|400px|center]]
		+
		+	===Configuration Network Server Loriot===
		+
		+	Notre premier choix était d’utiliser le Network Server Loriot, serveur qui prend en charge les balises de notre pack. Nous avons donc choisi un des serveurs en Europe (EU3) , et avons changé l’adresse du Network Server configuré sur la balise en conséquence (eu3.loriot.io).
		+	Nous avons ensuite enregistré notre balise en précisant son adresse MAC, puis le end device en renseignant le DevEUI, l’AppEUI et l’AppKey nécessaire. L’AppKey est ce qui permet à l’Application Server de déchiffrer les données reçues par le Network Server.
		+	Nous avons aussi configuré CayenneMyDevices, une API qui permet de visualiser les données différemment que sur Loriot.
		+
		+	Malheureusement, après plusieurs séances de tests et de tentatives de debug par de nombreuses modifications des diverses configurations, nous n’avons jamais réussi à récupérer et afficher les données sur le site de Loriot, bien que les configurations semblaient correctes.
		+
		+	===Installation et configuration d’un network/application server en local : ChirpStack===
		+
		+	Nous avons donc réalisé l’installation et la configuration d’un Network Server et d'un Application Server en local en utilisant ChirpStack. A noter que nous n’aurons alors plus besoin d’exécuter le script NAT dans cette configuration.
		+	Pour cela, plusieurs étapes ont été nécessaires :
		+	installation de nombreuses dépendances nécessaires au fonctionnement de ChirpStack: PSql, Mosquitto (un protocole de messager publish-subscribe pour les bandes passantes limitée, idéale pour le Lora) … etc
		+	créations de deux databases respectivement pour le Network Server et l’Application Server
		+	installations du Network et de l’Application Server
		+	configuration des fichiers de config de ces deux serveurs pour indiquer de nombreuses informations :  choix des bandes de fréquences, définissant des ports UDP pour le binding, ouverture des bases de données en indiquant user, mot de passe …
		+	Une fois la configuration faite, nous avons pu accéder à l’interface Web de l’Application Server ChirpStack en local en accédant à localhost:8080/ .
		+
		+
		+	Plusieurs configurations sont ensuite réalisées sur cette interface pour préparer la réception des données de nos capteurs :
		+	*Enregistrement de la Gateway
		+	*Enregistrement du “end device”
		+	*Configuration du Network Server
		+	*Configuration de deux bases de données
		+	*Configuration optionnelle d’une API (type myDevices Cayenne)
		+
		+	Suite à la consultation des logs du Network Server, nous avons pu observer que l’accès à base de données Psql était refusé
		+	dans la configuration des registres de la balise Lora, nous ne sommes pas certains de l’adresse IP du Network Server à utiliser pour un serveur Local comme lors de ces tests (192.168.0.1, 127.0.0.1 ?)
		+	Toujours dans ces registres de configurations, nous ne sommes pas sûrs des ports UDP (up et down) à utiliser et n’avons pas trouvé d’informations nous ayant permis de trancher de façon certaine.
		+
		+	=Conclusion=
		+
		+	Durant ces trois semestres, nous avons essayé de mettre en place un réseau de capteurs en utilisant le LoRa.
		+
		+	Durant le premier semestre, le projet nous a semblé trop complexe et nous avons donc réalisé un prototype aux technologies simplifié, en utilisant une carte Arduino, la liaison série plutôt que le protocole LoRa, et un fichier CSV pour stocker les données.
		+	Ce semestre était plutôt orienté dans la découverte de la technologie à employer.
		+
		+	Au fil des séances, le projet nous a semblé de plus en plus clair, et nous avons acquis des compétences, ce qui nous a permis au semestre suivant de développer une solution plus concrète : nous avons réussi à faire communiquer deux cartes via le LoRa, en modifiant un code à la structure complexe et en reconfigurant certaines parties des cartes. Cela nous a permis d'acquérir des compétences de programmation et des connaissances sur le LoRa et les micro-processeurs.
		+	Nous avons aussi amélioré le code php et utilisé une base de donnée SQL. Cependant, un problème de pin nous a bloqué et empêché d'avoir une solution entièrement viable, la chaîne de transmission complète ne fonctionnant pas. Nous avons ainsi développé des compétences dans divers langages de programmation.
		+
		+	Au dernier semestre, nous nous sommes penchés sur la couche LoRaWan du protocole et l'utilisation d'une balise et d'un Network Server. Ce semestre était entièrement orienté réseau et configuration, ce qui nous a permis de mesurer toute la complexité de l'ajout d'une couche réseau. En utilisant le pack fourni, nous avons pu développer une solution presque fonctionnelle, mais tout comme le semestre précédent, un détail de configuration a dû nous échapper et le problème rencontré semble insoluble. Nous avons gagné ce semestre des compétences en programmation réseau.

---

Version actuelle datée du 6 mai 2022 à 01:47

Présentation générale

Parmi les sujets disponibles, nous avons choisi le projet "Mise en place d'un réseau de capteurs dans les salles de Polytech", qui consiste en la conception d'un réseau de capteurs de température et de qualité de l'air communicants via le réseau LoRa. Notre groupe est constitué de quatre élèves de la filière Systèmes Embarqués: Yanis Lacroix, Florian Vallée, Haitam Blgrim et Abdelillah El Khotri. Lors de la première partie en troisième année, le groupe était aussi aidé par Fidele-M'bouke. Il est encadré par Mr.Thomas Vantroys.

Contexte

La qualité de l'air est une information importante à avoir, surtout étant donné les conditions sanitaires actuelles. La loi impose une contrôle de la qualité de l'air intérieur dans les établissements primaires et secondaires, mais aucune loi n'impose le contrôle dans les établissements d'études supérieures (du moins pas d'ici 2023).

Les seuils réglementaires ne sont pas toujours respectés dans les salles de classe, cela peut nuire à la santé et à l'efficacité des élèves ; il est important d'avoir une vue globale des données, pour pouvoir réagir en conséquence.

Enfin, avoir un historique des données permettrait d'être en mesure de réguler certains problèmes de flux dans l'école.

Description

Le réseau de capteur est un ensemble de capteurs individuels, qui communiquent tous avec une balise LoRa présente dans l'école, qui s'occupe de transmettre les données à un serveur applicatif via IP. Une fois les données recueillies et stockées, elles seront affichées sur une page web.

Objectifs

Offrir la possibilité de contrôler, superviser des données physiques, principalement sur la qualité de l’air, récupérées en temps réel dans les salles de classe de Polytech dans le but d’alerter les utilisateurs de l’école.

Analyse du projet

Premier prototype

Lors de notre 3ème année, nous avions simplifié le cahier des charges. Notre projet est constitué de cinq blocs différents :

• Recueillir et traiter les données
• Transmettre les données
• Traduire les données
• Stocker les données
• Afficher les données

Pour recueillir les données, nous avons utilisé une carte Arduino, servant à recueillir les informations fournies par le capteur de température SHT15. A l'aide de la bibliothèque spécifique au capteur, nous avons pu, à l'aide de deux fonctions, obtenir les valeurs de température et d'humidité.

Pour transmettre les données, nous avons dû nous limiter à la liaison série, principalement pour des raisons matérielles et de temps. Le paramétrage était plutôt simple, en précisant le baudrate sur le code Arduino et en utilisant la fonction "Serial", les données sont envoyées sur le port série.

Pour traduire les données, nous avons utilisé un code Python qui lit sur le port série, ne prend que les bits correspondants aux données de température et d'humidité, et le range dans un tableau. On a ajouté dans ce tableau la date d'acquisition, avant de recopier le tableau dans un fichier CSV qui a servi dans la partie suivante.

Pour stocker les données, nous avons donc utilisé un fichier CSV, qui contenait les valeurs de température, d'humidité et de date d'acquisition.

Pour afficher les données, nous avons choisi d'utiliser du php servant à afficher les valeurs dans le fichier CSV.

Plusieurs problèmes sont à relever dans cette première version du projet : - La carte STM32 était imposée dans le cahier des charges et non au choix de l'équipe de projet; - La liaison série n'est pas le moyen de communication imposé, il s'agit du LoRa - L'utilisation d'une base de données SQL est plus adaptée qu'un fichier CSV

Ainsi, l'objectif du second semestre de projet était de résoudre ces problèmes.

Préparation du projet

Maintenant que le premier prototype a été décrit, nous allons mettre à jour le cahier des charges et rappeler les différents "blocs" du projet.

Cahier des charges

Le projet se découpe en 5 grandes parties :

• Recueillir et traiter les données
• Transmettre les données
• Traduire les données
• Stocker les données
• Afficher les données

Voyons ce que chaque bloc doit être capable de réaliser.

1.Recueillir et traiter les données

Pour recueillir les données, nous avons utilisé deux capteurs de température et d'humidité différents. Pour pouvoir acquérir les informations, les capteurs doivent être reliés à un microcontrôleur, ici la STM32 imposée.

2.Transmettre les données

Pour la transmission, un shield LoRa est connecté à la carte STM32. Le LoRa est un moyen de communication

Les données sont envoyées du module LoRa de la carte vers une balise LoRa (installée au préalable par un ancien groupe de projet), qui elle même communique au serveur applicatif via Ethernet.

3.Traduire les données

Une fois les données reçues sur le serveur applicatif, elles sont traduites par un code Python. En effet, il faut repérer et extraire les données issues de la trame Ethernet, puis extraire les données de la trame LoRa encapsulée. Le code Python, grâce à une bibliothèque, peut lire sur le port Ethernet et ainsi extraire uniquement les informations pertinentes. Le code Python sert aussi à faire le lien avec la partie suivante, qui est le stockage de données : il permet de créer une base de données, et de stocker les valeurs obtenues dedans.

4.Stocker les données

Pour stocker les données, le plus pertinent était de prendre une base de données SQL, et ce pour plusieurs raisons :

• La possibilité de faire des requêtes, ce qui facilite l'affichage
• SQL apporte une couche de sécurité minimale, contrairement à un fichier CSV

Cette base de donnée est créée à partir du fichier Python grâce à la bibliothèque xxxx.

5.Afficher les données

L'affichage se fait sur une page html contenant du code php, qui permet de lire les données dans la base SQL et de les afficher dans des tableaux, des graphiques, et permet aussi d'afficher des messages d'erreur ou des valeurs en couleurs pour signaler tout non respect des normes indiquées.

Choix techniques : matériel et logiciel

Partie S7

Acquisition :

• 2x Carte STM32L152RE
• Capteur de température et d'humidité
• Une Breadboard
• Un PC

Partie S8

• Pack STMicroelectronics Lora LF band sensor and Gateway contenant 2 éléments principaux :
• une carte de développement STM32 Nucleo-L073RZ couplée à une Expansion Board de chez RisingHF composée de 4 capteurs intégrés (humidité, température, pression, magnétomètre) et d’un module d’émission Lora
• une carte STM32 Nucleo-F746ZG couplée à une Gateway Expansion Board Lora (une balise Lora)

Calendrier prévisionnel

Projet S8

Réalisation du Projet

Projet S7

Récupération et transmission des données des capteurs

Nous nous sommes d’abord penché sur une transmission des données via Lora entre deux cartes, et non à la balise LoRa de Polytech. L’objectif de notre travail était que le capteur DHT11 recueille les valeurs de température et d’humidité, les fournisse à la carte émettrice, qui transmettra les données via LoRa. La carte réceptrice recevrait les données, et les transmettrait via la liaison série au PC, grâce au câble d’alimentation USB. Le code implémenté sur les cartes a été développé sur l’IDE STM32Cube.

Le véritable enjeu de ce semestre était la familiarisation avec l’environnement de développement et les cartes. Pour cela, nous nous sommes concentrés sur la compréhension d’un exemple de code existant de "Ping Pong" entre deux cartes via LoRa utilisant un HAL (hardware abstraction layer).

Nous avons modifié le code afin de pouvoir envoyer une trame personnalisée, puis nous avons réalisé une partie pour la carte émettrice, et une partie pour la carte réceptrice, qui envoie ensuite la trame sur la liaison série. Il a donc fallu définir un format de données avant la transmission. Pour cela, nous avons choisi d’utiliser le format suivant, stockée dans une chaîne de caractères: line = {T:xx.x,H:xx.x} sizeof(line) = 15 octets

Cette trame ne contenait pour le moment que des données statiques définies préalablement. Nous avons donc ensuite commencé à nous occuper de l’implémentation d’un code permettant la lecture du capteur DHT11. Pour cela, nous avons utilisé la bibliothèque STM32 dédiée (un autre HAL). Un problème de taille s’est mesuré à nous : faire en sorte qu’il n’y ait pas de conflit entre les configuration du capteur, du shield LoRa, et de la liaison série. Même s’il n’utilise électriquement pas tous les PINS du micro-contrôleur, le shield Lora occupe physiquement toutes les broches de la carte. Nous avons donc commencé par récupérer les données du capteur sans le Shield et les transmettre en série. Cela a fonctionné mais nous avons rencontré 2 problèmes : -les données capteurs (T° et Humidité) ne présentaient aucune précision au-delà de la partie entière (précision au dixième selon le constructeur) -impossible de récupérer les données sur une autre broche analogique autre que A1, malgré les modifications en conséquence du code (définition d’un autre PIN pour la variable DHT_PIN)

Après étude du schematic du Shield Mbed, nous avons remarqué que le shield proposait l’accès à deux broches analogiques de la carte A4 et A5.

Nous n’avons pas réussi à associer l’utilisation du LoRa et l’utilisation du capteur: avec une recherche très approfondie, nous avons pu localiser le problème ; lors de l’initialisation des ports du capteur, un des pins de celui-ci est censé changer d’état seul. Cela fonctionne lorsque le capteur est relié à la broche analogique A1 de la carte, mais pas sur les autres broches, que ce soit en câblant le capteur directement sur la carte ou par l’intermédiaire des deux PINS disponibles sur le Shield. Nous en avons alors déduit que les autres broches devaient êtres initialisées par le HAL Lora, et donc utilisées d’une manière ou d’une autre par le shield. Nous avons en effet pu déterminer que certaines broches étaient utilisées pour la transmission radio ou autre, mais pas les broches A4 et A5 de la carte. Pourtant, nous n’avons pas réussi à faire fonctionner le capteur sur ces broches. Il est primordial que le capteur fonctionne sur une de ces broches puisque ce sont les seules redirigées par le shield LoRa pour l’utilisateur, et donc les seules utilisables par le capteur lorsque nous voulons utiliser le shield LoRa et le capteur en même temps.

Transmission Lora

Nous avons le montage suivant :

Pour permettre l'échange de données, nous avons du modifier le code existant du Ping-Pong en profondeur. Ci-dessous un exemple d’échange de trame entre deux cartes :

Code permettant de transmettre des données en LoRa. La trame est préfaite ici pour réaliser des tests.

Récupération des données du capteur

Voici le format des données reçues par la liaison série de l'ordinateur :

Un script Python a été choisi. Ce code est composé d’une partie qui sert à recevoir les données grâce à la bibliothèque serial. Les données reçues du port série sont ensuite stockées dans une base de données MySQL comme indiqué dans les solutions retenues, afin de rendre notre application plus performante. Pour faire cela on importe la bibliothèque MySQLdb , après on se connecte d’abord à notre base de donnée en cas d’erreur il affiche qu’on a pas réussi à se connecter à la base de donnée. Ensuite le script va nous permettre de stocker chaque donnée reçue dans la base de donnée MySQL , et en cas d’erreur il affiche qu’il n’a pas pu stocker la donnée. On récupère également dans le script python la date et l’heure sous le format : date = ‘20xx-xx-xx’ time = ‘xx:xx’

Affichage des données

Pour afficher les données du capteur, un script PHP est utilisé. Voici le résultat :

Projet S8

Le schéma de principe permettant de résumer l’ensemble du projet réalisé au S8 est le suivant :

Prise en main du Package STM32

Dans un premier temps, il nous a fallu prendre en compte le package ST importé et tenté de comprendre le fonctionnement général des différentes sources et headers. En effet, en important ce package, nous avons récupéré un exemple de code permettant l’envoi classique des données du capteur à intervalle régulier, mais nous nous sommes très rapidement rendu compte que ce programme était dépendant de plusieurs dizaines d’autres fichiers pratiquement tous utiles.

Pour savoir dans un premier temps si les données des capteurs étaient bien récupérées et pour connaître le format de la trame envoyée, nous avons ensuite tenté d’afficher dans un terminal (à travers le port série) les données transmises au module Lora. Nous nous sommes très rapidement rendu compte qu’il allait être très difficile de réussir à faire cela (malgré de nombreuses tentatives et questions auprès de notre tuteur) étant donné que par exemple l’initialisation des USART se fait à travers de nombreuses fonctions très bas niveau imbriquées à travers des dizaines de fichiers. Même chose pour les données, qui sont récupérées de manière très complexe (fonctions bas niveau au niveau des registres) puis chiffrées quand accessibles plus facilement. Chercher à réussir à implémenter une fonction affichant les données des capteurs via la liaison série dans cet environnement à ce moment-là de la chaîne d’information s’est donc avéré inutile étant donné le temps que nous aurions perdu pour la mettre en œuvre.

Néanmoins, nous avons tout de même été en capacité de comprendre certaines fonctions du code et de modifier certaines constantes nécessaires à l’adaptation du code à notre projet. Par exemple, le package a été initialisé pour une utilisation en Chine et les bandes de fréquences utilisées par défaut n’étaient donc pas cohérentes avec les bandes de fréquences autorisées en Europe pour les communications Lora.

Configuration de la Gateway

Serveur DHCP Normalement, la balise devrait être connectée via un câble RJ45 à un routeur doté d’un service DHCP, et connecté à Internet. En effet, de nombreux Network Server sont disponibles au grand public et accessibles depuis Internet (The Things Network est un des plus connus par exemple). La balise devant communiquer avec ce serveur externe à son réseau local filaire, il lui faut donc une adresse IP valide sur son réseau pour qu’elle puisse recevoir des réponses du Network Server. D'où l'intérêt du routeur permettant de faire le lien entre le réseau LAN local de la balise Lora et Internet. Ne pouvant pas disposer de cet équipement réseau facilement lors de nos séances de TP, c’est une de nos machines personnelles qui a dû servir de routeur, sur laquelle nous avons donc dû configurer serveur DHCP. Pour cela, après avoir installer le paquet dhcp3-server, il est nécessaire de configurer 2 fichiers de configurations :

• /etc/default/isc-dhcp-server : on indique l’interface réseau sur laquelle on veut que le serveur dhcp soit actif. Dans notre cas c’est l’interface ethernet eno1.
• /etc/dhcp/dhcpd.conf : on renseigne toutes les informations relatives au réseau dans lequel les IP seront attribuées (masque, DNS …). Notre configuration est la suivante :

Pour pouvoir être en même temps connecté à internet, le PC utilise donc finalement la configuration réseau suivante : la balise est connectée sur l’interface Ethernet du PC, qui lui attribue donc une adresse IP sur le sous-réseau 192.168.0.0 dans la plage 192.168.0.20 - 192.168.0.30 (le PC a lui l’adresse routeur sur ce réseau soit 192.168.0.1) et le PC est en même temps connecté à Internet via l’interface Wifi sur le réseau 192.168.1.0.

Sur cette capture, on peut voir la configuration effectuée sur la balise. On y trouve des informations comme :

• l'ID de la Gateway
• L'adresse IP du serveur LoRaWan
• La bande passante
• Les ports UDP utilisés
• Le fait que l'objet réponde lorsque l'on fait une commande AT

On peut voir que la gateway est bien connectée en éthernet, que les ports UDP sont utilisables, puis un envoi de données.

Sur la capture suivante, on peut voir que les tests ont été concluants : le serveur DHCP a bien sur donner une adresse à la gateaway, puis a transmit les informations à "localhost", c'est à dire l'adresse IP 127.0.0.1, là ou est censé être le Network Server que nous avons configuré. De plus, on peut voir que les données envoyées sont bien celles reçues par la balise, la réception des données puis le routage ont bien fonctionné.

Configuration Network Server Loriot

Notre premier choix était d’utiliser le Network Server Loriot, serveur qui prend en charge les balises de notre pack. Nous avons donc choisi un des serveurs en Europe (EU3) , et avons changé l’adresse du Network Server configuré sur la balise en conséquence (eu3.loriot.io). Nous avons ensuite enregistré notre balise en précisant son adresse MAC, puis le end device en renseignant le DevEUI, l’AppEUI et l’AppKey nécessaire. L’AppKey est ce qui permet à l’Application Server de déchiffrer les données reçues par le Network Server. Nous avons aussi configuré CayenneMyDevices, une API qui permet de visualiser les données différemment que sur Loriot.

Malheureusement, après plusieurs séances de tests et de tentatives de debug par de nombreuses modifications des diverses configurations, nous n’avons jamais réussi à récupérer et afficher les données sur le site de Loriot, bien que les configurations semblaient correctes.

Installation et configuration d’un network/application server en local : ChirpStack

Nous avons donc réalisé l’installation et la configuration d’un Network Server et d'un Application Server en local en utilisant ChirpStack. A noter que nous n’aurons alors plus besoin d’exécuter le script NAT dans cette configuration. Pour cela, plusieurs étapes ont été nécessaires : installation de nombreuses dépendances nécessaires au fonctionnement de ChirpStack: PSql, Mosquitto (un protocole de messager publish-subscribe pour les bandes passantes limitée, idéale pour le Lora) … etc créations de deux databases respectivement pour le Network Server et l’Application Server installations du Network et de l’Application Server configuration des fichiers de config de ces deux serveurs pour indiquer de nombreuses informations : choix des bandes de fréquences, définissant des ports UDP pour le binding, ouverture des bases de données en indiquant user, mot de passe … Une fois la configuration faite, nous avons pu accéder à l’interface Web de l’Application Server ChirpStack en local en accédant à localhost:8080/ .

Plusieurs configurations sont ensuite réalisées sur cette interface pour préparer la réception des données de nos capteurs :

• Enregistrement de la Gateway
• Enregistrement du “end device”
• Configuration du Network Server
• Configuration de deux bases de données
• Configuration optionnelle d’une API (type myDevices Cayenne)

Suite à la consultation des logs du Network Server, nous avons pu observer que l’accès à base de données Psql était refusé dans la configuration des registres de la balise Lora, nous ne sommes pas certains de l’adresse IP du Network Server à utiliser pour un serveur Local comme lors de ces tests (192.168.0.1, 127.0.0.1 ?) Toujours dans ces registres de configurations, nous ne sommes pas sûrs des ports UDP (up et down) à utiliser et n’avons pas trouvé d’informations nous ayant permis de trancher de façon certaine.

Conclusion

Durant ces trois semestres, nous avons essayé de mettre en place un réseau de capteurs en utilisant le LoRa.

Durant le premier semestre, le projet nous a semblé trop complexe et nous avons donc réalisé un prototype aux technologies simplifié, en utilisant une carte Arduino, la liaison série plutôt que le protocole LoRa, et un fichier CSV pour stocker les données. Ce semestre était plutôt orienté dans la découverte de la technologie à employer.

Au fil des séances, le projet nous a semblé de plus en plus clair, et nous avons acquis des compétences, ce qui nous a permis au semestre suivant de développer une solution plus concrète : nous avons réussi à faire communiquer deux cartes via le LoRa, en modifiant un code à la structure complexe et en reconfigurant certaines parties des cartes. Cela nous a permis d'acquérir des compétences de programmation et des connaissances sur le LoRa et les micro-processeurs. Nous avons aussi amélioré le code php et utilisé une base de donnée SQL. Cependant, un problème de pin nous a bloqué et empêché d'avoir une solution entièrement viable, la chaîne de transmission complète ne fonctionnant pas. Nous avons ainsi développé des compétences dans divers langages de programmation.

Au dernier semestre, nous nous sommes penchés sur la couche LoRaWan du protocole et l'utilisation d'une balise et d'un Network Server. Ce semestre était entièrement orienté réseau et configuration, ce qui nous a permis de mesurer toute la complexité de l'ajout d'une couche réseau. En utilisant le pack fourni, nous avons pu développer une solution presque fonctionnelle, mais tout comme le semestre précédent, un détail de configuration a dû nous échapper et le problème rencontré semble insoluble. Nous avons gagné ce semestre des compétences en programmation réseau.