WiFi ou LoRaWAN : quel réseau pour un capteur industriel

La réponse courte, avant les nuances

Sur un site de production, notre réponse par défaut n’est pas le WiFi. Les mesures passent par le réseau LoRaWAN, et il faut un contexte particulier pour que nous en changions.

C’est une position, et elle mérite son motif. La question « LoRaWAN ou WiFi » est presque toujours posée comme un arbitrage entre deux technologies sans fil concurrentes : portée contre débit, consommation contre latence. Ce comparatif a son intérêt, et nous l’avons déjà fait dans l’article sur les quatre types de réseaux IoT, qui explique pourquoi le WiFi n’a pas été conçu pour des capteurs sur batterie dispersés dans un hall.

Mais quand on installe pour de vrai, ce ne sont pas les spécifications qui décident. Ce sont deux questions plus terre à terre : quel matériel existe réellement pour ce que je veux mesurer, et qui contrôle le réseau qui le porte.

Ce qui tranche d’abord, c’est le matériel disponible

En LoRaWAN, le catalogue est large. Température, hygrométrie, luminosité, comptage d’impulsions, etc. Ce sont des produits industriels : indice de protection adapté à l’environnement, autonomie de plusieurs années sur batterie, boîtier prévu pour l’armoire ou pour l’extérieur, fabricant identifié, documentation, remplacement à l’identique. Sur à peu près tout ce qu’un industriel veut mesurer, il existe un device dont c’est le métier.

Il existe aussi des devices WiFi professionnels, ce serait faux de prétendre le contraire, et nous utilisons le WiFi. Ce qui distingue le LoRaWAN, c’est qu’il a été conçu pour cet usage précis. C’est un réseau industriel, pensé dès l’origine pour des équipements autonomes, dispersés sur un site, parfois installés à des endroits où personne ne retournera avant longtemps. Le catalogue a suivi cette logique, et c’est ce qui fait qu’on y trouve presque toujours le device qui correspond au besoin.

Il nous arrive aussi de concevoir nos propres cartes, quand la demande d’un client ne trouve pas sa réponse dans le commerce. C’est de la R&D et du sur mesure, pas une offre de catalogue, et cela se fait aussi bien en LoRaWAN qu’en WiFi ou en Ethernet. Notre Device V02 est fabriqué chez Finemeca sur ce principe.

Ce que nous voyons en LoRaWAN, et que le WiFi ne montre pas

C’est le point que je défends le plus volontiers en rendez-vous, et celui qu’on oublie systématiquement dans les comparatifs.

En LoRaWAN, chaque message qui arrive porte deux indicateurs sur la liaison qui l’a transporté : le RSSI, la puissance du signal reçu, et le SNR, sa lisibilité par rapport au bruit ambiant. Ces deux valeurs vous disent si un device est confortable ou s’il est à la limite. Vous voyez une liaison se dégrader avant qu’elle ne tombe : une machine déplacée devant un device, une porte métallique qui reste fermée, une antenne qui a bougé. Et vous pouvez agir sur des choses concrètes, remonter une gateway, la décaler vers le centre du site, en ajouter une seconde.

Nous surveillons les gateways en permanence. Celle qui cesse de répondre déclenche une alerte, ce qui nous permet de prévenir un client avant qu’il ne s’aperçoive lui-même du trou dans son dashboard.

Le WiFi n’interdit pas toute surveillance, et il serait malhonnête de le prétendre. Un équipement qui remonte vers une GTB, vers Home Assistant ou vers un serveur en MQTT peut parfaitement déclencher une alerte s’il n’a plus rien dit depuis vingt-quatre heures. Nous le faisons nous-mêmes lorsqu’un Raspberry Pi remonte ses mesures vers notre infrastructure.

La différence est ailleurs. Cette surveillance constate une absence, elle ne mesure pas une marge. Elle vous dit que le device est tombé, pas qu’il allait tomber. Et quand la cause est un point d’accès saturé, un canal encombré par le voisinage, une mise à jour de contrôleur, une clé changée ou une reconfiguration décidée un vendredi soir, elle reste hors de votre main. Le réseau appartient à quelqu’un d’autre, et personne ne vous préviendra avant d’y toucher.

Voilà la vraie frontière. Elle n’est pas entre deux technologies sans fil, elle est entre un réseau que vous exploitez et un réseau que vous subissez.

Premier endroit où le WiFi existe quand même chez nous : la gateway

Il serait facile de s’arrêter là et de laisser croire que le WiFi n’entre jamais chez nous. C’est faux, et le dire vaut mieux que le cacher.

Le premier cas est le raccordement d’une gateway quand aucun Ethernet n’est disponible. Nous l’avons vécu sur un site où la gateway a démarré en WiFi faute de mieux. La liaison s’est révélée instable, et nous ne pouvions rien y faire puisque ce réseau est géré par l’entreprise. Or une gateway instable, ce sont des devices injoignables et des données qui risquent de ne jamais arriver. Le client a fini par tirer un câble Ethernet, raccordé à un VLAN séparé du reste de son réseau, et la question ne s’est plus jamais posée.

