El sensor más importante de una operación suele estar lejos de la oficina. En la última piscina, al fondo de la finca, junto a un tanque, sobre una bomba o en una estación donde nadie pasa todos los días. Justo ahí es donde más duele perder datos.
La pérdida de datos no siempre se nota al momento. A veces aparece como huecos en una gráfica, alarmas que nunca llegaron o reportes incompletos. Para evitarlo, hay que diseñar pensando en enlaces débiles, energía limitada y mantenimiento difícil.
Primero: acepte que el enlace puede fallar
En campo, la comunicación no es perfecta. Puede fallar el enlace LoRaWAN por baja señal, el backhaul del gateway por internet inestable, la energía del sitio, la batería del nodo o incluso la hora interna del equipo.
Diseñar como si todo fuera estable es el primer error. La red debe asumir fallas y recuperarse sin perder el historial.
Guarde datos localmente
La práctica más importante es que el nodo o gateway tenga almacenamiento local. Si el enlace falla, el equipo debe seguir midiendo y guardar las muestras hasta poder transmitirlas.
Ese almacenamiento debe incluir:
- Valor medido.
- Marca de tiempo.
- Identificador del sensor.
- Estado de batería o energía.
- Calidad de señal cuando aplique.
- Estado de error si la lectura no fue válida.
Sin marca de tiempo, un dato retrasado pierde valor. No basta con saber cuándo llegó a la nube; hay que saber cuándo ocurrió.
A esta técnica se la conoce como buffer local o store-and-forward (“guardar y reenviar”): el nodo —o el gateway— almacena las muestras mientras el enlace está caído y las reenvía en cuanto se recupera, rellenando los huecos de la gráfica en lugar de dejarlos vacíos. Es la diferencia entre perder una hora de datos durante un corte de internet y recuperarla completa cuando vuelve la conexión. Para que el reenvío sea ordenado, cada muestra debe llevar su propia marca de tiempo y, idealmente, un número de secuencia (un contador que aumenta con cada lectura): así la plataforma sabe exactamente qué muestras faltan y en qué orden colocarlas.
Use reintentos con criterio
Reintentar ayuda, pero reintentar sin control puede gastar batería y saturar la red. Un buen firmware maneja colas, prioridades y límites. Puede enviar primero alarmas críticas, luego datos recientes y finalmente histórico pendiente.
En LoRaWAN, además, no conviene convertir cada mensaje en confirmado si no hace falta. Aquí hay una decisión técnica concreta entre dos tipos de envío (uplink):
- Uplinks confirmados: el nodo espera un acuse de recibo (ACK) del servidor de red y, si no llega, reintenta el envío. Dan más garantía de entrega, pero cada confirmación obliga al gateway a emitir un downlink hacia el nodo, consume tiempo de aire de la red y gasta más batería en el nodo, que debe quedarse despierto escuchando la respuesta.
- Uplinks no confirmados: el nodo transmite y sigue su camino, sin esperar respuesta. Son más eficientes en energía y en uso de la red, pero sin garantía: si el mensaje se pierde, nadie lo reintenta.
La estrategia sensata es usar confirmados con criterio: para una alarma crítica de oxígeno disuelto en una camaronera, donde perder el aviso es caro, tiene sentido pedir confirmación. Para mediciones rutinarias cada pocos minutos, el envío no confirmado combinado con buffer local y numeración de secuencia suele ser más sano para la batería y para la red.
ADR para mantener el enlace estable
LoRaWAN incluye un mecanismo llamado ADR (Adaptive Data Rate, tasa de datos adaptativa): el servidor de red ajusta automáticamente el factor de dispersión y la potencia de transmisión de cada nodo según la calidad de señal que recibe. Un nodo cercano al gateway, con buena señal, transmite a mayor velocidad y menos potencia (ahorra batería y libera la red); uno lejano usa un factor más robusto que llega mejor aunque más lento. Mantener ADR activo en nodos fijos ayuda a sostener un enlace estable y a reducir pérdidas por mala configuración. En nodos móviles, en cambio, conviene revisarlo, porque la señal cambia constantemente.
Monitoree la salud del nodo
Para evitar pérdida de datos, hay que detectar señales tempranas:
- Batería bajando.
- Señal débil.
- SNR degradándose.
- Muchos reintentos.
- Sensor sin respuesta.
- Gabinete abierto o humedad si el equipo lo permite.
- Última transmisión demasiado antigua.
Estos datos de salud son tan importantes como la variable principal. Un sensor de oxígeno sin batería no es un sensor; es una promesa rota.
Diseñe con margen de señal
Un enlace que funciona apenas durante la instalación no es suficiente. Debe tener margen para lluvia, crecimiento de vegetación, cambios de humedad, interferencia y pequeñas variaciones de montaje.
Si el nodo está muy lejos de la oficina, no conviene vivir al borde. Mejore antena, altura, ubicación del gateway o agregue otro gateway antes de aceptar una señal mínima como si fuera producción.
Cuide energía y reloj
Muchos huecos de datos son huecos de energía. Una batería envejecida, un panel solar sombreado o una fuente inestable pueden apagar el nodo justo cuando debía medir.
También importa el reloj. Si el equipo guarda datos localmente, debe mantener hora razonable o poder corregirla al sincronizar. De lo contrario, las muestras llegan, pero quedan ubicadas en momentos incorrectos.
Backhaul redundante cuando el dato es crítico
Si la operación depende del dato, el gateway no debería tener un solo camino a internet. Puede usar celular como respaldo, Starlink en sitios remotos, radioenlace o una combinación. La redundancia no siempre es necesaria para todos los proyectos, pero sí para alarmas y control.
En el backhaul ayuda mucho que el envío hacia la plataforma use colas con reintento, típicamente sobre MQTT o un mecanismo equivalente: si la nube no responde, los mensajes esperan en la cola y se entregan cuando vuelve la conexión, en lugar de descartarse. Es el mismo principio de “guardar y reenviar”, pero aplicado al tramo entre el gateway y el servidor.
Gateways redundantes: la red que se cubre a sí misma
Hay una propiedad de LoRaWAN que conviene aprovechar: un mismo uplink puede ser escuchado por varios gateways a la vez. Si dos gateways cubren la zona y ambos reciben la transmisión del nodo, el servidor de red deduplica los mensajes (se queda con una copia y descarta las repetidas). La ventaja es directa: si uno de los gateways se cae —por corte de energía, falla de internet o mantenimiento—, el otro sigue entregando los datos del nodo y no se pierde nada. En operaciones críticas, instalar gateways con cobertura solapada es una de las formas más efectivas de evitar huecos sin tocar el firmware del nodo.
Aun con redundancia, el almacenamiento local sigue siendo necesario. El respaldo reduce fallas; no las elimina. Si quiere profundizar en cómo opera una red cuando la conexión a internet es intermitente, vea también cómo mantener una red IoT funcionando sin internet.
Alertas por silencio
Una alarma por valor alto o bajo es obvia. Una alarma por silencio es igual de importante. Si un sensor debía reportar cada 10 minutos y lleva una hora sin aparecer, alguien debe saberlo.
La plataforma debe distinguir entre “la variable está normal” y “no hay datos”. En operación, esas dos situaciones no son equivalentes.
Pruebe recuperación
La prueba real es desconectar el enlace, dejar que el sensor acumule datos y volver a conectar. Luego revise:
- Si se subieron todas las muestras.
- Si conservaron su hora original.
- Si no se duplicaron.
- Si las gráficas quedaron ordenadas.
- Si las alarmas se comportaron correctamente.
Esta prueba debería hacerse antes de declarar la red lista.
Para el diagnóstico, las dos herramientas más útiles son las marcas de tiempo y la numeración de secuencia. Con un contador que avanza en cada muestra, detectar huecos es trivial: si llegan las muestras 100, 101 y luego 105, usted sabe que faltan tres y puede ir a buscarlas o confirmar que el buffer las reenviará. Sin secuencia, un hueco puede pasar desapercibido hasta que alguien nota la falta en una gráfica.
Conclusión
Evitar pérdida de datos en sensores remotos no depende de una sola función. Depende de almacenamiento local, marcas de tiempo, buen firmware, margen de señal, energía estable, monitoreo de salud, alertas por silencio y backhaul adecuado.
En Yubox diseñamos redes IoT para que el dato sobreviva al campo real: distancia, humedad, cortes e internet intermitente. Si tiene sensores lejos de la oficina y no quiere operar a ciegas, conversemos.