Trazabilidad de activos con LoRaWAN e IA generativa
Hace ya algunos años que llevo trasteando con la tecnología LoRaWAN. Hay una serie de artículos en este mismo sitio web al respecto, de temática variopinta: una serie sobre Gateways LoRaWAN, pruebas de conectividad, e incluso uno sobre la trazabilidad de activos. Es este último el que me interesa. Dentro de mis investigaciones, tanto para ámbito personal como para el profesional, desarrollé un prototipo rápido de cómo usar dispositivos Dragino GPS para ubicar activos en un mapa, trazar sus movimientos, e incluso establecer un mapa de calor de las ubicaciones más utilizadas. Funcionaba bien, estaba hecho con Node-RED, pero era ciertamente básico. Un demostrador, más que otra cosa. Pero la idea se quedó pululando en mi cabeza.
Así que otro de los proyectos en los que he estado trabajando estas semanas ha sido en dar una vuelta de tuerca a esta idea, y conseguir algo bastante más acabado. Así que empecé a elaborar una serie de puntos de mejora que aplicar a la versión rápida que había elaborado con anterioridad. A bote pronto, salieron unos cuantos:
- Gestión de usuarios: No había ningún tipo de control de usuarios en la aplicación anterior, sólo dispositivos. Esto implicaba que se podía saber qué movimientos había hecho un dispositivo, pero no saber quién había realizado esos movimientos.
- Gestión de dispositivos: Más allá de tener los dispositivos ubicados en un mapa, no había capacidad de gestión alguna. No era posible borrarlos, editarlos, cambiarles el nombre, o asignarlos a un usuario del entorno.
- Información de gateways: Los gateways no existían desde el punto de vista de la aplicación. Una de las cosas interesantes de LoRaWAN es que, además de enviar información del dispositivo, proporciona también información sobre los gateways que han recibido la señal enviada por el dispositivo. Esto permite realizar triangulaciones, representarlos sobre un mapa, establecer métricas de calidad de servicio… Toda esta información se estaba perdiendo.
- Historial de mensajes: No se guardaba registro alguno de los mensajes recibidos. Es interesante tener registrada esta información, dado que en el futuro es posible que exista otro registro valioso, que a día de hoy no lo es. Los mensajes, una vez procesados, se perdían.
- Historial de actividad: La clave de todo el asunto. La visibilidad sobre un mapa está muy bien, pero el no poder realizar filtrados por actividad en una fecha determinada para un usuario en concreto era un punto faltante claro. Casi que valía la pena emprender el proyecto nada más que por esto.
- Sistema de mensajería robusto: La lógica de gestión del canal de comunicaciones era básicamente inexistente. Un post HTTP contra un flujo de aplicación en Node-RED. Lo cual, teniendo a mi disposición un servidor MQTT, era casi una vergüenza. Era necesario usar algo más adecuado.
- Base de datos relacional: Y con todo lo anterior relacionado con mantenimiento de información, una base de datos se hacía imprescindible. No puedes confiar en mantener un registro histórico sin una base de datos mínimamente consistente.
- Soporte universal de dispositivos: No tenía tampoco mucha lógica limitarse a un tipo concreto de dispositivos. ¿Por qué no implementar una lógica que permita usar dispositivos heterogéneos?
Como todo esto daba ya para una aplicación bastante consistente, valía la pena invertir tiempo en el desarrollo de la aplicación. Pero esto implicaba, además de un proceso de desarrollo software, invertir en backend:
- Un entorno de despliegue: Resuelto con mi estupendo servidor de virtualización con ProxMox. Disponía de capacidad de cómputo y de espacio en disco sobrado. Me decidí a desplegar la aplicación a desarrollar en mi servidor virtual de backend.
- Un servidor LoRaWAN: Aquí la elección estaba clara. Necesitaba desplegar un servidor Chirpstack. Algo que a priori no representaba ningún problema, y con lo que tengo experiencia sobrada. Aunque esta vez le íbamos a dar una vuelta de tuerca. Lo iba a desplegar como contenedor en ProxMox. Y de paso, a probar la nueva versión existente.
- Dispositivos hardware: Cuando empecé a trastear con el asunto no tenía a mano los Dragino que venía utilizando. Sólo disponía de un Cubecell AB01 y de un módulo GPS para Arduino (el Neo 6M), así que tocaba también probar la validez de este dispositivo.
- Un gateway: Al igual que el caso anterior, no tenía acceso a los gateway Dragino que venía empleando en el ámbito laboral, y el gateway de un canal, más allá de la diversión de la prueba de concepto, no era un sistema sólido en el que basarse. Tocaba hacerse con uno.
Una vez puestos en pie estos puntos, era el momento de empezar a pensar en la aplicación. En los próximos artículos voy a escribir sobre los distintos aspectos tecnológicos involucrados en el este proyecto, en el que la IA generativa, cómo no, tuvo un peso importante, en diversos aspectos. Sirva como adelanto del contenido la siguiente captura de la aplicación:
