1

Ministère de l’enseignement supérieur et de la recherche scientifique

Université de Tunis

Ecole Nationale

Supérieure

d’Ingénieurs
Département de Génie Electrique

- 3 éme Année GE-ETA-

Rapport de stage technicien

Thème :
Envoie de données de consommation d’eau avec la
technologie LORAWAN

Réalisé par :
Oumaima Dinari

Maitre de stage :
M. Mouhamed Ali Boubakri

Travail proposé par : SFM Technologies

Année Universitaire : 2021/2022

Page | 1
 Remerciement…

Avant tout développement sur cette expérience professionnelle, il apparaît

opportun de commencer ce rapport de stage par des remerciements, à ceux
qui m’ont beaucoup appris au cours de ce stage, et même à ceux qui ont eu
la gentillesse de faire de ce stage un moment très profitable.

Aussi Je tiens à adresser mes plus sincères gratitudes et remerciements à

M. Mohamed Ali Boubakri mon maitre de stage pour son soutien, sa

disponibilité, son dévouement, sa patience, ses informations et ses précieux
conseils qui ont été déterminants dans l’élaboration de ce travail.

Enfin, je remercie l’ensemble des employés de SFM Technologies

pour les conseils qu’ils ont pu me prodiguer au cours de ces deux
mois.

2
 Liste de Figure
Figure 1:Groupe SFM..................................................................................................................................7
Figure 2:Fiche d’identité.............................................................................................................................8
Figure 3:Débitmètre 15-30L – min..............................................................................................................9
Figure 4:Lora transmetteur et Lora émetteur..........................................................................................10
Figure 5:Architecture de es32 avec module Lora (SX1278)......................................................................11
Figure 6:les caractéristiques d’un système embarqué.............................................................................13
Figure 7:Différents protocoles dans l’IoT.................................................................................................14
Figure 8:L’architecture globale LoRa-IoT..................................................................................................16
Figure 9:shéma du Gateways LoRa...........................................................................................................17
Figure 10 :Devices LoRaWAN classe A......................................................................................................18
Figure 11:Devices LoRaWAN classe B.......................................................................................................19
Figure 12:Devices LoRaWAN classe C.......................................................................................................19
Figure 13:Activation by personalization...................................................................................................20
Figure 14:Activation dans l'Air..................................................................................................................21
Figure 15:Paramétrage du device LoRa et du Serveur aprés le join-Request(OTAA)..............................21
Figure 16:La communication entre le device LoRa et le Network Server................................................22
Figure 17:Interface IDE Arduino...............................................................................................................23
Figure 18:La TTGO LoRa32 SX1276 OLED..................................................................................................24
Figure 19:LORA SENDER............................................................................................................................25
Figure 20:LORA RECEIVER.........................................................................................................................25
Figure 21:visualisation sur le serial monitor............................................................................................26
Figure 22:Visualisation sur le "thingspeak".............................................................................................27
Figure 23:test de LoRa Sender..................................................................................................................28
Figure 24:Test de LoRa receiver................................................................................................................29

3
Table des matières

Contents
Introduction générale..............................................................................................................................5
Chapitre I : Présentation générale du cadre de stage.............................................................................6
1.1 Introduction :.....................................................................................................................................6
I) Objectif du STAGE :.............................................................................................................................12
II ) L'Internet des Objets (Internet of Things / IoT).........................................................................12
1. Les systèmes embarqués dans l’IoT...................................................................................................12
IV ) Logiciel de programmation : ARDUINO IDE...............................................................................21
..............................................................................................................................................................23

4
 Introduction générale

Le stage est une occasion qui nous permet d'être en contact direct avec l'environnement
professionnel dans lequel nous entamerons notre future carrière.

En partant de cette participation, le stagiaire apprend des leçons pratiques en essayant de briser
les barrières de timidité, d'adapter et d'améliorer ses connaissances théoriques. Le stage nous
permet de connaître d'une façon générale les différents services de l'entreprise.

