TFG Manuel Lopez Ceron Corredor

Universidad Politécnica
de Madrid
Escuela Técnica Superior de
Ingenieros Informáticos
Grado en Grado en Ingenierı́a Informática
Trabajo Fin de Grado
Sistemas de Producción IoT Automáticos

y Seguros
Autor: Manuel López-Cerón Corredor

Tutor(a): Jorge Dávila Muro
Madrid, 28 de junio de 2023

Este Trabajo Fin de Grado se ha depositado en la ETSI Informáticos de la Univer-
sidad Politécnica de Madrid para su defensa.
Trabajo Fin de Grado

Grado en Grado en Ingenierı́a Informática
Tı́tulo: Sistemas de Producción IoT Automáticos y Seguros
28 de junio de 2023
Autor: Manuel López-Cerón Corredor

Tutor: Jorge Dávila Muro
Lenguajes y sistemas Informáticos e Ingenierı́a Informática
ETSI Informáticos
Universidad Politécnica de Madrid
Resumen
Este trabajo se centra en el diseño, realización y prueba de un sistema de control de
un vivero, que permite la monitorización y control de los parámetros ambientales de este
entorno. El sistema está diseñado para ser seguro, tanto en lo que respecta a la segu-
ridad de los datos que genera, como el acceso que tendrán los usuarios para manipular
configuraciones del mismo. Para ello se ha diseñado un sistema de control basado en mi-
crocontroladores ESP32, que se comunican entre si mediante un servidor alojado en una
Raspberry Pi, que actúa como servidor de aplicaciones y broker siguiendo el protocolo
de comunicaciones MQTT. El sistema permite la monitorización y control de los paráme-
tros ambientales del entorno, ası́ como la configuración de los dispositivos que lo componen.
El sistema está diseñado para ser escalable, permitiendo de forma sencilla la incorpo-
ración de nuevos dispositivos de forma sencilla. A lo largo de este trabajo se analizan las
diferentes tecnologı́as utilizadas, ası́ como las diferentes alternativas que se han tenido en
cuenta para el diseño y realización del sistema. Se analizan factores como la seguridad, la
escalabilidad, la eficiencia energética, el precio, la facilidad de uso, etc.
i
Abstract
This work focuses on the design, realization and testing of a nursery control system,
which allows the monitoring and control of the environmental parameters of this environ-
ment. The system is designed to be secure, both in terms of the security of the data it
generates, and the access that users will have to manipulate its configurations. For this
purpose, a control system based on ESP32 microcontrollers has been designed, which com-
municate with each other through a server hosted on a Raspberry Pi, which acts as an
application server and broker following the MQTT communications protocol. The system
allows the monitoring and control of the environmental parameters of the environment, as
well as the configuration of the devices that compose it.
The system is designed to be scalable, allowing the incorporation of new devices in a

simple way. Throughout this work, the different technologies used are analyzed, as well as
the different alternatives that have been taken into account for the design and realization
of the system. Factors such as security, scalability, energy efficiency, price, ease of use, etc.
are analyzed.
iii
Tabla de contenidos
1 Introducción 1
1.1 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Profundización en los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Variables a controlar . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Detalles de los sensores y actuadores . . . . . . . . . . . . . . . . . . 3
1.3.3 Detalles de la Comunicación . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.4 Detalles de la operación de los dispositivos . . . . . . . . . . . . . . 4
2 Estado del arte 5

2.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Desarrollo 9
3.1 Primeros pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1.1 Raspberry PI 3 . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1.2 ESP32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Software base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2.1 Red de comunicaciones, protocolo MQTT . . . . . . . . . . 14
3.1.2.2 Espressif, firmware para los ESPs . . . . . . . . . . . . . . 15
3.2 Diseño del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Comunicación fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1.1 Protocolo I2C . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1.2 Implementación en código . . . . . . . . . . . . . . . . . . . 21
3.2.2 Comunicación inalámbrica . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2.1 Conexión a la red WiFi . . . . . . . . . . . . . . . . . . . . 22
3.2.2.2 Implementación (ESP32) . . . . . . . . . . . . . . . . . . . 23
3.2.2.3 Servidor MQTT . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Diseño del mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3.1 Seguridad del mensaje . . . . . . . . . . . . . . . . . . . . . 25
3.2.3.2 Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3.3 Verificación de integridad . . . . . . . . . . . . . . . . . . . 27
3.2.3.4 Estructura del mensaje en claro . . . . . . . . . . . . . . . 27
3.2.3.5 Consumos de energı́a . . . . . . . . . . . . . . . . . . . . . 28
3.3 Puesta en funcionamiento del sistema . . . . . . . . . . . . . . . . . . . . . 31
4 Resultados y conclusiones 35
5 Análisis de impacto 37
v
1 Introducción
1.1. Motivación
La motivación para implementar este sistema tiene como raı́z la búsqueda de un entorno
óptimo para favorecer el crecimiento de las plantas. La búsqueda de estas condiciones
óptimas viene impulsada por los beneficios a las distintas industrias y enfoques que se
pueden obtener de un entorno botánico controlado.
Siendo ejemplo de esto el cuidado de especies delicadas y con posibilidad de entrar en
riesgo de extinción, producción de elementos para la industria médica, industria alimenti-
cia o como agricultura recreativa para jardines o exposiciones.
En primer lugar, un sistema de control IoT automático permite monitorizar y regular

de manera precisa las condiciones ambientales del entorno botánico o de cultivo. Esto im-
plica monitorización de factores como la temperatura, humedad, niveles de luz, y tomar
medidas, realizar acciones, sobre las polı́ticas de riego o dispoensación de nutrientes. Al
tener un control preciso de estas variables, es posible favorecer un entorno adecuado para
el crecimiento de las plantas, favoreciendo su salud y productividad. Esto resulta especial-
mente valioso en entornos industriales, donde la producción de cultivos de alta calidad y
en grandes cantidades es un objetivo clave. Estas son situaciones en las que los recursos
son limitados y la productividad debe ser alta. Ejemplo de estas situaciones son las sequı́as
vividas en los últimos años en España, que han provocado que la producción de cultivos
se reduzca drásticamente. O en zonas donde el agua es un recurso escaso, y por motivos
medioambientales no se puede hacer un uso excesivo de este recurso.
Aunque dicho sistema puede también ser utilizado en entornos domésticos donde el ob-
jetivo de las plantas sea tener un valor estético, en vez de conseguir de un rendimiento
económico.
Además, la automatización proporcionada por los sistemas IoT reduce la intervención

humana lo que podrı́a ayudar a minimizar los errores y la inconsistencia en la gestión de
las condiciones ambientales. También permite la monitorización y el control remoto, lo
que facilita la gestión de los entornos botánicos o de cultivo, especialmente en entornos
industriales donde el tamaño de las instalaciones puede ser muy grande. La precisión y
la constancia en la regulación de estos factores es fundamental para el desarrollo de las
plantas, ya que incluso pequeñas variaciones pueden afectar negativamente su crecimiento.
Sobre todo en factores como la humedad relativa[1]-[3] o la temperatura. Al eliminar la
dependencia de la intervención manual, se garantiza un control continuo y preciso, lo que
conduce a un crecimiento más saludable y predecible de las plantas.
Otro aspecto especialmente motivador es la eficiencia en el uso de los recursos. Con-

cretamente el uso del agua no salada y apta para la agricultura. Siendo este un tema
especialmente de actualidad por las anteriormente mencionadas sequı́as y la escasez de
1
Introducción
agua en algunas zonas del planeta. Mediante la implementación de un sistema de con-

trol IoT automático, es posible optimizar el consumo de energı́a, agua y nutrientes. Por
ejemplo, se pueden programar sistemas de riego inteligentes que suministren la cantidad
precisa de agua en el momento adecuado, evitando desperdicios y asegurando un uso efi-
ciente. Esto no solo tiene beneficios económicos, sino también ambientales, al reducir el
consumo de recursos naturales y minimizar el impacto ambiental. Aunque este trabajo
no se centrará en la gestión de recursos como horas de riego, fertilizantes y/o pesticidas,
tendrá en cuenta dejar opción a su implementación en el futuro.
Además, el sistema de control IoT proporciona la capacidad de recopilar datos en tiem-

po real sobre las condiciones del entorno o del cultivo. Estos datos pueden utilizarse para
obtener información valiosa sobre el rendimiento de las plantas, identificar patrones de
crecimiento, predecir problemas potenciales y tomar decisiones informadas para mejorar
el sistema. La posibilidad de obtener información detallada y actualizada contribuye al
desarrollo de estrategias de cultivo más eficientes y sostenibles.
En resumen, la implementación de un sistema de control IoT automático en un entorno

botánico o en el ámbito de cultivo de especies vegetales ofrece numerosas motivaciones, co-
mo la optimización de las condiciones ambientales, la automatización de tareas, la eficiencia
en el uso de recursos y la obtención de información precisa para la toma de decisiones.
Estos beneficios convergen en un objetivo común: proporcionar un entorno propicio para
el cultivo de las plantas, ya sea a escala industrial o doméstica.
1.2. Objetivos
En este trabajo se pretende explicar el diseño de un sistema de control autónomo para un
entorno botánico. Dicho sistema deberá cumplir ciertos requisitos en lo que a la seguridad
se refiere:
El sistema debe ser seguro para las especies que sean monitorizadas por este sistema,
es decir, el sistema no debe de permitir adoptar configuraciones que puedan resultar
perjudiciales para las plantas. Entendiéndose como perjudiciales aquellas que puedan
provocar la muerte no intencionada de las plantas.
El sistema debe ser seguro en lo que respecta a la comunicación, es decir, no debe

permitir que se pueda obtener información sobre el sistema ni introducir información
exógena que, además, pueda ser maliciosa.
Los elementos del sistema deben estar autenticados, es decir, solo dispositivos váli-
dos deberan poder acceder a él. Y los mensajes deberán contener información que
permita identificar al emisor.
El sistema deberá ser escalable, permitiendo el control de un número de dispositivos

comprendido entre las unidades hasta los centenares.
A excepción del controlador1 (o dispositivo maestro) habrá que valorar la autonomı́a

de los dispositivos.
1
En caso de querer escalar más allá de los objetivos del trabajo habrá que considerar añadir más
controladores.
2
1.3. Profundización en los objetivos
1.3. Profundización en los objetivos

MQTT es un protocolo de comunicación, muy popular en entornos IoT, que funcio-
na mediante un esquema de publicación y suscripción. En estas comunicaciones exisen
principalmente un servidor encargado de gestionar los mensajes y clientes de dos tipos:
publicadores y suscriptores. El diseño del sistema de control IOT partirá con la base de
una red MQTT. Esta arquitectura se basa en un sistema de publicación y suscripción. En
este tipo de sistemas los dispositivos tienen la opción de subscribirse a distintos temas2
de comunicación y cada mensaje se debe publicar en uno de los temas disponibles. Los
dispositivos suscritos a un determinado canal reciben los mensajes publicados en él.
Los dispositivos que controlarán directamente los sensores y actuadores serán implemen-
taciones del microcontrolador ESP32. Mientras que el dispositivo encargado de organizar,
gestionar y administrar el sistema IOT, será una Raspberry Pi 3.
1.3.1. Variables a controlar

