UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

GRADO EN INGENIERÍA INFORMÁTICA

TRABAJO FIN DE GRADO

Plataforma de bajo coste para la monitorización y

control de entornos inteligentes

Cristian Vozmediano García

Febrero, 2017
P LATAFORMA DE BAJO COSTE PARA LA MONITORIZACIÓN Y CONTROL
DE ENTORNOS INTELIGENTES
 Escuela
Superior
de Informática

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA
Tecnologías y Sistemas de Información

TECNOLOGÍA ESPECÍFICA DE
COMPUTACIÓN

TRABAJO FIN DE GRADO

Plataforma de bajo coste para la monitorización y

control de entornos inteligentes

Autor: Cristian Vozmediano García

Director: Dra. María José Santofimia Romero
Director: Dr. Félix Jesús Villanueva Molina

Febrero, 2017
Cristian Vozmediano García
Ciudad Real – Spain
E-mail: cvozmedg@gmail.com
Teléfono: 634 575 047

c 2017 Cristian Vozmediano García
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
of the license is included in the section entitled "GNU Free Documentation License".
Se permite la copia, distribución y/o modificación de este documento bajo los términos de la
Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por
la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en
el apéndice titulado «GNU Free Documentation License».
Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son
reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y
cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en
mayúsculas o como nombres propios.

i
TRIBUNAL:

Presidente:

Vocal:

Secretario:

FECHA DE DEFENSA:

CALIFICACIÓN:

PRESIDENTE VOCAL SECRETARIO

Fdo.: Fdo.: Fdo.:

ii
Resumen

Hoy en día estamos rodeados de tecnología, en la casa, en el trabajo o en nuestras acti-

vidades de ocio. Cada vez la tecnología y la manera en la que nos relacionamos con ella es
más importante y está más presente en nuestras vidas.
El auge del Internet de las Cosas hace que esta relación que comentamos sea muy estrecha
y que la tecnología nos ayude en muchas facetas de nuestra vida. Muy relacionado con este
paradigma está la domótica, que nos permite tener un espacio automatizado, que entiende
nuestras acciones y es capaz de reaccionar ante ellas. Además nos permite tener un control
de nuestros espacios incluso sin estar fisicamente en él.
Debido a la aparición de programas de ayuda para personas mayores relacionados con
sistemas informáticos y el auge de las tecnologías web y móviles, se presenta un marco en
el que surge la necesidad de unir estos hitos y pensar en sistemas para llevar a cabo esta
ayuda.
Analizando lo anterior surge la idea de este proyecto con la intención de desarrollar un
sistema domótico de bajo coste cuyo principal cometido sea supervisar y reconocer acciones
de los usuarios (personas mayores) para ayudarles a mejorar su calidad de vida.
Se ha logrado implementar un sistema basado en arquitectura cliente servidor, utilizando
hardware libre y de bajo coste monitorizado y controlado desde una aplicación móvil híbrida
desarrollada con tecnologías web. Además, el sistema posee cierta capacidad inteligente pues
utilizando los datos almacenados en una base de datos de lo que sucede en el entorno domó-
tico es capaz de reconocer las acciones que las personas mayores realizan en cada momento
para predecir después sus posibles acciones futuras.

III
Abstract

Currently, technology is around us, present not only in our work but also at home or even
in our free-time activities. The relationship between technology and the way we connect to
it is becoming more and more important.
The growth of Internet of Things makes this relationship quite narrow and the technology
helps us in many ways in our lives. Quite related to this paradigm we can identify the domotic
paradigm. This home automation lets us have an automatic space that understands our actions
and it is able to react to them. Besides, thanks to domotics, we can control our spaces even
if we are not physically present.
Due to the emergence of helping programmes for the elderly related to computing systems,
and the rise of the web technologies and mobile phones, a new environment is presented
where there is a need to link all these parts and to think about systems to accomplish this
help.
This project is conceived taking into account the previous ideas. It is focused on develo-
ping a domotics low-cost system whose tasks are to monitor and recognise users’ actions,
in this case the elderly’s, and to help them to improve their lives’ quality thanks to techno-
logy.
A new system based on client/server architecture has been achieved using a free low-cost
hardware which can be monitored and controlled from a hybrid mobile phone application
based on web technologies. Furthermore, the system has artificial intelligence by which it
is able to recognised actions performed by the elderly and predicts future actions using data
compiled in a database from the domotics environment.

IV
Agradecimientos

Después de unos largos años de muchas experiencias buenas vividas, ha terminado este
capítulo de mi vida.
Quiero agradecer en primer lugar a mis padres, Antonio y Jose, y a mi hermano Rubén,
por darme la oportunidad de poder estudiar y formarme, ya que sin ellos esto no hubiera sido
posible. Ha sido largo y duro pero se ha conseguido. Gracias por no dejar de creer en mí.
A Sonia, que me ha acompañado en tan largo viaje, que me ha visto disfrutar pero también
de sufrir y sobre todo en esta última etapa donde lo he tenido que dar todo. Gracias por estar
ahí siempre. No me olvido de tus padres Polo y Deme, ni de tu hermana Rosa Mari, que
también han participado en esta etapa.
A los amigos que me llevo de mis años de estudiante, con los que he compartido muy
buenos ratos y también días duros e intensos de estudio, de prácticas, proyectos... Así es la
vida del estudiante de informática.
A mis directores Maria José y Félix, que me han ayudado mucho para sacar esto adelante,
a pesar de las dificultades de no estar allí donde están ellos.
En general, a la gente que ha pasado por mi vida en esta etapa y que de alguna manera u
otra siempre la recordaré.
Gracias.
Cristian

V
A mis padres, hermano y Sonia, por apoyarme siempre

vi
Índice general

Resumen III

Abstract IV

Agradecimientos V

Índice general VII

Índice de cuadros X

Índice de figuras XI

Índice de listados XIII

Listado de acrónimos XIV

1. Introducción 1

2. Objetivos 5
2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Implementación de un servidor de comunicaciones . . . . . . . . . 5
2.2.2. Implementación servidor web . . . . . . . . . . . . . . . . . . . . 5
2.2.3. Desarrollo de aplicación móvil para usuarios . . . . . . . . . . . . 6
2.2.4. Implementación de un sistema de inteligencia . . . . . . . . . . . . 6
2.2.5. Validación del sistema . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Antecedentes 7
3.1. Domótica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Evolución de la tecnología . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Domótica de bajo coste . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Ambient Intelligence (AMI) y Ambient Assisted Living (AAL) . . . . . . . 15

VII
 3.3. Sistemas inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Dispositivos móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4. Método y Fases de Trabajo 22

4.1. SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2. Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3. Metodología Scrum aplicada a este proyecto . . . . . . . . . . . . 25
4.2. Tecnologías de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.1. Medios hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.2. Medios software . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5. Desarrollo del proyecto 34

5.1. Análisis de requisitos y estudio de tecnologías . . . . . . . . . . . . . . . . 34
5.1.1. Protocolo de comunicación para los clientes (sistemas de control)
con el broker de comunicaciones . . . . . . . . . . . . . . . . . . . 34
5.1.2. Circuito de validación del sistema y programas de control . . . . . 35
5.1.3. Servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.4. Aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.5. Módulo de inteligencia . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2. Desarrollo Broker y Protocolo de comunicación domótico . . . . . . . . . 37
5.3. Montaje circuitos de los sistemas sensores y actuadores y su programación . 39
5.4. Desarrollo servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5. Desarrollo aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6. Sistema de base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.7. Módulo de inteligencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.8. Servidores y tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6. Resultados 59

7. Conclusiones y propuestas 64

A. GNU Free Documentation License 67

A.0. PREAMBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.1. APPLICABILITY AND DEFINITIONS . . . . . . . . . . . . . . . . . . . 67

viii
 A.2. VERBATIM COPYING . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.3. COPYING IN QUANTITY . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.4. MODIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.5. COLLECTIONS OF DOCUMENTS . . . . . . . . . . . . . . . . . . . . . 72
A.6. AGGREGATION WITH INDEPENDENT WORKS . . . . . . . . . . . . 72
A.7. TRANSLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.8. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.9. FUTURE REVISIONS OF THIS LICENSE . . . . . . . . . . . . . . . . . 73
A.10.RELICENSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Referencias 75

ix
Índice de cuadros

3.1. Tabla comparativa hardware bajo coste . . . . . . . . . . . . . . . . . . . . 10

5.1. Tabla ejemplo de llamadas al API REST . . . . . . . . . . . . . . . . . . . 56

X
Índice de figuras

1.1. Placa Arduino Modelo UNO [Ard] . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Ordenador de bajo coste Raspberry Pi Modelo B [Foua] . . . . . . . . . . . 3
1.3. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1. Ejemplo de entorno domótico[Viv] . . . . . . . . . . . . . . . . . . . . . . 7

3.2. Kit de sensores y actuadores para Arduino[Ama] . . . . . . . . . . . . . . 11
3.3. Control de un led mediante pulsador con arduino[FM] . . . . . . . . . . . . 11
3.4. Tetris con Arduino[OG] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Esquema de arquitectura Casa domótica con Arduino y Android . . . . . . 13
3.6. Esquema sistema Prototipo de sistema de domótica basado en Arduino . . . 14
3.7. Representación gráfica de un sistema inteligente[Fri] . . . . . . . . . . . . 17
3.8. Ejemplo gráfico de una red bayesiana[Wik] . . . . . . . . . . . . . . . . . 18
3.9. Ilustración grafo probabilidades de una Cadena de Markov . . . . . . . . . 19
3.10. Dispositivo LG G4[Ele] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1. Fases de la metodología Scrum . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2. Fases de un ciclo de sprint[Auta] . . . . . . . . . . . . . . . . . . . . . . . 25

5.1. Ejemplo interacción del broker en el sistema . . . . . . . . . . . . . . . . . 39

5.2. Ejemplo interacción del broker en el sistema . . . . . . . . . . . . . . . . . 40
5.3. Fotografía del circuito con los sensores (luminosidad, presencia e interrup-
tores) montado para el prototipo y validación del sistema . . . . . . . . . . 41
5.4. Fotografía del circuito con los actuadores (luces) montado para el prototipo
y validación del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5. Plano de una casa convencional y ubicación de elementos domóticos . . . . 42
5.6. Diagrama conexión entre dispositivos móviles y servidor del sistema . . . . 45
5.7. Esquema de la arquitectura para la aplicación móvil . . . . . . . . . . . . . 46
5.8. Diagrama componentes de una aplicación con Marionettejs y Backbonejs[SO] 48
5.9. Vista sistema global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.10. Vista configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

XI
5.11. Diagrama que muestra la probabilidad de transición de estados inicial . . . 51
5.12. Diagrama que muestra la probabilidad de observaciones en cada estado . . 52
5.13. Diagrama de flujo del sistema inteligente . . . . . . . . . . . . . . . . . . . 53

6.1. Maqueta prototipo del circuito del sistema . . . . . . . . . . . . . . . . . . 59

6.2. Salida consola del sistema con el flujo de mensajes . . . . . . . . . . . . . 60
6.3. Salida por consola de sistema de inteligencia (ejemplo 1) . . . . . . . . . . 61
6.4. Salida por consola de sistema de inteligencia (ejemplo 2) . . . . . . . . . . 62
6.5. Cálculo de la predicción de la acción siguiente . . . . . . . . . . . . . . . . 62
6.6. Luces del salón y cocina encendidas desde el entorno domótico (manual) . 63
6.7. Visualización del entorno domótico en la aplicación móvil . . . . . . . . . 63

xii
Índice de listados

5.1. Dispositivos compatibles y estructura de los topics . . . . . . . . . . . . . 38

5.2. Estructura fichero de configuración de clientes . . . . . . . . . . . . . . . . 43
5.3. Estructura fichero de configuración de clientes . . . . . . . . . . . . . . . . 44
5.4. Estructura código con librería Johnny-Five . . . . . . . . . . . . . . . . . . 44
5.5. Estructura importación módulo Broker en el servidor . . . . . . . . . . . . 46
5.6. Estructura de datos de un control . . . . . . . . . . . . . . . . . . . . . . . 46
5.7. Contenido fichero configuración para el empaquetado de la aplicación . . . 47
5.8. Llamada funcion del API Rest en la aplicación . . . . . . . . . . . . . . . . 50
5.9. Ejemplos registros que se almacenan en una colección de la base de datos en
Mongo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.10. Conexión con la base de datos desde el módulo de broker . . . . . . . . . . 51
5.11. Escritura de datos en la base de datos desde el módulo de broker . . . . . . 51
5.12. Lectura de datos en la base de datos desde el módulo de inteligencia . . . . 52
5.13. Datos del modelo del sistema para inteligencia artificial . . . . . . . . . . . 57
5.14. Datos del modelo del sistema para inteligencia artificial continuación . . . . 58
5.15. Estructura de datos de evento . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.16. Salida del sistema, con la predicción de acción futura del usuario . . . . . . 58

XIII
Listado de acrónimos

I OT Internet of Things

TFG Trabajo Fin de Grado

TIC Tecnologías de la Información y la Comunicación

IA Inteligencia Artificial

AAL Ambient Assisted Living

AMI Ambient Intelligence

JS JavaScript

HTML HyperText Markup Language

CSS Cascading Style Sheets

MQTT Message Queue Telemetry Transport

API Application Programming Interface

REST Representational State Transfer

NPM Node Package Manager

IDE Integrated Development Environment

USB Universal Serial Bus

M2M Machine to Machine

TCP Transmission Control Protocol

HTTP Hypertext Transfer Protocol

URL Uniform Resource Locator

ETS Engineering Tool Software

MVC Modelo Vista Controlador

HMM Hidden Markov Model

XIV
Capítulo 1

Introducción

E LInternet de las Cosas[Esp](I OT), se puede definir como una revolucionaria relación
entre objetos y personas y objetos con objetos que se conectan entre sí utilizando in-
ternet y que proporcionan datos en tiempo real.
El objetivo de este nuevo paradigma es que el entorno de un usuario esté conectado y pueda
ser útil y aprovechable. Un ejemplo típico del I OT es el ámbito del hogar (Domótica [dDeIC]),
donde se aprovecha por ejemplo, para medir parámetros externos (como la luz, energía,
actividad humana, etc.), sin necesidad de interacción humana para controlar el entorno de
manera inteligente. El otro gran ejemplo son las llamadas Smart Cities [Sei], que pueden
implementar redes de sensores a través de los semáforos, alumbrado, alcantarillado, etc.
De esta manera se pueden optimizar recursos a partir de la información recogida, como
por ejemplo la gestión del tráfico en un determinado cruce. Otro paradigma que se está
desarrollando es el llamado Ambient Assisted Living [NM15], orientado a prestar ayuda
a personas mayores utilizando entornos o sistemas inteligentes como smartphones u otros
accesorios inteligentes denominados wearables, como las pulseras inteligentes.
Estos sistemas AAL, tienen como finalidad facilitar la vida de las personas mayores, do-
tándoles de una mayor independencia debido a una menor supervisión de personal sociosa-
nitario.
En la Unión Europea1 y tres Estados Asociados2 más, se han impulsado medidas para la
investigación y desarrollo en el ámbito del AAL, con un Programa Conjunto que tiene por
título Vida cotidiana asistida por el entorno.
Este programa tiene como objetivos:

Mejorar la calidad de vida de las personas mayores a través de las TIC dotándoles de
autonomía y participación social.
Reforzar la base industrial de Europa mediante el uso de las TIC, creando un entorno
en que se favorezca la participación de las PYME (pequeñas y medianas empresas),
1
Estados miembros participantes: Austria, Bélgica, Chipre, Dinamarca, Finlandia, Francia, Alemania, Gre-
cia, Hungría, Irlanda, Italia, Luxemburgo, Países Bajos, Polonia, Portugal, Rumanía, Eslovenia, España, Suecia
y el Reino Unido
2
Israel, Noruega y Suiza

1
 dentro del programa.
Proporcionar un marco europeo donde se incluyan de manera común normas que per-
mitar desarrollar un enfoque conjunto, facilitando la localización y adaptación de so-
luciones comunes, para compatibilizar la variedad de sociedades y aspectos reglamen-
tarios tanto a nivel nacional como regional de la UE [Mad].

Debido a la necesidad de ayudar a mejorar la calidad de vida de estas personas mayores, se

empieza a pensar en soluciones técnicas e innovadoras para crear sistemas que puedan cubrir
dicha necesidad. Estas soluciones vienen determinadas en parte por el auge de las TIC y el
I OT. Actualmente ya no es necesario realizar grandes desembolsos en costes de desarrollo y
mantenimiento de soluciones informáticas que permitan entrar dentro de estos programas de
ayuda. Estos sistemas que son tanto software como hardware, se pueden empezara desarro-
llar a menor coste y en parte gracias a hitos tan importantes como la aparición del hardware
libre y de bajo coste. Este tipo de hardware ha supuesto un avance para que personas con
conocimientos mínimos en electrónica y programación pudieran desarrollar sus pequeños
proyectos de robótica. Además han surgido empresas y startups3 que han empezado a explo-
tar este tipo de hardware para sus productos. Se estudiarán las alternativas existentes a día de
hoy en el mercado, pero a continuación presentamos dos ejemplos de hardware de este tipo
que es susceptible de ser utilizado para el desarrollo del proyecto.

El primero es Arduino (ver Figura 1.1). Este hardware se basa en un microcontrolador

(inicialmente Atmel AVR) y puertos de entrada/salida. Se pueden conectar sensores y actua-
dores de todo tipo como sensores de luminosidad, zumbadores, leds, servos, etc. En estos
últimos años los microprocesadores han evolucionado ya que son muy utilizados en compu-
tación móvil. Este hardware de bajo coste, puede utilizarse en aplicaciones relacionadas con
la domótica como puede ser este proyecto, donde se pretende crear una plataforma de bajo
coste.

Figura 1.1: Placa Arduino Modelo UNO [Ard]

3
http://www.asociacionstartups.es/

2
 Otro tipo de hardware como la Raspberry Pi (ver Figura 1.2), ha conseguido ofrecer un