Alors, comme tous mes collèges, j’ai fait durant la période du 15 juillet au 31 Aout 2021 un
stage au sein d’une entreprise “SFM Technologies” dans le secteur d’ingénierie et
développement des applications et services.
Durant la période du stage, j’ai accompli le programme de stage fixé par le responsable du stage
au sein de l’entreprise. Je me suis soumis aux mêmes contraintes que les employés de
l’entreprise ; horaire de travail, ponctualité, assiduité, discipline…
Ce travail présentant le rapport du stage comportera trois parties : la première s’articulera sur la
présentation de l’entreprise d’accueil. Quant à la deuxième est consacrée au choix du logiciel et
les cartes que j’ai utilisé pour le développement et l’envoie de la donnée vers un serveur . La
troisième et après cette étude théorique nous avons visualisé le résultat de notre code sur des
organigrammes sur un cloud “thingspeak”.

Chapitre I : Présentation générale du cadre de stage

1.1 Introduction : 

SFM est une entreprise créée en 1995, issue du domaine des télécommunications et des réseaux. Son
équipe d’experts et d’ingénieurs de haut niveau réalise des missions d’ingénierie et de conseil pour le
compte de régulateurs des télécommunications, d’opérateurs, de Ministères des TIC et de bailleurs de
fonds (BM, BAD).

C’est au cours de ses missions que SFM a développé des outils, applications et plateformes pour la
digitalisation des process d’ingénierie, de suivi et de mesures de QoS/QoE, de contrôle des tarifs, …

SFM a ainsi acquis une expertise pour la réalisation de produits IT pour le secteur des télécoms mais
également pour d’autres secteurs comme celui des assurances, de la banque ainsi que des solutions de
gestion intégrées pour les TPE/PME.

5
 Figure 1:Groupe SFM

Les outils et développements sur-mesure offerts par SFM se déclinent selon 3 axes :

1 Digitalisation des process des entreprises (ou Robotic Process Automation) avec notamment les
produits COSAP, Ticketeazy et IT&M

1 Cybersécurité avec un portail d’accès WiFi sécurisé, un SOC et une PKI entreprise
2 Big Data et Intelligence Artificielle avec des solutions destinées aux secteurs des
télécommunications (détection de fraude et churn), bancaire (estimation de l’évolution des taux
de change), ajout de couches de ML et DL dans les produits SFM

Certains outils sont immédiatement utilisables tandis que d’autres sont personnalisés par l’équipe SFM
après étude des besoins et de l’environnement de chaque client.

SFM maintient avec tous ses clients un lien permanent permettant de faire évoluer ses produits, d’assurer
un service après-vente personnalisé et une assistance sur site ou à distance.

1.2 Informations de contact et emplacement :

6
 Figure 2:Fiche d’identité

1.3 Cahier de charge :

1.3.1 Problématique :
Dans une maison ou un bâtiment, il est très important d'analyser régulièrement la consommation
d'eau et ainsi de prendre des mesures, en évitant des coûts inutiles. La possibilité de
suivre/contrôler plusieurs points d'eau via une seule page web est permise par ce projet, voire la
coupure automatique de l'alimentation en eau lors de la détection d'une inondation.Dans ce
projet, la surveillance peut se faire localement ou à distance, de cette façon vous pouvez générer
des alertes par programmation afin d'avertir l'administrateur d'une surconsommation dans
n'importe quelle partie d'un bâtiment. Toutes les données générées sont envoyées et enregistrées
aussi bien dans un "serveur web" local que dans une base de données distante (Emoncms ou
Thingspeak).Les mesures de la consommation d'eau sont stockées dans l'EEPROM de
l'ESP8266. Il est ensuite affiché dans une page Web et transmis aux plateformes IoT.

1.4 besoin de Fonctionnement:

 Débitmetre a capteur de fuite d’eau
 CARTE DE DÉVELOPPEMENT ESP32 IOT MODULE OLED WIFI LORA SX1276
868MHZ/915MHZ AVEC ANTENNE
 Des fils
 Module wifi esp32

7
1.4.1 débitmetre :

Figure 3:Débitmètre 15-30L – min

2PT Commutateur de capteur de débit d’eau mètre Débitmètre 1，5-30L – min

