Graduado en Ingeniería informática

Sistema Domótico con servidor mqtt y controlado por

aplicación Web

Home automation system with mqtt server and

controlled by Web application

Realizado por
Rafael Ordóñez molina

Tutorizado por
Juan Carlos Tejero Calado

Departamento
Electrónica

MÁLAGA, junio de 2022

 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA
INFORMÁTICA

GRADUADO EN INGENIERÍA INFORMATICA

Sistema Domótico con servidor mqtt y controlado por

aplicación Web

Home automation system with mqtt server and

controlled by Web application

Realizado por
Rafael Ordóñez Molina

Tutorizado por
Juan Carlos Tejero Calado

Departamento
Electrónica

UNIVERSIDAD DE MÁLAGA
MÁLAGA, JUNIO DE 2022

Fecha defensa: Julio de 2022

 Abstract
At present, many companies market home automation systems that are ready
to use, but with the defect of being external to the home where they are installed,
compromising the security of the home’s inhabitants.

To solve this problem, this Final Degree project develops a fully functional
home automation system within a network. For this purpose, a web system, a
web client, and a software for devices based on the ESP8266 processor have been
developed, connecting the devices with the web server based on “Api rest” archi-
tecture, by means of a MQTT server.

The final architecture of the system is consolidated by two large systems, the
web system and the Iot devices system. The web system is packaged using doc-
ker, which will allow an easy deployment of the system, and the intelligent de-
vices will have a multi-device software, that is, the same software contains the
different types of configurations existing in the system.

Finally, we will obtain a complete system that will allow the society to have a
private home automation software, free and easy to install and use.

Keywords: Home automation, Mqtt, Rest Api, Esp8266

2
 Resumen
En la actualidad numerosas empresas comercializan sistemas domóticos lis-
tos para usar, pero con el defecto de ser sistemas externos al hogar donde son
instalados, comprometiendo la seguridad de los habitantes del mismo.

Para solucionar dicho problema, este trabajo de Fin de Grado desarrolla un

sistema domotico completamente funcional dentro de una red. Para ello se han
desarrollado un sistema web, un cliente web, y un software para dispositivos
basados en el procesador ESP8266, conectando a los dispositivos con el servidor
web basado en arquitectura “Api rest”, mediante un servidor MQTT.

La arquitectura final del sistema queda consolidada por dos grandes siste-
mas, el sistema web y el sistema de los dispositivos Iot. El sistema web se en-
cuentra empaquetado usando docker, lo que permitirá un fácil despliegue del
mismo, y los dispositivos inteligentes, dispondrán de un software multi-dispositivo,
esto es, un mismo software contiene los diferentes tipos de configuraciones exis-
tentes en el sistema.

Finalmente obtendremos un sistema completo que permitirá a la sociedad

disponer de un software domotico privado, gratuito y fácil de instalar y usar.

Palabras clave: Domótica, Mqtt, Rest Api, Esp8266

3
4
 Índice
1. Introducción 7
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Tecnologías y herramientas de desarrollo 11

2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1. Lenguajes de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3. Análisis y diseño del sistema 21

3.1. Análisis de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.3. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Arquitectura y Diseño del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1. Visión General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.2. Sistema Interno de los Dispositivos Inteligentes . . . . . . . . . . . . . . . 40
3.2.3. Sistema Interno del servidor Web y Cliente Web . . . . . . . . . . . . . . . 49
3.2.4. Empaquetado y Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4. Conclusiones y Líneas Futuras 63

4.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2. Líneas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Apéndice A. Manual de
Instalación 69
A.1. Instalación del servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2. Despliegue de fichero docker-compose . . . . . . . . . . . . . . . . . . . . . . . . 69

5
 A.3. Instalación del firmware dispositivos Iot . . . . . . . . . . . . . . . . . . . . . . . 71

Apéndice B. Manual de
Usuario 73
B.1. Configuración Automática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.1.1. Dispositivo Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.1.2. Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.2. Configuración Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.2.1. Dispositivo Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.2.2. Servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.3. Modificar un dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.4. Eliminar un Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6
 1
Introducción
1.1. Motivación

En los últimos años se ha incrementado el uso de sistemas domóticos en los hogares Es-
pañoles, esto ha provocado que cada vez mas empresas fabriquen productos con caracterís-
ticas similares. Todos estos sistemas domóticos comerciales, permiten que la gran mayoría
de la población pueda domotizar sus hogares de una forma económica y sencilla.

Sin Embargo, la mayoría disponen de código privativo y los datos de todos los hogares
están alojados en servidores centrales, lo que implica un alto riesgo de seguridad.

En este caso, se justifica el objeto de este trabajo final de grado en base al desarrollo de
un software capaz de crear un sistema domótico de código libre y de fácil instalación para
toda la sociedad.

1.2. Objetivos

El objetivo principal de este trabajo final de grado es el desarrollo de un sistema domó-

tico completo de código libre, el cual podrá ser instalado en dispositivos compatibles con
el framework “Arduino”. Serán configurados mediante un sistema de configuración inicial y
pagina web propia, ayudando así a que el sistema sea sencillo de utilizar.

Todo el sistema domótico se encontrara en la red local del hogar, aunque podrá ser ex-
puesto al exterior del mismo. Para lograr estas metas, hay que cumplir una serie de objetivos
específicos:

7
 Desarrollo de software en C++ y Arduino para una placa con procesador ESP8266, este
software sera capaz de conectarse a un servidor MQTT, enviando y recibiendo infor-
mación de los dispositivos conectados, a su vez, este software, podrá ser usado para
hardware con diferentes fines, en concreto:

• Dispositivo Interruptor, por ejemplo, para controlar remotamente una lampara.

• Dispositivo para control de persianas.

• Dispositivo de interruptor remoto.

• Dispositivo de Control remoto para persianas.

• Dispositivo de control de luminosidad.

Desarrollo de API REST en Java y Spring Boot para la conexión con servidor MQTT y
control de todos los dispositivos, de esta forma se puede integrar el sistema de control
con cualquier cliente, como POSTMAN o un sistema desarrollado en Javascript.

Desarrollo de pagina web cliente “responsive”, en HTML, JAVASCRIPT Y CSS, la cual

emitirá peticiones a la API REST, de esta forma el usuario podrá controlar todo el sis-
tema domótico desde dispositivos móviles o de escritorio.[1]

Despliegue de un servidor MQTT, en concreto MOSQUITTO, el cual permitirá la co-

municación entre los dispositivos y el servidor web.

Empaquetado de todo el sistema, de forma que el usuario final, pueda desplegar el

sistema completo con una simple secuencia de comandos, tanto en una placa de de-
sarrollo“RASPBERRY PI” como en un gran servidor

De esta forma, obtenemos una interacción directa entre el usuario y el dispositivo a contro-
lar, de una forma dinámica y fluida para el usuario final.

8
1.3. Estructura del documento

El documento se encuentra dividido en los siguientes capítulos:

Capitulo 1: Introducción. En este primer capitulo introduciremos el proyecto realiza-

do, donde hablaremos sobre la motivación del proyecto y los objetivos.

Capitulo 2: Tecnologías y Herramientas. En el desarrollo de este capitulo, se pretende

plasmar todas las herramientas y tecnologías utilizadas a lo largo del proyecto.

Capitulo 3: Análisis y diseño del sistema. Este capitulo se encuentra dividido en dos
grandes bloques:

1. Análisis de requisitos: En primer lugar se realiza un estudio de los requisitos del

proyecto, así como de los casos de uso del mismo.

2. Arquitectura del sistema: En esta sección se plasmara la arquitectura completa

del sistema, así como el funcionamiento del mismo.

Capitulo 4: Conclusiones y futuras lineas de investigación. Se realizara una valoración

del proyecto realizado y se plantearan lineas futuras.

Referencias: Capitulo de las referencias indicadas a lo largo del proyecto

Apéndice A: Instalación del sistema

Apéndice B : Manual de Usuario

9
10
 2
Tecnologías y
herramientas de
desarrollo
Esta sección describe las tecnologías utilizadas durante el desarrollo del proyecto.
Todas ellas han sido elegidas por su flexibilidad y escalabilidad, permitiendo así, la creación
de nuevas lineas a futuro.

2.1. Hardware

A continuación se describen las tecnologías hardware utilizadas:

NodeMCU ESP8266

NodeMcu es una placa de desarrollo basada en el procesador ESP8266, y en el fra-

mework de desarrollo de Arduino. Este procesador es muy utilizado en el internet de
las cosas, Iot, dado que incorpora un modulo wifi, y potencia suficiente para poder
controlar y monitorizar la mayoría de los dispositivos de los hogares.NodeMCU viene
con un firmware pre-instalado el cual nos permite trabajar con el lenguaje C++ y el
framework de arduino. Como partes importantes, incluye un microprocesador a una
frecuencia de reloj de 80MHz/160MHz, Wi-Fi Direct (P2P), soft-AP, y 17 pines digita-
les, lo que nos permite que el dispositivo funcione en zonas de difícil acceso conectado
remotamente a la red del hogar.

11
En nuestro caso, es utilizada como base de los dispositivos Iot, dada la versatilidad de
la que dota a los mismos, aunque, podría se utilizado otro procesador compatible con
Arduino.

Figura 1: Placa de desarrollo Node MCU con ESP8266 Integrado

[2]

Domoboard V2.0 Juan Carlos Tejero. Dept Electronica

Se trata de una placa de desarrollo creada por el profesor Juan Carlos Tejero Calado
para impartir la docencia de la Asignatura “ Electrónica para la domótica”. Esta placa
incluye dispositivos, como relés, sensores o pulsadores, lo que permite un fácil desa-
rrollo de todo al sistema, usando una única placa donde se alojan todos los compo-
nentes necesarios.

Figura 2: Domoboard V2.0 Juan Carlos Tejero. Dept Electronica

