Universidad ORT Uruguay
Facultad de Ingeniería
SIMYCD: Sistema integrador de
monitoreo y control de dispositivos
domóticos
Entregado como requisito para la obtención del título de Ingeniero en
Telecomunicaciones
Javier Kaniewicz - 147323
Javier Groba - 147934
Tutor:
Ing. Álvaro Sánchez
Declaración de autoría
Nosotros, Javier Groba y Javier Kaniewicz, declaramos que el trabajo que se presenta en esta obra es de nuestra propia mano. Podemos asegurar que:
La obra fue producida en su totalidad mientras realizábamos el proyecto entregado como requisito para la obtención del título de Ingeniero en Telecomunicaciones; Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepción de estas citas, la obra es enteramente nuestra;
En la obra, hemos acusado recibo de las ayudas recibidas;
Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos expli-cado claramente qué fue contribuído por otros, y qué fue contribuído por nosotros; Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Javier Groba Javier Kaniewicz
Palabras claves
Cloud Computing: La computación en la nube es un paradigma, una forma de ofrecer diferentes servicios a través de Internet.
Domótica: Es un sistema que posibilita a una vivienda a funcionar por sí misma a través de diferentes interfaces que permiten el control y/o monitoreo de dispositivos en un ambiente determinado.
Gateway: También conocido en español como pasarela, es una solución para inter-conectar dos sistemas con protocolos diferentes.
IPv6: Internet Protocol version 6. Es la versión seis del protocolo IP, diseñada para reemplazar al protocolo de internet versión cuatro, IPv4.
SMS: Short Message Service. Es un servicio de telefonía para el envío de mensajes de texto de hasta 160 caracteres entre teléfonos.
Agradecimientos
A nuestras familias, muy especialmente a nuestras novias Lucía y Nati, por haber vivido este proceso junto a nosotros.
Además quisieramos hacer una mención especial en memoria de la abuela de Javier K, Ela (Ría Okret zl).
Al papá de Javier G, Esc. Emilio Groba, por habernos prestado el espacio necesario para trabajar cómodamente durante el transcurso del proyecto.
Al Ing. MSc. Gonzalo Arreche por su apoyo técnico y logístico, y por siempre estar dispuesto a aconsejarnos.
Abstract
El proyecto SIMYCD: Sistema integrador de monitoreo y control de dispositivos domóti-cos describe un sistema desarrollado para soportar la integración de diferentes estándares domóticos y sus dispositivos a través de múltiples interfaces de control. La motivación principal fue el reto de diseñar e implementar un sistema escalable y seguro que logre ser competitivo en funcionalidades respecto al mercado actual de domótica, explorando el estado de la tecnología en Uruguay y a nivel global, proponiendo el desarrollo de una solución integral.
Luego del estudio de interfaces de control, herramientas y estándares domóticos, se optó por implementar una interfaz web, que hace de cliente usuario y administrador para la creación de usuarios y redes domóticas, y una interfaz vía SMS para la ejecución de comandos a los dispositivos nales. La ejecución de los comandos se realiza sobre una red de control y automatización ZigBee. Las comunicaciones entre el estándar domótico y las interfaces de control se procesan mediante una API estilo REST utilizando para la persistencia una base de datos MySQL. El software de gestión fue diseñado para funcionar en la nube con el concepto Cloud Computing.
Índice
1. Introducción 18
1.1. Objetivos . . . 19
1.2. Introducción a la red domótica . . . 19
2. Arquitectura del sistema 22 2.1. Estándares y tecnologías estudiadas . . . 22
2.1.1. UPnP . . . 22
2.1.2. RESTful Web Services . . . 24
2.2. Componentes principales . . . 25
2.2.1. Modelo de gestión local . . . 26
2.2.2. Modelo de gestión en la nube . . . 26
2.2.3. Modelo de gestión mixto . . . 28
2.2.4. Elección del modelo de gestión . . . 28
2.3. Ejemplos de sistemas comerciales . . . 29
2.3.1. MiOS . . . 29
2.3.2. FoxyHouse . . . 30
2.4. Arquitectura propuesta . . . 31
2.4.1. Seguridad . . . 33
2.4.2. Implementación . . . 33
3. Selección de herramientas 35 3.1. Plataforma de desarrollo . . . 35
3.1.1. Servidor . . . 35
3.1.2. Ambiente de desarrollo . . . 39
4. Interfaces de control 41
4.1. Investigación previa . . . 41
4.1.1. SMS . . . 41
4.1.2. Aplicación web . . . 42
4.1.3. Aplicaciones nativas para dispositivos móviles . . . 42
4.1.4. IVR . . . 43
4.1.5. Tablero de control . . . 43
4.2. Elección de las interfaces de control . . . 43
4.3. Interfaz web . . . 44
4.3.1. Herramientas utilizadas . . . 44
4.3.2. Implementación de la interfaz web . . . 45
4.3.3. Funciones . . . 45
4.4. Módulo SMS . . . 46
4.4.1. Investigación previa . . . 46
4.4.2. Implementación del Módulo SMS . . . 49
4.4.3. Funciones . . . 50
5. Estándares domóticos 51 5.1. ZigBee . . . 51
5.2. Z-Wave . . . 52
5.2.1. Iniciando una red Z-Wave . . . 52
5.2.2. Topología . . . 52
5.3. X10 . . . 53
5.4. KNX . . . 53
6. ZigBee 55
6.1. Estándar IEEE 802.15.4 . . . 55
6.2. Tipos de Dispositivos ZigBee . . . 58
6.2.1. Según Dispositivo . . . 59
6.2.2. Según funcionalidad . . . 59
6.3. Estrategias de conexión . . . 60
6.4. Topología . . . 61
6.5. Arquitectura . . . 62
6.6. Seguridad . . . 63
6.7. Formación de una nueva red ZigBee . . . 65
6.8. Perles ZigBee . . . 67
6.9. Arquitectura de un dispositivo ZigBee . . . 68
6.10. ZigBee Gateway . . . 70
6.10.1. Arquitectura . . . 71
6.10.2. Características principales . . . 72
6.10.3. Funcionamiento . . . 73
6.10.4. Bindings . . . 74
6.10.5. Comunicaciones . . . 75
6.10.6. Manejo de funciones . . . 75
6.10.7. Funciones en un gateway ZigBee . . . 78
7. Hardware 80 7.1. Estudio y elección del ZigBee gateway . . . 80
7.1.1. Digi ConnectPort X2 ZigBee Gateway . . . 80
7.1.3. Exegin Q53 ZigBee Gateway . . . 83
7.1.4. Elección del ZigBee Gateway . . . 85
7.2. Estudio y elección de los dispositivos nales . . . 86
7.2.1. Sensores . . . 86
7.2.2. Actuadores . . . 88
8. Seguridad 90 8.1. Seguridad en el servidor . . . 90
8.1.1. Acceso web HTTPS . . . 90
8.1.2. Tokens . . . 91
8.1.3. API Key . . . 95
8.2. Seguridad en SMS . . . 95
8.3. Seguridad en la red domótica . . . 95
9. Implementación 96 9.1. Software de gestión . . . 97
9.1.1. Requerimientos . . . 97
9.1.2. Dominio de la solución . . . 97
9.1.3. Diagrama de clases . . . 99
9.1.4. Modelo de representación de gateways . . . 100
9.1.5. Metadata para descripción de dispositivos . . . 100
9.1.6. API REST . . . 101
9.1.7. Manejo de consultas asincrónicas . . . 108
9.1.8. Registro de actividad en archivos . . . 109
9.2. Driver ZigBee . . . 110
9.2.1. Implementación . . . 111
9.2.2. Funciones . . . 112
9.2.3. Comandos de control de dispositivos . . . 114
9.2.4. Ejemplo de envío de comando . . . 116
9.2.5. Inicio de un ZigBee Gateway . . . 118
9.2.6. Funciones implementadas . . . 122
9.2.7. Seguridad . . . 123
9.3. Interfaz web . . . 123
9.3.1. Desarrollo . . . 123
9.3.2. Funcionalidades . . . 124
9.3.3. Seguridad . . . 128
9.4. Módulo SMS . . . 128
9.4.1. Componentes . . . 128
9.4.2. Controladora SMSController . . . 128
9.4.3. Gateway de entrada - Aplicación Android . . . 129
9.4.4. Funciones soportadas . . . 130
9.4.5. Seguridad . . . 131
11.Casos de uso 133
11.1. Interfaz web SIMYCD . . . 133
11.1.1. Autenticación . . . 133
11.1.2. Domo . . . 133
11.1.3. Gateway . . . 134
11.1.4. Dispositivo ZBHT-2 . . . 138
11.1.5. Dispositivo ZBMPlug15 . . . 139
11.2. Interfaz SMS . . . 141
11.2.1. Lectura . . . 141
11.2.2. Acciones . . . 143
12.Conclusiones 144 12.1. Trabajo futuro . . . 145
13.Bibliografía 147 14.ANEXO I - Acrónimos y abreviaturas 152 15.ANEXO II - Exegin Q53 ZigBee Gateway Device 155 16.ANEXO III - ZBHT-2 157 16.1. Quick Start Guide . . . 157
16.2. Product Brief . . . 159
17.ANEXO IV - ZBMPlug15 161 17.1. Quick Start Guide . . . 161
18.ANEXO V - Manual de usuario 165
18.1. Descripción de los dispositivos . . . 165
18.2. Requisitos . . . 165
18.3. Conguración del gateway ZigBee . . . 165
18.4. Manejo de usuarios en SIMYCD . . . 169
18.4.1. Crear un nuevo usuario . . . 169
18.4.2. Modicar un usuario . . . 171
18.4.3. Eliminar un usuario . . . 172
18.5. Manejo de Domos . . . 172
18.5.1. Creación de un Domo y conguración de los usuarios dueños del Domo . . . 172
18.5.2. Eliminar un Domo . . . 174
18.6. Manejo de gateways . . . 174
18.6.1. Crear un gateway . . . 174
18.6.2. Modicar un gateway . . . 175
18.6.3. Eliminar un gateway . . . 176
18.7. Control de gateway . . . 176
18.7.1. Vía interfaz web . . . 176
18.7.2. Vía SMS . . . 179
18.8. Control de dispositivos . . . 182
18.8.1. Vía interfaz web . . . 182
18.8.2. Vía SMS . . . 185 19.Anexo VI - Dicultades y obstáculos 187
Índice de guras
1.1. Tipos de dispositivos domóticos . . . 20
2.1. Stack de protocolos UPnP . . . 23
2.2. Componentes principales de un sistema domótico . . . 25
2.3. Arquitectura básica . . . 31
2.4. Arquitectura del sistema SIMYCD . . . 34
4.1. GTS Gateway . . . 47
6.1. Gráco de rango de alcance en relación con la velocidad de transferencia . 57 6.2. Distintas topologías de red existentes . . . 61
6.3. Capas de especicación ZigBee . . . 63
6.4. Diagrama de una Red ZigBee . . . 66
6.5. Unión de un nuevo dispositivo nal . . . 66
6.6. Capas jerárquicas en un dispositivo ZigBee . . . 68
6.7. Modelo ZigBee de Cliente-Servidor . . . 69
6.8. Ejemplo de valores de un dispositivo con perl Home Automation . . . 70
6.9. Implementación general de un gateway ZigBee . . . 71
6.10. Arquitectura de un gateway tipo ZigBee . . . 72
6.11. Invocación de las funciones de Procedimiento y Controlador de Eventos . . 76
7.1. Digi ConnectPort X2 Gateway . . . 81
7.2. Placa Arduino UNO . . . 82
7.3. Exegin Q53 ZigBee Gateway . . . 84
7.4. Ejemplo de ZigBee PAN . . . 84
7.5. Ejemplos de sensores ZigBee . . . 87
8.1. Diagrama de inicio de sesión SSL . . . 91
8.2. Diagrama de inicio de sesión de usuario . . . 93
9.1. Sistema SIMYCD . . . 96
9.2. Diagrama de capas del sistema implementado . . . 96
9.3. Ejemplo de funcionamiento de la API . . . 97
9.4. Diagrama de clases . . . 100
9.5. Diagrama de consulta asincrónica . . . 109
9.6. Diagrama de ujo de NetworkDiscovery . . . 121
9.7. Interfaz de prueba de la aplicación Android . . . 129
9.8. Ejemplo de SMS de respuesta . . . 130
11.1. Autenticación desde la interfaz web de SIMYCD . . . 133
11.2. Sección DOMES de la interfaz web de SIMYCD . . . 134
11.3. Sección gateway de la interfaz web de SIMYCD . . . 135
11.4. Respuesta satisfactoria de la función Get . . . 136
11.5. Interfaz web del dispositivo ZBHT-2 de SIMYCD . . . 138
11.6. Interfaz web del dispositivo ZBMPlug15 de SIMYCD . . . 140
11.7. Envío y respuesta de SMS del sistema - Usuario no registrado . . . 141
11.8. Envío y respuesta de SMS del sistema - Usuario registrado . . . 142
11.9. Envío y respuesta de SMS del sistema - TIMEOUT . . . 142
11.10.Envío y respuesta de SMS del sistema - OnO . . . 143
18.1. Interfaz Gecko - Inicio . . . 166
18.2. Interfaz Gecko - Ventana pop-up . . . 166
18.3. Interfaz Gecko - IP obtenida del Q53 . . . 167
18.5. Cambio de contraseña de la interfaz web de Exegin . . . 168
18.6. Conguración del gateway de la interfaz web de Exegin . . . 168
18.7. Sección de control de la interfaz web de Exegin antes de iniciar el gateway 169 18.8. Sección de control de la interfaz web de Exegin luego de iniciar el gateway 169 18.9. Inicio de la interfaz SIMYCD . . . 170
18.10.Creación de usuario nuevo . . . 170
18.11.Login de usuario . . . 170
18.12.Menú principal . . . 171
18.13.Sección editar usuario - Datos cargados . . . 171
18.14.Sección editar usuario - Usuario actualizado . . . 172
18.15.Lista de Domos . . . 172
18.16.Creación de un nuevo Domo . . . 173
18.17.Menú para la asociación de un usuario a un Domo . . . 173
18.18.Usuario asociándose a un Domo . . . 173
18.19.Lista de usuarios y gateways asociados a un Domo . . . 174
18.20.Crear un gateway . . . 175
18.21.Sección editar gateway - Datos cargados . . . 175
18.22.Sección editar usuario - Usuario actualizado . . . 176
18.23.Menú principal del gateway . . . 177
18.24.Función Permit Join . . . 177
18.25.Función Start Network Discovery . . . 178
18.26.Menú principal del gateway ID 1 luego de ejecutar Permit Join y Get . . . 178
18.27.Función Create Callback . . . 179
18.29.Función Delete Callback . . . 179
18.30.Función Get Neighbor Devices . . . 179
18.31.Usuario no registrado . . . 180
18.32.Envío de funciones soportadas a nivel de gateway vía SMS . . . 181
18.33.Ejemplo de respuesta de función DEV ID . . . 182
18.34.Menú principal del ZBHT-2 . . . 183
18.35.Menú principal del ZBMPlug15 . . . 184
18.36.Ejemplo de envío de comandos con parámetros vía SMS . . . 185
18.37.Ejemplo de envío de comandos con parámetros vía SMS . . . 185
18.38.Ejemplo de respuesta de función VAR 67 sendOnO Mode 2 . . . 186
Índice de tablas
3.1. Diferencias entre Microsoft Windows y Linux . . . 36
5.1. Tabla comparativa de estándares domóticos . . . 54
6.1. Comparativa entre Wi-Fi, Bluetooth y ZigBee . . . 58
6.2. Código de estados de un ZGD . . . 77
7.1. Comparación entre sensores ZigBee . . . 88
7.2. Comparación entre actuadores ZigBee . . . 88
9.1. Funciones soportadas por el Exegin Q53 ZigBee Gateway . . . 113
9.2. Formato de un ZCLHeader . . . 114
9.3. Formato del campo Frame control . . . 114
9.4. Tramas de comando ZCL . . . 116
9.5. Parámetros de un StartGatewayDevice . . . 119
9.6. Parámetros de un PermitJoin . . . 120
9.7. Funciones utilizadas del Exegin Q53 ZigBee Gateway . . . 122
9.8. Funciones del ZBHT-2 . . . 123
1. Introducción
La domótica ha tenido una gran expansión en los últimos años acompañada con la reduc-ción de los costos de la tecnología. Aunque este concepto no sea nuevo, es mejor claricar lo que se entiende por domótica. En el presente documento se entiende como un sistema electrónico creado para realizar monitoreo y control dentro de un hogar. La palabra surge de la unión de Domo y Tica que provienen del griego y signican Casa Automática. También se puede tomar como referencia más estructural la denición según el diccio-nario de la Real Academia Española, que dice: Conjunto de sistemas que automatizan las diferentes instalaciones de una vivienda.. Entonces, dicho término comúnmente co-nocido como casas inteligentes, es un sistema que posibilita a una vivienda a funcionar por sí misma a través de diferentes interfaces que permiten el control y/o monitoreo de dispositivos en un ambiente determinado.
Muchos de los creadores de sistemas domóticos desarrollan protocolos propietarios para la comunicación entre sus centros de control o gateways1 y sus dispositivos nales. Esto se
debe al crecimiento dispar de las tecnologías domóticas y al poco apoyo que existe entre las empresas que desarrollan este tipo de soluciones; aunque aún así, existen estándares generados por alianzas de empresas. A partir de esta realidad se detectó la necesidad de implementar un sistema que pueda integrar varios estándares domóticos y diferentes interfaces de control, incentivando la utilización de protocolos de domótica existentes. A través del estudio de proyectos anteriores, se extrajeron ideas que nalmente sirvieron para marcar los objetivos nales y la motivación de crear un sistema que se diferencie de las soluciones existentes. Dentro de los trabajos relevados donde se proponía hacer uso de la domótica como objeto de estudio, varios se enfocaron principalmente en la creación del gateway que interpreta una señal proveniente del mundo IP y la transforma en un mensaje dentro de la red domótica, como por ejemplo X102,3.
El presente trabajo plantea una solución a los problemas de diversicación de estándares, mediante el diseño de una arquitectura que contemple todos los componentes necesarios para un sistema de domótica: una entrada, un núcleo integrador, un gateway de salida y algún dispositivo nal que demuestre el funcionamiento del mismo. En denitiva, la idea fue diseñar e implementar un sistema domótico que integre todas las partes, pero que no se limite a un único tipo de entrada o salida; o al desarrollo de un protocolo propio no convencional, sino que pueda ser integral y ampliable en un futuro.
1Gateway: También conocido en español como pasarela, es una solución para interconectar dos
sistemas con protocolos diferentes.
2X10: Ver punto 5.3.
3Por ejemplo: Acceso y control de un sistema de automatización hogareña desde la red IP (Yae et
1.1. Objetivos
Para la realización del proyecto se tomaron diferentes objetivos escalonados para enfocarse en una solución centralizada.
Como primer objetivo se planteó el estudio de los mecanismos y estándares que permiten conectividad entre dispositivos domóticos.
El siguiente objetivo fue el desarrollo de un software que permita la integración de distintas interfaces de control como SMS4,5 y aplicación web, para el manejo de los dispositivos
domóticos. Para ello se trabajó en el control de dichos dispositivos mediante órdenes enviadas por SMS desde un celular y también a través de una interfaz web. Además, se propuso incluir un análisis del sistema para su funcionamiento en un ambiente IPv6. Finalmente, para lograr esta integración se buscó desarrollar una solución que involucre software y hardware capaz de actuar como gateway entre las distintas interfaces de control y los dispositivos, conrmando el funcionamiento del sistema en un ambiente de pruebas.
1.2. Introducción a la red domótica
Entre los sistemas domóticos se encuentran diferentes funcionalidades dependiendo de las necesidades de los usuarios, entonces una red domótica puede ser tan simple como el control de las luces de una habitación, o tan complejo como la integración total de un hogar junto con las alarmas, iluminación, sistema HVAC6, riego, entre otros.
La Figura 1.1 permite ver los diferentes tipos de dispositivos domóticos existentes.
4SMS: Short Message Service.
Figura 1.1: Tipos de dispositivos domóticos
Se pueden dividir los dispositivos dependiendo de su funcionalidad según las siguientes categorías:
Bus Es el medio de transmisión que transporta la información entre los distintos dis-positivos por cableado (red eléctrica, red telefónica o red de datos) o de forma inalámbrica.
Interfaz Se reere a los dispositivos en los que se muestra la información del sistema a los usuarios y donde los mismos pueden interactuar con el sistema. Estos pueden ser pantallas táctiles, PC, tabletas, celulares u otros.
Actuador Es el dispositivo de salida capaz de recibir una orden del controlador y realizar una acción (encender / apagar, subir / bajar persiana, abrir / cerrar una electrovál-vula, entre otros). Estos dispositivos pueden admitir baterías o ir conectados a la red eléctrica. En algunos casos, el sensor y el actuador son integrados en el mismo dispositivo.
Un aspecto importante en un sistema domótico son las funciones que permite realizar al usuario. Estas funciones pueden ir desde realizar tareas como prender la calefacción antes que el usuario llegue a la casa, o bajar las persianas cuando cae el sol. Otra acción es la de monitorear mediante cámaras de seguridad la vivienda de manera remota. También existe la posibilidad de programar actividades, ya sea para que la casa realice acciones sistemá-ticas a una hora determinada, o programar al salir de la vivienda el modo simulación y aparentar la presencia de habitantes.
Teniendo conocimiento de estas funciones, se realizó un relevamiento de las diferentes funcionalidades soportadas en sistemas comerciales7:
Iniciar / dejar una red
Permitir unión de dispositivos
Ver listado de dispositivos conectados Encender / Apagar
Subir / Bajar Dimerizar Leer registro Alarmas Filmar
Grupos de dispositivos Programación de escenarios
En base del listado de funciones recopiladas, se decidirán las acciones requeridas a la hora de implementar una maqueta y la adquisición del hardware necesario detallado en la Sección 7.
2. Arquitectura del sistema
En esta sección se detalla el estudio previo y posterior denición de la arquitectura del sistema domótico implementado.
2.1. Estándares y tecnologías estudiadas
Se estudió la arquitectura de comunicación de dispositivos UPnP8 como referencia a la
automatización en la instalación de sistemas y RESTful Web Services como técnica de arquitectura de software a implementar.
2.1.1. UPnP
Se estudió UPnP con el propósito de poder implementar un sistema basado en este concep-to pero nalmente fue descartado como tal porque el hardware de los distinconcep-tos gateways de estándar domótico estudiados (ver Sección 7) no eran compatibles con UPnP. De todas maneras, la justicación de la presencia de UPnP en este documento es que se utilizaron conceptos de UPnP para la resolución de ciertos aspectos de conexión (ver punto 2.4). El concepto de Universal Plug and Play (UPnP) tiene sus raíces en el plug-and-play, y consiste en conectar dispositivos de manera directa a un ordenador sin necesidad de conguración. UPnP es un conjunto de protocolos promovidos por el UPnP Forum9. Su
nalidad es la de permitir que distintos dispositivos periféricos puedan interconectarse fácilmente, simplicando la creación de redes del sistema. Una vez que un dispositivo UPnP es conectado a la red, ya está disponible para comenzar a establecer comunicaciones con todos los demás dispositivos de la red. UPnP utiliza el puerto UDP 1900 y el puerto TCP 2869. Por defecto no implementa ningún tipo de autenticación, cada dispositivo debe implementar su propio mecanismo.
La arquitectura UPnP ofrece una conectividad punto a punto en la red para cualquier computadora, electrodoméstico inteligente y dispositivo inalámbrico. Es distribuida, de red abierta, que aprovecha TCP / IP para permitir la creación de redes de proximidad, además de la transferencia de control y de datos entre los dispositivos conectados en red en el hogar.
En la Figura 2.110 podemos apreciar la arquitectura del stack de protocolos UPnP. 8UPnP: Universal Plug and Play.
9http://www.upnp.org
10HUANG, Jau-Wu. 2012. UPnP. [online][citado en Agosto 2012] Disponible en internet:
Figura 2.1: Stack de protocolos UPnP
Cada dispositivo implementa un cliente DHCP11y busca un servidor DHCP al conectarse
por primera vez a la red. Luego de la obtención de una dirección IP, un dispositivo compatible con UPnP debe seguir los siguientes pasos:
1. Descubrimiento (Discovery):
Se utiliza SSDP12 para el descubrimiento de dispositivos en la red mediante el
envío de un paquete de búsqueda multicast (IP:Puerto - 239.255.255.250:1900). Los dispositivos que cumplen con el criterio de búsqueda, responden un paquete con la información básica del dispositivo, como pueden ser el tipo, ID y un enlace URL13 en donde obtener información completa del mismo.
2. Descripción (Description):
La descripción de un dispositivo se codica en formato XML14 e incluye
in-formación especíca del fabricante como nombre de modelo y número, número de serie, nombre de fabricante y URLs a sitios web especícos del fabricante. Además tiene una lista de servicios y dispositivos hijos. Para cada servicio la descripción incluye una lista de los comandos o acciones a las que responderá el servicio, y parámetros o argumentos de cada acción, a través del ingreso de variables.
11DHCP: Dynamic Host Conguration Protocol. 12SSDP: Simple Service Discovery Protocol. 13URL: Uniform Resource Locator.
14XML: eXtensible Markup Language, es un lenguaje que permite denir una gramática especíca para
3. Control (Control):
Los mensajes de control, al igual que los de descripción, se codican en formato XML mediante protocolo SOAP15.
El punto de control puede consultar por los servicios existentes para invocar acciones y recibir respuestas indicando el resultado de la acción. El servicio debe completar la invocación de la acción y su respuesta en un plazo no mayor a 30 segundos, incluyendo el tiempo de transmisión esperado.
4. Noticación (Eventing):
Para cada servicio en un dispositivo, un mensaje de descripción contiene la dirección URL de eventing y la identicación de servicio UPnP. Para suscribirse a eventing a un servicio particular, un mensaje de suscripción se envía a la URL de eventing de ese servicio.
El mensaje contiene el identicador de ese servicio, así como una dirección URL de entrega de mensajes de eventos. Un mensaje de suscripción puede incluir también una duración de la suscripción solicitada.
5. Presentación (Presentation):
Si un dispositivo tiene una URL de presentación, existe una interfaz web donde el usuario puede controlar el dispositivo.
2.1.2. RESTful Web Services
Los servicios web permiten la comunicación entre sistemas heterogéneos mediante mensa-jes. Estos mensajes que deben ser interpretados por los distintos sistemas utilizan estánda-res como XML o JSON16 que son esencialmente mensajes de texto con formato especíco.
Existen múltiples tecnologías que pueden ser utilizadas para implementar servicios web. Dada la simplicidad, facilidad de uso y el uso extensivo de tecnologías basadas en internet como HTTP17, REST18 se ha vuelto la tecnología preferida por los desarrolladores para
implementar servicios web. Otra alternativa existente es SOAP, sin embargo, hay críticas contra los servicios estilo SOAP especialmente en relación con la complejidad y el volumen de los mensajes, cuando se trata de utilizar los servicios para aplicaciones web.
REST es una técnica de arquitectura de software que por sus características resulta conve-niente para sistemas distribuidos. Existen recursos que pueden ser accedidos únicamente utilizando un identicador global o URI19. Para manipular estos recursos la
comunica-ción de los clientes se hace a través de HTTP que intercambian representaciones de estos recursos utilizando un set de operaciones GET, POST, PUT y DELETE.
GET Devuelve un recurso.
POST Inserta, actualiza, o extiende un recurso. Puede cambiar el estado de otros recur-sos.
PUT Crea, actualiza o reemplaza un recurso. DELETE Elimina un recurso.20
2.2. Componentes principales
Un sistema de domótica visto como un conjunto de componentes se puede separar en tres secciones: Interfaz de usuario, Gestor y Recursos a controlar. Estos componentes se comunican entre sí para conformar el sistema completo.
Figura 2.2: Componentes principales de un sistema domótico
Interfaz de usuario: La interfaz de usuario con el sistema puede ser táctil, me-diante la voz o a través de gestos y la respuesta puede ser auditiva o gráca. Recursos a controlar: Interruptores, alarmas, videos o cualquier otro recurso externo.
Gestor: Se encarga que las órdenes del usuario sean correctamente ejecutadas por el sistema. Notica a los usuarios de los cambios y gestiona la incorporación y elimi-nación de recursos del sistema domótico. Integra las distintas tecnologías domóticas que puedan coexistir en el hogar. También permite comunicaciones remotas hacia el sistema.
19URI: Uniform Resource Identier.
A continuación se detalla el estudio de las distintas opciones de modelo de gestión. Existen tres posibles modelos: el de gestión local, el de gestión en la nube y el modelo mixto. 2.2.1. Modelo de gestión local
En este modelo todos los componentes se encargan de la gestión tanto de hardware, como software, y están ubicados dentro del mismo espacio físico que los recursos a controlar. Debajo se presentan las ventajas y desventajas de este modelo:
Ventajas
Los datos de los usuarios y de los dispositivos se guardan localmente previniendo el acceso a sus datos por parte de terceros.
No se depende de terceros para el buen funcionamiento del sistema. Si las condiciones de funcionamiento están dadas en el hogar, no habrá problemas en el manejo del sistema.
El usuario tienen acceso total a la red. Desventajas
La seguridad del sistema de gestión va a depender de la seguridad de la red. Este punto puede ser convertido en una ventaja en el caso de una red local aislada, pero no es el caso que se da generalmente.
Cada upgrade debe ser descargado e instalado por su propia cuenta, necesitando estar pendientes de la disponibilidad de nuevas versiones del software.
2.2.2. Modelo de gestión en la nube
El modelo de gestión en la nube delega la gestión a un software centralizado que brinda soporte a múltiples clientes desde un único servidor. Este modelo trae consigo ventajas y desventajas propias de Cloud Computing21. Se analizaron éstas desde el punto de vista de
la domótica, tanto visto por el proveedor del servicio como de los clientes nales. Debajo se puede apreciar las ventajas y desventajas de este modelo:
21Ejecución de un software desde la nube. Es un paradigma que permite ofrecer servicios de
Ventajas
Facilidad en la instalación. La instalación del sistema de gestión se reduce a con-guración de algunos parámetros.
Facilidad para la instalación de upgrades de software, donde un cambio en el servidor se ve reejado automáticamente en todos los clientes.
Facilidad para la instalación de upgrades de hardware, en caso que la cantidad de clientes lo haga necesario. Servicios como Amazon Web Services22 lo hacen sencillo
al contar con un servicio adaptable a la demanda de recursos.
Facilidad para la realización de backups de la información, realizándose en forma centralizada.
Menor costo total de propiedad, no solo desde el punto de vista del software, sino también del hardware. Lo que se instala en el lugar de la red de domótica no es más que un gateway hacia la red de recursos domóticos.
Desventajas
Los datos de los usuarios y de los dispositivos se guardan en un servidor fuera de la casa. Este punto es negativo en caso que los usuarios desconozcan los niveles de seguridad de un servidor dedicado. Este concepto negativo es relativo ya que los estándares de seguridad con los que cuentan los servicios de Cloud Computing son más altos que el promedio de los sistemas hogareños.
La información que se guarda son datos privados y éstos pueden ser accedidos por el proveedor del servicio, el usuario se puede sentir invadido en su privacidad. Éste es un problema de conanza y se debe trabajar como tal.
Se depende de un proveedor para que el sistema funcione, si el servidor falla, el sistema se ve afectado. El nivel de tasa de fallas así como el tiempo de recuperación ante fallas de estos servicios está optimizado para que sea el menor posible.
Depende fuertemente de la conexión a internet. Este es un punto clave para este tipo de modelo, una solución es un sistema redundante, múltiple canal, por ejemplo con ADSL23 y conexiones 3G/4G de respaldo.24
22http://aws.amazon.com/es
23ADSL: Asymmetric Digital Subscriber Line.
24Software en la nube: ventajas e inconvenientes (Soportia, 2012). [online] [citado Noviembre 2012].
2.2.3. Modelo de gestión mixto
Este modelo de gestión toma una posición intermedia entre los modelos anteriormente descriptos, la implementación dene qué gestión se realiza localmente y qué en la nube. Por lo tanto, el análisis de ventajas y desventajas se puede realizar considerando el detalle de la implementación y relacionándolo con los análisis de los modelos de gestión local y modelo de gestión en la nube.
Ventajas
La principal ventaja de este modelo radica en ser un punto medio entre los modelos planteados.
Menor costo total de propiedad, no solo desde el punto de vista del software, sino también del hardware.
Puede instalarse a nivel local, hospedadas en la nube del proveedor, o en la nube de otra compañía dependiendo de las necesidades.
Desventajas
La información que se guarda son datos privados y éstos pueden ser accedidos por el proveedor del servicio en caso que estén guardados en la nube del proveedor. Se depende de un proveedor para que el sistema funcione, si el servidor falla, el sistema se ve afectado. El nivel de tasa de fallas así como el tiempo de recuperación ante fallas de estos servicios está optimizado para que sea el menor posible.
2.2.4. Elección del modelo de gestión
2.3. Ejemplos de sistemas comerciales
Globalmente hay muchas empresas que se están dedicando a la automatización del hogar, tanto a nivel local como en el exterior. En este punto se trata de dar una idea de cómo funcionan estas empresas y cómo solucionaron su modelo de gestión. Es por ello que se decidió estudiar dos casos comerciales: uno nacional y otro internacional.
2.3.1. MiOS
MiOS, LTD.25 es una empresa global de software y hardware, con el foco puesto en el
desarrollo y distribución de soluciones de control y monitoreo para hogares y pequeñas empresas. Fundada en el año 2008, creó una plataforma de tecnología que hace de puente entre múltiples dispositivos con el objetivo de producir soluciones de software y hardware para redes de domótica.
MiOS puede correr en múltiples plataformas, siendo un software ligero que puede ser embebido en televisores, routers, access points, set top boxes, game devices o reproduc-tores Blu-Ray por nombrar algunos. Mi Casa Verde26 comercializa la línea de productos
Vera que corre el software de MiOS con soporte para redes Z-Wave (ver punto 5.2). La plataforma cuenta con una herramienta de desarrollo para permitir la creación de nue-vas funcionalidades así como la expansión y personalización denominada LuuP (Lua + UPnP). Luup es un motor de software que combina el lenguaje de programación de scripts Lua y el estándar para control de dispositivos UPnP. LuuP convierte los comandos co-rrespondientes Z-Wave en llamadas UPnP para que puedan ser controlados por cualquier Control Point que implemente el estándar. Especícamente genera un dispositivo padre UPnP correspondiente a la red Z-Wave que contiene como dispositivos hijos a cada uno de los dispositivos que componen la red.
Como solución para dar soporte a software cliente que no implementa el stack UPnP, la plataforma provee la alternativa de realizar las mismas funciones de conguración, moni-toreo y control a través de un servidor web básico que responde a los mismos comandos cuando los recibe formando parte de la URL.
El sistema puede ser instalado sin necesidad de conexión a internet dado que la gestión está embebida en el hardware completamente. Sin embargo, existe la posibilidad mediante la creación de una cuenta de usuario, de registrar la unidad en los servidores de MiOS. Esto brinda funcionalidades extras como la localización de la unidad a través de internet,
25http://www.mios.com
ya que la unidad reporta su dirección IP hacia los servidores de la empresa. Tener la información de la IP permite el acceso remoto para control y monitoreo de la red.
Para la gestión de los dispositivos domóticos el sistema posee un mecanismo para permitir la inclusión de nuevos dispositivos mediante un botón en el panel frontal de la unidad que corre la rutina de emparejamiento. Una vez realizado el pareo de los dispositivos se puede ingresar a la interfaz web de conguración del dispositivo para conguración avanzada. 2.3.2. FoxyHouse
FoxyHouse27 es una empresa uruguaya dedicada al desarrollo de casas inteligentes. El
sistema desarrollado por ellos permite el acceso a la vivienda desde cualquier equipo que tenga internet, ya sea una computadora, un smartphone o tablet (aplicación FoxyHouse Remote). También cuentan con un control remoto que permite controlar los dispositivos estando dentro del hogar.
La tecnología utilizada es del tipo portadora, enviando la información por el cableado eléctrico de 220V, reutilizándolo para transformarlo en un canal de comunicación. El estándar domótico escogido por ellos para el armado de la red domótica es el PLCBus28,
sucesora de X10 (ver punto 5.3).
Para instalar el módulo de acceso web se conecta un equipo (FoxyHouse PlugIn) a uno de los puertos de red del router del hogar. Luego se congura un nuevo usuario para dicho sistema que permitirá el acceso a través del login desde la página web de FoxyHouse. Una vez ingresado al sistema, para encender una luz desde internet, los servidores de FoxyHouse reciben el pedido, identican qué casa es y envían un mensaje al módulo FoxyHouse PlugIn instalado. Este módulo reenvía la información por la corriente eléctrica y de ese modo llega a todos los controladores de la casa. Cada controlador tiene una dirección única y el que reconoce la suya en ese mensaje, enciende o apaga la luz.
Para acceder localmente a los dispositivos, y poder enviar un comando, se utiliza el control inalámbrico. Presionando el botón correspondiente, la información se transmite de forma inalámbrica hasta un receptor que envía el mensaje por la red eléctrica y de esa forma se distribuye hasta los controladores.
En cuanto a seguridad, FoxyHouse cuenta con protocolos de seguridad estándar, auten-ticación en todas las comunicaciones y encriptación para cifrar los datos. El acceso vía web si bien puede accederse por medio de SSL29 (ver punto 8.1), cuenta con protección
de contraseñas por cifrado y control de sesiones.
2.4. Arquitectura propuesta
Luego del estudio previo se decidió implementar un sistema cuya gestión se encuentre completamente en la nube. La razón para dicha elección de arquitectura basada en Cloud Computing es por el conjunto de ventajas que tiene esta arquitectura y que se desarrolló anteriormente en el punto 2.2.2. Se buscó que el sistema sea de fácil instalación, manteni-ble, escalamanteni-ble, con baja tasa de fallas y rápida recuperación en caso de que éstas ocurran. Por lo tanto, se migró toda la gestión del sistema, en la medida posible, hacia el servidor. La forma en que se realizó fue limitando la funcionalidad del hardware que corre en la casa a simplemente ser el puente entre la red domótica y el software de gestión.
La elección de esta solución permite el desarrollo de funcionalidades de alta demanda de procesamiento o almacenaje de datos, que requieren de servidores potentes. Ejemplos de estas funcionalidades pueden ser el procesamiento de señales de video en tiempo real, el almacenamiento posterior y nalmente el registro histórico de las variables sin límite de tiempo. También abre la posibilidad de utilizar todo tipo de canales de comunicación para noticar al usuario como son SMS, VoIP30o mensajería en la nube para comunicarse
con dispositivos móviles como Google Cloud Messaging de Android (Google)31 o Push
Notication Service de iOS (Apple)32.
La desventaja más importante de esta elección es la dependencia de la conexión a internet, que se podría minimizar si se cuenta con una conexión redundante múltiple canal como ADSL + 3G/4G.
Figura 2.3: Arquitectura básica
Se denen las siguientes áreas de un sistema domótico:
30VoIP: Voice over IP.
31http://developer.android.com/google/gcm/index.html
32
Domo
Un Domo es denido como un espacio físico donde está implementada la red domótica. Usuarios
Los usuarios son los dueños de cada Domo. Los usuarios son los encargados de denir un Domo en particular, y una vez denido el Domo, se puede dar acceso a otros usuarios de la red domótica.
Inputs - Interfaces de control
Los inputs son las interfaces de control que permiten interactuar con el sistema. Para dar soporte a las distintas interfaces de control, el sistema provee una API y cada input debe ajustarse a este protocolo para realizar cualquier operación.
Outputs - Acceso a los recursos
Para los outputs se desarrolló un modelo estándar de encapsulamiento, de modo que se pueda agregar soporte para distintos tipos de gateways y se puedan acoplar fácilmente al sistema. Generalizando las acciones y estados que se pueden realizar con los distintos endpoints (dispositivos nales como sensores o actuadores), siendo transparente para el sistema tratar con cualquiera de ellos. Para conseguir esta generalización, se ideó un mo-delo de abstracción de datos explicado en detalle en la Subsección 9.1.4. La descripción de los dispositivos que conforman la red de domótica fue inspirada por la capa Description de UPnP. Dado que el hardware adquirido nalmente no cumplía con la consigna de ser compatible con UPnP (ver Sección 7), es que se desarrolló una metadata conteniendo la descripción de las características del hardware para que el sistema sea capaz de controlar estos dispositivos. Para la comunicación entre el gateway y el sistema, un driver33
de-be ser implementado por cada estándar domótico que se quiera utilizar, facilitando las comunicaciones con el servidor.
Software de gestión
Es el software que se encarga de procesar todas las solicitudes, conoce todos los inputs, outputs, Domos y sus relaciones. Para poder brindar servicio a múltiples clientes desde
33Es el nombre que se le da a las piezas de software que permiten controlar algún sistema periférico,
el servidor se debió desarrollar una API34 adecuada. La API cuenta con controladoras
para cada uno de los módulos del sistema: usuarios, sesiones, dispositivos, domos, ga-teways y SMS. Esta arquitectura es escalable y exible a la hora de desarrollar nuevas funcionalidades. Para el presente proyecto se decidió utilizar una API estilo REST. Las ventajas de utilizar una arquitectura estilo REST son:
Escalabilidad.
Generalidad en el acceso, cualquier cliente HTTP es válido.
HTTP permite extender la operatividad mediante el uso de las cabeceras y a través de las URIs.
A partir de ahora el software de gestión también podrá ser llamado como API REST o SIMYCD a lo largo del proyecto.
2.4.1. Seguridad
Los aspectos de seguridad a tener en cuenta en la arquitectura propuesta son los siguientes: Protección de los datos que viajan por HTTP.
Manejo de la sesión de usuario.
Acceso al sistema desde otras interfaces de control.
Seguridad en la red domótica dependiendo del estándar domótico. Estos puntos son analizados en detalle en el capítulo de seguridad, Sección 8. 2.4.2. Implementación
De lo mencionado anteriormente se determina la arquitectura llevada a cabo en el proyecto. En la Figura 2.4 se ve un diagrama de la arquitectura propuesta. El mismo se resume en interfaces de control para usuarios con sus respectivas conexiones a la API REST, una base de datos que almacena la información, los drivers requeridos para la implementación del estándar domótico escogido, y los dispositivos correspondientes.
34API: Application Program Interface. Es una interfaz y conjunto de funciones y procedimientos
Figura 2.4: Arquitectura del sistema SIMYCD
Para el gateway se pensó en una interfaz que maneje las funcionalidades requeridas en un sistema domótico basadas en las características marcadas en la Subsección 1.2.
Los dispositivos al unirse a la red deberían describirse con archivos propios deniendo sus funciones y características, simulando lo que sería la etapa de Description en UPnP que podría ser a través de archivos de tipo XML. En este envío de información por parte de los dispositivos nales, se podría incluir información del fabricante, modelo, una lista de los comandos aceptados y parámetros de cada acción.
3. Selección de herramientas
En este capítulo se detalla el estudio y elección de las diferentes tecnologías y herramientas utilizadas en la elaboración del proyecto.
3.1. Plataforma de desarrollo
Para la elección del software y herramientas utilizadas se tomaron en cuenta los siguientes criterios:
Conocimientos previos. Rápida curva de aprendizaje.
Robustez y sencillez en su utilización. Factibilidad.
Bajos costos. 3.1.1. Servidor
Los requerimientos a la hora de seleccionar la infraestructura de hardware fueron que sea escalable y exible para soportar los servicios que se quisieran brindar. Otro tema a tener en cuenta es que debía ser asequible para poder montar una maqueta.
Para poder tomar la decisión de qué servidor sería el más adecuado, se estudió la viabilidad de instalar un servidor propio para este proyecto en especíco. Pero, teniendo en cuenta que se deseaba desarrollar un sistema escalable y con pretensiones de ser visto como un sistema integrador completo, se investigó la posibilidad de contratar un servidor en la web. Luego de estudiar las distintas opciones, se optó por contratar como servidor de prueba un VPS35en el proveedor GoDaddy Inc36, por ser un servicio conocido por los integrantes
del grupo. El VPS tiene un costo de 15 dólares y permite el control total del sistema con acceso root para la realización de tareas administrativas como instalación de software y creación de usuarios.
A continuación se detalla el estudio previo realizado para la elección de las herramientas de desarrollo.
35VPS: Virtual Private Server. Es un método que convierte un servidor físico en múltiples servidores
virtuales, comúnmente llamados máquinas virtuales.
Sistema operativo
El primer análisis a tomar en cuenta fue la búsqueda de un sistema operativo acorde para el proyecto. Se estudiaron las variantes entre una solución con Microsoft37 Windows y
otra con Linux.
Windows Es el nombre de la serie de sistemas operativos desarrollados y comercializados por Microsoft. Es el sistema operativo más difundido a nivel mundial para uso doméstico.38
Linux Es un sistema operativo con raíces en Unix. Su diferenciación con otros sistemas existentes en el mercado local es que es libre, lo que signica que no es necesario pagar licencias por el uso, y además es de código abierto.
En la siguiente Tabla 3.139 presentamos las diferencias entre ambos sistemas operativos
en cuanto a nuestras necesidades:
Tabla 3.1: Diferencias entre Microsoft Windows y Linux
37http://www.microsoft.com
38Usage share of operating systems (WIKIPEDIA, 2012) [online] [citado Noviembre 2012] Disponible
en internet: <http://en.wikipedia.org>
Finalmente, el sistema operativo adoptado fue Linux debido a las ventajas presentadas en los siguientes puntos analizados:
Licencia sin costo. Seguro.
Basado en plataformas Unix:
• Buena estabilidad.
• Corre sobre cualquier servidor.
• Muy baja probabilidad de malware y virus. • Sistema operativo multitarea.
Flexible.
Tecnología probada y ampliamente difundida. Fácil de administrar para usuarios avanzados. Servidor web
Para la elección del servidor web se analizaron dos sistemas diferentes: Apache40y NGINX41.
Apache es el más utilizado42. Gran parte de su éxito se debe a que es multiplataforma y
a que permite implementar diferentes lenguajes de programación como PHP43, Python y
Perl.
NGINX es un servidor web más reciente, ligero y también soporta multiplataformas. La principal diferencia con Apache, es que este último provee la información de manera sincrónica, esperando a que haya una respuesta para enviarla, mientras que NGINX lo realiza de manera asincrónica y por solicitud.44,45
Se optó por Apache, por ser un proyecto maduro y activo, conocido por los integrantes del grupo y ser uno de los más utilizados a nivel mundial. Se integra perfectamente con múltiples lenguajes de programación como PHP así como intérpretes SQL46como MySQL.
40http://www.apache.org 41http://www.nginx.org
42http://w3techs.com/blog/entry/most_popular_web_servers_by_country 43PHP: PHP Hypertext Pre-processor.
44http://wiki.nginx.org/Main
Lenguaje de programación
Para decidir el lenguaje de desarrollo del sistema, se estudiaron las opciones de JAVA y PHP.
PHP Se trata de un lenguaje de programación interpretado del lado del servidor con licencia de software libre. En la actualidad es ampliamente usado en entornos de desarrollo web por su facilidad de uso, su integración con HTML47 y su potencial
de uso en varios sistemas operativos. Tras la aparición de PHP5 se introdujeron cambios dándole mayor trascendencia al rendimiento, a la programación orientada a objetos (POO) y mejorando las conexiones a base de datos.48
JAVA Es un lenguaje de programación orientada a objetos desde sus inicios, independien-te de la plataforma de ejecución y además cuenta con una curva de aprendizaje muy rápida. Este lenguaje es ejecutado del lado del cliente enlenteciendo la experiencia del usuario. JAVA tiene una comunidad de más de nueve millones de desarrolladores que prueba, ajusta y amplía sus prestaciones. Es considerada una plataforma muy versátil, ecaz y portable.49
Entre ambas opciones, se escogió PHP para la implementación del server por diversas razones. Primero, porque se integra como módulo en el servidor Apache, siendo veloz, estable, seguro y simple. A esto se suma que es un lenguaje conocido por los miembros del equipo haciendo más sencilla la tarea de programación. Y nalmente, porque cuenta con una documentación accesible y completa así como una comunidad de desarrolladores activa a la cual solicitar soporte en caso de ser requerido.
Base de datos
Para la base de datos se estudiaron dos opciones diferentes: MySQL50 y PostgreSQL51.
PostgreSQL Es un sistema de gestión de bases de datos relacional orientado a objetos y libre. Permite que mientras un proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos.
47HTML: HyperText Markup Language. 48http://php.net/manual/es/faq.general.php 49http://www.java.com/es/about
MySQL Es un sistema de gestión de bases de datos relacional, multihilo y multiusuario, conocida a nivel mundial. Es muy utilizado en aplicaciones web, siendo una base de datos muy rápida en la lectura.
Finalmente se tomó MySQL por ser mundialmente conocida, integrarse perfectamente con PHP y Apache, open source, escalable, exible, de alto rendimiento, alta disponibilidad y de fácil gestión.52
3.1.2. Ambiente de desarrollo
Tras el estudio de las distintas variantes, se eligió la siguiente plataforma para el servidor: Sistema operativo Linux (CentOS release 5.6)
Servidor web Apache 2.2.3 PHP 5.3.3
MySQL 5.0.95
Todos los componentes tienen ciertas características en común, siendo software vigentes, activos, escalables y seguros. Son conocidos por los autores del proyecto, y todos los productos tienen comunidades de usuarios amplias con mucha documentación.
3.1.3. Herramientas de trabajo
Parte importante en la organización de cualquier proyecto es la selección de las herramien-tas de trabajo que se van a utilizar ya que ésherramien-tas facilitan y potencian los recursos con los que se cuenta. Para la implementación de este proyecto se decidió adoptar las siguientes herramientas y estándares de trabajo:
Control de versión y posibilidad de trabajo en equipo (Subversion) IDE53 (NetBeans54)
Gestor de documentos (Dropbox55) 52http://www.mysql.com/why-mysql
53IDE: Integrated Development Enviroment. Es un entorno de programación para desarrollar a través
de un conjunto de herramientas especícas.
Subversion
Subversion (SVN) es un sistema de control de cambios para piezas de software. Establece un esquema de trabajo organizado en el que cada integrante del equipo puede realizar los cambios que le parezcan necesarios en el código del sistema sin necesidad de pasar por encima lo que otro integrante realiza. En caso que el código escrito por uno de los miembros del equipo es nuevo, simplemente se agrega al código. En caso que sea diferente a lo existente, deberá actualizar y ser revisado por las partes para asegurar un correcto desempeño.
Para mantener el código fuente de todo el software que compone nuestro sistema utiliza-mos el Apache Subversion56, proyecto que pertenece a la Apache Software Fundation57.
Entorno de programación
El entorno de programación debe tener cualidades importantes como una interfaz simple y amistosa, además de ser potente y que sirva para los intereses del proyecto. Como entorno integrado de desarrollo se optó por NetBeans ya que además de soportar múltiples lenguajes de programación se integra perfectamente con SVN.
Gestión de proyecto
Una herramienta importante para la gestión de la documentación asociada al proyecto es el servicio que brinda Dropbox58, permitiendo compartir archivos y carpetas entre múltiples
usuarios de manera sincronizada y automática. Esta herramienta realiza un control de versión en los documentos de texto creados, permitiendo trabajar en forma simultánea a los miembros del equipo, sin perder información. Se creó una carpeta compartida que contiene toda la documentación de referencia, libros, artículos de interés y también la documentación del proyecto.
4. Interfaces de control
Todo sistema domótico cuenta con diversas interfaces para establecer la comunicación con los dispositivos nales. Estas entradas del sistema pueden ser desde las más conocidas e intuitivas, como es una interfaz web de gestión, hasta aplicaciones nativas para dispositivos móviles, mensajes SMS o un IVR59.
A continuación se detalla el estudio de las interfaces de control planteadas.
4.1. Investigación previa
4.1.1. SMS
El SMS es un servicio que permite el envío de mensajes de texto entre teléfonos móviles o teléfonos jos pertenecientes a la PSTN60, así como desde la web y otros dispositivos como
tablets. Inicialmente su función era la de permitir el envío de mensajes de control a los celulares por parte de las operadoras, los llamados MT-SM (Mobile Terminated Short Message). Luego se desarrolló la funcionalidad para que los mensajes también pudieran ser originados desde el terminal del usuario, siendo éste el mayor uso de hoy en día. A este mensaje se le llama MO-SM (Mobile Originated Short Message).
Quien se encarga de procesar los mensajes dentro de la red es el SMSC61, este software es
quien conoce las rutas para alcanzar los distintos destinos. El contenido de los mensajes está limitado a 160 caracteres de payload, además de contener los siguientes parámetros:
Fecha en que fue originado el envío (Timestamp). Tiempo de validez del mensaje.
Dirección de origen. Dirección de destino.
Número del SMSC que originó el mensaje.
Desde el punto de vista del sistema a desarrollar se vio como ventaja que está altamente difundido, es una funcionalidad estándar en todos los teléfonos móviles que se comerciali-zan actualmente, su uso es intuitivo para los usuarios y es barato en términos económicos.
59IVR: Interactive Voice Response.
Por otro lado, sus desventajas son principalmente que su entrega no está asegurada exis-tiendo hasta el día de hoy algunos fallos en los SMSC de cada operadora, y el payload está limitado imposibilitando el envío de grandes paquetes. Por último, la principal desventaja con la que cuenta esta interfaz, es que no es un sistema seguro debido a que el contenido del mensaje viaja en texto plano y puede ser leído fácilmente por cualquier persona que tenga acceso al SMSC o al celular del usuario.
4.1.2. Aplicación web
Una aplicación web es una pieza de software que se codica en un lenguaje soportado por los navegadores web en la que se confía la ejecución al navegador. La popularidad de este tipo de software se debe a que es independiente del sistema en que se corre la aplicación. Delega la conexión con el sistema operativo al navegador web. Los contenidos son generados en forma dinámica en el servidor antes de mostrarse al usuario. Permite que el usuario pueda interactuar a través de formularios y botones, y es capaz de mostrar contenidos multimedia de todo tipo.
El acceso se puede realizar desde cualquier dispositivo con conexión a internet que dis-ponga un cliente web. Ésta es una gran ventaja ya que permite interactuar con el sistema desde cualquier parte con un control total. La potencia de una aplicación web permite incorporar contenidos multimedia como cámaras de seguridad y escuchar audio en vivo, siempre de forma segura a través de un control de usuarios y permisos.
Con una aplicación web se obtiene alta disponibilidad, pudiéndose realizar consultas y enviar comandos en cualquier parte del mundo donde se tenga acceso a internet y a cualquier hora.
4.1.3. Aplicaciones nativas para dispositivos móviles
Las aplicaciones nativas han tenido un gran auge en los últimos años debido a que los teléfonos móviles de alta performance, también llamados smartphones, aumentaron su capacidad de procesamiento de forma considerable y su costo ha ido en descenso. La aparición de nuevos sistemas operativos especícos para móviles como iOS de Apple o Android de Google dan una plataforma de desarrollo potente que también colabora para que muchos desarrolladores y empresas se enfoquen en generar nuevas aplicaciones. Las aplicaciones pueden ser descargados desde tiendas de aplicaciones o mediante descarga directa desde un ordenador.
modelos de fabricantes como Samsung se incluyen sensores como GPS62, acelerómetro,
giroscopio, sensor de proximidad, brújula, barómetro, termómetro, entre otros. Para la domótica, el acceso a esta información permite realizar funciones avanzadas como por ejemplo apagar la calefacción cuando uno se va de casa automáticamente mediante el uso de los satélites de GPS, o el encendido de luces a distancia.
4.1.4. IVR
El IVR consiste en un sistema desarrollado para uso telefónico capaz de interactuar con el usuario a través de grabaciones de voz, escogiendo opciones de un menú mediante el discado de números o el reconocimiento de voz. Ejemplos conocidos pueden ser el llamado a centrales de taxi o call centers. La solución IVR sería mediante la tecnología DTMF63 o ASR64 las cuales tienen como principal ventaja facilitar el acceso al sistema
para personas con ceguera. Sin embargo, como opción es menos amistosa que el resto de las interfaces mencionadas anteriormente, pero tiene como virtud la posibilidad de acceder al sistema desde cualquier tipo de líneas telefónicas tanto jas como móviles incrementando la accesibilidad al sistema.
4.1.5. Tablero de control
Es una opción ampliamente difundida entre los productos comerciales. Este sistema ori-ginalmente comenzó basándose en botones o interruptores para el manejo de las luces, calefacción y demás artefactos de un hogar. Más cerca en el tiempo se empezó a trabajar en paneles de pantalla táctil similar a lo que sería una aplicación en una tablet.
Este tipo de soluciones con interruptores viene de la mano con sistemas de domótica que se propagan por la red eléctrica o por un cableado propio, aunque los principales protocolos de domótica actuales también adoptaron este tipo de soluciones.
4.2. Elección de las interfaces de control
Basado en las diferentes interfaces de control explicadas en el punto anterior y teniendo en cuenta los tiempos asignados para la investigación e implementación de dichas inter-faces, fueron determinadas dos interfaces diferentes para desarrollar en el sistema. Esto no signica que en fases posteriores al proyecto, sea para resolver algún requerimiento
especíco o con el objetivo de ampliar el sistema, se pueden incorporar nuevas vías de acceso al mismo. Por lo pronto, los medios de interacción con el usuario elegidos fueron la interfaz web y el acceso por SMS.
La elección de la interfaz web se entiende como un medio casi por defecto en la realización de cualquier sistema con acceso remoto como opción para brindar la interfaz de congura-ción, así como también para el monitoreo de los Domos de los usuarios. También permite implementar funciones más complejas que en las demás interfaces estudiadas.
En cuanto a los SMS como medio de entrada, se vio que es una interfaz ampliamente difundida y de fácil uso para el usuario. Es una forma de estar en cualquier momento en contacto con el hogar además de tener un costo de comunicaciones muy bajo.
A continuación, se desarrollan estas dos interfaces de control, recorriendo las opciones que fueron manejadas y el por qué de la elección nal en cada caso.
4.3. Interfaz web
4.3.1. Herramientas utilizadas
En el caso de la interfaz web, al ser utilizado internet como medio, es posible el acceso desde cualquier ordenador, tablet o celular con posibilidad de navegación web. No hay restricciones de hardware para este tipo de entradas sino que simplemente se debió denir las herramientas con las que realizó la interfaz. Estas herramientas son las mismas tecno-logías que en el servidor, es decir, utilizando PHP para la programación, base de datos MySQL, y apoyándose en un framework de desarrollo como lo es Kohana65.
MySQL y PHP
Luego de escoger estas dos herramientas para el desarrollo del servidor y su base de datos, se determinó seguir trabajando en el mismo sentido con la interfaz web del proyecto. Esta decisión fue tomada pensando en una integración simple entre las partes.
Kohana
Kohana es un framework desarrollado por la Kohana Software Foundation para aplicacio-nes web para PHP5. Kohana es un conjunto de herramientas para la construcción de sitios
web que incluye componentes útiles y reutilizables que facilitan la tarea. Entre las funcio-nalidades a destacar se encuentran el manejo de sesiones de usuarios, manejo transparente de la conexión con la base de datos, validación de formularios y datos, librería de manejo de imágenes y registro de errores. Está basado en el paradigma MVC66 separando la vista
del modelo a través del uso de una controladora que es quien se encarga del manejo del ujo de datos que comunica el modelo y la vista. La implementación de un framework con este modelo simplica el desarrollo debido a la exibilidad que proporciona la separación de secciones, permitiendo realizar cambios en cada una de ellas de forma individual. 4.3.2. Implementación de la interfaz web
En el caso de esta maqueta la interfaz web servirá como administrador y usuario del mismo. De esta manera el administrador puede crear un usuario, y luego con las mismas credenciales puede ejecutar las funciones pertinentes en un Domo.
Para escoger el estilo de interfaz web deseado se requirió entender las necesidades de una solución de domótica. Una interfaz web para este tipo de soluciones debe contar por lo menos, y a grandes rasgos, con las siguientes características:
Autenticación para inicio de sesión. Cierre de sesión.
Control sobre las funciones generales del ambiente.
Control sobre las funciones particulares por dispositivo (controlador o sensor). Para el desarrollo de la interfaz web se utilizó PHP, HTML y AJAX67.
4.3.3. Funciones
Un Domo puede tener distintos estándares de domótica y un conjunto de dispositivos nales diferentes. Se optó por implementar una interfaz que se genere dinámicamente mediante el descubrimiento de la red domótica para el gateway seleccionado, desplegando todas las funciones existentes por cada dispositivo que sea encontrado en el ambiente.
66MVC: Model View Controller.
67AJAX: Asynchronous JavaScript And XML. Hoy en día es una técnica de desarrollo web muy
Una vez que la red sea descubierta, toda esta información es almacenada en la base de datos. Es esta base de datos quien traerá la información para generar la interfaz al usuario. El detalle de cómo ejecutar las funciones e interpretación de las respuestas se encuentra desarrollado en el punto 9.2.6.
4.4. Módulo SMS
4.4.1. Investigación previa
Se jó como requerimiento para el desarrollo de este módulo que sea una solución autó-noma que se conecte al server a través de la API y que se encuentre alojada en la nube en lo posible. Para esto se manejaron distintas opciones:
Exemys GTS Kannel Servicio web Android Exemys GTS
En el caso de la inclusión del sistema vía SMS, se investigó un único caso de posible gateway SMS que incluya hardware necesario para la realización del mismo (los otros tipos de gateways están basados en software principalmente). Este caso centrado en hardware es a través de un dispositivo llamado GTS Gateway68 (ver Figura 4.169).
El GTS es un dispositivo de comunicación inalámbrica vía SMS y el mismo se compone de un puerto de comunicaciones serie, entradas analógicas y digitales, y salidas digitales según el modelo correspondiente.
Por medio del GTS es posible enviar y recibir mensajes por el puerto serie, actuar sobre las salidas, conocer el estado de las entradas y otras funcionalidades.
68Este gateway es conocido por uno de los autores del proyecto al tratarse de un producto comercial
en el ambiente laboral, propiedad de Fidemar S.A.
69EXEMIS. [online] [citado Agosto 2012]. Disponible en internet:
Figura 4.1: GTS Gateway
Como ventajas, el GTS además de ser manejable a través de un puerto serie que entregaría la información recibida por SMS, también puede proporcionar información para ser leída por el puerto de la computadora.
La principal desventaja encontrada fue el alto costo que tiene, llegando a los 600 dólares. Kannel
Kannel es un proyecto open source como SMS y WAP70 Gateway. Este sistema utiliza
la licencia BSD71. Tiene como uno de sus principales objetivos, ser un gateway de alta
disponibilidad donde se puedan ejecutar muchas transacciones simultáneas.
Kannel está orientado a trabajar directamente con el SMSC, siendo en esta conexión directa con un centro de mensajería cuando se alcanzan altos rendimientos aunque la disponibilidad depende de la conexión con la red GSM72. Para solucionar esto, también
hay conexiones mediante módem GSM o teléfono móvil con módem incluido.
Una de las principales ventajas de Kannel es ser moldeable al usuario, aunque para ello hay que tener un conocimiento avanzado del mismo. Sería una solución a tener en cuenta en caso de avanzar con el proyecto y tener que soportar grandes cantidades de tráco en un futuro.
Servicio web
Se entiende por un servicio web un servicio provisto por una compañía que ofrece el envío de mensajes SMS a nivel global para el uso privado de empresas o grupos publicitarios
70WAP: Wireless Application Protocol.
71BSD son las siglas de Berkeley Software Distribution. Es una licencia de software libre permisiva
basada en Unix.
mediante la venta de paquetes de mensajería. Estos paquetes suelen venderse de a miles y sus principales características se dan en su bajo costo y facilidad de uso.
Durante el estudio de estos servicios se analizó el caso de Clickatell73 que provee este tipo
de paquetes de mensajes mediante una API desarrollada por la compañía. Para poder utilizar esta solución se debería crear una capa por encima de la provista por el proveedor de los mensajes, con el n de hacerlo funcionar con la API del sistema. Clickatell ofrece además el servicio de shortcode el cual consiste en un número corto para la recepción de mensajes y el centro de mensajería local lo procesaría de forma personalizada, así como sucede hoy en día con varias empresas que ofrecen servicios como el estacionamiento, internet, chistes y otros.
Otro servicio similar estudiado fue Twilio74, que también tiene una interfaz propia para
el envío de mensajería. Es similar en su funcionamiento con Clickatell, pero cuenta con ciertas diferencias:
1. El servicio de número virtual de Twilio cuesta U$S 1 por mes y los mensajes enviados a Uruguay U$S 0.025, mientras que Clickatell cuesta U$S 10 por mes y los SMS a Uruguay U$S 0.020.
2. La mínima compra es de U$S 20 para Twilio, mientras que Clickatell exige un mínimo de U$S 200.
3. Clickatell tiene números para Uruguay, mientras que Twilio no cuenta con números nacionales.75
Android
Android es un sistema operativo basado en el kernel de Linux y desarrollado por Goo-gle para dispositivos móviles como smartphones o tablets. Android es una plataforma de código abierto, portable y exible que fue diseñado desde cero para permitir a los desa-rrolladores crear aplicaciones móviles aprovechando al máximo todo lo que un dispositivo puede ofrecer. Por ejemplo, una aplicación puede llamar a cualquiera de las funciones principales del teléfono, tales como hacer llamadas, enviar mensajes de texto o utilizar la cámara, lo que permite a los desarrolladores crear mejores experiencias de usuario. Además, utiliza una máquina virtual Dalvik76 que está optimizada para requerir poca
memoria.
73http://www.clickatell.com 74http://www.twilio.com
75Los precios y características de ambos servicios fueron tomados desde las páginas web ociales de
cada servicio.
