Capteurs industriels sans fil avec MQTT : Wi-Fi, LoRaWAN, WirelessHART et 5G privée

Les capteurs industriels sans fil permettent de mesurer la température, les vibrations, la pression et le niveau sur des équipements qui n'ont jamais été câblés, sans tirer de câble à travers une usine en fonctionnement. Dans ce guide, vous comparerez les quatre technologies radio entre lesquelles les ingénieurs d'usine choisissent réellement, comprendrez comment les données de chacune deviennent des messages MQTT, et exécuterez un petit bridge Python qui relaie les uplinks LoRaWAN dans une arborescence de topics structurée.

Pourquoi les capteurs sans fil s'imposent dans les projets de retrofit

Tirer un nouveau câble dans une usine, c'est rarement juste un câble. Cela implique chemins de câbles, gaines, permis de feu, fenêtres d'arrêt et parfois une certification pour zone dangereuse. Pour un seul point de mesure de vibration sur le ventilateur d'une tour de refroidissement, l'installation peut coûter bien plus que le capteur.

Les capteurs sans fil changent l'équation. Un capteur de vibration ou de température sur pile se fixe en quelques minutes avec un aimant ou un goujon, et il transmet pendant des années. La contrepartie : vous avez désormais un réseau radio à concevoir, et la portée, l'autonomie, la fréquence de mise à jour et la fiabilité dépendent toutes de la technologie choisie.

La bonne nouvelle, c'est que, quelle que soit la radio choisie, les données aboutissent au même endroit. Une passerelle ou un serveur réseau reçoit les paquets radio et les publie sur un broker MQTT, où tableaux de bord, historiens et outils d'analyse les récupèrent.

Comparaison des technologies de capteurs industriels sans fil

Capteurs Wi-Fi

Le Wi-Fi est l'option la plus familière et la seule où le capteur lui-même parle généralement MQTT directement. Un capteur à base d'ESP32 peut ouvrir une connexion TLS vers le broker et publier sans passerelle intermédiaire. L'inconvénient est la consommation : l'association Wi-Fi et les négociations TLS sont coûteuses, si bien que les capteurs Wi-Fi sur pile dorment longtemps ou exigent des changements de pile fréquents. La couverture Wi-Fi industrielle est aussi souvent inégale autour des structures métalliques. Si vous construisez vos propres capteurs, notre tutoriel ESP32 MQTT couvre la partie firmware.

Capteurs LoRaWAN

LoRaWAN échange de la bande passante contre de la portée et de l'autonomie. Les payloads sont minuscules, souvent une douzaine d'octets, et les règles régionales de duty cycle limitent la fréquence d'émission d'un appareil. Les capteurs envoient des uplinks aux passerelles, les passerelles les transmettent à un serveur réseau comme ChirpStack ou The Things Stack, et le serveur réseau décode le payload et l'expose, très souvent via MQTT. LoRaWAN est idéal pour des valeurs qui évoluent lentement sur de grands sites : niveaux de cuves, conditions ambiantes, compteurs d'eau et pompes isolées.

WirelessHART et ISA100

Ces normes ont été conçues pour les usines de procédé. Elles forment des maillages auto-réparants, utilisent le saut de canal synchronisé dans le temps et transportent le modèle d'équipement HART, si bien qu'un transmetteur de pression sans fil apparaît au système de contrôle presque comme un transmetteur câblé. Les données arrivent normalement sur une passerelle sans fil dotée d'interfaces Modbus TCP, OPC UA ou HART-IP. Pour les faire entrer dans MQTT, on ajoute une passerelle de protocole, comme pour n'importe quel autre bus de terrain.

5G et LTE privées

Les réseaux cellulaires privés excellent lorsque vous avez besoin de mobilité, de forte densité ou d'une couverture déterministe sur un grand campus : robots mobiles, AGV, grues et terminaux portables. Les appareils obtiennent une connectivité IP et peuvent exécuter des clients MQTT directement, exactement comme sur un réseau cellulaire public. Les questions de coût et de spectre sont importantes : la 5G privée arrive donc généralement dans le cadre d'un projet de site plus large plutôt que pour une poignée de capteurs. Le comportement de connexion est similaire à celui de MQTT sur réseau cellulaire, y compris la nécessité de valeurs de keepalive raisonnables.

