MQTT Gateway: How to Connect Devices, Protocols, and Broker Infrastructure

An MQTT gateway connects devices, field protocols, and local data sources to an MQTT broker. Many machines and legacy systems cannot publish MQTT messages on their own. The broker then provides the shared layer for distributing their data to connected applications and services.

MQTT gateway: key takeaways

• An MQTT gateway connects non-MQTT devices, machines, sensors, and field protocols to MQTT infrastructure by translating their data into structured messages.
• MQTT gateways prepare and publish data. MQTT brokers authenticate clients, apply topic permissions, and distribute messages to subscribers.
• Protocol gateways, edge gateways, broker bridges, and MQTT brokers serve different architecture tasks and require clear boundaries.
• Cedalo provides the broker infrastructure behind gateway deployments, including Transport Layer Security (TLS), role-based access control (RBAC), clustering, monitoring, and centralized management.

What is an MQTT gateway?

An MQTT gateway is a translation and publishing layer between local data sources and an MQTT broker. It reads data from machines, sensors, controllers, serial interfaces, fieldbuses, and local services. The gateway then converts this data into messages which follow the MQTT protocol.

In industrial architectures, the gateway is typically located close to machines, vehicles, buildings, or edge networks. It can map raw values to engineering units, add asset identifiers and timestamps, and publish the result to predefined MQTT topics.

The MQTT gateway therefore controls how field-level data enters the MQTT architecture. Downstream systems receive consistent data without maintaining direct connections to every source device or protocol.

How does an MQTT gateway differ from an MQTT broker?

The architectural difference lies in where each component acts. The gateway prepares data close to its source and publishes it through MQTT. The broker receives those messages and distributes them to matching subscribers.

Client IDs, session handling, reconnect logic, and Quality of Service (QoS) depend on the configuration of each MQTT client. The following comparison shows how the main MQTT components differ in function, location, protocol translation, and message routing:

A broker becomes essential once several applications need shared subscriptions, centralized authentication, topic-level access control, monitoring, and scalable message distribution.

Which MQTT architecture component do you need?

The correct component depends on whether the architecture requires protocol translation, local processing, MQTT message routing, or broker-to-broker exchange.

When does a broker bridge make sense?

A broker bridge is useful when separate MQTT environments need to exchange selected topics, for example between a plant and a central data center. Its Mosquitto bridge configuration defines the connection, topic filters, and forwarding direction.

How does an MQTT gateway work in an IoT architecture?

An MQTT gateway serves as the handoff point between field-level communication and broker-based data distribution. It reads local data, normalizes it, and publishes the result into MQTT infrastructure.

A typical data path follows six steps:

1. A device or field protocol produces a value.
2. The gateway reads the value through a local interface or protocol driver.
3. The gateway maps the raw value to a defined signal and engineering unit.
4. The gateway adds context such as asset ID, location, quality, and timestamp.
5. The gateway publishes the message to an MQTT topic.
6. The broker authenticates the gateway and routes the message to matching subscribers.

Example topic:

factory/site-a/line1/machine3/temperature

Example payload:

{
  "asset_id": "machine3",
  "site": "site-a",
  "line": "line1",
  "signal": "temperature",
  "value": 72.4,
  "unit": "C",
  "quality": "good",
  "timestamp": "2026-06-04T10:15:00Z"
}

The asset, signal, value, unit, and quality fields give consuming applications enough context to interpret the message consistently.

When do you need a Modbus MQTT gateway?

You need a Modbus MQTT gateway when PLCs, meters, drives, or sensors expose data through Modbus RTU or Modbus TCP, while the receiving architecture uses MQTT. The gateway reads Modbus registers, converts raw values into named signals, and publishes them to an MQTT broker.

The Modbus protocol defines the register types, addressing, and communication model behind that source data. The gateway-specific step begins when those register values become an MQTT topic and payload.

Example Modbus mapping:

Example MQTT topic:

factory/site-a/line1/power_meter_7/modbus/temperature

Example payload after conversion:

{
  "asset_id": "power_meter_7",
  "protocol": "modbus_tcp",
  "register": 30021,
  "signal": "temperature",
  "value": 72.4,
  "unit": "C",
  "timestamp": "2026-06-04T10:15:00Z"
}

How should MQTT gateway topics and payloads be structured?

MQTT gateway topics should identify the source context and signal without becoming overloaded with metadata. Payloads should carry values and operational attributes which may change independently of the topic hierarchy.

Useful topic patterns include:

factory/{site}/{line}/{machine}/{signal}
factory/{site}/{line}/{machine}/{protocol}/{signal}
building/{floor}/{room}/sensor/{sensor_type}
fleet/{vehicle_id}/gateway/{signal_type}

A protocol segment can help engineers trace where values originated:

factory/site-a/line1/machine3/modbus/temperature
factory/site-a/line1/machine3/can/engine_rpm
factory/site-a/line1/machine3/opcua/spindle_speed

Design rules for MQTT topics and payloads

Use the topic for stable routing context, such as site, asset, protocol, and signal type. Place changing values, units, timestamps, and quality states in the payload. This keeps subscriptions predictable and topic structures stable.