ordenador prácticamente completo de bajo coste (por unos 35 euros aproximadamente), con
una placa, procesador, memoria RAM, entradas y salidas, procesador gráfico, etc. En defini-
tiva es un ordenador con posibilidad de instalación de diversos sistemas operativos basados
en el núcleo Linux, que permite usarlo para múltiples aplicaciones.

Figura 1.2: Ordenador de bajo coste Raspberry Pi Modelo B [Foua]

Actualmente existen algunos ejemplos de proyectos de este tipo como Casa domótica con
Arduino y Android [Uba], Sistema control domótica Arduino [Ciu] o Prototipo de sistema de
domótica basado en Arduino [Gon]. En estos proyectos se ven diferentes formas de entender
estos sistemas e implementarlos.

En este proyecto nos centraremos en la unión de los paradigmas Internet de las Cosas
y AAL. Dada la necesidad del reconocimiento de acciones de personas mayores para po-
der ayudarlas, surge la idea de este proyecto, con el que se pretende desarrollar un sistema
domótico completo con capacidad para reconcer acciones mediante técnicas de inteligencia
artificial. Además debe tener un componente (teléfono móvil con una aplicación conectada
al sistema domótico por ejemplo) para poder monitorizar estos entornos por otras personas
como por ejemplo familiares.
Este sistema debería constar en primer lugar de diferentes circuitos domóticos con senso-
res y actuadores para determinados parámetros, creados con un hardware tipo Arduino.
Para el sistema domótico, se diseñará un protocolo domótico mediante el cuál, los com-
ponentes domóticos que se conecten al sistema se podrán comunicar entre sí, utilizando una
estructura de datos definida y que se pueda extender con facilidad. Este protocolo, podría im-
plementarse sobre algún protocolo de comunicaciones extendido en I OT, como por ejemplo,
MQTT.

Además se necesitará un ordenador central como Raspberry Pi donde residiará el software

del sistema que controla los sistemas domóticos y que dota al entorno de salida al exterior
(punto de acceso) mediante internet. Para ello se implementará un servidor web con el que
conectaremos una aplicación móvil cliente para el usuario, con la cual podrá ver que ocurre

3
en el entorno domótico y poder configurarlo e incluso realizar acciones a distancia, como
por ejemplo encendido de luces.
Se quiere dotar al sistema de inteligencia artificial, que permita realizar el reconocimiento
de acciones de los usuarios del sistema y de esta manera que el sistema se pueda anticipar a
ciertas acciones del usuario y poder brindar ayuda a éste, por ejemplo encendiendo una luz
de una habitación antes de llegar a ella.
En el siguiente diagrama (ver Figura 1.3) se puede ver como es la arquitectura a alto nivel
que define el sistema a desarrollar por este TFG. En el diagrama se pueden ver las distintas
tecnologías que se utilizan en cada parte del sistema (logotipos [Logd][Logc][Logf][Loga]
[mon][Nod][Mqt][Ras]). A lo largo del documento se verán las distintas partes del sistema,
como se han diseñado e implementado y que responsabilidades tienen en el sistema.

Figura 1.3: Arquitectura del sistema

4
Capítulo 2

Objetivos

E N este capítulo se describen los objetivos globales que han motivado al desarrollo de
este proyecto y los objetivos más específicos que se pretenden conseguir con él.

2.1 Objetivo General

El objetivo general de este proyecto es la creación de una plataforma para monitorizar y
controlar entornos inteligentes, usando hardware de bajo coste y en el contexto del paradigma
de AAL, para ayudar a la supervisión de personas mayores en su día a día reconociendo
acciones.
Además, debido a la utilización de hardware de bajo coste, será fácilmente accesible para
cualquier programador con conocimientos básicos de programación y electrónica. Será man-
tenible y escalable de manera que se puedan añadir más controles domóticos (actuadores y
sensores) funcionales de forma sencilla. Para ello se diseñará un protocolo domótico, a partir
de estándares de comunicación existentes, para este tipo de entornos.

2.2 Objetivos Específicos

Para llegar a conseguir el objetivo general del sistema, se necesitan conseguir objetivos
específicos que darán lugar al desarrollo de cada parte del sistema. Los objetivos específicos
se detallan a continuación.

2.2.1 Implementación de un servidor de comunicaciones

Esta parte del sistema es uno de los objetivos específicos fundamentales para la conse-
cución del objetivo general.Es el mecanismo mediante el cual, los controles y aplicaciones
de usuario que se implementen y que se conecten al sistema pueden intercambiar informa-
ción para entenderse entre sí y dotar al sistema de monitorización y control sobre dichos
controles.

2.2.2 Implementación servidor web

Se debe implementar un servidor web que dote a al sistema de accesibilidad desde cual-
quier lugar del mundo mediante internet. De esta manera, se puede saber qué está ocurriendo

5
en el entorno domótico y controlar el sistema desde un dispositivo móvil. Este servidor se
ejecutará en una máquina utilizando pocos recursos para mantener el bajo coste del hardware
y será el encargado de ejecutar el servicio de comunicaciones.

2.2.3 Desarrollo de aplicación móvil para usuarios

Dado que este sistema se pretende desarrollar para el control domótico de los hogares,
se implementará una aplicación móvil para los usuarios del sistema. Con esta aplicación,
podrán principalmente ver el estado del entorno inteligente y manejar los distintos controles
instalados. Además se podrá ver de manera gráfica e intuitiva cómo va cambiando el en-
torno. Se desarrollará para el sistema operativo Android por la facilidad de pruebas en este
entorno.

2.2.4 Implementación de un sistema de inteligencia

El sistema contará con un módulo de inteligencia artificial en el servidor, que será el encar-
gado de almacenar y explotar los datos que se generan en el entorno domótico. Este sistema
será el encargado de la predicción de acciones futuras en base a las acciones realizadas por
el usuario en el entorno. Estas predicciones servirán de ayuda para anticipar acciones al
usuario.

2.2.5 Validación del sistema

Para que todo el sistema se pueda probar y mostrar su funcionamiento será necesario
implementar un circuito que simule un entorno real con diferentes sensores y actuadores.
Este circuito debe ir conectado a la máquina donde corre el servidor de comunicaciones. Se
probará también la conexión entre la aplicación móvil y el resto del sistema.

El sistema ofrecerá:
Visualización de información de diferentes parámetros del entorno domótico.
Dar órdenes al control domótico para configurar y ejecutar acciones sobre los actua-
dores del sistema.
Comunicación entre el controlador domótico y los clientes conectados mediante un
protocolo, estándar, escalable y compatible con otros sistemas.
Reconocimiento de acciones o comportamientos de los usuarios del entorno inteligente
(personas mayores) y predicción de acciones futuras.

6
Capítulo 3

Antecedentes

E N este capítulo se presenta un estudio de los proyectos y tecnologías relacionadas y

que anteceden a la realización de este TFG. El sistema que se va a desarrollar tiene
diferentes partes, por lo que estudiaremos cada parte por separado.

3.1 Domótica
Se denomina domótica al conjunto de tecnologías aplicadas al control y automatización
de la vivienda, de manera inteligente, permitiendo la gestión eficiente del uso de energía,
aportando seguridad, confort y comunicación entre el sistema y el usuario [dDeIC].
Los sistemas domóticos recogen información del entorno mediante sensores o entradas,
para procesarlas y después dar órdenes en respuesta a esos estímulos. Estos sistemas han
evolucionado lo suficiente como para ser más utilizados y extendidos.

Figura 3.1: Ejemplo de entorno domótico[Viv]

A día de hoy estos sistemas aportan más funcionalidades y son más económicos, con más
variedad de productos y que se pueden instalar y usar de una forma más sencilla. Ejemplos
típicos de domótica pueden ser sistemas de control de iluminación, control de ventanas o de
temperatura.

7
 Los sistemas domóticos se basan en unos protocolos de comunicación [cvb], mediante los
cuáles se comunican los distintos dispositivos que componen el sistema. Los protocolos se
pueden clasificar en dos tipos:

Propietarios: También denominados cerrados, son específicos de alguna marca o fa-

bricante particular, de manera que solo el fabricante puede realizar mejoras y crear
dispositivos que entiendan este tipo de comunicación para su funcionamiento. La evo-
lución de estos protocolos está limitada a las expectativas del fabricante y puede no ir
en consonancia con la evolución de los sistemas domóticos. Además, depende de la
vida y política de la empresa del fabricante por lo que si esta desaparece el protocolo
queda descontinuado y los sistemas sin soporte.
Estándares: También denominados abiertos, son definidos por más de una compañía
o asociación de manera que se unen criterios y se da facilidad para que cualquier
fabricante pueda crear productos que entiendan este protocolo.

En la actualidad los protocolos estándares más extendidos son Lonworks [Cora], X10 [Autb]
y KNX [WEB].

Lonworks: Es una plataforma para control domótico que lleva integrado el protoco-
lo LonTalk [Corb]. Se utiliza para control de sistemas de diversas áreas como la in-
dustria, transportes, energía etc. Entre sus características están la interoperabilidad de
sus dispositivos independientemente del fabricante, el uso del estándar internacional
ISO/IEC-14908, diversos medios de transmisión como par trenzado o ethernet y desa-
rrollo continuado. Como punto negativo es la dificultad de manejo ya que hace que
algunos fabricantes creen software de programación y control para paliarla.
X10: Se desarrolló por Pico Electronics of Glenrothes, para control de dispositivos do-
mésticos y eléctricos, por lo que se considera la primera tecnología domótica, actual-
mente la más extendida. Utiliza como medio la red eléctrica convencional de 220V o
110V. Como puntos positivos tiene que está muy extendido y la facilidad de instalación
y de configuración. Se basa en asignación de direcciones a los dispositivos conectados
(máximo 256) y envío de órdenes básicas como ON, OFF, DIM, BRIGHT ... También
tiene puntos negativos como la fiabilidad por las interferencias de los ruidos en la se-
ñal eléctrica, uni-direccional y órdenes básicas no permitiendo funciones lógicas más
complejas.
KNX: Es una tecnología fruto de la unión de los protocolos domóticos EHS, EIB y
Batibus como estándar internacional bajo el nombre de KNX. Esta tecnología está am-
parada por la KNX Association. Como puntos positivos podemos destacar la múltiple
y libre elección de fabricantes KNX, estándar internacional ISO/IEC 14543-3, entorno
de diseño, implementación y configuración para productos certificados KNX único

8
 (ETS), diversidad de medios de transmisión y desarrollo continuado. Cómo puntos dé-
biles o negativos están la seguridad, la dificultad de su uso y el elevado coste.

3.1.1 Evolución de la tecnología

Gracias al hardware libre y de bajo coste que se está extendiendo últimamente es posible
crear entornos domóticos con poca inversión. Este hardware como Arduino y Raspberry Pi,
tienen la ventaja que son pequeños, tienen bajo coste y son fácilmente programables de ma-
nera que con ciertos conocimientos de electrónica y programación es posible crear pequeños
sistemas domóticos que pueden funcionar perfectamente en nuestro hogar. Además, puede
dar lugar a sistemas más complejos y de una utilización más exhaustiva.
En nuestro TFG, la domótica influye de manera que nuestro sistema, contará con una parte
domótica de control de iluminación mediante, sensores de luminosidad, presencia e interrup-
tores para facilitar la ayuda a personas mayores, aunque esto se explicará más adelante.
En la actualidad existen algunos proyectos de hardware de bajo coste para prototipado.
Gracias a este hardware se pueden realizar prototipos de cualquier tipo por un bajo coste,
ya que además cuentan con gran cantidad de componentes como actuadores y sensores con
precios muy bajos y de fácil uso. Se muestra una tabla comparativa de los dispositivos más
representativos de este tipo de hardware (ver Cuadro 3.1).
Los ejemplos de este tipo de hardware como Arduino y Raspberry Pi son los mejor po-
sicionados para la elección por su facilidad de uso y de conseguirlos además de la enorme
comunidad que hay detrás de estos dos proyectos.

Arduino
Es un proyecto de hardware libre1 en forma de plataforma con hardware y software com-
puesta por una placa de circuito impreso y un entorno de desarrollo (IDE). En nuestro sistema
puede encajar para el desarrollo del circuito, que simulará el entorno domótico (hogar de per-
sonas mayores).

Raspberry Pi
Este hardware es un pequeño computador completo que puede ejecutar diferentes sistemas
operativos. Gracias a su interfaz de red y sus puertos de entrada salida USB, será el encargado
de ejecutar el servidor web y el controlador domótico. Los controles domóticos se contec-
tarán por puerto serie a este computador. Mediante la conexión a internet y el servidor web,
será el punto de acceso al entorno domótico mediante internet.
Podemos encontrar numerosos tipos de sensores y actuadores (ver Figura 3.2), para casi
cualquier cosa que podamos imaginar a la hora de prototipar. Hay desde sensores tan básicos
1
Dispositivos de hardware de los que se liberan y hacen públicos sus especificaciones y esquemas, de
manera gratuita o de pago.

9
Nombre Precio (Euros) Características principales
Microcontrolador Atmega328,
2KB SRAM, 1KB EEPROM,
Arduino UNO 20
32KB Flash, e/s digitales
y analógicas, usb
ARM 1176JZF-S, 512MB RAM,
Raspberry Pi Model B 35 e/s digitales y analógicas, usb,
ethernet, hdmi, tarjeta sd
ARM Cortex A9 Exynos 4412,
NanoPC-T1 60 1GB RAM DDR3, 8GB Flash,
usb, hdmi, ethernet, tarjeta sd
ARM Cortex A8, GPU PowerVR
SGX530, SD/MMC, USB,
BeagleBone 84,90 RS-232, 256MB RAM, 256MB
Flash, usb, dvi, svideo, sd/mmc,
rs232
ARM Cortex A15 y A7, 2GB
LPDDR3, 16GB eMMC, wifi,
Samsung Artik 135
bluetooth, usb, e/s digitales
y análogicas
ARM Cortex A7 dualcore, 1GB RAM
Banana Pi 53,35 DDR3, GPU ARM Mali 400, usb,
hdmi, ethernet, tarjeta sd
Cuadro 3.1: Tabla comparativa hardware bajo coste

10
como un detector de luminosidad hasta sensores de ritmo cardíaco o infrarrojos. Actuadores
también podemos tener desde un simple led hasta servo motores o emisores de láser.

Figura 3.2: Kit de sensores y actuadores para Arduino[Ama]

Hay numerosos ejemplos de prototipos creados con este tipo de hardware pequeños y
sencillos como el típico prototipo que enciende una luz mediante un pulsador (ver Figura 3.3)
o más complejos como un tetris (ver Figura 3.4).

Figura 3.3: Control de un led mediante pulsador con arduino[FM]

11
 Figura 3.4: Tetris con Arduino[OG]

3.1.2 Domótica de bajo coste

En esta sección presentaremos alguno de los trabajos que nos han inspirado para hacer
este TFG, qué características tienen y en qué nos hemos fijado para que el sistema aporte
valor y sea más completo.
A continuación mostramos algunos trabajos que están relacionados con la parte domótica
del sistema:

Casa domótica con Arduino y Android

Este trabajo[Uba] utiliza una placa Arduino para el montaje del circuito y una aplicación
móvil Android para su control y monitorización. Utilizan un módulo wifi conectado al Ar-
duino para comunicar la aplicación móvil con él. El resto del sistema son controles de una
casa de diferentes tipos como control de luces, toldos, persianas etc.
Este sistema (ver Figura 3.5), está enfocado a un puro control domótico utilizando elemen-
tos como transformadores de corriente para el manejo de elementos de la casa como toldos,
persianas y luces. Utilizan un módulo para dotar al sistema de conexión hacia el exterior y
cada control se debe programar específicamente.
Utiliza una placa Arduino por cada circuito de control para un elemento dado (por ejemplo,
control de una persiana). Esta placa lleva el módulo Wifly RN-XV para la comunicación con
la aplicación Android y utilizan el protocolo I2C2 cómo protocolo de comunicaciones para
los controles.
Nuestro sistema pretende aportar una mayor escalabilidad y mantenibilidad, pues solo
queremos tener conectado cada circuito con Arduino al homebase del sistema, utilizando un
protocolo de comunicaciones más versátil y teniendo acceso desde el exterior de las aplica-
2
http://www.i2c-bus.org/i2c-bus/

12
 Figura 3.5: Esquema de arquitectura Casa domótica con Arduino y Android

ciones móviles clientes. No necesitamos módulos adicionales a la placa Arduino como en

este caso.

Sistema control domótica Arduino

En este sistema [Ciu], por lo que se ha podido investigar3 es el más completo de los tres
pues además de contar con todos los elementos que pueden tener los anteriores, si que se
extiende a más tipos de controles. También dispone de aplicación móvil para el control y
supervisión del entorno para sistema operativo Android.

Prototipo de sistema de domótica basado en Arduino

Este proyecto [Gon] se centra más en controlar una un entorno domótico real (ver Figu-
ra 3.6) pero acotado quizá a una habitación por ejemplo, en cuanto a temperatura, humedad
e iluminación. En este caso se incluyen elementos para poder utilizar el sistema en una ins-
talación más real y está pensado para automatizar acciones del entorno domótico y que los
habitantes no se tengan que preocupar de cuando encender o no luces o ventiladores. No
dispone de aplicación mediante la cuál controlar o cambiar parámetros de configuración.
3
Es un proyecto que busca financiación y sólo hemos podido analizarlo con los datos que y las explicaciones
que dan en la web

13
 Figura 3.6: Esquema sistema Prototipo de sistema de domótica basado en Arduino

