LoRa: qu’est-ce que c’est ? à quoi ça sert ?

LoRa ou LoraWAN, vous en avez peut être déja entendu parler ou jamais encore ? Voici l’occasion de faire un point sur cette techno d’apparence simple mais qui peut faire de grandes choses et solutionner pas mal de problématiques en domotique (capteurs déportés sans source d’alimentation, large couverture avec une seule borne, prévention de dommages comme des inondations entre autre,…) mais également dans le domaine de la surveillance à distance d’équipements.

Je commencerais par une présentation générale de la technologie dans ses grandes lignes, avant de vous présenter l’architecture d’un système LoRa avec ses différents éléments pour finir par un résumé des points forts et faibles de la technologie. Dans un prochain article, je vous présenterais la mise en oeuvre pratique avec quelques appareils interfaçés avec Home-Assistant.

Présentation générale:

Tout d’abord une petite mise au point de vocabulaire. On utilise le terme LoRa ou LoRaWAN de façon générale sans faire trop de distingo mais en fait LoRa désigne le système de modulation radio propriétaire et LoRaWAN désigne l’ensemble du système de communication entre les terminaux et les passerelles. Ici j’utiliserais le terme LoRa ou Lora tout le temps pour plus de simplicité car nous ne rentrerons pas dans les détails trop techniques.

Pour la petite anecdote, la technologie LoRa a été mise au point par une startup grenobloise en 2009 (Cycléo). Cette dernière a ensuite été rachetée par l’américain Semtech qui du coup pouvait produire toutes les puces pour ce nouveau système radio. Au jour d’aujourd’hui tous les appareils implémentant du LoRa ont une puce Semtech en leur coeur. Le protocole lui-même est désormais géré par la fondation LoRa Alliance.

Quel était le but de Cycléo en développant cette technologie ? Permettre à des objets connectés, typiquement des capteurs, de pouvoir transmettre leurs relevés de mesure à distance, voire longue distance, tout en fonctionnant sur batterie ou avec une énergie très limitée (solaire, batterie…).

Les capteurs peuvent être aussi variés qu’un compteur d’électricité ou d’eau, un compteur de passage pour les voitures sur une route, les boutons de satisfaction que vous trouvez dans les lieux publiques, capteur de température/humidité….

Fréquences utilisées:

Le LoRa utilise une bande de fréquences libre d’utilisation et selon les régions du monde différentes:

• 863-870MHz pour l’Europe
• 902-928MHz pour les États-Unis, le Canada et l’Amérique du Sud
• 470-510MHz en Chine
• 915-928 pour l’Australie
• 920-923 pour l’Asie avec des spécificités par pays.

La vérification de la fréquence est un point très important lors de l’achat de matériel LoRa sinon vous vous retrouverez avec un équipement inutilisable !

Données transmises:

Afin de permettre une très grande distance de transmission, la vitesse de transmission est très faible et les paquets transmis sont tout petits (cela n’a absolument rien à voir avec le Wifi par exemple qui lui fonctionne en duplex permanent avec un traffic de données ininterrompus).

On notera également que les paquets sont cryptés et donc même s’ils peuvent être captés par des tiers, ils ne sont pas décodables ni exploitables par des tiers.

On a donc un écosystème dans lequel les capteurs peuvent fonctionner sur une simple pile pendant plusieurs années et transmettre leurs données à plusieurs kilomètres de distance. Même les appareils les plus rustiques transmettent facilement à quelques km au minimum, et les bornes/gateways ont assez facilement une couverture de 20 à 30km.

Pour la petite anecdote, le record de portée Lora à ce jour est de 832km en utilisant un ballon sonde équipé d’un capteur Lora d’une puissance ridicule de 25mW et une station au sol !

Un autre exemple avec ma propre borne installée sur la terrasse de mon appartement en ville et qui a une couverture d’au moins 30km autour et pourtant je suis en ville.

Un protocole asymétrique

Un autre point important pour finir cette présentation générale est que le système est conçu principalement pour des remontées d’information et donc est extrêment asymétrique dans son traffic, voire unidirectionnel dans 99% du temps.

