Meetup on Sofia2 LPWA Integrations: SigFox, LoRaWAN & The Things Network

On February 28th, we scheduled one of our technical Meetups, this time on LPWA technologies and how easy is to integrate them on Sofia2 IoT Platform. Please join our Meetup group where we will keep you updated with our future meetup events. You may also find here the slides used during the presentation.

A big thank you also to THECUBE Madrid team for giving us free access and use of their building. They also contributed by composing this really nice video on the event, enjoy it!:

These time our speakers where Jorge Trallero and Mario Briceño from our Sofia2 Team. They highlighted how easy is to integrate data collected from IoT devices with LPWA technologies into Sofia2. 3 integrations scenarios were performed:

  • SigFox Integration
  • Private LoRa Network Integration
  • The Things Network Integration

We also had the luxury of having with us member of the core team of The Things Network Madrid Community, to present us their initiatives and to collaborate in the latter integration scenario.

Seguir leyendo “Meetup on Sofia2 LPWA Integrations: SigFox, LoRaWAN & The Things Network”

Meetup on Sofia2 LPWA Integrations: SigFox, LoRaWAN & The Things Network

¿Qué es la iniciativa The Things Network?

En este post os queremos transmitir lo que es la iniciativa de The Things Network (TTN desde ahora), y como han conseguido, en poco más de 2 años, empezando con una campaña en Kickstarter, promover la creación de más de 400 comunidades de entusiastas y desarolladores de IoT, con una red global y colaborativa de +2600 gateways utilizando la tecnología LoRaWAN.

 

Amsterdam: Zona cero

 

Todo empezó en Amsterdam en el verano de 2015, de la mano de los dos fundadores de The Things Network: Wienke Giezeman y Johan Stokking. En este breve vídeo, Wienke explica los inicios y las capacidades de TTN:

 

Utilizando la tecnología LoRaWAN, cubrieron todo el centro de la ciudad de Amsterdam con cobertura LoRaWAN en un par de semanas con unos pocos gateways.

 

Tecnología LoRaWAN + Red Abierta – Open source

 

TTN eligió como tecnología de comunicación LoRaWAN sobre LoRa (más info en este enlace de la LoRa Alliance). Basada en una modulación de espectro extendido, LoRa alcanza considerables distancias utilizando una potencia muy pequeña ocupando todo el ancho de banda disponible en torno a la frecuencia de 868 MHz (EU). Esta transmisión se puede realizar incluso por debajo del nivel de ruido, lo que otorga a la comunicación una robustez superior frente al ruido.

 

Desde el inicio ha sido una tecnología abierta y con gran atracción entre los entusiastas del IoT, centrándose en 3 puntos principales:

 

  • Largo alcance: Cobertura en líneas de 10-20 km son fácilmente alcanzables con un emplazamiento adecuado.
  • Bajo consumo de batería: Esta tecnología de comunicaciones permite alargar la vida de los dispositivos alimentados por batería hasta varios años.
  • Bajos costes: Los costes de los dispositivos son cada vez más competitivos, y una vez tienes cobertura de un gateway, los dispositivos transmiten información sin coste de comunicación alguno (ciñendose eso sí a las cuotas de uso (duty-cycle) del espectro libre para cada región del globo).

 

Además de la tecnología de comunicaciones, TTN ha hecho un esfuerzo de desarrollo en la parte de servidor, construyendo todo el backend de la red y que da soporte a los gateways distribuidos por el globo. Este backend es el que lidia con duplicidades de mensajes, orquestración de mensaje de bajada, gestión de integraciones con plataformas, etc. TTN ofrece también capacidades de integración por HTTP y MQTT, además de una serie de APIs en distintos lenguajes como: Go, Java, Node-RED y Node.js, con las cuales construir una aplicación end-to-end, mediante la integración de nodos, gateways, server de TTN y una platforma IoT como Sofia2.

 