Resumen
Analizando los trabajos previos, se puede apreciar que el denominador común es un siste-
ma de control domótico tradicional, utilizando hardware de bajo coste como placas Arduino
y una aplicación móvil para la supervisión y control del entorno. Además llevan programa-
ción típica con el entorno de desarrollo de Arduino y no utilizan protocolos de comunicación
basados en I OT.
EL sistema que se va a implementar con este TFG pretende evolucionar y mejorar en el
apartado de comunicaciones de los distintos elementos del sistema domótico, haciendo que
se puedan incorporar nuevos controles de una manera sencilla, escalable y mantenible. Para
ello se utilizará una arquitectura basada en un centro de control al que se le irán conectando
los demás controles y cuya comunicación será mediante un protocolo adaptado al internet
de las cosas.
Uno de los sistemas introduce una variable importante que es el control por voz para
ayudar a personas con discapacidad pero puede que no recuerde todos los comandos. Por
ello, este TFG, también incorporará un sistema de inteligencia, el cuál reconocerá acciones
de los usuarios del entorno domótico. De esta manera, se puede detectar por ejemplo cuando
una persona se ha ido a dormir y se deben apagar luces.
Además de estas mejoras, se pretende que el sistema esté desarrollado con un mismo
stack tecnológico basado en tecnologías y lenguajes web para que el sistema sea multiplata-
forma.

14
3.2 Ambient Intelligence (AMI) y Ambient Assisted Living (AAL)
Existen diferentes paradigmas de la inteligencia artificial dependiendo del entorno de apli-
cación. La Inteligencia Ambiental (AMI) [yDLdIGdA], es un paradigma que intenta conse-
guir los siguientes propósitos:

Mejorar la comunicación entre los objetos de los entornos inteligentes y el hombre,

para que sea lo más natural posible y conseguir que el usuario no pierda demasiado
tiempo en elegir las preferencias.
Conseguir que el usuario no esté pendiente de la presencia del sistema, para conseguir
una integración en su entorno completa.
Explorar nuevas formas de interacción persona-computador en el día a día de las per-
sonas en entornos cotidianos.

El AAL, es un paradigma muy relacionado con AMI, pero se diferencian en que el AAL,
se centra en la ayuda de personas de tercera edad. Ambos intentan crear un entorno donde
la tecnología esté siempre presente e integrada pero de manera invisible para el usuario.
Además, el uso debe simplificarse tanto que parezca que es el propio entorno de manera que
el sistema casi se autogestiona.
Los dispositivos tecnológicos que utilizamos hoy en día, están repletos de sensores y pue-
den captar gran volumen de información del usuario y del entorno. Como se hablará en el
siguiente apartado, la domótica (dispositivos inteligentes en el hogar) también juega un papel
importante en estos paradigmas y por ello será parte importante del sistema que se desarro-
llará en este TFG.
Una manera de aplicar este sistema a AAL podría ser con el siguiente escenario:
«Antonio es una persona mayor de 80 años que antes de acostarse, apaga la tele y va al
baño encendiendo y apagando dos luces en el pasillo. Una vez termina de lavarse los dientes
se acuesta.»
El sistema podría reconocer este comportamiento que en Antonio es habitual, y podría ir
encendiendo y apagando luces anticipándose a las acciones de Antonio, y cuando Antonio
esté en la cama además pondría el modo silencio en el teléfono y bajaría las persianas para
que no le molestase la luz del sol al amanecer.
Este es un caso de uso de ejemplo para ilustrar como este TFG aporta valor y hace uso de
la IA para la ayuda de personas de avanzada edad en una estrecha relación con el sistema
domótico.

3.3 Sistemas inteligentes

La inteligencia artificial (IA), se puede definir como un área multidisciplinar, que me-
diante las ciencias de computación, matemáticas, lógica y filosofía estudia como diseñar y

15
crear sistemas que puedan resolver problemas por sí mismos imitando la inteligencia huma-
na [RII].
A día de hoy, en países desarrollados, la sociedad está bastante familiarizada con nume-
rosos dispositivos tecnológicos y cada vez más con sistemas que les ayudan en el día a día,
tanto en tareas de la vida cotidiana como en tareas profesionales.
Muchos de estos sistemas, son denominados Sistemas Inteligentes[Sis], por lo que defini-
remos sistema inteligente como:
Un programa informático que consta de características y comportamientos parecidos a
la inteligencia humana, de manera que es capaz de decidir por sí mismo, que tareas de-
berá realizar para alcanzar una serie de objetivos mediante su percepción, conocimiento y
experiencia
El sistema inteligente (ver Figura 3.7) debe estar en un entorno donde actuar y poder sentir
para recibir comunicación del dicho entorno y transmitir información. Estos sistemas están
funcionando constantemente de manera que van almacenando todas las acciones gracias a la
memoria que tienen. Gracias a los datos almacenados, va aprendiendo con el tiempo de su
experiencia lo que hace que sus respuestas ante los objetivos para los que está diseñado sean
mejores aumentando su rendimiento.
Un sistema inteligente será completo si cumple los siguientes requisitos (capacidades):

Inteligencia: Nivel que tiene el sistema para lograr su objetivo.

Sistematización: Un sistema tiene extensión limitada en espacio y tiempo, por lo que
las partes del sistema tienden a tener más correlación con otras partes del sistema que
con partes que no son del sistema.
Capacidad sensorial: El sistema inteligente debe poder recibir información, conocer
el entorno en que está e interactuar en él.
Objetivo: Es la finalidad para la que el sistema inteligente ha sido ideado.
Conceptualización: Un concepto representa un pensamiento o idea, sirviendo además
como almacenamiento físico de la información. Todos los conceptos almacenados en
la memoria están relacionados.
Memoria: Es donde se almacena la información (conceptos y reglas de actuación).
Representa la experiencia del sistema.
Reglas de actuación: Son resultado de la experiencia del sistema relacionando situa-
ción y consecuencia.
Aprendizaje: Capacidad del sistema de aprender nuevos conceptos a partir de la infor-
mación que recibe del entorno.

16
 Figura 3.7: Representación gráfica de un sistema inteligente[Fri]

Para que el sistema sea inteligente y se pueda aprovechar toda la información que se genera
y el sistema almacena, se debe procesar dicha información. Uno de los objetivos de este
TFG es la búsqueda de patrones de comportamiento de los usuarios del sistema (personas
mayores) dentro de su hogar, de manera que se pueda hacer un uso más eficiente de la
energía y a la vez, aplicando el paradigma de AAL, podamos detectar escenarios anómalos y
ayudar a las personas de avanzada edad.
El sistema debe ir aprendiendo y para ello se utilizan técnicas de Machine Learning o
Aprendizaje Automático. El Aprendizaje Automático [Apr]es una parte de la IA, que desarro-
lla técnicas para que los computadores puedan aprender de manera que generalicen compor-
tamientos a partir de información no estructurada.
El aprendizaje automático da como resultado modelos que resuelven una problemática es-
tablecida y estos modelos pueden ser de los siguientes tipos: modelos geométricos, modelos
probabilísticos y modelos lógicos.
Hay diferentes algoritmos de aprendizaje automático y estos se clasifican según la salida
de los mismos. Los tipos son: aprendizaje supervisado, aprendizaje no supervisado, aprendi-
zaje semisupervisado, aprendizaje por refuerzo y aprendizaje multi-tarea.
Para el sistema que se pretende crear, son interesantes los algoritmos de tipo supervisado,
los cuales se caracterizan por la correspondencia entre la salida y la entrada del sistema que
establece la función producida. Su espacio de aplicación es en problemas de clasificación,
donde dada una entrada se deben etiquetar o clasificar en función de varias clases definidas.
Para establecer la base de conocimiento y entrenar al sistema, se utilizan ejemplos de datos
etiquetados previamente.

17
 Las redes bayesianas son modelos que representan conjuntos de variables aleatorias y la
dependencia condicional que existe entre ellas mediante grafos dirigidos acíclicos [Red].
Se puede dar una definción más formal[Rei] diciendo que una red bayesiana o red de
Bayes4 , es un grafo dirigido acíclico (ver Figura 3.8) que se compone de:

Conjunto de nodos, donde cada nodo representa una variable del mundo.
Conjunto de arcos que conectan los nodos, donde si un arco va deX a Y, quiere decir
que X es un padre de Y (padres(X) denota el conjunto de variables que son padres de
X).
Cada nodo Xi , contiene la distribución de probabilidad P (Xi |padres(Xi )).

Figura 3.8: Ejemplo gráfico de una red bayesiana[Wik]

Las Cadenas de Markov (o Modelos de Markov) [CM], son un tipo de proceso estocásti-
co en el que la probabilidad de que ocurra un cierto suceso depende exclusivamente de un
suceso anterior. Se dice que un proceso es estocástico cuando en un conjunto de observacio-
nes, los valores de las observaciones no se pueden predecir pero si se puede determinar la
probabilidad de que ocurran.
Las cadenas de Markov representan secuencias de variables aleatorias dependientes entre
si. Por ejemplo en esta cadena que representa los estados del tiempo (ver Figura 3.9), se ve
como la variable aleatoria que sería el tiempo, puede tener una serie de estados como son
soleado, nublado o lluvioso. Los arcos de este grafo representa la probabilidad que hay de
pasar de un estado a otro. El hecho de que un estado en un determinado momento dependa
exclusivamente del anterior es lo que se conoce como propiedad de Markov.
Un caso particular son los Modelos Ocultos de Markov [dCeIdlCPUJC] o HMM. En una
cadena de Markov las señales que se observan corresponden a los estados por los que pasa
un determinado modelo mientras que en los HMM no se conoce dicha secuencia de estados
sino un conjunto de observaciones por cada estado que sí son observables.
Un ejemplo de uso de estos modelos, sería el caso en el que tengamos tres urnas (tapadas
para que no las vea el espectador) con bolas de colores (rojo, azul y verde) con una deter-
4
https://bayesian.org/

18
 Figura 3.9: Ilustración grafo probabilidades de una Cadena de Markov

minada función de probabilidad de sacarlas en cada urna. Para calcular la probabilidad de

que salga una secuencia determinada de bolas podemos modelar el sistema como un mo-
delo oculto ya que no sabemos (no podemos observar) de qué urna sale cada bola. En este
caso las urnas se pueden representar como estados ocultos y las bolas que salen como las
observaciones.
Formalmente un Modelo oculto de Markov sería la siguiente tupla M = {S, Σ, A, B, Π}
donde:

S es un conjunto estados finito.

Σ es un conjunto de símbolos observables por cada estado.
A es una matriz de distribución de probabilidad de transición entre estados.
B es una matriz de distribución de probabilidad de observación de un símbolo en cada
estado.
Π Es un vector de distribución de probabilidad de estados inicial.

y se denota una secuencia de estados X = (X1 , ..., Xt+1 ) donde Xt : S −→ {1, ..., N } y
una secuencia de observaciones O = (o1 , ..., oT ) con oT ∈ Σ.
Los HMM resuelven tres problemas fundamentalmente que son:
Evaluación: Dado un modelo y un conjunto de observaciones, calcular la probabilidad
de dicho conjunto. Se calcula con el algoritmo de forward-backward.
Encontrar la secuencia de estados que dado un modelo y una secuencia de observacio-
nes mejor explique ésta última. Se puede hallar mediante el algoritmo de Viterbi.
Entrenamiento: Encontar los parámetros óptimos para un modelo dada una secuencia
de observaciones. Para ello se utiliza el algoritmo de Baum-Welch.

19
 En este TFG utilizaremos los HMM para modelar el comportamiento de los usuarios dentro
del entorno domótico y poder predecir acciones futuras teniendo en cuenta los dos primeros
problemas que resuelven los HMM.

3.4 Dispositivos móviles

Las TIC han evolucionado mucho en estos últimos años, ha coincidido también en el tiem-
po el auge de las tecnologías web y móvil por lo que estamos en un escenario donde la
sociedad está en contacto, en mayor o menor medida con estas tecnologías.
Gracias a los dispositivos móviles (ver Figura 3.10) las personas están cada vez más co-
nectadas con el entorno. Estos dispositivos contienen gran cantidad de sensores y una gran
capacidad de computación de manera que con ellos podemos determinar muchos aspectos de
nuestra vida como, dónde estamos, cómo nos movemos, qué buscamos, ¿estamos en espacios
abiertos o cerrados?, etc.

Figura 3.10: Dispositivo LG G4[Ele]

Estos dispositivos se han convertido en una extensión de las personas, pues se delega partes
de nuestras vidas e información a estos dispositivos, a modo de asistente personal. Estamos
conectados a internet prácticamente todo el día y podemos obtener información de cualquier
cosa, cuándo, dónde y cómo queramos.
Su uso en domótica también se ha visto incrementado ya que podemos controlar y moni-
torizar nuestro hogar desde cualquier punto del plante, solamente utilizando una conexión a
internet y una aplicación móvil. En este TFG, el dispositivo móvil tiene un papel importante
pues servirá para el control del entorno domótico y para ver que ocurre sin tener que estar
fisicamente en él. Además, puede ser muy útil para la supervisión de personas mayores en
estos entornos, pues podemos saber si la persona hace una vida normal atendiendo a sus
acciones y por qué zonas del entorno está interactuando, sin pertubar su intimidad en ningún
momento. Podemos llegar a saber si hay alguna anomlía si por ejemplo se está haciendo de

20
noche y no enciende la luz de la cocina, donde habitualmente hace la cena a una determinada
hora.
Este auge en este ámbito de la tecnología y su enorme uso, ha propiciado que cada vez
haya más aplicaciones móviles, más completas, mejor optimizadas, con más funcionalidad
y en definitiva tengamos más opciones para diversificar las acciones que hacemos con un
dispositivo como puede ser un smartphone. También esto desencadena la aparición de cada
vez más herramientas para facilitar el desarrollo de aplicaciones móviles y que cada vez más
gente se dedique a ello y sea más fácil acceder a este tipo de software.
Aunque los fabricantes de los principales sistemas operativos móviles liberan sus entornos
de desarrollo y a día de hoy publicar una aplicación en las tiendas de aplicaciones no es muy
costoso ni complicado, se pueden encontrar frameworks para el desarrollo de aplicaciones
móviles basadas en aplicaciones web embebidas. Esto hace que las aplicaciones se desarro-
llen para más plafatormas de una manera más rápida y fácil y no sea necesario conocimientos
muy profundos de las plataformas nativas.
En este TFG, haremos uso de estos nuevos frameworks y paradigmas de desarrollo móvil,
para el desarrollo de la aplicación web de la plataforma. La elección de estos frameworks
tiene que ver con uno de los objetivos del proyecto, ser de bajo coste.

21
Capítulo 4

Método y Fases de Trabajo

E N este capítulo describiremos el método de trabajo utilizado para la realización de este

proyecto. En particular para este desarrollo se ha utilizado una de las llamadas meto-
dologías ágiles [RdlHdD12].
Las metodologías ágiles son una serie de técnicas para la gestión de proyectos que surgie-
ron como contraposición a las metodologías de gestión clásicas. Con estas metodologías se
minimiza el impacto de las tareas que no son imprescindibles para llegar a la consecución
del proyecto, aumentando la eficiencia de las personas implicadas y reduciendo el coste.
Las metodologías clásicas son menos efectivas en proyectos donde los requisitos y el
entorno es susceptible a cambios. Con las metodologías ágiles, ya se contempla este tipo de
cambios, ofreciendo una mejor respuesta que las metodologías clásicas. Nos podemos hacer
la pregunta de que si las metodologías ágiles son mejores que las clásicas o viceversa y la
respuesta es que no, como en otros aspectos de la vida, depende del tipo de proyecto en el
que se vayan a aplicar.
Para considerar que una metodología es ágil deben cumplir «El Manifiesto Ágil» [BoK]:

Los individuos y su interacción por encima de los procesos y las herramientas.

El software que funciona mejor que la documentación exhaustiva.
La colaboración con el cliente por encima de la negociación contractual.
La respuesta al cambio por encima del seguimiento de un plan.

Algunas de las metodologías ágiles más utilizadas son las siguientes:

SCRUM [pro]. Entorno de trabajo que proporciona herramientas y roles para, de ma-
nera iterativa, llegar a obtener resultados de un proyecto.
XP [ext]. Metodología centrada en potenciar las relaciones interpersonales para llegar
al éxito en desarrollo de software, promoviendo el trabajo en equipo.
KANBAN [Gar]. Basada en una idea muy simple, que el trabajo en curso debe acotarse
y dividirse de manera que hasta que un bloque de trabajo no está terminado no se
continúa con el siguiente.

22
 Para el desarrollo de este proyecto, por la naturaleza del mismo, el número de personas
que formarían el equipo de desarrollo y el número de desarrolladores, se ha optado por elegir
Scrum.

4.1 SCRUM
Esta metodología sigue la estrategia de desarrollo iterativo e incremental. Se van defi-
niendo bloques que se llevan a cabo en cada iteración o «Sprint», generando una versión
del producto que aporta valor al cliente. Se muestra este producto al cliente al final de ca-
da sprint para que se pueda refinar y tomar decisiones sobre posibles modificaciones para
futuras iteraciones.
Las características más representativas son:

Gestión de las expectativas de los clientes.

Resultados tempranos.
Flexibilidad y adaptación.
Retorno de la inversión (valor).
Mitigación de riesgos.
Productividad y calidad.
Motivación del equipo de desarrollo.

Existen diferentes maneras de implementar los sistemas para gestionar el proceso Scrum,
como tablones con «post-it», pizarras o soluciones software como «Trello».

4.1.1 Roles
En esta metodología se definen una serie de roles que deben formalizarse y cada cual tiene
su cometido en el proceso. Estos roles son:

Product Owner o dueño del producto, la persona autorizada para definir el conocimien-
to funcional del proyecto. Representa al cliente, usuarios del software y en definitiva
a todas las partes implicadas en el producto. Entre sus funciones están las de canalizar
la lógica de negocio y transmitirlas al equipo en objetos de valor para el producto,
revisar el producto para ir mejorando las funcionalidades y aportar mayor valor al ne-
gocio. En este proyecto serían los directores María José Santofimia Romero y Félix
Jesús Villanueva Molina.
Scrum Master, lejos de ser el líder del equipo, es el facilitador que protege al equipo y
vela por que se apliquen los principios ágiles del Scrum. Debe incentivar y motivar al
equipo, resolver conflictos que bloqueen el progreso del proyecto, ayudar al equipo y
hacer prevalecer la separación entre el equipo y el resto de participantes del proyecto.

