Groundrun automatiza 5 métodos de provisioning Wi-Fi en ESP32

Por qué el primer arranque Wi-Fi decide si un producto conectado sobrevive

El ESP32 de Espressif se ha convertido en el microcontrolador de referencia para productos IoT por una combinación difícil de igualar: Wi-Fi y Bluetooth integrados, soporte de batería, interfaz USB y un precio que ronda los USD 4–5 por módulo según reseñas del sector (Geeky Gadgets, 2025). Esa accesibilidad explica por qué startups y fabricantes lo eligen para prototipos y producción.

Pero hay un momento en el ciclo de vida del producto donde esa ventaja competitiva se juega entera: la primera vez que el usuario final configura la red Wi-Fi. Si ese paso falla, el dispositivo vuelve a la caja y la promesa del «producto conectado» muere en el onboarding. El equipo de Groundrun lo plantea sin rodeos: «lo primero que hace un cliente con un producto conectado es completar el setup Wi-Fi, así que tiene que funcionar siempre».

Groundrun: qué es y qué resuelve

Groundrun es una plataforma de pruebas con hardware en el bucle (hardware-in-the-loop, HIL) orientada a dispositivos conectados. Su propuesta es llevar el dispositivo físico, un teléfono y un router a un mismo «rig» automatizable para que un agente de IA —en su caso, Claude Code— ejecute flujos de usuario reales y valide resultados, tanto en modo interactivo como en integración continua (CI).

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

En la práctica, conectar el setup es trivial: un ESP32-C6 por USB al rig y un Android por USB al mismo rig. A partir de ahí, la plataforma registra cada paso (flasheo, lanzamiento de la app, ejecución del mecanismo de provisioning, confirmación de unión a la red) con su tiempo individual.

Los 5 métodos de provisioning Wi-Fi que compararon

El ESP32 soporta al menos cinco mecanismos de configuración de red. Groundrun decidió probarlos todos en igualdad de condiciones:

Bluetooth (BLE): el teléfono se empareja con la placa y envía SSID y contraseña directamente.
Soft AP: la placa levanta una red Wi-Fi temporal; el teléfono se conecta a ella, envía las credenciales reales y la placa salta a la red del hogar.
Captive portal: variante del Soft AP, pero el teléfono es redirigido a una página web de login estilo hotel o aeropuerto, sin app necesaria.
SmartConfig (ESPTouch v2): tecnología propietaria de Espressif, integrada en su ESP-IDF. El teléfono permanece en la red del hogar y transmite las credenciales como paquetes codificados; la placa las escucha en modo promiscuo.
WPS (Wi-Fi Protected Setup): estándar de la Wi-Fi Alliance. Pulsar un botón del router basta para que la placa negocie las credenciales directamente, sin app.

Cómo se monta el banco de pruebas

El artículo detalla el stack que usaron y que cualquier equipo puede replicar:

App móvil mínima generada con Claude: solo necesita enviar los bytes correctos en el momento correcto para cada uno de los cinco métodos. No está pensada para producción; es instrumental.
Firmware generado también con Claude Code, asistido por las skills específicas para ESP32 que provee Groundrun. El artículo muestra el bloque app_main del flujo WPS como ejemplo de código resultante.
Flujos de usuario definidos paso a paso en el constructor de flows de Groundrun, uno por método, ejecutables tanto manualmente como en CI.
Medición de tiempos por etapa: flasheo, instalación y arranque de la app, mecanismo en sí, y espera de confirmación de unión a la red.

Resultados: WPS gana en velocidad, Soft AP pierde por goleada

La parte más útil del artículo para founders de producto son los números comparativos:

Flash y boot se mueven entre 22 y 24 segundos en cuatro de los cinco métodos. SmartConfig se dispara a 37 segundos porque requiere flashear una segunda placa que escucha el broadcast.
Aislando solo el tiempo del mecanismo de provisioning, Soft AP tarda casi 13 veces lo que WPS. La diferencia se explica por los diálogos del sistema operativo y los saltos de pantalla que Soft AP dispara en el teléfono.
SmartConfig y WPS quedan por debajo de los 15 segundos en la fase del mecanismo, muy por delante de Bluetooth, Soft AP y captive portal.

Quirks reales que aparecieron al probar los 5 en paralelo

Más allá del cronómetro, la comparación destapó fallos de diseño que solo se ven cuando el dispositivo, el teléfono y el router interactúan de verdad:

Captive portal es el más traicionero: la página de login se cierra automáticamente tras unos segundos y depende del sistema operativo del teléfono decidir cuándo. Si el formulario no se completa y envía dentro de esa ventana, las credenciales no llegan a la placa.
Bluetooth y Soft AP disparan pop-ups del sistema antes de que el teléfono se una a la red de la placa. Esos pop-ups tardan varios segundos en aparecer mientras el teléfono escanea, así que los tests deben esperarlos.
WPS prescinde de app: basta pulsar el botón del router para que el intercambio de credenciales ocurra entre router y placa.
SmartConfig fue notablemente más lento que los otros cuatro y tuvo fallos puntuales sin causa trazable, un patrón típico de mecanismos que dependen de condiciones de radio difíciles de reproducir.

Por qué Groundrun tuvo que actuar como router en las pruebas WPS

WPS requiere un router real, así que el rig levanta su propia red Wi-Fi temporal para cada corrida, fijada en 2.4 GHz porque la radio del ESP32 no llega a 5 GHz, y la apaga al terminar. Este detalle importa para cualquier founder: documentar en el firmware que el dispositivo solo opera en 2.4 GHz evita horas de depuración cuando un cliente prueba en una banda y la app en otra.

Qué significa esto para tu startup

Si tu producto depende de que un usuario final conecte un dispositivo a su Wi-Fi, esta comparativa te ahorra meses de prueba y error. Tres acciones concretas para implementar esta semana:

Elige el mecanismo de provisioning antes de escribir la app. WPS es el más rápido y el que menos depende del teléfono, pero exige un router compatible y un botón físico. SmartConfig parece elegante (no requiere cambiar de red), pero en las pruebas fue el más lento y el menos determinista. Si tu usuario promedio es no técnico, BLE sigue siendo el camino más predecible aunque no sea el más rápido.
Mide el tiempo de cada fase, no solo el total. Groundrun separa flasheo, arranque de app, mecanismo y confirmación. Esa descomposición es la que permite saber si un cuello de botella está en tu firmware o en el sistema operativo del teléfono. Sin esa granularidad, optimizarás a ciegas.
Pon las pruebas de provisioning en CI desde el día uno. El artículo insiste en un punto clave: cualquier cambio en el sistema (firmware, app, backend) puede romper el onboarding. Una regresión silenciosa en el setup Wi-Fi es invisible hasta que el soporte técnico se inunda de tickets.

El rol de Claude Code como ingeniero de QA

Un detalle que vale la pena subrayar: en este flujo, Claude Code no solo escribe código, sino que también ejecuta los tests porque tiene acceso al rig y a sus habilidades (skills) de ESP32. El equipo le da el plan, el objetivo y la condición de parada, y el agente itera solo. Para una startup de hardware sin un equipo grande de QA, este modelo «agente con hardware en el bucle» es probablemente el atajo más concreto hacia calidad del producto que se ha visto en 2026.