MQTT Gateway Buying Guide for Industrial IoT: What to Check Before Cloud Integration

Robustel EG5200 edge computing gateway is a practical fit when an industrial site needs to connect several local devices, run MQTT applications, and maintain cellular or Ethernet connectivity to an upstream platform. Before selecting any MQTT gateway, however, teams must define whether it will publish data, subscribe to commands, bridge industrial protocols, host a local broker, or combine several of these roles.

“Supports MQTT” is not a complete purchasing requirement. The project must also specify the topic structure, payload format, device identity, security method, delivery behaviour, offline policy, and application ownership expected after deployment.

Define the Gateway’s MQTT Role First

MQTT is a lightweight publish-and-subscribe messaging protocol in which clients exchange application messages through a broker. The protocol defines messaging behaviour, but it does not decide how an industrial gateway should collect, interpret, or store field data.

An MQTT gateway may perform four different roles.

Gateway Role	Main Responsibility	Typical Industrial Use
MQTT publisher	Sends locally collected data to a broker	Telemetry, alarms, status, and event reporting
MQTT subscriber	Receives messages from selected topics	Configuration requests or approved application instructions
Protocol bridge	Converts Modbus, SNMP, serial, or other data into MQTT messages	OT-to-cloud integration
Local MQTT broker	Routes messages among local publishers and subscribers	Site-level messaging independent of the WAN

One Robustel gateway may perform more than one role, but each role creates different requirements.

MQTT Publisher

As a publisher, the gateway may collect data from PLCs, meters, sensors, cameras, or local applications and send prepared messages to a cloud or enterprise broker.

The buying requirement should define:

• Number of data sources
• Publishing frequency
• Topic quantity
• Average and peak message volume
• Payload format
• Authentication method
• Broker destination
• Behaviour when publishing fails

This is often the simplest MQTT gateway role.

MQTT Subscriber

A subscriber receives messages from selected topics. An upstream application might use this path to deliver configuration values, maintenance requests, or other approved instructions.

Subscription does not mean that cloud software should receive unrestricted authority over industrial equipment. The local application must validate the message, sender, permitted action, operating state, and response boundary before changing anything at the site.

PLC control, safety interlocks, and deterministic machine functions should not depend on unverified MQTT commands.

Protocol Bridge

A protocol bridge collects data in one form and publishes it through MQTT. For example:

Modbus register

→ scaling and engineering unit

→ timestamp and data quality

→ MQTT topic and payload

→ cloud platform

The gateway must do more than move bytes. It needs a mapping that preserves the identity and meaning of every selected industrial variable.

Local MQTT Broker

A local broker receives messages from publishers and distributes them to authorised subscribers inside the site.

Robustel documents the installation of Mosquitto on supported edge computing gateways, including EG5120 and EG5200 running RobustOS Pro. The current procedure requires RobustOS Pro 2.3.0 or later, working internet access for package installation, SSH access, and a sudo-enabled account.

Hosting a broker locally can reduce dependence on the cloud for communication among site devices. It does not automatically provide persistent historical storage, application-level store-and-forward, unlimited queues, or data replay to an external broker.

Match the MQTT Message Contract to the Cloud Platform

After defining the gateway role, the project must define what the upstream platform expects to receive. An MQTT topic and payload together form an application contract. A connection can be technically successful while still delivering unusable data when that contract is incomplete.

Establish a Topic Namespace

A topic hierarchy should make the source and purpose of each message understandable.

A possible structure is: region/site/asset/data-type

Examples include:

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

The exact hierarchy depends on the cloud platform and fleet design. The important requirement is consistency. A topic should not depend on information that may change unpredictably, such as a temporary IP address. Site, asset, device, and message-type identifiers should be managed deliberately.

Define a Stable Payload Schema

A useful industrial payload may include:

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

The project should decide whether the payload needs:

• Asset identity
• Site identity
• Value and data type
• Engineering unit
• Original timestamp
• Gateway timestamp
• Data-quality status
• Sequence number
• Event classification
• Mapping or schema version

Without this information, a cloud application may receive a value without knowing whether it is current, valid, delayed, replayed, or associated with the correct asset.

Separate Telemetry, Events, and Gateway Health

Routine data, operational events, and gateway status should not necessarily share one topic or delivery policy.

Message Type	Example	Typical Requirement
Telemetry	Temperature every minute	Predictable reporting interval
State event	Machine started or stopped	Publish after transition
Alarm	Pressure outside approved range	Prompt delivery
Data-quality event	PLC communication timeout	Distinguish data loss from process value
Gateway health	WAN or application status	Support remote diagnosis

This separation helps the upstream platform prioritise messages and apply suitable retention rules.

Choose Delivery Behaviour by Data Type

MQTT provides mechanisms including Quality of Service, retained messages, persistent sessions, session expiry, and Will Messages. These mechanisms address specific messaging behaviours; they do not guarantee complete end-to-end data integrity without an application design around them.

Select QoS Deliberately

The project should choose the required delivery level for each message class rather than setting the highest option globally.

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

