Resumen

En la siguiente página se da a conocer el sistema NovaDomus, que es una solución de domótica para casas y que opera de manera inalámbrica (a través de sensores XBee) a nivel de sensores. Luego la información sobre el hogar queda disponible en línea para ser consultada en cualquier punto del mundo gracias a Internet, por lo que el objetivo del sistema es llevar control del hogar al usuario esté donde esté. La página se divide como sigue. El primer punto es la Introducción, para luego seguir con una descripción del sistema en sí, identificando interfaces, clases y hardware. Finalmente las conclusiones del trabajo especifican las tareas pendientes y las que se deseaban agregar.

Introducción

Un poco de contexto.

Novadomus es un sistema de domótica que permite la conexión remota de un usuario con su hogar para así enterarse del estado del mismo, como también para poder actuar sobre él. Se trata de una red de sensores/actuadores que, repartidos a través del hogar, permiten dar a conocer de manera remota el estado del hogar, así como también la posibilidad de actuar sobre él a través de la activación de determinadas opciones. El proyecto NovaDomus surge durante el curso de la asignatura Proyectos Electrónicos, donde se pretendía formar una empresa que se dedicara a la domótica a través de la venta de packs de transformación de casas normales a smarthouses, así como también conseguir mercado a través de la alianza estratégica de la empresa con constructoras que ofrezcan proyectos inmobiliarios con el sistema ya implementado para así darle plusvalía a las propiedades ofrecidas.

Objetivos.

Para cumplir con la descripción anterior de NovaDomus, se requiere imperativamente de un sistema tal que permita la conexión de un usuario desde cualquier lugar, cerca o lejos de su hogar. Esto implica una serie de interconexiones de diversos elementos que interactúan entre sí para llevar la información desde el hogar a la persona. Cabe destacar que no todos los sistemas hablarán en el mismo lenguaje (ya sea por el canal utilizado o por la naturaleza de los diferentes sensores), por lo que se necesita un intérprete e intercomunicador que permita esta interacción de manera fluida y transparente para el usuario final.

Es así como nosotros pretendemos desarrollar una aplicación tal de permitir que un usuario, desde cualquier parte del mundo, pueda acceder a su hogar para monitorearlo. Además, debería tener un sistema de autentificación, para que no cualquier persona pueda entrar al hogar. Además, debe ser concebido con el propósito futuro de poder agregar y utilizar sensores de diferente tipo, por lo que la generación de interfaces y métodos debe ser lo más abstracto y general posible para así realizar futuras implementaciones de manera eficiente.

El sistema

Para descargar la última versión de los fuentes de este software, haga clic AQUÍ.

Básicamente, Novadomus permite la interacción, a través de protocolo TCP, de un usuario con sensores remotos. Esta interacción consiste en la lectura/escritura de valores análogos/digitales. Se utiliza JAVA para el desarrollo de las aplicaciones, así como el uso de la biblioteca RxTx para la conexión vía serial del software en java con los sensores inalámbricos.

Figura 1. Esquema del flujo de datos en el sistema NovaDomus.

Red de sensores locales

Se utilizaron dispositivos XBee S1 como sensores y actuadores. Fueron creados por Digi International, y se han popularizado gracias a la facilidad de establecer redes inalámbricas de sensores. Página web del fabricante

Figura 2. Sensor XBee típico.

Algunas características de los sensores XBee son las siguientes: – 8 pines digitales, utilizables tanto para Input como para Output de información digital. – 5 conversores ADC de 10 bits, que permiten conversiones de hasta 1024 niveles. – Velocidades de transmisión Serial de hasta 250 kbps, utilizando baud rates fuera del estándar. – Uso de protocolo 802.15.4 para comunicaciones inalámbricas – Funcionamiento transparente o vía API. Cuando funciona de manera transparente, cualquier dispositivo conectado a la puerta serial del XBee que establezca conexión con otro XBee podrá enviar datos como si el XBee no existiera, casi como si estuviese establecida una comunicación por cable. Por otro lado, el funcionamiento a través de la API del XBee permite un mayor control del sensor XBee en sí, ya que se puede reconfigurar con sólo enviarle un paquete con los campos a configurar, además de mantener las mismas capacidades de comunicación que el modo transparente. Sin embargo, ahora es la aplicación la que se debe encargar de generar los paquetes  y enviar la información.

En este proyecto se utilizó el modo de comunicación API, ya que como se mencionó anteriormente, permite el envío de paquetes de manera serial con requerimientos específicos a cada sensor XBee conectado por cable o inalámbricamente al computador. Esto tiene una ventaja frente al funcionamiento transparente, ya que ahora es posible la reconfiguración del dispositivo on the fly.

Figura 3. Formato del paquete API

Gracias al uso del modo API, se pueden asignar los pines del sensor como entrada/salida digitales, como conversores ADC o simplemente desactivarlos, todo mientras el sensor no deja de funcionar. La gran desventaja, es el tener que armar el paquete por cada cambio a realizar. Esto quiere decir que se debe calcular el largo de la petición y calcular el checksum por cada paquete, así como también recibir el acuse de recibo y gestionar retransmisiones si el caso así lo necesita.

