Gestión avanzada de dispositivos en Sofia2

En Sofia2 somos conscientes de que en los próximos años la importancia de la gestión de dispositivos conectados va a aumentar de forma considerable, sobre todo en el ámbito IoT. Es por ello que desde sus primeras versiones, Sofia2 proporciona una gestión de dispositivos integrada en la plataforma.

En anteriores Post ya hemos visto cómo se entiende en Sofia2 el concepto de dispositivo y de qué manera se realiza su gestión. Podemos repasar algunos conceptos básicos:

 

  • Spaces (Proyectos): Representa un entorno colaborativo virtual donde los usuarios pueden crear sus aplicaciones, por ejemplo creando Things, modelando sus entidades, aplicando algoritmos o creando visualizaciones.
  • Ontología (Entities): Una Entity (Thintology) representa el Modelo de Dominio que maneja una Thing.
  • ThinKP: Un ThinKP (en terminología Sofia2 hablamos de KP: Knowledge Processor o de ThinKP) representa a cada uno de los elementos que interactúan con la plataforma, bien publicando, bien consumiendo información.

En Sofia2 es este ThinKP el que puede representar desde un dispositivo sencillo a un Gateway o un Sistema Empresarial.

Sofia2 contaba ya con una gestión de dispositivos básica. Entre otras funcionalidades, se contemplaban:

 

  • Gestión ThinKPs activos (conexiones activas de dispositivos con la plataforma).

  • Gestión de Conexiones (conexiones físicas y lógicas y actuaciones sobre las mismas).

  • Gestión de Configuraciones SW (configuración del SW instalado en los dispositivos clientes).

  • Gestión de Assets (Inventariado de dispositivos).

En las últimas versiones de la plataforma dicha gestión se ha visto ampliada considerablemente.

 

  • Extensión del API de comunicación con la plataforma. Se han incorporado nuevas directivas:
    • Error: se utilizará para comunicar a la plataforma errores que se hayan producido en el dispositivo y que quieran registrarse en la plataforma.
    • Log: permitirá disponer de un log completo en la plataforma de las operaciones llevadas a cabo en el dispositivo.
    • Location: actualizará la ubicación del dispositivo para poder realizar un seguimiento sobre el mismo.
    • Status: mediante este tipo de mensaje el dispositivo podrá actualizar el estado en el que se encuentra y que quede registrado en Sofia2. Como estado entendemos un grupo de variables y sus valores (pueden extraerse del dispositivo en cuestión: memoria libre, uso de CPU,…).
    • La directiva Command está compuesta por dos operaciones de comunicación:
      • SubscribeCommand: Cualquier Instancia de ThinKP puede subscribirse a la recepción de comandos sin necesidad de tener sessionKey (a diferencia de las subscripciones normales). Desde Sofia2 recomendamos realizar esta suscripción siempre un dispositivo (ThinKP) inicie su actividad.
      • Command:
        • A través de esta operación es posible mandar mensajes de comando a cualquier instancia de ThinKP que se haya suscrito previamente.
        • Para realizar el envío de comandos es necesario estar autenticado en Sofia2 y disponer de una sessionKey correcta. De esta manera se evita el envío malicioso de comandos no autorizados. El mensaje de comandos tiene un campo llamado Args dónde pasar los argumentos necesarios al ThinKP sobre el que se quiera actuar. Ejemplos de uso serían:
          • Pedir a un dispositivo que se reinicie.
          • Pedir a un dispositivo que envíe su estado actual.

Mediante el envío de información a través de estos nuevos tipos de mensajes se obtendrá una visión centralizada del estado y ubicación de todos los dispositivos conectados a la plataforma en tiempo real. Se dispondrá de un histórico en el que analizar los distintos estados por los que haya pasado cada uno de ellos así como los problemas que se hayan detectado. Además se podrá actuar remotamente sobre dispositivos enviándoles comandos a ejecutar.

 

  • Unificación en la consola de toda la operativa referida a dispositivos (ThinKPs)

En la consola de administración y configuración de la plataforma, se ha añadido una opción de menú que engloba toda la gestión asociada a ThinKPs.

 

– Mis ThinKPs: Permite dar de alta nuevos ThinKPs en la plataforma, definiendo el conjunto de datos sobre los que trabajaran, así como modificar o eliminar los ya existentes. Además se permite gestionar sus instancias y sus tokens de conexión con la plataforma.

Estado ThinKPs: Nueva opción que permite visualizar el estado de cada uno de los ThinKPs conectados con la plataforma (la veremos más en detalla a continuación en este post).

– ThinKPs Conectados: Listado de ThinKPs conectados con la plataforma así como detalles de las mismos (identificación, clave de sesión, fecha última conexión).

– Contenedor de ThinKPs: Permite desplegar ThinKPs en la propia plataforma, totalmente gestionables.

– Config SW en ThinKPs: Para asociar distintas versiones de SW y parámetros de configuración con ThinKPs o InstathinKPs.

Además como opción de administración se incluye:

