Autorizada la entrega del proyecto al alumno: Álvaro Arranz Domingo EL DIRECTOR DEL PROYECTO. Álvaro Sánchez Miralles

Transcripción

1 Autorizada la entrega del proyecto al alumno: Álvaro Arranz Domingo EL DIRECTOR DEL PROYECTO Álvaro Sánchez Miralles Fdo: Fecha: Vº Bº del Coordinador de Proyectos Álvaro Sánchez Miralles Fdo: Fecha:

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL PROYECTO FIN DE CARRERA DESARROLLO DE UN SISTEMA PARA EL CONTROL Y LA SEGURIDAD DE LAS CASAS. CONTROL INTERIOR AUTOR: Arranz Domingo, Álvaro DIRECTOR: Sánchez Miralles, Álvaro MADRID, junio de 2007

3 Resumen iii Resumen Durante la segunda mitad del siglo XX la sociedad ha evolucionado poco a poco hacia una sociedad de la información. Gracias a la evolución de la electrónica, sectores como el de telecomunicaciones e informática han tenido un gran desarrollo. Con la incorporación de las nuevas tecnologías al hogar surge la idea de poder automatizar la vivienda de tal forma que sea más cómoda y necesite una menor dedicación. Es así como surge el concepto de domótica. Algunas de las ventajas que puede ofrecer la domótica a nuestro ámbito cotidiano son un aumento de comodidad y seguridad, aporte de información sobre el estado del hogar y el ahorro energético que se puede conseguir. Todas estas ventajas se pueden resumir en un aumento de la calidad de vida del propietario. Comodidad: En general, la automatización de las tareas cotidianas del hogar repercute de forma directa en la comodidad de los usuarios. Seguridad: Cada vez más se demandan sistemas que velen por la seguridad de las casas. Podemos destacar seguridad ante robos mediante cámaras de vigilancia, sensores de movimiento, contacto directo con la policía, o seguridad ante accidentes domésticos. Información: El conocer el estado del hogar en tiempo real siempre puede ser interesante para los usuarios. Por ejemplo, saber qué luces de la casa están encendidas en ese momento. Ahorro energético: Cada vez se está más concienciado del problema energético y del consumo responsable que debe de hacerse tanto de agua como de electricidad y calefacción. De esta manera, un sistema domótico puede contribuir a un consumo responsable mediante luces que sólo se enciendan si hay alguien en la habitación, que la calefacción sólo se encienda cuando es necesario,

4 Resumen iv automatizar el riego de las plantas, aprovechar al máximo la luz del día, etc. Sin embargo, a pesar de las ventajas que ofrece instalar una solución domótica en un hogar, la domótica ha tenido poco éxito en el mercado, limitándose en gran medida a su instalación en viviendas de nueva construcción. Esto es debido a que la mayoría de los sistemas domóticos necesitan una fuerte instalación, implicando la ejecución de obras en prácticamente toda la casa, haciendo casi necesario que la vivienda se adapte al sistema domótico en lugar del sistema a la vivienda. De esta manera, la domótica no ha tenido ningún éxito en casas ya construidas. El objetivo de este proyecto ha sido, basándose en proyectos anteriores, crear un sistema domótico que mantenga las ventajas anteriormente mencionadas y que solucione algunas de las desventajas de los sistemas actuales que provocan que la domótica no se extienda a cualquier tipo de usuario. Las características que debe reunir el sistema en cuestión son: fácil instalación, autónomo, modular, configurable por reglas y modos, sencillo de utilizar y que sea asequible económicamente. Además de estas características, el sistema debe implementar una solución Web que permita a cualquier usuario ver el estado de su hogar a través de Internet en cualquier parte del mundo y en cualquier momento. Ilustración 1: Esquema de un sistema domótico

5 Resumen v Para alcanzar este objetivo en primer lugar se decidió que el sistema utilizase un PC para controlar todos los dispositivos instalados en el hogar. En segundo lugar fue necesario el separar el problema en dos: por un lado hay una aplicación que se encargue de las comunicaciones y de controlar todos los dispositivos instalados en el hogar; por otro hay otra aplicación que servirá como interfaz de usuario y que permitirá acceder a toda la información del hogar desde Internet. Este proyecto ha tenido como objetivo realizar la aplicación para el control del hardware. En primer lugar fue necesario elaborar un sistema de comunicaciones para que las dos aplicaciones que forman el sistema pudieran intercambiar información. Para que las comunicaciones se realicen de la manera más eficiente posible se ha implementado un sistema exclusivo en la aplicación que se dedica a esperar comunicaciones y a responder en consecuencia. En segundo lugar se añadió a la aplicación un sistema capaz de leer todos los datos de todos los dispositivos instalados en el hogar, guardarlos y actuar consecuentemente. Este sistema es el que permite que si la temperatura de una determinada habitación baja de un determinado valor, la calefacción se encienda automáticamente. Por último se implementó un sistema de reglas y modos configurables dinámicamente que aportan una gran versatilidad y permiten una mayor personalización. Mediante un sencillo script guardado en un archivo de texto, se pueden definir complejos comportamientos automatizados. Como resultado del proyecto se ha obtenido una aplicación que cubre las necesidades anteriormente descritas y que constituye la base para crear un sistema completo y comercial. Integrar nuevos componentes como sensores o actuadores específicos puede hacerse de una manera sencilla sin tener que reprogramar la aplicación de nuevo. Para concluir, se realizaron varias pruebas con varios dispositivos distintos, sensores, actuadores, reglas y modos todo ello controlado desde Internet a través de la aplicación de usuario obteniéndose unos resultados excelentes.

6 Summary vi Summary During the second half of the XX century the society has evolved to a society where information is very important. Thanks to the evolution of the electronics, sectors such as telecommunications and computer science have had a great expansion. The domestic sector has seen how the houses have filled with new electronic devices that make life easier. With the incorporation of new technologies into the houses the idea of being able to automate the house arises making it more comfortable and more secure. That is the beginning of the domotics. Some of the advantages that home automation can offer to us are an increase of comfort and security, give information about the state of our house and the energy saving that can be obtained. All these advantages can be summarized in an increase of the quality of life of the owner. Comfort: In general, the automation of the daily tasks made in home increases the comfort of the users. For example, a domotic solution that integrates a robot-vacuum cleaner prevents the user to spend some time doing that task. Security: Systems that increases the security of the houses are demanded more and more. Including cameras, movement sensors and communicating with the police are ways of preventing robberies. Other form of security is the prevention of domestic accidents such as the breakage of pipes, fires, toxic gases, etc. Information: Knowing the state of the home in real time is always interesting for the users. For example, knowing if the lights are on or off, if the sprinklers are working, if the calefactor is on, etc. Energy saving: Nowadays, the world has a big problem with global warming and is necessary for the users to reduce the energy consumption. A domotic system can contribute to a responsible energy consumption with lights that only turns on when there is

7 Summary vii somebody in the room, with a heating system that only turns on if it is necessary, with the automation of the irrigation of the garden, using the light the sun, etc. In spite of the advantages that installing a domotic solution offers, the domotic systems have not been successful in the market, being only installed in houses of new construction. This is because most of the domotic systems need a strong installation making necessary that the house is being adapted to the domotic system instead of the system being adapted to the house. This is the reason because the domotics has not been successful in houses already constructed, which represent the great majority of the market. The objective of this project has been, being based on previous projects, to create a domotic system that maintains the advantages previously mentioned and that solve some of the disadvantages of the actual systems that cause the domotics fail in the market. The characteristics that must have the system are: easy installation, independent, modular, configurable by rules, easy to use and cheaper than the actual systems. In addition to these characteristics, the system must implement a solution that lets the owner use the Internet to see the state of its home. Ilustración 2: Domotic system communications

8 Summary viii In order to reach this objective, first it was decided that the system used a PC to control all the devices installed in the house. After that, the problem was divided into two different parts: on one hand there is an application that is in charge of the communications and controls all the devices installed in the house; on the other hand there is another application that will be used as user interface and which will allow to ask for the information of the home from the Internet. This project had as objective to design the application for the control of the hardware. First of all it was necessary to design a communications system so that the two applications that form the system could interchange information. Thus, the user application can demand the state of any sensor or actuator at any time to the application hardware and later show it through the screen. It was implemented that the communications were made in the most efficient way creating an exclusive system in the application that is in charge of waiting for any communication to arrive and respond consequently. Secondly it was added a system able to read all the data of all the devices installed in the house, to store the information and to act consequently. This system is the one that allows that if the temperature of a certain room is lower than a certain value, heating system turns on automatically. Finally was implemented a rule system that gives the application a big versatility and allows a great customization. A simple script stored in a text file can determine complex automated behaviours, being all configurable easily by the user. As a result, it has being designed an application that covers the necessities previously described and that constitutes the base to create a complete and commercial system. The integration of new components such as sensors or specific actuators can be made in an easy way without having to compile again the application. Finally, several tests with different sensors, actuators and rules were made all controlled from the Internet through the user.

9 DOCUMENTO Nº 1: MEMORIA

10 Índice ii Índice Parte I Memoria...1 Capítulo 1 Introducción Estudio de los trabajos existentes / tecnologías existentes Motivación del proyecto Objetivos Metodología / Solución desarrollada Recursos / herramientas empleadas Capítulo 2 Estructura del sistema Introducción Visión global del sistema División del sistema Capítulo 3 Arquitectura hardware Introducción Base Remoto Tipos de remoto Sensores Actuadores Capítulo 4 Protocolo de comunicaciones Introducción Configuración inicial Protocolo en los mensajes Tipo de instrucciones Intercambio de ficheros en las comunicaciones Tablas de sensores... 35

11 Índice iii Capítulo 5 Reglas y modos Introducción Reglas Script de regla Ejemplo completo de regla Modos Script de modo Capítulo 6 Diseño del software Introducción Módulo de scripts Módulo de comunicaciones Módulo de reglas y modos Módulo de control del hardware Coherencia de datos en aplicaciones multihilo Capítulo 7 Capítulo 8 Resultados/Experimentos...63 Conclusiones...66 Capítulo 9 Futuros desarrollos...68 Bibliografía...69 Parte II Estudio económico...70 Parte II...71 Parte III Manual de usuario Instalación del hardware Instalación de la aplicación software Pasos a seguir para la instalación Depuración de errores Errores más importantes Parte IV Datasheets...78

12 Índice de figuras iv Índice de figuras Figura 1. Módulo de aparato X Figura 2. Kit Active Home X Figura 3: División del sistema domótico...15 Figura 4: Comunicaciones del sistema domótico...17 Figura 5: Fotografía de una base...19 Figura 6: Fotografía de un remoto...20 Figura 7: Esquema conexión de los sensores...21 Figura 8: Ecuación de la tensión medida en el micro...22 Figura 9: Relé para conectar a actuadores...23 Figura 10: Intercambio de ficheros en las comunicaciones Figura 11: Comunicaciones entre los hilos de la aplicación...48 Figura 12. Módulo de scripts...49 Figura 13. Módulo de comunicaciones...50 Figura 14. Bucle de comunicaciones...51 Figura 15. Módulo de reglas y modos...52 Figura 16. Cómo se forma la clase ScriptRegla...53 Figura 17. Módulo de control del hardware...55 Figura 18. Bucle de control de hardware...57 Figura 19: Conexiones de la base...73 Figura 20: Conexiones de un remoto...74 Figura 21: Conexiones de un relé...74

