Comando de Scripting getInBDTR

El comando de scripting getInBDTR es parte del set de ordenes accesibles desde el motor de scripting a partir de la librería groovy Sofia2.

El comando recupera información de una ontología con origen en la BDTR.

La sintaxis es la siguiente:

api.getInBDTR( ontologia, query );

Un ejemplo de uso seria como el siguiente:

Una condición inicial que siempre se cumple

Estas sentencias recuperan toda la información de una ontología (limitada a 100 registros) y la envía a la dirección de correo.

En el correo encontramos los datos de la query:

Es posible realizar querys mas complejas, usando la sintaxis nativa de mongo:

Comando de Scripting getInBDTR

Mejoras de estabilidad e Infraestructura del KP Modelo

El KPModelo es un software encargado de la ejecución y gestión de clientes Kps de alto nivel en la plataforma Sofia2.

Su finalidad es permitir el mantenimiento remoto de las AppModelo, centralizando su configuración y gestión de versiones en el SIB, facilitar el desarrollo de clientes aportando mecanismos para el control de errores, persistencia, suscripción y monitorización.

Durante la últimas releases se han realizado nuevas pruebas de rendimiento y estress ante situaciones no óptimas. Esta versión amplía considerablemente el conjunto de situaciones de recuperación de errores, haciendo uso de una nueva arquitectura encarada al almacenamiento muy flexible, que incorpora la tecnología de persistencia en memoria o en disco mediante la base de datos embebida H2.

Las mejoras en materia de rendimiento y escalabilidad que incluye esta versión eliminan la necesidad de recurrir a alternativas a medida y facilitan el desarrollo exclusivo de la lógica de negocio.

Entre las ventajas de esta versión se incluye:

Eliminacion de Leaks
Las pruebas realizadas al KpModelo permiten el funcionamiento continuado del Kp a lo largo del tiempo sin ninguna degradación de memoria. Se han realizado test en el KpMeteorologico de SmartCities Coruña durante las últimas semanas sin apreciar tendencia al alza del consumo en el Heap de Memoria.

Reducción de Memoria usada:
Se ha minimizado el uso de objetos en memoria mediante técnicas de reutilización de objetos. El KpModelo de la actual release es apto para desenvolverse en micro dispositivos con hasta 128megas de memoria sin ningún tipo de problema. Los tests realizados sobre el Kp Meteorologico de la Coruña ocupa una media menor de 30Mb no llegando nunca a superar los 35Mb.

Asimismo se ha realizado un ajuste detallado de los distintos espacios de memoria configurable en la máquina virtual.

Optimización del Rendimiento

En las modificaciones del Kp para la release se ha tenido especial cuidado en mantener los recursos en unos mínimos aceptables. La sostenibilidad de los recursos es un tema crítico dado que la mayoría dispositivos donde se ejecutará el KpModelo serán Gateways autónomos de difícil acceso y recuperación del software. Elementos como el uso mínimo de cpu y reutilización de hilos del sistema han sido mejorados y testeados a fondo.

Auditoría JMX: el marco de auditoría se incluyen todas las operaciones necesarias para hacer un seguimiento de las variables más importantes del sistema. Gracias a los endpoints JMX, los administradores pueden crear y filtrar las trazas de auditoría de las variables y operaciones del sistema.

Mejoras de estabilidad e Infraestructura del KP Modelo

API IOS Sofia2

En la release 2.15 se lanzó la nueva implementación IOS del API SSAP. Está escrita en lenguaje ObjectiveC y se comunica con la plataforma utilizando websockets.

La versión del XCode utilizada para el desarrollo es 6.1.1 y el Deployment target es 7.1 en adelante

Testeada para soportar dispositivos iPad.

El proceso de instalación es muy sencillo. Se descarga el paquete desde

sofia2.com > Desarrollo

El paquete tiene la siguiente estructura

Donde podemos encontrar

  • Librerías de conectividad protocolo ssap Sofia2iOS
  • Ficheros de proyecto Sofia2iOSExample
  • Tests Sobre las librerías Sofia2iOSTests
  • Ejemplo de funcionamiento Sofia2iOSExample
  • Tests sobre el ejemplo anterior Sofia2iOSExampleTests

El ejemplo escenifica el uso de los comandos del protocolo SSAP. Se descomprime y queda listo para ser importado en el XCode

Para manejarlo se lanza y se pueden lanzar mensajes ssap mediante una interfaz sencilla:

