Gestión domótica del hogar mediante la tecnología OSGi

Proyecto Final de Carrera Ingeniero Técnico en Informática de Gestión Gestión domótica del hogar mediante la tecnología OSGi Abril 2011, Valencia Jesús Martín Sayas [email protected] Dirigido por: Joan Fons i Cors [email protected]pv.es Nacho Mansanet Benavent [email protected] 1 INDICE INDICE ............................................................................................................... 1 INDICE DE ILUSTRACIONES ............................................................................... 3 1. INTRODUCCIÓN ......................................................................................... 4 2. CONTEXTO TECNOLÓGICO Y PROBLEMÁTICA. IDEAS DE SOLUCIÓN. .. 9 3. TECNOLOGÍA RELACIONADA. OSGI ...................................................... 11 FRAMEWORK ....................................................................................................... 13 CICLO DE VIDA...................................................................................................... 15 BUNDLES .............................................................................................................. 16 GESTIÓN DE SERVICIOS ......................................................................................... 17 4. ANÁLISIS DEL PROBLEMA. FUNCIONALIDAD Y EXTENSIONES. .............. 20 ESTRUCTURA DEL FRAMEWORK ........................................................................... 20 CAPA LÓGICA ....................................................................................................... 21 ESTRATEGIA GLOBAL DE EJECUCIÓN ..................................................................... 25 SECUENCIA DE ACCIONES ................................................................................ 25 EJECUCIÓN DE OPERACIONES .......................................................................... 32 2 5. DISEÑO DE LA SOLUCIÓN. DIAGRAMAS DE CLASE DE DISEÑO. ........... 36 CALIMERO ............................................................................................................ 36 ¿QUÉ ES CALIMERO? ....................................................................................... 36 DISEÑO ARQUITECTÓNICO .............................................................................. 36 KNX/EIB ............................................................................................................... 42 ¿QUÉ ES UNA INSTALACIÓN KNX/EIB? ............................................................. 42 ¿QUÉ ES EIBD? ................................................................................................ 42 6. IMPLEMENTACIÓN Y SOLUCIÓN TECNOLÓGICA. ................................. 43 ACTUADORES ....................................................................................................... 43 SENSORES ............................................................................................................ 43 PROPIEDADES ...................................................................................................... 47 7. CONCLUSIONES ....................................................................................... 53 8. REFERENCIAS ............................................................................................ 54 - ARQUITECTURA: CALIMERO ............................................................................ 54 - TENOLOGIA: OSGI ........................................................................................... 54 - DOCUMENTACIÓN TECNICA APORTADA POR EL DSIC ...................................... 54 3 INDICE DE ILUSTRACIONES Ilustración 1 - Framework de OSGi ............................................................................. 13 Ilustración 2 – Ciclo de vida elemental .................................................................... 15 Ilustración 3 – Operaciones con servicios ................................................................. 17 Ilustración 4 – Arquitectura básica de OSGi ............................................................ 23 Ilustración 5 – Estrategia de ejecución en el caso de interfaz WEB ..................... 27 Ilustración 6 – Estrategia de ejecución en el caso de interfaz WEB ..................... 31 Ilustración 7 – Diagrama de flujo de los sensores .................................................... 38 Ilustración 8 – Diagrama de clases de los dispositivos ............................................ 39 Ilustración 9 – Diagrama de clases del túnel ........................................................... 41 Ilustración 10 – Código del driver de la alarma ...................................................... 45 Ilustración 11 – Dirección física de un dispositivo .................................................... 47 Ilustración 12 – Relación Dispositivo– Dirección del dispositivo ............................. 48 Ilustración 13 – Relación Sensor – Tipo de dato del dispositivo ............................. 49 Ilustración 14 – Relación Dispositivo – Identificador ................................................ 51 Ilustración 15 – Relación Actuador – Tipo de dispositivo ........................................ 52 4 1. INTRODUCCIÓN En la actualidad existe mucha tecnología implicada en acciones cotidianas. Hoy en día se puede hacer prácticamente de todo a tiempo real y en cualquier lugar, no hay más que observar la domótica, que pretende que se pueda manejar una casa real mediante dispositivos tecnológicos. Así, y mediante esta idea, podemos manejar por ejemplo la iluminación de toda la casa vía Internet o permitir que la calefacción se encienda y se apague automáticamente en el instante que queramos, entre otros. Pero ¿que motiva a la gente a que se use la domótica? ¿Qué finalidad buscamos a través de la domótica que no pueda ofrecernos otra tecnología? Dentro de las aplicaciones principales de la domótica, encontramos varias que hacen que nos decantemos por esta tecnología para controlar y automatizar lo que denominaremos un hogar digital. Ahorro Energético Una de las principales ventajas del uso de la domótica es el ahorro energético. A pesar de que no sea un aspecto que sea tangible al usuario, es uno de los más importantes, puesto que hoy en día uno de los problemas comunes a todos los seres humanos es la cantidad de energía que se derrocha para vivir en un hogar día a día. 5 Para conseguir este ahorro energético no simplemente basta con sustituir los aparatos o sistemas del hogar por otros que consuman menos sino que también se trata de hacer una gestión eficiente de los mismos, en concreto:  Climatización: programación y zonificación. Se puede programar la climatización del hogar según determinadas zonas (para que no se aireé todo el hogar por completo, sino sólo la zona que deseemos) y/o determinar en qué momentos del día se debe utilizar.  Gestión eléctrica: o Racionalización de cargas eléctricas: desconexión de equipos de uso no prioritario en función del consumo eléctrico en un momento dado. o Gestión de tarifas, derivando el funcionamiento de algunos aparatos a horas de tarifa reducida.  Uso de energías renovables. Confort Otra de las ventajas, no menos importante, es el confort. El uso de la domótica en un hogar digital proporciona adicionalmente un confort en el día a día que facilita que las acciones que se llevan a cabo sean más fáciles. Dichas acciones pueden ser de carácter tanto pasivo, como activo o mixtas, dependiendo de si el usuario interviene en ellas o no:  Iluminación: o Apagado general de todas las luces de la vivienda o Automatización del apagado / encendido en cada punto de luz. 6 o Regulación de la iluminación según el nivel de luminosidad ambiente.  Automatización de todos los distintos sistemas / instalaciones / equipos dotándolos de control eficiente y de fácil manejo.  Integración del portero al teléfono, o del video portero al televisor.  Control vía Internet.  Gestión Multimedia y del ocio electrónicos  Generación de macros y programas de forma sencilla para el usuario. Seguridad La seguridad que proporcionan estas tecnologías es bastante importante. La finalidad que se consigue es proteger tanto los bienes patrimoniales (cualquier elemento de la casa) como la seguridad personal. Esto se consigue gracias a varios elementos:  Alarmas de intrusión (anti intrusión). Se utilizan para detectar o prevenir la presencia de personas extrañas en una vivienda o edificio, en concreto: o Detección de un posible intruso (Detectores volumétricos o perimetrales) o Cierre de persianas puntual y seguro o Simulación de presencia 7  Alarmas de detección de incendios, fugas de gas, escapes de agua, concentración de monóxido en garajes cuando se usan vehículos de combustión.  Alerta médica. Tele asistencia.  Acceso a Cámaras IP Comunicaciones Una de las mayores ventajas que detecta el usuario al utilizar un hogar digital es la cantidad de dispositivos, sistemas o infraestructuras de comunicaciones que posee el hogar. Esto permite, en primer plano, una facilidad de uso y una diversidad de usuarios distintos que pueden utilizar el hogar digital. Entre estos distintos sistemas / dispositivos / infraestructuras encontramos:  Ubicuidad en el control tanto externo como interno, control remoto desde Internet, PC, mandos inalámbricos (p. ej. PDA con WiFi), entre otros.  Tele asistencia  Tele mantenimiento  Informes de consumo y costes  Transmisión de alarmas  Intercomunicaciones 8 Accesibilidad Bajo este epígrafe se incluyen las aplicaciones o instalaciones de control remoto del entorno que favorecen la autonomía personal de personas con limitaciones funcionales, o discapacidad. El concepto "diseño" para todos es un movimiento que pretende crear la sensibilidad necesaria para que al diseñar un producto o servicio se tengan en cuenta las necesidades de todos los posibles usuarios, incluyendo las personas con diferentes capacidades o discapacidades, es decir, favorecer un diseño accesible para la diversidad humana. La inclusión social y la igualdad son términos o conceptos más generalistas y filosóficos. La domótica aplicada a favorecer la accesibilidad es un reto ético y creativo pero sobre todo es la aplicación de la tecnología en el campo más necesario, para suplir limitaciones funcionales de las personas. El objetivo no es que las personas con discapacidad puedan acceder a estas tecnologías, porque las tecnologías en si no son un objetivo, sino un medio. El objetivo de estas tecnologías es favorecer la autonomía personal. Los destinatarios de estas tecnologías son todas las personas, ya que por enfermedad o envejecimiento, todos somos o seremos discapacitados, más pronto o más tarde. 15 CICLO DE VIDA Esta capa dentro del framework es una de las más importantes, puesto que define una serie de estados por los cuales puede pasar cualquier bundle, y que definen la vida del mismo. Estos estados son: instalación, desinstalación, arranque, parada y actualización. El ciclo de vida, así mismo, también permite resolver las dependencias de los módulos de forma dinámica. INSTALADO RESUELTO DESINSTALADO START ACTIVO STOP Ilustración 2 – Ciclo de vida elemental 16 BUNDLES Los bundles son el mecanismo utilizado para distribuir e instalar aplicaciones y servicios en la plataforma. Un bundle es un Archivo Java (JAR) con la parte mínima de una aplicación OSGi, además, tienen un ciclo de vida restringido que es administrado externamente por el framework. El módulo de registro de servicios provee el mecanismo de manejo de los mismos, por eso, un bundle está diseñado para ser un conjunto de servicios que cooperan en el registro de servicios. Además, un bundle puede llevar información descriptiva sobre sí mismo en un archivo llamado manifest. El archivo manifest, normalmente está ubicado en la carpeta META-INF y su nombre debe ser MANIFEST.MF. Este archivo contiene varias etiquetas entre las que cabe destacar las siguientes:  Bundle-Activator: ruta donde se encuentra la clase activator.  Bundle-Name: nombre del servicio.  Bundle-Description: descripción del bundle.  Import-Package: paquetes que necesita para ejecutarse, normalmente se importa: org.osgi.framework. Estas son imprescindibles y debe respetarse el orden en el que se han presentado anteriormente para conseguir que el bundle funcione correctamente. Además, existen otras etiquetas opcionales como pueden ser:  Bundle-vendor: indica el nombre del autor del bundle.  Bundle-version: identifica la versión del bundle. 17 GESTIÓN DE SERVICIOS En concreto, un servicio OSGi se define mediante una interfaz, especificando los métodos públicos e implementándose como un objeto. El bundle es el encargado de registrar el servicio en el Servicio de Registros y así, su funcionalidad estará disponible para otros bundles. En general, los servicios registrados son referenciados mediante el Servicio de Referencia de Objetos para mantener las propiedades y otra meta-información sobre el servicio. En la siguiente figura, puede observarse un ejemplo de cómo registrar un servicio y obtenerlo: Ilustración 3 – Operaciones con servicios 18 1. Registro de servicios. Cuando un método registra un servicio (invocando al método registerService ()) se especifica el nombre de la interfaz que lo implementa y también, es recomendable incluir una descripción utilizando una colección de pares: clave/valor. Por ejemplo, en la figura anterior, el bundle A registra un servicio (serviceobj) junto con un diccionario de propiedades (props). El registro sería: registerService (“Alarm”,serviceobj,props). 2. Obtener servicios. Un bundle puede obtener un servicio OSGi mediante una búsqueda o un evento proporcionado por el framework (Service Listeners). Este último mecanismo, notifica a los bundles automáticamente cuando un servicio ha sido registrado, modificado o desinstalado además, pueden ser filtrados por el oyente. En el ejemplo anterior, el bundle B crea un oyente para obtener información sólo de los servicios de alarma: AddServiceListener (listener,”(objectClass=”+”Alarm”+”)”). De todos modos, se pueden acceder a servicios específicos activando la búsqueda en el Registro de Servicios utilizando el método: getServiceReference () cuyo parámetro de entrada es el nombre de la interfaz que implementa el servicio. Siguiendo el ejemplo anterior, el bundle B puede obtener la referencia del objeto correspondiente al servicio registrado en el bundle A como sigue: ref=getServiceRefenrence(“Alarm”). 19 3. Utilizar servicios. Una vez que el bundle B ha obtenido la referencia del objeto, debe obtener el objeto del servicio para ser capaz de usar los métodos asociados al servicio. En este caso, para el servicio Alarm hay tres métodos disponibles: actvAlarm, setAlarm, deactvAlarm y para invocarlos sería: alarmSrv=getService(ref) alarmSrv.setAlarm(mycode) Por otro lado, el framework de OSGi ofrece la posibilidad de refinar la búsqueda utilizando el método getServiceReferences(), cuyos parámetros de entrada son: 1) El nombre de la interfaz que implementa el servicio. 2) Propiedades de búsqueda. Se especifican mediante un filtro cuya sintaxis está basada en el lenguaje LDAP (Lightweight Directory Access Protocol). Por ejemplo, para obtener un listado con las alarmas sonoras que pertenezcan a la interfaz Alarm, el bundle puede utilizar: Ref=getServiceReferences(“Alarm”,”(type=sounding)”) donde el filtro type=sounding es comparado con el diccionario de propiedades proporcionado en el registro. 20 4. ANÁLISIS DEL PROBLEMA. FUNCIONALIDAD Y EXTENSIONES. El framework implementado utilizando el middleware OSGi proporciona una serie de clases abstractas que deberán ser convenientemente extendidas para obtener una aplicación funcionalmente operativa. Las primitivas que proporciona el framework son similares a las que utiliza en el lenguaje de modelado. El framework para sistemas pervasivos fue diseñado con la intención de servir de soporte a los sistemas especificados utilizando el lenguaje de modelado PervML. Por lo tanto, un objetivo crítico ha sido proporcionar primitivas similares a aquellas utilizadas por el lenguaje. A continuación se describe tanto la estructura como la estrategia global de ejecución del framework. ESTRUCTURA DEL FRAMEWORK El framework se puede estructurar en dos partes bien diferenciadas: el soporte a los elementos de la Capa Lógica (proveedores de enlace, componente e interacciones) y el soporte a las Interfaces de Usuario que se encuentra en la Capa de Interfaz. En este proyecto nos centraremos únicamente en la Capa Lógica, puesto que su desarrollo es uno de los objetivos principales del mismo. 21 CAPA LÓGICA La capa lógica se puede dividir en dos capas: la capa de Comunicaciones y la capa de Servicios. La Capa de Comunicaciones proporciona una representación de los proveedores de enlace (binding providers) que son usados en capas superiores. Esta capa contiene los aspectos de la comunicación con los dispositivos y sistemas software que son independientes de tecnología y fabricante. Por ejemplo, se encarga de registrar los accesos al proveedor de enlace, de notificar los cambios en el driver a todos los elementos de capas superiores que requieran esa información, etc. Por todo ello, existe una relación uno a uno entre los drivers y los elementos de esta capa. La Capa de Servicios se encarga de abstraer la funcionalidad que implementan las capas inferiores para ofrecerla tal y como la esperan los usuarios del sistema. Cada uno de los elementos de esta capa, a los que llamamos componentes, proporciona un tipo de servicio. Para hacer uso de la funcionalidad proporcionada por un tipo de servicio se establece un enlace (definido mediante pre y post condiciones de las operaciones) y un protocolo, que establece las operaciones que pueden invocarse en un momento dado. Para implementar su funcionalidad, un componente puede hacer uso de proveedores de enlace (Binding Providers), dispositivos y sistemas software externos o de otros componentes. Finalmente, en esta capa también se pueden implementar interacciones entre componentes. En este ámbito entendemos una interacción como 22 una secuencia de comunicaciones entre componentes, conceptualmente no relacionados a priori, para proporcionar una funcionalidad requerida por el usuario. Por ejemplo, el usuario puede requerir que cierren las ventanas de una sala cuando se active el aire acondicionado de la misma. Conceptualmente, los servicios de cierre de ventanas y activación del aire acondicionado no están relacionados entre sí pero, en un sistema en concreto, el usuario puede desear establecer una interacción entre ellos. 23 En este ejemplo concreto, tenemos dos dispositivos, como son iluminación y sensor de presencia. Estos dos dispositivos están enlazados con sus proveedores de enlace (Binding Providers) a través de los drivers. Es decir, los proveedores de enlace hacen uso de los drivers para permitir completar SERVICIO DE ILUMINACIÓN SERVICIO DE ILUMINACIÓN POR PRESENCIA SERVICIO DE PRESENCIA COMPONENTE SIMPLE COMPONENTE COMPUESTO COMPONENTE SIMPLE INTERFACE INTERFACE BINDING PROVIDER BINDING PROVIDER DRIVER DRIVER Interfaz Componentes Binding Provider Drivers Ilustración 4 – Arquitectura básica de OSGi 24 su funcionalidad. Un binding provider tiene dos funcionalidades principales: registrar el dispositivo en el sistema, permitiendo hacer referencia a él inequívocamente; y hacer uso de sus funcionalidades mediante los drivers. En el siguiente nivel, las interfaces definen las llamadas básicas a estos Binding Providers , utilizando para ello los métodos que sean necesarios. Por ejemplo, en este caso, la interfaz de la iluminación contendrá las cabeceras de los métodos de encendido y apagado de la luz, mientras que el detector de presencia tendrá los métodos de encendido y apagado del detector de presencia. En el siguiente nivel, los componentes simples lo único que hacen es definir el comportamiento de los métodos definidos en las interfaces. Así, el componente de iluminación dirá qué deben hacer los métodos de encendido y de apagado, mientras que el componente de detección de presencia se encargará de definir el comportamiento de detección de presencia. A este nivel existen los componentes compuestos, que permiten que varios componentes interactúen entre sí. En este ejemplo tendría sentido, por ejemplo, que se encendiera la luz al detectar una presencia y viceversa. Este comportamiento se definiría en estos componentes compuestos. 31 Ilustración 6 – Estrategia de ejecución en el caso de interfaz WEB 32 EJECUCIÓN DE OPERACIONES La estrategia de ejecución de operaciones es una de las partes más importante de la estrategia de ejecución general. Para ejecutar una operación de un Component se realizan los siguientes pasos: 1. Comprobar que es posible ejecutar la operación. Para ello será necesario: a. Comprobar que, desde el estado actual del DTE, está permitido llevar a cabo la operación. A su vez, este paso se puede descomponer en: i. Comprobar que realmente el Component se encuentra en el estado que está almacenado. Para ello se evaluará la fórmula asociada a ese estado. 1. Si no se cumple la fórmula: a. Evaluar las fórmulas de todos los estados del DTE i. Si sólo se cumple una: se actualiza el estado actual ii. Si se cumplen varias: se elige un estado al azar iii. Si no se cumple ninguna: Registrar el error y se detiene la ejecución ii. Comprobar que la operación se encuentra en la lista de operaciones válidas en el estado actual. 1. Si no se encuentra en la lista: se registra el error y se detiene la ejecución. b. Comprobar la precondición. Para ello se evaluará la fórmula asociada. 33 i. Si la fórmula no se satisface: se registra el error y se detiene la ejecución. 2. Deshabilitar la recepción de notificaciones. De este modo la ejecución de las operaciones tiene un carácter atómico. Esto se realiza para evitar comportamiento no deseado y posibles ciclos como consecuencia de la invocación de operaciones en los Binding Providers, los cuales a su vez podrían enviar notificaciones al propio Component. (Por ejemplo, un servicio de Iluminación que debe activar varias bombillas. Al activar una bombilla, esta notificará al Component de un cambio en su estado; lo cual desencadenará una serie de acciones en él (comprobación de disparadores, notificación del Component a otros elementos, etc.) antes de que se hayan activado el resto de bombillas). 3. Realizar las acciones de la operación. Para ello se sigue la siguiente estrategia: a. Conseguir las referencias de los Component o Binding Providers que se utilicen en los siguientes pasos. i. Si no se consiguen todas las referencias: se registra el error y se detiene la ejecución b. Ejecutar las acciones que implementan la operación. i. Si hay alguna excepción: se registra el error y se detiene la ejecución ii. Si hay que devolver un valor, se almacena en la variable returnValue. 34 c. Si hay que devolver un valor: hacer return de la variable returnValue. 4. Activar la recepción de notificaciones. 5. Comprobar que si la operación ha tenido el efecto esperado. Para ello se evaluará la fórmula de la postcondición. a. Si la fórmula se satisface: i. Transitar en el DTE b. Si la fórmula no se satisface: i. Registrar el error. ii. Averiguar el estado del DTE en el que se encuentra el Component. 1. Evaluar las fórmulas de todos los estados del DTE a. Si sólo se cumple una: se actualiza el estado actual b. Si se cumplen varias: se elige un estado al azar c. Si no se cumple ninguna: Registrar el error y se detiene la ejecución 6. Evaluar los disparadores del Component, por si se ha perdido alguna notificación durante el tiempo que se deshabilitaron las notificaciones. 7. Para todas las operaciones que no definen el estado, el Component consulta los resultados de aquellas de sus operaciones que devuelven algún valor (aquellas operaciones como “getIntensity(): int” o “isLighting(): bolean”). a. Si algún valor ha cambiado: 35 i. Almacenamos los nuevos valores. ii. Notificamos del cambio a los Component o Interaction suscritos. 36 5. DISEÑO DE LA SOLUCIÓN. DIAGRAMAS DE CLASE DE DISEÑO. CALIMERO ¿QUÉ ES CALIMERO? Para poder establecer una conexión a una red de dispositivos domóticos se utiliza lo que se conoce como Calimero. Se trata de un conjunto de API‟s desarrolladas en JAVA que facilitan este propósito además del envío como la recepción de datos mediante una conexión EIBNet/IP. EIBnet/IP es un protocolo que permite el acceso a una instalación KNX/EIB mediante una conexión TCP/IP. Este protocolo sencillamente se basa en una serie de preguntas y respuestas HTTP que permiten establecer una comunicación entre los dispositivos. DISEÑO ARQUITECTÓNICO Uniendo las oportunidades que nos brindan tanto Calimero como EIBd (que se explicará en el siguiente punto), se ha desarrollado una API en java que permite el acceso a alto nivel a una instalación domótica. A continuación se van a exponer las principales piezas que componen el túnel.  DISPOSITIVO Se ha incorporado al sistema el concepto de dispositivo y se entiende como un aparato conectado a una instalación (tunnel) y que puede identificarse en esta mediante una dirección (address). Este además, va gestionar un tipo de dato (DataType) y tendrá un nombre único en el sistema (Id), que no en la 37 instalación. Esto quiere decir que en el sistema pueden convivir dos o más dispositivos con idéntica dirección y túnel, pero el Id debe ser único para cada dispositivo. También indicaremos en el dispositivo un perfil que indicará si el dispositivo va a consumir datos (actuador) o a suministrarlos (sensor) al sistema. Para ser más específicos, al dispositivo le indicaremos un tipo de los siguientes:  Sensor  Regulador Porcentual (0‐100)  Regulador Angular (0‐360)  Regulador Hexadecimal (0x00 – 0xFF)  Dispositivos de movimiento vertical (Persianas: Arriba‐Abajo‐Parar)  Dispositivos de tipo pulsador (Timbre)  Dispositivos bi‐estado (Interruptor) Cabe indicar que para los sensores se ha proporcionado una extensión a esta interfaz que nos permite indicarle al sistema cuando deseamos recibir notificación de los valores: siempre que el dispositivo facilite un valor o solo si el valor ha cambiado desde el último que se nos ha notificado. 38 Ilustración 7 – Diagrama de flujo de los sensores 39 Ilustración 8 – Diagrama de clases de los dispositivos 40  TÚNEL El concepto de túnel que manejamos en la arquitectura se refiere al de la pieza que actúa de intermediario entre los dispositivos físicos y su representación en componentes OSGi. Todos los datos que vayan o vengan de la instalación física deberán pasar por el túnel adecuado que actuará a su vez de filtro. Cada túnel se conectará con una y solo una instalación física a la que accederá vía EIBnet/IP comunicándose con un EIBd que estará conectado físicamente a la instalación mediante un cable USB. Además el túnel se identificará con un nombre que será único en el sistema. Todo túnel presente en el sistema podrá actuar de 3 maneras respecto a los dispositivos físicos a que está vinculado:  Solo puede enviar datos (solo controla los actuadores de la instalación). Se registrará solo bajo la interfaz ITunnelWriter  Solo puede recibir datos (solo controla los sensores de la instalación). Se registrará solo bajo la interfaz ITunnelReader  Puede tanto enviar como recibir datos. Los túneles conservarán también una cache que conservará los datos que se envían y reciben del túnel para conservar el último dato. Por otra parte conservarán un histórico con todos los datos enviados y recibidos desde el túnel juntamente con el instante de tiempo en que ha ocurrido el evento. Contará también con una lista de actuadores y sensores asociados. 47 PROPIEDADES  DEVICE_ADDRESS: Dirección lógica del dispositivo. Cada dispositivo tiene una dirección física de 16 bits asociada que le identifica unívocamente. La dirección de un dispositivo además define la localización de éste en la red. Así, cada dirección se divide en área, línea dentro del área, y número de dispositivo, de la siguiente manera: A pesar de esto, las direcciones que se utilizan aquí son las lógicas, denominadas también direcciones de grupo. Todos los dispositivos que tengan la misma dirección de grupo reciben los mismos mensajes. Los sensores sólo pueden enviar telegramas a una dirección de grupo, mientras que los actuadores pueden tener varias direcciones de grupo, lo que les permite reaccionar a distintos sensores. Cualquier dispositivo de la red puede mandar telegramas a una dirección de grupo. Ilustración 11 – Dirección física de un dispositivo 48 Esta dirección tendrá siempre la misma estructura, que en el caso del ejemplo de alarma será 1/1/1 (grupo principal / grupo intermedio / subgrupo). Para el resto de dispositivos, la relación sería la que sigue. DISPOSITIVO DEVICE_ADDRESS Movimiento 1 1/4/7 Movimiento 2 1/4/8 Contacto 1 1/4/4 Contacto 2 1/4/9 Termostato 1/4/1 Luminosidad 1/4/5 Temperatura 1/4/6 Estación Meteorológica – Luminosidad 0/4/1 Estación Meteorológica – Temperatura 0/4/2 Estación Meteorológica – Lluvia 0/4/3 Estación Meteorológica - Viento 0/4/4 Notificación visual 1/0/0 Electroválvula 0/0/10 Bombilla 1 1/0/2 Bombilla 2 1/0/1 Bombilla Gradual 1/0/5 Luz general 0/0/1 Ilustración 12 – Relación Dispositivo– Dirección del dispositivo 49  DEVICE_DATA_TYPE: Aquí se define el tipo de datos que enviará el dispositivo cada vez que se active / desactive. En el caso de todos los actuadores se tratará siempre de un Booleano (activado / desactivado), pero en el caso de los sensores dependerá de cada uno. SENSOR DEVICE_DATA_TYPE Movimiento 1 Booleano Movimiento 2 Booleano Contacto 1 Booleano Contacto 2 Booleano Termostato Flotante (Float) Luminosidad Entero Temperatura Flotante (Float) Estación Meteorológica – Luminosidad Entero Estación Meteorológica – Temperatura Flotante (Float) Estación Meteorológica – Lluvia Booleano Estación Meteorológica - Viento Entero (Velocidad) Ilustración 13 – Relación Sensor – Tipo de dato del dispositivo 50  DEVICE_DESCRIPTION: Aquí se indica una breve descripción del dispositivo en cuestión.  DEVICE_ID: Aquí se indica el identificador de cada dispositivo. En el caso de la alarma es „AS‟, pero para el resto de dispositivos es según se indica en la siguiente tabla. DISPOSITIVO DEVICE_ID Movimiento 1 PD1 Movimiento 2 PD2 Contacto 1 WC1 Contacto 2 DC1 Termostato CT1 Luminosidad BR1 Temperatura CT2 Estación Meteorológica – Luminosidad MS_BRIGHT Estación Meteorológica – Temperatura MS_TEMP Estación Meteorológica – Lluvia MS_RAIN Estación Meteorológica - Viento MS_WIND Notificación visual AL Electroválvula EV Bombilla 1 L1 51 Bombilla 2 L2 Bombilla Gradual DIM Luz general GENERAL  DEVICE_LOCATION: Aquí se indica la localización donde está ubicado el dispositivo. Por defecto, y para todos los dispositivos de este contexto, utilizaremos "DSIC-LAB-103-MAQUETA"  DEVICE_MANUFACTURER: Aquí se indica el creador del driver, en este caso, soy yo.  DEVICE_MODEL: Aquí se indica el modelo del dispositivo. No es significativo para el desarrollo de los drivers.  DEVICE_NAME: Aquí se indica el nombre del dispositivo, en este caso, "Alarma"  DEVICE_PROFILE: Aquí se indica el tipo de dispositivo que es: en el caso de los actuadores se indica mediante „IDevice.DEVICE_PROFILE_EIB_ACTUATOR‟, mientras que si es sensor se indica mediante „IDevice.DEVICE_PROFILE_EIB_SENSOR‟  DEVICE_TUNNEL: Aquí se indica el nombre del túnel que enlaza el PC con los dispositivos físicos, que para todos los dispositivos de este proyecto será "MAQUETA_LAB_103_DSIC" Ilustración 14 – Relación Dispositivo – Identificador 52  DEVICE_TYPE: Aquí se indica el tipo de dispositivo ante el cual nos encontramos. En el caso de los sensores siempre será „IDevice.DEVICE_TYPE_SENSOR‟, pero en el caso de los actuadores dependerá de cada uno, según la tabla siguiente. ACTUADOR DEVICE_TYPE Notificación visual IDevice.DEVICE_TYPE_SWITCH Electroválvula IDevice.DEVICE_TYPE_SWITCH Bombilla 1 IDevice.DEVICE_TYPE_SWITCH Bombilla 2 IDevice.DEVICE_TYPE_SWITCH Bombilla Gradual IDevice.DEVICE_TYPE_SWITCH Luz general IDevice.DEVICE_TYPE_PERCENTUAL_DIMMER  DEVICE_SUBTYPE: Aquí se puede indicar un subtipo de dispositivo. Por defecto los sensores no tendrán, y los actuadores tendrán el valor "ON_OFF"  DEVICE_OTHER_PROPERTIES: Aquí se pueden indicar otras propiedades de interés según el dispositivo. En ninguno de estos dispositivos se gastarán estas propiedades, porque con las que tenemos nos bastan, así que se le asignará un valor vacío mediante „new Hashtable<String, Object>()‟ Ilustración 15 – Relación Actuador – Tipo de dispositivo 53 7. CONCLUSIONES Las conclusiones que se obtienen de este proyecto son positivas, puesto que nunca había estado trabajando con este tipo de arquitecturas, y menos con aplicaciones orientadas a la domótica. A pesar de tratarse de una arquitectura pesada y algo complicada de entender, se ve que se pueden obtener muchos beneficios de esta tecnología. 54 8. REFERENCIAS - ARQUITECTURA: CALIMERO http://calimero.sourceforge.net/ http://eibcontrol.sourceforge.net/ - TENOLOGIA: OSGI http://www.osgi.org http://www.javahispano.org/contenidos/es/manual_de_osgi_por_roberto_mon tero/ - DOCUMENTACIÓN TECNICA APORTADA POR EL DSIC 55