There is a vibration sensor bolted to a 200-tonne stamping press. Every second it has something to say — RMS velocity, bearing temperature, a peak count. Two aisles over, a flow meter reports once a minute and does not care about anything else. Both need to reach the historian and the alarm engine, over a network that was sized for PLC traffic. At some point in the design review, someone asks: MQTT or CoAP?

Both work. The deciding factors are rarely about which protocol is theoretically better. They are about session lifetime, who starts the conversation, how the packets travel, and how you plan to manage a few hundred device identities. Here is how to think it through.

Two Protocols, Two Mental Models

MQTT: a persistent line to a broker

MQTT is publish/subscribe over TCP. Each device holds a long-lived session with a broker, publishes to topics such as plant1/press3/vibration/rms, and subscribes to whatever it cares about. Delivery is graded: QoS 0 is fire-and-forget, QoS 1 is at-least-once, QoS 2 is exactly-once with extra round trips. Retained messages hand a new subscriber the last known value immediately, and the last-will message flags a device that dropped off without saying goodbye. MQTT 5 adds shared subscriptions, user properties and clearer reason codes.

CoAP: a small HTTP for constrained devices

CoAP is request/response over UDP, modelled on HTTP. A client issues a GET to a resource like /sensors/press3/vibration, and the reply fits in a handful of bytes. Messages are either confirmable, meaning they are retransmitted until acknowledged, or non-confirmable, meaning they are sent once and forgotten. The Observe option turns a GET into a lightweight subscription. Resources are discoverable at /.well-known/core, and LwM2M — the standards-based stack for device registration, firmware updates and bootstrap — is built on CoAP.

Overhead: It Depends on the Conversation Pattern

CoAP wins the raw header contest. A minimal CoAP message is a four-byte header plus options, over a connectionless transport with no handshake. MQTT's fixed header can be as small as two bytes, but each device first pays for a TCP handshake, then a TLS handshake, then periodic keepalive pings to hold the session open.

That difference flips depending on how chatty your devices are. A press sensor reporting every second on a persistent MQTT session amortises its setup cost across thousands of messages, and the broker's fan-out means one publish reaches the historian, the dashboard and the alarm engine without extra traffic from the device. A meter that reports once a minute, or a valve position sensor that is polled only when an operator opens a screen, looks wasteful maintaining a session for 99 percent idle time. CoAP's short exchanges and occasional Observe subscription fit that pattern neatly.

For battery-powered nodes on 802.15.4 or sub-GHz radios, radio time is the currency. TCP retransmissions and keepalives cost real energy, which is why MQTT-SN exists as a UDP variant for sensor networks. If your nodes run on harvested power or a coin cell, weigh this heavily.

Reliability: Different Guarantees, Different Failure Modes

  • MQTT QoS 1 gets you at-least-once delivery. Duplicates happen, so deduplicate downstream using a message ID or timestamp rather than assuming one publish equals one row in the database.
  • MQTT QoS 2 removes duplicates at the cost of extra round trips per message. Use it where a duplicate genuinely causes trouble, not by default.
  • TCP ordering keeps messages in sequence per topic, but head-of-line blocking means one stalled segment holds up everything on that socket.
  • CoAP confirmable messages retransmit with exponential backoff until acknowledged, so you know whether a reading arrived. Non-confirmable messages can vanish silently, which is fine for routine telemetry and wrong for alarm paths.
  • No broker buffering in CoAP. If a sleeping collector is unreachable, the data is gone unless the device or a gateway queues it.

One boundary worth stating plainly: neither protocol belongs in a functional safety function. Keep interlocks and safe stops in the safety controller. MQTT and CoAP carry diagnostics, trends and supervisory commands, and they should be designed so that losing them degrades visibility, not safety.

Security: Same Work, Different Plumbing

Both protocols have mature transport security. MQTT over TLS typically runs on port 8883 with mutual authentication and broker ACLs that restrict which device can publish to which topic. CoAP runs over DTLS with pre-shared keys or certificates, or over TLS when you have a reliable transport, and OSCORE adds object-level protection that survives proxies.

The practical work is identical and mostly unglamorous: run an internal certificate authority, issue unique credentials per device, keep an inventory mapping serial numbers to identities, and have a rotation and revocation path. Pre-shared keys are easy to deploy across a thousand devices and painful to rotate, which is how they end up in a spreadsheet nobody owns. Decide this before the pilot, and terminate traffic at a gateway or broker in a plant DMZ rather than exposing the corporate network to device traffic directly.

Deployment Trade-offs on a Real Factory Floor

  • Firewalls and NAT. MQTT clients dial out to a broker and work almost anywhere. CoAP clients also initiate, but a CoAP server sitting behind NAT needs LwM2M queue mode or a gateway to be reachable.
  • Existing infrastructure. If a broker already feeds your dashboards, adding CoAP means a second stack or a CoAP-to-MQTT bridge at the edge.
  • Discovery and multicast. CoAP can discover peers over multicast, and plenty of industrial switches and Wi-Fi controllers handle multicast badly. Test it.
  • Fleet management. LwM2M over CoAP gives you registration, bootstrap and over-the-air updates as a standard. MQTT leaves that to your platform vendor or your own scripting.
  • Data modelling. MQTT topics are flexible, and that flexibility curdles into inconsistency. Define the namespace before device number fifty. CoAP resources map naturally to a device tree.

A Short Checklist Before You Commit

  1. Write down the traffic pattern: device count, reporting interval, payload size, one-way or bidirectional.
  2. Check the power budget. Mains-powered gateway or battery node? That answer alone often decides it.
  3. Verify the network path end to end: is outbound TCP 8883 allowed, and is UDP forwarded without aggressive timeouts?
  4. Ask who manages the fleet for the next five years. Standards-based provisioning and OTA favour LwM2M over CoAP; an existing MQTT platform favours staying put.
  5. Consider the hybrid, which is what most plants actually build: CoAP to constrained devices, bridged into MQTT for everything upstream.
  6. Pilot ten devices for two weeks and measure reconnects, battery draw and message loss before standardising.

The Sensible Default

If your devices have mains power, your brokers already exist, and you need one publish to feed several consumers, MQTT is the lower-friction choice and will not embarrass you at scale. If your nodes are battery-powered, intermittent, or you want a standard story for provisioning and firmware updates, CoAP with LwM2M earns its place. Mixed estates are normal, and a bridge at the gateway is cheaper than rewriting a working network.

Pick the option that fits the devices you can actually buy, the network you actually own, and the team you actually have. Then test it with real hardware on a real VLAN before anyone signs a purchase order.

Photo: Brett Sayles / Pexels