Visual development in Sofia2 with Raspberry, Node-RED and Dashboards

6

We have already spoken in previous publications about Node-RED, a tool for visual editing and execution of flows.

In this post will be presented a set of nodes designed to interact with Sofia2 IoT Platform and will present a small demo using those nodes deployed on a Raspberry with a SenseHat sensor.

We will start presenting this set of nodes:

nodos1

We have a configuration node that has a global reach, that is, its state will be shared between flows. This node represents a shared connection with a remote system, in this case the configuration node is responsible for creating the connection (REST or MQTT) and make it available to the other nodes.

As for the other nodes are the performers of the operations of insertion, update, deletion, queries and release of the connection.

The nodes are available in Sofia2’s Github, in the npm repository and in the official Node-RED page.

Next we will develop two flows using the Node-RED tool, one of them will be deployed in a Raspberry Pi and another in Sofia2 IoT Platform:

nodos2

The flow of the Raspberry Pi will trigger the process:

nodos3

  • A node controls the SenseHat sensor data that we have integrated with our Raspberry Pi, and triggers the flow every second with temperature, pressure and humidity data.
  • A function node performs a data processing to generate a JSON instance that matches the ontology that is registered in Sofia2.
  • One of the nodes previously presented, will be responsible for sending a message to Sofia2 IoT Platform with the data obtained from SenseHat to the ontology and will be stored in the Real Time Database, which will feed us later the Dashboard.

The flow in Sofia2 IoT Platform

flujoNodeRed

We have a flow that consists of two parts:

  • On the one hand we have a node that retrieves from an Internet service the temperature of Madrid. This data is stored in the context at the flow level.
  • On the other hand we have a node listening the events received from the Raspberry to the ontology in which the data obtained from the SenseHat board are being inserted. In this flow a simple calculation will be made to obtain the difference of temperatures, in addition a rule will be created in which if that difference exceeds a certain threshold a tweet will be sent. Note that the temperature variation data will also be stored in another ontology in Sofia2, so that you can then feed the Dashboard.

Once the demo is in progress, we create a Dashboard on the Platform, which represents the data of temperature, pressure and humidity, collected from the SenseHat sensor, and also the data of the calculated temperature variation.

nodos5

This Demo is available in a guide format at the following link:

https://github.com/Sofia2/meetups/tree/master/Taller-IoT-NodeRED

Visual development in Sofia2 with Raspberry, Node-RED and Dashboards

Desarrollo visual en Sofia2 con Raspberry, Node-RED y Dashboards

6

Ya hemos hablado en publicaciones anteriores sobre Node-RED, una herramienta para la edición visual de flujos y motor de ejecución de dichos flujos.

En este post se van a presentar un conjunto de nodos diseñados para interactuar con Sofia2 IoT Platform y se presentará una pequeña demo utilizando dichos nodos desplegados en una Raspberry con un sensor SenseHat.

Empezaremos presentado este conjunto de nodos:

nodos1

Seguir leyendo “Desarrollo visual en Sofia2 con Raspberry, Node-RED y Dashboards”

Desarrollo visual en Sofia2 con Raspberry, Node-RED y Dashboards

Gateways en una Arquitectura IoT

En la edición 2015 de la Guía de Internet of Things de DZone encontramos un interesante artículo de Henryk Konsek sobre la importancia y características que tienen los Gateways en una Arquitectura IoT.

En resumen, en este articulo se comenta que la arquitectura típica de una solución IoT es generalmente más compleja que otros sistemas empresariales, debido a la gran cantidad de dispositivos que proveen o consumen información del backend, así como a la propia naturaleza de estos, que es muy diferente en cuanto a capacidades y funcionalidad, a los clásicos clientes web o incluso móviles. Haciendo necesario incluir otro elemento en la arquitectura, denominado Gateway, que actúa de proxy entre los dispositivos y la Plataforma IoT.