Dado que el entorno vegetal esta orientado al cuidado de plantas, se controlarán las
condiciones de temperatura, humedad (tanto eh ambiente como en tierra), luz y gases.
Para medir la temperatura se utilizará termómetro, el cual puede ser emparejado con un
sistema de calefacción para garantizar la constancia de la temperatura. Para controlar la
humedad se utilizará un sensor de humedad (ambiental y en el suelo) y para controlar los
valores un humidificador y un sistema de riego, como puede ser el riego por goteo. Para
controlar la luz se utilizará un sensor de luz y un sistema de iluminación, el propósito del
control de esta variable es para medir que las plantas reciben las horas de luz necesarias
aún cuando no hay luz natural. La información relativa a la concentración de gases presen-
tes (CO2 por ser necesario para la fotosı́ntesis de las plantas y O2 por ser resultado de la
misma) en el aire será únicamente de carácter informativo, para enriquecer la recopilación
de datos y poder monitorizar con más precisión el crecimiento de las especies.
1.3.2. Detalles de los sensores y actuadores

La comunicación de datos y comandos se efectuará en el ámbito de una red MQTT, por
lo que existirán tres tipos de dispositivos (o roles):
1. El broker : Este dispositivo será el encargado de controlar y gestionar, a modod de

intermediario, las comunicaciones entre los demás. En este caso el dispositivo maestro
será una Raspberry Pi 3.
2. Los editores: Estos dispositivos serán los encargados de publicar los mensajes en la
red. En este caso serán los microcontroladores esp32 que tengan acceso a sensores y
necesiten publicar datos leidos de dichos sensores.
3. Los suscriptores: Estos dispositivos serán suscribtores en los diferentes temas de la

red. En este caso serán los esp32 que tengan acceso a actuadores y requieran de
datos y órdenes externas para realizar cambios en los distintos habitáts.
2
Pudiendo comparar tema con la analogı́a de una revista en la que la editorial publica ediciones y los
subscriptores tienen acceso a estas publicaciones.
3
Introducción
Todo los detalles de estos tres dispositivos anteriormente se tratarán en profundidad

más adelante.
Dado que hay una gran diferencia entre todas las variables a controlar, los sensores y
actuadores que se utilizarán serán muy variados. Esta variabilidad en los modelos repercute
en el número de protocolos de comunicación hardware necesarios para controlarlos (I²C3 ,
SPI4 , GPIO5 ), tiempos de refresco, tamaño en bytes de las mediciones y/o órdenes, etc.
Por lo tanto, se deberá tener en cuenta la variabilidad de los sensores y actuadores a la
hora de diseñar la arquitectura del sistema.
1.3.3. Detalles de la Comunicación

Como ya se ha mencionado la comunicación entre los distintos dispositivos se realizará
a través de una red MQTT. El trabajo de diseño a realizar es el de definir la estructura
de los mensajes que se enviarán a través de la red. Para ello se deberá valorar las distintas
opciones disponibles para la construcción de mensajes, tanto de datos como de órdenes.
Además habrá que definir el esquema de seguridad que se utilizará para la comunicación
entre los dispositivos.
La seguridad en las comunicaciones deberá cumplir con dos requisitos:
Ser confidencial, es decir, que los mensajes no puedan ser leı́dos por terceros.
Ser autenticada para evitar que terceros puedan enviar mensajes falsos.
Esto se conseguirá mediante el uso de algoritmos de cifrado, identificadores únicos y sumas

de control6 .
1.3.4. Detalles de la operación de los dispositivos

Como se ha mencionado anteriormente, para los dispositivos de medición y actuación
deberá considerarse la posibilidad de operarlos de un modo autónomo, es decir, sin la
necesidad de una conexión a la red eléctrica. Para ello se deberá estudiar las opciones
de ahorro de energı́a en estos dispositivos y la posibilidad de utilizar baterı́as para su
funcionamiento. Además se deberá considerar la posibilidad de que los dispositivos se
puedan conectar a la red eléctrica en cualquier momento, para recargar las baterı́as y
posiblemente actualizar el firmware.
Se deberá suponer que el firmware recibirá actualizaciones periódicas, por lo tanto se
deberá considerar la posibilidad de actualizar el firmware de los dispositivos de forma
remota, y en caso de no ser posible, facilitar la actualización de los dispositivos de forma
manual.
3
https://www.i2c-bus.org/
4
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
5
https://es.wikipedia.org/wiki/GPIO
6
https://es.wikipedia.org/wiki/Cifrado_(criptograf a), https://es.wikipedia.org/w
iki/Identificador_ nico_universal, https://es.wikipedia.org/wiki/Identificador_ nico,
https://es.wikipedia.org/wiki/Suma_de_verificacin
4
2 Estado del arte
2.1. Contexto
El internet de las cosas está cada vez más cerca y más integrado en las vidas de las
personas. Partiendo desde dispositivos más estáticos como podrı́a ser la puerta de una
cochera, o un contador de luz hasta elementos más interactivos como un robot de cocina,
nevera o sensores de glucosa para diabéticos. Aunque incluido el ámbito doméstico no es
el único espacio en el que se encuentran estos sistemas. En la industria, la agricultura, la
sanidad, la educación, etc, en todos estos ámbitos surge la necesidad de diseñar sistemas
seguros y fiables que puedan ser utilizados por personas comunes.
2.2. Situación actual

Desde el principio de las sociedades modernas el control de acceso, privacidad y confiden-
cialidad de la información y/o sistemas ha sido una preocupación, debido a la existencia
de individuos malintencionados que buscan obtener beneficio a costa de la información de
otros. En la actualidad, con el desarrollo de la tecnologı́a y sobre todo el acceso universal
a la información, este tipo de individuos malintencionados han sofisticado y adaptado sus
técnicas maliciosas a la nueva realidad.
El campo del internet de las cosas es un campo relativamente nuevo, de hecho, según un
articulo de RFID Journal[4] el orı́gen o la primera vez que se acuñó el término internet de
las cosas (Internet Of Things) fue en 1999, a raiz de una edición de P&G Annual Report1 .
A pesar de ser un área de desarrollo reciente se ha expandido con gran rapidez, y por esta
expansión y su presencia en areas delicadas potencialmente lucrativas, se ha convertido en
un objetivo de los ciberdelincuentes.
Comparando datos, recogidos por la empresa Kaspersky, del ultimo semestre de 2020 con
el primero del siguiente año, se puede observar como el número de ataques a dispositivos
IOT aumenta un 100 %[5], [6], llegando a cifras de 1.5 billones de ataques según informes
de esta misma empresa.
Pais % de ataques
1 China 42.19 %
2 India 14.20 %
3 Estados Unidos 5.07 %
4 Rusia 4.22 %
5 Brasil 3.83 %
Figura 2.1: Paı́ses con más ataques sufridos IOT en el primer semestre de 2021.[6]
1
https://s1.q4cdn.com/695946674/files/doc_financials/1999/5f4c9889-9888-fad2-4f33-b24
dbe5ba9e5.pdf
5
Estado del arte
Tipo de malware % de ataques

1 Backdoor.Linux.Mirai.b 48.25 %
2 Trojan-Downloader.Linux.NyaDrop.b 13.57 %
3 Backdoor.Linux.Mirai.ba 6.54 %
4 Backdoor.Linux.Gafgyt.a 5.51 %
5 Backdoor.Linux.Agent.bc 4.48 %
Figura 2.2: Malware instalado en el dispositivo después de un ataque.[6]
Con la creciente amenaza también surge la necesidada de protegerse contra estos ata-
ques por lo que surgen organizaciones[7], leyes, decretos[8] e informes[9], para intentar
estandarizar, regular y dar a conocer procedimientos y buenas prácticas. Todo lo anterior
con el objetivo de proteger a los usuarios de estos dispositivos y a la sociedad en general.
Otro aspecto a mencionar es el hardware sobre el que se implementan estos sistemas

de IOT. Ası́ como en la informática tradicional existen diferentes dispositivos con mejores
o peores prestaciones dependiendo de la gama del mismo. Para algunas tareas de IOT2
podrı́a servir un ordenador común, sin embargo existen dispositivos más especializados que
pueden ser más eficientes y baratos. Algunos ejemplos de estos dispositivos son: Raspberry
Pi, Arduino, ESP32, STM32, etc. Que además de ser más asequibles y pequeños que un
ordenador común, también cuentan con peculiaridades especı́ficas como son los numerosos
puertos de entrada salida (GPIO), de comunicación (UART, I2C, SPI, etc.), modos de
bajo consumo, etc.
Incluso dentro de estos dispositivos hay grandes diferencias, por ejemplo las Raspberry
Pi 3 puede hacer las veces de ordenador de propósito general, teniendo capacidad de ins-
talar y ejecutar correctamente distribuciones de sistemas operativos genenralistas del tipo
Linux por ejemplo. Por otro lado los ESPs o arduinos son microcontroladores que solo
ejecutan un programa3 o firmware.
En un contexto más cercano a este proyecto podemos hablar de los dispositivos dispo-
nibles en el mercado. Por ejemplo, existen implementaciones comercializadas4 y multitud
de tutoriales5 para implementar sistemas de riego inteligentes.
En ámbitos industriales como puede ser un vivero, invernadero, floristerı́a... no se en-
cuentran empresas que ofrezcan soluciones adaptables para todas estas situaciones. Aunque
para escenarios caseros o para el mundo maker6 si existen soluciones estas cuentan con dos
inconvenientes principales: (1) El primero es la poca documentación de la construcción del
dispositivo7 y (2) el segundo es la falta de seguridad en estos dispositivos. En muchos casos
2
Por ejemplo como gestor de la información o servidor MQTT, que se verá más a delante.
3
Refiriendose a Proceso pesado capaz de ejecutar multiples hilos concurrentemente pero sin la estruc-
tura de un sistema operativo
4
Por ejemplo: https://es.aliexpress.com/item/4000049645084.html?gatewayAdapt=glo2esp,
https://www.amazon.co.uk/Reland-Sun-Capacitive-Moisture-Temperature/dp/B099FKKKH3...
5
Como: https://docs.arduino.cc/tutorials/mkr-iot-carrier/smart-garden-project, https:
//dronebotworkshop.com/soil-moisture/...
6
La cultura maker: https://es.wikipedia.org/wiki/Cultura_Maker
7
Esto se verá reflejado más adelante en el apartado de desarrollo con un dispositivo usado en este
proyecto.
6
2.2. Situación actual
las soluciones de firmware que proponen estos turoriales, o directamente comercializan los
creadores de estos dispositivos, son esencialmente inseguras.
Esta falta de seguridad tiene como consecuencia la exposición total de datos a un ata-
cante, además de la posibilidad de que el atacante pueda tomar el control del sistema, y
arruinarlo definitivamente, o secuestrarlo y pedir un rescate por el mismo.
7
3 Desarrollo
3.1. Primeros pasos

