Gateway multi-protocoles¶

Une gateway industrielle réconcilie en un point unique des protocoles incompatibles : Zigbee, LoRa, BLE, Modbus — et les expose en MQTT ou HTTP vers le reste de l'infrastructure.

Le problème de la tour de Babel protocolaire¶

Un site industriel typique héberge simultanément des dizaines de protocoles hétérogènes. Les capteurs de mesure utilisent Modbus RTU sur RS-485. Les détecteurs de présence sans fil parlent Zigbee 3.0. Les balises de localisation d'assets tournent en BLE 5.1. Les stations météo distantes transmettent en LoRaWAN. Les automates parlent PROFINET ou EtherNet/IP.

Chacun de ces protocoles existe pour de bonnes raisons : optimisation de la consommation énergétique, portée, débit, robustesse aux interférences, coût des modules. Aucun protocole unique ne couvre tous les cas d'usage.

La gateway multi-protocoles est le nœud qui réconcilie cet écosystème. Elle parle simultanément plusieurs langues "côté terrain" (southbound) et expose une interface unifiée "côté infrastructure" (northbound).

Architecture northbound / southbound¶

Le découpage fondamental d'une gateway est la séparation entre les interfaces orientées terrain et les interfaces orientées infrastructure.

graph TB
    subgraph Terrain ["Southbound — Terrain"]
        Z[Capteurs Zigbee\n2.4 GHz, IEEE 802.15.4]
        L[Noeuds LoRa\n868 MHz, longue portée]
        B[Balises BLE\nBluetooth 5.1 CODED]
        M[Automates Modbus RTU\nRS-485, 9600–115200 bps]
        W[Compteurs M-Bus\nWired, 2400 bps]
    end

    subgraph GW ["Gateway — Couche de traduction"]
        ZB[Stack Zigbee\nCoordinator CC2652]
        LR[Stack LoRa\nSX1276 + chirpstack]
        BT[Stack BLE\nhci0 + gatttool]
        MB[Stack Modbus\nlibmodbus]
        MBU[Stack M-Bus\nmbus-serial]

        CORE[Moteur de traduction\nNode-RED / Python]
        BUFF[Buffer local\nSQLite / Redis]
        FILT[Filtrage &\nagrégation]
    end

    subgraph Cloud ["Northbound — Infrastructure"]
        MQTT[Broker MQTT\nMosquitto / EMQX]
        HTTP[API REST\nHTTP/HTTPS]
        AMQP[Message queue\nRabbitMQ / Kafka]
        TSDB[Time-series DB\nInfluxDB / TimescaleDB]
    end

    Z --> ZB
    L --> LR
    B --> BT
    M --> MB
    W --> MBU

    ZB --> CORE
    LR --> CORE
    BT --> CORE
    MB --> CORE
    MBU --> CORE

    CORE --> BUFF
    CORE --> FILT
    FILT --> MQTT
    FILT --> HTTP
    FILT --> AMQP
    BUFF --> TSDB

Les bridges protocole par protocole¶

Zigbee → MQTT (zigbee2mqtt)¶

Zigbee est le protocole dominant pour la domotique industrielle et les bâtiments intelligents. La pile Zigbee 3.0 supporte jusqu'à 65 000 devices par réseau maillé, avec des consommations de l'ordre de 1 mA en actif et quelques µA en veille.

Le bridge zigbee2mqtt est de loin la solution la plus utilisée en production. Il s'appuie sur un coordinateur USB (Texas Instruments CC2652P ou SONOFF Zigbee 3.0 Dongle Plus) et expose chaque device Zigbee comme un topic MQTT.

Un thermostat Zigbee devient ainsi :

zigbee2mqtt/salon/temperature → {"temperature": 21.4, "humidity": 58, "battery": 87}
zigbee2mqtt/salon/set → {"occupied_heating_setpoint": 20}

Plus de 3 000 devices sont supportés nativement. La configuration se fait via un fichier YAML et une interface web intégrée.

LoRa / LoRaWAN → IP (ChirpStack)¶

