Nuevas APIS REST de Gestión para Reglas CEP y Script

En la release 2.13 de Sofia2, se han incluido nuevas APIS que pretenden facilitar la creación de reglas CEP y reglas Script sin necesidad de acceder a la consola de Configuración.

Al acceder a los servicios podemos ver que hay 3 nuevos disponibles: CEP Event Service, CEP Rule Service y Script Service que ha sido actualizado.

Hay que tener en cuenta que la ejecución de las operaciones proporcionadas por estos servicios dependerá de los permisos que los usuarios que los invocan tengan. Un usuario con ROL ADMINISTRADOR podrá operar sobre todos los elementos los haya o no creado él, mientras que un usuario con ROL COLABORADOR sólo podrá operar sobre aquellos que haya dado de alta él en el Sistema, o sobre los que tenga permisos.

Veamos cada uno de los servicios con algo más de detalle:

CEP Event Service : Este API REST dispone de los siguientes servicios:

· Operación GET (/cep/event) Permitirá obtener el listado de eventos existentes.

· Operación POST (/cep/event) Da de alta un nuevo evento que se utilizarán posteriormente para el alta de reglas.

· Operación PUT (/cep/event) Permitirá actualizar el evento indicado con la información pasada por parámetro.

· Operación DELETE (/cep/event/{identificacion}) Elimina el evento con la identificación pasada por parámetro.

· Operación GET (/cep/event/{identificacion}) Recupera el evento con la identificación pasada por parámetro.

CEP Rule Service : Servicio REST que dispone de operaciones GET, POST, PUT y DELETE para dar de alta, modificar, consultar o eliminar reglas del CEP.

· Operación GET (/cep/rule/{destino}) Permitirá obtener la regla CEP cuyo stream de salida coincide con el parámetro indicado.

· Operación POST (/cep/rule/) Permitirá dar de alta una nueva regla CEP.

· Operación PUT (/cep/rule/) Modifica la regla CEP indicada con la información del objeto json pasado por parámetro.

