MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe protocol — devices talk only to a broker in the middle, never directly to each other. It became an OASIS open standard in 2014 and is the default for IIoT because a 2-byte header and store-and-forward delivery survive weak, high-latency networks. Rayin's 8+4 Gigabit managed industrial switches sit at the edge as the MQTT carrier layer, keeping sensor traffic on its own VLAN away from the control plane.
MQTT runs over TCP: cleartext port 1883, TLS port 8883; the smallest header is just 2 bytes versus hundreds for HTTP.
A message = topic (slash-layered, e.g. plant/line1/temp) + payload + QoS (0 at-most-once, 1 at-least-once, 2 exactly-once).
Keep Alive heartbeat and session resume let a device reconnect after a flicker and still get its QoS 1 messages — no lost batch from one dropout.
The switch does not run MQTT; it carries the traffic. Rayin managed switches isolate and bandwidth-guard the MQTT flow with VLAN and ACL.
MQTT is a publish/subscribe (pub/sub) model, not HTTP's request/response. A device only ever speaks to the broker: the one sending data is the publisher, the one receiving is the subscriber, and the two never meet. That decoupling is the whole point — add a device and it just subscribes to its topic; you do not rewire the network.
The broker routes by topic, a slash-layered string like factory/line1/temperature. Subscribers use wildcards to pick the slice they care about. QoS sets the delivery promise: QoS 0 fires once with no ack (fine for a stray temperature point), QoS 1 is retried until received (status and alarms), QoS 2 is confirmed exactly once (metering and billing where duplicates are unacceptable).
| QoS | Delivery | Best for |
|---|---|---|
| 0 | At most once, no ack | Occasional spot readings (temp, humidity) |
| 1 | At least once, may repeat | Device status, alarms — must not be lost |
| 2 | Exactly once, heaviest handshake | Metering, billing — never duplicate or drop |
1. Lightweight — saves bandwidth and battery. A 2-byte header plus a small payload lets a battery sensor that reports every few days still run for years, and narrowband links (NB-IoT, LoRa) cope.
2. Async and decoupled — devices wait on no one. PLCs, meters, and gateways on the line just publish to the MQTT broker; SCADA and cloud platforms just subscribe. One end drops without blocking the other. Add a device and it gets data by subscribing to its topic — no topology change.
3. Weak-network resilient — resumes after a dropout. Keep Alive and session state (Clean Session flag) mean that after a brief disconnect, the broker replays the device's QoS 1 messages on reconnect, so a single outage loses no whole batch.
4. One-to-many, many-to-one distribution. One temperature sensor publishes once; a dozen back-end systems subscribe at once — no pushing to each in turn. Reverse works too: a platform sends one control command and every controller subscribed to that topic gets it simultaneously.
Industrial equipment data collection. A plant sends PLC, VFD, and meter data up through an edge gateway over MQTT, then aggregates to SCADA or cloud for monitoring and predictive maintenance — the most common production-line use.
Remote metering and asset tracking. Water, electricity, and gas meters, plus low-power asset tags, report readings or position on a schedule over MQTT; the back end bills and inventories centrally, no manual patrol.
Environmental and agriculture monitoring. Soil moisture, greenhouse temperature, and sump level sit in scattered, poor-coverage spots — MQTT's low overhead and offline resume fit exactly.
Power and oil-and-gas remote monitoring. RTUs and DTUs at substations, wellheads, and pipelines send telemetry and alarms back to the center over MQTT; more stable than poll-style protocols on weak links.
Vehicular and edge computing. Vehicles, roadside units, and chargers exchange status and events over MQTT; pub/sub is a natural fit for real-time distribution to many endpoints.
Step 1 — Open the broker path. Allow the broker address and ports 1883 / 8883 in the switch's uplink policy so MQTT traffic can reach the broker or cloud.
Step 2 — Name topics by convention. Use site/device/point (e.g. plant1/meter3/voltage) so back-end systems subscribe cleanly and no topic collides.
Step 3 — Encrypt and isolate over public links. For cloud over the public internet, use 8883 with username/password plus ACL; keep the MQTT flow on its own VLAN away from the management plane so one noisy topic cannot crowd the control link.
How do I choose between MQTT and HTTP? Many devices, weak network, real-time push — pick MQTT. An occasional web page or REST pull — HTTP is simpler. On a line with thousands of endpoints reporting continuously, MQTT's bandwidth and distribution wins are clear.
Is QoS 2 the most reliable, so should I always use it? No. QoS 2 has the heaviest handshake and cost; reserve it for billing or metering where "never duplicate, never drop" matters. Most status values are fine at QoS 1, plain spot readings at QoS 0.
What is the difference between 1883 and 8883? 1883 is cleartext, 8883 is TLS-encrypted. Use 1883 inside an isolated internal network; use 8883 over the public internet or to cloud, or the data is exposed in clear.
Does the switch need to support the MQTT protocol? Usually not. The switch is a Layer 2/3 carrier that forwards MQTT to the broker; the actual MQTT clients are the PLC, gateway, or edge box. A Rayin managed switch's job is to isolate that flow and guard its bandwidth.
What happens if the broker goes down? The publisher cannot connect and cannot send. With QoS 1 and session state, the broker replays offline messages after recovery; for critical systems run the broker in primary/standby so there is no single point of failure.
Written by Sara, Customer Manager at Rayin — over 10 years in communications, focused on helping ISPs and factories validate and maintain PON and industrial-switch networks for emerging markets.
About Rayin → https://www.szrayin.com/Profile/