Le WiFi reste donc possible pour ce raccordement. C’est un compromis assumé, pas un choix d’architecture.

Second endroit : la GTB et la domotique, où le contexte change tout

Le second cas sort du cadre industriel. Sur les projets de gestion technique de bâtiment et de domotique, nous travaillons avec du matériel professionnel, comme partout ailleurs. Le WiFi y a naturellement sa place, puisque les équipements sont alimentés et que le bâtiment est couvert par un réseau dimensionné pour ses occupants.

Il arrive pourtant qu’aucun produit du commerce ne réponde au besoin, et c’est souvent à ce moment qu’on nous appelle. La commande d’un poêle à pellets par son port série. La lecture d’un compteur de gaz pour lequel il n’existe aucun module d’impulsion. Ce sont des demandes auxquelles beaucoup d’intégrateurs répondent que ça ne se fait pas. Nous sommes capables de développer nous-mêmes l’équipement manquant, sur base d’un ESP32 programmé via ESPHome, d’un Raspberry Pi ou d’une carte Arduino, et de l’intégrer au reste de l’installation.

Le contexte fait tout. Dans un bâtiment tertiaire ou dans une maison, un WiFi de qualité est déjà une exigence pour l’usage des locaux : la couverture est dimensionnée, entretenue, et une dégradation se remarque tout de suite. Sur un site de production, rien de tout cela n’est acquis, et une bonne partie des points de mesure sont hors de portée du réseau existant.

Quant aux coupures, elles nous échappent dans les deux cas, mais elles ne coûtent pas la même chose. Une heure manquante sur la température d’un séjour ne dérange personne. Une heure manquante sur la consommation d’un atelier peut fausser une décision d’investissement. Acceptable en tertiaire et en domotique, pas en monitoring industriel.

Nous ne vendons pas une technologie, nous regardons l’usage

Il serait dommage de refermer cet article sur l’idée que Finemeca fait du LoRaWAN et rien d’autre. C’est faux, et l’étiquette nous dessert.

Sur des projets de gestion technique de bâtiment, il nous arrive de ne déployer aucun device LoRaWAN, parce que le Zigbee ou le WiFi répondaient mieux à l’usage et au bâti. Pour les installations critiques, les environnements à fortes interférences électromagnétiques ou les applications qui déplacent beaucoup de données, nous déployons du filaire. Et très souvent, la réponse la plus pragmatique est une combinaison de plusieurs technologies selon les zones.

Le nombre de points à mesurer compte aussi. Un réseau LoRaWAN privé est une infrastructure : gateway, étude de couverture, serveur de réseau, supervision. C’est ce qui le rend robuste, et c’est aussi ce qui le rend disproportionné quand il n’y a rien d’autre à suivre qu’un compteur d’eau et un compteur électrique dans un bâtiment isolé. Les alternatives qui se passent de gateway méritent alors l’examen : un device NB-IoT, un device muni de sa propre carte 4G, ou un device WiFi si le bâtiment est bien couvert. Chaque device porte alors son propre abonnement. Sur un ou deux points c’est supportable, sur trente l’addition devient le poste principal et l’infrastructure privée redevient la réponse évidente.

On nous demande d’ailleurs parfois si le WiFi déjà en place ne suffirait pas, quand il s’agit d’un vrai réseau professionnel, dimensionné pour la production, celui qui fait par exemple tourner les douchettes code-barres d’un atelier. La question est légitime et nous ne la balayons pas. Elle se referme presque toujours sur les mêmes constats : les points de mesure sont rarement là où le WiFi porte, les produits WiFi du commerce ne sont pas toujours conçus pour ce type de mesure, et la maîtrise du réseau nous échappe de toute façon. Dans les ateliers de ce type où nous sommes intervenus, y compris bien couverts, c’est le LoRaWAN que nous avons installé.

Un prospect en gestion technique de bâtiment nous a demandé un jour ce que nous apportions par rapport à une solution industrielle établie. La réponse tient en un mot : l’accès. Le LoRaWAN va chercher une mesure au fond d’une cave, dans un local sans câble ni prise, à l’autre bout d’un site, sur un point que personne n’a envie de raccorder. C’est là qu’il n’a pas de concurrent sérieux, et c’est pour ça que nous le sortons en premier sur un site industriel.

Avant toute chose, une étude de réseau

C’est pour cette raison que nous commençons toujours par une étude de réseau, quelle que soit l’installation. Elle nous dit ce que le bâtiment permet, où le signal passe et où il ne passe pas, ce qui existe déjà et ce qu’il faudrait ajouter.

C’est elle qui détermine la solution que nous proposons au client, et non l’inverse. Ce n’est pas la technologie qui est en cause, c’est l’usage qu’on veut lui faire porter.