LoRaWAN est conçu pour les longue portées (1 à 15 km selon l'environnement) avec des débits faibles (250 bps à 50 kbps) et une consommation très réduite — ce qui en fait le protocole privilégié pour les capteurs outdoor ou difficiles d'accès.

ChirpStack est le network server LoRaWAN open-source de référence. La gateway physique (Semtech SX1302, RAK7268) transmet les trames radio au network server via le protocole Semtech UDP Packet Forwarder. ChirpStack gère l'ADR (Adaptive Data Rate), le join OTAA/ABP, et expose les données en MQTT ou HTTP.

# Topic MQTT ChirpStack v4
application/[app_id]/device/[dev_eui]/event/up
→ payload JSON avec données déchiffrées + métadonnées radio (RSSI, SNR, SF utilisé)

BLE → MQTT¶

Le BLE (Bluetooth Low Energy) couvre typiquement 10 à 100 m selon la puissance d'émission et les obstacles. Il est très utilisé pour les balises de localisation (iBeacon, Eddystone), les capteurs portables, les équipements de laboratoire.

La translation BLE → MQTT se fait en deux étapes sur le gateway :

1. Scan passif : le dongle BLE (hci0) scanne les advertisings périodiques sans établir de connexion. Adapté aux balises de présence/localisation.
2. Connexion GATT : connexion directe au device pour lire/écrire des caractéristiques. Adapté aux capteurs avec notifications.

En Python, la bibliothèque Bleak (asyncio, cross-platform) est le standard actuel :

import asyncio
from bleak import BleakScanner, BleakClient
import paho.mqtt.client as mqtt

# UUID de la caractéristique de température (exemple standard BLE SIG)
TEMP_CHAR_UUID = "00002a6e-0000-1000-8000-00805f9b34fb"

async def read_ble_sensor(address: str, mqtt_client: mqtt.Client):
    async with BleakClient(address) as client:
        raw = await client.read_gatt_char(TEMP_CHAR_UUID)
        temp = int.from_bytes(raw, "little", signed=True) / 100.0
        mqtt_client.publish(f"ble/{address}/temperature",
                            f'{{"value": {temp}}}', qos=1)

Modbus RTU → MQTT¶

Modbus RTU sur RS-485 est le protocole industriel le plus répandu pour les automates, compteurs d'énergie, variateurs de fréquence, capteurs de process. Inventé en 1979, il équipe encore des centaines de millions de devices en service.

La translation se fait via polling cyclique : le gateway interroge régulièrement chaque esclave et publie les registres modifiés.

from pymodbus.client import ModbusSerialClient

client = ModbusSerialClient(port="/dev/ttyUSB0", baudrate=9600,
                            parity="N", stopbits=1, bytesize=8)
client.connect()

# Lecture des registres 0-9 de l'esclave 1 (holding registers)
result = client.read_holding_registers(address=0, count=10, slave=1)
if not result.isError():
    registers = result.registers
    # Conversion selon documentation du device
    temperature = registers[0] / 10.0    # ex. 215 → 21.5 °C
    pressure    = registers[1] / 100.0   # ex. 1013 → 10.13 bar

Buffering et store-and-forward¶

La connectivité northbound n'est jamais garantie à 100 %. Pannes réseau, maintenance, saturation du broker — la gateway doit absorber ces discontinuités sans perdre de données.

Le pattern store-and-forward stocke les messages localement et les retransmet par ordre chronologique dès que la connexion est rétablie.

sequenceDiagram
    participant C as Capteur terrain
    participant G as Gateway
    participant B as Buffer local (SQLite)
    participant M as Broker MQTT

    C->>G: Mesure toutes les 30 s
    G->>M: Publish (connexion OK)
    Note over M: Réseau tombe

    C->>G: Mesure #47
    G->>B: Store localement (offline)
    C->>G: Mesure #48
    G->>B: Store localement (offline)
    Note over M: Réseau revient

    G->>B: Read messages en attente
    G->>M: Publish #47 (MQTT QoS 1)
    M-->>G: PUBACK
    G->>M: Publish #48 (MQTT QoS 1)
    M-->>G: PUBACK
    G->>B: Delete messages acquittés

Dimensionnement du buffer¶

Le buffer doit être dimensionné pour la pire durée de déconnexion tolérée. À 100 messages/s et un message JSON de 200 octets, une coupure de 24 h représente :

100 × 86 400 × 200 = 1,73 GB

Pour les gateways industrielles, un SSD de 32 GB avec rotation automatique (suppression des plus anciens au-delà d'une retention de 7 jours) est un dimensionnement courant.

Tableau comparatif des bridges southbound¶

Ce qu'il faut retenir¶

• La gateway est le nœud central qui traduit les protocoles terrain (southbound) en interfaces infrastructure standardisées (northbound).
• Le buffering store-and-forward est indispensable pour garantir zéro perte de données lors des coupures réseau.
• zigbee2mqtt, ChirpStack et pymodbus sont les bridges open-source les plus matures pour les déploiements industriels.
• Le découplage northbound/southbound permet de remplacer un protocole terrain sans toucher à l'infrastructure cloud.

Chapitre suivant : Gateway sur Raspberry Pi — implémenter concrètement une gateway de terrain avec Mosquitto, zigbee2mqtt et Node-RED.