Comment les données des capteurs sans fil atteignent le broker

Il existe trois voies d'intégration, et la plupart des usines finissent par en utiliser plusieurs :

1. MQTT direct depuis l'appareil. Les capteurs Wi-Fi et cellulaires publient directement vers le broker via TLS. Simple, mais chaque appareil a besoin d'identifiants et d'assez d'énergie pour TLS.
2. Du serveur réseau vers MQTT. Les serveurs réseau LoRaWAN publient les uplinks décodés sur leur propre broker MQTT ou intégration. Un petit bridge les republie dans votre arborescence de topics d'usine.
3. Passerelle plus convertisseur de protocole. WirelessHART, ISA100 et de nombreux systèmes sans fil propriétaires exposent Modbus ou OPC UA au niveau de la passerelle. Une passerelle edge IIoT interroge cette interface et publie en MQTT.

La décision de conception importante n'est pas la radio mais la structure des topics. Quelle que soit la source, normalisez tout dans une seule hiérarchie, par exemple connectmq/site/area/asset/measurement, pour que les consommateurs, des tableaux de bord jusqu'à un éventuel jumeau numérique de l'usine, n'aient jamais besoin de savoir de quelle radio provient une valeur.

Exemple : relayer les uplinks LoRaWAN dans votre arborescence de topics

Le script ci-dessous s'abonne aux événements d'uplink de ChirpStack v4 sur le broker du serveur réseau et republie les valeurs décodées dans une arborescence de type ISA-95 sur le serveur MQTT public gratuit de ConnectMQ. ChirpStack publie les uplinks sur application/<application_id>/device/<dev_eui>/event/up en JSON, avec les valeurs décodées dans le champ object lorsqu'un codec de payload est configuré.

import json
import uuid
import paho.mqtt.client as mqtt

# Source : intégration MQTT de ChirpStack (ajustez l'hôte et les identifiants)
SRC_HOST = "chirpstack.local"
SRC_TOPIC = "application/+/device/+/event/up"

# Destination : broker de test public ConnectMQ, préfixe de démo unique
DST_HOST = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/site1/utilities"

# Associer les EUI des appareils aux noms d'équipements de votre hiérarchie
ASSETS = {
    "a84041000181c061": "tank-farm/tank03",
    "a84041000181c062": "cooling/fan02",
}

dst = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                  client_id=f"lora-bridge-dst-{uuid.uuid4().hex[:6]}")
dst.connect(DST_HOST, 1883, keepalive=60)
dst.loop_start()

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected to ChirpStack:", reason_code)
    client.subscribe(SRC_TOPIC, qos=1)

def on_message(client, userdata, msg):
    event = json.loads(msg.payload)
    dev_eui = event["deviceInfo"]["devEui"]
    values = event.get("object")
    if not values:
        return  # pas de codec configuré, rien à relayer
    asset = ASSETS.get(dev_eui, f"unmapped/{dev_eui}")
    rx = (event.get("rxInfo") or [{}])[0]
    for name, value in values.items():
        payload = {
            "value": value,
            "ts": event.get("time"),
            "rssi": rx.get("rssi"),
            "snr": rx.get("snr"),
        }
        topic = f"{PREFIX}/{asset}/{name}"
        dst.publish(topic, json.dumps(payload), qos=1, retain=True)
        print(topic, payload)

src = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                  client_id=f"lora-bridge-src-{uuid.uuid4().hex[:6]}")
src.on_connect = on_connect
src.on_message = on_message
src.connect(SRC_HOST, 1883, keepalive=60)
src.loop_forever()

Observez la sortie depuis un autre terminal :

mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-$RANDOM \
  -t 'connectmq/demo/+/site1/#' -v

