HTTP — the protocol of the web — requires a full request-response cycle for every message. For a temperature sensor that needs to send a reading every 30 seconds, HTTP would require the device to initiate a new connection, send headers, wait for a response, and close the connection. On a battery-powered device with 64KB of RAM and a 2G connection, this is unacceptably expensive.
MQTT was designed for exactly this situation. It uses a persistent TCP connection, tiny packet overhead (as little as 2 bytes of header), and an efficient pub/sub routing model. A sensor can stay connected and publish readings with minimal power draw and bandwidth.
HTTP: each message opens a connection, sends headers (hundreds of bytes), waits for response, closes. MQTT: one persistent connection, 2-byte minimum header, no response needed.
MQTT's keepalive mechanism lets devices sleep between messages. The broker holds messages for offline devices and delivers them when they reconnect.
MQTT fixed header is 2 bytes. HTTP minimum is ~500 bytes. For 10,000 daily readings, MQTT uses ~20KB vs HTTP's ~5MB — a 250x reduction.
One-way message delivery with no acknowledgement overhead at QoS 0. Device-to-subscriber delivery in single-digit milliseconds on a local network.
MQTT uses a publish/subscribe (pub/sub) model — fundamentally different from HTTP's request/response. There are three roles:
The central message router. Receives all published messages and routes them to subscribed clients. The FidesInnova Node includes a built-in broker — you do not need a separate Mosquitto or EMQX installation.
A client (your IoT device) that sends messages to the broker on a named topic. The publisher does not know who is subscribed — it just sends to the topic.
A client (FidesInnova Node, another device, a dashboard) that tells the broker which topics it cares about. The broker delivers any matching published messages immediately.
This decoupling is powerful: publishers and subscribers never need to know about each other. A new subscriber can start receiving data from existing devices without modifying the device firmware at all.
MQTT topics are hierarchical strings using / as separators. FidesInnova recommends a consistent naming convention:
Single-level wildcard (+) matches exactly one topic level. Multi-level wildcard (#) matches any number of levels and must appear at the end of a subscription.
MQTT offers three QoS levels. Choose based on the consequences of message loss or duplication:
Fire and forget. No acknowledgement. Use for high-frequency sensor readings (temperature every second) where occasional loss is acceptable and retransmission would cause outdated data anyway.
Broker acknowledges receipt. Message retransmitted until acknowledged — duplicates possible. Use for alerts and events where loss is unacceptable but duplicate processing is tolerable.
Four-way handshake. No loss, no duplicates. Use for ZKP proof submission, billing events, and actuator commands where exactly-once semantics are critical.
Use QoS 0 for raw sensor streams, QoS 1 for status updates, QoS 2 for proof submissions to the blockchain queue.
The FidesInnova Node broker listens on port 1883 (plain) and 8883 (TLS). Devices connect with a client ID, username (device ID), and password (device token generated by the Node dashboard).
Never use plain MQTT (port 1883) in production. Without TLS, all device credentials and sensor data are transmitted in cleartext — readable by anyone on the network path.
MQTTS (MQTT over TLS, port 8883) provides encryption and server authentication. The FidesInnova Node generates a TLS certificate during setup. Obtain it from your Node dashboard and embed it in device firmware.
For the highest security, enable mutual TLS (mTLS) — each device has its own certificate that the broker uses to authenticate it, eliminating the need for password-based authentication entirely.
LWT is an MQTT feature where a client pre-registers a message with the broker. If the client disconnects ungracefully (power loss, crash, network failure), the broker publishes the LWT message automatically. This is essential for device health monitoring in FidesInnova deployments.
Service Contracts on the FidesInnova Node subscribe to device topics automatically based on the device's registered configuration. A simple Service Contract that reacts to temperature readings:
Next Course
Writing Service Contracts →