The Things Network / LoRaWAN : découverte

[al1fch]

Bonjour

Echaudé par Sigfox (impossibilité de renouveler l'abonnement d'un an pour un  seul appareil) je me tourne vers LoRaWAN et plus particulièrement The Things Network (TTN) , réseau WAN collaboratif et ouvert.

ça me rajeunit... je revis les débuts du réseau WiFi collaboratif  FON et ses Foneras!!

Sur la base d'une première réalisation à base de Mega 328, d'ESP32 et de transceivers LoRa Semtech SX1276 je propose  une série  d'articles de 'prise en mains'

-> Présentation de  LoRa et LoRAWAN sur http://www.linuxembedded.fr/2017/12/introduction-a-lora/




1- Mise en place des éléments sur la Console TTN
-application comportant un ou plusieurs 'devices' (appareils)
-éventuelle passerelle perso en cas d'absence  de passerelle disponible dans le voisinage

2. Réalisation d'un 'device' (capteur) basé sur une carte Loraduino (= Mini Pro 8Mhz 3V3) + transceiver LoRa SX1276

3. Réalisation d'une MINI passerelle (Gateway) mono canal  économique
carte TTGO ESP32 LoRa 868 OLED V1

4.  Traitement des donées reçues par les serveurs TTN : MQTT, Ubidots, ThingSpeak, IFTTT .......

5. gestion des infos en retour  TTN -> device


Aperçu : d'un bout à l'autre de la chaîne aujourd'hui ça donne ça pour l'information 'tension batterie' de la carte Loraduino


le capteur LoRaWAN TTN (= 'device') :



Les données reçues par TTN



Présentation des données avec Ubidots Education :


Rédaction progressive.....!!

[al1fch]

Partie 1 : Utilisation de la Console TTN

Il s'agit ici, après inscription à The Things Network, de déclarer :

