Desarrollo de red de sensores de irradiación solar

Desarrollo de red de sensores de irradiación solar Iván García Palomino Francisco José Hinojosa Pérez GRADO EN INGENIERÍA DE COMPUTADORES, FACULTAD DE INFORMÁTICA, UNIVERSIDAD COMPLUTENSE DE MADRID. Trabajo Fin Grado en Grado de Ingeniería de Computadores Madrid, 24 de enero de 2019 Director/es y/o colaborador: José Ignacio Gómez Pérez Christian Tenllado van der Reijden ii iii Resumen Este proyecto engloba la idea de desplegar una red de nodos solares, formados por varios sensores, que repartidos por una zona geográfica realicen la recogida de muestras de varias magnitudes físicas, siendo la irradiación solar la más importante de ellas en este proyecto. Los datos recogidos por los distintos nodos solares que conforman la red serán procesados por un sistema predictivo, que predecirá la radiación solar del área geográfica donde estén situados los nodos en un futuro próximo. De manera más concreta, este trabajo se centra en el despliegue de la red de nodos solares y en la recogida de magnitudes físicas procedentes de los distintos sensores, para su posterior envío a un servidor a través de un gateway. La red de nodos solares utiliza la tecnología LoRa para la comunicación entre los nodos y un gateway que les da salida a Internet. Dicho gateway utiliza el protocolo MQTT para la comunicación con el servidor utilizando un broker como intermediario. En el servidor se utiliza la plataforma ThingsBoard como cliente suscrito al broker MQTT, que permitirá almacenar y representar gráficamente los datos recibidos. Palabras clave Nodo Solar, Sensor, Radiación, Servicios, Muestreo, Gateway, LoRa, MQTT, ThingsBoard iv Abstract This project includes the idea of deploying a network of solar nodes, made up of several sensors, distributed throughout a geographical area to collect samples of various physical quantities, with solar irradiation being the most important of them in this project. The data collected by the different solar nodes that make up the network will be processed by a predictive system, which will predict the solar radiation of the geographical area where the nodes are located in the near future. More concretely, this work focuses on the deployment of the network of solar nodes and the collection of physical quantities from the different sensors, for later sending to a server through a gateway. The network of solar nodes uses LoRa technology for communication between the nodes and a gateway that gives them access to the Internet. This gateway uses the MQTT protocol for communication with the server using a broker as an intermediary. On the server, ThingsBoard platform is used as a client subscribed to the MQTT broker, which will allow the received data to be stored and graphically represented. Keywords Solar Node, Sensor, Radiation, Services, Sampling, Gateway, LoRa, MQTT, ThingsBoard 1 Índice de Contenidos Resumen .............................................................................................................................. iii Palabras clave ...................................................................................................................... iii Abstract................................................................................................................................. iv Keywords .............................................................................................................................. iv Índice de Contenidos ............................................................................................................ 1 Capítulo 1: Introducción ........................................................................................................ 3 Chapter 1: Introduction .......................................................................................................... 6 Capítulo 2: Hardware Nodo Solar.......................................................................................... 9 2.1. Pinout LoPy ...................................................................................................... 11 2.2. Sensor de radiación .......................................................................................... 13 2.3. Sensor de temperatura interna y humedad ....................................................... 13 2.4. Sensor de temperatura externa ........................................................................ 14 2.5. Módulo de posicionamiento GPS ...................................................................... 14 2.6. Uso de powerPin .............................................................................................. 15 2.7. Características de red LoPy.............................................................................. 15 Capítulo 3: Arquitectura Software........................................................................................ 16 3.1. Estructura general de directorios ...................................................................... 18 3.2. Configuración y muestreo del nodo solar .......................................................... 20 3.3. Servicios generales........................................................................................... 21 3.3.1. ManagerService .......................................................................................... 22 3.3.2. LocationService ........................................................................................... 23 3.3.3. SamplingService ......................................................................................... 24 3.3.4. ErrorLogService .......................................................................................... 25 3.4. Servicios de red ................................................................................................ 26 3.4.1. ConnectionService ...................................................................................... 27 3.5. Servicios de sensores ....................................................................................... 28 2 3.5.1. IrradiationSensor ......................................................................................... 29 3.5.2. DHT22Sensor ............................................................................................. 30 3.5.3. HumiditySensor ........................................................................................... 31 3.5.4. TemperatureInSensor.................................................................................. 32 3.5.5. TemperatureOutSensor ............................................................................... 33 3.6. Limitaciones de desarrollo ................................................................................ 34 3.6.1. Consumo excesivo de memoria .................................................................. 34 3.6.2. RTC............................................................................................................. 35 3.6.3. Sensor DHT ................................................................................................ 35 3.7. Análisis de tiempos de ejecución ...................................................................... 35 Capítulo 4: Servidores centrales ......................................................................................... 37 4.1. Protocolo MQTT ............................................................................................... 37 4.2. Plataforma ThingsBoard ................................................................................... 38 4.3. Interacción nodos-gateway ............................................................................... 38 4.3.1. Protocolo de entrada ................................................................................... 39 4.3.2. Protocolo de salida ...................................................................................... 41 4.4. Interacción gateway-broker MQTT .................................................................... 43 4.4.1. Herramienta Node-RED .............................................................................. 43 4.5. Representación gráfica en ThingsBoard ........................................................... 45 Contribución al proyecto de Iván García Palomino .............................................................. 48 Contribución al proyecto de Francisco José Hinojosa Pérez ............................................... 50 Conclusiones ...................................................................................................................... 52 Conclusions ........................................................................................................................ 53 Referencias y Bibliografía ................................................................................................... 54 Anexo 1: Tabla de Codificación de Errores/Warnings ......................................................... 55 Anexo 2: Frozen Code ........................................................................................................ 56 Anexo 3: Diagramas de secuencia ...................................................................................... 57 3 Capítulo 1: Introducción En la actualidad vemos como cada día se tratan temas relacionados con la producción o el consumo de energía, pues se relacionan con algunas de las cuestiones más punteras de la última década, como pueden ser el cambio climático o la extrema contaminación. Además, hay que tener en cuenta que cada día se fija el precio de la energía en una subasta eléctrica de forma continuada lo que afecta directamente tanto a empresas generadoras de energía (de origen renovable o no), como a los consumidores de la misma. Si se pudiera prever la producción de energía solar a corto plazo (entre 30 minutos y 2 horas), se podría disminuir el uso de centrales térmicas, más contaminantes, para satisfacer la demanda en momentos de alta irradiación solar. Una mayor fiabilidad en la predicción de la producción solar futura, podría permitir así el cierre de plantas excedentarias. A pesar de que las energías renovables llevan varios años abriéndose paso en nuestro entorno (en 2016 el 90% de la nueva potencia instalada en Europa fue de origen renovable1) es en la actualidad cuando la energía solar empieza a destacar en su contribución en el panorama energético (9 GW de nueva potencia instalada en Europa en 2017 tenía este origen) y con buenas previsiones de futuro2. En España está situada en séptimo lugar (aproximadamente 5 GW de potencia instalada en el momento de la realización de este proyecto según los datos de Red Eléctrica de España3) aunque continúa en constante evolución y se espera que hacia 2022 la potencia instalada de este origen se haya duplicado. Sirve de motivación para este proyecto conseguir integrar completamente la energía solar en el pool de energías que se usan a diario, con el fin de disminuir el uso de centrales más contaminantes y conseguir satisfacer la demanda en momentos de alta irradiación solar. Existen distintas técnicas para la realización de predicciones solares a corto plazo. Una de esas técnicas es la de “sky cams”, que consiste en la toma de fotografías terrestres al cielo para localizar y parametrizar el tipo de nubes para posteriormente predecir cuál será la posición de dichas nubes. Otra técnica de predicción utiliza fotografías realizadas desde satélites para determinar el tipo, tamaño y dirección de las nubes, y en base a ello, determinar las zonas nubosas. 1 https://www.diariorenovables.com/2017.html 2 https://www.energias-renovables.com/fotovoltaica 3 https://www.ree.es/es/estadisticas-del-sistema-electrico/3015/3001 4 Este proyecto se centra, sin embargo, en la idea de poder desplegar una red de sensores que midan la irradiación solar en cada momento en diferentes lugares para conseguir la mayor cantidad de información posible para poder aplicar posteriormente técnicas de inteligencia artificial y, a partir de ello, conseguir predecir con la mayor exactitud posible la energía solar de la que disponer, pues puede resultar interesante intentar regular la producción de energía y poder ajustarla más al consumo real y con ello abaratar los costes tanto de fabricación como de uso de la misma. De aquí el planteamiento de este trabajo, basado en el desarrollo y despliegue de una red de sensores compuesta por nodos propios basados en la placa de desarrollo LoPy4. En dicha red cada nodo es autónomo (alimentado por un panel solar y una batería externa) y tiene conectados varios sensores (temperatura, humedad, radiación solar y GPS) cuyos valores se leen de forma periódica y se envían mediante WiFi o LoRa, en función de la disponibilidad. Concretamente en el resultado final de este proyecto, el envío periódico de muestras se realiza a través de una conexión LoRa (protocolo de red con modulación en radiofrecuencia) a un gateway cercano, que se encarga de comunicar vía protocolo MQTT5 (protocolo ligero de uso habitual en IoT, Internet Of Things, basado en publish/subscribe), a un broker MQTT externo (servidor “solarcasting.dacya.ucm.es” disponible en la Facultad de Ciencias Físicas de la UCM) previamente configurado para recibir las publicaciones y que permite que se puedan suscribir clientes a ellas. En dicho servidor a su vez está incluido un cliente MQTT (ThingsBoard6, plataforma IoT open-source que permite un rápido desarrollo, gestión y escalado de proyectos de IoT) que está suscrito a estas publicaciones y permite la representación gráfica de los datos recibidos lo que proporciona poder comprobarlos de una manera más visual. La figura 1 nos muestra la idea principal de cómo se despliega la red construida en este proyecto. 4 https://docs.pycom.io/datasheets/development/lopy.html 5 http://mqtt.org/ 6 https://thingsboard.io/docs/ Figura 1: Despliegue de Red de Nodos 5 En los capítulos siguientes, veremos paso a paso cada una de las etapas que se diferencian en el diagrama anterior, comenzando por una visión general del hardware disponible en el nodo solar, así como de los sensores disponibles, y siguiendo por el diseño y posterior implementación de la aplicación software. Dicho software permite a cada nodo solar obtener constantemente muestras telemétricas, buscando actuar de manera autónoma y, periódicamente enviar los datos recogidos a un gateway utilizando LoRa como mecanismo de transmisión. Este gateway mencionado publicará la información recibida, usando el protocolo MQTT, en un servidor externo que podrá almacenar e incluso representar gráficamente los datos obtenidos. Este trabajo concluye en este punto de recogida y visualización de los datos obtenidos a partir de los sensores disponibles en el nodo solar propio, pero el proyecto general continúa en constante evolución usando estos datos para generar un modelo predictivo a partir de técnicas de inteligencia artificial. El objetivo final es desplegar una red de muchos de estos sensores en zonas de interés (plantas solares, pueblos/barrios con instalaciones domésticas) para tener datos precisos de radiación solar que sirvan de entrada al modelo predictivo y se generen predicciones en tiempo real. Destacar en este punto el uso de MQTT como protocolo de mensajería pues permite la suscripción a información recogida por cada nodo de la red de manera independiente a cualquier cliente suscrito a los canales del broker MQTT, pudiendo ser uno de ellos el propio modelo predictivo. El plan de trabajo se divide en dos partes bien diferenciadas: la parte de diseño e implementación de la aplicación en el nodo solar, por un lado, y por otro lado llevar a cabo el diseño de protocolos de comunicación para su posterior aplicación con un servidor. Para ello, es necesario realizar primero tanto el diseño de lo que será la aplicación software que realice las mediciones en el nodo con una frecuencia que pueda variar en función de los intereses de cada situación, como el diseño de los protocolos de comunicación de entrada y salida del propio nodo, para conocer cómo debe la aplicación software enviar sus muestreos telemétricos y a su vez cómo tratar comunicaciones externas. Tras esto, se debe llevar a cabo la implementación del software de muestreo de las mediciones recibidas por los sensores disponibles para, por último, poder enviar esos datos a un servidor para su almacenaje y representación gráfica si se quisiera disponer de ella. En este proyecto se consideran especialmente aspectos de consumo energético, tolerancia a fallos y facilidad en el despliegue de la red. 12 - El pin P13 queda conectado a un módulo solar SLMD121H04L15 que contiene cuatro células fotovoltaicas, y utilizamos como sensor de radiación. - El pin P14 está conectado a una batería externa LP50344816 de litio con una capacidad de 800mAh, utilizada para alimentar el sistema. Adicionalmente para que el nodo sea autónomo, en la placa diseñada por la Universidad Complutense se incluye la circuitería necesaria para adaptar el voltaje de un panel solar MEDIUM 6V 2W SOLAR PANEL17 para la carga de la batería y alimentar la LoPy a una tensión constante de 3.3V. - El pin P22 era utilizado inicialmente en el diseño original anterior para una de las conexiones del GPS. Sin embargo, este pin está conectado internamente a un DAC (conversor digital-analógico) utilizado en el diseño para mantener una tensión de referencia (aproximadamente 0,5V), utilizado por otras partes del circuito. Descubrir este hecho fue uno de los puntos complicados a la hora de llevar a cabo esta parte del proyecto, pues fue de complicada detección y además resultó necesario consultar el diseño original que ya estaba realizado de años anteriores y adaptarlo para poder utilizar todos los módulos disponibles actuales. - El pin P8 es usado para una funcionalidad específica de la placa de expansión denominada como powerPin. 15 http://ixapps.ixys.com/DataSheet/SLMD121H04L_Nov16.pdf 16 http://www.fullwat.com/documentos/000485-LNK03447.pdf 17 https://github.com/VoltaicEngineering/Solar-Panel-Drawings.pdf 13 2.2. Sensor de radiación Uno de los objetivos de este proyecto es el bajo coste, principal razón por la que se ha elegido un módulo solar SLMD121H04L para la captura de datos de radiación solar en lugar de utilizar, por ejemplo, un piranómetro que tiene el mismo propósito, pero su valor excede el presupuesto deseado. Un piranómetro es un instrumento meteorológico utilizado para medir de manera muy precisa la radiación solar incidente sobre la superficie de la Tierra. Se trata de un sensor diseñado para medir la densidad del flujo de radiación solar (kilovatios por metro cuadrado) en un campo de 180 grados. Como no disponemos de un instrumento así para este proyecto, utilizamos el módulo solar SLMD121H04L que contiene cuatro células fotovoltaicas como sensor de radiación, de tal forma que el circuito analógico que incluye la placa de expansión UCM sitúa el punto de trabajo de la placa solar cerca del cortocircuito. La corriente de cortocircuito es proporcional a la radiación solar recibida por el panel, por lo que, midiendo dicha corriente, obtenemos una estimación de irradiación. Para medir la corriente, la placa UCM contiene un circuito de transimpedancia que proporciona un voltaje proporcional a la corriente. Ese voltaje es obtenido con un conversor analógico-digital (ADC) que nos proporciona una estimación más precisa de la irradiación solar que obtener los W/m2 de un sitio concreto, lo que nos permite tener mejores datos a tratar con un modelo predictivo. 2.3. Sensor de temperatura interna y humedad Cómo se vio en la figura 2, que mostraba la fotografía de un nodo ya montado, se puede observar que la placa LoPy está protegida por una estructura que le permite resguardarse de las inclemencias climáticas. Debido a esta estructura la placa queda aislada del exterior, pero esto nos produce la necesidad de conocer la temperatura interna de la estructura por si se produjera algún tipo de calentamiento en su interior. Para medir esta temperatura queda instalado dentro de la estructura con la placa un sensor DHT22, bastante económico incidiendo una vez más en el objetivo del bajo coste, que nos permite conocer esta temperatura de manera bastante precisa y que adicionalmente nos aporta el dato de la humedad ya que este sensor también dispone de ello. El valor de este sensor es obtenido a través de lecturas continuas de los pulsos producidos en su pin correspondiente (P3), con una librería especialmente diseñada para este sensor. Las lecturas del sensor proporcionan un valor distinto cada 2 segundos aproximadamente. 14 2.4. Sensor de temperatura externa Para la medición de la temperatura externa de la estructura de los nodos, usamos un sensor de temperatura DS18X20, que resulta ser bastante económico y que utiliza el sistema de comunicaciones en bus 1-Wire. El protocolo 1-Wire consiste en iniciar la comunicación enviando una señal de reset durante 480 µs o más a nivel bajo, pulsos largos (60 µs) para enviar bits de valor cero y pulsos cortos (menos de 15 µs) para los bits con valor uno, formando paquetes de ocho bits. Para identificar cada dispositivo conectado al bus se utilizan direcciones únicas de 8 bytes que incluyen uno como identificador del hardware, el más significativo, y otro para la verificación CRC, el menos significativo. Como ocurre en otros protocolos similares, en el inicio de la comunicación se incluye la identificación del dispositivo y la operación que se desea realizar (como escribir en la memoria o leerla, por ejemplo). Para el uso de este sensor es importante remarcar que el uso del protocolo 1-Wire implica la necesidad de un único cable para enviar y recibir datos, lo que permite el ahorro de un cable para casos en los que el número de conexiones es limitado. Por otro lado, remarcar que, para el uso de este sensor, Pycom proporciona una librería “ w ” que facilita su desarrollo. 2.5. Módulo de posicionamiento GPS Para mantener la hora y la fecha siempre sincronizados en el RTC interno del sistema, y adicionalmente disponer de la situación geográfica de cada nodo de la red desplegada, se dispone de un módulo GPS GNSS. Esto mismo podría ser realizado utilizando un RTC externo que mantuviera siempre la hora de manera sincronizada, sin embargo, un módulo como este nos permite conocer también la situación geográfica de cada uno de los nodos de la red de forma adicional. El módulo se pueden consultar con más detalle en la sección 3.3.2. del Capítulo 3 de este documento. 15 2.6. Uso de powerPin La placa UCM diseñada permite cortar la alimentación de todos los sensores para reducir el consumo. Es necesario activar el powerPin (P8) para poder consultar cualquiera de los sensores y es conveniente desactivarlo si se prevé un periodo largo de inactividad, pues el ahorro de energía es un aspecto crucial para un nodo autónomo. Además, debido a que este pin requiere de un tiempo para su activación, se puede producir un pequeño delay a la hora de realizar las mediciones. Adicionalmente, como este pin es compartido entre todos los sensores y con la intención de no mantenerlo siempre activo buscando el menor consumo posible del sistema, es necesario el uso de un cerrojo global para garantizar que cada sensor puede activar disponer de este pin activo para poder realizar sus muestreos correctamente. 2.7. Características de red LoPy Al principio de este capítulo, mencionamos como la placa LoPy dispone de capacidad para conexiones Wifi, Bluetooth y LoRa. Para la realización de este proyecto nos decantamos por el uso de LoRa18, ya que cumple el objetivo del bajo consumo pretendido y además proporciona un largo alcance para las comunicaciones, disponiendo de un bajo ancho de banda. LoRa es la capa física o la modulación inalámbrica utilizada para crear el enlace de comunicación de largo alcance, mientras que LoRaWAN define el protocolo de comunicación y la arquitectura del sistema para la red. Dicho protocolo proporciona, además, robustez ante interferencias y seguridad en la red, todo ello cumpliendo con el bajo consumo. Adicionalmente, comentar que la modulación LoRa trabaja con ISM (Industrial, Scientific and Medical), bandas reservadas internacionalmente para uso no comercial de radiofrecuencia electromagnética en áreas industriales, científicas y médicas. En nuestro caso realizamos las conexiones a través de la banda regional EU 868. 18 https://www.tuv.com/TUeV_Rheinland_Overview_LoRa_and_LoRaWANtmp.pdf 16 Capítulo 3: Arquitectura Software El principal objetivo en el diseño de la arquitectura software era el de otorgar facilidad para añadir o eliminar funcionalidades fácilmente sin repercutir en el funcionamiento del sistema, por ese motivo diseñamos la aplicación con diversos servicios, cada uno cumple con una funcionalidad determinada. Para cumplir con este objetivo diseñamos distintos módulos que denominamos servicios y pretendiendo que cada uno de ellos sea lo más independiente posible del resto de servicios en su funcionamiento, esto queda reflejado en el siguiente diagrama general. Figura 4: Diagrama General de la Arquitectura Software 17 Otro de los objetivos en el diseño era el de poder modificar atributos de algunos servicios, con este propósito diseñamos un fichero de configuración independiente para cada servicio en el que se guardan ciertos atributos configurables y habilitando la posibilidad de modificar dichos atributos de forma remota vía conexión LoRa o Wifi mediante las interfaces diseñadas que trataremos más adelante, aunque esta funcionalidad no está implementada en este proyecto. En el diseño software hemos dividido en tres tipos los servicios que forman la aplicación. Los servicios denominados sensores (IrradiationSensor, TemperatureInSensor, HumiditySensor, TemperatureOutSensor) dispondrán de un hilo de ejecución independiente. De este modo se garantiza una mayor precisión en la toma de muestras en cada sensor, que pueden configurarse con frecuencias de muestreo independientes. Estos servicios implementan la interface Sensors. Los servicios que no son sensores, que denominamos servicios generales, otorgan al sistema funcionalidades de gestión: ErrorLogservice gestiona los posibles errores y warnings; SamplingService es el encargado de solicitar muestras a los sensores para el posterior envío periódico de dichas muestras. LocationService es el encargado de la conexión con el satélite de posicionamiento; ManagerService es el encargado de gestionar el arranque y configuración inicial del sistema. Estos servicios implementan la interface Services, aunque pueden tener más métodos en función de la necesidad de cada servicio. Por último, en la arquitectura software se incluye una interfaz Network para los diferentes tipos de conexión posible Wifi o LoRa. En nuestro proyecto implementamos el servicio ConnectionService encargado de realizar la conexión vía LoRa con un gateway cercano. El código fuente de la aplicación aquí documentada puede ser consultado en el enlace https://github.com/Development-of-solar-irradiation-sensor-network. En el proceso de desarrollo de este software hemos utilizado la aplicación de escritorio Atom y su respectivo paquete de desarrollo Pymakr que incluyen una licencia de uso GPLv3, el módulo ESP proporcionado por Pycom cuenta con una licencia Apache 2.0, la implementación en MicroPython tiene licencia MIT, las librerías propias de Pycom a las que accedemos en este proyecto poseen licencia GPLv3, la herramienta node-RED necesaria para la interacción nodos-gateway y la plataforma ThingsBoard que utilizamos como cliente MQTT para las representaciones gráficas tienen licencia Apache 2.0. En base a las licencias de las distintas librerías (por ejemplo, “ w ” proporcionada por Pycom) utilizadas en el desarrollo del proyecto, decidimos otorgar una licencia GPL 3 “ na e si n ste i ” (GPLv3+) a este proyecto, compatible con todas las citadas anteriormente y que permite su uso comercial, su modificación, distribución, derecho de patente y uso privado. 18 3.1. Estructura general de directorios Los servicios disponen de directorios almacenados en la memoria flash de la placa de desarrollo LoPy, en los que se almacenan los distintos ficheros de configuración, todos ell s llamad s “c nf.txt”. n el cas de ErrorLogService también almacena en su directorio los ficheros log generados. Los ficheros de configuración tienen la estructura de un diccionario en python para facilitar el proceso de lectura y escritura de los ficheros. Figura 5: Diagrama General de Directorios 19 El código de la aplicación se encuentra en el firmware de la LoPy, donde cada servicio consta de un directorio propio en el que se almacena el fichero de código correspondiente al servicio, adicionalmente también existe un directorio llamado libraries para las distintas bibliotecas utilizadas en los servicios y un directorio especial para el dht22Sensor. Figura 6: Diagrama General de Estructura Software 20 3.2. Configuración y muestreo del nodo solar Los nodos solares al inicio de su ejecución constan de dos funcionalidades principales. Activación y configuración de todos los servicios que el fichero de configuración de Managerservice establezca que tienen que estar activos. Como se puede apreciar en la figura 7, que representa el diagrama de secuencia de configuración inicial de un nodo, ManagerService es el servicio encargado de la activación del resto de servicios de la aplicación. Inicialmente lee su propio fichero de configuración el cual le indica qué servicios tiene que activar. Después, activa los tres servicios que se consideran imprescindibles y su activación es prioritaria: ConnectionService (encargado de la conexión LoRa con un gateway cercano), ErrorLogService (encargado de la gestión de errores y warnings de la aplicación) y LocationService (cuya función es la de conseguir una sincronización con el GPS para establecer la hora en el sistema). Posteriormente se pasa a la activación de los distintos sensores pasándole a cada uno de ellos sus atributos correspondientes. En cada sensor se creará un hilo nuevo de ejecución cuya tarea será la de ir recogiendo muestras a la frecuencia establecida. En el caso de HumiditySensor y TemperatureInSensor, activarán a su vez el servicio DHT22Sensor que será el encargado de recoger las muestras para estos dos servicios. Debido a esta restricción la frecuencia de muestreo de estos dos sensores tiene que ser la misma. Finalmente, se activará el servicio SamplingService en el cual está el bucle principal de muestreo que irá solicitando las muestras a los sensores en función de la frecuencia de envío establecida. La funcionalidad principal que tiene que realizar los nodos solares es la de realizar muestras de los sensores a las frecuencias establecidas en cada sensor y enviarlas a un gateway a una frecuencia denominada sendingFrequency también establecida. Por otro lado, la figura 8 ilustra el bucle principal de recogida de muestras en SamplingService. Para este ejemplo, asumimos que los sensores están previamente activados y muestreando a las frecuencias seleccionadas en sus ficheros de configuración. Desde SamplingService se va solicitando la muestra de los sensores que están activos; la muestra que devuelvan los sensores puede ser de dos tipos: la media de todas las muestras que ha tomado entre peticiones del SamplingService o la última muestra realizada, dependiendo del modo que esté configurado el sensor en su fichero de configuración. Cuando se han solicitado todas las muestras que se desean enviar en un momento dado, SamplingService realiza una llamada al método sendPackage de ConnectionService para construir el paquete de muestras y realizar el posterior envío al gateway vía conexión LoRa. 21 Hemos diseñado un formato para dichos paquetes, tratando de minimizar el número de bits requeridos para el envío de las muestras. Asimismo, hemos diseñado el protocolo de comunicación nodo-gateway de modo que este último sepa cómo reaccionar ante los diferentes paquetes que recibe. El bucle se repetirá a la frecuencia establecida mientras que el servicio SamplingService esté activo. 3.3. Servicios generales Figura 9: Estructura de la Interfaz Services Para los servicios generales que otorgan funcionalidades de gestión, disponemos de una interface llamada Services que establecen los métodos que todo servicio que denominamos general debe cumplir. Los servicios tienen que activarse a través del método connect(), pudiendo desactivarlos con disconnect(). Para la configuración inicial de atributos se utilizará el método confService(); asimismo, los servicios dispondrán de atributos configurables vía LoRa o wifi a través ManagerService haciendo uso del método updateAtribute() de los servicios. El método serviceEnabled informará de si el servicio está activado. Por último, el método start() llevará acabado la funcionalidad principal del servicio, creando un hilo de ejecución nuevo para ello si fuese necesario. 28 3.5. Servicios de sensores Figura 16: Estructura de Interfaz Sensors Para los servicios que son sensores diseñamos una interfaz llamada Sensors que establece los métodos necesarios para la creación de un nuevo sensor, por cada instancia del sensor se creará un hilo encargado del muestreo y posible filtrado de los datos obtenidos. Para la activación, desactivación y configuración del sensor se utilizan los métodos connect(), disconnect() y confservice() respectivamente, updateAtribute() actualiza los atributos modificables del sensor, start() crea un nuevo hilo de ejecución con el método sampling() que será el encargado de realizar las muestras a una frecuencia establecida en el sensor y con getData() se obtiene el valor de las muestras. 29 3.5.1. IrradiationSensor Figura 17: Estructura de IrradiationSensor Irradiationsensor es el servicio a cargo del sensor de radiación solar, realiza mediciones periódicas utilizando la librería “A C” proporcionada por Pycom, a la frecuencia establecida, ofreciendo los datos de dos formas distintas dependiendo del valor de su atributo mode asignado en su fichero de configuración correspondiente, pudiendo devolver la media de las últimas mediciones o la última medición realizada (ambas posibilidades quedan habilitadas para todos los sensores disponibles). El valor devuelto por este sensor es una lectura de una de las posibles combinaciones del rango del ADC, en nuestro caso en forma de voltaje, que servirá para conocer con mayor precisión la radiación capturada por el sensor dedicado a ello, y que permitirá en el futuro trabajar con datos más precisos en el modelo predictivo. Los atributos samplingFrequency, que indica la frecuencia con la que se realizan muestras, y mode, q e esta lece el m d en q e se de el en las m est as “0” a a la media de las muestras “1” a a la última m est a, eden se m dificad s a t a és del fichero de configuración o de forma remota. 30 3.5.2. DHT22Sensor Figura 18: Estructura de DHT22Sensor El servicio DHT22Sensor es el sensor encargado de recoger las muestras de humedad y de temperatura interna del nodo. Este sensor tiene la particularidad de que realiza la recogida de muestras de dos mediciones a través de la creación de un hilo nuevo de ejecución, con el que se realiza el muestreo a la frecuencia establecida, es por ello que la frecuencia de muestreo de la humedad y de la temperatura interior tiene que ser la misma. Este sensor no tiene un fichero de configuración, pero ofrece la opción de modificar la frecuencia de muestreo a través de los servicios HumiditySensor y TemperatureInSensor que son los encargados de activar y establecer dicha frecuencia en DHT22Sensor. 31 3.5.3. HumiditySensor Figura 19: Estructura de HumiditySensor HumiditySensor es el servicio encargado del sensor de humedad e implementa la interfaz Sensors, en este servicio cabe destacar que no es el encargado de realizar las mediciones, sino que tiene que activar el servicio DHT22Sensor para crear un hilo de ejecución y realizar las mediciones apropiadas. Los atributos samplingFrequency, que indica la frecuencia con la que se realizan muestras, y mode, q e esta lece el m d en q e se de el en las m est as “0” a a la media de las m est as “1” a a la última m est a, eden se m dificad s a t a és del fichero de configuración o de forma remota. 32 3.5.4. TemperatureInSensor Figura 20: Estructura de TemperatureInSensor El servicio TemperatureInSensor gestiona la métrica de temperatura interior del nodo, aunque para realizar las muestras necesita activar el sensor DHT22Sensor para crear un hilo de ejecución y realizar el muestreo a la frecuencia que TemperatureInSensor le indique. Los atributos samplingFrequency, que indica la frecuencia con la que se realizan muestras, y mode, q e esta lece el m d en q e se de el en las m est as “0” a a la media de las m est as “1” a a la última m est a, eden se m dificad s a t a és del fichero de configuración o de forma remota. 33 3.5.5. TemperatureOutSensor Figura 21: Estructura de TemperatureOutSensor TemperatureOutSensor es el sensor encargado de realizar las muestras de temperatura exterior del nodo. Crea un hilo de ejecución en el que se realizan las muestras a la frecuencia establecida y como ya se mencionó en la sección 2.4. del Capítulo 2, este sensor utiliza el protocolo OneWire para la transmisión de datos. Los atributos samplingFrequency, que indica la frecuencia con la que se realizan muestras, y mode, q e esta lece el m d en q e se de el en las m est as “0” a a la media de las m est as “1” a a la última m est a, eden se m dificad s a t a és del fichero de configuración o de forma remota. 34 3.6. Limitaciones de desarrollo Como ya quedó reflejado en el Capítulo 2, en el contexto del bajo consumo es habitual encontrarse con ciertas dificultades debido a los recursos limitados del sistema. Debido a ello, reseñamos a continuación cuáles han sido las limitaciones de desarrollo más relevantes que nos hemos encontrado en este proyecto. 3.6.1. Consumo excesivo de memoria El dispositivo hardware utilizado dispone de 512KB de memoria. Tras instalarle el firmware proporcionado por PyCom quedan únicamente 79152 bytes libres19 aproximadamente. A su vez, parte de esos bytes son ocupados posteriormente por el intérprete de MicroPython necesario para ejecutar el código. Tras ir añadiendo módulo a módulo los servicios disponibles y la creación de los distintos hilos de ejecución necesarios para la recogida de muestras de los distintos sensores, la cantidad de memoria RAM iba disminuyendo de forma considerable hasta llegar el punto de que el nodo consumía toda la memoria ejecutando la aplicación, lo que bloqueaba su correcto funcionamiento antes de poder añadir incluso todos los módulos disponibles. Para tratar de paliar este problema, incluimos explícitamente en nuestro cóidgo llamadas que obligan a actuar al Recolector de Basura20 de MicroPython. Con el fin de mitigar el uso excesivo de estas llamadas establecemos un límite de 13000 bytes libres de memoria para dicha actuación; el código está incluido en la librería “ yM g ” de la aplicación. A pesar de esto, al agregar nuevos módulos seguía apareciendo el mismo problema. Este conflicto resultó ser el más importante del proyecto y finalmente pudo ser solucionado incluyendo todo el código fuente de la aplicación en el firmware de la LoPy a través de un proceso denominado “F z By ”, liberando así gran cantidad de memoria RAM en cada ejecución del programa y permitiendo añadir todos los módulos citados anteriormente. Esta solución queda más detallada en el Anexo 2 incluido al final de este trabajo. 19 https://forum.pycom.io/topic/170/lopy-wipy-2-esp32-specs-and-performance/9 20 http://docs.micropython.org/en/v1.9.3/pyboard/library/gc.html 35 3.6.2. RTC Debido a la pérdida de fiabilidad del RTC interno de la placa LoPy cuando entra en modo deepsleep, el nodo solar podría no iniciar a la hora esperada, por lo que al inicio de la ejecución se realiza una comprobación para considerar si tiene que volver a dormirse porque se inició antes de lo esperado. Esta comprobación consiste en leer un fichero almacenado en la memoria flash de la placa LoPy llamado “ Stamp. x ” y que contiene dos posibles valores: la marca temporal en segundos de cuando se tiene que iniciar el nodo n “1” q e señala q e el n d tiene q e esta e ec tand la a licaci n s ftwa e. l n d antes de entrar en modo deepsleep guarda en el fichero “ meStamp. x ” la marca temporal a la que se tiene que volver a iniciar. 3.6.3. Sensor DHT El sensor DHT22 realiza los muestreos de humedad y temperatura interior del nodo, al ser dos métricas distintas las que recoge un sólo sensor, surgió el problema de realizar dos accesos desde distintos hilos al sensor DHT22 lo que resultaba en valores erróneos, por lo que se optó por crear un único hilo de ejecución para la realización de los dos muestreos. El servicio DHT22Sensor es el encargado de realizar esta tarea. 3.7. Análisis de tiempos de ejecución A la hora de enviar los datos recogidos por la aplicación hacia un Gateway, nos dimos cuenta de que los envío tenían un ligero retraso temporal en la frecuencia de envío deseada, del que no conocíamos su origen. Para ello, hicimos algunos cálculos con la aplicación para conocer realmente que tiempos de ejecución estábamos manejando. En primer lugar, decidimos calcular el tiempo de ejecución del proceso de recogida de muestras de los sensores, para ver si el delay producido era fruto de la recogida de muestras en los sensores. Obtuvimos los tiempos que se reflejan en la Tabla 1. Tabla 1: Cálculo de Tiempos Bucle de Muestreo 36 Como se puede apreciar, sí que existe un ligero retraso en la recogida de estas muestras cuando tanto la frecuencia de envío como la de muestreo son altas (envíos cada poco tiempo), aunque solo se ve reflejado en algunos casos, como por ejemplo cuando están todos los sensores activos para frecuencias de envío de 5-10 segundos y frecuencia de muestreo de 1 segundo. Sin embargo, vemos como para frecuencias de envío de 10-20 segundos y frecuencias de muestreo de 2-5 segundos, el tiempo de la ejecución es apenas perceptible pues no llega al segundo en ninguno de los casos. Estos datos no aclararon demasiado el problema, pues tan sólo en unos pocos casos, vemos que se vea afectada en más de un segundo la ejecución esperada de la aplicación. Por ello, decidimos ir más allá y realizamos los cálculos del tiempo total transcurrido en el proceso de recogida de muestras por los sensores y con la creación de los paquetes que se envían, incluyendo también su envío hacia el Gateway. Los resultados obtenidos se pueden observar en la Tabla 2, incluida a continuación. Tabla 2: Cálculo de Tiempo Total de Muestreo y Envío a Frecuencia Deseada Tras esto, llegamos a la conclusión de que todos los tiempos estaban retrasados en aproximadamente 3 segundos a lo esperado, por ejemplo, para los casos de frecuencia de envío de 20 segundos el envío se realiza cada 23 segundos aproximadamente. Sin embargo, sí que seguimos observando que en períodos de envío de 5-10 segundos, con frecuencia de muestreo de 1 segundo, algunos envíos se retrasan más de 3 segundos, pero casualmente, se tratan de los mismos casos en los que el proceso de muestreo también manejaba un pequeño delay. Tras analizar y valorar todos los datos obtenidos, llegamos a la conclusión de que el proceso de creación del paquete a enviar y el envío del mismo, retrasaban en 3 segundos (generalmente) la ejecución normal de la aplicación. Para compensar este delay, la aplicación en su versión final incluye una resta de este tiempo transcurrido en la creación y envío del paquete de datos a la frecuencia de envío esperada, lo que nos permite ajustar de manera más precisa los tiempos de envío y obtener los datos en el Gateway a la frecuencia aproximada esperada. 37 Capítulo 4: Servidores centrales En la comunicación de la red de nodos con el exterior utilizamos un gateway que establece conexión con los dispositivos a través de conexión LoRa. Posteriormente desde el gateway se publicará la información recibida de todos los nodos a un broker MQTT usando protocolo MQTT. Dicha información puede ser el envío periódico de muestras realizadas para su posterior almacenamiento en el servidor “ g. y . . ”, mensajes para alertar de un posible error en la ejecución de la aplicación software en un nodo solar, mensajes para dar de alta o dar de baja un nodo del sistema de seguimiento ThingsBoard21, informar de la posición actual del nodo o informar de la hora del sistema en el nodo. El proceso de comunicación entre nodo, broker MQTT y cliente consta en primer lugar del envío de un mensaje para dar de alta al nodo solar en la plataforma ThingsBoard22. Tras esto, se procede al envío de la posición geográfica y la hora actual del sistema del dispositivo. A continuación, se realiza la transmisión periódica de muestras, dependiente de la frecuencia de envío establecida previamente, desde el nodo al broker MQTT, que hace accesible esta información para los distintos suscriptores, en nuestro proyecto utilizamos como cliente suscriptor la plataforma ThingsBoard. De carácter extraordinario el nodo puede realizar el envío de notificaciones de posibles errores y warnings producidos durante la ejecución de la aplicación software, y adicionalmente existe la posibilidad de enviar una petición de dar de al nodo en ThingsBoard. 4.1. Protocolo MQTT MQTT23 es un protocolo de mensajería de tipo publish/subscribe, extremadamente simple y liviano, diseñado para redes de bajo ancho de banda, de alta latencia o poco confiables. Los principios de diseño son minimizar el ancho de banda de la red y los requisitos de recursos del dispositivo al mismo tiempo que intentan garantizar la confiabilidad y cierto grado de seguridad de la entrega. La arquitectura MQTT tiene una topología en estrella, con un servidor central denominado broker. Los clientes pueden darse de alta en el broker cómo publish (publican información en un canal del broker) o cómo subscribe (reciben información del canal al que están suscritos). 21 https://thingsboard.io/ 22 http://solarcasting.dacya.ucm.es:8080 23 http://mqtt.org/ 44 Figura 33: Configuración de Node-RED en Gateway El diseño consta de varios módulos como se puede apreciar en la figura 33, el primer módulo “ ” es el encargado de la recepción de paquetes vía conexión LoRa, el segundo módulo “ y M G” identifica el tipo de mensaje, cada mensaje es tratado de una forma diferente, por lo que se crea un módulo nuevo por cada tipo de mensaje. El módulo “ ” realiza la interpretación de los mensajes sample del nodo y los transforma al formato aceptado por ThingsBoard indicando la marca de tiempo en la que se enviaron los mensajes (en segundos desde el epoch Unix), el identificador del nodo emisor del mensaje y los datos de las distintas muestras enviadas para su publicación en el canal “ y” del broker MQTT. En los módulos “ ” y “ ” se realiza la interpretación de los mensajes de Location y Time respectivamente, creando los respectivos mensajes ajustándose al protocolo de ThingsBoard donde se notifica la posición geoespacial y la hora del sistema en el nodo, con el identificador del nodo que emitió el mensaje para su posterior publicación en el canal “ b ” del broker MQTT. En el módulo “ W g” se traduce el mensaje recibido del nodo y se construye el mensaje para ThingsBoard en donde se notifica del error o warning que se indica en el mensaje recibido del nodo, el número de veces que ha sucedido en una ejecución y el identificador del dispositivo emisor, para su posterior publicación en el canal “ b ” del broker MQTT. En los módulos de “ ” y “ ” se construye un mensaje con el identificador del dispositivo que se quiere dar de alta o baja en la plataforma ThingsBoard, estos mensajes se publicarán en los canales MQTT “ ” y “ ” respectivamente. 45 Por último, se encuentran módulos que establecen conexión con el servidor broker MQTT en los diferentes canales que a los que está suscrita la plataforma ThingsBoad en el broker MQTT, en nuestro proyecto utilizaremos cuatro canales: “ y” para la publicación de las muestras, “ ” y “ ” para publicar los mensajes de dar de alta o baja respectivamente, a un nodo de la plataforma ThingsBoard y “ b ” para el envío de información acerca del nodo (posición geográfica, hora del sistema y errores en el nodo). 4.5. Representación gráfica en ThingsBoard Como ya quedó reflejado en la sección 4.2. de este mismo capítulo, ThingsBoard permite representar gráficamente los atributos y los datos telemétricos de los dispositivos que previamente se hayan dado de alta en la plataforma. Para la realización de este proyecto hemos tenido a nuestra disposición dos nodos montados: uno de ellos dispone de todos los sensores incluido GPS incluido, se identifica a través de un ID único de dispositivo 70-b3-d5-49-98-46-56-33; El otro nodo disponible constaba de GPS y todos los sensores, salvo sensor de temperatura exterior, y queda identificado como 70-b3-d5-49-93-24-c1-b2. Algunos atributos que manejamos con estos dispositivos son su Longitud y Latitud, que nos proporciona el módulo de posicionamiento de cada uno de ellos. ThingsBoard puede representar estos datos en un mapa para mostrar más claramente su situación geográfica, tal y como muestra la figura 34. Figura 34: Visualización de Localización en ThingsBoard 46 Para representar los datos telemétricos, la plataforma ThingsBoard proporciona gran variedad de gráficos, algunos muy llamativos. Sobre todo, pensados para representar datos muy concretos y de un solo dispositivo. Como en nuestro caso queremos visualizar las telemetrías de varios dispositivos a la vez, y en tiempo real, elegimos para ellos gráficos de trama como podemos ver en las figuras 35, 36 y 37 que muestran los gráficos de radiación, temperatura interna y humedad, respectivamente, de los dos nodos que disponemos. Figura 35: Visualización de Radiación en ThingsBoard Figura 36: Visualización de Temperatura Interna en ThingsBoard Figura 37: Visualización de Humedad en ThingsBoard 47 Sin embargo, como tan solo disponemos de sensor de temperatura exterior en uno de los nodos, elegimos otro tipo de visualización, que, a pesar de ser menos gráfica, permite revisar de forma más sencilla el historial de datos almacenados y, a su vez, sigue mostrando en tiempo real las muestras que se van recogiendo. Figura 38: Visualización de Temperatura Exterior en ThingsBoard 48 Contribución al proyecto de Iván García Palomino El proyecto consiste en una continuación de un trabajo de fin de grado de años atrás. Las primeras semanas se produjeron varias reuniones con los directores del trabajo de fin de grado del que parte este proyecto para tratar de comprender los pasos que se habían realizado anteriormente en el proyecto y poder fijar un punto de partida en este trabajo. Después estas reuniones, se procedió a un diseño de la arquitectura software que cumpliese con los requisitos que nos habían marcado los directores del proyecto. Algunos de los requisitos que indicaron fueron que el diseño de la aplicación software fuese un conjunto de servicios independientes, y que se habilita la opción de modificación y control de los nodos solares desde el exterior. Tras un primer diseño general se procedió a una reunión de los miembros del grupo con los directores de este proyecto para exponer el diseño inicial que los miembros del grupo habían realizado. Los directores aportaron sus opiniones y posibles mejoras a realizar en el diseño presentado. Después de modificar el diseño con las aportaciones de los directores, se procedió al diseño de los protocolos de comunicación de entrada y salida del nodo, debido a que en el proyecto los nodos solares se comunican con un gateway a través de LoRa. A continuación, se procedió al diseño de la estructura general de directorios de la aplicación software en los nodos. Posteriormente, se realizó a una reunión de los miembros del grupo y los directores para poner en común los diseños realizados, los directores dieron el visto bueno a los diseños presentados. En los primeros días después de la reunión se procedió a una toma de contacto con el hardware que conforma el nodo solar. Al no disponer de experiencia en el lenguaje de MicroPhyton, ni en trabajar con el tipo de limitaciones que presenta el hardware de este proyecto, se procedió a la realización de pruebas de algunas funcionalidades que estaban implementadas en el proyecto del que parte este trabajo. A continuación, se pasó a la división de los servicios entre los miembros del grupo, Iván García realizó la implementación de los servicios generales (ManagerService, SamplingService) que requerían un mayor esfuerzo en implementación y Francisco José Hinojosa se encargó de los servicios sensores que requieren un mayor esfuerzo de investigación. La unión de las dos partes realizadas por los miembros del grupo no resultó fácil, debido a que a cada vez que se añadían servicios a la aplicación se producían problemas en la memoria RAM, debido a la escasa capacidad que se dispone de ella. 49 Para ello los miembros del grupo realizaron investigaciones para encontrar una solución al problema presentado. Tras hablarlo con los directores, se decidió utilizar una técnica llamada “F z C ” que permite el ahorro de memoria RAM y nos otorga la posibilidad de seguir añadiendo el resto de los servicios que conforman la arquitectura software. Una vez resuelto el problema de la memoria, los miembros del grupo encontraron problemas de funcionamiento en el módulo de posicionamiento GPS. Por lo que se procedió a revisar el material del que disponíamos del anterior proyecto. Tras la revisión del código de la librería del protocolo ubx se encontró un error en dicho código. Resueltos estos dos problemas encontrados, los miembros del grupo se volvieron a dividir los servicios restantes. Iván García realizó la implementación del servicio ConnectionService, y la configuración de la herramienta node-RED en el gateway. Francisco José Hinojosa procedió a la implementación del servicio ErrorLogService. Después de la unión de los respectivos trabajos, se encontraron errores que tuvieron que ser revisados de forma conjunta por los dos miembros del grupo, para poder subsanar los problemas de la manera más rápida posible. Posteriormente los miembros del grupo trabajaron conjuntamente en la comunicación del gateway-servidor y en la plataforma ThingsBoard, de la cual se necesitó la ayuda del director del trabajo, José Ignacio Gómez que nos proporcionó dicha plataforma y la posibilidad de utilizar un servidor de la Facultad de Ciencias Físicas de la UCM. Por último, Iván García realizó los últimos ajustes y modificaciones de la aplicación software, mientras que francisco José Hinojosa se centró más en la labor de documentación de este proyecto. Para finalmente colaborar conjuntamente en la realización del análisis de tiempos de ejecución de la aplicación, para detectar el delay en el envío de los paquetes desde los nodos, y colaborar conjuntamente en el proceso de documentación de este trabajo. Cabe destacar el papel de los directores del trabajo en la revisión de varias versiones de la documentación y en la aportación de consejos para realizar de forma correcta la documentación del proyecto. 50 Contribución al proyecto de Francisco José Hinojosa Pérez En primer lugar, cabe destacar que enfrentarse a la continuación de un proyecto que ya había comenzado unos años atrás, no fue sencillo en primera instancia para ninguna de las dos personas que hemos realizado este proyecto. Gracias a la ayuda de los directores de este Trabajo de Fin de Grado que nos ayudaron a comprender el material que ya existía y, que nos guiaron a la hora del diseño inicial, conseguimos adaptarnos lo más rápido que pudimos para poder comenzar con nuestro trabajo. El primer paso que dimos a la hora de realizar este proyecto, fue el de realizar un diseño de la aplicación software basado en servicios. Para lo cual, fue necesaria la colaboración de todo el equipo para una puesta en común de los objetivos y de los requisitos necesarios, para poder realizar un diseño que se ajustara correctamente a ello. Una vez realizado el diseño inicial de la arquitectura software, fue necesario el trabajo conjunto de los dos miembros de la pareja para la creación de protocolos de entrada y salida de mensajes, pues conocíamos de antemano la existencia de un Gateway que debía recibir la información que procesáramos. Con todos los diseños ya terminados, procedimos a la toma de contacto con la placa LoPy y los distintos sensores, lo que no resultó sencillo y nos llevó a realizar investigaciones individuales para, entre los dos, poder ponernos al día con todos los recursos que disponíamos. En cuanto conseguimos comprender, más o menos, el funcionamiento de los elementos que teníamos a nuestra disposición, nos pusimos manos a la obra para realizar la implementación de la aplicación software. Para ello, dividimos los servicios resultantes en el diseño previo, quedándose Iván García con el grueso de los servicios generales (ManagerService y SamplingService), y Francisco José Hinojosa con el grueso de los servicios de sensores, que requerían un mayor esfuerzo en investigación, aunque a su vez, no precisaban de tanto esfuerzo en implementación. Una vez que disponíamos cada uno de unos esquemas generales, unimos las partes para poder comenzar a trabajar con el nodo solar completo. Una tarea que no resultó sencilla, pues ninguno teníamos experiencia en trabajar con MicroPython, ni mucho menos, en disponer de un sistema de recursos tan limitados. 51 Llegados al punto de poder ir añadiendo servicio tras servicio a la aplicación general, nos encontramos con el mayor problema del proyecto. La limitada memoria RAM que disponía el sistema para ejecutar la aplicación. Para ello, nuevamente tuvimos que colaborar como equipo para investigar que ocurría y poder resolverlo lo antes posible. Una vez resuelto el problema con la memoria del sistema, comenzamos a colaborar nuevamente, ya que nos resultaba complicado agregar el módulo de posicionamiento GPS, y tuvimos que realizar una investigación conjunta sobre el material que se nos había proporcionado, para finalmente, tras revisar completamente el código fuente de la librería del protocolo ubx, que ya había sido realizado en proyectos anteriores, encontrar un error en dicho código. Tras esto, ya teníamos todos los elementos disponibles en la aplicación, por lo que nuevamente dividimos el trabajo, quedándose Iván García con la implementación del servicio de conexión y con la configuración del Gateway con Node-RED, mientras que Francisco José Hinojosa se centró en implementar un servicio de gestión de errores, creando con ello la tabla de codificación vista en este documento, y en ir agregando este nuevo módulo a todos los demás, lo que también precisó de una nueva investigación de cada sensor para poder conocer los rangos de valores que podrían devolver. Después de volver a unir nuestro respectivo trabajo, surgieron nuevos errores que tuvimos que volver a retomar de forma conjunta para poder subsanarlos lo antes posible. Posteriormente, con todos los elementos ya unidos, trabajamos de forma conjunta para llevar a cabo la interacción Gateway-brokerMQTT, y a su vez, aprender a trabajar con el cliente ThingsBoard. Para lo cual fue necesaria la colaboración con el director del TFG, José Ignacio Gómez, que nos proporcionó el poder usar dicha plataforma en un servidor físico de la Facultad de Ciencias Físicas de la UCM. Por último, en la recta final del proyecto, Iván García continuó dando los últimos retoques a la aplicación software mientras que Francisco José Hinojosa se centró más en la labor de documentación de este proyecto. Para, finalmente, colaborar nuevamente realizando el análisis de tiempos de ejecución de la aplicación conjuntamente y, concluir esta documentación también de manera conjunta. Destacando nuevamente el papel de los directores de este Trabajo de Fin de Grado, que realizaron revisiones sucesivas del documento y, nos ayudaron a poder completarlo de una manera más correcta. 52 Conclusiones El proyecto se presentó como el desarrollo y despliegue de una red de nodos solares autónomos, y tras la resolución del proyecto, podemos concluir que se ha conseguido algún nodo autónomo preparado para su despliegue en un entorno real. A lo largo de la realización de este trabajo se presentaron algunos problemas, debido a los recursos limitados de los que se dispone en el nodo solar. El problema más importante al que nos enfrentamos fue la escasa cantidad de memoria RAM de la que se dispone en la placa LoPy, tras la instalación de su firmware, y cuya resolución ocupó gran parte del tiempo dedicado a este proyecto. Una vez que este problema quedó subsanado, descubrimos que los envíos periódicos de muestras no se realizaban en las frecuencias de envío deseadas. Para conocer el origen de dichos retrasos se pasó a la realización de un análisis de tiempos de ejecución para los procesos de recogida de las distintas muestras y de su posterior envío. Tras esto, llegamos a la conclusión de que el retraso se estaba produciendo en la creación y envío de los paquetes de datos de las muestras, lo que nos llevó a realizar modificaciones en la implementación de la recogida y envío de muestras. Para realizar el envío de muestras desde los nodos solares a un gateway cercano, se utiliza conexión LoRa ya que nos ofrece ventajas como un bajo consumo, conexión de largo alcance y un uso público de manera gratuita sin suscripción a un operador. En cambio, LoRa ofrece un bajo ancho de banda, quedando su uso limitado por las agencias reguladoras de cada región. Una posible continuación del proyecto se podría encaminar hacia el desarrollo de un nuevo servicio para la gestión de la batería, pudiendo regular el encendido o apagado de un nodo en función de la cantidad de batería disponible. Además, se podría realizar un estudio energético que permitiese obtener una visión más clara de la influencia del powerPin en el consumo energético para cierto rango de frecuencias de muestreo. Valorando un diseño alternativo para obtener un mayor ahorro de energía. Asimismo, cabe recordar que con el diseño de este proyecto queda habilitada la posibilidad de poder comunicarse con un nodo de manera remota desde el exterior. Parte que podría implementarse en un nuevo trabajo. Por último, con este proyecto ya se obtienen las muestras necesarias para el diseño de un modelo predictivo de radiación solar a corto plazo, lo que permite la evolución del proyecto general. 53 Conclusions The project was presented as the development and deployment of a autonomous solar nodes network, and after the resolution of the project, we can conclude that an autonomous solar node prepared for its deployment in a real environment has been achieved. Throughout the realization of this work some problems arose, due to the limited resources available in the solar node. The most important problem we faced was the small amount of RAM that is available on the LoPy board, after the installation of its firmware, and whose resolution took up a lot of the time dedicated to this project. Once this problem was corrected, we discovered that periodic sample shipments were not made at the desired delivery frequencies. In order to know the origin of these delays, an execution time analysis was carried out for the collection processes of the different samples and their subsequent delivery. After this we came to the conclusion that the delay was occurring in the creation and sending of the data packages of the samples, which led us to make changes in the implementation of the collection and shipment of samples. To send samples from the solar nodes to a nearby gateway, LoRa connection is used as it offers advantages such as low consumption, long-range connection and public use for free without subscription to an operator. In contrast, LoRa offers low bandwidth, its use being limited by the regulatory agencies of each region. A possible continuation of the project could be directed towards the development of a new service for the management of the battery, being able to regulate the turning on or turning off of a node depending on the amount of available battery. In addition, an energy study could be carried out to obtain a clearer vision of the influence of powerPin on energy consumption for a certain range of sampling frequencies. Valuing an alternative design to obtain greater energy savings. Also, remember that with the design of this project enables the possibility to communicate with a node remotely from the outside. Part that could be implemented in a new job. Finally, with this project, the necessary samples are already obtained for the design of a short-term predictive solar radiation model, which allows the evolution of the general project. 60