23
 En este proyecto serían los directores María José Santofimia Romero y Félix Jesús
Villanueva Molina.
Scrum Team, es el equipo de desarrolladores propiamente dicho. Son personas técnicas
cualificadas que llevan a cabo el desarrollo de software del producto. En este proyecto
sería el autor del proyecto Cristian Vozmediano García

También existe otro tipo de roles auxiliares que se denominan «Stakeholders» que suelen
ser clientes, proveedores y demás personas que hacen posible el proyecto y para los que este
proyecto les repercutirá con algún beneficio, el cuál justifica su desarrollo.

4.1.2 Fases
Esta metodología se desarrolla en tres fases (ver figura 4.1) que describimos a continua-
ción:

Figura 4.1: Fases de la metodología Scrum

Pre-Game. En esta fase se desarrolla la planificación, donde se presenta al equipo el

«Product Backlog», lista de requisitos y funcionalidades que debe desarrollarse para
el proyecto por orden de prioridad. Después, se lleva a cabo el plan para implementar
los requisitos teniendo en cuenta las posibles dependencias entre ellas y la definición
de la arquitectura del sistema a alto nivel.
Game. En esta fase se llevan a cabo los «Sprints»(ver figura 4.2) de desarrollo. La
duración de cada sprint es determinada por el equipo y suelen variar entre dos y cuatro
semanas normalmente. En cada sprint o iteración, se lleva a cabo el desarrollo de
nuevas funcionalidades para tener una versión que aporte valor al cliente. Dentro de
los sprints se hace una realimentación debido a ceremonias como las «Dailys»1 .
1
Reuniones diarias normalmente a primera hora para analizar el progreso del día anterior

24
 Post-Game. Una vez se termina el desarrollo del sprint, se presenta el producto con
su documentación y pruebas al cliente y se analizan las funcionalidades desarrolla-
das. Esto se hace en el «Sprint Review», donde el cliente también puede pedir que se
realicen cambios o modificaciones, que se planificarán para futuros sprints.

Figura 4.2: Fases de un ciclo de sprint[Auta]

4.1.3 Metodología Scrum aplicada a este proyecto

A continuación describiremos las fases de scrum aplicadas a la realización de este proyec-
to.
En primer lugar, en la fase pre-game se acordó con el Product Owner cuáles eran las nece-
sidades y las características que debía tener el producto a desarrollar y el objetivo del mismo.
Se debía construir una plataforma para la monitorización y control de sistemas inteligentes,
minimizando los costes, siendo escalable para poder añadir más controles de manera sencilla.
Además debía servir para ayudar en el día a día de personas ancianas gracias precisamente
a la monitorización y el control de dichos sistemas inteligentes, como puede ser un entorno
domótico. Por lo tanto se definió el Backlog de la siguiente manera:

Análisis y estudio del estado del arte.

Análisis de las tecnologías de desarrollo para el desarrollo del sistema.
Estudio del protocolo de comunicación para los sistemas.
Desarrollo servidor de protocolo de comunicación.
Montaje circuitos de los sistemas sensores y actuadores.
Desarrollo servidor web para la conexión del sistema con el exterior.
Desarrollo aplicación móvil para los usuarios.
Implementación módulo de inteligencia.
Montaje de servidores y tareas de construcción, despliegue y mantenimiento del siste-
ma.

25
 Después en la fase de game se llevaron a cabo los sprints para el desarrollo del sistema,
desarrollando cada parte en orden de prioridad del Backlog.

Sprint 1: Análisis y estudio del estado del arte

Planificación: Analizar y realizar un estado del arte para decidir como será el sistema.
Análisis de requisitos: Debe ser un sistema que cumpla el objetivo del proyecto tenien-
do en cuenta que servirá de prototipo para sistemas futuros.
Diseño: Se estudian los proyectos y trabajos existentes, mirando que cosas se pueden
mejorar y aportar con este sistema.
Implementación: Se realiza «Brainstorming» una vez analizado el estado del arte y se
definen las partes de las que estará formado el sistema (arquitectura).
Pruebas: Se comprueba que la arquitectura del sistema abarca y aporta la funcionali-
dad requerida.

Sprint 2: Análisis de las tecnologías de desarrollo para el desarrollo del sistema

Planificación: Se analizan las tecnologías de desarrollo del estado del arte y otras que
pueden encajar para el desarrollo del sistema.
Análisis de requisitos: Las tecnologías deben ser conocidas por el desarrollador para
que el desarrollo sea más rápido y eficiente y que permitan la implementación del
sistema teniendo en cuenta el ámbito de aplicación de cada una de ellas y del sistema
que se va a desarrollar.
Diseño: Se muestra algunas tablas comparativas.
Implementación: Se realiza una comparativa de las tecnologías.
Pruebas: Se comprueba que las tecnologías escogidas son las idóneas para llevar a
cabo la implementación del sistema.

Sprint 3: Estudio del protocolo de comunicación para los sistemas

Planificación: Se deben estudiar los protocolos de comunicación que existen y que son
susceptibles a ser elegidos.
Análisis de requisitos: El protocolo debe ser estándar y que no sea compleja su imple-
mentación.
Diseño: Se crean diagramas de los protocolos estudiados para entender su funciona-
miento.
Implementación: Se diseña el flujo de comunicación que tendrá el protocolo.
Pruebas: Se verifica que el protocolo elegido puede implementar todo el flujo de co-
municación del sistema.

26
Sprint 4: Desarrollo servidor de protocolo de comunicación
Planificación: Se tiene que implementar el servidor de comunicaciones.
Análisis de requisitos: El servidor de comunicaciones, debe ser escalable, de manera
que sea relativamente sencillo suscribir más controles.
Diseño: Se realizan diagramas, para el mejor entendimiento del flujo de eventos que
se darán en la comunicación de los clientes con el servidor.
Implementación: Utilizando una librería externa que implementa MQTT, implementa-
mos el protocolo domótico sobre MQTT (que es utilizado para distribuir la informa-
ción).
Pruebas: Se verifica que el protocolo funciona y que la comunicación entre los ele-
mentos del sistema es correcta.

Sprint 5: Montaje circuitos de los sistemas sensores y actuadores

Planificación: Se debe montar el circuito utilizando dos placas Arduino e implementar
los programas de control de cada placa. Para ello se utiliza lenguaje JS y una librería de
terceros para poder ejecutar código de este lenguaje en las placas. A parte del programa
de control, también implementan clientes MQTT con otra librería de terceros.
Análisis de requisitos: El circuito será una representación básica de una casa con dos
puntos de luz, un sensor de presencia y otro de luminosidad y dos interruptores.
Diseño: Se crea un diagrama con el esquema de montaje del circuito y diagrama de
secuencia del funcionamiento del mismo.
Implementación: Se monta el circuito y se desarrollan los programas de control.
Pruebas: Se verifica que el circuito funciona correctamente.

Sprint 6: Desarrollo servidor web para la conexión del sistema con el exterior
Planificación: Consta de dos tareas principalmente, implementar el API REST y asociar
cada una de las llamadas con el servidor de comunicaciones.
Análisis de requisitos: El servidor debe exponer un API, para recibir y mandar datos
con las aplicaciones clientes y servir de punto de entrada/salida del servidor de comu-
nicaciones.
Diseño: Se realiza esquema de funcionamiento.
Implementación: Se desarrolla el servidor con JS y «Nodejs».
Pruebas: Se verifica mediante llamadas a la API que el servidor funciona correctamen-
te.

27
Sprint 7: Desarrollo aplicación móvil para los usuarios
Planificación: Se plantea las diferentes partes que hay que desarrollar para la aplica-
ción móvil y se dividen las tareas en consecuencia. La aplicación consta de tres vistas
principales por lo que las tareas de desarrollo se dividió en cada una de las vistas y
además otra para la implementación de las llamadas al API.
Análisis de requisitos: La aplicación debe mostrar una vista con la información del
sistema global y otra con cada uno de los sistemas de control conectados, además de
poder controlarlos desde la misma vista. Y la tercera vista debe ser para la simulación
del funcionamiento del sistema.
Diseño: Se crea un esquema de como debe ser la aplicación a nivel de interfaz de
usuario.
Implementación: Se desarrolla una aplicación web con HTML, JS y CSS. Después se
monta sobre un contenedor mediante librería de terceros «Apache Cordova» para su
instalación y ejecución en los dispositivos móviles Android.
Pruebas: Se verifica que la aplicación se puede ejecutar en Android y que el funcio-
namiento y la información de las vistas es el correcto.

Sprint 8: Implementación módulo de inteligencia

Planificación: Implementación de un módulo de inteligencia con algoritmos de inteli-
gencia artificial para el análisis y explotación de datos y predicción de acciones.
Análisis de requisitos: El módulo debe recoger los datos de la base de datos y explo-
tarlos haciendo los procesados necesarios además realizar la predicción de posibles
acciones futuras a realizar por el usuario.
Diseño: Se realiza diagrama del funcionamiento del módulo para su mejor entendi-
miento.
Implementación: Se implementa el módulo mediante lenguaje JS. Se implementa un
módulo usando diferentes funciones para ir procesando los datos de manera que se
pueda después ejecutar un algoritmo para la predicción de acciones futuras utilizando
un HMM a través de una librería llamada Node HMM.
Pruebas: Se valida que el sistema recoge la información, la procesa y se obtienen
predicciones en base a dicha información.

Sprint 9: Montaje de servidores y tareas de construcción, despliegue del sistema y me-

joras
Planificación: Para que la construcción del sistema sea lo más adaptable posible y se
pueda hacer de manera sencilla, se deben construir scripts de construcción y desplie-
gue.

28
 Análisis de requisitos: Los scripts deben poder dar la capacidad de construir el sistema
con facilidad y dando opciones de configuración. Se tiene que poder ejecutar en el
hardware de bajo coste propuesto. También se llevan a tareas de mejoras del sistema
en general.
Diseño: Se realiza una tabla con las opciones que podrían tener los scripts.
Implementación: Los scripts se desarrollan para la ejecución con la herramienta NPM2 .
Pruebas: Se verifica que las tareas de construcción y despliegue funcionan correcta-
mente y el sistema se crea acorde las opciones introducidas.

Por último, la fase post-game, en el «Sprint Review se mostró al cliente lo realizado en

cada iteración de la siguiente manera:

Sprint 1: Análisis y estudio del estado del arte

Este sprint se desarrolló en 2 semanas y posteriormente se mostró al cliente para revisar el
estado del arte y poder decidir si continuar con la siguiente iteración.

Sprint 2: Análisis de las tecnologías de desarrollo para el desarrollo del sistema

Se llevó a cabo el análisis un 1 semana y se verificó la viabilidad del desarrollo del sistema
con las tecnologías y herramientas estudiadas.

Sprint 3: Estudio del protocolo de comunicación para los sistemas

El análisis de los protocolos de comunicación se llevó a cabo en 2 semanas. Hubo algún
contratiempo por lo que duró algo más de lo esperado. Al final se optó por el protocolo
MQTT.

Sprint 4: Desarrollo servidor de protocolo de comunicación

Este sprint se desarrolló en 2 semanas y se hicieron pruebas mediante un programa de
prueba. Se mostró el funcionamiento del protocolo y se aceptó.

Sprint 5: Montaje circuitos de los sistemas sensores y actuadores

El montaje del circuito, duró 1 semana, aunque hubo que modificarlo en sprints posterio-
res. Se verificó la primera aproximación que se tenía aunque después se mejorara.

Sprint 6: Desarrollo servidor web para la conexión del sistema con el exterior
Se realizó el servidor web en 1 semana y se mostró probándolo con la herramienta POST-
MAN 3 que nos permite lanzar llamadas a un API.
2
https://www.npmjs.com/
3
https://www.getpostman.com/

29
Sprint 7: Desarrollo aplicación móvil para los usuarios
. La aplicación móvil se tardó 3 semanas, pues hubo algún cambio necesario a mitad de
sprint, debido al cambio en el circuito. Se probó contra el sistema para mostrarlo al clien-
te.

Sprint 8: Implementación módulo de inteligencia

Este sprint se llevo a cabo en 1 semana. Se analizó la necesidad de incorporar este módulo
para añadirle robustez y un valor añadido al sistema.

Sprint 9: Montaje de servidores y tareas de construcción, despliegue del sistema y me-

joras
Se llevó a cabo en 3 semanas, pues coincidiendo con el final del TFG hubo que mejorar
algunas partes del sistema y añadir alguna funcionalidad para dotar al sistema de una mejor
aplicación a un entorno real.

4.2 Tecnologías de desarrollo

En las tecnologías de desarrollo existen infinidad de paradigmas, lenguajes de programa-
ción y herramientas para desarrollar. Estas tecnologías se tienen que centrar en el tipo de
sistema que se va a desarrollar. La plataforma que se va a crear tiene partes distintas pero
que de alguna manera se relacionan y se complementan entre ellas, por lo que se utilizarán
diferentes tecnologías de desarrollo de distinta índole.
En el apartado hardware, el arduino, como se ha comentado tiene un IDE de desarrollo con
un lenguaje de programación basado en Wiring4 . Nosotros optaremos por lenguaje JS, ya que
como se comentará en las herramientas software utilizadas, han surgido algunas bibliotecas
en este lenguaje para ejecutar programas escritos en él, dentro de la placa arduino.
Para el desarrollo del servidor web y control domótico, también se puede utilizar JS. Javas-
cript ha evolucionado mucho recientemente y ha dejado de ser un lenguaje de programación
para enriquecer las páginas web. Ahora se ha convertido en un lenguaje utilizado en un
amplio stack tecnológico que va desde el backend hasta el frontend, pasando por la progra-
mación para la utilización de bases de datos y, como se ha mencionado anteriormente, para
programación de hardware.
Por último para la aplicación móvil, se estudió desarrollarla en lenguaje Java5 para el
sistema operativo Android, pero se desestimó por el tiempo de aprendizaje que llevaría y
además nos limitaría a un sólo sistema operativo. De esta manera, surgió la idea de hacer
una aplicación móvil híbrida, que no deja de ser una aplicación web típica pero alojada
en un contenedor nativo para distintos sistemas operativos. Este tipo de aplicaciones está
4
Entorno de programación de código abierto para entradas/salidas.
5
https://www.java.com/es/

30
bastante en auge ya que se pueden crear aplicaciones multiplataforma basada en HTML5 de
una manera rápida y sencilla.

4.3 Herramientas
Daremos a conocer las herramientas técnicas, tanto software como hardware que se han
utilizado para el desarrollo e implementación de este TFG.

4.3.1 Medios hardware

Se ha utilizado hardware para el desarrollo del sistema y para crear el sistema en sí (cir-
cuitos).
TM
Computador de sobremesa para el desarrollo del TFG con Procesador Intel Core
R i7
CPU 870 2.93GHz 8GB Memoria RAM DDR3 y 1TB HDD. Desarrollo del sistema y
documentación.
TM
MacBook Pro con Procesador Intel Core
R i5 2.5GHz 8GB Memoria RAM DDR3 y
128GB SSD. Desarrollo del sistema.
Móvil Android. Dispositivo móvil para la realización de pruebas del sistema imple-
mentado. Móvil LG G4, Android 6.0.1.
Raspberry PI Model B. Procesador ARM 1176JZF-S, Memoria RAM 512MB. Home-
base del sistema.
Dos Arduino Modelo UNO. Implementación de circuitos sensores y actuadores.

4.3.2 Medios software

Se ha utilizado software tanto para el desarrollo del TFG, como para para la implementa-
ción del sistema (frameworks y bibliotecas).

Sistemas Operativos
• Android6 . Sistema operativo móvil sobre el que funcionan los dispositivos mó-
viles o tablets donde se ejecutará el sistema implementado. Dichos dispositivos
son muy accesibles hoy en día y tienen una capacidad de cómputo interesante.
Son fáciles de transportar y alcanzables para cualquier tipo de usuario.
• Mac OS X El Capitán7 . Sistema operativo donde se realizará el desarrollo del
sistema.
• Debian 8 Jessie8 . Sistema operativo para realizar desarrollo del sistema y la do-
cumentación.
6
http://www.android.com/
7
http://www.apple.com/es/osx/
8
https://www.debian.org/index.es.html

31
 • Raspbian Jessie Lite9 . Sistema operativo para el servidor donde se correrá el ho-
mebase del sistema.
Lenguajes
• Javascript10 . Lenguaje de programación para el desarrollo del sistema.
• LATEX11 . Lenguaje para el desarrollo de la documentación.
Frameworks y Bibliotecas
• Nodejs12 . Librería sobre lenguaje Javascript para ejecutar en el servidor.
• Jonnhy-Five13 . Librería para desarrollo con Arduino mediante lenguaje Javas-
cript.
• Mosca14 . Broker MQTT.
• MQTT.js15 . Cliente MQTT.
• Apache Cordova16 . Framework para creación de aplicaciones móviles híbridas
con tecnología web como HTML5.
• BackboneJS17 . Framework MVC para desarrollo de aplicación web con Javas-
cript.
• MarionetteJS18 . Framework para mejorar y simplificar el desarrollo de aplicacio-
nes con BackboneJS, aportando sistema de vistas y solución arquitectónica de
software.
• MongoDB19 . Base de datos no relacional, de tipo documental para el almacena-
miento de la información que se genera en el entorno inteligente.
• Node HMM20 . Biblioteca con la implementación del Modelo Oculto de Markov.
Herramientas
• NPM21 . Gestor de paquetes para la instalación de bibliotecas y dependencias para
el desarrollo.
• Atom 22 . Editor de código para programar el sistema.
9
https://www.raspbian.org/
10
http://www.w3schools.com/js/
11
https://www.latex-project.org/
12
https://nodejs.org/en/
13
http://johnny-five.io/
14
http://www.mosca.io/
15
https://www.npmjs.com/package/mqtt
16
https://cordova.apache.org/
17
http://backbonejs.org/
18
https://angularjs.org/
19
https://www.mongodb.com/es
20
https://www.npmjs.com/package/nodehmm
21
https://www.npmjs.com/
22
https://atom.io/

