IoT Protocol Scenario Selector

IoT Protocol Scenario Selector

Compare common IoT application protocols against scenario requirements

animation
protocol-selection
application-protocols
iot
A guided protocol-selection animation that compares MQTT, CoAP, AMQP, HTTP, and WebSocket against latency, reliability, payload, power, pub/sub, and bidirectional communication needs.
Animation Application Protocols Beginner Selector

IoT Protocol Scenario Selector

Describe the application first, then compare common protocol families. The selector shows why a protocol is a good starting point, what tradeoff to check next, and why there is rarely one universally correct IoT protocol.

CoAP Recommended start
84% Scenario match
MQTT Closest alternative
read Next review action
TryLoad constrained telemetry, set Power constraint High and Publish/subscribe need Yes, then press Play.
ObserveThe leading score and runner-up change as six requirements appear, showing why MQTT, CoAP, HTTP, or WebSocket fits differently. Step confirms this readout.
ExplainWeighted matching rewards brokered fan-out for pub/sub and simpler exchanges when device overhead is the dominant constraint. Step exposes this mechanism.
Technical boundariesThe selector excludes topology, implementation quality, broker cost, regulation, security operations, legacy integration, and measured network behavior.
Colour keyapp protocols identitycurrent / primaryreference / datasuccesscautionerror / failure
1. Scenario Start with the device, network, data pattern, and power limit.
2. Requirements Move the sliders to express what matters most.
3. Match Compare each protocol against the same requirements.
4. Tradeoff Read the runner-up and the cost of the top choice.
5. Verify Check security, payload, network, and operations before choosing.

Battery Sensor Match

--

--

--

Scenario Controls

Choose a preset, then tune the requirements to see how the recommendation changes.

can waitreal time
best effortstrong delivery
tiny messageslarge transfers
mains poweredbattery tight
request responsepub/sub
occasional uplinkfull duplex
Protocol Quick Reference

MQTT

  • Brokered publish/subscribe over TCP.
  • Useful for telemetry, device fleets, retained state, and QoS choices.
  • Check broker availability, topic design, TLS, and client identity.

CoAP

  • REST-like protocol commonly used over UDP.
  • Useful for constrained devices, small messages, and request/response control.
  • Check confirmable messages, DTLS or OSCORE, and proxy needs.

AMQP

  • Message-oriented protocol with queues, routing, and delivery semantics.
  • Useful for enterprise back ends and reliable workflows.
  • Usually heavier than MQTT or CoAP for very small devices.

HTTP

  • Universal request/response API model over TCP/TLS.
  • Useful for firmware, provisioning, REST APIs, and web integration.
  • Can be high overhead for frequent tiny telemetry messages.

WebSocket

  • Persistent full-duplex channel after an HTTP upgrade.
  • Useful for dashboards, live commands, and presence.
  • Check connection lifetime, backpressure, authentication, and reconnection.
Technical Accuracy Notes

Teaching score

The match score is a simplified teaching model. It helps compare tradeoffs, but it is not a standard, certification, or performance guarantee.

Security layer

MQTT, AMQP, HTTP, and WebSocket commonly use TLS. CoAP commonly uses DTLS or OSCORE. Identity, authorization, and key management still matter.

Power reality

Protocol overhead is only one part of energy use. Radio wake time, keepalive intervals, retransmissions, and payload frequency often dominate.

Protocol variants

Real deployments may use MQTT-SN, HTTP/2, HTTP/3, CoAP Observe, gateways, or vendor-specific constraints. Use this page to shortlist, then verify.

Practice Prompts

Battery sensor

Start with Battery sensor. Increase reliability and lower pub/sub. Why might CoAP and MQTT trade places?

Live dashboard

Select Live dashboard and lower bidirectional streaming. Which protocol becomes competitive, and why?

Firmware job

Select Firmware job. Which requirement makes HTTP look reasonable even though it is not the lightest protocol?

Enterprise queue

Select Enterprise queue and raise power constraint. What does that reveal about back-end protocols versus device-edge protocols?