Desde el 1 de Febrero, tanto los diseños HW del gateway y del nodo de TTN, como el código sobre el que se ha escrito todo el backend de TTN ha sido disponibilizado como opensource en su cuenta de GitHub, manteniendo el espíritu abierto y de comunidad con el que empezaron en 2015.

 

429 comunidades en los 5 continentes

 

En la actualidad el fenómeno de TTN ha tenido gran calado en la comunidad IoT global. En este momento disponen de 2946 Gateways en todo el mundo gracias a comunidades locales que montan estos puntos de acceso extendiendo la red y el conocimiento sobre IoT. Esta creciente comunidad está acelerando la expansión del IoT, facilitando a muchas personas el acceso sencillo y gratuito a un ecosistema de IoT donde pueden hacer realidad sus proyectos de forma muy sencilla.

 

mapattn.png

 

En ciudades como Berlín, las comunidades de TTN han dotado a la ciudad de tal nivel de cobertura, que el desarrollo de aplicaciones IoT sobre esta estructura es una realidad:

 

ttn-berlin.png

 

Con Gateways instalados en ubicaciones tan icónicas como la torre de televisión de Berlín, dotando de una cobertura ideal a la capital germana:

 

DQRSwsTW0AEby0h.jpg

Meetup Sofia2 – Comunidad TTN Madrid

 

Este 28 de Febrero, en el espacio de THE CUBE Madrid, seremos los anfitriones de un Meetup sobre tecnologías LPWA (SigFox y LoRaWAN), y cómo hemos integrado ya estas tecnologías con Sofia2.

Además, tendremos el privilegio de contar con la ayuda de la comunidad de TTN oficial en Madrid, que nos contarán de primera mano sus objetivos como comunidad, los avances de TTN y las posibilidades que ofrece como red ciudadana:

 

ttn-madrid.png

 

Como colofón, la comunidad de TTN Madrid nos enseñará un caso de puerta conectada basado en LoRaWAN, conectado a TTN, y que hemos integrado en Sofia2 para poder explotar el caso desde el lado de plataforma, ofreciendo visualización en un dashboard, y usos especiales como el motor de scripting de Sofia2 para disparar alertas.

 

Si estás interesado en asistir, aun nos quedan plazas disponibles, este es nuestro grupo de Meetup:

https://www.meetup.com/es-ES/IoT-BigData-Sofia2-Lab/events/247514374/ .

Es una oportunidad muy buena para conocer más sobre Sofia2 y profundizar sobre la iniciativa TTN gracias a la presencia de la comunidad TTN Madrid.

 

Os esperamos!!

¿Qué es la iniciativa The Things Network?

Integration of Lora and Sofia2

The communication between Lora and Sofia2 is done through the Multitech kit, formed by a test node that simulates the transmissions between a Lora device and a Gateway. This Gateway is needed to communicate this type of devices within the network and to send the captured data.

Kit
Used Multiconnect Conduit Kit.

Before the integration in Sofia2, the configuration between the Gateway and the test node is needed. In this brief tutorial, the steps to develop both configurations are collected, as well as all the information needed in Sofia2 to receive and store the data sent by Lora.

