Cuando un operador abre Yubox Cloud y ve una gráfica de oxígeno disuelto subir y bajar en tiempo real, ve el resultado final de un recorrido que involucra al menos cinco sistemas distintos, cada uno con su propia responsabilidad y su propio punto de falla. La mayoría de guías de IoT explican cada pieza por separado —el sensor, la radio, el servidor— pero pocas veces se cuenta el viaje completo, de punta a punta, con los tiempos y las decisiones que ocurren en cada etapa. Entender ese recorrido ayuda a diagnosticar dónde se pierde o se retrasa un dato cuando algo falla, en vez de asumir que “el sensor no sirve”.
Etapa 1: el sensor mide, el nodo empaqueta
Todo empieza con una magnitud física —oxígeno disuelto, humedad de suelo, corriente eléctrica— que un sensor convierte en una señal eléctrica (analógica, digital, SDI-12 o Modbus RTU, según el sensor). El microcontrolador del nodo lee esa señal, la convierte a un valor numérico y decide, según su firmware, cómo representarla en bytes: normalmente un entero escalado (×10 o ×100) en 1 o 2 bytes, no un número decimal de punto flotante que pesaría más. Este paso ya fija buena parte de la precisión final: si el sensor mide con más resolución de la que el firmware transmite, esa resolución se pierde antes de salir del nodo.
El nodo arma entonces el payload: un puñado de bytes crudos, sin ningún campo que diga “oxígeno” o “temperatura” (ese trabajo de traducción llega después, en la etapa 4). Ya hemos cubierto en detalle cómo se estructura ese payload y por qué se prefiere binario sobre JSON en el artículo sobre payload y decoders LoRaWAN.
Etapa 2: la radio saca el dato del sitio
Con el payload listo, el nodo transmite por radio —en la mayoría de despliegues de Yubox, LoRaWAN en banda AU915, la que corresponde a Ecuador y el resto de Sudamérica (no US915, que es para Norteamérica)—. Cuánto tarda y cuánto gasta en esto depende del Spreading Factor y del duty cycle y dwell time de la región: con buena cobertura, la transmisión completa de un uplink toma bien poco tiempo de aire (de decenas a un par de cientos de milisegundos), pero el nodo puede esperar hasta 1-2 segundos adicionales antes de que se abra su ventana de recepción (RX1/RX2), por si el network server tiene un downlink pendiente para él.
Uno o varios gateways LoRaWAN dentro del alcance de radio reciben esa trama y la reenvían, sin decidir nada sobre su contenido, hacia el network server vía IP (Wi-Fi, celular, Ethernet o incluso backhaul satelital en sitios sin cobertura, como cubrimos en el artículo sobre Starlink como backhaul LoRaWAN). Si dos gateways reciben la misma trama —algo común y deseable en redes bien dimensionadas—, la deduplicación ocurre en la siguiente etapa, no aquí.
Etapa 3: el network server valida y organiza
El network server (ChirpStack o The Things Stack, típicamente) recibe la trama de todos los gateways que la escucharon, descarta duplicados quedándose con la de mejor señal, verifica el código de integridad (MIC) contra la clave del dispositivo y descifra el payload con AES-128 (el mecanismo que protege el dato completo, detallado en el artículo de seguridad y cifrado en LoRaWAN). También aplica ADR si corresponde, ajustando el data rate del nodo para el siguiente ciclo.
En este punto el network server tiene bytes descifrados, pero todavía no sabe qué significan. Su trabajo es de tráfico y seguridad de red, no de interpretación de negocio.
Etapa 4: el decoder convierte bytes en datos con nombre
Aquí es donde el payload deja de ser una cadena hexadecimal ilegible y se convierte en algo como {oxigeno_mgl: 5.00, temperatura_c: 27.00, bateria_v: 3.38}. El decoder —una función corta, normalmente en JavaScript, definida por modelo de sensor— aplica el orden de bytes, el signo y la escala correctos para reconstruir cada variable, tal como se explica con un ejemplo byte a byte en el artículo de payload y decoders enlazado arriba. Un error aquí (orden de bytes invertido, un campo tratado como sin signo cuando sí puede ser negativo) es la causa más común de datos “raros” que en realidad nunca fallaron en el sensor ni en la radio, sino en esta traducción.
El resultado decodificado se entrega, normalmente por MQTT (con distintos niveles de calidad de servicio, QoS 0 a 2) o por un webhook HTTP, al siguiente eslabón: el servidor de aplicación.
Etapa 5: el servidor de aplicación almacena, grafica y alerta
Yubox Cloud —el servidor de aplicación en este flujo— recibe el dato ya decodificado y hace tres cosas con él:
- Lo guarda en una base de datos de series de tiempo, optimizada para escribir y consultar millones de lecturas ordenadas por fecha sin degradarse con el volumen (a diferencia de una base relacional genérica, que se vuelve lenta para graficar meses de histórico).
- Lo grafica en el dashboard que ve el operador, normalmente casi al instante: sumando las esperas de radio y procesamiento de las etapas anteriores, el recorrido completo de un dato LoRaWAN —desde que el sensor mide hasta que aparece en pantalla— suele tomar pocos segundos, no minutos.
- Lo evalúa contra reglas de alarma: si el oxígeno disuelto cruza un umbral crítico o la batería de un nodo cae por debajo de un límite, dispara una notificación (push, correo, webhook a otro sistema) sin que nadie tenga que estar mirando la gráfica en ese momento.
Esta es también la capa donde vive la lógica de negocio que ningún dispositivo de radio conoce: qué umbral dispara una alarma en una piscina camaronera de engorde versus una de larvas, o qué variable amerita revisión inmediata y cuál puede esperar al reporte diario.
Dónde suele romperse la cadena (y cómo se diagnostica)
Cuando un dato “no llega” o “llega mal”, el origen casi siempre está en una de estas cinco etapas, y cada una deja pistas distintas:
- Sensor o nodo: el dato no llega nunca, ni siquiera al network server. Se revisa con logs del propio nodo o consumo de batería anómalo.
- Radio: el nodo transmite pero el gateway no lo escucha (fuera de rango, obstáculo, antena mal ubicada). El network server no muestra ningún uplink de ese DevEUI.
- Network server: la trama llega pero se descarta por MIC inválido (reloj o claves desincronizadas) o el join OTAA falló.
- Decoder: el dato llega, pero el valor no tiene sentido (oxígeno de 5.000 mg/L, temperatura de -0,01 °C convertida en 655 °C). Aquí el problema está casi siempre en el orden de bytes o el signo, no en el sensor físico.
- Aplicación: el dato decodificado es correcto pero no aparece en el dashboard o no dispara la alarma esperada: se revisa la integración (MQTT/webhook) y la configuración de reglas en Yubox Cloud.
Diagnosticar por etapa, en vez de sospechar del sensor por defecto, ahorra horas de soporte en despliegues de campo.
Conclusión
Un dato IoT no “aparece” en un dashboard: recorre un sensor, un nodo, una radio, un network server, un decoder y un servidor de aplicación, cada uno con su propia responsabilidad y su propio modo de falla. Conocer ese mapa —no solo cada pieza por separado— es lo que permite a un equipo de campo o de TI ubicar en segundos en qué etapa se rompió la cadena, en vez de reemplazar equipos por prueba y error.
¿Su equipo necesita trazar este recorrido para un despliegue nuevo o diagnosticar uno existente? Conversemos: revisamos su arquitectura completa, de sensor a dashboard.