En effet, les capteurs vont envoyer des messages vers le réseau mais ce dernier ne renvoie pas de données en retour. De ce fait, 99% du traffic est depuis les capteurs et appareils vers le réseau et très rarement du réseau vers les appareils/capteurs. Pour cette raison, les appareils n’écoutent les messages descendants que brièvement lors de l’envoi d’un message remontant.

On y reviendra plus tard car cela a certaines conséquences sur le fonctionnement du réseau. Par exemple, compteur de messages sur ma passerelle (à peine 15 messages descendants du réseau vers les appareils pour 3 237 venant des appareils).

Cependant certains appareils pourront être une exception en utilisant une classe spéciale du LoRa qui est la classe C qui permet une écoute permanente des messages descendants. Par exemple le voyant de salle de conférence présenté plus haut se contente de recevoir des messages mais n’en envoie pas. Ce mode n’est bien sûr possible que pour des appareils qui ne sont pas sur des sources d’énergie limitées comme des piles ou batteries.

Architecture d’un réseau LoRa:

Comme pour un réseau GSM par exemple, le réseau LoRa est un système permettant la cohabitation de plusieurs réseaux sans problèmes majeurs s’ils sont bien configurés. De ce fait, il existe des réseaux LoRa totalement privés utilisés par exemple par des transporteurs pour suivre leur flotte de véhicules ou encore votre propre réseau, des réseaux commerciaux tels que ceux des opérateurs télécom type Swisscom, Orange,… et des réseaux participatifs tels que The Things Network, Helium…

Dans tous les cas, tous ces réseaux partagent une structure similaire que l’on va détailler maintenant en s’appuyant sur le schéma ci-dessous (image plus grande en cliquant dessus).