La necesidad de introducir gateways en una arquitectura IoT nace de las siguientes limitaciones:

  • Normalmente los sensores y dispositivos tienen capacidades interconexión muy limitadas, utilizando protocolos de bajo consumo y relativamente corto alcance (Bluetooth Low Energy, Zigbee…), y conectándose a redes de área local (LAN) o residencial (HAN). Es necesario un Gateway para coordinar la red de sensores y actuar de proxy con la red de área ancha (WAN) donde la plataforma IoT expone sus interfaces para recibir y proporcionar información.
  • El tratamiento de la información en bruto procedente de sensores y dispositivos, directamente en la plataforma IoT, puede ser en ocasiones ineficiente en términos de rendimiento y ancho de banda. Por lo que es necesario disponer de Gateways con capacidad de almacenamiento temporal de la información y procesamiento de la misma. De este modo es posible filtrar y agregar la información antes de enviarla a la plataforma, así como garantizar que no se pierde información en caso de interrupción temporal de las comunicaciones.
  • Disponer de un Gateway que centralice las operaciones de monitorización de todos los dispositivos conectados a su red de sensores, reduce la complejidad del sistema de monitorización, que solo se tiene que conectar al Gateway.

El software de un Gateway es el componente que realiza la lógica de tratamiento de la información recopilada de la red de sensores o dispositivos para enviarla a la plataforma IoT, así como de comandado, permitiendo a la plataforma IoT interactuar con el entorno cubierto por dichos sensores y dispositivos.

En este sentido, el software de un Gateway es el encargado de consultar periódicamente o bajo demanda las distintas medidas de los sensores o dispositivos, agruparlas en entidades mayores de información y enviarlas a la plataforma IoT. Recibir órdenes de comandado desde la plataforma y dirigirla al actuador correspondiente. Consultar el estado de los sensores o dispositivos y ofrecerlos al software de monitorización.

El software de un Gateway debe estar diseñado para soportar al menos estos tres criterios:

  • Recuperación ante fallos: Interrupción de la alimentación, caída de comunicaciones, fallos en sensores o dispositivos…
  • Soporte para actualizaciones automáticas, gestionadas desde entorno remoto centralizado.
  • Soporte para configuración centralizada, gestionada desde entorno remoto centralizado.

En Sofia2 IoT Platform la construcción de Gateways recae del lado cliente de la arquitectura, siendo construidos como Apps Sofia2 (en terminología Sofia2 KPs – Knowledger Processor –  o ThinKPs – Thing + KP), que gestionan los distintos sensores, actuadores y dispositivos a través del protocolo concreto para cada uno (Zigbee, bluetooth, señales GPIO…), y se comunican con la plataforma Sofia2 utilizando el protocolo de mensajería SSAP a través de cualquiera de los protocolos físicos expuestos como interfaz por el SIB (REST, MQTT, Websocket, Ajax/Push…).

En el desarrollo del software de un Gateway para Sofia2, cobran especial importancia las distintas APIs (Java, .Net, C, Javascript, Node.js, Android, IOS…), que simplifican al desarrollador las funciones de construcción de mensajes SSAP así como de encapsulamiento del protocolo físico de comunicación con Sofia2.

Dentro de la Suite de productos Sofia2, está disponible el KP-Modelo (más info aquí y aquí). Se trata precisamente de una infraestructura sofware (construida en Java), que puede ser desplegado en un Gateway con unos requisitos hardware bastante reducidos (pj  Raspberry Pi de primera generación: 128 MB RAM) y que proporciona todas las funcionalidades de recuperación ante fallos, gestión remota del software y de la configuración, así como de la persistencia de mensajes. De modo que solo tiene que ser extendido con la lógica de acceso a los distintos sensores, actuadores y/o dispositivos.

Tanto las APIs como el KP modelo están disponibles para su descarga en la sección de descargas de sofia2.com:

Otro Gateway integrado con Sofia2 es Node#1. Se trata de la solución de Indra para proporcionar distintos servicios de alto rendimiento y eficiencia, en ámbitos Smart Home, Smart Metering, Smart Grids, Servicios Energéticos y Gestión Activa de la Demanda. http://www.indracompany.com/noticia/indra-incorpora-tecnologia-intel-su-plataforma-smart-energy. Puede controlar simultáneamente varias redes de sensores, actuadores o dispositivos, y realizar tareas de procesamiento y monitorización. Utiliza la plataforma IoT Sofia2 como middleware de integración con otros sistemas así como de backend de información para analítica Big Data.

A su vez, Sofia2 es una de las plataformas certificadas para el Gateway Meshlium http://www.libelium.com/es/products/meshlium. Se trata de un Gateway comercial fabricado por Libelium. Este conector estará disponible en el software de serie del Gateway, permitiendo la integración con la plataforma Sofia2 de cualquier red de sensores o dispositivos que pueda gestionar, típicamente desplegados en balizas de tipo Waspmote http://www.libelium.com/es/products/waspmote

Gateways en una Arquitectura IoT