En las imagenes anteriores se pueden ver el lanzamiento de una sentencias sql para hacer query, insert, update y subscribe.

API IOS Sofia2

Integración Sofia2 con Ruoter Cisco 819

En la reléase 2.15.0 ingenieros de Indra y Cisco han trabajado conjuntamente para integrar sus modelos Cisco 819 con la Plataforma Sofia2.

Durante los trabajos no se ha perdido la perspectiva de mantener en las ventajas que ambos productos proporcionan al mundo IOT.

Se ha estudiado con especial interés en potenciar la filosofía de fog computing de cisco, consistente en ofrecer un conjunto de herramientas que fomentan la toma de decisiones tan pegados al dato como sea posible. Esto permite filtrados y preprocesados complejos de información que permiten reducir el volumen de datos relevantes finales y el consumo de ancho de banda.

https://about.sofia2.com/2014/07/29/que-es-fog-computing/

Sofia2 ofrece en su soporte el desarrollo de clientes inteligentes (KPs) siguiendo este concepto. Deja a decisión del proveedor, que puede delegar las reglas, disparadores,… al nodo central (SIB) o bien al local, manteniendo todas las ventajas de la relación KP-SIB. Deslocalización, multiprotocolo, multilenguaje, facilidades y herramientas de soporte a las comunicaciones, reconexiones, etc.

En el SIB mantenemos toda la potencia de procesamiento de la información recibida de los Cisco 819, permitiendo ejecución de reglas en tiempo real en función de la información recibida, cruce de datos con otros sistemas, análisis Big Data de la información recibida, publicación de la información a través del API Manager o compartida con el resto de KPs/APPs de Sofia2, etc.

Se ha puesto especial interés a la integración de manera bidireccional. No solo es posible realizar la publicación de mensajes, sino que además se admite la notificación de mensajes desde la plataforma hacia el router, mediante suscripción. Esta característica multiplica las funcionalidades del sistema integrado. El SIB se transforma potencialmente en “centro de control” de los routers, permitiendo cambiar las reglas, comandar su configuración o actualizar el software en remoto.

El diagrama representa los distintos bloques de la integración:

· Sobre el firmware del 819 corre una maquina virtual con una distribución ligera de Linux Debian.

· En este SO podemos embeber una jvm 1.7 específica para ARM, para la cual se ha desarrollado específicamente un KP.

· Este KP, está a la escucha de conexiones vía REST de Krikkit, el motor donde se configuran, gestionan y ejecutan las reglas del 819. A través del REST entran los mensajes ya procesados listos para la publicación en Sofia2.

· La publicación funciona mediante el protocolo Websocket, aprovechando que es full-duplex, ligero, y sobre el puerto 80 que lo hace amistoso a firewalls y restricciones de red. Se utiliza la una ontología específica para registrar los mensajes.

· La plataforma puede “push” de información al KP siguiendo el canal de comunicación del websocket bidireccional. Para ello se utiliza la suscripción a una ontología de reglas como origen de mensajes.

· La información de las nuevas reglas es insertada en el motor krikkit a través de publicación REST. Las nuevas reglas son aceptadas dinámicamente por el sistema.

· Existe un Kp desarrollado con el API Sofia2 en Javascript que realiza una doble función. Por un lado registrar los mensajes publicados por el 819 (suscribiéndose a la ontología de mensajes) y por otro la configuración y emisión de nuevas reglas (publicadas sobre la ontología de reglas). Este interfaz es consultable desde cualquier localización y dispositivo vía navegador compatible HTML5.

Integración Sofia2 con Ruoter Cisco 819

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

AGREGADO POR FECHAS CON MONGODB

estudio de datos de luminosidad agregados por hora

El escenario de agregados por fecha es muy habitual. Lo mostraremos con un ejemplo práctico.

EL PROBLEMA
Tenemos una colección de datos ‘SofiaSolarStation0’ que se popula mediante sensores que realizan lecturas cada 10 segundos.

Nuestro objetivo será crear una gráfica que represente la luminosidad y mostrar su tendencia a lo largo de los días.

Nos centraremos en los siguientes datos:

  • La luminosidad tomada de un sensor como ‘PlantillaBase.luminosidad.lux’
  • La fecha de la lectura es el campo ‘PlantillaBase.timestamp’

