24 abr 21 Trazabilidad de activos en exterior con LoRaWAN, Chirpstack, Node-Red y una arquitectura de microservicios
Bonito combo el del título de este artículo, ¿verdad? A resultas de algunas actividades que estoy realizando en el trabajo relacionadas con redes IoT industriales, en mi tiempo libre le he dado una vuelta de tuerca al proyecto, para realizar un piloto de trazabilidad de activos en exterior. Cómo no, basado en el uso de LoRaWAN y Chirpstack, como contaba en un artículo anterior.
Arquitectura LoRaWAN
La cosa es que aprovechando que contaba con una pequeña infraestructura local de Chirpstack desplegada mediante microservicios, me hice con un dispositivo de Dragino bastante interesante, el LBT1:
Dragino LBT1
Este dispositivo es bastante interesante: integra un módulo GPS que permite obtener su ubicación precisa, que es trasmitida mediante LoRaWAN para ser posteriormente explotada. Pero cuenta con capacidad Bluetooth, para realizar ubicación en interiores mediante iBeacons; dispone de un acelerómetro, de tal manera que el dispositivo tiene capacidad de enviar la señal LoRaWAN cuando detecta movimiento y no de manera indiscriminada, con el consiguiente ahorro de batería; tiene una batería recargable de 1000 mAh (que he podido probar que da para más de una semana de actividad sin necesidad de recarga); y cuenta con un botón que -en su configuración por defecto- permite pasar al dispositivo a un modo de emergencia, de tal manera que pasa a emitir la señal de manera periódica (y no activada por el acelerómetro, como en el modo normal), y con una codificación del paquete de datos específica, de tal manera que es posible distinguirlo de una transmisión normal, y actuar en consecuencia.
Estas capacidades, junto con la característica de integración HTTP proporcionada por Chirpstack, permiten algo bastante interesante, y es realizar un sistema de monitorización de activos en exterior, si lo combinamos con un procesamiento en segundo plano. Para ello, en mi caso, he utilizado Node-Red.
Flujo Node-Red para trazabilidad de activos
La idea general es la siguiente: se establece un punto de entrada desde donde recibir los POST HTTP provenientes de Chirpstack, que nos harán llegar cada uno de los eventos provenientes de los dispositivos. Aquí realizamos un primer procesado para obtener información relevante de la señal transmitida (básicamente, latitud, longitud, identificador del dispositivo, cantidad de carga de la batería, y si se trata o no de una señal de emergencia). Con esta información realizamos dos acciones: representar cada objeto definido en la aplicación Chirpstack y que esté enviando señal en el mapa, bien con un icono verde si todo va bien, o con un icono rojo si se ha pulsado el botón de emergencia. Además de esto, se mantiene trazabilidad de los movimiento realizados creando una línea con las distintas ubicaciones GPS enviadas por el dispositivo. Todo ello se representa sobre un mapa, que permite definir zonas de calor, y filtrar por cada uno de los objetos que estén enviando señal. El resultado es algo como esto:
Mapa de ubicaciones resultante
El sistema, además, tiene capacidad para integrarse con sistemas de monitorización de terceros, así como con sistemas de alerta específicos. En mi caso he realizado un procesamiento adicional, que consiste en realizar persistencia de datos para su análisis posterior, en este caso, mediante una hoja de Google Spreadsheet, lo que es interesante de por sí, y puede dar para otro artículo.
Este ejemplo de aplicación tiene bastantes aplicaciones prácticas: realizar seguimiento de activos en una zona exterior de una empresa, seguimiento de personas mayores en zonas urbanas sin coste de transmisión de datos, y con la capacidad de que emitar una señal de emergencia en caso de necesidad, o el seguimiento de visitantes en parques naturales y zonas boscosas, ya que como demostré hace algún tiempo, es posible cubrir zonas muy amplias en entorno forestal con un despliegue de infraestructuras mínimo. E incluso, que es lo que tenía en mente, un sistema para seguimiento de ciclistas o senderistas de montaña en zonas de montaña.
Etiquetas: chirpstack, dragino, lora, lorawan, microservicios, node-red
13 mar 21 Despliegue de un servidor LoRaWAN libre con Chirpstack basado en contenedores
Estas semanas (en parte por afición y en parte por trabajo) he seguido avanzando con mis investigaciones con tecnología IoT basada en LoRaWAN. Ya había hablado anteriormente de comunicaciones básicas LoRa, uso de una red abierta LoRaWAN como es la red TTN, pero no había tocado el tema de disponer de un servidor LoRaWAN privado. Y es aquí donde entra en acción Chirpstack. Éste es un diseño basado en software libre que proporciona la capacidad de conectar dispositivos de campo LoRa y junto con los Gateway LoRaWAN permite constituir una red privada LoRaWAN. En este contexto, ChirpStack una solución que mediante una interfaz de usuario amigable permite gestionar dispositivos, usuarios, gateways, y que proporciona una interfaz de integración que permite interactuar con terceros sistemas.
Interfaz web de administración de Chirpstack
ChirpStack proporciona una serie de componentes que interactúan entre sí para proporcionar la infraestructura necesaria para recibir información de dispositivos y gateways LoRa, con el objeto de proporcionar capacidades de gestión de dichos dispositivos (por un lado) y de poner la información que envían los dispositivos a disposición de terceros sistemas para que la consuman. Esto se articula en base a los siguientes componentes:
- Dispositivos LoRa: Dispositivos de campo que envían por LoRa información de los sistemas que controlan (final de carrera, sensor de temperatura, el propio estado del dispositivo, etc…) a un Gateway, o bien que reciben información de este Gateway para realizar una acción (activar un relé, encender un led…).
- Gateway LoRaWAN: Elemento que recibe información de los dispositivos, y transforma un paquete LoRa en un paquete IP (bien TCP o UDP, aunque lo más común es lo primero), transfiriendo la información que proporciona el dispositivo hacia un servidor donde esta información es procesada. También tiene capacidad de enviar información o solicitud de acciones a los dispositivos por parte de este servidor. Junto con los dispositivos LoRa, constituyen los elementos de campo, y aunque no forman parte estrictamente hablando de ChirpStack, sí tienen una interacción muy cercana con él.
- Gateway Bridge: Es el primero de los componentes de ChirpStack, si seguimos el flujo de datos desde los dispositivos de campo hasta los servidores de computación. Su función es recibir la información de los gateways y procesarla, volcándola en un servidor MQTT de mensajería. Este bridge puede residir en el servidor donde se despliegue ChirpStack, en los propios gateways LoRa o estar instalado en un tercer componente aparte. Su función primordial, en pocas palabras, es volcar la información proveniente de la red LoRaWAN en el sistema de mensajería MQTT, donde será consumida por el resto de servicios de ChirpStack.
- Network Server: Segundo de los componentes de ChirpStack. Es el servidor de red LoRaWAN propiamente dicho. Se encarga de monitorizar el estado de la red, los dispositivos conectados a la misma, y administrar el acceso de nuevos dispositivos a la red. También se encarga, en el caso de redes con múltiples gateways, de resolver duplicidades de dispositivos (dado que un paquete enviado por un dispositivo puede ser recibido y procesado por más de un Gateway), consolidar la información, y ponerla a disposición del servidor de aplicaciones de ChirpStack. También se encarga de las siguientes funcionalidades: Autenticación de dispositivos; gestión de la capa mac LoRaWAN; gestionar el envío de mensajes desde ChirpStack a los dispositivos, haciendo uso del canal descendiente de comunicaciones.
- Application Server: Tercer componente de ChirpStack. Es corazón de la arquitectura. Permite crear “aplicaciones”, que en este contexto son grupos de dispositivos que envían una información del mismo tipo. Relaciona la información enviada por uno o varios dispositivos, almacenando un histórico, y la pone a disposición de terceros sistemas mediante diversos métodos de integración.
- Geolocation server: Componente opcional que permite dotar de mayores capacidades de geolocalización de los dispositivos, en caso de que el Gateway no proporcione esta información, o en el que queramos hacer un tratamiento personalizado de la misma.
- Broker MQTT: Utilizado como sistema de mensajería interna para el resto de componentes de ChirpStack y la comunicación con los gateways.
- Redis: Motor de base de datos en memoria, que gestiona la información que se intercambia entre los dispositivos y aplicaciones creadas en ChirpStack.
- Base de datos PostgreSQL: Almacena información de configuración de ChirpStack, organizaciones, aplicaciones, usuarios, etc… además de información histórica enviada por los dispositivos. Existen diversos mecanismos (HTTP, MQTT, InfluxDB, RabbitMQ, PostgreSQL, Azure Service Bus, AWS SNS, API REST).
Arquitectura de alto nivel de Chirpstack
El aspecto clave de ChirpStack hace referencia al modo en el que se procesa la información. ChirpStack hace uso de los componentes anteriores para componer y almacenar información estructurada proveniente de los dispositivos de campo, en un formato similar al siguiente:
{
“applicationID”: “123″,
“applicationName”: “temperature-sensor”,
“deviceName”: “garden-sensor”,
“devEUI”: “0202020202020202″,
“rxInfo”: [
{
"gatewayID": "0303030303030303",
"name": "rooftop-gateway",
"time": "2016-11-25T16:24:37.295915988Z",
"rssi": -57,
"loRaSNR": 10,
"location": {
"latitude": 52.3740364,
"longitude": 4.9144401,
"altitude": 10.5
}
}
],
“txInfo”: {
“frequency”: 868100000,
“dr”: 5
},
“adr”: false,
“fCnt”: 10,
“fPort”: 5,
“data”: “…”,
“object”: {
“temperatureSensor”: {“1″: 25},
“humiditySensor”: {“1″: 32}
},
“tags”: {
“key”: “value”
}
}
Otro aspecto interesante es que Chirpstack se puede desplegar de muy diversas maneras, al estar estructurado en una serie de componentes bien definidos que se comunican entre ellos mediante puertos e interfaces estandarizados. Permite tanto realizar un despliegue convencional en un único servidor, a desplegarse en un modelo de microservicios en un entorno Docker o Kubernetes. Para el caso en el que estoy trabajando, he optado por hacer un despliegue basado en contenedores Docker en una máquina virtual, aunque he realizado algunas pruebas con un despliegue más monolítico, y en el ámbito laboral estoy haciendo uso de un entorno Kubernetes.
El despliegue mediante Docker es tremendamente sencillo, ya que los propios desarrolladores de Chirpstack proporcionan una configuración de ejemplo con todos los elementos necesarios. Y una vez desplegado, es bastante sencillo añadir los componentes necesarios. En mi caso, he integrado un gateway Dragino LG308. La integración es tan sencilla como apuntar el servicio LoRaWAN del gateway al puerto 1700/UDP del servidor donde se encuentre levantado el componente Network de Chirpstack. Es posible desplegar un paquete software en el gateway Dragino para convertirlo en un Gateway Bridge de Chirpstack, pero si tenemos éste desplegado en otro sitio, no es necesario realizarlo.
Registro de un gateway en Chirpstack
Y en cuanto al registro de los dispositivos, tampoco supone mayor inconveniente. Es necesario definir de manera previa unos perfiles de configuración de dispositivos y la aplicación donde registramos estos últimos, y a partir de ahí, se puede crear la propia aplicación, y registrar los dispositivos, bien por OTAA o ABP, en función de nuestras preferencias. Con todo ello, se tiene una red privada LoRaWAN perfectamente funcional.
Ejemplo de recepción de datos de un dispositivo de campo (1)
Ejemplo de recepción de datos de un dispositivo de campo (2)
Etiquetas: chirpstack, contenedor, docker, dragino, kubernetes, lora, lorawan, microservicio
Medidor de entropía