Data quality requires particular attention when a gateway reads from legacy devices or unstable connections. A source may remain reachable even though its latest measurement is outdated or invalid. The payload should make this state visible while preserving the last trusted value:

{
  "asset_id": "machine3",
  "signal": "temperature",
  "value": null,
  "unit": "C",
  "quality": "stale",
  "last_valid_value": 72.4,
  "last_valid_timestamp": "2026-06-04T10:15:00Z",
  "timestamp": "2026-06-04T10:17:00Z"
}

This structure separates the current invalid state from the last trusted measurement.

What security requirements matter for MQTT gateways?

MQTT gateway security depends on encrypted transport, unique gateway identities, and restricted publish permissions. These controls limit the impact of stolen credentials or a compromised gateway.

A secure gateway-to-broker setup includes:

• TLS encryption between the gateway and broker
• Mutual TLS or rotated credentials for gateway authentication
• Unique client identities for every gateway
• Publish permissions limited to assigned topic branches
• Audit records for authentication and authorization events

A correct MQTT TLS configuration verifies the broker identity and protects data in transit. Mutual TLS also enables the broker to verify the gateway certificate before accepting the connection.

The permission model should reflect the physical or organizational structure of the deployment:

A controlled TLS publish test can use:

mosquitto_pub \
  -h broker.example.com \
  -p 8883 \
  --cafile ca.crt \
  --cert gateway.crt \
  --key gateway.key \
  -t factory/site-a/line1/machine3/temperature \
  -m '{"asset_id":"machine3","signal":"temperature","value":72.4,"unit":"C","timestamp":"2026-06-04T10:15:00Z"}'

This command verifies encrypted transport, certificate-based authentication, and access to the assigned topic.

What should you check before choosing an open MQTT gateway?

An open MQTT gateway should support the source protocols, security model, outage behavior, and payload structure required by the production environment.

The following criteria separate a useful test setup from a gateway which can operate reliably in production:

Evaluate the complete data path rather than the gateway connection alone:

1. Verify that the gateway reads the required protocol values.
2. Confirm register, signal, scaling, and unit mappings.
3. Check topic and payload consistency.
4. Test TLS or mutual TLS authentication.
5. Disconnect the network and verify local buffering.
6. Restore connectivity and inspect replay behavior.
7. Confirm that broker permissions restrict the gateway correctly.
8. Monitor publish rates, disconnects, and authentication failures.

This test exposes mapping, buffering, and authorization problems before the gateway enters continuous operation.

When does the broker layer become the bottleneck behind MQTT gateways?

The broker layer becomes a bottleneck when gateway count, connection volume, message frequency, or broker-side state exceeds the capacity of the active deployment.

Typical pressure points include:

• Concurrent gateway connections
• Message frequency across many topic branches
• Retained-message volume
• Persistent sessions and queued messages
• Queue depth and disk usage
• Broker node failures
• Uneven connection distribution
• Permission checks across large topic structures

A simple message-rate estimate provides an initial sizing input:

200 gateways
50 signals per gateway
1 message every 5 seconds per signal

200 × 50 × 12 = 120,000 messages per minute

At that point, broker monitoring, topic design, Quality of Service (QoS), queue limits, and high availability become architecture requirements.

Build a reliable data path from gateway to broker infrastructure

A reliable MQTT gateway architecture starts with clear responsibilities. Gateways translate and normalize local data. Brokers authenticate clients, apply topic permissions, route messages, and provide the shared communication layer.

Your advantages with Cedalo:

• Secure gateway connections through TLS, mutual TLS, role-based access control, and audit trails.
• Central visibility into brokers, clients, subscriptions, and traffic through the Cedalo Management Center.
• Scalable broker infrastructure with clustering and high availability for growing gateway deployments.
• Continued use of Eclipse Mosquitto with added enterprise features for production environments.

MQTT gateway: frequently asked questions

How does an MQTT gateway handle network outages?

Many MQTT gateways store messages locally when the broker or network is unavailable. Queue limits, storage capacity, replay order, message expiry, and duplicate handling determine how reliably the gateway forwards buffered data after reconnecting.

Can an MQTT gateway publish and subscribe at the same time?

Yes. A gateway acts as an MQTT client and can publish device data while subscribing to commands, configuration updates, or control messages. Command paths require restricted permissions, validation, expiry rules, and safeguards for physical equipment.

Which field protocols can an MQTT gateway connect?

Many industrial gateways support several protocol drivers, such as Modbus, CAN, OPC UA, BLE, or serial communication. The available combinations depend on the gateway software, hardware interfaces, processing capacity, and licensing model.

Does an MQTT gateway need a permanent internet connection?

An MQTT gateway can operate on a local network and connect to an on-premises or edge broker. Internet access is only required when the architecture sends data to remote cloud or data-center infrastructure.

Does Cedalo provide MQTT gateway hardware?

Cedalo provides the MQTT broker infrastructure behind gateway deployments. Gateway hardware or edge software handles local protocol access, while Cedalo supports message routing, access control, monitoring, clustering, and broker management.

How does Cedalo support large MQTT gateway deployments?

Cedalo supports distributed gateway environments with clustering, high availability, role-based access control, TLS, and centralized broker monitoring. The appropriate setup depends on gateway count, message rate, session requirements, latency, and availability targets.