Un sensor que se rompe no es un problema. Deja de enviar, salta la alerta y se sustituye.
El problema es el otro: el que sigue midiendo, sigue reportando y sigue equivocándose. Ese puede pasar meses alimentando decisiones antes de que alguien sospeche.
En una red desplegada en campo, el fallo silencioso es la norma, no la excepción.
- Un pluviómetro con un nido dentro registra cero durante una tormenta.
- Una garita de protección degradada devuelve dos grados de más en los días soleados y sin viento, justo cuando el dato importa.
- Un sensor de humedad relativa que ha sufrido condensaciones repetidas empieza a saturar antes de tiempo y ya nunca baja del 95%.
Ninguno de esos tres valores es absurdo. Todos entran dentro de lo posible. Y los tres son falsos.
Cuatro capas de validación
No existe una comprobación que los detecte todos. Lo que funciona es una cadena, ordenada de la más barata a la más costosa.
1. Rango físico. ¿Es posible ese valor? Una temperatura de -273 ºC o una humedad del 140% delatan un fallo de electrónica o de decodificación de trama. Es la capa más simple y la que menos casos reales atrapa, pero cuesta nada implementarla.
2. Persistencia. ¿Lleva demasiado tiempo sin moverse? Un sensor congelado en el mismo valor durante horas no está midiendo, está repitiendo el último dato válido. El umbral depende de la magnitud: la humedad del suelo puede estar plana un día entero con normalidad; la temperatura del aire, no.
3. Coherencia temporal. ¿Es físicamente posible ese cambio en ese tiempo? El aire no sube ocho grados en cinco minutos. Un salto así indica ruido eléctrico, contacto defectuoso o una trama corrupta que ha pasado el CRC por casualidad.
4. Coherencia espacial. ¿Qué dicen los vecinos? Si tres estaciones en cinco kilómetros registran lluvia y una marca cero, el problema no es meteorológico.
Esta última es la única capa que detecta la deriva lenta, que es precisamente el fallo más caro. Y encierra la conclusión incómoda del asunto: un sensor aislado no puede autodiagnosticarse. Puede decirte que está vivo, nunca que está en lo cierto. La calidad del dato es una propiedad de la red, no del dispositivo.
El sensor también habla de sí mismo
Antes de que la medida se degrade, suele hacerlo el contexto. Tensión de batería en caída anómala, calidad de enlace deteriorada, temperatura interna de la electrónica fuera de lo esperado, contador de reinicios que crece.
Esos metadatos no interesan a nadie en el dashboard del cliente, pero son el sistema inmune de la red. Un nodo que empieza a reiniciarse cada pocas horas va a dar un dato malo pronto; conviene enterarse antes que el cliente.
Marcar, nunca borrar
Cuando el sistema decide que un valor es sospechoso, la tentación es limpiarlo: eliminarlo, interpolarlo, suavizarlo. Es un error.
El dato crudo se conserva siempre. Lo que se añade es una etiqueta de calidad, validado, sospechoso, inválido, y el motivo por el que se ha asignado.
Con eso ganas tres cosas que la limpieza destruye:
- Trazabilidad. Seis meses después puedes reconstruir por qué el sistema tomó una decisión.
- Diagnóstico. El patrón de los errores señala la causa: si todos los valores dudosos ocurren de madrugada, tienes un problema de condensación, no de sensor.
- Confianza. Un cliente acepta un hueco explicado. No perdona un dato inventado.Lo que esto obliga a decidir antes de desplegar
Estas cuatro capas no se añaden al final, encima de un sistema ya construido. Condicionan decisiones de arquitectura que después salen caras de revertir.
- La densidad de la red deja de ser solo una cuestión de cobertura. Si quieres coherencia espacial, necesitas al menos un nodo comparable dentro de un radio en el que las magnitudes sigan siendo equivalentes. Ese radio no es el mismo para temperatura que para lluvia: la primera varía de forma suave y previsible, la segunda puede diferir por completo entre dos puntos separados un kilómetro. Un despliegue calculado solo por alcance radio suele quedarse sin capacidad de autodiagnóstico.
- El almacenamiento se dimensiona para el dato crudo, no para el útil. Guardar la serie original junto a la validada multiplica el volumen y obliga a pensar la política de retención desde el principio. Es un coste que se acepta o se paga después, cuando hay que justificar ante un cliente por qué su gráfica de hace ocho meses dice lo que dice.
- Las alarmas necesitan dos niveles distintos. Una cosa es avisar de un umbral agronómico o energético superado, eso le interesa al usuario, y otra avisar de que un nodo se está degradando, eso le interesa a quien mantiene la red. Mezclarlas produce el peor resultado posible: el cliente recibe ruido técnico que no sabe interpretar y el equipo de mantenimiento se entera tarde.
- Y el firmware tiene que reportar su propio estado. Si el dispositivo solo envía la medida, has perdido la capa más barata de diagnóstico antes de empezar. Añadir tensión, calidad de enlace y contador de reinicios cuesta unos pocos bytes por trama y ahorra desplazamientos a campo durante toda la vida del despliegue.
Ninguna de estas decisiones es reversible sin tocar el sistema entero. Por eso la validación del dato no es una funcionalidad de la plataforma: es una premisa del diseño.
Medir es la parte fácil. Saber cuándo no creerte lo que has medido es lo que exige criterio, y es lo que separa una red que informa de una que solo emite.
Un sistema honesto no es el que nunca falla, eso no existe en campo, sino el que sabe reconocer sus propios fallos y decirlo a tiempo.
Esa es la diferencia entre una red que informa y una que solo emite.
