Monitorización textil (tejeduría)ESP32 PLCWiFiResiliencia / OTA
Reconexión WiFi que nunca detiene el monitor de máquina
La reconexión WiFi sin bloqueos es la diferencia entre un nodo de monitorización que aguanta los problemas de red y uno que se congela con ellos. El WiFi de fábrica se cae constantemente — puntos de acceso saturados, interferencias de variadores de frecuencia, ventanas de mantenimiento. Este ejemplo para el PLC ESP32 reintenta la conexión como mucho una vez cada 10 segundos sin frenar jamás el loop, un patrón endurecido en un despliegue real de monitorización de máquinas textiles en dos plantas de producción.
Comprobar en cada loop, reintentar cada 10 segundos
checkWiFiConnection() se ejecuta en cada iteración del loop pero no cuesta prácticamente nada mientras hay conexión — una lectura de estado y un retorno inmediato. Cuando el enlace está caído, llama a WiFi.begin() de forma asíncrona como mucho una vez por ventana de 10 segundos y nunca se queda esperando a que llegue el resultado. No hay ningún bucle while-not-connected en todo el firmware, porque ese patrón bloqueante clásico es exactamente lo que convierte un corte de WiFi en un corte total del firmware.
El trabajo real no se detiene nunca
Mientras la radio busca el punto de acceso, el contador de pulsos de producción sigue corriendo sobre su interrupción hardware y cada registro sigue aterrizando en el fichero diario de la tarjeta SD, exactamente como si no pasara nada. La conectividad se trata como una optimización, no como una dependencia — cuando la red por fin vuelve, la publicación MQTT se reanuda sola y los ficheros almacenados rellenan el hueco. Los datos de máquina acaban sin ni un solo agujero.
Contadores de caídas como métrica de salud
Un flag global de conexión le dice al resto del firmware si merece la pena intentar publicar ahora mismo, y un contador se incrementa en cada transición de conectado a caído. Expuesto en la página de estado embebida o en el snapshot MQTT periódico, ese contador de caídas resulta ser oro para diagnosticar redes de planta. Cuando un PLC de la flota reporta cuarenta caídas al día y sus vecinos reportan dos, estás ante un punto de acceso débil o saturado, no ante un problema de firmware.
Un fragmento de la implementación
Tal cual del ejemplo desplegado en el ESP32 PLC — cópialo libremente:
void setup() {
Serial.begin(115200);
// Plant work: production counter via interrupt
pinMode(I0_0, INPUT);
attachInterrupt(I0_0, [] { pulses++; }, FALLING);
// First connection attempt, also without blocking startup
WiFi.mode(WIFI_STA);
WiFi.begin(WIFI_SSID, WIFI_PASS);
lastConnectionAttempt = millis();
}
El ejemplo completo es un programa entero — cabecera de conexionado, setup y bucle principal — listo para adaptar a tu aplicación.
Preguntas frecuentes
¿Por qué no llamar a WiFi.begin() en cada iteración del loop?
Martillear la pila WiFi con intentos de conexión la deja sin recursos y puede mantenerla asociándose permanentemente. El límite de 10 segundos da tiempo a que cada intento termine sin dejar de recuperar rápido.
¿Funciona esto también con la reconexión MQTT?
Sí, el mismo patrón se aplica un nivel más arriba — intenta la conexión MQTT solo cuando el WiFi está arriba y el cliente desconectado, también con límite de frecuencia, y resuscríbete a los topics de comandos tras cada reconexión con éxito.
¿Cómo evito perder datos mientras estoy offline?
Escribe cada mensaje en la tarjeta SD antes de intentar publicarlo. Con ficheros JSON diarios en la tarjeta, un corte de horas o días no cuesta nada; los datos se suben o se reproducen cuando vuelve el enlace.