El ESP32 se ha convertido en el microcontrolador por defecto para producto conectado: cuesta poco, trae Wi-Fi y Bluetooth integrados, tiene potencia de sobra para la mayoría de casos y un ecosistema maduro. Pero un dispositivo con ESP32 no es un producto: es media solución. La otra mitad es la app que lo controla y el backend que recoge sus datos. Y ahí es donde la mayoría de proyectos de hardware se atascan.
El problema no es técnico, es de fronteras
El patrón que vemos una y otra vez: el firmware lo hace un proveedor, la app otro y el backend un tercero. El protocolo de comunicación entre el dispositivo y la app —qué bytes viajan, en qué característica GATT, con qué formato— se convierte en tierra de nadie. Cuando algo falla en producción, cada proveedor señala al otro. Construir las tres capas con un solo equipo no es una preferencia organizativa: convierte ese protocolo en un contrato interno que evoluciona de forma coordinada y que se puede depurar de punta a punta.
Las tres capas de un producto conectado
- Firmware ESP32: lo desarrollamos con ESP-IDF o Arduino según el caso, con conectividad BLE (perfiles GATT personalizados), Wi-Fi, gestión de energía (deep sleep para dispositivos a batería) y actualización OTA.
- App Flutter: multiplataforma (iOS + Android) desde un solo código, que empareja con el dispositivo, le envía comandos y lee sus datos.
- Backend en Go: sobre Cloud Run, que ingiere la telemetría por MQTT o HTTP, gestiona la flota de dispositivos (provisioning, configuración remota) y almacena las series de datos.
Por qué el BLE es la parte que más falla
El Bluetooth Low Energy tiene trampas conocidas que hunden los proyectos que las descubren tarde. Estas son las que resolvemos por defecto:
- Reconexión automática: el BLE se cae —por distancia, interferencias o que el SO mata la conexión— y la app tiene que reconectar de forma transparente, sin que el usuario tenga que reemparejar.
- Negociación de MTU: el tamaño de paquete BLE por defecto es minúsculo (23 bytes). Para transferencias grandes —una lectura de datos o una imagen— hay que negociar el MTU al máximo y trocear los datos en la capa de aplicación.
- Colas de comandos: enviar dos operaciones GATT a la vez es un error clásico. Serializamos los comandos en una cola que reintenta hasta confirmar.
- Diferencias iOS vs Android: el ciclo de vida BLE, el escaneo en background y los permisos se comportan distinto en cada plataforma. En Flutter lo abstraemos con flutter_blue_plus y una capa propia que unifica el comportamiento.
- Máquina de estados de conexión: escaneando, conectando, descubriendo servicios, listo, reconectando, error. La app refleja ese estado al usuario en lugar de quedarse colgada.
¿Qué pasa cuando el dispositivo genera datos sin cobertura?
Un sensor no espera a que haya internet para medir. Por eso los datos que llegan del ESP32 entran en la misma arquitectura offline-first que el resto de la app: se guardan en la base de datos local del móvil y se sincronizan con el backend cuando vuelve la conexión, sin perder ninguna lectura. Firmware, BLE y sincronización son un mismo sistema, no tres proyectos.
Del prototipo a producto industrializado
Muchas startups de hardware llegan con un PoC sobre ESP32 que funciona en el laboratorio. El salto a producto es grande: falta robustez del firmware frente a cortes y errores, gestión de energía, seguridad (cifrado, autenticación de dispositivo), OTA para poder actualizar la flota, una app publicable en las stores y un backend que aguante miles de dispositivos. Ese salto es exactamente donde aportamos.
Conclusión
Conectar una app con hardware real no es difícil por el ESP32 —que es una plataforma excelente— sino por todo lo que lo rodea: un BLE fiable, un protocolo bien definido, sincronización sin pérdida y un camino a producción. La forma de que no se convierta en un juego de culpas entre proveedores es construir firmware, app y backend con el mismo equipo. Lo explicamos con más detalle en nuestra página de desarrollo de apps IoT y firmware ESP32 y en integración de hardware.