13 Memoria 1 Parte I MEMORIA

14 Memoria. Introducción 2 Capítulo 1 INTRODUCCIÓN En este documento se reúnen diferentes puntos y aspectos sobre el desarrollo y ejecución del proyecto. En primer lugar, el capítulo 1 se trata de una introducción a los sistemas domóticos, mostrando el porqué del desarrollo de estos sistemas así como las tecnologías que existen en la actualidad. Más adelante se establecen los objetivos del proyecto, así como la metodología a seguir para alcanzar dichos objetivos y los recursos utilizados para su desarrollo. A lo largo del capítulo 2 se realiza un análisis de la arquitectura hardware del sistema domótico propuesto. En esta sección se pretende dar una visión global del funcionamiento del sistema, de qué módulos se compone, cómo se comunican dichos módulos y los sensores y actuadores utilizados. La solución domótica propuesta se compone de una aplicación que se encarga del hardware y otra que se encarga del interfaz de usuario. A pesar de que este proyecto se centra en la aplicación hardware, surge la necesidad de dar solución al problema de las comunicaciones entre ambas aplicaciones. De esta manera, en el capítulo 3 se establece un protocolo de comunicaciones donde se indica cómo puede mandarse información de una aplicación a otra. En el capítulo 4 se explica la necesidad de implementar un sistema de reglas y modos durante el proyecto. Posteriormente se hace un estudio de cómo funcionan las reglas y los modos y cómo poder realizar reglas y modos personalizados.

15 Memoria. Introducción 3 Finalmente, en el capítulo 5 se analiza cómo está hecha la aplicación hardware. 1 Estudio de los trabajos existentes / tecnologías existentes En la actualidad, el número empresas orientadas a la instalación de soluciones domóticas está en aumento. El sector domótico se trata de un sector que está claramente en auge. De esta manera, se han ido desarrollando diferentes estándares para las comunicaciones de los sistemas domóticos. Los más importantes son los siguientes: Protocolo X-10: El sistema X-10 es un protocolo de comunicaciones que utiliza la red eléctrica de la vivienda para comunicarse y para controlar los distintos elementos del sistema. Se trata del estándar domótico más difundido y comercializado tanto en España como en el resto del mundo. Su gran difusión es debida a las múltiples ventajas que posee el sistema: bajo coste, facilidad de instalación y programación, flexibilidad (se trata un sistema modular que permite ampliaciones) y facilidad de uso. Como desventajas de este estándar podemos destacar su falta de flexibilidad debido a que para instalar cualquier módulo se necesita la red eléctrica (generalmente enchufes) y los problemas que existen de interferencias en la red eléctrica. En la actualidad existen multitud de empresas que desarrollan módulos, controladores y completos kits bajo el estándar X-10.

16 Memoria. Introducción 4 Figura 1. Módulo de aparato X-10 En la Figura 1 se muestra la imagen de un módulo X-10 que, tras enchufarse a la red eléctrica, puede usarse como un activador manual o automático de cualquier aparato que esté conectado al módulo. Figura 2. Kit Active Home X-10 En la Figura 2 se puede ver un kit completo X-10 para automatización de un hogar. El kit se compone de un programador, un receptor RF, un módulo de aparato, un módulo de lámpara y un mando. Como desventajas de este estándar se puede destacar su falta de flexibilidad debido a que para instalar cualquier módulo es necesaria la red eléctrica (generalmente enchufes) y los problemas que existen de interferencias en la red eléctrica. Además, es una tecnología no preparada para su uso desde fuera del recinto de una

17 Memoria. Introducción 5 casa. Esto quiere decir, que los módulos son sólo controlables desde la casa misma, no se tiene acceso desde fuera. Debido a esto, algunas empresas han empezado a comercializar productos que permitan a partir de una llamada de teléfono, de un SMS o de Internet controlar alguno de los módulos. El precio del kit básico está en torno a los 190, mientras que un módulo de aparato cuesta Sistemas EIB 2 : A diferencia del estándar X-10, los sistemas EIB utilizan su propio bus de comunicaciones; se trata de un cable con dos hilos que se encarga de repartir las señales allí donde se quiera. Además, existen mecanismos para realizar las comunicaciones o bien vía radio o bien a través de la propia red eléctrica. Los sistemas EIB son sistemas distribuidos en red, lo que indica que no necesitan un módulo central, sino que pueden comunicarse todos los módulos entre sí.. Esto permite evitar problemas ya que el sistema no depende del buen funcionamiento de un solo aparato. A diferencia de los sistemas X-10, los sistemas EIB no se comercializan por módulos separados, sino que se realiza un proyecto y una instalación específica para cada cliente. Esto encarece mucho el precio, e impide la ampliación del sistema domótico instalado inicialmente. Sistemas LonWorks 3 : y

18 Memoria. Introducción 6 La tecnología LonWorks fue presentada por la empresa Echelon en Desde el punto de vista de las comunicaciones, ofrece una solución con arquitectura descentralizada, extremo-a-extremo, que permite distribuir la inteligencia entre los sensores y los actuadores instalados en la vivienda. Estos sistemas han tenido éxito en instalaciones profesionales, en las que importa mucho más la fiabilidad y robustez que el precio. De esta manera, se han implantado casi exclusivamente en edificios de oficinas, hoteles e industrias. En la siguiente tabla se puede ver un resumen de las diferentes capacidades de cada una de estas tecnologías. X-10 EIB LonWorks Necesidad de obra No Si Si Compatible Internet con No No Si Ampliaciones para control por Internet Si Si - Coste Bajo Alto Muy Alto Ampliable Si No Difícil Robustez Baja Media Alta Conocimiento del estado de los sensores No No Si Tabla 1. Resumen del estado del arte

19 Memoria. Introducción 7 2 Motivación del proyecto A lo largo de todo el siglo XX se ha ido evolucionando hacia una sociedad de la información. Se puede observar claramente este fuerte desarrollo en los sectores de la electrónica, telecomunicaciones e informática. Esta evolución ha provocado que nuestros hogares se llenen de electrodomésticos de nueva generación, que ofrecen muchas ventajas respecto a sus predecesores. Tal es el caso de los nuevos televisores, lavadoras, alarmas, persianas motorizadas, sistemas de vigilancia, etc. Sin embargo, en ocasiones, la incorporación de nuevas tecnologías trae consigo una mayor dificultad de realizar tareas cotidianas y surge la idea de poder tener un control más global sobre nuestro hogar, un control más completo y sencillo. De esta manera, aparece el concepto de sistema domótico, un sistema capaz de aunar todas las ventajas de las nuevas tecnologías y de controlar de forma autónoma e inteligente nuestro hogar. Las razones principales que pueden impulsar la instalación de un sistema domótico son la comodidad, la seguridad, la información y el ahorro energético. Todas estas razones se pueden resumir en el aumento en la calidad de vida. De esta forma, una de las principales preferencias que debería tener un sistema domótico es crear un hogar más cómodo para el usuario. En general, un hogar más cómodo se puede asociar a un hogar más autónomo, con un mayor grado de automatización, un hogar que requiera menos de nuestros cuidados y de nuestro tiempo. Pero además, un hogar más seguro también es un hogar más cómodo, pudiendo unificar así alarmas, video vigilancia, detectores de movimiento, detectores de fuego o humo, todo ello en un sólo sistema sencillo de utilizar. Algunas de las tareas que un sistema domótico puede realizar de forma autónoma son:

20 Memoria. Introducción 8 Detectar la presencia de intrusos mediante sensores de movimiento, cámaras de video u otras técnicas. Controlar la temperatura de varios recintos independientemente o en conjunto. Controlar la iluminación de los recintos mediante persianas, lámparas, tubos fluorescentes, etc. Además podemos regular la iluminación según la presencia de individuos. Automatizar el sistema de riego de plantas y jardines en función de la humedad del terreno. Detectar inundaciones cortando el suministro de agua. Detectar humo y gases tóxicos avisando al usuario. Sin embargo, los sistemas domóticos no están limitados a estas aplicaciones. Con la domótica se abre todo un mundo de nuevas posibilidades. Un ejemplo es el caso de la gestión energética de nuestro hogar. Podemos pensar en un sistema domótico como una vía de ahorro energético, un sistema capaz de optimizar al máximo los recursos de nuestras casas: control sobre las luces, la calefacción, aprovechar la luz del día, etc. Otro caso es el de la seguridad. Ésta puede verse desde dos puntos de vista: tanto la aportación de sistemas que eviten robos en los hogares como sistemas que eviten accidentes domésticos o palien sus efectos. En el apartado 1 Estudio de los trabajos existentes / tecnologías existentes se ha comentado los estándares en los que se basa actualmente la industria de la domótica. Conociendo las ventajas y desventajas de cada uno de los estándares, se pretende desarrollar un sistema que aúne las ventajas más importantes de éstos y evite las desventajas que impiden la

21 Memoria. Introducción 9 implantación de los sistemas domóticos en cualquier tipo de construcción, tanto en hogares como en oficinas. De esta manera, se propone un sistema que reúna las siguientes características: Sistema de fácil instalación. Para las viviendas ya construidas, se pretende evitar el tener que realizar obra en el hogar para instalar las conexiones de los sistemas. De este modo, se propone un sistema en el que las comunicaciones se realicen por radiofrecuencia, evitando así el cableado del hogar. Sistema asequible económicamente. Al evitar el tener que hacer obra en el hogar, el sistema resulta mucho más económico que otros sistemas que se venden actualmente. Sistema autónomo y automatizado. El sistema debe reaccionar adecuadamente a los eventos que sucedan en la casa. Así, podemos tener un sistema que apague las luces cuando no hay nadie en una habitación, que encienda y apague la calefacción cuando sea conveniente, encienda los aspersores del jardín cuando la humedad del recinto es demasiado baja, etc. Sistema sencillo de utilizar. El sistema se basa en un conjunto de modos y reglas, de tal forma que una vez configurado, sea muy sencillo e intuitivo de utilizar. Conectividad Web. Simplemente con una conexión a Internet se tiene acceso una página Web donde se puede observar el estado del hogar en tiempo real y poder modificarlo, por ejemplo, encendiendo la calefacción, apagando las luces del salón, etc.

22 Memoria. Introducción 10 3 Objetivos Durante la motivación se ha establecido una serie de objetivos deseables para nuestro sistema, que sirven de orientación general para el desarrollo del proyecto. Sin embargo, es necesario establecer un objetivo definido y concreto. El objetivo principal del proyecto es montar el sistema domótico, con al menos dos módulos diferentes llenos de sensores y actuadores. Crear un sistema automático, robusto, fácil de utilizar, configurable por reglas y modos, capaz de recibir órdenes desde otro programa mediante un archivo de texto con el fin último de poder ser controlado a través de una página Web. 4 Metodología / Solución desarrollada Para alcanzar el objetivo propuesto en el apartado anterior, se va a organizar el proyecto en dos objetivos principales. El primero es conseguir programar un sistema que sea capaz de controlar la casa de manera autónoma. Se basará en un bucle de control que irá verificando las reglas que estén activas en ese momento y producirá las salidas a dichas reglas en forma de cambio de los correspondientes actuadores. El segundo objetivo es dotar al programa anterior de la posibilidad de comunicarse con el exterior, para recibir órdenes, devolver lecturas de sensores, etc. Se pueden destacar las siguientes tareas: La primera tarea importante a realizar es definir un protocolo de comunicaciones en el que se determinará la forma en la que el programa principal se comunicará con el exterior. Esta tarea es esencial para la coordinación entre la aplicación Web y el programa base encargado de manejar el hardware.