Ce capteur est en ligne avec la ligne de flottaison et contient un capteur à moulinet pour mesurer
la quantité de liquide qu’il a traversé. Il y a un capteur à effet magnétique intégré qui émet une
impulsion électrique à chaque tour. Le capteur à effet Hall scellé par la conduite d’eau et permet
au capteur de rester en sécurité et au sec.
Le capteur est fourni avec trois fils : rouge (alimentation 5-24 VDC), noir (terre) et jaune (sortie
impulsion à effet Hall). En comptant les impulsions de la sortie du capteur, vous pouvez
facilement calculer le débit d’eau. Chaque impulsion d’environ 2,25 millilitres. Notez qu’il ne
s’agit pas d’un capteur de précision et que la fréquence du pouls varie légèrement en fonction du
débit, de la pression du fluide et de l’orientation du capteur. Un étalonnage soigneux sera
nécessaire si une précision supérieure à 10% est requise. Cependant, idéal pour les tâches de
mesure de base !

Nous avons un croquis Arduino comme exemple qui peut être utilisé pour tester rapidement le
capteur, calculer le débit approximatif d’eau en litres / heure.

Le signal d’impulsion est une simple onde carrée, donc assez facile à enregistrer et à convertir en
litres par minute en utilisant la formule suivante.
Fréquence d’impulsion (Hz) / 7,5 = débit en L / min.
Caractéristiques :
Modèle : YF-S201

Type de capteur : effet Hall

Tension de fonctionnement : 5 à 18 V CC (tension de fonctionnement minimale testée 4,5 V)
Consommation de courant maximale : 15 mA à 5 V
Type de sortie: 5 V TTL
Débit de fonctionnement: de 1 à 30 litres / minute
Plage de températures de fonctionnement: -25 à + 80
Plage d’humidité de fonctionnement: 35% – 80% d’humidité relative
Précision: 10%
Pression eau maximale: 2,0 MPa
Cycle de travail en sortie : 50% + -10%
Temps de montée en production : 0,04us
Temps d’abandon : 0,18us
Caractéristiques de l’impulsion de débit : Fréquence (Hz) = 7,5 * Débit (L / min)
Légumineuses par litre : 450
Durée : minimum 300 000 cycles

8
Longueur hauteur du câble : 15 cm
Connexions pour tuyaux 1/2 «, diamètre extérieur 0,78 », 1/2 « de filetage
Dimensions : 2,5 « x 1,4 » x 1,4 «
Détails de connexion :
Câble rouge : + 5 V
Fil noir : GND
Câble jaune : sortie PWM.

1.4.2 Carte de développement ESP32 iot Module Oled WIFI LORA SX1276
868MHZ/915MHZ avec antenne:

Figure 4:Lora transmetteur et Lora émetteur

a)Caractéristiques principales:

Puce SX1276 basée sur ESP32 Wi-Fi, fréquence 868 - 915 MHz, haute sensibilité sur-148 dBm,
puissance de sortie + 20 dBm, haute fiabilité, longue distance de transmission
Antenne Wi-Fi flash intégrée de 32 mo, écran OLED de 0.96 pouces, circuit de charge de
batterie au lithium, interface 9102X et puce série USB, prise en charge de l'environnement de
développement Arduino.
Parfaitement, peut être utilisé pour la vérification du programme, le développement du produit
est très facile et rapide.
b) Spécifications :
Tension de fonctionnement : 3.3 - 7 V

Plage de température de fonctionnement : -40 à 90 °C (-40 à 194 °F)

Prise en charge de l'analyse du protocole logiciel reniffer, des modes Station, SoftAP et Wi-Fi
Direct

Débit de données : 150 Mbps @ 11n HT40, 72 Mbps @ 11n HT20, 54 Mbps @ 11g, 11 Mbps @
11b

Puissance d'émission : 19.5 dBm @ 11b, 16.5 dBm @ 11g, 15.5 dBm @ 11n

Sensibilité du récepteur jusqu'à-98 dBm

9
C) Présentation :