Configuration of Lora technology

  • Gateway configuration

    In order to use the gateway without any connection problem, an initial configuration is needed. First access to the Gateway must be done by means of serial communication, though Putty or another similar tool. Credentials needed to access by console are admin/admin. We can get its IP address with the command ifconfig. Once the IP address is known, we use the explorer to access to the Multitech webpage, where we introduce the same credentials again.

    Acceso web al gateway
    Access to the gateway webpage

    Once we start the session, and only by the first time that we do it, we will find an assistant that requires us to change the password, to select the timezone and to configure the IP address. When the last window appears, we must to configure the static IP, to select the corresponding Gateway, and to add the DNS servers.

    Once we finish the IP configuration, we will configurate Lora. To do that, we have to access to Setup -> Lora. Then, we will see a screen where we will see some configurable fields. Anyway, we only need to modify Name and Passphrases.

    Web
    Lora configuration
  • Node-Red configuration

    Once we activate the Node-Red application, we can access though the “App” menu of the webpage. By default, a program that receives Lora test data and shows them is designed, but we have to modify it in order to send the information to Sofia2. Image shows the final flow diagram, with the option “Sofia2 API WEB encoder” added. This option is uncharged of giving the desired format, adding a header to the send message and an output HTTP.

    Node-Red
    Node-Red diagram
  •  Configuration of test node

    To configurate the parameters of the test node is really simple. We only have to connect the mDot to the PC, by means of a USB, and to connect it to the test node with the kit programming cable. Then, we select the “Configuration” option in the mDot Box and we access to the device by using the Putty serial communication at 115200 baud.

    Tester
    Lora tester

    We only need to configure two parameters, using the following AT commands:

    AT+NI=1,<Name>

    AT+NK=1,<Passphrase>

    AT&W is used to save changes and  AT+Exit to exit the configuration mode.

    <Name> y <Passphrase> fields have to be the same values as used previously in the gateway.

    Configuración del tester
    Test node configuration

    In order to check if the configuration of both devices has been correct, we can do a test with the Node-Red.

Sofia2

Once that the devices have been configured, we have to develop the next steps in Sofia2. We need two new ontologies, an API rest and a rule script to deal with data. This section briefly explains with each of them.

  • Defining new ontologies

    First of all, we have to create an ontology that will receive the data sent by the test node. In this ontology we will insert raw data, without any previously filtering.

    ontologia
    Ontology example with raw data

    As we can see in the previous image, data usually have hexadecimal codifications, undesirable formats or information that needs to be treated before work with it. To do that, we have to create a rule script and a new ontology, where we will insert filtered data with the format required by the data base to correctly store it.

  • API REST

    Once the ontologies are defined, we will create an API REST of type POST, to insert data in the ontology of raw data. To do that, we have to go to the API MANAGER -> APIs, where we will find the option “New API”. There, we write the name of our API, and select the option “Publish Ontology as REST API” and the ontology desired. It is convenient to disable the maximum number of calls per minute, in order to assure that we do not lose information. At the end, we select the “POST” operation and create the API.

    API
    API

    The URL of the “Base Endpoint” field is the one that we have to insert in the Node-Red.

  • Rule script

    Once verified that the data sent directly from the device is correctly inserted in the desired ontology, we must create a script to filter them, extract all possible information and provide them with the corresponding format. To do this, we simply enter Rules-> Wizard New Rules and select the option “Generate rule using a template “. With this type of rules, each time the device sends new data to the ontology, the script will be executed and data will be processed and inserted into the final ontology.

  • Presentation on results

    We can use Sofia2’s visualization tools to show the data we’re storing quickly and easily. To do that, we have to go to the Visualization ->My Gadgets -> New Gadget, where we can select the optimal tool depending on our data. On the basic of measured data from Lora tester, the following representation could be interesting: to drawn the coordinates on a map or Signal to Noise Rate (SNR) along the time.

Mapa
Coordinates shows on a map
SNR
SNR representation.
Integration of Lora and Sofia2

Integración de Lora con Sofia2

Para llevar a cabo la comunicación entre un dispositivo Lora y Sofia2 hemos utilizado un kit de Multitech formado por un nodo de pruebas que simula las transmisiones de un dispositivo con tecnología Lora y un gateway, necesario para que estos dispositivos puedan comunicarse con la red y enviar así los datos que tomen.

Kit
Kit Multiconnect utilizado.

Es necesario configurar tanto el gateway como el nodo de pruebas antes de integrar estos dispositivos en Sofia2. En esta breve guía se recogen los pasos a seguir para ambas configuraciones y todo lo necesario en Sofia2 para poder recibir y almacenar los datos enviados por Lora.