12
Esta placa, sera utilizada durante el desarrollo del proyecto para realizar la programa-
ción y pruebas de los dispositivos inteligentes de una forma mas rápida y directa, sin
la necesidad de disponer de varios dispositivos independientes. Podemos destacar los
siguientes componentes utilizados de la misma:

• Sensor de luminosidad.
En concreto hablamos de una foto resistencia, un semiconductor que responde
según la cantidad de luz que incide sobre el mismo, cuando este no esta expuesto
a radiación lo suficiente luminosa, los electrones están firmemente unidos, emi-
tiendo un valor prácticamente nulo, sin embargo, cuando incide la cantidad de
luz suficiente sobre la superficie del mismo, esta energía libera electrones con lo
que hace al material mas conductor. En concreto, este sensor será utilizado en el
sistema para controlar una lampara o similar en función de la luz del ambiente.

Figura 3: Sensor LDR

[3]

• Pulsadores
En este caso disponemos de pulsadores “push button”, los cuales cuando son
pulsados permiten el paso de la corriente, por tanto, podremos leer el estado de
los mismos desde el firmware de los dispositivos.
Estos, serán utilizados como interruptores remotos para las persianas y los dis-
positivos de apago y encendido.

13
• Relés
Un relé es un interruptor, más frecuentemente electromagnético, que utiliza una
pequeña corriente para accionar un circuito mayor. Básicamente, se aplica una
señal en la entrada que enciende otro circuito conectado en la salida, sin necesi-
dad de supervisión humana.
Esto nos permite controlar dispositivos como lamparas, o persianas emitiendo
una señal sobre estos.

Figura 4: Relé
[4]

14
2.2. Software

En esta subseccion, vamos a diferenciar entre lenguajes de programación y herramientas

utilizadas:

2.2.1. Lenguajes de programación

Java
Es una plataforma de desarrollo orientada a objetos, el código generado para java, co-
rre sobre JVM (Java Virtual Machine), la cual esta disponible en la mayoría de sistemas
operativos. Java es ampliamente utilizada en sistemas empresariales, y a lo largo del
grado en Ingeniería Informática, es la tecnología de desarrollo mas usada, por lo que
se ha decidido utilizar esta tecnología, dado que nos ofrece un gran abanico de posi-
bilidades además de tener experiencia usando dicha tecnología. Hemos elegido dicho
lenguaje para el desarrollo de la “Api Rest”.

Spring Boot
Se trata de uno de los Frameworks mas usados en el mundo para JAVA, este framework
nos permite simplificar el código, dotando a java de características como la escalabili-
dad, seguridad y simplicidad entre otras.

En este caso ha sido utilizado para facilitar la creación de una API REST, la cual sera
detallada posteriormente. También, proporciona conexión a un servidor MQTT, por
conexión segura, inicio de sesión y otras características a tener en cuenta.
Gracias a Spring Boot, se obtiene una aplicación empaquetada en formato war o jar,
la cual puede ser desplegada sobre un servidor TOMCAT, permitiendo así el acceso a
clientes tales como POSTMAN o una interfaz web. Hemos elegido dicho framework
para el desarrollo de la “Api Rest”.

15
JPA
JPA[5] es la interfaz que ofrece Java para implementar un ORM (Framework Object Re-
lational Mapping), que permite interactuar con la base de datos por medio de objetos,
de esta forma, JPA es el encargado de convertir los objetos Java en instrucciones para
el sistema gestor de base de datos.

C++
Se trata de un lenguaje de programación cuya intención de su creación fue extender al
lenguaje de programación C mecanismos que permiten la manipulación de objetos.
En ese sentido, desde el punto de vista de los lenguajes orientados a objetos, C++ es
un lenguaje híbrido.[6] En este caso se ha utilizado para la programación de las placas
de desarrollo, en concreto, sera utilizado junto al framework Arduino, explicado en el
siguiente punto.
C++ es uno de los lenguajes mas usados en sistemas empotrados, y aporta gran escala-
bilidad y robustez al sistema, además, el framework Arduino se integra perfectamente
con dicho lenguaje, lo que nos permite programar los dispositivos IoT de una forma
robusta.

Arduino
Arduino es un framework de desarrollo para dispositivos IoT en el lenguaje[7] C o C++,
el cual define define una API común de alto nivel para un facil acceso al hardware de
los dispositivos, por ejemplo, almacenar en la memoria EEPROM del chip datos no
volatites o la abstraccion de operaciones como el acceso a entradas/salidas digitales o
la gestión de interrupciones.

Arduino proporciona gran cantidad de librerías “open source”, que nos permite añadir
funciones a dichos dispositivos, en nuestro caso, permitirá la opción de usar la librería
"PubSubClient", de forma que el dispositivo actúa como cliente de un servidor MQTT
y se comunique posteriormente con la aplicación web.[8]

Javascript
Se trata de un lenguaje de programación interpretado, esta orientado a objetos, muy
poco tipado y dinamico. Javascript nos permite conectar la API REST del sistema do-
motico con la interfaz web para el cliente final.También puede realizar gran cantidad

16
de funcionalidades, como dar la capacidad a las paginas web de ser dinámicas, o en
nuestro caso, hacer peticiones al servidor Java Spring mediante.

Html
Se trata de un lenguaje de marcado de texto para la creación de paginas web, es el mas
usado en el mundo, y es el encargado de dar la estructura a nuestro cliente Web.

Css
Es un lenguaje de diseño gráfico para definir y crear la presentación de un documento
estructurado escrito en un lenguaje de marcado. Css nos permitirá definir estilos a
nuestro cliente web.

Bootstrap Se trata de un Framework para aplicaciones “frontEnd”, el cual genera códi-

go con estilos predefinidos y adaptados a la mayoría de dispositivos. Gracias a Boots-
trap, obtenemos una interfaz sencilla y agradable a la vista.

SqLite: Se trata de un pequeño sistema gestor de base de datos, de software libre, que
permite almacenar información en dispositivos empotrados de una forma sencilla,
eficaz, potente, rápida y en equipos con pocas capacidades de hardware, como puede
ser un dispositivo de un sistema domotico.

17
2.2.2. Herramientas

Comunicación pub/sub

• Servidor MQTT
MQTT [9] un protocolo de mensajería ligero de publicación/suscripción diseña-
do para telemetría M2M (máquina a máquina) en entornos de bajo ancho de
banda. Por tanto se convierte en un entorno ideal para conectar dispositivos con
potencia y ancho de banda limitados. Esto ha hecho que elijamos este soporte
para la comunicación entre el servidor web y los dispositivos IoT. La idea prin-
cipal, es utilizar este protocolo de publicación y suscripción, para que cada dis-
positivo tenga una ruta asociada, y el servidor web envíe datos a la misma, gene-
rando una reacción en el dispositivo Iot y viceversa.

• Mosquitto
Se trata de una implementación del protocolo MQTT open source, creado por
la fundación eclipse. Es una opción de servidor MQTT ligera, lo que hace que
sea una opción perfecta para desplegar dicho servidor sobre dispositivos de baja
potencia como Raspberry Pi

Servidor TOMCAT
Se trata de un servidor para ejecutar aplicaciones Java. Es ampliamente utilizado en
la industria, y destaca por su robustez y facilidad de uso, ya que al ser un contenedor
de servlets, brinda la opción de ejecutar una aplicación java completa con el simple
hecho de seleccionar un paquete war o jar. Este sera utilizado durante el desarrollo del
proyecto, aunque no sera la opción elegida para usarlo en un entorno real.

Eclipse
Eclipse es una plataforma de desarrollo, compuesto por un conjunto de herramientas
de programación de código abierto y multiplataforma, diseñada para ser extendida de
forma indefinida a través de plug-in. Este IDE ha sido elegido ya que no supone coste
alguno al ser open source, es ampliamente utilizado en el mundo empresarial, y es el
mas usado durante el desarrollo del grado de Ingeniería Informatica

18
Visual Studio Code
Se trata de un editor de codigo desarrollado por Microsoft, el cual ofrece gran can-
tidad de extensiones privativas o de la comunidad, lo que hace que sea un software
altamente escalable. Principalmente podemos destacar que incluye soporte para la
depuración, control integrado de Git, resaltado de sintaxis, finalización inteligente de
código, fragmentos y refactorización de código.

PlatformIO
PlatformIO es un ecosistema para el desarrollo de sistemas empotrados e IoT, el cuál
facilita y mucho la gestión de proyectos de software empotrados, gestión de depen-
dencias y librerías.

En el mercado existen gran cantidad de alternativas, pero este fue elegido gracias a la
cantidad de librerías incluidas en sus repositorios, asi como la búsqueda automática
en otros repositorios como gitHub. También incluye conexión directa con la placa que
esta siendo programada, asi como debug, lo que hace que sea un entorno de desarrollo
muy completo.

Docker: Es una herramienta que nos permite crear contenedores independientes de

nuestras aplicaciones y sistemas, permitiendo crear un sistema aislado donde instalar
las dependencias necesarias. De esta forma, una vez que tengamos el sistema funcio-
nado, podremos realizar el empaquetado completo( servidor web y servidor mqtt), y
ser desplegado en cualquier dispositivo que pueda ejecutar docker.
Esto permitirá que el proceso del despliegue del sistema domotico se realice en cues-
tión de minutos.[10]

Figura 5: Infraestructura de docker

[11]

19
POSTMAN Es un cliente HTTP que nos da la posibilidad de testear ’HTTP requests’ a
través de una interfaz gráfica de usuario, por medio de la cual obtendremos diferentes
tipos de respuesta que posteriormente deberán ser validados.
Gracias a este software, la api rest se puede probar de una forma muy sencilla y rapida.

Diagrams.io: Se trata de una aplicación web gratuita que permite diseñar todo tipo de
diagramas, desde diagramas de base de datos, hasta complejas arquitecturas de soft-
ware en la nube. En este documento ha sido ampliamente utilizada para la creacion
de los diagramas