-une application
-un ou plusieurs 'devices'  (capteurs pour l'instant)
-une passerelle ... si le besoin s'en fait sentir (pas de passerelle active dans un rayon de 2km )

Ces déclarations permettront de récupérer diverses  infos importantes dont des clefs à reporter dans le code des 'devices' et de la passerelle ('gateway')

Création d'une application (nommée ici mas91-19)

Cliquer sur APPILCATIONS, puis ADD APPLICATION



Création d'un 'device'
Cliquer sur REGISTER DEVICE et nommer celui ci


Choisir le mode d'activation ABP (le plus simple, le moins sécurisé = clefs constantes codées en dur)


Relever l'adresse et les deux clefs la première NSK permet l'authentification, la seconde  ASK sert au cryptage des données .

la création de la passerelle éventuelle sera décrite plus loin

[al1fch]

PARTIE 2 : Réalisation  d'un 'Device' (capteur LoRaWAN)  (< 10€)

Matériel : Carte LoraDuino mais une carte Mini Pro 3V3 8MHz et un SX1276 suffisent.
Pour me simplifier la vie j'ai pris chez l'un de mes fournisseurs asiatiques préférés ( documentation et suivi des produits) une carte Loraduino  sur laquelle j'ai soudé un SX1276 (868-915 MHz) acheté séparément

Elle comporte un chargeur d'accu LiPo et une petite mémoire Flash SPI 8 Mb inutilisée ici
(cf schéma carte Loraduino joint avec une erreur le quartz est bien à 8Mhz)

Logiciel : on trouve en général pour cet emploi des codes utilsant la librairie LMIC, j'ai trouvé quelque chose de plus 'KISS', une librairie reprise par Adafruit : TinyLoRa qui fait l'affaire.(elle est présente dans le gestionnaire de librairies , elle est également OK pour ESP)

Quelques adaptations de l''exemple 'hello_LoRa_single_chan' et ça roule.... les paquets bien formattés pour le LoRAWAN de TTN partent dans l'air et .... si par chance une passerelle TTN du voisinage les capte ils sont routés dans le réseau TTN. Sinon , faire une passerelle TTN !

Voici le code d'exemple  adapté à la carte Loraduino (led) + renseignement de l'adresse et des deux clefs du 'device'  relévées précédement sur la console TTN
Dans ce code j'ai également fixé des valeurs de canal, d'étalement (SF) et de bande passante (BW) identiques à celles de la passerelle que j'ai du me résoudre à faire.

Code: [Select]

/*

  OK sur carte LORADUINO  (Electrodragon) = Mini Pro 3283,3V 8MHz + radio Semtech SX1276 868 MHz+ .....
 
  Emission de données vers le réseau LoRaWAN collaboratif TTN 
  via une passerelle perso ou toute autre passerelle TTN disponible à proximité

  Le canal , l'étalement (sf) et la bande passante ( BW) doivent être  définis en lignes 71  et 72
  A l'identique de leur définition dans la passerelle monocanal perso (TTGO LoRA Oled V1)

  les lignes 38, 41 et 44 reprennent les 2 clefs et l'adresse du "device" obtenus sur la console TTN
  L'activation en mode ABP implique que ces clefs soient constantes et codées 'en dur' dans le code
  l'activation par OTA se fait par négociation , elle apporte plus de sécurité, mais ne semble pas encore
  à la portée des librairies utilisées ici.

*/

// Hello LoRa Single Channel - ABP TTN Single Channel Packet Sender
// Tutorial Link: https://learn.adafruit.com/the-things-network-for-feather/using-a-feather-32u4
//
// Adafruit invests time and resources providing this open source code.
// Please support Adafruit and open source hardware by purchasing
// products from Adafruit!
//
// Copyright 2015, 2016 Ideetron B.V.
//
// Modified by Brent Rubell for Adafruit Industries, 2018
/************************** Configuration ***********************************/


#include <TinyLoRa.h>
#include <SPI.h>

# define LED_BUILTIN 7
const int batterie = A7; // pont diviseur tension batterie

// Network Session Key (MSB)
uint8_t NwkSkey[16] = { A RENSEIGNER}; // MSB

// Application Session Key (MSB)
uint8_t AppSkey[16] = { A RENSEIGNER}; // MSB

// Device Address (MSB)
uint8_t DevAddr[4] = { A RENSEIGNER}; // msb

/************************** Example Begins Here ***********************************/
// Données à envoyer vers TTN (payload)
unsigned char loraData[4] = {"    "};

// délai entre deux émissions
const unsigned int sendInterval = 300;

//  TinyLoRa(irq,ss)
//TinyLoRa lora = TinyLoRa(26, 18); // TTGO32
TinyLoRa lora = TinyLoRa(2, 10); // Loraduino d'Electrodragon

/*
 *
 */
void setup() {
  delay(2000);
  Serial.begin(115200);
  //while (! Serial);

  // Led de la carte
  pinMode(LED_BUILTIN, OUTPUT);

  Serial.print("lancement LoRaWAN...");

  // configurer (canal, étalement, bande passante) comme fait avec la passerelle monocanal
  lora.setChannel(CH0);
  lora.setDatarate(SF9BW125);
  if (!lora.begin()) {
    Serial.println("Echec");
    while (true);
  }
  Serial.println("OK");
}

/*
 *
 */
void loop() {
  Serial.println("Envoi données vers TTN...");

  uint16_t vbatt = 6.4 * analogRead(batterie);

  //envoi 2 octets (paquet reformaté à convenance dans  la console TTN)
  loraData[0] = highByte(vbatt);
  loraData[1] = lowByte(vbatt);

  lora.sendData(loraData, sizeof(loraData), lora.frameCounter);
  Serial.print("Compteur Trames : "); Serial.println(lora.frameCounter);
  lora.frameCounter++;

  // del témoin d'envoi
  digitalWrite(LED_BUILTIN, HIGH);
  delay(1000);
  digitalWrite(LED_BUILTIN, LOW);

  Serial.println("temporisation...");

  delay(sendInterval * 1000);
}

A l'arrivée , dans la console TTN , voici l'info 'tension de la batterie'

[al1fch]

Partie 3 : Création d'une passerelle perso TTN monocanal (<20€)

Près de 300 'vraies' passerelles TTN sont déjà implantées en France, dont de nombreuses en région parisienne. Aucune ne m'est actuellement accessible , je suis dans une 'zone blanche', les paquets émis par mon 'device' ne sont pas captés, donc pas routés dans TTN.


Solution adoptée pour la passerelle (Gateway)  TTN : Faire une petite passerelle perso simplifiée.
Matériel : une carte ESP . TTGO 32 LoRa Oled V1 dans mon cas


Logiciel : un  code exceptionnel , de Maarten Westemberg ( lien vers le dépot github ) , qui prmet de faire une passerelle monocanal à très faible coût (<20€) 
Ce code s'appelle ESP-1ch-Gateway-V5.0. (V5.3.3)

Il est  très structuré (une quinzaine d'onglets) et bien documenté,  a été fait pour ESP8266 et vient d'être adapté aux ESP32.
N.B Sur le dépot j'ai récupéré également toutes les librairies  et les ait installées  et utilisées telles quelles pour cette application même si certaines d'entre elles peuvent dater un peu.

La configuration avant compilation  est à effectuer dans le fichier ESP-sc-gway.h en divers endroits
je joins mon fichier  mon fichier ESP-sc-gway.h.

Sauf oubli , les lignes modifiées dans ce fichier de configuration ont été  les lignes :
90 : adaptation à ma carte
116 pour désactiver WiFIManager qui semblait mal fonctionner et ne m'est pas utile
138 : pour sélectionner le type d'afficheur de ma carte
195 : pour reporter le nom de la passerelle choisi dans la console TTN (voir plus haut)
196 à 200 : mail, coordonnées...
263 : point d'accès WiFi   /!\ attention à laisser intacte la 1e ligne du tableau

Certains parametres peuvent être modifiés ensuite 'à chaud' car l'application ouvre un serveur HTTP de paramétrage :


Enregistrement de la passerelle côté TTN
Se connecter à TTN , ouvrir la console, choisir Gateway

Register Gateway

Nommer la passerelle


Passerelle monocanal ?

Malheureusement elle est pratiquement cantonnée à une seule fréquence, un facteur d'étalement et une bande passante. Elle ne peut  capter et router que des paquets d'un type unique et délaisse les autres.

Ce n'est pas une passerelle TTN complète , elle ne peut pas 'servir' tous les paquets variés susceptibles d'être émis par des tiers mais elle peut servir à tester TTN... en attendant de pouvoir pleinement jouer le jeu du partage avec une passerelle TTN complète.

MISE A JOUR : dépôt de la version 6.2.6 (octobre 2020 ) https://github.com/things4u/ESP-1ch-Gateway

[al1fch]

Partie 4 : Exploitation des données reçues par les serveurs  TTN

La transmission se fait bien , les données brutes apparaisent dans la console TTN.... et après ?

Le menu  Payload Format de la console permet d'appliquer une fonction de son choix sur les données brutes reçues. ça permet au besoin, comme avec Sigfox, de 'tasser' les données  dans le paquet radio émis et "déplier" à l'arrivée.

dans mon cas la valeur de tension de batterie apparait en clair à partir des deux octets reçus


ce n'est pas tout, le menu Integrations permet de "s'accrocher" à des services  divers, propres à TTN ou tiers (IFTTT, Ubidots...)

En attendant d'utiliser les service 'HTTP Integration' pour envoyer les données vers ThingSpeak j'ai activé la conservation des données dans le service 'Data Storage' de TTN et dans Ubidots que j'utilise par ailleurs en complément de ThingSpeak (le transfert vers Ubitots est facilité avec TTN)




Le résultat sur Ubidots Education:


-> Fonctionnalités et limitations d'Ubidots Education (gratuit)

[al1fch]

Partie 5 : Gestion des informations en retour (de TTN vers le 'device')
(Non réalisé pour l'instant en raison des limitations actuelles du code de ma passerelle perso.)

Toujours pas d'avancée, la communication reste pour l'instant  unidirectionnelle
 
Capteur ->   passerelle   -> Box  -> Serveurs TTN  -> Application

-> Par contre rédaction d'un message #7 décrivant la réalisation d'un second 'device ' (capteur) avec une carte TTGO LORA Oled V1 et une librairie LoRaWan distincte ce celle utilisée ci dessus pour le 'device 'avec la carte a Mega 328

[lesept]

Tu t'y mets aussi finalement !!!
Très intéressant, merci du tuto.

[al1fch]

Création d'un second 'DEVICE' , cette fois ci avec une carte ESP32 'TTGO LoRa OLED V1'

Le message #2 décrivait un 'device' utilisant une variante de carte Pro Mini dotée d'un transceiver LoRa SX1276 (868 MHZ)

Ici je présente la création d'un second 'device' avec une carte à ESP32 , la carte TTGO LoRA Oled V1, identique à celle utilisée en #3 pour faire la mini passerelle TTN


N'ayant pas encore pu exploiter avec ESP32 la librairie LoRaWAN légère utilisé précédemment (#2)  je me suis rabattu ici sur une librairie plus lourde issue d'IBM, souvent utilisée, la librairie LMIC , ou plutôt l'une des trois  variantes disponibles dans le gestionnaire de librairies



la communauté TTN est très active, docs, forum....
Pur exploiter cette carte j'ai utilisé les informations disponibles içi

Je suis parti d'un exemple utilisant la méthode ABP pour la connection avec le réseau WAN TTN (The Things Network), l'exemple ttn-abp, et l'ai adapté :
-a ux données (adresse et clefs fournies par TTN)
-a la carte TTGO LoRa Oled V1 (câblage  du SX1876, LED bleue....)
-aux restrictions imposées par la passerelle monocanal perso
-pour l'instant les donnée envoyées sont constantes, l'afficheur n'est pas utilisé, ni le WiFi ou le BT, il s'agit juste de valider la chaïne de transmission des infos, pas encore de deep-sleep entre les émisions......

Première étape :  déclarer (créer) un second 'device' dans la console TTN
lui attribuer un nom et un identifiant du genre" 01 23 45 67 89 AB"
La Console attribue au 'device'  une adresse hexa et deux clefs (authentification et cryptage) à reporter dans le code

Seconde étape  : adapter l'exemple.Les interventions sur l'exemple 'ttn-abp' sont les suivantes :

lignes 67-71 : report de 2  clefs et de l'adresse (attribuées par TTN)
ligne 81 : données constantes à transmettre (en attendant mieux....)
ligne 86  intervalle entre les émissions (en secondes)
lignes 91-94 :  GPIO de liaison avec la puce radio SX1276
lignes 99-110 forçage d'une fréquence et d'un facteur d'étalement, ici canal 0 et SF 7, comme réglé précedemment sur la mini -passerelle . (sans ces lignes la librairie LMIC qui fait du "LoRaWAN standard", change la fréquence d'émission... chose que ne sait pas faire la mini passerelle, résultat 1 paquet sur trois seulement était accepté par la passerelle. D'ou le besoin du forçage)
ligne 278 : appel de la fonction de forçage radio (canal et SF uniques)

Le programme testé avec succès est joint (trop long pour la publication dans le message), je vois sur la Console TTN les données issues des deux devices, peu de paquets  perdus (collisions entre devices ?)

[al1fch]

Une remarque

Contrairement au cas du WiFi les 'devices LoRaWan' n'ont pas à se connecter aux passerelles ('gateways') de la même manière qu'une station WiFi se connecte à un point d'accès.


Les deux clefs et l'adresse renseignées dans le code des 'devices' (en mode d'activation ABP) ne servent que pour l'accès au réseau Wan TTN.

Ma petite MINI passerelle réglée sur 868,1 MHz (canal 0) avec un facteur d'étalement de 7  accepte tout paquet émis avec ces réglages et les relaient par Internet aux serveurs de TTN

De même les paquets émis par mes 'devices' sont susceptibles d'être captés et relayés par d'utres passerelles que la mienne

CI dessous la réception et la prise en charge d'un paquet reçu d'une source distante (à 122 dB , preuve de la grande  sensibilité permise par la modulation LoRa). Les paquets gérés par la passerelle sont cryptés et cette dernière ne peut en principe les décrypter.

(copie d'écran de la page web servie par la mini passerelle)

[al1fch]

Un article complet et détaillé sur ce sujet ( TTN , LoRaWAN, noeud, passerelle......)
Article orienté Raspberry Pi

https://www.framboise314.fr/mise-en-place-dune-passerelle-et-dun-noeud-lora/#more-3374

[al1fch]

Bonjour

Voici une solution alternative pour faire un 'Device' connectable au réseau LPWAN collaboratif 'The Things Networks'

Elle utilise un nouveau module, le E78 868LN22S  de la société EBYTE (sorte de 'modem LoRaWAN')

http://www.ebyte.com/en/product-view-news.aspx?id=770


Ce module associe (dans une puce ASR6501) un microcontrolleur ARM Cortex M0+ et une puce radio SX1268 de Semtech
https://www.thethingsnetwork.org/marketplace/product/lora-sip-asr6501

Les modules E78  sont vendus  flashés avec un firmware de commandes AT permettant de gérer complètement la connection LoRaWAN.

/!\ Pas de LoRa point à point avec ce module il est exclusivement LoRaWAN !!


Le code à placer dans une carte Arduino , une cartes à ESP8266 , ESP32 ou autre est alors très simple, il se résule à l'envoi de quelques commandes AT
http://www.ebyte.com/en/downpdf.aspx?id=770

Les prix font du yoyo sur les boutiques d'Aliexpress qui le vendent (CDEBYTE, CDSENET, COJXU..)
je le vois aujourd'hui 9 janvier  à 3,41€, port compris chez CDSENET !!

Pour le test,  après avoir défini un nouveau device dans la console TTN et récupéré ses divers paramètres : adresse, clefs..

j'ai préconfiguré le module à la main (ordinateur + interface USB UART 3,3V)
commandes : AT+DEVADDR, AT+CDEVEUI, AT+CAPPEUI, AT+CAPPSKEY , AT+CNWKKEY pour reporter les paramètres du device  puis AT+CSAVE pour enregister la configuration

câblage d'un module E78 et , pour ce test, d'un WEMOS D1 Mini


Le plus délicat est le câblage du module E78 au pas de 1,27mm !!

Le code simpliste (joint) utilise pour les commandes AT , la classe SteamDevice de @J-M-L et mets en 'deep-sleep' les E78 et le D1 Mini entre les envois de données sur le réseau LPWAN "The Things Networks"
Il enchaîne deux seules commandes AT, la première demande un envoi unique, sans réponse, d'une donnée de 4 octets , la seconde met en sommeil le E78.

N.B : Programme à améliorer, la gestion des reveils n'est pas assez soignée  , je constate de temps en temps l'envoi d'une trame avec la donnée à mise à zéro.






EDIT : Variante en remplaçant l'ESP8266 par une carte Pro Mini 8MHz 3V3 modifiée (-led , -regulateur) consommation de l'ensemble en veille 7,3µA... pas mal pour un capteur LoRaWAN sur réseau TTN alimenté  sur pile ou batterie