Sommaire
LoRa ou LoraWAN, vous en avez peut-être déjà entendu parler ou pas encore ?
Voici l'occasion de faire un point sur cette techno d'apparence simple, mais qui peut faire de grandes choses et résoudre 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 forts et points faibles de la technologie.
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.
Origine de LoRa
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. Aujourd'hui tous les appareils implémentant du LoRa ont une puce Semtech en leur cœur. 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 publics, 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.
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 trafic de données ininterrompu).
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.
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êmement asymétrique dans son trafic, 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 trafic 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, le compteur de messages sur ma passerelle indique à peine 15 messages descendants du réseau vers les appareils pour 3 237 messages montants, 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 un voyant que j'utilise dans une salle de conférence 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 sûrs 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ème majeur 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 (TTN) ou encore Helium Network.
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).
Les appareils
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éjà évoqué précédemment, les messages seront quasiment uniquement envoyés 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 (Dwonlink) 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 énergie. 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
- 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) :
Exemple de devices LoRa
Les passerelles
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, voir un modem analogique, car le trafic généré est assez ridicule.
La passerelle peut tourner sur un simple 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 une borne SenseCAP M2) ou bien une solution robuste pour l'extérieur comme ce genre de choses, à droite ci-dessous (RakWireless 8/16 Channel Outdoor LoRaWAN Gateway).
Différents types de gateways
Le serveur LoRa
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, voir 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 toutes 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 publics 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 trafic 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 Helium Network.
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.
Les serveurs d'application
Les serveurs d'application seront les services qui vont récupérer les infos reçues 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. Il peut aussi avoir un rôle de supervision pour récupérer et afficher les états de capteur.
Conclusion
- 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.
Cet article est également publié sur mon blog.
Vincèn PUJOL
