MODELO DE RED DE ESTACIONES METEOROL ´ OGICAS MODULARES CON PLATAFORMA IOT PRESENTADO POR JEFFERSON RICARDO CHIVATA CASTRO COD: 20102005059 UNIVERSIDAD DISTRITAL FRANCISCO JOS ´ E DE CALDAS FACULTAD DE INGENIERIA INGENIERIA ELECTR ´ ONICA BOGOT ´ A D.C. 2017
98
Embed
PRESENTADO POR JEFFERSON RICARDO CHIVATA CASTRO COD ...repository.udistrital.edu.co/bitstream/11349/7429/... · Disenar~ e implementar un modelo de red de estaciones meteorol ogicas
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
MODELO DE RED DE ESTACIONES METEOROLOGICAS
MODULARES CON PLATAFORMA IOT
PRESENTADO POR
JEFFERSON RICARDO CHIVATA CASTRO
COD: 20102005059
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
FACULTAD DE INGENIERIA
INGENIERIA ELECTRONICA
BOGOTA D.C.
2017
MODELO DE RED DE ESTACIONES METEOROLOGICAS
MODULARES CON PLATAFORMA IOT
PRESENTADO POR
JEFFERSON RICARDO CHIVATA CASTRO
COD: 20102005059
Proyecto de grado para optar por el tıtulo de Ingeniero Electronico
5. SOLUCIÓN EN LA NUBE PARA PERMITIR LA GESTIÓN DE LA IN-FORMACIÓN 42
6. CASO DE USO DE RECEPCIÓN Y ENVÍO DE DATOS REMOTAMEN-TE 453
7. CONCLUSIONES 54
8. REFERENCIAS Y ANEXOS 55
4
1. RESUMEN
En Agosto del ano 2015 en la Universidad Distrital se realizo un trabajo como proyecto de gra-
do para la carrera de Ingenierıa Electronica, el cual se titula ’DISENO DE UNA ESTACION
METEOROLOGICA MODULAR QUE PERMITA CONEXION REMOTA Y GESTION DE
DATOS VIA INTERNET’[1], en donde se muestra una propuesta de diseno e implementacion
de un prototipo de estacion meteorologica modular. Los datos se obtienen por medio de una
sola tarjeta, de la estacion meteorologica, y se envıan por modulos Xbee a Raspberry Pi que
se utiliza como elemento de salida a internet. En esta tarjeta Raspberry Pi se implementa un
programa de codigo abierto llamado WeeWX el cual se encarga de subir las mediciones a una
base de datos MySQL que corre en un servidor remoto donde se presentan a traves de una
unica aplicacion web alojada allı mismo los datos obtenidos. Ver Figura 1.
Figura 1: Esquema de funcionamiento unidireccional. Fuente: Diseno de una estacion meteo-rologica modular que permita conexion remota y gestion de datos via internet. UniversidadDistrital, Facultad de ingenierıa, proyecto de grado.
Basado en el trabajo anterior, en este proyecto se propone un modelo mas completo y adapta-
ble que permite la conexion modular de una forma mas sencilla y que la informacion tenga la
posibilidad de viajar en ambos sentidos (bidireccionalmente), con un recuadro de un extremo
denominado ’Estaciones Meteorologicas modulares’ que representa el conjunto de estaciones
en su totalidad, y del otro lado un recuadro denominado ’Dispositivos de visualizacion y/o
control’ que representa los diferentes dispositivos electronicos que interactuan a traves de otro
elemento llamado ’internet’ con el otro extremo. Ver Figura 2.
5
Figura 2: Diagrama bidireccional general del sistema
Se describe a lo largo de este documento la estrategia para lograr el concepto de IoT por
medio de analizar en un sentido el flujo de los datos de adquisicion (desde los sensores) y en
el sentido contrario a este flujo los datos de control (desde los Clientes Web), lo cual permite
que en efecto de forma remota se puedan monitorear y a la vez realizar procesos de control al
sistema. Usando la estrategia del protocolo de maquina-maquina llamado MQTT se realiza el
envıo de los datos de medicion y de control ’publicandolos’ a nombre de una ruta en particular,
y para la recepcion de los datos a traves de la ’suscripcion’ a la ruta ya creada.
6
2. INTRODUCCION
El clima es uno de los temas mas estudiados a nivel mundial desde diferentes ramas del
conocimiento, posicionandose como uno de los problemas modernos mas importantes y de
mayor relevancia junto con el crecimiento poblacional[2]. Lo anterior se debe a que el clima
influencia de forma directa positiva o negativa en las actividades economicas, en campos
como el agrıcola, de pesca, construccion, entre otros [3]. En el caso especifico de Colombia,
se pueden evidenciar cambios climaticos de larga cobertura, ademas de microclimas diversos,
gracias a aspectos geograficos y atmosfericos que generan diferentes formas de fenomenos
meteorologicos causados por precipitaciones, radiacion solar, temperatura, sistemas de vientos,
altitud, continentalidad y humedad atmosferica[4].
Colombia cuenta actualmente con el Instituto de Hidrologıa, Meteorologıa y Estudios Am-
bientales IDEAM, que es una entidad publica encargada de prestar servicios de gestion de
informacion sobre el estado y las dinamicas de los recursos naturales y del medio ambiente[5],
enfocandose principalmente en el estudio del clima para con esto poder prevenir los efectos de
variabilidad climatica como El Nino y La Nina[6]. Sin embargo, cabe resaltar que para el 2012
solo el 12 % de las estaciones son automaticas, es decir que trasmiten datos en tiempo real[1];
esto genera un retraso en el uso de dichos datos y por ende, dificultades en modelamientos
climatologicos como por ejemplo la prediccion del clima para periodos cortos.
Dicho lo anterior, para diferentes estudios realizados ya sea por entidades nacionales publicas
o particulares, es necesario contar con multiple informacion meteorologica automatica, y en
lo posible de facil acceso, para lo cual el IDEAM debe administrar los datos de las variables
obtenidas en diferentes estaciones meteorologicas distribuidas por todo el territorio colombiano
de forma eficiente. No obstante, dicha informacion aunque puede ser adquirida libremente
debido a que es de caracter publico, es necesario dirigirse a un punto de atencion del IDEAM
y presentar una solicitud especificando la periodicidad de los datos y el codigo de la estacion o
estaciones mas cercanas al punto de interes y luego de haber transcurrido el tiempo establecido
es posible obtener la informacion, lo cual lo hace un proceso de consulta dispendioso[5].
Actualmente se han desarrollado estaciones meteorologicas modulares al alcance de cualquier
organizacion o persona interesada en meteorologıa y climatologıa que desee tener indepen-
dencia en la obtencion de datos para uso particular como es el caso de un proyecto de grado
de la Universidad Distrital Francisco Jose de Caldas, en donde se desarrollo una estacion
meteorologica la cual se conecta a internet para el envıo de los datos pero de forma unidirec-
cional con un modelamiento individual (solo una estacion y solo un destinatario web)[7]. En
consecuencia se plantea la siguiente pregunta: ¿Es posible disenar un modelo de red con mas
de una estacion meteorologica modular donde se integre los datos de dichas estaciones imple-
mentadas localmente y conectadas a internet, para que diferentes usuarios puedan administrar
remotamente la informacion de forma bidireccional de acuerdo a su interes particular?7
3. OBJETIVOS
3.1. Objetivo General
Disenar e implementar un modelo de red de estaciones meteorologicas modulares locales uti-
lizando el internet de las cosas (IoT).
3.2. Objetivos Especıficos
Disenar e implementar un sistema de forma modular para entregar y recibir datos a un
sistema conectado a internet.
Disenar e implementar un sistema en la nube que permita la gestion de la informacion
de una red de estaciones meteorologicas remotas que integran diferentes sensores y
actuadores aprovechando las caracterısticas de IoT.
Comprobar la integracion y unificacion de la informacion obtenida de la red de Esta-
ciones Meteorologicas a traves de Internet de forma bidireccional en un aplicativo web
remoto.
8
4. RED DE ESTACIONES METEOROLOGICAS
4.1. DISENO DE LA ARQUITECTURA DE HARDWARE
Primero que todo es importante definir cada uno de los elementos que conforman de manera
general el sistema para que de esta manera se logre una debida integracion de las soluciones
de diseno particulares.
En la Figura 3, se muestra detallado solo el extremo de las ’Estaciones Meteorologicas mo-
dulares’ de la Figura 2 ya que para este caso es el unico que cuenta realmente con un diseno
de Hardware, en donde basicamente se inicia de izquierda a derecha con unos elementos de
adquisicion y actuadores que interactuan con una estacion meteorologica correspondiente,
las cuales por medio de un modulo de comunicacion, que en este caso ya se define como
inalambrico por facilidad en el modo de uso, se les permite el envıo de forma bidireccional
de la informacion con un elemento de salida en comun con conexion a internet denominado
Gateway. Este modelo se estara desarrollando en los siguientes enumerados.
Figura 3: Modelo general con ambos sentidos de flujo de la informacion
9
Para las pruebas del desarrollo de este proyecto se utilizo la tarjeta de desarrollo LaunchPad
MSP-430F5529LP de Texas Instrument, ya que se considera un kit de desarrollo economico y
sencillo para programar en lenguajes de bajo y medio nivel el microcontrolador MSP430F5529
en donde toda la tarjeta en su mayorıa es de proposito general para el control de las funciona-
lidades del mismo. Ademas ofrece una manera facil de comenzar a desarrollar en el MSP430,
con emulacion para depuracion. Ver Figura 4.
Figura 4: Tarjeta de desarrollo LaunchPad MSP-EXP430F5529LP. Fuente:www.ti.com/lit/ug/slau533c/slau533c.pdf
Cuadro 1: Caracteristicas mas sobresalientes de LaunchPad MSP430F5529LP [8]Caracteristica Descripcion
Emulador Lite eZ-FET, con la aplicacion UART. (Open-source)
Pines 40 Conectores configurables hembra y macho
Puertos USB Capacidad para emular y desarrollar aplicaciones USB con un solo
cable USB. Hub USB.
Consumo energetico Bus de 5V reducido a 3.3 V usando un convertidor dc-dc
La interfaz de usuario que trae se limita de forma sencilla a botones y LED’s, y de forma
externa la salida a pantallas u otros modulos por medio de sus pines (Ver Cuadro 1) pre-
viamente configurados del microcontrolador MSP430F5529 (Ver Figura 5) el cual muestra
caracteristicas relevantes en el Cuatro 2.
10
Figura 5: Asignacion de pines microcontrolador MSP-EXP430F5529. Fuente:http://www.ti.com/lit/ds/symlink/msp430f5529.pdf
Cuadro 2: Caracteristicas mas sobresalientes de microcontrolador MSP430F5529 [9]Caracteristica Descripcion
CPU 25MHz 16-bit
Memoria RAM 8 KB
GPIO Pins 63
Consumo energetico 3.6 V hasta 1.8 V
4.1.1. Elemento de adquisicion de datos y actuadores
Si bien cada Estacion Meteorologica se plantea como un elemento integral, el flujo de la
informacion para algunos de los elementos que la conforman tales como las unidades finales
(actuadores y dentro de los elementos de adquisicion los sensores), en un sentido estricto no
es bidireccionales o las unidades no permiten el flujo de la informacion en mas de un solo
sentido por las propiedades mismas del Hardware ya sea solo haciendo entrega datos o solo
recibiendo datos respectivamente.
Elemento de adquisicion de datos
Una de las caracterısticas mas importantes en relacion con un usuario final es la facilidad de
uso que un dispositivo provee, por tal motivo se plantea que la estacion meteorologica sea
modular, es decir que permita la conexion de modulos a la misma; sin embargo esta conexion
de los modulos basicamente esta direccionada a que sea conectar y usar (Plug-and-Play). Por11
tal razon es que se debe disenar cada modulo o elemento de adquisicion como un circuito de
interfaz sensor-microcontrolador, de modo que permita directamente ser anadido o quitado a
una estacion meteorologica local como se muestra en la Figura 6.
Figura 6: Diagrama de interfaz directa para elemento de adquisicion
Para lograr la conexion de diferentes modulos al mismo tiempo en una estacion en particular,
se disena la comunicacion con I2C entre el microntrolador del elemento de adquisicion (slave) y
el microcontrolador de la estacion (master); utilizando entre todos los elementos de adquisicion
la topologıa en bus en donde solo hay un canal de comunicaciones y todos los dispositivos
comparten el mismo canal.
Figura 7: Diagrama de conexion I2C de los elementos de adquisicion a la estacion
Como parte del diseno de Hardware es importante agregar que para el correcto funcionamiento
de I2C, es necesario anadir dos resistencias de Pull-up; es decir una resistencia de cada una
de las lıneas del Bus de Datos hacia una fuente de alimentacion (VCC), la cual sera colocada
o asumida por la tarjeta de la estacion meteorologica, por lo tanto, no se tendran en cuenta
para el diseno de los diferentes modulos de adquisicion de datos.12
Con base a lo anterior, en el Software de Easily Applicable Graphical Layout Editor - Eagle,
el cual es un programa que permite el diseno de diagramas y PCB’s, que tiene una gran
cantidad de herramientas, librerıas y funcionalidades que permite de forma facil y profesional
la creacion de tarjetas electronicas, se hace el diseno de cada uno los componentes que se
necesitan para el correcto funcionamiento de los elementos de adquisicion.
En primera instancia, en la Figura 8 se encuentra una parte del esquematico en donde se
muestra como parte esencial el microcontrolador de la tarjeta, las partes basicas para su
correcto funcionamiento dentro de lo cual esta el reloj, un boton de Reset y voltajes de
referencia.
Figura 8: Esquematico con Microcontrolador, reloj y voltajes de referencia disenado en EA-GLE.
Por otra parte, en la Figura 9 se encuentra las conexiones a puertos de una forma generica,
ya que en este caso se pretende por cuestion de costos que se pueda utilizar el mismo diseno
y tarjeta para que interactue de una forma mas sencilla con cualquier sensor correctamente
configurado que se quiera acoplar. Cuando se utiliza con un diseno de tarjeta de proposito
especıfico, evidentemente la cantidad de conexiones se reduce de manera notoria tanto en
tamano como en versatilidad.13
Figura 9: Esquematico con puertos de conexion y testigos disenado en EAGLE.
Una vez se genera toda la parte referente al esquematico, se hacer la relacion y organizacion
de cada uno de los componentes sobre la tarjeta o board de la manera mas conveniente para
la interaccion con la misma. Para este caso en la parte superior derecha se disena la tarjeta
para que los pines de programacion y alimentacion queden un poco mas aislados y visibles a
la perspectiva del usuario. En la parte izquierda y derecha de la tarjeta se propone dos buses
de datos de que pueden ser utilizados de forma generica par a los sensores que se quieran
utilizar. Ademas la tarjeta cuenta con un testigo LED y un boton de Reset. Ver Figura 10.
Figura 10: PCB final de tarjeta del sensor disenada en EAGLE.
14
Es importante igualmente visualizar en un visor de paquetes los componentes en tercera
dimension y ası dar una mejor idea del modelo y que va de acuerdo a lo propuesto. Ver Figura
11.
Figura 11: Visualizacion en tercera dimension de la PCB con sus compenentes. Fuente:http://3dbrdviewer.cytec.bg/
Una vez terminado el diseno de la tarjeta encargada de recibir los sensores; en el costado
izquierdo de la Figura 12 se muestra la foto de la PCB en un estado finalizado pero sin
componentes y en el lado derecho de la misma imagen una foto donde los componentes, en su
mayorıa superficiales, han sido debidamente colocados y probados para garantizar el correcto
funcionamiento.
Figura 12: Resultado final de la tarjeta para los sensores
Para la programacion de las tarjetas se utilizo Code Composer Studio, un entorno de desa-
rrollo integrado (IDE) de TI (Texas Instruments) para microcontroladores, ya sea la creacion15
y edicion de codigo fuente, compilacion, depuracion e integracion del programa al microcon-
trolador o procesadores integrados. Incluye una optimizacion del compilador C/C++. El IDE
es de media dificultad de uso pero proporciona buena documentacion para el desarrollo de
aplicaciones de sistemas embebidos.
Para finalizar se describiran de forma sencilla y puntual algunos de los sensores mas comunes
y las variables que se pueden medir recopilados en el Cuadro 3.
Cuadro 3: Variables principales con su respectivo intrumento de medicion[10]Variable Instrumento
Direccion del viento Veleta
Velocidad del viento Anemometro
Presion atmosferica Barometro
Humedad del aire Higrometro
Precipitacion Pluviometro
Temperatura Termometro
Anemometro: Este sensor mide la velocidad del viento (m/s) y utiliza un molino de
tres aspas que en su extremo posee cazoletas, el cua gira en el momento en que el viento
sopla y de esta manera se obtiene el registro de vueltas, bien sea dado directamente por
un contador o registrado sobre una banda de papel; con esto se calcula la velocidad[11]
Para el diseno del anemometro por contador es suficiente con generar uno o varios puntos
de referencia con el objetivo de detectar el momento en el que se pasa por este punto.
Figura 13: Diagrama de sensor con punto de referencia. Fuente:https://www.thingiverse.com/thing:41367
Como se muestra en la Figura anterior, se establece un solo punto conformado por un
par de sensores (transmisor y receptor) los cuales se encuentran de forma estatica en
un solo punto. En medio de ellos se coloca un disco perforado que gira de acuerdo al16
eje que se encuentra sujeto a las aspas que reciben el impacto del viento y generan el
movimiento. El disco perforado cuenta con dos agujeros, uno a cada extremo de la pieza,
con el objetivo de no dejar puntos ’muertos’ o ’ciegos’ al momento de medir sobre todo
en el caso de estar moviendose a una velocidad muy baja. Cada vez que el sensor pasa
por un agujero del disco genera un nivel en alto y cada vez que pasa por un punto no
perforado del disco genera un nivel en bajo. Esta actividad se hace ciclicamente hasta
obtener una serie de pulsos a partir del cual es posible sustraer la frecuencia y calcular
la velocidad con la siguiente formula:
V = 5 ∗ f − 0,0005 ∗ f2 − 0,000014 ∗ f2 (1)
La ecuacion 1 resulta de poder medir el valor captado por el sensor de acuerdo a la
velocidad de un objeto donde se conozca la velocidad a la que viaja, como por ejemplo de
un carro moviendose en diferentes direcciones y a distiantas velocidades. Seguidamente
se interpolan los resultados y se grafican para ası obtener la ecuacion que describe el
comportamiento.
Figura 14: Grafica de resultados de la medida e interpolacion del sensor.https://www.thingiverse.com/thing:41367
Este sensor tambien cuenta con un diseno de cada una de las piezas en tercera dimension
lo cual fue util para el proyecto con el fin de poderlas imprimir en una impresora 3D y
ası proceder a armar toda la estructura del mismo como se muestra en la Figura 15.
Figura 15: Diagrama 3d sensor. Fuente: https://www.thingiverse.com/thing:41367
17
La estructura del anemometro es dividida en tres partes relevantes las cuales son: Una
cabecera compuesta de los aspas y el eje, otra parte es el cuerpo donde se encuentra el
disco perforado y los sensores, y por ultimo un soporte para sostener todo el sensor en
su conjunto. Para facilitar el movimiento y generar baja friccion entre la cabecera y el
cuerpo se propone el uso de unos rodamientos. El resultado se puede evidenciar en la
Figura 16 y Figura 17.
Figura 16: Impresora 3D Makerbot Replicator 2x (Izquierda). Pagina de diseno 3D Makerbot(Derecha)
Figura 17: Anemometro finalizado e implementado
Veleta: Es un instrumento sencillo que indica la direccion del viento y consta de un
eje sobre el que esta colocado un senalador, el cual debe ofrecer la menor resistencia al
aire. Gracias a que la direccion del viento es la misma hacia donde apunta la veleta,18
es importante poseer una ubicacion correcta de la misma por lo que es necesario que
sea colocada a la mayor altura posible sobre la superficie del suelo y ademas debe estar
alejada de cualquier obstaculo que interfieran o provoquen alteraciones en las corrientes
de aire como edificios, arboles etc.[12]
Al contrario del anemometro, este sensor debe ofrecer la menor resistencia al aire posible,
ya que mas que girar con el viento, debe permitir evidenciar la direccion en la que el
viento se dirige.
Figura 18: Diagrama de interfaz directa para elemento de adquisicion. Fuente:https://www.thingiverse.com/thing:42858
En este caso la veleta cuenta con la misma tecnologıa del sensor anterior, con la diferencia
que tiene cinco pares de sensores los cuales al momento de estar en alto o en bajo y por
la perforacion del disco al interior del cuerpo de la estructura, permite saber la posicion
en la que se encuentra por el numero en bits que se registra.
Figura 19: Disco con numeros de bits posibles por perforaciones. Fuente:https://www.thingiverse.com/thing:42858
La estructura de la veleta podrıa dividirse en tres partes relevantes las cuales son: Una
cabecera compuesta por veleta y punta, otra parte es el cuerpo donde se encuentra el19
disco perforado y los sensores, y por ultimo un soporte para sostener todo el sensor en
su conjunto. De la misma manera entre la cabecera y el cuerpo se propone el uso de
unos rodamientos.
Figura 20: Diagrama sensor 3d. Fuente: https://www.thingiverse.com/thing:42858
El resultado del impreso se puede evidenciar en la Figura 21.
Figura 21: Veleta finalizada e implementada
Temperatura: Instrumento que permite medir la temperatura de un ambiente en diver-
sas horas del dıa. Se conocen diversos tipos de termometros utilizados en meteorologıa,
de donde los mas comunes son el termometro de extremas y el termometro de suelo;
el primero se obtiene las temperaturas mınima y maxima ocurridas en un instante de
tiempo que comunmente es un dıa; por otra parte el termometro de suelo penetra verti-
calmente hacia arriba y se utiliza a poca profundidad, teniendo el deposito de mercurio
encerrado en una varilla recta [13].20
Actuadores
Al igual que los elementos de adquisicion los actuadores tambien deben ser de facil uso,
por lo cual en este caso y a diferencia del anterior, los actuadores estaran integrados en la
misma tarjeta de las estaciones meteorologicas; y aunque se considerara como un modulo
independiente, su manipulacion e integracion se manejaran de forma estatica y a partir de
determinadas instrucciones recibidas por la estacion enviara al respectiva senal de control a
los actuadores y utilizadas a conveniencia del mismo usuario final.
4.1.2. Estacion meteorologica
Luego de tener listo el diseno fısico de algunos de los modulos que se pueden conectar, se
procede al diseno de la estacion meteorologica teniendo en cuenta que se va a encargar de
coordinar la informacion de cada uno de estos elementos. Cada uno de los bloques de la Figura
22 representa una funcionalidad y/o modulo de la estacion (El recuadro ’Actuadores’ aunque
si bien se encuentra fijo en la tarjeta de la estacion meteorologica, se coloca por aparte para
mostrar que es un modulo independiente).
Figura 22: Diagrama de bloques estacion meteorologica
21
A continuacion se muestra una descripcion del diseno de los bloques de la Figura anterior.
Sistema de alimentacion y carga: Por tratarse de una estacion meteorologica que va
a ser colocada en lugares donde la conexion a una fuente de alimentacion fija como una
toma corriente no es posible, es necesario recurrir a otras tecnologıas para la obtencion
de la energıa como son los paneles solares.
Dichos paneles solares se encargan de tomar la energıa del sol y transformarla en co-
rriente electrica, no obstante, esta corriente por depender de un agente externo no es
uniforme y constante, ya que cuando hay ausencia u obstruccion de la fuente solar esta
disminuye o desaparece, y cuando hay aumento de la fuente solar por no ser aprovechada
o consumida en su totalidad se pierde; por tal motivo es necesario contar con un sistema
que cuente con un gestor baterıas y energıa, un elemento de almacenamiento que en este
caso sera una Baterıa LiPo por sus caracterısticas de mayor densidad de la energıa, tasa
de descarga y ligereza, y por ultimo un panel solar encargado de suministrar la energıa.
Microcontrolador: Para el microcontrolador de la estacion meteorologica se selecciono
el MSP430F5529 por sus caracterısticas de bajo consumo y memoria RAM que se ajusta
a las necesidades del proyecto (Ver Figura 5 y Cuadro 2).
Este microcontrolador cuenta con los componentes electricos basicos para el funcio-
namiento, los puertos habilitados y facil conexion tanto del puerto I2C en donde se
conectaran los elementos de adquisicion, el puerto serie de comunicacion UART, entre
otros.
Interfaz de programacion: Para la facilidad de programacion y manipulacion del
microcontrolador ya fijado en la tarjeta de desarrollo de la estacion meteorologica, es
conveniente como parte del diseno dejar una interfaz o unos sockets disponibles para
versatilidad al momento de cargar un programa.
Teniendo claro todas y cada una de las etapas o partes que componen la estacion meteo-
rologica (Figura 22), al igual que en el diseno de los elementos de adquisicion se propone tres
esquematicos.
El primero de ellos que aparece en la Figura 23, muestra un esquematico con relacion a las
conexiones de energıa que va a utilizar la tarjeta. En la parte superior izquierda se muestra
la entrada microusb que permite la alimentacion a toda la tarjeta ya sea por medio de un
cargador de 5 V convencional, o como se nombro anteriormente, con la alimentacion provista
por un panel solar cuando no se dispone de una toma corriente cercana y utilizar fuentes de
energıa alternativas.
La alimentacion electrica de entrada es suministrada y gestionada por un cargador de baterıas
que se encuentra en la parte superior derecha del esquematico, quien se encargara de tomar22
la energıa y realizar dos labores, tanto energizar toda la tarjeta y los componentes que se
conecten desde una baterıa LiPo, como tambien de recargar y mantener disponible la energıa
en dicha baterıa.
Finalmente en la parte inferior de la imagen se garantiza por medio de un regulador la debida
alimentacion a toda la tarjeta.
Figura 23: Esquematico de alimentacion y carga disenado en EAGLE.
Para el siguiente recuadro del esquematico que se encuentra en la Figura 24, es importante
notar que es basicamente la misma configuracion que la Figura 8 ya que solo contiene el
mismo microcontrolador con cada uno de los elementos basicos que se necesitan para su
funcionamiento (Microcontrolador, Reloj, voltajes de referencia, boton de Reset).
Figura 24: Esquematico con Microcontrolador, reloj y voltajes de referencia disenado en EA-GLE.
23
Para el ultimo recuadro del esquematico mostrado en la Figura 25, se amplıa la posibilidad
de testigos y de botones con los cuales se puede interactuar. Ademas de esto de agrega una
ranura de conexion de mas en donde se hara la respectiva conexion de los sensores al bus I2C.
Figura 25: Esquematico con puertos de conexion y testigos disenado en EAGLE.
En la Figura 26 se organiza cada uno de los elementos que hacen parte de este diseno de la
estacion meteorologica. En la parte superior izquierda se coloca la entrada de alimentacion;
en la parte superior central el regulador; en seguida de la parte superior el administrador de
baterıas; en la parte central el micronctrolador; y por ultimo en la parte externa de la tarjeta
(izquierda y derecha) los puertos que seran utilizados para llevar a cabo las diferentes tareas
como son el uso de UART, I2C, entre otros.
Figura 26: PCB final de tarjeta de la estacion disenada en EAGLE.
Finalmente, en la Figura 27 se muestra una vista superior del modelo en tercera dimension
de los paquetes de la estacion meteorologica.24
Figura 27: Visualizacion en tercera dimension de la PCB con sus compenentes. Fuente:http://3dbrdviewer.cytec.bg/
Para la comunicacion inalambrica de los datos que se van a enviar y recibir se utiliza el Xbee.
Xbee es un dispositivo electronico que permite la interconexion y la comunicacion inalambrica
entre ellos y aunque estos modulos cuentan con varias referencias y tecnologias, permite en
su mayoria la misma configuracion de sus pines independientemente de estos modelos.
Estos modulos utilizan el protocolo de red llamado IEEE 802.15.4 para crear redes para punto
a punto o punto a multipunto. Fueron disenados para aplicaciones que requieren de un alto
trafico de datos, baja latencia y una sincronizacion de comunicacion predecible basado en el
protocolo Zigbee. En terminos simples, los XBee son modulos inalambricos faciles de usar[16].
Una vez terminado el diseno de la tarjeta de la estacion; en el costado izquierdo de la Figura
28 se muestra la foto de la PCB en un estado finalizado pero sin componentes y en el lado
derecho de la misma imagen una foto donde los componentes, en su mayorıa superficiales, han
sido debidamente colocados y probados para garantizar el correcto funcionamiento.
Figura 28: Resultado final de la tarjeta para la estacion meteorologica
25
4.1.3. Elemento de salida con conexion a internet (Gateway)
Como elemento de salida con conexion a Internet y que permite una facil programacion
se selecciono la tarjeta de desarrollo Raspberry Pi 3 la cual sera la encargada de tomar
toda la informacion de las estaciones meteorologicas a traves de un modulo de comunicacion
inalambrica conectado al (GPIO - general purpose input/output). Ver Figura 29 y 30.
En esta tarjeta se utilizara igualmente el modulo Xbee y su modo de funcionamiento se
desarrolla en la seccion de Diseno de Software.
La Raspberry Pi es una tarjeta de desarrollo similar a un computador usual pero mas limitado,
de bajo costo y bajo consumo del tamano de una tarjeta de credito. Cuenta con la posibilidad
de instalar y configurar un sistema operativo, el cual debe ser instalado en la SD que va en
una de sus ranuras, lo que permite desarrollar y correr diferentes tipos de Software[17].
Figura 29: Tarjeta de desarrollo Raspberry Pi. Fuente: www.raspberrypi.org
Figura 30: Entradas y salidad de proposito general (GPIO) de tarjeta de desarrollo RaspberryPi. Fuente: www.raspberrypi.org/documentation/usage/gpio/
26
Cuadro 4: Caracteristicas mas sobresalientes de Raspberry Pi 3 [17]Caracteristica Descripcion
CPU 1.2GHz 64-bit quad-core ARMv8
Memoria RAM 1 GB
GPIO Pins 40
Puertos USB 2.0 4
Red de conectividad Ethernet (RJ-45), Wifi 802.11n, Bluetooth 4.1
Consumo energetico 800 mA, (4.0 W)
En las Figuras 31 y 32 se evidencia el resultado de tarjeta que se implementa en la Raspberry
Pi.
Figura 31: Esquematico y PCB de tarjeta para Raspberry Pi
Figura 32: Tarjeta para Raspberry Pi
27
4.2. DISENO DE LA ARQUITECTURA DE SOFTWARE
Actualmente dentro de la tecnologıa del mundo de los dispositivos conectados a internet
IoT se encuentran implementados diferentes protocolos ya estructurados como por ejemplo
MQTT, REST, CoAP, STOMP, ZeroMQ, OpenWire y AMQP. Sin embargo, Message Queue
Telemetry Transport - MQTT[18] permite tener una buena experiencia por ser un protocolo
de mensajerıa sencillo y ligero, disenado para dispositivos limitados, para un bajo ancho de
banda y latencia alta o redes no confiables, y para mejorar el uso de la energıa de la baterıa.
MQTT es un protocolo inventado por IBM y hace referencia a la comunicacion machine-to-
machine (M2M) por medio de un conjunto de reglas basadas en publicaciones y suscripciones
como se muestra en la Figura 33, en donde un cliente ’publica’ su informacion enviandola a un
broker o nodo central que se encarga de mantener activo el canal gestionando la informacion
recibida y transmitiendola a uno o varios nodos que se encuentren ’suscritos’ al cliente que
entrego los datos.
Figura 33: .
Los datos de la comunicacion se fundamentan en unos temas (topics) que el cliente inicial
publica con su respectivo mensaje, y los nodos que desean recibirlo se suscriben a ese tema;
dicho tema se representa por una cadena jerarquica separada por ’/’ como una ruta a seguir
(Ver Figura 16).28
Figura 34: .
Aunque el problema planteado en este proyecto puede tener diversas soluciones en Software,
continuando con el planteamiento de la Figura 2, una forma sencilla de abordarlo es simplificar
todo el sistema a un conjunto de tres elementos individuales donde uno de ellos actua como un
nodo central en topologıa estrella y debido a la organizacion resultante del sistema simplificado
es posible adoptar una serie de reglas basadas en publicaciones y subscripciones siguiendo la
metodologıa usada en el protocolo MQTT (Ver Figura 33), en donde un extremo hace la
publicacion de los datos al nodo central, quien se encarga de gestionarla como una ruta de
tema y lo envıa a cada uno de los suscritos a dicha ruta en otro extremo. Sin embargo, por ser
un sistema que trabaja de forma bidireccional, es importante mirar a cada uno de los nodos
de los extremos como un publicador y como un suscriptor dependiendo el sentido en el que se
haga el envıo de los datos.
De acuerdo a lo anterior, en la Figura 35 se muestra un diagrama unidireccional de las es-
taciones meteorologicas actuando como publicadoras a un Broker central en donde los datos
suministrados hacen relacion de forma mas puntual al valor obtenido de los sensores que in-
tegran este bloque como se vera mas adelante, y el nodo del lado derecho de dispositivos de
visualizacion como elementos suscritos a la ruta que ha publicado el valor de interes como
pueden ser servicios de Internet, aplicaciones de escritorio o moviles, entre otros suscritos que29
esten interesados en la informacion publicada.
Figura 35: .
A su vez, la Figura 36 muestra como al tomar la direccion en la que viajan los datos en el otro
sentido; estos servicios Web, aplicaciones de escritorios o moviles pasan a ser los dispositivos
de control quienes se encargan de publicar los datos en el broker y para que en este caso se
puedan aplicar a uno de los actuadores asociados a la ruta.
Figura 36: .
A continuacion se desarrollara de forma mas especifica el diseno logico que se tendra en cuenta
para el desarrollo del Software de cada uno de los elementos individuales y de esta manera
lograr la solucion propuesta anteriormente.
4.2.1. Logica de programacion del sistema de adquisicion de datos
Aunque los elementos actuadores no requieren una logica de programacion ya que solo se
encargan de recibir una senal de entrada booleana (Alto/Bajo), no sucede lo mismo para el30
caso de los elementos de adquisicion quienes deben interactuar con el microcontrolador de la
estacion meteorologica de una forma sencilla pero a la vez coordinada permitiendo ası tanto la
adicion de nuevos elementos de adquisicion como el continuo envıo de los datos desde los sen-
sores. Por tal razon se considerara cada una de las actividades de los microcontroladores como
una tarea individual (Task) dentro de un programa basado en Multitarea (Multitasking), don-
de unas tareas tendran mayor complejidad que otras pero todas se podran realizar de manera
rapida y eficaz, y si bien no son rigurosamente simultaneas, sı se manejaran cercanamente a
multiples tareas en paralelo.
Tarea de peticion y suministro de informacion de nuevo sistema de adqui-
sicion de datos: Esta tarea hara parte del Multitarea del microcontrolador que se
encuentra en cada uno de los sensores, el cual se encargara de que una vez sea conec-
tado el sensor de forma fısica al modulo I2C, enviar a la estacion el caracter del sensor
que tiene integrado con el fin de identificarse como un nuevo elemento reconociendo
todas las caracterısticas de su sensor y ası obtener una nueva direccion de I2C que se le
asignara con la cual podra hacer peticiones mas adelante al momento de enviar datos
de su sensor. (ver Figura 37).
Figura 37: Diagrama de interaccion entre Elemento de Adquisicion y Estacion Meteorologica.
Tarea adquisicion de datos: Esta tarea hara parte del Multitarea del microcontrola-
dor que se encuentra en cada uno de los sensores y simplemente se encargara de una vez
sea identificado y otorgado una direccion de I2C de la terea anterior, hacer peticiones a
las estaciones meteorologicas para poder entregar los datos del respectivo sensor.31
4.2.2. Red de comunicacion inalambrica Estacion-Gateway
Este punto es tomado por aparte ya que es importante mostrar de forma mas detalla la
comunicacion y la coordinacion que se tiene en cuenta para la debida gestion de la informacion.
Esta tarea es una de las iniciales para las Estaciones y actua en conjunto con una tarea del
Gateway. Para comenzar se aclarara los conceptos respecto a topologıas en el area de las
comunicaciones y el Zigbee.
Para el primer concepto a tener en cuenta, en la teorıa de redes de comunicacion, existe una
clasificacion de acuerdo a la tecnologıa o configuracion que esta maneja. Uno de los tipos mas
esenciales y sencillos es la topologıa punto a punto que hace referencia al enlace mas simple
que se genera entre solo dos puntos o nodos, que fue la utilizada para conectar los actuadores
a la Estacion Meteorologica. Ver Figura 38.
Figura 38: Topologıa punto a punto.
Tambien es posible encontrar la topologıa de la Figura 39, denominada topologıa en bus y
utilizada para la conexion en I2C de los sensores a la tarjeta de la Estacion Meteorologica
ya que se permite la transmision de informacion por un solo canal a cualquier dispositivo
particular mientras que las otras escuchan, dejando que todas los demas dispositivos que no
son requeridas igualmente reciban la informacion que se transmite pero no respondan[19].
Figura 39: Topologıa en bus
32
Aunque existen muchas mas topologıas, por ultimo y de mayor interes en esta seccion es la
Topologıa de red en estrella (punto a multipunto) ya que esta arquitectura de red todos los
nodos se conectan entre si pasando por un nodo central que trabaja de forma maestra por
medio de uno mas caminos y va a ser la utilizada en la comunicacion inalambrica entre las
Estaciones y el Gateway utilizando modulos Xbee[20].
Figura 40: Topologıa con controlador central
Como segundo concepto a tener en cuenta es el protocolo Zigbee que consiste segun la pagina
oficial Zigbee como ’una alianza y un estandar de redes en estrella de eficiencia energetica y
de costos. XBee utiliza el estandar Zigbee y lo agrega y envuelve en un pequeno empaque
elegante’[21]. El protocolo Zigbee ofrece tres tipos de elementos como se muestra en la Figura
41.
Figura 41: .
33
Coordinador ZigBee (ZigBee Coordinator, ZC): Este es el nodo mas activo de
la red ya que es el encargado de establecerla inicialmente, almacenando la informacion
sobre la red, seguridad y coordinacion. Por red se encuentra solo un dispositivos de
estos.
Router ZigBee (ZigBee Router, ZR): Estos dispositivos de nodo actuan como
elementos intermedios, cuya funcionalidad principal es retransmitir los datos a otros
nodos conectados a el.
Dispositivo final (ZigBee End Device, ZED): Estos dispositivos a diferencia de
los dos anteriores tienen la funcionalidad de comunicarse solamente con el Coordinador
o Router que lo posee en una de sus ramas ya que el no tiene ningun nodo mas a su
cargo, por ende su consumo es mas reducido.
Una vez aclarados estos dos conceptos, en primera instancia encontramos para este proyecto
el uso de los modulos Xbee en la comunicacion inalambrica como se ha dicho con anterioridad,
ya que permiten una comunicacion tanto de punto a multipunto, como de multipunto a un
solo punto aprovechando su estandar Zigbee que cuenta con diversos componentes a la hora
de abordar problemas de este tipo por el envıo de datos de forma bidireccional que se requiere;
un solo nodo Coordinador a varios nodos denominados dispositivos finales, ası como de estos
multiples dispositivos finales a un solo punto comun Coordinador. ver Figura 41.
Dicho Coordinador sera configurado en el Xbee del Gateway (Raspberry) el cual se encargara
dentro de la red de iniciar el intercambio de datos con un solo dispositivo final seleccionado
dentro de la red (Estacion Meteorologica). Para el diseno de la solucion se propone que cada
periodo de tiempo desde el momento en que las estaciones son energizadas envıan en forma de
broadcast al coordinador un codigo de quererse acoplar y el usuario que quiere que se integre
a un Gateway en especıfico, de forma manual debera accionar un boton para que de forma
automatica se haga el reconocimiento y sincronizacion.34
Figura 42: Diagrama de interaccion entre Gateway una estacion nueva y las estaciones yaexistentes.
En la Figura anterior se muestra como luego de accionar un pulsador en la tarjeta del Gateway
a la cual se quiere integrar; el Gateway suspende o silencia la comunicacion con las otras
estaciones meteorologicas que se encuentran activas en ese mismo instante para darle paso a
la comunicacion particular con la estacion que hasta ahora ingresa a la red de comunicacion.
Esta nueva estacion se encarga de proporcionar la informacion necesaria para que se pueda
enviar a la nube, con el fin recibir un codigo de aprobacion con el cual podra asociarse a
una ruta que se creara para los modulos que se vayan conectando donde los sensores pueden
publicar los datos medidos por medio de las Estaciones.35
Una vez se le asigna este codigo unico a la estacion recien integrada, el Gateway se encarga
de enviar el codigo de reactivacion ’ $ ’ para continuar con el funcionamiento normal junto
con todas y cada una de las estaciones que ya se encuentran en la red de comunicacion.
4.2.3. Logica de programacion de las Estaciones Meteorologicas
De la misma manera que los elementos de adquisicion, las actividades del microntrolador de
las estaciones meteorologicas tambien seran desarrolladas como tareas individuales de una
multitarea.
Tarea de busqueda y asignacion de nueva direccion I2C al nuevo sistema
de adquisicion de datos: Dado que cada uno de los sistemas de adquisicion cuando
son conectados por primera vez responden a la direccion I2C que traen por defecto
(Direccion 0X02h), es el dispositivo maestro o en este caso la estacion meteorologica
quien inicia la peticion a esa direccion y una vez encuentra una respuesta, como se veıa
anteriormente, es realmente cuando el microcontrolador que trae el sensor responde y
es capaz de interactuar con el. (Ver Figura 42).
Figura 43: Diagrama general con suscriptor a la izquierda y publicador a la derecha
La Figura 43 describe como una de las tareas de la estacion meteorologica se encarga
de cada determinado tiempo enviar una peticion a la direccion de nueva estacion con
el fin de hallar una respuesta y de ser ası, poder en primera medida identificar la clase
de sensor conectado y en segunda medida asignar una nueva direccion I2C a dicho
dispositivo con el fin de liberar la direccion por defecto 0X02h y poder dar paso a
futuros nuevos dispositivos que se acoplen.
Tarea lectura de datos desde sistemas de adquisicion: Esta tarea se encarga de
tomar todos los valores que se encuentran en los sensores y enviarlos cada determinado36
tiempo. Para este ejercicio, se considera que el microcontrolador hace una peticion a
cada una de las direcciones I2C activas de los modulos que se encuentran conectados a
la tarjeta de la estacion guardandolas en la memoria y refrescandolas cada vez que se
haga esta tarea cada determinado periodo de tiempo.
Liberar direcciones I2C: Es importante saber que las direcciones del bus I2C en
primera instancia son definidas y en segunda instancia es necesario saber cuando modulos
ya no se encuentran conectados o activos, por un lado para no hacer dispendioso el
trabajo de llamar direcciones que no ya no estan en uso en todo momento, tanto como
para poder volver a usar direcciones. Basicamente consiste en que si un dispositivo no
responde despues de determinadas veces, es descartado como una direccion disponible
y colocada como disponibles.
Envıo de datos de las estaciones por XBee: Una vez los sistemas de adquisicion
de los sensores responden con sus datos, se toma la informacion de todos estos sensores
y se organiza en formato JSON para ser transmitido por UART a traves del modulo
Xbee el cual permite por las caracterısticas del protocolo Zigbee enviar varios datos de
forma estable y segura por su sistema de rectificacion. Esta tarea inicia luego de que
el Broker o Gateway selecciona en forma de Broadcast el codigo de la Estacion que le
fue asignado (Ver Figura 44) para poder publicar en una ruta ’Estacion/sensor’ el valor
tomado.
Figura 44: Diagrama general con suscriptor a la izquierda y publicador a la derecha
Tarea de activacion de actuadores: Aunque si bien esta tarea es una de las mas
sencillas ya que solo se trata de poner una senal en alto o en bajo a cada uno de37
los actuadores que se encuentran en la tarjeta, no obstante el dato del estado de los
actuadores se toma de la respuesta que da el Broker a la estacion por el dato de un
sensor que recibio.
4.2.4. Logica de programacion del elemento de salida Gateway
De la misma manera que los microcontroladores de los dispositivos de adquisicion y de las
estaciones meteorologicas, el Gateway tambien trabajara con multitarea y a continuacion se
mostrara la descripcion de cada uno de sus tareas (incluyendo brevemente la tarea del item
anterior).
Tarea de busqueda y conexion a red WIFI: Si bien esta tarea es sencilla en
terminos generales ya que solo se trata de hacer un tipo de escaneo para ver si el
Gateway tiene la posibilidad de engancharse a una red WIFI y de ser posible conectarse,
de esta tarea depende muchas otras tareas o decisiones dentro de las mismas, ya que por
ejemplo como se mostrara mas adelante, si hay conexion a internet los datos que sean
suministrados desde las estaciones meteorologicas seran almacenadas de forma local o
subidas directamente a internet.
La solucion sencilla que se propone en esta tarea es que cada determinado tiempo se
hace un chequeo de la conexion a internet para hacer la conmutacion que se requiera en
la tareas que requiera internet y ademas de esto para hacer mas complejo el asunto de
conexion y validacion con la red WIFI, se propone un unico nombre y unica clave que
sean guardadas por defecto en la memoria de la Raspberry y a la cual sea la que busque
la tarjeta para poderse conectar de forma determinada.
Tarea de busqueda de nueva Estacion Meteorologica: Como ya se explico en el
item anterior, aunque la integracion y asociacion de una estacion meteorologica a la red
del Gateway esta dada de forma automatica, esta actividad se activa si y solo si a partir
de una accion manual por parte del usuario final en la tarjeta del Gateway por medio de
un pulsador y ası hacer la integracion automatica solo en el momento que se requiera.
Tarea de recepcion datos de sensores desde las Estaciones Meteorologicas:
Consiste en que cada determinado periodo de tiempo, el elemento de salida Gateway
toma los datos que se tenga en ese momento el buffer UART en este caso recibidos por
los modulos Xbee y guardarlos de manera temporal en la memoria de la Raspberry.
Tarea de respaldo en base de datos local y base de datos en la nube: Esta
actividad consiste en tomar una decision de acuerdo a el resultado de la actividad
”Tarea de busqueda de nueva Estacion Meteorologica”de guardar la informacion que
se encuentra almacenada de manera temporal, de la tarea anteriormente descrita, para38
ser guardada en la base de datos local (cuando no se encuentra una conexion de red
de internet presente) o de enviar directamente los datos al servicio web que los recibe
(cuando hay conexion de internet). Se utilzo SQLite como ’un motor de base de datos
SQL de dominio publico autonomo, de alta confiabilidad, incorporado y con todas las
funciones’[22], es preciso decir que es el motor de base de datos mas utilizado sobretodo
en gran variedad de dispositivos moviles precisamente por ser publico, y no solo esto,
sino que es un programa muy ligero; pero a pesar de ello mantiene confiabilidad y
prestaciones de un motor mas robusto, lo cual lo hace una buena opcion cuanto se
cuenta con poco espacio de almacenamiento o memoria en un dispositivo.
Tarea de monitoreo base de datos y memoria disponible en el Gateway:
Para evitar desbordamientos innecesarios de la memoria de la Raspberry, esa tarea se
encarga de estar monitoreando la cantidad de informacion en la base de datos local y
la capacidad o disponibilidad de la tarjeta para seguir guardando informacion. Muestra
de forma visual por medio de un testigo que ya no es posible seguir obteniendo mas
datos y bloquea las tareas relacionadas al almacenamiento continuo de informacion.
Una vez hay internet tambien se encarga de desocupar las tablas de la base de datos
que se relacionan a los datos de los sensores y vuelve a activar las funcionalidades
anteriormente deshabilitadas para continuar trabajando normalmente.
4.2.5. Comunicacion Gateway con la nube
La respuesta exitosa de la comunicacion de la tarjeta del Gateway con la nube es de suma
importancia, ya que esto significa tener los datos disponibles de forma remota. No obstante,
se debe resaltar que multiples estaciones meteorologicas con conexion a Internet pueden estar
enviado informacion de manera constante y persistente, por lo cual es conveniente enviar los
datos de la manera mas conveniente posible tanto en formato como en arquitectura. Siguiendo
con el concepto de MQTT en donde a nombre de una ruta se publica un valor (ver Figura
34), se busca en primera instancia crear la ruta completa (Gateway/Estacion/Sensor - Valor),
para lo cual todo el proceso se inicia de acuerdo a la Figura 45 con una identificacion con la
nube por parte de la tarjeta Gateway por medio de un codigo interno de cada Raspberry. Una
vez se identifica ya tiene la capacidad de comunicarse con la nube y transmitir informacion.
Es importante notar que en la Figura 42, se muestra como una vez se hace la conexion y
acoplamiento entre la estacion y Gateway del numeral 6.2.2, el Gateway es quien Registra en
la nube la informacion correspondiente a la estacion meteorologica conectada con el fin de
recibir un codigo unico con el cual se podra irse armando la ruta de publicacion junto con el
numero de sensor que se tiene en la nube ya registrado.
Una vez la tarjeta de salida a internet Gateway tiene todos los datos de la ruta (Gate-
way/Estacion/Sensor) y los envıa, recibe un codigo que representa finalmente a todo el camino39
a seguir para hallar el sensor en referencia y a su vez publicar los valores.
Figura 45: Diagrama general con suscriptor a la izquierda y publicador a la derecha
Para la programacion de las tareas de la Raspberry se utilizo Python, un lenguaje de progra-
macion que se destaca por la facil interpretacion del formato de su codigo el cual es abierto y
compatible con varias plataformas. Python cuenta con una gran variedad de librerıas y paque-
tes de software que le permite ser un lenguaje de rapido desarrollo e integracion eficazmente.
40
5. SOLUCION EN LA NUBE PARA PERMITIR LA
GESTION DE LA INFORMACION
Se define un Servicio Web (Web Service - WS) como un Software conformado por un con-
junto de aplicaciones o de tecnologıas las cuales intercambian datos entre sı en la web por
protocolos de comunicacion de estandar abierto para dar interoperabilidad e integracion a los
desarrolladores de Software, como por ejemplo HTTP, con el objetivo de ser consumidos como
servicios maquina a maquina, por lo cual no cuenta con una interfaz de usuario.
Los proveedores de servicios web WS ofrecen sus servicios como procedimientos remotos y los
usuarios solicitan un servicio llamando a estos procedimientos a traves de la Web.
Figura 46: Estructura de Servicio web convencional
El proveedor de servicios web WS proporciona en la web o publica la informacion y su WSDL
(Web Services Description Language) el cual describe las operaciones, los argumentos de
entrada / salida y el argumento WS para el servidor de integracion de descubrimiento de
descripcion universal (UDDI) (el registro de servicios). El desarrollador llamado cliente movil
(solicitante del servicio) encuentra entonces los WS necesarios en el servidor UDDI. Final-
mente, el codigo de aplicacion del cliente se genera a partir del WSDL como una funcion de
enlace al WS a traves de una solicitud en un protocolo estandar obteniendo una respuesta de
informacion deseada [23].41
Lo que hasta aquı se ha denominado como el broker, el cual es el encargado de actuar como un
nodo central de gestion de la informacion, debe estar en la nube como un aplicativo web que
permita no solo recibir datos y enviarlos a otro punto, si no que de forma sencilla permita a
cualquier usuario acceder a la informacion de forma intuitiva. Si bien en este punto es posible
utilizar cualquier aplicativo en la nube como hace normalmente con cualquier API (Interfaz
de programacion de aplicaciones), para este caso por facil uso e integracion se utilizara un
Web Service.
Cabe recordar que si bien un Web Service no necesita ningun tipo de integracion embebido
dentro de los codigos de los aplicativos que corren sobre los dispositivos que quieran acceder o
enviar informacion del broker, sino que simplemente basta con enviar estrictamente mediante
protocolos de red la informacion de entrada requerida para ası obtener una respuesta deseada;
si ası se quiere ver, el Web Service podrıa verse simplemente como un conjunto de metodos
de programacion con parametros de entrada y salida sin conocer su funcionamiento o estruc-
tura que se encuentra en la nube y que pueden puede ser consumidos o utilizados mediante
protocolos de red.
El Web Service como se muestra en la Figura 46, esta conformado por un WSDL donde se
especifica claramente cada uno de dichos metodos que lo conforman y de que manera pueden
ser consumidos. A continuacion se hara una descripcion de cada uno de los metodos que se
utilizaran en este proyecto.
Registrar Estacion: Este servicio permite al Gateway, una vez se ha conectado, re-
gistrar en la base de datos en la nube datos relacionados con el nombre, la latitud,
la longitud y comentarios de una nueva estacion meteorologica que sea conectada por
primera vez, retornando un codigo unico para dicha estacion.
Registrar Sensor: Similar al servicio anterior, este servicio le permite al Gateway
por medio del codigo propio y del codigo de la estacion a la cual se conecta el sensor,
registrar la informacion con respecto al nombre, tipo, variable, y comentarios de dicho
sensor en la nube. Cabe resaltar que generalmente todos los sensores son registrados
de forma previa y simplemente es atribuido el codigo a las tarjetas de las sensores ya
que muy rara vez los sensores varıan y basto con solo identificarse con el codigo que ya
esta en la nube para saber todos los datos anteriormente mencionados; sin embargo se
genera este servicio con la posibilidad de cualquier otro medio registrar nuevos sensores
futuros no existentes en la base de datos.
Registrar para Publicar: Este servicio crea por medio del envıo del codigo del Ga-
teway, el codigo de la Estacion Meteorologica y el codigo del Sensor la ruta o camino a
donde se puede publicar los datos obtenidos. Si esta fue utilizada anteriormente, devol-
vera el codigo de la ruta ya existente para poder publicar.42
Publicar Sensor: Una vez se tiene el codigo de la ruta, este servicio permite publicar
o postear el valor medido por el sensor final del camino. Este servicio retorna el valor
de los actuadores a la tarjeta que publico.
Informacion de Todas las Estaciones Existentes: Este servicio tiene como parame-
tro de entrada el campo ’Activo’ donde se puede enviar un booleano ”true.o ”false”para
indicar si se retorna toda la informacion de las Estaciones Meteorologicas existentes en
la nube o todas las estaciones meteorologicas que solo esten activas en ese momento.
Informacion de una Estacion Individual: Este servicio retorna toda la informa-
cion relacionada a una Estacion Meteorologica, como el codigo, nombre, comentario, y
sensores conectados a la estacion.
Informacion de una Sensor Asociado a una Estacion Individual: Este servicio
por medio del envıo de parametros de entrada fecha inicial y fecha final los valores
relacionados a los datos medidos por un sensor en particular durante esta el periodo de
tiempo de estas fechas.
Suscribir Url a un Sensor y Estacion Individual: Tras el envıo de una URL, la
estacion y el sensor que se desea; este servicio asocia dicha URL a todos los datos que
se publiquen para ser recibidos en tiempo real.
Publicar en Actuador: Este servicio permite publicar el valor que se quiera colocar
en los actuadores de la tarjeta de la Estacion Meteorologica que se requiera controlar
remotamente.
Para la implementacion de la solucion en la nube, se utilizo un servidor que se encuentra en
la Universidad Distrital con la direccion rita.udistrital.edu.co y puerto 23624, en el cual se
aloja el Web Service y tambien un usuario final presentado como aplicativo Web en donde se
evidenciara y se desarrollara una comprobacion mas puntual de uso en la siguiente Unidad.
Todo el modulo de Web Service se desarrollo en Hypertext Preprocessor - PHP[11], un lenguaje
de codigo especialmente adecuado para el desarrollo web (sobretodo modificar el contenido
de forma dinamica) y que puede ser usado en HTML. Principalmente es usado en el lado del
servidor pero tambien en diferentes tipos de aplicaciones. Tiene la capacidad de conexion con
diversas bases de datos,funciones nativas sin necesidad de incluirlas o importarlas.
Para la base de datos se utiliza MySQL, que es una base de datos cuya licencia es dual,
open source bastante sencilla y para la gestion de la Base de Datos en el servidor se utiliza
phpMyAdmin[24], una herramienta de software libre que actua como un tipo de interfaz de
usuario escrito, como su nombre lo indica en PHP, el cual permite la administracion de una
base de datos MySQL a traves de Internet de una forma muy sencilla o tambien por medio
de sentencias SQL directamente.43
En primera instancia de acuerdo a la Figura 46, el Web Service suministra un WSDL en
donde es posible encontrar los metodos que se ofrecen para ser consumidos ya menciona-
dos con anterioridad, cada uno de ellos con los parametros de entrada que se requieren co-
mo la salida que se genera. Ese WSDL puede consultarse de forma visual en la direccion
http://rita.udistrital.edu.co:23624/WebService.php y para entrada de consumo del Web Servi-
ce en los clientes de maquina en la direccion http://rita.udistrital.edu.co:23624/WebService.php?wsdl.
44
6. CASO DE USO DE RECEPCIÓN Y ENVÍO DE DATOSREMOTAMENTE
Una vez finalizado todo el modelo de red de estaciones meteorológicas de forma modular utili-zando IoT, se muestra una prueba real de uso en donde se genera básicamente el uso de un sen-sor y control remotamente utilizando la URL ya mencionada http://rita.udistrital.edu.co:23624/.
En las Figuras 47 y Figura 48 se encuentra la primera vista de cara al usuario denominadaPágina de Inicio. Aquí se encuentra descrito el objetivo general y los específicos. Además traela opción de poder mirar un breve resumen e imagen del proyecto en cuestión. Finalmente unlink al grupo de investigación LASER.
Figura 47: Página de Inicio. Objetivos.
Figura 48: Página de Inicio. Resumen.
45
El aplicativo en la web cuenta con una pestaña llama ’Mapa de Estaciones’ en donde unusuario final puede encontrar un mapa que cuenta con una señales rojas y señales verdes, querepresentan Estaciones Meteorológicas inactivas y activas en el presente respectivamente. VerFigura 49.
Una vez que cada estación es energizada e identificada por el Gateway, aparece en la posicióngeográfica suministrada por la estación con todos los datos y en primera instancia de colorrojo ya que aunque ha sido conectada, no se encuentra en un proceso de actividad de envío dedatos en tiempo real, es decir que solo se encontrara activa si después de determinado tiempono ha dejado de hacer publicaciones de cada uno de los sensores que gestiona cada estación.
Figura 49: Mapa con Estaciones Meteorológicas
Sobre el mapa es posible seleccionar cualquier estación para desplegar un dialogo como semuestra en la Figura 50 y Figura 51. Este dialogo contiene en su interior toda la informaciónque la estación ha suministrado por primera vez cuando se conectó. En la parte superior seve el nombre que se le ha dado, seguidamente de izquierda a derecha información sobre el46
estado de la estación, el código único de la estación y la fecha en la cual se ha instalado lamisma. En la parte central se encuentran dos botones de suma importancia, Consultar Listade sensores y Consultar Actuadores, los cuales permitirán interactuar de forma más directacon la estación, sin embargo este punto se explicará más adelante. Y finalmente en la parteinferior el comentario de la estación.
Figura 50: Dialogo de Estación Activa.
Figura 51: Dialogo de Estación Inactiva.
La Figura 52 deja ver que una vez es oprimido el primer botón de la parte central, ConsultarLista de Sensores, se despliegue un menú con los sensores que en están o han sido conectadosa la estación meteorológica. 47
Figura 52: Estación Meteorologica con sensor integrado en la lista.
En la Figura 53 se ve más en detalle una tabla que se genera con información general sobreel sensor que ha sido conectado y a su vez dos nuevos botones, Histórico del Sensor y TiempoReal del Sensor. El primero de estos botones, permite al usuario final ver un gráfico y unatabla con todos los datos que han sido obtenidos a los largo de las publicaciones del sensorque se desea consultar. No obstante, esta información puede ser filtrada y la gráfica impresaal criterio del usuario.
Figura 53: Información general de sensor asociado a la Estación. Tareas Historico y TiempoReal habilitadas.
48
Como se dijo anteriormente, también está el botón consultar actuadores el cual consiste en estecaso el despliegue de tres switch para hacer un control remoto sobre la estación en cuestióncolocando en alto o en bajo los actuadores.
Figura 54: Función de actuadores remotos activados.
En la última vista de las pestañas se encuentra toda la información y grafica de los que sehan recolectado gracias a la gestión de la plataforma, los cuales pueden ser filtrado por uncalendario para acotar las fechas que se desean (Figura 55) y la forma de imprimir o guardarla imagen de la graficas (Figura 56).
Figura 55: Vista de datos registrados por el sensor de forma histórica con filtro en la parteizquierda superior.
49
Figura 56: Vista de datos registrados por el sensor de forma histórica con exportación a imagene impresión en la parte derecha superior de la gráfica.
Como prueba de concepto, en la Figura 57 se muestra la conexion real que se realiza delsensor de velocidad del viento que ya esta integrada con la tarjeta del sensor desarrolladaen los puntos anteriores, la cual por medio de los pines de polarizacion (Rojo-VCC y Negro-GND) y los pines de I2C (Amarillo-SDA y Verde-SCL) a una de las trajetas de EstacionMeterorologica.
Figura 57: Imagen de modo de conexión para integración entre el sensor y la Estación Meteo-rológica.
Una vez se proporciona una red de Wifi conocida al Gateway, en este caso la red con ID:Stations y Password: Stations, la Raspberry se conecta manteniendo encendido el LED testigo50
el cual indicara parpadeando cada periodo de 10 segundos si la conexión a la red todavía estao de lo contrario apagando el testigo si no es así. Como se mostró en el diseño del Gateway,es necesario una vez se energiza la Estación, oprimir el botón en la Raspberry para activar latarea de Encontrar una Estación nueva; No obstante el botón debe ser oprimido hasta que eltestigo LED parpadea a una mayor frecuencia. Figura 58.
Figura 58: Presentación final de conexión de todo el sistema funcionando en conjunto.
Figura 59: Vista de mapa de las estaciones meteorológicas en el aplicativo Web. A la izquierdael mapa sin la nueva estación y a la derecha con el reconocimiento de la nueva estación.
Las coordenadas de geográficas de la Universidad Distrital sede de Ingeniería proporcionadapor la tarjeta de la Estación Meteorológica, como se muestra en la Figura 59, a la izquierdase encuentra el mapa antes de ser conectada la estación la cual no contiene la ubicación de laestación actual, y al lado derecho de la Figura 59 el mapa con la ubicación ya existente luegode ser identificada y registrada la nueva estación meteorológica en el Web Service y vista en51
la aplicación Web. Es importante denotar que toda la información que viaja desde el WebService viene en formato JavaScript Object Notation (JSON), que aunque si bien no es comotal un lenguaje de programación, sí constituye una estructura de datos o formato de textoque le permite ser clasificado como un lenguaje de marcado ya que consiste en la escritura einterpretación por medio de una marca o nombre con su determinado valor separado por dospuntos ’:’ de la siguiente manera:
"Nombre": "Valor"
Así puede ser leído por cualquier otro lenguaje de programación y poder empaquetar datosde diferentes tipos uno dentro de otro como se muestra en la Figura 60.
Figura 60: Estructura general JSON
Con la información del sensor en la tarjeta del sensor se procede a conectar directamentela Estación meteorológica lo cual coloca la posición en el mapa en verde de activo y poderinteractuar por medio del aplicativo Web a cada una de las funcionalidades descritas anterior-mente. Por ejemplo, Ver en tiempo real la información, el histórico de muestras, enviar datosdesde el aplicativo a cada uno de los actuadores de la tarjeta. Ver Figura 61 y 62.
Figura 61: Captura y gráfica de datos en tiempo real del nuevo sensor integrado a la EstaciónMeteorológica.
52
Figura 62: Vista de información de la estación y sensor seleccionada con grafica de históricoy tabla de datos.
53
7. CONCLUSIONES
- Se ha logrado desarrollar e implementar un sistema que le brinde al usuario final, la facilidadde integrar sensores modularmente para obtener su informacion y control de forma remota
- Se ha logrado desarrollar e implementar la integracion de diversas tecnologias para unafacilidad e intuicion para el usario final
- El proyecto realizado promueve la investigacion en el area de meteorologia por el uso desensores e interfases graficas para el manejo de datos
- Si bien la plataforma esta implementada para uso de USB impetearologico es posible por suversatibilidad de diseño solucionar otros problemas que requiera captura de datos y controlremoto
- Se encuentra en la utilizacion de la energia solar una fuente de energia alterna para dispo-sitivos y de bajo consumo
- La topologia de red un breve control permite mejor gastar de la que viaja bidirectamente
- La conexion en IZC para el caso de l integracion de edistintos dispositivos al mismo bus condistintas procedencias es de facil uso y de adaptibilidad con el control de las
- Aunque si bien utilizar una tarjeta por cader sensar influye en un mayor recurso fisico, teneruna tarjeta de forma particular que construye la informacion y afigmacion del sensor solo sepermita para moyor
54
8. REFERENCIAS Y ANEXOS
Referencias
[1] J. F. Boshell V. Informe de Consultoría: Gestión De Información Agroclimática En Co-lombia. Programa Adapt. al Cambio Climático en la Región Andin., 2012.
[2] Salthammer, T.; Uhde, E.; Schripp, T.; Schieweck, A.; Morawska, L.; Mazaheri, M.;Clifford, S.; He CongRong; Buonanno, G.; Querol, X.; Viana, M.; Prashant KumarGlobalchallenges for the 21st century: the role and strategy of the agri-food sector. FraunhoferWKI, Department of Material Analysis and Indoor Chemistry, Braunschweig, Germany.2016.
[3] Castro Colina, L.; Sova, C.; Martínez Barón, D.; Saravia, D.Mapping the influence ofsocial actors at different levels for Central America: climate change and agriculture.Estudios Urbanos y Ambientales por El Colegio de México, México, D.F., Mexico.
[4] Subgerencia Cultural del Banco de la República. (2015). Clima: elementos y factores.Clima elementos y factores.
[5] IDEAM Clima elementos y factores. Colombia.Recuperado de http://www.ideam.gov.co
[6] CORNARE Fenómeno El Niño y La Niña. Colombia. Recuperado dehttp://www.cornare.gov.co/contactenos/139-gestion-del-riesgo/336-fenomeno-el-nino-y-la-nina
[7] Andrés Felipe Cruz Bernal(2015). DISEÑO DE UNA ESTACIÓN METEOROLÓGICAMODULAR QUE PERMITA CONEXIÓN REMOTA Y GESTIÓN DE DATOS VÍAINTERNET. Universidad Distrital, Facultad de ingeniería, proyecto de grado.
[8] The User’s guide MSP430F5529 LaunchPad Development Kit (MSP-EXP430F5529LP)[Online]. Available: http://www.ti.com/lit/ug/slau533c/slau533c.pdf [Accessed: January-2017].
[10] C. Meruane and R. Garreaud. Instrumentos Meteorológicos y Humedad Atmosférica -Módulo 1. Universidad de Chile Facultad de Ciencias Físicas y Matemáticas Departa-mento de Geofísica, 2005.
[11] Diccionario de definiciones de palabras o conceptos [Online]. Available:http://definicion.de [Accessed: January-2017].55
//Service("updateOne","b_active","dir_station","'1'","n_id='$validation3'");$idPath = Service("selectOne","n_id","path","","n_id_g='$validation1' AND n_id_st='$validation3' AND n_id_s='$validation2'");
if ((is_numeric($validation1)) and (is_numeric($validation2))) {
$idPath = Service("selectOne","n_id","path","","n_id_st='$validation1' AND n_id_s='$validation2'");
if(is_numeric($idPath)){
if(empty($initialdate)){
$data = Service("select","j_value,d_date","value_table","","n_id_path='$idPath' AND b_delete_logic=0");
return json_encode($data);}else{
if(empty($enddate)){
$data = Service("select","j_value,d_date","value_table","","n_id_path='$idPath' AND b_delete_logic=0 AND (d_date between '$initialdate' and '2018-10-10')");
return json_encode($data);}else{
$data = Service("select","j_value,d_date","value_table","","n_id_path='$idPath' AND b_delete_logic=0 AND (d_date between '$initialdate' and '$enddate')");
return json_encode($data);}
}}else{
return "Invalid path information";}
}else{return "The information is not found";
}
}
function Subscribe($urluser,$station,$peripheral){
//Service("updateOne","b_active","dir_station","'1'","n_id='$validation3'");$idPath = Service("selectOne","n_id","path","","n_id_g='$validation1' AND n_id_st='$validation3' AND n_id_s='$validation2'");
if ((is_numeric($validation1)) and (is_numeric($validation2))) {
$idPath = Service("selectOne","n_id","path","","n_id_st='$validation1' AND n_id_s='$validation2'");
if(is_numeric($idPath)){
if(empty($initialdate)){
77
$data = Service("select","j_value,d_date","value_table","","n_id_path='$idPath' AND b_delete_logic=0");
return json_encode($data);}else{
if(empty($enddate)){
$data = Service("select","j_value,d_date","value_table","","n_id_path='$idPath' AND b_delete_logic=0 AND (d_date between '$initialdate' and '2018-10-10')");
return json_encode($data);}else{
$data = Service("select","j_value,d_date","value_table","","n_id_path='$idPath' AND b_delete_logic=0 AND (d_date between '$initialdate' and '$enddate')");
return json_encode($data);}
}}else{
return "Invalid path information";}
}else{return "The information is not found";
}
}
function Subscribe($urluser,$station,$peripheral){
//******************************************************************************// PRINCIPAL FUNCION//******************************************************************************void main(void){
Initialisation();__bis_SR_register(LPM0_bits + GIE); // Enter LPM0, enable interrupts__no_operation(); // For debugger
RXCompare = 0x0; // Used to check incoming dataP1OUT |= 0x01; // P1.0 = 1
while (1){
}}
//******************************************************************************// FUNCIONES DE LA MULTITAREA//******************************************************************************
void Task1(){// Solicitud de conexionwhile (!(UCA0IFG&UCTXIFG));UCA0TXBUF = Station;__delay_cycles(20);t1 = 0;
//******************************************************************************////This is the TIMER1_A3 interrupt vector service routine.////******************************************************************************
while (!(UCA0IFG&UCTXIFG));Station = UCA0RXBUF;__delay_cycles(1000);Enable_t1 = 1;Enable_t6 = 1;
}if(UCA0RXBUF == NEW && Station == '0'){
volatile unsigned int StationDataInfo[]={0x34,0x2E,0x36,0x32,0x31,0x32,0x30,0x2C,0x2D,0x37,0x34,0x2E,0x30,0x36,0x35,0x39,0x32,0x2C,0x75,0x6E,0x6F,0x2C,0x45,0x73,0x74,0x61,0x63,0x69,0x6F,0x6E,0x20,0x56,0x69,0x76,0x69,0x65,0x6E,0x64,0x61,0x20,0x4A,0x65,0x66,0x66,0x65,0x72,0x73,0x6F,0x6E,0x2C,0x45,0x73,0x74,0x61,0x20,0x65,0x73,0x20,0x75,0x6E,0x61,0x20,0x65,0x73,0x74,0x61,0x63,0x69,0x6F,0x6E,0x20,0x71,0x75,0x65,0x20,0x70,0x65,0x72,0x6D,0x69,0x74,0x65,0x20,0x6D,0x65,0x64,0x69,0x72,0x20,0x65,0x6C,0x20,0x76,0x61,0x6C,0x6F,0x72,0x20,0x64,0x65,0x20,0x63,0x61,0x64,0x61,0x20,0x75,0x6E,0x61,0x20,0x64,0x65,0x20,0x6C,0x61,0x73,0x20,0x68,0x61,0x62,0x69,0x74,0x61,0x63,0x69,0x6F,0x6E,0x65,0x73,0x2E,0x0D};int y;for(y=0;y<131;y++){
//-------------------------------------------------------------------------------// The USCI_B0 data ISR is used to move received data from the I2C slave// to the MSP430 memory. It is structured such that it can be used to receive// any 2+ number of bytes by pre-loading RXByteCtr with the byte count.//-------------------------------------------------------------------------------#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)#pragma vector = USCI_B1_VECTOR__interrupt void USCI_B1_ISR(void)#elif defined(__GNUC__)void __attribute__ ((interrupt(USCI_B1_VECTOR))) USCI_B1_ISR (void)#else#error Compiler not supported!#endif{
Valor = ValorBf[1] * 256;Valor = Valor + ValorBf[0];
}}
}else
{*PRxData = UCB1RXBUF; // Move final RX data to PRxData
//ValorTmp = UCB1RXBUF;//if(ValorTmp>0x00){
//Valor = ValorTmp;//}
__bic_SR_register_on_exit(LPM0_bits); // Exit active CPU}break;
case 12: break; // Vector 12: TXIFGdefault: break;}
}
/*Código Tarjeta de Sensor (Microcontrolador MSP430f5529 - Entorno de desarrollo Energía). Programación en C
*/// Wire Slave Receiver
// by Nicholas Zambetti <http://www.zambetti.com>
// Demonstrates use of the Wire library// Receives data as an I2C/TWI slave device// Refer to the "Wire Master Writer" example for use with this
// Created 29 March 2006
// This example code is in the public domain.// most launchpads have a red LED#define LED RED_LED
#include <Wire.h>
int valor = 0;int x = 0; 95
int sensorPin = A0; // select the input pin for the potentiometerint ledPin = 13; // select the pin for the LEDint sensorValue = 0; // variable to store the value coming from the sensorfloat Sensor[5];float aux = 0;int cont = 0;float value;
void setup(){
pinMode(LED, OUTPUT);Wire.begin(2); // join i2c bus with address #4//Wire.onReceive(receiveEvent); // register eventSerial.begin(9600); // start serial for outputWire.onRequest(requestEvent); // register event
// function that executes whenever data is received from master// this function is registered as an event, see setup()void receiveEvent(int howMany){
//while(1 < Wire.available()) // loop through all but the last//{
//char c = Wire.read(); // receive byte as a character//Serial.print(c); // print the character
//}char c = Wire.read(); // receive byte as an integerc = 0x30 + c;Serial.println(c); // print the integerdigitalWrite(LED, HIGH); // turn the LED on (HIGH is the voltage level)//Wire.write(0x35);
}
void requestEvent(){
char primero = x / 256;char segundo = x;Serial.println(primero); // print the integerSerial.println(segundo); // print the integerif(valor == 1){
Wire.write(primero); // respond with message of 6 bytes// as expected by master
97
valor = 2;}if(valor == 0){
Wire.write(segundo); // respond with message of 6 bytesvalor = 1;
}if(valor == 2){
valor = 0;}digitalWrite(LED, HIGH); // turn the LED on (HIGH is the voltage level)