La primera decisión a la hora de comenzar el diseño de la estructura del sistema fue la
de elegir los dispositivos sobre los que se iba a construir el sistema.
3.1.1. Dispositivos
3.1.1.1. Raspberry PI 3
El dispositivo encargado de gestionar la red, control de acceso, y en una posible expan-

sión del sistema, albergar una interfaz gráfica para el usuario, será una Raspberry PI 3.
El motivo de esta elección es que se trata de un dispositivo de bajo coste, con un consumo
energético muy bajo (llegando hasta los 5µAh), y que cuenta con una gran comunidad de
desarrolladores detrás, lo que facilita la búsqueda de soluciones a problemas que puedan
surgir durante el desarrollo del sistema. Entre las opciones disponibles estaba un ordena-
dor de sobremesa o, más adecuadamente, un NUC1 . Sin embargo, factores como el elevado
coste y consumo energético de estos dispositivos, los descartaron como opciones viables.
La Raspberry PI 3, únicamente existirá un dispositivo de estos en el sistema. Este

dispositivo es equivalente a un ordenador de bajas capacidades y cuenta con las siguientes
caracterı́sticas:
Quad Core 1.2GHz Broadcom BCM2837 64bit CPU
1GB RAM
Conectividad USB, ethernet, HDMI.
Capacidad de conexión inalámbrica WiFi y Bluetooth.
40 pines GPIO con capacidad de que sean usados como puertos I/O con protocolos
como I2C, SPI, UART, etc.
Puertos CSI y DSI para cámara y pantalla.
1
Ver https://www.intel.com/content/www/us/en/products/docs/boards-kits/nuc/what-is-nuc
-article.html
9
Desarrollo
Figura 3.1: Raspberry PI 3 [10]
Aunque en este proyecto no se vaya a considerar el desarrollo de una interfaz gráfica, el

sistema deberá contar con una interfaz la cual permita controlar y monitorizar el sistema.
Por lo que la capacidad de instalar un sistema operativo en el dispositivo es una carac-
terı́stica prácticamente necesaria2 . Además esto ofrecerı́a una interfaz más amigable a un
usuario que no contase con conocimientos avanzados en informática.
Los fabricantes de este dispositivo ofrecen un sistema operativo basado en Linux lla-
mado Raspberry PI OS, una versión modificada de la distribución Debian de Linux. Este
sistema operativo está diseñado especificamente para este dispositivo. Lo distribuyen di-
rectamente los fabricantes y se puede descargar desde la página oficial de Raspberry PI[11].
Figura 3.2: Esquema de conexiones, SSH y nube MQTT
Tal y como se ilustra en el diagrama, la gestión de este dispositivo se realizará a través

del protocolo SSH3 . Un protocolo que permite el acceso a la consola del servidor4 de forma
2
Esta necesidad, o conveniencia, viene del requerimiento de contar con aplicaciones como ssh para
control remoto, o más importante, hostear un servidor MQTT.
3
https://en.wikipedia.org/wiki/Secure_Shell
4
En este caso el servidor es la Raspberry
10
3.1. Primeros pasos
remota y segura. La Raspberry será donde se aloje el servidor (también llamado broker)
MQTT. Para ello, se utilizará el software Mosquitto[12], un servidor MQTT de código
abierto.
La elección de este software para el servidor MQTT se debe a dos motivos principales[12]:
(1) ’implementa las versiones 5.0, 3.1 y 3.1.1 del protocolo MQTT’ y (2) está clasificado
como ’lightweight’ (ligero) permitiendo un uso eficiente en dispositivos poco potentes como
los que forman parte de un sistema pequeño IoT. Los detalles de los roles y funcionamiento
de un servidor MQTT se explicarán más adelante en este documento.
3.1.1.2. ESP32
El segundo dispositivo a tener en cuenta del sistema será el ESP32, un microcontro-

lador de bajo coste con capacidad de conectividad WiFi y Bluetooth. Mientras que para
el dispositivo responsable del papel de broker hubo una elección clara, en el caso de los
clientes la elección no fue tan directa debido a la variedad de opciones disponibles. En las
siguientes figuras se ilustran las opciones que se tuvieron en cuenta en las últimas decisio-
nes del proceso de selección.
(a) ESP8266 (b) ESP32
(c) Arduino Uno (d) Arduino Pro Mini
ESP8266 ESP32 Arduino Uno Arduino Pro Mini

Precio 4 − 6€ 5 − 12€ 20 − 25€ 10 − 20€
WiFi HT20 HT40 X X
Bluetooth X 4.2 & BLE X X
Canales PWM 8 16 6 6
Pines GPIO 17 34 20 22
Voltaje de entrada 3.3V/5V 3.3V/5V 5V 5V
Figura 3.4: Comparativa de dispositivos 5
11
Desarrollo
Además de las especificaciones técnicas de cada dispositivo, se tuvo en cuenta el entorno

de desarrollo y frameworks disponibles para desarrollar firmware para cada uno de ellos.
Una herramienta popular en el mundo maker y de la IoT ’de andar por casa’ es el IDE de
Arduino6 , y capaz de generar programas para todos los dispositivos valorados, sin embargo
para los ESPs existen alternativas más potentes y flexibles como el framework Espressif7 ,
una alternativa que ofrece mayor libertad a cambio de una complejidad ligeramente mayor.
Además de la preferencia por el entorno de desarrollo Espressif, los ESPs ofrecen me-
jores prestaciones a menor precio. Esto se manifiesta en temas como por ejemplo Wifi y
Bluetooth, incluidos en el propio chip; más variedad en cuanto a la conectividad y capa-
cidades de comunicación8 .
Otro aspecto en el que son superiores los ESPs es en el consumo de energı́a. Los proce-
sadores de los ESPs operan con una tensión de alimentación de 3.3V de entrada. Aunque
pueden operar con una tensión de entrada de 5V ya que vienen con reguladores para hacer-
los compatibles con la salida de potencia estándar del protocolo USB9 y permitir alimentar
algunos sensores y/o actuadores que puedan requerir 5V. Por otro lado los procesadores
de arduino esperan una tensión de 5V, aunque son capaces de funcionar a 3.3V reduciendo
frequencia. Además de la ventaja que es alimentar estos chips (los ESPs) con una tensión
inferior, cuentan con métodos de ahorro de energı́a que pueden llegar a ser más eficaces.
Tanto los ESPs como las placas de arduino cuentan con métodos para apagar ciertas
partes de los chips, como pueden ser los procesadores principales, controladores ADC10 ,
relojes internos, etc. Sin embargo hay dos aspectos en los que la gama ESP es superior a la
de arduino: (1) los ESPs cuentan con un llamado ULP Coprocessor[13], una máquina de es-
tados finitos de bajo consumo capaz de ejecutar código en paralelo al procesador principal
o siendo este el único procesador activo, y (2) los ESPs logran llegar a valores inferio-
res de consumo de corriente. Según experimentos realizados y documentados[14]-[16] por
usuarios. Haciendo referencia a la ficha técnica[17] del microprocesador ATMEGA328p11 ,
el procesador de los arduino es capaz de llegar a consumir corrientes de entre 30.8µA
y 6.2µA. Por otro lado, siguiendo el mismo proceso de consultar la ficha técnica[18] del
microprocesador ESP32 y algunos experimentos [19], [20] del mundo maker, los el esp32
puede reducir su corriente de alimentación hasta 2.5µA.
5
Datos obtenidos de makeadvisor.com para los ESPs y arduino.cc para el Arduino Uno y para el
Arduino Pro Mini.
6
https://www.arduino.cc/en/software/
7
https://www.espressif.com/en/products/sdks/esp-idf
8
Refiriendose a capacidades de comunicación a los canales I2C (no ilustrados en la tabla 3.4), más
canales de generación de pulsos (PWM), mayor número de pines GPIO entre otras.
9
https://es.wikipedia.org/wiki/Universal_Serial_Bus
10
Analog to Digital Converter o conversor de analógico a digital
11
Este microprocesador es el núcleo de los arduino.
12
3.1. Primeros pasos
Figura 3.5: Diagrama de bloques de funciones[21]
Otro aspecto, y de gran relevancia en este trabajo, por el que destaca el ESP32 es por
contar con aceleradores hardware. Los aceleradores criptogŕaficos son módulos hardwa-
re dentro del procesador diseñados especı́ficamente para hacer operaciones especı́ficas. El
microcontrolador Esp32 cuenta con tres aceleradores[18]: (1) para hasheado, (2) para ci-
frado simétrico y (3) cifrado asimétrico. También cuenta con un módulo para mejorar los
números aleatorios que puede generar un chip de ese tamaño.
En ámbitos donde la criptografı́a es importante un buen generador de números aleatorio
es crucial12 a la hora de generar claves y valores secretos e impredecibles. En dispositivos
tan limitados, y generalmente con un grado de determinismo elevado, es fácil cometer el
error de recoger poca entropı́a para generar estos números aleatorios. La solución imple-
mentada en los ESP32 es tener un módulo hardware que combina fuentes de entropı́a13 co-
mo ruido en la tensión de alimentación, en los puertos de comunicación, sensores ADC. . . Y
posteriormente accediendo al ruido recogido por los módulos de radio frequencias cuando
estos estén habilitados.
Por todo lo anterior el dispositivo encargado de realizar las lecturas de sensores y ma-
nipular los actuadores será un ESP32.
12
Ver: https://www.cryptomathic.com/news-events/blog/the-role-of-random-number-generator
s-in-cryptography https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_numb
er_generator https://en.wikipedia.org/wiki/Key_generation
13
Ver: https://es.wikipedia.org/wiki/Entropa_(informacin)
13
Desarrollo
3.1.2. Software base

3.1.2.1. Red de comunicaciones, protocolo MQTT
Como se ha mencionado anteriormente las comunicaciones entre los dispositivos tendrán
como canal de comunicaciones una red MQTT. El modelo editor-subsciptor, propio de esta
red, se ve reflejado en el siguiente diagrama:
Figura 3.6: Modelo editor/subscriptor
La primera interacción que se produce es la conexión del cliente con el broker, después se
determinará si ese cliente actúa como subscriptor o como editor. En este paso el cliente debe
identificarse con unas credenciales (usuario y contraseña). El broker, tras comprobar la
validez de las credenciales, aceptará o rechazará la conexión. Una vez aceptada la conexión
el cliente tendrá acceso a la red y podrá interactuar en la misma.
Como se observa en el diagrama 3.6 los dispositivos cliente pueden interactuar con
el broker de dos maneras, (1) publicando mensajes o (2) suscribiendose a un tema. Los
mensajes publicados por los clientes son recibidos por el broker y reenviados a todos los
clientes suscritos a ese tema. El broker hace las veces de albacea, de depositario, de los
mensajes y datos que se intercambian agentes y subscriptores.
Dado que es un protocolo de comunicación, MQTT tiene mecanismos para asegurar la
entrega de los mensajes. Nos referimos al llamado QoS (Quality of Service) que se puede
configurar en tres niveles14 : QoS 0, QoS 1 y QoS 2.
Como se ha especificado anteriormente dicha red se desplegará en una raspberry pi