· Operación PUT ((/cep/rule/activate/{destino}/{activate}) Activa o desactiva la regla dependiendo del valor del flag que recibe como parámetro. true = regla activa, false = regla desactivada.

· Operación DELETE (/cep/rule/{destino}) Permitirá eliminar la regla CEP indicada por parámetro.

· Operación GET (/cep/rule) Obtiene el listado de reglas CEP existentes.

Script Service : Servicio REST que dispone de operaciones GET, POST, PUT y DELETE para poder gestionar el alta, modificación, consulta o eliminación de scripts.

· Operación GET (/scripts) Obtiene la lista de Scripts.

· Operación POST (/scripts) Permitirá dar de alta un nuevo Script.

· Operación PUT (/cep/event) Modifica el Script indicado con la información pasada como parámetro en formato JSON.

· Operación DELETE (/scripts/{identificacion}) Elimina el Script con la identificación pasada.

· Operación GET (/scripts/{identificacion}) Obtiene el Script cuya identificación coincide con la pasada por parámetro.

Nuevas APIS REST de Gestión para Reglas CEP y Script

Borrado de registros anteriores a una fecha en BDTR

Cuando haya que borrar registros antiguos en BDTR estas queries os pueden ser útiles.

Buscamos lo que queremos borrar:

db. feedGasolinera.find({‘contextData.timestamp’:{‘$lt’:ISODate(‘2014-11-14T00:00:00.000Z’)}})

Nos aseguramos de que los registros son previos a la fecha con un find y una proyección:

db.feedGasolinera.find({‘contextData.timestamp’:{‘$lt’:ISODate(‘2014-16-14T00:00:00.000Z’)}},{‘contextData.timestamp’:1}).sort({‘contextData.timestamp’: -1}).limit(5)

Ej de salida de una query de este tipo:

Y ya una vez seguros, borramos:

db. feedGasolinera.remove({‘contextData.timestamp’:{‘$lt’:ISODate(‘2014-11-14T00:00:00.000Z’)}})

Borrado de registros anteriores a una fecha en BDTR

API REST API Manager

En la release 2.13 de Sofia2, el módulo API Manager incorpora una nueva interfaz REST para acceder a la gestión de las APIs sin tener que hacer uso de la consola de Configuración.

Si bien es posible invocar los servicios expuestos a través de cualquier servicio externo, también se incorpora un nuevo interfaz gráfico para su utilización.

Como puede observarse, se exponen 3 nuevas APIs: Token Usuario Service, Apis Suscripciones Service y Api Service.

Para facilitar el uso de dichas APIs, el mecanismo de seguridad implementado será mediante la inclusión de un token de usuario en el Header de la petición:

El usuario que invoque a las Apis, debe estar dado de alta en la plataforma Sofia2 y disponer de un token de usuario propio.

A continuación se detalla cada una de las APIs disponibles

  • Token Usuario Service: incorpora los siguientes servicios:

o La operación GET permitirá obtener el token de usuario de un determinado usuario, pasando como parámetro el identificador de usuario.

o La operación POST permitirá generar el token de usuario de un determinado usuario, pasando como parámetro el identificador de usuario.

o La operación PUT permitirá regenerar el token de usuario de un determinado usuario, pasando como parámetro el identificador de usuario.

– Apis Suscripciones Service: Recupera información sobre las suscripciones a las APIs existentes:

o La operación GET (/apisuscripciones/usuario/{identificacionUsuario}) permite recuperar todas las suscripciones de un determinado usuario.

o La operación GET (/apisuscripciones/{identificación}) recupera todas las suscripciones a una determinada API.

o La operación POST permitirá realizar la suscripción de un usuario a una API determinada.

o La operación PUT permitirá modificar una suscripción existente.

o La operación DELETE eliminará la suscripción indicada.

– Api Service: Gestiona información referente a las APIs dadas de alta en el sistema:

  • La operación GET (/apisuscripciones}) recupera todas las APIs con esa identificación (todas las versiones existentes).
  • La operación GET (/apis) permite recuperar todas las Apis filtrando por usuario, identificación y estado.
  • La operación POST permitirá realizar la creación de una nueva API.
  • La operación PUT permite modificar una API existente.
  • La operación DELETE (/apis) eliminará la API indicada.
  • La operación DELETE (/apis/{identificación}/{numversion} eliminará una API utilizando su identificación y numero de versión.

La realización de las operaciones proporcionadas por estos servicios estará supeditada al usuario que los invoquen, comprobando si dicho usuario tiene o no permisos para realizar la operación.

API REST API Manager

Guía de Uso de la Consola Web de Configuración

Se ha liberado la versión actualizada de la guía de uso de la Consola de Configuración de la plataforma.

Se encuentra disponible a través del enlace en la web de Sofia2 (sección Desarrollo) o a través del siguiente enlace.

http://sofia2.com/docs/SOFIA2-Guia%20de%20Uso%20de%20Consola%20Web.pdf

En breve se disponibilizará la versión en inglés.

Guía de Uso de la Consola Web de Configuración

Gadget Valor Simple

En la release 2.13.0 se ha incluido una herramienta en la consola que amplía las opciones gráficas de Sofia2. Se trata del gadget Valor Simple que permite la visualización a tiempo real del valor de una ontología.

Se puede acceder al gadget Valor Simple desde el menú Visualizaciones>Mis Gadgets>Valor Simple>Crear Gadget desde la consola

Entramos en un wizard para la creación de widgets a partir de KPs para la visualización de la información. El wizard permite configurar durante la creación el Kp, ontología y atributo que se quiere mostrar en el widget:

En la imagen se pueden apreciar las diferentes partes del gadget.

El wizard empezará a obtener datos en directo en cuanto se selecciona un atributo que esté lanzando notificaciones. Podemos renombrar, listar y modificar las opciones de configuración cuando deseemos.

En el gadget una vez configurado aparecerá el nombre del gadget, nombre kp, ontología, el valor actual, el valor anterior, tendencia y hora de actualización.

Los gadgets de Valor Simple son perfectamente compatibles en integrables con el dashboard, lo que permite componer displays de información complejos.

Gadget Valor Simple

Smart Home Demo

La Smart Home Demo muestra la capacidad de interoperar entre diferentes sistemas que nos ofrece la plataforma Sofia2.

El escenario es un edificio o casa domótica donde varios sistemas intercambian información en una red zigbee de sensores y actuadores.

En el video se muestra la funcionalidad:

Los diferentes elementos del sistema son:

Sensor de Humedad y Temperatura Dispositivo autonomo alimentado mediante bateria. Realiza medidas de humedad y temperatura, enviandolas a un gateway zigbee a intervalos regulares.
Watorimetro Su aspecto es el un enchufe convencional que se conecta de un modo convencional a la pared para dar voltaje a electrodomésticos caseros. Permite realizar medidas de consumo electrico (medida active y medida acumulada) y enviarlas al gateway mediante zigbee.También admite commandos on/off para permitir o no el paso de corriente.
GateWay Zigbee Su proposito es hacer de intefaz entre un controlador lógico (raspberry pi) via Ethernet (conector RJ45) y una red de dispositivos ZigBee usando el protocolo de comunicaciones Modbus.
Controlador Lógico Placa Controladora con las funciones de lógica de alto nivel sobre los dispositivos. Se conecta al Gateway mediante el cable Ethernet.Un APP procesa los mensajes modbus mediante un API de comunicaciones en Java y después envía las medidas al SIB Sofia2 para disponibilizarlas.El APP está suscrito a la plataforma para recibir notificaciones que comandan ordenes on/off al watorimetro.
Interfaz HTML5 Página HTML5 asociado a un APP que hace de interfaz de control. El APP interfaz recibe notificación de las diferentes medidas y puede emitir órdenes sobre el watorimetro.

El diagrama de flujo de información es el siguiente:

  • Los dispositivos watorimetro y sensor de temperatura forman parte de la red zigbee. Se comunican con el Gateway.
  • El Gateway se comunica con el Controlador -raspberry pi- mendiante el cable Ethernet. Realiza la lógica de alto nivel, enviando y recibiendo ordenes del Gateway vía protocolo ModBus.
  • El software controlador del dispositivo es el APP del dispositivo domótico propiamente dicho. Se comunica con el KP hacia el SIB sofia via internet protocolo MQTT.
  • El APP controlador publica datos periódicamente sobre las ontologías de humedad/temperatura y potencia del watorimetro. Estas ontologías son llamadas ontologías de estado, dado que reflejan a tiempo real los valores de estado de los sensores.
  • El APP controlador está suscrito a una ontología de comando del watorimetro. Cuando esta ontología notifica un on o un off, el controlador indica al watorimetro que se active o desactive el paso de corriente. Por ello este tipo de ontología la denominamos ontología de comando.
  • En el interfaz, a la inversa, se suscribe a las ontologías de estado para reflejar en los diferentes displays los datos a tiempo real. Y notificará a la ontología de comnado si queremos activar o desactivar el watorimetro.

El APP Interfaz de la demo es accesible desde la web sofia2 en

http://sofia2.com/demos/watorimetro/index.html

Smart Home Demo

Funcionalidad Carga de Asset externos

En la release 2.13 de Sofia2, se incorpora una nueva funcionalidad, que permitirá realizar la carga de Assets desde un sistema externo.

Para configurar dicha carga externa, será necesario realizar los siguientes pasos:

1) Definir el/los servicio/s que recuperará/n los Assets como una nueva API REST mediante el uso del API Manager de Sofia2. Se definirán todos los parámetros necesarios para realizar su invocación.

