tutorial iv: conectando arduino a internet

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
<Bridge.h>
<Console.h>
<Process.h>
<avr/wdt.h>
"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
<Bridge.h>
<Console.h>
<Process.h>
<avr/wdt.h>
"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