Quelques détails méritent d'être repris en production. Les messages sont retenus : un nouveau tableau de bord voit immédiatement le dernier niveau de cuve au lieu d'attendre le prochain uplink, qui peut survenir quinze minutes plus tard en LoRaWAN. La qualité radio (RSSI et SNR) accompagne chaque valeur, ce qui permet de repérer facilement un capteur dont l'antenne a été heurtée. Enfin, les appareils inconnus arrivent sous unmapped/ : ils apparaissent au lieu de disparaître silencieusement. En production, passez la destination sur le port 8883 avec TLS et vos identifiants ConnectMQ, et réservez le serveur MQTT public gratuit aux tests, puisque tout ce qui s'y trouve est lisible par tous.

Conseils pratiques pour déployer des capteurs sans fil

• Faites un relevé radio avant d'acheter. Parcourez le site avec une passerelle ou un point d'accès de test. Cuves en acier, béton et machines en mouvement modifient considérablement la couverture.
• Adaptez la fréquence de mise à jour à la physique. Un niveau de cuve qui évolue sur plusieurs heures n'a pas besoin de mises à jour à la seconde. Des fréquences plus lentes allongent l'autonomie.
• Publiez par exception au niveau de la passerelle. Ne relayez une valeur que lorsqu'elle change de manière significative, et utilisez des retained messages pour l'état courant. Notre guide du report by exception explique les seuils.
• Surveillez les capteurs, pas seulement le procédé. La tension de la pile, l'heure de dernière réception et la force du signal méritent leurs propres topics et règles d'alerte.
• Prévoyez les trous. Les liaisons sans fil décrochent. Les consommateurs doivent traiter un horodatage périmé comme une donnée manquante plutôt que comme la dernière valeur connue.

Un broker qui accueille toutes les radios

Comme toutes les technologies radio convergent vers MQTT, le broker devient la pièce dont dépendent toutes les équipes. Un broker MQTT managé comme ConnectMQ vous offre des points de connexion TLS, un explorateur de topics en direct pour vérifier que chaque capteur arrive au bon endroit, et des règles d'alerte à seuil pour des valeurs comme une pile faible ou des vibrations élevées. Sa vue des équipements regroupe les topics par niveaux ISA-95, un moyen pratique de vérifier que les données LoRaWAN, Wi-Fi et WirelessHART suivent toutes la même hiérarchie. Pour le contexte général, lisez le guide de l'IoT industriel avec MQTT.

Connectez vos capteurs sans fil à ConnectMQ

Inscrivez-vous sur app.connectmq.com et créez un broker Serverless gratuit, sans carte bancaire. Pointez-y votre bridge ou votre passerelle avec les identifiants générés, puis utilisez l'explorateur de topics en direct et le tableau de bord de ConnectMQ pour voir les données de vos capteurs sans fil arriver dans un espace de noms structuré unique.

Questions fréquentes

Quelle technologie sans fil choisir pour des capteurs industriels ?

Tout dépend de l'usage. LoRaWAN convient aux valeurs qui évoluent lentement sur de longues distances et sur pile, WirelessHART à l'instrumentation de procédé en réseau maillé, le Wi-Fi aux appareils sur secteur ou à haute fréquence, et la 5G privée aux équipements mobiles et aux campus denses.

Les capteurs LoRaWAN peuvent-ils publier en MQTT directement ?

Non. Les appareils LoRaWAN envoient de petits paquets radio aux passerelles, et le serveur réseau les décode. C'est ensuite le serveur réseau, ou un bridge comme celui de ce guide, qui publie les valeurs décodées via MQTT.

Comment faire entrer les données WirelessHART dans MQTT ?

Les passerelles WirelessHART exposent généralement Modbus TCP, OPC UA ou HART-IP. Une passerelle edge interroge cette interface et publie les valeurs sur votre broker MQTT.

Les valeurs des capteurs sans fil doivent-elles être des retained messages ?

En général oui pour les valeurs d'état courant comme les niveaux et les températures, car les nouveaux abonnés reçoivent immédiatement la dernière valeur. Ne retenez pas les messages de type événement, comme les alarmes, qui ne doivent être vus qu'une fois.