Sleep

Many low-power wireless devices feel “not real-time enough”: a contact sensor reports slightly late, a sensor syncs periodically, BLE notifications jitter, or Zigbee and Thread end devices cannot always be awakened immediately.

This is usually not protocol laziness. It is the core trade-off of low-power wireless: a device that wants to save power cannot keep listening to the air all the time. If it does not listen all the time, wake windows, queues, and latency appear.

IoT devices often need to save power. When the screen is off, the network is idle, or sensor sampling is infrequent, the system wants to enter a low-power state.

From the application point of view, sleep can look like “pause for a while and continue when an event arrives.” Inside the system, much more happens.

Device sleep is not just pausing the CPU. The system may stop CPU cores, lower frequencies, gate peripheral clocks, cut power domains, save register state, freeze user processes, run driver suspend callbacks, and leave only a small set of wake sources enabled.