3, este dispositivo ejecutará un Raspberry Pi OS15 y el broker de MQTT Mosquitto16 .
Dado que el dispositivo correspondiente al broker es uno con las capacidades de un orde-
nador de baja gama, también será el administrador del sistema, encargado de gestionar
14
Ordenados de menor a mayor cuidado del mensaje y para más información consultar https://www.
hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/
15
Raspberry Pi OS https://www.raspberrypi.com/software/.
16
Mosquitto es un broker de MQTT de código abierto, desarrollado por eclipse foundation https:
//mosquitto.org/.
14
3.2. Diseño del sistema
las configuraciones de los clientes y proporcionar una interfaz de de comunicación para el

usuario.
Mosquitto es un una implementación pro-
porcionada por la fundación eclipse, de códi-
go abierto y disponible para múltiples distribu-
ciones. Se seleccionó esta implementación por
ser de código abierto, estar implementado en
C17 y por ser capaz de conectarse como cliente Figura 3.7: Logo de Mosquitto[22]
además de hostear el servicio de broker.
3.1.2.2. Espressif, firmware para los ESPs

El firmware que ejecutan los ESPs se desa-
rrolló con el framework ofrecido por Espressif,
ESP-IDF18 .
Framework de código abierto, desarrollado
Figura 3.8: Logo de Espressif[23] por la misma empresa que fabrica los microcon-
troladores. Por lo tanto las librerı́as que ofrece
ESP-IDF son capaces de hacer uso de todas las particularidades 19 y mejoras hardware
que ofrecen estos dispositivos.
Para organizar dependencias, generar binarios y leer datos de las UART20 se usó la
extensión disponible en VSCode de Platform IO21 . Una serie de herramientas diseñadas
especı́ficamente para gestionar el desarrollo de firmware para microcontroladores y disposi-
tivos de IOT. Realmente el propósito de Platform IO es ofrecer una interfaz más amigable
y sencilla de usar para los comandos ofrecidos por ESP-IDF.

Para las pruebas recopiladas en este trabajo se implementó un sistema que siguiendo
las siguientes directrices:
Dispositivos variables ESPs:
1. ESP-DHT11 ⇒
Sensor de temperatura y humedad: DHT11.
Sensor capacitivo de humedad del suelo.
Sensor de luz: BH1750.
17
Lenguaje de programación de bajo nivel, que permite un control más preciso de los recursos del
sistema.
18
ESP-IDF, librerı́as y ejecutables tanto para compilar como para leer y escribir en las distintas zonas
de memoria interna de los chips https://docs.espressif.com/projects/esp-idf/en/latest/esp32/
19
Mencionados anteriormente, los aceleradores criptogŕaficos, generadores de números aleatorios, modos
de sueño. . .
20
Universal Asynchronous Receiver-Transmitter, es un puerto que permite la comunicación serie, en
este caso se puede considerar la consola del dispositivo.
21
https://platformio.org/
15
Desarrollo
(a) Lilygo con tapa (b) Lilygo sin tapa
Figura 3.9: ESP-DHT11, citcuito integrado de LiliGo 22
2. ESP-MS430 ⇒
3. Sensor de temperatura, humedad, presión y gases: BME680[24].
Sensor de intensidad lumı́nica: VEML6030.
Sensor de intensidad sonora: SPH0645LM4H-B.
Figura 3.10: ESP-MS430[25]
4. ESP-BME280 x2⇒
Sensor de temperatura, humedad y presión: BME280[26].
16
Figura 3.11: ESP-BME280
5. ESP-Act⇒
Relé para activar un calefactor.
Relé para activar una bomba hidráulica.
Figura 3.12: ESP32-DevKit, dispositivo encargado de la comunicación con los sensores.
Como es lógico y necesario para su funcionamiento, el sistema contará con la Raspberry

Pi.
17
Desarrollo
Figura 3.13: Raspberry Pi 3.
Estos dispositivos están pensados para un invernadero, como puede ser un vivero. Como
se observa en la lista anterior la temperatura y la humedad ambiental se mide con mucha
más frecuencia que el resto de parámetros. Esto se debe a dos motivos principales, (1)el
primero es que estos parámetros suelen ser de los que más influyen en el desarrollo de las
plantas. Según fuentes[1]-[3]: la humedad relativa es muy importante para el desarrollo de
las plantas porque influye en la transpiración. La transpiración es el proceso por el cual
las plantas expulsan vapor de agua por sus superficies. Cuanto mmenor sea el desquilibrio
en las presiones de vapor de agua entre el interior y el exterior de la planta, menos energı́a
gastará la planta en transpirar y más energı́a podrá dedicar a su crecimiento.
Y (2) la mayorı́a de sensores o dispositivos preparados para medir otros valores (luz,
presión. . . ) cuentan también con sensores de temperatura y humedad. Véanse los casos
del sensor BME680 o los circuitos integrados de LiliGo(ESP-DHT11 ) o MS430.
3.2.1. Comunicación fı́sica
Primero se explicará la comunicación del dispositivo ESP-DHT11. Dado que es un cir-

cuito integrado con los sensores soldados en la placa del dispositivo, la comunicación es
interna y no hay opción de modificarla.
18
Figura 3.14: Esquema de diseño del dispositivo ESP-DHT11[27].
En este dispositivo se cuentan tres sensores. (1) El sensor de humedad y fertilidad en

el suelo, que se comunica a base de mediciones ADC23 . Los pines de conexión de este
sensor son los GPIO32 y GPIO34. (2) El sensor de temperatura y humedad ambiental,
que se comunica a través de un único pin de datos. Sigue un esquema de comunicación24
propio basado en pulsos/señales a través de este pin. Y este pin de datos está conectado al
GPIO16 del Esp32. (3) El sensor de intensidad lumı́nica, que se comunica a través de I2C
(detallado más adelante). Los pines de conexión de este sensor son los GPIO21 y GPIO22.
3.2.1.1. Protocolo I2C

En el resto de dispositivos el ESP32 se comunica con los sensores via protocolo I2C. Este
protocolo es un protocolo de comunicación serie sı́ncrono de dos hilos, un hilo de reloj y
un hilo de datos. El protocolo I2C es un protocolo de comunicación maestro-esclavo, es
decir, el dispositivo maestro es el que inicia la comunicación y el esclavo es el que responde
a las peticiones del maestro. En este caso el ESP32 es el maestro y los sensores son los
esclavos.
Por norma general los dispositivos escalvos cuentan con una dirección única, que les per-
mite ser identificados, y unos registros de lectura y escritura. El maestro para comunicarse
debe direccionar al esclavo al que quiere acceder, especificar que tipo de operación quiere
realizar (lectura o escritura) y la dirección del registro25 al que quiere acceder. Una vez
23
Convertidor analógico-digital, https://es.wikipedia.org/wiki/Conversor_de_seal_analgica_a_
digital
24
Explicación del diagrama de tiempos en https://www.electronicwings.com/sensors-modules/dht
11
25
Los registros tanto de escritura como de lectura de los dispositivos son de 8 bits.
19
Desarrollo
definidos los parámetros de la operación se puede comenzar el intercambio de información.
Ejemplo
Para ilustrar el funcionamiento de este protocolo de comunicación tomaremos el ejemplo
del dispositivo ESP-BME280. Tomamos los diagramas de comunicación para las operacio-
nes de escritura y lectura de la ficha técnica del dispositivo[26].
Escritura
Lectura
Figura 3.15: Diagramas de comunicación para las operaciones de escritura y lectura del
dispositivo ESP-BME280[26].
Los bits que se observan en los diagramas son los correspondientes a los niveles de
tensión en el cable SDA(cable de datos), ya que SCL es el cable de reloj. Todas las
operaciones empiezan (α) con una señal de START y deben terminar con una señal de
STOP. Y después de cada operación de 8 bits se puede enviar una señal de ACK o NACK por
parte del maestro o del esclavo26 . Justo después de la señal de START se envı́an 8 bits(β),
los 7 primeros son la dirección del dispositivo y el último es el bit de lectura/escritura. En
este primer caso el bit 0 será siempre de escritura puesto que la siguiente operación será
una escritura. Especı́ficamente la escritura de la dirección (de 8 bits) del registro al que
se quiere acceder(γ).
En el caso de la escritura, una vez direccionado el dispositivo y el registro, se envı́an los
datos que se quieren escribir en el registro. Si se quiere seguir escribiendo en otro registro
se deben repetir las operaciones desde el direccionamiento del registro.
26
Mandará la señal ACK el dispositivo que reciba los datos de la transmisión
20
Por otro lado la lectura conlleva dos señales de START, la primera ya se ha explicado. La
segunda señal de START se debe enviar después de direccionar el registro(γ) al que se quiere
acceder. Despues de esta segunda señal de START se envı́a la dirección del dispositivo con
el bit de lectura activado, para ordenar al dispositivo esclavo que empiece a enviar datos.
El dispositivo esclavo enviará datos27 (confirmados por el maestro con ACK) hasta que el
maestro manda un NACK, indicando que ya no quiere recibir más datos. Y por supuesto
cerrando la operación con una señal de STOP.
3.2.1.2. Implementación en código

Como se ha mencionado Espressif implementa unas operaciones para facilitar la comuni-
cación con los dispositivos I2C. Las funciones que hacen la gestión de estas comunicaciones
se ven recogidas en el fichero driver/i2c.h de la librerı́a de Espressif.
A continuación se muestra una función auxiliar de desarrollo propio que junta28 todas
las operaciones necesarias para leer un registro de un dispositivo I2C. De las dos mencio-
nadas se muestra la de lectura por el añadido en complejidad por la necesidad de iniciar
operaciones dos veces.
1 esp_err_t i2c_aux_read_reg_from_dev(uint8_t reg , uint8_t *data, size_t size){

2 i2c cmd handle t cmd = i2c_cmd_link_create();
3 esp_err_t ret = i2c master start(cmd);
4 ret |= i2c_master_write_byte(cmd, (i2c_addr << 1) | I2C_MASTER_WRITE, true);
5 ret |= i2c_master_write_byte(cmd, reg , true);
6 ret |= i2c_master_start(cmd);
7 ret |= i2c_master_write_byte(cmd, (i2c_addr << 1) | I2C_MASTER_READ, true);
8 ret |= i2c_master_read(cmd, data, size, I2C_MASTER_LAST_NACK);
9 ret |= i2c_master_stop(cmd);
10 ret |= i2c master cmd begin(i2c port, cmd, 1000 / portTICK PERIOD MS);
11 i2c_cmd_link_delete(cmd);
12 return ret;
13 }
Como funciona esta librerı́a es creando una lista de comandos (i2c_cmd_handle_t)(lı́nea 1)