Umbrello:Es una herramienta gratuita para crear y editar diagramas UML desde ce-
ro, o importando las clases desde el propio código. Tiene soporte para la mayoría de
lenguajes existentes, y ha sido desarrollada por el equipo de KDE.

Finite State Machine Designer: Es una pagina web para la creacion de maquinas de
estado. Destaca por ser gratuita y muy intuitiva.

20
 3
Análisis y diseño del
sistema
3.1. Análisis de Requisitos

En esta sección vamos a analizar los requisitos necesarios para la realización del sistema.
En concreto se analizaran los requisitos funcionales, los cuales tratan de expresar las funcio-
nalidades que deberá de realizar el sistema, y los requisitos no funcionales, especificando
las restricciones del mismo. También serán especificados los casos de uso del sistema.

3.1.1. Requisitos Funcionales

RF01. Interfaz web centralizada El usuario dispondrá de una interfaz web, donde po-
drá observar el estado de todos los dispositivos conectados a la red, así como el control
de los mismos.

RF02.Iot Conectar dispositivo IoT a la red wifi del hogar. El usuario podrá conectar el
dispositivo haciendo uso de la pagina web del mismo, mediante un punto de acceso
creado por el mismo.

RF.03.Iot Configuración Manual. El usuario podrá realizar una configuración de for-

ma manual, indicando las rutas del servidor MQTT[12], para la conexión del disposi-
tivo al servidor web.

21
RF04.Iot Configuración Automática. El usuario conectara el dispositivo al servidor
web sin necesidad de especificar ninguna ruta, el dispositivo automáticamente puede
ser encontrado por el servidor Web.

RF05.Iot Software genérico para todos los dispositivos Iot. Los dispositivos IoT, usa-
ran un software genérico, permitiendo que el usuario elija el dispositivo que esta usan-
do desde la interfaz web del mismo.

RF06.Iot Eleccion del servidor MQTT.El usuario podrá elegir desde la interfaz web de
los dispositivos el servidor MQTT al que desea conectarse.

RF07.Búsqueda de nuevos dispositivos. Desde la aplicación web, el usuario podrá

visualizar todos los dispositivos disponibles para ser enlazados.

RF08.Configuración de dispositivos Externos. El sistema permitirá el control de dis-

positivos MQTT externos al mismo, configurando las rutas MQTT de dichos dispositi-
vos.

RF09.Web Modificación de dispositivos Desde la aplicación web, el usuario podrá

modificar las rutas del dispositivo, así como el nombre del mismo.

RF10. Web Eliminar Dispositivos. El usuario podrá eliminar dispositivos del sistema
web

RF11.Control de persianas. El usuario podrá añadir dispositivos Iot para el control de

persianas, así como el control de los mismos desde la aplicación web.

RF12. Control de dispositivos On/Off. El usuario podrá añadir dispositivos para el

control de dispositivos de apagado y encendido, así como controlar los mismos desde
la aplicación web.

RF13. Dispositivo físico para el control de Persianas. El usuario podrá conectar un

interruptor inteligente, el cual se conectara al servidor, para la configuración con el
dispositivo que controlará. De esta forma, las persianas, pueden ser controladas desde
un dispositivo externo a la aplicación web.

22
RF14. Dispositivo físico para el control de Dispositivos On/Off. El usuario podrá co-
nectar un interruptor inteligente, el cual se conectara al servidor, para la configuración
con el dispositivo que controlará. De esta forma,los dispositivos de encendido / apa-
gado, como una lampara, pueden ser controladas desde un dispositivo externo a la
aplicación web.

RF15. Control de luminosidad para dispositivos On/Off. El usuaria podrá configurar

un dispositivo de control de luminosidad, este sera conectado al servidor web, donde
se configuraran los limites de encendido y apagado del dispositivo que controla.

23
3.1.2. Requisitos no funcionales

RNF 0. El sistema deberá ser intuitivo de usar para la mayoría de los usuarios

RNF 1. El sistema deberá consumir bajos recursos, para poder ser desplegado en un
sistema empotrado como Raspberry Pi

RNF 2. El sistema contara con un manual para el despliegue del mismo

RNF 3.El sistema contara con un manual de uso.

Figura 6: Interfaz final del sistema

24
3.1.3. Casos de uso

En esta sección del documento, realizaremos una especificación de los casos de uso [13],
donde se explica el comportamiento del sistema o de una parte. Detallan como reacciona el
sistema a una determinada acción ejecutada por el usuario.Por tanto, describe el conjunto
de secuencias de acciones (incluyendo variantes) que ejecuta el sistema para producir un
resultado observable de interés para un actor.

Caso de Uso Conectar dispositivo Iot a la red Wifi

Actor Usuario

El usuario podrá configurar la red wifi del dispositivo inteligente

Descripción
para su posterior configuración

Referencias RF-02,RF-03, RF04

Pre-condición El usuario dispone de un dispositivo en modo SoftAp

Post-condición El sistema se queda a la espera de añadir las configuraciones restantes

1.El usuario dispone de un dispositivo en modo SoftAp

2.El Usuario accede a la red emitida por el dispositivo
Flujo normal
3.El usuario introduce el SSID de la red del hogar y la contraseña
4.El sistema queda a la espera de las demás características solicitadas

1.SSID o contraseña incorrecto

Flujo alternativo 2.El dispositivo no puede conectarse a la red
3.El usuario reinicia el dispositivo

Cuadro 1: Caso de uso, Conectar dispositivo Iot a la red wifi

25
Caso de Uso Configuración manual del dispositivo

Actor Usuario

Descripción El usuario podrá configurar manualmente el dispositivo inteligente

Referencias RF-02,RF-03

El usuario dispone de un dispositivo en modo SoftAp y

Pre-condición
previamente introduce las credenciales de la red

Post-condición El sistema es configurado con las rutas establecidas

1.El usuario dispone de un dispositivo en modo SoftAp

2.El Usuario accede a la red emitida por el dispositivo
Flujo normal 3.El usuario introduce las rutas para el control del dispositivo
4.Completa las siguientes entradas del formulario
5.El dispositivo se reinicia y se conecta al servidor MQTT

1.SSID o contraseña incorrecto

1.1.El dispositivo no puede conectarse a la red
1.2.El usuario reinicia el dispositivo
Flujo Alternativo
2.Rutas incorrectas
2.1.El dispositivo no puede ser controlado
2.2.El usuario reinicia el dispositivo

Cuadro 2: Caso de uso, Conexión Manual del dispositivo

26
Caso de Uso Configuración automática del dispositivo

Actor Usuario

Descripción El usuario podrá configurar automáticamente el dispositivo inteligente

Referencias RF-02,RF-04, RF-07

El usuario dispone de un dispositivo en modo SoftAp y

Pre-condición
previamente introduce las credenciales de la red

Post-condición El sistema web encuentra al dispositivo y lo muestra en la interfaz

1.El usuario dispone de un dispositivo en modo SoftAp

2.El Usuario accede a la red emitida por el dispositivo
3.El usuario selecciona la opción Configuración automática’
Flujo normal
4.El dispositivo es configurado para la conexión con el servidor
5.El dispositivo se reinicia
6.El sistema web encuentra el dispositivo

1.SSID o contraseña incorrecto

Flujo Alternativo 1.1.El dispositivo no puede conectarse a la red
1.2.El usuario reinicia el dispositivo

Cuadro 3: Caso de uso, Conexión Automática del dispositivo

27
Caso de Uso Eleccion del tipo de dispositivo

Actor Usuario

El usuario podrá elegir el tipo de dispositivo a configurar, dado que es

Descripción
un software genérico

Referencias RF-05

El usuario dispone de un dispositivo en modo SoftAp y

Pre-condición
previamente introduce las credenciales de la red

Post-condición El dispositivo se configura en función del dispositivo elegido

1.El usuario dispone de un dispositivo en modo SoftAp

2.El Usuario accede a la red emitida por el dispositivo
Flujo normal
3.El usuario selecciona el tipo de dispositivo que corresponda
4.El dispositivo es configurado para la conexión con el servidor

1.SSID o contraseña incorrecto

1.1.El dispositivo no puede conectarse a la red
1.2.El usuario reinicia el dispositivo
Flujo Alternativo
2.Dispositivo elegido incorrecto
2.1.El dispositivo no puede configurarse correctamente
2.2.El usuario reinicia el dispositivo

Cuadro 4: Caso de uso, Elección de dispositivo

28
Caso de Uso Búsqueda de nuevos dispositivos

Actor Usuario

Descripción El usuario podrá agregar nuevos dispositivos existentes en la red

Referencias RF-07

Pre-condición El usuario ha configurado previamente los dispositivos inteligentes

El dispositivo se agrega a la interfaz web, donde podrá ser

Post-condición
controlado y monitorizado

1.El usuario dispone de dispositivos configurados en la red

2.El Usuario accede a la búsqueda de nuevos dispositivos
3.El usuario selecciona el nuevo dispositivo
4.Si precisa añadir campos, el usuario los completa
Flujo normal
4.1. En caso de ser un dispositivo controlador, por ejemplo un pulsador
, deberá indicar en el formulario dinámico que dispositivo controla
5.El dispositivo es completamente controlable y monitorizable desde
la web

1.El usuario no dispone de dispositivos en la red configurables

Flujo Alternativo
1.1.No se puede realizar ninguna configuración

Cuadro 5: Caso de uso, Búsqueda de nuevos dispositivos

29
Caso de Uso Añadir dispositivos manualmente

Actor Usuario

Descripción El usuario podrá agregar nuevos dispositivos

Referencias RF-08

El usuario dispone de dispositivos compatibles con el protocolo MQTT o

Pre-condición
dispositivos configurados manualmente

El dispositivo se agrega a la interfaz web, donde podrá ser

Post-condición
controlado y monitorizado

1.El usuario dispone de dispositivos MQTT o configurados manualmente

