Gestión eficiente de una finca mediante el uso de una aplicación móvil y microcontroladores ESP32

GESTIÓN EFICIENTE DE UNA FINCA MEDIANTE EL USO DE UNA APLICACIÓN MÓVIL Y MICROCONTROLADORES ESP32 EFFICIENT FARM MANAGEMENT WITH ESP32 AND APP TRABAJO FIN DE GRADO CURSO 2022-2023 AUTORES ENRIQUE JUEZ DE MICELI FABRIZIO ALCARAZ ESCOBAR RARES PETRISOR CINCEA DIRECTOR JUAN CARLOS FABERO JIMÉNEZ GRADO EN INGENIERÍA DE COMPUTADORES FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID GESTIÓN EFICIENTE DE UNA FINCA MEDIANTE EL USO DE UNA APLICACIÓN MÓVIL Y MICROCONTROLADORES ESP32 EFFICIENT FARM MANAGEMENT WITH ESP32 AND APP TRABAJO DE FIN DE GRADO EN INGENIERÍA DE COMPUTADORES AUTORES ENRIQUE JUEZ DE MICELI FABRIZIO ALCARAZ ESCOBAR RARES PETRISOR CINCEA DIRECTOR JUAN CARLOS FABERO JIMÉNEZ CONVOCATORIA: JUNIO 2023 GRADO EN INGENIERÍA DE COMPUTADORES FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID 16 DE MAYO DE 2023 III AGRADECIMIENTOS A nuestras familias, amigos y parejas por el gran apoyo que nos han brindado durante el desarrollo de este proyecto. También queremos agradecer a nuestro tutor Juan Carlos Fabero por guiarnos en este arduo camino, ya que sin su ayuda esto no hubiera sido posible. También agradecer a Gustavo Eloy Alcaráz (tío de Fabrizio) por donarnos su Raspberry Pi, y por sus consejos de cómo afrontar el proyecto. Y no podemos olvidarnos de todos los profesores que nos han acompañado a lo largo de la carrera, descubriéndonos el maravilloso mundo de la Ingeniería de Computadores. Muchas gracias a todos. V RESUMEN Gestión eficiente de una finca mediante el uso de una aplicación móvil y microcontroladores ESP32 El objetivo de este TFG es facilitar la gestión de una finca mediante el uso de microcontroladores ESP32 que permitan identificar distintos parámetros dentro de un recinto, estos parámetros podrían ser: la temperatura, la humedad, concentración de humo/gas, nivel de agua en bebederos de animales, etc. Todos esos valores serán enviados a la aplicación móvil para que quien esté al cargo de la finca pueda llevar un mejor control de la misma, y no solo eso, sino que además podrá enviar con la misma aplicación peticiones para configurar los sensores que intervienen en todo este proceso. Para llevar a cabo este propósito se establece una red de comunicación bidireccional indirecta entre los ESP32 y la aplicación, ya que un broker actuará como intermediario entre ambos. Esta comunicación se lleva a cabo mediante el protocolo MQTT con el uso de tópicos previamente definidos, donde si se quiere enviar información se hará un “PUBLISH” en el tópico en cuestión, y al contrario si se desea recibir información deberemos suscribirnos a él. Palabras clave ESP32, Sensores, Broker, Raspberry, App, MQTT, WiFi, HTTP, NTP, Mosquitto. VII ABSTRACT Efficient farm management using a mobile app and ESP32 microcontrollers The objective of this Final Project is to facilitate the management of a farm through the use of ESP32 microcontrollers that allow the identification of different parameters within a farm enclosure, these parameters could be: temperature, humidity, smoke/gas concentration, water level in animal water troughs, etc. All these values will be sent to the mobile application so that whoever is in charge of the farm can have a better control of it, and not only that but also can send requests to configure the microcontrollers that participate in this process. To carry out this purpose, an indirect bidirectional communication is established between ESP32 and the mobile application, since a broker will act as an intermediary between both. This communication is carried out through the MQTT protocol with the use of previously defined topics, where if you want to send information you will make a "PUBLISH" in the wished topic, and on the opposite side if you want to receive information you will have to subscribe to it. Keywords ESP32, Sensors, Broker, Raspberry, App, MQTT, WIFI, HTTP, NTP, Mosquitto. VIII ÍNDICE DE CONTENIDOS Capítulo 1 - Introducción .........................................................................................................17 1.1 Motivación .......................................................................................................................17 1.1.1 Motivación personal ..................................................................................................17 1.1.2 Antecedentes ...........................................................................................................17 1.2 Objetivos .........................................................................................................................19 1.3 Plan de trabajo ................................................................................................................20 Capítulo 2 - Estado de la cuestión ...........................................................................................23 2.1 IoT ...................................................................................................................................23 2.1.1 ¿Cómo funciona IoT? ...............................................................................................23 2.1.2 Ventajas que ofrecen los sistemas de IoT ................................................................24 2.1.3 Ejemplos de sistemas IoT .........................................................................................24 2.2 ESP32 .............................................................................................................................25 2.2.1 Modelos ESP32 ........................................................................................................26 2.3 Conexiones .....................................................................................................................28 2.3.1 Bluetooth ..................................................................................................................28 2.3.2 WiFi ..........................................................................................................................29 2.3.3 Bluetooth frente a WiFi .............................................................................................30 2.4 MQTT ..............................................................................................................................31 2.4.1 Calidad de servicio (QoS) .........................................................................................32 Capítulo 3 - Elección ESP32 ...................................................................................................33 3.1 Compatibilidades .............................................................................................................34 Capítulo 4 - Elección de Periféricos .........................................................................................35 4.1 DHT22 ............................................................................................................................35 XV ÍNDICE DE TABLAS Tabla 6-1. Tabla de particiones de la memoria..........................................................................63 Tabla 9-1. Login nuevo usuario .................................................................................................84 Tabla 9-2. Login usuario existente ............................................................................................84 Tabla 9-3. Salir de la aplicación ................................................................................................84 Tabla 9-4. Eliminar dispositivo existente ...................................................................................85 Tabla 9-5. Refrescar información del dispositivo .......................................................................86 Tabla 9-6. Acceso a la vista de edición de dispositivo ...............................................................86 Tabla 9-7. Acceso a la vista de escaneo de dispositivos ...........................................................86 Tabla 9-8. Escaneo de dispositivos ...........................................................................................87 Tabla 9-9. Añadir un dispositivo ................................................................................................88 Tabla 9-10. Consultar información sobre un sensor ..................................................................89 Tabla 9-11. Editar alias del ESP32 ............................................................................................89 Tabla 9-12. Editar umbrales de alarma de un tipo de sensor ....................................................90 Tabla 9-13. Cambiar GPIO de un sensor ..................................................................................91 Tabla 9-14. Editar parámetros extra de un tipo de sensor .........................................................91 Tabla 10-1. Tabla de presupuesto........................................................................................... 105 17 Capítulo 1 - Introducción 1.1 Motivación 1.1.1 Motivación personal Con el avance de la tecnología en la actualidad y la llegada al mercado de innovadores productos de IoT se percibe una creciente necesidad de nuevos sistemas tecnológicos capaces de encargarse de la gestión de estos productos. La finalidad de estos sistemas no es más que la mejora en la calidad de vida diaria, tanto a nivel personal, como a nivel industrial o laboral. Nuestro trabajo “GESTIÓN EFICIENTE DE UNA FINCA MEDIANTE EL USO DE UNA APLICACIÓN MÓVIL Y MICROCONTROLADORES ESP32” o como nos gusta llamarlo cariñosamente “My ESPecial Finca” es un proyecto que encaja a la perfección con las tecnologías IoT. En nuestro caso, intentamos proporcionar a los granjeros los medios necesarios para ayudarles a realizar sus tareas en el campo, que de otra forma serían más difíciles y tediosas de realizar. 1.1.2 Antecedentes Antes de comenzar con el desarrollo de nuestro proyecto, se realizó un estudio para descubrir sistemas similares que nos sirvieran de referencia. Algunos de ellos fueron: • Totsom Ilustración 1-1. Pantalla de inicio de Totsom 18 Totsom es una empresa que se dedica a la automatización industrial y al desarrollo de productos electrónicos. Uno de los ámbitos en los que trabajan es en el sector agrícola, ofreciendo la posibilidad de automatizar procesos como la medición de datos (temperatura, niveles de agua, de silos, etc.) Tienen dispositivos capaces de gestionar la información del recinto donde haya sido instalado este sistema de manera remota, también toman decisiones de manera autónoma en función de los valores obtenidos. Por último, ofrecen un sistema de análisis en tiempo real para una mayor eficiencia y productividad. • Spherag Ilustración 1-2. Pantalla de inicio de Spherag Spherag es una empresa que ofrece servicios IoT combinados con servicios en la nube que permiten crear un ecosistema cloud que simplifica la necesidad de migrar digitalmente los datos. Hacen uso de dispositivos IoT ATLAS que son dispositivos solares basados en la tecnología LTE-M que vincula los datos de los sensores propios y de terceros, ofreciendo la posibilidad de automatizar acciones. Los dispositivos ATLAS no necesitan un despliegue previo ni acceso a la red eléctrica, son tecnologías Plug & Play, haciéndolos autónomos y autosuficientes. Basta con conectarlos a los elementos que quieras gestionar para empezar a recibir datos y mandar órdenes en tiempo real. 19 • HW Group Ilustración 1-3. Dispositivo Poseidon2 4002 Es una empresa que se encarga de la fabricación de equipos RME (Sistemas de monitorización Eco-System). De esta empresa nos interesa mencionar el dispositivo Poseidon2 4002 que está diseñado para monitorizar, controlar sensores, entradas y salidas digitales a través de la red mediante protocolos M2M seguros, como HTTP o IPv6. Y gracias al protocolo de comunicaciones MQTT posibilita la integración de este dispositivo en sistemas IoT. Utilizando el portal SensDesk de HW Group se puede configurar y monitorizar de forma remota gracias a un servidor web incorporado en el propio dispositivo. 1.2 Objetivos El objetivo de este proyecto de fin de grado es crear un sistema IoT capaz de gestionar de manera eficiente una finca mediante el uso de microcontroladores ESP32 que tendrán conectados un conjunto de sensores capaces de medir las variables del entorno. Se llevará a cabo en las siguientes fases: • Desplegar microcontroladores ESP32 capaces de gestionar información relativa a esas variables del entorno dentro de una finca. • Establecer unos canales de comunicación para permitir la transmisión de datos entre la aplicación móvil y los microcontroladores por medio de un broker. • Programar una Raspberry para que actúe como un broker privado. • Crear una aplicación móvil capaz de mostrar datos por pantalla, así como mandar peticiones al ESP. 20 • Establecer un servidor web para poder configurar todos los parámetros relevantes de nuestro sistema. 1.3 Plan de trabajo Una vez definidos los objetivos necesarios para que nuestro sistema de gestión funcione correctamente, el siguiente paso consistirá en decidir el orden en el que se realizará el desarrollo de cada una de las partes que componen el sistema final. Para de esta manera, llevar a cabo una distribución de las tareas en el tiempo y así poder hacer una estimación de la duración total del proyecto como de la duración prevista para el desarrollo de cada una de las partes. Pero primero se tendrá que realizar un desglose de esos objetivos y marcar las tareas necesarias que se deberán llevar a cabo: 1. Investigación preliminar a. Familiarizarse con los microcontroladores ESP32 y la capacidad que tienen para la medición de variables ambientales. b. Llevar a cabo un aprendizaje sobre el protocolo MQTT y la forma en la que funciona un broker de comunicación entre dispositivos. c. Indagar en las distintas herramientas que existen para el desarrollo de una aplicación móvil y una aplicación web. 2. Diseño del sistema a. Definir qué variables se quieren medir en la finca y de qué manera se llevará a cabo su medición. b. Diseñar el esquema de la red de microcontroladores ESP32, y como se comunicarán con el broker. c. Diseñar la arquitectura de las aplicaciones móviles y web, así como la interfaz de usuario. 3. Desarrollo del software de los microcontroladores ESP32 a. Programar drivers de los sensores para que midan las variables ambientales deseadas. b. Programar ficheros encargados de manejar la incorporación y eliminación de sensores, así como recolectar o modificar la información relativa a ellos. c. Programar ficheros capaces de gestionar todas las tareas relativas a las conexiones WIFI, HTTP, NTP y MQTT. 4. Configuración de Raspberry para que funcione como broker MQTT a. Instalar software necesario para hacer que Raspberry funcione como broker. 21 b. Configurar el broker MQTT para que se comunique con los microcontroladores ESP32. 5. Desarrollo de la aplicación móvil a. Programar aplicación móvil para que sea capaz de comunicarse con el broker MQTT y así recibir datos de los microcontroladores ESP32. b. Diseñar la interfaz gráfica de la aplicación móvil. c. Implementar sistema de autenticación para comunicación MQTT. d. Implementar sistema de alarmas de los sensores. 6. Desarrollo de la aplicación web a. Diseñar la interfaz gráfica de la aplicación web. b. Programar un fichero JavaScript que permita a la aplicación web conectarse con el microcontrolador ESP32 y comunicarse con él mediante peticiones XML. c. Generar las herramientas necesarias para poder configurar las conexiones WIFI, NTP y MQTT. d. Hacer el despliegue de información relativa a los sensores conectados al microcontrolador. e. Permitir a la aplicación web añadir o eliminar sensores, así como poder configurar todos sus parámetros de manera dinámica. f. Embellecer la interfaz mediante CSS. 7. Pruebas y arreglos a. Realizar pruebas del sistema para comprobar que todos los componentes funcionen correctamente. b. Llevar a cabo los ajustes y correcciones pertinentes en el software y la configuración de nuestro sistema. 8. Documentación a. Documentar el proceso de desarrollo. b. Preparar una presentación del proyecto para su defensa, incluyendo una demostración de su funcionamiento. Una vez fijados los objetivos se estableció un plan de trabajo para poder llevarlos a cabo en el tiempo establecido. Para ello, se realizó un Diagrama de Gantt fijando la cantidad de tiempo necesaria para cada una de las actividades en lo que se refiere a la dificultad y la prioridad que se le ha otorgado a cada una de ellas: 22 Figura 1-1. Diagrama de Gantt 1 1 Figura realizada con el programa teamGantt 23 Capítulo 2 - Estado de la cuestión Para este proyecto se hará uso de varios microcontroladores que sean capaces de leer señales analógicas provenientes de los distintos tipos de sensores para poder medir valores como la temperatura ambiental, humedad relativa del aire, presencia de gas/humo, humedad relativa de la tierra (como por ejemplo de una maceta) y el nivel de agua (de un recipiente, bebedero, etc.). La información recogida de cada sensor se visualizará en una pantalla LCD y, mediante una conexión inalámbrica, se retransmitirá a una “unidad central” que agrupará a todos los microcontroladores para, finalmente, transmitir la información a los usuarios que se conecten. De este modo, los usuarios no tendrían que conectarse a cada microcontrolador del que quieran recibir la información de sus sensores. Antes de entrar en detalles sobre nuestro proyecto, se mostrará información relevante de temas relacionados con él. 2.1 IoT El término IoT (Internet of Things), o Internet de las cosas en español, hace referencia a las nuevas tecnologías que facilitan la comunicación entre los dispositivos y la nube. Con la mejora en las prestaciones de los chips, el aumento del ancho de banda en los canales de comunicación, así como, la facilidad de acceder a estas nuevas tecnologías gracias a su reducido precio, ha provocado que actualmente existan miles de millones de dispositivos conectados a Internet concurrentemente. En los últimos 30 años, dentro del ámbito de la ingeniería se ha estado integrando sensores y procesadores a los objetos cotidianos, donde los módulos que contienen estos componentes son cada vez más pequeños, rápidos y su capacidad de procesamiento es cada vez mayor. Gracias a esto se ven cada vez más presentes los dispositivos IoT en lugares del día a día como puedan ser nuestra casa o lugar de trabajo. 2.1.1 ¿Cómo funciona IoT? Los sistemas IoT, entre otras cosas, pueden recopilar datos para poder informar o autorizar acciones. Se lleva a cabo en 4 etapas: 24 Figura 2-1. 4 etapas del IoT 1. Capturar la información: Los dispositivos IoT capturan información de su entorno mediante el uso de sensores. 2. Compartir información: Esta información se puede transmitir a otros sistemas informáticos tales como un sistema en la nube u otro dispositivo. Esta etapa no es estrictamente necesaria, puesto que también el sistema que obtiene estos datos puede conservarlos para realizar ciertas acciones de manera automática. 3. Procesamiento de la información: El sistema procesa los datos obtenidos y actúa en consecuencia. 4. Respuesta a la información obtenida: El usuario analiza la información obtenida de los dispositivos que se comunican con él. Basándonos en esta información, el usuario tomará las decisiones pertinentes. 2.1.2 Ventajas que ofrecen los sistemas de IoT Los sistemas IoT nos proporcionan una gran cantidad de ventajas, entre las cuales se incluyen la automatización de tareas y la monitorización de la información en tiempo real. Gracias a la automatización se aumenta la eficiencia al realizar tareas y se reducen los posibles errores humanos que se puedan cometer, mientras que la monitorización de la información nos ayuda en diversos ámbitos, como podrían ser la eficiencia energética y la seguridad. En resumen, los sistemas IoT mejoran la calidad de vida de las personas y nos ayudan a tomar decisiones de manera informada. 2.1.3 Ejemplos de sistemas IoT En la actualidad los sistemas IoT se pueden encontrar en muchos sitios. Algunos muy comunes son: 31 2.4 MQTT Una vez definido que se utilizará WiFi para las conexiones entre los dispositivos y el usuario, queda pendiente cómo se llevaría a cabo el intercambio de mensajes, dado que la idea inicial era algo similar a un MAESTRO/ESCLAVO entre los microcontroladores y la “unidad central” para poder agrupar el envío de datos desde la “unidad central” al usuario, nuestro tutor nos recomendó el protocolo MQTT, el cual se ajusta a la perfección a la idea del proyecto. “Message Queue Telemetry Transport” (MQTT) es un protocolo de transmisión de mensajes basado en publicaciones/suscripciones creado por IBM en 1999 con la intención de ser ligero, bidireccional y eficiente. En MQTT se hace distinción entre 3 roles: • Publisher (Publicador): es el que envía la información a través de los temas o tópicos, los cuales son cadenas de texto jerarquizadas a través de “/” utilizadas para categorizar los mensajes publicados, facilitando así una organización lógica de los mensajes, como por ejemplo “Casa/Habitación2/Temperatura” • Subscriber (Suscriptor): es el que recibe la información publicada a través del tópico al que está suscrito. • Broker: es el servidor encargado de intermediar entre los publicadores y los suscriptores, pues es el que recibe todas las publicaciones y las retransmite a los suscriptores del tópico al que fue publicado. Su funcionamiento es relativamente sencillo, pues es comparable al de un quiosco (broker) al que los clientes (suscriptores) acuden para comprar revistas o periódicos (mensajes) vendidas por las distintas editoriales (publicadores). Cabe destacar que los roles no son excluyentes, pues un suscriptor puede ser a la vez un publicador, lo cual es una situación común, ya que, por ejemplo, un usuario podría ser suscriptor de un dispositivo y publicador del mismo para poder configurarlo o enviar comandos. Gracias a este funcionamiento, la escalabilidad es mucho más alta, pues tanto los suscriptores y los publicadores solo están conectados al broker, independientemente de cuantos más dispositivos haya en la red, provocando que haya una comunicación 1 a N. 32 2.4.1 Calidad de servicio (QoS) En MQTT se diferencian 3 tipos de calidad de servicio para la entrega de mensajes 9 : • QoS 0: llamado también “fire and forget”, es el nivel más bajo de servicio, ya que el mensaje se envía una sola vez sin la garantía de que se haya entregado al destinatario. • QoS 1: se garantiza que el receptor reciba, al menos, una vez el mensaje aunque puede recibir duplicados, puesto que si el remitente no ha recibido un mensaje de confirmación de que el mensaje ha llegado en un tiempo razonable, reenvía el mensaje hasta que lo reciba. • QoS 2: nivel máximo de servicio, en el que se garantiza que el mensaje es recibido exactamente una vez a cada receptor a través de un mecanismo de “four-part handshake” desechando los duplicados. 9 HiveMQ - MQTT Essentials 33 Capítulo 3 - Elección ESP32 Una vez visto todos los modelos posibles que ofrecen la familia de los ESP32, se ha de elegir el que se usará en este proyecto. Dado que difícilmente se podrá instalar los modelos basados en formatos SoC y SiP sin las herramientas necesarias, se optará mejor por los modulos PCB o las placas de desarrollo. En este caso se eligieron los modelos basados en placas de desarrollo por la facilidad que hay en usarlas. Con esto se conseguirá que no se tengan demasiados problemas durante su instalación, además de permitirnos modificarlo fácilmente en un futuro si fuese necesario. En cuanto a la serie, no es necesario que sea un tipo especializado en nada. Es por ello que se usará los modelos de la serie base, que son las que se adaptan mejor a nuestras necesidades. Dentro de todos los modelos posibles de esta serie se ha utilizado fundamentalmente el ESP32-WROVER-B modificado por la compañía Freenove. Dicha modificación consta de una placa de expansión conectada a una placa de prototipado. La siguiente imagen muestra los componentes mencionados: Ilustración 3-1. Kit ESP32 Freenove 10 10 Foto extraída de la documentación de Freenove 34 3.1 Compatibilidades No se han podido realizar pruebas en diversos ESP32 de distintas series, pero la compatibilidad debería ser bastante alta por lo general. Algunos aspectos clave para saber que sí es compatible son: • La ejecución de tareas se ha dividido de tal forma que se reparta la carga de trabajo en los dos núcleos del microprocesador, con ello se evita que el programa se bloquee en exceso y se mejora su rendimiento. Por lo tanto, se necesitaría que el ESP escogido no sea de un solo núcleo. • Se guardan algunas variables en la memoria flash integrada del ESP. Son las que están relacionadas con la configuración de las conexiones WiFi y MQTT, así como los sensores y sus parámetros relevantes. Se hace esto para evitar tener que reconfigurar todo a mano cada vez que se inicia el programa. Por ello habría que asegurarse que el ESP disponga de tal memoria. • Cada ESP32 dispone de una cantidad diferente de GPIOS, además también varía la numeración y el tipo de GPIO que es. Por ejemplo, el que principalmente se usa (ESP32-WROVER-B de “Freenove”) tiene 30 GPIOS de los cuales 4 de ellos son solo de entrada. Aquí es donde es más fácil que haya incompatibilidades entre ESP32, pero es fácilmente configurable a través del fichero creado para manejar los GPIOS del ESP. 35 Capítulo 4 - Elección de Periféricos Los periféricos son fundamentales para el correcto funcionamiento de nuestro proyecto, ya que serán los encargados de realizar todas las tareas relacionadas con las variables del entorno, tanto su percepción (DHT22, HC-SR04…) como su representación (LCD). Los periféricos se dividen en dos partes: • Hardware: es la parte física del sensor, estará en contacto con el medio en cuestión. Cada sensor estará compuesto de los materiales necesarios que le permitan percibir las señales. Se comunica con el microcontrolador a través de sus pines de entrada/salida. • Software: es la parte lógica del sensor, es decir, la parte responsable de que el periférico actúe convenientemente. Todo ello estará contenido en un único fichero denominado driver. Hay muchos sensores diferentes que podrían encajar en nuestro proyecto, a su vez cada sensor puede tener modelos distintos desarrollados por diversas compañías. En nuestro caso se ha decidido utilizar los siguientes cuatro: 4.1 DHT22 Sensor encargado de medir la temperatura y la humedad que haya en la localización que se encuentre, preferiblemente una sala cerrada para evitar lecturas irregulares. 4.1.1 Hardware Figura 4-1. DHT22 36 1. VCC: pin conectado al voltaje del circuito. Aunque acepte del rango de 3 a 5 V lo más recomendado son 5 V. 2. Data: pin con el cual se comunicará con el ESP (Pin de Entrada/Salida). 3. NC: pin que no se usa para nada, este pin deberá estar desconectado del circuito para evitar problemas. 4. GND: pin conectado a tierra. Las variables que mide son: • Humedad: se mide gracias a dos electrodos separados por un sustrato que la retienen, cuanto mayor es la concentración, el sustrato ejerce menos resistencia y permite un mayor flujo de iones, permitiendo calcular la humedad relativa en el ambiente. • Temperatura: se mide gracias a un termistor que tiene internamente. 4.1.2 Software Pasos: 1) El ESP32 pone el GPIO “Data” en modo output. Pone su señal a ‘0’ durante 3 ms y posteriormente lo pone ‘1’ brevemente. 2) El sensor detecta este cambio de señal y entiende una señal “Start”, por lo que empieza a medir la humedad y la temperatura. A todo esto, el ESP pone el GPIO “Data” en modo input para comenzar la lectura. 3) Tras una breve pausa que realizan ambos dispositivos, el sensor comienza a mandar bit a bit el resultado de la lectura hasta mandar un total de 40 bits: a) 0 - 15: los primeros 16 bits son el resultado al porcentaje de humedad en el ambiente, los 8 primeros son la parte entera y los 8 últimos la parte decimal. b) 15 - 31: los siguientes 16 son el resultado de la temperatura, los 8 primeros la parte entera y los otros 8 la parte decimal. c) 32 - 40: Finalmente, el sensor manda un “CheckSum” en los 8 últimos bits para comprobar que la lectura de los anteriores 32 se haya realizado correctamente. 37 4.2 HC-SR04 Sensor que se encarga de medir distancias a través de ondas que dispara frontalmente y que recibe cuando rebotan en alguna superficie. 4.2.1 Hardware Figura 4-2. HC-SR04 1. VCC: pin que va conectado al voltaje del circuito. 2. Trig: pin a través del cual se le indica al sensor que comience a mandar ondas (Pin de entrada). 3. Echo: pin con el que se indica la llegada de las ondas previamente mandadas (Pin de salida). 4. GND: pin conectado a tierra. La variable que mide es: • Distancia: se mide a través del tiempo que tarda el sensor desde que comienza a mandar ondas hasta que las recibe de vuelta. 4.2.2 Software Pasos: 1) El ESP comienza poniendo una señal ‘0’ en el “Trig” pin, tras un par de microsegundos cambia la señal a ‘1’ y de vuelta lo vuelve a poner a ‘0’. 2) El ESP espera a que el sensor ponga su “Echo” pin a ‘1’. Una vez detectado el cambio espera a que este se ponga a ‘0’ indicando que el sensor ya ha recibido las ondas de vuelta. En su defecto, si el sensor no lo indica durante un periodo largo de tiempo, el ESP dará por hecho que ha fallado y se descarta todo el proceso hasta el momento. 38 3) En caso de que todo salga bien, se realiza un cálculo matemático en relación con el tiempo que ha pasado desde el cambio de señal en el GPIO “Echo”. 4) Finalmente, en nuestro proyecto se utilizará para saber cómo de lleno está un recipiente de agua (porcentualmente). La fórmula sería: res = 100 - ((distSens - distAlSens) / distReci) * 100 • res: resultado, como de lleno está el recipiente de manera porcentual. • distSens: distancia resultante calculada a través del sensor. • distAlSens: distancia que hay desde el sensor a la parte superior del recipiente. • distReci: distancia que hay desde la parte superior del recipiente hasta su parte inferior. 4.3 MQ2 Sensor que detecta la presencia de humo y diversos gases en el aire. No indica el porcentaje como tal, ya que solo actúa como una resistencia que varía en función de la concentración de partículas de dichos compuestos. 4.3.1 Hardware Figura 4-3. MQ2 39 1. VCC: pin que va conectado al voltaje del circuito. 2. GND: pin conectado a tierra. 3. D0: pin que indica con una señal digital la aparición de humo o diversos gases. El propio sensor contiene un comparador que comprueba la cantidad de corriente que está dejando fluir y con ello selecciona cuál es la señal a mandar (ese comparador puede ser ajustado a través de una rosca para indicar el umbral) (Pin de salida). 4. A0: pin que transmite una señal analógica, este será el que se utilice en el ESP32. Esa señal analógica es equivalente a la corriente que deja fluir. Según el voltaje que nos llegue por su GPIO se podrá hacer una estimación porcentual de humo o gases (Pin de salida). La variable que mide es: • Concentración humo/gas: esto le es posible gracias a una capa de dióxido de estaño que se encuentra en su interior. Cuando el aire se encuentra limpio de cualquier gas reductor, los átomos de oxígeno se quedan atraídos a la superficie de la capa, al quedarse en dicha superficie los electrones que se encuentran en la propia capa quedan atraídos también a causa de los átomos de oxígeno, formando así una barrera altamente resistiva e impidiendo que la corriente fluya. Con la aparición de los gases reductores, los átomos de oxígeno son arrastrados fuera de la superficie, liberando así los electrones de la capa de dióxido de estaño y permitiendo de esta forma que fluya la corriente de nuevo. A continuación, se muestra una tabla que especifica lo que puede detectar y cómo actúa el sensor en función de las cantidades “ppm”: 40 Figura 4-4. Gráfica ppm • H2: molécula de dihidrógeno. • LPG: gas licuado de petróleo. • CH4: metano. • CO: monóxido de carbono. • Alcohol: compuestos que contienen una molécula de hidroxilo (OH) en sustitución de un átomo de hidrógeno. • Smoke: humo procedente de la combustión por fuego. • Propane: gas propano. • Air: compuesto de aire sin alterar. 47 Capítulo 5 - Estructura MQTT 5.1 Posibles diagramas de conexiones Tras la elección de MQTT como protocolo de envío de mensajes entre los dispositivos del sistema, se han analizado las posibles conexiones que se podrían llevar a cabo en el TFG: Figura 5-1. Diagrama de conexiones 1 Sería el más típico, pues se podría utilizar una red interna sin conexión a internet para comunicar los microcontroladores con el broker, estando este último conectado tanto a esa red interna como, por ejemplo, a la red de la casa o finca, ya que con este modo se podría tener acceso al broker desde internet. 48 Figura 5-2. Diagrama de conexiones 2 Es un caso muy parecido al primero, con la diferencia de que se podrían conectar al broker microcontroladores que estén fuera de la red interna. Un ejemplo real sería una casa grande en la que la mayoría de los microcontroladores se encuentren en la red interna, pero haya algunos a los que la señal no alcance, pero sí lo haga el de la red de la casa (por ejemplo, por repetidores) u otra red con acceso a internet que permitan esa conexión con el broker. Este diagrama de conexión es el que se ha utilizado a lo largo de la realización del proyecto. 49 Figura 5-3. Diagrama de conexiones 3 A través de este diagrama se estaría explotando la capacidad de “bridging” entre brokers, por el cual es posible que varios brokers se comuniquen entre sí intercambiándose los mensajes, provocando que un dispositivo que publique estando en la Red 1 sea retransmitido a algún suscriptor de la Red 2, por ejemplo. Un caso real sería el de tener microcontroladores en una casa y otros en la segunda residencia y/o finca en donde haya un broker en cada red y, estos a su vez hagan “bridging” a un servidor en la nube (que no deja de ser otro broker, pero sin microcontroladores conectados) desde el cual el usuario podrá recibir la información de todos los microcontroladores. 50 5.2 Estructura de los tópicos Con el fin de organizar el envío de los mensajes, se ha diseñado la siguiente estructura de los temas de MQTT que se utilizan en el proyecto: Figura 5-4. Diagrama de tópicos NOTA: Los temas en cuadros amarillos son ejemplos, mientras que los rojos están presentes siempre. Se decidió que la raíz de los tópicos sea MESPF, ya que de esta forma se podrían utilizar otros proyectos de MQTT dentro del mismo broker sin que haya colisiones en los tópicos. De MESPF salen dos ramas: SENS (en donde se ubicarán las informaciones de los microcontroladores) y USR (en donde cada usuario tendría su espacio personal para que los microcontroladores publiquen el resultado de alguna petición realizada por él). 51 5.2.1 Rama SENS En esta rama de los tópicos se encuentra la información de los sensores que publican los microcontroladores, correspondiéndole el primer nivel de esta rama a cada microcontrolador conectado al sistema, por ejemplo, el microcontrolador ESP32_X publicará toda su información en los subniveles a MESPF/SENS/ESP32_X… Cabe destacar que el tema SCAN ubicado en el mismo nivel que los microcontroladores no se corresponde a ningún microcontrolador en particular, sino que se trata de un “comando” general al que los usuarios publicarán su nombre para que todos los microcontroladores activos en el sistema respondan con su nombre al correspondiente. Por ejemplo, el usuario FABRIALC publica en MESPF/SENS/SCAN el siguiente mensaje: “FABRIALC”, con ello los suscriptores de ese tópico (los cuales serán los microcontroladores) que reciban el mensaje publicarán en el tópico MESPF/USR/FABRIALC/SCAN su nombre o identificador para, de esta forma el usuario FABRIALC sepa qué microcontroladores se encuentran activos. El segundo nivel de esta rama (siendo el 3.º desde la raíz) se corresponde con los distintos tipos de sensores conectados a cada microcontrolador, como por ejemplo el DHT22 o el MQ2, los cuales publicarían su información en los subniveles de MESPF/SENS/ESP32_X/DHT22/… o MESPF/SENS/ESP32_X/MQ2/… respectivamente. Como la instalación de los sensores es dinámico (es decir, no todos los microcontroladores tendrán un MQ2 o un DHT22 instalado) estos temas son opcionales, a excepción de STATUS, el cual es un tema especial en el que se informa de datos genéricos (dirección IP, hora local, etc.) del microcontrolador. El tercer nivel se corresponde a las unidades de cada tipo de sensor, por ejemplo, si un microcontrolador tiene instalado 2 MQ2s, publicaría la información de cada uno en los siguientes tópicos: MESPF/SENS/ESP32_X/MQ2/1/… y MESPF/SENS/ESP32_X/MQ2/2/… El cuarto nivel se refiere a los dos temas en los que los microcontroladores publican información: • ALERT: donde se informa de la alerta de algún valor anormal. • INFO: en donde los microcontroladores publican periódicamente los datos de sus sensores (por defecto, cada 5 minutos). 52 Por último, en el quinto nivel se hallan los 3 comandos soportados actualmente, los cuales son: • REFRESH: Sirve para que el microcontrolador publique toda la información de todos sus sensores en el sub tópico del usuario que lo solicita para que, de esta forma, en caso de que algún usuario pida un refresco de los datos, los microcontroladores solo envíen la información al usuario solicitante evitando así tener que volverlo a enviar a todos los suscriptores de INFO. • GETCONF: Su finalidad es la de informar al usuario que lo solicita de la configuración de GPIOS y de alarma de cada sensor instalado. • SET: El cual es lo contrario a GETCONF, pues a través de este comando los usuarios pueden configurar los sensores ya instalados de cada microcontrolador. 5.2.2 Rama USR En esta rama se encuentran las respuestas a las distintas peticiones lanzadas a los microcontroladores por parte de los usuarios, facilitando así el resultado de estas. En el primer nivel se identifican todos los usuarios que hayan realizado alguna petición. En el segundo nivel se encuentran las respuestas a las peticiones realizadas: • RESP: Actualmente, es utilizado para recibir el resultado de los comandos SET y GETCONF. • REFRESH: Es análogo a la rama SENS, pues aquí se reciben los datos de los microcontroladores a los que se les ha solicitado el comando REFRESH. • SCAN: Tema en el que los microcontroladores responderán con su identificador cada vez que el usuario lo solicite a través de MESPF/SENS/SCAN. 5.3 QoS seleccionado Para el proyecto se hará uso del QoS 0, pues es el más rápido, la información de los mensajes no es crítica (ya que son datos de sensores que se vuelven a enviar cada cierto tiempo y se puede hacer un REFRESH en caso de necesitarlo) y, al momento del desarrollo del TFG, el QoS 2 aún no está disponible en el ESP32. 53 5.4 Usuarios de MQTT En MQTT es posible que las conexiones al broker sean autenticadas con el uso de usuarios, los cuales pueden tener definidos una serie de permisos para publicar/suscribirse a ciertos tópicos añadiendo así un poco de seguridad, pues no se permite la conexión a usuarios sin autenticarse. Para este proyecto se han definido 3 tipos de usuarios con los siguientes permisos: 1. MESPF_ADMIN: es el “superusuario” que se utiliza para supervisar el sistema a modo de “debug”, pues tiene permisos de publicación y suscripción a todos los tópicos. 2. MESPF_SENSOR: el que utilizan los microcontroladores que publican la información de los sensores, puede publicar en los siguientes tópicos: a. MESPF/SENS/+/+/+/INFO b. MESPF/SENS/+/+/+/ALERT c. MESPF/USR/+/RESP d. MESPF/USR/+/REFRESH/+/+/+/INFO e. MESPF/USR/+/SCAN Mientras que solo puede suscribirse a los siguientes: a. MESPF/SENS/SCAN b. MESPF/SENS/+/+/+/CMD/+ 3. MESPF_USER: utilizado para los usuarios de la aplicación móvil, sus permisos son los contrarios que el de MESPF_SENSOR, es decir, solo puede suscribirse a los temas que MESPF_SENSOR pública y viceversa. NOTA: Los niveles con “+” indican que es una “Wild Card” o comodín, por el cual se hace referencia a todos los temas del nivel que se encuentre “+”. Por ejemplo, utilizando de referencia la estructura de tópicos del TFG, MESPF/SENS/ESP32_X/STATUS/1/CMD/+ hace referencia a MESPF/…/CMD/REFRESH, MESPF/…/CMD/GETCONF y MESPF/…/CMD/SET. 54 5.5 Broker Como se ha explicado anteriormente, para poder llevar a cabo la retransmisión de mensajes en MQTT es necesario la presencia de un broker que intermedie entre los publicadores y los suscriptores, convirtiendo al broker en la unidad más importante. Al principio del desarrollo del proyecto se tenía planeado utilizar un ESP32 como broker, pues se buscaba que todos los componentes del sistema sean lo más pequeño posible, pero, tras una búsqueda de posibles brokers ya desarrollados para el ESP32 no se encontró ninguno convincente, pues uno de los problemas de conexión en el ESP32 es que por defecto solo admite 16 conexiones simultáneas, mermando así su rendimiento y la escalabilidad del proyecto. Por ello, y a modo de “testeo”, se utilizaron brokers públicos como el de Eclipse Projects 11 (mantenido por la comunidad) o el de HIVEMQ 12 aunque no por mucho tiempo, ya que posteriormente y gracias a MOSQUITTO 13 , se pudo utilizar un ordenador portátil como broker para así no depender de terceros y, a su vez se pudo configurar a las necesidades del proyecto (creación de usuarios con permisos, longitud de mensajes, logs de mensajes, etc.). Aunque el ordenador portátil como broker funcionaba bien, no era viable mantenerlo encendido 24 horas y su tamaño choca con la filosofía de “componentes pequeños”, hasta que se nos fue donado una RASPBERRY PI 2 MODEL B (el cual es un ordenador monoplaca (SBC) caracterizado por su pequeño tamaño y tener todo lo necesario en la placa base), solventando así esos problemas. A su vez, la RASPBERRY PI también sirvió de punto de acceso, pues a través de una antena WiFi conectada por USB es posible crear una red WiFi interna utilizada únicamente por los ESP32, aislándolos del exterior. Con ello, el diagrama 2 de conexiones se cumpliría al estar la RASPBERRY PI conectada con los ESP32 a través de la WiFi, mientras que por Ethernet lo estaría a la red de la casa. 11 Broker Eclipse Projects 12 Broker HiveMQ 13 MOSQUITTO es un broker open source desarrollado por Eclipse 55 Capítulo 6 - Aplicación ESP32 Aquí se describe en detalle todos los recursos que gestiona el ESP32 para hacer funcionar nuestro sistema. Administrando la entrada/salida de información desde varios puntos (Servidor HTTP, MQTT, WiFi, etc.). 6.1 Ficheros de gestión de sensores Para facilitar la administración de todos los posibles sensores que se puedan llegar a registrar en el ESP32, se ha optado por dividir todas las tareas existentes relacionadas con ellos en 3 ficheros de gestión. 6.1.1 Gestor de GPIOS Se hará cargo de gestionar correctamente todos los GPIOS de los que disponga nuestro ESP32, que como ya se ha mencionado anteriormente es muy probable que no coincidan. El proyecto está pensado para hacer uso del modelo ESP-WROVER-B. En caso de usar un modelo distinto a ese, se deberá actualizar los GPIOS a los que el modelo admita. El fichero bloqueará los GPIOS que se seleccionen durante la configuración de nuestro sistema (puede darse el caso de que un GPIO no se bloquee si se trata de un canal que pueda ser compartido, como por ejemplo I2C). También el caso contrario, liberará los GPIOS que dejen de ser usados para que pueda volver a ser seleccionado. 6.1.2 Gestor de recolección Este fichero se encargará de recolectar información relativa a lo sensores, tanto las variables del entorno que calcule, como los posibles parámetros o GPIOS que lo definan. Básicamente lo que hace es almacenar todas las funciones “get” de los sensores. Esas son: • X_get_sensors_data: función que envía datos propios del sensor como su nombre. Y también las variables que calcula. • X_get_sensors_gpios: función que envía los GPIOS que están siendo usados por las unidades de ese sensor. • X_get_sensors_additional_parameters: función que envía los posibles parámetros adicionales que fueran necesarios para el correcto funcionamiento del sensor. Casi toda la información que devuelve este gestor lo hace en formato JSON. 56 6.1.3 Gestor de configuración Es el gestor intermediario entre el usuario y los sensores que se desean configurar. Permite configurar valores como los GPIOS que se desean usar, cambiar los umbrales de alarma de una variable e incluso desplegar o eliminar unidades de un tipo de sensor. Almacena todas las funciones “add”, “delete” y “set” de los sensores. Esas son: • X_add_sensor: función que realiza todo lo necesario para desplegar una nueva unidad de cualquier sensor registrado. • X_delete_sensor: función que realiza lo necesario para eliminar una unidad de cualquier sensor registrado. • X_set_gpios: función que hace cambios para establecer el uso de nuevos GPIOS. Libera los que se estaban usando y bloquea los que se quieren usar. • X_set_parameters: función que hace cambios en los parámetros adicionales necesarios para el correcto funcionamiento del sensor. • X_set_location: función que hace cambios en la localización en la que se encuentra una unidad. • X_set_alert_values: función que hace cambios en las variables relacionadas con las alarmas de un sensor. Nota: ‘X’ equivale al nombre del sensor a la que se envía la orden (por ejemplo dht22_set_location(…)). 6.2 Sincronización Otro de los problemas encontrados durante el desarrollo del proyecto fue el de la sincronización entre los ESP32 y el resto del sistema ya que habría que, por ejemplo, si un usuario recibe dos mensajes a la vez del mismo ESP32 o alguno otro que se haya quedado “atascado” en la red no habría forma de saber cuál es el más reciente y, por tanto, el más realista con la situación actual. Para solventar este problema se pensaron en varias opciones que se exponen a continuación. 63 La memoria flash que tienen los ESP32 por lo general son de 4MB, aunque los puede haber de otros tamaños como 8MB o incluso 16 MB (También cabe la posibilidad de que no tenga). La memoria se encuentra dividida en particiones, más concretamente en las siguientes: Nombre Tipo Subtipo desplazamiento Tamaño nvs data nvs 0x9000 0x14000 otadata data ota 0x1D000 0x2000 phy_init data phy 0x1F000 0x1000 ota_0 app ota_0 0x20000 0x1F0000 ota_1 app ota_1 0x210000 0x1F0000 Tabla 6-1. Tabla de particiones de la memoria Esta tabla no es una de las que nos ofrece el entorno de Espressif, se trata de una tabla de particiones personalizada. Esto se debe a que no teníamos espacio suficiente para todo el programa. Por ello se decidió personalizarla, lo cual nos permitió adquirir todo el espacio de la memoria que no estaba siendo utilizado, con esto se consiguió el doble de memoria de la que se tenía previamente. En este caso nos centraremos en la partición “nvs” que será el lugar donde se almacenen las variables o bloques de variables que nos interesen. La información se almacenará por parejas clave - valor. Cuando se use una misma clave múltiples veces a la hora de almacenar información, solo persistirá la última de todas, el resto quedarán eliminadas por completo. La clave no debe superar los 15 caracteres (incluyendo el carácter nulo) y algunos de los tipos de valores que se pueden almacenar son los siguientes: • “Int” y “Uint”, así como posibles subdivisiones de ellos (8 bits, 16 bits, etc.). • “String”, el tamaño máximo (incluido el carácter nulo) no debe superar los 4000 bytes • Blob, está pensado para almacenar estructuras. El tamaño de la estructura no debe superar los 508000 bytes o el 97,6% del tamaño de la partición - 4000 bytes, lo que ocurra antes. 64 65 Capítulo 7 - Despliegue del ESP32 A lo largo del desarrollo del proyecto se ha utilizado una placa de prototipo al que estaba conectado el ESP32 con todos los sensores a través de un adaptador para el propio ESP32, con lo cual esto provoca que todos los componentes estén expuestos y no sea viable su uso en exteriores. Ilustración 7-1. Sensores conectados a la placa de desarrollo Freenove Por lo tanto, para solventar el problema de que las conexiones de los sensores y el propio ESP32 estén expuestos al aire libre se optó por utilizar una caja de conexión estanca. De este modo, se podría instalar el ESP32 con sus sensores en el exterior o, simplemente para aislarlo. 66 Ilustración 7-2. Caja estanca Sin embargo, al buscar una caja acorde a las dimensiones de la placa que se estaba utilizando no se encontró una que sea lo suficientemente pequeña, por lo que, finalmente, se decidió por utilizar una placa de desarrollo especial para el ESP32, reduciendo así considerablemente el tamaño ocupado en comparación con la placa de prototipado. Ilustración 7-3. Comparación placa de desarrollo Freenove con uno especial para ESP32 67 Finalmente, para fijar el ESP32 a la caja se ha utilizado silicona aplicado directamente entre la placa y la caja, se ha fijado un trozo de placa de prototipado para las tomas de tierra y alimentar con 3.3V a los sensores que lo necesiten y, para poder conectar los sensores desde el exterior se han utilizado tubos de PVC. Ilustración 7-4. Montaje caja estanca con una batería externa como fuente de alimentación 7.1 Fuente de energía Otra cuestión importante para el montaje final del ESP32 fue la de qué se utilizaría para alimentar al ESP32 y todos los sensores, pues al tener pensado que se utilizará en exteriores, no se podría depender de que siempre hubiese un enchufe cerca. Por ello, se pensó en hacer uso de baterías de lión litio 18650 para alimentar al ESP32, las cuales podrían ser cargadas a través de paneles solares durante el día siguiendo el siguiente esquema: 68 Figura 7-1. Esquema paneles solares En el que se utiliza un módulo TP4056 para controlar la carga y descarga de la batería, y un MCP1700 para regular el voltaje de la batería, pues en su máxima capacidad tiene una salida de 4.2 V cuando el ESP32 admite como mucho 3.3V. No obstante, tras una revisión de las especificaciones del TP4056 15 se ha visto que no es del todo seguro utilizarlo con ese esquema debido a su propio funcionamiento, el cual consiste, de forma resumida, en suministrar una corriente constante (después de una serie de comprobaciones) y, conforme detecte que se está llegando a los 4.2V va bajando la corriente hasta el punto que detecte que la batería ya no lo está absorbiendo, dando así por terminada la carga. Figura 7-2. Proceso de carga del TP4056 15 TP4056 - Datasheet 69 Es por ese último paso que no es recomendable el uso de este módulo en el anterior circuito, pues de la batería está “colgando” el ESP32 y todos sus sensores, los cuales están constantemente consumiendo la energía provocando que la carga nunca acabe, desgastando así la vida útil de la batería considerablemente (pues se está cargando y descargando todo el rato e, incluso podría sobrecargarse). Por esta razón se buscó otra forma de poder cargar la batería y alimentar el ESP32 sin correr riesgos, encontrando así el MCP73871, el cual es un módulo que se encarga de gestionar la carga de la batería y de la alimentación del ESP32 de forma segura. Sin embargo, a la fecha de la realización del montaje final este componente no estuvo disponible y su entrega se estimaba después de la entrega del TFG, por lo que no se ha podido llevar a cabo, quedándose como un plan de trabajo futuro poder integrar baterías de li-ión litio y paneles solares como fuente de energía al proyecto. Ilustración 7-5. MCP73871 70 71 Capítulo 8 - Herramientas utilizadas Todo el proceso de creación de nuestro sistema se ha llevado a cabo gracias a una serie de herramientas o programas que nos lo han permitido. A continuación, veamos algunas de las más relevantes: 8.1 Arduino IDE Arduino IDE es uno de los entornos de desarrollo más conocidos del mundo. Su fama se debe a la simplicidad de su interfaz, la cantidad de librerías preprogramadas que contiene y la gran compatibilidad que tiene con los microcontroladores. Fue creada para poner en funcionamiento sus placas de Arduino, pero con la ayuda de terceros, a día de hoy se pueden programar aplicaciones e instalarlas en muchos más tipos de placas, entre ellas las del ESP32. Ilustración 8-1. Vista principal Arduino IDE 72 Como se puede observar, el concepto que se lleva a cabo en este entorno de desarrollo es muy simple, usando únicamente una función “setup” que se ejecuta al inicio del programa y una función “loop” que se ejecuta a continuación del “setup” y lo hace de manera cíclica cada vez que llega al final de sí misma. Arduino IDE es un entorno tan amigable y fácil de usar que nos hemos servido de él para introducirnos en el mundo de los microcontroladores ESP32. Hicimos diferentes pruebas con diversos periféricos para tener una idea inicial de como empezar a desarrollar todo el trabajo. Pero llegado el momento se decidió que Arduino no iba a ser el entorno que se usase para nuestro proyecto final. Nosotros buscábamos algo que nos permitiese llevar a cabo lo que teníamos en mente, especificando con más detalle todo. Así que nos trasladamos al entorno de desarrollo ofrecido por la propia compañía creadora de los ESP32. Este entorno se llama SDKIDF. 8.2 SDK-IDF SDK-IDF es el entorno de desarrollo aconsejado para la programación de los ESP. Es mucho más interesante que Arduino debido a que da una mayor libertad al usuario para llevar a cabo el proyecto que realmente quiere. Esa libertad se traduce también en una mayor complejidad a la hora programar lo que necesitas, puesto que se trata de un entorno de desarrollo más completo como podrían ser Eclipse o Visual Studio. Ilustración 8-2. Vista principal SDK-IDF 79 Studio, lo que indica que dispondremos de una mayor cantidad de plugins y herramientas en Android Studio especiales para este lenguaje. Además, Kotlin se presenta como un lenguaje más conciso y fácil de leer y de escribir. Esto nos permite escribir código más rápido y, por tanto, de manera más eficiente. Por último, se debe hacer especial hincapié en su principal diferencia con Java, y es el enfoque que tiene Kotlin ante la nulabilidad. Ya qué los tipos de datos en Kotlin, no pueden ser nulos por defecto, y, en consecuencia, los errores de NullPointer se detectan en tiempo de compilación en lugar de en tiempo de ejecución, ofreciendo un código más seguro y robusto. 9.1.3 SQLite Fue necesario crear una base de datos para nuestra aplicación y la elección es SQLite. SQLite es una base de datos relacional de código abierto muy común que además se encuentra integrada de manera nativa en Android y, por tanto, no ha sido necesario la instalación de paquetes adicionales. También tiene poca complejidad y es una base de datos con la que ya había trabajado con anterioridad en varias asignaturas de la carrera, además es una base de datos muy ligera, que ocupa poco espacio de almacenamiento y memoria RAM. Otro aspecto a destacar es la velocidad con la que se realizan las escrituras y las lecturas, haciendo que nuestra aplicación sea más rápida y no notemos delays. Todo esto se consigue gracias a 4 factores fundamentales: • Su arquitectura, ya que está diseñada como una base de datos sin servidor que se ejecuta de manera local, por tanto, no es necesario realizar peticiones a la base de datos que puedan tener delay en la respuesta. • Las transacciones de la base de datos están optimizadas de manera que permite varias operaciones realizarse en un solo bloque, reduciendo así el número de escrituras necesarias. • Uso de índices: ya que, al tener identificadores únicos, es más fácil buscar y clasificar los elementos en la base de datos, traduciéndose esto en una mayor velocidad de acceso a la información contenida. • Y, por último, el uso de sistema de archivos del sistema operativo subyacente para el almacenamiento de datos. 80 9.1.4 Shared Preferences Los SharedPreferences en Android, son ficheros que contienen pares, clave-valor, donde la clave será un string y el valor puede ser desde un string a un booleano o incluso un conjunto de strings. Y que nos permiten el acceso y la escritura de datos de manera sencilla. Es un método perfecto para guardar preferencias y configuraciones del usuario, y dado que nuestra aplicación necesita guardar preferencias y configuraciones. 9.1.5 View Binding Usualmente en Android se hacía empleo del método findeViewById() para referenciar los componentes de las vistas. Esto hace necesario que si una vista tiene varios elementos, tengamos que referenciar cada uno de los elementos mediante el método findViewById(). Y es una tarea que puede ser propensa a errores, además de ser muy tediosa de hacer, dado que hay vistas que pueden tener muchos componentes visuales y cada vez que se añade un nuevo componente debemos referenciar de nuevo. No solo eso, sino que también el impacto que se tiene en la cantidad de código que se debe escribir, es otro punto en contra. Es por eso que surge View Binding, que se presenta como una herramienta que nos permite acceder a la vista de un Activity o Fragment. Para llevar a cabo su tarea, View Binding crea una clase de vinculación para cada archivo de vista que tenemos, un layout, y a todas las componentes de esa vista, por tanto, una vez hayamos referenciado el layout, ya podemos acceder a todas sus componentes simplemente accediendo al objeto que se ha creado de la vista. Figura 9-1. Esquema de interacción vista/modelo 81 Además, la vinculación se genera automáticamente cada vez que se realiza la build de la aplicación. Lo que significa que la vista siempre estará actualizada al añadir nuevos componentes visuales dentro de esta. En la figura inferior se muestra un ejemplo donde vinculamos el layout de la actividad y configuramos un listener para el botón que tenemos dentro de la vista. Ilustración 9-2. Ejemplo de uso de un objeto binding 9.1.6 Servicios de Android Un servicio en Android, es un componente de una aplicación que nos permite lanzar operaciones de larga duración en segundo plano, permitiendo que nuestra aplicación lance un servicio que se mantenga en ejecución incluso cuando el usuario haya cerrado la aplicación. Esto nos dará la posibilidad de usar este servicio combinado con las notificaciones de Android, creando un canal de notificaciones con un único id. De esta manera nuestro servicio mostrará los mensajes recibidos en ese canal seleccionado. Figura 9-2. Comunicación service con notification manager 82 9.1.7 JSONTokener Herramienta que permite procesar datos en formato JSON. Es una clase que viene con la biblioteca JSON-java y facilita el trabajo con objetos JSON en Kotlin y por supuesto, en Java. Funciona analizando cadenas de texto y extrayendo objetos JSON según la sintaxis que debería tener un objeto JSON. 9.1.8 Paho MQTT Librería open source que nos permite, mediante métodos sencillos, establecer conexiones a través de MQTT. Estas conexiones son con brokers MQTT que actúan como servidores intermediarios entre los dispositivos que publican y los que reciben los mensajes. En este caso nuestra aplicación actúa como cliente que intenta comunicarse con otros clientes que son los microcontroladores. 9.2 Especificación de requisitos de la aplicación móvil En este apartado, vamos a describir los actores y los casos de uso que se han definido para la aplicación. Para simplificar el desarrollo del esquema, agrupamos los casos de uso en módulos funcionales y definimos los tipos de usuarios que utilizarán nuestra aplicación. 9.2.1 Actores de la aplicación En la aplicación podemos describir los siguientes tipos de usuarios: • Usuario no logueado: es el usuario que aún no se ha conectado y, por tanto, no se ha conectado con el broker MQTT. Dándoles la posibilidad solo de poder conectarse con usuario ya existente o con un nuevo usuario y con nueva información de conexión MQTT. • Usuario logueado: es el usuario que ya ha introducido los datos para establecer conexión con el broker MQTT, en consecuencia, dispone de todas las funcionalidades de la aplicación. 83 9.2.2 Módulos de la aplicación Los módulos funcionales de la aplicación que se han definido son los siguientes: • Módulo de scan. • Módulo de edición. • Módulo principal. • Módulo de login. 9.2.2.1 Módulo de login En este módulo se muestran las funcionalidades del usuario que aún no ha establecido conexión con el broker MQTT y, por tanto, estarán limitadas. En la Figura representamos el diagrama con los casos de uso para el módulo respectivo. Figura 9-3. Diagrama casos de uso módulo de login A continuación, describiremos los casos de uso del módulo de login. Login nuevo usuario Actores Usuario no logueado Descripción El usuario no logueado accede al menú de Login que le permiten identificarse y conectarse al broker Mqtt. Precondición Que el usuario conozca el usuario, la contraseña y la IP para conectarse al broker MQTT. Secuencia Normal 1. El usuario selecciona la opción de Nuevos Datos Mqtt. 2. Introduce la ip y el puerto del broker Mqtt. 84 3. Introduce usuario y contraseña para identificarse en el broker. 4. Introducir el nombre de usuario que usaremos para los tópicos en los que publicaremos y recibiremos los mensajes Mqtt. Postcondición El usuario accede a la página principal de gestión y visualización de dispositivos ESP32. Tabla 9-1. Login nuevo usuario Login usuario existente Actores Usuario no logueado Descripción El usuario no logueado accede al menú de Login que le permiten identificarse y conectarse al broker Mqtt. Precondición Que el usuario haya accedido anteriormente con un usuario, contraseña e IP para conectarse al broker MQTT. Secuencia Normal 1. El usuario selecciona la opción de Usar Datos Guardados. Postcondición El usuario accede a la página principal de gestión y visualización de dispositivos ESP32. Tabla 9-2. Login usuario existente Salir de la aplicación Actores Usuario no logueado Descripción El usuario no logueado puede cerrar la aplicación. Precondición Que el usuario esté en el menú de login. Secuencia Normal 1. El usuario pulsa el botón Atrás del móvil. Postcondición La aplicación se cerrará. Tabla 9-3. Salir de la aplicación 9.2.2.2 Módulo principal En este módulo, se encuentran las funcionalidades principales de la aplicación, que tienen que ver con la visualización de los dispositivos conectados y el acceso a la gestión de estos. En la Figura podemos ver el diagrama de casos de uso del módulo en cuestión. 85 Figura 9-4. Diagrama casos de uso módulo principal Describimos a continuación los casos de uso más detalladamente. Eliminar dispositivo existente Actores Usuario logueado Descripción Elimina un dispositivo existente de la lista de dispositivos a los que estamos suscritos para recibir información de sus sensores. Precondición El dispositivo debe estar en la lista de dispositivos a los que estamos suscritos. Secuencia Normal 1. Selecciona uno de los dispositivos y el fondo de ese dispositivo se vuelve oscuro para indicar que está seleccionado. 2. Seleccionamos el botón con símbolo de contenedor que se encuentra en el menú superior para eliminarlo. 3. El dispositivo desaparecerá de la lista de dispositivos de los que recibimos información. Postcondición El dispositivo se eliminará de la lista de dispositivos y dejamos de estar suscritos al tópico en el que se publica información sobre ese dispositivo. Tabla 9-4. Eliminar dispositivo existente Refrescar información del dispositivo Actores Usuario logueado Descripción Refresca la información de los sensores de un dispositivo. Precondición El dispositivo debe estar en la lista de dispositivos a los que estamos suscritos. 86 Secuencia Normal 1. Pulsamos el botón con símbolo de refrescar que se encuentra en la esquina derecha del nombre del dispositivo. 2. La aplicación publica en el tópico Refresh del dispositivo con el nombre del usuario y el ID del mensaje. 3. La aplicación suscribe al tópico refresh donde publicará el dispositivo ESP32 en cuestión. 4. Se recibe un JSON con la información de los sensores del dispositivo. 5. Se parsea el JSON y se muestra la información de los sensores de ese dispositivo. Postcondición La aplicación publicará en su tópico para ese dispositivo y después recibirá la información de los sensores del mismo, refrescando el valor si hubiera cambiado. Tabla 9-5. Refrescar información del dispositivo Acceso a la vista de edición de dispositivos Actores Usuario logueado Descripción Acceso a la vista con dispositivos disponibles. Precondición El usuario debe estar en la página principal de la aplicación y haber establecido conexión con el broker Mqtt. Además, el dispositivo debe estar en la lista de dispositivos a los que estamos suscritos. Secuencia Normal 1. Seleccionamos el dispositivo que deseamos editar. 2. Una vez seleccionado pulsamos el botón con símbolo de lápiz que tenemos en el menú superior para editar el dispositivo. Postcondición Accedemos a la vista de edición del dispositivo. Tabla 9-6. Acceso a la vista de edición de dispositivo Acceso a la vista de escaneo de dispositivos Actores Usuario logueado Descripción Acceso a la vista con dispositivos disponibles. Precondición El usuario debe estar en la página principal de la aplicación y haber establecido conexión con el broker Mqtt. Secuencia Normal 1. Pulsamos el botón “+” que se encuentra en el menú superior. 2. La aplicación lanzará la actividad de escaneo y nos mostrará otra vista. Postcondición Accedemos a la vista de escaneo de dispositivos disponibles. Tabla 9-7. Acceso a la vista de escaneo de dispositivos 87 9.2.2.3 Módulo de scan Figura 9-5. Diagrama casos de uso módulo scan En este módulo, está contenido la funcionalidad relacionada con el escaneo y la posibilidad de añadir dispositivos ESP32 que se encuentran publicando en el broker con el que hemos establecido comunicación. En la Figura observamos el diagrama de casos de uso de este módulo. Escaneo de dispositivos Actores Usuario logueado Descripción Realizar un escaneo de los dispositivos que están publicando en el broker actualmente. Precondición El usuario debe estar en la página de Scan de la aplicación y haber establecido conexión con el broker Mqtt. Secuencia Normal 1. Estar en la página de scan de la aplicación. 2. La aplicación publicará en el tópico de Scan. 3. Se reciben los mensajes de los dispositivos conectados al broker en formato JSON. 4. Se parsea el JSON y se extrae el nombre único de los dispositivos. 5. Mostramos una lista con los nombres de los ESP32 disponibles. Postcondición Se mostrarán los dispositivos ESP32 disponibles con su identificador único. Tabla 9-8. Escaneo de dispositivos 88 Añadir un dispositivo Actores Usuario logueado Descripción Añadir un dispositivo ESP32 nuevo. Precondición El usuario debe estar en la página de Scan de la aplicación y haber establecido conexión con el broker Mqtt. También debe tener dispositivos disponibles siendo mostrados. Secuencia Normal 1. Seleccionar el dispositivo que cambiará de color para saber que está seleccionado. 2. Pulsar el botón de ADD para suscribirnos al dispositivo y añadirlo a la lista de dispositivos. 3. El dispositivo desaparece de la lista de dispositivos disponibles. 4. El dispositivo es añadido a la base de datos. Postcondición Se guardará el nombre único del dispositivo en la base de datos de la aplicación y desaparecerá de la lista de elementos disponibles. Tabla 9-9. Añadir un dispositivo 9.2.2.4 Módulo de edición El módulo de edición contiene todas las funcionalidades relacionadas con la edición de un dispositivo ESP32 y sus parámetros. En la Figura se muestra el diagrama de casos de uso más detalladamente. Figura 9-6. Diagrama casos de uso módulo de edición 95 Ilustración 9-3. Pantalla de primer acceso La figura inferior nos muestra lo que ve el usuario una vez selecciona la opción de NUEVOS DATOS MQTT desplegándose un menú de Login, donde cada cuadro de texto se ha diseñado utilizando la librería Material de Android. Gracias a esta herramienta encontramos el icono dibujado en cada recuadro para indicarnos más claramente qué información debe estar rellenada en ese recuadro. Además, se obliga al usuario a rellenar cada campo. En caso contrario se le informará que no puede intentar la conexión y se le requerirá rellenar todos los campos. En caso de haber rellenado correctamente todos los campos, al pulsar el botón SIGN y se recogerá la información contenida en los campos y se usará para intentar establecer conexión con el broker Mqtt. Si se ha establecido la conexión correctamente, la información de inicio de sesión será guardada en el fichero SharedPreferences y la aplicación nos llevará al menú principal de usuario Logueado como se muestra en la figura. 96 Ilustración 9-4. Pantalla de login 9.5.2 Módulo principal En esta pantalla el usuario puede ver todos los dispositivos Esp32 a los que está suscrito, permitiendo añadir y eliminar elementos de forma dinámica, viéndose estas modificaciones reflejadas en las pantallas. Para conseguir esto, se ha utilizado un RecyclerView, que es un componente de la librería de Android que permite mostrar conjuntos de datos dinámicos. Para ello, se introduce en la vista un elemento del tipo RecyclerView, este RecyclerView necesitará un adapter, que se encargará de inflar el diseño de la lista y vincular cada uno de los componentes de esta. 9.5.2.1 Generación y visualización de elementos Para entenderlo mejor, crearemos la vista de cada uno de los elementos que queremos mostrar en la lista, que será el ItemViewHolder, con la lógica de esta pantalla y la vista, como se muestra en la siguiente figura: 97 Ilustración 9-5. Visualización de elementos (ItemViewHolder) En esta vista se cargarán gracias a la lógica del ViewHolder los objetos Esp32 en la vista. Haciendo que los sensores del objeto Esp32 que no estén inicializados porque no están instalados no mostrarán sus valores y solo veremos los que tenemos instalados. Una vez creada la vista y la lógica de cada elemento, se pasa una lista de estos elementos al adapter, de esta manera tenemos control sobre lo que ocurre en cada elemento de la vista y en los cambios que ocurran en cada dispositivo que esté en la lista. Por tanto, lo que hacemos en esta pantalla, es tener una lista de Esp32, que se le proporciona al adapter, que inflará cada elemento mediante una función que actualiza la vista de cada uno de ellos. Para poder visualizar mejor el funcionamiento del RecyclerView podemos observar la figura inferior. Figura 9-8. Esquema RecyclerView Esto significa que cuando se actualice uno de los elementos, porque hemos recibido información de ese Esp32, solo actualizaremos la vista de ese elemento, lo que hace que esta forma de representar datos sea muy eficiente. 98 Ilustración 9-6. Pantalla principal Ahora que sabemos cómo se construye la vista, debemos saber cómo se generan los elementos de esta. En primera instancia, los elementos que se ven son los sensores que publican en el tópico del elemento 1 del Esp32 al que estamos suscritos. Pero para poder diferenciar cada sensor del mismo tipo que tiene un Esp32, se crean elementos nuevos visuales con el mismo nombre del Esp32 y añadiendo el número del sensor del mismo tipo, por tanto, tal como se ve en la figura Pantalla Principal si tenemos varios sensores del mismo tipo, se generan elementos visuales para diferenciar cada nuevo elemento. Para poder refrescar la información de un elemento, lo que hace el usuario es pulsar el botón de refresco del elemento en cuestión. Al pulsar este botón, lo que hace la aplicación es publicar un JSON con su nombre y un ID del mensaje estando suscrito al tópico MESPF/USR/NOMBRE_USUARIO/REFRESH/ESP32_X/+/+/INFO, de esta manera recibiremos información de todos los sensores que tenga el ESP32. 99 9.5.2.2 Eliminar elemento Cada elemento de la lista se puede seleccionar pulsando sobre él. Esto hará que cambie el color de fondo indicándonos que el elemento está seleccionado y utilizando el botón seleccionado en la figura inferior eliminará ese elemento, tanto de la lista, como de la base de datos, y se desuscribirá de los tópicos de ese microcontrolador Esp32. Ilustración 9-7. Menú superior 9.5.2.3 Añadir elemento El elemento “+” del menú superior, abrirá una nueva actividad llevándonos a otra ventana, donde podremos observar los microcontroladores disponibles. Este es el módulo de scan que explicamos en el siguiente punto. 9.5.2.4 Editar elemento El elemento Editar del menú superior funciona de manera parecida al botón de eliminar. Al seleccionar un elemento y seleccionar la opción de Editar que es el símbolo restante. Se lanzará una nueva actividad, pero esta actividad tendrá extras, que es una forma de poder compartir variables y elementos entre actividades al lanzar una nueva actividad. En nuestro caso, enviaremos los datos del Esp32 a esa actividad. 9.5.3 Módulo de scan La vista que se muestra en la figura indica que tenemos un microcontrolador Esp32 que está publicando en el broker. La implementación de la lista de dispositivos disponibles se hace de la misma manera que se ha diseñado y construido el RecyclerView de la página principal. Pero para este caso los elementos son de tipo Tópico y solo tienen un nombre y un alias como variables de la clase. Por tanto, hemos creado otra clase Adapter personalizado para los tópicos. Al acceder a la vista, el usuario publica en MESPF/SENS/SCAN un JSON con su nombre y el ID del mensaje y suscribe al tópico MESPF/USR/USER_NAME/SCAN para recibir los dispositivos Esp32 disponibles para suscribir y recibir información de sus sensores. 100 Para ello, el usuario seleccionará el elemento al que desea suscribirse viendo que el color del fondo de ese elemento cambia para indicar que está seleccionado, y pulsará el botón de ADD, añadiendo el elemento a la base de datos y eliminándolo de la vista. Los elementos a los que suscribamos en esta vista son los que se mostrarán en la pantalla principal. Ilustración 9-8. Pantalla de scan 9.5.4 Módulo de edición Por último, la pantalla de Edición, al iniciar podemos observar en primer lugar el nombre del dispositivo que estamos editando. El primer cuadro de texto permite editar el alias que se mostrará en la aplicación una vez utilicemos el botón de guardado que está al lado de este. Para el resto de funcionalidades, el usuario tiene que hacer uso del selector de sensores que nos permite elegir el tipo de sensor que queremos modificar. El n.º del sensor en cuestión y los umbrales, que cambian el texto mostrado dependiendo del tipo de sensor que hemos seleccionado. Y no solo eso, además también se muestran los parámetros especiales de los dispositivos que los tengan, como podemos observar en la figura que ocurre con la profundidad del tanque y la distancia del sensor. 101 Ilustración 9-9. Pantalla scan HC-SR04 Ilustración 9-10. Pantalla scan DHT22 102 Al consultar los datos, si existe el sensor, veremos cómo los datos se actualizan, incluyendo el switch que muestra si la alarma está o no activa como en la figura inferior. Ilustración 9-11. Pantalla consulta correcta Ilustración 9-12. Pantalla consulta errónea 103 Esto ocurre de la misma manera al intentar modificar los parámetros del sensor, en caso de éxito se nos muestra por pantalla y se puede volver a consultar para ver que los cambios han surtido efecto. Y en caso contrario se nos devuelve un código con errores que parseamos y mostramos al usuario mediante un Toast. Ilustración 9-13. Pantalla de error al guardar modificación 104 111 b. Program a javascript file that allows the web application to connect to the ESP32 microcontroller and communicate with it via XML requests. c. Generate the necessary tools to be able to configure the Wi-Fi, NTP and MQTT connections. d. Display information about the sensors connected to the microcontroller. e. Allow the web application to add or remove sensors, as well as to be able to configure all its parameters dynamically. f. Beautify the interface using CSS. 7. Tests and fixes a. Perform system tests to check that all components are working properly. b. Carry out the relevant adjustments and corrections to the software and the configuration of our system. 8. Documentation a. Document the development process. b. Prepare a presentation of the project for defense, including a demonstration of its operation. Conclusions and future work Throughout the process, we encountered several difficulties, such as the use of new technologies like Kotlin. The use of ESP32 microcontrollers was also a challenge, as we had to understand their architecture and operation in order to take advantage of their full potential. The MQTT protocol, which was a first approach for all of us, was also an extra difficulty to understand and be able to use it correctly. However, the objectives set at the beginning of the project have been met satisfactorily, fulfilling the initial expectations and even surpassing them by implementing functionalities such as the OTA that allows the ESP32 to be updated without the need to be physically next to it. As the system is, there were possible improvements for the future, but due to lack of time or resources they could not be implemented in this version. Some security problems were found, such as: 112 • The possibility of viewing through a network eavesdropper (using Wireshark, for example) the packets sent by MQTT because they do not have any encryption. The suggested solution for the future is to include SSL with certificate between the broker and the ESP32 for data encryption. • Easy physical access to the ESP32, allowing anyone to connect through a USB port and load the software of their choice. For this purpose, the access to the ESP32 is shielded. • Through the OTA functionality, it is possible to upload any binary file to the ESP32, either by being connected to the same Wi-Fi network or by causing one of the ESP32s to enter AP+STA mode. When entering AP+STA mode, your Wi-Fi and password are public knowledge, which may make the initial configuration easier for third parties. It is also suggested to configure OTA to only support code or signed files for future releases to avoid the possibility of uploading third party files 113 CONTRIBUCIONES PERSONALES Enrique Juez de Miceli Es quien se encarga de la programación y buen funcionamiento de la aplicación a nivel del ESP32 (junto con su compañero Fabrizio). Su aportación a este proyecto se puede dividir en dos bloques: • Periféricos: Ha sido el encargado de programar toda la lógica detrás de los drivers. Haciendo una evolución constante de los mismos durante el desarrollo del sistema. Empezando por una primera versión completamente estática sin posibilidad de modificar parámetros relacionados con ellos, ni gestionar más de una unidad al mismo tiempo. Hasta una versión bastante completa donde se permite el despliegue y repliegue de unidades de manera dinámica durante la ejecución del programa, así como, la modificación de muchos de los parámetros que definen a un sensor/unidad, como por ejemplo sus GPIOS, los umbrales de alerta para cualquiera de los valores que calcule, la localización donde se encuentra la unidad u otros parámetros adicionales que sean cruciales para el buen funcionamiento de los sensores. Para llevar a cabo esta labor, ha desarrollado dos ficheros desde cero y ha ampliado en gran medida uno creado por su compañero Fabrizio. Todos ellos encargados de gestionar a los sensores. Creó un fichero para los GPIOS que maneja el ESP32 que estemos utilizando, con el propósito de hacer una correcta gestión de los mismos y a su vez facilitar en gran medida la compatibilidad entre distintos modelos de ESP32, donde el usuario tan solo tendrá que modificar unas pocas variables para adaptarla a sus necesidades. El otro fichero que hizo se encarga de intermediar las peticiones “Add” “Delete” y “Set” de los usuarios con los sensores, creando un punto común al que dirigir las peticiones, ya sean desde el servidor HTTP como de la aplicación móvil vía MQTT. El fichero que amplió es el encargado de recolectar información de los sensores. La primera versión solo era capaz de recolectar los valores calculados por los sensores, pero lo amplió hasta el punto que era capaz de recolectar cualquier información relevante para el servidor HTTP o aplicación móvil. 114 Por ultimo y no por ello menos importante hizo el driver que gestiona el LCD. Tanto las funciones que modifican el funcionamiento del LCD, como la tarea que se le ha encargado hacer. Dicha tarea es mostrar de manera constante y cíclica la información relativa al Status del sistema y todos los sensores que estén registrados en el microcontrolador. • Servidor HTTP El otro bloque del que se ha encargado es todo lo relacionado con el servidor HTTP. Partió de una versión casi sin contenido, se trataba de una versión casi estática. Lo amplió de forma que el contenido de la página web se fuese mostrando y eliminando de manera dinámica, pasando a una versión completamente interactiva para el usuario. Programó el JavaScript casí entero (Fabrizio hizo una parte también) de forma que le otorgó a la página web la capacidad de solicitar información a los sensores para representarlos, a través de llamadas a URIs reconocidas por nuestro sistema. El sistema lo reconoce gracias a que los ha registrado en el servidor junto con su correspondiente handler que lo maneja. Una vez terminado todo lo relacionado representación de información, hizo que el servidor pudiese realizar peticiones de modificación a lo sensores. Mientras desarrollaba esos temas, iba mejorando la estética de la web dividiéndola en bloques mucho más coherentes, mostrando información útil para el usuario, etc. Todo ello mediante CSS, dando prioridad a los colores claros y campestres. Finalmente, el grupo acordó dividir la página web en distintas pestañas, haciéndolo menos cargante a la vista. Fuera de esos bloques ha estado comprobando y rehaciendo el código que pudiese suponer vulnerabilidades en nuestro sistema. También ha dado un repaso importante en la memoria para la entrega final, poniendo todo el texto en el mismo formato y procurando dejarlo todo según dice la plantilla. 115 José Fabrizio Alcaraz Escobar Junto con Enrique, se encargó de la programación del ESP32, aunque centrándose principalmente en las conexiones inalámbricas de este, desarrollando el driver del WiFi así como su configuración por defecto para los modos AP (punto de acceso) y STA (estación). Para la parte de MQTT realizó el driver (partiendo de un ejemplo de Espressif) para su conexión, a la vez que la programación de todos los comandos soportados (SCAN, REFRESH, GETCONF y SET) junto con su documentación para que Rares pueda implementarlos en la aplicación móvil. Respecto a la parte de los sensores, se encargó del driver del RTC, pues, aunque ya estaba implementado por terceras personas, tuvo que adaptarlo al proyecto, aunque luego fuese desechado en detrimento al uso de NTP. Además, también estuvo a cargo del STATUS (aunque no sea un sensor físico, a efectos de envío de datos sí se le considera), para el cual buscó maneras de poder sincronizar el ESP32, primero a través del comando SET, posteriormente con el módulo RTC y, finalmente con el uso de NTP y las librerías ya incorporadas por Espressif. Para el servidor HTTP desarrolló la sección de configuración del WiFi, MQTT y del NTP, así como el comportamiento del WiFi (ya que dependiendo de si consigue conectarse o no a la red indicada por HTTP pasa a modo AP o STA). Fuera del ESP32 se centró en el diseño de los temas de MQTT, así como de la coordinación de su uso con la aplicación móvil. También se encargó de todo lo relacionado con el uso de la Raspberry Pi, pues se tuvo que instalar un SO, configurar los usuarios con sus permisos en el broker MQTT y de la creación y diseño de una base de datos, el cual ha sido usado para recoger estadísticas respecto al número de envíos de mensajes o los tiempos en los que cada ESP32 se desconectaban. Para la recolección de los datos para la base de datos tuvo que programar un daemon que se iniciaba junto con el SO, el cual se suscribe a todos los temas de MQTT y cada vez que recibe un mensaje lo vuelca en la base de datos donde, gracias a un trigger se almacenaba en su correspondiente tabla. Por último, se encargó del diseño y montaje final del ESP32, para el cual buscó distintas formas de encapsular y aislarlo del aire libre por seguridad a través de búsquedas por internet, encontrando así distintos tipos de cajas estanco de conexiones que se podrían utilizar, de los cuales finalmente se optó por uno compacto con el que se utilizó en conjunto con una placa de desarrollo específico para el ESP32, dejando de lado así la placa de prototipado que se estaba utilizando desde el inicio del desarrollo del proyecto. Dentro del montaje, fue el que investigó la forma de poder integrar paneles solares junto con baterías de litio a través de foros y artículos 116 de internet, diseño que al final no se pudo llevar a cabo debido a la tardanza en la entrega del circuito integrado que gestiona la carga compartida entre la batería y el ESP32. 117 Rares Petrisor Cincea Fue la persona encargada de todo lo relacionado con la aplicación móvil. En primer lugar, implemento un sistema para poder conectarse a través del protocolo Mqtt al broker. Para ello se tuvo que realizar un trabajo de investigación, eligiendo entre las maneras de implementar este sistema, la óptima. En este caso, la librería de PahoMqtt, que ofrece métodos claros para ello. Una vez establecida la conexión con el broker se empezaron a realizar pruebas para que el sistema fuera capaz de suscribirse a los tópicos del broker. Para ello se publicaba desde MqttExplorer y se mostraban los mensajes en la aplicación. Una vez que se pudo comprobar que era posible la suscripción y recepción de los mensajes publicados en el broker, se implementó todo él parseó de los tipos de mensajes JSON que se iban a recibir de los microcontroladores ESP32, aunque esto fue algo gradual, ya que fueron variando. Además de poder suscribir a tópicos, se implementó la capacidad de publicar en tópicos para poder controlar y modificar los microcontroladores Esp32. Siendo posible la publicación en tópicos y la suscripción y recepción de mensajes utilizando un usuario, una contraseña y una IP estática, que se hardcodeaba, sé implementó la posibilidad de que el usuario final introduzca esos datos. Para ello se ha realizado una pantalla de Login, encargándose de la lógica y el diseño de esta en su totalidad. El siguiente paso a dar fue el desarrollo de la página principal, que planteaba el reto de gestión de los mensajes Mqtt, que se parsean y se categorizan dependiendo del tópico en el que se publica, y de cómo mostrar esos datos. Para llevar a cabo esa tarea, realiza el desarrollo de un RecyclerView y se encarga del diseño de la vista de cada elemento del mismo. Asimismo, se hizo un estudio profundo del ciclo de vida de las actividades y del funcionamiento de los intents para poder llevar a cabo el lanzamiento de nuevas actividades desde la actividad principal. Como es la actividad de scan, que también se realizó implementando un RecyclerView y haciendo uso del parseo y los mensajes Mqtt recibidos. Para que nuestra aplicación fuera capaz de guardar elementos, fue dotada por una base de datos sencilla que guarda todos los dispositivos a los que estamos suscritos. Para ello se hizo uso del conocimiento de DAOS en aplicaciones móviles. También tomó cargo para el diseño y la programación funcional de la vista de edición de un ESP32. Para lo que tuvo que implementar la posibilidad de editar los elementos de la base de 118 datos y la gestión de comunicación para recibir los parámetros de los dispositivos, parsear los mensajes de error y formar los mensajes y publicarlos para la edición de los microcontroladores. A lo largo del proyecto estuvo comunicando continuamente con sus compañeros para establecer el formato de mensajes y poder crear de esta manera una comunicación óptima entre la parte de aplicación móvil y los ESP32. 119 BIBLIOGRAFÍA [1] IoT. Retrieved from SAP « System Analysis Program Development » Available: https://www.sap.com/index.html [2] IoT. Retrieved from AWS «Amazon Web Servicies» Available: https://aws.amazon.com/es/what-is/iot [3] Espressif Systems. ESP-IDF Programming Guide. ONLINE: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/index.html [4] ANDROID STUDIO. Aprende a desarrollar aplicaciones (2021). José Dimas Lujan Castillo [5] Android for Developers. ONLINE: https://developer.android.com/docs [6] Espressif Systems. ESP32 Datasheet. ONLINE: https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf [7] HIVEMQ. MQTT Essentials. ONLINE: https://www.hivemq.com/mqtt-essentials/ [8] Sparkfun. DHT22 Datasheet. ONLINE: https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf [9] Sparkfun. HC-SR04 Datasheet. ONLINE: https://cdn.sparkfun.com/datasheets/Sensors/Proximity/HCSR04.pdf [10] Pololu. MQ2 Datasheet. ONLINE: https://www.pololu.com/file/0J309/MQ2.pdf [11] MOSQUITTO Documentation. ONLINE: https://mosquitto.org/documentation/ [12] Wikipedia. Network Time Protocol. ONLINE: https://es.wikipedia.org/wiki/Network_Time_Protocol [13] Random Nerd Tutorials. Power ESP32/ESP8266 with Solar Panels. ONLINE: https://randomnerdtutorials.com/power-esp32-esp8266-solar-panels-battery-level-monitoring/ [14] eMariete. Añadir cargador de batería a ESP8266 y ESP32. ONLINE: https://emariete.com/cargador-bateria-esp8266-esp32-bien-hecho/ Anexo al repositorio de GitHub: https://github.com/Fabrialc123/My-ESPecial-Finca 120