Trazabilidad de activos con LoRaWAN e IA generativa
El primer punto para iniciar el proyecto de trazabilidad LoRaWAN y GPS era disponer de un servidor de ChirpStack. El el pasado ya realicé un artículo al respecto, pero han pasado ya 4 años desde entonces, y bastantes cosas han cambiado. Para empezar, la versión de ChirpStack, que ya ha va por la versión 4, mientras que el artículo anterior hacía referencia a la versión 3.
Las diferencias entre estas versiones son las siguientes:
- Principales Diferencias: ChirpStack v4 introduce mejoras significativas en lo relativo a facilidad de uso y arquitectura comparado con v3, enfocándose en simplificar la configuración y migración. Mientras v3 requería instancias separadas por región, v4 soporta múltiples regiones en un solo servidor. Además, v4 es totalmente compatible con ChirpStack Gateway Bridge v3 (versión 3.14.0+ usando protobuf), facilitando la transición sin interrupciones.
- Soporte Multi-Región: En v4 se elimina la necesidad de múltiples instancias de Network Server por región, permitiendo configurar gateways de diferentes regiones en un solo despliegue con archivos de configuración predefinidos para regiones comunes de LoRa Alliance. Esto contrasta con v3, donde cada región demandaba un setup independiente. Esta característica reduce la complejidad operativa y el mantenimiento.
- Interfaz de Usuario y API: La UI de v4 ha sido reescrita en TypeScript con gRPC-web para mayor usabilidad y modernidad, reemplazando la de v3 que era menos intuitiva. Respecto a APIs, v4 elimina el REST API embebido (recomendando un componente separado para REST sobre gRPC) y requiere actualizar clientes gRPC a v4, ya que los de v3 no son compatibles; los tokens API también deben regenerarse. Estos cambios priorizan eficiencia y seguridad.
- Identificadores y Eventos: v4 cambia identificadores numéricos (de v3) a UUIDs para entidades como organizaciones y usuarios, mejorando privacidad al evitar exposición de conteos en instancias públicas. Los mensajes de eventos de integración se refactorizan para incluir información base consistente (como tenant y device-profile) y uplinks decodificados como objetos directos, no strings JSON. Esto estandariza el manejo de datos.
- Otras Mejoras y Cambios Rompedores: v4 añade soporte nativo para FUOTA (Firmware Updates Over The Air) sin necesidad de servidores adicionales, alineado con especificaciones TS003/TS004/TS005. Se remueve el descubrimiento de gateways (no compatible con Basics Station) y la interfaz NetworkControllerService, reemplazada por logs en Redis Streams. Los algoritmos ADR personalizados ahora se implementan en JavaScript en lugar de Go compilado. Para migrar, se recomienda un script que copia datos de v3 a nuevas bases PostgreSQL/Redis.
En cuanto al despliegue, por mi parte opté por realizarlo como un contenedor de ProxMox. La verdadera razón para ello era que me apetecía probar un despliegue de contenedores en ProxMox, pero este tipo de despliegue tiene una serie de ventajas:
- Eficiencia de Recursos: Los contenedores LXC de Proxmox para ChirpStack v4 son ligeros, comparten el kernel del host y consumen menos RAM/CPU que una VM completa, permitiendo mayor densidad de instancias en hardware limitado sin overhead de OS emulado.
- Arranque Rápido: Los contenedores LXC inician en segundos, lo que es ideal para desplegar ChirpStack v4 rápidamente y escalar servicios LoRaWAN, a diferencia de VMs que tardan más en arrancar un SO completo.
- Aislamiento de Aplicación: Proporcionan aislamiento suficiente para ChirpStack (un servicio de red), protegiendo contra fallos sin el aislamiento total de VMs, lo que es perfecto para cargas de trabajo como servidores LoRaWAN en entornos Debian LXC.
- Gestión Simplificada: Integración nativa en ProxMox con backups automáticos, migración entre nodos de cluster y GUI web unificada, lo que reduce las necesidades de mantenimiento.
- Portabilidad y Escalabilidad: Es fácil clonar, migrar o respaldar contenedores, optimizando recursos para entornos de tipo IoT como ChirpStack, que tiene un consumo bajo de recursos en estático (ej. <4MB en Alpine LXC vs 60MB en VM).
- Compatibilidad Práctica: ChirpStack v4 se despliega exitosamente en LXC Debian de manera directa o con Docker, lo que minimiza el overhead y facilita actualizaciones, aunque las VMs ofrecen más flexibilidad si se necesita un kernel independiente.
La arquitectura de la v4 se ha simplificado, siendo sólo necesario realziar un despliegue de la interfaz de gestión, y del Gateway Bridge; esto permite seguir interactuando desde los gateways mediante comunicaciones UDP bidireccionales. Las comunicaciones internas de los elementos se apoyan en un broker MQTT. En mi caso, opté por hacer uso de mi servidor MQTT, a fin de evitar despliegues adicionales innecesarios.
Desde el punto de vista del proyecto, uno de los aspectos más interesantes es que la v4 permite hacer uso de claves API, para permitir la integración de aplicaciones externas y realizar una adecuada securización de estas integraciones. Estas claves API pueden definirse tanto a nivel de servidor como a nivel de tenant, lo que resulta muy conveniente para controlar de manera muy granular los permisos de acceso al entorno.
Otro de los aspectos a tener en cuenta es el relativo al cambio de la estructura de codificación del codec que permite traducir la carga útil (payload) de los paquetes de datos LoRaWAN. Pero eso lo dejaremos para más adelante, cuando comente sobre los dispositivos.