2.El Usuario accede a la pestaña ’Añadir manualmente’
Flujo normal 3.El usuario completa el formulario con las características y rutas
5.El dispositivo es completamente controlable y monitorizable desde
la web

1.El usuario no completa correctamente las opciones de configuración

Flujo Alternativo
1.1.No se puede agregar un nuevo dispositivo

Cuadro 6: Caso de uso, Añadir dispositivos manualmente

30
Caso de Uso Modificar dispositivos

Actor Usuario

Descripción El usuario podrá Modificar el nombre y las rutas de los dispositivos

Referencias RF-09

Pre-condición El usuario dispone de dispositivos agregados en la interfaz web

Post-condición El dispositivo es modificado

1.El usuario dispone de dispositivos en el servidor web

2.El Usuario accede a la pestaña ’modificar’
Flujo normal
3.El usuario modifica el formulario con las características y rutas
5.El dispositivo es modificado

1.El usuario no completa correctamente las opciones de configuración

Flujo Alternativo
1.1.No se modifica correctamente el dispositivo

Cuadro 7: Caso de uso, Modificación de dispositivos

Caso de Uso Eliminar dispositivos

Actor Usuario

Descripción El usuario podrá eliminar dispositivos del sistema web

Referencias RF-10

Pre-condición El usuario dispone de dispositivos agregados en la interfaz web

Post-condición El dispositivo es eliminado

1.El usuario dispone de dispositivos en el servidor web

Flujo normal 2.El Usuario accede a la pestaña ’eliminar’
5.El dispositivo es eliminado

Flujo Alternativo

Cuadro 8: Caso de uso, Eliminar dispositivos

31
Caso de Uso Control de persiana

Actor Usuario

Descripción El usuario podrá controlar y monitorizar el estado de una persiana

Referencias RF-11

El usuario dispone de dispositivos de control de

Pre-condición
persiana agregados en la interfaz web

Post-condición Cambia el estado de la persiana

1.El usuario dispone de persianas agregadas en el servidor web

2.El Usuario pulsa sobre un botón accionador
Flujo normal
3.La persiana obtiene el estado enviado desde el servidor.
4.El usuario observa el movimiento de la persiana desde la interfaz web

1.El dispositivo para control de persiana no esta activo

Flujo Alternativo
1.1.El sistema no acciona la persiana

Cuadro 9: Caso de uso, Control de persianas

32
Caso de Uso Control de dispositivos On/Off

Actor Usuario

El usuario podrá controlar y monitorizar el estado de dispositivos On/Off,

Descripción
como una lampara

Referencias RF-12

El usuario dispone de dispositivos On/Off

Pre-condición
agregados en la interfaz web

Post-condición Cambia el estado del dispositivo

1.El usuario dispone de dispositivos On/Off en el servidor Web

2.El Usuario pulsa sobre un botón accionador
Flujo normal 3.El dispositivo obtiene el nuevo estado enviado desde el servidor.
4.El usuario observa el nuevo estado del dispositivo desde
la interfaz web

1.El dispositivo no esta activo

Flujo Alternativo
1.1.El sistema no acciona el dispositivo

Cuadro 10: Caso de uso, Control de dispositivos On/Off

33
Caso de Uso Control de persiana mediante dispositivo remoto

Actor Usuario

El usuario podrá controlar desde un dispositivo remoto y físico

Descripción
la posición de las persianas

Referencias RF-13

El usuario dispone de dispositivos On/Off

Pre-condición
agregados en la interfaz web y dispositivos controladores

Post-condición Cambia el estado del dispositivo

1.El usuario dispone de dispositivos en el servidor Web y dispositivos

controladores
Flujo normal 2.El usuario acciona un botón del dispositivo físico.
3.El servidor procesa la solicitud y la envía a la persiana indicada
4. La persiana cambia de estado

1.El dispositivo no esta activo

Flujo Alternativo
1.1.El sistema no acciona el dispositivo

Cuadro 11: Caso de uso, Control de persiana mediante dispositivo remoto

34
Caso de Uso Control On/Off mediante dispositivo remoto

Actor Usuario

El usuario podrá controlar desde un dispositivo remoto y físico

Descripción
el estado de un dispositivo

Referencias RF-14

El usuario dispone de dispositivos On/Off

Pre-condición
agregados en la interfaz web y dispositivos controladores

Post-condición Cambia el estado del dispositivo

1.El usuario dispone de dispositivos On/Off en el servidor Web

y dispositivos controladores
Flujo normal 2.El usuario acciona un botón del dispositivo físico.
3.El servidor procesa la solicitud y la envía al dispositivo indicado
4. El dispositivo cambia de estado

1.El dispositivo no esta activo

Flujo Alternativo
1.1.El sistema no acciona el dispositivo

Cuadro 12: Caso de uso, Control On/Off mediante dispositivo remoto

35
Caso de Uso Control mediante cambio de luminosidad

Actor Sistema

El sistema detecta un cambio en la luminosidad respecto

Descripción a los parámetros indicados en la configuración del dispositivo, y lanza
una llamada al dispositivo controlado

Referencias RF-15

El usuario dispone de dispositivos On/Off

Pre-condición
agregados en la interfaz web y dispositivos controladores

Post-condición Cambia el estado del dispositivo

1.El usuario dispone de dispositivos On/Off en el servidor Web

y dispositivos
controladores
Flujo normal 2. El sistema detecta cambios por debajo o por encima de los
limites establecidos
3.El servidor procesa la solicitud y la envía al dispositivo indicado
4. El dispositivo cambia de estado

1.El dispositivo no esta activo

Flujo Alternativo
1.1.El sistema no acciona el dispositivo

Cuadro 13: Caso de uso, Sensor de luminosidad

36
 Para una mayor especificación de los casos de uso, y poder analizarlos visualmente, he-
mos desarrollado el modelo de casos de uso, donde podemos ver las relaciones entre los
mismos:

Figura 7: Diagrama de Casos de uso

37
3.2. Arquitectura y Diseño del Sistema

En esta sección especificaremos la arquitectura y el diseño del sistema mediante explica-

ciones de cada subsistema, mostrando diagramas de clases, diagramas del funcionamiento
y conexión del mismo.

3.2.1. Visión General

Para poder enviar una señal a un dispositivo inteligente, y que este controle una per-
siana o una lampara, se ha diseñado e implementado una arquitectura basada en servidor
MQTT. El objetivo, es comunicar dispositivos de bajas capacidades computacionales, como
el procesador ESP8266, con un dispositivo utilizado por el usuario final, con el fin de mandar
señales y monitorizar a los mismos.

Para ello existen diversas soluciones, pero hemos optado por desplegar un servidor cen-
tral, el cual dispone de una API REST [14] que permite la conexión a diversos clientes, como
POSTMAN o al cliente propio que hemos diseñado para controlar a todos los dispositivos de
forma centralizada.

Este cliente esta implementado utilizando JavaScript como lenguaje que realiza las pe-
ticiones al servidor web, realizando así las acciones necesarias desde una interfaz intuitiva.
El servidor central usara SQLite, como sistema gestor de base de datos, el cual nos permite
almacenar los dispositivos que han sido añadidos y la configuración del sistema cuando este
es apagado.

El servidor Web, es el encargado de enviar los datos a los dispositivos Iot. Para enviar y
recibir información de dichos dispositivos, se utiliza un servidor MQTT, de forma que los
dispositivos Iot quedan a la espera de un mensaje para realizar una acción previamente pro-
gramada, así como enviar información de su estado en un determinado periodo de tiempo.
Todos estos procedimientos serán especificados en las siguientes secciones.

38
Figura 8: Visión general del sistema

39
3.2.2. Sistema Interno de los Dispositivos Inteligentes

En esta subsección especificaremos el diseño y la arquitectura de los dispositivos Iot, los

cuales utilizan el procesador ESP8266. Esta sera acompañada del diagrama UML del sowft-
ware interno, donde podremos ver las relaciones entre las clases y los métodos existentes.
También, se incluirán las maquinas de estado para cada tipo de funcionalidad del sistema.

El sistema interno esta desarrollado entorno a la entidad “Device”, lugar donde se espe-
cifican las características del dispositivo, así como el control del mismo. Uno de los puntos
mas importantes del sistema, es la conexión con el servidor MQTT, donde llegan las ordenes
enviadas desde el servidor para realizar una acción concreta.

En los siguientes puntos serán detallados en profundidad los componentes del sistema
junto con el diagrama UML.

Descripción de los componentes [9]

1. Devices:
Se trata de la clase central, en ella se especifican las características de cada dispo-
sitivo, y encontramos los métodos para controlar el dispositivo a nivel mas bajo.
Desde esta clase podemos accionar pines del procesador, así como declararlos.
En caso de declarar el dispositivo como sensor, se podrán llamar a dichos méto-
dos para obtener el estado del mismo.

2. mqttConn:
El dispositivo esta programado para ser controlado remotamente, para ello se
utiliza la conexión con un servidor mqtt. En este caso, disponemos de métodos
para poder publicar información a una determinada ruta del servidor mqtt, así
como un método denominado callBack. Este método es el encargado de realizar
una acción determinada en función del tipo de dispositivo que tenemos confi-
gurado, de esta forma, cada vez que dicho método recibe un mensaje a la ruta a
la que se encuentra suscrita, se realiza una acción determinada.

40
3. utils:
Aquí encontraremos los métodos destinados al control y a la configuración del
dispositivo en si, es decir, disponemos de los diferentes métodos que accionan
un determinado tipo de dispositivo, esto nos permite mantener en un mismo
software la cantidad de dispositivos a controlar que deseemos. El funcionamien-
to de cada uno de estos métodos sera especificado en los siguientes subaparta-
dos, utilizando maquinas de estado.