Figure 5:Architecture de es32 avec module Lora (SX1278)

Conclusion :
Dans ce chapitre, nous avons présenté le cadre de travail dans lequel nous avons effectué le
stage, ce qui nous permis de mieux comprendre et apprécier le travail abattu à l’ensemble du
Personnel du SFM technology et de connaitre la place qu’occupe cette entreprise dans le
domaine de l’embarque et de IOT ainsi, nous avons présenté le sujet de notre stage.

10
Chapitre II : Modélisation du fonctionnement du
système

I) Objectif du STAGE : 

Le Sujet du stage explique les étapes nécessaires à la mise en place d’une application basique de
l’IOT avec la technologie LoRa.

La démonstration présentée consiste à envoyer des valeurs prélevées par un capteur Débitmètre
qui va détecter la fuite d’eau d’une électrovanne vers une plateforme Web/IoT publique et j’ai
choisi comme un serveur le (thingspeak) pour visualiser et Contrôler cette fuite.

II ) L'Internet des Objets (Internet of Things / IoT)

1. Les systèmes embarqués dans l’IoT

D’une façon générale, les systèmes électroniques peuvent être caractérisés par leur
consommation, leur puissance de calcul, leur taille et leur prix. Dans le cas spécifique des
systèmes embarqués utilisés dans l’IoT, nous pouvons affecter le poids suivant à chacune des
caractéristiques :

Figure 6:les caractéristiques d’un système embarqué

11
Comparés aux autres systèmes électroniques, les systèmes embarqués utilisés dans l’IoT
possèdent donc :

■ Une faible consommation

■ Une faible puissance de calcul

■ Une petite taille

■ Un prix faible

1.1 Différents protocoles dans l’IoT

Dans le monde l'IOT (Internet Of Things), on peut citer les protocoles suivants que nous pouvons classer
en fonction de leur bande passante et de leur portée dans la Figure suivante :

Figure 7:Différents protocoles dans l’IoT

Nous nous intéressons aux protocoles longue portée, faible débit et très faible consommation.
L’ensemble de ces réseaux sont dénommés LPWAN : Low Power Wide Area Network. Ce
graphique ne montre pas la consommation pour lesquelles les deux protocoles LoRa et Sigfox
sont sans contestation les plus performants.
1.2 Bandes de fréquence utilisées
En Europe, certaines bandes de fréquence sont libres d'utilisation

Le Tableau 1 présente quelques-unes de ces bandes libres.

Fréquences Quelques utilisations

13.56 MHz RFID, NFC

433 MHz Talkie-Walkie, télécommande, LoRa

12
On remarque
868 MHz qu'en Europe,Sigfox,
le LoRaLoRa
peut utiliser la bande des 433 MHz ou des 868 MHz.

2.4 GHz WiFi, Bluetooth, Zigbee

5 GHz Wifi

III) L’architecture globale LoRa-IoT

Les principaux éléments d’un déploiement IoT avec LoRa sont donnés en Fig. 1. Trois étapes de
communications peuvent être distinguées globalement :
• Une communication avec la technologie LoRa permet de connecter les capteurs aux
passerelles. Avec LoRa, cette communication s’effectue en un seul saut capteur-
passerelle.
• Différents types de communications peuvent connecter la passerelle LoRa au serveur-
IoT/Cloud. On retrouve généralement une connexion filaire Ethernet, ou sans fil avec
Wi-Fi ou 3G/4G ; ces liens hétérogènes représentent la connexion Internet. Le serveur
IoT stocke les données collectées par les capteurs et relayées par la passerelle. Ici, la
passerelle LoRa doit disposer d’au moins 2 interfaces de
Communication ; une radio LoRa et une interface Ethernet, Wi-Fi ou 3G/4G.
• Enfin, les données du serveur-IoT/Cloud sont accessibles aux utilisateurs via Internet.

13
 Figure 8:L’architecture globale LoRa-IoT

1. Distance de transmission en LoRa :

La puissance émise (PE) sera atténuée dans l'air selon la formule suivante :

