Software de Interés
Thingsboard
Thingsboard.io se está posicionando como una plataforma de integración para dispositivos IoT Open Source y la verdad es que promete. Con una documentación muy completa y la posibilidad de instalación en nuestros servidores así como su utilización en la nube con una diversa gama de planes de subscripción en base a dispositivos y bienes. Su modelo de instalación se adapta a todos los gustos: Windows, Linux, Raspberry Pi, Kubernetes, Docker. etc.
La plataforma puede recoger datos de nuestros dispositivos IoT definidos, realizar procesos de adaptación/modificación sobre los mismos a través de un motor de reglas potente y realizar paneles de mando muy profesionales, avalada toda esta interoperabilidad por empresas como:
Otro aspecto importante es la organización de perfiles para su uso que permiten la convivencia de diferentes servicios/soluciones desde una instancia única con usuarios y roles organizados para su administración general, administración de servicios/soluciones concretas así como el uso personalizado de perfiles de clientes, todos y cada uno de ellos con su acreditación y sin olvidar la posibilidad de compartición en abierto de paneles de monitorización para poderlos insertar o permitir un uso abierto de sus métricas en nuestros portales y/o aplicaciones. Esto sólo es un resumen introductorio para suscitar el interés que merece pero tenéis toda la información en la web de la plataforma Thingsboard.io.
La base fundamental es tener dispositivos IoT que configuremos para que envíen los datos a la plataforma a través de protocolos sencillos como CoAP, MQTT o HTTP, pero en este artículo, previo a las vacaciones merecidas de verano, queremos enseñaros la posibilidad que nos proporciona FiWare para integrar los datos de nuestros sensores ya desplegados en nuestro “core” FiWare con Thingsboard.io como plataforma adicional de usuario, donde poder desplegar paneles de mando de manera sencilla y con la mínima complicación desde el punto de vista de FiWare, en definitiva, vamos a alimentar tambiénThingsboard.io desde FiWare para la gestión de paneles de mando y/o monitorización desarrollados por el propio usuario.
FiWare
Un conjunto de sensores ya desplegados (para nuestro ejemplo, nuestros sensores LoRaWAN que a través de TheThingsnetwork.org y nuestro agente LoRa para FiWare recopilan la información hacia nuestro servidor de contexto) serán los medios que que vamos a utilizar de prueba ya los tenemos monitorizados con nuestras propias herramientas y aplicaciones; No queríamos “reutilizar” -programar desde cero el dispositivo- ninguno de nuestros sensores para poder probar las bondades de Thingsboard.io, por lo tanto y utilizando una gran propiedad de nuestro servidor de contexto, lo único a considerar y configurar en nuestro “core” de FiWare, es la posibilidad de que, una vez recepcionados los datos de nuestros sensores a través de los diferentes agentes (LoRaWAN, SigFox, HTTP, MQTT, etc) los dirijamos también hacia nuestra plataforma de Thingsboard de la misma manera que lo dirigimos hacia otros “enablers” como bien pueden ser, aquellos que se encargan de ir generando nuestros históricos. Sería el mismo procedimiento, rápido, claro y transparente.
Utilizando una propiedad fundamental de nuestro servidor de contexto tenemos la solución simple y transparente: las suscripciones y sobre todo la posibilidad de realizar suscripciones con peticiones personalizadas desde donde poder manipular cabeceras, métodos, consultas y payload asociado a los datos de nuestras entidades y adaptados a nuevas necesidades, en este caso la integración con la plataforma Thingsboard que hemos desplegado. Vamos a explicar rápidamente estos sencillos pasos.
Lo primero que hacemos es en nuestra plataforma Thingsboard es definir nuestro dispositivo en un servicio previamente establecido:
Para cada dispositivo, además de su información general (los detalles en la documentación de Thingsboard.io), nos interesa un dato que genera por encima de todo, el TOKEN de acceso para poder acceder a él en base a peticiones según protocolo. Este TOKEN, junto con nuestro servidor Thingsboard y las cabeceras personalizadas son los datos que utilizaremos para realizar una suscripción adicional en nuestro servidor de contexto para un dispositivo ya provisionado que redirija los datos. La suscripción es de la forma siguiente:
La documentación particular definida en Subscriptions Payload Validation de la documentación oficial de FiWare nos enumera las posibilidades de composición de una suscripción y en especial para el caso que nos ocupa, fijamos nuestra atención en las notificaciones adaptadas a través de las validaciones httpCustom desde la que podemos definir nuestro “endpoint” personalizado (url), modificaciones sobre la cabecera (headers), argumentos de consulta (qs) y los datos (payload).
Dada un suscripción sencilla sobre un dispositivo específico provisionado en nuestro “core” FiWare, a través de idPattern. Definimos nuestra notificación hacia nuestro “endpoint” especificando nuestro servidor Thingsboard y la llamada a la API correspondiente con el TOKEN de acceso definido previamente para este dispositivo según la API de uploads de telemetría documentada en Thingsboard.io
Siguiendo las indicaciones del formato de datos de Thingsboard.io según la API mencionada anteriormente, sólo tenemos que confeccionar nuestro payload con la misma estructura y utilizar las potencia de las sustituciones de FiWare basadas en las macros ${...} que nos ofrece el servidor de contexto para las suscripciones de la forma:
Hay que tener cuidado con la utilización de secuencias de escape o codificación URL para una perfecta generación de la petición y sustitución de los valores a través de las funciones de macro. En la imagen superior describimos un ejemplo concreto.
Una vez generada la suscripción sólo nos queda comprobar que la telemetría, además de actualizada en nuestro “core” FiWare también nos llega a nuestro dispositivo en nuestro servidor Thingsboard desplegado.
En nuestra aplicación a través de los datos de FiWare podemos comprobar que nos siguen llegando los datos de manera natural:
Y con Thingsboards podemos comprobar que nos llegan los datos a través de la opción de consulta de última telemetría en el registro del dispositivo, de esta forma:
Y por último, ya teniendo en cuenta que los datos los tenemos por dos fuentes distintas y sin interferencias de ningún tipo entre ellas, sólo no queda el montaje de un Dashboard en la nueva plataforma según las instrucciones de Thingsboard.io, fáciles de diseñar y de montar en unos minutos gracias a su librería de widgets “listos para usar”.
Conclusiones
A través de FiWare podemos re-utilizar todos los sensores que tengamos provisionados y de cualquier naturaleza sin necesidad de reprogramar cada uno de los dispositivos para integrarlos con cualquier otra aplicación, plataforma, etc. ya sea propietaria o abierta de manera sencilla y óptima a través de la potencia de las suscripciones.
En este caso, Thingsboard nos aporta solución de cliente para ese elemento de integración tan necesario en nuestras soluciones como es el uso de una plataforma amigable para gestionar y monitorizar todos nuestros dispositivos.
Ya tenemos un círculo cerrado para soluciones a medida y de bajo coste: dispositivos DIY, sistema de comunicaciones abiertos LoRaWAN a través de TheThingsnetworks.org y plataformas robustas de integración para la gestión y monitorización de dispositivos en una arquitectura multiservicios, con diferentes roles de utilización y gestión así como paneles de control creados a gusto de cada usuario.
Vamos a aprovechar el confinamiento para poner en funcionamiento este vínculo atractivo entre nuestros dispositivos basados en LoRa/LoRaWan e InfluxDB que creo, de gran importancia, para el desarrollo rápido y transparente. Desde nuestra Aula de Transformación Digital FiWare usamos la gestión de datos que nos proporciona el estandard FiWare pero en la propuesta de hoy, además y simultáneamente, los datos pueden ser redirigidos a otras herramientas de gran evolución y aceptación últimamente. Una solución muy fácil de implementar.
InfluxDB se formaba como una BBDD de series temporales No-SQL, además aporta una gran integración con herramientas de graficación como Grafana que representa los datos con gran facilidad y con toda su potencialidad al ser una de las BBDD de base con las que trabaja esta herramienta, por tanto utilidades como umbrales, alarmas y avisos se encuentran contemplados, de esta manera, los datos de nuestros dispositivos pasaban a InfluxDB y desde Grafana se monitorizaban con gran precisión.
Pero InfluxDB no es sólo una BBDD sino que se ha nutrido de servicios adicionales, de esta forma se pusieron en valor los exploradores de datos, agentes encargados de dirigir información desde diferentes fuentes a la BBDD común y por último la graficación y monitorización. La última versión integra "all-in-one" la BBDD, el explorador y la graficación (entre otros también: gestión de buckets, usuarios, roles, etc.) pero además, dispone de un elemento excepcional para el caso que nos ocupa, que es Telegraf.
Telegraf es un agente, esto es un servicio que se encarga de capturar datos de diferente naturaleza e integrarlos en la BBDD de InfluxDB, a partir de ahora no lo llamaré BBDD sino modelo de gestión de Influx, o simplemente Influx. Influx ha generado un servicio en la nube, pero también puede ser desplegado en nuestro propio ordenador, servidor etc. por tanto somos los propietarios, sin intervención, de nuestros datos (sin abrir otro debate!!).
Pues bien, lo que pretendemos hacer es que este agente, se encarge de tomar los datos de nuestros dispositivos LoRa/LoRaWAN a través de TTN e inyectarlos en nuestro Influx, por tanto los podemos explorar y graficar. En nuestro propio ordenador podemos instalar Influx + Agente Telegraf y desde un sólo equipo, tener la solución que estamos buscando. Para esto vamos a jugar con los siguientes recursos del Aula de Transformación Digital FiWare:
Tenemos los sensores de campo que estamos desplegando (temperatura y humedad) en su envolvente IP65 de la firma Zane que nos provee. Son dispositivos robustos y con gran autonomía que nos envía su información cada 5-15min, según configuración. También, y para interiores (ahora en casa), el gateway TTIG que nos sirve de pasarela para llegar a TTN.
Nos interesa la gestión de datos desde Influx, por tanto no entramos en la configuración de los dispositivos y tampoco en la definición de los mismos en la red TTN, presuponemos este conocimiento, se puede encontrar mucha información al respecto Googleando "solo un poco" (prometemos hacer otro artículo en breve), lo más importante y punto clave de nuestro desarrollo, es la inyección de los datos que nos reporta TTN hacia Influx.
Para inyectar datos en Influx sería necesario utilizar la API de Influx, tener credenciales en base a un sistema Tokenizado y hacer peticiones POST. Esto se podría hacer a través de las integraciones de TTN pero, lo vamos a hacer más fácil: SIN INTEGRACIONES. TTN dispone de un servicio intrínseco que es MQTT, con lo cual para cualquier aplicación desplegada en TTN nos permite subscribirnos a los dispositivos y por tanto obtener sus valores a través de sus servidores MQTT y credenciales correspondientes. Y aquí, es dónde nuestro agente Telegraf va a desarrollar toda su función.
Recopilemos: en nuestro servidor tendremos nuestro propio Influx y nuestro propio agente Telegraf. En la página WEB de Influx podemos econtrar información de su instalación en diferentes plataformas. En nuestro caso, instalaremos los recursos señalados en la imagen.
Una vez instalado y funcionando estos servicios en nuestro servidor, tendremos acceso al modelo de gestión de Influx a través de la URL y puerto correspondiente, y nuestro agente (telegraf), por defecto empezará a inyectar datos de nuestro servidor, bbdds o buckets, que crea por defecto al inicializarse por primera vez. Pero lo que queremos son los datos de nuestros dispositivos en TTN. Veamos como:
Como hemos dicho, Telegraf permite inyectar datos de diferentes fuentes, y en nuestro caso, de subscripciones MQTT. Pues vamos a configurar nuestro agente telegraf para que haga esta labor. Para ser concretos, primero tendremos que definir en nuestro agente, cual será nuestro servidor Influx y segundo, definir en nuestro agente las subscripciones MQTT de TTN.
En la siguiente imagen, ponemos los datos del servidor Influx, el token necesario para acceder desde el agente (que generamos nosotros desde Influx) y la bbdd o "bucket" a utilizar para estos datos. Esta definición corresponderá con el destino de los datos que el agente inyecta. El fichero de configuración lo encontramos en /etc/telegraf en sistemas unix*
Por otro lado, definimos el origen de datos. Entre los diferentes orígenes por defecto que gestiona el agente Telegraf, encontramos el mqtt_consumer. Definimos por tanto, aquí, las subscripciones con las credenciales que nos brinda TTN para cada aplicación:
Una vez todo configurado, reiniciamos el agente y pasamos a ver los resultados. Por el momento ya no hay NADA MAS que hacer, los datos de nuestros dispositivos cuando lleguen a TTN los captura nuestro agente Telegraf vía MQTT y los inyecta en Inlfux. Solo nos queda irnos a nuestro modelo de gestión de influx, explorar y empezar a definir nuestros gráficos.
Veamos un ejemplo de exploración que también nos servirá para generar un gráfico en el Dashboard integrado de Influx. Selecciona cada uno de los puntos indicados en la imagen y al final ejecuta la orden a través del botón de SUBMIT. Tenemos que seleccionar nuestro bucket, recuerda que en el agente definimos el bucket que se llamaba "smart", en este bucket tenemos diferentes medidas; se ha creado una media para los contenidos de origen MQTT, la denominada "mqtt_consumer", acto seguido nos aparecen los uplinks de los dispositivos pertenecientes a las distintas aplicaciones, por tanto seleccionamos los que quermos graficar y, por último los valores correspondientes.
Esta misma exploración de datos la realizamos para la generación de un gráfico determinado en nuestros dashboards. Vamos a crear un "Grapfh + SingleStat" desde la opción de Dashboard en Inlfux.
Fácil ¿ no ?, pues poco a poco vamos añadiendo gráficos hasta que tengamos el Dashboard que mejor se adapte a nuestras necesidades.
Node-RED is a flow-based development tool for visual programming developed originally by IBM for wiring together hardware devices, APIs and online services as part of the Internet of Things.
Node-RED provides a web browser-based flow editor, which can be used to create JavaScript functions. Elements of applications can be saved or shared for re-use. The runtime is built on Node.js. The flows created in Node-RED are stored using JSON. Since version 0.14 MQTT nodes can make properly configured TLS connections.
In 2016, IBM contributed Node-RED as an open source JS Foundation project.