Con una toma de datos tan frecuente, la cantidad de documentos que se van a acumular en mongo a lo largo del tiempo puede ser relativamente voluminosa, mas de 250000 registros al mes.

CREAR UNA REPRESENTACION
Cuando realizamos una query online, nos vemos frecuentemente limitados en número de respuestas por el sistema.

Nuestro sistema es sofia2.com, que en condiciones normales limita a un máximo de 100 elementos por cada consulta. Realizamos la siguiente query:

db.SofiaSolarStation0.find(
Query tipo ‘find’
   { 'PlantillaBase.timestamp': 
      { '$lte':ISODate('2014-09-26T11:30:00.000Z') } },
Criterio de busqueda (fecha menor o igual que el 26-Septiembre)
   { 'PlantillaBase.timestamp':1, 'PlantillaBase.luminosidad.lux':1}
Proyeccion: Devolver campos ‘timestamp’ y ‘lux’
).sort(
Modificador ‘ordenar’
   { 'PlantillaBase.timestamp':-1 }
Criterio de ordenacion: por ‘timestamp’ de mayor a menor
)

Y la respuesta tiene la siguiente representación :

(fuentes disponibles en http://sofia2.com/examples2/sol1.html)

El problema es que 15 minutos de tomas de luminosidad no ofrecen datos suficientemente relevantes si lo que queremos es deducir una tendencia de luminosidad entre varios días.

Para obtener algo más representativo deberíamos mostrar un día completo de datos. Solo un día suponen 6 * 60 *24 = 8640 datos.

  • Podría pasarse por nuestra cabeza acumular varias peticiones paginadas y componer los resultados. Esto resultaría muy poco eficiente: de 100 en 100 un solo día serian 86 querys.
  • Saltar la restricción de 100 elementos devueltos tampoco saldría barato. 8000 datos podrían ser viables, pero imaginemos que queremos mostrar un mes o un año de datos. La respuesta sería tan voluminosa que la penalización de la transmisión por internet la haría muy lenta.
  • Cualquier componente gráfico de javascript sufre severas pérdidas de rendimiento cuando manejamos cantidades de varias decenas de miles de datos.

LA SOLUCION

Si nos vamos a la documentación de mongodb, nos encontramos los agregados de datos.

Los agregados nos permiten hacer un tratamiento en varias fases de una colección para generar un resultado que agrupa y ordena los documentos, un poco al estilo “group by” y “order by” de una base de datos SQL.

Queremos mostrar la media de luminosidad agrupada por horas.

Después de leer, probar y experimentar, encontramos que esta forma de realizar los aggregates que nos resulta adecuada:

db.SofiaSolarStation0.aggregate([
Query tipo ‘aggregate’
{ $match: {
Fase de Filtrado
   'PlantillaBase.timestamp':{
      '$lte':{'$date':'2014-09-26T11:30:00.000Z'}
   }
} },
condicion de filtrado fecha menor o igual que el 26-SeptiembreNota: si en vez del canal javascript usamos la consola, se debe utilizar el ISODate de esta manera:
‘$lte’:ISODate(‘2014-09-26T11:30:00.000Z’)
{ $project:{
Fase proyección
   hora: {
      0: {'$year': '$PlantillaBase.timestamp'},
      1: {'$month': '$PlantillaBase.timestamp'},
      2: {'$dayOfMonth': '$PlantillaBase.timestamp'},
      3: {'$hour': '$PlantillaBase.timestamp'}
   },
Valor proyectado ‘hora’ compuesto de

  • campo 0:año
  • campo 1:mes
  • campo 2:diames
  • campo 3:hora
   base:'$PlantillaBase'
Valor proyectado: lo llamamos ‘base’
}},
{ $group:{
Fase agrupación
   _id:'$hora',
      'assetId':{$first:'$base.assetId'},
      'avg_lux':{$avg:'$base.luminosidad.lux'},
      'sum_ir':{$sum:'$base.luminosidad.ir'}
Criterio de ordenación (_id): proyección ‘hora’

  • Primer valor assetId del grupo
  • Media de valores ‘luminosidad.lux’ del grupo
  • Suma de valores ‘luminosidad.ir’ del grupo
} },
   { $sort:{
      '_id':-1
   } }
Fase sort: Ordenar por el _id
])

La respuesta horaria es mucho más adecuada para ver las tendencias diarias:

(fuentes disponibles en http://sofia2.com/examples2/sol2.html)

AGREGADO POR FECHAS CON MONGODB