𝐴𝑡𝑡é𝑛𝑢𝑎𝑡𝑖𝑜𝑛 = 10.𝑙𝑜𝑔10( 1755)

■ Atténuation : en dB.

■ Distance : en km.

■ Fréquence : en MHz.

On peut donc en déduire la distance maximale :

Le Link Budget étant l'atténuation maximale que peut supporter une transmission, nous pouvons
en déduire la distance en remplaçant l'atténuation par le Link budget :

• Le transceiver LoRa SX1276 (Link Budget de 168 dB), cela nous donne une distance
théorique de 6907 km.

14
2. Les Gateways LoRa :
Elles écoutent sur tous les canaux, et sur tous les Spreading Factor. Lorsqu’une trame LoRa est
reçue, elle transmet son contenu sur internet à destination du Network Server qui a été configuré
dans la Gateway au préalable. Elle joue donc le rôle de passerelle entre une modulation LoRa, et
une communication IP.

Figure 9:shéma du Gateways LoRa

Chaque Gateway LoRa possède un identifiant unique (EUI sur 64 bits). Cet identifiant est utile
pour enregistrer et activer une Gateway sur un Network Server.

3.Classes des Devices LoRaWAN :

Les Devices LoRa sont classés en 3 catégories (A, B, C) en fonction de leur consommation
et de leur accessibilité en Downlink, c’est-à-dire la facilité qu’un utilisateur aura à
transmettre une trame au Device LoRa.

3.1 Classe A (All) : Minimal power Application :

tous les Devices LoRaWAN sont de classe A. Chaque Device peut transmettre (Uplink) à la
Gateway sans vérification de la disponibilité du récepteur. Cette transmission est suivie de 2
fenêtres de réception très courtes. La Gateway peut alors transmettre pendant le « RX Slot 1 » ou
le « RX Slot 2 », mais pas les deux.

15
 Figure 10 :Devices LoRaWAN classe A

La durée des fenêtres doit être au minimum la durée de réception d’un préambule. Un préambule
dure 12.25 Tsymbole et dépend donc du Data Rate (DR : voir paragraphe 4.6 pour plus
d’information sur le DR) . Lorsque qu’un préambule est détecté, le récepteur doit rester actif
jusqu’à la fin de la transmission. Si la trame reçue pendant la première fenêtre de réception était
bien à destination du Device LoRa, alors la deuxième fenêtre n’est pas ouverte. Première fenêtre
de réception :

■ Le Slot RX1 est programmé par défaut à 1 seconde +/ 20 µs après la fin de l’émission Uplink.

■ La fréquence et le Data Rate (DR) sont les mêmes que ceux choisis lors de la phase
d’émission (Uplink). Seconde fenêtre de réception :

■ Le Slot RX2 est programmé par défaut à 2 secondes +/ 20 µs après la fin de l’émission
Uplink.

■ La fréquence et le Data Rate (DR) sont configurables mais fixes.

Un Device LoRa qui est uniquement de classe A ne peut pas recevoir s’il n’a pas émis. Il
n’est donc pas joignable facilement.

3.2 Classe B (Beacon): Scheduled Receive Slot

Les Devices de classe B ont le même comportement que les Devices de classe A, mais d’autres
fenêtres de réception sont programmées à des périodes précises. Afin de synchroniser les
fenêtres de réception du Device LoRa, la Gateway doit transmettre des balises (Beacons) de
façon régulière.

16
 Figure 11:Devices LoRaWAN classe B

Un Device LoRa de classe B est joignable régulièrement sans qu’il soit nécessairement obligé
d’émettre. En revanche, il consomme plus qu’un Device de classe A.

3.3 Classe C (Continuous) : Continuously Listening

Les Devices de classe C ont des fenêtres de réception constamment ouvertes entre 2 Uplinks.
Ces Devices consomment donc beaucoup plus.

Figure 12:Devices LoRaWAN classe C

Toutes les zones RX sont sur les même paramètres (canal et Spreading Factor) que RX2.
Un Device LoRa de classe C est joignable en permanence. En revanche, c’est la classe de Device
qui est la plus énergivore.