23 Memoria. Introducción 11 Lo siguiente a realizar en el proyecto será dedicar un tiempo al diseño de software; se creará una estructura sólida sobre la cual se irá programando la aplicación. Cabe destacar la importancia de esta fase, que evitará futuros problemas a la hora de programar el sistema. La siguiente tarea consistirá en dotar a la aplicación de la capacidad de leer el archivo de configuración (archivo que reunirá toda la configuración hardware del sistema domótico). Una vez el sistema conoce de qué hardware está formado, se programará la habilidad de leer y escribir en los sensores y actuadores respectivamente. Esta tarea se basará en un driver ya creado para el manejo de los módulos a través del puerto RS232 (puerto serie) del ordenador. Una vez logrado leer los sensores y escribir en los actuadores, es interesante buscar información de posibles sensores y actuadores que podrán ser integrados en un futuro en el sistema. De esta forma, se elaborará un texto con sensores de temperatura, luminosidad, humedad, humo, etc. Esta tarea no es fundamental para el desarrollo del sistema, con lo cual no es imprescindible que a la hora de su realización se siga su orden. Una vez elegidos los sensores será necesario escribir las tablas de correspondencia entre el voltaje y la magnitud real para cada sensor. Además habrá que dotar al sistema de la capacidad de leer dichas tablas e interpolar para obtener el valor de la magnitud real correspondiente. La próxima tarea a realizar será programar el sistema de reglas y modos por el cual, a partir del valor de los sensores de la casa (entradas) se establecerá un cierto valor para cada actuador (salidas). Una vez terminada esta tarea, se integrarán los sistemas

24 Memoria. Introducción 12 programados con el fin de realizar una prueba del sistema de control. A partir de unas reglas y sensores se comprobará que los actuadores se actualizan correctamente. La siguiente tarea será crear un bucle de control de mensajes que mirará constantemente si llegan mensajes, los procesará, realizará la acción correspondiente y contestará con otro mensaje. En este sistema es interesante integrar un historial de las comunicaciones que se han producido en la aplicación. Con la finalización de esta tarea se dará por concluido el objetivo de dotar a la aplicación de la capacidad de comunicarse. 5 Recursos / herramientas empleadas La aplicación se programará con Microsoft Visual C++ 7.1, integrado dentro de Microsoft Visual Studio.NET. Ha sido imprescindible tener un amplio conocimiento del compilador y del lenguaje C++.

25 Memoria. Estructura del sistema 13 Capítulo 2 ESTRUCTURA DEL SISTEMA 1 Introducción El sistema domótico está formado por un servidor y un determinado hardware conectado a él. Además, formado por dos partes bien diferenciadas. Por un lado se tiene una aplicación hardware que se encarga de las comunicaciones con los dispositivos situados por el hogar. Por otro lado se tiene una aplicación encargada de la interfaz de usuario. En las siguientes secciones se muestra en detalle cómo están divididas las diferentes partes y cuáles son sus tareas a realizar. 2 Visión global del sistema La casa domótica diseñada a por este proyecto se caracteriza por tener un servidor como núcleo del sistema. Este servidor, que podrá ser un ordenador cualquiera de la casa utilizado al mismo tiempo como servidor, será el eje central del sistema domótico. Es al servidor donde llegará toda la información y de donde saldrán todas las órdenes. Deberá pues estar conectado con los diferentes transductores. Para ello, se conecta un dispositivo que llamaremos base al puerto serie del servidor. Ésta se encargará de las comunicaciones entre este y los distintos módulos distribuidos por la casa. Estas comunicaciones entre base y módulo se realizarán por radio y en el módulo estarán directamente conectados los transductores. Por otra parte, si el ordenador tiene conexión WIFI, o acceso a una conexión WIFI de la casa, éste podrá interactuar con robots. Por último, cualquier usuario identificado que se conecte a Internet,

26 Memoria. Estructura del sistema 14 podrá, a través de la página Web alojada en el servidor, controlar todos estos elementos. Figura 3: Esquema completo del sistema En la Figura 3 se puede ver cómo una aplicación en servidor pide la información a los módulos situados en diferentes lugares de la casa para almacenar su estado. Desde Internet se pedirá la información de los módulos y se mostrará por pantalla desde un navegador. 3 División del sistema A continuación se muestra un esquema con las diferentes aplicaciones que forman el sistema:

27 Memoria. Estructura del sistema 15 Figura 4: División del sistema domótico En primer lugar en la Figura 4 se puede ver que la aplicación de control del hardware es completamente independiente de la interfaz de usuario que se utilice y siempre es el intermediario entre el usuario y los sistemas hardware. Por un lado la aplicación hardware se comunica con los remotos para guardar el estado de los sensores y actuadores. Por otro lado, necesita leer archivos en los que se describen determinadas reglas y modos. Las reglas y modos determinarán la forma de comportarse del sistema frente a los distintos eventos. El actual proyecto tratará del diseño y programación de la aplicación hardware.

28 Memoria. Arquitectura hardware 16 Capítulo 3 ARQUITECTURA HARDWARE 1 Introducción La arquitectura hardware fue elaborada previamente por Álvaro Sánchez Miralles y por otros proyectistas. Este capítulo se presenta como una introducción a la arquitectura del sistema, no siendo el objetivo de este proyecto ahondar en ella. Un sistema domótico, en general, necesita los siguientes dispositivos: Dispositivos de recepción de información del entorno. Dispositivos de actuación sobre el entorno. Dispositivos de toma de decisiones. Infraestructura para que se comuniquen los distintos dispositivos entre sí. La forma en la que estos dispositivos estén localizados en el sistema puede dar multitud de combinaciones diferentes. En algunas ocasiones se puede dar el caso de que en un mismo dispositivo existan sensores para conocer el entorno y a la vez actuadores sobre el mismo entorno. Incluso puede darse el caso de que la toma de decisiones esté distribuida entre varios dispositivos que a su vez tengan sensores y actuadores. Según sean las comunicaciones entre los dispositivos, se puede hablar de sistemas centralizados y de sistemas distribuidos. Un sistema centralizado es aquel en el que todas las comunicaciones deben pasar siempre por un dispositivo central. Por el contrario, un sistema distribuido es aquel en el

29 Memoria. Arquitectura hardware 17 que todos los dispositivos se pueden comunicar mutuamente entre sí, sin necesidad de pasar previamente por ningún otro dispositivo. Además, según sea el medio en el que se produzcan las comunicaciones, podemos hablar de sistemas cableados o inalámbricos. El sistema domótico que se está desarrollando tendrá los siguientes dispositivos: base y remoto. La base será la encargada de pedir todos los datos necesarios y de dar órdenes a los distintos remotos. Los remotos serán los encargados de tomar las medidas de los sensores que tengan conectados y de mandar sobre los actuadores. De esta manera, podemos decir que se trata de un sistema centralizado puesto que toda la información siempre pasa por las bases. Las comunicaciones entre las bases y los remotos se realizan mediante radiofrecuencia, por lo que podemos decir que es un sistema inalámbrico. Mostramos ahora cómo se comunican los dispositivos entre sí: Figura 5: Comunicaciones del sistema domótico En primer lugar, la base se comunica con el ordenador a través del puerto serie (RS232) y de un driver. Es éste el que demanda información a la base

30 Memoria. Arquitectura hardware 18 de cada uno de los remotos. La base se comunica por radiofrecuencia con cada remoto mediante un protocolo de comunicaciones. Cada remoto contesta a la base y es ésta la que devuelve la información recibida al ordenador. De esta manera, se consigue un sistema muy flexible, ya que se puede añadir un dispositivo remoto de forma muy sencilla. 2 Base La base se encarga de comunicar el ordenador con los distintos remotos que se encuentren en el hogar. Cabe destacar que la base no toma ninguna decisión en el sistema, simplemente se encarga de establecer las comunicaciones pertinentes. Es el ordenador, en concreto, un determinado software, el que se encarga de recibir toda la información y tomar las decisiones pertinentes. La base está formada por los siguientes componentes: Sistema de alimentación conmutada, para optimizar los consumos. Dispositivo de comunicación con el puerto serie. Un microcontrolador para procesar la información recibida. Un aparato de radio para que la base se pueda comunicar por radiofrecuencia con los remotos. A continuación se muestra una fotografía real de una base:

31 Memoria. Arquitectura hardware 19 Figura 6: Fotografía de una base Las funcionalidades de la base se pueden utilizar a través de un driver que permite establecer comunicaciones con cualquier remoto, inicializarlo, pedirle información, etc. 3 Remoto Los remotos se encargan de leer la información de los sensores y modificar los actuadores que tengan conectados. Todas las órdenes las reciben a través del enlace de radiofrecuencia con la base. La estructura de un remoto es la siguiente: Sistema de alimentación conmutada, para optimizar los consumos. Un microcontrolador que se encarga tanto de las comunicaciones con el aparato de radio como de las lecturas de los sensores y el establecimiento de los actuadores. Sistema de radiofrecuencia para las comunicaciones con la base.

32 Memoria. Arquitectura hardware 20 A continuación se muestra una fotografía de un remoto: Figura 7: Fotografía de un remoto Cada remoto tiene la posibilidad de incluir: Cinco entradas analógicas. Diez entradas/salidas digitales. 2 PWM 3.1 Tipos de remoto Existen dos tipos distintos de remoto: Alimentado con baterías. Sirve para remotos cuyo principal objetivo sea la obtención de información del entorno a través de sensores. Debido a la posibilidad de dormir el microcontrolador y del bajo consumo que tienen la mayoría de los sensores (suelen ser resistencias variables con una alta resistividad en condiciones

33 Memoria. Arquitectura hardware 21 normales), dos pilas pueden ser suficiente para alimentar este tipo de remoto. También podría darse el caso de actuadores de bajo consumo que puedan ser conectados a este tipo de remotos. Alimentado a través de la red eléctrica. Está orientada para aquellos remotos que necesiten uno o más actuadores. Generalmente, para cada actuador se tiene que alimentar a un relé. Debido al consumo de cada relé, unas baterías no tendrían sentido en un módulo con actuadores, por eso deben estar alimentados con una fuente de alimentación. 4 Sensores El diseño de los remotos permite una fácil integración de sensores resistivos en éstos. El microcontrolador posee en uno de sus puertos un conversor analógico-digital que nos da la posibilidad de leer tensiones. Realizaremos la conexión de las resistencias de la siguiente forma: Figura 8: Esquema conexión de los sensores Como podemos ver en la figura, la tensión del conversor in depende de la resistencia variable R(x) de la siguiente forma: R( x) Vin = Vcc R( x) + R1