Debe incluir una operación HTTP Get, para permitir recuperar los resultados, así como los parámetros de autenticación que sean necesarios.

De esta forma, el servicio estará disponible para su invocación.

2) A la hora de recuperar la configuración, mediante el mensaje GET_CONFIG, se dispondrá a partir de ahora de la posibilidad de invocarlo con dos nuevos parámetros:

– instanciaKp: Instancia KP.

– kp: KP.

– token: Token.

assetService: Identificación de API REST a invocar.

assetServiceParam: Parametros asociados a la petición (claves-valor).

Se encontrará configurado por defecto un servicio al que se invocará en caso de no encontrar Assets en la BDC.

3) La configuración recuperada mediante el uso de este mensaje, proporcionará un listado de Assets, que se obtendrán de las siguiente manera:

– Si el mensaje GET_CONFIG incluía una instancia estática y no se indicaba assetService:

o Se buscarán los Assets en BDC,

§ Los assets recuperados incluirán un nuevo atributo isNative a true indicando que son propios a la plataforma.

o Si no se encuentran en BDC se buscarán mediante el servicio externo.

§ Se incluirá un único resultado, con el atributo is Native a false, lo que indicará que no son propios a la plataforma y un atributo jsonAssets que incluirá la respuesta recibida desde el servicio externo de obtención de Assets para su posterior tratamiento.

– Si el mensaje GET_CONFIG incluía una instancia estática y se indicaba assetService:

o se buscarán los Assets directamente a través del servicio externo.

§ Se incluirá un único resultado, con el atributo is Native a false, lo que indicará que no son propios a la plataforma y un atributo jsonAssets que incluirá la respuesta recibida desde el servicio externo de obtención de Assets para su posterior tratamiento.

– Si el mensaje GET_CONFIG incluía una instancia dinámica:

o Siempre se buscarán los Assets directamente a través del servicio externo, ya que no pueden tener asociada configuración propia de Assets en BDC

§ Como ya se ha visto, se incluirá un único resultado, con el atributo is Native a false, lo que indicará que no son propios a la plataforma y un atributo jsonAssets que incluirá la respuesta recibida desde el servicio externo de obtención de Assets para su posterior tratamiento.

Además se ha modificado el API Restful para permitir enviar mensajes GET_CONFIG mediante el interfaz gráfico disponible:

Funcionalidad Carga de Asset externos