Configuración de la tecnología Lora

  • Configuración del gateway

    Es necesario hacer una configuración inicial para poder usar el gateway sin problemas de conexión. La primera vez que accedemos a él lo haremos por comunicación serie usando Putty u otra herramienta similar. Las credenciales necesarias para acceder por terminal son admin/admin, y con el comando ifconfig podemos obtener su dirección IP. Una vez conocida esta IP, accedemos a ella mediante un navegador y nos encontramos con una página de Multitech donde podemos acceder usando de nuevo las mismas credenciales que antes.

    Acceso web al gateway
    Acceso web al gateway

    Nada más iniciar sesión, y solo la primera vez que lo hacemos, nos encontramos con un asistente que nos va solicitando en varios pasos modificar la contraseña, seleccionar la zona horaria y configurar la IP. Cuando nos sale esta última ventana debemos configurarla como IP estática, seleccionar el gateway correspondiente y añadir los servidores DNS.

    Una vez terminada la configuración de la IP, configuramos la parte de Lora. Para ello basta con acceder a Setup -> Lora. Aparece una pantalla como la que se muestra en la siguiente imagen donde hay muchos campos configurables de los cuales solo necesitamos modificar Name y Passphrases.

    Web
    Pantalla de configuración de Lora.
  • Configuración de Node-Red

    Una vez activada la aplicación de Node-Red podemos acceder a ella desde el menú “App” de la web. Por defecto viene diseñado un programa que simplemente recibe los datos del tester de Lora y los muestra por pantalla, pero debemos modificarlo para que la información se envíe a Sofia2.  En la imagen se muestra el diagrama de flujos final, en el que ha añadido la función “Sofia2 API WEB encoder”, encargada de dar el formato deseado y añadir una cabecera al mensaje a enviar y una salida HTTP (envío).

    Node-Red
    Configuración de Node-Red
  • Configuración del nodo de pruebas

    Configurar los parámetros del nodo de pruebas es realmente sencillo. Solamente hay que conectar el mDot vía USB a nuestro ordenador y conectarlo al nodo de pruebas con el cable de programación que viene en el mismo kit, de la forma que se muestra en la figura. Una vez hecho esto seleccionamos la opción “Configuration” en el mDot Box y accedemos al dispositivo utilizando la comunicación serie de Putty a velocidad 115200 baudios.

    Tester
    Tester de Lora utilizado

    Solamente es necesario configurar dos parámetros y para ello se utilizan los siguientes comandos AT:

    AT+NI=1,<Name>

    AT+NK=1,<Passphrase>

    AT&W para guardar los cambios realizados Y finalmente AT+Exit para salir del modo configuración.

    Los campos <Name> y <Passphrase> tienen que ser los mismos valores que los fijados anteriormente en el Gateway.

    Configuración del tester
    Configuración del tester

    Para comprobar si la configuración de ambos dispositivo ha sido correcta, podemos hacer una prueba con Node-Red.

Sofia2

