Intégrer des capteurs LoRaWAN dans une GTB BACnet ou Modbus

Les capteurs LoRaWAN permettent d'instrumenter un bâtiment existant sans tirer de câble : température de zone, CO2, présence, comptage, fuite d'eau. Mais la GTB, elle, parle BACnet ou Modbus. Entre les deux, il faut une couche d'intégration qui décode les trames radio et les présente sous forme de points exploitables par l'automate ou le superviseur.

Ce guide compare les trois architectures les plus courantes, avec leurs avantages, leurs limites et les étapes de mise en service.

Le principe : du payload radio au point GTB

Un capteur LoRaWAN émet une trame binaire compacte, le payload. Pour l'exploiter, trois opérations sont nécessaires :

1. réception radio par une ou plusieurs passerelles ;
2. gestion du réseau par un serveur LoRaWAN (LNS) : authentification des capteurs, déchiffrement, déduplication ;
3. décodage du payload en grandeurs physiques (température en °C, CO2 en ppm, état d'un contact), puis publication vers la GTB dans un protocole qu'elle comprend.

Selon l'architecture, ces opérations sont regroupées dans une seule passerelle ou réparties entre plusieurs briques.

Architecture 1 : la passerelle LoRaWAN qui parle BACnet et Modbus

C'est l'architecture la plus directe. La passerelle embarque le serveur de réseau, décode les capteurs et publie les mesures en BACnet/IP ou Modbus TCP sur le réseau de la GTB.

Les passerelles Milesight UG56, UG65 et UG67 fonctionnent ainsi : leur serveur embarqué décode les capteurs Milesight grâce à une bibliothèque de codecs intégrée, accepte des codecs personnalisés pour les autres marques, et expose les points en BACnet/IP, BACnet/SC ou Modbus TCP. Le superviseur lit alors chaque capteur comme un équipement BACnet ou une table de registres Modbus.

La Milesight EG71 ajoute des interfaces filaires (RS-485, KNX, M-Bus), des entrées et sorties, et remonte le tout en BACnet/IP, Modbus TCP, MQTT ou HTTP. Elle convient aux locaux techniques où cohabitent compteurs filaires et capteurs radio.

Points forts : pas de serveur supplémentaire, fonctionnement autonome sur site, mise en service rapide pour un bâtiment.

Limites : la configuration des points est propre à chaque passerelle ; sur un grand site couvert par plusieurs passerelles, il faut organiser le réseau autour d'une passerelle maître. Milesight propose pour cela une fonction Gateway Fleet, qui permet à une passerelle de servir de serveur de réseau à d'autres passerelles Milesight d'appoint.

Architecture 2 : la passerelle LoRaWAN esclave Modbus

Certaines GTB ou automates ne savent lire que du Modbus, parfois uniquement en RTU sur RS-485. Le Dragino MS48-LR répond à ce cas : il intègre ChirpStack et Node-RED, et expose les capteurs sans fil comme un esclave Modbus RTU (RS-485) ou Modbus TCP. L'automate interroge la passerelle comme il interrogerait n'importe quel équipement Modbus.

Pour les capteurs Enless, qui utilisent le protocole radio LoRa Easy, les récepteurs dédiés jouent le même rôle : l'Enless RX MODBUS décode nativement jusqu'à 50 capteurs dans une table Modbus TCP et RTU, et l'Enless RX BACnet les publie en BACnet/IP et BACnet MS/TP.

Points forts : compatibilité avec des automates anciens, table de registres fixe et documentée.

Limites : les tables Modbus ne portent ni unité ni description : la documentation du mapping est indispensable.

Architecture 3 : serveur de réseau, MQTT et intégration logicielle

Sur un parc multisite ou un projet piloté par une plateforme IoT, les passerelles fonctionnent en simple relais (packet forwarder ou Basic Station) vers un serveur de réseau centralisé : ChirpStack, The Things Network, LORIOT ou Actility. Le serveur publie les données décodées en MQTT ou HTTP, et une brique logicielle (superviseur, hyperviseur, driver de GTB) les consomme.

Points forts : une seule configuration pour tout le parc, ajout de passerelles sans reconfiguration, historisation centralisée.

Limites : dépendance au réseau et au serveur central, compétences logicielles nécessaires, et une GTB qui doit savoir consommer du MQTT ou passer par un connecteur.

Comparatif des trois architectures

Critère	Passerelle BACnet / Modbus TCP	Passerelle esclave Modbus	Serveur réseau et MQTT
Taille de site idéale	Un bâtiment	Un bâtiment ou un local	Parc multisite
Serveur supplémentaire	Non	Non	Oui
Protocole côté GTB	BACnet/IP, BACnet/SC, Modbus TCP	Modbus RTU ou TCP	MQTT, HTTP, connecteur
Exemple	Milesight UG56, UG65	Dragino MS48-LR, Enless RX	Passerelles en packet forwarder

BACnet ou Modbus côté GTB : que privilégier ?

Lorsque la passerelle propose les deux, le choix dépend surtout de la GTB et de la façon dont l'exploitant travaille.

BACnet/IP et BACnet/SC

BACnet décrit les données sous forme d'objets typés : une température devient un objet Analog Input avec un nom, une unité et un état. Le superviseur peut découvrir automatiquement les équipements et leurs objets, ce qui accélère l'intégration et limite les erreurs de saisie. BACnet/SC (Secure Connect) ajoute une communication chiffrée et authentifiée par certificats, utile lorsque le réseau de la GTB est partagé avec d'autres usages.

Modbus TCP

Modbus transporte des registres de 16 bits sans aucune description. Il est universel, simple à diagnostiquer et lu par pratiquement tous les automates, mais chaque point doit être saisi à la main avec son adresse, son type (entier, flottant sur deux registres), son ordre d'octets et son facteur d'échelle. Sur quelques dizaines de points, c'est très gérable ; sur plusieurs centaines, une table de correspondance soignée devient indispensable.

Le cas MQTT

MQTT n'est pas un protocole de GTB à proprement parler, mais de plus en plus de superviseurs et d'hyperviseurs savent s'abonner à un broker. Il convient bien aux remontées vers une plateforme d'analyse énergétique ou un outil de maintenance, en parallèle de la GTB.

Dimensionner l'installation

• Nombre de passerelles : une passerelle bien placée couvre souvent plusieurs niveaux d'un bâtiment tertiaire, mais les sous-sols, parkings et locaux techniques demandent parfois un point de réception supplémentaire.
• Fréquence des mesures : une remontée toutes les 10 minutes suffit pour la température ou le CO2 ; les alarmes (fuite, ouverture) sont émises sur événement.
• Nombre de points GTB : comptez chaque grandeur utile, pas chaque capteur. Un capteur d'ambiance qui mesure CO2, température, humidité et présence représente quatre points.

Le chemin inverse : remonter un équipement Modbus en LoRaWAN

Il arrive aussi qu'on veuille faire l'inverse : lire un compteur ou un automate Modbus situé dans un endroit difficile à câbler, et transmettre ses valeurs en radio. Les convertisseurs Modbus vers LoRaWAN servent à cela : le Milesight UC100 lit jusqu'à 32 registres sur un port RS-485 Modbus RTU, et le Dragino RS485 existe en LoRaWAN, NB-IoT, LTE-M ou LTE Cat 1, avec des versions autonomes sur pile. Voir la catégorie modules E/S et interfaces LoRaWAN.

Mise en service pas à pas

1. Inventorier les points : liste des capteurs, grandeurs utiles, fréquences d'émission, emplacement.
2. Valider la couverture radio depuis l'emplacement de la passerelle, surtout dans les sous-sols et les gaines techniques.
3. Enregistrer les capteurs sur le serveur de réseau (DevEUI, AppEUI ou JoinEUI, AppKey).
4. Vérifier le décodage sur des trames réelles. Notre testeur de décodeur LoRaWAN permet de tester les décodeurs officiels de nombreux capteurs directement dans le navigateur.
5. Construire le mapping : objets BACnet (type, instance, nom, unité) ou registres Modbus (adresse, type de donnée, facteur d'échelle).
6. Paramétrer la GTB et vérifier chaque point, y compris l'horodatage et le comportement en cas de capteur muet.
7. Documenter l'ensemble pour l'exploitant.

Questions fréquentes

Un projet d'intégration à étudier ?

Envoyez-nous la liste de vos points et le modèle de votre GTB : nous vous proposons l'architecture la plus simple, avec une réponse sous 24 h ouvrées. Consultez aussi les passerelles BACnet du catalogue ou contactez-nous.