4. serverConf:
Para la configuración inicial, donde se introducen datos como la ip del servidor
mqtt, o el ssid de la red, utilizamos un servidor Asíncrono, lo que permite que en
el primer inicio del dispositivo, o tras pulsar una combinación de botones, este
entre en modo configuración, creando un punto de acceso wifi, y generando una
pagina web interactiva con el usuario

5. eepromUtils:
Para el almacenamiento de todas las variables necesarias cuando el dispositivo
es apagado, utilizamos la librería “EEPROM FOR ESP8266”, la cual emula la exis-
tencia de una memoria eeprom sobre la memoria flash del procesador, de esta
forma podemos almacenar variables como el ultimo estado del sistema antes de
ser apagado.

41
Figura 9: Diagrama UML dispositivos Iot

42
Configuración inicial de los dispositivos:
Para facilitar la configuración inicial de los dispositivos, se ha desarrollado un sistema
de configuración automática y manual. De esta forma el usuario solo deberá conec-
tarse a la red wifi emitida por el dispositivo y a su pagina web, realizado una configura-
ción automática y sencilla. También se dispone de una configuración manual, donde
se podrán introducir las rutas especificas del servidor mqtt.

En el siguiente diagrama de bloques, podemos observar el proceso seguido para la

configuración previa de los mismos.

Figura 10: Diagrama de bloques de la configuración inicial

En dicho procedimiento, el usuario selecciona si desea la configuración automática

o manual, dado que en caso de elegir configuración manual, las rutas del servidor
deberán ser indicadas en el formulario de la pagina web creada por el dispositivo.

43
Para realizar el proceso de configuración automática, el dispositivo deberá estar en
modo access point, donde el usuario indicara desde la pagina web los atributos: ssid,
password,mqtt server Ip, deviceType y tipo de configuración. Una vez los campos han
sido rellenados el usuario envía el formulario y el sistema se reinicia con los paráme-
tros introducidos. El sistema inicia en modo auto configuración, y este se conecta a la
red previamente indicada.

Ahora, cada segundo, publica en la ruta “/autoConfig” su identificador junto con el

tipo de dispositivo que es, de esta forma, el servidor web que esta suscrito a la ruta
“/autoConfig”, detecta al nuevo dispositivo, mostrándolo al usuario final.

Cuando el usuario final pulsa sobre añadir dispositivo, el servidor publica en la ruta
/deviceId el payload addDevice, por lo que el dispositivo “deviceId”, recibirá el pay-
load, reiniciando el dispositivo y entrando en modo “Ready”, por lo que el dispositivo
sera añadido al sistema y el usuario final podrá controlarlo.

El funcionamiento es detallado en el siguiente diagrama:

44
Figura 11: Diagrama de funcionamiento de la configuración automática de los dispositivos

45
Descripción de los tipos de dispositivos y su funcionamiento
Disponemos de un software polivalente, dado que este se adapta a los siguientes tipos
de dispositivos que monten el procesador ESP8266:

1. Dispositivo de apagado y encendido: Se trata de un dispositivo que disponga de

un relé en un determinado pin, estas características serán detalladas en el ma-
nual de Instalación y uso. El dispositivo esta constantemente escuchando en una
ruta del servidor mqtt determinado, de forma que cuando recibe el valor, “on” u
“off”, el pin configurado obtiene dicho valor. Además, para un control exhaustivo
del mismo y poder controlar el estado actual del dispositivo, este emite su estado
hacia la ruta de escucha que tiene configurado el servidor web, consiguiendo sa-
ber el estado del dispositivo en tiempo real. Podemos ver el diagrama de estados
que sigue el dispositivo en la siguiente imagen:

Figura 12: Diagrama de estados Dispositivo On / Off

46
2. Dispositivo Persiana:
Se trata de un dispositivo mas complejo, este, deberá montar dos relés, para el co-
rrecto funcionamiento de la persiana, dado que dispone de tres estados, parada,
subiendo o bajando. Además, en todo momento el dispositivo emite el porcenta-
je en el que se encuentra la persiana.Cuando la persiana obtiene el valor de 100 %
o 0 % esta adquiere el valor de parada. Este dispositivo responde a los comandos
0,1 y 00, los cuales serán especificados en el siguiente diagrama:

Figura 13: Diagrama de estados del dispositivo persiana

3. Interruptor remoto para el control de dispositivo On/Off:

Se trata de un dispositivo controlador, el cual también puede ser agregado al sis-
tema, para ser enlazado con el dispositivo a controlar de una forma sencilla.
Escuchará en la ruta de envío del actuador asignado, de esta forma, cuando el
dispositivo On/Off envía un determinado estado, tanto el servidor web como el
dispositivo controlador son informados.Esto permite que al pulsar el botón físi-
co, apague el actuador si esta encendido o viceversa.

4. Interruptor remoto para persiana:

Este dispositivo, implementa el mismo sistema que el indicado en el punto an-
terior, con la diferencia de que incluye dos botones físicos, uno para subir la per-
siana y otro para bajarla. Este dispositivo, a diferencia del anterior, no necesita
escuchar el estado de la persiana, dado que al accionar un botón u otro se ejecu-
ta la maquina de estados de la persiana, realizando la acción pertinente.

47
5. Fotoresistencia remota para dispositivo On/Off:
Este dispositivo implementa un funcionamiento similar al botón On/Off, sin em-
bargo, es necesario indicarle un rango de luminosidad en el cual emitirá una se-
ñal al dispositivo controlado. Esto es configurado desde la configuración inicial
en el servidor web.

48
3.2.3. Sistema Interno del servidor Web y Cliente Web

En esta subsección especificaremos el diseño y la arquitectura del servidor web. Esta

sera acompañada del diagrama UML del mismo, donde podremos ver las relaciones entre
las clases y los métodos existentes.

El sistema esta basado en el modelo de API REST, donde disponemos de un controlador,

el cual especifica las rutas de acceso al sistema, este llama al servicio, donde se encuentra
la lógica de la aplicación, que a su vez llama al repositorio para almacenar datos en sqli-
te, modificarlos o extraerlos. Funciona conjuntamente con la clase MqttBeans, encargada
de realizar la conexión con el servidor MQTT. Todas estas clases serán especificadas en los
siguientes apartados.

Figura 14: Diagrama UML del servidor Web en Java Spring

49
Especificación de las clases del servidor Web:

Device
Se trata de la clase encargada de contener los atributos de los dispositivo inteligentes,
tales como las rutas mqtt, el estado del dispositivo o el tipo.
En ella se incorporan los métodos necesarios para modificar dichos atributos, así co-
mo para enlazar dicho dispositivo con un segundo dispositivo a controlar.Por esta ra-
zón observamos como la clase Device esta relacionada con ella misma, dado que un
dispositivo, por ejemplo un pulsador, puede controlar una lampara.

Device Service
Es la clase donde se encuentra la lógica del sistema, en ella encontramos todas las
operaciones que hacen que la aplicación funcione correctamente.
Existen cantidad de métodos dentro de ella, pero podemos destacar:

1. setStatusAndSend: El servicio recibe desde el controlador una petición de cambio

de estado de un dispositivo, por lo que el servicio recoge la petición almacenán-
dola en la base de datos y envía el nuevo estado al dispositivo indicado haciendo
uso de la pasarela mqtt.

2. setMovementShutter: Tal y como veremos en el apartado del sistema interno de

los dispositivos, el control de las persianas puede ser, subir, bajar, o parar, de esta
forma, el servicio recibe el estado deseado y lo envía al servidor mqtt.

3. findNewDevices: Este devuelve los dispositivos que la clase mqtt ha encontrado

en la red, el cual sera explicado posteriormente.

4. setSensor: Este método nos permite agregar varios tipos de sensores que contro-
laran dispositivos en el sistema de una forma que se adapta a las necesidades del
dispositivo a agregar y a controlar.

5. runAfterStartUp: Se trata de un método el cual es ejecutado en cada inicio de la

aplicación. Es el encargado de conectar los dispositivos almacenados en la base
de datos del sistema al conector mqtt, añadiendo las rutas de los dispositivos
que el servidor debe escuchar. Esto es debido a que el sistema almacena las rutas

50
 mqtt en memoria, por lo que en cada inicio del sistema, hay que realizar una
carga de los mismos.

6. AddAutoDevice y AddSensor, se tratan de dos métodos que permiten añadir dis-

positivos, tanto actuadores como sensores al sistema de forma automática, dado
que el proceso es complejo, procedemos a detallarlo mediante varios diagramas
de secuencia, en primer lugar la búsqueda de nuevos dispositivos, y en segundo
lugar, agregarlos al sistema.Cabe destacar que los diagramas representan la se-
cuencia para agregar un actuador al sistema. El proceso para agregar un sensor
es el mismo, pero añadiendo el parámetro “ControlledDevice” a la petición.

Figura 15: Diagrama de secuencia para encontrar nuevos dispositivos

51
Figura 16: Diagrama de secuencia para añadir un dispositivo de forma automática

Device Controller: Este es el punto de entrada al sistema web, en el obtenemos las

peticiones del cliente y son procesadas y filtradas para enviarlas al servicio.
Las peticiones disponibles son detalladas en la siguiente tabla:

52
URI Tipo Descripción

Este método permite obtener todos los dispositivos

domoApi/devices GET
existentes en el sistema

domoApi/devices/id GET Este método permite obtener un dispositivo del sistema

Con este metodo añadimos un dispositivo al sistema, el

domoApi/devices/ POST controlador llama al método addDevice del servicio, y le
indica si dicho dispositivo controlara a otro dispositivo o no

Este método del controlador altera el estado del dispositivo

domoApi/devices/
POST indicado, utilizando el método previamente explicado
setStatus/id/status
setStatusAndSend

Tal y como veremos en las maquinas de estado del

movimiento de las persianas, estas no pueden actualizar su
domoApi/devices/ estado siguiendo un valor Alto o bajo, sino que precisan
setMovementShutter POST de una maquina de estado mas complejas, por tanto,
/id/moveDirection disponen de un método especifico en el controlador que
permite enviar una acción especifica al dispositivo
controlador de las persianas