32
 • Mercurial23 . Sistema de control de versiones para el seguimiento de la evolución
del código fuente del sistema y de las versiones del mismo.

23
https://www.mercurial-scm.org/

33
Capítulo 5

Desarrollo del proyecto

E N este capítulo se describirá todo el desarrollo del proyecto, las partes que tiene el
sistema, cómo se ha implementado, las soluciones que se han dado y ejemplos del
sistema. Se va a ir describiendo cada una de las partes del sistema en el orden que se ha
seguido el desarrollo. El código fuente del proyecto está alojado en un repositorio público
(véase https://bitbucket.org/arco group/tfg.cristian.vozmediano).

5.1 Análisis de requisitos y estudio de tecnologías

Una vez visto los antecedentes de este proyecto, como sugiere el título del mismo, la
idea fundamental que motiva este TFG es la creación de una plataforma completa, de bajo
coste, para monitorizar y controlar entornos inteligentes. Además se incluye un sistema de
inteligencia, que lo enmarca en el paradigma AAL y lo hace más completo.
Para empezar a abordar dicho proyecto, se hace un análisis de las partes de las que debe
constar el sistema a alto nivel que son las siguientes:

Servidor de comunicaciones para el sistema.

Circuito de validación del sistema y programas de control.
Servidor web.
Aplicación móvil.
Módulo de inteligencia.

5.1.1 Protocolo de comunicación para los clientes (sistemas de control) con

el broker de comunicaciones
Se investiga que protocolos de comunicación existen y se pueden utilizar para la comuni-
cación entre las distintas partes del sistema que vamos a tener. Se ha de tener en cuenta qué
protocolos se pueden aplicar a la hora de distribuir la información sobre la pila de protocolos
TCP/IP.
JXTA [Mic] es un proyecto que inició Sun Microsystems que crea una plataforma para
estandarizar protocolos de comunicación con la idea de crear servicios de tipo peer-to-peer,
con dispositivos de cualquier tipo con independencia de la topología de red. Este conjunto de

34
protocolos se basan en XML para representar las estructuras de datos que se intercambian.
Uno de los protocolos mas ampliamente utilizado en M2M e I OT es un protocolo orien-
tado a eventos de IBM. Este protocolo se llama MQTT[OAS]. Originalmente utilizado en
aplicaciones de telemetría. La idea es tener un broker de eventos con un modelo publicado-
r/subscriptor. Este protocolo no depende del protocolo de transporte aunque normalmente va
montado sobre TCP.
El protocolo MQTT, encaja perfectamente en la idea de nuestro sistema, pues lo que se
pretende es tener un servidor que centralice todas las comunicaciones de los clientes (siste-
mas de control) que se conecten al sistema. Este servidor contendrá el broker encargado de
gestionar los eventos de los distintos topics a los que los sistemas conectados se suscriban.
La comunicación debe ser genérica y definida mediante el protocolo de comunicaciones,
para que cualquier sistema de control se conecte a nuestro sistema implementando dicho
protocolo y se pueda establecer comunicación estándar y escalable.

5.1.2 Circuito de validación del sistema y programas de control

Para el circuito de validación del sistema, se estudiaron las alternativas existentes en el
mercado, ya comentado en los antecedentes. De entre todas las alternativas se eligió un sub-
conjunto más representativo y que parecía que podrían servir para prototipar nuestro sistema
domótico, las cuáles fueron BeagleBoard1 , RaspberryPi2 , NanoPCT13 y Arduino4 .
De las cuatro alternativas que se estudiaron más a fondo, se decidió el uso de Arduino
por ser el más estandarizado y utilizada a día de hoy. Gracias a ello se dispone de bastante
documentación y se trabaja de manera sencilla con esta placa.
Con la utilización MQTT, se analizó las posibilidades para su implementación en los pro-
gramas de control para la placa. Después del análisis se determinó la posibilidad de imple-
mentación de MQTT en Arduino mediante el uso de una biblioteca en JS. Dado que el sistema
se desarrolla en su totalidad en este lenguaje no hubo dudas en su elección. Se hicieron prue-
bas de concepto para verificar su correcto funcionamiento.

5.1.3 Servidor web

Para la implementación del servidor web, se analizaron las siguientes tecnologías:

Java: Es uno de los lenguajes más estandarizados y utilizados. Se podría hacer un ser-
vidor HTTP con API REST mediante la utilización del framework Spring5 . Se descartó
pues es pesado para levantarlo en máquinas con pocos recursos y el desarrollo es más
lento y costoso.
1
http://beagleboard.org/
2
https://www.raspberrypi.org/
3
http://www.nanopc.org/
4
https://www.arduino.cc/
5
https://spring.io/

35
 Ruby: Lenguaje de programación tipo scripting. No es muy pesado al ser interpretado
y rápido de escribir. Para la creación del api, se pensó en utilizarlo con Sinatra6 que
nos brinda un framework para aplicaciones web bastante sencillo.Era una muy buena
alternativa, pues el objetivo era hacer algo sencillo y rápido, pero se descartó por la
mantenibilidad del sistema ya que el stack tecnológico que se quiere utilizar va más en
la línea de lenguaje JS.
Node: Es un framework en tiempo de ejecución, para la capa servidor basado en el
motor V87 de Google. Se desarrolla en lenguaje JS y se utilizaría con Express8 , que
es una infraestructura web que nos permite crear una API REST de manera rápida y
sencilla. Este fue el elegido, por su facilidad de uso, escalabilidad y mantenimiento.

5.1.4 Aplicación móvil

Una de las primeras cosas que se pensó fue ver en qué dispositivos móviles queríamos
tener la aplicación. Tenemos dos alternativas principalmente porque son las que dominan el
mercado de estos dispositivos, que son Android9 e iOS10 .
La idea es desarrollar la aplicación para dispositivos Android, porque el desarrollo es me-
nos costoso y no se necesita hardware y software especial. Por el contrario para desarrollar
en iOS si son necesarios11 .
Para desarrollar aplicaciones móviles se tiene dos alternativas, desarrollo nativo o híbrido.
En el caso de desarrollo nativo, es específico de cada sistema operativo y se necesita conoci-
mientos para desarrollar y saber utilizar herramientas propias de ese sistema operativo. Para
desarrollar de forma nativa en Android es necesario conocer el lenguaje Java
En el caso del desarrollo híbrido mediante aplicaciones web y contenedores web (web-
views) es más sencillo si se tienen conocimientos medios del stack HTML, JS y CSS. Además,
estas aplicaciones son multiplataforma y pueden ejecutarse en cualquier sistema operativo
móvil gracias a frameworks o bibliotecas como Apache Cordova12 . A veces se necesita al-
guna pequeña optimización o configuración especial dependiendo del sistema operativo.
Nuevamente por el stack que estamos utilizando y la rapidez del desarrollo se elige desa-
rrollar la aplicación móvil como una aplicación web embebida.

5.1.5 Módulo de inteligencia

Para el desarrollo de este módulo, se estudian varias alternativas:
6
http://www.sinatrarb.com/
7
https://developers.google.com/v8/
8
http://expressjs.com/es/
9
https://www.android.com/
10
http://www.apple.com/es/ios/
11
Ordenarores Apple con Mac OS con Xcode como IDE y dispositivos móviles Apple para poder hacer las
pruebas con una licencia de desarrollador.
12
https://cordova.apache.org/

36
 MATLAB13 : Es una plataforma para la resolución de problemas de ingeniería y cien-
tíficos, con múltiples herramientas y algoritmos para utilizar en inteligencia artificial
y machine learning. Es bastante completa y se podría utilizar para el desarrollo de
nuestro módulo pero se detectaron dos inconvenientes principalmente por lo que se
rechazó su uso, es de pago por lo que no encaja con nuestra idea de ahorrar en costes
y el programa es pesado para ejecutarlo en el dispositivo pensado para este sistema.
Python En este lenguaje es bastante sencillo desarrollar pequeños programas para la
resolución de problemas como el que pretendemos solucionar, no solo por su sencillez
si no por todas las librerías de funciones que hay disponibles para su uso, en temas
relacionados con la inteligencia artificial como Scikit-Learn14 entre otras. Es una alter-
nativa bastante buena, además de por lo dicho anteriormente, porque la ejecución de
estos scripts es sencilla y sólo necesita de la instalación de un intérprete de Python en
el sistema operativo del dispositivo donde se alojará el módulo.
Javascript Analizamos el uso de este lenguaje nuevamente y se hizo una búsqueda de
librerías para la resolución de nuestro problema. Se encontró una librería (Node HMM)
que encajaba para nuestro desarrollo y la implementación del módulo era sencilla y
ligera para ejecutar en el dispositivo usando Node. Además de por la experiencia en el
uso de esta tecnología, se optó además por ella por la homogeneidad de todo el stack
tecnológico utilizado en el sistema.

Después de analizar las tres alternativas anteriores, la elección fue javascript como tecno-
logía para el desarollo del sistema de inteligencia.

5.1.6 Resumen
En resumen, después de ver y analizar cada una de las tecnologías susceptibles de ser
elegidas, se ha apostado por tecnologías web, pero que cada vez están más presentes en
otras capas y paradigmas . Por lo tanto para el desarrollo del sistema, se utilizará lenguaje
JS completamente junto a una serie de bibliotecas o frameworks que nos ayudarán en la
implementación a todos los niveles.

5.2 Desarrollo Broker y Protocolo de comunicación domótico

El broker de comunicaciones, mediante el cuál se llevará a cabo la comunicación de los
distintos dispositivos domóticos entre si y el homebase del hogar, se ha implementado como
un módulo en javascript. Este módulo se instancia y ejecuta desde el servidor y es el que
coordina las distintas conexiones al broker de comunicaciones de los dispositivos domóti-
cos. Para ello se utiliza una librería javascript llamada Mosca la cuál nos provee de un broker
MQTT en Node. Nosotros haremos uso de este broker internamente extendiendo su funcio-
13
https://es.mathworks.com/products/matlab.html
14
http://scikit-learn.org/stable/

37
nalidad. El protocolo MQTT te permite distribuir los mensajes, y se han definido los eventos
domóticos de nuestro protocolo para ser distribuidos sobre MQTT.
La estructura de datos de un mensaje MQTT sería la siguiente:

Topic: Es la cadena con la cuál se identifican los tipos de eventos y quienes van diri-
gidos.
Payload: Información que se quiere transmitir. Por ejemplo, si una luz está “on” u
“off”.
QoS: Indica calidad del servicio. Tiene niveles 0,1 y 2. Nosotros utilizamos el 0 que
sólo nos asegura la correcta entrega.
Retain: Indica si se cuando se conecta un nuevo cliente se le manda este mensaje.

Nuestro protocolo se ha implementado como librería propia llamada cvgMqttProtocol.js

(ver Listado 5.1) que describe cómo es la estructura de mensajes de nuestro sistema, los
distintos tipos de dispositivos domóticos que podemos tener en nuestro sistema y una serie
de funciones para la composición de mensajes, validación de estructura de los mensajes
etc.

DEVICES = ["SYSTEM", "LIGHT", "SENSORPRESENCE", "SWITCH", "BUZZER",

"TEMPERATURE", "SENSORLIGHT", "RELAY", "TRACKING", "LASEREMIT",
"PHOTORESISTOR", "HUMIDITY", "HALLMAGNETIC", "IREMISSION", "IRRECEIVER",
"TOUCH", "JOYSTICK"];

PROTOCOL_NAME = ’cvgmqttprotocol’,

TOPIC_REGEXP_STRUCTURE = /cvgmqttprotocol\/[a-zA-Z0-9]+\/*[a-zA-Z0-9]*/;

Listado 5.1: Dispositivos compatibles y estructura de los topics

Asociaremos la jerarquía de topics a la localización de los dispositivos, de esta forma,

algunos ejemplos de mensajes en nuestro protocolo pueden ser los siguientes:

cvgmqttprotocol/system: Evento del sistema.

cvgmqttprotocol/sensorpresence/house1/downfloor/hall: Evento de un sensor de pre-
sencia en el hall, de la planta baja de la casa.
cvgmqttprotocol/light/house1/upfloor/bathroom: Evento en la luz del baño de la
planta alta de la casa.
cvgmqttprotocol/switch/house1/downfloor/kitchen: Evento en el interruptor de la
cocina en la planta baja de la casa.

Además, este módulo recoge todos los mensajes que se transmiten por el sistema y los va
almacenando en una base de datos documental (MongoDB). Esto servirá luego para el motor

38
de inteligencia artificial del sistema. También está dotado de funcionalidad para controlar la
transmisión de información al servidor web. Por ello hay funciones para ir almacenando el
estado de los distintos dispositivos conectados al sistema para cuando desde las aplicaciones
móviles se requieran y tiene funciones que son utilizadas por el servidor web para manejar.
Algunas de estas funciones son para mandar órdenes a los dispositivos domóticos que vienen
dadas desde las aplicaciones móviles de los usuarios.
A continuación comentamos dos ejemplos del funcionamiento del broker. En uno de los
ejemplos (ver Figura 5.1) uno de los clientes (Sensores), que tiene un sensor de presencia
localizado en el hall, detecta que hay una persona y publica un evento (cvgmqttprotocol/-
sensorpresence/house1/downfloor/hall) que el broker recibe y despacha a los demas dispo-
sitivos. El otro cliente (Actuadores) lo recibe porque está suscrito a él y ejecuta la orden
de encender la luz. El otro ejemplo (ver Figura 5.2), desde la aplicación móvil se da la or-
den de encender la luz del baño, esta orden dada al servidor web por el API, es reconocida
por este servidor y ejecuta una función del broker pasando la información necesaria (acción
y localización). El broker traduce esta orden a un evento mqtt (cvgmqttprotocol/light/hou-
se1/upfloor/bathroom) y lo recibe el cliente (Actuadores) que también está suscrito a él y
encenderá la luz del baño.

Figura 5.1: Ejemplo interacción del broker en el sistema

5.3 Montaje circuitos de los sistemas sensores y actuadores y su pro-

gramación
En esta sección se muestra el circuito completo (consta de dos circuitos) creado para el
prototipo y validación de nuestro sistema. Como se ha mencionado anteriormente la placa
elegida para el prototipo ha sido Arduino. Se han utilizado los siguientes elementos:

2 Placas Arduino UNO.

39
 Figura 5.2: Ejemplo interacción del broker en el sistema

4 Pulsadores/Interruptores.
1 Sensor de luminosidad.
2 Sensores de presencia.
6 Leds.
4 Resistencias.
2 Protoboards 15 .

El circuito que contiene la parte de sensores del sistema (ver Figura 5.3), está formado
por:

4 interruptores conectados a puertos digitales del Arduino a través de su pata de señal

utilizando una resistencia entre ésta y el puerto negativo. La pata positiva se conecta a
la corriente del Arduino a través de la línea positiva que alimenta la protoboard.
2 sensores de presencia conectados también al Arduino mediante puertos digitales a
través de sus patas de señal. Puertos negativos y positivos a las líneas negativa y posi-
tiva de la protoboard. Llevan una resistencia interna por lo que no hace falta añadirle
ninguna.
1 sensor de luminosidad conectado a un puerto analógico mediante su pata de señal.
Igual que los sensores de presencia polos negativo y positivo a líneas negativa y posi-
tiva de la protoboard y posee resistencia interna.

El circuito de actuadores (ver Figura 5.4), consta de una serie de seis leds, que simulan las
luces de cada localización de la casa, divididas en rojas para la planta superior y verdes para
15
Placa para prototipar sin tener que soldar cables a las placas controladoras con líneas de alimentación
positiva y negativa

40
Figura 5.3: Fotografía del circuito con los sensores (luminosidad, presencia e interruptores)
montado para el prototipo y validación del sistema

la planta baja. En este circuito los leds van conectados (polo positivo) a puertos digitales del
Arduino a través de la protoboard.

Figura 5.4: Fotografía del circuito con los actuadores (luces) montado para el prototipo y
validación del sistema

Además, se ve (ver Figura 5.5) cómo sería la correspondencia en una casa convencional
de los elementos domóticos representados en la maqueta.

41
 Figura 5.5: Plano de una casa convencional y ubicación de elementos domóticos

Tenemos un prototipo con dos circuitos, que electrónicamente son independientes el uno
del otro, pero están relacionados. Se ha simulado por un lado los elementos sensores y por
otro los elementos actuadores. Cada circuito está gobernado por un programa escrito en JS,
que le da la lógica de cliente MQTT y la lógica básica de funcionamiento. La comunicación
entre los circuitos se hace mediante el protocolo MQTT que implementa una librería llama-
da Mqttjs(ver Listado 5.2). Ambos están conectados al sistema mediante puerto serie y se
comunican con el broker MQTT16 .
Los clientes se configuran mediante un fichero de configuración llamado client.config.json
(ver Listado 5.3).
A continuación indicamos que es cada atributo:

clienteId: Identificador que le damos al cliente para saber de qué cliente se trata por
ejemplo en los logs del sistema.
urlBroker: Dirección URL donde está levantado el broker de comunicaciones.
portMac: Puerto serie donde está conectada la placa Arduino, en caso de ser un sistema
Mac OS.
portMac: Puerto serie donde está conectada la placa Arduino, para sistemas tipo Unix.

Para programar en Arduino, lo normal es utilizar su entorno de desarollo y su lenguaje

específico para él. Pero para este TFG, siguiendo con el stack que vamos a utilizar, será
javascript el lenguaje con el que trabajaremos.
16
El sistema podría funcionar con los clientes conectados a cualquier otra máquina, pero para el prototipo lo
conectaremos en la misma máquina en la que corre el broker MQTT.

42
 //Importamos la biblioteca
mqtt = require(’mqtt’);

//Conexion con el broker pasando url del broker e

//identificador del cliente
client = mqtt.connect(config.sensorsClient.urlBroker,{
clientId:config.sensorsClient.clientId
});

// Suscripcion a topics
client.on(’connect’, function () {
client.subscribe(’cvgmqttprotocol/system’,{qos:0});
that.operative = true;
});

client.on(’message’, function (topic, message) {

var message = message.toString().toUpperCase();

//Accion con el topic y mensaje

if(topic === "cvgmqttprotocol/light/house1/upfloor/bathroom"){
lightOn("batchroom");
}
});

Listado 5.2: Estructura fichero de configuración de clientes

Para que se pueda ejecutar código javascript en el Arduino necesitamos hacer uso de dos
elementos principalmente:

Node: A día de hoy el código javascript que se ejecuta en Arduino, no se puede alojar
en la memoria flash de la placa, por lo que se ejecuta en la máquina a la que está
conectada la placa mediante node y se comunica con la placa mediante puerto USB.
Esta pequeña limitación hace que las placas Arduino las tengamos que conectar al
homebase (Raspberry Pi) del sistema mediante puerto USBtanto para la alimentación
de corriente como para la ejecución del programa.
Biblioteca Jhonny-Five: Esta biblioteca nos proporciona acceso a la placa, y control
sobre todos los elementos que estén conectados sobre ella, mediante un programa en
javascript (ver Listado 5.4). Se necesita ejecutar el programa con node y haber instala-
do en la placa, mediante en entorno de desarrollo de Arduino el StandarFirmata para
que la biblioteca pueda funcionar.

Este circuito funciona con corrientes de entre 5 y 12 voltios. Para su uso en una instalación
eléctrica de una casa convencional sería necesario utilizar una etapa de potencia, y así poder
trabajar a 220v.

5.4 Desarrollo servidor web

El servidor web que se va a implementar en el sistema conectará el sistema domótico con
el exterior (ver Figura 5.6). Este servidor servirá tanto para mandar información del entorno

43
 {
"actuatorsClient":{
"clientId":"tfg_Actuators",
"urlBroker":"mqtt://localhost:1883",
"port_mac":"/dev/cu.usbmodem1411",
"port_linux":"/dev/ttyACM1",
"portSelected":"linux"
},
"sensorsClient":{
"clientId":"tfg_Sensors",
"urlBroker":"mqtt://localhost:1883",
"port_mac":"/dev/cu.usbmodem1421",
"port_linux":"/dev/ttyACM0",
"portSelected":"linux"
}
}

Listado 5.3: Estructura fichero de configuración de clientes

//Importamos la biblioteca
var five = require("johnny-five"),
board;

//Inicializamos la placa indicando el puerto donde esta conectada

board = new five.Board({
port:config.actuatorsClient["port_" + config.sensorsClient.portSelected];
});

//Ejecutamos el programa que queramos una vez la placa esta lista

board.on("ready", function () {
//code
});

Listado 5.4: Estructura código con librería Johnny-Five

domótico a los dispositivos móviles (aplicación móvil cliente) del sistema, como para recibir
órdenes que los dispositivos móviles darán al entorno domótico.
El servidor está implementado en Node utilizando Express, un framework web rápido y
minimalista con el que el desarrollo de API REST es muy rápido y sencillo. Se basa en el
levantamiento de un servidor escuchando en un puerto que definamos al que se le asocian
distintas acciones en función de la ruta y del método con el que se lancen las peticiones. En
esta tabla (ver Cuadro 5.1) se puede ver el api.
El servidor web se comunica con el servidor broker de comunicaciones del sistema do-
mótico mediante una interfaz de llamadas a funciones de Javascript. En el servidor web se
importa el módulo del broker y se hacen las llamadas a las diferentes funciones que expone
el interfaz (ver Listado 5.5). Esto se consigue gracias a la biblioteca de inyección de depen-

44
 Figura 5.6: Diagrama conexión entre dispositivos móviles y servidor del sistema

dencias para Javascript RequireJS17 . En las llamadas a los controles se le pasan parámetros
como el tipo de control y el lugar o localización (parte del protocolo), para que el broker
mande los mensajes a los dispositivos que se indiquen.
El broker y la aplicación móvil, tienen en común la lista de controles que están en el siste-
ma (por fichero de configuración). Cada elemento de la lista es un objeto con una estructura
de datos como esta (ver Listado 5.6). Esta estructura de datos tiene como atributos tipo de
control, etiqueta de nombrado, localización y estado.
//Importamos el modulo del broker
var brokerMqtt = require(’../broker/BrokerMQTT’);

//Dada una llamada al api del servidor web para obetener

//informacion del sistema
app.get(’/tfg-api/system’, function (req, res) {
var data = brokerMqtt.system();
res.status(200).send({
status:data.status,
mode:data.mode
});
});

Listado 5.5: Estructura importación módulo Broker en el servidor

17
http://requirejs.org/

45
 {
controlType:"light-control",
label: "light-control-livingroom",
place:"downfloor/livingroom",
status:"off"
}

Listado 5.6: Estructura de datos de un control

5.5 Desarrollo aplicación móvil

Para el desarrollo de la aplicación móvil se ha utilizado un enfoque de aplicación híbrida.
Esto es, una aplicación web que se adapta para su funcionamiento al dispositivo como si
fuera una aplicación nativa. Para ello es necesario el uso de frameworks como Apache Cor-
dova [Foub] que nos permitan embeber estas aplicaciones web en un contenedor nativo.
El proceso de creación mostrado en la figura (ver Figura 5.7) de la aplicación nativa a
partir de la aplicación web es muy sencillo gracias al framework. Sólo necesitamos copiar
el target18 de la aplicación web al directorio donde tenemos el esqueleto de la aplicación
nativa y mediante un comando de compilación que nos proporciona el framework de Apache
se compila y se despliega para el sistema operativo elegido. En la figura se muestra que tec-
nologías (logotipos [Fouc][Logd][Logc][Logf][Loga][Loge][Logb]) están presentes en cada
parte de la composición de la aplicación móvil.

Figura 5.7: Esquema de la arquitectura para la aplicación móvil

El framework necesita un fichero config.xml donde se indican parámetros de configuración

para la aplicación nativa, como el nombre de la aplicación, autor, fichero html de inicio de la
aplicación. Para este TFG se ha desarrollado y optimizado para el sistema operativo Android
(ver Listado 5.7).
Una vez visto cómo se construye y cómo va a ser nuestra aplicación móvil a nivel de
18
Ficheros Javascript y HTML y un index.html

46
 <?xml version=’1.0’ encoding=’utf-8’?>
<widget id="com.tfg.mobileapp" version="0.0.1" xmlns="http://www.w3.org/ns/widgets" xmlns:cdv="
http://cordova.apache.org/ns/1.0">
<name>TFGApp</name>
<description>
Aplicacion movil TFG Plataforma de bajo coste para la monitorizacion y control de
entornos inteligentes
</description>
<author email="cvozmedg@gmail.com">
Cristian Vozmediano Garcia
</author>
<content src="index.html" />
<plugin name="cordova-plugin-whitelist" spec="1" />
<access origin="*" />
<allow-intent href="http://*/*" />
<allow-intent href="https://*/*" />
<platform name="android">
<allow-intent href="market:*" />
</platform>
<engine name="android" spec="~5.1.1" />
</widget>

Listado 5.7: Contenido fichero configuración para el empaquetado de la aplicación

dispositivo, vamos a empezar a ver cómo es la aplicación, qué hace, cómo es su interfaz y
cómo se ha implementado.
Primero tenemos que decir que la aplicación web se ha creado con el stack tecnológico
HTML5, CSS y Javascript.
Para el desarrollo de la aplicación se ha optado por utilizar un patrón de diseño Modelo,
Vista, Controlador, o MVC (ver Figura 5.8), utilizando un framework de javascript llamado
Backbonejs. Este framework nos aporta el patrón de diseño de manera que podamos tener
separado la lógica de negocio, de las acciones y de las vistas. Además utilizamos Marionet-
tejs para la gestión de las vistas, pues nos da más funcionalidad y aporta sencillez para la
utilización de vistas con Backbonejs.
La interfaz de usuario de la aplicación se ha intentado que sea lo más sencilla e intuitiva
para el usuario, por ello cuenta con un pequeño menú de dos pestañas, para las dos vistas
que dispone, una para el sistema y otra para configuración.
En la vista del sistema (ver Figura 5.9) se muestra el estado del sistema (encendido o
apagado) y la lista de contoles (luces) donde se indica el estado y se puede interactuar con el
sistema (apagar o encender). Además, cuenta con un botón para actualizar el estado general
del sistema, es decir, si por ejemplo el usuario ha encendido o apagado luces físicamente se
actualizará el estado de los controles en la aplicación bajo demanda.
En la vista de configuración (ver Figura 5.10) el usuario podría apagar o encender los con-
troles de presencia y luminosidad, así como configurar la dirección url del servidor alojado

47
Figura 5.8: Diagrama componentes de una aplicación con Marionettejs y Backbonejs[SO]

en el hogar a controlar. Los controles de presencia, se pueden apagar o encender. El control

de luminosidad exterior se puede configurar para que encienda o apague todas las luces de
la casa, sólo las de la planta alta o planta baja o apagarlo.

Figura 5.9: Vista sistema global

La aplicación se conecta con el servidor web que tiene el homebase mediante el API REST,
definido en el servidor web. Se ha implementado una utilidad en la aplicación para gestionar
las diferentes llamadas al API y que esté centralizado de manera que si hay que extender el
sistema y agregar más llamadas sea más sencillo. Para la implementación de esta utilidad
se ha seguido un patrón de diseño Facade que nos proporciona un conjunto de funciones
bien definidas para hacer uso de otras más complejas para que al programador le resulte más

48
 Figura 5.10: Vista configuración

sencillo interactuar con el API sin conocerlo del todo.

En el código que se muestra (ver Listado 5.8), se puede ver una llamada al api, donde lo
único que le pasamos son los datos para la llamada, y las funciones con el código que se
quiere ejecutar en caso de que la llamada sea correcta o de error.

5.6 Sistema de base de datos

El sistema necesita persistir datos para luego poder explotar la información y poder extraer
acciones futuras, que es lo que se quiere conseguir como objetivo principal.
Por el tipo de datos que se necesita almacenar y el lenguaje de programación con el que
se implementa el sistema, la base de datos MongoDB es ideal para ello.
Se utiliza una librería de Node llamada mongodb19 para la interacción con la base de
datos.
Cada documento (registro) de la base datos es un documento en formato BSON 20 y repre-
senta un mensaje (topic) dado en el sistema (ver Listado 5.9).
Al ejecutar el broker se instancia el objeto (ver Listado 5.10) que servirá de interfaz para
controlar la gestión de base de datos. Por defecto si no existe se creará la base de datos y la
colección (tabla) donde se almacenará la información. Los nombres tanto de la base de datos
como de la colección está almacenada en el fichero de configuración broker.config.json.
Una vez la base de datos está ejecutándose y el objeto conector está activo se puede al-
19
https://www.npmjs.com/package/mongodb
20
http://bsonspec.org/

49
 TfgApp.trigger("api-post",{
data:{
action:_action
},
partialUrl:"system",
onSuccess:function(){
if(TfgAppViewHelpers.isOn(that.model.get(’status’))){
that.model.set("status", TfgAppEnums.status.OFF);
that.ui.buttonStatus.html(TfgAppStrings.translate("on"));
}else{
that.model.set("status", TfgAppEnums.status.ON);
that.ui.buttonStatus.html(TfgAppStrings.translate("off"));
}
that.render();
},
onError:function(){
console.log("Error api");
}
});

Listado 5.8: Llamada funcion del API Rest en la aplicación

{ "_id" : ObjectId("58728f5f0932a7613dd91c7e"), "time" : "08/01/2017 20:13:35", "topic" : "

cvgmqttprotocol/sensorpresence/house1/downfloor/hall", "message" : "TRUE" },
{ "_id" : ObjectId("58728f5f0932a7613dd91c7e"), "time" : "08/01/2017 20:13:35", "topic" : "
cvgmqttprotocol/sensorpresence/house1/downfloor/hall", "message" : "FALSE" },
{ "_id" : ObjectId("58728f5f0932a7613dd91c7e"), "time" : "08/01/2017 20:13:35", "topic" : "
cvgmqttprotocol/switch/house1/downfloor/livingroom", "message" : "HIGH" }

Listado 5.9: Ejemplos registros que se almacenan en una colección de la base de datos en
Mongo

macenar información en ella desde el broker (ver Listado 5.11) o leerla como se hace en el
módulo de inteligencia (ver Listado 5.12).

5.7 Módulo de inteligencia

Para el desarrollo de este módulo, se ha utilizado un programa en javascript. Su objetivo
principal es dar una predicción del siguiente estado o acción futura que es más probable
que realice el usuario, analizando la información de las acciones anteriores y los datos del
modelo HMM, que se ha creado.
A continuación se ve con que datos se ha creado el modelo HMM, analizando las acciones
cotidianas de una persona en su casa. El siguiente diagrama (ver Figura 5.11) representa la
probabilidad de transicion de estados inicial. En ella se ve que los estados del usuario son ac-
ciones típicas cómo ducharse, lavarse los dientes, ver la tv, cocinar etc. Estas probabilidades
se han improvisado, pero en un entorno real deberían obtenerse observando el comporta-
miento del usuario. Estos estados son los que denominaríamos ocultos en el HMM, pues no
vamos a poder observalos con el sistema. Para ello tenemos un cojunto de observaciones y
sus probabilidades (ver Figura 5.12) que sí podemos determinar si ocurren o no en el sistema

50
 mongodb.MongoClient.connect(config.eventRegistry.iaRegistryDbUrl)
.then(function(db) {
return db.createCollection(’eventsCollection’);
}).then(function(_events){
events = _events;
});
//La variable events, es una referencia a la coleccion donde almacenamos los datos

Listado 5.10: Conexión con la base de datos desde el módulo de broker

//Se inserta un objeto (registro) utilizando la referencia a la coleccion

events.insert({
time: moment().format("DD/MM/YYYY HH:mm:ss"),
topic:packet.topic,
message
});

Listado 5.11: Escritura de datos en la base de datos desde el módulo de broker

gracias a los sensores del entorno domótico. Estas obsevaciones representan localizaciones
del entorno domótico (cocina, entrada, salón, dormitorio etc) donde se puede encontrar el
usuario y que están relacionadas con las acciones (estados ocultos) que puede realizar el
usuario. Por esta razón se eligieron los modelos ocultos de Markov para el reconocimiento y
predicción de acciones.

Figura 5.11: Diagrama que muestra la probabilidad de transición de estados inicial

Para llegar a cumplir el objetivo, tiene que haber una serie de procesados de la información,

51
 mongodb.MongoClient.connect(config.eventRegistry.iaRegistryDbUrl)
.then(function(db) {
var data = db.collection("eventsCollection").find().toArray(function(err, data){
//data es el objeto que contiene los datos leidos

});

});

Listado 5.12: Lectura de datos en la base de datos desde el módulo de inteligencia

Figura 5.12: Diagrama que muestra la probabilidad de observaciones en cada estado

desde que se recoge los topics que se han dado en el sistema de la base de datos hasta que se
calcula la siguiente acción.
La información se almacena como ya se ha dicho anteriormente en una base de datos no
relacional y documental llamada MongoDB. Además, el módulo necesita toda la informa-
ción del modelo (HMM) del sistema (matrices de emisión, probabilidad de transición entre
estados, observaciones y estados posibles etc). En el siguiente listado (ver Listados 5.13
y 5.14), se muestra como se almacenan los datos de los diferentes parámetros del modelo
HMM que se ha implementado utilizando las probabilidades, estados y observaciones expli-
cadas anteriormente.
En la ilustración (ver Figura 5.13) se puede ver de una manera rápida el flujo del módulo.
En primer lugar se leen los registros de la base de datos que son los topics que se dan en el

52
sistema. Como estos topics pueden ser de cualquier acción que se lleve a cabo en el sistema
hay que procesarlos y quedarse con los que de verdad interesan para determinar en que
lugar de la casa se encuentra el usuario. Para ello, se tiene un subconjunto de topics que
son característicos de acciones manuales del usuario (darle a un interruptor o presencia en
un lugar por ejemplo), por lo que en la primera etapa tendríamos un conjunto de eventos
definidos mediante una estructura de datos propia (ver Listado 5.15). Estos eventos tienen
el instante (fecha y hora) en la que se produjo el evento y una serie de atributos que son los
lugares de la casa, los cuales están a true o false si ese evento ha determinado la presencia
en un lugar o no.

Figura 5.13: Diagrama de flujo del sistema inteligente

Una vez tenemos los eventos que verdaderamente indican por qué lugares de la casa ha ido
pasando, procedemos a transformar estos eventos en un vector de observaciones, es decir, un
vector con los identificadores de los lugares (observaciones) por los que ha pasado el usuario
definidos en el modelo de nuestro sistema. Este vector será necesario para los algoritmos del
HMM.

Para calcular la observación futura más probable dada las anteriores, cogemos las últimas
observaciones y vamos iterando tantas veces como posibles observaciones(lugares) tenga-
mos, formando un nuevo conjunto con últimas observaciones más la observación sobre la
que estamos iterando. En cada iteración calculamos la probabilidad de este nuevo conjunto
de manera que nos quedamos con la nueva secuencia de observaciones que sea posible y
tenga más probabilidad de ocurrir.
Una vez tenemos el nuevo conjunto de observaciones, de las cuales la última es la futura,
aplicamos el algoritmo de Viterbi[Zü]. Este algoritmo está basado en programación dinámica
y nos permite hallar el conjunto de estados que mejor que son más probables de generar este
nuevo conjunto de observaciones. Al aplicarlo sobre la nueva secuencia de observaciones nos
dará el estado futuro, es decir, la acción que con más probabilidad va a realizar el usuario.
La salida del sistema (ver Listado 5.16), será el conjunto de lugares en los que el usuario

53
ha estado, la predicción del lugar donde estará y la acción futura que realizará. Puede ser que
en ocasiones no se produzca salida válida y no se pueda calcular la predicción debido a que
haya realizado alguna secuencia de observaciones que no es válida con el modelo actual (ya
que se ha realizado de manera manual y aproximada). En este caso la salida será un mensaje
de error indicando que no se ha podido realizar la predicción.

5.8 Servidores y tareas

EL homebase será el hardware Raspberry Pi. Se ha instalado como sistema operativo una
distribución Debian21 especial para este dispositivo llamada Raspbian22 .
En él es necesario intalar Node para que funcione el servidor, el broker de comunicaciones
del sistema y los clientes, además de bibliotecas complementarias y algunas dependencias
23
para el correcto funcionamiento de todo el sistema. Para la gestión de dependencias del
proyecto y de la instalación de las bibliotecas se ha utilizado el gestor de paquetes Npm. Para
acceder al homebase a realizar tareas de mantenimiento se utilizará ssh.
Se ha creado algunas tareas (scripts) con npm para la instalación, inicio, apagado del sis-
tema y ejecución del módulo de inteligencia.
Los comandos son los siguientes:

npm run install-tfg: Instala las dependencias de Node, que necesita el sistema para
ejecutarse.
npm run run-tfg: Levanta los servidores, la base de datos MongoDB y lanza los pro-
gramas de control de los circuitos con Arduino configurados siempre que estén conec-
tados.
npm run stop-tfg: Para todas las instancias y las ejecuciones del sistema.
npm run drop-database: Limpia la base de datos.
npm run ia-tfg: Ejecuta el módulo de inteligencia.

Para la aplicación móvil, es necesario compilarla a parte en sistemas preferiblemente Mac

o Linux teniendo instalado Apache Cordova y Node. Es necesario, tener instalada las depen-
dencias de la plataforma sobre la que vamos a compilar la aplicación en Apache Cordova.
Los comandos son:

npm run install-android-dependencies: Instala las dependencias de Android para la

compilación de la aplicación móvil al sistema operativo Android.
npm run create-app: Copia el código HTML,CSS Y JS creado en el directorio target de
la aplicación móvil y genera un apk instalable.
21
https://www.debian.org/index.es.html
22
https://www.raspberrypi.org/downloads/raspbian/
23
Necesario tener instalado MongoDB

54
Acción Recurso Método
Obtener información
/tfg-api/system GET
del sistema
Dar órdenes al sistema
/tfg-api/system POST
(encender, apagar...)
Dar órdenes a un
/tfg-api/light-control POST
actuador de luz(bombilla)
Dar órdenes a un
/tfg-api/sensorlight-control POST
sensor de luminosidad
Dar órdenes a un
/tfg-api/presence-control POST
sensor de presencia
Cuadro 5.1: Tabla ejemplo de llamadas al API REST

55
module.exports = {
"observations": {
"HALL":0,
"BEDROOM" : 1,
"LIVING_ROOM": 2,
"KITCHEN": 3,
"BATHROOM": 4,
"STUDY": 5,
"LAUNDRY_ROOM": 6
},

"states": {
"ENTER_HOME":0,
"LEAVING_HOME":1,
"READING": 2,
"WATCH_TV": 3,
"COOK": 4,
"GET_SHOWER": 5,
"BRUSH_TEETH": 6,
"EATING":7,
"SLEEPING": 8,
"LAUNDRY": 9,
"IRON": 10
},

//["ENTER_HOME", "READING", "SLEEPING", "WATCH_TV", "BRUSH_TEETH", "LAUNDRY", "IRON", "

GET_SHOWER", "COOK", "EATING", "LEAVING_HOME"]
"statesStartProbability": [0.2, 0.05, 0.1, 0.05, 0.1, 0.05, 0.1, 0.05, 0.2, 0.05, 0.05],

"transitionProbabilityMatrix":[
[0.0, 0.1, 0.0, 0.1, 0.2, 0.0, 0.0, 0.4, 0.2, 0.0, 0.0], // ENTER_HOME
[1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0], // LEAVING_HOME
[0.0, 0.0, 0.0, 0.1, 0.0, 0.2, 0.0, 0.0, 0.7, 0.0, 0.0], // READING
[0.0, 0.0, 0.0, 0.0, 0.1, 0.2, 0.0, 0.1, 0.6, 0.0, 0.0], // WATCH_TV
[0.0, 0.0, 0.1, 0.0, 0.0, 0.2, 0.0, 0.6, 0.0, 0.0, 0.1], // COOK
[0.0, 0.3, 0.0, 0.0, 0.0, 0.0, 0.0, 0.1, 0.5, 0.1, 0.0], // GET_SHOWER
[0.0, 0.0, 0.0, 0.2, 0.0, 0.0, 0.0, 0.0, 0.8, 0.0, 0.0], // BRUSH_TEETH
[0.0, 0.0, 0.0, 0.2, 0.0, 0.0, 0.7, 0.0, 0.0, 0.1, 0.0], // EATING
[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.8, 0.0, 0.2, 0.0], // SLEEPING
[0.0, 0.0, 0.2, 0.0, 0.2, 0.0, 0.0, 0.0, 0.0, 0.0, 0.6], // LAUNDRY
[0.0, 0.4, 0.0, 0.0, 0.0, 0.0, 0.0, 0.4, 0.2, 0.0, 0.0] // IRON
],

Listado 5.13: Datos del modelo del sistema para inteligencia artificial

56
 "emmisionProbabilityMatrix":[
[1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0], // ENTER_HOME : ["HALL","BEDROOM", "LIVING_ROOM", "
KITCHEN", "BATHROOM", "STUDY", "LAUNDRY_ROOM"]
[1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0], // LEAVING_HOME : ["HALL","BEDROOM", "LIVING_ROOM",
"KITCHEN", "BATHROOM", "STUDY", "LAUNDRY_ROOM"]
[0.0, 0.5, 0.2, 0.0, 0.0, 0.3, 0.0], // READING : ["HALL","BEDROOM", "LIVING_ROOM", "
KITCHEN", "BATHROOM", "STUDY", "LAUNDRY_ROOM"]
[0.0, 0.5, 0.3, 0.2, 0.0, 0.0, 0.0], // WATCH_TV : ["HALL","BEDROOM", "LIVING_ROOM", "
KITCHEN", "BATHROOM", "STUDY", "LAUNDRY_ROOM"]
[0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0], // COOK : ["HALL","BEDROOM", "LIVING_ROOM", "KITCHEN
", "BATHROOM", "STUDY", "LAUNDRY_ROOM"]
[0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0], // GET_SHOWER : ["HALL","BEDROOM", "LIVING_ROOM", "
KITCHEN", "BATHROOM", "STUDY", "LAUNDRY_ROOM"]
[0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0], // BRUSH_TEETH : ["HALL","BEDROOM", "LIVING_ROOM", "
KITCHEN", "BATHROOM", "STUDY", "LAUNDRY_ROOM"]
[0.0, 0.0, 0.7, 0.3, 0.0, 0.0, 0.0], // EATING : ["HALL","BEDROOM", "LIVING_ROOM", "
_
KITCHEN", "BATHROOM", "STUDY", "LAUNDRY ROOM"]
[0.0, 0.8, 0.2, 0.0, 0.0, 0.0, 0.0], // SLEEPING : ["HALL","BEDROOM", "LIVING_ROOM", "
_
KITCHEN", "BATHROOM", "STUDY", "LAUNDRY ROOM"]
[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0], // LAUNDRY : ["HALL","BEDROOM", "LIVING_ROOM", "
_
KITCHEN", "BATHROOM", "STUDY", "LAUNDRY ROOM"],
[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0] // IRON : ["HALL","BEDROOM", "LIVING_ROOM", "KITCHEN
", "BATHROOM", "STUDY", "LAUNDRY_ROOM"]
]
}

Listado 5.14: Datos del modelo del sistema para inteligencia artificial continuación

{
TIME: "01/01/2017 18:00:00",
HALL: false,
BEDROOM: false,
LIVING_ROOM: true,
KITCHEN: false,
BATHROOM: false,
STUDY: false
}

Listado 5.15: Estructura de datos de evento

Observations (Place where user stay) ----> [ ’STUDY’, ’KITCHEN’, ’LIVING_ROOM’ ]

Observations (Place where user will stay) ----> BEDROOM
The next most likely state is --> WATCH_TV

Listado 5.16: Salida del sistema, con la predicción de acción futura del usuario

57
Capítulo 6

Resultados

E N este capítulo mostraremos como ha quedado el sistema y ejemplos de funcionamiento

y validación del sistema.
En primer lugar se muestra las distintas partes que forman la plataforma en esta imagen
(ver Figura 6.1) con el prototipo del circuito del entorno domótico, el centro de control y la
aplicación móvil en un teléfono móvil. En la ilustración se ve los dos circuitos de sensores
y actuadores, una serie de letreros que indican a qué corresponde cada sensor o actuador, el
móvil con la aplicación corriendo y la raspberry conectada a los circuitos.

Figura 6.1: Maqueta prototipo del circuito del sistema

Una vez se ha instalado las dependencias de los sistemas de la plafatorma (mediante el

comando npm run install-tfg) en el centro de control (Raspberry Pi), conectamos los circuitos
mediante puerto serie (USB) al centro de control y ésta a su vez a un punto de red para que
tenga conexión a internet. Para ejecutar el sistema se lanza el script de inicio (npm run run-

58
tfg), el cuál desencadena las siguientes tareas:

Arrancar el servidor web en el puerto 3000.

Iniciar el broker.
Crear si no existe la base de datos.
Lanzar los clientes (programas de control de los Arduino).

Una vez el sistema está funcionando, el circuito sensor va registrando las acciones que
realiza el usuario sobre los elementos domóticos de la casa como son los interruptores o
detectores de presencia. El programa de control va emitiendo mensajes de los eventos que
se van produciendo y son recibidos por el broker y el circuito actuador, que actúa en conse-
cuencia encendiendo o apagando luces.
En la siguiente figura (ver Figura 6.2) se puede ver por la consola del sistema el flujo de
mensajes y las acciones que se van llevando a cabo en el entorno domótico.

Figura 6.2: Salida consola del sistema con el flujo de mensajes

Una vez se tienen suficientes datos almacenados en el sistema, se puede lanzar el módulo
de inteligencia que será el encargado de hacer predicciones de posibles acciones futuras.
Cuando se ejecuta el sistema, va procesando cada evento registrado en el sistema y hace un
barrido para quedarse con los eventos que nos dan información de por dónde ha pasado el
usuario.
Por ejemplo, se pueden dar una serie de eventos tales como el apagado del interruptor del
baño, la activación de las luces de la planta baja por el sensor de luminosidad y el encendido
de luces del salón mediante el accionamiento del interruptor por el usuario. De estos eventos
realmente sólo interesa el apagado y encendido de luces que el usuario realiza, pues son los
eventos que permiten extraer la observación de dónde ha estado.

59
 El sistema de inteligencia utiliza la secuencia de observaciones válidas (donde ha estado
el usuario) junto con los parámetros del modelo HMM para realizar las predicciones y así
poder ayudar al usuario. Al predecir una acción futura y el lugar donde la puede realizar,
el sistema puede anticiparse y por ejemplo encender la luz del lugar donde va a realizar la
acción. De esta manera si está oscuro y el usuario tiene que recorrer una distancia hasta el
lugar que se dirige, el sistema podrá encender la luz antes de que el usuario eche a andar y
así verá bien el camino al andar y puede evitar una caida por ejemplo.
Para la validación del sistema inteligente se muestran dos casos de prueba a continua-
ción:
«Antonio entra a su casa, deja el abrigo en el perchero y pasa al salón para dejar la car-
tera y ver las llamadas. Después va a la cocina a merendar un bocadillo y leer las noticias.
Después va al baño a lavarse los dientes.»
En este momento si ejecutamos el sistema de inteligencia, analizando estas acciones de
Antonio y según el modelo HMM ideado, nos predice que irá al cuarto de lavandería a hacer
la colada (ver Figura 6.3) .

Figura 6.3: Salida por consola de sistema de inteligencia (ejemplo 1)

«Antonio entra a su casa, deja el abrigo en el perchero y entra a la cocina para dejar la
tartera y prepararse un sándwich. Después se va a echarse un rato a la habitación porque
está cansado. Después de un tiempo se levanta aturdido y va al baño a lavarse la cara con
agua fría.»
De nuevo si ejecutamos el sistema de inteligencia, analizando estas nuevas acciones de
Antonio y según el modelo HMM ideado, nos predice que irá a la cocina a comer algo (ver
Figura 6.4) .
En ambos casos, la forma de proceder por el sistema es similar. Calcula la probabilidad
de las distintas combinaciones que se pueden dar con los lugares visitados y el siguiente

60
 Figura 6.4: Salida por consola de sistema de inteligencia (ejemplo 2)

lugar posible. En la figura (ver Figura 6.5) se muestra cómo se realizaría la predicción en el
segundo ejemplo que se ha comentado antes.

Figura 6.5: Cálculo de la predicción de la acción siguiente

Una vez se tiene esa nueva secuencia que será la secuencia que se dará en el futuro inme-
diato según la predicción, se aplica otro algoritmo del modelo HMM y se halla la secuencia
de estados (acciones del usuario) que sería lo más probable que se diera para ese conjunto de
observaciones, teniendo que el último estado sería la acción que realizaría en la cocina.
Por último se muestra la parte en la que la domótica tiene más importancia, la utilización

61
del dispositivo móvil para el control y monitorización del entorno domótico. A continuación
se muestra un ejemplo donde se enciende dos luces (salón y cocina) (ver Figura 6.6) manual-
mente en el entorno, desde la aplicación se puede ver remotamente que está pasando en el
entorno domótico, para ello basta con actualizar la información con el botón Actualizar de
la interfaz y de manera inmediata se verá como está el sistema (ver Figura 6.7).

Figura 6.6: Luces del salón y cocina encendidas desde el entorno domótico (manual)

Figura 6.7: Visualización del entorno domótico en la aplicación móvil

62
Capítulo 7

Conclusiones y propuestas

E N este capítulo se describirán las conclusiones a las que se ha llegado después de la

realización de este TFG, analizando la consecución de los objetivos propuestos y de las
posibles propuestas o mejoras que se pueden hacer para la evolución de dicho proyecto.
La realización de este TFG ha supuesto la finalización de una de las etapas más importantes
de mi vida como estudiante. En él, se ha puesto todo el esfuerzo, ganas y conocimiento
aprendido durante los años de estudios, así como conocimientos nuevos adquiridos durante
el desarrollo del mismo.
Este proyecto surgió de una idea de experimentar con ciertas tecnologías y conseguir una
plataforma enfocada a sistemas domóticos que se pudiera desarrollar con un bajo coste y que
tuviera una aplicación importante de ayudar a mejorar la vida de las personas. De esta idea,
se propusto el principal objetivo de crear una plataforma para la monitorización y el control
de sistemas inteligentes de bajo coste.
Para llegar a la consecución del objetivo principal de este TFG se han tenido que abordar
los siguientes hitos:

Creación de una arquitectura cliente servidor basada en tecnologías web, mediante las
cuáles se han creado las distintas partes del sistema.
Implementación de un núcleo servidor, formado por el broker del sistema y el servidor
web para la conexión de clientes móviles.
Utilización del protocolo MQTT para la creación y funcionamiento de nuestro proto-
colo domótico.
Montaje de circuitos electrónicos independientes pero funcionalmente conectados con
uso de hardware libre, para la simulación y validación del sistema.
Implementación de un sistema inteligente capaz de utilizar la información generada
en el sistema para reconocer acciones de los usuarios y determinar posibles acciones
futuras.
Desarrollo de una aplicación móvil para el control y seguimiento del sistema a través
de internet desde cualquier punto del planeta, con una interfaz fácil y sencilla para
mostrarle la información al usuario.

63
 Implantar el sistema en un ordenador de bajo coste.
Utilización de un stack tecnológico completamente web para el desarrollo del sistema
completo.
Facilidad para implementar nuevos circuitos y programas de control para extender y
escalar el sistema.
Uso de ficheros de configuración para mejorar la escalabilidad del sistema y minimizar
modificaciones del código fuente para posibles ampliaciones del sistema.

En general y aunque se puede concluir que el objetivo de este TFG se ha conseguido casi
en su totalidad, hay ciertos aspectos que se pueden mejorar:

El sistema inteligente se ha implementado modelando la interacción del usuario en su

entorno mediante modelos ocultos de Markov. Estos modelos se han definido sin un
periodo de observación pero lo más realista posible, por lo que una mejora seríadotarlo
de aprendizaje. Para ello, una posible solución sería ejecutar una tarea diariamente por
la noche que recogiese las acciones del usuario y volviese a calcular los parámetros
del modelo HMM, con la utilización del algoritmo Baum-Welch.
La aplicación móvil recoge la información y actualiza la interfaz gráfica bajo demanda
del usuario accionando un botón de la pantalla. Una mejora sería, la utilización de
websockets (aprovechando la tecnología javascript y node) para que se actualizara en
tiempo real con los cambios del sistema.
Aunque la ampliación del sistema no es costosa gracias a la implementación usan-
do ficheros de configuración, se puede mejorar añadiendo funcionalidad al protocolo
domótico, para que los controles que se conecten al sistema sean los que den la infor-
mación de quienes son y que contienen.

64
ANEXOS

65
Anexo A

GNU Free Documentation License

Version 1.3, 3 November 2008

Copyright
c 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. <http://fsf.org/>

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing
it is not allowed.

0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document
“free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or noncommercially. Secondarily, this License
preserves for the author and publisher a way to get credit for their work, while not being considered
responsible for modifications made by others.

This License is a kind of “copyleft”, which means that derivative works of the document must
themselves be free in the same sense. It complements the GNU General Public License, which is a
copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software
needs free documentation: a free program should come with manuals providing the same freedoms
that the software does. But this License is not limited to software manuals; it can be used for any
textual work, regardless of subject matter or whether it is published as a printed book. We recommend
this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by
the copyright holder saying it can be distributed under the terms of this License. Such a notice grants
a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated
herein. The “Document”, below, refers to any such manual or work. Any member of the public is a
licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work
in a way requiring permission under copyright law.

66
 A “Modified Version” of the Document means any work containing the Document or a portion of
it, either copied verbatim, or with modifications and/or translated into another language.

A “Secondary Section” is a named appendix or a front-matter section of the Document that deals
exclusively with the relationship of the publishers or authors of the Document to the Document’s
overall subject (or to related matters) and contains nothing that could fall directly within that overall
subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not
explain any mathematics.) The relationship could be a matter of historical connection with the subject
or with related matters, or of legal, commercial, philosophical, ethical or political position regarding
them.

The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those
of Invariant Sections, in the notice that says that the Document is released under this License. If
a section does not fit the above definition of Secondary then it is not allowed to be designated as
Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any
Invariant Sections then there are none.

The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-
Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover
Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A “Transparent” copy of the Document means a machine-readable copy, represented in a for-

mat whose specification is available to the general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images composed of pixels) generic paint programs
or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters
or for automatic translation to a variety of formats suitable for input to text formatters. A copy ma-
de in an otherwise Transparent file format whose markup, or absence of markup, has been arranged
to thwart or discourage subsequent modification by readers is not Transparent. An image format is
not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called
“Opaque”.

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo
input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-
conforming simple HTML, PostScript or PDF designed for human modification. Examples of trans-
parent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that
can be read and edited only by proprietary word processors, SGML or XML for which the DTD
and/or processing tools are not generally available, and the machine-generated HTML, PostScript or
PDF produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plus such following pages as
are needed to hold, legibly, the material this License requires to appear in the title page. For works in
formats which do not have any title page as such, “Title Page” means the text near the most prominent
appearance of the work’s title, preceding the beginning of the body of the text.

The “publisher” means any person or entity that distributes copies of the Document to the pu-
blic.

67
 A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely
XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here
XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedica-
tions”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the
Document means that it remains a section “Entitled XYZ” according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License
applies to the Document. These Warranty Disclaimers are considered to be included by reference in
this License, but only as regards disclaiming warranties: any other implication that these Warranty
Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommer-
cially, provided that this License, the copyright notices, and the license notice saying this License
applies to the Document are reproduced in all copies, and that you add no other conditions whatsoe-
ver to those of this License. You may not use technical measures to obstruct or control the reading
or further copying of the copies you make or distribute. However, you may accept compensation in
exchange for copies. If you distribute a large enough number of copies you must also follow the
conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display
copies.

3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Docu-
ment, numbering more than 100, and the Document’s license notice requires Cover Texts, you must
enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts
on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly
identify you as the publisher of these copies. The front cover must present the full title with all words
of the title equally prominent and visible. You may add other material on the covers in addition. Cop-
ying with changes limited to the covers, as long as they preserve the title of the Document and satisfy
these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones
listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must
either include a machine-readable Transparent copy along with each Opaque copy, or state in or
with each Opaque copy a computer-network location from which the general network-using public
has access to download using public-standard network protocols a complete Transparent copy of the
Document, free of added material. If you use the latter option, you must take reasonably prudent steps,
when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will
remain thus accessible at the stated location until at least one year after the last time you distribute an

68
Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistri-
buting any large number of copies, to give them a chance to provide you with an updated version of
the Document.

4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections
2 and 3 above, provided that you release the Modified Version under precisely this License, with the
Modified Version filling the role of the Document, thus licensing distribution and modification of
the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the
Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document,
and from those of previous versions (which should, if there were any, be listed in the History
section of the Document). You may use the same title as a previous version if the original
publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship
of the modifications in the Modified Version, together with at least five of the principal authors
of the Document (all of its principal authors, if it has fewer than five), unless they release you
from this requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright
notices.
F. Include, immediately after the copyright notices, a license notice giving the public permis-
sion to use the Modified Version under the terms of this License, in the form shown in the
Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts
given in the Document’s license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at
least the title, year, new authors, and publisher of the Modified Version as given on the Title
Page. If there is no section Entitled “History” in the Document, create one stating the title, year,
authors, and publisher of the Document as given on its Title Page, then add an item describing
the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Trans-
parent copy of the Document, and likewise the network locations given in the Document for
previous versions it was based on. These may be placed in the “History” section. You may omit

69
 a network location for a work that was published at least four years before the Document itself,
or if the original publisher of the version it refers to gives permission.
K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the
section, and preserve in the section all the substance and tone of each of the contributor ack-
nowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles.
Section numbers or the equivalent are not considered part of the section titles.
M. Delete any section Entitled “Endorsements”. Such a section may not be included in the
Modified Version.
N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with
any Invariant Section.
O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary
Sections and contain no material copied from the Document, you may at your option designate some
or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the
Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of
your Modified Version by various parties—for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words
as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage
of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by)
any one entity. If the Document already includes a cover text for the same cover, previously added by
you or by arrangement made by the same entity you are acting on behalf of, you may not add another;
but you may replace the old one, on explicit permission from the previous publisher that added the
old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their
names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING
DOCUMENTS

