MQTT Integration

Eziwan includes a native MQTT client that publishes field data (RS485 sensors, network metrics, events) to any MQTT broker—whether cloud-based or on-premises.

Supported Brokers

Broker	Type	Notes
Eziwan MQTT	Managed (included)	`mqtt.eziwan.com:8883` — TLS, zero configuration
Mosquitto	Self-hosted	Open-source — requires hosting
HiveMQ	Cloud / On-premises	Enterprise
EMQX	Cloud / On-premises	High performance
AWS IoT Core	Cloud	Lambda, S3 integration
Azure IoT Hub	Cloud	Azure Stream Analytics integration
Google Cloud IoT	Cloud	Pub/Sub integration
Scaleway IoT Hub	Cloud	Hosted in France

Broker Configuration

Via the Eziwan dashboard

Device → Settings → MQTT

Graphical interface for configuring the broker, credentials, and topics.

YAML Configuration

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

  # Auth — token available in the dashboard → Settings → MQTT
  username: "np_device"
  password: "np_mqtt_xxxxxxxxxx"

  # Quality of 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

Offline Buffering

If the LTE connection is temporarily interrupted, Eziwan buffers MQTT messages locally (up to offline_buffer_size messages) and automatically publishes them when the connection is restored. Data is never lost.

Topic Structure

RS485 / Modbus Sensor Data

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

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

You can also define custom topics by register in the Modbus configuration:

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

System Metrics (published automatically)

Topic	Description	Interval
`.../system/rsrp`	LTE RSRP Signal (dBm)	60 s
`.../system/rsrq`	RSRQ Signal Quality (dB)	60 s
`.../system/uptime`	Uptime (seconds)	60 s
`.../system/sim_active`	Active SIM (1 or 2)	On change
`.../system/operator`	Current LTE operator	On change
`.../system/wan_ip`	WAN IP	On change
`.../system/vpn_latency_ms`	VPN tunnel latency	60 s

Real-Time Events

Topic	Trigger
`.../events/failover`	Switch from SIM1 to SIM2
`.../events/failover_recovered`	Switch back to SIM1
`.../events/reboot`	Restart detected
`.../events/vpn_connected`	VPN tunnel established
`.../events/vpn_disconnected`	VPN tunnel lost
`.../events/modbus_timeout`	Modbus slave no longer responding

Payload Format

Standard Payload (Sensors)

{
  "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"
}

Failover Event Payload

{
  "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
}

The "quality" field indicates the reliability of the measurement:

"good" — successful Modbus read
"timeout" — the slave did not respond
"error" — Modbus error ("error_code" field present)
"stale" — last known value (slave temporarily unavailable)

Subscription and Trial

Quick Test with mosquitto_sub

# Subscribe to all topics for a device
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

# Specific Topics
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/#"

Download your client certificates from Settings → MQTT → Download Certificates.

InfluxDB 2.x + Grafana Integration

Architecture

Telegraf Configuration

# /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"

Flux Query for 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")

Node-RED Integration

Node-RED lets you create visual data processing flows:

[
  {
    "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"
  }
]

Recommended QoS by Use Case

Use Case	QoS	Justification
System metrics (RSSI, uptime)	0	Redundant data — acceptable loss
Process sensors (energy, T°, P)	1	Reliability required, duplicates managed
Alarms and critical events	1	Received at least once
Actuator commands	2	Exactly once — prevents duplicate actions

Certificates and Security

MTLS client certificates are available under Settings → MQTT → Download Certificates. They are unique to each tenant and can be regenerated at any time.

Contact Support → | REST API →

Frequently Asked Questions

Why Has MQTT Become the Standard in Industrial IoT?

Because it is lightweight (ideal for 4G), operates on a publish/subscribe model (devices initiate the connection; no incoming ports), and natively supports intermittent connections with QoS levels and queued messages.

Which QoS level should you choose?

QoS 1 (at least once) is the right default for telemetry: it guarantees delivery without the overhead of QoS 2. Reserve QoS 0 for high-frequency, loss-tolerant measurements.

How do you secure an MQTT stream?

Systematic TLS (port 8883), authentication via client certificate or device-specific credentials, and topic isolation by site. The broker must never accept anonymous connections.

Is MQTT Replacing Modbus?

No, they complement each other: Modbus collects data as close to the devices as possible (fieldbus), while MQTT efficiently transmits it to the cloud. The gateway handles the Modbus-to-MQTT conversion.

Industrial MQTT — the solutions page
OPC UA and MQTT — combining the two standards
Modbus RTU to MQTT — field-to-cloud conversion
Eziwan REST API — another integration option
MQTT and RS-485 in Practice — the in-depth article

Supported Brokers​

Broker Configuration​

Via the Eziwan dashboard​

YAML Configuration​

Topic Structure​

RS485 / Modbus Sensor Data​

System Metrics (published automatically)​

Real-Time Events​

Payload Format​

Standard Payload (Sensors)​

Failover Event Payload​

Subscription and Trial​

Quick Test with mosquitto_sub​

InfluxDB 2.x + Grafana Integration​

Architecture​

Telegraf Configuration​

Flux Query for Grafana​

Node-RED Integration​

Recommended QoS by Use Case​

Frequently Asked Questions​

Why Has MQTT Become the Standard in Industrial IoT?​

Which QoS level should you choose?​

How do you secure an MQTT stream?​

Is MQTT Replacing Modbus?​

Related Resources​