TUTORIAL IV: CONECTANDO ARDUINO A INTERNET

Carmen López de la Torre (Universidad de Cantabria) Ignacio Elicegui Maestro (Universidad de Cantabria) 1

TUTORIAL IV: CONECTANDO ARDUINO A INTERNET Objetivo de este tutorial En tutoriales anteriores hemos aprendido los conceptos básicos de la placa Arduino YUN y también cómo conectar diferentes tipos de sensores y obtener sus valores. Ahora llega el momento de dar un paso más y conectar nuestra placa a Internet. Esto permitirá que nuestros proyectos tengan más posibilidades, como por ejemplo poder subir los datos de nuestros sensores a un servidor y mostrarlos en una página web, que sean mostrados en una cuenta de Twitter, utilizarlos para crear nuevas aplicaciones, compartirlos con otros usuarios, etc. Para seguir este tutorial sería de ayuda tener algunos conocimientos sobre redes, pero intentaremos explicar los conceptos más básicos y hacer que estos pasos resulten lo más sencillos posible. Como vimos en anteriores ocasiones, existen diferentes modelos de Arduino. Nosotros utilizaremos el Arduino YUN (Figura 1) que permite la conexión vía WiFi y también por puerto Ethernet. Sin embargo, no es la única placa con la que podemos conectarnos a Internet, hay placas Arduino que también tienen puerto Ethernet y también hay “shields” (como la shield WiFi o la Ethernet) que como recordaréis son placas que se pueden añadir sobre otras como el Arduino UNO para sumar funcionalidades. En este tutorial, explicaremos en primer lugar teóricamente cómo conectar a Internet nuestra placa Arduino YUN . A continuación presentaremos un ejemplo práctico, explicando de forma sencilla los conceptos básicos que se deben conocer para entender los diferentes pasos, utilizando la plataforma SocIoTal para el almacenamiento y gestión de los dispositivos y datos. Configuración de Arduino YUN

Figura 1. Frontal Arduino YUN

Como podréis recordar, podemos comunicarnos con nuestra YUN a través de diferentes interfaces como la USB, WiFi o Ethernet. Nosotros trabajaremos vía WiFi (ya que es uno de los grandes potenciales de la placa). En el tutorial anterior explicamos cómo configurar nuestro Arduino conectándolo a nuestra red WiFi. Éste también será un paso fundamental en este caso, ya que al configurarla estamos diciendo a la placa a través de qué red podrá enviar la información a Internet. Esa información fluirá desde nuestra placa hasta el router de la red correspondiente, para a continuación recorrer la red hasta llegar al servidor donde queramos almacenar y gestionar nuestra información. A continuación repasaremos los pasos necesarios para configurar la placa por primera vez. o

En primer lugar necesitaremos los parámetros de nuestro WiFi (nombre de la red y contraseña). 2

o

o

o

Alimentamos la placa conectándola a nuestro ordenador con el cable microUSB. Recordad que la placa Arduino YUN no tiene un regulador de 5V, por lo que si alimentáis la placa con un valor mayor podéis dañarla. Buscamos entre las redes WiFi que detecta nuestro ordenador una del tipo “Arduino YUN-90A2DA…” (punto de acceso de nuestro Arduino YUN) y nos conectamos a ella. Si tenéis problemas al encontrar la red (tened en cuenta que necesita un rato para aparecer) o no os deja conectaros a ella es posible que necesitéis instalar los servicios Bonjour 1. Si no lo tenéis instalado lo podéis descargar en vuestro ordenador desde aquí [1] .También deberéis comprobar que vuestro antivirus no está bloqueando el puerto 5353. Una vez conectados, abrimos el navegador y accedemos a la dirección “192.168.240.1”. Nos encontraremos con el cuadro de diálogo mostrado en la Figura 2.

Figura 2. Pantalla de bienvenida del Arduino YUN

o o

La contraseña por defecto es “arduino”. A continuación nos encontraremos con la pantalla mostrada en la Figura 3, con la información básica de las interfaces de nuestra placa.

Figura 3. Panel con la información básica de las interfaces de nuestro Arduino YUN

Bonjour es un programa que originariamente está diseñado para gestionar algunas impresoras desde Windows, aunque YUN lo utiliza para el auto-descubrimiento en redes wireless.

1

3

o

A continuación nos aparece un formulario como el de la Figura 4 que completaremos con los datos de nuestro WiFi para que la placa pueda conectarse a él.

Figura 4. Pantalla de configuración del Arduino YUN

o