34 Memoria. Arquitectura hardware 22 Figura 9: Ecuación de la tensión medida en el micro Cabe destacar la importancia que tiene la elección de la resistencia R1. Una resistencia R1 muy baja tiene el peligro de crear grandes intensidades (hay que tener en cuenta que R(x), en general, puede alcanzar valores muy bajos) y por lo tanto grandes consumos de energía además de quedarse Vin sin sensibilidad frente a x. Sin embargo, una R1 muy grande puede provocar que las variaciones de R(x) no produzcan a penas variaciones en Vin. Todos los sensores que se han elegido han sido resistencias variables con cierta magnitud física de interés (en la ecuación y figuras anteriores dicha magnitud se representa con la letra x ). Además, en general se ha elegido la resistencia R1 = 10kΩ. Si se configura el remoto adecuadamente, también se pueden incluir sensores digitales. Un ejemplo de estos sensores es el de un sensor de movimiento. Éste al detectar movimiento pone una determinada patilla a V+ (generalmente 5V); en caso de que no detecte movimiento pone la patilla a 0V. Hay que tener en cuenta que la suma entre los sensores digitales y los actuadores digitales que estén instalados en un remoto está limitada. 5 Actuadores Los actuadores que actualmente pueden utilizar los módulos son actuadores que sean controlados con señales del tipo PWM o que tengan la función de encendido o apagado. Éste es el caso de de las calderas de calefacción, las luces de las lámparas, cerraduras, etc. Para ello se han utilizado las salidas digitales que proporciona el microcontrolador situado en los remotos. Para encender y apagar el actuador se ha utilizado un relé.

35 Memoria. Arquitectura hardware 23 Puesto que una salida digital de un microcontrolador no puede alimentar un relé, se ha utilizado además un transistor. A continuación se muestra una imagen del pequeño circuito montado para atacar al actuador: Figura 10: Relé para conectar a actuadores

36 Memoria. Protocolo de comunicaciones 24 Capítulo 4 PROTOCOLO DE COMUNICACIONES 1 Introducción En el proyecto de automatizar completamente un hogar existen dos elementos diferenciados. Por una parte se tiene una aplicación que se encarga de la parte hardware de la casa: se encarga del control de los sensores y actuadores, comunicación entre bases y remotos, etc. Por otra parte, se tiene la interfaz de usuario que servirá al cliente para conocer los datos de la casa y modificarlos si lo cree conveniente. La parte hardware debe conocer el estado inicial del hogar, es decir, la cantidad de módulos que tiene el sistema, los sensores que hay en cada módulo, dónde están situados los módulos, etc. Esto se realiza a partir de un archivo de configuración en el que se halla toda la información inicial del hogar. Además, entre la parte hardware y la interfaz de usuario es necesario que exista comunicación puesto que la interfaz usuario necesitará los datos que son sólo accesibles por el elemento que controla el hardware y éste realizará lo que le pida la aplicación interfaz de usuario. De esta manera necesitamos definir un protocolo de comunicaciones entre las dos partes. 2 Configuración inicial Los datos necesarios para la configuración inicial de nuestra aplicación son fijos desde que se instala el sistema y se guardan en un archivo tipo texto que es accesible por ambos programas. Es necesario establecer una estructura del archivo de configuración. En la configuración inicial se pueden distinguir tres tipos de datos: los referentes a la organización en la casa, la organización de los módulos y

37 Memoria. Protocolo de comunicaciones 25 las propiedades de cada sensor. Hay que tener en cuenta que en esta plantilla hablamos de sensores pero también se refiere a actuadores. La estructura es la siguiente: <configuracion> <modulos> <modulo idmodulo= tipomodulo= > <pin idpin= idsensor= />... </modulo>... </modulos> <sensores> <sensor clase = idsensor= tipo= conversor= descripción= unidades= /> </sensores> </configuracion> Esta estructura está pensada para una sola casa. En el caso de que se hiciese para un edificio o para una urbanización de varios edificios se tendría que cambiar la estructura identificando cada casa y cada piso. En el tag <casa> se encierra los datos sobre la casa. En cada casa habrá varias plantas, con varias salas, cada una de ellas asociadas a uno o varios sensores. Para ello se dará un idsala e idplanta a cada sala y planta respectivamente para identificarlas. Cabe destacar que cada uno de estos id s será único para poder identificar a cada planta o sala unívocamente. A su vez, cada sala lleva asociado un cierto número de sensores. De esta manera, en cada casa hay diferentes plantas, en cada planta hay diferentes salas que a su vez tienen diferentes sensores.

38 Memoria. Protocolo de comunicaciones 26 El tag <modulos> comprende las características de cada módulo uno a uno. Así, en este tag tendrá tantos tag <modulo> como módulos haya en la casa. Los módulos se identifican con el atributo idmodulo dentro de su tag. Además poseen otro atributo que es el tipomodulo que indica si el módulo estará conectado a la red eléctrica o funcionará con baterías. Cada uno tendrá tantos tag <pin> como pins tenga el módulo. Estos tags tienen el idpin para identificarlos dentro del módulo, así como el atributo idsensor que sirve para identificar unívocamente cada sensor. Estas configuraciones básicas de los sensores se encuentran en el tag <sensores>. Este tag tiene tantos tags <sensor> como idsensor existen. En éstos se incluyen las propiedades siguientes: clase, que determina si se trata de un sensor o un actuador, idsensor, tipo, que diferencia entre los sensores digitales, analógicos y PWM; conversor, que permitirá hacer la conversión entre la tensión del pin y el valor físico real; unidades, que dará la unidad física en la que se calcule el valor; descripción, que indicará que sensor o actuador es. Por último, hay que hablar de los datos de presentación que podrá modificar el usuario. Estos se almacenarán en un archivo al que sólo podrá acceder la interfaz usuario en modo lectura y escritura. Estos datos no se almacenan con los datos de la casa ya que no serán fijos y no son parte de la configuración de la casa, sólo serán útiles para la aplicación gráfica de la interfaz usuario. En este archivo se almacenará el nombre que el usuario da a cada sala así como tipo de habitación que es: dormitorio, salón, cocina, salón, cuarto de baño, trastero, etc. Además, se tendrá la configuración de qué información y cómo el usuario quiere que se muestre en cada una de las salas. A continuación se muestra un ejemplo completo utilizado para la configuración de un sistema sencillo:

39 Memoria. Protocolo de comunicaciones 27 Config.txt: <configuracion> <modulos> <modulo idmodulo="85" tipomodulo="0"> <pin idpin="25" idsensor="0"/> <pin idpin="26" idsensor="1"/> <pin idpin="2" idsensor="2"/> <pin idpin="3" idsensor="3"/> </modulo> </modulos> <sensores> <sensor clase="sensor" idsensor="0" tipo="digital" conversor="tabla5.txt" descripcion="movimiento" unidades="c"/> <sensor clase="actuador" idsensor="1" tipo="digital" conversor="tabla5.txt" descripcion="lampara" unidades="c"/> <sensor clase="sensor" idsensor="2" tipo="analogico" conversor="tablaluminosidad.txt" descripcion="movimiento" unidades="c"/> <sensor clase="sensor" idsensor="3" tipo="analogico" conversor="tablahumedad.txt" descripcion="movimiento" unidades="c"/> </sensores> </configuracion> En este ejemplo se está configurando un sistema que tiene un único remoto. Dicho remoto tiene como identificador el número 85 y es del tipo 0 (sirve para distinguir si es de bajo consumo o no). El remoto tiene cuatro sensores o actuadores distintos conectados en los pines 25, 26, 2 y 3. A continuación se describen las características de cada sensor asociado al

40 Memoria. Protocolo de comunicaciones 28 remoto. Por ejemplo, el primero se trata de un sensor digital de movimiento, con 0 como número identificador y utiliza la tabla5 para traducir las medidas realizadas a valores reales de la magnitud física. Cabe destacar que las tablas no tienen ninguna aplicación en sensores digitales puesto que no es necesario interpolar entre los distintos posibles valores. 3 Protocolo en los mensajes La transmisión de los datos se realizará a partir de archivos de texto. Cada transmisión estará compuesta por un mensaje con la siguiente estructura: <mensaje idmensaje= idmensajeack= > <instrucción idinstruccion= tipo= > //dependiendo del tipo de instrucción el contenido será diferente </instruccion> <instruccion idinstruccion= tipo= > //dependiendo del tipo de instrucción el contenido será diferente </instruccion>... </mensaje> Como se puede observar, todo mensaje vendrá incluido entre los tags <mensaje>. Cada mensaje tiene los atributos idmensaje e idmensajeack. El primero sirve para identificar el mensaje entre el conjunto de todos los mensajes que ha habido en todas las comunicaciones, mientras que el segundo sirve para identificar el mensaje al que se está contestando en el caso que exista. De esta forma el idmensajeack de los mensajes escritos por la interfaz usuario serán siempre nulos ya que el servidor (elemento hardware) nunca pide información al cliente. Sin embargo el idmensajeack

41 Memoria. Protocolo de comunicaciones 29 de los mensajes escritos por el hardware tendrá un valor igual al idmensaje al que contesten. Cada mensaje podrá tener varias instrucciones, cada una de ellas comprendida en un tag <instrucción>. Una instrucción es una acción determinada a realizar por el hardware o la respuesta del mismo a otra instrucción demandada anteriormente. Para diferenciar las instrucciones de un mismo mensaje, se utiliza el atributo idinstruccion. Hay que tener en cuenta que en la respuesta a un mensaje, cada instrucción es la respuesta a la instrucción de mismo idinstruccion. Las instrucciones que pueden ser realizadas por la parte usuario son la Lectura, o la Escritura en la parte hardware. Por su parte el hardware puede tener 3 tipos de respuestas: Datos, OK y Error. En el siguiente apartado se explican con más detenimiento cada uno de los tipos de instrucción. 3.1 Tipo de instrucciones Lectura: La instrucción tipo lectura está identificada con el tipo= 1. Esta instrucción es demandada por la parte usuario a la parte hardware para pedir el valor de todos los sensores. Así pues, no se necesita saber nada más y la instrucción Lectura no pasa ningún argumento. Se aprovecha pues para refrescar todos los datos de la casa. Un ejemplo de una instrucción lectura sería:... <instruccion idinstruccion= 2 tipo= 1 > </instruccion>...

42 Memoria. Protocolo de comunicaciones 30 Escritura: La escritura está definida por el tipo= 2 dentro de la instrucción y le sirve al usuario para cambiar el valor de un actuador al que tiene acceso la parte hardware. Tenemos que identificar a que actuador nos referimos, así como el valor que se quiere poner. Se pasará un idsensor para identificar el actuador y un atributo valor dentro del tag <dispositivo>. Por ejemplo:... <instruccion idinstruccion= 3 tipo= 2 > <dispositivo idsensor= 5 valor= 27 /> </instruccion>... Datos: Esta respuesta la realiza el hardware cuando se le demanda una lectura. Su tipo de instrucción es tipo= 3. El modulo y pin al que la respuesta se refiere puede ser identificado a través del idinstruccion. El valor vendrá comprendido entre los tags <valor> así como la evolución que está teniendo entre los tags <evolucion>. Un ejemplo es el siguiente:... <instruccion idinstruccion= 8 tipo= 3 > <sensor idsensor= 1 valor= 46 evolucion= - > < sensor idsensor= 2 valor= 5 evolucion= + >... </instruccion>...

