Modbus vs OPC UA vs SNMP vs MQTT: which industrial protocol to use in each project

If you are integrating physical equipment with software —HVAC in a technical room, PLCs on the shop floor, ISP routers, field sensors— the first technical decision is which protocol to talk to the equipment. Getting it wrong is invisible at first; six months later it shows up as missing metrics, fragile integrations and support costs nobody budgeted for.

This guide is not an exhaustive manual. It’s the quick decision we make at COL0 when a new project arrives, with the practical criteria so you can make it too.

TL;DR — which protocol by use case

Need	Protocol
Talk to a PLC, drive, meter or industrial device	Modbus (RTU over RS-485 or TCP over Ethernet)
Integrate a modern plant with rich data modeling	OPC UA
Monitor network infrastructure (routers, switches, servers)	SNMP
Stream telemetry from many devices to the cloud	MQTT
Building HVAC, BMS, lighting	BACnet (honorable mention)

If you mix several in one project, you are doing it right. The unusual thing is a real industrial project that uses just one.

Modbus: the plant’s universal language

The oldest (1979) and most widespread. Almost any industrial device speaks Modbus in some flavor:

• Modbus RTU over RS-485 — for plant equipment wired in series. Found in drives, electrical meters, process sensors, industrial scales.
• Modbus TCP over Ethernet — the modern variant, plug-and-play on IP networks.

Choose Modbus when:

• The equipment supports it (check the manual; almost certainly yes).
• You need to read concrete registers: temperature, voltage, weight, status.
• Budget is tight and you don’t need sophisticated data modeling.

Real limits:

• Reads/writes numeric registers only. No complex types, no discovery, no metadata.
• No security. Modbus TCP is cleartext — protect it via VLAN or VPN, never on the open internet.
• Client-server: you must poll. Real-time alerts require pairing it with MQTT.

In Colombian projects we see it in 70% of cases: the question is not “do I use Modbus?” but “is Modbus alone enough or do I need to complement it?”.

If your project lives in this territory, this is the service that covers integration with physical devices we offer at COL0.

OPC UA: when the system warrants it

OPC UA is the modern standard (IEC 62541) for industrial communication. It does not replace Modbus on legacy equipment; it replaces Modbus at the plant layer when the system grows.

Choose OPC UA when:

• Greenfield or major plant modernization — new PLCs (Siemens S7-1500, Allen-Bradley CompactLogix, Beckhoff) speak OPC UA natively.
• You need rich data modeling (not just “register 40001 = 23.5”, but “Motor M1.Speed = 23.5 RPM with timestamp and quality”).
• You need real security: authentication, authorization, TLS encryption.
• SCADA, MES or system integration that already understands OPC UA.

Real limits:

• Heavier than Modbus. A microcontroller cannot implement OPC UA — you need a gateway or a PLC.
• Steeper learning curve for the software team.
• Some commercial implementations carry license costs.

Common plant pattern: legacy equipment over Modbus → gateway normalizes them → exposes via OPC UA to SCADA and MES. Mixing protocols is not a sin; it’s the reality.

SNMP: built for networks

SNMP (Simple Network Management Protocol) is what a router uses to report its state, a printer to report ink level, a server to expose CPU load.

Choose SNMP when:

• Monitoring network infrastructure: MikroTik routers, Cisco switches, firewalls.
• Monitoring physical servers, UPS, PDUs.
• You need operational metrics (not industrial process metrics).
• You want push alerts from the device (SNMP traps) on failure.

Real limits:

• Useless for reading an industrial temperature sensor (use Modbus).
• SNMP v1/v2c have no security. Use v3 in enterprise networks.
• Each vendor ships its own MIBs — integrating requires knowing the device’s OIDs.

If your project is managing and monitoring telecom infrastructure, this is the telecom integration service where we apply SNMP and NETCONF directly.

MQTT: transport for the cloud

MQTT is not a protocol to talk to industrial equipment. It’s a lightweight messaging protocol to ship telemetry from distributed devices to a central platform, typically in the cloud.

Choose MQTT when:

• You have hundreds or thousands of remote devices sending data to a central broker.
• You need connectivity over unstable networks — MQTT is designed to reconnect.
• You want publish/subscribe, not client/server.
• You are building an IoT platform on AWS IoT Core, Azure IoT Hub or your own broker (Mosquitto, EMQX).

Real limits:

• Does not talk to a PLC or router directly. You need an agent or gateway in between.
• The broker is a single point; plan for HA if it’s mission-critical.
• Badly designed topics are a 6-month nightmare — invest in the schema from day one.

The standard IoT pattern: sensors speak Modbus to the gateway → gateway publishes via MQTT to the cloud → the cloud transforms and stores. If you are heading there, this is exactly the IoT development service with real-time dashboards we deliver.

BACnet: a mandatory mention for buildings

If your project is HVAC, lighting or building controls, you’ll likely see BACnet (Building Automation and Control Network). It is to buildings what Modbus is to the plant.

Typical BACnet equipment: Honeywell, Siemens Desigo, Schneider EcoStruxure, Johnson Controls.

Practical tip: if your project is building-only, go BACnet direct. If it mixes plant + building, a gateway that normalizes to OPC UA or MQTT is what avoids six months of pain.

How we decide on real projects

In the first hour of technical discovery we ask five questions:

1. Which concrete equipment will we integrate? Brand, model, year. Without this, no protocol conversation is real.
2. Which protocols does that equipment support per the manual? What the equipment supports constrains the choice before any preference.
3. Where does the data go? A local SCADA? Likely OPC UA. The cloud? MQTT. An internal dashboard? Depends on volume.
4. Do we need data modeling or just reads? Modbus is enough for reads. OPC UA is for modeling.
5. Is the network plant, telecom or mixed? SNMP does not integrate plant equipment. Modbus does not monitor routers. They don’t cross.

If your project needs this decision well-structured, download the free feasibility guide we share with clients —it includes the full equipment-and-protocol validation checklist— from the banner below. Or write us directly from contact or via WhatsApp and let’s talk in a 30-minute call, no strings attached.

Typical mistakes we avoid

1. Choosing the “modern” protocol without device support. OPC UA is useless if your 2015 drive only speaks Modbus RTU.
2. Confusing industrial protocol with transport. Modbus and MQTT don’t compete; they complement. Modbus reads the equipment, MQTT moves the data far.
3. Forgetting security. Modbus TCP and SNMP v2c on a corporate network are tickets to an incident. VLAN, VPN or firewall — mandatory.
4. Reinventing what exists. If the equipment has a documented standard integration, use it. Don’t invent proprietary protocols.
5. Not testing with the real device. Datasheets lie. Test reads/writes on a physical device before committing architecture.

---

Are you mid-integration and unsure which protocol is right? At COL0 we’ve integrated dozens of devices across Colombian industrial sectors. Tell us your case and we’ll let you know in a single call which path to take.