Texto completo
|
PDF (Portable Document Format)
- Se necesita un visor de ficheros PDF, como GSview, Xpdf o Adobe Acrobat Reader
Descargar (2MB) |
| Título: | Diseño y desarrollo de un sistema de gestión domótica multi-ubicación |
|---|---|
| Autor/es: |
|
| Director/es: |
|
| Tipo de Documento: | Trabajo Fin de Grado o Proyecto Fin de Carrera |
| Grado: | Grado en Ingeniería en Tecnologías Industriales |
| Fecha: | Septiembre 2024 |
| Materias: | |
| ODS: | |
| Palabras Clave Informales: | Domótica, IoT, Sensores, Zigbee, MQTT, Bases de datos, HTML, HTMX, FastAPI, Contenedores, Docker, SQLModel, Paho, Zigbee2MQTT, Sistema Domótico |
| Escuela: | E.T.S.I. Industriales (UPM) |
| Departamento: | Automática, Ingeniería Eléctrica y Electrónica e Informática Industrial |
| Licencias Creative Commons: | Reconocimiento - Sin obra derivada - No comercial |
|
PDF (Portable Document Format)
- Se necesita un visor de ficheros PDF, como GSview, Xpdf o Adobe Acrobat Reader
Descargar (2MB) |
La industria 4.0 lleva años en constante desarrollo, siendo uno de sus componentes fundamentales el “Internet of Things” o IoT. El desarrollo de tecnologías IoT como las redes de comunicación 5G, la computación en la nube o los avances en cuanto a protocolos de comunicación, no solo han servido como base de la innovación en la industria, sino que también han tenido un gran impacto en otros ámbitos como, por ejemplo, la domótica, abriendo en ellos un gran abanico de nuevas posibilidades de innovación.
Los sistemas domóticos profesionales ofrecen actualmente un servicio básico, a un coste elevado a través de cuotas mensuales. Por ello se han ido desarrollando distintos sistemas domóticos de libre uso, que permiten al usuario final crear su propio sistema con un coste muy inferior.
Algunos de estos nuevos sistemas de libre uso se han implementado utilizando tecnologías de comunicación inalámbricas, mediante protocolos de comunicación como Zigbee o Z-Wave. Otros han implementado servicios de almacenamiento de datos en la nube, permitiendo la gestión de estos sistemas desde cualquier lugar. Sin embargo, es difícil encontrar sistemas que hayan implementado las mejores prácticas de las distintas tecnologías del IoT en su conjunto.
En este contexto, surge la idea de desarrollar este proyecto, a partir de la motivación personal del autor, por crear su propio sistema domótico. El objetivo de este proyecto es, por tanto, la creación de un sistema domótico, con prestaciones técnicas similares a uno profesional, manteniendo el enfoque de minimizar el coste para el usuario final e implementando todas las ventajas de los desarrollos tecnológicos en el área de la domótica y la informática.
De esta forma, el objetivo principal del proyecto se puede concretar en:
Creación de un sistema de gestión domótica, multi-ubicación, con capacidad remota de gestión, intuitivo, personalizable, optimizado en el coste por usuario, con alta capacidad de escalar, de uso masivo y de arquitectura hardware fácilmente migrable, si el crecimiento lo requiriera.
Este objetivo incluye la creación de un sistema extremo a extremo, de uso masivo, que permita a cada usuario instalar, gestionar y personalizar sistemas de gestión domótica en múltiples ubicaciones, desde una única aplicación final, de manera remota. Todo ello, manteniendo la búsqueda de un coste mínimo por usuario.
Para alcanzar este objetivo, en primer lugar, se analizaron los protocolos de comunicación existentes relacionados con los sensores domóticos. De entre aquellos válidos, se ha seleccionado Zigbee por su razonable alcance, arquitectura de redes malladas, su bajo consumo y la gran variedad de dispositivos disponibles.
Una vez decidido el protocolo de comunicación, se realiza un diseño conceptual del sistema sobre el que realizar el posterior análisis y desarrollo.
En el diseño a alto nivel, se identifican un conjunto de ubicaciones. En cada ubicación del sistema se considera que existen múltiples sensores, así como un “Homehub” o consola de control del sistema, la cual se comunica con el gestor domótico (que es el núcleo del proyecto) y éste con el usuario final a través de una interfaz web HTML.
Una vez conocido el esquema básico del sistema, se realizan las fases de análisis y diseño. En ellas se definen los requisitos funcionales y no funcionales, y la labor de cada uno de los componentes del sistema. A continuación, se desarrollan con más detalle aquellos componentes más relevantes.Empezando por la descripción de las piezas más sencillas, los sensores se comunican con el Homehub a través del protocolo de comunicación Zigbee. Para evitar la complejidad de gestionar cada sensor a través de dicho protocolo, se implementa en el Homehub la librería de Python “Zigbee2MQTT”. Esta librería traduce los mensajes de los sensores al protocolo MQTT, el cual es ideal para la comunicación entre el Homehub y el gestor domótico, ya que permite la comunicación asíncrona mediante un sistema de colas de mensajería.
Por tanto, la labor del Homehub es gestionar los sensores de su ubicación, recibir y enviar mensajes en protocolo Zigbee del lado de los sensores, recibir y enviar mensajes en protocolo MQTT del lado del gestor domótico y ser capaz de traducir de un protocolo al otro. Para analizar las funciones que debe realizar el gestor domótico, se realiza un diseño de bajo nivel de cada uno de sus componentes. De esta forma, se identifican qué funciones debe realizar cada uno y cómo se gestionan las conexiones entre ellos.
En este diseño de bajo nivel, el gestor domótico está compuesto por 4 servicios. El primero de ellos, el servicio de mensajería, se encarga de permitir la comunicación con los Homehubs. Por ello, su función es implementar la parte servidor del protocolo estándar MQTT. De esta forma se convierte en un “broker” o intermediario de mensajería, que permite la comunicación a través de sus canales, a los distintos clientes MQTT que se conecten a él.
El servicio de escucha o “Listener”, se encarga de recibir mensajes MQTT en relación con los Homehubs. Por ello, su función principal es la implementación de la parte cliente del protocolo MQTT.
Cada vez que el servicio de escucha recibe un mensaje, se comunica con la base de datos para guardar la información relevante y llama a una función del servidor de aplicaciones para comprobar si debe realizarse alguna acción adicional.
El servicio de almacenamiento de datos debe ser capaz de almacenar y gestionar todos los datos necesarios para el sistema y permitir sesiones de lectura y escritura de datos a los demás servicios del sistema.
El servicio se compone de una base de datos SQL, gestionada mediante PostgreSQL, en la que se ha implementado un modelo de datos adaptado a las necesidades del proyecto.
El modelo de datos está formado principalmente por las clases: usuarios, ubicaciones, sensores y eventos.
Cada usuario tiene asociados, en un primer nivel , una serie de ubicaciones. Estas ubicaciones a su vez están vinculadas, en un segundo nivel, a una serie de sensores. Por otro lado, cada usuario también tiene asociados en el primer nivel una serie de eventos.
De entre estas clases, destacan: “Sensores” y “Eventos”.
En primer lugar, “Sensores” se ha estructurado a través de una tabla de tipos de sensor y otra tabla de campos de cada tipo. Esto permite incorporar al sistema cualquier sensor, independientemente del número de campos o tipología de los mismos, sin necesidad de realizar ningún cambio en el modelo de datos.
Por su parte, el campo “Eventos”, surge de la agrupación de una serie de condiciones y acciones. La introducción de eventos al sistema permite a los usuarios definir bajo qué circunstancias quieren que el sistema realice automáticamente alguna acción y, de esta forma, gestionar de manera automática y personalizada su conjunto de ubicaciones.
Por último, el servidor de aplicaciones-web es el núcleo central del gestor domótico y de este proyecto. En él se encuentra toda la lógica necesaria para su funcionamiento. Su función principal es la creación y gestión de un servidor de aplicaciones-web.
Este servicio debe ser capaz de gestionar la creación, lectura, actualización y borrado (CRUD) de usuarios, ubicaciones, sensores y eventos. El envío de los mensajes MQTT necesarios para la gestión de los sensores también forma parte de este servicio. Además, también es el encargado de la generación y envío de páginas HTML personalizadas para cada usuario.
Para poder realizar todas estas labores se utilizan múltiples librerías de Python, siendo las más destacadas las siguientes:
1. Uvicorn: permite la creación del servidor de aplicaciones.
2. FastAPI: framework que permite un fácil desarrollo, optimizado para suministrar un alto rendimiento.
3. SQLModel: permite la fácil gestión de los modelos y conexiones a la base de datos.
4. Paho: permite la creación de un cliente MQTT para el envío de mensajes.
5. Jinja2: permite la personalización de los archivos HTML.
6. HTMX: permite mejorar la experiencia del usuario al interactuar con la página web.
El uso de todas estas herramientas permite cumplir con los distintos objetivos de este proyecto.
Para terminar con el análisis y diseño del sistema, debe destacarse el uso del software Docker. Este software permite desarrollar el sistema a través de “dockers” o “contenedores”, entendiéndose por contenedor, un “paquete” de software con todo lo necesario para ejecutar un servicio de manera independiente.
Diseñando el sistema a través de contenedores, se garantiza que éste pueda migrarse de una arquitectura hardware a otra, y en caso de ser necesario escalar la solución, se puedan replicar los servicios, simplemente aumentando el número de contenedores.
Para llevar a cabo el desarrollo del proyecto, han sido necesarias 1.423 líneas de Python y 1.995 líneas de código HTML. Su desarrollo ha permitido alcanzar los objetivos del proyecto de manera satisfactoria.
Una vez terminado el proyecto con éxito, se plantean numerosas mejoras posibles, dentro de estas, destacan la implementación de sistemas de seguridad, la ampliación del sistema a otros protocolos de comunicación y la creación de una aplicación móvil que permita una fácil gestión del sistema desde cualquier lugar.
| ID de Registro: | 83393 |
|---|---|
| Identificador DC: | https://oa.upm.es/83393/ |
| Identificador OAI: | oai:oa.upm.es:83393 |
| Depositado por: | Biblioteca ETSI Industriales |
| Depositado el: | 03 Oct 2024 14:14 |
| Ultima Modificación: | 03 Nov 2024 01:30 |
Publicar en el Archivo Digital desde el Portal Científico