You may combine the Document with other documents released under this License, under the
terms defined in section 4 above for modified versions, provided that you include in the combination
all of the Invariant Sections of all of the original documents, unmodified, and list them all as Inva-
riant Sections of your combined work in its license notice, and that you preserve all their Warranty
Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant
Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same
name but different contents, make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section if known, or else a unique

70
number. Make the same adjustment to the section titles in the list of Invariant Sections in the license
notice of the combined work.

In the combination, you must combine any sections Entitled “History” in the various original do-
cuments, forming one section Entitled “History”; likewise combine any sections Entitled “Acknow-
ledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endor-
sements”.

5. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this
License, and replace the individual copies of this License in the various documents with a single
copy that is included in the collection, provided that you follow the rules of this License for verbatim
copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under
this License, provided you insert a copy of this License into the extracted document, and follow this
License in all other respects regarding verbatim copying of that document.

6. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents
or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the
copyright resulting from the compilation is not used to limit the legal rights of the compilation’s
users beyond what the individual works permit. When the Document is included in an aggregate, this
License does not apply to the other works in the aggregate which are not themselves derivative works
of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the
Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on
covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the
Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole
aggregate.

7. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Docu-
ment under the terms of section 4. Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include translations of some or all Invariant
Sections in addition to the original versions of these Invariant Sections. You may include a translation
of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided
that you also include the original English version of this License and the original versions of those
notices and disclaimers. In case of a disagreement between the translation and the original version of
this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the