a la que se van acumulando las operaciones que se quieren realizar. Una vez acumuladas
todas las operaciones se ejecutan con la función i2c_master_cmd_begin()(linea 10)
que traduce a pulsos los datos a enviar y que espera recibir por la lı́nea I2C. La bateria de
operaciones comienza con un START en la lı́nea 3 , seguido de la dirección del dispositivo
con el último bit indicando una operación de escritura (linea 4). Después de direccionar
el dispositivo se especifica el registro al que se quiere acceder: el parámetro reg (linea 5).
Para comenzar la lectura se debe volver a iniciar una operación con un START (linea 6),
seguido de la dirección del dispositivo con el último bit indicando una operación de lectura
(linea 7). Y ya tras todas estas operaciones se puede realizar la lectura con el comando
i2c_master_read() (linea 8). Finalmente se cierra la conexión con el dispositivo con
27
El primer dato será el del registro direccionado, mientras que los siguientes serán de los registros
consecutivos del dispositivo esclavo. Permitiendo de esta manera la lectura en ’burst’ o de ráfaga, para
agilizar lecturas grandes o de muchos datos.
28
Estas funciones de lectura y escritura fueron desarrolladas para mejorar la comprensión del código y
reducir la posibilidad de introducir errores.
21
Desarrollo
un STOP (linea 9). Se ejecuta la comunicación i2c_master_cmd_begin()(linea 10)

y se destruye el struct del manejador para no ocupar recursos de manera innecesaria
(linea 11).
3.2.2. Comunicación inalámbrica

Ya se ha mencionado que la comunicación entre los dispositivos será a través de un
servidor MQTT. Este servidor requerirá necesariamente de una red WiFi para poder
poner en contacto a todos los dispositivos que quieran acceder al sistema.
3.2.2.1. Conexión a la red WiFi

En el caso del dispositivo broker, la Raspberry Pi, se ha optado por una conexión por
cable Ethernet. El motivo principal de esta decisión es prescindir de la necesidad de ac-
tualizar manualmente la contraseña de la red WiFi en el caso de que esta cambiase. En
el caso de este dispositivo es perfectamente viable una conexión ethernet puesto que no
precisa de un espacio abierto para tomar mediciones, o proximidad a una maceta para
interactuar con ella. Como añadido se deberá configurar una dirección IP estática para la
Raspberry. Esto facilitará enormemente la conexión Esp32⇒Servidor MQTT.
Por otro lado están los ESPs, que si precisan de conexión WiFi por dos motivos princi-
pales: (1) no cuentan con pueto ethernet y (2) la ubicación de estos dispositivos introducirá
una dificultad añadida a la hora de conectarlos por cable. De aquı́ surge el problema de la
actualización de credenciales WiFi. Los ESPs no cuentan con un sistema de entrada salida
fácilmente accesible, como puede ser la pareja de teclado y monitor. Además mientras que
Raspberry solo habrá una, el número de ESPs puede elevarse tanto como se desee escalar
el sistema.
La primera opción serı́a introducir las credenciales en el firmware y que estas no cambia-
sen nunca. Esta opción es poco segura puesto que, ya de por si es recomendable cambiar
la contraseña de las redes WiFi de manera más o menos regular, en caso de detectar un
intruso en la red WiFi se deberı́a cambiar la contraseña de la red. Este cambio de contra-
seña implicarı́a tener que volver a cargar el firmware en todos los ESPs, lo que supone un
trabajo, tiempo y conocimientos que en un caso de uso real no serı́a viable. Sobre todo
porque para generar y subir el firmware serı́a necesario desmontar los dispositivos de su
ubicación y volverlos a montar una vez actualizados.
Bien es cierto que existen mecanismos de actualización OTA29 (Over The Air) que
permiten actualizar el firmware de los ESPs sin necesidad de desmontarlos. Pero existen
soluciones más sencillas y eficientes para este problema.
Esta solución es usar WPS30 (WiFi Protected Setup). Con esta solución se pueden
conectar los dispositivos a la red WiFi sin necesidad de introducir la configuración de la
red en el firmware. El proceso de conexión es tan sencillo como presionar un botón en el
router y esperar a que el Esp32 se conecte a la red WiFi. La única pega es que hay que
conectar cada dispositivo de manera individual31 , pero es un proceso que no requiere de
conocimientos técnicos.
29
Ver: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/
ota.html
30
Ver: https://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup
31
Es decir cada vez que se presiona el boton en el router solo puede establecerse una nueva conexión
22
3.2.2.2. Implementación (ESP32)

Una vez más se hizo uso de las librerı́as ofrecidas por el entorno de desarrollo, junto a
código de ejemplo ofrecido en la documentación oficial32
La conexión a la red de comunicaciones es lo primero que debe hacer un dispositivo
tanto al arrancar como al salir de algún estado de suspensión. Como hemos mencionado
antes, la conexión a la red WiFi se realiza mediante WPS. Lo que requiere de una acción
por parte del administrador del sistema. Es deseable que solo haga falta configurar la
conexión WiFi una única vez33 , por lo que se ha implementado un sistema de guardado
de credenciales en la memoria no volátil (NVM) del ESP32.
El procedimiento de arranque del dispositivo es el siguiente:
Figura 3.16: Diagrama de flujo de la conexión WiFi
3.2.2.3. Servidor MQTT

Una vez todos los dispositivos están conectados a la red WiFi, el siguiente paso es hablar
del servidor MQTT. La primera acción de configuración al montar el sistema es establecer
las reglas del servidor MQTT.
Configuración del Broker

Estas reglas se resumen en las dos siguientes: (1) la primera es que el servidor debe
aceptar conexiones de otras máquinas34 y (2) configurar las credenciales de acceso para
cada dispositivo.
32
Ver: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network
/esp_wifi.html
33
O cada vez que se cambie la contraseña de la red WiFi
34
Por defecto el servidor solo acepta conexiones locales (localhost)
23
Desarrollo
Para permitir conexiones de otras máquinas en la misma red local hace falta modificar
el fichero de configuración del servidor MQTT añadiendo:
1 listener 1883 0.0.0.0
Esta lı́nea indica que el servidor debe escuchar en el puerto 1883 de la máquina local. Y
además aceptar conexiones provenientes de cualquier dirección IP.
Para configurar las credenciales de acceso al servidor MQTT se debe especificar el fichero
de contraseñas en el fichero de configuración del servidor.
1 password_file /etc/mosquitto/passwd
Y una vez especificado el fichero de contraseñas se añaden entradas al fichero de contraseñas

con el siguiente comando:
$> mosquitto_passwd /etc/mosquitto/passwd <username>
Tras ejecutar este comando se pedirá al usuario que introduzca la contraseña para el
usuario especificado. Como resultado del comando anterior se creará una entrada en el
fichero de contraseñas especificado con el nombre de usuario y la contraseña cifrada35 .
Conexión desde los ESPs

Una vez configurado el servidor MQTT, el siguiente paso es conectar los ESPs al servi-
dor. Como se ha mencionado la IP de la Raspberry es estática, por lo que no será necesaria
la labor de búsqueda para descubrir la IP de la Raspberry.
Este proceso es tan simple como definir un struct c y llamar a la función esp_mqtt_ ⌋
client_init/1 con el struct como argumento.
1 esp_mqtt_client_config_t mqtt_cfg = {
2 .broker.address.uri = "mqtt://192.168.0.100:1883",
3 .credentials.username = "example_username",
4 .credentials.authentication.password = "example_password",
5 .session.disable_clean_session = true,
6 };
7 esp_mqtt_client_handle_t client = esp_mqtt_client_init(&mqtt_cfg);
Una vez llamada la función de inicio del servicio MQTT, hará falta llamar a esp_mqtt_ ⌋
client_register_event() para registrar una función que se ocupará de gestionar los
eventos (o mensajes) que se reciban del servidor MQTT. Para la suscripción y publicación
de mensajes se usan las funciones esp_mqtt_client_subscribe() y esp_mqtt_client_ ⌋
publish() respectivamente.
3.2.3. Diseño del mensaje

Con todo lo anterior los dispositivos ya están conectados y pueden comunicarse entre
ellos. Hasta este punto se han implementado medidas de seguridad en cada paso, recapiu-
lando:
35
La contraseña se guarda en un formato similar a crypt(3) https://mosquitto.org/man/mosquitto_
passwd-1.html
24
1. La red WiFi está protegida por una contraseña que además de cumplir con los
requisitos de seguridad de una contraseña, es fácilmente modificable.
2. El servidor MQTT se ejecuta en una Raspberry a la que no se tendrá fácil acceso

fı́sico. Y se controlará a través de SSH.
3. El servidor MQTT solo acepta conexiones de dispositivos que se autentiquen con

unas credenciales válidas.
Aún con todas estas precauciones se decidió añadir otra capa más, puesto que si la
Raspberry y la red WiFi/router son comprometidos, el sistema quedarı́a accesible a un
posible atacante.
3.2.3.1. Seguridad del mensaje

Dado que el objetivo de esta capa de seguridad es que un dispositivo intruso suscrito
a un tema no pueda leer los mensajes que se envı́an a ese tema, se decidió cifrar los
mensajes. Todas las operaciones criptográficas provienen de la librerı́a mbedtls36 . Esta es
la librerı́a criptográfica que usa Espressif en su SDK, además haciendo uso de esta librerı́a
se aprovechan las optimizaciones hardware (aceleradores criptográficos) que incluye el
ESP32.
3.2.3.2. Cifrado
A la hora de cifrar hay varias decisiones que tomar, la primera es el tipo de cifrado a
usar. En el mundo de la criptografı́a existen dos maneras de cifrar mensajes: simétrica y
asimétrica 37 . La criptografı́a simétrica es aquella en la que se usa la misma clave para
cifrar y descifrar el mensaje. Mientras que la criptografı́a asimétrica usa dos claves, una
para cifrar y otra para descifrar.
En este escenario el cifrado simétrico presenta ventajas sobre el cifrado asimétrico. La

primera es la velocidad, puesto que las operaciones de cifrado y descifrado son más rápidas
en el caso simétrico. Otra ventaja es la gestión de claves, en el caso de la criptografı́a
simétrica solo hace falta una clave que pueden compartir todos los dispositivos. Mientras
que en el caso de la criptografı́a asimétrica cada dispositivo debe tener su propia clave
privada y la clave pública de los demás dispositivos.
Esta necesidad de compartir claves introduce el inconveniente de, ¿Cuando se comparten
las claves? Existen dos opciones, (1) en el momento de la generación del firmware o (2)
con el sistema corriendo. Si es en el momento de la generación del firmware, a la hora de
querer introducir un nuevo dispositivo en el sistema, se deberı́a generar un nuevo firmware
para todos los dispositivos existentes. Haciendo de esta opción una solución poco operable
en un ámbito real. Y si por otro lado la clave la publican a un servidor o al mismo broker
MQTT, no hay manera de verificar la identidad de esta clave. Por lo que un atacante
podrı́a saltarse esta capa de seguridad publicando su propia clave y recibiendo la pública
del resto de dispositivos.
36
Ver: https://tls.mbed.org/ y https://docs.espressif.com/projects/esp-idf/en/latest/esp
32/api-reference/protocols/mbedtls.html
37
Más información en: https://en.wikipedia.org/wiki/Symmetric- key_algorithm y https:
//en.wikipedia.org/wiki/Public-key_cryptography
25
Desarrollo
Por lo que a consecuencia de los motivos expuestos anteriormente se decidió usar crip-
tografı́a simétrica.
Una vez decidido el tipo de cifrado, la siguiente decisión es la de que algoritmo usar.
La suite criptográfica de MbedTls38 ofrece algoritmos de cifrado simétrico como el AES,
DES, 3DES, Blowfish, etc.
El algoritmo elegido fue el AES, un cifrador de bloques, principalmente por dos motivos:
(1) no es un algorimo nuevo, por lo que se ha probado su seguridad y (2) los ESPs cuentan
con un acelerador criptográfico para este algoritmo. El acelerador marca la grán diferencia
a la hora de elegir este, el AES, frente a los cifradores de flujo. En una pequeña prueba
realizada se midieron los tiempos de establecimiento de clave y de cifrado de un mensaje
de 2048 bytes.
Aes-128
Tiempo medio de establecimiento de clave: 3µs
Tiempo medio de cifrado: 562µs
Blowfish-32
Tiempo medio de establecimiento de clave: 3556µs
Tiempo medio de cifrado: 2108µs
Tras esta clara diferencia tanto en el establecimiento de la clave como en el cifrado de