Una vez configurada toda la parte de los dispositivos, solamente queda desarrollar la parte necesaria en Sofia2. Necesitamos dos nuevas ontologías, un API rest y un Script de reglas para tratar los datos. En este apartado se explica brevemente cómo crear cada uno de ellos.

  • Definir las nuevas ontologías

    Lo primero que debemos hacer es crear una nueva ontología que recibirá los datos que envía el nodo de pruebas. En esta ontología se insertarán los datos “en crudo” (data RAW) tal y como los envía el dispositivo, sin aplicar ningún filtrado previo.

    ontologia
    Ejemplo de ontología con datos sin tratar.

    Estos datos suelen contener tramas con codificaciones en hexadecimal, formatos no deseados o información que debe ser tratada antes de trabajar con ella. Por ello es necesario crear un Script de reglas y una nueva ontología donde se insertarán los datos ya tratados y con el formato requerido por la base de datos para su correcto almacenamiento.

  • Api Rest

    Una vez definidas las ontologías, crearemos una API REST de tipo POST a la ontología de datos sin tratar para que los datos puedan ser insertados en ella.

    Para ello debemos entrar en API MANAGER -> APIs donde encontramos la opción “Crear API”. Una vez aquí, escribimos un nombre para nuestra API, seleccionamos la opción “Publicar ontología como API REST” y la ontología deseada. Es conveniente desactivar el número máximo de peticiones por minuto para asegurarnos de que no perdemos información. Por último, seleccionamos la operación “POST” y creamos nuestra API.

     API
    Pantalla de creación de API

     La URL que aparece en el campo “EndPoint base” es la que se debe insertar en Node-RED.

  • Script de reglas

    Una vez comprobado que los datos enviados directamente desde el dispositivo se insertan de forma correcta en la ontología deseada, debemos crear un Script para tratarlos, extraer toda la información posible y dotarlos del formato correspondiente. Para ello simplemente entramos en Reglas->Wizard creación de reglas y seleccionamos la opción “Generar regla script ontología”. Con este tipo de reglas, cada vez que el dispositivo envíe nuevos datos a la ontología se ejecutará este script en el que se tratarán los datos para luego insertarlos en la ontología final.

  • Representación de resultados

    Utilizando las herramientas de visualización de Sofia2 podemos representar de manera rápida y sencilla los datos que estamos almacenando.  Para ello entramos en visualización ->Mis Gadgets-> Crear gadgets, desde donde podemos seleccionar el tipo de herramienta que más nos conviene en función de los datos. Atendiendo a los datos que se obtienen del tester de Lora, dos tipos de visualizaciones interesantes podrían ser la representación de coordenadas en un mapa y los valores de la relación señal a ruido (SNR) a lo largo del tiempo.

    Mapa
    Representación de coordenadas en un mapa

    SNR
    Representación del parámetro SNR
Integración de Lora con Sofia2

Integración de Sigfox con Sofia2

A través de las herramientas de Sofia2 la integración entre Sofia2 y Sigfox es relativamente sencilla (leer post Qué es Sigfox)

A  continuación se realiza una explicación diferenciando el desarrollo sobre la plataforma Sigfox y sobre la plataforma Sofia2.

Captura0.PNG

 Configuración en Sofia2:

Para preparar la integración en Sofia2, primero crearemos la Ontología donde almacenaremos los datos procedentes del dispositivo en crudo.

En nuestro caso, y conociendo todos los parámetros que nos envía Sigfox, creamos la ontología a partir de esta información.

Los campos serán los siguientes:

propierdades

Una vez creada nuestra ontología, la forma más sencillo es levantar un API REST para realizar la ingesta de los datos .Para ello en el apartado de API Manager en la consola de Sofia2 procedemos a crear dicha API, enlazada a la ontología que hemos generado anteriormente.

api1

Una vez creado y publicado el API con una operación POST, disponemos del servicio al cual llamará el dispositivo para enviar la información.

api2

Configuración Backend Sigfox:

Una vez logados en la plataforma de Sigfox, y con los dispositivos activados y agrupados, seleccionaremos el grupo en el cual queremos crear un nuevo callback, el cual afectará a todos los dispositivos agrupados. En este caso configuraremos el envío para los dispositivos  Sigfox Wifi  Geoloc.

sigfoxTIPOS

En la nueva pantalla que se nos muestra, seleccionamos a la izquierda “CALLBACKS”, y creamos una nueva.

Disponemos de  varias opciones para crear callbacks , en este caso seleccionamos “Custom callback” donde tendremos varios tipos de llamadas, dependiendo de la llamada que elijamos enviaremos unos datos u otros. En esta integración, nos interesa geolocalizar los dispositivos y de este modo controlar la posición de los mismos. Por ello generamos un callback de tipo GEOLOC, el cual podrá enviarnos los datos que necesitamos. Como vemos en la siguiente captura, introducimos únicamente los headers y el end point del API que hemos creado anteriormente.

