What to Check Before Buying an Industrial MQTT Gateway

“Supports MQTT” is not a complete gateway requirement.

An industrial MQTT gateway may publish telemetry, subscribe to approved commands, bridge Modbus or serial data into MQTT, host a local broker, or combine several of these roles. Each role creates different requirements for topics, payloads, credentials, delivery behavior, offline storage, and maintenance.

A Robustel edge computing gateway EG5200 can be a practical fit when a site needs several local device connections, an open edge application environment, cellular or Ethernet backhaul, and RCMS-based gateway operations. But the buying decision should still begin with the MQTT role, not the product checkbox.

The main takeaway is direct: before choosing an MQTT gateway, define what MQTT job the gateway is expected to perform.

Define the MQTT role first

The gateway may act as an MQTT publisher. In that role, it collects local data and sends prepared messages to a broker. The project should define data sources, publishing frequency, topic count, payload format, authentication method, broker destination, and behavior when publishing fails.

The gateway may act as a subscriber. That means it receives selected messages from approved topics. This role needs stronger caution because subscription can become a path for instructions coming from outside the site. The local application must validate the sender, message, permitted action, operating state, and safety boundary.

The gateway may act as a protocol bridge. For example:

Modbus register
  → scaling and unit
  → timestamp and quality
  → MQTT topic and payload
  → cloud platform

The gateway may also host a local MQTT broker. That can help local applications exchange messages without depending on the WAN, but it adds security, configuration, queue, and maintenance responsibility.

These roles should not be mixed casually. Write them down before purchasing.

Design the topic and payload contract

A technically successful MQTT connection can still deliver unusable data.

The topic and payload together form a contract between the gateway and the consuming platform. A topic namespace should make the source and purpose of the message clear.

Example:

europe/plant7/compressor2/temperature
europe/plant7/compressor2/status
europe/plant7/compressor2/alarm
europe/plant7/gateway1/connectivity

The payload should carry enough context for the receiving system to understand the value.

{
  "asset_id": "compressor2",
  "value": 72.4,
  "unit": "degC",
  "quality": "good",
  "source_timestamp": "2026-07-29T09:42:18Z",
  "sequence": 18432,
  "schema_version": "1.1"
}

Without this context, the cloud may receive data but still not know whether the value is live, delayed, replayed, valid, or mapped to the correct asset.

Use MQTT features deliberately

MQTT provides useful mechanisms such as QoS, retained messages, persistent sessions, session expiry, and Will Messages. These should be selected by data type, not switched on blindly.

A higher QoS can add acknowledgements and retransmission behavior. That may be useful for selected alarms or records, but unnecessary for rapidly changing telemetry where the next value will soon replace the previous one.

Retained messages are useful for current state, such as latest gateway availability or current machine mode. They are not a time-series database.

A Will Message can indicate that a client disconnected unexpectedly, but it does not diagnose the whole site. It does not prove whether the gateway lost power, WAN failed, the application restarted, or a field device stopped responding.

MQTT is a messaging protocol. The industrial application still needs a data and failure policy around it.

Secure the MQTT path

An anonymous test connection should not become production architecture.

The project should define client identity, credentials or certificates, TLS requirements, topic-level permissions, firewall rules, VPN or private-network paths, credential rotation, and access review.

Each gateway or application should have only the permissions required by its role. A meter gateway may publish telemetry but should not subscribe to control topics. A maintenance tool may read diagnostic messages but should not change production configuration. One customer or site should not be able to access another site’s topic tree.

This is especially important if a local broker is installed. A broker should not be exposed through the cellular or public WAN just because remote access is convenient.

Define offline and replay behavior

Industrial sites cannot assume that the WAN, broker, and cloud platform will always be available.

The gateway specification should answer several questions. Does local collection continue when the WAN is unavailable? Where are pending messages stored? Are original timestamps preserved? What happens if storage fills? How is backlog replay controlled? Do live alarms have priority over historical telemetry?

Persistent MQTT sessions do not replace application storage. A site that must retain several days of records may need a local database, queue, or dedicated store-and-forward function.

When the connection returns, uncontrolled replay can overwhelm the broker or delay live messages. Replay rate, batching, acknowledgements, duplicate handling, and message expiry should be part of the design.

Where Robustel EG5200 fits

Robustel edge computing gateway EG5200 fits larger MQTT integration projects where the site may need several local IP devices, serial interfaces, Docker or Debian-based applications, 5G or 4G variants, firewall and VPN functions, and RCMS-based management.

It can support different MQTT architectures depending on the deployed software: custom publisher, protocol bridge, subscriber application, local broker, or combined local-broker and cloud-forwarding design.

The important boundary is that these are implementation choices, not automatic guarantees. The selected software, broker, application, credential model, and recovery design still need to be confirmed.

For product reference, see the Robustel EG5200 product page.

FAQ

Q1. Does an MQTT gateway need a local broker?

Not always. A gateway can act as an MQTT publisher or protocol bridge and connect directly to a remote broker. A local broker is useful when several site applications must exchange messages without depending on the WAN. It also adds security, storage, configuration, and maintenance responsibilities.

Q2. What is the difference between an MQTT gateway and an MQTT broker?

An MQTT gateway usually collects, converts, or prepares local data and acts as a publisher, subscriber, or protocol bridge. An MQTT broker receives messages from publishers and distributes them to authorized subscribers. A gateway can host a broker, but the roles remain different and should be specified separately.

Q3. Where does Robustel edge computing gateway EG5200 fit?

Robustel edge computing gateway EG5200 fits MQTT projects that need multiple local connections, industrial interfaces, application hosting, cellular or Ethernet backhaul, security controls, and remote gateway management. It should still be validated against the actual broker, topics, payload schema, credentials, outage behavior, and maintenance model.