71
requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual
title.

8. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided
under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and
will automatically terminate your rights under this License.

However, if you cease all violation of this License, then your license from a particular copyright
holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally ter-
minates your license, and (b) permanently, if the copyright holder fails to notify you of the violation
by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright
holder notifies you of the violation by some reasonable means, this is the first time you have received
notice of violation of this License (for any work) from that copyright holder, and you cure the violation
prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have
received copies or rights from you under this License. If your rights have been terminated and not
permanently reinstated, receipt of a copy of some or all of the same material does not give you any
rights to use it.

9. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation
License from time to time. Such new versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies
that a particular numbered version of this License “or any later version” applies to it, you have the
option of following the terms and conditions either of that specified version or of any later version that
has been published (not as a draft) by the Free Software Foundation. If the Document does not specify
a version number of this License, you may choose any version ever published (not as a draft) by the
Free Software Foundation. If the Document specifies that a proxy can decide which future versions
of this License can be used, that proxy’s public statement of acceptance of a version permanently
authorizes you to choose that version for the Document.

10. RELICENSING
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server
that publishes copyrightable works and also provides prominent facilities for anybody to edit those
works. A public wiki that anybody can edit is an example of such a server. A “Massive Multiauthor
Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published
on the MMC site.

72
 “CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Crea-