los mensajes, se decidió usar el algoritmo AES.
Y ya como últimas consideraciones referente al cifrado se decidió usar el modo CBC,

para poder garantizar que dos mensajes cifrados nunca repitan bloque. Y el tamaño de
la clave, como los mensajes que se retransmitirán por la red no serán demasiado grandes,
se decidió usar una clave de 128 bits. Además, en la búsqueda de velocidad, AES con un
tamaño de clave de 256 bits es un 40 % más lento en sus operaciones que AES-128. Como
ventaja AES-256 es más robusto frente a ataques de fuerza bruta, sin embargo, hoy en dia
sigue siendo inviable atacar AES-128 por fuerza bruta. Por lo que no se consideró como
una ventaja suficiente para sacrificar velocidad.
Llevamos mencionando la velocidad como motivo de peso para elegir un algoritmo u otro.
Esto es por la traducción directa que tiene a la energı́a consumida. Como sabemos, estos
dispositivos tienen que intentar reducir el consumo energético al máximo, para alargar la
duración que puede estar funcionando con una baterı́a. Por lo que cuanto menos tarden
en realizar las operaciones de comunicación, antes podrás volver a un estado de letargo y
reducir ası́ el consumo energético.
Para verificar la implementación de este algoritmo se llevó a cabo pruevas con ’test
vectors’ ofrecidos por la página oficial del NIST39 .
38
Aquı́ se detalla una lista de algoritmos: https://en.wikipedia.org/wiki/Mbed_TLS
39
Ver: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/block-c
iphers
26
3.2.3.3. Verificación de integridad

En una comunicación segura no solo es importante que los mensajes no sean legibles
por un atacante, sino que también es importante que el mensaje no haya sido modificado.
Aunque en este caso la modificación de un bit en el bloque cifrado n del mensaje convertirı́a
en ilegible ese y todos los posteriores40 . Hay que detectar esta modificación. Para esto se
decidió añadir una suma de control del mensaje antes del cifrado.
Para esta suma de control (Hash) no hacı́a falta seleccionar un algoritmo altamente
robusto, puesto que no va a ser obeto de ataque. En otras palabras, la seguridad de
la comunicación depende del cifrado, la suma de control es únicamente para garantizar
integridad ante posible ruido o modificación de los mensajes. Por lo que se decidió usar el
algoritmo SHA-1. Es una función hash que devuelve 20 bytes de longitud, suficientes para
detectar modificaciones en el mensaje. Es el más pequeño de la familia SHA, por lo que
es el más rápido de todos y ocupa el menor espacio a la hora de transmitirlo por la red.
De igual manera que se probó la implementación del algoritmo de cifrado, con SHA-1
también se comprobó la implementación41 .
3.2.3.4. Estructura del mensaje en claro

Para transmitir información se consideraron dos opciones, (a) construir el mensaje en
claro con un formato propio o (b) usar un formato estándar como puede ser JSON. JSON42
es un formato de texto plano que permite representar información de manera estructurada.
Esto tiene las siguientes consecuencias, (1) únicamente contiene caracteres imprimibles,
por lo que detectar corrupción de datos es más sencillo. (2) Es un formato legible y
comprensible para el usuario. (3) Añade longitud al mensaje a la hora de transmitirlo por
la red.
Como el mensaje no se va a mostrar al usuario y el mensaje se retransmitirá con su suma
de control, se decidió usar un formato propio. Porque de esta maner se puede reducir el
tamaño del mensaje mejorando la velocidad y los recursos necesarios para la comunicación.
Elementos del mensaje
Hash del mensaje.
Identificador del dispositivo.
Marca temporal.
Datos del sensor o comandos de configuración.
Los campos se organizarán en el orden en el que aparecen en la lista anterior. Este

orden no ha sido aleatorio, el hash debe ir lo primero. Esta peculiaridad permite que dos
mensajes que contengan la misma información (de los sensores) no contengan colisiones en
el texto cifrado. Como hemos mencionado el modo de encadenamiento para el cifrado es
CBC, por lo que modificaciones en primer bloque del cifrado se propagan a los siguientes.
40
Este arrastre del error viene por el modo de encadenamiento CBC https://www.educative.io/ans
wers/what-is-cbc.
41
Los vectores de prueba provienen de: https://www.di-mgt.com.au/sha_testvectors.html
42
Ver: https://www.json.org/json-en.html
27
Desarrollo
El hash lo ponemos lo primero porque dos mensajes nunca serán iguales. Nunca serán
iguales porque: aunque los datos de los sensores sean los mismos, la marca temporal será
distinta. Y si se diese la casualidad de que dos dispositivos distintos leen los mismos datos
y construyen el mensaje a la vez, el identificador del dispositivo será distinto.
Con todo esto el mensaje queda de la siguiente manera:
hash | identificador | marca_temporal | id_dato | dato
0x 00000000 00000000 00000000 00000000 00000000 | fca2538a | 00001234 | eeee
| abcd1234
Tras aplicar la función hash al mensaje anterior, se obtiene el siguiente mensaje en claro
completo:
0x cf314b61 5bca55b0 419980e1 e76f718e eab3a631 | fca2538a | 00001234 | eeee
| abcd1234
Los últimos dos campos, id_dato y dato, se pueden repetir tantas veces como datos se
quieran enviar. De esta manera reduciendo la cantidad de mensajes a enviar y por tanto
minimizando tiempos y consumo.
3.2.3.5. Consumos de energı́a
Dado que los consumos de energı́a son un factor importante en el diseño de este sis-
tema, se han estudiado las medidas que se implementan en los dispositivos para reducir
el consumo. Consultando el manual[18], algunos experimentos[28] llevados a cabo por la
comunidad y experimentos propios se han obtenido las siguientes conclusiones a cerca de
los modos de sueño.
Activo: Clock En este primer modo todos los periféricos, procesadores y memorias están
alimentados y pueden funcionar a máximo rendimiento. La CPU trabaja con los relojes
de alta frecuenciaen un rango de 26 240MHz.
Figura 3.17: Consumo en modo activo[28].
Modem Sleep: En este modo se desactiva la radio. La wifi y el bluetooth o se desactivan

o se limita su consumo. La CPU sigue operativa pero se reduce a un máximo de 80MHz.
La recuperación hasta el estado activo es inmediata.
28
Figura 3.18: Consumo en modo modem sleep[28].
Light Sleep: En el sueño ligero se desactivan todos los módulos de comunicación inalámbri-
ca3, además los relojes de alta frecuencia se deshabilitan y se pausa el procesador pudiendo
retomar el hilo de ejecución. Tanto el ULP como los periféricos RTC (Real Time Clock)
se mantienen operativos. Para despertar tarda menos de 1ms.
Figura 3.19: Consumo en modo sueño ligero[28].
Deep Sleep: Durante el sueño profundo solo queda activo el ULP y los periféricos RTC, el
hilo de ejecución se pierde, se mantienen 8x32 bits de información en registros de propósito
general. Para despertar tarda menos de 1 ms también.
29
Desarrollo
Figura 3.20: Consumo en modo sueño profundo[28].
Hibernación: Durante la hibernación la única parte que se mantiene alimentada es el

reloj RTC, ni siquiera los periféricos RTC reciben corriente. De este estado solo se puede
salir con un temporizador en el RTC, o con EXT1 que está configurado para que pueda
ser causa de reactivación en cualquier nivel de sueño.
Figura 3.21: Consumo en hibernación[28].
Estos son los diferentes modos de sueño y susu consumos energéticos correspondientes.
Sin embargo en las pruebas propias realizadas se observó un comportamiento que no se
corresponde con los datos recopilados. En las pruebas realizadas no se consiguió rebajar
el consumo por debajo de los 4mA en los ESP-DevKits. Y en el dispositivo integrado,
correspondiente al ESP-DHT11 el menor consumo fue de 18.2mA. Estas diferencias se de-
ben a fallos en la implementación de las placas de desarrollo. En el caso del ESP-DHT11
el problema pasa directamente por el hecho de que los sensores periféricos no reciben co-
rriente gestionada por el procesador. Esto hace que sea imposible apagarlos para eliminar
ese consumo mientras el procesador está en modo de sueño.
Sin embargo en el caso de los ESP-DevKits el problema de los sensores no está, con
lo cual ¿Dónde está el problema? En este caso el fallo de diseño está en el regulador de
tensión que alimenta el ESP32. Este regulador es un AMS1117-3.3, si atendemos a la
ficha técnica[29] podemos ver que el consumo de corriente quiescente es de 5mA. Es decir,
30
3.3. Puesta en funcionamiento del sistema
aunque el procesador esté en modo hibernación, consumiendo µAmperios, el consumo

mı́nimo del dispositivo entero será de 5mA.

Lo primero que hizo falta fue configurar la raspberry, instalar sistema operativo, servidor
mosquitto y definir credenciales.
Tras añadir las primeras credenciales quedaba ası́ el fichero de contraseñas de mosquitto:
Figura 3.22: Fichero de contraseñas de mosquitto.
Se definió una IP estática para la Raspberry:
Figura 3.23: IP estática de la Raspberry.
Y se inició el servidcio de mosquitto con el comando mosquitto.

Una vez arrancado el servidor mosquitto se procedió a arrancar los ESP32. En el pri-
mer arranque no tenı́an credenciales wifi guardadas en el NVM, por lo que pasaron a
configuración wps.
31
Desarrollo
1 I (540) WIFI: Attempting to read from NVS ...