– Gestión de conexiones: permite monitorizar y actuar sobre las conexiones, tanto físicas como lógicas que establecen los distintos ThinKPs con la plataforma.

 

  • Nuevo UI para la gestión centralizada de información proveniente de dispositivos (Estado ThinKPs): Esta opción muestra una lista de KPs conectados con la plataforma, así como un listado con la última información recibida desde los mismos.

En un primer listado se mostrarán las instancias de ThinKPs conectadas con la plataforma.

Si se selecciona una de las instancias de la tabla, los componentes de la pantalla quedarán filtrados, mostrando información relativa únicamente a esa instancia de ThinKP seleccionada.

A su lado se mostrará la posición de cada uno de ellos sobre un mapa. Esta información provendrá de los mensajes de tipo LOCATION que cada uno de los dispositivos ha ido enviando a la plataforma. Al mantenerse un histórico de esta información, se podrá mantener trazabilidad sobre la ubicación de cada uno de los dispositivos.

Si se sitúa el cursos sobre uno de los puntos del mapa, se ofrecerá información adicional, como la precisión, velocidad y rumbo del dispositivo.

La opción Ver en detalle, despliega un mapa a pantalla completa para una mejor visualización.

Incorpora un componente de búsqueda para filtrar entre los dispositivos mostrados y el número de dispositivos a mostrar.

Además de este componente visual que permite la localización de los dispositivos, se incorporan tres listados en los que se mostrará información proveniente de los mensajes de ERROR, LOG y STATUS recibidos desde los dispositivos.

El listado de Mensajes de Error mostrará el contenido de los mensajes de ERROR recibidos. Se incluye un campo severidad que indicará la gravedad del mensaje recibido. Como niveles de ERROR están disponibles los siguientes:

 

  • DEBUG
  • INFORMATIONAL
  • NOTICE
  • WARNING
  • ERROR
  • CRITICAL
  • ALERT
  • EMERGENCY

Además se incluye el identificador de la instancia de ThinKP que ha enviado el mensaje, un código de error asociado, el contenido del mensaje de error y la fecha de envío. Tanto el código de error como el contenido del mensaje pueden ser definidos y construidos en el propio dispositivo, siendo configurables completamente por el usuario.

Se incluye además un enlace para mostrar el detalle del log de error. Mostrará, de forma similar al detalle de ubicaciones, un interfaz que permitirá filtrar por distintos criterios y mostrar los mensajes de error en un listado a pantalla completa.

El listado de mensajes de Log, mostrará los mensajes de tipo Log que los dispositivos hayan ido enviando a la plataforma.

El listado muestra como primera columna el nivel de log del mensaje enviado. Sus posibles valores son:

 

  • TRACE
  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL

Se incluye también el identificador de la instancia de ThinKP que ha enviado el mensaje, el contenido del mensaje y la fecha de envío.

Al igual que para la el listado de mensajes de error se incluye un enlace para mostrar el detalle del log que mostrará un interfaz que permitirá filtrar por distintos criterios y mostrar los mensajes de log a pantalla completa.

El listado de mensajes de Status mostrará los mensajes de estado que se han recibido desde los dispositivos. En este caso se mostrará la identificación de la instancia de Thinkp, así como el valor de las variables enviadas desde el dispositivo y la fecha de envío de las mismas.

Se dispone también del mismo enlace Ver en detalle con la misma funcionalidad que en el resto de listados:

 

  • El envío de mensajes de la directiva COMMAND se realiza mediante el api SSAP que proporciona la plataforma. El formato de dichos mensajes sería el siguiente:

SUBSCRIBECOMMAND

{“messageId”:null,”sessionKey”:null,”ontology”:null,”direction”:”REQUEST”,”messageType”:”SUBSCRIBECOMMAND”,”body”:”{“thinkp”:”TestKP”,”thinkpInstance”:” THINKP:INS “,”token”:”XXXXXXXXXXXXXXXXX”,”type”:”STATUS”}”}

COMMAND

{“messageId”:null,”sessionKey”:”XXXXXXXXXXXXXXX”,”ontology”:null,”direction”:”REQUEST”,”messageType”:”COMMAND”,”body”:”{“thinkp”:”TestKP”,”thinkpInstance”:”THINKP:INS”,”type”:”STATUS”,”args”:null}”}

El futuras versiones de la plataforma, se implementará un interfaz que permita el envío de mensajes a dispositivos.

Gestión avanzada de dispositivos en Sofia2

Remote deployment of Node-RED flows with Sofia2

As we have already mentioned in other post, Node-RED is a visual tool that provides a light flow engine capable of running on devices with reduce capacities, such as a Raspberry Pi.

In this post we will show how it is possible to edit centrally, from the Sofia2 admin console, Node-RED flows, which will subsequently be deployed remotely in devices. As an example of device and video demonstrator we will use a Raspberry Pi model A.

The remote deployment of flows will be performed on the device by a fairly light ThinKP, whose mission will be to receive new flows edited in the platform through the SSAP messaging protocol of Sofia2 and deploy them to the local Node-RED instance of the device.

video1

Seguir leyendo “Remote deployment of Node-RED flows with Sofia2”

Remote deployment of Node-RED flows with Sofia2