Captura2

En el campo body, se crea el mensaje a enviar, donde seguiremos la estructura de la ontología, señalando aquellos datos que queremos que se envíen. Sigfox parsea los datos de las variables predefinidas entre paréntesis.

En este caso el body que enviamos es el siguiente:

Captura3

Una vez completados estos pasos, y habilitando el callback, nuestros dispositivos Sigfox estarán enviando la información a Sofia2. Puedo revisar el funcionamiento de las llamadas en el apartado de cada dispositivo independientemente, en el menu “MESSAGES”.

Captura4.PNG

Una vez comprobado que el sistema está funcionando, guardando los datos de manera correcta, podemos decir que hemos integrado los dispositivos Sigfox con Sofia2 de manera rápida y sencilla!!!

 

Integración de Sigfox con Sofia2

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

Real-time Location Systems (RTLS). RFID vs BLE vs UWB Tags

Post_RTLS

 

RTLS are used to automatically identify and track the location of objects or people in real time, usually within a building or a delimited area. The fixed reference points receive wireless signals from RTLS tags to determine their location.

 

Examples of real-time locating systems are:

  • Tracking automobiles through an assembly line
  • Locating pallets of merchandise in a warehouse
  • Identification of people for security and safety reasons
  • Finding medical equipment in a hospital

 

The physical layer of RTLS technology is usually some form of radio frequency (RF) communication, like BLE (Bluetooth 4.0), UWB (Ultra Wide Band ) or propietary systems, etc. Tags and fixed reference points can be transmitters, receivers, or both, resulting in numerous possible technology combinations.

 

RTLS are a form of local positioning system, and do not usually refer to GPS, mobile phone tracking. Location information usually does not include speed, direction, or spatial orientation. Instead they are very cost effective, need minimal batteries, work indoor and outdoor, do not need a mobile telecom operator and use open protocols.

 

Technologies in Real-Time Location Systems RTLS

 

There is a wide variety of technologies on which RTLS can be based:

 

    • Infrared (IR). They require a clear line of sight for labels and sensors to communicate, so if a board is covered by a blanket or flips, the system may not work properly.
    • Ultrasound. Ultrasound, as a communications protocol, is slower (with longer wavelengths) than the infrared, so it generally can not match the performance of other technologies
    • Wi-Fi. Although Wi-Fi infrastructure is often preexisting in the performance environment, accuracy is limited to up to 9 meters, which makes its value as a tool for locating the location is uncertain.
    • RFID. There are two types of RFID technologies to consider, active and passive. Passive RFID technology works only in the proximity of specialized RFID readers, providing a ‘point-in-time’ location. As an example, let’s think of a fashion store where the reader sends a radio signal to a labeled item of clothing and an alarm is triggered only when the label is detected very close to the designated control point. With active RFID, it has tags that send the signal to a reader every few seconds (similar to a cell phone and a tower) and triangulation software or other methods are used to calculate the position of the marked object.
    • UWB. The advantage of UWB technology is the high level of transmission safety. The UWB signal is difficult to detect and localize, because the spectral power density is below background noise. It can reach an accuracy of 10 centimeters at measuring distances of up to 100 m.
    • BLE. The Bluetooth Low Energy (or BLE) appears from the specification in version 4.0. It is aimed at very low power applications powered by a button cell. It has a data transfer rate of 32Mb / s. It operates on frequencies of 2.4 GHz and was created for marketing reasons for smartphone and tablet devices. Important advantages of this technology are that it’s based on a universal standard, and is immediately available on mobile devices without hardware need.

 

Comparison of Different Technology Tags for RTLS:

 

comparison

 

 

Real-time Location Systems (RTLS). RFID vs BLE vs UWB Tags