43 Memoria. Protocolo de comunicaciones 31 El valor que se devuelve estará convertido ya a valores físicos o binarios en caso de encendido/apagado. Por lo tanto, sus unidades dependerán del tipo de sensor al que se refiere. La evolución tendrá valores -, = o + dependiendo de si la evolución es negativa, constante o positiva. La evolución tiene utilidad sólo para los valores no binarios como la temperatura o la humedad, para el resto de sensores, se devolverá. OK: La respuesta OK, identificada con el tipo= 4, es la respuesta que le da el hardware al cliente si la escritura que ha pedido ha sido realizada sin ningún problema. Teniendo en cuenta que no hay que pasar ningún tipo de dato, la estructura es muy simple, consta simplemente del tag <instruccion>. Por ejemplo:... <instruccion idinstruccion= 1 tipo= 4 > </instruccion>... Error: La respuesta Error tiene el argumento tipo= 5. Esta instrucción se manda desde el hardware a la interfaz de usuario y significa que no ha podido ser realizada la instrucción a la que se refiere. El hardware mandará el tipo de error que se ha producido. El tipo de error estará entre los tag <error>. Un ejemplo de una instrucción tipo Error es el siguiente:... <instruccion idinstruccion= 7 tipo= 5 > <error> 2 </error> </instruccion>

44 Memoria. Protocolo de comunicaciones Cambio de estado de un actuador: El cambio de estado de un actuador se identifica por el tipo= 6 dentro de la instrucción y le sirve al usuario para cambiar de manual a automático o vice-versa un actuador. Esto significa, que en manual, el actuador no se modificará salvo si un usuario lo hace desde la interfaz Web, sin embargo, en automático, se modificará según las reglas previamente creadas, pero no hará caso a las ordenes del usuario por Internet. Tenemos que identificar a que actuador nos referimos, así como el estado al que se quiere cambiar. Se pasará un idsensor para identificar el actuador y un atributo valor dentro del tag <dispositivo>. valor será igual a 1 cuando se quiera cambiar a automático, e igual a 0 cuando se quiera cambiar a manual. Por ejemplo:... <instruccion idinstruccion= 6 tipo= 6 > <dispositivo idsensor= 1 valorr= 1 /> </instruccion>... Cambio del modo de la casa: Esta instrucción permite al usuario cambiar las reglas de actuación de una casa, es decir, pasar del estado verano a invierno o de vacaciones por ejemplo. Para ello utiliza el tipo= 7. Se identifica únicamente por un tag <modo> cuyo único valor valor que indica a que modo se cambia. He aquí un ejemplo:... <instruccion idinstruccion= 3 tipo= 7 > <modo valorr= 3 />

45 Memoria. Protocolo de comunicaciones 33 </instruccion>... Lectura del modo actual: Esta instrucción sirve para poder saber en que modo están los transductores de la casa, para poder modificarlo si el usuario lo cree conveniente. El tipo= 9 codifica para esta instrucción, que no necesita de ningún tag:... <instruccion idinstruccion= 12 tipo= 9 > </instruccion>... Cambio de modo actual: Esta es la respuesta a la instrucción anterior. Su estructura es similar a la instrucción 7: Error! No se encuentra el origen de la referencia., con un sólo tag <modo>, pero con el atributo idmodo. Se utiliza el tipo= 10 para reconocer esta instrucción. A continuación se muestra un ejemplo:... <instruccion idinstruccion= 3 tipo= 10 > <modo idmodo= 4 /> </instruccion>... 4 Intercambio de ficheros en las comunicaciones Todas las comunicaciones se van a realizar a través de archivos de texto. Esto en un principio puede crear problemas a causa de los derechos de lectura y escritura de los mismos, así como en el momento de borrarlos si

46 Memoria. Protocolo de comunicaciones 34 otro hilo los está leyendo. Otro problema encontrado es el saber cuándo la comunicación tiene lugar. Para solucionar estos problemas, la solución que ha sido propuesta es la siguiente: Para empezar se trabajará con varios archivos a la vez. Por una parte la aplicación para el usuario tendrá un archivo donde escribirá el mensaje con las instrucciones. Este archivo, que se llamará client2hard.txt, será leído por la parte hardware. De la misma manera, la parte hardware tendrá un segundo archivo hard2client.txt donde escribirá las respuestas que serán leídas por la aplicación cliente. Para evitar problemas de lecturas de mensajes a medias, los mensajes, tanto de una parte como de otra, serán escritos en un primer lugar en un archivo temporal, hard2client.tmp y client2hard.tmp respectivamente. A este archivo temporal, una vez el mensaje esté totalmente escrito, se le renombrará en.txt para que la otra parte pueda leerlo entero. La aplicación hardware sabe cuándo empiezan las comunicaciones, cuando existe el archivo client2hard.txt. Mira continuamente si existe dicho archivo. En el momento en que lo encuentra, lee el mensaje y borra el archivo, responde a las instrucciones, y se pone de nuevo a la espera de un nuevo mensaje. Por su parte, la aplicación usuario sabe cuándo la otra parte ha recibido sus mensajes ya que los archivos que crea son borrados una vez leídos. Además, ambas partes escribirán un archivo con el historial de las comunicaciones con cada mensaje.

47 Memoria. Protocolo de comunicaciones 35 Figura 11: Intercambio de ficheros en las comunicaciones. 5 Tablas de sensores Las tablas de sensores sirven para traducir la tensión leída por el microcontrolador en las magnitudes reales a las que se refiere el sensor. De esta manera, la tabla proporciona varios puntos de transformación y el programa interpolará entre los puntos para conocer la magnitud en todo el rango de valores. Para indicar un determinado valor en la tabla, dentro de un archivo de texto se deberá escribir lo siguiente: :Vpin->Xreal; De esta manera se vincula el valor de una determinada tensión con el valor de la correspondiente magnitud. A continuación se muestra un ejemplo utilizado para traducir la información leída de un sensor de humedad: tablahumedad.txt: :0->100;

48 Memoria. Protocolo de comunicaciones 36 :1.15->90; :1.67->80; :2.5->70; :3.5->60; :4.28->50; :4,8->40; :4.95->30; :5->20; Algo muy importante a destacar es que todas las tablas deben incluir al menos dos puntos, y siempre deben asignarse valores para los puntos de Vpin = 0 y Vpin = 5 (esto es debido a que el rango de tensiones que puede aparecer en cualquier conversor AD es de 0 a 5 voltios).

49 Memoria. Reglas y modos 37 Capítulo 5 REGLAS Y MODOS 1 Introducción Durante el capítulo 1, se comentó que una de las características deseables para un sistema domótico debía ser que fuera configurable y flexible. Todo usuario desea que los sistemas que utiliza se amolden a él y no él a los sistemas. De esta manera, los usuarios del sistema domótico deben tener la posibilidad de configurar el grado de automatización de su hogar y las características de dicha automatización. 2 Reglas En una regla describimos conjunto de circunstancias que se deben dar en el hogar para que se realicen unas determinadas acciones. Una de las reglas más sencillas que podemos imaginar es la que actúa sobre la temperatura de de cualquier casa. Así, lo que se quiere es que cuando la temperatura de de la casa baje de un determinado valor se encienda la calefacción, mientras que si la temperatura es demasiado alta se desea que la calefacción se apague. Otro ejemplo de una regla podría ser una que mantuviera las luces de casa apagadas, que suene una alarma si hay movimiento en ciertos lugares, etc. De los ejemplos anteriormente mencionados se puede ver que todas las reglas poseen ciertas similitudes. Siempre se basan en alguna medida realizada por uno o varios sensores.

50 Memoria. Reglas y modos 38 El usuario puede querer variar parámetros de la regla en tiempo real. Tomando como referencia el ejemplo de la regla de temperatura, el usuario podría desear bajar o subir la temperatura de su casa dependiendo de si está en invierno o en verano. Siempre se desea modificar al menos un actuador. Existen cálculos más o menos complicados que pueden involucrar los valores de los sensores, los de ciertos actuadores, los de las variables modificables por el usuario, etc. Se pretende realizar un sistema de reglas que sea lo más flexible posible, por lo tanto, se ha desarrollado sistema que incorpore todas las características mencionadas anteriormente. 2.1 Script de regla Las características de cada regla se guardarán en un archivo de texto que posea la siguiente estructura: <REGLA nombre= 8 Id= 3 > </REGLA> El tag REGLA determina que comienza la definición de una nueva regla. Los atributos nombre y Id se utilizan para la identificación de la regla en el conjunto de todas las reglas tanto dentro del programa como para el usuario. Dos reglas nunca pueden tener idéntico nombre o Id. Dentro de cada regla siempre debe haber una sección de variables, sensores, actuadores y código.

51 Memoria. Reglas y modos Sección de variables En la sección de variables se declaran todas las variables que podrán ser modificadas por el usuario desde fuera. Estas variables suelen ser variables de referencia por ejemplo de una temperatura, una luminosidad, una humedad, etc. La sección vendrá definida de la siguiente forma: <VARIABLES> V1 = 0; V2 = 10; </VARIABLES> A la izquierda del igual tendremos los identificadores que usaremos durante nuestro código para referirnos a la variable, mientras que a la derecha del igual tendremos el valor inicial que asignamos a la variable Sección de sensores Por otro lado, tenemos la sección sensores, donde se indica en qué sensores nos vamos a basar para realizar los cálculos de la regla. La sección tiene la siguiente estructura: <SENSORES> sensorluminosidad = 3; sensortemperatura = 7; </SENSORES>

52 Memoria. Reglas y modos 40 Los nombres a la izquierda del igual son identificadores que usaremos durante el script para referirnos al valor del sensor en ese determinado instante. A la derecha del igual deberemos escribir el número Id del sensor al que nos queremos referir Sección de actuadores La siguiente sección que debemos tener dentro de la regla es la sección de actuadores. Tiene la siguiente forma: <ACTUADORES> caldera = 6; lucespasillo = 10; </ ACTUADORES > Como se puede observar, se trata de una sección muy similar a la sección de sensores. A la izquierda debe estar el identificador del actuador, mientras que a la derecha escribiremos el Id del actuador al que nos referimos Sección de código La última sección que debe tener nuestra regla es la sección de código. Es la más importante de nuestro script de regla. Es en esta sección donde se determinan las comparaciones y cálculos que se deben hacer a partir de las variables, valores de los sensores, y actuadores para producir una determinada salida en los actuadores. El código estará formado por un conjunto de comparaciones, sentencias y asignaciones:

53 Memoria. Reglas y modos 41 Comparaciones: Siempre que queramos comparar el valor de alguna variable, de un sensor o de un actuador se deberá hacer de la siguiente forma: sensorluminosidad < 700; Tanto a la derecha del operador como a la izquierda se puede colocar una variable, un sensor, un actuador o una constante. Los operadores soportados son los siguientes: < (operador menor que), > (operador mayor que), == (operador igual a). Se pueden realizar operaciones de suma, resta, multiplicación y división a la derecha del operador siempre que se indique la operación entre paréntesis: sensorluminosidad < ( sensortemperatura ); Sentencias: Cada comparación tiene que ir relacionada con una sentencia de la siguiente manera: OperadorDeSentencia comparación; Un ejemplo es el siguiente: U sensorluminosidad < 700; Las sentencias sirven para ir realizando operaciones binarias con el resultado de la comparación. La operación se realizará entre el acumulador y el resultado de la comparación correspondiente. El acumulador será 1 si se trata de la primera sentencia y el resultado de las sentencias anteriores si se trata de otro caso. Así, se realiza la operación:

