From ESP32 prototype to cloud-connected product.

The gap after the successful demo

A prototype usually proves sensor reading, motor actuation or a wireless connection on the workbench. Real deployment introduces weak networks, power interruptions, noisy sensors, device identity, firmware bugs and users who cannot attach a debugger.

Product engineering begins by writing failure scenarios: What happens when Wi-Fi disappears? What happens when the backend is unavailable? Can the device safely restart? Does a failed actuator leave equipment in a safe state?

Build reliability at the device layer

Firmware should separate sensor input, local control decisions and connectivity. If cloud communication fails, the device must continue its safe essential behaviour and buffer only the telemetry it can manage.

• Use watchdog recovery and deliberate boot-state handling.
• Store configuration safely and validate it before applying changes.
• Include firmware version, battery or supply state and signal quality in telemetry.
• Use unique device identities and protected credentials rather than a shared key in firmware.

{ 
  "device_id": "wisk-042",
  "firmware": "1.4.2",
  "timestamp": "device-clock-or-server-time",
  "telemetry": { "battery": 81, "temperature": 27.4 },
  "health": { "wifi_rssi": -55, "last_restart": "watchdog" }
}

Design the cloud ingestion path

Telemetry needs a controlled entry point that authenticates the device, validates payloads and handles intermittent connectivity. For high-volume or unreliable connections, a message broker or queued ingestion layer prevents a slow downstream processor from blocking devices.

Store operational telemetry separately from device commands. Commands such as firmware updates or motor actions need acknowledgement, expiry and audit records. A dashboard should show the last known device health without implying stale data is live.

Operate a fleet, not only one device

Once multiple units are deployed, firmware rollout becomes a release-management problem. Roll out updates to a small test group first, monitor failures and support a fallback version where hardware allows it. Record hardware revision alongside firmware because circuit changes may affect behaviour.

IoT succeeds when electronics, firmware, cloud services and field operations are designed together. The product is the entire loop, not only the board on the bench.