¿Qué debe hacer un sensor ESP32 cuando pierde Wi-Fi?

Perder Wi-Fi, quedarse sin internet y no poder acceder a la aplicación son fallas distintas. Un dispositivo puede seguir conectado al router sin que sus lecturas lleguen a la base de datos. Un corte eléctrico es otro caso: el software no puede seguir midiendo sin una fuente de energía adecuada.

Escribe un requisito operativo antes de elegir almacenamiento. Por ejemplo: continuar midiendo durante cuatro horas sin red, conservar las lecturas acordadas y mostrar que el monitoreo remoto no está disponible. Es un objetivo hipotético de aceptación, no una especificación ni una promesa de rendimiento de un producto Carras.

Con una lectura cada 30 segundos, cuatro horas producen 480 registros por sensor. Si el contenido de una medición de ejemplo ocupa 96 bytes, solo los datos necesitan 46.080 bytes. Añade identificadores, comprobaciones de integridad, espacio adicional del almacenamiento y un margen probado; la capacidad real depende del formato y del hardware.

Decide qué sucede al llenarse la cola: eliminar las lecturas más antiguas, dejar de conservar las nuevas o guardar un resumen definido. Registra explícitamente cualquier pérdida. Distingue también el almacenamiento temporal en RAM de los datos que deben sobrevivir a un reinicio. Tener una cola de red no demuestra protección frente a cortes eléctricos.

Espressif describe NVS como almacenamiento en flash para pares clave-valor, especialmente adecuado para valores pequeños. No lo elijas automáticamente para un registro extenso de mediciones. Evalúa organización, frecuencia de escritura, capacidad y recuperación, y prueba escrituras interrumpidas con el hardware seleccionado.

Cada registro debe identificar el dispositivo, la secuencia de medición, el valor, las unidades y la información horaria disponible al tomarlo. Guarda por separado la hora de llegada. Los datos enviados tras reconectar pertenecen al historial; no deben sustituir una lectura actual más reciente.

Define cómo conservar identificadores únicos después de reiniciar. Si el reloj no está sincronizado, conserva la secuencia y el tiempo transcurrido e indica la incertidumbre de la hora. Inventar una hora exacta dificulta investigar después. Decide cuándo un registro pendiente resulta demasiado antiguo para ser útil.

Espressif documenta eventos de conexión y una reconexión controlada por la aplicación. Utiliza una política de reintentos limitada y con pausas, y distingue una desconexión intencionada de una falla. Recuperar Wi-Fi no demuestra por sí solo que la aplicación aceptó una lectura.

ESP-MQTT retransmite mensajes QoS 1 y 2 sin confirmar; QoS 0 no proporciona confirmaciones de entrega. Su bandeja de salida tiene ajustes de caducidad. Define qué confirmación permite borrar un registro local. La confirmación del intermediario MQTT no demuestra que una base de datos o una notificación posterior se haya completado.

Usa un identificador estable del evento para que repetirlo no cree filas ni avisos duplicados. Tras reconectar, envía los datos pendientes a un ritmo controlado mientras mantienes el monitoreo actual. Prueba una falla después de recibir el registro y antes de confirmarlo: permite detectar debilidades en el control de duplicados.

El panel debe distinguir información actual, antigua y no disponible. Acuerda la antigüedad máxima de una lectura antes de cambiar su estado. Muestra la última medición y el último contacto correcto, evitando que un valor normal antiguo siga pareciendo actual.

Last Will de MQTT puede señalar una desconexión inesperada, pero no demuestra que las mediciones estén actualizadas. Incluye un límite de tiempo del lado del servidor. No supongas que un aviso enviado por la conexión averiada llegará a alguien; asigna un canal operativo y un destinatario responsable.

Ejecuta una secuencia acordada y compara el registro del dispositivo, los datos almacenados y los avisos. Una lista útil cubre tanto la recuperación como la evidencia disponible cuando queda incompleta.

• Retirar Wi-Fi manteniendo el sensor encendido.
• Mantener Wi-Fi e interrumpir internet o el acceso a la aplicación.
• Llenar la cola y comprobar la política de pérdida elegida.
• Reiniciar mientras quedan escrituras y envíos pendientes.
• Repetir un registro y confirmar que no duplica acciones.
• Recuperar la conexión con el reloj incierto y revisar las horas.
• Comprobar que los avisos de datos antiguos y recuperación llegan al destinatario.

Documenta intervalo de medición, corte tolerado, conservación, pérdidas esperadas, canal de aviso y criterios de recuperación. Carras Technologies puede evaluar firmware, almacenamiento local y comportamiento del panel dentro de un proyecto de sensores delimitado. Incluye estos requisitos al solicitar una evaluación, para que la propuesta contemple también el funcionamiento sin conexión.