Sistema IoT para monitorización del estado de un centro de proceso de datos de grandes dimensiones

SISTEMA IoT PARA MONITORIZACIÓN DEL ESTADO DE UN CENTRO DE PROCESO DE DATOS DE GRANDES DIMENSIONES Ballesteros de Andrés, Carlos Sypko, Denys GRADO EN INGENIERÍA DE COMPUTADORES. FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID Trabajo Fin de Grado en Ingeniería de Computadores Madrid, 1 de junio de 2017 Directores: Igual Peña, Francisco Piñuel Moreno, Luis Autorización de difusión Ballesteros de Andrés, Carlos Sypko, Denys Madrid, a 1 de junio de 2017 Los abajo firmantes, matriculados en el Grado de Ingeniería de Computadores de la Facultad de Informática, autorizan a la Universidad Complutense de Madrid (UCM) a difundir y utilizar con fines académicos, no comerciales y mencionando expresamente a su autor el presente Trabajo Fin de Grado: “SISTEMA IoT PARA MONITORIZACIÓN DEL ESTADO DE UN CENTRO DE PROCESO DE DATOS DE GRANDES DIMENSIONES”, realizado durante el curso académico 2016-2017 bajo la dirección de Francisco Igual Peña y la co-dirección de Luis Piñuel Moreno en el Departamento de Arquitectura de Computadores y Automática, y a la Biblioteca de la UCM a depositarlo en el Archivo Institucional E-Prints Complutense con el objeto de incrementar la difusión, uso e impacto del trabajo en Internet y garantizar su preservación y acceso a largo plazo. Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional. “I have learned all kinds of things from my many mistakes. The one thing I never learn is to stop making them.” Joe Abercrombie, Last Argument of Kings 2 Agradecimientos A mis padres Olena y Oleksandr por todo su apoyo y paciencia. Denys A mi hermana y mis padres, gracias por todo. Carlos A Francisco Igual Peña y a Luis Piñuel Moreno por toda la ayuda prestada. A todos ellos, muchas gracias. 3 Índice general Índice i Índice de figuras v Índice de códigos vii Resumen viii Abstract ix 1. Introducción 2 1.1. Objetivos y visión general del sistema . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Requisitosiniciales ................................ 4 1.2.1. Nodosensor................................ 4 1.2.2. Persistencia de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.3. Comunicación bidireccional . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.4. Visualización y alarmas . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.5. Seguridad ................................. 5 1.3. Tecnologías y recursos utilizados . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Metodología y plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Nodo Sensor 10 2.1. Características hardware del nodo sensor . . . . . . . . . . . . . . . . . . . . 10 2.2. Infraestructuras software evaluadas . . . . . . . . . . . . . . . . . . . . . . . 12 i 2.3. Interfaces y protocolos de comunicación . . . . . . . . . . . . . . . . . . . . . 14 2.4. Obtencióndedatos................................ 16 2.4.1. Sensor de temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.2. INA219 .................................. 18 2.4.3. Fotoresistencia .............................. 19 2.5. Evaluacióndeautonomía............................. 20 3. Intercambio y almacenamiento de datos 24 3.1. MQTT....................................... 24 3.1.1. Broker................................... 26 3.2. Telegraf ...................................... 27 3.3. Persistenciadedatos ............................... 29 3.4. Seguridad ..................................... 30 3.5. Comunicación bidireccional . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4. Visualización de los datos, alarmas y despliegue del proyecto 36 4.1. Grafana ...................................... 37 4.1.1. Visualización de los datos . . . . . . . . . . . . . . . . . . . . . . . . 38 4.1.2. Alarmas y notificaciones . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1.3. Plugins, extensiones y APIs . . . . . . . . . . . . . . . . . . . . . . . 40 4.2. Despliegueenlanube............................... 40 4.3. CasosPrácticos.................................. 42 4.3.1. Monitorización de sala fría . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.2. Monitorización en laboratorio de Física de Materiales . . . . . . . . . 44 4.3.3. Monitorización del sistema de refrigeración en Facultad de Ciencias Físicas................................... 46 ii 5. Conclusiones 49 5.1. Conocimientos adquiridos y usados . . . . . . . . . . . . . . . . . . . . . . . 50 5.2. Desafíosencontrados ............................... 51 5.3. Posibles mejoras y objetivos futuros . . . . . . . . . . . . . . . . . . . . . . . 52 5.4. Aportación individual de los miembros del grupo al proyecto . . . . . . . . . 53 Bibliografía 56 A. Introduction 58 A.1.Aimsandsystemoverview............................ 58 A.2.Initialrequirements................................ 60 A.2.1.Sensornode................................ 60 A.2.2.Datapersistence ............................. 60 A.2.3. Two-way communication . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2.4. Visualization and alerts . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.2.5.Security .................................. 61 A.3. Technologies and resources used . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.4. Methodology and work plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 A.5. Structure of the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 B. Conclusions 65 B.1. Acquired and used knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . 66 B.2.Challengesfound ................................. 67 B.3. Improvements and future aims . . . . . . . . . . . . . . . . . . . . . . . . . . 68 B.4. Individual contribution of the members of the group to the project . . . . . . 69 C. Instrucciones de instalación 71 iii C.1. InfluxDB1..................................... 71 C.2. Telegraf2...................................... 72 C.3. Grafana3...................................... 72 C.4. Mosquitto4..................................... 73 C.5.Ejecución ..................................... 73 D. Firmware Arduino 75 E. Scripts LUA 84 E.1.init.lua....................................... 84 E.2.setup.lua...................................... 85 E.3.application.lua................................... 86 E.4.config.lua ..................................... 88 1https://docs.influxdata.com/influxdb/v1.2/introduction/installation/ 2https://docs.influxdata.com/telegraf/v1.2/introduction/installation/ 3https://docs.grafana.org/installation/ 4https://mosquitto.org/documentation/ iv Capítulo 1 Introducción IoT (Internet of Things o Internet de las Cosas) es un paradigma que consiste en interconectar los objetos de la vida cotidiana a través de Internet. A través de este paradigma, es posible desplegar grandes redes de sensores que monitorizan, en tiempo real y de forma conjunta multitud de parámetros y pueden, en caso de ser necesario, actuar en función de los valores observados y en base a parámetros o umbrales predefinidos. El concepto IoT se propuso en 1999 en el MIT por Kevin Ashton pero no ha sido hasta los últimos años cuando ha crecido su popularidad gracias entre otras cosas al auge de la tecnología de los smartphones. Según la empresa Gartner, en 2020 tendremos 12.863 millones unidades conectadas1, principalmente serán los dispositivos del mercado de Domótica . Esto nos permitirá controlar diferentes aparatos integrados en nuestros hogares tales como sistemas de climatización, sistemas de seguridad y sobre todo equipos multimedia. 1.1. Objetivos y visión general del sistema El objetivo principal de este proyecto es diseñar e implementar un sistema de bajo coste, robusto y fácilmente escalable que permita la monitorización en tiempo real de los factores 1http://www.gartner.com/newsroom/id/2636073 2 físicos que puedan tener relevancia en un Centro de Procesamiento de Datos, como humedad, temperatura, consumo o luz. Además, resulta deseable que el sistema desarrollado pueda extenderse a otros ámbitos en los que la monitorización de cualquier proceso relevante, sin que dicha migración resulte complicada para el usuario final. Dada la versatilidad del dashboard de visualización utilizado, que permite seleccionar de forma muy intuitiva qué datos queremos ver y cómo hacerlo, así como programar alarmas que nos notifiquen cuando algún parámetro sobrepase los valores que le indiquemos y la multitud de sensores que se pueden conectar al nodo, se pueden encontrar otras utilidades y casos prácticos como podremos ver más adelante, véase a la hora de monitorizar el circuito de refrigeración de la facultad de Ciencias Físicas o vigilar el correcto funcionamiento de los hornos de vacío del laboratorio de Física de Materiales. Figura 1.1: Esquema general de la infraestructura propuesta. 3 La Figura 1.1 ilustra un esquema general de la disposición e interrelación de los elementos que componen el sistema propuesto. 1.2. Requisitos iniciales Para el desarrollo del sistema se pretende crear un proyecto que cumpla, la menos, con las siguientes necesidades. 1.2.1. Nodo sensor 1. Se pretende que el dispositivo tenga un bajo coste económico, con el fin de que sea fácilmente instalable con una inversión mínima. 2. Queremos que además conlleve un bajo consumo, puesto que puede ser necesario instalar un gran número de dispositivos en la misma red eléctrica e incluso que estos estén alimentados por baterías. 3. Es obvio que, puesto que puede medir parámetros críticos, ha de ser un sistema robusto, por lo que necesitamos buen soporte a nivel software (firmware). 4. Al ser un proyecto bastante versátil, que puede ser montado en multitud de escenarios, necesitamos que el nodo sensor sea compatible con distintos tipos e interfaces de sensor. 5. Por último, es recomendable que el nodo que elijamos tenga un buen soporte e nivel de comunidad para poder resolver de forma rápida y precisa problemas con los que nos encontremos. 1.2.2. Persistencia de datos Otra de las necesidades con la que nos encontramos es la de poder consultar de forma inmediata un histórico de los datos recogidos por los Nodos sensores, por lo que se han de 4 valorar diferentes sistemas de bases de datos con el fin de que este almacenaje de información se realice de la forma más eficiente posible. 1.2.3. Comunicación bidireccional Puede darse el caso en el que necesitemos comunicarnos con el Nodo sensor de forma remota. Para ello es preciso establecer un mecanismo de recepción de mensajes en el mismo de forma que, en el supuesto de ser necesario, podamos dar órdenes o transmitir información al microcontrolador. 1.2.4. Visualización y alarmas Obviamente todo este sistema no tendría sentido si no se pudiesen consultar los datos obtenidos de una forma fácil e intuitiva. Así que es necesario buscar algún dashboard o plataforma de visualización que cumpla con dichos requisitos. Además es un requisito recomendable que, de alguna forma, se nos notificara cuando los parámetros recogidos por los sensores sobrepasen unos valores críticos. 1.2.5. Seguridad Por último, si conseguimos que la comunicación entre el microcontrolador y el Broker se realice de forma segura (con algún protocolo de encriptación y/o autenticación) y protegemos el acceso a los diferentes servicios podremos evitar problemas de seguridad y robos de información. 1.3. Tecnologías y recursos utilizados Dados los anteriores requisitos, se estructura el sistema IoT desarrollado en las siguientes cuatro capas principales: dispositivo, interfaz de comunicación, persistencia y visualización, 5 cuya funcionalidad y características se introducen a continuación y se detallarán en el resto del documento: El dispositivo. Encargado de la captura de datos, en nuestro caso, un Nodo de bajo coste ESP8266 implementado en diferentes placas (NodeMCU [5] o Feather HUZZAH [7]) al que se conectan diferentes sensores como el INA219 [1], DS18B20 [3] o DHT22 [2]. Interfaz de comunicación. Es la parte encargada de recibir y tratar la información que le envían los Nodos. Está implementado en un servidor Ubuntu al que se le han configurado servicios como Mosquitto [11] (recibe mensajes por MQTT [10]) y Telegraf [14] (trata los datos contenidos en esos mensajes). Persistencia. Es el eje principal del sistema para poder administrarlo de forma inteligente, esta gestionado mediante InfluxDB [13], que se encarga de almacenar los datos enviados por los Nodos. Visualización. Se realiza mediante el dashboard Grafana [15], que ofrece multitud de opciones de personalización para proporcionar toda la información recolectada al usuario de forma amigable, así como un sistema de alarmas. 1.4. Metodología y plan de trabajo La finalidad de este proyecto es diseñar una infraestructura de monitorización en tiempo real basada en IoT, seleccionando, integrando y configurando herramientas ya desarrolladas, e implementando la funcionalidad requerida en el nodo sensor a través del firmware correspondiente. Para ello el trabajo se ha dividido en dos partes, una de investigación y prueba y otra de desarrollo. 6 Se empieza evaluando diferentes frameworks y lenguajes de programación para los Nodos sensores, probando hasta tres lenguajes con sus respectivos IDEs. Como se verá, se ha decidido utilizar el entorno Arduino [6] por su soporte a través de comunidades en Internet, la multitud de librerías desarrolladas y la familiaridad con el lenguaje de programación C, así como por la estabilidad observada al utilizarlo sobre las placas NodeMCU. Una vez decidido, se comenzaron a valorar tecnologías para configurar los servicios del servidor. Este punto es sobre todo una labor de investigación a través de foros especializados en IoT, blogs o páginas de comparativas. Una vez decidido todo esto de forma paralela se trabaja en la programación de los Nodos sensores y en la instalación y configuración de los distintos servicios del servidor. Con un sistema totalmente estable y funcional el trabajo ha consistido en una última fase de evaluación de diferentes formas de mejorar la infraestructura: utilización de Cloud Computing en dominios como AWS oAzure, comunicación bidireccional entre servidor y nodo sensor o añadir nuevos sensores para medir nuevos parámetros o los ya existentes. 1.5. Estructura del documento La presente memoria se ha dividido en capítulos siguiendo la siguiente estructura: En el Capítulo 1 se introduce el proyecto, explicando los objetivos y requisitos de partida, las tecnologías y el plan de trabajo que se van a utilizar para llegar a los mismos. En el Capítulo 2 se habla de todos los aspectos relativos al Nodo Sensor. Desde la parte física y electrónica del mismo, hasta las plataformas software que se han eva7 luado y utilizado para la programación del mismo, pasando por los diferentes sensores utilizados y las interfaces de comunicación que utilizan. El Capítulo 3 explica del envío y recepción de los mensajes, entre el microcontrolador y el servidor de forma segura, incluyendo el tratamiento de los mismos y el almacenamiento en la base de datos. El Capítulo 4 trata sobre el despliegue en la nube de los distintos servicios, y de la visualización de los datos en el dashboard, así como de su sistema de alarmas. Además se comentan en esta sección casos prácticos reales donde se ha implementado el proyecto. En el Capítulo 5 se discuten las conclusiones alcanzadas después de desarrollar nuestro sistema, comparándolas con los requisitos iniciales y mencionando los conocimientos y habilidades que nos ha proporcionado la elaboración del mismo. 8 Capítulo 2 Nodo Sensor En este capítulo explicaremos el funcionamiento del nodo, basado en el módulo ESP8266 que es un chip de bajo costo Wi-Fi con una pila TCP/IP completa y un microcontrolador, así como de algunos de los sensores que se han instalado y configurado en el mismo. Este módulo se puede encontrar montado en diferentes placas de desarrollo. En nuestro caso hemos utilizado NodeMCU yFeather Huzzah, que además incluye un conector para baterías de tipo Lipo. Por lo demás tanto el método para programarlas como su funcionamiento son similares, por lo que nos centraremos en temas más relevantes como la plataforma software utilizada o los sensores configurados. 2.1. Características hardware del nodo sensor El módulo ESP8266 cuenta con un procesador que funciona a 80MHz utilizando una arquitectura de tipo RISC de 32 bits. Cuenta con una memoria RAM de 128KB y lo podemos encontrar con diferentes tamaños de memoria flash (los modelos que se han utlizado durante el desarrollo del proceso cuentan con 4MB). 10 En cuanto a los pines, cuenta con 16 pines GPIO, entre los que se incluye un conversor ADC de hasta 10 bits y soporte para protocolos de comunicación como I2C, SPI o 1-wire. Podemos ver en la Figura 2.1 el pinout de un ESP8266 montado sobre un NodeMCU, del que hablamremos a continuación. Figura 2.1: Pinout de ESP8266 sobre una placa NodeMCU. Una de las características más interesantes de este microcontrolador, al margen de su reducido precio (en torno a 5€comprándolo en España, menos de 3€si recurrimos a mercados asiáticos), es que incluye un módulo de conexión inalámbrica Wi-Fi 802.11 b/g/n con toda la pila TCP/IP instalada. Podemos encontrar el ESP8266 montado sobre placas de desarrollo de diferentes fabricantes como NodeMCU o Feather Huzzah (Figura 2.2). La diferencia entre estas placas es mínima, variando el número de pines GPIO disponibles (por ejemplo pueden sacrificarse pines para la conversión al microUSB que incluyen estas placas y que se usa para programar 11 import time import machine import onewire #Pin del sensor GPIO2/D4 dat = machine . Pin (2) #Creamos e l o bjeto OneWire ds = onewire . DS18B20( onewire . OneWire( dat ) ) #Escaneamos l o s d i s p o s i t i v o s del bus roms = ds . scan () print ('found d evices : ', roms ) ds . convert_temp() time . sleep_ms (750) f o r rom in roms : print ( ds . read_temp (rom) ) Código 2.3: MicroPython. Sensor DS18B20. 2.4.2. INA219 El INA219 es un chip fabricado por Texas Instruments (aunque pueden encontrarse clones en los mercados asiáticos), que permite medir parámetros de corriente continua como son voltaje e intensidad de entrada con una precisión de un 1 %, lo cual nos permite calcular de forma trivial otros parámetros relacionados como son la resistencia eléctrica o el consumo de potencia en vatios. El esquema de conexión con la placa Feather Huzzah es el mostrado en la Figura 2.7. El código para inicializar el bus I2Cy realizar las lecturas del sensor y los cálculos necesarios corresponde con el Código 2.4. #include <Adafruit_INA219 .h> #include <Wire . h> . . . Adafruit_INA219 ina219 ; //I2C . . . //Se i n i c i a e l sensor Wire . begin (4 ,5) ; //I2C −> sda , s c l ina219 . begin () ; . . . 18 // Lectura de l o s datos float shuntvoltage = ina219 . getShuntVoltage_mV () ; float busvoltage = ina219 . getBusVoltage_V ( ) ; float current_mA = ina219 . getCurrent_mA () ; float loadvoltage = busvoltage + ( shuntvoltage / 1000) ; float power_mW = ( current_mA ) ∗loadvoltage ; Código 2.4: Arduino. Sensor INA219. Figura 2.7: Esquema de conexión del sensor INA219. 2.4.3. Fotoresistencia El sensor de luz se ha configurado mediante una fotorresistencia conectada a un conversor analógico digital MCP3008 (Figura 2.8), que se comunica con el controlador mediante el protocolo SPI. El LDR (Light Dependent Resistor) o resistencia dependiente de la luz o también fotocélula, es una resistencia que varía su resistencia en función de la luz que incide sobre su superficie. Cuanto mayor sea la intensidad de la luz que incide en la superficie del LDR menor será su resistencia y cuanto menos luz incida mayor será su resistencia y por tanto menor es la lectura de voltaje que se realiza en el ESP8266. 19 Figura 2.8: Esquema de conexión del sensor LDR con MCP3008. A continuación, en el Código 2.5 se detallan las instrucciones necesarias para la inicialización, configuración y lectura de los parámetros proporcionados por este sensor: #include <SPI . h> #include <MCP3008. h> // Conversor ADC //∗∗ Definiciones ∗∗// #define CS_PIN 14 #define CLOCK_PIN 5 #define MOSI_PIN 13 #define MISO_PIN 12 . . . // Librer í a MCP MCP3008 adc (CLOCK_PIN, MOSI_PIN, MISO_PIN, CS_PIN) ; . . . // Lectura de l o s datos int val = adc . readADC(0) ; // leamos Canal 0 de MCP3008 ADC( pin 1) float voltage = ( val ∗3 . 3 ) / 1023 ; // Conversi ón de adc con v o l t a j e 3 .3 Código 2.5: Arduino. Sensor LDR y MCP3008. 2.5. Evaluación de autonomía Con el fin de que el sistema pueda instalarse sin dependencia de una línea de corriente eléctrica o bien de tener un respaldo en caso de corte del suministro eléctrico y puesto que la placa Feather Huzzah incluye una entrada de alimentación de tipo Lipo se han probado diferentes baterías para comprobar la duración de la vida de las mismas y por tanto que uso 20 podrían tener. El Primero de los modelos probados es del fabricante PKCELL, más concretamente el modelo LP503035(Figura 2.9), con una capacidad de 500mAh y un voltaje de salida de 3,7V. Esta batería puede encontrarse en mercados asiáticos por un precio que oscila los 2,5$. Figura 2.9: Primera de las baterías probadas para el proyecto. Este modelo dio unos resultados de autonomía relativamente buenos, utilizando en el microcontrolador el modo DeepSleep y haciendo que éste despertara cada sesenta segundos, se consiguió una duración de la vida útil de la batería algo superior a cincuenta horas. Por lo que se planteó que esta pila podría utilizarse para instalar el Nodo sensor de modo que que sea independiente de la red eléctrica. El segundo de los tipos de batería probados es una pila de botón de Litio recargable, conectada aun adaptador que permite la conexión de tipo Lipo, como puede verse en la Figura 2.10. Estas baterías tienen una capacidad de 120mAh, sin embargo su voltaje de salida es de 21 3,6V, lo que hace que se encuentre «en el límite» por lo que la duración de su vida útil bajo las mismas condiciones apenas llega a ocho horas. Sin embargo su bajo coste hace que deba ser tenida en cuenta como pila de respaldo para hipotéticos cortes de luz en caso de que el nodo sensor estuviese conectado a la red eléctrica. Figura 2.10: Batería conectada a adaptador Lipo. 22 Capítulo 3 Intercambio y almacenamiento de datos En este capítulo veremos como se realiza la comunicación de los datos, desde que los sensores de la ESP8266 los capturan hasta su llegada a la Base de Datos, más detalladamente hablaremos del protocolo de comunicación MQTT, del Broker usado y de Telegraf que se encarga de recolectar todos los datos, procesarlos si fuera necesario y mandarlos a InfluxDB. 3.1. MQTT MQTT es un protocolo usado para la comunicación machine-to-machine(M2M) en el Internet of Things. Es un protocolo cliente-servidor sobre el que se publican/suscriben los mensajes entre los dispositivos interconectados. Está orientado principalmente a la comunicación de sensores, debido a su bajo consumo de banda ancha y mínima sobrecarga puede ser utilizado en dispositivos con pocos recursos. Los mensajes se trasmiten por TCP-IP. Puede verse en el Código 3.1 la configuración para la inicialización del servicio y el envío de mensajes en nuestro poyecto. #include <PubSubClient . h> // Función para r e c i b i r l o s mensajes MQTT void mqtt_sus (char ∗topic , byte ∗payload , unsigned int length ) ; //Parámetros de conexi ón const char ∗mqtt_server = " 147.96.67.1 7 2 " ; const char ∗mqtt_user = " tfg −esp " ; const char ∗mqtt_pass = "∗∗∗∗∗∗∗∗∗"; 24 //TLS u t i l i z a e l puerto 8083 WiFiClientSecure w i f i C l i e n t ; // I n i c i a l i z a m o s la comunicaci ón PubSubClient c l i e n t ( mqtt_server , 8883 , w i f i C l i e n t ) ; c l i e n t . connect ( c l i e n t I d . c_str () , mqtt_user , mqtt_pass ) ; //Env í o de un mensaje con un determinado topic c l i e n t . publish ( " se n s o r s /nodemcu/temperatureDht" , temeperatureDhtString) ; Código 3.1: Arduino. Configuración MQTT. La arquitectura de MQTT sigue una topología de estrella, con un programa o dispositivo que actúa como servidor (Broker) el cual es el encargado de gestionar la red e intercambiar los mensajes. La comunicación se basa en los topics, que el cliente que publica el mensaje crea y a los que los nodos que pretenden consumirlo se suscriben. Un topic se representa mediante una cadena y tiene una estructura jerárquica. Cada nivel de la jerarquía se separa con el símbolo (/). De este modo, un posible ejemplo de jerarquía desarrollado en el ámbito de nuestro proyecto podría ser edificio1/planta1/sala1/arduino0/temperatura; la Figura 3.1 muestra la jerarquía MQTT planteada en el ámbito de nuestro sistema de monitorización de un centro de proceso de datos. Otra de las ventajas destacadas de este protocolo es que ofrece tres calidades de servicio para la entrega de mensajes: Como máximo una vez, a lo sumo el mensaje publicado se recibe una vez. Se puede producir pérdida de mensajes. Al menos una vez, donde se asegura que los mensajes llegan, pero se pueden producir duplicados. Exactamente una vez, se asegura que los mensajes llegan exactamente una sola vez. Se consideraron otros protocolos de comunicación, como HTTP, pero por la naturaleza de los dispositivos IoT, donde suele ser importante un bajo consumo de recursos, lo habitual 25 es utilizar protocolos optimizados como son MQTT. Al fin y al cabo todas estas características lo hacen ideal en este tipo de ecosistemas. Figura 3.1: Jerarquía MQTT planteada. 3.1.1. Broker Es precisamente el Broker el elemento encargado de gestionar la red y redirigir los mensajes a sus correspondientes suscriptores. En nuestro caso, se optó por utilizar uno de los Brokers más conocidos que existen para MQTT: Mosquitto. Mosquitto es un Broker desarrollado como código abierto por Eclipse1, ampliamente utilizado debido a su ligereza frente a otras alternativas como Mosca que al estar escrito en java consume más recursos, lo que nos permite fácilmente emplearlo en gran número de ambientes, incluso si éstos pueden 1http://mosquitto.org/ 26 aportar pocos recursos. A través de esta página2se puede descargar y consultar la documentación necesaria para instalarlo y usarlo en diferentes sistemas operativos. Dentro de la estructura que aparece en la Figura 3.1, nuestros únicos «emisores» son los sensores de Temperatura y Humedad que hemos colocado en la Planta1->Sala1->Arduino1 y Arduino2. Cada uno de ellos, lo vamos a asignar a un topic propio quedando el listado de topics de la siguiente forma: Sala1: edificio1/planta1/sala1/arduino0/temperatura edificio1/planta1/sala1/arduino0/humedad Para poder ver los mensajes publicados por los emisores hay que subscribirse a los dos topics anteriores. El Broker es una de las piezas principales del sistema ya que sin MQTT no tendríamos una forma tan eficiente de comunicación. Cabe constatar la sencillez con la que se puede instalar el sistema y tenerlo funcionando de forma instantánea. En nuestro proyecto el Broker está configurado para escuchar los mensajes a través de los puertos 1883 (por defecto) y 8883 (seguro). 3.2. Telegraf Es un agente, escrito en Go, que se encarga de recopilar métricas y distribuirlas a una alta gama de salidas, como pueden ser dashboards o bases de datos, de forma nativa. Este sistema se extiende no sólo a las salidas, sino también a las posibles entradas, que pueden ser 2https://mosquitto.org/download/ 27 PubSubClient c l i e n t ( mqtt_server , 8883 , w i f i C l i e n t ) ; void setup () { . . . c l i e n t . setCallback ( mqtt_sus ) ; } void reconnect() { while ( ! c l i e n t . connected ( ) ) { String c l i e n t I d = "ESP8266Client−"; c l i e n t I d += String ( random (0 x f f f f ) , HEX) ; i f ( c l i e n t . connect ( c l i e n t I d . c_str () , mqtt_user , mqtt_pass ) ) { S e r i a l . pr int ln ( " connected " ) ; c l i e n t . subs c ribe ( "ledStatus") ; //Nodo se sus c ri b e al top i c " ledStatus " } e l s e { S e r i a l . print ( " f a i l e d , rc=" ) ; S e r i a l . print ( c l i e n t . s tat e () ) ; S e r i a l . pr int ln ( " try again in 5 seconds " ) ; delay (2000) ; } } } void loop () { i f ( ! c l i e n t . connected () ) { reconnect() ; } . . . c l i e n t . loop ( ) ; // Permite al MqttCliente pro cesa r l o s mensajes e ntran te s } Código 3.3: Arduino. Comunicación Bidireccional. La aplicación práctica de esta funcionalidad radica en la posibilidad de configuración de ciertos parámetros del nodo sensor desde el prisma del usuario (por ejemplo, desde el dashboard); por ejemplo, parámetros como frecuencia de muestreo, dimensiones concretas a muestrear, o unidades de medida a utilizar podrían configurarse remotamente y de forma individual para cada nodo sensor. 34 Capítulo 4 Visualización de los datos, alarmas y despliegue del proyecto Durante la fase de programación de los ESP8266, cuando aún no se tenía definida la arquitectura de aplicaciones en el servidor, se utilizó la plataforma ThingsPeak [16](Figura 4.1). Se trata de una aplicación web, basada en el envío de mensajes mediante el protocolo HTTP, la cual nos sirvió para comprobar el correcto funcionamiento de los periféricos conectados a la placa. Es bastante intuitiva y fácil de utilizar, pero preferimos utilizar el protocolo MQTT por las ventajas que se han comentado anteriormente, además de ser más complicado de integrar en la arquitectura de nuestro proyecto, por ser un servicio externo y dependiente de terceros. Podemos encontrar en la red multitud de plataformas para el montaje de dashboards, tanto gratuitas como de pago, orientadas a la monitorización y al Internet de las Cosas. Así dimos con algunos como Plotly1, el cual es bastante potente en su versión de pago pero no tanto en la gratuita; Graphite2, que aunque promete ser muy funcional aún está en fases tempranas de desarrollo; o Freeboard 3, sencillo, intuitivo y fácil de utilizar pero que en su 1https://plot.ly/ 2https://github.com/graphite-project 3https://freeboard.io/ 36 versión gratuita no permite tener dashboards privadas. Figura 4.1: Ejemplo de funcionamiento de la aplicación ThingsPeak. Después de leer foros de comunidades interesadas en IoT, viendo como la gente hablaba maravillas de cierta plataforma que, pese a estar por aquel entonces aún en desarrollo, tenía muchísima funcionalidad nos decidimos por Grafana, cuyas características se detallan a continuación. 4.1. Grafana Grafana4es un visualizador en tiempo real de series temporales de datos que permite el uso de gráficos totalmente interactivos y editables, así como un sistema de alertas fácilmente configurables desde la interfaz gráfica de usuario. Otra de las utilidades que posee esta plataforma es un eficiente sistema de gestión de usuarios, mediante grupos y roles con distintos permisos. 4https://grafana.com/ 37 Por último hay un banco bastante importante de de extensiones para Grafana cuya instalación es muy intuitiva y que permiten añadir funcionalidades como paneles con mapas para geolocalizar la fuente de nuestras métricas o APIs para integrar distintos tipos de bases o fuentes de datos. 4.1.1. Visualización de los datos Grafana permite la visualizaión de los datos en formatos de gráfica muy variados con puntos, rayas, barras, etc. En nuestro caso y para series de datos temporales hemos considerado que lo mejor es mostrarlos de forma lineal como la gráfica de la Figura 4.2. La configuración de las gráficas se hace mediante consultas InfluxDB como por ejemplo: SELECT mean("value")FROM "mqtt_all" WHERE "topic" ='sensors/nodemcu/luminosidad' De esta forma se puede mostrar en una gráfica todos los valores que entran con un determinado topic. Figura 4.2: Visualización de la temperatura mediante líneas. 38 4.1.2. Alarmas y notificaciones Una de las funcionalidades que nosotros consideramos más útiles en nuestro proyecto, es el soporte para alertas que ofrece Grafana. Éstas pueden configurarse desde la interfaz gráfica y permite el envío notificaciones no sólo por email si no por otras plataformas como Slack oPagerDuty. Figura 4.3: Pantalla de configuración de alertas en una gráfica. El sistema permite definir las alertas, que funcionan como un trigger en la base de datos InfluxDB, de diferentes maneras (Figura 4.3). Así podemos encontrarnos con consultas de diferentes tipos para que la aplicación nos avise cuando un parámetro supere o baje de un determinado valor, cuando se deje de recibir dicho parámetro o consultas más complejas cómo por ejemplo que la media de los datos obtenidos en los últimos 5 minutos pase de un valor crítico. Podemos saber que gráficas tienen alertas configuradas, como la de la Figura Figura 4.4. Para ponerla en funcionamiento tuvimos que crear una cuenta de correo con el nombre 39 gr[email protected]om y especificamos la configuración SMTP (del servicio gMail) en el fichero de configuración de Grafana. Figura 4.4: Cuando una gráfica tiene una alerta configurada se muestra un icono con un corazón junto al nombre de la misma. 4.1.3. Plugins, extensiones y APIs Grafana ofrece una lista de extensiones5, que va aumentando a medida que distintos desarrolladores o empresas publican sus trabajos en la comunidad de usuarios. Podemos encontrar de varios tipos: diferentes formatos de visualización de gráficas, APIs para conectar con distintas bases de datos, aplicaciones independientes de Grafana, etc. 4.2. Despliegue en la nube A la hora de instalar los servicios se optaron por distintas alternativas, pero los tutores del proyecto nos facilitaron una máquina virtual, al que se puede acceder desde la dirección pera.dacya.ucm.es. Está máquina cuenta con el sistema operativo Ubuntu 16.04.1 y las siguientes características hardware virtualizadas: 5https://grafana.com/plugins 40 1GB de memoria RAM. 14GB de capacidad de disco duro. Procesador Intel Westmere, que funciona a 3GHz, con una memoría caché de 4 MB y que sólo utiliza un core. Por último y una vez teníamos el proyecto funcionando completamente, se decidió hacer una configuración similar a la que había instalada en el servidor, pero utilizando tecnologías de Cloud Computing, analizándose las siguientes plataformas para el despligue de la misma: Windows Azure. Es una plataforma de nube abierta y flexible que permite compilar, implementar y administrar aplicaciones rápidamente en una red global de centros de datos administrados por Microsoft. Puede compilar aplicaciones en cualquier lenguaje, herramienta o marco. Amazon Elastic Compute Cloud (EC2). Forma parte del conjunto de aplicaciones conocidas como Amazon Web Services. Proporciona capacidad informática con tamaño modificable en la nube. Amazon EC2 presenta un auténtico entorno informático virtual, que permite utilizar interfaces de servicio web (Figura 4.5) para iniciar instancias con distintos sistemas operativos, cargarlas con su entorno de aplicaciones personalizadas, gestionar sus permisos de acceso a la red y ejecutar su imagen utilizando los sistemas que desee. Debido a que Amazon nos ofrecía más servicios gratuitos así como crédito para gastar en su plataforma por darnos de alta en la misma como estudiantes universitarios, decidimos decantarnos por ésta. Además de ser más segura puesto que genera un fichero de clave para que sólo se pueda conectar de forma segura mediante TLS. 41 Figura 4.5: Panel de administración de Amazon E2C con la instancia de la máquina creada para el proyecto. 4.3. Casos Prácticos Dada la flexibilidad de nuestro proyecto se han encontrado diferentes aplicaciones de uso del mismo, algunas de las cuales ya están en funcionamiento y otra está proyectada para un futuro a corto plazo. 4.3.1. Monitorización de sala fría Siendo el objetivo inicial la monitorización de un CPD de grandes dimensiones no podíamos dar por finalizado el proyecto sin el despligue del mismo en una sala fría con un gran número de servidores, más concretamente uno de nuestros Nodos sensores se encuentra instalado en el laboratorio del Departamento de Arquitectura de Computadores y Automática en la Facultad de Físicas de la Universidad Complutense (Figura 4.6). Se requería en este caso la medición de la temperatura, humedad y luminosidad (a mo42 do de sensor de presencia) de dicha sala, por lo que se han configurado sensores DHT22, DS18B20 (a modo de respaldo) y una fotoresistencia. Figura 4.6: Nodo sensor instalado en sala fría. Todas las gráficas se han configurado con alertas para asegurar el correcto funcionamiento del sistema de refrigeración de la sala, tal como puede verse en la Figura 4.7. La figura muestra el estado de la monitorización de la sala durante un período de siete días, reportando temperatura (paneles superior izquierdo e inferior), humedad relativa (panel superior derecho) y luminosidad (panel central). Tanto en los paneles de temperatura como de luminosidad se han establecido las alarmas correspondientes, configuradas para enviar correos electrónicos al administrador del laboratorio al superar 25ªC y una luminosidad del 60 %. En los paneles, se pueden observar, mediante líneas verticales de color rojo y verde, los momentos en los que se han enviado avisos al superar el umbral establecido y al recuperar un valor aceptable. El sensor de luminosidad envía alarmas a modo de aviso de presencia en la sala. El sistema ha funcionado de forma estable durante un elevado número de días y 43 Al haber probado baterías de respaldo, está protegido contra hipotéticos cortes de luz. Además después de haber testado los servicios de cloud computing de Amazon, se ha comprobado que se puede instalar todo el sistema con relativa facilidad en un servidor externo de alta fiabilidad y disponibilidad. Es fácilmente escalable ya que se puede ampliar el número de nodos sensores con el único límite de las direcciones IPs disponibles en la red, puesto que se puede reutilizar el mismo código para programar todos los controladores. Además de todo esto, se puede afirmar que el sistema ofrece una gran versatilidad, ya que su funcionamiento es fácilmente extrapolable a otros ecosistemas, como la monitorización de un sistema de calefacción o de los parámetros físicos de un invernadero. 5.1. Conocimientos adquiridos y usados Hemos utilizado diversos conocimientos relativos a varias ramas de la informática y de las asignaturas estudiadas durante el transcurso del Grado: Los lenguajes de programación LUA y Python eran desconocidos para nosotros; no obstante con la base que tenemos a lo largo de la carrera resultó relativamente sencillo adquirir unas nociones básicas con las que manejarnos con ellos. El código que usa Arduino IDE, prácticamente igual a C no nos supuso ningún problema al estar muy familiarizados con este lenguaje; además, en las asignatura Programación de Sistemas y Dispositivos ySistemas Empotrados ya programamos periféricos sobre un microcontrolador, por lo que teníamos cierta experiencia en este ámbito. Por el lado de las comunicaciones entre Nodo y Broker, nos fueron de gran ayuda los conocimientos adquiridos en las asignaturas Redes yAmpliación de Redes a la hora de elegir protocolos a nivel de aplicación y transporte. También la asignatura optativa 50 Seguridad en Redes, así como temas tratados en Ética, Legislación y Profesión nos empujaron a encriptar los mensajes mediante TLS para que el intercambio de información fuera lo más seguro posible. Tampoco teníamos ninguna experiencia previa en bases de datos no relacionales, por lo que fue un tema totalmente novedoso. Afortunadamente, el formato de consultas utilizado por InfluxDB es similar a SQL, sí estudiado en la asignatura Bases de Datos y por tanto la adaptación no resultó complicada. No nos resultó complicado utilizar el servidor Linux puesto que estamos muy acostumbrados a trabajar en este Sistema Operativo, que estudiamos con bastante profundidad en Sistemas Operativos yAmpliación de Sistemas Operativos. Por último, la asignatura Ingeniería del Software nos dio unas nociones sobre cómo se debe planificar y gestionar un proyecto. Por otra parte los trabajos presentados a lo largo de toda la carrera, así como las diferentes presentaciones que hemos realizado en todas las asignaturas nos han venido muy bien a la hora de redactar la memoria y planificar la presentación de la misma. 5.2. Desafíos encontrados El primero de los problemas encontrado fue el desarrollo inicial con Lua. Si ya de por sí el lenguaje nos resultaba nuevo pronto nos topamos con que, al intentar que el controlador entrara en estado DeepSleep entre lecturas y envíos, éste no volvía a funcionar correctamente. Investigando por foros descubrimos que se trataba de un problema de las librerías del lenguaje por lo que, entre otros motivos, renunciamos a seguir avanzando en dicho framework. 51 No fue el único problema encontrado en relación a DeepSleep, puesto que una vez terminado el proyecto y ya en fase de investigación de posibles mejoras, intentamos añadir funcionalidades con comunicación bidireccional, haciendo que el sensor pudiera recibir mensajes del servidor. No obstante, al estar la placa dormida no se recibían esos mensajes y se perdían. Por lo que en un futuro y si se pensase en añadir esta funcionalidad habría que pensar si interesa aumentar el consumo, sobre todo si el sistema trabaja de forma autónoma conectado a una batería. Por último, otro de los desafíos que nos encontramos fue el hacer funcionar el sistema de alertas o alarmas. Cuando nos decidimos a usar Grafana en los foros de desarrolladores se comentaba que se estaba trabajando en este sistema, y prácticamente el día que se publicó la primera beta nosotros comenzamos a testearla, sin apenas documentación ni referencias. El usuario que habíamos asignado a Grafana en InfluxDB sólo tenía permisos de lectura, pero al funcionar las alertas como un trigger en la base de datos no podía ejecutarse al no tener permisos, detalle que conllevó cierto retraso en el desarrollo. La configuración del protocolo SMTP para el envío de correos electrónicos de alerta conllevó también cierto esfuerzo adicional. 5.3. Posibles mejoras y objetivos futuros Una de las primeras mejoras a implementar, cuya viabilidad ya se ha probado, es el despliegue de toda la infraestructura del servidor utilizando Cloud Computing. Plataformas como Azure de Windows y EC2 de Amazon Web Services podrían resultar económicas y totalmente factibles. Otro de los objetivos marcados a corto plazo es la instalación y configuración de diferentes 52 sensores como pueden ser proximidad, humo, presencia para poder utilizar el proyecto en diferentes ámbitos y ecosistemas de trabajo. Se nos ha propuesto el montaje del sistema en un invernadero, en la monitorización de un sistema de calefacción o el control de la temperatura de un horno. 5.4. Aportación individual de los miembros del grupo al proyecto Por lo general el trabajo se ha desarrollado de forma conjunta, organizando sesiones conjuntas para implementar de manera cooperativa los distintos aspectos del proyecto. Al comienzo del proyecto, mientras se evaluaban los distintos lenguajes de programación que se podían usar para configurar los nodos, Denys se encargó de probar más en profundidad MicroPython mientras Carlos investigaba con Lua para, después de poner nuestras respectivas conclusiones en común, programar de forma conjunta un primer script en Lua. Una vez decididos por Arduino por los motivos explicados en los apartados anteriores cada uno de nosotros comenzó el trabajo sobre una placa diferente (NodeMCU Denys y Feather Huzzah Carlos) para, de forma paralela, ir programando el funcionamiento de diferentes sensores mientras cada uno investigábamos diferentes tecnologías que se podrían usar en el servidor. Reuniendo cada dos semanas para poner en común nuestros avances y la información descubierta. Además en estas reuniones periódicas se aprovechó para instalar y configurar todos los parámetros necesarios para hacer funcionar los programas en el servidor. 53 Bibliografía [1] INA219 - DataSheet. https://cdn-shop.adafruit.com/datasheets/ina219.pdf. [2] DHT22 - DataSheet. https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf. [3] DS18B20 - DataSheet. https://cdn.sparkfun.com/datasheets/Sensors/Temp/DS18B20.pdf. [4] MAX31855 - DataSheet. https://datasheets.maximintegrated.com/en/ds/MAX31855.pdf. [5] NodeMCU - Documentación. https://nodemcu.readthedocs.io/en/dev/. [6] Arduino - Documentación. https://www.arduino.cc/. [7] FeatherHUZZAH - Documentación. https://learn.adafruit.com/adafruit-feather-huzzah-esp8266. [8] FeatherHUZZAH - Pinouts. https://learn.adafruit.com/adafruit-feather-huzzah-esp8266/pinouts. [9] NodeMCU - Pinouts. https://github.com/opendata-stuttgart/meta/wiki/Pinouts-NodeMCU-v2,-v3. 55 [10] MQTT - Documentación. http://mqtt.org/documentation. [11] Mosquitto - Broker. http://mosquitto.org/. [12] Mosquitto - TLS. https://mosquitto.org/man/mosquitto-tls-7.html. [13] InfluxDB - BBDD. https://docs.influxdata.com/influxdb/v1.2/. [14] Telegraf - Collect. https://docs.influxdata.com/telegraf/v1.2/. [15] Grafana - Dashboard. https://grafana.com/. [16] Thingspeak - Dashboard. https://thingspeak.com/. 56 Apéndice A Introduction IoT (Internet of Things) is a paradigm that consists of interconnecting the objects of everyday life through the Internet. Through this paradigm, it is possible to deploy large networks of sensors that monitor, in real time and jointly a multitude of parameters and can, if necessary, act on the observed values and based on predefined parameters or thresholds. The IoT concept was first presented by Kevin Ashton in 1999 at the MIT, but its popularity has only risen in recent years mainly due to the boom in the smart phones technology. According to Gartner, in 2020 there will be 12.863 million of things connected1, mainly the Home Automation Market devices. It will allow the users to control a series of integrated devices such as air conditioning systems, security infrastructures and multimedia tools. A.1. Aims and system overview The main purpose of this project is to create a low price, robust and easily escalated system to monitor in real time physical factors that might be relevant in a Data Processing Center, such as humidity, temperature, consumption or light. 1http://www.gartner.com/newsroom/id/2636073 58 In addition, it is desirable that the developed system may be extended to other areas in which the monitoring of any relevant process is crucial, without impact on the end user. Given the versatility of the visualization tool dashboard used, it allows to select in a very intuitive way what data we want to see and how to do it, as well as to program alarms that notify us when a parameter exceeds the values that we indicate and the multitude of sensors that can be connected to the node. It is possible to find other utilities and practical cases as we will see later, see when monitoring the refrigeration circuit of the Faculty of Physical Sciences or monitor the correct operation of vacuum furnaces of the Physics laboratory of Materials. Figure A.1 illustrates a scheme that serves to make us the idea of the general structure of the proposed system. Figura A.1: General scheme of the proposed infrastructure. 59 The backup batteries are protected against hypothetical courts of light. Besides after testing the Amazon cloud computing services, it was proven that it can all be installed with relative ease in an external server of high reliability. It is easily scalable since you can expand the number of sensor nodes with the only limit of the IPs addresses directions available in the network, since you can reuse the same code to program all the controllers. In addition, the system offers a huge versatility since its operation can be easily transferred to other ecosystems, like the monitoring of a heating system or the physical parameters of a greenhouse. B.1. Acquired and used knowledge We have used knowledge of several computing branches as well as knowledge from the subjects studied in the career. We did not know at first the programming languages LUA and Python, nevertheless with the base that we have obtained along the career, it did not cost us much to learn some basic notions for both languages The Arduino IDE code is practically the same used in C, so it was no problem for us since we are very familiarized with this language, besides that in the subject “Programación de Sistemas y Dispositivos” and “Sistemas Empotrados” we had already programed peripheral on a microcontroller, so we had some experience in this field. Regarding the communications between Node and Broker, it was a great help for us the knowledge obtained in the subjects “Redes y Ampliación de Redes” in order to choose protocols for application and transport. Also the “Seguridad en Redes”, as well as subjects treated in “Ética, Legislación y Profesión” pushed us to encrypt the messages by means of TLS so that the exchange of information was the safest possible. 66 Neither had we had any previous experience in no relational databases, it was a complete new ground for us. Luckily, the format of queries that it is used in InfluxDB is quite similar to SQL, which we have already studied in the subject “Bases de Datos”, so it was not difficult to become fluent in this language. It was not complicated to use the Linux server since we are very used to work with Operative Systems, which we study in the subject “Sistemas Operativos y Ampliación de Sistemas Operativos”. Finally, the subject “Ingeniería del Software” gave us some notions on how to schedule and manage a project. On the other hand, the deliverables handled along all the career, as well as the different presentations that we have made in all the classes have helped us elaborate the documentation and plan its presentation. B.2. Challenges found The first problem that we faced was when we started to develop with Lua. The language itself was very new to us and we soon faced a problem when we tried to put the controller on DeepSleep mode between readings and it did not work properly afterwards. After investigating in some forums, we discovered that is was a problem with the languages libraries so among other reasons, we refused to keep advancing with this framework. It was not the only problem that had with the DeepSleep, since once we had finished the project and decide to investigate improvements, we tried to add functionalities with bidirectional communication so the sensor could receive messages from the server. However, because the plate was asleep it did not receive these messages and they got lost. Having 67 said that, in the future if this functionality was to be implemented it would be first recommended to analyze weather the increase in consumption, especially if the system works of autonomous form connected to a battery. Finally, another of the challenges that we faced was to make work the alerts and alarms system. When we decide us to use Grafana, at the developer’s forums they were discussing working with this tool and basically the day that the first beta version was released we started testing it, without any documents nor references. The user that had assigned to Grafana in InfluxDB only had reading permissions, but since the alerts worked like a trigger in the database, it could not be executed due to not having permissions. We had lots of problems with this matter up until we found out what was causing the error. In addition to it, with the first settings files there were no clear specification regarding the configuration SMTP for the mailing. B.3. Improvements and future aims One of the first improvements to implement, whose feasibility has already being tested, is the deployment of all the server infrastructure using Cloud computing. Platforms like Azure of Windows and EC2 from Amazon Web Services could result economic and totally feasible. Another of the aims marked in the short term is the installation and configuration of different sensors as they can be vicinity, smoke, presence to be able to use the project in different fields and ecosystems of work. It has proposed to us the setting of the system in a greenhouse, for monitoring a heating system or the oven temperature control. 68 B.4. Individual contribution of the members of the group to the project Generally the project has been developed by the group jointly, we gathered to implement in a collaborative way the different tis project’s steps. At the beginning of the project, while we evaluated the distinct programming languages that could be used to configure the nodes, Denys was responsible to test in depth MicroPython while Carlos investigated with Lua in order to later, after sharing our perspectives and conclusions, we stated to program together the first script in Lua. Once we decided to use Arduino due to reasons explained in the previous sections, each one of us carried a plate home (NodeMCU Denys and Feather Huzzah Carlos) in order to work in parallel to program the operation of different sensors while each one investigated different technologies that could be used in the server. We gathered each two weeks to put in common our advances and the information discovered. At these periodic meetings we install and configure all the necessary parameters to do work the programs in the server. 69 Apéndice C Instrucciones de instalación Se proporcionan, como documentación adicional, las instrucciones y pasos básicos necesarios para la instalación y configuración de los distintos servicios utilizados para el desarrollo del proyecto. C.1. InfluxDB1 En desde la terminal y en el directorio home ejecutamos: $ wget https://dl.influxdata.com/influxdb/releases/influxdb_1.2.1_amd64.deb $ sudo dpkg -i influxdb_1.2.1_amd64.deb Después de la instalación podremos editar la configuración de la base de datos InfluxDB ubicada en el fichero /etc/influxdb/influxdb.conf . A continuación podremos acceder a la misma desde cualquier navegador web, para ello ello debemos abrir la URL de InfluxDB, que será la dirección ip del servidor en el que se ha instalado, accediendo desde el puerto 8083: http://ip:8083. 1https://docs.influxdata.com/influxdb/v1.2/introduction/installation/ 71 C.2. Telegraf2 Al igual que en el paso anterior, se ejecutan desde la consola de comandos ubicados en el directorio home las siguientes instrucciones: $ sudo wget https://dl.influxdata.com/telegraf/releases/telegraf_1.2.1_amd64.deb $ sudo dpkg -i telegraf_1.2.1_amd64.deb Una vez completada la instalación, desde el fichero de configuración /etc/telegraf/telegraf.conf se pueden insertar todos los parametros que nos hacen falta, como fuentes de datos de entrada y de salida. Por ejemplo la URL de nuestro servidor InfluxDB se indica en la sección llamada outputs.influxdb. C.3. Grafana3 En home ejecutamos desde la línea de comandos: $ sudo wget https://grafanarel.s3.amazonaws.com/builds/ grafana_4.1.2-1486989747_amd64.deb $ sudo dpkg -i grafana_4.1.2-1486989747_amd64.deb Una vez se ha iniciado el servicio sin problemas, ya podemos ir a nuestra URL por el puerto 3000 http://ip:3000 desde un explorador web y entrar a la aplicación con el usuario por defecto (user: admin, password: admin) para configurar desde la interfaz gráfica el resto de parámetros como dashboards, alarmas, usuarios y permisos, etc. 2https://docs.influxdata.com/telegraf/v1.2/introduction/installation/ 3https://docs.grafana.org/installation/ 72 C.4. Mosquitto4 Mosquitto es el Broker que vamos a utilizar para la recepción y manejo de los mensajes MQTT de nuestro sistema. Para instalarlo sólo tenemos que ejecutar en el directorio home la siguiente instrucción: $ sudo apt-get install mosquitto Para cambiar los diferentes parámetros del servicio como pueden ser autentificación, puertos, certificados de encriptación, etc., iremos al fichero de configuración ubicado en /etc/mosquitto/mosquitto.conf . Además, la herramienta Mqtt-Spy es una aplicación que puede ser útil para monitorizar la actividad del sistema en caso de dudar del correcto funcionamiento del mismo. C.5. Ejecución Para ejecutar hemos de cargar el programa del Apéndice D en la ESP8266 usando el Arduino IDE 5. Después hemos de levantar InfluxDB, Mosquitto y Grafana. Una vez que todos los sistemas están arrancados y funcionando accedemos a Grafana por la siguiente url http://ip:3000 y configuramos el origen de los datos como InfluxDB. 4https://mosquitto.org/documentation/ 5https://www.arduino.cc/en/main/software 73 Apéndice D Firmware Arduino A continuación se adjunta el código en Arduino que se ha utilizado para la instalación de todos los sensores y la inicialización de los distintos buses e interfaces que se han mencionado y explicado a lo largo del proyecto: 1//** Librerías **// 2#include <OneWire.h> // OneWire 3#include <DallasTemperature.h> // DS18B20 4#include <ESP8266WiFi.h> // WiFi 5#include <ESP8266WebServer.h> // TCP 6#include <MCP3008.h> // ADC 7#include <PubSubClient.h> // MQT 8#include <DHT.h> // DHT 9#include <Wire.h> // INA219 10 #include <WiFiClientSecure.h> // Cliente WiFi con soporte de TLS 11 #include <Adafruit_INA219.h> // INA219 12 #include "FS.h" // File System 13 14 //** Definiciones **// 15 /* GPIOS: En esta región se definen distintos GPIOS que se 16 usaran para establecer la comunicación con los periféricos. */ 17 //SPI 18 #define CS_PIN 14 19 #define CLOCK_PIN 5 75 224 client.disconnect(); 225 226 Serial.println("Closing WiFi connection..."); 227 WiFi.disconnect(); 228 delay(100); 229 230 // Configuramos el modo deepSleep 231 // WAKE_RF_DEFAULT, WAKE_RFCAL, WAKE_NO_RFCAL, WAKE_RF_DISABLED. 232 ESP.deepSleep(1000000 * timeSleep,WAKE_NO_RFCAL); 233 234 } 82 Apéndice E Scripts LUA Este código son los scripts LUA que fueron desarrollados como primera versión, pero desechada por problemas a la hora de configurar el modo DeepSleep. En ellos, vemos la conexión por WIFI, lecturas de los datos del sensor ds18b20 y el envío de mensajes a través de MQTT. E.1. init.lua 1app =require("application") 2config =require("config") 3setup =require("setup") 4-- https://github.com/nodemcu/nodemcu-firmware/tree/master/lua_modules 5-- DS18B20 one wire module for NODEMCU 6ds18b20 =require("ds18b20") 7 8setup.start() 84 E.2. setup.lua 1local module ={} 2 3local function wifi_wait_ip() 4if wifi.sta.getip()== nil then 5print("IP unavailable, Waiting...") 6else 7tmr.stop(1) 8print("\n====================================") 9print("ESP8266 mode is: " .. wifi.getmode()) 10 print("MAC address is: " .. wifi.ap.getmac()) 11 print("IP is "..wifi.sta.getip()) 12 print("====================================") 13 app.satart() 14 end 15 end 16 17 local function wifi_start(list_aps) 18 if list_aps then 19 -- 20 for key,value in pairs(list_aps) do 21 if config.SSID and config.SSID[key] then 22 wifi.setmode(wifi.STATION); 23 wifi.sta.config(key,config.SSID[key]) 24 wifi.sta.connect() 25 print("Connecting to " .. key .. " ...") 26 --config.SSID = nil -- can save memory 27 tmr.alarm(1,2500,1, wifi_wait_ip) 28 end 29 end 30 else 31 print("Error getting AP list") 32 end 85 33 end 34 35 function module.start() 36 print("Configuring Wifi ...") 37 wifi.setmode(wifi.STATION); 38 -- scan acces point 39 wifi.sta.getap(wifi_start) 40 end 41 42 return module E.3. application.lua 1local module ={} 2m=nil 3 4-- sends a simple ping to the broker 5local function send_ping() 6m:publish(config.ENDPOINT .. "ping","id=" .. config.ID,0,0) 7end 8 9-- sends my id to the broker for registration 10 local function register_myself() 11 m:subscribe(config.ENDPOINT .. config.ID,0,function(conn) 12 print("Successfully subscribed to data endpoint") 13 end) 14 end 15 16 local function mqtt_start() 17 m=mqtt.Client(config.ID, 120) 18 -- register message callback beforehand 19 m:on("message",function(conn, topic, data) 20 if data ~= nil then 21 print(topic .. ": " .. data) 86 22 -- do something, we have received a message 23 -- execute_command(data) 24 end 25 end) 26 -- connect to broker 27 m:connect(config.HOST, config.PORT, 0,1,function(con) 28 register_myself() 29 -- cnd then pings each 1000 milliseconds 30 tmr.stop(6) 31 tmr.alarm(6,1000,1, send_ping) 32 end) 33 end 34 35 local function ds18b20_start() 36 print("ds18b20_start....\n ") 37 -- pin sensor 38 --gpio0 = 3 --D3 39 gpio3 =nil -- default D9 40 gpio4 = 2 --D4 41 42 ds18b20.setup(gpio3) 43 addrs =ds18b20.addrs() 44 if (addrs ~= nil)then 45 print("Total DS18B20 sensors: "..table.getn(addrs)) 46 end 47 -- just read temperature 48 print("Temperature: "..ds18b20.read().."'C\n") 49 print("Temperature: "..ds18b20.read(nil,ds18b20.K).."'K") 50 -- release it after use 51 ds18b20 =nil 52 ds18b20 =nil 53 package.loaded["ds18b20"]=nil 54 end 55 87 56 function module.start() 57 ds18b20_start() 58 --mqtt_start() 59 end 60 61 return module E.4. config.lua 1local module ={} 2 3-- wifis array 4module.SSID ={} 5module.SSID["MOVISTAR_*"]="pass" 6module.SSID["MOVISTAR_*"]="pass" 7module.SSID["Orange_*"]="pass" 8 9module.HOST ="test.mosquitto.org" 10 module.PORT = 1883 11 -- topic 12 module.ENDPOINT ="nodemcu/" 13 14 return module 88