LoRa Monitor 3DFAB — LoRa Helios

LoRa Helios se planteó como una plataforma propia de monitoreo para sensores ambientales distribuidos. La operación necesitaba concentrar la señal entrante, conservar históricos y ofrecer una vista clara del estado de los dispositivos, sus variables y sus asignaciones.

El sistema debía recibir payloads LoRaWAN desde TTN, convertir formatos variables de sensores y permitir revisar P1, P2, temperatura, humedad, batería y señal. Además, necesitaba históricos filtrables, comparación entre dispositivos, exportación CSV y separación de permisos entre administración y clientes.

Diseñé y desarrollé el flujo full-stack: integración del webhook, normalización y persistencia de mediciones, modelos de dispositivos y usuarios, API, autenticación, autorización, caché, dashboard, gráficos, comparación, exportación, panel administrativo, pruebas y empaquetado para despliegue.

Los payloads de TTN pueden variar según el decoder y algunos sensores no envían todas las variables. También había que contemplar duplicados, ráfagas, una infraestructura acotada y la necesidad de validar cambios antes de tocar el servidor real. La interfaz usa polling de hasta 30 segundos, por lo que no se presenta como telemetría sub-segundo.

Construí un dashboard con estado de dispositivos, búsqueda y filtros; vistas de detalle con históricos por variable; gráficos comparables entre nodos; zoom y navegación temporal; exportación CSV; y un panel de administración para usuarios, roles y asignaciones. La ingesta crea el dispositivo cuando corresponde, normaliza campos alternativos y mantiene el registro aunque el frontend no esté abierto.

El flujo es Nodos LoRa → gateway → TTN → webhook autenticado → API Express → MongoDB/Mongoose. El middleware valida y normaliza el payload antes de persistirlo; Redis funciona como caché, invalidación y Pub/Sub auxiliar. React con Vite, React Router y Recharts consulta la API por HTTP y refresca el dashboard mediante short polling. Los roles admin/cliente limitan la visibilidad de dispositivos. Docker reproduce backend, frontend y Redis, mientras MongoDB se configura como servicio externo.

Canalización de datos (Data Ingestion Pipeline): los nodos LoRaWAN transmiten uplinks al gateway, que los entrega a The Things Network (TTN); TTN publica el evento hacia el webhook POST autenticado de LoRa Helios. En el flujo implementado, el decoder de TTN transforma el frame binario recibido —base64/hex según la integración— en `uplink_message.decoded_payload`; el backend no afirma una decodificación genérica de `frm_payload` por sí mismo. Joi valida la envoltura TTN v3, el normalizador extrae device_id, timestamp, variables ambientales y metadatos RF, admite nombres alternativos y conserva rawPayload antes de persistir la medición en MongoDB.

Manejo de concurrencia y pérdida de paquetes: el webhook es asíncrono y puede atender solicitudes concurrentes; la persistencia en MongoDB usa un índice único por deviceId + receivedAt para que reenvíos y duplicados terminen como una respuesta idempotente. Los payloads corruptos o con estructura inválida se rechazan con 400 mediante Joi; la autenticación y el rate limiting —100 solicitudes por minuto por IP— reducen tráfico no válido. La medición se guarda antes de invalidar caché y publicar en Redis, y si Redis cae no se utiliza como fuente de verdad. No hay una cola durable ni un reintento propio del backend: una caída de la API o de MongoDB produce error y la recuperación del uplink depende de la capa upstream; por eso no se promete ausencia universal de pérdida de paquetes.

Elegí MongoDB para acomodar payloads de sensores variables y consultar mediciones por dispositivo y tiempo, con índices para históricos, idempotencia y retención. Redis quedó como acelerador y mecanismo de invalidación, no como fuente de verdad. Preferí short polling frente a WebSockets porque el intervalo de envío de los nodos hacía suficiente una actualización periódica y reducía complejidad operativa. Docker permitió ejecutar pruebas, validaciones y correcciones en un entorno reproducible antes del despliegue.

La solución aplica autenticación basada en tokens, autorización por rol y dispositivo, validación de payloads, autenticación del webhook, limitación de tráfico, headers de seguridad, allowlist de orígenes, trazabilidad de solicitudes y registros de auditoría. La ficha pública no expone tokens, secretos, credenciales, nombres de bases de datos, hosts, rutas internas ni configuraciones exactas; tampoco constituye una auditoría externa ni una garantía absoluta de seguridad.

La suite backend usa Jest, Supertest y MongoDB en memoria para cubrir autenticación, refresh tokens, autorización por dispositivos, validación del webhook, duplicados, campos opcionales, consultas históricas, exportación CSV, comparación, caché Redis y logging. El escenario de más de 10.000 datos corresponde a una validación del proyecto y no a un benchmark público reproducible.

Despliegue: la infraestructura documentada está preparada sobre una VPS de Hostinger con Coolify, que orquesta contenedores Docker separados para backend Express, frontend React/Nginx y Redis. Docker Compose define dependencias, reinicio automático, health checks y readiness antes de servir tráfico. MongoDB Atlas funciona como base de datos externa y fuente de verdad; Redis mantiene caché y Pub/Sub con volumen persistente, sin reemplazar MongoDB. Las variables sensibles y las claves de firma se inyectan por entorno, mientras Coolify puede gestionar el proxy HTTPS delante de los servicios. No se publican host, credenciales ni parámetros de producción.

En el escenario validado del proyecto, la plataforma recibió más de 10.000 datos provenientes de TTN sin incidencias observadas mientras aplicaba limitación de tráfico. El resultado también dejó operativo el flujo de históricos, comparación, exportación y control de acceso, y permitió corregir el sistema en Docker antes de llevarlo al servidor real. No se publica una medición independiente de carga, disponibilidad o latencia.

Evidencia pública: demo visual en video y ficha técnica. La revisión del repositorio aporta README, ADRs y pruebas automatizadas para respaldar las decisiones de MongoDB, autenticación del webhook, polling y validación. La ficha incluye una muestra aislada de normalización de datos para evidenciar calidad de ingeniería sin exponer endpoints, credenciales, infraestructura ni payloads operativos. La cifra de más de 10.000 datos es un escenario validado del proyecto; no se presenta como benchmark independiente ni como garantía para cualquier infraestructura.