54 Memoria. Reglas y modos 42 acumulador operador resultadocomparacion Los tipos de operadores que hay son: U (and), O (or), UN (and negado) y ON (or negado). Veamos un ejemplo con dos sentencias: U sensorluminosidad < 700; O sensortemperatura > 23; El cálculo que se realizará es el siguiente: Primero se resuelve la primera comparación, si el sensor de luminosidad es menor que 700 se devolverá un 1 o verdadero, en otro caso se devolverá un 0 o falso. Supongamos que la luminosidad es menor de 700 y se devuelve un 1. La sentencia hará un and del acumulador y del 1. Como es la primera sentencia del código, el acumulador es 1, con lo cual se realiza la operación 1 and 1, que da como resultado otro 1. Pasamos a la siguiente sentencia; se resuelve la comparación que suponemos devuelve un 0, se realiza un or entre el acumulador y la comparación, como el acumulador era un 1: 1 or 0 = 1. De esta manera, el acumulador para la siguiente sentencia seguirá siendo un 1. Las sentencias pueden agruparse en bloques de la siguiente forma: ( U sensorluminosidad < 700; O sensortemperatura > 23; ) U sensortemperatura < 14;

55 Memoria. Reglas y modos 43 En este caso, primero se resolverá el bloque comprendido entre los paréntesis, se modificará el acumulador, y posteriormente se resolverá la siguiente sentencia. Por último, existe una sentencia especial para reinicial el valor del acumulador: RST; Es útil para poder introducir valores a actuadores, con diferente lógica de control. Asignaciones: Sirven para dar un determinado valor a un actuador. Poseen la siguiente forma: actuador = valor; Por ejemplo: caldera = 1; El cálculo que se realiza es que si el acumulador hasta ese momento ha sido 1 o verdadero, se realiza la asignación, mientras que si ha sido 0 o falso no se realiza ninguna acción. Una asignación no modifica el valor del acumulador. Las asignaciones siempre deben ir al final de todas las sentencias. Se pueden poner varias asignaciones de forma consecutiva para modificar más de un actuador. caldera = 1; lucespasillo = 0;

56 Memoria. Reglas y modos Ejemplo completo de regla En este apartado vamos a mostrar un ejemplo ilustrativo de lo que podría ser una regla de temperatura para nuestro sistema: < REGLA nombre= Regla de temperatura Id= 3 > <VARIABLES> TReferencia = 21; Histeresis = 2; </VARIABLES> <SENSORES> sensortemperatura = 3; </SENSORES> <ACTUADORES> caldera = 5; </ACTUADORES> <CODIGO> U sensortemperatura < TReferencia; caldera = 1; RST; U sensortemperatura > ( TReferencia + Histeresis ); caldera = 0; </CODIGO> </REGLA> En la sección de variables hemos definido dos variables que puede modificar el usuario en tiempo real: la temperatura a la que desea su hogar y la histéresis. Luego se determinan cuáles son los sensores y actuadores que intervendrán en la sección de código. En la sección de

57 Memoria. Reglas y modos 45 código determinamos que la caldera se encienda si la temperatura que mide el sensor de temperatura es menor que la de referencia y que la caldera se apague si la temperatura medida por el sensor es mayor que la de referencia más una cierta histéresis. 3 Modos Un sistema domótico en el que sólo hubiese reglas sería realmente incómodo de utilizar. Por ejemplo un usuario quiere, si se está fuera de casa, que si hay movimiento en el hogar salte una alarma, se encienda todas las luces y se cierren las puertas. Sin embargo, si es el usuario el que está dentro de casa, no quiere que esto suceda. Si sólo hubiese reglas, implicaría que cada vez que el usuario entrara en casa, tendría que activar y desactivar cierto número de reglas, lo que sería una situación ciertamente incómoda. Por esta razón se han introducido los modos en el sistema domótico. Un modo es un conjunto de reglas. De esta manera, se pueden asociar todas las reglas de seguridad que se desee al modo, por ejemplo, Fuera de casa. Cada vez que se entre o se salga del hogar simplemente hay que cambiar el modo de funcionamiento del sistema. Esto añade flexibilidad al sistema y comodidad al usuario. 3.1 Script de modo Para definir el modo y las reglas que están asociadas al modo, se utilizará un archivo de texto con la siguiente configuración: <MODO nombre= Modo fuera de casa Id= 5 > <REGLAS> Regla1.txt Regla2.txt

58 Memoria. Reglas y modos 46 </REGLAS> </MODO> Primero, en el tag MODO indicamos cuál es el nombre del modo y su número de identificación. Con el tag REGLAS se indica que se van a comenzar a escribir las reglas que pertenecen al modo que se está definiendo. Dentro del tag REGLAS se debe escribir el nombre del archivo que contenga la regla que queramos incluir en el modo. De esta forma, la regla que venga definida dentro del archivo Regla1.txt pertenecerá al modo Modo fuera de casa. Cabe destacar que una regla puede pertenecer a varios modos distintos. Todos los modos de la aplicación deberán estar reunidos en el archivo de texto Modos.txt. Dicho archivo tiene la siguiente estructura: <MODOS> Modo1.txt Modo2.txt <MODOS> Dentro del tag MODOS deberán estar los nombres de los archivos que contienen la información de cada modo. El sistema mira qué modos existen a partir de este archivo y luego relacionará las reglas con cada modo a partir de los archivos de modo.

59 Memoria. Diseño del software 47 Capítulo 6 DISEÑO DEL SOFTWARE 1 Introducción Este capítulo trata sobre cómo se ha realizado el diseño de la aplicación software que se encarga del control de todo el hardware del que se compone el sistema. Se trata de una aplicación de gran importancia debido a que un fallo en ésta puede provocar efectos indeseados en nuestro hogar, ya sea porque no actúe cuando deba o porque actúe cuando no deba. Además de administrar con seguridad el hardware del sistema, la aplicación debe estar preparada para recibir mensajes desde el exterior para modificar su estado. Para separar la tarea de controlar el hardware del hogar y recibir mensajes de otras aplicaciones, se ha optado por un diseño con varios hilos de ejecución o multithread. De esta manera, se tendrá un módulo de comunicaciones encargado exclusivamente a éstas y un módulo de hardware encargado exclusivamente de ejecutar acciones sobre el hardware. Este sistema tiene la ventaja de que permite establecer prioridades entre ambos hilos, lo que permite que no interfieran los mensajes externos si hay alguna tarea importante a realizar sobre el hardware. A continuación se muestra un esquema que describe las comunicaciones que se dan entre los distintos hilos de ejecución en los que se basa la aplicación:

60 Memoria. Diseño del software 48 Figura 12: Comunicaciones entre los hilos de la aplicación Toda la aplicación se ha programado con el lenguaje de programación C++ y se ha utilizado un diseño de programación orientado a objetos. Para su compilación y desarrollo se ha utilizado el compilador Microsoft Visual Studio.NET. 2 Módulo de scripts La función del sistema de scripts es dar acceso al programa a archivos guardados en el disco duro. Generalmente, durante el desarrollo del programa necesitaremos acceder al contenido de archivos tipo texto, que generalmente tienen una estructura con tags y atributos. Por lo tanto, también es función del sistema de scripts el hacer más fácil el acceso a la información escrita dentro de los tags. El sistema tiene la siguiente forma:

61 Memoria. Diseño del software 49 Figura 13. Módulo de scripts En la Figura 13. Módulo de scripts, se puede observar que todas las clases pertenecen al módulo de script y tienen el color verde de fondo. Las flechas en el diagrama anterior y en los próximos diagramas significan o bien herencia o bien que la clase apuntada es utilizada por la clase que apunta. Existe una clase ScriptEscritura con la finalidad de que se encargue de escribir sobre archivos, con funciones específicas para insertar tags en éste. Además, se crea otro objeto con la función de leer archivos de texto, facilitando la lectura de tags. El sistema de scripts no se ha basado en ninguna librería específica para esta tarea; ha sido un sistema creado íntegramente para la aplicación. Esto fue debido a la flexibilidad que se obtiene si no se escriben scripts exclusivamente en XML. Este sistema tiene gran importancia porque el resto de sistemas necesitan acceder a archivos de texto y, por lo tanto, se basarán en este modulo.

62 Memoria. Diseño del software 50 3 Módulo de comunicaciones El módulo de comunicaciones tiene como finalidad el que la aplicación pueda establecer comunicaciones con el exterior a través de mensajes insertados en archivos de texto. Se asigna un hilo de ejecución exclusivamente a esta tarea. Veamos los módulos en los que se basa: Figura 14. Módulo de comunicaciones Las clases que forman el módulo de comunicaciones están coloreadas de naranja. En primer lugar, el hilo de comunicaciones hereda de la clase Thread las capacidades de ejecutarse y finalizarse. Basándonos en el módulo de scripts, tenemos dos clases que se encargan de leer o escribir mensajes que contengan determinadas instrucciones. De este modo, el hilo de ejecución tiene un director de mensajes que se encarga de leer un mensaje nuevo si existe y de contestar con otro mensaje si es necesario.

63 Memoria. Diseño del software 51 En general, se puede decir que la ejecución del bucle de comunicaciones no es de vital importancia para la aplicación y basta con que se ejecute aproximadamente una vez cada segundo. El bucle de comunicaciones tiene la siguiente forma: Figura 15. Bucle de comunicaciones El bucle lo primero que realiza es comprobar si ha llegado un mensaje nuevo. Si es necesario, traduce el mensaje a instrucciones, ejecuta las instrucciones leídas, crea unas nuevas instrucciones contestando a las anteriores y finalmente escribe un nuevo mensaje contestando al que había recibido. Antes de volver a ejecutar el bucle siempre se duerme el hilo durante un segundo para no sobrecargar el procesador del ordenador con tareas que no son de utilidad. Se ha dicho, que durante el bucle de comunicaciones hay cierto momento en el que se ejecutan las instrucciones leídas. Estas instrucciones pueden ser para leer datos del hardware o modificar estados del hardware. En general, podemos decir que para ejecutar las instrucciones necesitaremos

64 Memoria. Diseño del software 52 del módulo de control de hardware, que será explicado más adelante detalladamente. 4 Módulo de reglas y modos El módulo de reglas y modos es el encargado de gestionar todas las acciones relacionadas con los módulos y las reglas, desde su lectura a su ejecución y modificación. Veamos de qué clases está formado: Figura 16. Módulo de reglas y modos El módulo de reglas y modos lo forman las clases que tienen de fondo el color azul claro. Como se puede ver, el módulo se basa en el módulo de scripts para poder acceder a los archivos donde se guarda la información de cada regla y modo. La clase ScriptRegla da las capacidades para cargar una regla en el programa, modificar sus valores, y ejecutarla. La clase ScriptModo carga un modo en la aplicación junto con las reglas que estén relacionadas con el modo. Además existe la posibilidad de ejecutar un modo, lo que implica que se ejecuten todas las reglas que pertenecen a dicho modo. La clase más importante de este módulo se trata de

65 Memoria. Diseño del software 53 ScriptModosManager, cuya tarea es cargar todos los modos que existan, ejecutar el modo actual, cambiar entre modos, etc. En la figura aparecen las clases más importantes del módulo, pero no son las únicas. La clase ScriptRegla se basa en muchas otras clases que representan ciertas secciones que pueden aparecer en un script que describa una regla. A continuación se muestra un esquema general de cómo está formada la clase ScriptRegla: Figura 17. Cómo se forma la clase ScriptRegla Según se explicó en el Capítulo 5, cada script que contenga una regla debe tener cuatro secciones. Existe una sección que contiene todas las variables de la regla que pueden ser modificadas por el usuario, otra que contiene todos los sensores a los que se hace referencia durante el script, otra contiene todos los actuadores que podrán ser modificados por la regla y por último otra sección en el que se explica cómo se debe ejecutar la regla. Esta última sección está formada por expresiones que podrán ser de asignación o de evaluación. Además, toda evaluación tiene asociada una comparación que puede o no tener incluida una operación matemática.

