P
ROYECTO
F
IN DE
C
ARRERA
Implementaci´on de Sistema
Dom´otico con Servidor Raspberry
Autores:Juan Angosto Herrmann
Fernando Salgado ´Alvarez
PROYECTO FIN DE CARRERA PLAN 2000
E.T.S.I.S. TELECOMUNICACIÓN
RESUMEN DEL PROYECTO: TEMA:
TÍTULO:
AUTOR:
TUTOR: Vº Bº.
DEPARTAMENTO:
Miembros del Tribunal Calificador:
PRESIDENTE:
VOCAL:
VOCAL SECRETARIO:
DIRECTOR:
Fecha de lectura:
Calificación: El Secretario,
Automatización y Sistemas de Control
Implementación de Sistema Domótico con Servidor Raspberry
Salgado Álvarez, Fernando
Angosto Herrmann, Juan
Herrera Camacho, José Antonio
García Hernando, Ana Belén
Herrera Camacho, José Antonio
Jiménez Martínez, Francisco Javier
Se trata de diseñar y desarrollar un sistema de control ambiental distribuido para una
vivienda utilizando hardware específico y un protocolo de comunicación inalámbrico
destinado para ello. El sistema se compone de un servidor que hará de gestor de tareas
y funciones, y de interfaz para el usuario. Este se implementará con un ordenador en
miniatura llamado Raspberry Pi. Los controladores que recibirán las directivas de
funcionamiento serán implementados por los alumnos utilizando microcontroladores
de la familia C8051.
R
ESUMEN EN
C
ASTELLANO DEL
P
ROYECTO
F
IN DE
C
ARRERA
Implementaci ´on de Sistema
Dom ´otico con Servidor Raspberry
Autores:Juan Angosto Herrmann
Fernando Salgado ´Alvarez
Este proyecto consiste en el dise ˜no e implementaci ´on un sistema dom ´otico que puede ser instalado en una vivienda para controlar distintas variables ambientales y conseguir as´ı la m´axima comodidad de los habitantes de manera autom´atica o manual seg ´un los gustos y necesidades de los usuarios.
La caracter´ıstica principal de este sistema, es que cuenta con un funciona-miento distribuido donde entran en juego un servidor, encargado de tomar las decisiones generales para el comportamiento de la casa, y una serie de controla-dores esclavo cuya funci ´on es mantener constantes las variables ambientales con los valores fijados por el servidor. As´ı se consigue mantener la vivienda en una situaci ´on de bienestar constante para cualquier persona que se encuentre dentro. El sistema ha sido pensado de manera que se intenta reducir al m´aximo el cableado para facilitar su instalaci ´on por lo que la comunicaci ´on entre los distintos dispositivos se hace de manera inal´ambrica por medio de un protocolo descrito en la norma IEEE 802.15.4 llamado ZigBee. Para ello se ha utilizado un m ´odulo de comunicaci ´on wireless llamado Xbee, el cual permite la comunicaci ´on entre dos dispositivos.
Para el control de dicho sistema distribuido se cuenta con una aplicaci ´on web, que mediante una interfaz gr´afica permite al usuario controlar los distintos dispositivos dentro de la vivienda consiguiendo as´ı controlar las variables ambientales a gusto del usuario. Dicha interfaz gr´afica no depende de un software especifico, sino que s ´olo es necesario un cliente http como podr´ıa ser Internet Explorer, Mozilla Firefox, Google Chrome, etc.
se realiza mediante unos controladores g´enericos implementados mediante
µcontroladores 80C51F410, pertenecientes a la familia 80C51, y una serie de
componentes y circuiter´ıa que permiten el correcto funcionamiento de ´estos. Existen dos tipos de controladores distintos, los cuales son:
Controlador Sensor: Encargados de las tomas de valores ambientales como puede ser la luz y la temperatura.
Controladores Actuadores: Encargados de actuar sobre los dispositivos que modifican y estabilizan las variables ambientales como pueden ser la calefacci ´on, tiras de leds de iluminaci ´on, persianas, alarmas, etc.
R
ESUMEN EN
I
NGL
ES DEL
´
P
ROYECTO
F
IN DE
C
ARRERA
Implementaci ´on de Sistema
Dom ´otico con Servidor Raspberry
Autores:Juan Angosto Herrmann
Fernando Salgado ´Alvarez
The project described in this report consisted designing and implementing a
home automation system that could be installed in a house in order to control
environmental variables and thus get the maximum comfort of the inhabitant
automatically or manually according to their tastes and needs.
The main feature of this system consists in a distributed system, formed
by a server which is responsible for making the main decisions of the actions
performed inside the house. In addition, there are a series of slave controlers
whose function consists in keeping the environmental variables within the values
established by the server. Thus gets to keep the home in a situation of constant
wellbeing to anyone who is inside.
The system has been designed in order to reduce the amount of wire needed
for the inter-connection of the devices, by means of wireless communication. The
devices chosen for the solution are Xbee modules, which use the Zigbee protocol
in order to comunicate one between each other. The Zigbee protocol is fully
described in the IEEE 802.15.4 standard.
A web application has been used to control the distributed system. This
application allows users to control various devices inside the house and
subsequently the different environmental variables. This implementation allows
obtaining the maximum comfort by means of a very simple graphical interface.
In addition, the Graphical User Interface (GUI) does not depend on any
specific software. This means that it would only be necessary a http client (such
as Internet Explorer, Mozilla Firefox, Google Chrome, etc.) for handling the
application
The system has been integrated using a low-cost mini computer called
manage and to automatize the different environmental variables. Furthermore,
for changing and stabilizing those variables, some generic controllers have been
developed, based onµcontrollers 80C51F410.
There have been developed mainly two different types of controllers: Sensor
Controllers, responsible for measuring the different environmental values, such
as light and temperature; and Actuator Controllers, which purpose is to modify
and stabilize those environmental variables by actuating on the heating, the led
lamps, the blinders, the alarm, etc.
The combination of the RaspBerryPi and the different controllers conform the
prototype designed during this project. Additionally, this solution could be easily
expanded in order to intake further functionalities adapted to new needs that
´Indice General
I Introducci´on
15
II Ideas Generales del Proyecto
23
1. Resumen General Del Proyecto 25
2. Sistema Completo 27
2.1. Comunicaci´on Usuario→Servidor . . . 29
2.2. Comunicaci´on Servidor→Controlador . . . 30
2.3. Comunicaci´on Controlador→Controlador . . . 31
3. Motivaciones del Proyecto 33
3.1. Raspberry Pi . . . 33
3.2. Controladores . . . 34
3.4. Intereses Propios . . . 35
4. Presentaci´on del Documento 37
III Desarrollo
39
5. Interfaz Web y Comunicaci´on con el Servidor 41 5.1. Dise ˜no y Estructura de la Aplicaci´on . . . 415.1.1. Estructura de la Aplicaci´on . . . 44
5.1.2. Aplicaci´on M´ovil . . . 47
5.1.3. Aplicaci´on Ordinaria . . . 50
5.2. Petici´on de Datos al Servidor . . . 52
5.2.1. Muestra de Informaci´on en Tiempo Real . . . 52
5.2.2. Muestra de Informaci´on de Monitorizaci´on . . . 53
6. Procesamiento de Datos en el Servidor 55 6.1. Monitorizaci´on . . . 56
6.2. Control de Intensidad Lum´ınica (Tira de Leds) . . . 61
7. Controladores 65
7.1. Software de Dise ˜no de PCB’s . . . 65
7.2. Controladores . . . 67
7.2.1. Perifericos Digitales Utilizados por elµControlador . . . 70
7.2.2. Perifericos Anal´ogicos Utilizados por elµControlador . . . 71
7.2.3. M´odulos que Forman la Placa Controladora . . . 72
7.3. Placas Complementarias . . . 77
7.3.1. Placa de Comunicaci´on Wireless . . . 78
7.3.2. Placa Complementaria Sensora . . . 81
7.3.3. Placa Complementaria Actuadora . . . 84
7.4. Software de Programaci´on y Depuraci´on . . . 85
8. Comunicaci´on Entre Entidades 87 8.1. Clasificaci´on de los Mensajes . . . 87
8.2. Direccionamiento del Sistema . . . 88
8.3. Adaptador Xbee para la Raspberry Pi . . . 92
9.2. Motor de Persiana . . . 96
9.3. Calefacci´on El´ectrica . . . 97
IV Conclusiones
99
10. Resumen de Prestaciones del Sistema 101 10.1. Uso de Raspberry Pi . . . 10110.2. F´acil Instalaci´on . . . 103
10.3. Interfaz Web . . . 103
10.4. Bajo Coste . . . 104
11. Ideas de Evoluci´on del Sistema 105
12. Repercusi´on Tecnol´ogica 107
V Glosario, Bibliograf´ıa y Anexos
111
Glosario 113
Acr´onimos 117
Anexos
A. Algor´ıtmos de Programaci´on 125
B. Esquematicos y Layouts de las Placas Desarrolladas 183
C. Datasheets de Componentes Electr´onicos 191
´Indice de Figuras
2.1. Estructura de Comunicaci´on del Sistema . . . 28
3.1. Ordenador de Bajo Coste RaspBerry Pi . . . 34
5.1. Zonas de Emplazamiento para Dispositivo en Vertical . . . 43
5.2. Zonas de Emplazamiento para Dispositivo en Horizontal . . . 43
5.3. P´agina Principal de la Aplicaci´on M´ovil . . . 44
5.4. Ejemplo de Pantalla de Control de Variables Ambientales de una Habitaci´on de la Vivienda para un Dispositivo de Pantalla en Horizontal . . . 48
5.5. Ejemplo de Pantalla de Control de Variables Ambientales de una Habitaci´on de la Vivienda para un Dispositivo de Pantalla en Vertical 49 5.6. Ejemplo del Bloque de Control de la Aplicaci´on Ordinaria . . . 51
6.2. Secuencia de Acciones del Sistema Monitor . . . 60
6.3. Secuencia de Acciones del Control de Intensidad Lum´ınica . . . 62
6.4. Petici´on de Cliente por Medio de Socket . . . 63
7.1. Software de dise ˜no de PCB’s Eagle . . . 66
7.2. Placa controladora . . . 70
7.3. Reguladores de la fuente de alimentaci´on . . . 73
7.4. Circuito de Reset . . . 74
7.5. Circuito de programaci´on/depuraci´on JTAG . . . 74
7.6. Circuito de Pila para SmartClock . . . 75
7.7. Puertos DIO . . . 75
7.8. M´odulo de Leds Indicadores . . . 76
7.9. Placa Controladora con Placa Sensora y de Comunicai´on Wireless . 78 7.10. Conexi´on para la Comunicaci´on entre dos Xbee . . . 79
7.11. Placa de comunicaci´on wireless con m´odulo Xbee . . . 81
7.12. Funci´on de Transeferencia del Sensor de Luz . . . 82
7.13. Funci´on de Transeferencia del Sensor de Temperatura . . . 84
9.1. Puente en H para Control de Motor de Corriente Continua . . . 96
B.1. Esquem´atico del Circuito Completo de la placa Controladora . . . . 185
B.2. Layout Top del Circuito Completo de la placa Controladora . . . . 186
B.3. Layout Bottom del Circuito Completo de la placa Controladora . . 187
B.4. Esquem´atico de la Placa Adaptadora Xbee . . . 187
B.5. Layout Top de la Placa Adaptadora Xbee . . . 188
B.6. Layout Bottom de la Placa Adaptadora Xbee . . . 188
B.7. Esquem´atico de la Placa Complementaria Sensora . . . 189
B.8. Layout Top de la Placa Complementaria Sensora . . . 189
Parte I
Dentro del campo tecnol´ogico, la vivienda y el hogar ha encontrado un amplio abanico de posibilidades. La integraci´on de la tecnolog´ıa en el dise ˜no inteligente del hogar se conoce con el nombre de Dom´otica. Dicho t´ermino proviene de la uni´on de las palabras domus (derivada de la raiz domo que quiere decir casa en lat´ın) y la palabra francesa informatique (de la que ha derivado la palabra inform´atica).
Se puede decir que el origen de la dom´oticase remonta a la d´ecada de los 70. Es en dicha ´epoca cuando comienzan las primeras investigaciones y desarrollos de dispositivos enfocados a la automatizaci´on de las viviendas basados en la tecnolog´ıa X-10(1) desarrollada entre 1976 y 1978 en Escocia. Posteriormente surgieron diversas tecnolog´ıas entre las cuales se pueden encontrar tambi´en KNX (2) y Zigbee(3). En los siguientes a ˜nos comenz´o a cobrar inter´es internacional dicho campo buscando as´ı un modelo de vivienda ideal, lo cual inspir´o cierto af´an de investigaci´on y desarrollo. A finales de la d´ecada de los 80 y principio de los 90 nacen los primeros PC’s (Personal Computer) y comienza su integraci´on en los edificios consiguiendo as´ı un control de ciertos dispositivos electr´onicos dando lugar a lo que hoy conocemos como edificios inteligentes. Podemos decir que en Espa ˜na el origen de la dom´otica se remonta a finales de la d´ecada de los 90. De la misma manera que a dias de hoy no es aceptable que una vivienda carezca de sistema el´ectrico o agua corriente, en un futuro no muy lejano no se concebir´a viviendas que no est´en m´ınimamente domotizadas. Hoy en d´ıa el campo dom´otico est´a en cont´ınuo crecimiento y desarrollo tecnol´ogico.
laexperiencia de usuario y la usabilidad(4) dentro de ladom´otica, que se encargar´a de un manejo c´omodo, sencillo e intuitivo del sistema ofrecido a dicho usuario, el cual no tiene porque sentir ninguna afinidad con el campo tecnol´ogico que esconde ladom´otica.
De ´esta manera se entiende por dom´oticala integraci´on de la automatizaci´on, la inform´atica y las nuevas tecnolog´ıas dentro de los espacios habitables con los fines de mejorar el bienestar, el ahorro energ´etico, la seguridad, la comunicaci´on, la satisfacci´on y la comodidad del usuario de dicho espacio. (5)(6)
Debido a ´esto se obtiene un sinf´ın de posibilidades entre las cu´ales priman las diferentes aplicaciones de ladom´otica:
Programaci´on y ahorro energ´etico.
Comfort.
Seguridad.
Comunicaciones.
Accesibilidad.
Analizando cada uno de estas aplicaciones se pueden determinar los servicios y ventajas que ofrece vivir en un hogar digital.
Programaci´on y ahorro energ´etico
otros que consuman menos si no que basta con una gesti´on eficiente de los mismos como puede ser:
Programaci´on y zonificaci´on de la climatizaci´on.
Control de toldos y persianas.
Gesti´on electrica, racionalizaci´on de cargas y control de tarifas.
Uso de energ´ıas renovables.
Comfort
El confort conlleva todas las actuaciones que se puedan llevar a cabo que mejoren el confort en una vivienda. Dichas actuaciones pueden ser de car´acter tanto pasivo, como activo o mixtas.
Apagado general de todas las luces de la vivienda.
Automatizaci´on del apagado / encendido en cada punto de luz.
Regulaci´on de la iluminaci´on seg ´un el nivel de luminosidad ambiente.
Automatizaci´on de todos los distintos sistemas / instalaciones / equipos dot´andolos de control eficiente y de f´acil manejo.
Control v´ıa Internet.
Generaci´on de programas de forma sencilla para el usuario y automatiza-ci´on.
Seguridad
Alarmas de intrusi´on para detectar la presencia de personas extra ˜nas en la vivienda.
Cierre de persianas puntual y seguro.
Simulaci´on de presencia.
Detectores y alarmas de detecci´on de incendios (detector de calor, detector de humo), detector de gas (fugas de gas, para cocinas no el´ectricas), escapes de agua e inundaci´on, etc.
Alerta m´edica y teleasistencia.
Acceso a c´amaras.
Comunicaciones
Son los sistemas o infraestructuras de comunicaciones que posee el hogar.
control tanto externo como interno, control remoto desde Internet, PC, mandos inal´ambricos, etc.
Teleasistencia.
Telemantenimiento.
Informes de consumo y costes.
Transmisi´on de alarmas.
Intercomunicaciones.
Esta aplicaci´on es una de las mas complejas debido a la cantidad y variedad de limitaciones funcionales y discapacidades que existen hoy en dia. Cada usuario con su discapacidad necesitar´a unos u otros servicios por lo que ´estos han de ser personalizados para cada usuario.
Ladom´oticaaplicada a favorecer la accesibilidad es un reto ´etico y creativo pero sobre todo es la aplicaci´on de la tecnolog´ıa en el campo m´as necesario, para suplir limitaciones funcionales de las personas, incluyendo las personas discapacitadas o mayores. El objetivo no es que las personas con discapacidad puedan acceder a estas tecnolog´ıas, porque las tecnolog´ıas en si no son un objetivo, sino un medio. El objetivo de estas tecnolog´ıas es favorecer la autonom´ıa personal. Los destinatarios de estas tecnolog´ıas son todas las personas, ya sea por enfermedad, discapacidad o envejecimiento. (8)
El Sistema
Para poder realizar un sistema dom´otico en una vivienda como el propuesto en este proyecto son necesarios diversos elementos interconectados entre s´ı de tal manera que se base en una arquitectura centralizada en cuanto a que se dispone de varios peque ˜nos dispositivos capaces de adquirir y procesar la informaci´on de m ´ultiples sensores. Esta informaci´on es transmitida a un servidor central que es el encargado de la toma de decisiones en funci´on de los datos almacenados a lo largo del tiempo y a su vez ´este se encarga de transmitir dichas ordenes al resto de dispositivos distribuidos por la vivienda, los cuales act ´uan en consecuencia. Los elementos de una instalaci´on dom´otica necesarios son:
Central de gesti´on llamada servidor.
Sensores o detectores.
Parte II
Cap´ıtulo 1
Resumen General Del Proyecto
En la especialidad de Sistemas Electr´onicos y de Control, impartida en la carrera de Ingenier´ıa T´ecnica de Telecomunicaci´on, se estudian distintos campos que pueden dar lugar a tipos de proyecto diferentes. Uno de ellos en particular es el protagonista del trabajo presentado en esta documentaci´on. Se trata de los sistemas de control, una ciencia especialmente apreciada por las personas que componen el equipo que ha desarrollado esta aplicaci´on.
Este proyecto consiste en un sistema dom´otico que puede ser instalado en una vivienda para controlar distintas variables ambientales y conseguir as´ı la m´axima comodidad de los habitantes de manera autom´atica.
La comunicaci´on entre los distintos dispositivos se hace de manera inal´ambri-ca por medio de un protocolo descrito en la normaIEEE 802.15.4. Esta norma se utiliza para crear redes sin cables de transmisi´on de mensajes cortos. Para ello se ha utilizado un m´odulo de comunicaci´on wireless llamado Xbee, que gracias a una adecuada configuraci´on, permite la comunicaci´on de 2 dispositivos, emulan-do una comunicaci´on serie punto a punto por medio de unaUART.
Adem´as se dispone de una interfaz gr´afica que permite al usuario controlar la vivienda sencillamente desde cualquier dispositivo que sea capaz de conectarse a una red local. Se trata de una aplicaci´on web que puede ser controlada sin un software espec´ıfico para su utilizaci´on, siendo necesario ´unicamente un cliente http.
Cap´ıtulo 2
Sistema Completo
Para entender de manera sencilla la estructura y funcionamiento de este sistema, se ha dividido el mismo en 3 partes, teniendo en cuenta los distintos momentos de comunicaci´on entre entes del sistema.
Comunicaci´on usuario→servidor.
Comunicaci´on servidor→controlador.
Comunicaci´on controlador→controlador.
Para explicar en detalle el funcionamiento de la aplicaci´on se ha utilizado como ejemplo a un usuario tratando de mantener una temperatura constante en el sal´on de su casa por medio de nuestro sistema.
Una vez el servidor ha recogido los datos de configuraci´on de la temperatura deseada en el sal´on, debe tomar decisiones y comunicarse con el controlador de la calefacci´on para que este tenga constancia de la temperatura deseada y la mantenga estable. A esta comunicaci´on se la denomina como servidor → controlador.
Una vez el controlador tenga constancia de qu´e temperatura debe mantener, ha de medir la temperatura ambiental para saber si debe o no debe encender la calefacci´on. Para leer la temperatura ambiental, el controlador debe comunicarse con otro controlador. Este ´ultimo controlador citado tiene acceso a los sensores localizados en toda la vivienda como pueden ser sensores de luz o temperatura. A esta comunicaci´on se la denomina comocontrolador→controlador.
Por tanto el sistema completo, que como m´ınimo deber´a estar formado por un servidor y dos controladores (dos controladores por habitaci´on, uno sensor y otro actuador), debe tener un esquema general parecido al mostrado en la figura 2.1.
Figura 2.1:Estructura de Comunicaci´on del Sistema
partes.
2.1. Comunicaci´on Usuario
→
Servidor
En este escenario entran en juego un usuario, que maneja una interfaz por medio de un dispositivo, y un servidor que ofrece esa interfaz y recoge los datos fijados por el usuario. Adem´as de esto, el servidor almacena los datos de configuraci´on introducidos en una base de datos.
En el servidor habr´a instalado un sistema gestor de base de datos conocido comoApache(10) con los m´odulos necesarios para administrar dicha base de datos y para poder interpretar un lenguaje de programaci´on dise ˜nado para el desarrollo web conocido como PHP(11). Dicho lenguaje es el que ha sido utilizado para implementar la interfaz web.
2.2. Comunicaci´on Servidor
→
Controlador
Una vez procesados los datos recibidos por la interfaz web, el servidor toma las decisiones oportunas para que la configuraci´on fijada sea llevada a cabo. Entre estas decisiones, la m´as importante es la de configuraci´on del dispositivo destino del mensaje. Para la gesti´on de esta decisi´on se utiliza un direccionamiento implementado por los desarrolladores de este sistema. Debido al m´odulo de comunicaci´on de comunicaci´on wireless Xbee utilizado (el m´as sencillo y econ´omico) las comunicaciones entre dispositivos ´unicamente se pueden hacer punto a punto o por difusi´on (tambi´en conocido como comunicaci´on Broadcast). En el caso de establecer comunicaciones punto a punto, es necesario configurar el m´odulo wireless cada vez que se desee enviar un dato a un dispositivo determinado. Por tanto, la decisi´on tomada es la de enviar mensajes por difusi´on y a ˜nadir en la trama enviada una direcci´on. Esto hace que un dispositivo, que recibe un mensaje donde la direcci´on destino coincide con la suya propia, tome dicha cadena. En caso contrario lo descarta. El hecho de enviar los mensajes por difusi´on, permite transmitir ordenes comunes a todos los dispositivos a la vez, como por ejemplo un mensaje de sincronizaci´on de hora, o un mensaje de activaci´on de alarmas de emergencia, etc...
Otro escenario en el que el servidor necesita comunicarse con el controlador es en el momento en el que el primero desea registrar el valor actual de una variable ambiental para guardarla en la base de datos y hacer as´ı un historial del entorno. Para ello el servidor env´ıa una petici´on de dato al controlador sensor para que este mida y env´ıe el valor como respuesta. En este caso el direccionamiento es el mismo que el del caso anterior.
en la red.
2.3. Comunicaci´on Controlador
→
Controlador
Cap´ıtulo 3
Motivaciones del Proyecto
3.1. Raspberry Pi
Figura 3.1:Ordenador de Bajo Coste RaspBerry Pi
3.2. Controladores
En un principio los controladores iban a ser implementados con placas de desarrollo llamadasArduino(14). Se trata de unos dispositivos de hardware libre, es decir controladores de los cuales se dispondr´ıa de las especificaciones y diagramas esquem´aticos de manera p ´ublica, que disponen de un µcontrolador Atmel y pines de Entrada/Salida. Se programan mediante un lenguaje propio basado enProcessing. Son muy sencillos de programar, depurar y utilizar.
3.3. Entorno Web
En lo referente al entorno web, se han querido aprovechar los conocimientos de desarrollo web de los que disponen los aspirantes a ingenieros, para poder demostrar la versatilidad de los mismos. Hay que tener en cuenta que en lo tiempos que corren es complicado encontrar un trabajo de desarrollo de sistemas electr´onicos y por tanto, la implementaci´on de aplicaciones inform´aticas es una buena alternativa profesional, debido al margen que este negocio ofrece, ya que la infraestructura necesaria es m´as f´acil de conseguir y mantener.
La primera ventaja que ofrece la interfaz web que sirve para controlar el siste-ma es que es innecesario desarrollar una aplicaci´on espec´ıfica para cada dispositi-vo que pueda entrar en juego. Es bien sabido, que la estandarizaci´on de sistemas comerciales conlleva complicaciones, y que si una persona decide desarrollar una aplicaci´on compatible con cualquier dispositivo m´ovil, tendr´a que tener en cuen-ta 3 grandes sistemas operativos que sonAndroid, IOS y Windows. Esto sin contar con el elevado n ´umero de entornos para estaciones de trabajo no m´oviles. Por ello, con una aplicaci´on web, solo es necesario un cliente http y a ´un teniendo en cuenta que cada dispositivo tiene un tama ˜no espec´ıfico de pantalla que se tiene que estudiar, la adaptaci´on para cada uno de ellos consiste ´unicamente en cam-biar la estructura de la interfaz, nunca saliendo de un mismo entorno o lenguaje.
3.4. Intereses Propios
Cap´ıtulo 4
Presentaci´on del Documento
Un vez presentado el proyecto de manera general, se describir´a cada paso para llevarlo a cabo. Se describir´an las ideas iniciales que llevaron a ciertas b ´usquedas, las pruebas realizadas, los dise ˜nos y los pasos seguidos en la implementaci´on definitiva de las diferentes funcionalidades. Para ello se dividir´a el documento en 5 grandes partes que pueden ser independientes entre s´ı pudiendo trabajar con cada una de ellas sin tener en cuenta las dem´as. Estas son:
Interfaz web y comunicaci´on con el Servidor.
Procesamiento de datos en el Servidor.
Controladores.
Comunicaci´on entre entidades.
Parte III
Cap´ıtulo 5
Interfaz Web y Comunicaci´on con el
Servidor
Como se dijo anteriormente, una de las ventajas de crear una aplicaci´on web para la soluci´on es que permite acceder a dicha aplicaci´on desde cualquier dispositivo que disponga de un cliente http.De esta manera se consigue independencia respecto a cualquiera de los sistemas operativos disponibles en la actualidad.
Esta interfaz se aloja en la RbP con unServidor Apacheinstalado, que dispone de lo necesario para entregar una aplicaci´on web implementada en PHP y con una base de datos enMySQL(15).
5.1. Dise ˜no y Estructura de la Aplicaci´on
grupos de dispositivos: los tradicionales que disponen de un teclado y un rat´on para interactuar con ellos y los dispositivos m´oviles donde el manejo se hace gracias a una pantalla t´actil. Por ello se dise ˜naron dos entornos adaptados a cada uno de estos dos tipos de dispositivos.
Para el desarrollo del entorno web se opt´o por recurrir a 2 frameworks que ofrecen una manera sencilla de conseguir funcionalidades y presentaciones adaptadas a cada uno de los tipos de dispositivos descritos anteriormente. En lo referente a dispositivos m´oviles se utilizaJQuery Mobile, un plugin de la librer´ıa JQuery. Para los dispositivos tradicionales, como son los ordenadores se utiliza Bootstrap.
Figura 5.1:Zonas de Emplazamiento para Dispositivo en Vertical
Figura 5.2:Zonas de Emplazamiento para Dispositivo en Horizontal 6
tradicional, y dependiendo de esto, el servidor entrega una u otra presentaci´on de la aplicaci´on.
Figura 5.3:P´agina Principal de la Aplicaci´on M´ovil
Adem´as de las secciones de control de zona de la vivienda, la aplicaci´on dispone de una interfaz de presentaci´on de datos ambientales guardados en la base de datos del servidor. Esta soluci´on se basa en un formulario que permite seleccionar qu´e dato ambiental se desea que se represente en una gr´afica, en la cual se representan los valores ambientales seleccionados alojados con respecto al tiempo.
5.1.1. Estructura de la Aplicaci´on
DomoWeb/ classes/
Mobile-Detect-2.7.1/...Detector de dispositivo libreria/
funciones.php...Funciones comunes mobile/
componentes/ ...Elementos de control e indicaci´on css/ ...Hojas de estilo img/ ...Im´agenes js/...Ficheros JavaScript peticionesAjax/ ...Script de atenci´on a petici´on Ajax plugins/ ...Plugins de terceros secciones/ ...Contenedores de secciones acceder.php ...Validaci´on de usuario cabecera.php...headde la aplicaci´on index.php
Inicio de sesi´on.php...Formulario de inicio de sesi´on menu.php...Men ´u de secciones normal/
componentes/ ...Elementos de control e indicaci´on css/ ...Hojas de estilo img/ ...Im´agenes js/...Ficheros JavaScript peticionesAjax/ ...Script de atenci´on a petici´on Ajax plugins/ ...Plugins de terceros secciones/ ...Contenedores de secciones acceder.php ...Validaci´on de usuario cabecera.php...headde la aplicaci´on index.php
logueo.php ...Formulario de logueo menu.php...Men ´u de secciones config.php...Fichero de configuraci´on global index.php
t´actil en vez de un click con el rat´on cambia mucho la programaci´on de comportamiento y gesti´on de dicha detecci´on.
Una vez expuesto el ´arbol de directorios de las aplicaciones se va a proceder a comentar c´omo se ha implementado los distintos elementos de las aplicaciones. La idea b´asica es modular la aplicaci´on en partes correspondientes a cada uno de las secciones, y dentro de cada una de estas secciones a ˜nadir componentes que representan los indicadores, controles, etc...
En el directorio/componentes/se encuentran todos y cada uno de los elementos que van a aparecer en las secciones. Todos ellos son reutilizables entre secciones, es decir, que el reloj que aparece en la secci´on ”sal´on” en el mismo que aparece en la secci´on ”cocina”. De esta manera, si en un futuro se desease hacer una administraci´on gr´afica para a ˜nadir y configurar la interfaz web, se podr´a hacer sencillamente con un sistema de arrastre de elementos, de la misma manera en la que se arrastran los widgets en un entorno Wordpress (sistema de gesti´on de contenidos enfocado a la creaci´on de sitios web peri´odicamente actualizados).
El m´etodo de login o inicio de sesi´on consiste en un array de nombres y contrase ˜nas definido en el fichero de configuraci´on que es comparado con los datos que el usuario introduce a la hora de logarse. Si dicha informaci´on es v´alida y coincide con alguno de los usuarios autorizados, se crea una variable de sessi´on que contiene un valor trueen un ´ındice v´alido. Definir una variable de datos de usuarios no es, a priori, la soluci´on m´as com ´un, pero resulta la opci´on m´as sencilla en caso de necesitar dar de alta nuevas personas en el control de la casa.
Finalmente, esta aplicaci´on dispone de un plugin de reconociento de disposi-tivos cliente (ya sea entorno web o m´ovil) que permite diferenciar que disposici´on de los elementos (mandos necesarios para administrar las variables controlables) es necesaria en la interfaz correspondiente a cada uno.
En el desarrollo de ambas aplicaciones, tanto m´ovil como ordinaria, se ha optado por utilizar la librer´ıa JQuery con el fin de aprovechar las ventajas que ofrece a la hora de manejar los documentos HTML.
5.1.2. Aplicaci´on M´ovil
En lo referente a la aplicaci´on movil, desde un punto de vista de dise ˜no web, la principal caracter´ıstica para que el usuario encuentre c´omoda la navegaci´on en una web es hacer accesibles los elementos de control en zonas donde los dedos tengan facilidad de llegar a pulsar. Ademas los elementos que muestran informaci´on deben estar localizados en zonas que no quedan tapadas a la hora de manejar la interfaz (Figuras5.1y5.2). Esta filosof´ıa no es una regla estricta de dise ˜no pero se debe respetar dentro de lo posible.
para que la interfaz posicione los elementos de la misma en determinados lugares dependiendo de su utilizaci´on horizontal (Figura5.4) o vertical (Figura5.5).
Figura 5.5:Ejemplo de Pantalla de Control de Variables Ambientales de una Habitaci´on de la Vivienda para un Dispositivo de Pantalla en Vertical
Con el fin de que la aplicaci´on tenga un aspecto adecuado para los dispositivos m´oviles se ha utilizadojQuery Mobile. Se trata de un framework que marca una pautas de maquetaci´on sencillas y se ocupa de generar elementos con aspectos determinados al fijar atributos class (referencias que ofrecen la posibilidad de asignar estilos, caracter´ısticas o comportamientos espec´ıficos). De esta manera, se asignan los estilos oportunos a cada elemento.
5.1.3. Aplicaci´on Ordinaria
Para esta parte de la aplicaci´on web no hay puntos de dise ˜no tan importantes que determinen una posici´on adecuada para los distintos elementos de la interfaz. Por ello, el posicionamiento de estos se ha fijado bajo criterio propio (Figura5.6).
En primer lugar, se puede dividir la aplicaci´on base en dos partes: Men ´u y Contenido.
El primero se encuentra a la derecha de la pantalla, y contiene el acceso a todas las secciones de la aplicaci´on.
El segundo se encuentra a la izquierda de la pantalla y muestra los mandos de control e indicadores de informaci´on correspondientes a la secci´on en la que se encuentra el usuario.
Al contrario de la versi´on para dispositivos m´oviles, en la versi´on ordinaria no es necesario variar la posici´on de los elementos dependiendo del tama ˜no o posici´on de la pantalla. Por tanto, la web se mantiene siempre con la misma presentaci´on independientemente del navegador utilizado.
Bootstrap (16) el cual es un framework de software libre para dise ˜no de sitios y aplicaciones web. ´Este contiene plantillas de dise ˜no con tipograf´ıa, formularios, botones, cuadros, men ´us de navegaci´on y otros elementos de dise ˜no basado en HTML y CSS, as´ı como, extensiones de JavaScript opcionales adicionales. De la misma manera que con jQuery Mobile, se deben aplicar ciertos valores a los atributos class de los elementos de la web para que el plugin se ocupe del resto. Para la colocaci´on de cada elemento, Bootstrap divide el site (p´agina del entorno) en un n ´umero variable de columnas de mismo tama ˜no, por defecto 12 y un n ´umero de filas variable. De esta manera se consigue hacer un sistema de rejilla mediante el c ´ual podremos posicionar los elementos deseados. Cuando se quiere a ˜nadir un elemento, como podr´ıa ser un t´ıtulo, se asigna un offset que asigna la posici´on donde se quiere colocar dicho elemento y se asigna un tama ˜no en funci´on de las columnas que se quiere que ocupe dicho elemento. As´ı se consigue, entre otras opciones, estructurar los diferentes bloques definidos por bootstrapdel sitio web a desarrollar. Posteriormente dichos bloques son rellenados por botones, barras deslizantes, men ´us, etc.
5.2. Petici´on de Datos al Servidor
Hay distintos momentos en los que la aplicaci´on muestra datos que pueden variar mientras la interfaz se est´a mostrando en el cliente http. De este modo, el usuario puede variar la configuraci´on de la informaci´on que est´a visualizando. Un ejemplo del primer caso es la funcionalidad de mostrar la temperatura ambiental de la zona elegida en tiempo real. Un ejemplo del segundo caso es la secci´on donde se muestran los datos recogidos en la monitorizaci´on de la viviendo en forma de gr´afico.
5.2.1. Muestra de Informaci´on en Tiempo Real
En esta parte s´olo se ha modificado el ´area que parte desde la interfaz web hasta elServidor Apache. As´ı que se fijar´a una configuraci´on en la que se dar´a por hecho que elRaspberry Pidispone de la informaci´on solicitada por el cliente en el momento de la petici´on.
Para una funcionalidad de muestra de datos a tiempo real, este no es un comportamiento adecuado, ya que es una molestia que la interfaz se actualice cada vez que el servidor env´ıa el dato. Pero hay otra alternativa. De alguna manera se necesita pedirle al servidor la informaci´on sin que ´esta tenga forma de p´agina web a cargar.
La librer´ıa JQuery dispone de una funci´on que permite hacer peticiones al servidor en segundo plano, sin que esto se plasme en lo mostrado por el cliente web. Esta funci´on se llamaAjaxy con esto se consigue modificar el contenido de la web sin que haya recarga.
Aplicado a este proyecto, la soluci´on mas eficaz es pedir al servidor la informaci´on necesaria en un periodo de 30 segundos o 1 minuto, y una vez recibida la respuesta, se modificar´a el contenido con Javascript.
La ´unica informaci´on que no depende del sistema y que debe mostrarse a tiempo real es la temperatura ambiente. Este dato se muestra en grados cent´ıgrados y en un term´ometro virtual con valor m´aximo de 50 grados.
5.2.2. Muestra de Informaci´on de Monitorizaci´on
Aunque no se trate de una situaci´on en la que la informaci´on se muestre en tiempo real, se ha decidido recurrir a la t´ecnica de desarrollo web Ajaxtambi´en para que la interfaz tenga un aspecto m´as moderno al no recargar la p´agina cada vez que se valida el formulario de configuraci´on de la gr´afica.
para sacar los datos acordes con la configuraci´on y los devuelve al cliente donde este los plasma en la gr´afica.
El formulario dispone de 4 campos que son modificables:
Zona Deseada: Se trata de la zona de la vivienda que se desea visualizar la informaci´on. Coincide con el controlador sensor que le corresponde. Se representa con un elemento select el cual inserta un desplegable de opciones en el formulario y un option el cual define una opci´on dentro de un men ´u desplegable creado por el elementoselect, por cada controlador o zona. Dichas zonas se leen de la base de datos antes de ser mostradas.
Fecha de Inicio y Fecha de Fin: El rango de tiempo que se desea visualizar. Al menos uno de los campos ha de ser completado. En caso de que los dos campos sean rellenados, los resultados mostrados ser´an los que est´en comprendidos entre dichos valores de tiempo. Por o contrario si el campo de inicio es el ´unico fijado, los datos mostrados ser´an los que est´en comprendidos entre dicho valor y el momento actual. Y en caso de que el campo final sea el ´unico fijado, se mostrar´an los valores correspondientes al d´ıa indicado. Los campos se componen de d´ıa, mes, a ˜no y hora.
Cap´ıtulo 6
Procesamiento de Datos en el
Servidor
En esta parte del proyecto existen m ´ultiples posibilidades que pueden ser implementadas. Al poder ejecutar aplicaciones en un dispositivo con un sistema operativo y una capacidad de procesamiento y almacenamiento muy grande, se puede definir cualquier comportamiento cuyas decisiones ser´an posteriormente enviadas como ´ordenes sencillas. Para entenderlo, se puede decir que encender una luz a una cierta hora fijada es sencillo, pero tomar las decisiones de a qu´e hora, con qu´e frecuencia y dependiendo en base a qu´e datos, es algo m´as complicado que requiere un sistema m´as amplio que un µcontrolador de prop´osito general. Por ello, todas estas acciones se dejan en manos del servidor.
adelantarse a estos hechos para controlar las variables ambientales que necesitan tiempo para ser ´optimas. Por ejemplo, si en invierno el usuario sale de casa para ir a trabajar, la vivienda debe de ser capaz de apagar la calefacci´on sin que usted tenga que preocuparse de ello, y lo mismo pasa al volver, la vivienda debe de adelantarse a su llegada para que la casa est´e caliente cuando llegue sin haber tenido que tenerla encendida todo el d´ıa.
6.1. Monitorizaci´on
Esta funcionalidad es muy interesante en el sistema, ya que es una de las bases para la mejora y soluci´on de necesidades que tenga el usuario de la vivienda. Esta monitorizaci´on consiste en el almacenamiento de datos recogidos por los sensores con un cierto periodo y las acciones m´as relevantes que se produzcan tanto en la configuraci´on, como en el d´ıa a d´ıa de las personas presentes en la casa.
La informaci´on se almacena en una Base de Datos gestionada por un servidor MySQL. Se compone de tres tablas, descritas a continuaci´on.
Tablazonas:
• id: Identificador ´unico de zona, su incremento es autom´atico cuando
se a ˜nade un dato nuevo y es la clave principal de la tabla. Es de tipo
SmallInt.
• nombre: Nombre de la zona (por ejemplo ”posici´on persiana sal´on”,
”intensidad luz ba ˜no 1”, ...), es un campo de tipoVarCharque permite 50 caracteres.
• descripcion: Descripci´on de la zona, es un campo de tipo VarChar que
• idcontrolador: Identificador del controlador que aporta el dato
registra-do, coincide con la direcci´on de red del mismo. Es de tipoSmallInt.
Tablavariables:
• id: Identificador ´unico de variable, su incremento es autom´atico
cuando se a ˜nade un dato nuevo y es la clave principal de la tabla. Es de tipoSmallInt.
• nombre: Nombre de la variable, es un campo de tipo VarChar que
permite 50 caracteres.
• descripcion: Descripci´on de la variable, es un campo de tipo VarChar
que permite 250 caracteres.
• alias: Nombre de identificaci´on de la variable, es un campo de tipo
VarCharque permite 50 caracteres.
• unidad: Nombre de la variable (por ejemplo ”grados cent´ıgrados”,
”luxes”, ...), es un campo de tipoVarCharque permite 50 caracteres.
• simbolounidad: Simbolog´ıa de la unidad registrada (por ejemplo ”oC”,
” %”, ...), es un campo de tipoVarCharque permite 10 caracteres.
Tablaregistrovars:
• id: Identificador ´unico de dato registrado, su incremento es autom´atico
cuando se a ˜nade informaci´on nueva y es la clave principal de la tabla. Es de tipoBigInt.
• idvariable: Identificador de la variable que representa el dato, coincide
con la clave ´unica de la tabla variables correspondiente. Es de tipo
SmallInt.
• valor: Valor del dato registrado, es de tipo Decimal de 15 cifras de
• fecha: Fecha de registro del dato, es de tipoTimeStamp y su valor por
defecto es el valor del tiempo en el momento en el que se registra el dato.
• idzona: Identificador de la zona a la que pertenece el valor registrado,
coincide con la clave ´unica de la tablazonascorrespondiente. Es de tipo
SmallInt.
En este prototipo, la monitorizaci´on consiste en el registro de la temperatura y la intensidad lum´ınica de la habitaci´on donde se encuentra la placa sensora.
En este escenario entran en juego el sistema Raspberry Pi y un controlador sensor. Cada minuto, el primero env´ıa al segundo una petici´on de dato a recoger por uno de los sensores. Al recibir el destinatario dicho mensaje, ´este toma el valor de la variable ambiental midiendo la tensi´on a la salida del sensor por medio delADC. Una vez el valor ha sido recogido, lo convierte en el resultado correspondiente a la unidad de la variable medida y env´ıa una respuesta al dispositivo que ha pedido el dato. Al recibir la contestaci´on, el servidor guarda el valor en la base de datos. Acto seguido, se vuelve a repetir la secuencia de acciones para medir otra variable. Esto ocurre tantas veces como variables distintas son capaces de medir los sensores.
Los mensajes enviados en esta funcionalidad tienen un formato com ´un donde se indica lo necesario para que cada dispositivo sepa de qu´e tipo de mensaje se trata, cu´al es el destinatario y, en caso de contener un valor, la representaci´on del mismo.
Esta estructura es la siguiente:
Mensaje de Respuesta: [direcci´on origen] [comando de petici´on a la que se responde] [valor]
Para el mensaje de respuesta, no ser´ıa necesaria la direcci´on de destino, puesto que el dispositivo que ha hecho la petici´on espera la respuesta de un sensor y un comando determinados. Este aspecto resulta relevante en el momento en el que varios dispositivos hacen la misma petici´on al mismo tiempo. En este caso, el sensor solo necesitar´ıa enviar la respuesta una sola vez, puesto que ninguno de los dispositivos que preguntan descartar´ıa el mensaje de vuelta.
A continuaci´on se va a describir las pruebas realizadas enumerando las configuraciones de cada dispositivo (Figura 6.1) y la secuencia de acciones realizadas (Figura6.2).
Figura 6.1:Configuraci´on de Comunicaci´on del Sistema Monitor
Figura 6.2:Secuencia de Acciones del Sistema Monitor
6.2. Control de Intensidad Lum´ınica (Tira de Leds)
En esta parte del proyecto se pretende controlar, por medio de la interfaz web, la iluminaci´on de una zona por medio del control de intensidad de una tira de LEDs variando el ciclo de trabajo con el que se conmuta dicha fuente de luz.
En la parte que concierne al servidor, cuando se modifica el valor del control de intensidad lum´ınica a trav´es del slider circular (o barra deslizante) se genera un dato que es enviado por el dispositivo cliente (por ejemplo un smartphone) a un socket(17) de escucha del servidor y que es recibido por ´este en forma de paquete http. Acto seguido, el servidor procede a la extracci´on del mensaje orden y su interpretaci´on de manera que, en funci´on de la orden, se env´ıe dicho mensaje al controlador correspondiente y ´este act ´ue en consecuencia fijando la intensidad lum´ınica deseada. Dicho mensaje se env´ıa mediante el m´odulo de comunicaci´on wireless, a ˜nadido a la Raspberry Pi, que es recibido por el m´odulo de comunicaci´on wireless a ˜nadido al controlador, el cual lo transmite a trav´es de su uart conectada con la uart del µcontrolador. Mediante al algor´ıtmo de programac´ıon que tiene grabado y almacenado en su memoria flash act ´ua en consecuencia con el mensaje recibido.
Las tareas que realiza laRaspberry Pipara cumplir con estas funciones son las indicadas en el siguiente diagrama.
Figura 6.3:Secuencia de Acciones del Control de Intensidad Lum´ınica
iluminaci´on no es demasiado preciso. Para mitigar ese efecto, se ha fijado el env´ıo de petici´on de intensidad lum´ınica en tramos de 5 % de la intensidad m´axima. As´ı, si el usuario modifica de 0 % a 50 % la intensidad, solo se envian 10 mensajes en vez de 50. Esto permite que el tiempo de respuesta m´axima del servidor aumente a 50 milisegundos. Debido a que las comunicaciones por WIFI no son muy estables, de vez en cuando se puede tener la sensaci´on de que la luz var´ıa con un ligero parpadeo intermitente.
Figura 6.4:Petici´on de Cliente por Medio de Socket
6.3. Env´ıo de Dato de Temperatura Ambiental
Como se describi´o en el cap´ıtulo Interfaz Web y Comunicaci´on con el Servidor, hay una funcionalidad para el control de temperatura, en la que se muestra la temperatura ambiental actual. Para ello, se env´ıa al servidor una petici´on de valor de dicha variable con un periodo determinado, para posteriormente recibirlo y mostrarlo en la interfaz.
Cap´ıtulo 7
Controladores
7.1. Software de Dise ˜no de PCB’s
Con el fin de llevar a cabo el proyecto aqui descrito se ha recurrido al desarrollo de diversas placas provistas de un µcontrolador. Para ello ha sido necesario utilizar diversas herramientas inform´aticas para facilitar el dise ˜no de la circuiter´ıa impresa necesaria para poder desarrollar placas controladoras que informaran al servidor de la situaci´on actual o que actuar´an en funci´on de lo que el servidor ordene.
Conocido el manejo de distintos softwares de dise ˜no de PCB’s como puede ser Orcad, KiCad, DesingSpark se decidi´o usar un software llamado EAGLE (Figura7.1). Las principales ventajas del manejo de Eagle frente a otros sotwares de dise ˜no son:
La compatibilidad con diversos sistemas operativos, ya que puede trabajar tanto en Windows, Mac y Linux.
Los escasos requisitos necesarios exigidos por el software para su correcto funcionamiento e instalaci´on.
Servicio de soporte por expertos de la compa ˜nia mediante el foro de su pagina web.
Las fuentes para el dise ˜no de nuestra fueron diversos tutoriales conseguidos por internet, el dise ˜no de la ya citada anteriormente de la asignatura ISE y c´alculos y desarrollos realizados por cuenta propia como podr´ıa ser el dise ˜no de los circuitos reguladores los cuales han sido estudiados en la asignatura Circuitos Electr´onicos.
7.2. Controladores
Debido al previo estudio y manejo del µcontrolador 80C51F320 de Silicon Laboratories en la asignatura ISE, se decidi´o usar un µcontrolador parecido con fin de poder implementar nosotros la placa controladora sin tener que usar una ya dise ˜nada, fabricada y comercializada (tipo Arduino), pero con las facilidades del previo conocimiento de su manejo tanto en concepto de disponibilidad de perif´ericos, manejo de los registros, programaci´on, etc .
En este caso se decidi´o usar el modelo de µcontrolador 80C51410 (18) que incluye ciertas mejoras, como puede ser un reloj a tiempo real (Sma Real Time Clock) el cual es un reloj de bajo consumo de 47 bits que permite la cuenta de hasta 137 a ˜nos con el a ˜nadido de que incluye alarmas, 32Kb de memoria interna programable en vez de los 16Kb disponibles de su modelo inferior y un conversor ADC de 12 bits en vez de los 10 bits de los que dispone el modelo inferior. Tambi´en se escogi´o dichoµcontrolador con el fin de realizar un estudio previo en su manejo y programaci´on para as´ı ampliar conocimientos a la hora de utilizar diversosµcontrolador en un futuro.
de Programaci´on y Depuraci´on. Debido a la necesidad de gestionar la recepci´on de datos (uart) por parte de los controladores de manera inesperada, ya que el controlador no es capaz de saber cuando el servidor env´ıa ´ordenes, se ha tenido que utilizar un sistema de gesti´on multitarea de manera que ´estos sean capaces de recibir datos mientras que ejecutan otras tareas. Gracias a este sistema multitarea se consigue la ventaja frente a los sistemas que manejan una ´unica tarea de, por ejemplo, poder estar ejecutando la tarea de recepci´on de datos (uart) a la vez que se ejecuta la tarea que modifica la iluminaci´on de una habitaci´on mediante la tira de leds.
La placa dise ˜nada funciona como un controlador gen´erico el cual es v´alido para la realizaci´on no s´olo de nuestro proyecto, sino que ´esta ha sido dise ˜nada con el fin de poder adaptarPCB’s adicionales de manera que se puedan insertar o extraer, dando pie a distintas funcionalidades de nuestroµcontrolador, o en su defecto ampliar el margen de funcionamiento de dicho proyecto.
Cabe destacar que algunos de los diferentes m´odulos que componen la placa controladora, como pueden ser los reguladores que forman la fuente de alimentaci´on, el circuito de reset, la pila para el SmartClock o conexion al transformador de alimentaci´on externa de 12V han sido aislados del circuito general mediante jumpers con el fin de poder separarlos del µcontrolador. Tambi´en se han a ˜nadido puntos de test donde se podr´a verificar el correcto funcionamiento de los m´odulos de alimentaci´on formados por los reguladores de tensi´on.
A parte de haberse dise ˜nado y desarrollado la placa controladora, tambi´en se han dise ˜nado y desarrollado variasPCB’s adicionales y extra´ıbles como pueden ser:
ZigBee
Sensora, con sensores de temperatura y luz.
Actuadora, con rel´es para la activaci´on de luces leds, motores para persianas, etc.
De esta manera se dise ˜n´aran y desarrollar´an dos m´odulos controladores por habitaci´on. Uno de ellos ser´a un m´odulo sensor formado por una placa controladora, una placa de comunicaci´on wireless y una placa sensora, encargado de tomar medidas de luz y temperatura para posteriormente comunic´arselo al servidor y al m´odulo actuador. El otro m´odulo sera un m´odulo actuador, el cual estar´a formado por una placa controladora, una placa de comunicaci´on wireless y una placa actuadora de tal manera que dicho m´odulo sera el encargado de recibir las ordenes del servidor o del m´odulo sensor para actuar en consecuencia y bajar/subir persianas, controlar la iluminaci´on por leds, o activar/desactivar la calefacci´on de la habitaci´on.
Figura 7.2:Placa controladora
7.2.1. Perifericos Digitales Utilizados por el
µ
Controlador
Elµcontrolador 80C51F410 tiene varios perif´ericos digitales como pueden ser los puertos I/O, los timers (timer 0, timer 1, timer 2 y timer 3), PCA, UART, SMBus, SPI, Crossbar y CRC. Para la realizaci´on este proyecto se han tenido que usar varios perifericos para conseguir los objetivos deseados. Los diferentes perifericos que han sido utilizados son:
En lo referente a los Puertos I/O se han utilizado los siguientes aqu´ı citados:
• P0.4 como transmisi´on (TX) del perif´ericoUARTpara la comunicaci´on
con el m´oduloXbee
• P0.5 como recepci´on (RX) del perif´erico UART para la comunicaci´on
con el m´oduloXbee
• P1.0 como entrada anal´ogica para elADCy la conversi´on de la se ˜nal
• P1.1 como entrada anal´ogica para elADCy la conversi´on de la se ˜nal
del sensor de luz SFH5711
• P2.7 como pueto de programaci´on y depuraci´on
Timer 0 : Usado por el sistema operativo (RTOS) RTX51 Tiny 51 en modo 1 para generar una interrupci´on peri´odica con el fin de generar Ticks que ocurren cada 10000 ciclos m´aquina que luego ser´an utilizados en funciones del RTOS.
Timer 2 : Usado en modo autorecarga con el fin de generar una frecuencia de 60 Hz con la que luego modificando su dutty cycle se conseguir´a mayor o menor iluminaci´on.
UART: Usado como perif´erico de comunicaci´on con el m´odulo Xbee integrado en una placa adaptadora que nos permita conexionar sus pines de DataIn y DataOut con los pines RX(P0.5) y TX(P0.4) de nuestroµcontrolador para poder gestionar la comunicaci´on wireless. Para ello se configura la uartcon unbaudratedeterminado y generado por el Timer 1 en modo 2 de autorrecarga. (19)
Crossbar: Configurado de tal maneras que se aislen los pines P0.4 (TX) y P0.5 (RX) consiguiendo as´ı que dichos pines no se puedan ser utilizados para cualquier otra finalidad que no sea la transmisi´on y recepci´on de datos serie.
7.2.2. Perifericos Anal´ogicos Utilizados por el
µ
Controlador
AMUX (multiplexador), 2 comparadores de tensi´on, tensi´on de referencia, regulador de tensi´on y un sensor de temperatura.
Para la realizaci´on de dicho proyecto se han tenido que usar varios perif´ericos para conseguir los objetivos deseados. Los diferentes perif´ericos que se han utilizado han sido:
ADC: Usado junto con el perif´erico anal´ogico AMUX(multiplexador) con el fin de convertir las se ˜nales generadas por los sensores de luz y de temperatura para poder tratar y transmitir dichas se ˜nales y posteriormente reaccionar en funci´on de los valores de dichas se ˜nales. Para ello se ha de usar el multiplexador (AMUX) de tal manera que en funci´on del momento y la se ˜nal deseada se multiplexe una entrada anal´ogica que ser´a tratada posteriormente por el ADC y as´ı permitir la posibilidad de convertir hasta 27 se ˜nales(cada una correspondiente a un pin de un puerto distinto), de los cuales solo se usar´an 2 de ellos, uno para la se ˜nal del sensor de luz y otra para la se ˜nal del sensor de temperatura.
Tensi´on de referencia: Utilizada con el fin de tener una referencia a la hora de poder convertir las se ˜nales anal´ogicas a digitales ya sea la se ˜nal del sensor de luz o del sensor de temperatura.
7.2.3. M´odulos que Forman la Placa Controladora
circuito de pila para SmartClock, puertos DIO y m´odulo de leds indicadores. A continuaci´on se describir´an mas detalladamente los distintos m´odulos de nuestra placa controladora:
El m´odulo de la fuente de alimentaci´on esta formado por dos reguladores de tensi´on modelo LM317(20) (Figura 7.3), los cuales entregan 5V y 3,3V respectivamente habiendo sido configurados anteriormente para poder entregar dichos valores. Con dichas tensiones se podr´a proporcionar alimentaci´on al µcontrolador, al m´odulo de comunicaci´on wirelessXbee y al m´odulo de programaci´on y depuraci´on JTAG.
Figura 7.3:Reguladores de la fuente de alimentaci´on
Figura 7.4:Circuito de Reset
M´odulo de programacion JTAG compuesto de un conector para cable paralelo de 10 pines (Figura 7.5) m´as diversos componentes como pueden ser resistencias y leds. A trav´es dicho m´odulo se podr´a programar la memoria flash del µcontrolador y depurar el c´odigo de programaci´on desarrollado.
Figura 7.5:Circuito de programaci´on/depuraci´on JTAG
Figura 7.6:Circuito de Pila para SmartClock
Los puertos de entrada/salida tambi´en conocidos como puertos DIO o Data Input/Output (Figura7.7). Compuestos simplemente por conectores planos que permiten acoplar diferentes placas para diversas funcionalidades. Adem´as se incluye un puerto adicional de alimentaci´on independiente de los puertos DIO del µcontrolador donde se dispone de se ˜nales como 12V, 5V, 3V3, VDD, Reset y GND que permiten proporcionar diversas se ˜nales de alimentaci´on a las distintas placas externas que se podr´an conectar a la placa controlador.
El m´odulo de leds indicadores (Figura 7.8). Formado b´asicamente por sencillos componentes como leds y resistencias mediante los cuales se puede detectar si se transmite o recibe a trav´es de laUARTdelµcontrolador o si se programa o depura a trav´es del conector JTAG.
Figura 7.8:M´odulo de Leds Indicadores
7.3. Placas Complementarias
Para poder ampliar la funcionalidad de la placa controladora desarrollada fue necesario implementar y dise ˜nar diversas placas complementarias. Dichas placas cumplen un dise ˜no modular con el fin de que conecten unas encima de otras y, a su vez, quedan todas ellas conectadas con la placa controladora a trav´es de sus puertos DIO. De esta manera la placa controladora hace las veces de placa base para las distintas placas complementarias. Como ya se coment´o anteriormente es necesario tener dos placas controladoras distintas para cada habitaci´on de la casa. Esto se consigue a ˜nadiendo unas u otras placas complementarias a nuestra placa controladora. Para conseguir dicho resultado se a ˜nade una placa de comunicaci´on wireless con el m´odulo Xbee en ambas placas y por encima de dicha placa se a ˜nade una placa sensora o una placa actuadora consiguiendo as´ı dos placas con distintas funcionalidades. Como generalidad, dichas placas cuentan todas ellas con un sistema de pines situados en la misma posici´on con el fin de que se puedan conectar unas con otras consiguiendo as´ı el dise ˜no modular deseado. Las diversas placas que se han tenido que dise ˜nar y desarrollar para crear una placa controladora capaz de intervenir en nuestro sistema final son:
Placa de comunicaci´on wireless
Placa sensora
Placa actuadora
Figura 7.9:Placa Controladora con Placa Sensora y de Comunicai´on Wireless
7.3.1. Placa de Comunicaci´on Wireless
La placa de comunicaci´on wireless (Figura 7.11) est´a compuesta por los pines encargados de conexionar dicha placa con la placa controladora adem´as del conexionar ´estos con los pines del m´odulo de comunicaci´on wireless Xbee mediante el cual la placa controladora es capaz de transmitir o recibir mensajes.
Para ello s´olo se debe disponer de:
Una conexi´on entre el pin de entrada delXbee(DIN) y el pin de salida TX de laUARTdelµcontrolador.
Una conexi´on entre el pin de salida delXbee(DOUT) y el pin de entrada RX de laUARTdelµcontrolador.
Una conexi´on a alimentaci´on de tensi´on a 3,3 V.
Xbee: M´odulo de Comunicaci´on Wireless
Antes de continuar, se explicar´an los aspectos b´asicos del m´odulo de comunicaci´on wireless Xbee(21). ´Este es un m´odulo que trabaja por radio frecuencia dentro de la frecuencia ISM a 2,4 GHz mediante el estandar IEEE 802.15.4teniendo un alcance m´aximo entre los m´odulos de 30 metros.
A su vez el Xbeeofrece numerosas posibilidades y complejidades pero en el desarrollo de este proyecto el manejo y configuraci´on tienden a la sencillez ya que se usan las menores conexiones posibles. Una de las ventajas de la utilizaci´on del m´odulo Xbee es su sencilla conexi´on y comunicaci´on con el µcontrolador a trav´es de la UARTsin necesidad de componentes intermedios que transformen los niveles l´ogicos para la compatibilidad en la comunicaci´on. En la Figura7.10 se puede observar el m´etodo b´asico de conexi´on, apreci´andose as´ı la sencillez del sistema para conseguir establecer una comunicaci´on entre dispositivos del mismo tipo.
Figura 7.10:Conexi´on para la Comunicaci´on entre dos Xbee
encontrar dentro de una misma vivienda. Para ello se puede utilizar un comando en la consola de cualquier sistema operativo:
Netsh wlan show all (Consola de Comandos en Windows)
Iwlist scan (Consola de Comandos en Linux)
Este comando proporciona la informaci´on de las diferentes redes Wifi que se encuentran al alcance indicando est´andares, canales, tipo de red en cuesti´on, cifrado, etc. Atendiendo a estos par´ametros se puede tomar la decisi´on de que canal utilizar para la comunicaci´on de los distintos m´odulos Xbee. En este caso se ha elegido el Channel C, el cual trabaja en la frecuencia de 2.41 MHz, se aleja de las frecuencias de los extremos del est´andarIEEE 802.15.4y de las frecuencias de los canales de las diferentes redes Wifi detectadas en la vivienda donde se desarrolla dicho proyecto. El resto de par´ametros de configuraci´on del m´odulo Xbee que han sido establecidos son el Baudrate (9600 bps) que ha de coincidir con el Baudrate de la uart µcontrolador, su direcci´on de origen (source adress) y la direcci´on de destino (destination adress) en caso de requerir una conexi´on punto a punto, pero en este caso se transmite porBroadcasty se filtra por software dichas direcciones. En la comunicaci´on porBroadcasttodos los m´odulos en la red tienen la misma configuraci´on de direccionamiento la cual ser´a de la siguiente manera:
DL (Destination Low Address) = 0x0000FFFF
DH (Destination High Address) = 0x00000000 (valor por defecto)
Los mensajes transmitidos entre los Xbee tienen la siguiente estructura XXXXX COMANDO VALOR
LZFR para modificar el dutty cycle y variar la ilumunaci´on led.
TEMP para obtener el valor medido por el sensor de temperatura.
MILZ Para obtener el valor medido por el sensor de luz.
Figura 7.11:Placa de comunicaci´on wireless con m´odulo Xbee
7.3.2. Placa Complementaria Sensora
La placa est´a compuesta por los pines encargados de conexionar dicha placa con la placa controladora adem´as de un sensor de luz y un sensor de temperatura de los cu´ales se obtienen las se ˜nales que posteriormente se convierten mediante elADCdelµcontrolador para actuar en consecuencia.
dicho sensor. Dicho fotodiodo est´a ajustado de tal manera que permite detectar el mismo cambio en la luminosidad que el ojo humano es capaz de percibir, con una precisi´on del 1 %. Este aspecto supone una gran ventaja de manejo, en lo que a aspectos dom´oticos se refiere.
La funci´on de transferencia entregada por dicho sensor se puede obtener mediante la siguiente expresi´on:
Iout = S×log(Ev/Eo)
Dicho valor de corriente es controlado mediante una resistencia de salida de valor 44 Kohms que nos proporciona unos valores de tension comprendido entre 0V y 2,5V aptos para ser convertidos por nuestroADCdelµcontrolador.
En la gr´afica adjunta (Figura 7.12) se puede visualizar dicha funci´on de transferencia.
Los valores orientativos de iluminaci´on son:
50 lux→Sala de una vivienda familia
400 lux→Salida o puesta de sol en un d´ıa despejado
32.000 lux→Luz solar en un d´ıa medio (m´ın.)
100.000 lux→Luz solar en un d´ıa medio (m´ax.)
El sensor de temperatura elegido(24) es el MCP9701A(25) de la marca MICROCHIP el cual entrega un valor de tensi´on equivalente a la temperatura ambiente de la sala donde se encuentra dicho sensor con una precisi´on de±2oC en un rango comprendido entre 0oC a 70oC.
La funci´on de transferencia entregada por dicho sensor se puede obtener mediante la siguiente expresi´on:
Vout = Tc×Ta + V(0oC)
Donde Tc es el coeficiente de temperatura, cuyo valor es de 19.5 mV/oC.
En la gr´afica adjunta(Figura 7.13) se puede visualizar dicha funci´on de transferencia.
Resulta rese ˜nable a ˜nadir que se podr´ıa haber utilizado el sensor de tempera-tura integrado en el µcontrolador. Pero con el prop´osito de obtener una medi-da de temperatura m´as fiable se ha utilizado un sensor externo a ´el, ya que el
Figura 7.13:Funci´on de Transeferencia del Sensor de Temperatura
A continuaci´on se muestra una imagen de la placa sensora (Figura7.14)
Figura 7.14:Placa Sensora