• • • On va commencer par la gauche avec les appareils, typiquement les capteurs dont on a parlé précédemment, qui vont envoyer leurs données périodiques sur le réseau LoRa. Les messages envoyés seront captés par une ou plusieurs bornes LoRa à portée. Le réseau LoRa gère automatiquement les doublons et donc aucun risque de recevoir 2 fois le même message. Chaque message a un ID unique qui permet au réseau LoRa de faire le nettoyage dans les messages redondants. Comme on l’a déja évoqué précédemment, les messages seront quasiment uniquement depuis les capteurs vers le réseau LoRa (Uplink). Les messages descendants du réseau vers les capteurs seront essentiellement pour modifier à distance les paramètres d’un capteur (Downlink) et ceux-ci ne pourront être transmis qu’au moment où le capteur enverra un message (fenêtre d’écoute). En effet, il est hors de question d’avoir un appareil qui reste à l’écoute en permanence car cela « coûterait » beaucoup trop en énerqie. Il s’agit du mode Classe A. Il existe d’autres modes de fonctionnement du LoRa mais qui sont très spécifiques et rarement utilisés: Classe B où l’appareil va périodiquement écouter et non uniquement quand il a transmis quelque chose, et le Classe C où l’appareil quand il ne transmet pas est en écoute permanente (mais cela est réservé à des appareils sur alimentation permanente). Quelques exemples de capteurs/appareils ci-dessous (de gauche à droite un capteur de température/humidité de Dragino (LHT-65N), un détecteur de fuite/inondation (Laiier Severn WLD),un voyant d’occupation de salle de réunion):

    • Dragino LHT-65N

      Severn WLD

      Plenom Busylight

  • • Les messages émis par les appareils vont être alors captés par une ou plusieurs passerelles (Gateways en anglais) à proximité. Les passerelles se contentent « uniquement » de relayer les messages radios des appareils au serveur LoRa (Uplink) et dans l’autre sens également (Downlink). En raison de la toute petite taille des messages LoRa, les gateways peuvent être connectées au serveur via une simple liaison GSM voire modem analogique, car le traffic généré est assez ridicule. La passerelle peut tourner sur un SBC type Raspberry sans problèmes en utilisant un HAT adéquat (par exemple chez RakWireless, à gauche ci-dessous), cela peut être sur un matériel dédié (par exemple, au milieu ci-dessous) ou bien une solution robuste pour l’extérieur comme ce genre de choses, à droite ci-dessous. Beaucoup de ces passerelles sont alimentables sur batterie/panneau solaire pour des lieux reculés ou placer la borne au mieux par exemple dans le cas d’utilisation pour des fermes ou des cultures.
      

      RakWireless Hat

      SenseCAP M2 LoRaWAN Indoor Gateway

      RakWireless 8/16 channel Outdoor LoRaWAN Gateway

  • Le serveur LoRa lui-même est purement logiciel et va tourner sur un ou plusieurs ordinateurs selon la charge du réseau. Il est en général disposé sur Internet pour un accès facile des passerelles au serveur, mais il peut aussi se trouver dans un LAN pour un réseau d’entreprises par exemple voire même dans une passerelle pour des réseaux très limités ou totalement privés (les modèles de passerelles évoqués juste avant supportent toute ce mode).  Dans le cas de réseaux privés, on pourra utiliser Chirpstack, qui est la seule implémentation open-source d’un serveur LoRa et qui permet alors de construire intégralement son propre réseau LoRa. Dans le cas de réseaux publiques ou semi-publiques, l’opérateur donnera accès aux réglages nécessaires pour ajouter des passerelles et des appareils dans son réseau via une console de gestion. Ce serveur gérera l’ensemble des passerelles qui lui sont raccordées ainsi que tout le traffic montant et descendant, et gèrera également différents moyens externes pour communiquer avec: MQTT, API, etc… C’est lui qui sera interconnecté avec Home-Assistant par exemple pour récupérer les états de capteur (en général en MQTT). Dans le cas qui nous concerne pour la domotique, on utilisera soit les réseaux participatifs comme The Things Network (TTN) ou éventuellement Hélium. En effet, les réseaux commerciaux, typiquement ceux des opérateurs télécom, ne sont pas accessibles aux particuliers (Swisscom, en Suisse, par exemple ne donne pas d’accès à son réseau LoRa si vous n’êtes pas une entreprise référencée chez eux, idem pour Orange Business en France). Les réseaux participatifs sont basés sur un partage équitable des ressources. TTN fournit le serveur réseau et les utilisateurs mettent à disposition leurs passerelles ce qui permet de développer un réseau que tout le monde peut utiliser gratuitement. On y reviendra plus en détail dans un article séparé dédié à la mise en place d’un appareil Lora avec le réseau TTN et Home-Assistant.
  • Les serveurs d’application seront les services qui vont récupérer les infos reçus via le réseau LoRa à travers le serveur pour les exploiter. Home-Assistant, s’il est connecté à un serveur LoRa, peut quasiment s’assimiler à un serveur d’Applications. Cela peut être aussi une supervision pour récupérer et afficher les états de capteur.

 

Conclusion:

• • Le LoRa est parfaitement adapté à la récupération d’informations de capteurs distants (voire très distants) avec un réseau assez simple à déployer. Les communications étant cryptés, les données ne sont pas exposées. La consommation pour transmettre étant assez ridicule, les capteurs peuvent fonctionner durant des années sur une simple pile.
  • Interfaçage simple avec des systèmes domotiques type Home-Assistant via MQTT ou une API. Cela fera l’objet d’un article ultérieur.
  • En revanche, cela ne remplace pas du Wifi ou un réseau mobile car la communication n’est ni en duplex ni symétrique ni à haut-débit.
  • Technologie très abordable et multitude de fabricants d’appareils LoRa ainsi que de passerelles, possibilité aisée de mettre en place son propre réseau LoRa.
  • Flexibilité d’installation des passerelles qui peuvent être alimentées par panneau solaire et disposer d’une simple connexion GSM 2G/3G pour communiquer avec le serveur.

PS: Cet article est également publié sur le portail HACF (La Communauté Francophone des Utilisateurs de Home-Assistant) sur cette page: (https://www.hacf.fr/lora-presentation/).