17
4. Activation des Devices LoRa : ABP ou OTAA
En LoRaWAN les trois éléments indispensables pour la communication sont le DevAddr pour
l’indentification du Device, ainsi que deux clés : le NwkSKey pour l’authentification et
l’AppSKey
Pour le chiffrement. Deux méthodes sont possibles pour fournir ces informations à la fois au
Device LoRa et au serveur :

■ Activation By Personalization : ABP.

■ Over The Air Activation.

4.1 ABP : Activation By Personalization

C’est la plus simple des méthodes. C’est donc peut-être celle que nous avons tendance à utiliser
lors d’un test de prototype et d’une mise en place de communication LoRaWAN.

■ Le Device LoRa possède déjà le DevAddr, l’AppSKey et le NwkSKey.

■ Le Network server et application serveur possède déjà le DevAddr, NwkSKey et AppSKey

En ABP, toutes les informations nécessaires à la communication sont déjà connues par le Device LoRa,
par le Network Server et par l'Application Server

Figure 13:Activation by personalization

4.2 OTAA : Over The Air Activation :

Cette fois-ci le DevAddr, l’AppSKey et le NwkSKey vont être générés lors d'une procédure de
négociation (Join-Request) dès lors que le Device LoRa se connectera pour la première fois au
serveur. Au préalable, le Device LoRa doit connaitre : le DevEUI, l’AppEUI, et l’Appkey. Le
Network Server doit, lui, connaitre le DevEUI, l’AppEUI, et l’Appkey.
Tous les éléments notés EUI (Extended Unique Identifier) sont toujours sur une taille de 64 bits.

18
C'est donc uniquement grâce à ces informations de départ et à la négociation avec le Network
Server (Join-Request) que le Device LoRa et le serveur vont générer les informations essentielles
: DevAddr, NwkSKey et AppSKey.

Figure 14:Activation dans l'Air

Lorsque le Join-Request a eu lieu, alors les paramètres générés (DevAddr, NwkSKey et

AppSKey) sont stockés dans le Device LoRa et dans les serveurs.

Figure 15:Paramétrage du device LoRa et du Serveur aprés le join-Request(OTAA)

Informations possédées par le Device LoRa avant le Join-Request :

■ DevEUI : Unique Identifier pour le device LoRa (Equivalent à une @MAC sur Ethernet).
Certains Device LoRa ont déjà un DevEUI fourni en usine.

■ AppEUI : Unique Identifier pour l’application server.

■ AppKey : AES 128 clé utilisée pour générer le MIC (Message Code Integrity) lors de la Join
Resquest. Il est partagé avec le Network server. Informations possédées par le Device LoRa
après le Join-Request :

■ NwkSKey : Utilisé pour l’authentification avec le Network Server.

■ AppSKey : Utilisé pour le chiffrement des données.

■ DevAddr : Identifiant sur 32 bits unique au sein d'un réseau LoRa.

19
 Figure 16:La communication entre le device LoRa et le Network Server

1. Le Device LoRa émet un Join-Request à l'aide des informations DevEUI, AppEUI et AppKey
qu'il possède.
2. Le Network Server authentifie le Join-Request et le valide. Il génère alors une NwkSKey, une
AppSKey, et un DevAddr.
3. Le Network Server retourne le DevAddr, ainsi qu'une série de paramètres.
4. Les paramètres fournis lors du Join-Accept, associés à l'AppKey, permettent au Device LoRa
de générer le même NwkSKey et le même AppSKey qui avaient été initialement générés sur le
Network Server.
Lora c’est : le réseau des objets connectés, c’est un réseau long porté à faible consommation
énergétique et surtout c’est un réseau bas débit
Un réseau bas débit c’est-à-dire que quelque dizaine d’octet changés par trame pensé un peu
comme un SMS
LoRaWAN est un protocole de télécommunication radio permettant la communication à bas
débit d'objets connectés. Il émet en France sur la bande de fréquence 868 mégahertz. Le signal
radio est émis sur une grande largeur spectrale, pour limiter au maximum le risque d'interférence
avec des signaux parasites.