The acceptance criteria should state:

• Which messages may be lost
• Which messages may be duplicated
• Which records require acknowledgement
• Whether the receiving application performs deduplication
• How long a message remains useful

Even where MQTT provides stronger delivery semantics between a client and broker, the industrial application may still need a unique event ID or sequence number to prevent duplicate business actions.

Use Retained Messages for Current State, Not History

A retained MQTT message can allow a new subscriber to receive the broker’s retained value for a topic. It is useful for states such as:

• Current gateway availability
• Latest machine mode
• Current configuration version
• Last reported operating condition

A retained message is not a time-series database. It should not be used as a substitute for storing historical measurements or events.

Use a Will Message to Signal Unexpected Disconnection

A client can define a Will Message that the broker publishes when the connection closes unexpectedly under the applicable MQTT conditions. This can help indicate that a gateway or application may no longer be connected.

The upstream system should still distinguish an MQTT client disconnect from:

• Complete gateway power loss
• WAN interruption
• Broker failure
• Application restart
• Deliberate maintenance
• Loss of communication with a field device

A Will Message is evidence about the client connection, not a diagnosis of the entire industrial site.

Secure the MQTT Path Before Production

A successful anonymous test connection should never become the production design.

Robustel’s Mosquitto installation guide uses allow_anonymous true only for initial setup, testing, and trusted local networks. It states that production deployments should disable anonymous access and use authentication plus Access Control Lists to restrict which clients may publish or subscribe to specific topics.

The security review should cover four layers.

Client Identity

Each gateway or application should have a managed identity. Depending on the broker and project, this may use:

• Username and password
• Client certificate
• Token or cloud-issued credential
• A private APN and additional application credentials

Credentials should not be shared across the full fleet unless the security architecture explicitly accepts the resulting risk.

Encryption in Transit

The project should confirm whether the broker requires TLS, which certificate authority is trusted, how server identity is verified, and how certificates are renewed.

MQTT does not make application traffic encrypted simply because the protocol is lightweight or commonly used for IoT.

Topic-Level Permissions

An industrial MQTT client should only have access to the topics required by its role.

For example:

• A meter gateway may publish telemetry but not subscribe to control topics.
• A maintenance application may read diagnostic topics but not change production configuration.
• One customer or site should not access another customer’s topic tree.

Network Exposure

A local broker should not be exposed directly through the cellular or public WAN merely because a remote client needs to connect.

Robustel EG5200 edge computing gateway supports firewall controls and VPN technologies, while RCMS and RobustVPN provide managed remote-access options for Robustel gateway estates. The permitted path should be designed around least privilege rather than opening a general MQTT port to the internet.

Define Offline and Reconnection Behaviour

Industrial sites cannot assume that the gateway, WAN, broker, and cloud platform will remain continuously available.

The buying specification should explain what happens in each failure state.

Failure	Required Question
WAN unavailable	Does local collection continue?
Cloud broker unavailable	Where are pending messages stored?
Local broker stops	Do site applications reconnect automatically?
Gateway reboots	Are queues and session states preserved?
Credentials expire	How is the connection restored?
Storage fills	Which data is discarded first?
Backlog is large	How is replay rate controlled?

Do Not Confuse MQTT Sessions with Application Storage

Persistent sessions can retain selected MQTT session information and queued messages under the applicable broker configuration, QoS, expiry settings, and resource limits. They do not remove the need to calculate storage, message lifetime, and recovery behaviour for the industrial application.

A site that must retain several days of telemetry may need a local database or dedicated queue rather than relying only on the broker session.

Preserve Original Timestamps

A message published after reconnection should retain the time the measurement or event occurred.

Otherwise, an alarm generated during a three-hour outage may appear to be a new live event when the gateway reconnects.

Prioritise Live and Historical Traffic

When the WAN returns, the Robustel gateway may need to send:

• Current critical alarms
• Queued critical alarms
• Current telemetry
• Historical routine telemetry

Uploading the complete backlog at maximum speed can delay live messages or overwhelm the broker. Replay rate, batching, acknowledgement, and duplicate handling should be included in the application requirements.

A local broker alone does not implement this entire process. Store-and-forward behaviour must be configured in the broker, bridge, database, or gateway application selected for the project.

How Robustel EG5200 Edge Computing Gateway Supports MQTT Integration

Robustel EG5200 edge computing gateway combines local application hosting, multi-device networking, industrial interfaces, and resilient WAN connectivity.

The current platform includes:

Product Area	Relevant EG5200 Capability
Operating system	RobustOS Pro based on Debian 11
CPU	Quad-core Cortex-A53 at 1.6 GHz
Memory	4 GB LPDDR4
Local storage	32 GB eMMC
Ethernet	5 × Gigabit Ethernet, configurable as LAN or WAN
Serial	2 × software-configurable RS-232/422/485
Cellular	Dual-SIM 5G or 4G models
Applications	Docker containers, Debian packages, and SDK
Security	Firewall and VPN functions
Fleet operations	RCMS monitoring, configuration, applications, and updates