domoApi/devices/ Este método nos provee de los nuevos dispositivos

GET
findNewDevices encontrados en la red

domoApi/devices/ Punto de entrada para agregar nuevos dispositivos al sistema

POST
addAutoDevices/id de forma automática, explicado en los diagramas de secuencia

domoApi/devices/
Punto de entrada para agregar nuevos sensores al sistema
addSensor POST
de forma automática, explicado en los diagramas de secuencia
/sensorName

domoApi/devices/id PUT Este método permite modificar los dispositivos del sistema

domoApi/devices/id DELETE Este método permite eliminar los dispositivos del sistema

Cuadro 14: Peticiones REST disponibles en el sistema Web

53
Device Repository
Se trata de la interfaz que extiende de la Clase JPA [5](detallada previamente en el capi-
tulo tecnologías). Por tanto, utilizando el repositorio en el servicio, conseguimos tratar
a los dispositivos de la base de datos como objetos que pueden ser modificados tanto
en la base de datos como en el propio flujo del programa. Como podemos observar,
existe una función “findByRoute”, la cual realiza una búsqueda de dispositivos en la
base de datos en función de la ruta del servidor mqtt de cada uno, lo que permite de-
sarrollar un código limpio y fácilmente escalable.

Constants y Utils

1. Constants: Se trata de una clase con variables enteras y estáticas, cada una de
estas almacena el valor del tipo de dispositivo disponibles dentro del sistema, lo
que permite tener un código limpio.

2. Utils:Dentro de dicha clase, podemos encontrar el método “getNewDevice”, que

tal y como veremos en el siguiente apartado, es utilizado para obtener un objeto
dispositivo desde el Payload enviado por el servidor MQTT.

Conexion con el Servidor Mqtt

1. mqttBeans: Se trata de la clase de configuración principal para la conexión con

el servidor MQTT, utilizando las librerías suministradas por el framework Spring.
Gracias a dicha clase, podemos enviar y recibir informacion del servidor, me-
diante el canal de entrada “InBound”, y el canal de salida “OutBound”.
Podemos diferenciar una serie de métodos, los cuales son declarados como “Beans”
[15], de forma que pueden ser llamados en otra parte del código utilizando el
contenedor de Beans.

• mqttClientFactory: Se trata del método encargado de la configuración de la

conexión con el servidor MQTT, en el se indican parametros como la direc-
cion IP o usuario y contraseña si fuese necesario.

• mqttInputChanel: Es el metodo encargado de conectarse al servidor en ca-

lidad de puerta de entrada al sistema web, a el llegaran los nuevos mensajes
del servidor, y serán tratados por el siguiente método, handler.

54
 • handler:Es uno de los puntos críticos del sistema, dado que es el encarga-
do de tratar los mensajes que llegan al servidor, previamente suscritos a un
topic.Cuando un mensaje coincide con los topics a los que el servidor se ha
suscrito, por ejemplo, el topic el configuración automática de los dispositi-
vos, o los topic de estado de los dispositivos, se realiza una serie de métodos.
En caso de ser detectado un nuevo dispositivo en el topic de auto configura-
ción, el sistema añade el nuevo dispositivo a la lista de dispositivos a agregar,
en caso contrario, actualiza el estado de los dispositivos existentes.

• mqttOutBound: Es el método encargado del envío de los mensajes hacia el

servidor mqtt, este es llamado cada vez que la interfaz “mqttGateway” nece-
sita enviar un mensaje a una determinada ruta del servidor.

2. mqttGateway:Se trata de una interfaz, creada como pasarela de envío, utilizando

las anotaciones de spring “@MessagingGateway”, e indicándole el metodo ante-
rior “mqttOutBound”, de esta forma, cuando queremos enviar un determinado
mensaje al servidor, instanciamos a dicha interfaz, indicando el mensaje y la ru-
ta hacia la que va dirigido.

55
 Por ultimo, en esta sección hablaremos del cliente web, este realiza peticiones al servidor
previamente especificado, y es donde el cliente final podrá realizar todas las acciones para
controlar el sistema. En el apéndice del Manual del Usuario, sera ilustrado con imágenes el
uso del sistema para el usuario Final.

Aspectos visuales

1. Html
En primer lugar, la estructura de la pagina es creada utilizando el lenguaje HTML,
la pagina se compone de un menu inicial donde se pueden ver todos los dispo-
sitivos disponibles en el sistema. Este menú es generado mediante un elemento
grid, de forma que va mostrando dispositivos en función de los existentes en el
sistema. También dispone de pantallas flotantes, tanto para la búsqueda de dis-
positivos como para la modificación de los mismos

2. Bootstrap
Para dotar a la estructura de un estilo elegante, minimalista y facil de usar para
los usuarios, se ha utilizado la librería bootstrap para maquetar la interfaz grafica.
Esta libreria permite generar una visual agradable a la vista con componentes
predefinidos.

Peticiones al servidor Web, Javascript

Se trata del punto mas importante del cliente web, usando javascript, se realizan peti-
ciones a la API REST, usando peticiones asíncronas, de forma que mientras el sistema
espera la respuesta del servidor web tras realizar una petición, puede seguir realizando
otras acciones sin paralizar el sistema.

var requestOptions = {
method: 'GET',
redirect: 'follow'
};

