Monitorización textil (tejeduría)ESP32 PLCNTPResiliencia / OTA
Timestamps industriales fiables con NTP más un RTC hardware
Un RTC hardware sincronizado por NTP es lo que separa los datos de producción utilizables de la basura: un timestamp que se resetea a 1970 tras cada corte de corriente deja sin valor los ficheros de log diarios y los ID de trazabilidad. Este ejemplo para el PLC ESP32 obtiene la hora de pool.ntp.org con reintentos y la escribe en el chip RTC con batería del PLC. El patrón funciona en un despliegue real de monitorización de máquinas textiles donde los nombres de los ficheros de log y los ID de mensaje dependen de él.
NTP pone en hora, el RTC la conserva
La hora interna del ESP32 muere con cada reinicio, y las redes de fábrica no siempre están arriba cuando el PLC arranca. Por eso NTP se usa solo para poner en hora el chip RTC hardware — que sigue contando con su batería a través de reinicios y cortes. En un arranque en frío sin red, el firmware simplemente lee la última hora válida del chip y continúa con timestamps correctos.
Reintentos y un diagnóstico de última sincronización
getLocalTime() se consulta hasta diez veces antes de que el firmware se rinda, porque una red de planta congestionada pierde de forma rutinaria los primeros paquetes NTP y un único intento fallaría demasiado a menudo. Cada sincronización con éxito registra su epoch en una variable dedicada que exponen tanto el servidor web embebido como los comandos de estado MQTT — un vistazo a ese valor te dice si el reloj de un PLC está al día o lleva semanas funcionando por libre.
Resincronización periódica contra la deriva
Los cristales de los RTC derivan unos segundos al mes, lo que parece inofensivo hasta que intentas correlacionar un evento de parada en una máquina con un defecto de calidad registrado en otra. Un temporizador de resincronización cada 12 horas corrige el chip mientras haya red disponible, de modo que la deriva nunca se acumula. La zona horaria y el horario de verano los gestiona configTime, lo que significa que la rotación del fichero de log diario cambia a la medianoche local real, no a una hora desplazada respecto a UTC.
Un fragmento de la implementación
Tal cual del ejemplo desplegado en el ESP32 PLC — cópialo libremente:
void setup() {
Serial.begin(115200);
RTC.begin(); // the chip time is already usable at boot
checkWiFi();
uint32_t t0 = millis(); // initial WiFi wait (max 15 s)
while (WiFi.status() != WL_CONNECTED && millis() - t0 < 15000) delay(500);
if (!syncRTC())
Serial.println("No NTP at startup: using previous hardware RTC time");
}
El ejemplo completo es un programa entero — cabecera de conexionado, setup y bucle principal — listo para adaptar a tu aplicación.
Preguntas frecuentes
¿Y si la red de fábrica no tiene acceso a internet?
Apunta el firmware a un servidor NTP interno en lugar de pool.ntp.org — los hosts de Node-RED o cualquier servidor Linux pueden servir NTP en la LAN. En el código solo hay que cambiar el hostname.
¿Por qué no usar solo el reloj interno del ESP32 tras una sincronización NTP?
El reloj interno se pierde con cada reset y cada brownout. El chip RTC hardware del PLC lleva batería, así que los timestamps siguen siendo válidos incluso tras un fin de semana sin alimentación.
¿Cómo sé que el reloj de un PLC se ha quedado desactualizado?
El firmware guarda el timestamp de la última sincronización con éxito. Publícalo en el snapshot MQTT periódico o muéstralo en la página de estado; un valor antiguo significa que el dispositivo lleva tiempo sin alcanzar NTP.