Trabajo Fin de Grado
GRADO EN INGENIERÍA TELEMÁTICA
DISEÑO DE SISTEMA MONITORIZACIÓN DE CALIDAD DEL AIRE MEDIANTE TECNOLOGÍAS Y SENSORES DE IOT Y
DOMÓTICA
Autor: Mario H. Roldán Martínez Director: Juan Carlos Aarnoutse Sánchez
Autor Mario H. Roldán Martínez
E-mail del autor [email protected]
Director Juan Carlos Aarnoutse Sánchez
Título del TFG
Diseño de sistema de monitorización de calidad del aire mediante tecnologías y sensores de IOT y domótica
Resumen
Actualmente el control y la medición de la calidad del aire está al orden del día y es muy importante.
En este TFG se pretende diseñar un prototipo de software y hardware de bajo coste para la medición de la calidad del aire de una estancia mediante sensores IOT basado en ESP32. Se emplea un ESP32 con ESP Home que tiene conectado un sensor DHT11 para la medición de la temperatura y la humedad, un Senseair S8 para la medición de CO2 y una pantalla st7735 que permite mostrar los datos de forma sencilla al usuario. El ESP32 y HomeAssistant establecen un canal de comunicación usando un protocolo custom TCP "esp home API". Esp home envía a homeassistant por este canal los valores y eventos nuevos según van ocurriendo. HomeAssistant tiene instalada y configurada la integración con InfluxDB, envía una copia de todos los eventos que normalmente guardaría en su base de datos interna a un InfluxDB externo. Esta instancia de InfluxDB se encuentra alojada en los servidores del FOSC y gestionada por Kubernetes.
Titulación Grado en Ingeniería Telemática
Departamento Tecnología de la Información y las Comunicaciones.
Fecha de
presentación Septiembre - 2022
AGRADECIMIENTOS
Para empezar, me gustaría agradecer al tutor de mi TFG, Juan Carlos Aarnoutse Sánchez, la oportunidad de hacer este trabajo y la ayuda recibida.
Agradecer por supuesto a mi familia el sacrificio diario que realizan para que yo haya podido llegar hasta aquí y a mi pareja, por apoyarme y animarme en todo este proceso.
Y para finalizar, agradecer a mis amigos de carrera, pues con ellos es con quien más experiencias, tristezas y alegrías he compartido todos estos años y sin los cuales no estaría donde estoy.
ÍNDICE
AGRADECIMIENTOS 3
ÍNDICE 4
ÍNDICE DE FIGURAS 6
CAPÍTULO 1. INTRODUCCIÓN 8
1.1. Introducción y objetivos 8
1.2. Herramientas software y elementos usados 9
1.3. Estructura y organización del proyecto 10
CAPÍTULO 2. TECNOLOGÍAS PRINCIPALES 11
2.1. HARDWARE 11
2.1.1. Módulo ESP32 11
2.1.2. Raspberry Pi 3 Model B+ 12
2.1.3. SENSOR DE CO2 SenseAir S8 13
2.1.4. SENSOR DE TEMPERATURA Y HUMEDAD DHT11 15
2.1.5. PANTALLA AZ-DELIVERY ST 7735 16
2.2. SOFTWARE 17
2.2.1. ESP Home 17
2.2.2. Home Assistant 17
2.2.3. KUBERNETES 17
2.2.4. INFLUXDB 18
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN ESP32 CON ESPHOME 19
3.1. IMPLEMENTACIÓN HARDWARE 19
3.2. IMPLEMENTACIÓN SOFTWARE 24
3.2.1. PRUEBAS ENTORNO ESPHOME 24
3.2.2. IMPLEMENTACIÓN ESPHOME 27
CAPÍTULO 4. IMPLEMENTACIÓN HOME ASSISTANT 36
4.1. MÉTODOS DE INSTALACIÓN DE HOME ASSISTANT 36
4.1.1 Home Assistant OS 36
4.1.2 Home Assistant Supervised 36
4.1.3 Home Assistant Container 37
4.1.4 Home Assistant Core 37
4.2. INSTALACIÓN HOME ASSISTANT 37
4.3. Overview Home Assistant 39
4.4. Acceso desde internet a Home Assistant 42
4.4.1 Compra de un dominio y su configuración 42
4.4.2 Configuración de forwarding de puertos 44
4.4.3 Permitir acceso desde fuera de la red local a Home Assistant 45
4.5. Comunicación Google Home y Home Assistant 46
4.5.1. Home Assistant Cloud 46
4.5.2. Configuración manual 46
4.5.3. Conclusión y problemas encontrados 48
CAPÍTULO 5. KUBERNETES E INFLUXDB 50
CAPÍTULO 6. CONCLUSIONES Y TRABAJOS FUTUROS 52
6.1. CONCLUSIONES 52
6.2. TRABAJOS FUTUROS 55
BIBLIOGRAFÍA 56
ÍNDICE DE FIGURAS
Figura 1. Esquema simplificado dispositivos y conexionado
Figura 2. ESP32-DevKitC V4 con el módulo ESP32-WROOM-32 soldado Figura 3: Disposición de los pines del ESP32-DevKitC
Figura 4: Raspberry Pi 3 Model B+
Figura 5. Tabla comparativa MH-Z19 y Senseair S8 Figura 6: SenseAir S8
Figura 7: Disposición de los pines SenseAir S8 Figura 8: Disposición de los pines Sensor DHT11
Figura 9: Disposición de los pines pantalla az-delivery ST7735 Figura 10. Montaje ESP32 y sensor de CO2
Figura 11. Montaje ESP32 y sensor DHT11 Figura 12. Vista cenital del prototipo Figura 13. Vista lateral del prototipo
Figura 14. Esquema del prototipo mediante Fritzing Figura 15. Tabla conexionado ESP32 - Senseair S8 Figura 16. Tabla conexionado ESP32 - Pantalla ST7735 Figura 17. Tabla conexionado ESP32 - DHT11
Figura 18. Tabla conexionado ESP32 - Leds
Figura 19. Resultado primera prueba pantalla ST7735 Figura 20. Código primera prueba ST7735
Figura 21. Resultado primera prueba DHT11 Figura 22. Código prueba sensor DHT11
Figura 23. Código prueba Sensor CO2 Senseair S8
Figura 24. Resultado prueba Senseair S8 y botones de calibración Figura 25. Código definición ESPHOME
Figura 26. Opción actualización por OTA Figura 27. Portal cautivo ESPHOME
Figura 28. Código implementación Home Assistant en ESPHOME Figura 29. Código configuración WiFi ESPHOME
Figura 30. Código text_sensor Figura 31. Definición luces
Figura 32. Definición salidas de las luces Figura 33. Definición fuente de texto
Figura 34. Botón para habilitar calibración abc del sensor de CO2 Figura 35. Botón para deshabilitar calibración abc del sensor de CO2 Figura 36. Botón obtención del intervalo de tiempo de calibración abc Figura 37. Botón para forzar calibración
Figura 38. Botón para obtener resultado calibración Figura 39. Definición sensor DHT11
Figura 40. Definición sensor sensor de CO2 Senseair S8 Figura 41. Definición UART sensor de CO2
Figura 42. Definición SPI pantalla
Figura 43. Estructura escritura texto por pantalla ST7735 Figura 44. Definición pantalla ST7735
Figura 45. Imagen de instalación de Home Assistant Figura 46. Instalación Home Assistant
Figura 47. IP Fija Home Assistant
Figura 48. Overview default Home Assistant Figura 49. Vista personalizada Home Assistant Figura 50. Alarmas nivel CO2 Home Assistant Figura 51. Ejemplo alarma 2K CO2
Figura 52. A record en Cloudflare Figura 53 . Petición DNS al subdominio
Figura 54. Modo de encriptación SSL en Cloudflare
Figura 55. Rangos de IP de Cloudflare en configuración Home Assistant Figura 56. Webhook Google Assistant
Figura 57. Setup account linking Google Cloud Platform Figura 58. Nuevas credenciales Service Account
Figura 59. Google Assistant en configuración Home Assistant Figura 60. Sensores en Google Home
Figura 61. No Información humedad en Google Home
Figura 62. Posible solución problema humedad y temperatura en Google Home Figura 63. Instalación InfluxDB en el FOSC
Figura 64. IngressRoute Kubernetes Figura 65. Dashboard InfluxDB Figura 66. Tramos niveles CO2 Figura 67. Nivel de CO2 muy elevado
Figura 68. Peligro radiación temperatura y humedad
Figura 69. Días al año con "wet-bulb temperature" por encima de 32°C
CAPÍTULO 1. INTRODUCCIÓN
1.1. Introducción y objetivos
En este TFG se presenta el diseño de un prototipo de software y hardware de bajo coste para la medición de la calidad del aire de una estancia mediante sensores IOT basado en ESP32 [1]. En la actualidad hay gran cantidad de sensores IOT que se pueden usar con ESP32, en este caso se han empleado un sensor de temperatura y humedad y un sensor de CO2, pero sería fácilmente extrapolable a otros sensores.
Si se realiza una búsqueda rápida de sensores de CO2 por internet, se encontrará gran cantidad de dispositivos de bajo coste que, a priori, parecen una buena opción desde el punto de vista económico, pero, como sucede con casi todos los sensores, además del precio hay que considerar la tecnología que emplea, en este caso, la forma en la que se mide el CO2. La gran mayoría de los comerciales utilizan sensores VOC como el SGP30, que en realidad no miden CO2 directamente, sino que estiman (calculan) la proporción correcta de CO2 en el ambiente [2], a base de suponer que se trata de un local cerrado expuesto a la respiración de las personas y a otros factores como humo de tabaco o consumo de bebidas alcohólicas en relación a unas tablas y datos [3]. Es por ello que la intención de este TFG es hacer un prototipo razonablemente económico, pero persiguiendo que sea fiable y escalable.
Para ello, se emplearán dispositivos y software que requieren de una configuración y una coordinación para funcionar correctamente todo junto.
Además de los dispositivos anteriores, en aras de buscar una solución económica, se ha empleado una Raspberry pi 3 Model B+ [4] como servidor local para alojar un HomeAssistant[5], que además de ser utilizada para realizar diferentes automatizaciones, tiene instalada y configurada la integración con InfluxDB [6]: envía una copia de todos los eventos que normalmente guardaría en su base de datos interna a un InfluxDB externo alojado en el FOSC1. La figura 1 muestra el conjunto de la arquitectura desarrollada en este trabajo y su interconexión.
1FOSC, es una asociación que busca usar y promover el software libre, y, al mismo tiempo, aprender con él tanto dentro como fuera de la universidad. Su sede se encuentra actualmente en laEscuela Técnica Superior de Ingeniería de Telecomunicaciones, Cartagena (Murcia)
Figura 1. Esquema simplificado dispositivos y conexionado
1.2. Herramientas software y elementos usados
Para el desarrollo de este trabajo se han empleado los siguientes programas y librerías:
● Visual Studio Code [7]: IDE empleado para el desarrollo del código de funcionamiento del ESP32
● Python 3.10 [8]: Lenguaje utilizado para el desarrollo del código de funcionamiento del ESP32
● Arch Linux [9]: Distribución Linux Open Source en la que se ha realizado el trabajo.
● ESP Home [10] (ESP32 OS)
● HomeAssistant (Raspberry Pi OS)
● InfluxDB 2.0 (Base de datos)
● Kubernetes [11] (Alojamiento de InfluxDB)
● Draw.io [12] (Software web empleado para la realización de esquemas de bloques)
● Fritzing [13] (Herramienta software empleada para la creación de esquemas de circuitos)
1.3. Estructura y organización del proyecto
A lo largo de este proyecto vamos a estudiar diferentes componentes, tecnologías y software que se han usado para su realización.
Siguiendo los principios de Free Open Source Club (FOSC), todo el software empleado en el proyecto es Software Open Source (OSS), es decir, es un código diseñado de manera que sea accesible al público: cualquier persona puede ver, modificar y distribuir el código de la forma que considere conveniente.
Con intención de realizar un aprendizaje progresivo y de asentamiento de conocimientos, se ha ido realizando el trabajo aumentando la complejidad y las características a tratar de forma gradual, que se refleja en el orden de los capítulos generados en este documento:
- En el segundo capítulo, se realizará una descripción más detallada que la realizada en el capítulo uno de todo lo empleado, del módulo ESP32, de la Raspberry Pi, de los sensores y de los softwares empleados.
- En el capítulo tres se realiza un diseño del esquemático, se documenta la implementación del hardware del ESP32, de los sensores y de la pantalla. Finalmente se explica ESPHOME y el código empleado en su configuración.
- En el cuarto capítulo se añade la Raspberry Pi al prototipo, se personaliza y se configura HomeAssistant para funcionar tanto con ESPHOME, como con el InfluxDB alojado en el servidor del FOSC.
- En el capítulo quinto se realiza el volcado de datos en el servidor del FOSC mediante Kubernetes e InfluxDB para el análisis de los datos.
- Y por último, el capítulo sexto resume las conclusiones principales obtenidas durante este trabajo, y se plantean los posibles trabajos futuros derivados del mismo.
CAPÍTULO 2. TECNOLOGÍAS PRINCIPALES
2.1. HARDWARE
2.1.1. Módulo ESP32
En la actualidad existen infinidad de microcontroladores. En este trabajo se ha elegido el módulo ESP32, un microcontrolador de propósito general de 38 pines que pretende dar una solución de Wi-Fi/Bluetooth todo en uno, integrada y certificada, que proporciona no solo la radio inalámbrica, sino también un procesador integrado con interfaces para conectarse con varios periféricos.
Hemos seleccionado este módulo para la realización del proyecto en base a su versatilidad. Los ESP32 cuentan con un gran número de periféricos, en particular con 34 pines digitales de características muy similares a los que cuentan las placas Arduino, pudiendo agregar LEDs, botones, zumbadores y demás, pero también dispone de un controlador remoto infrarrojo, interfaces I2C, módulos UART, sensores táctiles, conversores digitales-analógicos y viceversa, entre otros. Todo sin olvidar su bajo coste, alrededor de los 10€ o incluso menos si los plazos de entrega no son importantes.
De entre los distintos módulos ESP32 disponibles, hemos usado el más extendido, el ESP32-WROOM-32D [14], que funciona hasta 240 MHz y va montado en una placa ESP32 DevkitC V4 [15]. Entre otras cosas, nos permitirá trabajar con más comodidad, al poder conectar los periféricos con cables de puente o montar el módulo en una protoboard y al tener ya integrada “on-board” una antena PCB que integra Bluetooth, Bluetooth LE y Wi Fi. Todo eso nos ha permitido usar tecnología wifi para la comunicación tanto con la Raspberry Pi como con el propio router de internet sin la necesidad de instalación de módulos extra.
La figura 2 mostrada a continuación muestra los componentes clave, las interfaces y los controles de la placa ESP32-DevKitC V4.
Teniendo en cuenta la gran cantidad de placas de desarrollo que se comercializan, hay que prestar especial atención al datasheet y a la disposición de pines de la placa Devkitc seleccionada, ya que no todas tienen la misma distribución y no todos los pines pueden ser usados con los mismo fines. En nuestro caso el pinout es el que se puede observar en la figura 3.
Figura 3: Disposición de los pines del ESP32-DevKitC
2.1.2. Raspberry Pi 3 Model B+
La Raspberry Pi es un ordenador de bajo coste, del tamaño de una tarjeta de crédito, de arquitectura ARM muy utilizado. Es capaz de hacer todo lo que se espera de un ordenador de sobremesa, desde navegar por Internet y reproducir vídeos de alta definición, hasta hacer hojas de cálculo, procesar textos y jugar, todo aceptando sus limitaciones hardware.
Las Raspberry Pi son muy populares gracias a que se adaptan bien a los dispositivos IoT (Internet of Things), DIY (Do It Yourself) debido a su pequeño tamaño y a sus exhaustivas capacidades. Hay muchos modelos diferentes de placas Raspberry Pi, con diferentes combinaciones de puertos y sensores.
En nuestro caso hemos empleado una Raspberry Pi 3 Model B+ (2018) como servidor local para alojar Home Assistant. El motivo principal de su elección ha sido su disponibilidad y bajo coste en comparación con los modelos más nuevos, aunque como es lógico lo ideal sería emplear un modelo más actual ya que el Home Assistant funcionaría de forma más rápida y fluida.
Figura 4: Raspberry Pi 3 Model B+
2.1.3. SENSOR DE CO2 SenseAir S8
El sensor Senseair S8 [16] es un sensor de C02 de origen sueco, es la opción ideal para el control de la ventilación interior y la supervisión del CO2 en aplicaciones residenciales.
Para el proyecto también podríamos haber empleado otros sensores del mercado, como el sensor MH-Z19 [17], un sensor muy extendido entre la comunidad de aficionados a la electrónica porque es relativamente barato, suficientemente preciso y hay muchos proyectos en internet basados en él. Pero nos hemos decantado por el Senseair, en primer lugar por su disponibilidad, al disponer de ellos en la universidad, y porque comparando sus características, teóricamente el senseair es mejor.
Son sensores muy similares pero podemos destacar un mayor tiempo de vida del sensor, una mejor precisión y un mayor rango de medida como se puede observar en la tabla 5 mostrada a continuación:
MH-Z19B Senseair S8
Precisión ±50 ppm y ±3% de la lectura ±40 ppm y ±3% de la lectura Corriente máxima 150 mA (suministro @ 5V) 300 mA
Rango de medición 400 ~ 2000 ppm 400 ~ 5000 ppm
400 ~ 2000 ppm 400 ~ 10000 ppm (en rango extendido)
Vida > 5 años > 15 años
Tiempo de respuesta
T90 < 120s 2 minutos para 90%
Humedad de funcionamiento
0 a 95% RH (sin condensación) 0 a 85% RH (sin condensación)
Figura 5. Tabla comparativa MH-Z19 y Senseair S8
En este tipo de sensores, la medición no se obtiene directamente, como puede ser el caso de un termómetro de mercurio, sino que se «deduce» de determinados «efectos». El sensor se basa en la moderna tecnología de infrarrojos (NDIR). En el caso de sensores como este, con tecnología NDIR, la medición consiste en cuantificar la dispersión que se produce en un haz de infrarrojos cuando atraviesa el aire que hay en su diminuta cámara de medición.
Además, esta medida es dependiente de la temperatura (y en menor medida la humedad) y de su correcta calibración. Por ello, estos sensores se auto calibran periódicamente para ajustar sus medidas, y es su firmware el que se ocupa de hacerlo. En “teoría” el firmware de calibración del senseair es mucho más inteligente/preciso que el de la competencia y está diseñado para una fácil integración, aunque en la práctica nos hemos encontrado numerosos problemas en relación a su calibración, que son compartidos por un gran número de usuarios en foros y que parecen estar relacionados con problemas de firmware que impedían realizar una correcta calibración. Para solucionar este problema hemos tenido que recurrir a emplear un segundo sensor Senseair S8.
En las siguientes imágenes se puede observar tanto el sensor Senseair S8 como su Disposición de los pines SenseAir S8.
Figura 6: SenseAir S8
Figura 7: Disposición de los pines SenseAir S8
2.1.4. SENSOR DE TEMPERATURA Y HUMEDAD DHT11
El DHT11 [18] presume de ser un sensor con una alta fiabilidad y estabilidad debido a su señal digital calibrada y de muy bajo precio. En nuestro caso hemos empleado la versión ya insertada en una PCB, esta versión tiene un pin menos que la versión sin PCB y una resistencia de 5KΩ integrada.
Al utilizar este sensor no debemos olvidar que aunque nos conectemos a un pin digital, este sensor es un sensor analógico en el cual se hace la conversión entre analógico y digital dentro del propio dispositivo, es decir partimos de una señal analógica que luego es convertida en formato digital y que se enviará al microcontrolador.
Figura 8: Disposición de los pines Sensor DHT11
2.1.5. PANTALLA AZ-DELIVERY ST 7735
Se trata de un módulo de pantalla TFT LCD de 1.77 pulgadas y 128x160 píxeles de resolución, equipado con chip controlador ST7735 y soporte de fuente de alimentación de 3.3 V [19]. Este módulo nos permitirá visualizar los datos obtenidos por los sensores sin la necesidad de tener un ordenador delante, gracias a la conexión por interfaz SPI con el ESP32. En la figura 9 se puede observar la disposición de los pines pantalla az-delivery ST 7735.
Figura 9: Disposición de los pines pantalla az-delivery ST 7735
2.2. SOFTWARE
2.2.1. ESP Home
ESP Home [10] es un firmware para ESP8266/ESP32 que soporta cientos de sensores y es configurable desde archivos de texto plano sencillos. Es la forma más rápida, fácil y versátil de crear un dispositivo de domótica inteligente y es capaz de conectarse nativamente a Home Assistant [5] usando un ESP32.
2.2.2. Home Assistant
Software de control de domótica con soporte para cientos de dispositivos y protocolos. Completamente de código abierto, se integra con prácticamente cualquier otra plataforma y servicio. En el proyecto usamos Home Assistant OS, una distribución Linux que simplifica su instalación y mantenimiento.
Mediante Home Assistant podemos realizar muchas acciones como realizar automatizaciones, controlar los dispositivos conectados y las zonas o áreas, y también nos permite añadir diferentes Add-ons mediante la Add-on store, tanto oficiales como realizados por la comunidad que pueden facilitarnos mucho el trabajo.
2.2.3. KUBERNETES
Actualmente en el servidor del FOSC utilizamos Kubernetes, una plataforma de contenedores, al igual que antes utilizabamos Docker.
¿Por qué usamos contenedores?
Los contenedores requieren menos recursos del sistema que los entornos de máquinas virtuales tradicionales porque no incluyen imágenes del sistema operativo.
Las aplicaciones que se ejecutan en contenedores se pueden poner en marcha fácilmente en sistemas operativos diferentes. Es decir, nos permite una ágil y fácil creación y despliegue de aplicaciones, lo cuál es muy importante en el FOSC.
Una prueba de su comodidad es que usando Helm el administrador de paquetes de Kubernetes pude desplegar Influxdb para este proyecto muy rápido y correctamente configurado sobre la arquitectura del servidor del FOSC.
2.2.4. INFLUXDB
InfluxDB [6] es una base de datos de series temporales construida desde cero para manejar altas cargas de escritura y consulta. InfluxDB está pensada para ser utilizada como almacén de respaldo para cualquier caso de uso que implique grandes cantidades de datos con marca de tiempo, incluida la monitorización de DevOps, las métricas de las aplicaciones, los datos de los sensores de IoT y los análisis en tiempo real.
En este proyecto se ha empleado InfluxDB 2.0, versión que proporciona una interfaz web cómoda y elegante para registrar, analizar y visualizar los datos recogidos por los sensores. Gracias a esto no ha sido necesario el uso de Grafana [28] ya que InfluxDB 2.0 ya nos proporcionaba la utilidad para la que habría sido empleado.
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN ESP32 CON ESPHOME
En este capítulo se va a realizar una completa explicación de la implementación de ESP HOME tanto a nivel hardware como software de cada uno de los componentes.
El primer paso va a ser realizar un prototipo Hardware. Para ello se ha tenido en cuenta toda la electrónica para el desarrollo del proyecto.
Posteriormente se procederá a describir toda la configuración software del ESP32, es decir, todos los pasos seguidos para que esta sea correcta y la programación del archivo de configuración (YAML) de ESPHOME.
3.1. IMPLEMENTACIÓN HARDWARE
De cara al prototipado Hardware se han empleado los siguientes componentes:
- Dos diodos led (Uno verde y uno rojo)
- Un sensor de temperatura y humedad DHT11 - Un sensor de CO2 Senseair S8
- Una pantalla AZ-DELIVERY ST7735 - Una Esp32 devkitc v4
- Un módulo de alimentación
En las siguientes imágenes se muestra el prototipo en diferentes fases, de acuerdo a diferentes pruebas que se han realizado durante el proceso de montaje con la intención de comprobar el correcto funcionamiento de cada componente.
Este proceso ha permitido comprobar distintos errores de montaje, relacionadas por ejemplo con las limitaciones de uso de ciertos pines del ESP32, y los fallos en la calibración del Senseair S8 que no se pudieron solucionar correctamente hasta el cambio por otro Senseair S8 distinto, a pesar de los numerosos intentos realizados con intención de solventarlo siguiendo tanto el datasheet oficial, como información recogida de distintos foros y páginas web.
- Prototipo con ESP32 y sensor de CO2 únicamente:
Figura 10. Montaje ESP32 y sensor de CO2
- Prototipo con ESP32 y sensor de DHT11 de temperatura y humedad únicamente:
Figura 11. Montaje ESP32 y sensor DHT11
- Montaje completo del prototipo, es decir montaje del ESP32 con los dos sensores y la pantalla
Figura 12. Vista cenital del prototipo
- Esquema del montaje del prototipo realizado con el programa fritzing[13]
Figura 14. Esquema del prototipo mediante Fritzing
Para que los esquemáticos y el diseño sean más entendible y replicable, las tabla 15-18 reflejan el conexionado realizado:
ESP32 PINs Senseair S8
5V G+
GND G-
GPIO 17
(UART TX 2) RX
GPIO 16
(UART RX 2) TX
Figura 15. Tabla conexionado ESP32 - Senseair S8
ESP32 PINs Pantalla ST7735 Power Supply Module
- PIN 8
(LED A) 3.3 V
GPIO 21 PIN 7
(CS) -
GPIO 5 PIN 6
(RS/CD) -
GPIO 22 PIN 5
(RESET) -
GPIO 23 (MOSI)
PIN 4
(SPI MISO) -
GPIO 18 PIN 3
(SPI SCK) -
5V PIN 2
(VCC) -
- PIN 1
(GND) GND
Figura 16. Tabla conexionado ESP32 - Pantalla ST7735
ESP32 PINs DHT 11
5V PIN 2
(CENTRO)
GND PIN 3
(DRCH)
GPIO 25 PIN 1
(IZQ)
Figura 17. Tabla conexionado ESP32 - DHT11
ESP32 PINs LEDS
GPIO 27 LED
VERDE
GPIO 14 LED
ROJO
Figura 18. Tabla conexionado ESP32 - Leds
3.2. IMPLEMENTACIÓN SOFTWARE
En este apartado se procederá a explicar todo el desarrollo software que se ha hecho para la realización de la parte de ESPHOME del proyecto.
Toda la programación y la configuración se ha realizado empleando Arch Linux, una distribución linux minimalista altamente actualizada, que permite al usuario total control del sistema. Este sistema operativo se ha utilizado para la mayoría de los programas, como VS Code, el IDE (entorno de desarrollo integrado) de programación, empleado en nuestro caso para el desarrollo del código de nuestro dispositivo ESP32 con ESP Home, su compilación y posterior "flasheo" en el microcontrolador.
3.2.1. PRUEBAS ENTORNO ESPHOME
Para hacer funcionar el ESP32 el primer paso ha sido familiarizarnos con el entorno y las diferentes keywords de ESP Home. Gracias a la alta cantidad de documentación que podemos encontrar en su web no ha sido un gran problema, Tan sólo resaltar pequeñas dificultades debidas a errores en nomenclatura, tabulaciones o por haber utilizado información errónea de alguna otra web o foro.
Para familiarizarnos, hemos comenzado por hacer diferentes pruebas con cada componente por separado, principalmente para comprobar su funcionamiento en primera instancia e interiorizar cómo funciona.
Ejemplos de pruebas realizadas en cada componente:
- Para la pantalla ST7735 probamos a dibujar cuadrados de diferentes colores para comprobar tanto que la pantalla funcionaba, como que el ESP32 se comunica adecuadamente con la misma.
En la prueba obtuvimos el siguiente resultado mostrado en la figura 19, utilizando el posterior código:
Figura 19. Resultado primera prueba pantalla ST7735
spi:
clk_pin: 18 mosi_pin: 23
display:
- platform: st7735
model: "INITR_18BLACKTAB"
reset_pin: 22 cs_pin: 21 dc_pin: 5 rotation: 90 device_width: 128 device_height: 160 col_start: 0
row_start: 0
eight_bit_color: true update_interval: 5s
lambda: |-
auto red = Color(255, 0, 0);
auto green = Color(0, 255, 0);
auto blue = Color(0, 0, 255);
auto white = Color(255, 255, 255);
it.rectangle(20, 50, 30, 30, white);
it.rectangle(25, 55, 30, 30, red);
it.rectangle(30, 60, 30, 30, green);
it.rectangle(35, 65, 30, 30, blue);
Figura 20. Código primera prueba ST7735
- Para el sensor DHT11, probamos a obtener valores del sensor y visualizarlos en el navegador. Como en este caso el resultado fue satisfactorio, el código de la prueba fue el empleado en el código final del prototipo.
En la prueba obtuvimos el siguiente resultado utilizando el posterior código:
sensor:
- platform: dht model: DHT11 pin: 25 temperature:
name: "Temperature"
id: temperature humidity:
name: "Humidity"
id: humidity
update_interval: 10s id: dht11
Figura 22. Código prueba sensor DHT11
- Por último, para el Senseair S8 realizamos numerosas pruebas en los intentos de calibrar el sensor. En estas pruebas, tras comprobar que el código era correcto al recibir datos del sensor, configuramos varios botones con distintos modos de calibración.
Empleamos el siguiente código para leer datos del sensor de C02 y junto con la configuración de los botones de calibración, obtuvimos el posterior resultado:
sensor:
- platform: senseair co2:
name: "SenseAir CO2 Value"
id: ppm
update_interval: 30s uart_id: co2
id: co2sensor
uart:
rx_pin: 16 tx_pin: 17 baud_rate: 9600 id: co2
Figura 23. Código prueba Sensor CO2 Senseair S8
Figura 24. Resultado prueba Senseair S8 y botones de calibración
3.2.2. IMPLEMENTACIÓN ESPHOME
Tras realizar todas las pruebas y conocer cómo funciona el entorno, procedimos a generar el código del prototipo empleado, que se explica de forma detallada a continuación.
- En el siguiente fragmento de código, primero definimos el nombre del dispositivo, el tipo de procesador empleado (esp32dev) y el framework empleado como base, y habilitamos el logger. Este último componente registra automáticamente todos los mensajes de registro a través del puerto serie.
esphome:
name: tfgmario
esp32:
board: esp32dev framework:
type: arduino
# Enable logging logger:
# level: VERBOSE
Figura 25. Código definición ESPHOME
- Activamos la API de conexión de Home Assistant. De esta forma permitimos que se conecte con Home Assistant. Esta conexión se realiza mediante un protocolo nativo basado en los búferes del protocolo TCP+, ya que usar MQTT para este cometido tiene algunos problemas, como que los usuarios tienen que instalar un broker MQTT para poder empezar, o su ineficiencia en este caso (un mensaje MQTT típico para enviar el estado de un sensor binario tiene una longitud de unos 70 bytes). El empleo de este protocolo no significa que MQTT no se utilice, esta API nativa sólo sirve para sustituir las comunicaciones con el Home Assistant por lo que también se pueden utilizar ambas cosas a la vez.
Comprobamos que se pueda actualizar ESPHome mediante OTA.
Figura 26. Opción actualización por OTA
Habilitamos el servidor web en el puerto 80 y el portal cautivo que se muestra en la siguiente imagen.
Figura 27. Portal cautivo ESPHOME
# Enable Home Assistant API api:
password: ""
ota:
password: ""
web_server:
port: 80
captive_portal:
Figura 28. Código implementación Home Assistant en ESPHOME
- Conectamos el ESP32 a una red wifi indicando su ssid y su contraseña, y definimos un AP alternativo para que, en caso de no estar disponible la red wifi especificada, el microcontrolador cree su propia wifi de reserva "Fallback Hotspot".
wifi:
ssid: "Noelia"
password: "badfibra"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Tfgmario Fallback Hotspot"
password: "RxxuFqMDymtX"
Figura 29. Código configuración WiFi ESPHOME
- Creamos un “text_sensor”, esto nos permite poder utilizar luego los datos de la información wifi del ESPHome. En nuestro caso obtendremos la IP que se le asigna al ESPHome en la red local y la mostramos por pantalla. Esto nos ha facilitado el trabajo cuando el prototipo cambiaba de red Wifi.
text_sensor:
- platform: wifi_info ip_address:
name: ESP IP Address id: ipaddr
ssid:
name: ESP Connected SSID
- Definimos las luces como binario, es decir, únicamente con dos estados (encendido y apagado) e indicamos un nombre, un id que podría ser utilizado posteriormente y un output, que como veremos a continuación, indica el pin en el que están conectadas.
light:
- platform: binary name: "Red Led"
output: light_red id: red
- platform: binary name: "Green Led"
output: light_green id: green
- platform: binary name: "Yellow Led"
output: light_yellow id: yellow
Figura 31. Definición luces
- Definimos las salidas de las luces, es decir, los pines en los que están conectados los leds, cada uno con la respectiva id que también hemos indicado en las "lights".
output:
- id: light_red platform: gpio pin: 14
- id: light_green platform: gpio pin: 27
- id: light_yellow platform: gpio pin: 12
Figura 32. Definición salidas de las luces
- Mientras que en la mayoría de los proyectos de visualización de Arduino tienes que usar una de las pocas fuentes predefinidas en tamaños muy específicos, con ESPHome tenemos opción de usar cualquier archivo de fuente TrueType (.ttf) en cualquier tamaño. De esta forma no hay que preocuparse por la licencia de los archivos de fuentes.
Para utilizar las fuentes, primero tenemos que definir un objeto de fuente (font) en el archivo de configuración de ESPHome. Para añadir fuentes se puede hacer de dos formas: se puede hacer, mediante un archivo .ttf en una ruta indicada o como en el caso de este proyecto, o como método alternativo, mediante la ruta abreviada de Google Fonts. Con este método nos ahorramos tener que descargarnos una fuente, simplemente indicamos la fuente en la URL y ya podemos utilizarla en la pantalla.
font:
- file: "gfonts://Roboto"
id: roboto size: 20
Figura 33. Definición fuente de texto
- Una entidad de botón se representa en ESPHome como un interruptor momentáneo sin estado. Éste puede activarse en el Home Assistant a través de la interfaz de usuario o de las automatizaciones.
A continuación hemos definido cinco botones con diferentes funciones, indicando un nombre, un id y la acción a realizar al pulsar el botón. En nuestro caso todos los botones están relacionados con la calibración del sensor de CO2.
En la figura 34 se muestra el código empleado para habilitar calibración abc del sensor de CO2:
button:
- platform: template
name: Enable abc Calibration id: enableabc
on_press:
then:
- senseair.abc_enable: co2sensor
Figura 34. Botón para habilitar calibración abc del sensor de CO2
En la figura 35 se muestra el código empleado para deshabilitar calibración abc del sensor de CO2. En la figura 36 se muestra el código empleado para obtener el tiempo que dura la calibración abc (180 horas). En la figura 37 se muestra el código empleado para forzar calibración a 400 ppm el valor actual del sensor de CO2. Por último, en la figura 38 se muestra el código empleado para obtener resultado y estado de la calibración, es decir, si ha sido satisfactoria.
- platform: template
name: Disable abc Calibration id: disableabc
on_press:
then:
- senseair.abc_disable: co2sensor
Figura 35. Botón para deshabilitar calibración abc del sensor de CO2
- platform: template
name: Get abc calibration interval id: getabcinterval
on_press:
then:
- senseair.abc_get_period: co2sensor
Figura 36. Botón obtención del intervalo de tiempo de calibración abc
- platform: template
name: Force Calibration id: forcecalibration on_press:
then:
- senseair.background_calibration: co2sensor Figura 37. Botón para forzar calibración
- platform: template
name: Get calibration result id: getcalibresult
on_press:
then:
- senseair.background_calibration_result: co2sensor Figura 38. Botón para obtener resultado calibración
- Definición de los sensores empleados en el proyecto.
El sensor de temperatura y humedad DHT11 es un sensor sencillo que no emplea ni UART ni I2C, la comunicación se realiza simplemente mediante un pin al que se conecta el bus de datos del DHT.
Para la definición del sensor indicamos, el modelo (DHT11), ya que la misma
"platform" se emplea para varios sensores distintos, el pin al que se conecta el bus de datos del DHT, el id del sensor, el intervalo de lectura (10s) y los nombres e id empleados para la temperatura y la humedad, el id de la temperatura y la humedad los empleamos luego para mostrar estos datos por pantalla.
sensor:
- platform: dht model: DHT11 pin: 25 temperature:
name: "Temperature"
id: temperature humidity:
name: "Humidity"
id: humidity
update_interval: 10s id: dht11
Figura 39. Definición sensor DHT11
Empleamos la "platform" senseair, lo cual nos permite usar en principio cualquier sensor Senseair.
Para la definición del sensor de CO2 hemos indicado un nombre, un id que empleamos para mostrar en pantalla (ppm), el intervalo de lectura (30s), el id que empleamos para los botones (co2sensor) y el id de la UART que emplea para comunicarse con el ESP32.
- platform: senseair co2:
name: "SenseAir CO2 Value"
id: ppm
update_interval: 30s uart_id: co2
id: co2sensor
Como la comunicación con el SenseAir se hace usando UART, necesitamos tener un bus UART en la configuración con el rx_pin conectado al pin TX del sensor y el tx_pin conectado al pin RX (se cambia porque las etiquetas TX/RX son desde la perspectiva del sensor SenseAir) y también necesitamos establecer la tasa de baudios a 9600.
uart:
rx_pin: 16 tx_pin: 17 baud_rate: 9600 id: co2
Figura 41. Definición UART sensor de CO2
- Por último, queda por definir la pantalla; para la comunicación con la pantalla utilizamos el Bus SPI, indicando el pin de reloj y el pin MOSI (Master Output Slave Input)
spi:
clk_pin: 18 mosi_pin: 23
Figura 42. Definición SPI pantalla
Tras definir los datos para la comunicación SPI procedemos a definir la configuración de la pantalla. Para esto indicamos el conexionado entre la pantalla y el ESP32, el tamaño de la pantalla y los offsets de filas y columnas, y por último, mediante un "lambda", empleando código C++ indicamos qué mostrar por pantalla, especificando offsets, fuente a emplear, el texto y el que mostrar indicando la id.
Figura 43. Estructura escritura texto por pantalla ST7735
display:
- platform: st7735
model: "INITR_18BLACKTAB"
reset_pin: 22 cs_pin: 21 dc_pin: 5 rotation: 90 device_width: 128 device_height: 160 col_start: 0
row_start: 0
eight_bit_color: true update_interval: 10s
lambda: |-
it.printf(0, 0, id(roboto), "Hum: %.1f%%", id(humidity).state);
it.printf(0, 20, id(roboto), "Temp: %.1f°%", id(temperature).state);
it.printf(0, 40, id(roboto), "CO2: %.1f%", id(ppm).state);
std::string val = id(ipaddr).state;
it.printf(0, 80, id(roboto), "IP: %s", val.c_str());
Figura 44. Definición pantalla ST7735
CAPÍTULO 4. IMPLEMENTACIÓN HOME ASSISTANT
En este capítulo vamos a explicar cómo hemos realizado la instalación del Home Assistant, su configuración paso a paso y sus posibilidades.
4.1. MÉTODOS DE INSTALACIÓN DE HOME ASSISTANT
Para obtener un Home Assistant funcional tenemos cuatro métodos distintos que describiremos en los cuatro subapartados siguientes.
4.1.1 Home Assistant OS
Esta primera opción consiste en emplear un Sistema Operativo completo preconfigurado basado en Debian, disponible tanto para PCs como para varios sistemas ARM entre las cuales se incluye la familia de Raspberry Pi.
Es la opción más popular, capacitada y sencilla de gestionar. Goza de total soporte por parte de los desarrolladores de Home Assistant y es la que recomiendan para cualquier caso de uso.
4.1.2 Home Assistant Supervised
Si no queremos instalar el SO completo, o si queremos partir de un equipo que ya tiene un SO, entonces la opción es instalar Supervisor, un software que gestiona Home Assistant OS sobre otro sistema operativo que no sea Home Assistant OS.
Esto nos da una experiencia de uso muy similar, con la excepción de que seríamos responsables de mantener el sistema operativo base razonablemente actualizado y compatible con lo que espera Supervisor.
Esta forma de obtener Home Assistant está expresamente no recomendada por los desarrolladores de Home Assistant. La lista de requisitos para no experimentar problemas es larga y no es la opción que normalmente escoja un usuario final.
Sin embargo, ésta opción es interesante para dispositivos embebidos que no disponen de una imagen oficial de Home Assistant OS, pero sí de una distribución Linux basada en Debian.
4.1.3 Home Assistant Container
Un enfoque diferente pasa por emplear containers. En este caso, un container estándar que permita el uso de Home Assistant en cualquier ordenador capaz de ejecutar containers, típicamente con Docker aunque alguna gente lo ejecuta sobre Kubernetes.
Esta opción tiene alguna ventaja, pero como contrapartida, perdemos una feature que es la Addon Store.
En Home Assistant OS u otra instalación con Supervisor, disponemos de una store de programas externos a Home Assistant para instalar en nuestro dispositivo.
Hay una gran variedad, pero un ejemplo popular es el software de VPN OpenVPN.
Cada Addon tendría asociado un container que Supervisor gestionaría de forma transparente al usuario.
Ya que en este tipo de instalación no hay Supervisor, el usuario final es el responsable de ejecutar otros containers o software si desea añadir funcionalidad fuera de Home Assistant.
4.1.4 Home Assistant Core
Como última opción, se podría hacer una instalación con Python. Si lo deseamos es posible instalar Home Assistant con pip, el gestor de paquetes de Python. Todos los aspectos de instalación del software se realizan de forma manual y externa. Los requisitos del sistema operativo base siguen en pie y la compatibilidad con numerosas integraciones tiene muchas probabilidades de no funcionar.
En resumidas cuentas, no es una opción real.
4.2. INSTALACIÓN HOME ASSISTANT
Como se puede deducir tras revisar las cuatro opciones de instalación, para obtener una experiencia de uso completa de Home Assistant con la menor fricción y errores posibles, es necesario el uso de Home Assistant OS.
En este caso, como todo el proceso se ha realizado en Arch Linux, no hemos usado el programa que se indica en la guía de Home Assistant, la cual sí habríamos seguido en caso
Para su instalación, descargamos la imagen para Raspberry Pi y la flasheamos a una tarjeta SD. Para este proceso, usamos la funcionalidad de escritura de imágenes de disco de Gnome Disks. Las imágenes 45 y 46 muestran parte del proceso de instalación.
Figura 45. Imagen de instalación de Home Assistant
Figura 46. Instalación Home Assistant
Una vez instalado, se introduce la tarjeta SD en la raspberry y se inicia.
Una vez creada la imagen, se inserta en la Raspberry Pi, se conecta a una red Local (por cable, aún no tiene configurada una red Wifi).
Ahora tendremos que acceder por red a ese equipo. Si no conocemos la dirección IP que le ha asignado el router, una forma sencilla de averiguar su IP es a través de NMAP [29].
Esta herramienta está disponible para diversos SO (Linux y Windows como mínimo). Puede presentar una aplicación gráfica, pero en Linux es mucho más sencillo lanzarla desde un terminal, simplemente ejecutando el siguiente comando (eso sí, necesitamos conocer la dirección de red):
sudo nmap -T4 -p 8123 10.0.0.0/24
Una vez encontrada la IP, accedemos desde el navegador a Home Assistant, con el detalle de especificar el puerto no estándar en el que escucha el servidor web (8123 en este caso).
https://10.0.0.100:8123
Sería conveniente que esa IP fuera permanente, por lo que se fijó esta IP para que no cambiara en el panel de configuración del router.
Debido a la infinidad de sistemas operativos de router disponibles es imposible dar una guía paso a paso efectiva, en este caso se ha empleado el panel de configuración de un router marca Zyxel, router proporcionado por el operador DIGI. En otras circunstancias se podría haber empleado un router "flasheado" OpenWRT firmware de código libre basado en una distribución de Linux instalable en dispositivos tales como routers personales. En cualquier caso, la operación es similar: asignar a la MAC de la interfaz de red de la Raspberry una dirección IP estática, tal y como se muestra en la figura 47.
Figura 47. IP Fija Home Assistant
4.3. Overview Home Assistant
Cuando ya tenemos el Home Assistant instalado y en una IP definida, podemos proceder con la integración de ESPHome y Home Assistant. Para ello vamos a Settings/Devices & Services, seleccionamos añadir una integración y buscamos ESPHome. Al añadir nuestro ESPHome obtenemos una Overview automática con todo lo definido en Home Assistant, pero hemos modificado esta vista eliminando las luces led, ya que no serán modificables por el usuario dado que su cometido será únicamente una señal luminosa para alarmas (ver figura 48).
Figura 48. Overview default Home Assistant
Para una mejor visualización de los datos se ha creado una vista "custom", que se puede apreciar en la figura 49.
Figura 49. Vista personalizada Home Assistant
También se han añadido tres automatizaciones para activar los leds según el nivel de CO2 del ambiente. La figura 50 muestra una captura de pantalla de estas tareas, y la 51 un ejemplo de codificación de una de ellas.
- Luz verde encendida si estamos por debajo de 1000 ppm - Luz amarilla encendida si estamos entre 1000 ppm y 2000 ppm - Luz roja encendida si estamos por encima de 2000 ppm
Figura 50. Alarmas nivel CO2 Home Assistant
id: '1655925581720' alias: CO2 2K Alert description: '' trigger:
- type: carbon_dioxide platform: device
device_id: 2be9fceb4974be914054bfa088780e72 entity_id: sensor.senseair_co2_value
domain: sensor above: 2000 below: 10000 condition: []
action:
- type: turn_on
device_id: 2be9fceb4974be914054bfa088780e72 entity_id: light.red_led
domain: light - type: turn_off
device_id: 2be9fceb4974be914054bfa088780e72 entity_id: light.yellow_led
domain: light - type: turn_off
device_id: 2be9fceb4974be914054bfa088780e72 entity_id: light.green_led
domain: light mode: single
Figura 51. Ejemplo alarma 2K CO2
4.4. Acceso desde internet a Home Assistant
Es conveniente tener acceso a la instancia de Home Assistant desde cualquier lugar del mundo, para llegar a esto necesitamos configurar varios componentes, que se describirán a continuación.
4.4.1 Compra de un dominio y su configuración
En primer lugar, sería conveniente disponer de un dominio.
Actualmente existen diferentes alternativas para esto, y las opciones cambian constantemente. En en caso de este trabajo no ha sido necesario adquirir un dominio dado que se ha utilizado el dominio que ya posee el FOSC.
A partir de ese dominio, se apunta un subdominio a la IP pública del router del sitio donde está la Raspberry Pi. Para esto se crea un nuevo A record, como se muestra en la imagen 52. Podemos utilizar una característica extremadamente interesante de CloudFlare [20] que es su servicio de Proxy, tal y como se ve en la imagen.
Figura 52. A record en Cloudflare
Al estar activado, este registro de DNS en realidad no apunta a la IP elegida, en su lugar nos lleva a un servidor de CloudFlare cercano. En la figura 53 se puede apreciar el resultado de la petición de la IP del subdominio de este trabajo.
mario@t440 ~ % dig mario-ha.fosc.space
; <<>> DiG 9.18.4 <<>> mario-ha.fosc.space
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22871
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mario-ha.fosc.space. IN A
;; ANSWER SECTION:
mario-ha.fosc.space. 300 IN A 188.114.96.5 mario-ha.fosc.space. 300 IN A 188.114.97.5
;; Query time: 16 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Jun 29 18:29:06 CEST 2022
;; MSG SIZE rcvd: 80
Figura 53 . Petición DNS al subdominio
La dirección a usar para acceder al Home Assistant desde el exterior es:
https://mario-ha.fosc.space/
Esto nos da múltiples beneficios. En primer lugar, la conexión entre el navegador y los servidores de Cloudflare se realiza de forma segura con los últimos estándares de encriptación y la IP real del lugar donde está la Raspberry Pi no se puede averiguar. También nos protege de posibles ataques DDoS y nos permite filtrar países desde los cuales se permite el acceso.
Como Home Assistant escucha en un puerto sin seguridad de ningún tipo, es necesario configurar el modo de operación de Cloudflare para que la conexión entre los dos vaya sin encriptar (ver figura 54).
Figura 54. Modo de encriptación SSL en Cloudflare
De esta forma se dice que Cloudflare nos da un servicio de Reverse Proxy que hace de SSL Terminator.
Esto es especialmente importante hoy en día, dado que los navegadores cada vez están poniendo más dificultades para la visualización de contenido sin encriptar. Además, es necesario para poder establecer una comunicación entre Google Assistant y Home Assistant.
Una opción alternativa hubiera sido configurar Let's Encrypt para que el propio servidor web de Home Assistant escuchara en un puerto seguro y ofreciera un certificado válido. Sin embargo, esto es más laborioso especialmente en Home Assistant OS.
4.4.2 Configuración de forwarding de puertos
También conocido coloquialmente como "abrir puertos".
Redirigimos el puerto 80 del router en su interfaz de WAN hacia el puerto 8123 de la Raspberry Pi. De esta forma, al entrar desde WAN a la IP externa del router por el puerto estándar HTTP (80), tendremos una comunicación transparente con Home Assistant (que escucha en la IP de la red LAN interna, en el puerto 80).
4.4.3 Permitir acceso desde fuera de la red local a Home Assistant
Se instala la extensión "Studio Code Server" para editar fácilmente el archivo de configuración de nuestra instancia de Home Assistant.
Esto nos permite abrir "Visual Studio Code" en su versión completamente open source dentro de la web de Home Assistant y editar cualquier archivo de configuración.
Existen otras formas de hacer esto, como activar el SSH y entrar con un editor como vi o nano, montar el sistema de archivos con SSHFS pero son más incómodos para realizar labores de edición de texto avanzadas.
La modificación que permite que funcione el acceso desde Cloudflare involucra añadir los rangos de IP de su propiedad a la lista de IPs con acceso permitido.
http:
use_x_forwarded_for: true trusted_proxies:
- 173.245.48.0/20 - 103.21.244.0/22 - 103.22.200.0/22 - 103.31.4.0/22 - 141.101.64.0/18 - 108.162.192.0/18 - 190.93.240.0/20 - 188.114.96.0/20 - 197.234.240.0/22 - 198.41.128.0/17 - 162.158.0.0/15 - 104.16.0.0/13 - 104.24.0.0/14 - 172.64.0.0/13 - 131.0.72.0/22
Figura 55. Rangos de IP de Cloudflare en configuración Home Assistant
4.5. Comunicación Google Home y Home Assistant
El Home Assistant ahora es accesible desde fuera de la red local, desde cualquier lugar del mundo y con certificado SSL, por lo que podemos sincronizarlo con Google Assistant. Esto permite controlar cosas a través del asistente de Google en el móvil, la tableta o el dispositivo Google Home. La integración de los dos asistentes se podía haber realizado de dos formas, mediante Home Assistant Cloud o mediante configuración manual [21].
4.5.1. Home Assistant Cloud
Con Home Assistant Cloud, se puede conectar la instancia de Home Assistant con unos simples clics a Google Assistant, no se tiene que lidiar con DNS dinámicos, certificados SSL o abrir puertos en tu router. Solo se tiene que iniciar sesión a través de la interfaz de usuario y se establecerá una conexión segura con la nube, pero esto requiere una subscripción de pago mensual y por ello se ha realizado manualmente.
4.5.2. Configuración manual
La integración de Google Home sin Home Assistant Cloud requiere un poco más de configuración que la mayoría debido a la forma en que Google requiere la configuración de Assistant Apps.
1. Para empezar, se crea un proyecto nuevo y, como estamos configurando la conexión con Home Assistant, se selecciona la tarjeta Smart Home.
2. En la sección de Quick Setup se introduce un nombre.
3. Seleccionamos Build your Action y procedemos a añadir una acción.
Introducimos el webhook utilizado. Los webhooks son herramientas para que las diferentes aplicaciones puedan comunicarse entre sí.Ver figura 56.
Figura 56. Webhook Google Assistant
4. Copiamos el Project-Id de Project Settings.
5. Volvemos a la sección de Quick Setup de la página Overview y ahora procedemos a hacer la vinculación de cuentas (Setup account linking).
Ver figura 57.
Figura 57. Setup account linking Google Cloud Platform
6. Habilitamos la sincronización de dispositivos (Device sync) para no tener que introducir a mano en el YAML de la configuración de Home Assistant todos los dispositivos que queremos que se sincronicen sin tener que introducirlos uno a uno.
En Google Cloud Platform seleccionamos el proyecto y seleccionamos APIs & Services/Credentials y creamos unas nuevas credenciales de tipo Service Account. Ver figura 58.
Figura 58. Nuevas credenciales Service Account
Descargamos el JSON y procedemos a editar el YAML de configuración de Home Assistant de nuevo, tal y como se muestra en la figura 5.
google_assistant:
project_id: tfgmario-b4f32
service_account: !include service_account.json report_state: true
Figura 59. Google Assistant en configuración Home Assistant
4.5.3. Conclusión y problemas encontrados
Tras realizar todo el proceso descrito, la conexión entre Home Assistant y Google Home funciona correctamente, algo que demuestra que la configuración se ha realizado satisfactoriamente. Sin embargo, se ha encontrado un problema o bug muy importante a la hora de trabajar con sensores y Google Home.
Google Home no puede leer adecuadamente los valores obtenidos por los sensores, aunque sí es capaz de obtener información simple como puede ser el nombre, esto lo podemos ver en las figuras 60 y 61. Esto ocurre porque Google no tiene un tipo de dispositivo doméstico inteligente [30]
correspondiente para leer datos de sensores de esta forma.
Figura 60. Sensores en Google Home
Figura 61. No Información humedad en Google Home
Buscando el error en internet encontramos referencias de otros usuarios y programadores a los que le ocurre lo mismo [22]. Una posible solución sería usar un "falso'' termostato, similar al del código mostrado en la figura 62, para obtener datos de la temperatura y de la humedad.
Desafortunadamente, hasta la fecha, no hemos dado con una opción para solucionar el problema en el sensor de CO2 ya que no hay ningún tipo de dispositivo inteligente reconocido por Google trabaje con datos de CO2 de esta forma.
- platform: generic_thermostat name: Temperatura Balcone
heater: input_boolean.fake_heater
target_sensor: sensor.temperature_158d0001b95f60 initial_operation_mode: "off"
target_temp: 21
Figura 62. Posible solución problema humedad y temperatura en Google Home
CAPÍTULO 5. KUBERNETES E INFLUXDB
El FOSC ofrece un servicio de Kubernetes managed a sus miembros. Usamos este servicio para desplegar una instancia de InfluxDB, utilizamos la versión dos de InfluxDB porque nos permite visualizar la información de forma muy cómoda y trabajar con la misma creando nuestro "dashboard" sin necesidad de emplear Grafana (herramienta de código abierto para el análisis y visualización de métricas, esta se utiliza frecuentemente para visualizar de una forma elegante series de datos en el análisis de infraestructuras y aplicaciones).
InfluxData, la compañía padre de InfluxDB ha hecho el trabajo necesario para desplegar su software en Kubernetes a través de Helm (administrador de paquetes para Kubernetes). Helm nos abstrae de las complejidades internas de Kubernetes y simplemente establecemos valores de configuración que modifican los que hay por defecto.
helm3 upgrade --namespace tfgmario --install influxdb
influxdata/influxdb2 --set persistence.storageClass=local-path
Figura 63. Instalación InfluxDB en el FOSC
A través de este comando instalamos InfluxDB al namespace "tfgmario" para que esté aislado del resto de software que se ejecuta en el cluster del FOSC.
La única propiedad establecida es el "storageClass" que le dice a Kubernetes que queremos almacenar los archivos de InfluxDB a través del proveedor llamado "local-path".
Esto los guarda en el almacenamiento del servidor principal para fácil acceso y permite que persistan en el tiempo a eventos que causen el reinicio del programa.
Para acceder a InfluxDB en sí mismo es necesario un Ingress (un tipo de balanceador de carga especializado para la plataforma, así como otros entornos relacionados con contenedores) para que las peticiones HTTP al servidor dirigidas a un subdominio de nuestra elección sean encaminadas hacia su correspondiente contenedor.
Debido a que el FOSC usa Traefik [23] como ingress, usamos la api customizada de Traefik, IngressRoute, en vez del Ingress genérico de Kubernetes.
apiVersion: traefik.containo.us/v1alpha1 kind: IngressRoute
metadata:
name: netdata
namespace: tfgmario spec:
entryPoints:
- websecure routes:
- match: Host(`tfgmario.fosc.space`) kind: Rule
services:
- name: influxdb-influxdb2 port: 80
Figura 64. IngressRoute Kubernetes
Con esto ya podemos acceder a la web de nuestra instancia de InfluxDB y comunicarnos con su API para subirle datos.
Para iniciar sesión se han creado dos usuarios, el admin o propietario o un invitado cuyos datos de inicio de sesión son:
Usuario: guest
Contraseña: guestguest
Dentro del InfluxDB aparece un Dashboard usando la interfaz gráfica de la web con intención de crear unas queries para obtener los datos que queremos de los almacenados en la base de datos del Influx y mostrarlos en gráficas de forma muy visual.
CAPÍTULO 6. CONCLUSIONES Y TRABAJOS FUTUROS
6.1. CONCLUSIONES
En este proyecto se han obtenido varias conclusiones, tanto relacionadas con el ESP32, como con medidas tomadas por los sensores que se han estado visualizando durante todo el tiempo que ha durado el desarrollo del proyecto.
La primera conclusión es la versatilidad del microcontrolador ESP32, con el cual se puede conseguir realizar casi cualquier proyecto de IOT. Una ventaja adicional es la enorme cantidad de proyectos que los emplean, algo que permite encontrar gran cantidad de información en internet bastante útil para aprender a usarlos y programarlos. Esto los convierte en una de las mejores opciones en comparación a la competencia, un claro ejemplo de estas ventajas es la propia existencia de ESPHOME.
Durante el desarrollo del proyecto, observando los datos obtenidos por los sensores, se ha llegado a dos principales conclusiones. La primera, tras medir el nivel de CO2 en una estancia vacía con todas las ventanas abiertas durante largos periodos de tiempo obteniendo un valor medio de 950 ppm y teniendo en cuenta que la concentración media de CO2 al aire libre oscila sobre los 420 ppm (parts per million) y 700 ppm en las ciudades, Cartagena presenta una alta concentración de CO2. Y la segunda y quizá más importante, tras medir el aumento del nivel de CO2 y la velocidad de este en una estancia cerrada con cuatro personas y con aire acondicionado encendido (Figura 67), se ha observado que el CO2 aumenta a gran velocidad y hasta cifras bastante elevadas como se puede observar en la Figura 66. Esto podría ser perjudicial para la salud sostenido en el tiempo y es algo de lo que la gente no tiene constancia y debería ser tenido en cuenta y considerado en cada casa y empresa, ya que unos altos niveles de CO2 pueden afectar en gran medida a la capacidad de concentración y al rendimiento.
Figura 66. Tramos niveles CO2
Figura 67. Nivel de CO2 muy elevado
En lo relativo a la temperatura y la humedad, también se ha investigado esta relación, ya que es importante tenerla en cuenta: siempre que se mida la temperatura se debe tener en cuenta la humedad y viceversa. Como se puede ver en la siguiente gráfica (Figura 68), a ciertas relaciones de temperatura y humedad puede haber grave peligro para la vida.
Figura 68. Peligro relación temperatura y humedad
Para medir esta relación y su peligrosidad se emplea la "wet-bulb temperature" (WBT) [24], la temperatura leída por un termómetro cubierto con un paño empapado de agua (agua a temperatura ambiente) sobre el que pasa el aire.
Los organismos vivos sólo pueden sobrevivir dentro de un determinado rango de temperatura. Cuando la temperatura ambiente es excesiva, muchos animales se enfrían por debajo de la temperatura ambiente mediante el enfriamiento por evaporación [25] (sudor en humanos y caballos, saliva y agua en perros y otros mamíferos); esto ayuda a prevenir la hipertermia potencialmente mortal debida al estrés térmico. La eficacia del enfriamiento por evaporación depende de la humedad; la "wet-bulb temperature", o cantidades calculadas más complejas como la "wet-bulb globe temperature" (WBGT), que también tiene en cuenta la radiación solar, dan una indicación útil del grado de estrés térmico [26], y son utilizadas por varios organismos como base para las directrices de prevención del estrés térmico.
Una "wet-bulb temperature" sostenida que supere los 35 °C puede ser mortal incluso para personas sanas y en forma, sin ropa, a la sombra junto a un ventilador; a esta temperatura, el cuerpo humano pasa de ceder calor al entorno a obtenerlo. En la práctica, no siempre se dan estas condiciones ideales para que los seres humanos se refresquen, de ahí los altos niveles de mortalidad en las olas de calor europeas de 2003 [27] y rusas de 2010, en las que las temperaturas de bulbo húmedo no superaron los 28 °C.
Figura 69. Días al año con "wet-bulb temperature" por encima de 32°C
Por último, en el coste económico asociado todo el prototipo no ha sido realmente excesivo, el producto de mayor coste ha sido el sensor de C02, que implica el 50%
aproximadamente (40€), ya que se optó por emplear un sensor de calidad, que midiese realmente la concentración de este gas en el aire.
Si se compran los componentes en Europa el precio sería aproximadamente de 80€, siendo unos 40€ el sensor de CO2, 3€ el sensor de temperatura y humedad, 10€ la pantalla y 10€ el ESP32. Aunque si se recurre a la importación de China el precio total rondaría la mitad.
6.2. TRABAJOS FUTUROS
Este proyecto puede seguir siendo desarrollado, y se tiene la intención de hacerlo, siguiendo las siguientes dos líneas principales que se exponen a continuación. Sería posible incluir más líneas, pero nos centraremos en estas dos dado que son de aplicación casi inmediata, y necesaria para tener un producto de mayor calidad.
- 1. Emplear una Pi Pico W en lugar de un ESP32. La fundación Raspberry provee un producto que tiene años de producción y/o soporte, con un desarrollo profesional detrás, más estable, con una pcb de mayor calidad, más potente y con una memoria flash de mayor capacidad. Su coste es prácticamente el mismo o inferior al del ESP32, aproximadamente de 6$ y también han portado soporte a ESPHOME.
- 2. Otro punto por el que se seguirá trabajando y en el que hay cierto interés, es en perfeccionar el diseño para poder utilizarlo en la vida cotidiana en una estancia. Para esto es necesario diseñar una PCB y producirla para poder tener todo de forma compacta y sin cables, así como diseñar una carcasa que se adapte a las necesidades del prototipo e imprimirla en 3D teniendo un producto más profesional y avanzado que el prototipo actual.
Ambas líneas probablemente sean seguidas de forma simultánea, es decir, emplear una Pi Pico W y posteriormente seguir la línea 2. pero empleando una Pi Pico W en lugar de un ESP32.