fetch(url+"domoApi/devices", requestOptions)
.then(function (response){

56
 return response.json();
})
.then(function (data){
let html='';
data.forEach(function (device){
//Mostrar dispositivos formateados

1. Funcionamiento
Observemos el siguiente diagrama de secuencias.

Figura 17: Diagrama de secuencias para la visualización de los dispositivos del sistema

El usuario accede al panel web del cliente, como sabemos, en esta primera pan-
talla se muestran todos los dispositivos, por tanto, el cliente, mediante una peti-
ción al servidor web, obtiene todos los dispositivos disponibles en formato JSON,
tratando los datos y mostrándolos formateados al cliente final en la interfaz web.

57
3.2.4. Empaquetado y Despliegue

Como hemos comentado previamente, el sistema va a ser portable gracias al proceso de

empaquetado con docker, esto permitirá que el sistema brinde gran cantidad de facilidades
a la hora de desplegar los servidores y la red que deben crear.Como sabemos, el sistema esta
dividido en cuatro grandes bloques, servidor web, servidor mqtt, pagina cliente, y dispositi-
vos Iot. En este caso, el sistema de los dispositivos Iot, es completamente independiente del
sistema web, por tanto nos enfocaremos en los bloques relativos al servidor web.El objetivo
es crear un fichero que con un solo comando, pueda desplegar una red de tres servicios.

Este apartado se dividirá en varias secciones:

Creación de la imagen del servidor web

El servidor web, el cual tiene arquitectura de Api Rest [16] [17], ha sido desarrollado
en java en concreto en el framework spring, por tanto, para la creación de una imagen
de docker, sera necesario la creación de un paquete jar, para poder ser desplegado en
un servidor tomcat, o en nuestro caso, sobre una imagen de java ya funcional. Para
ello, dado que el proyecto ha sido creado y desarrollado utilizando las herramientas
de maven, utilizaremos el siguiente comando para el empaquetado de la aplicación:

mvn clean package

Esto nos permitirá empaquetar el sistema web en un fichero jar funcional. Tras ejecu-
tar el comando, el paquete sera enviado a la carpeta target.

Ahora que ya tenemos el sistema empaquetado, deberemos crear un fichero Docker-

file, donde especifiquemos los pasos que deberá seguir docker para la creación de la
misma.

En nuestro caso usaremos la imagen “openjdk:11”, la cual nos permite ejecutar apli-
caciones java. Ademas, deberemos copiar el paquete previamente creado y exponer el
puerto de la api, 8080. El fichero docker quedaría asi:

58
FROM openjdk:11
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

EXPOSE 8080

Listing 1: Fichero Dockerfile para la creación de la imagen del servidor web

Finalmente, ejecutamos el comando para la construcción de la imagen, y obtenemos

en una imagen portable el servidor web desarrollado

docker build .

Conexión con un contenedor de mosquitto mqtt

Como sabemos, la conexión entre los dispositivos iot y el servidor web, se realiza me-
diante un servidor mqtt, este servidor en concreto en mosquitto.

Para facilitar la instalación y configuración del mismo, seguimos la documentación

oficial de mosquitto en dockerhub [18], simplemente deberemos incluir este servicio
en el fichero docker-compose.yml, el cual sera mostrado al final de este apartado.

59
services:
mqtt:
container_name: mosquitto_mqtt
image: eclipse-mosquitto:1.6
restart: always
ports:
- "1883:1883"
- "9001:9001"
volumes:
- ./mosquitto/config:/mosquitto/config
- ./mosquitto/log:/mosquitto/log
- ./mosquitto/data:/mosquitto/data

Listing 2: Servicio mqtt en docker

Conexión con el contenedor de la pagina cliente

Por ultimo, deberemos crear el servicio de la pagina web para la interacción con el
usuario final. En este caso, no crearemos una imagen dedicada a dicho servicio, sino
que utilizaremos el conocido proxy inverso “nginx” [19]. Esto es debido,a que la pagina
cliente, realiza peticiones a la api, por tanto, el servidor web, obtendrá una dirección
ip diferente en cada red.

Por ello, desplegaremos un servicio de nginx, que nos permitirá obtener los datos de la
pagina web desde un volumen, en concreto, de un directorio del host. Esto permitirá
que la url del servidor pueda ser modificada alterando un archivo, y elimina la com-
plejidad de crear un contenedor donde debemos acceder a el para modificar dicho
archivo.

60
 Para ello seguimos el siguiente fichero:

client_website:
container_name: client_website
image: nginx
volumes:
- ./clienteJs:/usr/share/nginx/html
restart: always
ports:
- "80:80"

Listing 3: Servicio de web cliente en docker

Finalmente, y tal y como veremos en el manual podemos ejecutar un solo comando y

todo el sistema comenzara a ejecutarse. El fichero completo queda así:

version: '3.8'
services:
mqtt:
container_name: mosquitto_mqtt
image: eclipse-mosquitto:1.6
restart: always
ports:
- "1883:1883"
- "9001:9001"
volumes:
- ./mosquitto/config:/mosquitto/config
- ./mosquitto/log:/mosquitto/log
- ./mosquitto/data:/mosquitto/data

springserver:
container_name: web_server
image: rafaelom/tfgmayo
restart: always

61
 ports:
- "8080:8080"
environment:
mqttUrl: mqtt

client_website:
container_name: client_website
image: nginx
volumes:
- ./clienteJs:/usr/share/nginx/html
restart: always
ports:
- "80:80"

Listing 4: Fichero docker-compose del sistema

62
 4
Conclusiones y Líneas
Futuras
En este capitulo, se especifican las conclusiones obtenidas tras la realización del pro-
yecto completo, y se plantean una serie de lineas futuras que podrían partir de este trabajo
como base.

4.1. Conclusiones

Tras la realización del proyecto, obtenemos las siguientes conclusiones respecto a los
objetivos inicialmente planteados:

Se ha conseguido desarrollar un sistema domotico completamente funcional, donde

el usuario podrá controlar dispositivos de encendido-apagado o persianas, remota-
mente, desde un dispositivo móvil, o un interruptor inteligente.

Se ha desarrollado un software en C++ y el framework “Arduino” para dispositivos

compatibles con el mismo, el cual es capaz de conectarse con un servidor mqtt y rea-
lizar acciones en función de las ordenes recibidas.

Obtenemos un software multidispositivo, capaz de controlar persianas, dispositivos

de encendido y apagado, interruptores remotos y sensores.

Creación de una “Api Rest”, para el control de los dispositivos desde una interfaz web.

Desarrollo de una interfaz de usuario “responsive”, la cual permite el control de los

dispositivos inteligentes.

63
 Se ha desplegado el servidor mqtt “mosquitto” con éxito, así como la conexión con los
demás sistemas.

El empaquetado de los sistemas usando la tecnología de “docker”, es una actividad de

suma importancia para la portabilidad de los sistemas modernos.

La importancia de las asignaturas impartidas a lo largo del grado de “Ingeniería In-

formatica”, han sido de gran ayuda a la hora de crear una arquitectura de software
completa y funcional, donde podemos destacar la asignatura “Electrónica para la do-
motica”, la cual ha permitido asentar las bases para el desarrollo de un proyecto de
este calibre.

Concienciación de la importancia de un sistema de código libre para la sociedad en

general.

Por tanto, tal y como se planteo al inicio, se ha desarrollado un sistema donde los dis-
positivos se controlan mediante el protocolo mqtt, todo el sistema se encuentra en una red
local, y se encuentra empaquetado , para una mayor facilidad de instalación y uso.

64
4.2. Líneas Futuras

A continuación se enumeran una serie de lineas para seguir ampliando la extensión de

dicho proyecto

1. Añadir dispositivos dimmables:

Una de las características mas relevantes actualmente en los sistemas domóticos, es
la capacidad de poder regular la intensidad de las lamparas remotamente. Para ello
se debería añadir dicha función al sistema, de forma que este permita controlar la
intensidad de lamparas led e incandescentes.

2. Incluir control por voz:

Seria útil que el sistema pudiese ser controlado por voz, utilizando alguna inteligencia
artificial como google home, o Alexa, permitiendo el control de los dispositivos por
voz.

3. Interfaz cliente usando un Framework :

En nuestro caso la interfaz web cliente, se encuentra desarrollada usando el lenguaje
javascript, sin embargo, cada vez esta mas extendido el uso de frameworks para el
desarrollo de software, como “React” o “Angular”, dado que pueden nutrir al sistema
de una mayor robustez y escalabilidad. Por tanto, proponemos el desarrollo de una
aplicación web basada en uno de estos frameworks.

4. Desarrollo de una Aplicación Móvil:

Aunque la web del sistema domotico esta adaptada a dispositivos móviles, para el
usuario final, puede ser de gran ayuda, disponer de una aplicación nativa para su
“smartphone”, desde donde podrá controlar el sistema de una forma mas directa.
Por tanto, se propone el desarrollo de una aplicación para dispositivos móviles que
realice peticiones a la “Api rest” previamente desarrollada, para el control del sistema.

65
5. Implementar seguridad en el sistema:
Se propone dotar el sistema de más seguridad, de forma que este pueda ser expuesto
al exterior sin poner en riesgo la integridad del mismo. Existen gran cantidad de herra-
mientas a aplicar, pero destacamos el uso de “SSL” entre el servidor MQTT y el servidor
web, así como la creación de usuario y contraseña para cada miembro del sistema.

66
 Referencias
[1] B. Anderson, Responsive and fast : implementing high-performance responsive design.
2014, ISBN: 1-4919-1293-6.

[2] naylampmechatronics.com, NodeMcu, https://naylampmechatronics.com/espressif-

esp/153-nodemcu-v2-esp8266-wifi.html#:~:text=NodeMc, [Online; Se accedio el
27 de Marzo del 2022], 2022.

[3] wikimedia Commons, LDR Sensor, https://commons.wikimedia.org/wiki/File:

LDR.png, [Online; Se accedio el 18 de Mayo de 2022].

[4] O. Lanuza, Open Lanuza, https : / / openlanuza . com / utilizando - un - rele - en -

arduino/, [Online; Se accedio el 18 de Mayo de 2022].

[5] M. Tyson, What is JPA? https://www.infoworld.com/article/3379043/what-is-

jpa-introduction-to-the-java-persistence-api.html, [Online; Se accedio el 12
de Abril de 2022].

[6] B. StroustrupA, El lenguaje de programación C++. Addison Wesley, 1998, ISBN: 84-7829-
019-2.

[7] S. Córcoles Córcoles, Arduino. 2018, ISBN: 84-9964-745-6.

[8] P. Porcuna López, Robótica y domótica básica con Arduino. 2015, ISBN: 84-9964-610-7.

[9] G. C. Hillar, MQTT Essentials. 2017, ISBN: 1787285146.

[10] J.-P. Gouigoux, Docker: Primeros pasos y puesta en práctica de una arquitectura basada
en micro-servicios. 2018, ISBN: 2409015905.

[11] Docker, Docker, https://www.docker.com/resources/what-container/, [Online;

Se accedio el 18 de Mayo de 2022].

[12] T. Pulver, Hands-on internet of things with MQTT : build connected IoT devices with
Arduino and MQ telemetry transport (MQTT). 2019, ISBN: 1-78934-500-6.

[13] J. de Andalucia, Casos de uso, https : / / www . juntadeandalucia . es / servicios /

madeja/contenido/recurso/416, [Online; Se accedio el 2 de Abril de 2022].

67
[14] R. Hat, What is REST, https://www.redhat.com/es/topics/api/what-is-a-rest-
api, [Online; Se accedio el 6 de Abril de 2022].

[15] N. N. Thai, What is a spring Bean? https://www.baeldung.com/spring-bean, [Onli-

ne; Se accedio el 14 de Abril de 2022].

[16] M. A. Massé, REST API Design Ruleboo. 2011, ISBN: 1-4493-1790-1.

[17] J. C. Braun, Desarrollo de Servicio REST API para el uso seguro de dispositivos IoT,
https : / / riuma . uma . es / xmlui / handle / 10630 / 18899, [Trabajo final de grado],
2019.

[18] eclipse mosquitto, mosquitto in dockerhub, https://hub.docker.com/_/eclipse-

mosquitto, [Online; Se accedio el 5 de Mayo de 2022].

[19] nginx, Official nginx website, https://www.nginx.com/, [Online; Se accedio el 5 de

Mayo de 2022].

68
 Apéndice A
Manual de
Instalación
En este apéndice se especifica la instalación del sistema web en un entorno donde sea
posible ejecutar docker, y la carga del firmware de los dispositivos Iot.

A.1. Instalación del servidor web

Para el despliegue del servidor web, es necesario disponer de docker y docker compose
instalado en el sistema.

A.2. Despliegue de fichero docker-compose

Como sabemos, todo el sistema se encuentra dockerizado, y conectado correctamente

dentro de un entorno virtual, en este caso, disponemos del directorio “homeAutomationSys-
tem”, desde donde podemos acceder al fichero “docker-compose.yml” y al código de la in-
terfaz cliente.
Para lanzar el sistema completo, deberemos ejecutar desde el directorio “homeAutoma-
tionSystem”, el comando:

docker-compose up -d

Este comando levantara los tres contenedores que contienen a la aplicación en su totali-
dad, diviendo al sistema en tres servicios, servidor web, servidor mqtt y web cliente.

69
 Figura 18: Servicios del sistema funcionando en docker

Una vez los tres contenedores están corriendo, deberemos obtener la dirección ip de la
red local del equipo en el que se encuentra docker, dado que esta ip sera necesaria a la hora
de configurar un dispositivo inteligente.
En caso de estar en un sistema ubuntu deberemos ejecutar:

ifconfig

Obteniendo la Ip correspondiente a nuestro adaptador de red. Suele empezar por 192.168.X.X

En este punto, ya podemos acceder al servidor web desde la red local, o desde el equipo des-
de el que ha sido desplegado. Sin embargo, la web cliente esta configurada para enviar las
peticiones a un servidor en la dirección “localhost”, por tanto, si deseamos poder acceder a
la interfaz desde cualquier dispositivo de la red, deberemos modificar dicha direccion Ip.

1. En primer lugar accedemos al fichero “/clienteJs/assets/js/functions.js”

70
 2. En la linea 2, observamos la direccion ip “localhost”, la cual debe de ser modificada
por la direccion ip obtenida en el paso previo

3. Guardamos el archivo, y el sistema queda completamente configurado.

