Orquestación de notebooks desde motor de flujos: Procesamiento de imágenes con Sofia2

image1

En la nueva versión de Sofia2 se ha añadido un nuevo nodo al motor de flujos capaz de gestionar ejecuciones sobre notebooks de la plataforma.

Con esta nueva característica, se pueden orquestar procesos basados en notebook e incluso paralelizar los mismos distribuyendo la carga de trabajo. Es posible pasar parámetros dinámicos a estos notebooks, pudiendo incluir información fija o generada por un flujo sobre cualquier lenguaje usado en los notebooks y más adelante iniciar una ejecución con los mismos.

Al igual que los parámetros de entrada, se posibilita la salida de los datos generados por uno o varios párrafos de un notebook, incluyendo información generada por un proceso analítico dentro del flujo y tomar decisiones en base al mismo.

Vamos a ver un tutorial de uso del mismo. Tendremos varios elementos de Sofia2 que nos ayudarán a construir y procesar una imagen que el usuario incluirá a través de una web, los cuales son:

  • Proyecto Web: Donde alojaremos la web donde el usuario subirá su imagen y verá los resultados.
  • Binary Repository: Para almacenar y recuperar las diferentes imágenes generadas
  • SSAP: Que nos servirá para comunicarnos entre los diferentes elementos
  • Motor de Flujos (Nodered + nodo Notebook Launcher)
  • Notebooks Sofia2: Usaremos dentro de los mismos Python junto con la librería PIL para procesar imágenes.
  • Gadgets Sofia2: Tendremos un gadget donde se mostrará el histograma de la imagen subida

Lo primero que haremos, será crear un proyecto en Sofia2 que tendrá un domino del motor de flujos y que también tendrá asociada la web.

image2

En la web asociada al proyecto tendremos una interfaz simple que permitirá subir un imagen al binary repository, realizará un POST sobre una URL que iniciará el flujo de procesamiento (al que le pasará los datos de la imagen ya subida) y que mediante el protocolo SSAP se subscribirá a la ontología donde recibirá los resultados de las imágenes ya procesadas.

image3

La url donde se pueden ver los resultados y el código fuente es la siguiente https://sofia2.com/web/imageprocess/imageFlow.html

A continuación, veremos los notebooks necesarios para el procesamiento, así como la configuración necesaria en el motor de flujos. Los notebooks se han construido de manera que cada uno haga una funcionalidad concreta y aislada.

Conversor de RGB a escala de grises: recibe como parámetro una sessionKey válida y el identificador del binary repository (la referencia de la imagen de entrada). Utilizando lenguaje Python y la librería PIL se obtendrá esa imagen del binary repository se convertirá a escala de grises y se volverá a subir al binary repository.

En este notebook podemos comprobar cómo se pueden recibir parámetros en el mismo. Simplemente usando z.input(“nombreParámetro”) crearemos un párrafo que podrá recibir datos dinámicos de forma externa por un formulario, esto no solo es válido para Python, se puede incluir igualmente en otros lenguajes soportados en los notebook como por ejemplo con el interpreter de Spark(scala).

image4

image5

Teniendo ese notebook creado, dentro del motor de flujos podremos añadirlo con el nodo Notebook Launcher:

image6

Al añadir ese nodo, podremos seleccionar cualquiera de los notebooks del usuario en la configuración:

image7

Posteriormente añadiremos el párrafo de entrada (se nos mostrará la lista de los mismos junto con el título y el texto de los mismos):

image8

Al añadir un párrafo con parámetros de entrada, se nos desplegará el formulario correspondiente para configurar cada entrada dinámicamente.

image9

En cuanto a la salida del párrafo (la cual, en este caso, será el nuevo identificador del binary repository de la imagen procesada) la haremos como salida del último párrafo el cuál imprimirá ese identificador. De manera análoga a los parámetros de entrada seleccionaremos un párrafo de salida. Además, se le podrá añadir un tópico para poder distinguir esta salida de otras en nodos posteriores.

image10

Si tuviéramos varios párrafos de salida, podríamos incluir diferentes salidas distinguidas por tópico.

image11

Al enviarlas, podrá ser por array en el mismo puerto (Split Output desactivado) o por diferentes puertos de salida (Split Output activado):

image12

Filtro Blur sobre imagen RGB: similar al notebook anterior salvo que se hará un filtro blur sobre un imagen.

image13image14

Obtención histograma: en este caso se leerá la imagen y se devolverá en el último párrafo el array del histograma

image15

Agrupación de datos: notebook que unificará los datos de los diferentes notebook de procesamiento para conformar una salida única que se enviará posteriormente a la ontología de salida por SSAP a Sofia2.

image16

En este caso, en la configuración del nodo, al tener varios notebooks de entrada tendremos que tener activado el Workflow Mode. Con esta opción, este nodo, se esperará a todos los notebooks de entrada antes de ejecutarse (cada notebook le enviará un parámetro). A parte, al tener varias entradas y no saber el orden de las mismas, tendremos que diferenciar las entradas del nodo por tópico para direccionarlas correctamente. Este direccionamiento se puede hacer de 3 formas:

  • payload: única entrada y se recoge el parámetro el contenido de “payload”
  • payload[n]: múltiples entradas, se recoge la que llega en posición n
  • payload{“topic”:”t1″}: múltiples entradas, se busca la que “topic” sea igual a “t1”

Para este nodo en concreto tendremos:

image17

Ahora, vamos a ver el flujo de procesamiento completo dentro del motor de flujos:

image1