tive Commons Corporation, a not-for-profit corporation with a principal place of business in San
Francisco, California, as well as future copyleft versions of that license published by that same orga-
nization.

“Incorporate” means to publish or republish a Document, in whole or in part, as part of another

Document.

An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were
first published under this License somewhere other than this MMC, and subsequently incorporated
in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus
incorporated prior to November 1, 2008.

The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on
the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.

73
Referencias

[Ama] Amazon.es. Kit de sensores y actuadores. https://images-na.

ssl-images-amazon.com/images/I/81r%2BzBQ%2Bv2L. AA1500 .jpg. Retrieved

on August, 2016.

[Apr] Aprendizaje Automático. https://es.wikipedia.org/wiki/

Aprendizaje autom%C3%A1tico. Retrieved on December, 2016.

[Ard] Arduino. Arduino. https://www.arduino.cc/en/Main/ArduinoBoardUno. Re-

trieved on May, 2016.

[Auta] Autentia. Checklist de Scrum de Autentia. http://autentia.com/2014/03/

27/checklist-de-scrum-de-autentia/. Retrieved on May, 2016.

[Autb] Kevin Boone / UK Automation. Using X10 for Home Automation. http://
www.uk-automation.co.uk/blog/using-x10-for-home-automation/. Retrie-

ved on August, 2016.

[BoK] Scrum Manager BoK. El manifiesto ágil. http://www.scrummanager.net/

bok/index.php?title=El manifiesto %C3%A1gil. Retrieved on May, 2016.

[Ciu] Roberto Cerveró Ciudad. Sistema control domótica Arduino. https://

en.goteo.org/project/sistema-control-domotica-arduino/. Retrieved on

March, 2016.

[CM] Cadena de Markov. https://es.wikipedia.org/wiki/Cadena de M%C3%A1rkov.

Retrieved on January, 2017.

[Cora] Echelon Corporation. Especificaciones KNX. http://www.echelon.com/

assets/blt893a8b319e8ec8c7/078-0183-01B Intro to LonWorks Rev 2.pdf.

Retrieved on August, 2016.

[Corb] Echelon Corporation. Especificación protocolo LonTalk. http://www.

enerlon.com/JobAids/Lontalk%20Protocol%20Spec.pdf. Retrieved on Au-

gust, 2016.

74
[cvb] KNX Association cvba. El protocolo de comunicaciones, el lenguaje de la
domótica. https://www.knx.org/knx-es/knx/tecnologia/especificaciones/
index.php. Retrieved on August, 2016.

[dCeIdlCPUJC] Gloria Inés Alvarez V. Departamento de Ciencias e Ingeniería de la Compu-

tación Pontificia Universidad Javeriana Cali. Bases Formales de la Compu-
tación: Sesión 3. Modelos Ocultos de Markov. http://cic.puj.edu.co/wiki/
lib/exe/fetch.php?media=materias:bfc sesion3 2008-2.pdf. Retrieved on

January, 2017.

[dDeIC] Asociación Española de Domótica e Inmótica CEDOM. ¿Qué es la domó-

tica? http://www.cedom.es/sobre-domotica/que-es-domotica. Retrieved on
March, 2016.

[Ele] LG Electronics. Dispositivo móvil LG G4. http://www.lg.com/es/

telefonos-moviles/lg-G4-H815-CUERO-CAMEL. Retrieved on June, 2016.

[Esp] Pablo Espeso. Las 3 tecnologías clave para el internet

de las cosas. http://www.xataka.com/internet-of-things/

las-3-tecnologias-clave-para-el-internet-de-las-cosas. Retrieved
on March, 2016.

[ext] extremeprogramming.org. Extreme Programming: A gentle introduction.

http://www.extremeprogramming.org/. Retrieved on May, 2016.

[FM] OpenWebinars Fernando Martínez. Tutorial Arduino: Entradas (2): Bo-

tones. https://openwebinars.net/tutorial-arduino-entradas-2-botones/.
Retrieved on August, 2016.

[Foua] Raspberry PI Foundation. Raspberry. https://www.raspberrypi.org/. Re-

trieved on May, 2016.

[Foub] The Apache Software Foundation. Apache Cordova Logo. https://

cordova.apache.org/docs/en/latest/. Retrieved on August, 2016.

[Fouc] The Apache Software Foundation. Apache Cordova Logo. https://

cordova.apache.org/. Retrieved on August, 2016.

[Fri] Walter Fritz. Vista general del sistema inteligente. http://www.

intelligent-systems.com.ar/overviewSp.htm. Retrieved on June, 2016.

[Gar] Javier Garzás. ¿Qué es el método Kanban para la gestión de proyec-

tos? http://www.javiergarzas.com/2011/11/kanban.html. Retrieved on May,
2016.

75
[Gon] Antony García González. Prototipo de sistema de do-
motica basado en Arduino. http://panamahitek.com/

proyecto-prototipo-de-sistema-de-domotica-basado-en-arduino/.

Retrieved on March, 2016.

[Loga] LogoTypes101.com. Android Logo. http://www.logotypes101.com/logo/

android-4. Retrieved on August, 2016.

[Logb] LogoTypes101.com. Blackberry Logo. http://www.logotypes101.com/logo/

blackberry. Retrieved on August, 2016.

[Logc] LogoTypes101.com. CSS3 Logo. http://www.logotypes101.com/logo/css3.

Retrieved on August, 2016.

[Logd] LogoTypes101.com. HTML5 Logo. http://www.logotypes101.com/logo/

html5. Retrieved on August, 2016.

[Loge] LogoTypes101.com. iOS Logo. http://www.logotypes101.com/logo/ios-1.

Retrieved on August, 2016.

[Logf] LogoTypes101.com. Javascript Logo. http://www.logotypes101.com/logo/

javascript. Retrieved on August, 2016.

[Mad] Madrid.org. Programa conjunto de investigación y desarrollo "Vida

cotidiana asistida por el entorno"(AAL). http://www.madrid.org/cs/

Satellite?blobcol=urldata&blobheader=application%2Fpdf&blobkey=id&

blobtable=MungoBlobs&blobwhere=1352807269374&ssbinary=true. Retrieved
on June, 2016.

[Mic] JXTA Sun Microsystems. JXTA The Language and Platform Independent
Protocol for P2P Networking. https://jxta.kenai.com/. Retrieved on De-
cember, 2016.

[mon] mongodb.com. MongoDB Logo. https:

//webassets.mongodb.com/ com assets/cms/

MongoDB-Logo-5c3a7405a85675366beb3a5ec4c032348c390b3f142f5e6dddf1d78e2df5cb5c.

png. Retrieved on August, 2016.

[Mqt] Mqtt.org. iOS Logo. http://mqtt.org/. Retrieved on August, 2016.

[NM15] Joel J.P.C. Rodrigues Nuno M.Garcia. Ambient Assisted Living. CRC Press,
2015.

[Nod] Nodejs.org. iOS Logo. https://nodejs.org/static/images/logos/

nodejs-new-pantone-black.png. Retrieved on August, 2016.

76
[OAS] OASIS. MQTT Version 3.1.1 Specification. http://docs.oasis-open.org/
mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html. Retrieved on June, 2016.

[OG] BricoGeek.blog Oscar Gonzalez. Juego TETRIS con Arduino

y pantalla LCD color. http://blog.bricogeek.com/noticias/arduino/

juego-tetris-con-arduino-y-pantalla-lcd-color/. Retrieved on August,

2016.

[pro] proyectosagiles.org. Qué es SCRUM. https://proyectosagiles.org/

que-es-scrum/. Retrieved on May, 2016.

[Ras] Raspberrypi.org. iOS Logo. https://www.raspberrypi.org/wp-content/

uploads/2011/10/Raspi-PGB001.png. Retrieved on August, 2016.

[RdlHdD12] Carmen Lasa Gómez Rafael de las Heras del Dedo, Alonso Álvarez García.
Métodos Ágiles y Scrum. Anaya Multimedia, 2012.

[Red] Red Bayesiana. https://es.wikipedia.org/wiki/Cadena de M%C3%A1rkov.

Retrieved on January, 2017.

[Rei] José L. Ruiz Reina. Tema 8: Introducción a las Redes Bayesianas. https:
//www.cs.us.es/cursos/ia2-2005/temas/tema-08.pdf. Retrieved on January,

2017.

[RII] Comunidad RIIAL. ¿Qué es la Inteligencia Artificial? http://www.riial.

org/que-es-la-inteligencia-artificial/. Retrieved on December, 2016.

[Sei] Gildo Seisdedos. ¿Qué es una smart city? http://www.coit.

es/publicaciones/bit/bit188/monograficoseisdedos.pdf. Retrieved on
March, 2016.

[Sis] Sistema Inteligente. https://es.wikipedia.org/wiki/Sistema inteligente.

Retrieved on December, 2016.

[SO] blog.davebouwman.com Stefan O. Marionette with Maps:

Series Intro. http://blog.davebouwman.com/2013/02/18/

marionette-with-maps-series-intro/. Retrieved on August, 2016.

[Uba] Diego Romano Ubalde. Casa domótica con Arduino y An-

droid. https://diegoromanoubalde.wordpress.com/proyectos-realizados/
casa-domotica-eficiente/. Retrieved on March, 2016.

[Viv] Domótica Viva. Ejemplo entorno domótico. http://www.domoticaviva.com/

PHP/newsphp 2009.php?id=272. Retrieved on June, 2016.

77
[WEB] DomoPrac WEB. Especificaciones KNX. http://www.

domoprac.com/protocolos-de-comunicacion-y-sistemas-domoticos/

el-protocolo-de-comunicaciones-el-lenguaje-de-la-domotica.html.

Retrieved on August, 2016.

[Wik] Wikidot.com. Redes Bayesianas. http://redbay.wikidot.com/start. Re-

trieved on December, 2016.

[yDLdIGdA] Iñaki Vázquez y Diego L.Z. de Ipiña GZ. de Artaza. Inteligencia Ambien-
tal: la presencia invisible. http://paginaspersonales.deusto.es/dipina/
publications/AmI.pdf. Retrieved on June, 2016.

[Zü] Dr. Hubert Kaeslin. Microelectronics Design Center.ETH Zürich. A Gentle

Introduction to Dynamic Programming and the Viterbi Algorithm. http:
//www.cambridge.org/resources/0521882672/7934 kaeslin dynpro new.pdf.

Retrieved on January, 2017.

78
Este documento fue editado y tipografiado con LATEX empleando
la clase esi-tfg (versión 0.20170122) que se puede encontrar en:
https://bitbucket.org/arco group/esi-tfg

[respeta esta atribución al autor]

79