Figura 19: Linea a modificar

Es muy importante que no eliminemos el directorio donde están dichos archivos del servi-
dor web, dado que dicho directorio se encuentra montado como un volumen en el sistema
de docker.

Finalmente tenemos el sistema web completamente funcional.

A.3. Instalación del firmware dispositivos Iot

Como hemos explicado previamente, el software para el control de los dispositivos, esta
diseñado para ser configurado en diferentes situaciones, por tanto, solo deberemos instalar
un software genérico en todos los dispositivos.
Para ello, el desarrollo del software se ha llevado a cabo en el ide “Visual Studio Code”, junto
con la extensión de “Platform.io”, por tanto la recomendación es instalalar dicha herramien-
ta e iniciar el flasheo desde ahi.

71
72
 Apéndice B
Manual de
Usuario
En este apéndice se pretende explicar al usuario el uso del sistema completo, partiendo
desde la configuración inicial de los dispositivos Iot, hasta el servidor web.

B.1. Configuración Automática

B.1.1. Dispositivo Inteligente

Para configurar un dispositivo inteligente, deberemos pulsar el botón conectado al pin

5 a la vez que pulsamos el botón que reinicia el procesador, de esta forma el dispositivo de
inicia de nuevo, creando un punto de acceso denominado TFG_XXXXX.
Deberemos de seguir una serie de pasos para configurar el dispositivo:

1. Conectarnos a dicha red, indicando la contraseña 12345678

2. Acceder a la dirección 192.168.4.1 en un navegador web

3. Introducir la red wifi de su hogar junto con su contraseña

4. Indicar la direccion Ip del servidor obtenida en el momento de la instalación del ser-

vidor

5. Seleccionar el tipo de dispositivo

6. Rellenar el formulario, seleccionando la opción “Smart”, para que el servidor pueda

encontrar al dispositivo.

73
 Figura 20: Configurar un dispositivo automáticamente

7. Finalmente, enviaremos el formulario, de forma que el dispositivo se reiniciara auto-

máticamente, entrando en modo “Auto Config”, de forma que el servidor podrá en-
contrarlo en la red.

B.1.2. Servidor Web

En esta subsección enumeraremos como realizar la conexión entre los dispositivos y el

servidor web, así como el uso de los mismos:

Dispositivo On/Off
Se trata del dispositivo mas básico de todos, este permite el encendido y apagado de
un dispositivo tipo On/Off del Hogar.
Una vez hemos realizado el paso previo, deberemos dirigirnos hacia “New Device”>“Find
new devices”

74
 Figura 21: Buscar nuevo dispositivo

Dentro de la lista, encontraremos el dispositivo previamente configurado, por tanto

deberemos pulsar,“Add device”

Figura 22: Añadir dispositivo On/Off

Ahora podremos observar el nuevo dispositivo en el panel principal.

Pulsando sobre la imagen de la bombilla, podremos alernar el estado del dispositivo:

75
 Figura 23: Dispositivo en estado On

Persiana
Para agregar el dispositivo de tipo persiana, deberemos seleccionar la opción “Per-
siana”, en la configuración inicial del dispositivo, de esta forma, tras acceder al panel
principal y acceder “Find new Devices”, deberemos ver la siguiente pantalla, donde
deberemos pulsar sobre “Add device“:

Figura 24: Buscar dispositivo persiana

Finalmente obtenemos el dispositivo en el panel principal:

76
 Figura 25: Persiana agregada

Para controlar un dispositivo de tipo persiana, disponemos de las siguientes funcio-

nes:

1. Flecha hacia arriba: pulsándola, desencadenamos una acción que comienza a

subir la persiana, en caso de estar completamente abierta no se realiza ninguna
acción

2. Fecha hacia abajo: pulsándola, desencadenamos una acción que comienza a ba-
jar la persiana, en caso de estar completamente abierta no se realiza ninguna
acción

3. Botón de parada: Frena la persiana en la posición que se encuentre

4. La barra de progreso muestra la posición en la que se encuentra la persiana en

todo momento

5. Si cuando la persiana esta bajando o subiendo, pulsamos el botón opuesto al

sentido del movimiento, la persiana se para.

Dispositivo de control remoto

En este caso el sistema dispone de dos tipos de pulsadores, pulsador para control de
persiana y para control de lampara, en este caso realizaremos la explicación para una
persiana, pero el procedimiento es el mismo para el pulsador de lampara.
Para agregar el dispositivo de tipo control remoto de persiana, deberemos seleccio-
nar la opción “Control de Persiana”, en la configuración inicial del dispositivo, de esta
forma, tras acceder al panel principal y acceder “Find new Devices”, deberemos ver la
siguiente pantalla, donde deberemos pulsar sobre “Add device config“:

77
 Figura 26: Buscar control remoto de persiana

Pulsaremos el boton , y se abrira una nueva ventana, donde deberemos seleccionar el

dispositivo a ser controlado, en este caso elegimos el unico que hay disposible:

Figura 27: Elección de dispositivo

78
Tras elegir el dispositivo y guardar los cambios podemos observar el nuevo dispositivo
en el panel de usuario, donde indica el dispositivo controlado.
Ahora desde el dispositivo físico podremos controlar la persiana.

Figura 28: Dispositivo controlado y controlador

Dispositivo control de luminosidad

El dispositivo de control de luminosidad nos permite indicar dos limites para el apaga-
do y el encendido de un dispositivo tipo On/Off, de esta forma, cuando la luminosidad
es mas baja al limite inferior, la lampara se enciende, y cuando supera el superior, se
apaga.
Para agregar el dispositivo de tipo control de luminosidad, deberemos seleccionar la
opción “Sensor Luminico para dispositivo On/Of”, en la configuración inicial del dis-
positivo, de esta forma, tras acceder al panel principal y acceder “Find new Devices”,
deberemos ver la siguiente pantalla, donde deberemos pulsar sobre “Add device con-
fig“:

79
 Figura 29: Búsqueda de dispositivo sensor de luminosidad

Después, en la siguiente ventana seleccionaremos el dispositivo a controlar, y especi-

ficaremos dos valores en un rango de 0 y 1024, indicando el limite superior e inferior.

80
 Figura 30: Indicar limite inferior y superior

Finalmente, el dispositivo es configurado, y al alcanzar los limites indicados, el sensor

enciende o apaga el dispositivo esclavo.

Figura 31: Dispositivo controlado y controlador

81
B.2. Configuración Manual

En este apartado se explicará como añadir un dispositivo de forma manual al sistema,

aunque cabe destacar que no es el objetivo de dicha implementación, sino que, los dispo-
sitivos sean agregados de forma automática para asegurar que todos los dispositivos sean
correctamente configurados.

B.2.1. Dispositivo Inteligente

Para configurar un dispositivo inteligente, deberemos pulsar el botón conectado al pin

5 a la vez que pulsamos el botón que reinicia el procesador, de esta forma el dispositivo de
inicia de nuevo, creando un punto de acceso denominado TFG_XXXXX.
Deberemos de seguir una serie de pasos para configurar el dispositivo:

1. Conectarnos a dicha red, indicando la contraseña 12345678

2. Acceder a la dirección 192.168.4.1 en un navegador web

3. Introducir la red wifi de su hogar junto con su contraseña

4. Indicar la direccion Ip del servidor obtenida en el momento de la instalacion del ser-

vidor

5. Seleccionar el tipo de dispositivo

6. Rellenar el formulario, seleccionando la opción “Manual” e indicando las direcciones

del servidor mqtt que deseamos, dado que es una opción manual y deberemos confi-
gurarlo a nuestro gusto.

82
 Figura 32: Configurar un dispositivo manualmente

7. Finalmente, enviaremos el formulario, de forma que el dispositivo se reiniciara auto-

máticamente, entrando en modo “Ready” y funcionando con las rutas previamente
indicadas

83
B.2.2. Servidor web

Para ello deberemos acceder a la interfaz cliente, y pulsaremos sobre “New Device>Add
device Manually”

Figura 33: Botón para añadir un nuevo dispositivo

Después rellenaremos el formulario en función del dispositivo a controlar, pero en este

caso las rutas mqtt, deberán coincidir con las indicadas en la configuración del dispositivo.
Cabe destacar, que esta opción permite añadir cualquier dispositivo que permita el proto-
colo mqtt, dado que la conexión se realiza mediante el mismo, aunque no podrá ser contro-
lador desde la interfaz web.

Figura 34: Formulario para añadir un dispositivo manualmente

84
 Finalmente, tras pulsar en “save changes”, veremos el nuevo dispositivo en nuestro panel
principal.

Figura 35: Nuevo dispositivo añadido

85
B.3. Modificar un dispositivo

Los atributos de los dispositivos añadidos pueden ser modificados, aunque solo es re-
comendable cambiar el nombre de los mismos, dado que modificar las rutas mqtt, pueden
afectar al funcionamiento del mismo.
Para editar un dispositivo seguiremos los siguientes pasos:

1. En primer lugar pulsaremos sobre la rueda de uno de ellos.

Figura 36: Modificación de un dispositivo

2. Después, cuando se abra el formulario, modificamos los campos que deseemos, y pul-
samos sobre “Modify”

86
Figura 37: Modificación del nombre de un dispositivo

87
 3. Finalmente, observamos el nuevo nombre del dispositivo:

Figura 38: Modificación del nombre de un dispositivo

B.4. Eliminar un Dispositivo

Para ello el proceso es muy simple. Deberemos acceder al panel principal y pulsar sobre
la rueda :

Figura 39: Eliminar un dispositivo

88
 Después, en el formulario, presionaremos “Remove”, de forma que el dispositivo quedara
eliminado

Figura 40: Dispositivo eliminado

89
 E.T.S de Ingeniería Informática
Bulevar Louis Pasteur, 35
Campus de Teatinos
29071 Málaga
E.T.S. DE INGENIERÍA INFORMÁTICA