Recuperar los datos en búfer de la SD con HTTP POST autenticado
Subir ficheros de la SD por HTTP POST cierra el círculo de un datalogger offline-first: almacenar datos en búfer durante un corte solo sirve si luego puedes recuperarlos sin ir andando hasta la máquina. Este ejemplo envía por streaming un fichero JSON diario desde la tarjeta SD del PLC ESP32 a un endpoint de Node-RED con autenticación básica — la vía de recuperación usada en un despliegue real de monitorización de máquinas textiles cada vez que la red cae y vuelve.
Streaming directo desde la tarjeta
La línea clave es http.sendRequest("POST", &file, file.size()) — HTTPClient toma el objeto File abierto y lo envía por streaming en fragmentos, de modo que el ESP32 nunca tiene que cargar el fichero en RAM. Un día de logs de máquina de varios megabytes se sube igual de fácil que uno pequeño, con los mismos pocos kilobytes de memoria en juego. El Content-Type text/plain y un timeout generoso de 15 segundos dan margen a las transferencias grandes, y el manejador del fichero se cierra inmediatamente después, tanto si la petición tuvo éxito como si no.
Autenticación y una cabecera con el nombre del fichero
setAuthorization(HTTP_USER, HTTP_PASS) añade autenticación HTTP básica, de modo que el endpoint de recuperación no queda como una puerta abierta para cualquier otra cosa que viva en la red de planta. Una cabecera personalizada X-File-Name viaja con la petición y le dice al servidor exactamente qué fichero diario está recibiendo, sin tener que extraer nada del cuerpo. En el lado receptor, un nodo HTTP-in de Node-RED verifica las credenciales, sanea ese nombre de fichero y escribe el payload en una carpeta de recuperación por planta en disco.
Borrar solo tras un 200
La regla de oro de la recuperación: el PLC solo mueve un fichero a la carpeta /enviados cuando el servidor ha respondido HTTP 200. Cualquier otro código — timeout, 401, 500 — deja el fichero intacto en la tarjeta para el siguiente intento. En producción la subida se lanza en remoto con un comando MQTT, así que toda la recuperación se hace desde una mesa.
Un fragmento de la implementación
Tal cual del ejemplo desplegado en el ESP32 PLC — cópialo libremente:
void setup() {
Serial.begin(115200);
SD.begin();
WiFi.mode(WIFI_STA);
WiFi.begin(WIFI_SSID, WIFI_PASS);
uint32_t t0 = millis();
while (WiFi.status() != WL_CONNECTED && millis() - t0 < 15000) delay(500);
Serial.println("Ready. Type the name of the file to upload,");
Serial.println("e.g.: /2026-06-10.json");
}
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é HTTP POST en lugar de reenviar los datos por MQTT?
Un día de logs puede ser miles de mensajes; reproducirlos a través de un broker es lento e inunda a los suscriptores. Un único POST autenticado mueve el fichero completo en una sola transacción con una señal clara de éxito.
¿Cómo se lanza la subida tras un corte?
En el sistema de producción llega un comando MQTT del tipo "upload 2026-06-10.json" al topic de comandos del PLC. También puede automatizarse — al reconectar, recorre el inventario de la SD y sube cada fichero aún no marcado como enviado.
¿Es suficiente la autenticación básica como seguridad?
En una VLAN de planta aislada es una base razonable que deja fuera los accesos casuales. Si el tráfico cruza redes menos fiables, pon el endpoint detrás de un proxy inverso con TLS y credenciales más robustas.