A practical guide to IoT prototyping with ESP32

Connected devices blend hardware, firmware, cloud and software, which is exactly why IoT projects stall. Each layer has its own surprises, and they compound. A focused prototype answers the riskiest questions early, while changes are still cheap.

This guide is the process we use to take an idea from a sketch to a working, connected prototype in weeks. It's written around the ESP32 family because it's our default for prototypes, but most of the steps apply to any microcontroller.

#Why ESP32?

The ESP32 family from Espressif has become a default choice for connected prototypes because it combines:

• Built-in Wi-Fi and Bluetooth (Classic and/or BLE) with no extra radio modules
• Low cost, with development boards widely available
• Plenty of I/O: analogue inputs, I²C, SPI, UART, PWM and capacitive touch
• Low-power sleep modes for battery-powered devices
• Security features such as secure boot and flash encryption on many variants
• A large community and support in Arduino, ESP-IDF and MicroPython

There are several variants: some add USB, AI acceleration or lower power; some trade Wi-Fi features for cost. Choose the variant that matches your connectivity and power needs, but don't over-optimise at the prototype stage.

#Step 1: define the signal

Before buying parts, write down what the device must do:

• What do you need to measure or control? Temperature, motion, current, presence, a door lock?
• How often? Once an hour, once a second, or only when something changes?
• How accurately? A tenth of a degree, or "warm versus cold"?
• Where? Indoors, outdoors, in a vehicle, near water, on a construction site?
• How is it powered? Mains, USB, battery, solar?
• How does data get out? Wi-Fi, Bluetooth to a phone, LoRa, cellular?

These answers choose your sensors, power budget and connectivity, and they reveal the riskiest assumption to test first. For an RFID attendance system, the risk might be read range through a wallet. For a battery-powered sensor, it's usually battery life.

#Step 2: choose your firmware path

We usually prototype with Arduino or MicroPython to prove the concept quickly, then move performance- or security-critical parts to ESP-IDF as the design firms up.

#Step 3: breadboard the core

Wire the sensors to an ESP32 development board and read real values. Keep it messy. The goal is data, not tidiness.

#include <WiFi.h>

void setup() {
  Serial.begin(115200);
  WiFi.begin("ssid", "password");
}

void loop() {
  int reading = analogRead(34);
  Serial.println(reading);
  delay(1000);
}

At this stage, check:

• Do readings look plausible? Compare against a reference instrument if accuracy matters.
• How noisy are they? Do you need filtering or averaging?
• Does the sensor behave the same after an hour, or when warm?
• Does Wi-Fi activity interfere with analogue readings? (On ESP32, some ADC pins are unavailable while Wi-Fi is active, which is a classic early surprise.)

#Step 4: prove the pipeline end to end

Send readings to the cloud and show them on a simple dashboard. An end-to-end pipeline uncovers connectivity, latency and data-format issues while they're cheap to fix.

A typical prototype pipeline:

1. Device publishes readings over MQTT (lightweight and designed for unreliable networks).
2. A broker receives them, either a managed service or a small self-hosted one.
3. A service validates and stores readings in a time-series-friendly database.
4. A dashboard shows live values, history and alerts.

// Publishing a reading as JSON over MQTT (PubSubClient)
char payload[96];
snprintf(payload, sizeof(payload),
         "{\"device\":\"%s\",\"temp\":%.1f,\"ts\":%lu}",
         deviceId, temperature, (unsigned long)time(nullptr));
mqtt.publish("sites/site-1/sensors/temp", payload);

Decide early on a message format (JSON is fine for prototypes), topic structure and device identity. They're painful to change once dozens of devices are in the field.

#Step 5: harden what matters

Once data flows, work through the areas that shape the final product.

#Power

• Measure real current draw in each state (active, transmitting, sleeping) with a proper meter, not estimates.
• Use deep sleep between readings and wake on a timer or interrupt.
• Batch transmissions; the radio is usually the biggest power consumer.
• Model battery life from measurements, then test it.

#Connectivity

• Reconnect automatically after Wi-Fi or broker drops, with back-off.
• Buffer readings offline and send them when the connection returns.
• Handle provisioning: how will a customer put the device on their Wi-Fi? A temporary access point or a BLE set-up app are common approaches.
• Consider LoRa or cellular if Wi-Fi isn't reliable where the device lives.

#Over-the-air (OTA) updates

Every connected device will need a firmware update after it ships. Build OTA in from the first field prototype:

• signed firmware images, so devices only accept your updates
• a fallback partition, so a failed update doesn't brick the device
• staged roll-outs to a few devices before all of them

#Security

• unique credentials per device; never one shared password baked into every unit
• TLS for every connection to the cloud
• secure boot and flash encryption where the variant supports them
• no debug ports or default passwords left open in production
• a plan for revoking a compromised device

#Enclosure and environment

• size and mounting
• heat from the board, the battery and the sun
• dust and water protection (IP rating) for outdoor or industrial use
• antenna placement: metal enclosures block radio signals

#Step 6: field test

Bench tests lie. Put a handful of devices where they'll really live, for at least a couple of weeks:

• watch reconnection behaviour, battery drain and data gaps
• collect feedback from the people installing and using them
• log everything, including resets and their causes

Field tests are where you discover that the warehouse Wi-Fi drops every night, or that a sensor fogs up in the morning.

#Common pitfalls

1. Polishing hardware before the pipeline works. A beautiful enclosure around an unreliable data flow is wasted effort.
2. Ignoring power until the end. Battery life usually forces architectural changes.
3. Hard-coding Wi-Fi credentials. Fine on your desk, impossible for customers.
4. No OTA plan. The first bug in the field becomes a site visit.
5. One shared secret for every device. One leaked device compromises them all.

#From prototype to product

Once the prototype proves the idea, the path to production typically includes:

• Custom PCB design around a pre-certified ESP32 module, which simplifies radio certification
• Production firmware, often in ESP-IDF, with secure boot, OTA and robust error handling
• Provisioning and manufacturing tools to flash, test and register each unit
• A polished app and dashboard for customers and support teams
• Certification appropriate to your markets (radio, electrical safety)

Each step is easier because the prototype already answered the riskiest questions.

#What we've built this way

We've used this approach for RFID access control and automated attendance, and for safety systems that detect protective gear on construction sites. In each case, proving the end-to-end pipeline early saved weeks of rework later.

If you have a connected-device idea, we can take it from first sketch to field-tested prototype and beyond. Read about our IoT and hardware services, see the construction and facilities work, or send us a brief.