2013 Sistema domótico basado en Android y hardware libre Título de Especialista Universitario en Computación Móvil y Ubicua
Autor: Richard Juan Barberán Director: Javier Campos
Índice
Introducción. ................................................................................................................................. 3 Soluciones actuales....................................................................................................................... 4 Domótica X10. ........................................................................................................................... 5 Domótica inalámbrica. .............................................................................................................. 5 ODAS VS X10 VS ZigBee ............................................................................................................. 6 Sistema ODAS al detalle. .............................................................................................................. 8 Red de sensores. ....................................................................................................................... 8 Control del entorno domótico. ............................................................................................... 10 Funcionamiento de la aplicación. ........................................................................................ 10 Un sistema dinámico y asequible. ........................................................................................... 16 Implementación. ......................................................................................................................... 16 Protocolo de comunicación. .................................................................................................... 17 Visión general. ..................................................................................................................... 17 Estación Base. .......................................................................................................................... 21 Módulos desarrollados. ........................................................................................................... 22 Módulo Interruptor. ............................................................................................................ 22 Módulo Sensor de Movimiento........................................................................................... 23 Aplicación Android. ................................................................................................................. 25 Servicio en backgroud. ........................................................................................................ 25 Interfaz de usuario. ............................................................................................................. 25 Gestión de los módulos. ...................................................................................................... 27 Gestión de las reglas............................................................................................................ 29 Notificaciones. ..................................................................................................................... 30 Gestión de la memoria. ....................................................................................................... 31 Conclusiones. .............................................................................................................................. 31 Bibliografía. ................................................................................................................................. 32
Introducción. Este proyecto trata el desarrollo de un sistema domótico que une dos tecnologías que vienen pegando fuerte en estos últimos años: la tecnología móvil y el hardware libre. El sistema, bautizado como ODAS, pretende crear un entorno domótico que basa el hardware de sus distintos componentes en Arduino, referencia del hardware libre, y utilizar la tecnología móvil, en concreto Android, para que el usuario interactúe con el sistema. El nombre ODAS nace de la unión de las palabras que definen su esencia, como veremos en la imagen siguiente y es más que una simple aplicación para encender o apagar una luz. ODAS es un sistema modular de bajo coste diseñado específicamente para poder ser ampliado y configurado por el propio usuario cuando y donde quiera.
Figura 1: Representación del origen del nombre ODAS. La manera con la que el usuario final del sistema interactúe con los dispositivos y sensores es de vital importancia para el éxito del proyecto, por esto, se ha desarrollado una aplicación móvil Android que servirá a los habitantes de una casa o trabajadores de una oficina, por dar ejemplos, controlar de manera remota el sistema con una interfaz amigable en un dispositivo que utiliza todos los días. Además de una interfaz amigable y fácil de usar para el usuario el éxito de un sistema de éstas características radica en la usabilidad. Es poco práctico y atractivo un sistema en el que vengan predefinidos el número de módulos o sea costoso y caro ampliar o modificar la red de sensores y actuadores del entorno domótico. Por esto el trabajo realizado se centra en el diseño de un sistema adaptable por el usuario en el que agregar elementos a la red de sensores sea una tarea simple y barata para el propietario. El sistema a presentar consiste en un conjunto de dispositivos compuesto por una estación base y dos módulos inalámbricos además de una aplicación de monitorización y control basada en el sistema operativo Android capaz de controlar el sistema desarrollado. La estación base, se conectará al router wifi de la casa donde se monte el sistema y creara un elemento servidor en la red. Éste dispositivo será el que controlará directamente los módulos y sensores del sistema domótico a través de transmisiones vía radio frecuencia.
Como primeros dispositivos desarrollados para el entorno domótico se ha pensado en un módulo sensor de movimiento y un módulo actuador que funcione a modo de interruptor remoto para dispositivos que conectamos a la red eléctrica común en nuestras casas. Debido a la importancia que cobra la usabilidad y funcionalidad del panel de control del sistema para el usuario, en la etapa de definición de requerimientos de la aplicación móvil se establecieron unos objetivos que se han ido cumpliendo durante el desarrollo del sistema prototipo y que describiremos a lo largo de éste documento. Los objetivos planificados para el sistema desarrollado son los siguientes: -
-
Controlar el dispositivo interruptor con dos estados: encendido y apagado. Aviso de detección con notificaciones por parte del sensor de movimiento. Sistema modular configurable por el usuario. El usuario debe de poder añadir/quitar módulos del sistema desde la aplicación. La aplicación se ajustará dinámicamente de acuerdo al número de dispositivos instalados. Aunque sólo se presenten dos tipos de módulos para el trabajo, la aplicación contemplará la posibilidad de incrementar el abanico de dispositivos aceptados por el sistema en un futuro. Acciones propias para cada uno de los dispositivos. Esto es la posibilidad de definir reglas o acciones desde la aplicación y que los diferentes módulos se relacionen entre ellos si existe dicha posibilidad o se comporten de una manera determinada. Esto es por ejemplo, la posibilidad de relacionar un módulo de detección de movimiento con un módulo actuador, como puede ser el módulo que se presentara (on/off). De ésta manera se podrá encender un módulo actuador cuando se detecte movimiento en el sensor de movimiento.
Soluciones actuales. La domótica hoy día convierte nuestros hogares en algo más que un refugio, los convierte en algo vivo a través de sistemas de climatización, control sobre luces y persianas, seguridad, y todo tipo de sistemas que en la actualidad son capaces de interrelacionarse entre ellos. El ritmo de vida actual ha provocado un cambio inmenso en la sociedad con las Tecnologías de Comunicación que crecen a un ritmo vertiginoso y es por esto que la integración de estas nuevas tecnologías en la vivienda se convierte en algo necesario. Pero lo que hace que cada vez más busquemos una vivienda tecnológicamente superior es que todos aspiramos a una mejor calidad de vida y parece lógico que esto se refleje en el entorno más importante y cercano, nuestro hogar. Esta tendencia a integrar medios informáticos, de automatización y de nuevas tecnologías de comunicación, junto a la necesidad de establecer planes de ahorro energético en nuestros hogares, provoca como es natural, una creciente aparición de nuevas empresas que ofrecen nuevos sistemas domóticos más avanzados y a precios más competitivos. Si bien es cierto que el sector tecnológico de la domótica está en continuo crecimiento, también lo es que se ha visto ralentizado desde que estalló la burbuja inmobiliaria. Con la crisis, la instalación de robótica para el hogar en inmuebles españoles usados pasó de suponer el 15% del sector en 2005 al 36% en el 2011. Principalmente las soluciones actuales se basan en tres medios de comunicación: a través de la propia red eléctrica de la casa (corrientes portadoras), a través de cableado especializado para el entorno domótico y a través de medios inalámbricos. Vamos a centrarnos en los casos primero y segundo y dejaremos de lado los sistemas que requieran instalación de cableado para la domótica de la casa. Estos sistemas por norma general son muy caros y difíciles de ampliar o personalizar además
de estar destinados a viviendas de obra nueva. Como se ha pretendido diseñar un sistema que el mismo usuario pueda instalar y configurar y que sea de bajo coste, compararemos nuestra solución con los sistemas basados en portadora y en los sistemas inalámbricos. Para posicionar el sistema desarrollado en un sector del mercado domótico, vamos a comparar nuestro sistema con dos alternativas actuales en entornos domóticos económicos y de fácil instalación. Debido a que hemos diseñado y construido el sistema en unas escasas 6 semanas no podemos equiparar nuestro sistema a otro comercial, así que daremos una visión de la comparación más general y compararemos con algo más de detalle los módulos que hemos diseñado con otras alternativas comerciales.
Domótica X10. La Historia de la domótica la inició X10 en 1975, creado para el telecontrol y basado en corrientes portadoras o Power Line(PL). Este sistema de protocolo estándar se extendió mucho por Estados Unidos y en Europa (sobretodo Reino Unido y España). A diferencia de los sistemas basados en módulos inalámbricos, los sistemas basados en X-10 utilizan la red eléctrica para intercomunicar los diferentes módulos agregados al sistema. La sencillez y sobretodo la accesibilidad al protocolo, derivó en multitud de aplicaciones (software y hardware), una variada red de distribución, e incluso a través de internet se sigue vendiendo mucho, así como la creación de marcas con productos X10 (DiLArtec) que pasaron a instalarse de forma masiva en grandes promociones inmobiliarias. En la actualidad se siguen creando empresas alrededor de X10, y el bajo coste de producción a los que nos tienen acostumbrados los países asiáticos como China, hacen de este el sistema el más utilizado en los dispositivos plug&play vendidos por internet. Ventajas. •
Es el sistema más extendido y utilizado en todo el mundo. Esto hace que en la actualidad se sigan creando empresas que utilicen X10 en sus productos. Además de su expansión, la simplicidad de su uso ha provocado que aparezcan productos desde el mercado Chino a muy bajo coste.
Inconvenientes. • •
El principal problema de X10 está en la base de su funcionamiento, usando las corrientes portadoras para transmitir la señal, esta depende directamente de la calidad con que llegue a nuestros hogares y por tanto es muy vulnerable a las frecuentes alteraciones de la misma. A través de éste sistema solo se pueden controlar módulos con regulaciones sencillas de tipo ON/OFF y similares, lo que implica utilizar otro sistema de transmisión para comunicaciones más complejas.
Domótica inalámbrica. Con la llegada al mercado de nuevos estándares inalámbricos como ZigBee muchas empresas domóticas han visto el momento de adaptar sus productos a la comunicación sin cables. Zigbee fue creado por la Zigbee Alliance, un gran grupo de empresas que apoyaron el desarrollo de ésta tecnología, para hacer evolucionar las redes de sensores/actuadores en un mercado en el que
predomina la necesidad de un sistema a bajo coste. ZigBee, es el estándar llamado a ser referencia en la domótica inalámbrica por su bajo consumo, seguridad y fiabilidad. Ventajas. • • •
Sencillez del protocolo de transmisión. Un consumo extremadamente bajo. Es posible alimentar un módulo con dos pilas AA de 6 meses a 2 años. Capacidad de formar redes de sensores en diferentes configuraciones: en estrella, bus&idots, MESH, etc.
Inconvenientes. •
Aunque ZigBee es un estándar abierto no existe una definición completa y específica de cómo desarrollar la comunicación de los productos que una empresa fabrica. Esto implica que diferentes productos de diferentes empresas que utilicen ZigBee no tienen por qué ser compatible entre ellos, como ocurre con X10.
ODAS VS X10 VS ZigBee Al igual que los sistemas basados en ZigBee, el sistema que hemos desarrollado utiliza como medio de comunicación las transmisiones inalámbricas. Aunque ZigBee permita construir módulos de bajo coste en comparación con las alternativas que necesitan instalación previa, el precio de un sistema basado en ZigBee sigue siendo algo elevado para los hogares de familias de un poder adquisitivo medio y más aún teniendo en cuenta la recesión económica que está provocando la actual crisis. La solución que hemos propuesto utiliza módulos desarrollados con hardware libre y esto implica una alternativa a ZigBee con un abaratamiento aún mayor de los costes de producción además de una aceleración en el ciclo de desarrollo y producción de nuevos dispositivos. Además de la ventaja de trabajar con hardware libre, una importante mejora es la de utilizar los dispositivos móviles como medio de control del sistema. Hasta hace unos años la única manera de controlar el entorno domótico era a través de mandos y paneles lcd o tft específicos que encarecían el sistema y añadían más complejidad para su control. Ahora, con la evolución que han sufrido los dispositivos móviles las compañías empiezan a ver una ventaja en integrar los dispositivos móviles en los sistemas domóticos. El sistema desarrollado para el proyecto implementa el control del sistema en una aplicación Android añadiendo facilidad de uso y un abaratamiento del sistema de cara al usuario final. Ventajas del sistema ODAS. • • • •
Sistema con un coste económico menor. Control del sistema mediante una app para dispositivos Android. Proceso de diseño y desarrollo de nuevos módulos más fácil y rápido que en otros sistemas al estar basado en hardware libre. Fácil instalación y ampliación del entorno domótico. El usuario mismo puede realizar la instalación.
Desventajas. • • •
La comunicación no está basada en un estándar, con lo que los productos de otras empresas no son compatibles. Se trata de un sistema todavía muy inmaduro, con poco tiempo de desarrollo y pruebas. Inconvenientes asociados a los sistemas inalámbricos. Interferencia en las comunicaciones, comunica paquetes perdidos, etc.
Comparativa de los diferentes elementos del sistema con alternativas actuales: Sensor de Movimiento:
Precio
DomoDesk(X10)
Tenealive (ZigBee)
ODAS
48.34€
76.37€
6.5€*
Interruptor ON/OFF:
Precio
DomoDesk( DomoDesk(X10)
Tenealive (ZigBee)
ODAS
60.44€
89.69€
6.5€* €*
Mandos de control: DomoDesk(X10)
Pantalla Táctil Inalámbrica
ODAS
907.50€
22€*
+ Receptor Precio
108.90€ + 31.08€
*Los precios asociados a los dispositivos son el coste aproximado del material utilizado para fabricarlos y no incluyen mano de obra, ni otros gastos. De la misma manera no se ha contabilizado ningún coste asociado a la app Android del sistema.
Sistema ODAS al detalle. El sistema domótico que hemos diseñado consta de 3 partes: La estación base o receptor, los módulos y sensores y por último la aplicación de control del entorno. En éste capítulo vamos a ver en detalle el funcionamiento del sistema y de la aplicación desarrollada para entender en qué consiste instalar en una casa, tienda u oficina el sistema domótico ODAS. Posteriormente, en el siguiente capítulo describiremos el proceso de implementación del sistema sin entrar en demasiados detalles en la fabricación de los dispositivos para no extender demasiado el documento.
Red de sensores. En un entorno domótico inalámbrico, es muy importante tener en cuenta el alcance de la conexión entre los módulos y la base, pues de este depende el buen funcionamiento del sistema, por esto que el sistema ODAS implementa una red de sensores de tipo arbol. En una red de tipo árbol, los nodos pueden enviar o recibir información tan solo de sus nodos hijos o de su nodo padre. Esto hace necesario que solo los nodos que no tienen descendientes o hijos puedan ser desconectados del sistema sin que la red quede dividida en diferentes partes sin posibilidad de interconexión. Las redes de tipo árbol, son redes en las cuales dos nodos se pueden comunicar aunque no estén dentro del alcance uno de otro. Esto es posible porque cuando un nodo envía un mensaje hacia un destinatario éste sigue un camino atravesando diferentes nodos de la red hasta llegar a su objetivo. Este tipo de redes posibilitan ampliar el área de distribución de la red de módulos en una casa aunque haya módulos fuera del alcance de otros o de incluso la estación base. Mientras todo nodo esté en el radio de alcance de sus nodo padre y descendientes podrá recibir o enviar información a cualquier nodo de la red. Veamos un ejemplo:
Figura 2: Ejemplo de red en tipología arbol. En la imagen tenemos una red de sensores organizados en una tipología árbol en la cual se dan dos casos de comunicación. En uno de los casos el módulo hoja A envía un mensaje al módulo B y para ello el mensaje se encamina a través de diferentes módulos hasta llegar al destino. En el otro caso el módulo C envía un mensaje al módulo D, descendiente de su módulo hermano y para ello el mensaje atraviesa dos módulos intermedios. Como se puede apreciar, en la raíz del árbol tenemos la base receptora del sistema, la cual hace de puente entre los sensores y el usuario. Cuando la base es conectada al router wifi de la casa, ésta se convierte en un servidor local al que la app del dispositivo móvil envía los mensajes para retransmitirlos hacia los módulos repartidos por la casa. La base o estación, se ha implementado pensando en un sistema escalable en el que podamos añadir nuevos módulos, es por esto que la base no guarda información relativa al tipo de los módulos ni interpreta sus mensajes. Esto permite que podamos instalar módulos diseñados a posteriori sin actualizar el software de la base. Sólo el propio módulo y la app conocen e interpretan la funcionalidad de cada módulo. Para poner en funcionamiento el sistema por primera vez, basta con conectar la base al router wifi de la casa e ir poniendo en funcionamiento los módulos. Cuando un módulo nuevo es encendido, este entra en un modo de descubrimiento y envía periódicamente un mensaje que contiene su dirección lógica establecida en el firmware del dispositivo. Cuando la base recibe este mensaje de descubrimiento, guarda la dirección del módulo y responde con un reconocimiento que indica que ya está enlazado al sistema para que pare de transmitir. De esta manera módulo a módulo se van enlazando los dispositivos a la base y se va estableciendo la topología de árbol, primero la base, luego sus descendientes y así hasta completar la red domótica. Cuando un módulo está enlazado al sistema ya es capaz de enviar o recibir mensajes a través de la red.
Cuando el conjunto de módulos ya están colocados y enlazados con la base, cualquier mensaje enviado desde un nodo a otro atravesará los nodos intermedios y será retransmitido hasta llegar a su destino. Así cuando base recibe un mensaje para actuar sobre alguno de los módulo, la orden se va encaminando desde la raíz hasta llegar al módulo destino. Éste tipo de redes ofrecen la ventaja de que pueden ocupar mayores espacios, sin embargo y como ya hemos dicho, requiere que algunos de los nodos estén siempre en funcionamiento para que no queden dos zonas de la red aisladas. En nuestro caso, debido a las características hardware del módulo inalámbrico utilizado, cada módulo puede comunicarse directamente con 5 descendientes y con su módulo padre. De ésta manera podríamos organizar una red de 31 nodos en tan solo 2 niveles como muestra la siguiente imagen:
Figura 3: Ejemplo de red en tipología árbol con 31 nodos.
Control del entorno domótico. El tener la posibilidad de controlar el entorno domótico a través de un medio tan utilizado por el usuario como es su propio Smartphone o una tablet es un valor seguro que agradará a un futuro cliente, y no sólo por el ahorro en la factura sino por la simplicidad y la facilidad en el aprendizaje, mucho mayor en un dispositivo que se utiliza con regularidad. Para el control de los módulos fabricados se ha diseñado una aplicación para dispositivos Android que a través de una interfaz intuitiva y atrayente permitirá al usuario no sólo el control de los dispositivos sino programar el sistema para que los módulos interactúen entre ellos de cierta manera. Funcionamiento de la aplicación. Cuando ejecutamos la aplicación nos encontramos en la pantalla Home, donde tenemos acceso a las diferentes secciones en las cuales se organizarán los módulos de la red domótica. La navegación a través de la app es muy simple y consta en todo momento de un menú superior para acceder a las diferentes pantallas a las que podemos acceder: Home, Reglas, Ajustes y Acerca de. Home. La sección Home es la principal de la aplicación y en ella encontramos un menú central en el cual podemos acceder a las diferentes secciones en las que se dividen los módulos instalados en el
sistema. Para mejorar la simplicidad de la aplicación se han dividido los módulos en sólo 5 categorías: Iluminación, Clima, Persianas, Seguridad y Jardín. Por ejemplo en la sección Iluminación, encontraríamos los módulos de iluminación, tiras de leds RGB, de tipo ON/OFF, etc., o en la de Seguridad módulos sensores de movimiento, cámaras IP, detectores de puertas abiertas, etc. En la parte superior izquierda encontramos un indicador que nos informa de los nuevos módulos enlazados en la base, que ya forman parte de la red domótica pero que todavía no están instalados en la aplicación. De la misma manera, en la parte superior encontramos dos botones que nos proporcionan un acceso más directo a las secciones de Reglas y Ajustes de la aplicación, que como recordaremos, también podemos acceder a través del menú superior de la barra de tareas.
Figura 4: Detalle del Home de la aplicación.
Secciones. Cuando pulsamos algún bobón del menú central para acceder a los módulos de determinada clasificación (Iluminación, Clima, Persianas, Jardín o Seguridad) nos trasladamos a una nueva pantalla en la que encontraremos una lista que clasifica los diferentes módulos instalados en diferentes zonas creadas y administradas por el usuario.
Figura 5: Detalle de diferentes tipos de módulos.
En la primera imagen anterior podemos ver como 3 módulos de tipo Interruptor están repartidos en 2 zonas diferentes creadas por el usuario. Como es lógico dependiendo del tipo de módulo se mostraran unos controles diferentes para cada caso. Como ejemplos tenemos que para un módulo Interruptor como en la imagen, un botón de On/Off nos permite encender o apagar el dispositivo, o que en un sensor de movimiento tenemos un checkbox para permitir o no las notificaciones cuando el módulo haya detectado movimiento en el sensor. Cuando un módulo muestra una lista de Reglas asociadas como en el sensor de movimiento “Sensor cocina” de la imagen derecha superior, significa que el módulo en cuestión es partícipe de una o más reglas que lo relacionan con otros módulos. En el ejemplo, la primera regla indica que el sensor de movimiento “Sensor cocina” activa, cuando detecta presencia, al módulo interruptor “luz mesa”. Con los botones situados en la barra inferior podemos crear una nueva zona o insertar un nuevo módulo a la sección. Cuando pulsemos el botón para añadir un nuevo módulo aparecerá un diálogo con una lista de los nuevos módulos agregados al sistema y que por su tipo se corresponda con la sección en la que nos encontramos. Por ejemplo, en la sección Iluminación nunca tendremos la posibilidad de insertar un módulo detector de movimiento. Una vez creados lo módulos podemos acceder a ciertas acciones como añadir una nueva regla sobre otro módulo, borrar el módulo o editar sus atributos con tan solo hacer una pulsación larga sobre el módulo.
Figura 6: Detalle del menú emergente con una pulsación larga.
Con el botón superior de la barra de acciones de la sección Iluminación, tenemos la posibilidad de encender o apagar todos los módulos de la sección que sean compatibles con ésta acción. Reglas. En la sección de reglas encontramos un listado con todas las reglas añadidas al sistema. Las reglas, como ya hemos dicho, agregan interrelaciones entre los módulos del sistema. Para eliminar una regla basta con hacer una pulsación larga sobre la regla en cuestión y seleccionar la opción de borrado en el menú emergente.
Figura 7: Detalle de la sección dedicada a las reglas del sistema.
Ajustes. Como el prototipo desarrollado todavía no tiene demasiadas opciones de configuración, en la actualidad la pantalla de Ajustes permite pocos cambios sobre la aplicación. Por el momento la IP asignada a la estación base al ser conectada al router wifi de la casa es fija, siendo siempre la misma, pero en un futuro podría ser configurable y por esto desde ajustes podremos cambiar la IP de la base a la que encaminar los mensajes o órdenes desde la app. En lo que refiere a la memoria tenemos dos botones que nos permiten por una parte borrar de manera íntegra la memoria de la app (módulos instalados y reglas) y por otra simular la llegada de nuevos dispositivos al sistema. Ésta simulación de dispositivos va destinada a los profesores de la aplicación para que puedan probar la aplicación sin disponer del conjunto de dispositivos.
Figura 8: Detalle de la sección Ajustes.
Acerca de. En último lugar, tenemos una página “Acerca de” con información sobre la aplicación donde encontraremos información sobre la versión de la app, el autor del proyecto, un email de soporte y una breve descripción del sistema domótico ODAS.
Figura 9: Detalle de la página de información “Acerca de”.
Un sistema dinámico y asequible. Una de las principales características del sistema domótico que se ha desarrollado es que el usuario puede instalar y ampliar cuantas veces quiera el sistema. La estación base no contiene información de cómo tratar o interpretar la información de proviene de los módulos o los mensajes que se mandan a éstos desde la app. El abstraer la base receptora de esta tarea nos proporciona la posibilidad de añadir al entorno nuevos módulos diseñados a posteriori de la base con una simple actualización de la app. Tan solo los propios módulos y la aplicación Android conocen e interpretan las características y posibilidades de los diferentes dispositivos de la red dejando a la base las tareas de enlace entre app y red inalámbrica y la gestión de reglas del sistema. Esta modularidad del sistema da la posibilidad al usuario de ampliar y adaptar el sistema a su gusto sin ningún tipo de instalación física que encarezca la inversión. Esto, junto al diseño basado en hardware libre, hace que nos encontremos ante un sistema realmente económico y asequible para cualquier bolsillo. Pongamos como ejemplo el prototipo desarrollado para el proyecto, que constando de una base receptora, un sensor de movimiento y un módulo interruptor ha tenido un coste económico total de unos 30€, cifra realmente baja teniendo en cuenta los costes de alternativas actuales, como hemos podido apreciar en la comparación establecida en capítulos anteriores.
Implementación. Desde el inicio del proyecto se ha estado definido por varias etapas que se han ido cumpliendo conforme los dispositivos y la aplicación han ido tomando forma. Hemos pasado de tener un conjunto de placas de hardware libre compradas a china a un sistema domótico con varios módulos funcionales y una aplicación de control simple y con un cuidado diseño.
Figura 10: Imágenes de algunos de los componentes al inicio del proyecto y los dispositivos terminados al finalizar.
En las siguientes secciones veremos los puntos clave en la implementación que nos han permitido transformar un poco de material y unas ideas en el sistema domótico ODAS.
Protocolo de comunicación. Visión general. La comunicación entre los distintos elementos del sistema está basada en dos redes inalámbricas, una Wifi y otra radio frecuencia. La base domótica es la clave para comunicar los distintos sensores y actuadores del sistema domótico entre ellos y poder ser comandados desde el propio Smartphone, ya que ejerce la función de conectar entre sí las dos redes inalámbricas. Veamos el sistema de forma general.
Router wifi
Base domótica idTipo dispositivo: 0 dirección física: 0 ip: 192.168.1.160
Dispositivo Interruptor idTipo dispositivo: 2 dirección física: 2
Sensor de Movimiento idTipo dispositivo: 1 dirección física: 1 Smartphone/tablet ip: 192.168.1.11
Figura 11: Visión global del sistema domótico y dispositivo de control.
Comunicación entre la base y los módulos.
Base domótica idTipo dispositivo: 0 dirección física: 0 ip: 192.168.1.160
Dispositivo Interruptor idTipo dispositivo: 2 dirección física: 2
Figura 12: Representación de la comunicación módulo-base receptora.
Cada módulo agregado al sistema, incluida la base, disponen de una dirección física que los identifica. A nivel de hardware es necesaria ésta dirección para que los módulos inalámbricos direccionen los paquetes que enviemos a través de la red rf. La comunicación entre los sensores o actuadores y la base, se realiza mandando por la red un paquete que contiene una estructura de datos compuesta por varios campos: Tipo de Módulo: Identificador propio del tipo de módulo que envía el mensaje. Dirección del módulo: Dirección que tiene asignada el módulo remitente del mensaje en la red. Tipo de Orden: Identificador del tipo de orden que se está mandando. Contenido: Información que el destinatario interpretará de acuerdo a su tipo y orden. Esta estructura será la que se empaquetará y enviará a través de la red inalámbrica, en cualquiera de los sentidos: base a módulo, módulo a módulo o modulo a base.
Envío de información del dispositivo móvil a la base.
Router wifi
Smartphone/tablet ip: 192.168.1.11
Base domótica idTipo dispositivo: 0 dirección física: 0 ip: 192.168.1.160
Figura 13: Representación de la comunicación móvil-base.
Como hemos dicho anteriormente, cuando conectamos la base al router wifi de la casa, ésta toma el rol de servidor HTTP. La base es el enlace entre la aplicación de control y los módulos, y por éste motivo, no ejerce ninguna funcionalidad directa con los módulos, nada más que la de retransmitir los mensajes que se reciben desde la app y viceversa. Conocida la ip asignada a la base, la comunicación a través de la red wifi consiste en el envío de mensajes con distintos parámetros que la base identificará y actuará en consecuencia. Desde la app, la comunicación con la base se realiza con una conexión http con la ip de la base y adjuntando el mensaje de la siguiente forma: http://192.168.1.160/SmensajeE, donde mensaje es una trama delimitada por los caracteres de inicio ‘S’ y final ‘E’. Los campos encapsulados en dicho mensaje y separados por ‘;’ son:
• •
idMensaje: Identificador del mensaje para la base. campos: Subtrama compuesta por otros campos. Normalmente éste campo estará destinado exclusivamente para el módulo destinatario del mensaje y no la base. Esta subtrama contiene los siguientes campos: o tipoMod: Identificador del tipo demódulo al que va dirigido el mensaje. o Dirección: Dirección del módulo al que va dirigido el mensaje. o idOrden: Identificiador de la orden que recibirá el módulo. o contenido: Información necesaria para la ejecución de la orden.
Así, tenemos que un ejemplo de mensaje que podría enviar la app en reacción a un evento producido por el usuario podría ser el siguiente: http://192.168.1.160/S1;2:5:0:1E •
con esto tendíamos que:
mensaje: 1;2:5:0:1 • idMensaje: 1 • campos: 2:5:0:1 • tipoMod: 2 • dirección: 5 • idOrden: 0 • contenido: “1”
Este mensaje indicaría a la base que la subtrama “campos” tiene que ser reenviada al módulo de tipo ‘2’ (Módulo interruptor) con dirección destino ‘5’ para que ejecute la orden ‘0’ con valor “1” (Activación o modo ON del interruptor).
Envío de información de la base al dispositivo móvil.
Router wifi
Base domótica idTipo dispositivo: 0 dirección física: 0 ip: 192.168.1.160
Smartphone/tablet ip: 192.168.1.11
Figura 14: Representación de la comunicación base-móvil.
La recepción de información en la aplicación Android se basa en un Servicio que implementa un servidor para capturar la entrada de datos a través de la red por el socket 8080. Para enviar un
mensaje a la app, ya sea un mensaje que proviene de alguno de los módulos del sistema o como respuesta a una petición se envía a través del puerto indicado y la ip asignada al dispositivo móvil y es el Servicio el que recibe y procesa esta información. Cuando el servicio recibe un mensaje se descompone en sus diferentes campos y dependiendo de la razón del mensaje se actúa en consecuencia. Los mensajes enviados por la base hacia la aplicación contienen una trama delimitada por los caracteres de inicio ‘<’ y fin ‘>’ que encapsula varios parámetros. Veámoslos: <idMensaje;campos> Donde: • •
idMensaje: Identificador del mensaje recibido. De acuerdo al identificador se ejecutará una orden u otra. campos: Campo de datos del mensaje, puede contener desde a lista de dispositivos instalados en el sistema a una subtrama con los diferentes parámetros que identifiquen al módulo emisor del mensaje y la información que esté transmitiendo. En los casos anteriores: o Si se recibe lista de módulos: campos = &x1:y1&x2:y2…&xn:yn, donde x denota el tipo de módulo e y su dirección física en la red de sensores. o
Si se recibe mensaje de módulo: campos = tipoMod:dirMod:idOrden:contenido Donde:
tipoMod: id del tipo del módulo que manda el mensaje. dirMod: dirección del módulo, utilizada para su identificación. idOrden: identificador de la orden que manda el módulo. contenido: información necesaria para ejecutar la orden.
De ésta manera unos ejemplos de mensaje recibido en la aplicación podrían ser:
<0;&1:10&1:15:&2:8> : Este mensaje recibido con identificador ‘0’ (Lista de módulos) contiene la lista de los módulos enlazados a la base. Dos módulos de tipo ‘1’ (Sensor de Movimiento) con direcciones ‘10’ y ‘15’ respectivamente y un módulo de tipo ‘2’ (Interruptor) de dirección 8. <1;2:5:0:1> : Este mensaje recibido con identificador ‘1’ (Mensaje de módulo) contiene información que indica que el módulo de tipo ‘2’ (Sensor de movimiento) y dirección ‘5’ envía la orden de tipo ‘0’ (Evento del sensor) y contenido ‘1’ que significa que ha habido una detección en dicho sensor.
Estación Base. Para no extender el documento con documentación innecesaria, no entraremos en detalles de cómo se han fabricado los dispositivos, sino que daremos una visión general del funcionamiento de los mismos. Como ya sabemos, los dispositivos están hechos utilizando placas Arduino, clones chinos de éstas, para ser más exactos, y sensores electrónicos de bajo coste. La base está compuesta por dos módulos trabajando en serie. El primer de los módulos trabaja como servidor Http y está compuesto por un Arduino Mega junto con una placa Ethernet y una pequeña pantalla lcd y el segundo módulo está compuesto por un Arduino Pro Mini junto con un transmisor/receptor radio frecuencia. La función de este segundo módulo es simplemente la de ejercer de pasarela entre el servidor Http y la red inalámbrica de sensores/actuadores. La funcionalidad de la estación base queda reflejada en el siguiente diagrama de flujo, donde podemos ver la ejecución realizada por el algoritmo implementado en la placa Arduino Mega.
Figura 15: Diagrama de flujo del algoritmo ejecutado por la base receptora.
No vamos a extendernos más en el funcionamiento de la base, pues queda totalmente reflejado con el anterior diagrama.
Módulos desarrollados. De la misma manera que hemos hecho con la estación receptora, vamos a presentar de manera superficial cómo se han implementado los dos módulos y describir el algoritmo que ejecutan a través de unos diagramas de flujo, pues son la mejor manera de explicar el algoritmo al detalle sin extender ni complicar la comprensión del texto. Módulo Interruptor. El módulo está compuesto por un Arduino Pro Mini junto con uno de los transmisores RF integrados dentro de una regleta para de ésta manera controlar el paso de corriente desde la aplicación android. Para abrir o cerrar el paso de corriente en la regleta al conectarla a la red eléctrica de la casa se un relé conectado con el arduino. De ésta manera cuando el módulo recibe el mensaje de abrir o cerrar la corriente la placa arduino actúa directamente sobre el relé. Para alimentar el circuito Arduino-RF dentro de la regleta se ha integrado en el interior de la regleta también un transformador a 5V de los que se utilizan en los cargadores de móvil. Veamos unas imágenes del módulo acabado y con el módulo Arduino_RF instalado dentro de la regleta.
Figura 16: Imagen del dispositivo Interruptor ya finalizado.
El algoritmo que ejecuta el dispositivo se corresponde con el siguiente diagrama de flujo.
Figura 17: Diagrama de flujo del algoritmo ejecutado por el módulo interruptor.
Módulo Sensor de Movimiento. De la misma manera que el módulo interruptor la parte principal de éste módulo está compuesta por un Arduino Pro Mini junto con un transmisor RF pero en éste caso integramos también en el diseño un sensor de presencia PIR de bajo coste capaz de detectar movimiento en una distancia de hasta 7 metros. Para la alimentación del módulo se utiliza un cargador de móvil que no es más que un transformador de corriente a 5V. Veamos unas imágenes del sensor durante el desarrollo del proyecto y una vez finalizado el módulo.
Figura 18: Imagen del m贸dulo sensor de movimiento. El algoritmo implementado que ejecuta el micro de la placa arduino es el siguiente, y viene presentado en un diagrama de flujo, como en las secciones anteriores.
Figura 19: Diagrama de flujo del algoritmo ejecutado por el m贸dulo sensor de movimiento.
Aplicación Android. La aplicación diseñada para el control del sistema domótico está compuesta por dos partes que se complementan para ofrecer al usuario una experiencia sencilla e intuitiva en el control del entorno domótico. Una de éstas partes o sección de la aplicación corresponde a la aplicación que interactúa con el usuario para el control de los módulos y de la que se explica el funcionamiento en capítulos anteriores, la otra parte es un servicio que se encuentra en continua ejecución para recibir los datos enviados desde la base a través de la red wifi y poder por ejemplo, notificar al usuario ante cualquier evento ocurrido en alguno de los sensores. Servicio en backgroud. Para el correcto funcionamiento de la aplicación, un servicio se ejecutará en segundo plano esté abierta o no la aplicación. El servicio es el encargado de recibir los mensajes que llegan al dispositivo móvil y notificar de su llegada a la aplicación en el caso de que esté abierta. La principal ventaja de utilizar un hilo de ejecución en segundo plano que recoja los mensajes enviados por la estación receptora es que podemos notificar al usuario de eventos acontecidos en los módulos domóticos sin que la aplicación de control permanezca abierta. El algoritmo ejecuta un hilo de manera indefinida que mantiene un ServerSocket escuchando por el puerto 8080 de manera que cuando la base abre una conexión con la aplicación a través de éste puerto queda abierto un canal por donde transmitir los mensajes. Cuando un mensaje es recibido por el servicio se identifican el emisor del mensaje y el tipo de mensaje recibido para realizar la acción correspondiente. Por ejemplo, la llegada de un mensaje puede significar que la base está enviando como respuesta a una petición la lista de módulos enlazados o también cabe la posibilidad de que la base esté retransmitiendo un mensaje recibido desde algún módulo. Cuando se ha realizado la acción pertinente el servicio avisa a través de un intent el evento ocurrido para que si la aplicación está abierta pueda capturar este aviso a través de un BroadCastReceiver y actuar en consecuencia si procede.
Interfaz de usuario. Para la interfaz de usuario se ha pretendido diseñar una imagen de la aplicación simple, sin demasiados botones que despiste al usuario pero al mismo tiempo con un diseño cuidado y llamativo. No vamos a entrar en detalles de cómo se han diseñado y funcionan todos y cada uno de los elementos de la aplicación sino que nos centraremos en los puntos importantes donde merece prestar atención.
Navegación. La interfaz de usuario consta de una activity principal en la que a través de un menú de navegación situado en la Action Bar se van intercambiando los distintos fragments que contienen las diferentes secciones o páginas de la aplicación. También en la página Home de la app, se han incluido dos botónes que ofrecen un acceso rápido a dos de las secciones de la aplicación: Reglas y Ajustes.
En la pantalla Home encontramos un menú central que da acceso al usuario a las cinco secciones en las que se clasifican los módulos domóticos y cuya estructuración trataremos en la sección siguiente. Veamos los tipos de navegación que encontramos en la aplicación:
Figura 20: Detalle de las diferentes formas de navegación.
Cuando el usuario selecciona una de las secciones en el menú central del Home, una nueva activity se lanza con el listado de módulos organizado por zonas que corresponden a la categoría seleccionada. Listados de módulos. Cuando la nueva activity es lanzada al seleccionar una de las categorías en el menú del Home, se muestra una lista explandible en la que aparecen los módulos organizados por zonas. La complicación del listado de módulos reside en que cualquier categoría puede disponer de módulos de diferente tipo, y esto implica que los componentes de la interfaz para controlar cada módulo dependerán del tipo de este. Por ejemplo, un módulo interruptor tendrá unos controles diferentes a los de un módulo de control de una luz de color varible rgb y sin embargo los dos módulos pertenecen a la misma categoría Iluminación. En la imagen siguiente podemos observar cómo distintos módulos tienen distintos componentes en su layout de representación.
Figura 21: Detalle de componentes propios de cada tipo de módulo.
Por éste motivo se ha realizado un adaptador para la lista expandible en el cual dependiendo del tipo de módulo genere un layout diferente para cada elemento de la lista. Como pretendemos evitar en la mayor medida posible el identificar un módulo por técnicas de tipo if-else o switch porque la actualización de la app con nuevos módulos implicaría ampliar estas estructuras, se ha pensado utilizar el método de la herencia para dicho fin. De ésta manera los diferentes tipos de módulo heredarán de una clase común y abstracta que permitirá por ejemplo, tener un método abstracto que cargue el layout con las características propias del módulo en el adaptador pasado como parámetro. Así para formar la lista expandible con los módulos organizados por zonas, el adaptador de lista con la lista de módulos cargada, tan solo tendrá que llamar al método setEnAdaptador() de cada módulo que se encargará añadir al layout padre el layout propio del módulo, evitando así tener que hacer futuras modificaciones en el adaptador. Otro de los aspectos más interesantes ha sido el poder actualizar el estado de alguno de los elementos de la lista expandible al tener lugar algún evento en alguno de los módulos. Por ejemplo, veamos la siguiente imagen donde se destaca un componente de la igu del módulo sensor de movimiento.
Figura 22: Detalle de componente que cambia tras la llegada de un evento.
Podemos observar cómo existen dos estados para el mismo componente que no dependen del usuario para cambiar, sino que dependen de alguna variable de estado del sensor de movimiento en cuestión. Como ya se ha dicho, el servicio que se ejecuta en background es el encargado de recibir los mensajes de los módulos, pues es cuando se recibe un mensaje en el servicio cuando se actualizan ciertos componentes. Esto se ha implementado agregando a ésta activity un BroadcastReceiver que recibe el aviso de que un módulo ha sido actualizado. Cuando ocurre uno de éstos avisos se vuelve a cargar el módulo con sus variables actualizadas y se actualiza el adaptador que cambiará el estado del componente gráfico. Gestión de los módulos. La gestión de los módulos es una de las partes fundamentales y su correcta implementación es necesaria para un buen funcionamiento de la app. Como ha hemos dicho en la sección anterior, cada módulo del sistema ha sido representado como una clase que hereda de una común y abstracta llamada “Modulo”. Esto nos permite que cada tipo de módulo tenga un comportamiento de acuerdo a sus características sin hacer distinciones, simplemente llamando a métodos abstractos definidos en la clase padre.
Utilizar los métodos abstractos y los mecanismos de herencia entre clases es una necesidad en una aplicación de éste tipo. Si el sistema desarrollado desembocara en un producto comercial serían muchos los módulos que poco a poco se irían desarrollando y cuando más simple sea acomodar la aplicación a nuevos módulos más rápida y eficiente será su actualización. Por ejemplo, si creamos un nuevo módulo para medir la temperatura ambiente, prácticamente sólo tendremos que añadir una nueva clase que herede de “Modulo” y que implemente los métodos abstractos de acuerdo a sus características. Como la llamada a los métodos se hace a través de la clase padre, serán mínimos los cambios realizados en la app. Como ya sabemos, los módulos se organizan en 5 categorías a las cuales el usuario puede acceder desde el menú central del Home. Cuando se accede a cualquiera de las categorías se lanza una nueva activity con el listado expandible de los módulos instalados en la sección organizados por zonas. Para simplificar y para minimizar las zonas de código que habría que actualizar al añadir nuevos tipos de módulos a la app, se ha pensado en utilizar unas listas constantes de manera que haya una lista por categoría y que estas contengan el identificador del tipo de los módulos que son compatibles con la sección. De ésta manera, antes de generar la lista expandible en igu, cargamos todos los módulos correspondientes cuyo tipo sea compatible con la sección seleccionada. Esto nos permite tener una sola activity para las 5 categorías, basta con pasar como parámetro en el Intent que llama a la activity el identificador de la sección seleccionada para cargar, como ya hemos dicho, los módulos instalados en el sistema que sean compatibles con dicha sección. Instalación de nuevos módulos. Un aspecto fundamental de la aplicación es la instalación de nuevos módulos en la app para poder controlarlos. Siempre que el usuario abre la aplicación se está realizando una llamada a la estación base pidiendo la lista de módulos enlazados y como ya hemos dicho, es el servicio el encargado de recogerla. Cuando el servicio recibe la lista comprueba en memoria los módulos instalados y si alguno de los módulos de la lista no está en la memoria del dispositivo, el servicio crea un nuevo módulo del tipo especificado y con una variable de estado que indica que es nuevo. Después guarda el nuevo módulo en memoria y repite el proceso hasta terminar con toda la lista recibida. Cuando se han guardado los nuevos módulos se manda un Intent que la aplicación recibe e indica que se ha recibido y procesado la lista. Después de esto y gracias a la variable de estado que indica si un módulo está o no instalado la aplicación puede recuperar la lista de módulos disponibles en la red y que no estén instalados en la app. Cuando el usuario se encuentra en la sección de de cualquiera de las categorías, tiene la posibilidad de añadir un nuevo módulo al sistema con el botón derecho de la barra inferior.
Figura 23: Detalle de la barra de herramientas inferior de la pantalla secciones.
Con esto, y recordando las listas de compatiblidad entre módulos y categorías, se recupera una lista con los módulos guardados en memoria que estén marcados como no instalados y que además pertenezcan a la sección en la que se encuentre el usuario. Con ésta lista es simple crear un diálogo que dé a elegir al usuario de entre todos los módulos disponibles el que quiere añadir a la aplicación.
Figura 24: Diálogo que lista los nuevos dispositivos disponibles para instalar.
Como vemos en la imagen el diálogo muestra para la sección “Iluminación” los módulos disponibles para su instalación. Aunque también haya nuevos módulos de tipo sensor de movimiento, cómo nos encontramos en una sección no compatible con módulos de seguridad no aparecerán en la lista, facilitando el proceso al usuario. El borrado de los módulos no afecta a estación base a no ser que el módulo seleccionado para ser borrado intervenga en alguna de las reglas añadidas por el usuario. Esto ocurre porque la base no guarda información de los módulos instalados en la app sino que simplemente guarda la dirección física de los módulos enlazados físicamente al sistema. Por otra parte como el conjunto de reglas se almacena tanto en la app como en la base (para su ejecución) el borrado de un módulo en la app implica el borrado también de las reglas en las que intervenga y por tanto necesita comunicar a la estación base que reglas tiene que borrar. Esto provoca que sin estar conectado el usuario a la wifi de la red domótica pueda desinstalar un módulo en la aplicación si no tiene reglas asociadas, pero si el módulo tiene reglas recibirá el aviso de que no puede ser borrado para mantener la sincronía de las reglas con la estación base, necesario para el correcto funcionamiento del sistema. Gestión de las reglas. La posibilidad de insertar reglas en el sistema y que los módulos interactúen entre ellos es una de las principales ventajas del sistema. De la misma manera que ocurre con los módulos, las reglas se representan con una clase que hereda de una clase abstracta común para facilitar la inserción en el sistema de nuevas reglas tras el diseño de nuevos módulos. Una regla de manera simplificada se puede ver cómo una acción en la que generalmente intervienen dos módulos, el primero (sensor) lanzaría a ejecución la regla y el segundo (actuador) sería sobre el que se realizaría la acción. Para insertar una regla desde el menú emergente al hacer una pulsación larga sobre un módulo, al igual que con los tipos de módulos y las distintas categorías, utilizamos listas de compatibilidad para saber qué reglas son compatibles con qué tipos de módulos. Así, cuando el usuario desea insertar una regla para cierto módulo, se genera una lista de las reglas compatibles para el módulo y cuando se selecciona una, se genera otra lista de los módulos que son compatibles con el rol “actuador” para
dicha regla. Después de la elección del módulo sobre el que se realizará la acción de la regla, se envía un mensaje de guardado a través de una conexión Http (ver sección “Protocolo de comunicación”) con los parámetros de la regla a la estación base para que la archive en memoria. En el caso de que la base no respondiera con un mensaje de validación después de guardar la regla, se abortaría el guardado y se mostraría un aviso al usuario. De manera diferente a los módulos, las reglas si tienen la necesidad de permanecer en la memoria de la estación receptora, pues tienen que ser ejecutadas de manera independiente al usuario. Es por esto que cuando en la pantalla “Reglas” se quiere borrar una de ellas si no se establece una comunicación con la estación se mostrará un aviso de que no la regla no puede ser borrada. Esto es para evitar que en el sistema puedan existir reglas “fantasma” instaladas en la estación base pero no en la memoria de la aplicación. Para el borrado de una regla se genera un mensaje de borrado que contiene el identificador de la regla y se envía, utilizando el protocolo visto en el capítulo dedicado al protocolo de comunicación, a través de una conexión Http a la base. Si se recibe una respuesta de validación desde la base después de ser borrada de su memoria, entonces se procede a borrar la regla de la memoria de la app. En el caso de que no se reciba la respuesta esperada, se mostrará un mensaje al usuario y se abortará el borrado. Notificaciones. Ante algunos eventos en los módulos se generan notificaciones que avisan al usuario de la vivienda de lo sucedido. En el sistema presentado es el caso del sensor de movimiento, que cuando detecta algún movimiento y es reportado a la aplicación puede generar una notificación desde el Servicio según estén activadas o no las notificaciones para dicho módulo. Como la información a mostrar en la notificación tras algún evento depende directamente del tipo de módulo y la información que almacene, la notificación se genera en un método desde el propio módulo. Esto permite que el servicio al recibir un mensaje de cierto módulo recupere la instancia almacenada en la memoria del dispositivo con la información de estado del propio módulo y ejecute el método que aplicará los cambios necesarios y de crear y lanzar la notificación si se precisa. Así tenemos que la notificación se lanza en el hilo de ejecución del Servicio, ajeno a la propia aplicación que no tiene porque estar abierta. El aspecto de la notificación es el siguiente:
Figura 25: Captura donde se aprecia la llegada de una notificación.
La notificación anterior es el resultado de una detección de un sensor de movimiento. Como se puede apreciar, las notificaciones no sólo indican el sensor que la manda, sino que también la zona en la que está situado. En el ejemplo: “Sensor cocina en Cocina”. Cuando se recibe una notificación además de información propia del dispositivo, cuando pulsamos sobre ella nos lleva al Home de la aplicación. Para evitar de una manera sencilla, abrir una segunda instancia de la aplicación si se recibe la notificación estando con la aplicación abierta, se ha utilizado una variable de estado guardada en la memoria (SharedPreferences) de la aplicación. Esta variable se actualiza cuando se abre o cierra la aplicación, de manera que se comprueba esta variable antes de lanzar la apertura de la aplicación, de manera que si la aplicación ya se encuentra abierta, evitaremos volver a abrirla.
Gestión de la memoria. Tanto como para la gestión de los módulos como de las reglas en la aplicación, se ha optado por utilizar las SharedPreferences. La elección de este sistema de memoria se ha elegido porque no es mucha la cantidad de información necesaria para el control de los módulos y las reglas y las SharedPreferences proporcionan un acceso a memoria ligero y rápido. Como este tipo de memoria está especialmente diseñado para almacenar datos de tipo simple hemos requerido de una librería externa para transformar las instancias de las clases de los módulos y de las reglas en objetos JSON, que son fácilmente re escribibles en una cadena de texto. La librería utilizada ha sido GSON, que permite convertir cualquier clase en un objeto JSON y viceversa. De esta manera, cuando se requiere guardar un nuevo módulo se crea una nueva instancia de la clase a la que pertenezca y después de actualizar sus variables se convierte en un objeto JSON, fácilmente almacenable en las SharedPreferences. Cuando dicho módulo se requiere, re recupera el objeto JSON de memoria y se vuelve a convertir en su clase origen.
Conclusiones. Este proyecto ha servido para demostrar que con poco, se puede hacer mucho. Con poco presupuesto y poco tiempo se ha desarrollado un sistema domótico, que si bien es verdad que no puede competir todavía con un sistema comercial, funciona muy bien y demuestra las muchas posibilidades de los dispositivos móviles actuales y más aún si las unimos al hardware libre. Aunque el prototipo no explota todas sus posibilidades, por el escaso tiempo de desarrollo del hardware utilizado, y todavía en ocasiones se dan problemas de interferencias en la red inalámbrica de los sensores, el sistema desarrollado podría ser la base de un entorno domótico más trabajado y verdaderamente útil que cumpliría las expectativas de cualquier cliente y a un coste bastante económico. Personalmente, no sé si en un futuro este proyecto evolucionará en un sistema domótico comercial pero estoy contento con el resultado obtenido en escasas 6 semanas de desarrollo. He mejorado mucho en el desarrollo de aplicaciones durante el proyecto y con los consejos de mi director, y espero seguir mejorando en mis futuros proyectos.
BibliografĂa. [1]
http://stackoverflow.com/
[2]
http://www.arduino.cc/
[3]
http://maniacbug.wordpress.com/2011/11/02/getting-started-rf24/
[4]
http://forum.arduino.cc/
[5]
http://developer.android.com/
[6]
http://www.domodesk.com/
[7]
http://www.latiendadedomotica.com/
http://www.monografias.com/trabajos61/zigbee-estandar-domotico-inmotica/zigbee[8] estandar-domotico-inmotica.shtml