A continuación se muestra la interfaz gráfica del software monitor.

Figura 4. Interfaz gráfica del HomeMonitor.

Conexión a Internet

Para hacer visible los sensores a internet, se desarrolló una aplicación servidor, que se ejecuta en el hogar, la cual empaqueta la información recibida desde los dispositivos XBee y la transforma en objetos que luego son registrados en un servicio RMI. En una primera instancia se había decidido el volver público al objeto XBeeSensor (que representa cada sensor XBee conectado al computador) por completo, sin embargo éste era demasiado pesado para la red y recibimos constantes errores por exceder el timeout de la red. Se presume que el origen de esto es el tratar de enviar también la clase Communicator, que era la que mantenía la comunicación serial con los sensores y no tenía un tamaño despreciable. Por otro lado, el enviar solamente el objeto XbeeData era más que suficiente para las tareas de monitoreo y control.

Figura 5. Clase XBeeSensor y sus atributos.

La Aplicación. Clases y Jerarquía.

La aplicación servidor posee dos Clases que se encargan de la comunicación:

– public class TwoWaySerialComm, que establece conexiones serial entre los dispositivos XBee y el computador. Se utiliza biblioteca RXTXcomm.

– Public class HomeMonitor, que registra los objetos para que sean visibles por red, además de realizar peticiones periódicas a la clase de comunicación serial para el despliegue local de la información.

La Jerarquía de clases se puede visualizar de la siguiente manera:

Figura 6. Diagrama de jerarquía de clases.

La aplicación HomeServer es la que incializa a  HomeMonitor. Esta clase es la que se encarga de registrar el objeto XbeeData de cada sensor conectado en el RMIregistry que también se debe ejecutar en el computador. Además, HomeMonitor se encarga de iniciar la GUI local con la que se despliega la información de los sensores. XBeeSensors representa a un array de objetos XBeeSensor, los cuales almacenan toda la información de cada sensor en el objeto XBeeData. Además cada sensor posee un objeto Communicator, el cual se encarga de interpretar y transformar los requerimientos provenientes del usuario (indicados a través de la GUI) en peticiones a la API del sensor XBee. Por lo tanto esta clase se encarga de recibir un requerimiento, armar la petición en el formato API, y luego enviársela a la clase TwoWaySerialComm para que esta última arme en definitiva el paquete que se enviará por el puerto serial del computador hacia el sensor que se desea controlar.

Acceso Remoto – Aplicación Cliente.

Gracias a que la información contenida en XbeeData es visible por red (ya que se registró anteriormente en el RMIregistry), un cliente puede conectarse al software servidor y consultar el estado de los pines y desplegar la información en pantalla, de manera remota. Para realizar esto, es necesario saber de antemano la URL del computador en el que se está ejecutando el HomeServer.

 La siguiente es la Interfaz SensorInterface. Esta interfaz es implementada por la clase XbeeData.

Figura 7. Interfaz SensorInterface.

El espíritu de utilizar esta estructura de interfaz es la de extender este programa hacia el uso de otros tipos de sensores, como por ejemplo el uso de microcontroladores arduino. Los métodos definidos son lo más generales posibles, salvo SettingState que aún utiliza un objeto XbeeData. Uno de los desafíos será el que este método tampoco dependa de algún tipo de dato exclusivo de los sensores Xbee, para así utilizar esta interfaz con cualquier tipo de sensor.

Por otro lado, la GUI utilizada es muy similar a la utilizada en la clase HomeMonitor, con la salvedad que ahora se debe ingresar la URL del servidor donde están las clases. La implementación que subyace a la interfaz es prácticamente la misma, con la salvedad que ahora no se inicializa una comunicación serial en el cliente, sino que sólo se actualizan periódicamente los objetos XbeeData enviados por la red.

Figura 8. Detalle de la diferencia entre las ventanas del HomeMonitor y el ClientMonitor.

Un ejemplo de uso

Para utilizar la aplicación, se debe iniciar primero el RMIregistry en el equipo donde se ejecutará HomeServer. Para esto se debe ejecutar (en Windows)

Ø start RMIregistry

Luego se puede inicializar el software HomeServer. Una vez que inicializa aparecerá la imagen de la figura 4. En este paso, se debe cargar un archivo de configuración, el cual contiene la lista de sensores XBee disponibles y la dirección de cada uno de los pines de I/O:

Figura 9. Opción para abrir configuración

Una vez que se carga el archivo de configuración, y se presiona el botón start, comenzará automáticamente el monitoreo de los clientes, y la información se desplegará por pantalla:

Figura 10. Pestaña Sensor Setup

Aquí, Digital Mask indica la dirección de los pines de I/O. Si la casilla está activada, es porque el pin es de salida. Si está desactivada, se trata de un pin de entrada. Por otro lado, también se muestra la máscara de las entradas análogas. Si está activada una determinada casilla, no se podrá seleccionar un valor de DIO, ya que ese pin ya no es una entrada/salida digital, sino que es una entrada análoga. Mientras no esté corriendo el software, es posible además activar la configuración realizada haciendo clic en el botón set sensor.

