Small devices
An IoT (Internet of Things) device is a small computer, often on a battery. This temperature sensor has about 10 KiB of memory; a phone has hundreds of thousands of times more. It wakes, sends a few bytes, then sleeps. Its protocols must be tiny.
Publish / subscribe
MQTT is a tiny messaging protocol. The sensor opens one TCP connection to a broker, a post office for messages, on port 1883. It sends CONNECT with its own client ID and a keep-alive of 60 s. The broker answers CONNACK.
Messages are sorted by topic, a name with levels split by slashes, like home/kitchen/temp. The phone app subscribes to home/+/temp: + matches any one level, so it gets every room's temperature. The broker replies SUBACK.
The sensor publishes 21.5 to home/kitchen/temp, with the retain flag set. It does not know who is listening, or even if anyone is; it only talks to the broker. The whole PUBLISH packet is just 26 bytes.
The broker checks every subscription. home/+/temp matches, so it sends a copy to the phone. With a thousand subscribers it would send a thousand copies; the sensor still sends one. This pattern is called publish/subscribe.
Reliability
Each publish picks a quality of service, QoS. QoS 0: sent once, no reply, may be lost. QoS 1: at least once; the broker answers PUBACK. If none comes, the sensor resends after it reconnects. QoS 2: exactly once, using four packets.
The dashboard starts later and subscribes to home/#: # matches every level below. The sensor had set the retain flag when it published, so the broker kept its last value and sends 21.5 at once, without waiting for the next reading.
With nothing to say, the sensor still sends PINGREQ within 60 s and gets PINGRESP. If the broker hears nothing for 90 s, 1.5 times the keep-alive, it closes the connection and publishes the sensor's last will: "offline".
Gateways and CoAP
This leak sensor speaks only Zigbee, a low-power radio that has no IP addresses. It cannot reach the broker by itself. It sends its alarm by radio to a gateway, a box that speaks both Zigbee and IP.
The gateway turns the alarm into an MQTT publish to home/basement/leak. The dashboard's home/# matches, so it gets the alarm; the phone's home/+/temp does not. Thread devices already have IPv6, so a border router simply forwards them.
CoAP works like the web instead, with no broker. The app asks the device directly, while it is awake: GET /temp, over UDP port 5683, with a 4-byte header. The sensor replies 2.05 Content: 21.5.
Security
Off the home network, MQTT runs inside TLS on port 8883, so nobody can read or fake readings. Every device gets its own password or certificate, never a shared default, and may use only its own topics.
On the wire, in numbers
;; step 1/12 · tiny-device · local ;; at temp sensor temperature sensor (battery, Wi-Fi) address 192.168.1.50 on the home LAN 192.168.1.0/24 memory about 10 KiB RAM, 100 KiB flash: an RFC 7228 "Class 1" device a phone about 8,388,608 KiB (8 GiB): 838,861 times more RFC 7228 classes of constrained devices Class 0 RAM << 10 KiB flash << 100 KiB Class 1 RAM ~ 10 KiB flash ~ 100 KiB Class 2 RAM ~ 50 KiB flash ~ 250 KiB a constrained device cannot afford big protocols, long messages, or keeping its radio on
If the broker receives no packet for 1.5 × the keep-alive (90 s here), it must close the connection (MQTT 5.0 §3.1.2.10). MQTT 5.0 also lets a client delay its will with a Will Delay Interval. Device classes from RFC 7228: Class 0 well under 10 KiB of RAM, Class 1 about 10 KiB, Class 2 about 50 KiB. The sizes are rough guides, not hard limits.