Pour ce faire, il suffit de disposer d'une antenne reliée à internet (Wifi, câble, 4G, etc.) et d'une
station de base émettant en France sur la bande 868MHz (la bande de fréquence dépend du pays
considéré, aux Etats-Unis la bande utilisée par LoRa est de 915MHz).

IV ) Logiciel de programmation : ARDUINO IDE

L’IDE Arduino est le logiciel qui vous permettra de programmer votre Arduino ou n’importe
quelle carte électronique. Pour cette étape, rien de plus simple, vous aurez besoin d’un PC
(Windows, Mac ou Linux, Arduino est compatible avec ces 3 OS) sur lequel nous allons installer

20
le logiciel Arduino IDE et d’une connexion à internet. Et sélectionnez votre système
d’exploitation pour télécharger le fichier d’installation du logiciel. Une fois le fichier téléchargé
nous devons suivre les instructions de l’installateur :

1) Après avoir installé l’IDE Arduino, lorsque vous ouvrez le logiciel, une fenêtre semblable à
celle-ci devrait s’ouvrir :

Figure 17:Interface IDE Arduino

2) Il vous faut maintenant configurer le logiciel pour l’adapter à votre carte :

Dans la barre des menus cliquez sur « Outils » puis sur « type de carte » et sélectionner la carte
que vous souhaitez connecter (UNO, Nano, Mega 2560 …). Si vous choisissez la Nano ou la
Mega vous pouvez vérifier que la case « processeur » (toujours dans « Outils ») affiche bien
ATmega328 pour la Nano et ATmega2560 pour la Mega.

Dans notre cas on va connecter la carte ‘’ TTGO LoRa32 board”

 Le lien utilisé: Installing the ESP32 Board in Arduino IDE (Windows, Mac
OS X, Linux)

La TTGO LoRa32 SX1276 OLED est une carte de développement ESP32 avec une puce LoRa
intégrée et un écran OLED SSD1306 de 0,96 pouce. Dans ce guide, nous allons vous montrer

21
comment : envoyer et recevoir des paquets LoRa (communication point à point) et utiliser l'écran
OLED avec Arduino IDE.

Figure 18:La TTGO LoRa32 SX1276 OLED

Le test d’un LoRa Sender Sketch :

Télécharger le code sur le logiciel. Puis la sélection de la bonne carte et le bon port COM que
nous avons utilisé. Pour sélectionner la carte, dans l'IDE Arduino, accédez à Outils > Carte et
sélectionnez la carte TTGO LoRa32-OLED V1.

Après avoir téléchargé le code sur votre carte, elle devrait commencer à envoyer des
paquets LoRa :

22
 Figure 19:LORA SENDER

Le test d’un LoRa reciever Sketch :

Télécharger le code sur le logiciel.

Sélectionner le TTGO LoRa32-OLED V1 dans le menu Cartes.

Après avoir téléchargé le code, il devrait commencer à recevoir les paquets LoRa de l'autre carte.

Figure 20:LORA RECEIVER

Conclusion :
Après avoir illustrer l’objectif de notre stage et le logiciel utilisé pour le développement et le
protocole utilisé pour l’envoie du data (débit de consommation de fuite d’eau par minute ) par le
débitmètre et le partage de donnée soit via LORAWAN soit par le module WIFI vers un cloud
(thingspeak) ,nous allons constater notre travail pratique dans le chapitre3.

Chapitre III : Réalisation et la visualisation du

système

23
Introduction :

Dans les deux chapitres précédents, nous avons effectué une étude théorique concernant notre
stage en détaille, alors dans ce chapitre qui est consacré pour la réalisation pratique du notre
système.

1) Les étapes suivis pour la réalisation de ce système :

1.1) Collecte de valeur de débit : visualisation sur le port série :

Figure 21:visualisation sur le serial monitor

1.2) Visualisation sur l’Interface thingSpeak :

