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

Meetup sobre Integración de LPWAN con Sofia2: SigFox, LoRaWAN y The Things Network

 

El pasado Miércoles 28 de Febrero tuvimos el placer de organizar uno de nuestros Meetups de tecnología. Podéis seguir tanto este Meetup como los que planifiquemos en el futuro si os unís a nuestro grupo de MeetupAquí también podéis encontrar las slides usadas durante la sesión.

Queremos dar las gracias a THECUBE Madrid por cedernos el espacio y elaborar este video resumen del Meetup, muy chulo!

De la mano de nuestros compañeros Jorge Trallero y Mario Briceño, se presentó de presentar lo sencillo que resulta realizar integraciones de datos recogidos de dispositivos que transmiten usando tecnologías de comunicación Low Power Wide Area (LPWA). En concreto nos centramos en 3 casos:

  • Integración con SigFox
  • Integración con una red LoRa privada
  • Integración con The Things Network

Además tuvimos el privilegio de compartir nuestro espacio con la comunidad de The Things Network en Madrid, sobre la que podéis leer más en este post.

Seguir leyendo “Meetup sobre Integración de LPWAN con Sofia2: SigFox, LoRaWAN y The Things Network”

Meetup sobre Integración de LPWAN con Sofia2: SigFox, LoRaWAN y 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?

Web Thing API by Mozilla

W3C Web Thing es una nueva propuesta (en este caso por parte de Mozilla) para describer un modelo de datos común y un API para la “Web of Things”.

La Web Thing Description provee un vocabulario para describir dispositivos físicos conectados a Internet en un formato legible basado en JSON.

Por su parte la Web Thing REST API y Web Thing WebSocket API permiten que un cliente web pueda acceder a las propiedades de un dispositivo, ejecutar acciones sobre este y suscribirse a eventos que representan un cambio en su estado.

La especificación incluye:

· Web Thing Types como tipos adicionales que pueden ser definidos usando extensiones semánticas sobre JSON-LD

· Un Web Thing API Protocol Bindings para escribir bindings a la Web Thing API para otros protocolos IoT

· El documento Web of Things Integration Patterns describe patrones para integrar dispositivos con la Web Thing API.

Seguro que con un ejemplo se entiendo mucho major lo que nos ofrece esta especificación:

Donde podemos ver que el dispositivo (DigitalTwin) tiene una propiedad temperatura de tipo Number, otra humidity y otra led, así como una acción (que alguien puede ejecutar sobre el dispositivo) y un evento (que se publica cuando se desencadena) reboot. Así como links para acceder a las propiedades, acciones ,eventos,…

Siguiendo la especificación podemos ver como:

Ejecutando esta petición:

Obtengo la descripción del dispositivo concreto.

Si hago

Me devolverá el valor de la propiedad:

Si quiero cambiar el valor de una propiedad:

Si quiero lanzar una acción reboot:

También puedo obtener una lista de peticiones de acciones:

Para acceder a los eventos

Aunque a la especificación le faltan aún bastantes cosas (como la seguridad, lógica embebida en el dispositivo) a nivel de interfaces la especificación es muy sencilla y fácil de implementar versus otras soluciones más potentes (y complejas) que veremos en próximos posts.

Web Thing API by Mozilla

Beijing Institute of Technology (BIT) meets Sofia2

IMG_20180123_153430862

 

In the context of “Winter School”, the collaboration framework between Polytechnic University of Madrid (UPM) and Beijing Institute of Technology (BIT), students from BIT visited Indra’s facilities in Madrid. Different Indra’s technological solutions were presented, highlighting the IoT approach based on Minsait IoT Sofia2 platform.

 

IoTVision

 

Sebastián Gómez, Business Development manager and Ayla Ruiz, platform consultant, introduced Sofia2 to the students, explaining its origin, present and future, as well as its main characteristics and capabilities.

 

IMG_20180123_153430862

 

They also presented the different types of projects where Sofia2 can be applied. They got help from Mario Briceño and Lucía Fernandez, IoT engineers, to explain practical examples and some of the different solutions that use Sofia2 as a technological base.

 

IMG_20180123_160417

 

BIT students showed great interest in creating their own projects using  CloudLabthe Sofia2’s experimentation environment.

See you soon!!

Beijing Institute of Technology (BIT) meets Sofia2

Despliegue y monitorización de Aplicaciones Spring Boot desde Control Panel de Sofia2