66 Memoria. Diseño del software 54 Para más información sobre cuál es el léxico de los scripts que contienen una regla, consultar Capítulo 52.1: Script de regla. Al igual que ocurría con el módulo de comunicaciones, cada vez que se ejecuta una regla implica que puede que se deba modificar algún actuador, surgiendo así la necesidad de tener acceso al módulo de hardware. En la siguiente sección veremos exactamente cómo funciona dicho módulo y cómo puede ser accedido desde el módulo de reglas y modos. 5 Módulo de control del hardware El módulo de control de hardware es sin duda alguna el módulo más importante de toda la aplicación. Este módulo se encarga de establecer comunicación con los distintos remotos que haya instalados en el sistema domótico, inicializarlos, pedir el estado de los sensores, establecer el estado de los actuadores, etc. En la siguiente figura se puede ver un esquema de cómo está formado el módulo de control del hardware:

67 Memoria. Diseño del software 55 Figura 18. Módulo de control del hardware Las clases que pertenecen al módulo hardware son las clases que tienen de fondo el color salmón. En primer lugar empezaremos analizando la clase más importante del módulo: la clase Casa. Esta clase da acceso a toda la lista de sensores y actuadores que existen en el sistema domótico. Además, tiene una lista con todos los remotos (también llamados módulos) en los que está dividido el sistema, y a su vez cada remoto posee una referencia a los sensores y actuadores que tiene conectados. De esta manera, a través de esta lista de remotos se tiene acceso a todo el sistema domótico. Para conocer de qué remotos y de qué sensores está formado el sistema, se necesita en primer lugar cargar la información de configuración. Para ello se usa la clase ScriptConfigCasa, que utiliza el módulo de scripts. Otra clase que utiliza el módulo de scripts es la que se encarga de leer de las tablas de los sensores. Esta clase es la encargada de traducir una

68 Memoria. Diseño del software 56 información cruda (en mv) que se lee del sensor en valores en las magnitudes que corresponda. Para que la clase Casa pueda comunicarse con los remotos, primero debe comunicarse con la base a través del puerto de comunicaciones RS-232. Estas comunicaciones están encapsuladas en la clase Comm, con lo que simplemente se utiliza su interfaz para poder comunicarse con los remotos. La clase Casa también se ocupa de iniciar todos los modos y reglas y de ejecutar el modo que sea pertinente. Vemos que sólo hace falta tener acceso a la clase ScriptModosManager para poder tener control absoluto de todo el sistema de reglas y modos, lo que implica que las tareas de cambiar de modo, actualizar modos y reglas y modificar reglas se pueden hacer de una manera muy sencilla a través de dicha clase. El último aspecto que queda por analizar de este módulo es que existe un hilo de ejecución encargado de actualizar toda la información del sistema. Este hilo de ejecución hereda de Thread y tiene la siguiente estructura:

69 Memoria. Diseño del software 57 Figura 19. Bucle de control de hardware Lo primero que se realiza es actualizar todos los remotos que componen el sistema. Para ello, para no tener que conectar con el mismo remoto dos veces cada vez que se ejecute el bucle, cada vez que se contacta con un módulo se le pide toda la información de los sensores y se modifica todos los actuadores que sean necesarios. En segundo lugar, el bucle de control ejecuta el modo que esté activo; para ello ejecuta cada una de sus reglas. Si alguna regla debe modificar algún actuador, será en el próximo bucle de control (cuando se comunique con el módulo donde se encuentra el actuador) cuando se actualizará realmente el valor del actuador en el remoto. Para no sobrecargar el procesador del ordenador, se deja dormido el hilo un segundo cada bucle de control. En anteriores secciones se ha comentado la necesidad de acceder al módulo de control de hardware desde otros módulos. Existen varias soluciones a este problema. La primera de ellas podría ser crear un sistema de mensajes con el cual se puedan mandar determinados mensajes desde

70 Memoria. Diseño del software 58 cualquier módulo y luego leer los mensajes que sean de interés en cualquier otro. De esta manera, cada módulo no tendría porqué conocer la existencia del módulo de control de hardware, sino que mandaría mensajes del estilo mueve un cierto actuador y sería en el módulo de hardware donde se estaría escuchando a esos mensajes y se actuaría en consecuencia. Esta solución se trata de una solución general para poder comunicar muchos módulos sin que sea necesario que se conozcan entre sí. En el caso que nos ocupa, los módulos sólo necesitan tener acceso a la clase Casa para poder modificar los actuadores, con lo que la solución de crear un sistema de mensajes es demasiado complicada y se le sacaría poco partido. Por esta razón, se ha optado por crear un objeto tipo Casa global al que puedan acceder todos los módulos. De esta manera se resuelve el problema de una forma sencilla y rápida, pero hay que tener en cuenta que puede ser peligrosa y que se debe tener cuidado a la hora de programar los módulos puesto que cualquiera puede modificar y alterar el objeto global. 6 Coherencia de datos en aplicaciones multihilo Las aplicaciones multihilo tienen grandes ventajas frente a las aplicaciones con un sólo hilo de ejecución. Algunas de estas ventajas es la capacidad de que dos procesos se ejecuten en paralelo (al menos aparentemente), mejorar el rendimiento de la aplicación, etc. En nuestro caso resulta muy útil la programación multihilo para poder separar los procesos de control y de comunicaciones. Sin embargo, las aplicaciones multihilo tienen algunas desventajas como puede ser la coherencia de datos o la dificultad de programación y de depuración. En esta sección se pretende hacer hincapié en la importancia que ha tenido la coherencia de datos durante la programación de la aplicación. El problema surge cuando se tienen varios hilos de ejecución que deben compartir información. Un hilo puede intentar leer una variable a la vez

71 Memoria. Diseño del software 59 que otro hilo la está modificando, lo que producirá que la variable leída será errónea. De esta manera, hace falta proteger las variables mientras que se está accediendo a ellas para que otros hilos no puedan modificarlas. En el caso de la aplicación que se ha desarrollado, la información que deben compartir los dos hilos es el objeto global tipo Casa. Más concretamente, la información que se comparte es el estado de los sensores y de los actuadores. La solución implementada ha sido incluir banderas en cada sensor y cada actuador, de tal forma que cada vez que algún hilo accede a la variable, se toma la bandera y el resto de hilos no puede acceder a la variable porque la bandera está cogida. Una vez que se ha terminado de modificar o de leer la variable, se suelta la bandera para que el resto de hilos puedan acceder a ella. La utilización de semáforos para conservar la coherencia de datos en programas multihilo es una solución rápida y sencilla. Sin embargo, puede ser peligrosa. Hay que tener en cuenta que si la bandera está cogida por un hilo y otro hilo intenta acceder a ella, este último debe esperar hasta que el primero suelte la bandera. El problema viene cuando un hilo coge la bandera y por un fallo de programación la bandera no se suelta: cada hilo que intente acceder a la variable esperará eternamente a que la bandera sea liberada. A continuación se expone un ejemplo de un uso correcto de los semáforos en sistemas multihilo: extern CSensor g_sensor1; //objeto global void actualiza_sensor(int valor, float hora){ g_sensor1.set_valor(valor, hora);

72 Memoria. Diseño del software 60 } void mostrar_info_sensor1(){ int valor = g_sensor1.get_valor(); float hora = g_sensor1.get_hora(); printf( valor: %i, hora: %f, valor, hora); } El problema surge cuando tenemos una variable compartida entre varios hilos, por ejemplo la variable g_sensor1. Supongamos que las funciones actualiza_sensor1() y mostrar_info_sensor() pueden llamarse desde distintos hilos de ejecución. Si desde un hilo se llama a la función mostrar_info_sensor1(), no se puede asegurar que desde otro hilo no se esté llamando a la vez a la función actualiza_sensor(). Con lo cual, lo que podría ocurrir en este caso es que se muestre almacene un valor de un sensor, se modifique la información del sensor desde otro hilo y posteriormente se almacene la nueva hora, corrompiendo de esta manera la información. Una de las soluciones podría ser utilizar un semáforo que evite que se pueda pedir información del sensor si éste está siendo modificado: Bool semaphore; void actualiza_sensor(int valor, float hora){ do{

73 Memoria. Diseño del software 61 if(semaphore == false) semaphore = true; g_sensor1.set_valor(valor, hora); semaphore = false; } }while(semaphore!= false); } void mostrar_info_sensor1(){ do{ if(semaphore == false) semaphore = true; int valor = g_sensor1.get_valor(); float hora = g_sensor1.get_hora(); printf( valor: %i, hora: %f, valor, hora); semaphore = false; } }while(semaphore!= false); } Como se puede ver, ahora las funciones no permiten que se obtengan valores del sensor si se está modificando en ese mismo momento. En el momento en que se pretende utilizar una variable compartida se cambia el valor del semáforo evitando que el resto de funciones puedan acceder ala

74 Memoria. Diseño del software 62 variable. Como se puede ver, la correcta programación de los semáforos en las aplicaciones es crucial para el correcto funcionamiento multihilo. El fallo más común a la hora de programar semáforos es coger el semáforo y no soltarlo una vez que deja de ser necesario. En ese momento el recurso compartido (en este caso una variable) dejaría de ser accesible por siempre para el resto de la aplicación.

75 Memoria. Resultados/Experimentos 63 Capítulo 7 RESULTADOS/EXPERIMENTOS El principal experimento que se realizó fue probar el sistema con las siguientes características: 1 servidor Web para las comunicaciones con la página Web del proyecto complementario a este proyecto. 1 base conectada a dicho servidor. 2 remotos de distinto tipo: 1 de bajo consumo y otro no. El de bajo consumo se utilizó para conectar todos los sensores y se alimentó con pilas. El de alto consumo se alimentó con red eléctrica. 1 sensor de humedad conectado al módulo de bajo consumo. 1 sensor de luminosidad conectado al módulo de bajo consumo. 1 sensor de movimiento conectado al módulo de bajo consumo. 1 relé conectado al módulo de alto consumo que acciona una lámpara. 1 relé conectado al módulo de alto consumo que acciona un humidificador. Una regla muy simple que encendía la lámpara si existía movimiento. Cabe destacar que el sistema de reglas no estaba implementado como lo está actualmente y que una regla se definía mediante programación. Este sistema fue probado y funcionaron las características para las que fue programado. Entre ellas se pueden destacar: Desde la página Web se podía ver en tiempo real tanto luminosidad como la humedad y si había movimiento en ese momento o no.