Aceptamos (click en “Configure & Restart” y… listo!

Ahora nuestro router WiFi asignará a la placa una dirección a la cuál tendremos que dirigirnos cuando queramos comunicarnos con ella. Sin embargo, esta dirección en principio no será estática, es decir, irá cambiando cuando desconectemos y volvamos a conectar la placa, lo que nos resultará incómodo a la hora de saber cuál tiene en cada momento. Por ello, es recomendable que la asignemos una dirección IP estática (fija). A continuación os presentamos dos formas de fijar la IP, una de ellas es entrando en la configuración de vuestro router y fijarla allí (esto dependerá de la marca/modelo del router, en Internet podréis encontrar más información sobre ello), y la otra es la de fijar la IP en la propia placa. Será esta última forma la que explicaremos con detalle: 1. Averiguar qué IP nos ha dado el router para poder entrar otra vez al menú de configuración 2. Para ello, con la YUN conectada, abriremos el IDE de Arduino e iremos a la pestaña “Herramientas” al apartado “Puerto” y apuntamos la dirección IP que aparecerá en “Network ports”, esa es la dirección que nos ha dado el router Figura 5. Anteriormente hemos utilizado la dirección 192.168.240.1 porque estábamos en la red de Arduino. Ahora estaremos en la red de nuestro router, por lo que la dirección IP habrá cambiado.

2

4

Figura 5. IDE Arduino -> Herramientas --> Puerto --> Network ports, para averiguar qué IP nos ha dado el router

2. Tecleamos esa dirección en el navegador y nos aparecerá la pantalla de configuración de la YUN pidiéndonos la contraseña. Tras introducirla hacemos click en “Configure” y después en “advanced configuration panel (luci)” que aparecerá en la parte superior. En este panel de control podremos modificar una gran cantidad de opciones de nuestra placa, que aunque también podrían modificarse por línea de comandos podría resultar más incómodo (Figura 6)

Figura 6. Dónde se encuentra el apartado "Advanced configuration panel (luci)"

3. En este menú de administración seleccionamos la pestaña “Network” y después la pestaña “Interfaces”. Seleccionamos la red a la que estemos conectados y hacemos click en “Edit”, apareciendo en la pestaña “General Setup”. El protocolo (protocol) que aparece por defecto es DHCP (el que hace que el router nos asigne las direcciones IP). En nuestro caso lo cambiaremos y buscaremos en el desplegable “Static address” (dirección estática) (Figura 7). En la casilla inferior nos preguntará si queremos realmente cambiar el protocolo, hacemos click en la casilla y nos aparecerá una serie de huecos que deberemos rellenar de la siguiente forma: 5

a. IPv4 address: en este apartado pondremos la dirección IP fija que queramos que tenga nuestra placa. Para que no haya conflictos en el router, y que éste no asigne la misma dirección a otros dispositivos, es importante asignar una dirección que nuestro router no vaya a asignar a nadie más. Esto dependerá de cómo esté configurado nuestro router pero, en general, trabaja asignando direcciones X.X.X.2 hasta X.X.X.250, y generalmente las va asignando desde la 2 una a una hasta la 250. Por ello, si no tenemos más de 200 dispositivos conectados a nuestro router, podremos asignar direcciones a partir del X.X.X.200 a nuestra placa con una probabilidad muy baja de que el router las haya asignado a otros dispositivos. [Si quieres estar seguro puedes mirar cómo es la configuración de tu router en este aspecto]. Otra opción es la de utilizar la dirección IP que hemos visto que nos ha asignado el router (que no se la habrá asignado a nadie más) como explicamos en el punto número 1 del proceso. b. IPV4 netmask: es la máscara de red que en general será 255.255.255.0 c. IPV4 gateway: esta será la dirección de nuestro router. d. Debajo de estas casillas tendremos el apartado DHCP Server que deshabilitaremos (seleccionando la casilla “Disable DHCP for this interface”) para evitar futuros problemas. e. Hacemos click en el botón de abajo a la izquierda “Save and apply” para guardar los cambios y ya tendremos lista una dirección IP permanente para nuestra placa.

Figura 7. Configuración de la dirección IP estática

Hardware y software de Arduino YUN y la librería Bridge Como ya apuntamos en tutoriales anteriores sobre Arduino YUN, esta placa difiere bastante del resto de placas Arduino. A parte de tener capacidad para conectarse por WiFi, debemos destacar su combinación de Arduino y Linux. Siendo más concretos, tenemos por un lado el procesador Arduino Leonardo clásico (atmega32U4) y por otro lado un OpenWRT con Linino instalado. Para que ambas partes se comuniquen se utiliza la librería Bridge. Ésta, además de comunicar ambas partes, transferirá las funciones complejas de conexiones de red, transacciones HTTP, etc. que describamos en Arduino a la parte de Linino. Por eso, en general, si tenemos conocimientos Linux será más sencillo trabajar con YUN que con las placas anteriores. La librería Bridge [2] permite que algunas de las órdenes que especificamos en nuestros sketch de arduino puedan ser interpretados con Python en la parte Linux. Además de transferir los comandos que le requiera la parte de Arduino en Linux, también se encarga de proveer un espacio de almacenaje compartido para compartir datos (como lecturas de sensores) entre Arduino e Internet, y de recibir comandos desde Internet pasándoselos directamente a Arduino. En la Figura 8 podéis ver un esquema general del Arduino YUN mostrando lo que acabamos de explicar. 6

Figura 8. Esquema general Arduino YUN

Debido a las continuas mejoras de la librería, la versión que viene instalada por defecto en nuestra YUN puede que no esté actualizada. Por ello os animamos a que comprobéis cuál es vuestra versión y que la actualicéis si es necesario. Hay dos formas de actualizarla, utilizando el panel de control de la placa o usando línea de comandos. A continuación explicaremos el primer caso, utilizando el panel de control. Si queréis hacerlo por línea de comandos podéis encontrar información de cómo hacerlo en [3]. 1. En la web [4] buscad en “Other Software” la última versión de OpenWRT-YUN y descargaros el archivo .zip 2. Extraer el contenido del archivo .zip en una microSD (si utilizáis un tarjeta de mucha capacidad es posible que no os funcione, una de 8GB es suficiente). Tened en cuenta que al actualizar la YUN perderéis todos los archivos y configuraciones que hayáis guardado anteriormente en la memoria flash. 3. Antes de actualizarla es aconsejable que carguemos el ejemplo YunSerialTerminal (Archivo->Ejemplos>Bridge->YunSerialTerminal) en nuestra placa, ya que si tenemos cargados otros programas puede haber problemas durante la actualización si la placa intenta ejecutarlos. 4. Insertamos la tarjeta en la correspondiente ranura de la YUN. 5. Una vez que nuestra placa está en la misma red que nuestro ordenador abrimos un navegador y accedemos con la IP de la placa al panel de control. En la parte inferior nos aparecerá un botón grande “RESET” y un mensaje que dice que en la tarjeta SD se ha encontrado un fichero y que si lo quieres utilizar para resetear la placa. Hacemos click en el botón de RESET. 6. Tardará unos minutos en actualizarse, no debemos utilizar la placa mientras se está actualizando.

Por otro lado, en algunas ocasiones será necesario que reseteemos nuestra placa, por ejemplo cuando veamos que no está funcionando de forma correcta (y pensemos que el reseteo puede solucionarlo). La placa ofrece tres tipos de reseteo: reseteo del procesador Linux, del 32UE y del WiFi.

7

Para reiniciar el procesador Linux tendremos que presionar el botón “YUN RST”. En el caso de querer reiniciar la parte Arduino de nuestra placa y que vuelva a comenzar el programa (sketch) que tenemos cargado, tendremos que apretar dos veces el botón 32U4 RESET que está en la esquina de la placa al lado del puerto Ethernet. El botón para resetear el WiFi se encuentra en la esquina donde está el puerto USB. En este caso tendremos dos opciones, si hemos cambiado de red y no podemos conectarnos con la nueva, apretamos el botón durante algo más de 5 segundos (pero menos de 30) y nuestra YUN aparecerá como otro punto de acceso en la lista de redes WiFi a las que conectarse. A continuación podremos conectarnos a ella y modificar los parámetros de la red WiFi como explicamos anteriormente. Si lo que queremos es resetear la placa a la última versión instalada, dejando la placa como si la acabáramos de actualizar, borrando todos los ficheros y la configuración de red, deberemos apretar el botón durante 30 segundos [5].

Enviar información desde Arduino YUN a un servidor Ahora que sabemos un poco más sobre cómo funciona la placa, podemos ponernos manos a la obra y comenzar a enviar la información que recogemos con nuestros sensores a través de Internet. Pero… ¿para qué queremos enviar la información a través de Internet y a dónde? Hasta ahora hemos recogido los valores de los sensores que conectábamos a nuestras placas y el ordenador nos ha proporcionado los valores imprimiéndolos por pantalla. Esto está bien si no necesitamos más que esto, pero lo realmente interesante del Internet de las Cosas es que yo pueda gestionar mis dispositivos esté donde esté, y esta capacidad nos la dará el que nuestros dispositivos estén conectados a Internet. De esta forma, podremos consultar los datos de nuestros sensores allá donde estemos y exista una conexión a Internet. Por ejemplo, podría tener una alarma en mi casa (un dispositivo con una cámara y un sensor de presencia en mi entrada) que me enviara una notificación cuando alguien atravesara la puerta, me encontrara donde me encontrara, sin la necesidad de estar continuamente mirando la pantalla de mi ordenador. Además, de esta forma podría compartir la información con otros usuarios o crear nuevos servicios de valor añadido. Hemos respondido a la pregunta del por qué voy a querer enviar la información a Internet. Ahora toca responder a la pregunta ¿a dónde envío la información? Dependerá de lo que queramos hacer, pero en general enviaremos la información a un servidor que se encargará de su manejo y almacenamiento. Un servidor, puede definirse de forma muy breve como una máquina a la que realizaremos peticiones, realizará una acción y nos devolverá un resultado. Por ejemplo, imaginemos un servidor que da la hora, le podemos enviar una petición preguntándole la hora y nos devolvería la hora que es en ese momento. En nuestro caso, lo que tendremos será un servidor al que (explicándolo de forma muy genérica) le enviaremos una petición con la información que queremos almacenar y éste lo almacenará. Lo que tendremos que programar en nuestras placas es la petición que le haremos al servidor. Esto no será complicado, solamente tendremos que saber la dirección de ese servidor (a dónde tenemos que enviar la petición) y cómo tenemos que enviar la información (de qué forma hay que enviársela para que la entienda). La Figura 9 presenta un esquema de cómo viaja la información recogida por nuestras placas.

8

Figura 9. Esquema de cómo viaja la información desde nuestra placa a un servidor

A continuación os presentamos el código genérico para Arduino (sketch) que utilizaremos para recoger la información del sensor y enviarla al servidor encargado de recibir los datos. El código está comentado para que sea más sencillo de entender, pero explicaremos las líneas más importantes. #include #include #include #include #include

"DHT.h"

//Definimos el pin digital que leerá del sensor #define DHTPIN 9 //especificamos que estamos usando el DHT22 #define DHTTYPE DHT22 // Inicializamos el sensor pasando como parámetros el pin y el tipo de sensor. DHT dht(DHTPIN, DHTTYPE);

//Setting time between POST requests unsigned long lastConnectionTime = 0; // última vez que nos conectamos al const unsigned long postingInterval = 20L*1000L; //intervalo de tiempo

servidor en milisegundos entre envíos en milisegundos

void setup() { wdt_disable();

//wachdog, añadir al principio de la función de setup

// La libería Bridge tarda unos 2 segundos en arrancar, por lo tanto es de utilidad // utilizar el LED de la placa (pin 13) para saber si se ha inicializado pinMode(13, OUTPUT); //establecemos el pin 13 como salida digitalWrite(13, LOW); //apagamos el LED Bridge.begin();//arrancamos la librería Bridge digitalWrite(13, HIGH); //encendemos el LED del pin 13 dht.begin(); //arrancamos la librería del DHT //Console.begin(); //descomentar si queremos ver mensajes por pantalla wdt_enable(WDTO_8S); //watchdog, añadir al final de la función de setup }

9

void loop() { //podríamos utilizar la función de millis() para saber en qué momento estamos ahora //y compararlo con lastConnectionTime para saber cuánto tiempo ha pasado desde la //última vez que nos hemos conectado al servidor. El problema es que la función //millis() vuelve a tomar el valor 0 cuando pasan unos 50 días. Para solucionar esto, //cuando esto ocurra, igualaremos el valor de lastConnectionTime para que éste nunca //sea mayor que millis()

if (millis() < lastConnectionTime){ //Serial.println("millis menos que lastConnectionTime"); lastConnectionTime == millis(); }

if (millis() - lastConnectionTime > postingInterval) {

//****** Cogemos el valor de temperatura del sensor y lo convertimos de float a string char cadenaTemporal[6]; float roomTemperature = dht.readTemperature(); String temp = dtostrf(roomTemperature, 3, 2, cadenaTemporal);

//****** Cogemos el valor de humedad del sensor y lo convertimos de float a string char cadenaTemporal2[6]; float roomHumidity = dht.readHumidity(); String hum = dtostrf(roomHumidity, 3, 0, cadenaTemporal2); //******creamos un nuevo proceso y enviamos el comando al procesador de linux Process p; //instance of Process wdt_disable(); p.runShellCommand("sh /mnt/sda1/test.sh 193.144.201.50:3500 " + temp + " " + hum); wdt_enable(WDTO_8S); //******descomentar para recibir datos por pantalla //while (p.available()) { // char c = p.read(); // Console.print(c); // } //Console.println(); //Console.flush(); lastConnectionTime = millis(); }//if wdt_reset(); }//loop

El código podemos dividirlo en tres partes: una primera parte en la que llamamos a las librerías necesarias y declaramos algunas variables, una segunda parte que será el setup del código y se ejecutará una única vez, y una tercera con el loop que se ejecutará de forma continua en el Arduino. En la primera parte del código llamamos a la librería Bridge que se encarga de comunicar la parte Arduino de la placa con la parte Linux, a la librería Console que nos permitirá pintar por pantalla cuando utilicemos WiFi, a la librería Process que nos permitirá enviar comandos a la parte Linux, a la librería Watchdog que nos reiniciará el dispositivo si deja de funcionar normalmente [6], y por último la librería para manejar el sensor SHT15.

10

Los siguientes pasos que se llevan a cabo son los de especificar los pines que vamos a utilizar para leer los datos que nos ofrece el sensor, y declarar e inicializar un par de variables que nos servirán para marcar los intervalos de tiempo entre envíos. Ya en el setup iniciamos la librería Bridge. Normalmente se suele programar que se encienda el LED 13 una vez que se inicia la librería para saber que realmente se ha iniciado, ya que suele tardar un par de segundos en arrancar. Antes de salir del setup también arrancamos la librería Console por si la utilizamos en un futuro. Como ya sabemos de ocasiones anteriores, en el ciclo loop() se especifican las líneas que se ejecutarán una y otra vez, el corazón del sketch. En nuestro código, el primer “if” se utiliza para mantener el correcto funcionamiento de la función millis(), ya que el valor que devuelve esta función (el tiempo que ha pasado desde que se ha lanzado el programa) vuelve a 0 pasados unos 50 días, y esto puede dar lugar a problemas. El siguiente “if” nos sirve para seguir ejecutando el programa si ha pasado el intervalo de envío, realizando entonces las tareas previas al envío y enviando la información. Antes de enviar, primero deberemos recoger el dato de temperatura del sensor y lo transformaremos a string para enviarlo. A continuación realizamos la misma operación con la humedad. Una vez recogidos los datos los enviaremos al servidor. Este paso, que se resume en hacer un POST al servidor con la información, se puede hacer de varias formas. Una de ellas es utilizando la librería HTTP que ofrece Arduino YUN y otra es enviando la tarea a la parte Linux de la YUN para que lo ejecute. Nosotros, siguiendo la filosofía de YUN en la que las tareas más complejas es preferible que sean ejecutadas por la parte Linux, utilizaremos la segunda opción y ordenaremos, con la ayuda de la librería Process, a la parte Linux que ejecute la orden que tendrá almacenada en un fichero con los datos que le estamos enviando. Exactamente eso es lo que haremos con la siguiente línea: p.runShellCommand("sh /directorio/archivo.sh IP_server:PORT " + temp + " " + hum);

Una vez creada una instancia de Process “p” (que le dice a Linux que va a tener que realizar una acción) utilizamos el método runShellCommand para que Linux ejecute el comando que se define a continuación. Lo que estamos ordenando con el comando es que tiene que ejecutar el archivo “sh” (un tipo de script) que se encuentra en este caso en /directorio y que se llama “archivo.sh”. En el comando también se especifican 3 parámetros que son la IP y el PORT (dirección IP y puerto) del servidor al que tenemos que enviar, y los valores de temperatura y humedad. Estos parámetros son requeridos por el script archivo.sh. Por último, se actualiza el momento de la última conexión al actual ofrecido por millis().

Ahora llega el momento de analizar el fichero “archivo.sh” de la Figura 10 que ejecutamos en la parte de Linux, y que realmente es el encargado de enviar los datos al servidor. #!/bin/sh curl ${1}/ruta -X POST -H "Cabecera1" –H “Cabecera2” –H “CabeceraN” -d 'datos' Figura 10. Script archivo ".sh"

Lo mostrado en la Figura 11 es un esquema de lo que tiene que contener el fichero .sh para que se envíe la información deseada al servidor. En primer lugar deberemos entender qué hace un archivo .sh. Siendo breves podemos decir que interpreta las órdenes que le escribimos y las ejecuta en la línea de comandos de Linux (como una receta de cocina que tenemos que seguir paso a paso). En este caso lo que le estamos diciendo es que tiene que hacer un “curl”. cURL [8] es una herramienta muy útil para realizar peticiones HTTP/S, las cuales nosotros vamos a utilizar para hacer peticiones a un servicio RESTful [7], que nos permitirá (entre otras cosas) guardar información, actualizarla, etc. Como podréis observar, con el curl que os mostramos estamos haciendo una petición POST. Esto quiere decir que estamos enviando cierta información al servidor para actualizar 11

ciertos datos. Entendido esto, ahora vamos a analizar cómo estructuramos el cURL para que funcione. En primer lugar se especifica el comando, que como habéis visto es “curl”. A continuación se especifica cuál es la dirección del servidor, que en nuestro caso es la IP que le hemos puesto como parámetro en el sketch de Arduino (también la podéis escribir aquí directamente, la hemos puesto como parámetro por si alguna vez la cambiamos poderlo hacer directamente en el sketch de Arduino), y el resto de la ruta en la cual actualizamos los valores de los recursos en el servidor. A continuación podemos ver “-X POST” que indicará al cURL que queremos actualizar un valor (si fuera otro tipo de petición esto cambiaría a GET, PUT, DELETE, etc. dependiendo de lo que queramos que haga el cURL [8]). Después vienen las cabeceras que empiezan con un “-H”. Las cabeceras son información extra que enviamos en la petición para dar información sobre cómo procesar las peticiones. Por ejemplo, una típica es "Content-Type:application/json" en la que le indicamos que lo que le vamos a enviar va a ser un JSON (formato de intercambio de datos). Estos parámetros serán necesarios o tendrán que modificarse dependiendo de lo que se vaya a enviar al servidor. Una vez que hayamos añadido las cabeceras que necesitamos, podemos enviar los datos que queremos que lleguen al servidor con -d 'datos'.

Ejercicio práctico – Enviando información a la plataforma SocIoTal Una vez presentadas las bases teóricas de cómo enviar información a Internet con nuestro Arduino, vamos a realizar un ejercicio práctico en el que enviaremos la información recogida por nuestras placas a la plataforma SocIoTal. Existen diferentes plataformas que ofrecen servicios de recolección, almacenaje o visualización de datos, como por ejemplo GroveStreams [9], Xively [10], ThingSpeak [11] o Carriots [12]. Cada una tiene sus ventajas y sus desventajas, y cada una tendrá sus “instrucciones” particulares de uso, aunque fundamentalmente habrá que enviar a un servidor la información siguiendo un determinado modelo de datos. En nuestro caso os proponemos utilizar la plataforma desarrollada dentro del proyecto europeo SocIoTal [20] (Figura 11). Esta plataforma, además de ofrecernos un servidor en el que almacenar la información producida por nuestros dispositivos, nos permitirá registrar nuestros dispositivos, subscribirnos a la información que reportan, crear alertas y notificaciones, encontrar anomalías en la información, compartir la información con aquellos usuarios a los que nosotros autoricemos de forma segura, etc.

Figura 11. Esquema de cómo viaja la información desde nuestra placa a la plataforma SocIoTal

12

Para utilizar la plataforma SocIoTal tenemos disponibles dos vías. Una de ellas, destinada a usuarios avanzados que tengan práctica en el manejo de APIs [13], en la que dispondrán de un conjunto de APIs de los diferentes componentes y que podrán utilizar para acceder a la plataforma o para crear sus propios servicios basándose en dichos componentes. Podéis encontrar información sobre las APIs de SocIoTal en [14]. Por otro lado, si queremos hacer un uso de la plataforma más sencillo y directamente acceder a sus funcionalidades a través de una web, tenemos disponible el Entorno de Usuario, el cual utilizaremos en este caso práctico y que explicamos a continuación. En este ejemplo práctico queremos montar una pequeña estación meteorológica que constará de una placa Arduino YUN y el sensor de temperatura y humedad DHT22 que hemos utilizado en ocasiones anteriores. Seguiremos el montaje mostrado en la Figura 12.

Figura 12. Montaje del DHT22 para el ejemplo práctico.

Entorno de Usuario y envío de la información a la plataforma SocIoTal El entorno de usuario de SocIoTal nos permitirá gestionar nuestros dispositivos de la forma más amigable posible. Cuando hablamos de gestión de dispositivos nos referimos a que seremos capaces de registrarlos, subscribirnos a las medidas que envíen al servidor, eliminar dispositivos, buscar dispositivos de otros usuarios que ofrezcan medidas concretas, etc. Además, podremos crear “comunidades” en las cuales los usuarios podrán compartir información sin que ésta pueda ser accedida por otros usuarios externos a la comunidad. Creando una cuenta y conociendo los paneles principales El primer paso para empezar a usar el Entorno de Usuario será el de crear una cuenta para tener nuestro propio perfil y gestionar nuestros dispositivos. Para ello, entraremos en la página web [15] y haremos click en “Sign up”. Nos aparecerá un pequeño formulario como el que se muestra en la Figura 13.

13

Figura 13. Página de inicio del Entorno de Usuario de SocIoTal

Una vez completados estos datos recibiremos un email en nuestro correo confirmando que nuestra cuenta ha sido activada y podremos utilizarla. El siguiente paso será el de entrar en la página de log in con nuestros datos y entramos en nuestro panel de control (dashboard), muy similar al ejemplo mostrado en la Figura 14.

Figura 14. Panel principal (dashboard) del Entorno de Usuario de SocIoTal

14

El Dashboard será nuestro panel principal y en él podremos encontrar 3 cuadros que son accesos directos a los 3 entidades principales que nos permitirán gestionar nuestros dispositivos: Channels (canales), Devices (dispositivos), y Smartphones. A continuación describiremos la información que encontraremos al hacer click en cada cuadro. • Device: el término “Devices” se refiere a nuestros dispositivos y si hacemos click en ese cuadro podremos ver una lista con todos los dispositivos que hay registrados en la plataforma (y accesibles por todos los usuarios)Figura 15. Si hacemos click en alguno de ellos veremos dos nuevos cuadros, uno de ellos nos proporcionará información sobre el dispositivo (nombre, identificador, proyecto, despliegue y tipo – más adelante explicaremos cada uno de estos términos), y el otro nos informará sobre los atributos del dispositivo.

Figura 15. Ejemplo lista dispositivos.

•

•

Channel (canal): un canal es la interfaz que nos permitirá gestionar nuestros dispositivos además de recoger y visualizar la información que éstos producen. Cuando hagáis click en este cuadro, se os mostrará una lista con los diferentes tipos de canales que hayamos creado. Por ejemplo, podremos tener un XivelyChannel para dispositivos conectados a Xively [10] o podremos tener un SocIoTalChannel para dispositivos que estén enviando a la plataforma SocIoTal (como es nuestro caso). Si hacéis click en uno de ellos podréis ver la información del canal. En primer lugar se muestra la información principal (autor, tipo de canal, el identificador, la fecha en la que fue creado, una descripción y tags). El siguiente cuadro mostrará los atributos del dispositivo asociado a ese canal (con información complementaria en el icono de la derecha). A continuación se muestra un cuadro que nos permitirá suscribirnos a la información que recoge nuestro dispositivo. Si hacemos click en el botón verde con el símbolo de “play” comenzaremos a recibir los datos que ofrezca nuestro dispositivo cada vez que la información cambie (Figura 26). Smartphones: se refiere a los teléfonos que hayamos registrado, es decir, que tengan instalada la apliación de SocIoTal, también llamada Entorno de Usuario Móvil. Con esta aplicación podremos tener acceso a la lista de nuestros canales y dispositivos, así como de la información que estos proveen.

En el área superior derecha de cualquier página encontraremos un acceso directo a nuestro perfil y un desplegable con 4 apartados: nuestro perfil, link a la página del proyecto SocIoTal, la versión del entorno de 15

usuario y el botón para desconectarnos. Expliquemos en detalle la información que nos proporciona nuestro perfil (Figura 16): en la parte superior aparecerá nuestro nombre, alias y dirección de correo electrónico que proporcionamos al registrarnos. A continuación aparece un API Key (una clave personal para manejar el API e identificarnos) que se nos otorga por defecto y que nos servirá para identificarnos como usuarios en la aplicación móvil. El código QR contiene el mismo código, por lo que también podremos leerlo con nuestra aplicación. Además, los desarrolladores que deseen utilizar el API del Entorno de Usuario de SocIoTal deberán especificar este código en todas las llamadas del API, podéis encontrar más info en la documentación [16]. Deberéis mantener este código en secreto, ya que con él cualquiera podría instalarse la aplicación y acceder a vuestros dispositivos.

Figura 16. Perfil de usuario en el Entorno de Usuario de SocIoTal

Registro de un dispositivo en la plataforma Una vez que ya estamos registrados en la plataforma podremos comenzar a registrar nuestros dispositivos. Tendremos dos formas de registrar dispositivos: utilizando el API del gestor de información de SocIoTal que podéis encontrar en [17], o mediante el entorno de usuario de SocIoTal. Si tenéis conocimientos de desarrollo podéis utilizar el API mencionado, si no es el caso os recomendamos la segunda opción, que será la que explicaremos a continuación. Para registrar nuestro dispositivo hacemos click en la pestaña “Devices” (dispositivos) y después en el botón “+”. Nos aparecerá una ventana que nos ofrece una lista de plantillas con “tipos de dispositivos” (Figura 17). Una vez seleccionada la plantilla, nos aparecerá un formulario en el que rellenar los datos de nuestro nuevo dispositivo (Figura 18).

16

Figura 17. Plantillas para registrar un nuevo dispositivo.

Figura 18. Formulario para registrar un nuevo dispositivo a partir de una plantilla.

Si el dispositivo que queremos añadir no está en esa lista de plantillas podemos seleccionar la plantilla vacía “Blank” y rellenaremos un formulario como el mostrado en la Figura 19.

17

Figura 19. Formulario para registrar un nuevo dispositivo con plantilla vacía.

Figura 20. Selección de atributos durante el registro de un nuevo dispositivo.

Como se muestra en la Figura 19 tendremos que completar los siguientes campos: o o o

Entity Name: o nombre de entidad, que rellenaremos con el nombre que queramos darle a nuestro dispositivo. ID: o identificador, que estará formado (en ese orden) por los valores que introduzcamos en las casillas de “project”, “deployment”, “context type” y “entity name”. Project: este campo describe el proyecto al que está adscrito el dispositivo. Se utiliza para ayudar a los usuarios a “ordenar” sus dispositivos y realizar búsquedas de entidades más eficientes. Hasta ahora, en todos los dispositivos que hemos registrado dentro del proyecto SocIoTal este campo se ha puesto con el valor “SocIoTal”. Vosotros, por supuesto, podéis utilizar el mismo o poner el que vosotros consideréis, como por ejemplo el nombre de vuestros proyectos personales. 18

o

o

o

Deployment: identifica el despliegue. En el proyecto se ha estado utilizando para este valor el nombre de la ciudad donde está físicamente el dispositivo. En nuestro caso solemos poner SAN de Santander pero, como en el caso anterior, podéis poner el nombre que vosotros deseéis. La utilización de la ciudad se ha vuelto a utilizar por cuestiones de realizar búsquedas más rápidas en el futuro. Context Type: en este caso es interesante utilizar un nombre que realmente describa el tipo de contexto (información) que ofrecerá el dispositivo. Por ejemplo, en nuestro caso que tenemos una estación meteorológica el context type será “weather station”. Aunque hayamos puesto el nombre en inglés también podéis hacerlo en castellano. Attributes: o atributos, describen las diferentes características/propiedades que tienen nuestros dispositivos. Por ejemplo, si tenemos un dispositivo que nos ofrezca valores de temperatura y humedad, éstos serán sus atributos. Haciendo click en el botón “+” podremos seleccionar atributos de una lista como la mostrada en la Figura 20.

En el caso que hayamos seleccionado una plantilla distinta a “Blank” tendremos completados los valores de “Context Type”, “Project” o “Deployment” (los cuales podremos modificar), y aparecerán por defecto una serie de atributos predefinidos que podremos eliminar si nuestro dispositivo no ofrece dicha información, o añadir otros nuevos. Una vez hayamos completado estos valores podemos guardar el registro haciendo click en “save” (guardar). Nos aparecerá un cuadro de diálogo preguntándonos si queremos crear un “channel” para este nuevo dispositivo. Podemos hacer click en “ok” o “Cancel” dependiendo si queremos crear el canal ahora (ok), crearlo más tarde (cancel) o no crearlo (cancel).

Programación del arduino para enviar la información a la plataforma SocIoTal Ahora que nuestro dispositivo está registrado, podemos empezar a enviar la información del dispositivo al gestor de contexto donde se almacena la información. El código que utilizará nuestro Arduino para recoger la información de los sensores y enviarla al servidor es el mismo que explicamos en las primeras secciones del tutorial, salvo que ahora la dirección IP y PORT del servidor será la del gestor de contexto de SocIoTal: IP = 193.144.201.50 y PORT= 3500, el directorio donde almacenaremos el archivo .sh es el de la tarjeta microSD (/mnt/sda1), y hemos puesto el nombre “test.sh” al archivo.sh. Abrimos el Arduino IDE, copiamos este código y lo subimos a nuestro Arduino. #include #include #include #include #include

"DHT.h"

//Definimos el pin digital que leerá del sensor #define DHTPIN 9 //especificamos que estamos usando el DHT22 #define DHTTYPE DHT22 // Inicializamos el sensor pasando como parámetros el pin y el tipo de sensor. DHT dht(DHTPIN, DHTTYPE);

//Setting time between POST requests unsigned long lastConnectionTime = 0; // última vez que nos conectamos al const unsigned long postingInterval = 20L*1000L; //intervalo de tiempo

servidor en milisegundos entre envíos en milisegundos

19

void setup() { wdt_disable();

//wachdog, añadir al principio de la función de setup

// La libería Bridge tarda unos 2 segundos en arrancar, por lo tanto es de utilidad // utilizar el LED de la placa (pin 13) para saber si se ha inicializado pinMode(13, OUTPUT); //establecemos el pin 13 como salida digitalWrite(13, LOW); //apagamos el LED Bridge.begin();//arrancamos la librería Bridge digitalWrite(13, HIGH); //encendemos el LED del pin 13 dht.begin(); //arrancamos la librería del DHT //Console.begin(); //descomentar si queremos ver mensajes por pantalla wdt_enable(WDTO_8S); //watchdog, añadir al final de la función de setup } void loop() { //podríamos utilizar la función de millis() para saber en qué momento estamos ahora //y compararlo con lastConnectionTime para saber cuánto tiempo ha pasado desde la //última vez que nos hemos conectado al servidor. El problema es que la función //millis() vuelve a tomar el valor 0 cuando pasan unos 50 días. Para solucionar esto, //cuando esto ocurra, igualaremos el valor de lastConnectionTime para que éste nunca //sea mayor que millis()

if (millis() < lastConnectionTime){ //Serial.println("millis menos que lastConnectionTime"); lastConnectionTime == millis(); }

if (millis() - lastConnectionTime > postingInterval) {

//****** Cogemos el valor de temperatura del sensor y lo convertimos de float a string char cadenaTemporal[6]; float roomTemperature = dht.readTemperature(); String temp = dtostrf(roomTemperature, 3, 2, cadenaTemporal);

//****** Cogemos el valor de humedad del sensor y lo convertimos de float a string char cadenaTemporal2[6]; float roomHumidity = dht.readHumidity(); String hum = dtostrf(roomHumidity, 3, 0, cadenaTemporal2); //******creamos un nuevo proceso y enviamos el comando al procesador de linux Process p; //instance of Process wdt_disable(); p.runShellCommand("sh /mnt/sda1/test.sh 193.144.201.50:3500 " + temp + " " + hum); wdt_enable(WDTO_8S); //******descomentar para recibir datos por pantalla //while (p.available()) { // char c = p.read(); // Console.print(c); // } //Console.println(); //Console.flush(); lastConnectionTime = millis(); }//if wdt_reset(); }//loop

20

Como explicamos anteriormente, necesitamos tener cargado en la placa el archivo “.sh” en el que indicaremos a la placa el comando que tiene que ejecutar para enviar la información al servidor. La Figura 21 muestra el código “.sh” que utilizaremos en el caso práctico. #!/bin/sh

curl ${1}/SocIoTal_CM_REST_V2/NGSI10_API/updateContext -X POST -H "ContentType:application/json" -d '{"contextElements": [{ "id": "SocIoTal:SAN:WeatherStation:testMeetup", "type": "urn:xorg:sociotal:resource:weatherstation", "isPattern": "false", "attributes": [ { "name": "AmbientTemperature", "value": "'${2}'", "metadatas": [ { "name": "DateTimeStamp", "value": " '$(date -u +%Y%m%dT%H%M%SZ)' ", "type": "http://sensorml.com/ont/swe/property/DateTimeStamp" } ] }, { "name": "HumidityValue", "value": "'${3}'", "metadatas": [ { "name": "DateTimeStamp", "value": "'$(date -u +%Y%m%dT%H%M%SZ)' ", "type": "http://sensorml.com/ont/swe/property/DateTimeStamp" } ] } ] }], "updateAction": "UPDATE" }' Figura 21. Script archivo ".sh" completo.

Como podréis observar, con el curl que os mostramos estamos haciendo una petición POST. Esto quiere decir que estamos enviando cierta información para actualizar ciertos datos. ¿Y qué es lo que estamos actualizando en este caso? Muy sencillo, la información de temperatura y humedad del dispositivo que está registrado con el identificador "SocIoTal:SAN:WeatherStation:testMeetup". Como explicamos anteriormente, en primer lugar se especifica el comando “curl”. A continuación se especifica cuál es la url del servidor, que en nuestro caso es la IP que le hemos puesto como parámetro en el sketch de Arduino (también la podéis escribir aquí directamente, la hemos puesto como parámetro por si alguna vez la cambiamos poderlo hacer directamente en el sketch de Arduino), y el resto de la ruta en la cual actualizamos los valores de los recursos en el servidor. La que está puesta es la que se utiliza en el gestor de contexto de SocIoTal, es decir, estamos haciendo un POST a 193.144.201.50:3500/ SocIoTal_CM_REST_V2/NGSI10_API/updateContext. Tened cuidado con las mayúsculas y las minúsculas, es importante que utilicéis la dirección tal y como os la mostramos. A continuación podemos ver “-X POST” que indicará al cURL que queremos actualizar un valor. Después vienen las cabeceras que empiezan con un “-H”. Las cabeceras son información extra que enviamos en la petición para dar información sobre cómo procesar las peticiones. En nuestro caso utilizamos "Content-Type:application/json" en la que le indicamos que lo que le vamos a enviar va a ser un JSON (formato de intercambio de datos). Una vez que ya hemos puesto las cabeceras que necesitamos, enviamos la información indicando su comienzo con “-d” y añadiendo los datos con el formato correspondiente. En nuestro caso estamos guardando este fichero de instrucciones en una micro-SD que puede insertarse en la placa. Si quisiéramos guardarlo en otro directorio de la placa podríamos hacerlo siempre que indiquemos en el comando “p.runShellCommand("sh /directorio/test.sh IP_server:PORT " + temp + " " + hum);” del código de Arduino el directorio correspondiente.

La forma de enviar la información dependerá del modelo de datos que requiera el servidor, es decir, cómo el servidor pida recibir la información. En nuestro caso, el servidor de SocIoTal requiere que le enviemos los datos en formato JSON con una estructura concreta, de la que podéis ver un ejemplo en la Figura 22.

21

{"contextElements": [{ "type": "urn:x-org:sociotal:resource:weatherstation", "isPattern": "false", "id": "SocIoTal:SAN:WeatherStation:testMeetup", "attributes": [{ "name": "AmbientTemperature", "value": "30.0", "type": "http://sensorml.com/ont/swe/property/AmbientTemperature", "metadatas": [{ "name": "DateTimeStamp", "value": "20141030T113343Z", "type": "http://sensorml.com/ont/swe/property/DateTimeStamp" }, { "name": "Unit", "value": "celsius", "type": "http://purl.oclc.org/NET/ssnx/qu/qu#Unit" }, { "name": "accuracy", "value": "0,5", "type": "http://sensorml.com/ont/swe/property/QuantitativeAttributeAccuracy" }, { "name": "DataDescription", "value": "float", "type": "http://sensorml.com/ont/swe/property/DataDescription" }] }, { "name": "HumidityValue", "value": "50", "type": "http://sensorml.com/ont/swe/property/HumidityValue", "metadatas": [{ "name": "DateTimeStamp", "value": "20141030T113343Z", "type": "http://sensorml.com/ont/swe/property/DateTimeStamp" }, { "name": "Unit", "value": "percentage", "type": "http://purl.oclc.org/NET/ssnx/qu/qu#Unit" }, { "name": "accuracy", "value": "1", "type": "http://sensorml.com/ont/swe/property/QuantitativeAttributeAccuracy" }, { "name": "DataDescription", "value": "integer", "type": "http://sensorml.com/ont/swe/property/DataDescription" }] }],

}

}], "updateAction": "UPDATE" Figura 22. Ejemplo modelo de datos SocIoTal

22

El modelo de datos que os mostramos en la Figura 22 sigue un formato JSON, que es un formato ligero para intercambio de datos ampliamente utilizado del que podéis encontrar más info en [18]. Lo que representa esta plantilla es un conjunto (un array) de contextElements (elementos de contexto) que están formados por una serie de elementos fundamentales: o o o o

o

“id”: identificador de nuestro dispositivo. “type”: definirá el tipo de dispositivo, podéis poner lo que queráis pero es aconsejable que realmente identifique lo que es, por ejemplo “estación meteorológica” en nuestro ejemplo. “isPattern”: por ahora no es utilizado en la actualización de datos pero es un campo obligatorio que pondremos a valor “false”. “attributes”: son los atributos de nuestros dispositivos, o dicho de otra forma, las propiedades que éste ofrece y que se definen con un “name” (nombre), un “value” (valor) y un “type”. En nuestro caso, que tenemos una estación meteorológica los atributos serán temperatura y humedad. La razón por la que utilizamos “AmbientTemperature” y “HumidityValue” en lugar de, por ejemplo, “temperatura” y “humedad” es por seguir algún tipo de estándar que será útil cuando queramos realizar búsqueda de dispositivos por atributos. Esto es así porque si buscamos todos los dispositivos que nos ofrezcan “humedad” sólo aparecerán aquellos que tengan explícitamente el atributo “humedad”, pero no los que tengan “humidity” o “hum” aunque todos ofrezcan valores de humedad. El estándar que se utiliza en SocIoTal (y que podéis seguir si queréis) es sensorML y podéis encontrar más información en [19]. “metadata”: son tripletes (nombre, valor y tipo) que ofrecen información extra sobre los atributos. No es una información que haya que añadir de forma obligatoria, pero suele ser interesante en muchos casos.

Después del array de contextElements encontramos “updateAction”: “UPDATE” que indica que estamos actualizando valores, en [17] podéis encontrar todas las llamadas que se pueden hacer (en el caso de que estemos trabajando con el API) al gestor de contexto de SocIoTal (el servidor que estamos utilizando). El ejemplo de plantilla que os hemos presentado es el JSON que describe una dispositivo con los atributos temperatura, humedad y localización completo. Sin embargo, una vez que el dispositivo está registrado no será necesario que pongamos todos y cada uno de los parámetros cuando queramos hacer una actualización de la información. Algunos sí que son obligatorios como el “id”, el “type” y el “isPattern” de la entidad. En cuanto a los atributos, sólo tendremos que añadir aquellos que vayamos a actualizar. Por ejemplo, si sólo quisiéramos actualizar el valor de la temperatura no tendríamos que añadir el de humedad. De los atributos sólo será necesario añadir el “name” y el “value”. En cuanto a los metadatas sólo añadiremos aquellos que vayamos a actualizar (en nuestro caso sólo actualizaremos el “DateTimeStamp” para saber en qué momento se actualizó por última vez). En el caso de los metadatas tendremos que mantener el triplete completo de “name”, “value” y “type”. Y por supuesto, al final tendremos que añadir el “updateAction”:”UPDATE” para que el servidor sepa que la acción que tiene que realizar es la de actualizar los valores. Con todo esto, por ejemplo, en el caso de querer actualizar únicamente el valor de la temperatura, utilizaremos el esquema de la Figura 23.

{

23

{"contextElements": [{ "type": "urn:x-org:sociotal:resource:weatherstation", "isPattern": "false", "id": "SocIoTal:SAN:WeatherStation:testMeetup", "attributes": [{ "name": "AmbientTemperature", "type": "http://sensorml.com/ont/swe/property/AmbientTemperature", "value": "30.0", "metadatas": [{ "name": "DateTimeStamp", "value": "20141030T113343Z", "type": "http://sensorml.com/ont/swe/property/DateTimeStamp" }] }, { "name": "HumidityValue", "value": "50", "type": "http://sensorml.com/ont/swe/property/HumidityValue", "metadatas": [{ "name": "DateTimeStamp", "value": "20141030T113343Z", "type": "http://sensorml.com/ont/swe/property/DateTimeStamp" }] }],

}

}], "updateAction": "UPDATE"

Figura 23. Modelo de datos simplificado.

Este texto será el que añadamos en el fichero “.sh” justo después de la indicación “-d” y lo escribiremos entre comillas simples. Subimos el código Arduino a nuestra placa, copiamos el archivo.sh a la tarjeta microSD y después la insertamos en la placa en la ranura correspondiente. Alimentamos la placa y, una vez que ésta se conecte a la Wifi que configuramos al principio, empezará a actualizar los datos en el servidor. Creación y manejo de los “channels” o canales Una vez que nuestro dispositivo está registrado y está enviando la información a la plataforma, podremos volver a hacer uso del Entorno de Usuario de SocIoTal para comenzar a gestionar la información que envía el dispositivo. En primer lugar crearemos un canal para nuestro dispositivo (si no lo hemos hecho cuando lo registramos) accediendo a la caja “Channels” y haciendo click en el botón arriba a la derecha “+”. Nos aparecerá una lista de tipos de canales, seleccionaremos el que corresponda. En nuestro caso, como utilizaremos la plataforma SocIoTal crearemos un canal del tipo “SocIoTalChannel”. En ese momento nos aparecerá la lista con todos los dispositivos disponibles. Para crear un canal asociado al dispositivo que deseemos, tenemos que hacer click en el icono de cadena que aparece en el dispositivo en cuestión (Figura 24).

24

Figura 24. Creación de un canal a partir de un dispositivo registrado.

Una vez seleccionado, tendremos que rellenar un pequeño formulario con los campos que detallaremos a continuación: o o o

Name (obligatorio): nombre para nuestro nuevo canal. Description (opcional): descripción para el canal. Tags (opcional): etiquetas que caractericen el canal. Por ejemplo, si el canal va a ser el interfaz de una estación meteorológica, las etiquetas podrían ser: tiempo, temperatura, humedad.

Una vez hayamos completado los campos requeridos (y los opcionales si es el caso) crearemos el canal haciendo click en “Save”. En ese momento nos aparecerá un nuevo canal en la lista con el nombre que le hayamos puesto. Una vez creado el canal podremos, a través de él, realizar acciones sobre la información que nuestro dispositivo está enviando al SocIoTal Context Manager. En primer lugar, cuando accedemos a uno de los canales haciendo click sobre su nombre (Figura 25), podremos encontrar información del canal como el autor del canal, el tipo de canal y la fecha en la que fue creado. A la derecha encontremos la lista de atributos que tiene nuestro dispositivo. En la zona superior a la derecha podemos acceder a las opciones “Edit” para editar el canal, y “Delete” para borrar el canal (se borrará el canal pero no el dispositivo de la lista de dispositivos).

25

Figura 25. Ejemplo de la descripción de un canal

Debajo de la información del canal tenemos el apartado “Data” que nos permitirá realizar subscripciones (Figura 26). Esto significa que podremos subscribirnos a los datos que nuestro dispositivo envía al gestor de contexto de SocIoTal. De esta forma, cada vez que cambien los valores de nuestro dispositivo recibiremos los nuevos valores. Haciendo click en el botón “play” podremos activar la subscripción a los valores. Una vez que este botón haya sido pulsado cambiará a “stop” y lo tendremos que pulsar cuando queramos dejar de estar suscritos. El botón rojo con el aspa nos permitirá limpiar la lista con los datos recibidos. Por otro lado, el signo de exclamación se refiere a “Anomalías de los datos” y lo explicaremos un poco más adelante.

26

Figura 26. Ejemplo del resultado de una suscripción a los valores ofrecidos por un dispositivo.

El apartado “Connections” (conexiones) permite programar el envío de notificaciones cuando ocurren determinados eventos. Por ejemplo, enviar una notificación al teléfono (que tenga instalada la aplicación del Entorno de Usuario Móvil de SocIoTal) cuando la temperatura en una habitación baje de los 18 grados o cuando el sensor de la entrada detecte presencia. Para crear una conexión hacemos click en el botón “+” y nos aparece una ventana inicialmente con dos campos para completar. En la parte superior aparece un desplegable “WHEN” (cuándo) para indicar el atributo que cuando cambie queremos que se nos envíe la notificación. Una vez seleccionado el atributo nos aparecerá el “trigger” donde indicaremos si el valor de ese atributo tiene que ser igual, distinto, mayor o menor que el valor que pongamos a continuación. El siguiente campo es “DO” (hacer) donde seleccionaremos el canal a través del cual queremos que nos llegue la notificación. Por ejemplo, si tenemos instalada la aplicación móvil del entorno de usuario nuestro teléfono aparecerá como un nuevo canal y podremos enviar notificaciones a nuestro teléfono. Una vez que hemos seleccionado el canal, podremos seleccionar una acción como puede ser enviar un mensaje que escribiremos en el campo correspondiente. Por ejemplo, si queremos que se nos envíe una notificación cuando la temperatura sea menor que 15 grados programaremos: WHEN “AmbientTemperature” LESS THAN “15” DO dispositivo “send a notification” notificación (Figura 27).

27

Figura 27. Ejemplo de la creación de una conexión.

El apartado “Anomalies Detection” está bajo desarrollo, por lo que se pueden obtener valores extraños durante su uso. Esta funcionalidad se basa en herramientas estadísticas para reconocer eventos anómalos y lanzar un mensaje. Por ejemplo, si normalmente en una habitación tenemos una temperatura media y de repente se obtiene un valor 10 grados menor saltaría un evento.

Comunidades – Restringiendo el acceso a los datos Hasta ahora, los dispositivos que hemos registrado aparecen de forma pública para todos los usuarios, pudiendo estos ver la información que estos ofrecen y pudiendo subscribirse y creando conexiones. Por supuesto, esto no siempre será de nuestro interés y querremos que otros usuarios no tengan acceso a ciertos dispositivos, u ofrecer acceso sólo a aquellos usuarios que nosotros deseemos. Esto podrá realizarse de forma sencilla con la funcionalidad de “Creación y gestión de comunidades” que SocIoTal ofrece. Para ello, tendremos disponible una nueva opción en nuestro panel (dashboard) para crear nuevas comunidades de las que seremos propietarios y a las que podremos añadir aquellos dispositivos a los que nosotros queramos restringir el acceso, además de añadir a otros usuarios a los cuales queramos dar acceso a dichos dispositivos. En cuestiones de código, solamente tendremos que modificar ligeramente el “.sh” al que le añadiremos otro paso en el que, antes de enviar la información a actualizar, pediremos un “token” (permiso) al servidor a partir de nuestro usuario/password y que añadiremos como nueva cabecera en la petición. Toda la información sobre la creación y gestión de comunidades estará disponible próximamente en un nuevo tutorial en la web del proyecto [20].

Referencias 1. 2. 3. 4.

Bonjour services. [En línea] https://support.apple.com/kb/DL999?locale=en_US Bridge Libraries. [En línea] https://www.arduino.cc/en/Reference/YunBridgeLibrary Actualizar Arduino YUN. [En línea] https://www.arduino.cc/en/Tutorial/YunSysupgrade Descarga software Arduino. [En línea] https://www.arduino.cc/en/Main/Software#toc8 28

5. 6. 7. 8.

9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.

Información sobre Arduino YUN. [En línea] https://www.arduino.cc/en/Guide/ArduinoYun Librerías Wachdog. [En línea] http://polaridad.es/watchdog-reloj-perro-guardianarduino/ Introducción a los servicios Restful. [En línea] http://www.dosideas.com/noticias/java/314-introduccion-a-los-servicios-web-restful.html Herramienta curl. [En línea] http://programandolo.blogspot.com.es/2013/08/herramienta-curl-en-el-interpretede.html Grovestreams. [En línea] https://www.grovestreams.com/ Xively. [En línea] https://xively.com/ Thingspeak. [En línea] https://thingspeak.com/ Carriots. [En línea] https://www.carriots.com/ Interfaz de programación de aplicaciones API. [En línea] https://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones API SocIoTal. [En línea] https://github.com/sociotal/SOCIOTAL/wiki SocIoTal User Environment. https://sociotal.crs4.it/login API SocIotal User Environment. [En línea] https://github.com/sociotal/SOCIOTAL/wiki/User-Environment-API API Context Manager SocIoTal. [En línea] https://github.com/sociotal/SOCIOTAL/wiki/SocIoTal-Context-Manager Qué es JSON y dónde se usa. [En línea] http://canela.me/articulo/%C2%BFqu%C3%A9es-json-y-d%C3%B3nde-se-usa SensorML properties. [En línea] http://sensorml.com/orr/#http://sensorml.com/ont/swe/property SocIoTal project. [En línea] http://sociotal.eu/

Agradecimientos Este tutorial ha sido realizado dentro del proyecto europeo SocIoTal (www.sociotal.eu). Este proyecto ha recibido financiación del Séptimo Programa Marco de la Unión Europea para investigación, desarrollo tecnológico y demostración bajo el acuerdo de concesión nº 609112.

29