Introducción

Se ha integrado en el componente Contenedor de ThinKPs la posibilidad de desplegar aplicaciones basadas en Spring Boot. Para simplificar la integración de estas aplicaciones con Sofia2 se ha avanzado con la funcionalidad del módulo Sofia4Boot descrito aqui.

Las aplicaciones desplegadas dentro del contenedor de Sofia2 pueden ofrecer cualquier tipo de funcionalidad, incluso si no requiere de Sofia2 más que el contenedor y el sistema de gestión (en entornos desplegados tras un Nginx puede requerir cierta configuración, como abrir puertos).

Autorización

Las aplicaciones Spring Boot que usen en contenedor de ThinKPs necesitan proporcionar ciertos credenciales a la plataforma Sofia2. Para esto es necesario disponer de un ThinKP asociado a una ontología, y proporcionar como propiedad el token de acceso (ver sección de propiedades más adelante).

Creando una aplicación nueva

Para crear una aplicación basada en Spring Boot para Sofia2 se debe empezar con incluir en el POM las dependencias necesarias. Sofia2 dispone de un repositorio Nexus con las dependencias requeridas.

Atención! Sofia4Boot requiere de una versión de Java igual o superior a 1.8

Repositorio Nexus de Sofia2

<repositories>
     <repository>
    <id>SOFIA2</id>
    <url>http://sofia2.org/nexus/content/groups/public/</url>
    </repository>
</repositories>

Dependencias de Sofia4Boot

<dependency>
    <groupId>com.indra.sofia2.boot</groupId>
    <artifactId>sofia4boot</artifactId>
    <version>1.3</version>
</dependency>

Además hay que incluir las dependencias propias de Spring Boot (en esto no hay diferencias respecto a una aplicación SpringBoot típica). Es particularmente importante asegurarse que la aplicación que generamos es autocontenida (y ejecutable). Para esto lo más normal es usar el plugin de Spring Boot:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Durante el diseño de la aplicación hay que tener en cuenta que a la hora de arrancarla, el contenedor añadirá elementos adicionales a la configuración, como por ejemplo, limitación de memoria y propiedades de configuración. Un ejemplo de comando de arranque puede ser: -Xmx256m -Dspring.boot.admin.url=http://127.0.0.1:8101 -Dspring.boot.admin.prefer-ip=true. Esto incluye por ejemplo la configuración interna necesaria para registrar la aplicación en la instancia spring boot admin de Sofia2.

Clase principal

Para la clase principal usaremos una plantilla habitual para Spring Boot, a la que añadiremos el soporte para que se integre con el sistema de administración (esto se consigue añadiendo la anotación @EnableSpringBootAdminRegister).

@SpringBootApplication
@EnableSpringBootAdminRegister
public class S4BApp 
{
    public static void main (String [] args) {
        new SpringApplicationBuilder(S4BApp.class).run(args);
    }
}

La anotación @EnableSpringBootAdminRegister se encargará de registrar la aplicación en la consola, con lo que se podrá gestionar en una ventana de la consola de Sofia2:

Modelado de una ontología

La forma más fácil de modelar una ontología es descargarse las clases generadas desde el Control Panel de Sofia2. Para esto hay que ir a la opción de menú ‘Mis Ontologías’, buscar la ontología que se quiera, pulsar sobre el botón ‘Ver Ontología’ (con un icono representando un ojo), y al final de la ventana deberemos ver un botón con el texto ‘Clase Java de la Ontología’. Esto nos descargará un fichero comprimido con las clases de la ontología.

Esto también puede hacerse a mano. Un ejemplo de modelado de una ontología sencilla sería la siguiente:

Modelo de la ontología de ejemplo

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "level Schema",
    "type": "object",
    "required": [
        "Level"
    ],
    "properties": {
        "Level": {
            "type": "string",
            "$ref": "#/datos"
        }
    },
    "datos": {
        "description": "descripcion",
        "type": "object",
        "required": [
            "date"
        ],
        "properties": {
            "value": {
                "type": "integer"
            },
            "date": {
                "type": "string"
            }
        }
    }
}

Y un ejemplo de instancia:

{
    "Level": {
        "value": 1,
        "date": "string"
    }
}

Las clases Java de modelado serían:

Modelo de datos

public class Level {

    private String date;
    private Integer value;

    public Level() {

    }

