Saltar al contenido
Polarity
Volver al blog

Cinco cosas que rompen un ESP32 en producción (y ninguna es el código)

El firmware funcionaba perfecto en el escritorio. A los once días en planta, la mitad de los dispositivos estaba mudo. Esto fue lo que encontramos.

Polarity · 18 de agosto de 2026 · 3 min

Un prototipo que funciona sobre la mesa y un dispositivo que funciona seis meses atornillado a una máquina son dos productos distintos. Lo aprendimos caro: de los primeros veinte nodos que instalamos en una planta, nueve dejaron de reportar antes del día doce.

Ninguna de las causas estuvo en la lógica del programa. Estas son, en orden de frecuencia.

1. La alimentación, siempre la alimentación

El ESP32 pide picos de corriente de varios cientos de miliamperios cuando enciende la radio WiFi. Una fuente que en reposo se ve perfectamente estable colapsa en ese instante, el voltaje cae por debajo del umbral, y el chip se reinicia. Desde el punto de vista del software parece un cuelgue aleatorio.

Lo que hacemos ahora en todos los diseños:

  • Un condensador electrolítico de al menos 470 µF cerca del módulo, con uno cerámico de 100 nF en paralelo.
  • Fuente dimensionada al pico, no al promedio. Si el consumo medio es 80 mA, la fuente es de 1 A.
  • Medición del riel de alimentación con osciloscopio durante el arranque de la radio, antes de cerrar la carcasa.

2. El WiFi de la planta no es el WiFi de la oficina

La red industrial tiene portales cautivos, cambios de contraseña sin aviso, saturación por turnos y puntos de acceso que se reinician de madrugada. Un dispositivo que asume que la red siempre está ahí va a fallar.

La regla que seguimos: el dispositivo debe seguir midiendo y guardando aunque no haya red, y reintentar con espera creciente. Si pierde la conexión, almacena en memoria flash y descarga el buffer cuando vuelva. Nunca bloquear la lectura esperando a la red.

3. El watchdog apagado "temporalmente"

Alguien lo deshabilita para depurar y nunca lo vuelve a activar. Meses después, un bloqueo en una librería de terceros deja al dispositivo colgado indefinidamente, y hay que ir físicamente a desconectarlo.

Activa el watchdog de hardware desde el primer día y trata cada reinicio que dispare como un defecto que hay que investigar, no como algo normal.

4. El calor

Dentro de una caja cerrada, al sol o cerca de un motor, la temperatura interna sube muy por encima de la ambiental. El ESP32 tolera bastante, pero los reguladores de voltaje baratos no, y los condensadores electrolíticos envejecen mucho más rápido.

Mide la temperatura interna y repórtala junto con los datos del proceso. Es el indicador más barato de que un dispositivo va a fallar pronto.

5. No poder actualizar sin ir en carro

Este no rompe el dispositivo, pero rompe el presupuesto. Si para corregir un error hay que visitar cuarenta puntos distribuidos en seis estados, el costo del error se multiplica.

Actualización por aire desde el primer prototipo, con dos cosas obligatorias: verificación de firma del firmware y partición de respaldo para volver a la versión anterior si el arranque falla. Un dispositivo inalcanzable que aceptó una actualización defectuosa es peor que uno sin actualización remota.


Nada de esto es exótico. Es la diferencia entre un proyecto de fin de semana y un equipo que alguien va a poner en su línea de producción confiando en que funcione.

  • ESP32
  • IoT
  • Hardware
  • Producción

¿Tienes un proceso que todavía se hace a mano?

Cuéntanos cómo funciona hoy. Te respondemos con un diagnóstico honesto: qué se puede automatizar, qué no vale la pena, y cuánto costaría.