Hardware · Firmware · Ingeniería inversa
Smart switch revivido: de un chip Tuya quemado a un ESP32-C3
Un apagador inteligente con el chip WiFi quemado vuelve a la vida con un ESP32-C3 soldado a su placa original, firmware propio y diagnóstico de reinicios.
- Año
- 2026
- Estado
- En uso: controla una bomba de agua
- Rol
- Diagnóstico, adaptación electrónica y firmware
- Repositorio
- Repositorio en preparación
01 · Problema
El chip WiFi (BK7231, módulo Tuya WA2) de un apagador inteligente se quemó. El resto de la placa —fuente capacitiva, relevador, botón táctil y LED— seguía sano, pero el aparato quedó inservible.
02 · Enfoque
Identifiqué la función de cada pad de la placa y soldé un ESP32-C3 Super Mini en lugar del módulo. El LED de la placa trabaja cerca de 5 V, así que lo manejo con un transistor NPN (MPS2222A) para proteger los GPIO de 3.3 V. El firmware lo escribí desde cero.
03 · Resultado
Firmware v1.4.0 con control por botón, web, MQTT / Home Assistant y WebSerial bilingüe; portal cautivo, OTA y efectos de LED según el estado. Tras un incidente de reinicios con la bomba, agregué registro de causas de reinicio y un arranque seguro que no la vuelve a encender después de una caída de voltaje.
04 · Stack
- ESP32-C3
- C++ / Arduino
- PlatformIO
- MQTT
- Home Assistant
- ElegantOTA
- WebSerial
- Transistor NPN
Conexiones
| Cable | Pad de la placa | ESP32-C3 | Función |
|---|---|---|---|
| Rojo | VBat / VCC | 3V3 | Alimentación desde el regulador AMS1117 |
| Negro | GND | GND | Tierra común |
| Café | PWM0 | GPIO4 | Botón (LOW = presionado) |
| Verde | PWM4 | GPIO3 | Relevador (HIGH = encendido) |
| Azul | PWM1 | vía transistor | LED indicador |
El pad del LED entrega entre 4.4 y 4.8 V con rizado de la fuente capacitiva. El chip original «hundía» esa corriente; un GPIO del ESP32-C3 no lo tolera. El NPN hace de interruptor: el ESP32 solo controla la base con 1 kΩ, y como conmuta rápido a 5 kHz, el LED también funciona como dimmer para efectos de respiración y desvanecido.
El incidente de la bomba
Con la versión 1.3.1 el switch se reiniciaba solo y, a veces, la bomba arrancaba sin que nadie la prendiera. Medí antes de tocar nada:
- Señal WiFi: de −83 a −92 dBm (promedio −86) en 158 muestras.
- Enlace: 7.5 % de paquetes perdidos y 11 % de consultas a la API sin respuesta.
- Código: al arrancar, el relevador se restauraba en encendido justo antes del mayor pico de consumo (el arranque del WiFi), y no se guardaba la causa de ningún reinicio.
La hipótesis principal: la fuente de la placa Tuya —diseñada para un chip que consume menos— no aguanta el pico, el voltaje cae, el ESP32 se reinicia y vuelve a encender la bomba. Pero también hubo un reinicio con el relevador apagado, así que no di la causa por cerrada.
Qué cambió en la v1.4.0
- Registro persistente de los últimos 8 reinicios (causa, tiempo encendido previo, estado del relevador y señal) visible en WebSerial, en la API y como sensores en Home Assistant.
- Arranque seguro: tras un brownout o dos reinicios inesperados seguidos, la bomba no se vuelve a encender sola.
- El relevador queda retenido durante los reinicios que decide el propio firmware.
- Los comandos llegan a una cola y se aplican en el ciclo principal (sin condiciones de carrera entre tareas).
- Se borra cualquier comando MQTT retenido para evitar «encendidos fantasma».
Estado honesto: el problema quedó mitigado por software; la causa raíz se confirma con los datos del nuevo registro y lo más probable es que pida una mejora de hardware (fuente dedicada o mejor señal).