Intégration MQTT

Eziwan inclut un client MQTT natif qui publie les données terrain (capteurs RS485, métriques réseau, événements) vers n'importe quel broker MQTT — cloud ou on-premise.

Brokers compatibles

Broker	Type	Notes
Eziwan MQTT	Managé (inclus)	`mqtt.eziwan.com:8883` — TLS, zéro config
Mosquitto	Self-hosted	Open-source — à héberger
HiveMQ	Cloud / On-premise	Enterprise
EMQX	Cloud / On-premise	Haute performance
AWS IoT Core	Cloud	Intégration Lambda, S3
Azure IoT Hub	Cloud	Intégration Azure Stream Analytics
Google Cloud IoT	Cloud	Intégration Pub/Sub
Scaleway IoT Hub	Cloud	Hébergé en France

Configuration broker

Via le dashboard Eziwan

Dispositif → Configuration → MQTT

Interface graphique pour configurer le broker, les credentials et les topics.

Configuration YAML

mqtt:
  enabled: true
  broker: "mqtt.eziwan.com"
  port: 8883
  tls: true
  client_id: "GW-Paris-01"

  # Auth — token disponible dans dashboard → Paramètres → MQTT
  username: "np_device"
  password: "np_mqtt_xxxxxxxxxx"

  # Qualité de service
  keepalive: 60
  qos: 1
  retain: false

  # Reconnexion automatique
  reconnect_delay_min: 1
  reconnect_delay_max: 60

  # Buffering si connexion perdue
  offline_buffer: true
  offline_buffer_size: 10000  # messages
  offline_buffer_ttl: 3600    # secondes

Buffering hors ligne