Robustel positions the EG5200 as an open industrial edge platform for protocol bridges, buffering, analytics, and multi-device integration. Five Gigabit Ethernet ports allow several IP devices to connect at one site, while its configurable serial interfaces can connect compatible legacy equipment.

The Robustel platform can support different MQTT architectures:

• A custom application acting as an MQTT publisher
• A protocol bridge converting local data into MQTT
• An application subscribing to approved topics
• A locally installed Mosquitto broker
• A combined local-broker and cloud-forwarding design

These functions depend on the software installed and configured for the deployment. They should not all be described as pre-installed native functions.

The Robustel EG5200 edge computing gateway product information should be used to confirm the current processing resources, interfaces, WAN options, and application environment before approval.

RCMS can monitor Robustel EG5200 fleets, deploy signed firmware, applications, and configurations, provide remote CLI and diagnostics, and support controlled access through RobustVPN. RCMS manages the gateway estate; it does not replace the MQTT broker, cloud IoT platform, or application-level message monitoring.

The Robustel MQTT broker installation guide provides a practical reference for installing, testing, and securing Mosquitto on supported EG-series gateways.

Run a Cloud-Integration Acceptance Test

Before purchasing for a wider rollout, the Robustel EG5200 should be tested against the actual broker or cloud endpoint.

The test should verify:

1. The gateway authenticates with the approved credential.
2. TLS and certificate validation work as designed.
3. Topics follow the agreed namespace.
4. Payloads match the required schema.
5. Telemetry, alarms, and health messages use the intended delivery settings.
6. Unauthorised publish and subscribe attempts are rejected.
7. The gateway reconnects after WAN loss.
8. Queued messages retain original timestamps.
9. Backlog replay does not block live data.
10. Duplicate messages are handled correctly.
11. The application recovers after a gateway reboot.
12. RCMS can diagnose the Robustel gateway without exposing the MQTT service unnecessarily.

Acceptance Area	Evidence Required
MQTT role	Documented publisher, subscriber, bridge, or broker responsibility
Cloud contract	Approved topics and payload examples
Security	Authentication, TLS, ACL, firewall, and credential process
Delivery	Tested QoS, session, retained, and Will behaviour
Offline operation	Defined queue, storage, expiry, and replay policy
Maintenance	Named owner for broker, application, certificates, and updates

The test should use representative message volume and outage duration. A successful publication of one test message proves connectivity; it does not prove production readiness.

FAQs

Q1. Does an MQTT gateway need to include a local broker?

Not necessarily. Robustel EG5200 edge computing 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, so teams should confirm that local publish-and-subscribe communication is genuinely required.

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

An MQTT gateway usually collects or converts local data and acts as a publisher, subscriber, or protocol bridge. An MQTT broker receives messages from publishers and distributes them to authorised subscribers. A gateway can also host a local broker, but the roles remain different. Buyers should confirm which function is included, which software provides it, and who owns updates, security, credentials, and recovery.

Q3. Which MQTT security features should an industrial gateway support?

The project should require managed client identities, encrypted connections where appropriate, certificate or credential validation, topic-level permissions, firewall rules, and a defined renewal process. A local broker should not remain anonymously accessible in production. VPN or private-network options may add another protection layer. These controls should be tested during commissioning using expired credentials, rejected connections, and unauthorised topic-access attempts.

Q4. How should an MQTT gateway behave during a network outage?

The gateway should continue approved local collection where possible, store selected messages according to a defined limit, preserve original timestamps, and reconnect automatically. After recovery, it should prioritise live alarms, replay historical records at a controlled rate, and avoid uncontrolled duplicates. These behaviours require explicit application, broker, session, and storage settings. They are not guaranteed simply because the gateway supports MQTT.

Q5. What should be tested before connecting an MQTT gateway to the cloud?

Test the real broker or cloud endpoint using production-style credentials, topics, payloads, and message volume. Confirm TLS or VPN behaviour, publishing and subscription permissions, QoS settings, retained and Will messages, WAN loss, broker loss, gateway reboot, credential failure, queue limits, and backlog replay. A single successful test message proves connectivity only; it does not demonstrate secure and recoverable industrial operation.

Conclusion: MQTT Gateway Buying Takeaway

Robustel EG5200 edge computing gateway is a strong fit when an industrial MQTT project needs several local device connections, an open Debian-based application platform, 5G or 4G backhaul, and RCMS-based gateway operations.

The purchasing decision should not stop at confirming MQTT support. Teams must identify whether the Robustel gateway will be a publisher, subscriber, protocol bridge, local broker, or a controlled combination of these roles.

Once that role is clear, the project can validate the message contract, delivery behaviour, security controls, offline storage, reconnection process, and long-term application ownership. That is what turns MQTT from a protocol checkbox into a supportable industrial edge-to-cloud data path.

Related Reading on Edge Computing in Industrial IoT:

About the Author

Robert Liao | Technical Support Engineer

Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.