2 I (540) WIFI: err: 4354
3 ...
4 I (750) WIFI: start wps...
5 I (750) WIFI: WIFI_EVENT_STA_START
6 I (850) MQTT_HANDLER: MQTT_EVENT_BEFORE_CONNECT
7 E (860) esp-tls: [sock=54] connect() error: Host is unreachable
8 E (860) transport_base: Failed to open a new connection: 32772
9 E (860) mqtt_client: Error transport connect
Como se ve en el volcado de la linea UART del ESP, primero prueba a leer de la NVM,
da fallo y arranca el WPS. Como son procesos ası́nconos, mientras se intenta conectar a
la red wifi, se inicializa la conexión al servidor MQTT. Dado como están implementadas
las librerı́as esto no es un problema, puesto que la conexión al servidor MQTT se intenta
periodicamente hasta que se consigue.
Cuando se activa la conexión WPS en el router el ESP32 detecta ese protocolo y lo usa
para conectarse a la red wifi.
1 I (18390) WIFI: WIFI_EVENT_STA_WPS_ER_SUCCESS

2 I (18390) WIFI: Connecting to SSID: IOT-Cryptolab, Passphrase: 1i0tCRTL2
3 I (18430) wifi:state: run -> init (0)
4 I (18430) wifi:new:<6,0>, old:<6,2>, ap:<255,255>, sta:<6,2>, prof:1
5 I (18440) WIFI: WIFI_EVENT_STA_DISCONNECTED
6 E (18440) wifi:sta is connecting, return error
7 I (18440) wifi:new:<6,2>, old:<6,0>, ap:<255,255>, sta:<6,2>, prof:1
8 I (19330) wifi:state: init -> auth (b0)
9 I (19340) wifi:state: auth -> assoc (0)
10 I (19340) wifi:state: assoc -> run (10)
11 I (19350) wifi:connected with IOT-Cryptolab, aid = 3, channel 6, 40D, bssid =
,→ a0:f3:c1:f4:33:c2
12 I (19350) wifi:security: WPA2-PSK, phy: bgn, rssi: -53
13 I (19360) wifi:pm start, type: 1
Si por orto lado las credenciales existen en la NVM, el ESP32 se conecta directamente
a la red wifi.
1 I (555) WIFI: Attempting to read from NVS ...

2 I (555) WIFI: err: 0
3 I (555) WIFI: Read SSID
4 I (555) WIFI: Read SSID: IOT-Cryptolab, Passphrase: 1i0tCRTL2
5 I (775) WIFI: Connecting with saved credentials
6 I (775) WIFI: Connecting to SSID: IOT-Cryptolab, Passphrase: 1i0tCRTL2
7 I (775) WIFI: WIFI_EVENT_STA_START
Una vez conectado a la red wifi, el ESP32 se puede conectar al servidor MQTT.
1 I (2542) esp_netif_handlers: sta ip: 192.168.0.101, mask: 255.255.255.0, gw:

,→ 192.168.0.1
2 I (2542) WIFI: got ip: 192.168.0.101
3 I (15842) MQTT_HANDLER: MQTT_EVENT_BEFORE_CONNECT
4 I (15852) MQTT_HANDLER: MQTT_EVENT_CONNECTED
5 I (15852) MQTT_HANDLER: sent subscribe successful, msg_id=22938
6 I (15862) MQTT_HANDLER: MQTT_EVENT_SUBSCRIBED, msg_id=22938
32
En este volcado se ve como segundos después de recibir IP de parte del router, el

ESP32 se conecta al servidor MQTT. Y en l a misma acción de recibir esa conexión con
el broker MQTT, se suscribe a los temas que le interesan. Para este ejemplo el tema será
/measurements/airdata/. En este tema estará el ESP-MS430 publicando los datos de los
sensores. Y el ESP-Act recibiendo datos y activando termostatos y humidificadores (en
este caso representados por LEDs).
Una vez inicializados los ESP32, se puede observar la comunicación entre ellos.
El ESP-MS430:
1 I (483041) MQTT_HANDLER: Read temp: 28.9ºC, hum: 47.0%, pres: 93110Pa

2 I (494035) MQTT_HANDLER: Data message constructed:
3
4 W (494035) HexPrint: 00000000 00000000 00000000 00000000 00000000 A0EE0100 00030000
,→ 00010000 003333E7 41020000 0000003C 42030000 00B66B01 00
5 I (494035) MQTT_HANDLER: SHA1:
6
7 W (494045) HexPrint: 5D38BFFC 6B7C07D6 6620B777 66665252 35B6FE1B A0EE0100 00030000
,→ 00010000 003333E7 41020000 0000003C 42030000 00B66B01 00
8 I (494055) MQTT_HANDLER: Published:
9
10 W (494065) HexPrint: 1B592211 5A2CCF59 7F47A554 6BECDB33 308F9AB8 8A8D2D62 28D8D725
,→ 82C9CE17 557E2A0D 8CF00D9F EC5A45D4 7F890FF2 04C33680 49B4A663 1C9D8CC1 FC2EA533
Y el ESP-Act recibiendo los datos:
1 I (351132) MQTT_HANDLER: MQTT_EVENT_DATA

2 TOPIC=/topic/measurements
3 LEN=64
4 I (351132) MQTT_HANDLER: Received
5 I (351132) MQTT_HANDLER: Encrypted data:
6 W (351132) HexPrint: 1B592211 5A2CCF59 7F47A554 6BECDB33 308F9AB8 8A8D2D62 28D8D725
,→ 82C9CE17 557E2A0D 8CF00D9F EC5A45D4 7F890FF2 04C33680 49B4A663 1C9D8CC1 FC2EA533
7 I (351152) MQTT_HANDLER: Decrypted data:
8 W (351152) HexPrint: 5D38BFFC 6B7C07D6 6620B777 66665252 35B6FE1B A0E40100 00030000
,→ 00010000 003333E7 41020000 0000003C 42030000 00B66B01 00000000 00000000 00000000
,→ 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
,→ 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
,→ 00000000 00000000 00
9 I (351212) MQTT_HANDLER: ID: A0, Timestamp: Thu Jan 1 00:08:04 1970, Fields: 3
10 I (351222) MQTT_HANDLER: Temperature: 28.9ºC
11 I (351234) MQTT_HANDLER: Humidity: 47.0%
12 I (351249) MQTT_HANDLER: Pressure: 93110Pa
En estos volcados se puede observar el mensaje en claro construido por el ESP-MS430

(ESP-MS430:linea7) y descifradoS por el ESP-Act (ESP-Act:linea8). 5D38BFFC 6B7C07D6
6620B777 66665252 35B6FE1B A0 EE0100 00 030000 00 0100 00 003333E7 41
020000 0000003C 42030000 00B66B01 00—
En este mensaje se observa, el hash , el ID del dispositivo , la marca temporal , el
número de datos en el mensaje , el código del dato , el dato . La parte sin colorear son
los datos dos y tres. Correspondientes en orden (1) a la temperatura, (2) a la humedad y
(3) a la presión.
Este es un ejemplo de comunicación cifrada de extremo a extremo. Siendo cada extremo
un ESP32. Gracias a esto aunque la raspberry fuese comprometida y un atacante consi-
33
Desarrollo
guiese recuperar los mensajes retransmitidos por la red, no podrı́a conocer el contenido de
estos mensajes.
34
4 Resultados y conclusiones
Como resultado principal de este trabajo tenemos el desarrollo del sistema de supervisión
y control de un entorno botánico. Como caracterı́stica principal y objetivo original de
este proyecto, el sistema cumple la propuesta de ser un sistema seguro. Implementando
seguridad tanto de prevención contra ataques por agentes externos, como de prevención
de errores no intencionados.
A lo largo de este trabajo se ha demostrado que no es tarea sencilla garantizar la seguri-
dad total en un sistema como el propuesto. Además de las dificultades propias que conlleva
el desarrollo de un sistema de estas caracterı́sticas, están las dificultades introducidas por
las implementaciones ofrecidas por los fabricantes de dispositivos.
En lo que respecta a las seguridad del sistema, no se ha conseguido la seguridad total,

puesto que siempre dependerá de los usuarios y administradores de sistema que hagan uso
de este sistema.
Además, un ataque por denegación de servicio tendrı́a que basarse únicamente en desha-
bilitar un dispositivo: la raspberry pi. En tal caso los ESPs del sistema seguirı́an trabajando
con la última configuración recibida.
Como posible continuación de este trabajo, se proponen varias lı́neas de trabajo:
Interfaz de usuario Ofrecer una interfaz web al usuario, para poder monitorizar de forma
más visualmente atractiva el sistema. También para poder configurar el sistema de forma
más sencilla.
Sistema de alertas Implementar un sistema de alertas que notifique al usuario de posibles

problemas en el sistema.
Configuraciones en caso de denegación de servicio Implementar un sistema de respaldo

que en caso de perder conexión con el broker revertir a una configuración que minimice
los daños.
Sistema de actualizaciones Implementar un sistema de actualizaciones que permita ac-

tualizar el sistema de forma remota.
35
5 Análisis de impacto
Este proyecto tiene un amplio alcance tanto en lo social como en lo medioambiental. En
el ámbito social introduce ejemplos y nuevas configuraciones para los sistemas de control
IOT, que mejoran la seguridad de los datos y entornos que estos sistemas controlan.
El diseño de este sistema permite que sea escalable, por lo que facilita tanto a los
pequeños negocios que no pueden permitirse un sistema de altı́sima calidad, y permite
crecer con este sistema en caso de que haga falta renovar y ampliar el negocio.
En lo que al medio ambiente se refiere, este proyecto tiene un impacto positivo, ya que
permite el control de un entorno botánico de forma remota, lo que permite reducir el
consumo de recursos energéticos, como la electricidad y el agua. Además abre la puerta
a la posibilidad de recopilar grandes cantidades de información valiosa sobre los entornos
tratados en el trabajo.
Por último alza la queja sobre la implementación de los microcontroladores, que sin
tener en cuenta todas las capacidades de sus partes obligan a malgastar energı́a a cambio
de ahorrar unos pocos euros en el precio de los dispositivos. Y lanza la propuesta a los
fabricantes para que mejoren estos diseños para poder hacer un uso más eficiente de todos
los componentes de sus dispositivos.
Por último resaltar algunos objetivos de la agenda 2030 de la ONU que este proyecto
podrı́a ser de ayuda a la hora de alcanzarlos:
Hambre cero, mejorando la producción de alimentos y consiguiendo un rendimiento

más eficiente de las cosechas.
Vida de ecosistemas terrestres, mejorando el control de los entornos botánicos.
Acción por el clima, haciendo un llamamiento a la eficiencia energética y optimizando