    public Level(String date, Integer value) {
        this.date = date;
        this.value = value;
    }

    public String getDate() {
        return date;
    }

    public void setDate(String date) {
        this.date = date;
    }

    public Integer getValue() {
        return value;
    }

    public void setValue(Integer value) {
        this.value = value;
    }
}

Y como la ontología tiene un nivel adicional para controlar siempre los valores, tendremos que incluir un wrapper

Envoltorio de ontología

public class LevelOntology extends Ontology<Level> {

    @JsonProperty("Level")
    private Level level;

    public LevelOntology () {}

    public LevelOntology (String date, Integer value) {
        level = new Level(date, value);
    }

    @Override
    public void setData(Level level) {
        this.level = level;
    }

    @Override
    public Level getData() {
        return level;
    }
}

Acceso al repositorio de la ontología

Para operar con la ontología disponemos de un conjunto de anotaciones que nos autogeneran el código de operación necesario. Un ejemplo de repositorio para la sencilla ontología del ejemplo anterior:

@Sofia2Repository("level")
public interface LevelRepository {

    @Sofia2Query("select * from level")
    List<LevelOntology> findAll ();

    @Sofia2Query("select * from level where Level.value=0")
    List<LevelOntology> findAllZeros ();

    @Sofia2Query("select * from level where Level.value=$value")
    List<LevelOntology> findAllWhereValueMatches (@Param("$value") Integer value);

    @Sofia2Insert
    SofiaId save(LevelOntology levelOntology);

    @Sofia2Query("db.level.remove({\"Level.value\":$value})")
    SofiaIds deleteWhereValueMatches(@Param(value = "$value") Integer value);

    @Sofia2Delete
    List<SofiaId> delete(String id);
}

Este repositorio no tiene código, es sólo un interfaz, siendo la librería de Sofia4Boot la encargada de generar y registrar en el contexto de spring la clase de implementación necesaria, con lo cual ya podremos disponer de ella de la forma habitual en spring:

@Autowired private LevelRepository levelRepository;

Añadiendo funcionalidad

Para este ejemplo, simplemente voy a hacer que cada n minutos se genere un nuevo valor aleatorio para la ontología. Para esto implementamos un servicio proveedor de valores que se encargue de hacer inserciones en la ontología:

@Service
public class Provider {

    private static final Logger log = LoggerFactory.getLogger(Provider.class);
    private Random random = new Random();

    @Autowired
    private LevelRepository levelRepository;

    public void sendRandomMessage () {

        try {
            // --- create new level value
            Instant now = Instant.now();
            Integer value = random.nextInt(10);
            LevelOntology levelOntology = new LevelOntology(now.toString(), value);
            log.info("Inserting data ontology: {}, ", levelOntology);
            // --- insert a random value
            SofiaId id = levelRepository.save(new LevelOntology(now.toString(), value));
            log.info("Created new record with value '{}' and id '{}'", value, id.getId().getOid());
        } catch (Exception e) {
            log.warn("Captured exception running app", e);
        }
    }
}

Y para que se ejecute cada intervalo genero un job con un planificador (un scheduler) que arranque cuando la aplicación haya terminado de cargarlo todo:

@Configuration
public class JobConfig implements ApplicationListener<ContextRefreshedEvent> {

    private final Logger log = LoggerFactory.getLogger(JobConfig.class);
    private final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);

    @Autowired
    private Config config;
    @Autowired
    private Provider provider;

    @Override
    public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {

        log.info("Scheduling tasks ({} minutes)", config.getIntervalInMinutes());
        Runnable task = new Runnable() {
            @Override
            public void run() {
                provider.sendRandomMessage();
            }
        };

        Integer interval = config.getIntervalInMinutes();
        scheduler.scheduleAtFixedRate(task, interval, interval, TimeUnit.MINUTES);
    }
}

Para cargar la configuración estamos usando una clase Java mapeada por Spring con un fichero de configuración:

@Configuration
@ConfigurationProperties(prefix = "s4b")
public class Config {

    // el valor por defecto es 1, y la property se mapea contra 's4b.intervalInMinutes'
    private Integer intervalInMinutes = 1;

    public Integer getIntervalInMinutes() {
        return intervalInMinutes;
    }

    public void setIntervalInMinutes(Integer intervalInMinutes) {
        this.intervalInMinutes = intervalInMinutes;
    }
}