La pantalla sensor raw data, muestra la siguiente información:

Figura 11.Pestaña Sensor Raw Data.

Aquí se visualiza la misma información entregada en Sensor setup, salvo que ahora se muestra en formato hexadecimal. La principal función de esta pestaña es la de visualización de la información para depuración del programa.

Finalmente, la pestaña ADC Monitor, abre el panel donde se mostrará la gráfica de los valores de los ADC activados:

Figura 12. Pestaña ADC Monitor.

Como se aprecia, se pueden visualizar hasta 5 conversores ADC en tiempo real, o más bien, a la velocidad con la que se refresca el valor de los sensores.

Por el lado de la aplicación HomeClient, la interfaz es exactamente la misma salvo el detalle mostrado en la figura 8. El modo de funcionamiento es el mismo, salvo que el botón SetSensor aún no funciona.

Conclusiones

El desarrollo de esta aplicación nos dejó como grupo la experiencia de trabajar con un lenguaje de alto nivel como lo es java para trabajar de manera transversal en el proceso de intercomunicación entre dos tipos completamente diferentes de protocolos de comunicación, como lo es la API de XBee a través del puerto serial, y el uso de RMI para el acceso sobre una red TCP de los objetos contenidos en una aplicación servidor. A continuación un resumen de lo conseguido y lo que se desea conseguir a futuro, motivados con el desarrollo de este proyecto:

Lo conseguido

• Utilización de comunicación serial entre el computador y los dispositivos Xbee en java. Se logró desarrollar un sistema que interpreta los requerimientos de alto nivel en requerimientos de bajo nivel (paquetes API), lo cual aporta con modularidad a nuestro código y permite que se pueda trabajar en la aplicación de alto nivel (GUI) con independencia del código utilizado para la comunicación de bajo nivel.

• Uso de API para el envío-recepción de datos, generación de paquetes de datos y máquinas de estado para la recepción de los mismos. La generación de una clase exclusiva para el armado de paquetes permite la reutilización del código en otras aplicaciones, además de independizar capas superiores del funcionamiento interno de la API de XBee. Así, si el día de mañana se desea agregar otro tipo de sensor, basta con remplazar a la clase TwoWaySerialComm por otra clase que realice un trabajo similar pero concentrado en el otro tipo de sensor.

• Uso de RMI para hacer visibles por red los datos de cada sensor y así visualizarlos de manera remota. Se comprobó empíricamente las limitantes del sistema RMI para el envío de objetos. Se recomienda para futuras aplicaciones el uso de objetos pequeños (que contengan poca información) para el acceso remoto de información, ya que a medida que estos crecen se dificulta su acceso a través de RMI, incluso usando redes locales (en las pruebas se utilizaron redes Ad-hoc y aun así se conseguía problemas de timeout).

• Uso de hebras para la recolección en paralelo de información por parte de cada dispositivo Xbee. Esto era posible gracias a que cada XBee tenía asociado su propio puerto COM. (se desarrolló la aplicación en Windows).

• Generación de aplicaciones de visualización tanto locales como remotas. Usando JFreeChart, se logró el despliegue en tiempo real de la información entregada por los puertos análogo-digitales, así como también se diseñó la interfaz de manera que el seteado de pines fuera lo más sencillo posible, de cara a la futura utilización de nuestra aplicación por un cliente que no tiene fuertes conocimientos en aplicaciones. Se buscó desarrollar una GUI user-friendly, obteniendo significativos resultados.

Lo que falta / Lo que se desea agregar

• Mayor robustez en las aplicaciones clientes. Algunos bugs conseguían que la aplicación simplemente dejara de funcionar. Por otro lado, no existe soporte aún para el envío de comandos de manera remota, debido simplemente a poco tiempo para continuar con el desarrollo.

• Integración del código con otros dispositivos/sensores. Por factores de tiempo también, no se pudo realizar la integración del código con, por ejemplo, microcontroladores Arduino. La idea es que en el futuro sensores de diferente tipo puedan convivir en armonía bajo el mismo marco de trabajo, para así entregar un servicio multifuncional al cliente final.

• Mayor comprensión sobre políticas de seguridad. El tener que pasar innumerables horas sólo revisando documentación para descubrir que el problema del código se originaba en la existencia de una línea de código en nuestro programa, y que para que funcionara se debía eliminar simplemente, demostró el poco conocimiento que se tenía sobre materias de seguridad en servidores RMI, así como el formato y las configuraciones necesarias que necesitaban los archivos de  políticas de seguridad que se agregaban a la ejecución del software.

• Inserción de sistema de autentificación del cliente (usuario/contraseña). Administración de la misma en aplicación externa. En un principio se pensó en utilizar un servidor de autenticación que generara la conexión de los clientes con los HomeServer respectivos, para así tener la capacidad de gestionar un mayor  número de hogares en un mismo lugar (y que así representaría al servicio entregado por nuestra compañía de domótica y por el cual se cobrarían tarifas mensuales de acceso). Sin embargo, nuevamente por cuestiones de tiempo, se tuvo que optar por un sistema sin seguridad, donde el único requisito para conectarse al sistema es tener la ip del HomeServer.