las técnicas de cultivo.
37
Bibliografı́a
[1] S. Parent. ((¿Cómo influye la humedad en la calidad de los cultivos?)) (), dirección:
https://www.pthorticulture.com/es/centro-de-formacion/como-influye-la
-humedad-en-la-calidad-de-los-cultivos/ (visitado 27-03-2023).
[2] C. Research. ((Influencia de la temperatura ambiental en las plantas.)) (), dirección:
https://www.canna.es/influencia_temperatura_ambiental_en_las_plantas
(visitado 27-03-2023).
[3] Nutricontrol. ((La humedad relativa en invernadero.)) (), dirección: https://nutric
ontrol.com/es/la-humedad-relativa-en-invernadero/ (visitado 27-03-2023).
[4] K. A. and. ((That ’Internet of Things’ Thing.)) (), dirección: https://www.rfidjou
rnal.com/that-internet-of-things-thing (visitado 10-04-2023).
[5] T. Seals. ((IoT Attacks Skyrocket, Doubling in 6 Months.)) (), dirección: https://t
hreatpost.com/iot-attacks-doubling/169224/ (visitado 14-04-2023).
[6] Kaspersky, ((Kaspersky Security Bulletin 2021. Statistics,)) Kaspersky, inf. téc., 2021.
[7] I. S. Foundation. ((IoT Security Foundation.)) (), dirección: https://iotsecurityf
oundation.org/ (visitado 14-04-2023).
[8] U. Congress, ((H.R.1668 - IoT Cybersecurity Improvement Act of 2020, 116th Con-
gress Public Law 207,)) From the U.S. Government Publishing Office, inf. téc., 2020-
04-12.
[9] I. I. C. S. W. Group, ((Interagency Report on the Status of International Cyberse-
curity Standardization for the Internet of Things (IoT),)) NIST, inf. téc., November
2018.
[10] R. P. Foundation. dirección: https://www.raspberrypi.com/products/raspberr
y-pi-3-model-b/ (visitado 12-04-2023).
[11] R. P. Foundation. ((Raspberry Pi Downloads.)) (), dirección: https://www.raspber
rypi.com/software/operating-systems/ (visitado 11-04-2023).
[12] E. Mosquitto. ((Eclipse Mosquitto.)) (), dirección: https://mosquitto.org/ (visita-
do 12-04-2023).
[13] E. Systems. ((ULP Coprocessor programming.)) (), dirección: https://docs.espre
ssif.com/projects/esp-idf/en/latest/esp32/api-reference/system/ulp.ht
ml (visitado 01-04-2023).
[14] P. Khatri. ((Arduino Sleep Modes and How to use them to Save the Power.)) (),
dirección: https://circuitdigest.com/microcontroller- projects/arduino-
sleep-modes-and-how-to-use-them-to-reduce-power-consumption (visitado
14-04-2023).
[15] D. Patel. ((How to Reduce Arduino Power Consumption.)) (), dirección: https://m
aker . pro / arduino / tutorial / how - to - reduce - arduino - power - consumption
(visitado 14-04-2023).
39
Bibliografı́a
[16] A. the Giant. ((Reducing Arduino Power Consumption.)) (), dirección: https://l
earn . sparkfun . com / tutorials / reducing - arduino - power - consumption / all
(visitado 14-04-2023).
[17] ATMEL, ATMEGA328P Datasheet (PDF) - ATMEL Corporation. dirección: https
://pdf1.alldatasheet.es/datasheet-pdf/view/1132281/ATMEL/ATMEGA328P.h
tml (visitado 14-04-2023).
[18] E. Systems, ESP32 Datasheet (PDF) - Espressif Systems. dirección: https://www.e
spressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf
(visitado 14-04-2023).
[19] L. M. Engineers. ((Insight Into ESP32 Sleep Modes & Their Power Consumption.))
(), dirección: https://lastminuteengineers.com/esp32-sleep-modes-power-c
onsumption (visitado 14-04-2023).
[20] J. Cook. ((ESP32 power consumption can be reduced with sleep modes.)) (), dirección:
https://www.arrow.com/en/research-and-events/articles/esp32-power-con
sumption-can-be-reduced-with-sleep-modes (visitado 14-04-2023).
[21] E. net. dirección: https://www.esp32.net (visitado 26-04-2023).
[22] E. Mosquitto. dirección: https://mosquitto.org/ (visitado 20-04-2023).
[23] E. Systems. dirección: https://www.espressif.com/ (visitado 20-04-2023).
[24] B. Sensortec, BME680 Low power gas, pressure, temperature and humidity sensor.
dirección: https://cdn-shop.adafruit.com/product-files/3660/BME680.pdf
(visitado 20-04-2023).
[25] Metriful, Indoor environment monitor with I2C compatible interface. dirección: ht
tps://raw.githubusercontent.com/metriful/sensor/master/Datasheet.pdf
(visitado 20-04-2023).
[26] B. Sensortec, BME280 Combined humidity and pressure sensor. dirección: https:
//www.mouser.com/datasheet/2/783/BST-BME280-DS002-1509607.pdf (visitado
20-04-2023).
[27] Lilygo. dirección: https://www.lilygo.cc/products/t-higrow (visitado 26-05-2023).
[28] L. M. Engineers. ((Insight Into ESP32 Sleep Modes and Their Power Consumption.))
(), dirección: https://lastminuteengineers.com/esp32-sleep-modes-power-c
onsumption/ (visitado 27-05-2023).
[29] A. M. Systems, 1A Low Dropout Volatage Regulator. dirección: http://www.advan
ced-monolithic.com/pdf/ds1117.pdf (visitado 27-05-2023).
40
Índice de figuras
2.1 Paı́ses con más ataques sufridos IOT en el primer semestre de 2021.[6] . . . 5
2.2 Malware instalado en el dispositivo después de un ataque.[6] . . . . . . . . . 6
3.1 Raspberry PI 3 [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Esquema de conexiones, SSH y nube MQTT . . . . . . . . . . . . . . . . . . 10
3.4 Comparativa de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 Diagrama de bloques de funciones[21] . . . . . . . . . . . . . . . . . . . . . 13
3.6 Modelo editor/subscriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Logo de Mosquitto[22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8 Logo de Espressif[23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.9 ESP-DHT11, citcuito integrado de LiliGo . . . . . . . . . . . . . . . . . . . 16
3.10 ESP-MS430[25] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.11 ESP-BME280 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.12 ESP32-DevKit, dispositivo encargado de la comunicación con los sensores. . 17
3.13 Raspberry Pi 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.14 Esquema de diseño del dispositivo ESP-DHT11[27]. . . . . . . . . . . . . . . 19
3.15 Diagramas de comunicación para las operaciones de escritura y lectura del
dispositivo ESP-BME280[26]. . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.16 Diagrama de flujo de la conexión WiFi . . . . . . . . . . . . . . . . . . . . . 23
3.17 Consumo en modo activo[28]. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.18 Consumo en modo modem sleep[28]. . . . . . . . . . . . . . . . . . . . . . . 29
3.19 Consumo en modo sueño ligero[28]. . . . . . . . . . . . . . . . . . . . . . . . 29
3.20 Consumo en modo sueño profundo[28]. . . . . . . . . . . . . . . . . . . . . . 30
3.21 Consumo en hibernación[28]. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.22 Fichero de contraseñas de mosquitto. . . . . . . . . . . . . . . . . . . . . . . 31
3.23 IP estática de la Raspberry. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
41
Este documento esta firmado por
Firmante CN=tfgm.fi.upm.es, OU=CCFI, O=ETS Ingenieros Informaticos -
UPM, C=ES
Fecha/Hora Wed Jun 28 14:08:14 CEST 2023
Emisor del EMAILADDRESS=camanager@etsiinf.upm.es, CN=CA ETS Ingenieros
Certificado Informaticos, O=ETS Ingenieros Informaticos - UPM, C=ES
Numero de Serie 561
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe
Signature)

TFG Manuel Lopez Ceron Corredor

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Manuel Lopez Ceron Corredor

Cargado por

Copyright:

Formatos disponibles

Universidad Politécnica

Grado en Grado en Ingenierı́a Informática

Trabajo Fin de Grado

Sistemas de Producción IoT Automáticos

Autor: Manuel López-Cerón Corredor

Madrid, 28 de junio de 2023

Trabajo Fin de Grado

Tı́tulo: Sistemas de Producción IoT Automáticos y Seguros

Autor: Manuel López-Cerón Corredor

The system is designed to be scalable, allowing the incorporation of new devices in a

2 Estado del arte 5

En primer lugar, un sistema de control IoT automático permite monitorizar y regular

Además, la automatización proporcionada por los sistemas IoT reduce la intervención

Otro aspecto especialmente motivador es la eficiencia en el uso de los recursos. Con-

agua en algunas zonas del planeta. Mediante la implementación de un sistema de con-

Además, el sistema de control IoT proporciona la capacidad de recopilar datos en tiem-

En resumen, la implementación de un sistema de control IoT automático en un entorno

El sistema debe ser seguro en lo que respecta a la comunicación, es decir, no debe

El sistema deberá ser escalable, permitiendo el control de un número de dispositivos

A excepción del controlador1 (o dispositivo maestro) habrá que valorar la autonomı́a

1.3. Profundización en los objetivos

1.3.1. Variables a controlar

1.3.2. Detalles de los sensores y actuadores

1. El broker : Este dispositivo será el encargado de controlar y gestionar, a modod de

3. Los suscriptores: Estos dispositivos serán suscribtores en los diferentes temas de la

Todo los detalles de estos tres dispositivos anteriormente se tratarán en profundidad

1.3.3. Detalles de la Comunicación

Esto se conseguirá mediante el uso de algoritmos de cifrado, identificadores únicos y sumas

1.3.4. Detalles de la operación de los dispositivos

2.2. Situación actual

Tipo de malware % de ataques

Figura 2.2: Malware instalado en el dispositivo después de un ataque.[6]

Otro aspecto a mencionar es el hardware sobre el que se implementan estos sistemas

3.1. Primeros pasos

El dispositivo encargado de gestionar la red, control de acceso, y en una posible expan-

La Raspberry PI 3, únicamente existirá un dispositivo de estos en el sistema. Este

Quad Core 1.2GHz Broadcom BCM2837 64bit CPU

Conectividad USB, ethernet, HDMI.

Capacidad de conexión inalámbrica WiFi y Bluetooth.

Puertos CSI y DSI para cámara y pantalla.

Figura 3.1: Raspberry PI 3 [10]

Aunque en este proyecto no se vaya a considerar el desarrollo de una interfaz gráfica, el

Figura 3.2: Esquema de conexiones, SSH y nube MQTT

Tal y como se ilustra en el diagrama, la gestión de este dispositivo se realizará a través

El segundo dispositivo a tener en cuenta del sistema será el ESP32, un microcontro-

(a) ESP8266 (b) ESP32

(c) Arduino Uno (d) Arduino Pro Mini

ESP8266 ESP32 Arduino Uno Arduino Pro Mini

Figura 3.4: Comparativa de dispositivos 5

Además de las especificaciones técnicas de cada dispositivo, se tuvo en cuenta el entorno

Figura 3.5: Diagrama de bloques de funciones[21]

3.1.2. Software base

Figura 3.6: Modelo editor/subscriptor

Como se ha especificado anteriormente dicha red se desplegará en una raspberry pi

las configuraciones de los clientes y proporcionar una interfaz de de comunicación para el

3.1.2.2. Espressif, firmware para los ESPs

3.2. Diseño del sistema

(a) Lilygo con tapa (b) Lilygo sin tapa

Figura 3.9: ESP-DHT11, citcuito integrado de LiliGo 22

3. Sensor de temperatura, humedad, presión y gases: BME680[24].

Sensor de intensidad lumı́nica: VEML6030.

Sensor de intensidad sonora: SPH0645LM4H-B.

Figura 3.10: ESP-MS430[25]