Configuración de la aplicación

A parte de la configuración habitual de Spring, existen propiedades adicionales referentes a Sofia4Boot, y además están las propias de nuestra aplicación.

La configuración específica de Sofia4Boot que nos aplica está referida a continuación:

Propiedad Valor de ejemplo Descripción
sofia2.host sofia2.com El host del servicio MQTT
sofia2.port 1884 El puerto para MQTT
sofia2.kp levelkp El kp al que se asocia la aplicación
sofia2.instance levelkp-demo El nombre de esta instancia de thinkp
sofia2.token 5118bt0acc2e464782dfwb52af582h9z El token de autorización del thinkp
sofia2.mqtt false Decide si se utiliza rest (false) o mqtt (true)
sofia2.endpoint http://sofia2.com/sib/services/ssap La URL del endpoint SSAP de Sofia2

Las propiedades propias de este ejemplo, junto con las de Spring Boot:

Propiedad Valor de ejemplo Descripción
logging.file ${spring.application.name}.log El nombre del archivo de logs a generar
server.port 0 Si fuera necesario, el puerto en el que se quiere arrancar el servicio. Esto requiere actualizar la configuración de Nginx
management.security.enabled false Esta property se asegura que se utiliza el sistema de autenticación de sofía, y no el que tiene spring boot admin por defecto
s4b.intervalInMinutes 5 inserta un valor nuevo a la ontología cada 5 minutos

Desplegando en el Contenedor de ThinKPs

Para desplegar nuestra aplicación dentro del contenedor de ThinKPs de Sofia2 deberemos haber completado los siguientes pasos:

  1. Generar una ontología en la plataforma, o seleccionar una que ya esté disponible (puede estar vacía si no se necesitan datos).
  2. Crear un KP, y generar un token, que se usarán para autorizar a nuestra aplicación (como cualquier otro dispositivo).
  3. Implementar nuestra aplicación y disponer del archivo ‘jar’ para desplegarlo.

Hecho esto, accedemos a la consola de Sofia2, menú ‘Contenedor ThinKPs’, y una vez allí haremos click en el botón con el texto ‘Nuevo ThinKP en contenedor’. Rellenamos la ventana que nos muestra la consola asegurandonos de:

  • Marcar el tipo de aplicacion como ‘Aplicación Spring Boot’
  • Seleccionar un token de autenticación (que coincida con el que incluimos en la configuración de nuestra aplicación!).
  • Cargamos nuestro archivo jar
  • Seleccionamos un nombre para nuestro contenedor, asegurandonos de incluir la extensión ‘.jar’

Un ejemplo:

Cuando termine (según nuestra conexión y el tamaño del JAR puede tardar un poco), deberíamos ver una ventana con la descripción parecida a la siguiente:

Aquí tenemos el botón que nos permite arrancar nuestra aplicación (por defecto están paradas nada más crearlas).

Spring Boot Admin

Una vez nuestra aplicación está arrancada y si está configurada correctamente, pasado un rato deberíamos poder verla registrada en el servicio de administración de Spring Boot Admin, en el menú ‘ThinKPs -> Administración de Spring Boot’, como puede verse a continuación:

Pulsando sobre el botón ‘Details’ podemos ver más detalles acerca de nuestra aplicación, como por ejemplo:

Despliegue y monitorización de Aplicaciones Spring Boot desde Control Panel de Sofia2

Nueva guía e IDE de desarrollo de soluciones sobre Plataforma Sofia2

image0172

 

Uno de los objetivos fundacionales de la Plataforma Sofia2 es el de simplificar y agilizar el desarrollo de todo tipo de aplicaciones, desde aplicaciones IoT en las que intervienen Gateways o dispositivos móviles a grandes sistemas Big Data, sin olvidar las aplicaciones web puras de gestión, para las que Sofia2 es un facilitador.

En este ámbito se ha añadido en la sección de Documentación  de la web sofia2.com una nueva guía que explica paso a paso cómo construir aplicaciones web (en la guía basadas en Spring Boot y Angular):

image0172

 

Complementando la guía se ha generado un entorno de desarrollo empaquetado como un ZIP que contiene todas las herramientas necesarias para construir estas soluciones (incluyendo JVM Java, IDE Eclipse, Maven, Apache Tomcat,…)

Nueva guía e IDE de desarrollo de soluciones sobre Plataforma Sofia2