Io T aplicado al huerto urbano PDF

Preview

Summary

Proyecto...

Description

IoT aplicado al huerto urbano Hasta ahora la recogida de datos necesaria para estos estudios se realiza de forma manual por los investigadores o alumnos de asignaturas relacionadas. Con este proyecto queremos mejorar el proceso de recogida y procesado de datos mediante la utilización de “Internet de las cosas”. Por ello vamos a desarrollar un sistema basado en una red de “nodos sensores” capaces de recoger datos útiles para sus estudios, y una estación base que reciba, procese y muestre la información de una forma amigable para los usuarios. El sistema se completará con nodos actuadores capaces de recibir órdenes para actuar sobre las condiciones ambientales del cultivo (riego, iluminación, ventilación

Página | 1

Requerimientos del sistema Dentro de los requerimientos del sistema podemos diferenciar entre la funcionalidad básica y las opciones de mejoras.

•

FUNCIONALIDADES BÁSICAS DEL SISTEMA

▪

El dispositivo permanecerá la mayor parte del tiempo en deep-sleep para el ahorro de energía y cada x minutos se despertará, recogerá los valores de sus sensores y los enviará mediante mensaje MQTT con formato JSON. Junto a los datos medidos de los sensores en el mensaje MQTT también se enviarán datos para la identificación del dispositivo, configuración de este y el estado de conexión (ChipId, MAC, IP, SSID, RSSI, etc). Habrá que estructurar el mensaje en JSON para organizar la información de forma coherente. Además, recibirá por MQTT (también con formato JSON) mensajes de configuración.

▪

El funcionamiento del dispositivo debe optimizarse para conseguir el mínimo consumo de energía posible. Habrá que tomar medidas para minimizar el consumo.

▪

Se habilitará un sistema de actualización de programación inalámbrica (FOTA) del dispositivo.

▪

El sistema debe ser robusto, es decir, todos los sensores deben proporcionar una medida correcta. Se añadirá al mensaje MQTT un campo de control de errores que será tendrá valor cero (0) siempre que todos los datos sean correctos. Se debe manejar la situación de que un sensor se rompa, desconecte o pierda la calibración, entonces se enviarán valores -999 para ese sensor y se indicará mediante un código de error distinto de cero que permita identificar el problema.

Página | 2

▪

El dispositivo debe conectarse al broker MQTT con un identificador de cliente único.

▪

Se debe garantizar que los mensajes mandados desde el dispositivo llegan al bróker MQTT.

•

OPCIONES DE MEJORA

▪

Se enviará junto al resto de datos leídos de los sensores una marca de tiempo (timestamp). Esta información de tiempo la mantendrá actualizada un reloj de tiempo real externo, el RTC DS3231. Para poner en hora el RTC se usará un servidor NTP como cronos.uma.es (pero sólo si el reloj no está en hora o se recibe un mensaje forzando la puesta en hora).

▪

La actualización (FOTA) se intentará cada N reinicios en vez de hacerlo siempre.

▪

Añadir a los sensores utilizados un sensor analógico de humedad en el suelo. Será necesario usar al menos dos entradas ADC (radiación solar y humedad del suelo) cuando nuestro dispositivo solo cuenta con una. Utilizar el módulo ADS1015 (I2C) que proporciona 4 canales ADC con precisión de 12 bits.

▪

Se almacenarán los datos recibidos en una base datos mongoDB para su posterior recuperación.

▪

Se utilizará una pantalla OLED SSD1306 para mostrar la información de los sensores y estado del dispositivo. La información se actualizará en la pantalla en cada ciclo de lectura de los sensores y permanecerá encendida mostrando esta información mientras el dispositivo está en deep-sleep. Se debe investigar el consumo que supone esta opción y cómo afectaría a la autonomía de la batería.

▪

El dispositivo creará un punto de acceso WiFi propio que permita la conexión del usuario como cliente.

Página | 3

Diseño

Hardware

y

esquema

del

conexionado Para realizar el proyecto IoT, nos hemos basado en el uso de la placa NodeMCU v1.0, una plataforma IoT de código abierto basada en Arduino, la cual lleva incorporado el módulo ESP8266, un módulo WiFi que nos permite la conexión a diversos dispositivos tales como teléfonos, tablets u ordenadores. Además, la placa cuenta con un chip microcontrolador ESP32, que se encargará del procesamiento de la información. En el siguiente esquema podemos identificar la forma y los pines de la placa:

Figura 1. ESP8266.

Hemos empleado una serie de dispositivos y sensores que nos permiten registrar o mostrar los datos que necesitamos, el más básico de ellos es el DHT11, un sensor ampliamente conocido que nos permite registrar tanto la temperatura como la humedad del ambiente.

Página | 4

Cuenta con 4 pines, aunque nosotros solo emplearemos la alimentación (de 3 V a 5 V), la tierra y la línea de datos, que cuenta con su propio método para mandar los datos.

Figura 2. Sensor DHT11 y sus pines.

El bus de este sensor es de un cable y se usa tanto para comunicar y sincronizar el MCU y el sensor DHT11. Una comunicación entre el DHT11 y NodeMCU dura unos 4 ms, el sensor envía un total de 40 bits y comienza por el bit más significativo. Los datos de la humedad y la temperatura contienen parte entera y decimal. El formato de la transmisión viene dado por orden: -

8 bits parte entera de la humedad +

-

8 bits parte decimal de la humedad +

-

8 bits parte entera de la temperatura +

-

8 bits parte decimal de la temperatura +

-

8 bits de comprobación.

Si la transmisión de los datos ha sido correcta, los bits de comprobación deberían corresponderse con los 8 bits menos significativos de la suma de los 32 bits anteriores. El proceso de comunicación es el siguiente, en el momento que NodeMCU manda una señal de comienzo, el DHT11 cambia de estado de baja consumición a estado activo y espera a que termine la señal de comienzo. Una vez completada, el DHT11 manda la señal de respuesta de 40 bits de datos que contienen la humedad relativa, la temperatura y la

Página | 5

comprobación al NodeMCU. En el código podemos elegir qué datos son los que necesitamos. Sin la señal de comienzo el DHT11 se mantendrá a la espera de recibir una señal de comienzo en su modo de baja consumición.

Figura 3.

Para la conexión de este sensor, lo alimentaremos con la línea de alimentación común y se comunican con el NodeMCU mediante su pin D3.

Figura 4. Esquema de conexión I.

Otro de los sensores que hemos empleado es el DS1015, que nos permite medir la temperatura del suelo con un rango de medida deseado de -10°C a +85°C con una precisión Página | 6

de ±0.5°C. Aunque se nos haya proporcionado el encapsulado del sensor, este debe ir contenido en una sonda para tomar correctamente la temperatura. Este cuenta con 4 pines, de los cuales empleamos la alimentación (de 3 V a 5.5 V), la tierra y la señal de datos, que se dispone mediante un Bus One-Wire, que permite la conexión de múltiples esclavos. Además, permite la alimentación parasitaria, pero nosotros nos ceñiremos a la alimentación regular.

Figura 5. Sensor DS1015, sonda y los pines empleados.

El bus de este sensor emplea un cable empleando el método One-Wire y se usa para comunicar y sincronizar el NodeMCU y el sensor DS18B20. Una comunicación entre el DS18B20 y NodeMCU dura unos 2 ms de media, el sensor envía 16 bits en complemento a 1 separados en dos bytes almacenados en la ROM del sensor, 4 bits para la parte decimal y los 4 bits menos significativos de la parte entera para el primer byte y los 4 bits más significativos de la parte entera junto 4 bits de relleno para el segundo byte. La transmisión comienza por el bit menos significativo. El formato de la transmisión viene dado por orden: -

4 bits parte decimal de la temperatura +

-

12 bits parte entera de la temperatura (En realidad solo se emplean 8).

El proceso de comunicación es algo más complejo, por lo que solo se explicará el método que nosotros empleamos, con un solo dispositivo y alimentación directa.

1.

Inicialización: El maestro manda una señal de reset que recibe nuestro sensor, este a su vez le devuelve una señal de presencia. Esto se ejecuta cada vez que un comando ROM se utiliza.

Página | 7

Figura 6.

2. Comando ROM: El maestro manda una señal que afecta a uno o varios sensores. Dado que solo trabajamos con uno, la primera vez que se ejecute el programa mandará la instrucción READ FROM [33H] de uso exclusivo a un sensor, que lee los datos de la ROM del sensor (un total de 64 bits), incluyendo su dirección completa que usará en usos posteriores mediante el comando MATCH ROM [55h] para referirse a él y mandarle un comando de función.

3. Comando de función DS18B20: Dado que solo queremos leer la temperatura del esclavo solo se empleará el comando CONVERT T [44h]. Este comando inicia la conversión de la temperatura. Tras completarla, los datos de la temperatura son almacenados en los dos bytes de los registros de la temperatura y el DS18B20 vuelve a su estado de bajo consumo. Dado que el DS18B20 es usado en alimentación externa, el maestro puede pedir la lectura de los registros al terminar el comando Convert T y el DS18B20 responderá enviando un 0 mientras la temperatura está en proceso de conversión y un 1 cuando haya terminado, entonces se mantendrá a la espera de recibir una señal de reset en su modo de baja consumición.

Figura 7.

Página | 8

Para la conexión de este sensor, lo alimentaremos con la línea de alimentación común y se comunican con el NodeMCU mediante su pin D4.

Figura 8. Esquema de conexión II.

A continuación, analizaremos el reloj (DS3231), la pantalla (OLED SSD1306) y el bus analógico (ADS1015). Lo que tienen en común estos tres componentes es que emplean el bus IC2. El bus I2C requiere únicamente dos cables para su funcionamiento, uno para la señal de reloj (SCL) y otro para el envío de datos (SDA), para NodeMCU estos pines son el D1 y el D2, respectivamente. En el bus, cada dispositivo dispone de una dirección, que se emplea para acceder a los dispositivos de forma individual. Esta dirección puede ser fijada por hardware (como en el caso del bus analógico) o totalmente por software.

En general, cada dispositivo conectado al bus debe tener una dirección única. Si tenemos varios dispositivos similares tendremos que cambiar la dirección o, en caso de no ser posible, implementar un bus secundario.El bus I2C tiene una arquitectura de tipo maestro-esclavo. El dispositivo maestro inicia la comunicación con los esclavos, y puede mandar o recibir datos de los esclavos. Los esclavos no pueden iniciar la comunicación (el maestro tiene que Página | 9

preguntarles), ni hablar entre si directamente. El bus I2C es síncrono. El maestro proporciona una señal de reloj (SCL), que mantiene sincronizados a todos los dispositivos del bus. Cabe destacar que este bus no tiene capacidad para verificar que la información que pasa por él. Para poder realizar la comunicación con solo un cable de datos, el bus I2C emplea una trama (el formato de los datos enviados) amplia. La comunicación cuenta con: -

7 bits a la dirección del dispositivo esclavo con el que queremos comunicar.

-

Un bit restante indica si queremos enviar o recibir información.

-

Un bit de validación.

-

Uno o más bytes son los datos enviados o recibidos del esclavo.

-

Un bit de validación.

Reloj DS3231 El DS3231 es un reloj en tiempo real de extrema precisión de bajo coste, que emplea el bus I2C y con un oscilador de cristal termocompensado integrado. El dispositivo incorpora una opción de batería externa para ser capaz de seguir midiendo el tiempo de forma autónoma sin la alimentación principal. La integración del cristal permite asegurar el buen funcionamiento, aunque haya desgaste en el componente a lo largo del tiempo y reduce el número total de piezas a incroporar. El RTC contiene información sobre los segundos, minutos, horas, días, días de la semana, meses y años. El número de días del mes es ajustado automáticamente según el mes, e incluso si el año es bisiesto.

El reloj puede operar tanto en formato de 12:00 horas, con un indicador AM/PM o de 24:00 horas.

Este componente incorpora la opción de incluir dos alarmas programables para una hora concreta del día, así como una señal cuadrada programable. La dirección y los datos son transferidos mediante el bus I2C.

Página | 10

Figura 9. Reloj DS3231.

Como se puede ver, tenemos acceso a a 6 pines, de los cuales emplearemos 4 de ellos, la alimentación principal con VCC y GND y el bus I2C con SCL y SDA. Siendo 32K una referencia de 32 Kiloherzios para otros componentes y SQW, que se emplea tanto como un interruptor de entrada, como salida para las alarmas programadas.

Pantalla SSD1306 El SSD1306 es un CMOS OLED/PLED driver dispuesto en un único chip que contiene una pantalla compuesta por una matriz de puntos de diodos emisores de luz que consiste en 128 segmentos y 64 comunes, una memoria RAM y un oscilador, que reduce el número de componentes externos y la consumición. Este componente ha sido diseñado para ser una pantalla de tipo OLED con cátodo común. El SSD1306 posee control de contraste, de 256 niveles de iluminación.

Los datos o comandos pueden ser mandados a este componente en diversas arquitecturas de buses, entre ellas el I2C, que requiere de una alimentación de entre 1.65 V a 3.3 V para este bus. Es una buena elección para diversos proyectos que requieran de una pantalla compacta, pero con buena resolución, como sub-displays de móviles, reproductores MP3, calculadoras...

Página | 11

Figura 10. Pantalla SSD1306

Como podemos observar, tenemos acceso a a 7 pines, de los cuales emplearemos 4 de ellos, la alimentación principal con VCC y GND y el bus I2C con SCK y SDA. Siendo RES una señal para hacer reset a la pantalla, que no emplearemos, DC, una entrada analógica para seleccionar el nivel de brillo y CS un pin para seleccionar la dirección, en caso de que se necesite más de una pantalla.

Bus analógico ADS1015 El ADS1015 es un convertidor analógico/digital (ADCs) con una precisión 12 bits por lectura, de bajo consumo y compatieble con el bus I2C. The ADS1015 incorporate a low-drift referencia de tensión y un oscilador, también incorpora una ganancia de amplificación programable (PGA) y un comparador digital. Estas características, junto con su amplio rango de medida, de alimentación y su pequeño tamaño, hacen que el ADS1015 sea una buena opción para implementar un bus analógico en espacios reducidos. El ADS1015 puede alcanzar una frecuencia de 3300 muestras por segundo (SPS). La PGA permite rangos de entrada de ±256 mV a ±6.144 V, permitiendo unas medidas precisas para grandes o pqueños valores de entrada.

El dispositivo posee un multiplexor (MUX) que permite cuatro medidas de entrada analógicas. El ADS1015 puede operar en el modo continuo o en el modo de una sola captura. Los dispositivos se apagan automáticamente una vez haya terminado el modo de una sola captura, por lo tanto, la consumición de energía se reduce considerablemente en los periodos de espera. Página | 12

Figura 11. Bus analógico ADS1015.

Como se puede ver, tenemos acceso a 10 pines, de los cuales emplearemos 6 de ellos, la alimentación principal con VCC y GND , el bus I2C con SCL y SDA y las entradas analógicas A0 y A1. Siendo ADDR la selección de dirección que podemos poner a tierra o dejar desconectada, ALERT, una señal de salida que advierte de que la conversión se ha realizado y A2 y A3, las entradas analógicas que no emplearemos.

Conexión Bus I2C Empleando un bus I2C, la transmisión de datos se estandariza y se simplifica, el esclavo puede leer o escribir en el bus. Para la operación de escritura por parte del maestro y de lectura del esclavo, en la línea SDA este mandará un bit que alerta a los componentes del bus de que se va a recibir una dirección que puede referirse a uno de ellos, la dirección del componente elegido y un bit adicional para indicar si el maestro va a mandar o recibir información, 0 para escribir, 1 para leer.

El esclavo referido mandará un bit para reconocer que ha comprendido la instrucción, la mayoría de los esclavos no referidos quedarán en segundo plano y a continuación el maestro mandará el número de bytes que necesita escribir, una vez que el componente lo haya recibido, mandará otro bit de validación y una vez que el maestro lo haya recibido, mandará la primera palabra y quedará a la espera de la señal de validación del componente. De este modo se transmitirán tantas palabras de 8 bits como haya indicado el maestro, con una señal de validación por parte del esclavo tras cada una de ellas, para indicar que lo ha

Página | 13

recibido correctamente. Una vez el maestro haya mandado todas las palabras, mandara un bit de parada para cesar el flujo de información con el esclavo seleccionado. Quedando el esclavo a la espera de la próxima instrucción.

Figura 12.

Para la operación de lectura por parte del maestro y de escritura del esclavo, el maestro se referirá de la misma forma al esclavo, con un bit de comienzo, su dirección y con un bit de lectura, 1, que el esclavo debe reconocer mediante un bit de validación.

Pero en este caso, se invertirán los papeles, el esclavo será el que manda por el bus el número de bytes que va a recibir y el maestro tendrá que validar los valores que le sean mandados mediante el bus por parte del esclavo, mandando señales de reconocimiento palabra por palabra, para que el esclavo pueda asegurarse de que ya ha recibido la información el maestro y puede a proceder con la siguiente palabra. Aun así, será el maestro que verifique que todos los bytes han sido recibidos y el que termine la conexión entre ambos.

Figura 13.

Para la conexión de estos componentes, simplemente debemos alimentarlos con la línea de

Página | 14

alimentación común y se comunicarlos con el NodeMCU mediante la línea de I2C.

Las direcciones para que la placa pueda conectarse con los dispositivos son: -

Reloj (DS3231): 0x68

-

Pantalla (SSD1306): 0x3c

-

Bus (ADS1015): 0x48

Figura 13. Esquema de conexión III.

Además, emplearemos un sensor de humedad del suelo, el HL-69, que consiste en dos placas separadas entre sí por una distancia determinada. Ambas placas están recubiertas de una capa de material conductor. Si existe humedad en el suelo se creará un puente entre una punta y otra, lo que será detectado por un circuito de control con un amplificador operacional que será el encargado de transformar la conductividad registrada a un valor analógico que podrá ser leído por Arduino.

El circuito de control es el que posee las resistencias limitadoras de corriente y es el encargado

de

alimentar

el

módulo

YL-83.

Posee

un

amplificador

operacional,

específicamente el circuito integrado LM392. Este es el encargado de amplificar el pequeño diferencial de voltaje que se general cuando se genera un puente (o su ausencia) entre las puntas del módulo. Aquí es donde se genera la señ...