ALLPCB
Common IoT Protocols
First, an overview of common IoT protocols.
Typical protocols include:
- HTTP. Since IoT evolved from the Internet, the dominant Internet protocol HTTP is still used by many capable devices.
- CoAP. Although sometimes criticized, CoAP remains active in many IoT deployments.
- Other protocols. You can also find DDS, AMQP, XMPP, OPC UA and others used for IoT.
Why MQTT Won Out
Based on long-term observation of MQTT, several factors explain its widespread adoption.
1. Protocol characteristics
MQTT has several properties well suited to IoT: it runs over TCP, has low transmission overhead, and a lightweight protocol stack. Many industrial IoT devices are implemented on microcontrollers or small CPUs with very limited memory and storage, so a compact protocol stack matters.
These devices are often deployed in the field where persistent online status tracking is important. MQTT's TCP connection model and keepalive mechanism are well suited to report device online/offline status. Combined with MQTT's publish/subscribe messaging model, it is highly appropriate for many IoT scenarios.
2. Increasing acceptance
Early successful IoT projects using MQTT earned positive feedback from both customers and vendors, encouraging broader adoption.
3. Lower learning and usage cost
As MQTT adoption grew, learning resources and SDKs became widely available. There are open source SDKs that let newcomers get started quickly. Vendors and module makers also wrapped MQTT into ready-to-use SDKs on development boards and IoT modules, so developers only need to configure domain names, topics, and related information to connect.
Many platform providers also publish SDKs adapted to their servers, so in practice MQTT code is often plug-and-play compared with earlier days when developers had to implement the protocol stack themselves.
4. Ecosystem development
MQTT has been used in IoT for several years, and practitioners tend to share good practices. Engineers and product managers who worked on MQTT projects often move to new companies or rise to decision-making positions, which leads subsequent projects to favor MQTT. Additionally, more graduates who studied IoT at university already have hands-on MQTT experience, reducing onboarding effort for new projects. These dynamics helped form a healthy MQTT ecosystem.
5. Bridging IT and OT
MQTT has helped bridge information technology (IT) and operational technology (OT). IT typically focuses on development, while OT focuses on product operation and maintenance. Successful IT/OT integration requires balancing development and operational costs including time, personnel, funding, and training.
For IT, MQTT is mature, with many project examples and reusable knowledge, so development cost is lower. For OT, MQTT is no longer unfamiliar, reducing the need for extensive training and enabling product operation and management without large upfront learning costs. In some simple product architectures, the same team handles both development and operation, blurring the IT/OT separation.
Comparing MQTT and OPC UA
To illustrate differences, a metaphor can help. OPC UA is like a high-speed rail network where each station is a rich, comprehensive node in a structured network. OPC UA defines extensive models and services potentially eliminating the need for extra components.
MQTT is like a small delivery tricycle: it is lightweight, flexible, and well suited for simple, frequent deliveries. MQTT topics act like different parcels on the vehicle, each parcel destined for a different subscriber. For many IoT use cases where devices only need to send occasional sensor readings, MQTT's lightweight delivery is sufficient and more practical than a full-featured OPC UA deployment.
Security is another consideration. Plaintext MQTT is like an open tricycle where contents are visible. Encrypted MQTT over TLS or other transport-level protections corresponds to an enclosed vehicle offering better privacy and integrity.
Product Directions for MQTT
Typical MQTT-related product directions include platform, device, and integrated device-plus-platform offerings.
1. Platform direction
IoT platforms focus on server-side capabilities and are often B2B products. Providers develop scalable platforms, APIs, and SDKs for devices to connect. Platform vendors must consider data security and large-scale device access. IoT device counts and simultaneous connections can far exceed consumer app concurrency seen during major shopping events, so the server architecture must handle high concurrency and data throughput.
These products emphasize software value and data services, including data interfaces for user applications and built-in support for device connectivity via MQTT.
2. Device product direction
Hardware device vendors produce gateways, sensors, and consumer devices. Device products can target B2B or consumer markets depending on product planning. Consumer products such as smart home devices often combine the device with a WeChat mini program or mobile app for user interaction.
Industrial gateways focus on reliable online presence and broad protocol support for controllers and PLCs. Many gateways support Modbus, Siemens, Omron, and other data acquisition standards, and nearly every industrial gateway on the market supports MQTT as a connectivity option.
3. Integrated device and platform
Some vendors offer both gateway hardware and an integrated platform. For system integrators, platform choice affects which gateways to select, and vice versa. Choosing a gateway often requires checking compatibility with selected cloud platforms and expected controllers or PLCs, as well as estimating software development and ongoing operational costs for data integration.
Integrated offerings provide an out-of-the-box platform, client management tools, historical data storage, and cloud configuration capabilities, and they may also support MQTT integration with third-party platforms.
Solution and Consulting Products
Another product direction is providing tailored solutions and consulting. These offerings require domain knowledge and product architecture design. Effective product work needs both technical understanding and awareness of the product background and target use cases.
Conclusion
MQTT's lightweight design, reliable TCP-based connection model, wide community adoption, available SDKs, and growing platform support have created an ecosystem that fits many IoT scenarios. For applications that need simple, efficient message delivery, MQTT remains a practical choice. For deployments requiring richer data models and built-in semantic interoperability, protocols such as OPC UA may be more appropriate. Choosing the right protocol depends on device constraints, security requirements, and the overall system architecture.