La primera parte del mismo crea un endpoint REST de tipo POST (este será el disparador de todo el flujo). Dentro de este POST se incluirán por JSON los datos de:

  • SessionKey: sessionKey del usuario contra Sofia2. Se usará en todos los acceso al binary repository o al enviar mensajes SSAP
  • BinaryID: id en el binary repository de la imagen inicial

image18

A parte también se incluirá la sessionKey (común para todos los procesos) en el contexto del flow mediante el nodo function.

image19

Más adelante esta información llega a 3 nodos de tipo Notebook Launcher:

image20

Cada uno de estos notebooks recibirá como parámetro el ID del Binario junto con la sessionKey (desde el contexto del flow).

image21

La salida en el caso concreto del conversor a escala de grises va tanto al notebook de agrupación de datos, como a otro notebook idéntico al de filtrado blur.

image22

Aquí, se puede el porqué de la distinción por funcionalidad completa y aislada de los notebooks pudiendo verlos como “cajas negras” reutilizables que procesa con una entrada y una salida. A parte, el nodo notebook launcher crea una instancia de ejecución nueva para cada notebook, por lo que se puede usar varios nodos iguales en paralelo.

Finalmente, se crea un mensaje SSAP que se envía por POST a la ontología destino.

image23

image24

El resultado de todo este proceso, al subir una imagen de este tipo:

image25

Obtendremos al terminar el procesamiento las diferentes imágenes:

  • Imagen con filtro blur
  • Imagen en escala de grises
  • Imagen en escala de grises más filtro blur
  • Histograma en un gadget

image26

El código de los notebook así como la exportación del flujo de nodered puede descargar en el siguiente enlace del github de Sofia2: https://github.com/Sofia2/Sofia2-ImageProcessing

 

Orquestación de notebooks desde motor de flujos: Procesamiento de imágenes con Sofia2

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

Creating Dashboards with Node-RED

node

As we mentioned in previous posts, Node-RED is a tool with which you can create flows visually. In this post we will see a new use of Node-RED as a tool to create Dashboards.

To do this we will use the Freeboard node, it is available on GitHub, this node allows us to design our own dashboards.

For this demo, we used a Meshlium sensor concentrator, which inserts real-time data into two ontologies defined by a single ThinKP. To access this data, in our Node-RED flow we will use the following nodes:

  •  A SSAP-process-request node: listening to insert events on the ontologies defined.
  • A function node, whose function will be to parse the data recovered from the ontology. It must be taken into account that the freeboard node only represents the data provided by the message payload in JSON format.
  • A Freeboard node, this will allows us to design our dashboard.

Our flow would look like this:

dash0

We will create two different Dashboards, in one of them we will represent the monitoring data of the device as the battery, internal temperature … In the other one we will represent the measurements provided by the sensors: solar radiation, humidity …

The two dashboards are shown below:

dashn

dashnuevo

Once we have created the Dashboard, we save it to be able to access it from other devices or at another time. There are two ways to open a dashboard that you have saved:

  • By copying the URL generated at the time of saving the dashboard, through this URL we can access it from another device or browser.
  • By selecting the option “LOAD FREEBOARD” in the upper left corner, where we will have to load the generated .json file when we save the dashboard.

In the following video you can see a video of the demo:

Creating Dashboards with Node-RED

2º Meetup: Taller IoT: Desarrollo visual con Raspberry, Node-RED y dashboards

4.jpg

El pasado martes 28 de marzo se realizó el segundo Meetup sobre la plataforma Sofia2 llamado Taller IoT. Desarrollo visual en Sofia2 con Raspberry, Node-RED y dashboards (Puedes acceder a la página del evento aquí).

 

meetup2_1

 

Seguir leyendo “2º Meetup: Taller IoT: Desarrollo visual con Raspberry, Node-RED y dashboards”

2º Meetup: Taller IoT: Desarrollo visual con Raspberry, Node-RED y 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

Soporte Node-RED como motor visual de flujos (Nueva Funcionalidad en Release 3.4)

La Plataforma permite ahora crear visualmente reglas y flujos a través de Node-RED, una herramienta para la edición visual de flujos y motor de ejecución de estos flujos.

 

node_red

 

 

Seguir leyendo “Soporte Node-RED como motor visual de flujos (Nueva Funcionalidad en Release 3.4)”

Soporte Node-RED como motor visual de flujos (Nueva Funcionalidad en Release 3.4)

Creación de Dashboards con Node-RED

Como venimos comentando en post anteriores, Node-RED es una herramienta con la que podemos crear flujos de manera visual. En este post vamos a ver un nuevo uso del Node-RED como herramienta para crear Dashboards.

Para ello vamos a utilizar el nodo Freeboard, el cual tenemos disponible en GitHub, este nodo nos permite diseñar nuestros propios dashboards.

Para esta demo hemos utilizado un concentrador de sensores Meshlium, que nos inserta datos en tiempo real en dos ontologías definidas por un mismo ThinKP. Para acceder a estos datos, en nuestro flujo Node-RED vamos a utilizar:

  • Un nodo SSAP-process-request que estará a la escucha de nuevas inserciones en la ontología pertinente.
  • Un nodo de tipo function, cuya función será parsear los datos recuperados de las ontología, hay que tener en cuenta que el nodo freeboard solo representa los datos proporcionados por el pyload del mensaje en formato JSON.
  • Un nodo freeboard, que será el que nos permita diseñar nuestro dashboard.

A continuación se muestra como quedaría nuestro flujo:

dash0.PNG

Seguir leyendo “Creación de Dashboards con Node-RED”

Creación de Dashboards con Node-RED