Si la connexion LTE est momentanément interrompue, Eziwan bufferise les messages MQTT localement (jusqu'à offline_buffer_size messages) et les publie automatiquement à la reconnexion. Les données ne sont jamais perdues.

Structure des topics

Données capteurs RS485 / Modbus

eziwan/{device_id}/modbus/{slave_id}/{tag_name}

Exemple :
eziwan/d_a1b2c3d4/modbus/1/active_power
eziwan/d_a1b2c3d4/modbus/2/temperature

Vous pouvez aussi définir des topics personnalisés par registre dans la config Modbus :

mqtt_topic: "usine/paris/energie/compteur-01/puissance"

Métriques système (publiées automatiquement)

Topic	Description	Intervalle
`.../system/rsrp`	Signal RSRP LTE (dBm)	60 s
`.../system/rsrq`	Qualité signal RSRQ (dB)	60 s
`.../system/uptime`	Uptime (secondes)	60 s
`.../system/sim_active`	SIM active (1 ou 2)	Sur changement
`.../system/operator`	Opérateur LTE actuel	Sur changement
`.../system/wan_ip`	IP WAN	Sur changement
`.../system/vpn_latency_ms`	Latence tunnel VPN	60 s

Événements temps réel

Topic	Déclencheur
`.../events/failover`	Bascule SIM1 → SIM2
`.../events/failover_recovered`	Retour sur SIM1
`.../events/reboot`	Redémarrage détecté
`.../events/vpn_connected`	Tunnel VPN établi
`.../events/vpn_disconnected`	Tunnel VPN perdu
`.../events/modbus_timeout`	Esclave Modbus ne répond plus

Format des payloads

Payload standard (capteurs)

{
  "device_id": "d_a1b2c3d4",
  "name": "GW-Paris-01",
  "timestamp": "2025-06-15T14:23:45.123Z",
  "metric": "active_power",
  "value": 42.7,
  "unit": "kW",
  "quality": "good",
  "source": "modbus:slave=1:reg=0x0048"
}

Payload événement failover

{
  "device_id": "d_a1b2c3d4",
  "event": "failover",
  "timestamp": "2025-06-15T14:23:45.123Z",
  "from_sim": 1,
  "to_sim": 2,
  "from_operator": "Orange",
  "to_operator": "SFR",
  "reason": "rsrp_below_threshold",
  "rsrp_sim1_dbm": -104,
  "duration_ms": 28340
}

Le champ "quality" indique la fiabilité de la mesure :

"good" — lecture Modbus réussie
"timeout" — l'esclave n'a pas répondu
"error" — erreur Modbus (champ "error_code" présent)
"stale" — dernière valeur connue (esclave temporairement absent)

Abonnement et test

Test rapide avec mosquitto_sub

# S'abonner à tous les topics d'un dispositif
mosquitto_sub -h mqtt.eziwan.com -p 8883 \
  --cert ~/eziwan/client.crt \
  --key  ~/eziwan/client.key \
  --cafile ~/eziwan/ca.crt \
  -t "eziwan/d_a1b2c3d4/#" -v

# Topics spécifiques
mosquitto_sub -h mqtt.eziwan.com -p 8883 \
  --cert ~/eziwan/client.crt --key ~/eziwan/client.key \
  --cafile ~/eziwan/ca.crt \
  -t "eziwan/d_a1b2c3d4/modbus/1/active_power" \
  -t "eziwan/d_a1b2c3d4/events/#"

Téléchargez vos certificats client depuis Paramètres → MQTT → Télécharger certificats.

Intégration InfluxDB 2.x + Grafana

Architecture

Configuration Telegraf

# /etc/telegraf/telegraf.conf

[[inputs.mqtt_consumer]]
  servers = ["ssl://mqtt.eziwan.com:8883"]
  topics  = ["eziwan/+/modbus/#", "eziwan/+/system/#"]
  qos     = 1

  # Certificats MTLS
  tls_ca   = "/etc/telegraf/eziwan-ca.crt"
  tls_cert = "/etc/telegraf/eziwan-client.crt"
  tls_key  = "/etc/telegraf/eziwan-client.key"

  # Parsing JSON
  data_format = "json"
  json_time_key    = "timestamp"
  json_time_format = "2006-01-02T15:04:05.999Z07:00"
  tag_keys = ["device_id", "name", "metric", "unit"]

[[outputs.influxdb_v2]]
  urls         = ["http://influxdb:8086"]
  token        = "votre-token-influx"
  organization = "acme-corp"
  bucket       = "eziwan"

Requête Flux pour Grafana

from(bucket: "eziwan")
  |> range(start: -24h)
  |> filter(fn: (r) => r._measurement == "mqtt_consumer")
  |> filter(fn: (r) => r.metric == "active_power")
  |> filter(fn: (r) => r.device_id == "d_a1b2c3d4")
  |> aggregateWindow(every: 1m, fn: mean, createEmpty: false)
  |> yield(name: "puissance_active")

Intégration Node-RED

Node-RED permet de créer des flux de traitement de données visuels :

[
  {
    "type": "mqtt in",
    "topic": "eziwan/d_a1b2c3d4/modbus/1/active_power",
    "broker": "eziwan-mqtt",
    "qos": 1
  },
  {
    "type": "json"
  },
  {
    "type": "function",
    "func": "if (msg.payload.value > 100) { msg.alert = true; } return msg;"
  },
  {
    "type": "http request",
    "method": "POST",
    "url": "https://hooks.slack.com/services/xxx",
    "comment": "Alerte Slack si puissance > 100 kW"
  }
]

QoS recommandé par cas d'usage

Cas d'usage	QoS	Justification
Métriques système (RSSI, uptime)	0	Données redondantes — perte acceptable
Capteurs process (énergie, T°, P)	1	Fiabilité requise, doublons gérés
Alarmes et événements critiques	1	Au moins une fois reçu
Commandes actionneurs	2	Exactement une fois — évite double action

Certificats et sécurité

Les certificats client MTLS sont disponibles dans Paramètres → MQTT → Télécharger les certificats. Ils sont uniques par tenant et peuvent être régénérés à tout moment.

Contacter le support → | API REST →

Questions fréquentes

Pourquoi MQTT s'est-il imposé dans l'IoT industriel ?

Parce qu'il est léger (idéal sur 4G), fonctionne en publication/abonnement (les équipements initient la connexion, aucun port entrant), et gère nativement les liens intermittents avec les niveaux de QoS et les messages retenus.

Quel niveau de QoS choisir ?

QoS 1 (au moins une fois) est le bon défaut pour la télémétrie : il garantit la livraison sans la lourdeur du QoS 2. Réservez QoS 0 aux mesures haute fréquence tolérantes à la perte.

Comment sécuriser un flux MQTT ?

TLS systématique (port 8883), authentification par certificat client ou identifiants dédiés par équipement, et cloisonnement des topics par site. Le broker ne doit jamais accepter de connexion anonyme.

MQTT remplace-t-il Modbus ?

Non, ils se complètent : Modbus collecte les données au plus près des équipements (bus de terrain), MQTT les transporte efficacement vers le cloud. La gateway fait la conversion Modbus → MQTT.

Ressources associées

MQTT industriel — la page solution
OPC UA et MQTT — combiner les deux standards
Modbus RTU vers MQTT — la conversion terrain → cloud
API REST Eziwan — l'autre voie d'intégration
MQTT et RS-485 en pratique — l'article de fond

Brokers compatibles​

Configuration broker​

Via le dashboard Eziwan​

Configuration YAML​

Structure des topics​

Données capteurs RS485 / Modbus​

Métriques système (publiées automatiquement)​

Événements temps réel​

Format des payloads​

Payload standard (capteurs)​

Payload événement failover​

Abonnement et test​

Test rapide avec mosquitto_sub​

Intégration InfluxDB 2.x + Grafana​

Architecture​

Configuration Telegraf​

Requête Flux pour Grafana​

Intégration Node-RED​

QoS recommandé par cas d'usage​

Questions fréquentes​

Pourquoi MQTT s'est-il imposé dans l'IoT industriel ?​

Quel niveau de QoS choisir ?​

Comment sécuriser un flux MQTT ?​

MQTT remplace-t-il Modbus ?​

Ressources associées​