What Is IoT and How Do You Build a Connected Device?

IoT (the Internet of Things) is the practice of connecting physical devices—sensors, actuators, appliances—to a network so they can report data and be controlled remotely. You build one by combining four layers: a device-side SoC or MCU, a wireless link (Wi-Fi, Bluetooth LE, Thread, or a low-power protocol like ESP-NOW), a cloud service that stores and routes data, and a phone or web app for the user. A minimal build is achievable with one development board, a vendor SDK, and an open-source cloud platform; the main decisions are power budget, connectivity choice, and whether you need OTA updates and device security from day one.

The four layers of a minimal IoT system

Every connected device, from a smart plug to an industrial sensor, reduces to the same chain:

The data flow is a loop, not a one-way pipe: the device publishes sensor readings to the cloud, the cloud holds the latest state, the app reads that state and sends commands back, and the device acts on them. A light switch that only reports on/off but cannot receive a command is a sensor, not a full IoT device.

Choosing the device side: SoC, MCU, and wireless protocol

The device-side chip determines almost everything downstream. Espressif's product line illustrates the range: the ESP32 family spans general-purpose SoCs (ESP32, ESP32-S3, ESP32-C3, ESP32-C6), plus variants targeting specific needs such as the ESP32-H series for IEEE 802.15.4/Thread and the ESP32-P series for higher-performance applications. The older ESP8266 remains in the catalog for cost-sensitive, Wi-Fi-only designs.

Match the protocol to the job rather than defaulting to Wi-Fi:

• Wi-Fi — mains-powered devices that need direct internet access and higher throughput (cameras, displays, smart speakers).
• Bluetooth LE — battery devices paired to a phone, or provisioning a Wi-Fi device during setup.
• Thread / IEEE 802.15.4 — low-power mesh networks, common in smart-home lighting and sensors (ESP32-H and ESP32-C6 support this).
• ESP-NOW — a connectionless peer-to-peer protocol for low-latency, low-power links between devices without a router, useful for remotes and sensors that talk to a local hub.

Power budget is the deciding constraint. A battery sensor that wakes, reads, transmits, and sleeps can last months on BLE or Thread; a Wi-Fi device that stays associated draws far more and generally wants mains power.

The software stack: SDK, cloud, and app

On the software side, the layers map to concrete pieces:

• Firmware framework — Espressif's ESP-IDF is the general framework, with a component manager for pulling in libraries. Specialized SDKs sit on top: ESP-Matter for Matter-compatible smart-home devices, ESP-BLE-MESH and ESP-Mesh-Lite for mesh networking, ESP-Hosted and ESP-AT for connectivity co-processors, and the ESP-Arduino and Zephyr ecosystems for developers coming from those environments.
• Cloud — ESP RainMaker is Espressif's device-to-cloud-to-phone platform, described as open source, with a public dashboard and client apps (Nova Home and ESP RainMaker) whose source is available. ESP Insights provides remote debugging so you can see device logs and crashes without physical access.
• App — either a vendor-provided app or your own client talking to the cloud API.

The practical advantage of an integrated stack is that provisioning, device authentication, and OTA are handled by the platform rather than rebuilt per project. The trade-off is coupling: a fully open-source platform reduces lock-in, but you still inherit its data model and update path.

A first build, step by step

1. Pick a board. Choose a DevKit matching your protocol—for example an ESP32-C6 board if you want Wi-Fi plus Thread, or an ESP32-S3 board if you need more compute for audio or display work. Confirm the board exposes the pins your sensor needs.
2. Install the toolchain and flash a sample. Set up ESP-IDF, build one of the bundled examples, and flash it. Expected result: serial output confirming the firmware booted. This validates your toolchain before you add complexity.
3. Bring up the sensor locally. Read the sensor over I2C/SPI/ADC and print values to serial. Do not touch the network yet—debugging radio and sensor issues at the same time is where most beginners stall.
4. Connect to the cloud. Provision the device (typically Wi-Fi credentials via BLE or a captive portal), register it with your cloud platform, and confirm it appears in the dashboard. Expected result: the device shows as online and its telemetry updates.
5. Control from the app. Send a command from the phone app and verify the device acts on it. This closes the loop and proves the full chain works.
6. Add OTA and security. Enable firmware updates over the air and confirm device authentication (per-device keys or certificates). Do this before shipping, not after—retrofitting OTA onto deployed devices is painful.

Common failure points and how to diagnose them

• Provisioning fails. Usually a mismatch between the app's expected provisioning method and the firmware's. Check that the device is actually in provisioning mode and that the phone is on a 2.4 GHz network if the chip is 2.4 GHz-only.
• Device drops offline intermittently. Often Wi-Fi signal strength, router DHCP lease expiry, or a watchdog resetting the device. Log reset reasons and RSSI; a device that reconnects cleanly is fine, one that reboots is not.
• OTA update bricks or loops. Caused by insufficient flash partition size, a power loss mid-write, or a version check that rejects the new image. Use A/B partitions with rollback and verify the image hash before switching.
• Cloud shows stale data. The device may be publishing but the cloud topic or data model doesn't match what the app subscribes to. Inspect the raw payload at the cloud side before blaming the firmware.

How to decide

If you are prototyping, start with a mainstream Wi-Fi SoC, the vendor's general SDK, and an open-source cloud platform—you get the fastest path to a working loop. If you are designing for battery life, choose BLE or Thread and design the sleep/wake cycle first. If you are building for a smart-home ecosystem, prioritize Matter support and OTA from the start. In every case, treat security and update capability as selection criteria, not features to add later.