ThingSpeak : est un logiciel open source écrit en Ruby qui permet aux utilisateurs de
communiquer avec des appareils compatibles Internet. Il facilite l'accès aux données, la
récupération et l'enregistrement des données en fournissant une API à la fois aux
appareils et aux sites Web de réseaux sociaux, ThingSpeak a intégré la prise en charge du
logiciel de calcul numérique MATLAB de MathWorks, permettant aux utilisateurs de
ThingSpeak d'analyser et de visualiser les données téléchargées à l'aide de MATLAB
sans nécessiter l'achat d'une licence MATLAB auprès de MathWorks.

24
 Figure 22:Visualisation sur le "thingspeak"

 Litres comptant dans le moniteur série de l'IDE Arduino ;

 Configuration d'un serveur Web dans l'ESP8266, où les données de la consommation de
litres sont affichées en réponse à une requête HTTP. L'accès au serveur Web peut se faire
à l'intérieur du réseau ou de l'extérieur, nécessitant la configuration correspondante du
routeur Wi-Fi.

25
 Grâce à une requête HTTP GET, le nombre total de litres est envoyé à un serveur externe
(ThingSpeak). Avec ces informations, un tracé est affiché sur la plate-forme ThingSpeak
(voir https://thingspeak.com/channels/120470), qui peut être consulté dans n'importe quel
terminal Internet et analysé à tout moment.

 La possibilité d'utiliser un "html iframe" dans le serveur Web local pour afficher le
graphique de ThingSpeak (illustré sur l'image ci-dessus).

1.3) Communication avec esp wifi et Lora :

Il commence par inclure les bibliothèques nécessaires :

Ensuite, définissez les broches utilisées par votre module LoRa. Si vous avez suivi le
schéma précédent, vous pouvez utiliser la définition de broche utilisée dans le code.
Si vous utilisez une carte ESP32 avec LoRa intégré, vérifiez les broches utilisées par
le module LoRa de votre carte et attribuez la bonne affectation des broches.

a) Tester ESP32_LoRa_Sender :

Figure 23:test de LoRa Sender

26
 b) Tester ESP32_LoRa_Receiver :

Figure 24:Test de LoRa receiver

Si le RSSI est plus proche de 0, meilleur est le signal.

Les valeurs LoRa RSSI typiques sont comprises entre 0 et -120dbm, Si RSSI=-30dBm : le signal
est fort. Si RSSI>=-120dBm : le signal est faible.

Comme vous pouvez le voir ici, nous approchons de -28 ou -27dbm, ce qui signifie que le signal
est excellent. Les deux appareils sont à côté de chacun d’eux ; c'est pourquoi la force du signal
est bonne.

Conclusion :
Comme dans tout autre projet, quelque chose échoue...
Le NodeMcu a envoyé des erreurs de pile aléatoires, parfois en échouant à se connecter au
réseau wifi, ou en utilisant la fonction attachInterrupt.
Lorsque je démarrais le code, j'utilisais la bibliothèque ESP8266WiFiMulti.h et j'ai décidé
d'échanger contre la bibliothèque ESP8266WiFi.h, et l'erreur a commencé à apparaître moins
souvent.
Bien que je sois un peu meilleur en codage qu'en électronique. J’ai continué à lire ces problèmes
sur le Web, mais sans succès. J'ai utilisé 3 unités de NodeMcu (2 modèles différents), pour
vérifier si les erreurs provenaient d'un défaut, mais cela n'a fait aucune différence.

27
 Conclusion générale :
Malgré sa courte durée, j’ai le plaisir d’exprimer ma satisfaction face ce stage, qui était vraiment
utile et bénéfique. Je me suis intéressé de près aux outils de développement et la liaison entre
les cartes électroniques et les protocoles de communications. J’ai maîtrisé les étapes de l’étude
théorique de ces projets et les étapes pratiques. Je suis très content à cette formation que j’ai
obtenue dans ce mois et demie de vacances. J’étais profondément touché, non seulement par le
climat professionnel qui règne entre les différents secteurs, aussi par l’esprit de collaboration qui
marque le travail dans SFM TECHNOLOGIES.

Enfin, je tiens encore à remercier tous qui m’ont m’aidé de près ou bien même de loin à réaliser
ce modeste stage.

28