76 Memoria. Resultados/Experimentos 64 Posibilidad de cambiar un actuador de modo manual a automático. Si el actuador estaba en modo manual se podía encender y apagar a través de la página Web. Si la lámpara estaba en modo automático, se encendía si había movimiento cerca del módulo. Sin embargo, al principio, no funcionó todo perfectamente bien: de vez en cuando aparecían fallos a la hora de establecer comunicaciones entre la aplicación software y el hardware, creando una sensación de que la aplicación no reaccionaba como el usuario quería. Este sistema fue llevado al stand de la Universidad Pontificia de Comillas en la Feria de la Ciencia de Madrid el 13 de Abril de Allí se mostró cómo funcionaba el sistema y sus características. Posteriormente se desarrolló el sistema de reglas y se mejoraron los problemas que existían en las comunicaciones entre las aplicaciones. Se volvió a montar otro sistema para probar las nuevas características. El sistema montado fue el siguiente: 1 servidor Web para las comunicaciones con la página Web del proyecto complementario a este proyecto. 1 base conectada a dicho servidor. 1 remoto del tipo de alto consumo. 1 sensor de movimiento conectado al remoto. 1 humidificador conectado al remoto a través de su correspondiente relé. Se configuraron dos reglas distintas: la primera encendía el humidificador si existía movimiento en la habitación y lo apagaba si dejaba de haberlo. La segunda hacía lo contrario, si no existía

77 Memoria. Resultados/Experimentos 65 movimiento encendía el humidificador y había movimiento lo apagaba. Se configuraron dos modos distintos asociando cada una de las reglas a cada modo. Durante esta prueba se comprobó que los fallos en las comunicaciones entre las dos aplicaciones fueron subsanados y que las comunicaciones funcionaban correctamente. Además, el sistema de reglas funcionó correctamente añadiendo la capacidad de poder cambiar de modo desde la página Web.

78 Memoria. Conclusiones 66 Capítulo 8 CONCLUSIONES Durante el desarrollo del proyecto se han cubierto los siguientes objetivos: Se ha realizado una aplicación software capaz de leer las medidas de los sensores colocados en diferentes módulos en una casa y de poder determinar y modificar el estado de los distintos actuadores que haya conectados a los correspondientes módulos. Se ha creado un sistema de reglas por el cual se pueden generar fácilmente reglas y modos complejos de forma dinámica sin tener que recompilar la aplicación. Se han conseguido comunicaciones robustas entre la aplicación hardware y la aplicación interfaz de usuario. La aplicación es capaz de leer un archivo de configuración de una casa y de inicializar correctamente los distintos módulos que en ella se especifican. Se ha creado una gestión de errores de forma que en caso de que haya algún error de comunicaciones la aplicación mostrará el correspondiente fallo a través de la ventana de comandos y de un archivo de tipo.log. Cada vez que se comunique la aplicación con cada módulo se aprovechará para mandar la información correspondiente de los actuadores, con la correspondiente mejora en la eficiencia en las comunicaciones. Como conclusión se puede decir que el proyecto ha cumplido todos los objetivos planteados. En primer lugar, se ha conseguido crear un programa capaz de controlar y modificar el estado de varios sensores y

79 Memoria. Conclusiones 67 actuadores en varios remotos distintos. En segundo lugar, se ha implementado un sistema de reglas y modos configurables de forma sencilla por el usuario. Por último, se han conseguido unas comunicaciones robustas entre las distintas aplicaciones software así como las comunicaciones entre los distintos componentes hardware.

80 Memoria. Futuros desarrollos 68 Capítulo 9 FUTUROS DESARROLLOS El sistema que se ha finalizado durante este proyecto crea las bases necesarias para que se pueda desarrollar un sistema realmente completo. De esta manera, existen varias ampliaciones que se podrían hacer al sistema: Ampliar el abanico de sensores y actuadores disponibles para el sistema domótico. Gestión de datos históricos. Crear un conjunto de reglas y modos nuevos acorde con los sensores y actuadores que se puedan implementar en el sistema domótico. Crear una carcasa tanto para la base como para los remotos. Para el diseño de la carcasa de los remotos hay que tener en cuenta que cada remoto puede tener un conjunto distinto de sensores y actuadores. Podemos también nombrar como futuros desarrollos aquellas evoluciones de lo que existe actualmente en el sistema domótico. A continuación se muestran varias propuestas: Cambiar el tipo de conexión entre la base y el ordenador. Hoy por hoy el puerto serie tiende a desaparecer de los ordenadores y una conexión tipo USB sería mucho más adecuada. Reducir el consumo de baterías en las base de bajo consumo para que tengan aún más tiempo de autonomía.

81 Memoria. Bibliografía 69 BIBLIOGRAFÍA [1] Manuel Alvar Miró; Desarrollo de un sistema para el control y la seguridad de las casas. Interfaz de ususario. Junio [2] Steve McConnell; Code Complete, Second Edition. Junio 2004 [3] [4] [5] [6] ain.htm [7] &SubSubCatID=0 [8]

82 Estudio económico 70 Parte II ESTUDIO ECONÓMICO

83 Estudio económico 71 El proyecto realizado se trata de un sistema domótico modular, y configurable por el usuario siendo éste capaz de automatizar completamente un hogar. El sistema ofrece todas las ventajas de los sistemas domóticos actuales como son la comodidad y la seguridad, pero además permite que el usuario pueda modificar y configurar el sistema a su gusto de una manera fácil a la par que potente. Una de las ventajas fundamentales que tiene el sistema domótico elaborado durante el proyecto frente a la gran mayoría de los sistemas actualmente comerciales es el sistema de comunicaciones que posee. El sistema se basa en comunicaciones de radiofrecuencia entre los distintos dispositivos que lo componen, lo que implica que el impacto estructural en el hogar es mínimo. La mayoría de los fabricantes de soluciones domóticas en la actualidad tienen unos productos que hacen imprescindible que se haga una instalación más o menos complicada en el hogar. En contraposición, se pretende ofrecer un sistema domótico completo con la característica de que no hace falta hacer una instalación compleja en el hogar, dirigiendo el producto especialmente a los hogares ya construidos, en los que nuestro sistema sería muchísimo más fácil de instalar que la mayoría de los actuales sistemas comerciales. Otro de los puntos clave en el que destaca el sistema domótico desarrollado durante el proyecto es la capacidad de acceso que tiene desde Internet. Desde cualquier punto con conexión a Internet cualquier usuario es capaz de ver el estado de su casa y modificarlo si lo desea en tiempo real.

84 Parte III MANUAL DE USUARIO

85 Manual de usuario 73 1 Instalación del hardware A continuación se describen los pasos a seguir para conectar correctamente el hardware que forma el sistema domótico. En primer lugar se comienza conectando la base al ordenador. Para ello se ha de conectar el puerto COM1 del ordenador a la base a través del cable apropiado. A continuación se muestra una base con sus conexiones pertinentes: Figura 20: Conexiones de la base A la hora de conectar la alimentación a la base hay que tener cuidado de la dirección en la que se conecta. El conector tiene un saliente en un determinado lado, lo que permite su conexión sólo en una determinada dirección. A continuación se instalan los remotos. Hay que destacar que la alimentación de los remotos es más sencilla que la de la radio puesto que su conector no da lugar a errores.

86 Manual de usuario 74 Figura 21: Conexiones de un remoto Por último se muestran las conexiones necesarias entre un relé y un remoto para poder utilizar un actuador: Figura 22: Conexiones de un relé En primer lugar se pueden ver los dos conectores blancos. Estos van destinados a conectar el propio actuador. Como el actuador estará alimentado con la red eléctrica no importa el orden de dichas

87 Manual de usuario 75 conexiones. El conector en el que aparece un + a un lado y un punto al otro lado del conector se refiere a la alimentación del circuito. Por lo tanto, es necesario aplicar Vcc en el lado del + y tierra en el del punto. El otro conector sirve como señal para el relé. En este caso se deberá conectar la tierra al punto y la señal en el otro pin (el ± que hay al lado del punto sirve para indicar que dicho conector es el de la señal, no el de tensión). 2 Instalación de la aplicación software La aplicación no es autoinstalable, con lo cual, antes de ejecutarla hay que tener en cuenta que se deben reunir ciertas condiciones: Todos los archivos a los que tenga que acceder la aplicación deben estar en la misma carpeta que el ejecutable. La aplicación es sensible a las mayúsculas y a las minúsculas siempre. Para el correcto funcionamiento de la aplicación, es necesario que exista el archivo de configuración Config.txt en la misma carpeta que la aplicación. Se debe prestar especial atención al léxico en el archivo de configuración, puesto que un fallo en éste puede provocar el mal funcionamiento de la aplicación. Deberá existir el archivo Modos.txt, donde el programa buscará todos los modos y posteriormente las reglas que formarán el sistema de reglas y modos dentro de la aplicación. Para una explicación más detallada del léxico, acudir al Parte ICapítulo 52.1: ScriptRegla. Todos los archivos de las tablas de los sensores deben también estar situados en la misma carpeta que el archivo ejecutable.

88 Manual de usuario 76 Dentro de la carpeta donde se sitúa el ejecutable, nunca se deben crear archivos con los siguientes nombres: hard2client.txt, hard2client.log, client2hard.txt, logdomo.txt ni los anteriormente mencionados Config.txt ni Modos.txt. 2.1 Pasos a seguir para la instalación Situar el ejecutable DOMO0.3.exe en la carpeta de interés. Hay que tener en cuenta que si se desea que la aplicación establezca comunicación con la aplicación de usuario, se deben recibir los mensajes client2hard.txt en la misma carpeta donde se localice el ejecutable. Crear el archivo de configuración Config.txt según viene explicado en Parte ICapítulo 42: Configuración Inicial y colocarlo en la misma carpeta que el ejecutable. Crear los archivos de reglas y modos deseados y completar el archivo Modos.txt como viene explicado en la sección Parte ICapítulo 53.1: Script de modo. 3 Depuración de errores La aplicación está diseñada para crear un historial de los procesos que va ejecutando poco a poco. Esta información se puede ver en tiempo real en la pantalla de comandos que aparece cuando se ejecuta la aplicación. Toda la información que aparece en la ventana de comandos se va guardando poco a poco en un archivo de texto para poder ver y analizar toda la secuencia de procesos una vez que el programa ha finalizado su ejecución. Este archivo es el logdomo.txt y está diseñado para leerse una vez que se ha finalizado el programa. Si se intenta acceder al archivo durante la ejecución del programa, se accederá a un historial desactualizado del mismo.

89 Manual de usuario 77 El análisis del historial es fundamental para poder determinar por qué ha fallado la aplicación. Por ejemplo, puede ocurrir que un remoto esté mal enchufado o sin pilas; esto provocará que en el historial aparezca una frase diciendo que ha sido imposible comunicarse con el módulo en cuestión. 4 Errores más importantes En esta sección se comentarán los errores que pueden provocar que la aplicación deje de funcionar correctamente. Un error muy importante a tener en cuenta es que un fallo en el léxico de configuración inicial del sistema en el archivo Config.txt puede provocar que la aplicación se detenga en el proceso de cargar dicha configuración. Siempre que aparezca un fallo en las comunicaciones con algún módulo, el problema podrá estar en la comunicación con la base o entre la base y el módulo. Al lado del error de comunicación aparecerá la cadena devuelta por el driver de comunicaciones. Si no aparece ningún número, es que el fallo se encuentra en la base. Si aparece un 85, es que se ha podido establecer comunicación con la base pero el remoto no ha contestado a la comunicación. Si hay un fallo en las comunicaciones para configuración inicial de cierto módulo, el programa intentará repetir la comunicación varias veces. Si no consigue comunicarse con el módulo, la aplicación finalmente se ejecutará correctamente salvo para el módulo sin configurar, en el que siempre dará un error de comunicación.

90 Datasheets 78 Parte IV DATASHEETS

91 Datasheets 79

92 Datasheets 80