Daniel Eduardo Martínez Vargas, "Sistema de Domótica para Control y Supervisión de Una Habitación de Manera Remota"

SISTEMA DE DOMTICA PARA CONTROL Y SUPERVISIN DE UNA
HABITACIN DE MANERA REMOTA
DANIEL EDUARDO MARTNEZ VARGAS
PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERA ELECTRNICA
BOGOT, D. C.
SISTEMA DE DOMTICA PARA CONTROL Y SUPERVISIN DE UNA
HABITACIN DE MANERA REMOTA
DANIEL EDUARDO MARTNEZ VARGAS
PROYECTO DE GRADO
P RESENTADO COMO REQUISITO PARCIAL
P ARA OPTAR AL TTULO DE
INGENIERA ELECTRNICA
DIRECTOR:
ING. DAVID FERNANDO SUREZ DAZ, M.SC.

FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERA ELECTRNICA
BOGOT, D. C.
-2-
FACULTAD DE INGENIERA
CARRERA DE INGENIERA ELECTRNICA
RECTOR MAGNFICO:
R.P. JORGE HUMBERTO PELEZ PIEDRAHITA, S.J.
DECANO ACADMICO:
Ing. JORGE LUIS SNCHEZ TLLEZ, M.Ed.
DIRECTOR DE CARRERA:
Ing. JAIRO ALBERTO HURTADO LONDOO, Ph.D.
DIRECTOR DEL PROYECTO:

Ing. DAVID FERNANDO SUREZ DAZ, M.Sc.
-3-
NOTA DE ADVERTENCIA
La Universidad no se hace responsable de los conceptos emitidos por algunos de sus alumnos en los
proyectos de grado. Solo velar porque no se publique nada contrario al dogma y la moral catlica y
porque no contengan ataques o polmicas puramente personales. Antes bien, que se vea en ello el anhelo
de buscar la verdad y la justicia.
Artculo 23 de la Resolucin No. 13, del 6 de

julio de 1946, por la cual se reglamenta lo
concerniente a Tesis y Exmenes de Grado en la
Pontificia Universidad Javeriana.
-4-
A mi mam, por su cario y apoyo incondicional.
A mi pap, por ser un modelo en mi vida y por el jugo de naranja todas las maanas.
A Andrs y Santi, por rerse de mis chistes malos.
A David, por su paciencia y excelentes archivos de Excel.
A Felipe y a Ivonne, por sus cartas de aliento y natillas caseras.
A Stella, por sus clases de canto, y a Chiqui, por las velas al Espritu Santo.
A todos mis familiares y amigos que me han brindado un abrazo y una palabra de apoyo.
Hasta luego y gracias por el pescado.
-5-
TABLA DE CONTENIDO
LISTA DE TABLAS ...................................................................................................................... 8
LISTA DE ILUSTRACIONES..................................................................................................... 9
LISTA DE ANEXOS ................................................................................................................... 11
1. INTRODUCCIN ................................................................................................................. 12
2. MARCO CONCEPTUAL ..................................................................................................... 14

2.1 Domtica.............................................................................................................................................. 14
2.2 Internet de las cosas (IoT) .................................................................................................................... 14
2.3 Wireless Sensor Networks ................................................................................................................... 15
2.4 Ordenadores de placa reducida ............................................................................................................. 16
2.5 Framework OSGi ................................................................................................................................. 16
2.5.1 Arquitectura OSGi ............................................................................................................................ 16
2.5.2 OpenHAB ......................................................................................................................................... 17
2.5.2.1 Arquitectura Software OpenHAB .................................................................................................. 17
2.5.2.2 Canales de comunicacin en OpenHAB ........................................................................................ 17
3. ESPECIFICACIONES .......................................................................................................... 19
3.1 Gateway ............................................................................................................................................... 20
3.1.1 Hardware........................................................................................................................................... 20
3.1.2 Software ............................................................................................................................................ 20
3.1.3 Motor de sincronizacin .................................................................................................................... 21
3.2 Interfaz Grfica .................................................................................................................................... 21
3.3 Sensores y Actuadores ......................................................................................................................... 22
3.3.1 Sensor de movimiento ....................................................................................................................... 22
3.3.2 Sensor de consumo ........................................................................................................................... 22
3.3.3 Actuador para controlar una lmpara ................................................................................................ 23
3.4 Base de datos........................................................................................................................................ 23
4. DESARROLLO DEL PROYECTO ..................................................................................... 24

4.1 Preparacin de la plataforma ................................................................................................................ 24
4.1.1 Caractersticas del servidor ............................................................................................................... 24
4.1.2 Ordenador de placa reducida (SBC) .................................................................................................. 25
4.1.2.1 Comparacin de ordenadores de placa reducida............................................................................. 25
4.1.2.2 Seleccin de RaspberryPi ............................................................................................................... 25
4.1.3 Distribuciones de Linux disponibles para la RaspberryPi ................................................................. 26
4.1.3.1 Seleccin de la distribucin Raspbian ............................................................................................ 27
4.1.3.2 Instalacin y configuracin de Raspbian ........................................................................................ 27
4.2 OpenHAB ............................................................................................................................................ 27
4.2.1 Configuracin de OpenHAB ............................................................................................................. 28
-6-
4.2.2 Items de OpenHAB ........................................................................................................................... 29
4.2.3 Codificacin de los nombres de los items ......................................................................................... 30
4.2.4 Configuracin de la persistencia ....................................................................................................... 30
4.3 Protocolo inalmbrico .......................................................................................................................... 31
4.3.1 Sistemas inalmbricos tradicionales .................................................................................................. 31
4.3.2 ZigBee y Z-Wave .............................................................................................................................. 31
4.3.3 Seleccin del Protocolo de Comunicacin ........................................................................................ 32
4.3.4 Creacin de la red Z-Wave................................................................................................................ 32
4.4 Sensores y actuadores .......................................................................................................................... 33
4.4.1 Parmetros de configuracin los dispositivos.................................................................................... 33
4.4.2 Aeon Labs Aeotec Z-Wave Multisensor ........................................................................................... 34
4.4.3 AeonLabs - Z-wave Smart Energy Switch (DSC06106-ZWUS)....................................................... 35
4.4.4 Jasco Z-Wave Lighting Control On/Off Switch, (45609).................................................................. 36
4.5 Arquitectura del Software .................................................................................................................... 36
4.5.1 Bases de datos ................................................................................................................................... 36
4.5.1.1 Persistencia MySQL de OpenHAB ................................................................................................ 37
4.5.1.2 Tabla switch_next_state ................................................................................................................. 38
4.5.2.1 Entorno de programacin ............................................................................................................... 39
4.5.2.2 sync_engine.c ................................................................................................................................. 40
4.5.2.3 http_request.c ................................................................................................................................. 42
4.5.3 Interfaz grfica .................................................................................................................................. 43
4.5.3.1 Ambiente de desarrollo .................................................................................................................. 44
4.5.3.2 Aspecto visual ................................................................................................................................ 44
4.5.3.3 Estructura ....................................................................................................................................... 45
4.5.3.4 Autogenerado de los widgets ......................................................................................................... 48
4.5.3.5 Diseo para celulares ..................................................................................................................... 48
5. ANLISIS DE RESULTADOS ............................................................................................ 50

5.1 YSlow y PageSpeed Insights ................................................................................................................ 50
5.2 Compatibilidad del sistema .................................................................................................................. 51
5.3 Estabilidad del sistema ......................................................................................................................... 54
5.3.1 La red Z-Wave .................................................................................................................................. 54
5.3.2 Log de OpenHAB ............................................................................................................................. 55
5.3.4 Rendimiento de la RaspberryPi ......................................................................................................... 56
5.4 Anlisis econmico del sistema ........................................................................................................... 57
6. CONCLUSIONES.................................................................................................................. 58
7. BIBLIOGRAFA.................................................................................................................... 59
ANEXOS....................................................................................................................................... 61
-7-
LISTA DE TABLAS
Tabla 1 Especificaciones Hardware del Gateway ....................................................................................... 20

Tabla 2 Especificaciones del adaptador USB Z-Wave ............................................................................... 20
Tabla 3 Especificaciones Software del Gateway ........................................................................................ 20
Tabla 4 Especificaciones del motor de sincronizacin en el Gateway ........................................................ 21
Tabla 5 Especificaciones de la interfaz grfica........................................................................................... 21
Tabla 6 Diagramacin del widget de dispositivo ........................................................................................ 22
Tabla 7 Especificaciones del sensor de movimiento .................................................................................. 22
Tabla 8 Especificaciones del sensor de consumo ....................................................................................... 23
Tabla 9 Especificaciones del actuador para controlar una lmpara ............................................................ 23
Tabla 10 Especificaciones base de datos .................................................................................................... 23
Tabla 11 Caractersticas del servidor de HeliconiaTech ............................................................................. 24
Tabla 12 Comparacin de Ordenadores de placa reducida [7] ................................................................... 25
Tabla 13 Distribuciones Linux de propsito general para la RaspberryPi .................................................. 26
Tabla 14 Descripcin de la funcin de las carpetas en la configuracin de OpenHAB .............................. 29
Tabla 15 Campos para definicin de un item en OpenHAB ....................................................................... 29
Tabla 16 Campos para denominacin de un item ....................................................................................... 30
Tabla 17 Sistemas Wireless Tradicionales ................................................................................................. 31
Tabla 18 ZigBee vs Z-Wave ...................................................................................................................... 32
Tabla 19 Estructura tabla items .................................................................................................................. 37
Tabla 20 Estructura tablas item# ................................................................................................................ 37
Tabla 21 Descripcin tabla switch_next_state ............................................................................................ 38
Tabla 22 Bibliotecas usadas en el motor de sincronizacin ........................................................................ 39
Tabla 23 Variables de sync_engine.c ......................................................................................................... 40
Tabla 24 Variables de http_requesst.c ........................................................................................................ 42
Tabla 25 Principales selectores CSS .......................................................................................................... 45
Tabla 26 Compatibilidad de la interfaz grfica con diferentes dispositivos ................................................ 51
Tabla 27 Costo de los elementos del sistema ............................................................................................. 57
-8-
LISTA DE ILUSTRACIONES
Ilustracin 1 Inicio IoT entre el 2008 y el 2009 [1] .................................................................................... 14

Ilustracin 2 Wireless sensor network data path......................................................................................... 15
Ilustracin 3 Tamao representativo SBC. ................................................................................................. 16
Ilustracin 4 Arquitectura OSGi ................................................................................................................. 16
Ilustracin 5 Arquitectura software OpenHAB .......................................................................................... 17
Ilustracin 6 Canales de Comunicacin OpenHAB .................................................................................... 18
Ilustracin 7 Diagrama general del proyecto .............................................................................................. 19
Ilustracin 8 Diagrama de flujo del Sistema ............................................................................................... 19
Ilustracin 9 Esquema para el sensor de consumo...................................................................................... 22
Ilustracin 10 Ordenador de placa reducida RaspberryPi ........................................................................... 26
Ilustracin 11 rbol de carpetas de runtime de OpenHAB ........................................................................ 27
Ilustracin 12 rbol de la carpeta configurations de OpenHAB ................................................................ 28
Ilustracin 13 Diagrama de conexin un red tipo mesh .............................................................................. 31
Ilustracin 14 Configuracin Z-Wave de HABmin .................................................................................... 33
Ilustracin 15 Parmetros XML de los nodos Z-Wave............................................................................... 34
Ilustracin 16 Rango efectivo de deteccin de movimiento ....................................................................... 34
Ilustracin 17 Parmetros Z-Wave del Multisensor Aeonlabs .................................................................... 35
Ilustracin 18 Parmetros Z-Wave del Smart Energy Switch ..................................................................... 35
Ilustracin 19 Arquitectura Software ......................................................................................................... 36
Ilustracin 20 Diagrama de la base de datos tesisdb ................................................................................... 37
Ilustracin 21 IZQ: Organizacin entorno de programacin del motor de sincronizacin; DER: Fuente del
motor de sincronizacin ............................................................................................................................. 39
Ilustracin 22 Ambiente de desarrollo de la interfaz grfica ...................................................................... 44
Ilustracin 23 Ejemplo de retroalimentacin al usuario sobre el widget .................................................... 45
Ilustracin 24 Ubicacin del men y las pginas en la interfaz grfica ...................................................... 46
Ilustracin 25 Ejemplo de un widget. Sensor de movimiento activado. ..................................................... 46
Ilustracin 26 Barra de navegacin de la pgina stats ................................................................................ 47
Ilustracin 27 Tendencia de los tamaos de pantalla en enero del 2014 ..................................................... 48
Ilustracin 28 Diagramacin de la interfaz grfica para menos de 768px .................................................. 48
Ilustracin 29 Diagramacin de la interfaz grfica entre 768px y 1022px.................................................. 49
Ilustracin 30 Diagramacin de la interfaz grfica para ms de 1022px .................................................... 49
-9-
Ilustracin 31 Resultado de gtmetrix para la interfaz grfica ..................................................................... 51
Ilustracin 32 Captura de pantalla iPhone 4s. Diagramacin de la interfaz grfica para menos de 768px.. 52
Ilustracin 33 Captura de pantalla modo landscape de LG G PAD 8.3. Diagramacin para pantalla entre
768px y 1022px.......................................................................................................................................... 53
Ilustracin 34 Capturas de pantalla en el iPhone 4s de las estadsticas de Power, ON-OFF Switch, PIR
Sensor y Luminance ................................................................................................................................... 53
Ilustracin 35 Capturas de pantalla del iPhone 4s cambiando orientacin de portrait a landscape ............ 54
Ilustracin 36 Administrador Z-Wave de HABmin con todos los dispositivos vivos ................................. 55
Ilustracin 37 Uso CPU IZQ: Durante inicializacin de OpenHAB IZQ: Todos los servicio de OpenHAB
cargados ..................................................................................................................................................... 56
- 10 -
LISTA DE ANEXOS
ANEXO 1: ACRNIMOS ......................................................................................................................... 61

ANEXO 2: PREPARACIN DE LA PLATAFORMA ............................................................................. 63
ANEXO 3: CONFIGURACIN DE OPENHAB ...................................................................................... 64
ANEXO 4: MOTOR DE SINCRONIZACIN .......................................................................................... 65
ANEXO 5: INTERFAZ GRFICA ........................................................................................................... 65
ANEXO 6: OPENHAB - RUNTIME ......................................................................................................... 65
ANEXO 7: IMGENES DE LOS DISPOSITIVOS .................................................................................. 66
- 11 -
1. INTRODUCCIN
La tendencia del Internet de las Cosas (IoT por sus siglas en ingls) indica que para el ao 2020 ms de 30
mil millones de dispositivos estarn conectados a internet [1], lo que ha creado una expectativa muy alta
sobre cmo estos dispositivos interactuarn entre ellos y de cmo la vida de las personas cambiar cuando
todos los objetos de su entorno dispongan de capacidad inalmbrica.
Para el mismo 2020 las proyecciones indican que en un hogar comn se encontraran ms de 30
dispositivos todos conectados a internet [1]. Teniendo esto en cuenta, es evidente la necesidad de una
integracin a travs de algn tipo de sistema de control intuitivo, que agrupe todos estos dispositivos y que
le facilite al usuario la interaccin con su entorno.
En la actualidad es posible crear, a un precio razonable, ambientes inteligentes construidos alrededor de
dispositivos basados en tecnologas inalmbricas ya disponibles comercialmente. Sin embargo, el modo en
que estos dispositivos se relacionan e interactan entre s, su control y su facilidad de uso, son
problemticas que no se han resuelto completamente y sobre las cuales muchas compaas actualmente se
encuentran trabajando, razn que ha dificultado su amplia distribucin.
Otro motivo que ha ocasionado que los sistemas de automatizacin residencial (domtica) no gocen de
una amplia distribucin, es la falta de una interfaz de usuario comn e intuitiva. Las soluciones
disponibles en el mercado vienen integradas a aplicaciones cerradas y de propiedad de una compaa, por
lo cual el usuario est obligado a usar diferentes programas o dispositivos para poder controlar su entorno.
La realizacin de este trabajo de grado busca acercarse a la solucin de estas problemticas a travs del
diseo e implementacin de un sistema de domtica para un espacio pequeo y controlado, en el cual el
control y la supervisin de los dispositivos se realice de manera remota a travs de internet. Con una
cantidad fija y limitada de dispositivos es posible delimitar cules son los requerimientos necesarios para
la integracin de stos en ambientes ms vastos y con ms variables. A partir de este punto, a este espacio
controlado que contiene los dispositivos se le conocer con el nombre de habitacin.
Las potenciales variables que un usuario quisiera supervisar dependen de la funcin de la habitacin. Por
ejemplo, en una bodega de alimentos as como en un invernadero son de especial inters la temperatura y
la humedad, mientras que en un espacio residencial la iluminacin y la deteccin de presencia pueden
llegar a ser muy tiles. Tomando esto en consideracin, los dispositivos para poblar la habitacin se
escogieron teniendo en cuenta que la informacin que stos permitan visualizar sea de especial inters
para un usuario residencial, le generen beneficios reales y le permitan interactuar con el espacio en formas
que antes no le eran posibles. Las variables escogidas para ser supervisadas y/o controladas fueron:
La iluminacin, mediante un interruptor conectado a una lmpara.
El movimiento, con un sensor PIR.
La potencia instantnea de entrada de un dispositivo conectado a una toma de corriente con sensor
de consumo.
El uso de tecnologas inalmbricas fue importante durante la concepcin de este proyecto debido a su
precio razonable y a su poco impacto en trminos de instalacin. Los sensores, actuadores y el sistema de
control, se comunican entre s a travs de un protocolo inalmbrico de bajo consumo orientado a
domtica, soportado por el framework OSGi. En la seccin 4.3 de este documento se evalan los
principales protocolos inalmbricos orientados a domtica y se selecciona el ms apropiado para esta
aplicacin.
La arquitectura software del sistema de automatizacin planteada en la seccin 4.5 de este documento, se
dise aprovechando las ventajas que ofrece un framework OSGi open-source orientado a domtica,
permitiendo su uso sin ningn costo y libre de regalas [2]. Adicionalmente se implement un software
que acta como motor de sincronizacin entre el framework, encargado de enviar y recibir los comandos y
estados de los sensores y actuadores, y la interfaz de usuario, accesible mediante internet.
- 12 -
Para la seleccin del hardware, donde vienen ejecutados el framework OSGi y el motor de sincronizacin,
se busc una plataforma de gran flexibilidad, bajo costo y consumo, caractersticas de los ordenadores de
placa reducida. En la seccin 4.1.2 de este documento se compararon diferentes opciones y se seleccion
el ms adecuado para el sistema de domtica desarrollado.
La interaccin del usuario con los sensores y actuadores en la habitacin se realiza a travs de una interfaz
grfica web accesible desde internet, implementada como parte de este proyecto. Dicha interfaz de usuario
permite: controlar el estado de un interruptor conectado a una lmpara (encendido/apagado), supervisar el
estado de un sensor de movimiento y supervisar el consumo de un dispositivo conectado a una toma de
corriente.
Finalmente, en la seccin 5 del documento, se realiza un anlisis para verificar y evaluar el
funcionamiento del sistema, considerando factores como su rendimiento, facilidad de uso, compatibilidad
entre diferentes plataformas, entre otros.
Las implicaciones de este proyecto van ms all de la creacin de un hogar inteligente. Desde el punto de
vista econmico, el proyecto se ve justificado teniendo en cuenta que el mercado de la domtica en
Colombia y Latinoamrica tiene pocos actores, as que una insercin temprana con un rpido diseo y
desarrollo del producto podra convertirse en una muy buena oportunidad de emprendimiento. Adems,
con modificaciones a la interfaz de usuario y la inclusin de sensores para supervisar datos fisiolgicos,
usuarios con discapacidad podran ganar independencia adems de seguridad, salud y bienestar. As
mismo, teniendo en cuenta que se usaron tecnologas y protocolos estndar fcilmente escalables, las
conclusiones de este proyecto son extrapolables para la implementacin de ambientes con ms
dispositivos.
- 13 -
2. MARCO CONCEPTUAL
2.1 Domtica
En los aos 90 la gran mayora de viviendas comenzaron a interactuar con: diversos dispositivos
electrnicos regulares como neveras y televisores; aparatos de comunicacin, como telfonos y faxes; y
dispositivos de cmputo, como computadores. El funcionamiento de cada uno de ellos requera un sistema
de cableado dedicado y muchas veces diferente. Todos estos sistemas usaban distintos tipos de
comunicacin y conducan mltiples tipos de seales completamente independientes las unas de las otras.
Bajo este escenario surge la necesidad de crear un sistema unificado de redes [3].
La clave para controlar todos los dispositivos de manera conjunta recae an en la habilidad de los
productos para comunicar su estado. Hasta 1993, las redes de comunicacin para domtica empleaban
medios cableados para la interconexin de los dispositivos [3], sin embargo, los problemas generados por
el uso fsico de redes cableadas y la dificultad de su instalacin no permitieron una completa introduccin
de soluciones de este tipo en el mercado. Esto cre la necesidad de desarrollar sistemas de fcil instalacin
e impuls el desarrollo y la implementacin de sistemas ms flexibles. De esta manera se introduce por
primera vez el concepto de domtica de tipo inalmbrica (wireless), usando dispositivos que se comunican
a travs de redes de control y automatizacin sin la presencia de cables entre ellos.
Durante la dcada pasada, grandes avances en internet, la telefona mvil y TCP/IP han dado como
resultado muchos dispositivos y soluciones de automatizacin para hogares que hacen uso de sus propios
sistemas y protocolos de comunicacin, entre ellos: Wi-Fi, enfocado principalmente a conexiones y hubs
de internet; Bluetooth, desarrollado como alternativa de baja potencia para la transferencia de datos entre
dispositivos; Z-Wave, orientado a la domtica de ltima generacin y seguridad en el hogar; y ZigBee,
orientado a sensores para el hogar y dispositivos de supervisin.
2.2 Internet de las cosas (IoT)

IoT es el punto temporal en el cual habr ms objetos o cosas que personas conectadas a internet [1].
Esta tendencia crea la necesidad de recolectar, analizar y distribuir grandes cantidades de datos, que
pueden ser convertidos en informacin y conocimiento.
Ilustracin 1 Inicio IoT entre el 2008 y el 2009 [1]
En los ltimos aos, internet ha mantenido un estado de desarrollo estable y constante pero no
significativo. En este contexto, IoT se vuelve inmensamente importante porque es la primera evolucin
real del internet, al constituirse como una nueva etapa que conducir el desarrollo de aplicaciones
revolucionarias con el potencial de mejorar la manera en que las personas viven, estudian, trabajan y se
entretienen.
- 14 -
Actualmente todos los sensores y dispositivos producen datos individuales que no son procesados en
conjunto, pero si estos volmenes de informacin son analizados es posible identificar patrones y generar
resultados potenciales. IoT incrementa dramticamente la cantidad de datos disponibles para procesar, y
esto, sumado a la habilidad del internet para comunicar la informacin, permitir acelerar el desarrollo y el
avance de la tecnologa. Dado que los humanos avanzan y evolucionan convirtiendo datos en informacin,
conocimiento y desarrollo, IoT tiene el potencial de cambiar el mundo que conocemos, de una manera
positiva.
2.3 Wireless Sensor Networks

Las redes de sensores inalmbricos (WSN) ofrecen una combinacin de informacin, comunicacin y
deteccin distribuida. Trabajan como un gran nmero de nodos de sensores autoalimentados que recogen
informacin o detectan eventos, para luego comunicar estos datos de manera inalmbrica a una estacin
base donde estos sern procesados [4]. Deteccin, procesamiento y comunicacin son tres elementos
claves cuya combinacin en un nico dispositivo da lugar a un gran nmero de aplicaciones.
Ilustracin 2 Wireless sensor network data path
Las WSN tpicamente tienen poca o ninguna infraestructura, se componen de un nmero de nodos de
sensores (desde decenas hasta miles) que trabajan juntos para controlar una regin y obtener datos sobre el
entorno [5]. La tarea de un nodo genrico de sensores es tomar medidas del ambiente a supervisar, puede
estar equipado con una variedad de dispositivos que pueden medir diferentes atributos fsicos, tales como
la luz, temperatura, humedad, presin baromtrica, velocidad, aceleracin, campo magntico, etc. El
Gateway o puerta de enlace de los nodos rene los datos de los sensores genricos y los trasmiten a la
estacin base. Los nodos de las puertas de enlace tienen mayor capacidad de procesamiento, autonoma de
batera y rango de trasmisin. Una combinacin de los nodos genricos y de puerta de enlace normalmente
se despliega para formar una red de sensores WSN.
Las aplicaciones WSN se pueden clasificar en dos categoras [5]:
Supervisin: la cual incluye supervisin de ambientes, sean externos o internos, de salud y
bienestar, control de energa, automatizacin de procesos o control ssmico.
Seguimiento: que incluye sujetos en movimiento, como animales, seres humanos y vehculos.
El protocolo de comunicacin se compone de cinco capas de protocolo estndar para la conmutacin de
paquetes: la capa de aplicacin, capa de transporte, la capa de red, capa de enlace de datos y la capa fsica.
A partir de los requisitos de aplicacin y perspectivas de gestin de red, es importante que los nodos de
sensores sean capaces de auto-organizarse. Es decir, que puedan organizarse en una red y, posteriormente,
sean capaces de controlar y gestionarse a ellos mismos de manera eficiente. Las redes de sensores son un
campo relativamente nuevo en adquisicin y tratamientos de datos, pero que al mismo tiempo pronostica
avances en mltiples aplicaciones en distintos campos tales como entornos industriales y domtica.
- 15 -
2.4 Ordenadores de placa reducida
Un ordenador de placa reducida o SBC (Single Board Computer) es un computador completamente
integrado en un solo circuito, junto con los microprocesadores, memorias, interfaces de entrada y salida y
otras caractersticas requeridas en un computador. Esta configuracin disminuye el costo global del
sistema, reduciendo el nmero de placas de circuitos requeridos y eliminando conectores y buffers que de
otra manera habran sido utilizados. Al implementar todas las funciones en una nica placa, se puede
obtener un sistema general ms pequeo y gil.
Ilustracin 3 Tamao representativo SBC.
Su principal beneficio es su facilidad de uso, ya que mantienen la flexibilidad de un PC, con respecto a la
variedad de procesos que pueden realizar, pero su pequeo tamao y costo los hace ideales para
aplicaciones donde el uso de un PC regular sera excesivo. Esto es de gran ayuda especialmente durante el
proceso de investigacin y desarrollo.
2.5 Framework OSGi

OSGi, acrnimo de Open Services Gateway Initiative, es una corporacin independiente, sin nimo lucro,
que busca definir y promover especificaciones abiertas para la prestacin de servicios en entornos de red,
como casas y automviles. Un elemento clave de esta iniciativa es el framework OSGi, un sistema
modular ligero escrito en Java, usado para la implementacin y ejecucin de aplicaciones orientadas a
servicios, que soporta el despliegue dinmico de aplicaciones conocidas como bundles o mdulos,
incluyendo reglas de visibilidad, gestin de dependencias y versionado de los paquetes y donde la
instalacin, inicio, terminacin, actualizacin y desinstalacin de paquetes se realiza de manera dinmica
en tiempo de ejecucin, sin tener que detener por completo la plataforma.
2.5.1 Arquitectura OSGi
Ilustracin 4 Arquitectura OSGi
- 16 -
La funcionalidad del framework OSGi se divide en las siguientes capas:
Security Layer: Capa de seguridad.
Module Layer: Este mdulo define la reglas para el intercambio de paquetes java entre los bundles.
Life Cycle Layer: Gestiona el ciclo de vida de un bundle o paquete dentro del framework, sin tener
que detener la Java VM.
Service Layer: La capa de servicios proporciona un modelo de programacin dinmico para los
desarrolladores de bundles, simplificando la implementacin y despliegue de mdulos a travs del
desacople de la especificacin del servicio (java interface) de su implementacin.
Java VM: Mquina virtual Java.
Execution Environment: Ambiente mnimo de ejecucin OSGi.
2.5.2 OpenHAB
OpenHAB es una plataforma software escrita en Java que integra diferentes sistemas de automatizacin y
tecnologas en una nica solucin que permite la creacin de reglas automticas y que ofrece interfaces
unificadas buscando ser absolutamente neutral respecto a los diferentes proveedores de dispositivos y
agnstica respecto a los protocolos de comunicacin y las plataformas hardware. Funciona utilizando
enlaces (bindings), por lo tanto es posible aadir paquetes de software para habilitar la comunicacin con
una variedad de sistemas como: KNX, Philips Hue, MiLight, USB, Bluetooth, Asterisk, Modbus, etc. [6].
2.5.2.1 Arquitectura Software OpenHAB
La grfica a continuacin muestra un resumen de los principales componentes de OpenHAB y la forma en
que dependen unos de otros:
Ilustracin 5 Arquitectura software OpenHAB
Al estar basado en OSGi, OpenHAB proporciona una arquitectura altamente modular, lo que permite
incluso agregar y/o quitar una funcionalidad en tiempo de ejecucin sin detener el servicio. OpenHAB le
proporciona al usuario diferentes interfaces web basadas en HTML, capaces de funcionar en cualquier
dispositivo mvil o de escritorio, as como aplicaciones nativas para iOS y Android. Adems, si es
necesario integrarlo con otros sistemas, puede interactuar con ellos mediante un interfaz de servicio REST
API, permitiendo el acceso en lectura a los elementos as como actualizaciones de su estado o el envo de
comandos hacia los dispositivos.
2.5.2.2 Canales de comunicacin en OpenHAB
OpenHAB tiene dos canales diferentes de comunicacin interna, un bus de eventos asncronos y un
repositorio de estados que puede ser consultado. El bus de eventos es el servicio de base de OpenHAB y
- 17 -
todos los paquetes que no requieren un comportamiento basado en estados deben usarlo para informar a
otros sobre los eventos y para ser actualizados por eventos externos. Todos los bindings de protocolo (los
cuales proporcionan el vnculo a los dispositivos reales) deben estar comunicndose a travs del bus de
eventos. El siguiente esquema muestra como los canales de comunicacin son usados:
Ilustracin 6 Canales de Comunicacin OpenHAB
- 18 -
3. ESPECIFICACIONES
El sistema desarrollado a lo largo de este proyecto le permite a un usuario controlar y/o supervisar, a
travs de internet, un interruptor conectado a una lmpara, un sensor de movimiento y una toma de
corriente con sensor integrado de consumo, dispositivos que se encuentran ubicados en una habitacin. A
continuacin el diagrama general del proyecto.
Ilustracin 7 Diagrama general del proyecto
La informacin que se propaga a travs del sistema ser, por lo tanto, el estado de los dispositivos. La
Ilustracin 7 proporciona una visin general del sistema mientras que la Ilustracin 8 muestra con ms
detalle la interaccin real de los elementos de la solucin, que sern explicados en las secciones
siguientes:
Ilustracin 8 Diagrama de flujo del Sistema
Para definir las especificaciones del proyecto es pertinente dividir el sistema de domtica en sus
principales componentes:
Gateway.
Interfaz grfica.
Sensores y actuadores.
Base de datos.
- 19 -
3.1 Gateway
El Gateway es el dispositivo hardware que toma el papel de centro de control del sistema y que
corresponde al nodo central de la red de sensores y actuadores. En este dispositivo sern ejecutados el
framework OpenHAB y el motor de sincronizacin encargado de mantener alineada la informacin real, la
informacin en el servidor y los datos mostrados en la interfaz de usuario. Debido al rol que desempea,
ste debe permanecer encendido y corriendo durante todo el tiempo que se quiera controlar la habitacin.
3.1.1 Hardware
Las especificaciones hardware del gateway se encuentran resumidas en la siguiente tabla:
Especificacin Notas
Hardware Computador de placa reducida RaspberryPi
Conexin a Internet Ethernet o Wi-Fi (Adaptador USB Edimax EW-7811Un)

Protocolo inalmbrico
orientado a domtica que Z-Wave
soporta
Consumo de corriente 300mA (Promedio tomado de [7])
Tabla 1 Especificaciones Hardware del Gateway
Para garantizar la comunicacin entre el gateway y la red inalmbrica de sensores y actuadores ubicados
en la habitacin, es necesario que ste cuente con un adaptador que soporte el protocolo inalmbrico de
comunicacin usado, en este caso Z-Wave. Para tal fin se usa un adaptador USB cuyas especificaciones
detalladas se encuentran en la tabla siguiente:
Especificacin Notas [8]
Marca y referencia AeonLabs Z-Stick 2E
Protocolo inalmbrico Z-Wave 900 MHz ISM band (US)

Cantidad de dispositivos
232
soportados
Modos Z-Wave Inclusion; Removal; SerialAPI
Tabla 2 Especificaciones del adaptador USB Z-Wave
3.1.2 Software
En la tabla a continuacin se encuentran referenciadas las especificaciones del software con el que debe
contar el gateway:
Especificacin Notas
Sistema operativo Raspbian O.S.

Framework
OpenHAB 1.5.1
automatizacin
Framework OSGi Equinox
Administrador OpenHAB HABmin 0.1.3
Motor bases de datos MySQL
Java Virtual Machine Oracle JDK Versin "1.7.0_40"

Tabla 3 Especificaciones Software del Gateway
- 20 -
3.1.3 Motor de sincronizacin
Las especificaciones del componente software que sirve como motor de sincronizacin entre las diferentes
partes del sistema se encuentran resumidas en la siguiente tabla:
Especificacin Notas
Lenguaje de desarrollo C
Bibliotecas stdio.h, stdlib.h, string.h, mysql.h, signal.h, curl.h

Coherencia del La coherencia entre la interfaz grfica y el estado real del interruptor es garantizada a
interruptor travs de un polling de 1 segundo a la base de datos de sincronizacin
Tabla 4 Especificaciones del motor de sincronizacin en el Gateway
3.2 Interfaz Grfica

La interfaz grfica es el punto de interaccin entre el usuario y el sistema. Sus especificaciones se
encuentran en la tabla siguiente:
Especificacin Notas
Alojamiento web Servidor de HeliconiaTech Bitnami/AWS (http://www.heliconiatech.com)

www.heliconiatech.com/Tesis_de_daniel/
Direccin web
Nota: Sensible a las maysculas
Lenguajes de desarrollo HTML, CSS, JavaScript
JQuery 1.11.1
Bibliotecas JQuery Mobile 1.4.5
JQuery Flot 0.8.3
Coherencia entre los
AJAX mantiene un polling 1 segundo a la base de datos de OpenHAB
dispositivos y la interfaz
Navegadores con motor de renderizado Gecko y WebKit como:
Compatibilidad Google Chrome 28 en adelante
transversal entre Mozilla Firefox 31
navegadores Safari 8.0
Internet Explorer (renderizado Trident no est soportado).
3 rangos de tamao de pantalla cada uno con un distribucin diferente:
Menor o igual a 768px
Diseo para mviles
Entre 769px y 1019px
Mayor o igual a 1020px
Paleta de colores Los colores corresponden a la imagen corporativa de HeliconiaTech.
Tabla 5 Especificaciones de la interfaz grfica
Teniendo en cuenta que el usuario puede controlar y/o supervisar diferentes tipos de dispositivos
(interruptor, sensor de movimiento, consumo de un aparato), es importante tener formas claras de
distinguir los dispositivos en la interfaz grfica. De igual modo, suponiendo que el usuario final del
sistema ser una persona promedio, la interfaz grfica tiene interfaces dedicadas y diseadas
especficamente para diferentes tipos de dispositivos (computadores, tabletas, smartphones, etc.) con
distintos tamaos de pantalla.
En la tabla siguiente son especificados los widgets que representan un dispositivo en la interfaz grfica.
Cada uno de stos tiene dos diagramaciones dependiendo del tamao de pantalla, por lo tanto el nmero
de columnas en que se despliega el widget puede cambiar de acuerdo a la plataforma en que la interfaz es
utilizada.
- 21 -
Tamao de pantalla Nmero de columnas Diagramacin
Menor a 768 px 1
Entre 769px y 1019px 2
Mayor o igual a 1020px 3
Tabla 6 Diagramacin del widget de dispositivo
3.3 Sensores y Actuadores

Los dispositivos (sensores y actuadores) a usar para la realizacin de este proyecto son:
Un sensor capaz de identificar si hay movimiento de una persona en la habitacin.
Un sensor que permita medir la potencia consumida por un dispositivo.
Un actuador capaz de prender y apagar una luz.
Tales dispositivos soportan el protocolo inalmbrico Z-Wave. Cabe indicar que aun cuando los
dispositivos usados son de baja potencia y la comunicacin de los datos es de manera inalmbrica, la
alimentacin de estos puede ser cableada.
En este punto es importante definir el tamao de la habitacin de la cual se ha venido hablando en este
documento; para lo concerniente a este proyecto una habitacin es un rea cerrada de 3 metros por 3
metros y que tiene una sola va de acceso.
3.3.1 Sensor de movimiento
Corresponde a un dispositivo capaz de indicar si hay movimiento de una persona en la habitacin. Sus
especificaciones se encuentran reportadas en la siguiente tabla:
Marca y referencia Aeon Labs 4 in 1 Multisensor

Intervalo de tiempo de
2 minutos
deteccin
Rango efectivo 5x7 metros (montado en la pared)
OPEN: Movimiento detectado
Comandos Z-Wave
CLOSED: El sistema no registra movimiento por 2 o ms minutos.
Tabla 7 Especificaciones del sensor de movimiento
3.3.2 Sensor de consumo

El sensor de consumo est conectado en serie con la toma elctrica y la carga (dispositivo al cual se le
medir el consumo), de la siguiente manera:
Ilustracin 9 Esquema para el sensor de consumo
- 22 -
Las especificaciones tcnicas de este dispositivo se encuentran resumidas en la siguiente tabla:
Marca y referencia AeonLabs Smart Energy Switch

Potencia mxima de
1600W
entrada
Comandos Z-Wave El sensor muestra la potencia instantnea en vatios (W)
Tabla 8 Especificaciones del sensor de consumo
3.3.3 Actuador para controlar una lmpara

Este dispositivo ser capaz de prender y apagar una lmpara al ser dada la instruccin al framework OSGi
a travs de la interfaz grfica. La lmpara ser una carga incandescente. Las especificaciones del actuador
se encuentran reunidas en la siguiente tabla:
Marca y referencia GE/Jasco Z-Wave Wireless Lighting Control On/Off Switch, 45609

Potencia mxima de
600W, incandescente; HP Motor; 1800W (15A) resistiva
entrada
ON
Comandos Z-Wave
OFF
Tabla 9 Especificaciones del actuador para controlar una lmpara
3.4 Base de datos

Contiene la informacin usada por los distintos mdulos del proyecto: por una parte guarda los datos
relativos a la persistencia de OpenHAB, es decir, almacena el estado actual de cada uno de los dispositivos
y por otra parte es usada por el motor de sincronizacin al almacenar los comandos por ejecutar,
informacin que obtiene de la interfaz de usuario.
Las especificaciones de esta base de datos se encuentran relacionadas en la siguiente tabla:
Especificacin Notas
Nombre tesisdb
Sistema de gestin MySQL

Software de
PHPmyadmin; MySQL Workbench
administracin
Tabla 10 Especificaciones base de datos
- 23 -
4. DESARROLLO DEL PROYECTO
4.1 Preparacin de la plataforma
Parte del diseo e implementacin del sistema fue establecer cules seran las caractersticas necesarias de
la plataforma hardware y software. Adems del proceso de seleccin del hardware y software, en esta
seccin se indican cuales fueron algunas de las configuraciones adicionales que se debieron realizar
durante el desarrollo del proyecto, esto con el fin de sealarle al lector los requerimientos totales de la
plataforma, que es la base del sistema de domtica.
En la seccin 4.1.1 se describen cules son las caractersticas del servidor que se us. Este servidor
pertenece a HeliconiaTech y el sistema aprovech las caractersticas de mismo, en especial el hecho de
que cuente con una IP pblica y un domino, lo que le otorga al usuario final la posibilidad de acceder a la
interfaz grfica del sistema de domtica desde cualquier lugar. El proceso de seleccin del ordenador de
placa reducida y las configuraciones necesarias para que sea apropiado para al sistema de domtica se
desarrollan en la seccin 4.1.2.
4.1.1 Caractersticas del servidor
El servidor que se utiliz en el proyecto cuenta con plataforma LAMP y est hospedado por Bitnami/AWS
de HeliconiaTech. El servidor tambin tiene un nombre de dominio pblico que est administrado por
GoDaddy.
Caracterstica Descripcin
Sistema Operativo Ubuntu Server 14.04.1 LTS (Long Term Support)
Servidor Web Apache/2.4.10 (Unix)

Motor de gestin de base
MySQL Ver 14.14 Distrib. 5.5.39
de datos
Server-side scripting PHP 5.4.32
Alojamiento web Servidor de HeliconiaTech Bitnami/AWS (http://www.heliconiatech.com)

www.heliconiatech.com/Tesis_de_daniel/
Direccin web
Nota: Sensible a las maysculas
Zona horaria UTC
Tabla 11 Caractersticas del servidor de HeliconiaTech
LAMP es el acrnimo usado para denominar al conjunto de soluciones de servicios web que consiste de
los siguientes software: Linux, Apache, MySQL y PHP. Linux es el sistema operativo del servidor, al
momento del desarrollo de este proyecto el servidor tiene instalado la distribucin de Ubuntu nombrada en
la Tabla 11, ste se encuentra totalmente actualizado. Apache es el servidor web HTTP para la plataforma
Linux, es capaz de interpretar lenguajes de programacin de lado servidor, como por ejemplo: Perl,
Python y PHP. MySQL es un sistema de motor gestin de base de datos y fue el mdulo de mayor inters
para el desarrollo del proyecto. El objetivo de usar la base de datos en el servidor de HeliconiaTech fue el
de poder exportar el estado actual de los dispositivos a una ubicacin donde el usuario fuera capaz de
accederlos desde internet, esto implica caractersticas propias de un servidor web, como el dominio
pblico y un sistema de gestin de base datos.
En la seccin 4.5.1 se describe con mayor detalle las caractersticas de la base de datos usada para este
sistema de domtica, as como las funciones del sistema de gestin MySQL que se utilizaron. Respecto a
la configuracin, tema principal de esta seccin, solo falta mencionar que fueron necesarios ajustes de
lado servidor para permitir al Gateway exportar los datos del estado de los sensores y actuadores a la base
de datos, entre estos habilitar y abrir puertos del servidor y permisos de escritura y lectura a usuarios
externos a ste.
- 24 -
4.1.2 Ordenador de placa reducida (SBC)
Actualmente en el mercado se encuentra una gran variedad de ordenadores de placa reducida. La mayora
de los procesadores de los SBC estn basados en la arquitectura de procesadores ARM y algunos de ellos
ofrecen un mejor rendimiento y ms memoria que otros, algunos tienen una gran variedad de conectores,
mientras que otros solo tienen el mnimo necesario. Con el fin de elegir el SBC adecuado para este
proyecto, a continuacin se presenta una comparacin de los principales SBC actualmente disponibles.
4.1.2.1 Comparacin de ordenadores de placa reducida
El ordenador de placa reducida ms econmico es la RaspberryPi, mientras que el ms costoso es el Intel
NUC. La RaspberryPi tiene un consumo muy bajo de potencia lo cual es deseable en este proyecto, la
Beaglebone Board tambin presenta un consumo bajo pero su precio es casi 3 veces mayor que el de la
RaspberryPi, adems esta ltima tiene una capacidad de memoria RAM ms alta que la Beaglebone.
VIA
Beaglebone RaspberryPi B Intel NUC PandaBoard
APC
Frec. CPU (MHz) 720 700 1800 800 1200
RAM (MB) 256 512 - 512 1024

Consumo de
2 3.5 65 13.5 5
Potencia (W)
Precio (USD) 89 35 315 40 180
Arquitectura ARM ARM x86 ARM ARM

Sistemas operativos Linux (Angstrom, Linux (Raspbian), Windows, OS X, Android, Linux, Android,
soportados Ubuntu), Android RISC OS, Android Linux, Android Linux RISC OS
Almacenamiento
0 0 0 2048 0
interno (MB)
Almacenamiento MicroSD,
microSD, USB SDHC, USB SATA, USB SD, MMC,USB
externo USB
Puerto HDMI NO SI SI SI SI
Puerto VGA NO NO NO SI NO
Puerto Ethernet SI SI SI SI SI
Wi-Fi interno NO NO SI NO SI
Entradas USB
1 2 3 4 2
(2.0/3.0)
Pines GPIO SI SI NO NO SI
Tabla 12 Comparacin de Ordenadores de placa reducida [7]
Una caracterstica importante, pero difcil de cuantificar, es el soporte de la comunidad de desarrolladores.

En este aspecto la RaspberryPi se destaca, en parte debido a su fama, lo que incrementa el nmero de
usuarios proficientes, y en parte tambin a que el proyecto RaspberryPi tiene una inclinacin educativa lo
que hace que los creadores se preocupen por resolver los problemas que puedan surgir en los proyectos de
los usuarios.
4.1.2.2 Seleccin de RaspberryPi
Diseado y comercializado por RaspberryPi Foundation y fabricado por Sony UK, el SBC RaspberryPi
combina caractersticas muy positivas de hardware, como un buen rendimiento (el procesador ARM @
700 MHz puede ser acelerado hasta 1 GHz), una memoria RAM de 512MB y consumo de potencia
extremadamente bajo (3.5W) lo que lo hace ideal para este proyecto. Adems los pines GPIO permiten
conectividad con hardware personalizado para desarrollos futuros.
- 25 -
Ilustracin 10 Ordenador de placa reducida RaspberryPi
Estas razones, combinadas con el precio, llevaron a elegir la RaspberryPi como el SBC para el desarrollo
de este proyecto.
Especificaciones:
CPU: procesador ARM1176JZF-S 700 MHz
GPU: VideoCore IV
RAM: 512 MB
Conectores: USB, HDMI, RCA, Jack de audio 3.5mm, 10/100 Ethernet, micro USB
Almacenamiento: tarjeta SD/MMC/SDIO
Nota sobre las limitaciones de la RaspberryPi
La RaspberryPi tiene dos puertos USB de una sola raz: todo el trfico de todos los dispositivos
conectados se canaliza por este bus, que opera a una velocidad mxima de 480Mbps. Dado que el
adaptador para protocolo de comunicacin inalmbrica se conectar utilizando el puerto USB la limitacin
a la velocidad de datos estara cerca de 35MB/s. En general no hay problemas con la conexin de
mltiples dispositivos USB de alta velocidad a la RaspberryPi.
4.1.3 Distribuciones de Linux disponibles para la RaspberryPi
Existe una gran variedad de distribuciones de Linux para la RaspberryPi. La primera distincin que se
hizo fue entre distribuciones de propsito general y de propsito concreto. Entre estas ltimas se destacan
algunas como Raspbmc, la cual permite convertir la RaspberryPi en un media center, o arkOS, que ofrece
herramientas para crear y administrar un servidor cloud privado de archivos. Para este proyecto fue de
inters escoger una distribucin de propsito general, esto debido a que stas son ms flexibles en trmino
de posibles configuraciones, cualidad importante durante proyectos de investigacin y desarrollo.
Versin de Fecha de la ltima
Basado en GUI
Kernel versin
PIDORA Fedora Remix 3.12.23 2014-09-09 Yes
RASPBIAN Debian Wheezy 3.12 2014-07-24 Yes
ARCH LINUX Arch Linux 3.12 2014-10-01 No
MOEBIUS ARM HF Debian 3.12 2014-05-01 Yes

Tabla 13 Distribuciones Linux de propsito general para la RaspberryPi
- 26 -
4.1.3.1 Seleccin de la distribucin Raspbian
Raspbian es un sistema operativo (SO) de libre distribucin basado en Debian y optimizado para la
RaspberryPi. Esta distribucin provee ms de 35000 paquetes de software optimizados para ejecutar en la
RaspberryPi. Este SO cuenta con una de las ms grandes comunidades de desarrollo entre todas las
distribuciones para la RaspberryPi; esto fue un importante factor al momento de escoger esta distribucin,
ya que gracias a la constante implementacin, el sistema posee una gran estabilidad y cualquier problema
que se genere es rpidamente detectado por el equipo de desarrollo.
4.1.3.2 Instalacin y configuracin de Raspbian
La instalacin del sistema operativo Raspbian se realiz en una tarjeta SD (clase 6, 8Gb) a partir del
instalador NOOBS. Una vez el sistema operativo se instal fueron necesarias algunas configuraciones
adicionales.
Los ajustes predeterminados de ingreso son:
Username: pi
Password: raspberry
Nota: En la disposicin final del proyecto esta informacin fue cambiada.
Una vez disponible la interfaz de lnea de comando es posible conectar un monitor por HDMI e iniciar la
Raspbian GUI con el comando startx, sin embargo, esto no es obligatorio ya que la mayora de la
configuracin se puede realizar por consola a travs de Secure Shell (SSH); este servicio inicia
automticamente con el sistema operativo.
Lo primero que se debi garantizar fue la conexin a internet, que puede ser va Ethernet o Wi-Fi, usando
el adaptador USB proporcionado. Una vez se comprob la conexin a internet, ya sea va el comando ping
o el comando ifconfig, se continu actualizando el sistema operativo e instalando JAVA 1.71 con los
comandos indicados en el ANEXO 2.
El motor de sincronizacin requiere dos bibliotecas que no estn incluidas en esta distribucin de
Raspbian: libmysql y libcurl. Los pasos detallados para instalar estas bibliotecas se encuentran en el
ANEXO 2 de este documento.
4.2 OpenHAB
A la fecha, la distribucin oficial de OpenHAB es la 1.5.1 y se puede descargar en la pgina oficial
(http://www.openhab.org/) junto a los addons (bindings) que fueron utilizados en este proyecto.
Ilustracin 11 rbol de carpetas de runtime de OpenHAB
- 27 -
Para completar la instalacin fue suficiente descomprimir el archivo descargado distribution-1.5.1-
runtime.zip en una carpeta a eleccin, que en este caso se nombr openhab. Despus de realizar este
procedimiento, al interno de la carpeta mencionada se encuentra la serie de archivos y carpetas mostrada
en la Ilustracin 11.
El siguiente paso consisti en copiar los addons utilizados para el desarrollo de este proyecto en la carpeta
addons del directorio runtime; stos se encuentran en el archivo descargado denominado distribution-
1.5.1-addons.zip.
Los addons que se utilizaron fueron:
org.openhab.binding.zwave-1.5.1.jar
org.openhab.persistence.mysql-1.5.1.jar
El software de administracin para el framework OpenHAB (HABmin v.0.1.3) no se encuentra en los
addons de la distribucin oficial; se puede descargar en su pgina oficial:
https://github.com/cdjackson/HABmin.
4.2.1 Configuracin de OpenHAB
La carpeta de configuracin de OpenHAB, de nombre configurations, contiene los siguientes archivos y
carpetas:
Ilustracin 12 rbol de la carpeta configurations de OpenHAB
El nombre del archivo de configuracin de OpenHAB es openhab.cfg. Este archivo contiene los
principales parmetros de configuracin tanto del framework como de los addons que se utilizaron en el
sistema. En el ANEXO 3 se encuentran los cambios que se realizaron a este archivo, los cuales consisten
principalmente en configurar la persistencia de la informacin relativa a los dispositivos en una base de
datos externa e identificar el dispositivo Linux donde se encuentra el adaptador USB de Z-Wave en la
RaspberryPi.
La mayora de los dems archivos y carpetas son usados por servicios de OpenHAB que no fueron usados
durante el desarrollo de este proyecto, como es el caso de la interfaz grfica nativa de OpenHAB o el uso
de reglas automticas que modifican un item de acuerdo a eventos predeterminados. Otras funcionalidades
de OpenHAB tienen gran potencial en desarrollos futuros de este proyecto, como por ejemplo: las reglas,
que otorgan la posibilidad de definir si otros items o bindings se modifican cuando algn comando en
particular se detecta en el bus de eventos; o los scripts, que permiten escribir cdigo que analice los
estados de los items.
- 28 -
Carpeta/Archivo Descripcin
Ac es posible definir a travs de archivos .map una traduccin para los estados
retornados por los diferentes dispositivos. Por ejemplo, se desea que para un
transform
interruptor encendido valor que se muestra en la interfaz grfica de OpenHAB sea
ENCENDIDO en vez de ON.
El sitemap corresponde a la distribucin lgica y grfica de las interfaces de usuario
sitemaps nativas de OpenHAB. Esta carpeta contiene archivos con extensin .sitemap, los
cuales contienen descripciones de la diagramacin de los items en la interfaz.
Un script es la manera de crear cdigo reutilizable para las reglas. Un archivo .script
scripts contiene instrucciones que pueden ser utilizadas simplemente incluyendo este archivo
en la lgica de la regla.
Con las reglas es posible definir respuestas automatizadas a diferentes eventos, como
rules cambios es el estado de algn dispositivo, condiciones de tiempo o cambios en el
sistema. Las reglas son escritas en un pseudo lenguaje similar a JAVA.
Esta carpeta contiene archivos con extensin .persist en los que es posible configurar
persistence
como se desea almacenar la historia del estado de los items.
Contiene archivos .item que son usados para definir los items. Un item es un objeto
items que se puede leer o escribir con el fin de interactuar con ellos, pueden estar
vinculados a un dispositivo real o corresponder a dispositivos virtuales.
En el archivo users.cfg se configuran los nombres de usuario y sus contraseas, como
users.cfg
opcin de seguridad para ingresar a la interfaz grfica de OpenHAB
Aquellas opciones que no se encuentren definidas en el archivo principal de
openhab_deafult.cfg
configuracin, openhab.cfg, tienen en este archivo su valor por defecto
Es el archivo principal de configuracin de OpenHAB. Especifica las opciones
openhab.cgf
generales del sistema as como parmetros para diferentes binddings/addons.
logback_default.xml Contiene las opciones por defecto de la verbosidad del log.
logback.xml Contiene las opciones para modificar el log.

Tabla 14 Descripcin de la funcin de las carpetas en la configuracin de OpenHAB
4.2.2 Items de OpenHAB

El framework identifica a los dispositivos (sensores y actuadores) como items. Para OpenHAB un item no
tiene que estar relacionado con un protocolo o con un addon/binding, as que es posible crear items que
indiquen informacin diferente al estado de un dispositivo real.
Campo Descripcin Posibles valores
Le indica a OpenHAB si el dispositivo es

itemtype switch; number
un interruptor o un sensor
itemname Nombre del dispositivo Consultar seccin 4.2.3
labeltext Usado por OpenHAB El mismo itemname
iconname Usado por OpenHAB El mismo itemtype
group Usado por OpenHAB Habitacin

Le indica a OpenHAB que
binding/protocolo el dispositivo usa; para zwave="<node#>:<endpoint#>:command=<comma
bindingconfig
el caso de Z-Wave tambin le indica el nd_class>:<modifiers>"
nodo que le corresponde al dispositivo.
Tabla 15 Campos para definicin de un item en OpenHAB
- 29 -
En general los items se definen de la siguiente manera:
itemtype itemname ["labeltext"] [<iconname>] [(group1, group2, ...)] [{bindingconfig}] [12]
En este proyecto los campos usados en la definicin de un item tienen son descritos en la Tabla 15.
El archivo demo.items, que se encuentra en la carpeta items de la configuracin de OpenHAB, contiene la
definicin de los items del sistema de domtica.
Number Energy_Consumo_Habitacion "Energy_Consumo_Habitacion [%.1f W]" <chart>
(Room) {zwave="4:1:command=meter"}
Contact Movement_Movimiento_Habitacion "Movement_Movimiento_Habitacion [%S]"
<chart> (Room) {zwave="3:1:command=sensor_binary,respond_to_basic=TRUE"}
Number Temperature_Temperatura_Habitacion Temperature_Temperatura_Habitacion
[%.1f F]" <temperature> (Room)
{zwave="3:1:command=sensor_multilevel,sensor_type=1,sensor_scale=0"}
Number Humidity_Humedad_Habitacion "Humidity_Humedad_Habitacion [%.1f %%]"
<wind> (Room) {zwave="3:1:command=sensor_multilevel,sensor_type=5"}
Number Luminance_Luminancia_Habitacion "Luminance_Luminancia_Habitacion [%.1f
lux]" <chart> (Room) {zwave="3:1:command=sensor_multilevel,sensor_type=3" }
Switch Switch_Luz_Habitacion "Switch_Luz_Habitacion" <light> (Room)
{zwave="5:1:command=switch_binary"}
4.2.3 Codificacin de los nombres de los items
Para OpenHAB el nombre que tengan los distintos items no tiene ningn significado, pero ya que esta
informacin va a estar disponible para la interfaz grfica a travs de la base de datos, fue conveniente
incluir en estos la mayor cantidad de informacin posible. Con esto en cuenta, el nombre de un item tiene
la siguiente codificacin:
type_name_group
En donde cada campo est descrito de la siguiente manera.
Campo Descripcin Posibles valores
Switch; Energy; Movement; Humidity;

type Indica el tipo de dispositivo correspondiente
Temperature; Luminance
Luz; Consumo; Movimiento; Humedad;
name Nombre del dispositivo; describe su funcin
Temperatura; Luminancia
Indica el grupo al cual pertenece el dispositivo;
group Room
puede describir el espacio fsico en el que se ubica
Tabla 16 Campos para denominacin de un item
Es de vital importancia indicar que ninguno de los campos puede contener el carcter _ debido a que
ste se utiliza como token de separacin al decodificar esta informacin en la interfaz grfica.
El campo group describe el espacio al que pertenece el dispositivo, que para este proyecto es la
habitacin. Se implement para futuras iteraciones de la interfaz grfica que posean la posibilidad de
dividir los dispositivos por espacios residenciales.
4.2.4 Configuracin de la persistencia
Para configurar la persistencia de los datos recolectados por los diferentes dispositivos del sistema fue
necesario realizar los cambios al archivo openhab.cfg indicados en el ANEXO 3. Una vez definidos cules
son los parmetros de conexin a la base de datos, el siguiente paso consisti en configurar la estrategia, o
estrategias, que usa el servicio de persistencia, lo cual se realiz en el archivo mysql.persist ubicado en la
carpeta persistence, Ilustracin 12.
En este proyecto se usaron estrategias estticas de persistencia definidas en OpenHAB. Especficamente
se us everyChange (Nota: Es posible definir las estrategias con expresiones de tipo cron).
En el ANEXO 3 se encuentra el contenido del archivo mysql.persist, que define las estrategias usadas para
cada item.
- 30 -
4.3 Protocolo inalmbrico
Para el sistema de domtica desarrollado en este documento se decidi que los sensores y actuadores
comuniquen su estado de manera inalmbrica. Esto es importante debido a que en el momento en que se
quisiera implementar el sistema en un ambiente real y de manera permanente, una directiva esencial de
este proyecto, la instalacin se convierte en un proceso ms simple, debido a que no se necesita ninguna
clase de cableado estructural.
En la actualidad es posible encontrar sensores y actuadores que usan una gran variedad de protocolos
inalmbricos, desde los ms tradicionales como Wi-Fi y Bluetooth (seccin 4.3.1) hasta los orientados a
domtica (seccin 4.3.2).
4.3.1 Sistemas inalmbricos tradicionales
Wi-Fi y Bluetooth son protocolos tradicionales con amplia distribucin y gran soporte, se usan
principalmente para la transmisin de datos con alta tasa de transmisin.
Wi-Fi 802.11 Bluetooth 802.15.1
Aplicacin orientada Web, email, video Sustitucin de cables
Tamao de la red 32 7
Ancho de Banda (KB/s) 11.000+ 720
Rango de Transmisin (m) 1-100 1-10+
Conexin cliente-servidor Asimtrica Simtrica
Indicadores de desempeo Velocidad, Flexibilidad Costo, Conveniencia

Tabla 17 Sistemas Wireless Tradicionales
Wi-Fi tiene excelente velocidad y gran rango de transmisin, pero el enrutamiento se hace desde un punto
central (servidor) lo cual limita la ubicacin de los dispositivos alrededor de ste, adems Wi-Fi no est
diseado como un protocolo de bajo consumo lo cual no es lo ideal para dispositivos que funcionen a
batera. Ahora, mientras Bluetooth es conveniente por su bajo consumo, su principal problema es que el
tamao de red est limitado a 7 dispositivos.
Es importante recalcar que aun cuando ninguna de estas razones hacen imposible la realizacin de este
proyecto en especfico, si limitan sus desarrollos futuros.
4.3.2 ZigBee y Z-Wave
Z-Wave y ZigBee son tecnologas de comunicacin inalmbrica basadas en chip que permiten transmitir y
recibir pequeas instrucciones (seales de comando). Los chips Z-Wave y ZigBee se utilizan para crear
sistemas inalmbricos que controlan funciones de iluminacin, seguridad, acceso, sensores, alarmas y
comunicacin entre dispositivos residenciales o industriales. Los chips de ambas tecnologas son de muy
bajo consumo de energa, por lo que pueden funcionar con base en pilas ordinarias en intervalos de tiempo
que alcanzan el orden de aos.
Ilustracin 13 Diagrama de conexin un red tipo mesh
- 31 -
Las redes basadas en estas tecnologas son de topologa de tipo malla (mesh), esto quiere decir que no
dependen de un punto central de control (un servidor), ya que la plataforma de conectividad se establece a
partir de dispositivos compatibles que se enlazan entre s, como se muestra en la Ilustracin 13.
ZigBee Z-Wave
Tecnologa propietaria desarrollada por la

empresa SigmaDesigns (que vende chips y
Tipo de estndar Estndar abierto
software a las firmas que deseen disear
productos compatibles con Z-Wave)
Tecnologa impulsada por la
Estndar respaldado por la Z-Wave Alliance
ZigBee Alliance (alianza industrial
(grupo de empresas que se encarga de vigilar la
Respaldo de la que incluye a firmas como
compatibilidad entre productos, y que est
industria Chipcom, Honeywell, Mitsubishi,
liderado por las firmas Dayfoss, Intermatic,
Ember, Motorola, Samsung,
Leviton, UEI, Wayne Dalton y Zensys)
Philips)
Hasta 250 Kbps (en chips de
Capacidad de datos 40Kbps (en chips de segunda generacin)
primera generacin)
Soporta hasta 232 dispositivos. Es posible unir
Capacidad en red Soporta hasta 65,536 dispositivos
(puntear) redes
Frecuencias 2.4 GHz o 900 MHz en 26 canales 868.42/900/ 916 /919.82 MHz en un canal
Patrn de propagacin Flooding Routing

Zonas comerciales, espacios
Mercados potenciales Espacios residenciales
residenciales y reas industriales
Binding de OpenHAB No (en desarrollo) Si
Tabla 18 ZigBee vs Z-Wave
4.3.3 Seleccin del Protocolo de Comunicacin

Z-Wave fue diseado especficamente para aplicaciones residenciales y permite controlar amplios
espacios simplemente distribuyendo estratgicamente los nodos, por lo que es posible crear una red Z-
Wave para gestionar un dispositivo, una habitacin, un piso o una casa entera. Opera en la banda sub-
1GHz (la banda americana es 900MHz), sin interferencias generadas por Wi-Fi u otros tipos de
tecnologas wireless en el rango de los 2.4GHz (Bluetooth, ZigBee, etc.).
Z-Wave es accesible, fcil de implementar y los costos de mantenimiento y consumo de energa son muy
bajos. Adems, la red de malla inteligentes tipo mesh entiende el estado actual de cualquier dispositivo
habilitado y da la confirmacin de que sus dispositivos han recibido las rdenes automticas o manuales
indicadas.
Los dispositivos Z-Wave comunican sus estados a la red a travs de clases de comandos (command class),
que se encuentran ligados a la funcin del dispositivo. As, por ejemplo, un sensor de temperatura informa
a la red sus lecturas con un command class de tipo sensor_multilevel.
Los chipsets de Z-Wave solo pueden ser producidos bajo la licencia de SigmaDesigns, lo que permite una
mejor interoperabilidad entre productos Z-Wave de diferentes fabricantes, cuestin que implica un gran
beneficio para el consumidor porque no importa si una compaa no tiene todos los sensores o actuadores
deseados, siempre se podr comprar dispositivos de otra compaa para satisfacer los requerimientos de
cada proyecto.
4.3.4 Creacin de la red Z-Wave
El primer paso para poder usar un dispositivo es incluirlo a la red Z-Wave. Este proceso es conocido como
pairing, y se puede realizar de manera manual, oprimiendo el botn Z-Wave en el controlador AeonLabs
Z-Stick 2E y luego en el dispositivo que se quiera incluir. Una vez en la red, el dispositivo es identificado
con un ID nico.
- 32 -
Sin embargo, realizar el pairing manual con los dispositivos es un proceso que no cuenta con ninguna
retroalimentacin, por lo tanto es difcil determinar si el dispositivo se agreg o no a la red. Es por esto
que se incluy en el sistema el addon administrador denominado HABmin, que provee, entre otros
servicios, la posibilidad de configurar la red Z-Wave, es decir, incluir y excluir dispositivos, adems de
supervisar el estado de la red en tiempo real.
Ilustracin 14 Configuracin Z-Wave de HABmin
De acuerdo a la pgina web oficial de HABmin [13], al iniciar, la interfaz deber mostrar solamente la
lista de los nodos y en el caso en el cual el tipo de nodo es encontrado en la base de datos de productos de
HABmin, se listarn tambin su fabricante y el tipo de producto para cada nodo.
El pequeo indicador junto al nombre del dispositivo puede ser gris, amarillo, verde o rojo. Si es gris,
entonces ste indica que el dispositivo no ha completado su inicializacin. Si es rojo, el nodo est
MUERTO, y si es verde, el nodo est VIVO. Si es amarillo, el nodo se encuentra operando de manera
correcta, sin embargo, ha estado muerto en las ltimas 24 horas o tiene un contador de reintentos de
arranque mayor al 5%. Se seala que para los dispositivos alimentados a batera puede tomar algn tiempo
completar su inicializacin, por lo tanto estos dispositivos pueden permanecer con su indicador de color
gris por un largo tiempo, tpicamente algunas horas dependiendo de la configuracin de su intervalo de
wake up.
4.4 Sensores y actuadores

Las caractersticas ms importantes que se tuvieron en cuenta al seleccionar los dispositivos fueron que
soportaran el protocolo Z-Wave y que estuvieran comercialmente disponibles. Es importante destacar que
Z-Wave opera en diferentes frecuencias como se indica en la Tabla 18, de stas la banda de 900MHz es la
aprobada en Estados Unidos y fue la que se us en este proyecto, por lo tanto todos los sensores y
actuadores del sistema utilizan esta banda de frecuencia.
Cada dispositivo proporciona un archivo XML con sus parmetros de configuracin, los cuales se usan
para definir diferentes opciones del sensor o actuador. En algunas ocasiones esta especificacin no estaba
disponible en el sitio web del fabricante y es por esto que fue importarte, a la hora de seleccionar los
sensores y actuadores, que estos se encontraran en una de las bases de datos de dispositivos Z-Wave mejor
documentada, como es el caso de Pepper One, compaa que prueba y certifica dispositivos que usan el
protocolo Z-Wave (http://www.pepper1.net/zwavedb/).
4.4.1 Parmetros de configuracin los dispositivos
Los parmetros de un dispositivo Z-Wave definen cundo, cmo y a quin transmitir sus comandos. El
cundo se refiere al momento en que el dispositivo transmite, esto es de especial inters para los
sensores que supervisan variables como temperatura o humedad, en estos casos este parmetro definira
los intervalos de tiempo mnimos para comunicar los grados Centgrados o la humedad relativa. Ahora, si
por ejemplo el sensor fuera capaz de medir la temperatura en grados Centgrados o en Fahrenheit, ste
sera el cmo, que permite controlar la manera en que se comunican los estados.
- 33 -
El quin se refiere a los dispositivos a los cuales se le entregarn los datos. Este dispositivo de destino
no es necesariamente el controlador Z-Wave. Tal comportamiento se puede especificar configurando
grupos en cada dispositivo, donde por ejemplo, un sensor de presencia podra activar un interruptor sin
que el comando pasase por el controlador.
OpenHAB lee estos parmetros de cada dispositivo como un archivo XML y los almacena en la carpeta
etc/zwave/1.5 del runtime.
Ilustracin 15 Parmetros XML de los nodos Z-Wave
Estos parmetros se pueden modificar con HABmin a travs de la interfaz de configuracin Z-Wave
(Ilustracin 14), basta con expandir el nodo y aqu se da la posibilidad de modificarlos.
4.4.2 Aeon Labs Aeotec Z-Wave Multisensor
El multisensor de Aeon Labs es capaz de medir temperatura, humedad y luminancia, adems de detectar
movimiento a travs de su sensor PIR. Es alimentado por 4 bateras AAA o por USB. Cuando se ubica
apoyado en una pared, el rea de deteccin corresponde al siguiente diagrama:
Ilustracin 16 Rango efectivo de deteccin de movimiento
El sensor PIR transmite un command class de tipo sensor_binary, con valor CLOSED cuando no hay
movimiento y OPEN cuando detecta movimiento. Este valor es mantenido la cantidad de segundos
especificada por el parmetro On time, y luego regresa a CLOSED hasta que se vuelva a disparar.
La temperatura, la humedad y la luminancia se miden respectivamente en, grados Fahrenheit, humedad
relativa y lux, donde cada una de estas medidas se transmite con un command class de tipo
sensor_multilevel. Es posible configurar 3 maneras distintas de trasmitir estas medidas a travs de los
parmetros 101, 102 y 103. Estos parmetros corresponden a la representacin decimal de un nmero
binario de 8 bits, donde los 3 bits ms significativos indican qu medidas se quieren transmitir, de la
siguiente manera: bit7, luminancia; bit6, humedad; y bit5, temperatura [14]. Ahora, una vez definidas qu
medidas se quieren transmitir, solo falta definir cundo se quieren transmitir. sta es la funcin de los
parmetros 111, 112 y 113, los cuales definen este intervalo en segundos.
Entonces, por ejemplo, si el parmetro 101 tiene un valor decimal de 160, binario 10100000, y el
parmetro 111 tiene un valor de 60, esto quiere decir que el multisensor transmitir cada 60 segundos
comandos sensor_multilevel nicamente con los valores de luminancia y temperatura medidos en ese
instante.
- 34 -
El multisensor usado en el sistema de domtica tiene la siguiente configuracin:
Ilustracin 17 Parmetros Z-Wave del Multisensor Aeonlabs
4.4.3 AeonLabs - Z-wave Smart Energy Switch (DSC06106-ZWUS)

El Smart Energy Switch de AeonLabs es un interruptor Z-wave que adems puede reportar
instantneamente la potencia de entrada en vatios [W] a travs de un command class de tipo meter. Este
interruptor inteligente tambin funciona como repetidor Z-wave permitiendo as extender la cobertura de
la red hasta 20 metros. Puede manejar cargas de mximo 1875 W [10]. Fueron configurados los siguientes
parmetros Z-Wave en este dispositivo: 1 y 90, para activar el sensor, y 92 para especificar la diferencia
porcentual necesaria para reportar un cambio en su medicin:
Ilustracin 18 Parmetros Z-Wave del Smart Energy Switch
- 35 -
4.4.4 Jasco Z-Wave Lighting Control On/Off Switch, (45609)
Este interruptor ON/OFF (45609) de Jasco/GE puede controlar cualquier tipo de iluminacin. Es capaz de
manejar cargas incandescentes de mximo 600 W o motores de HP [11]. Este interruptor tambin
funciona como repetidor Z-wave, permitiendo as extender la cobertura de la red. Es importante tener en
cuenta que el lugar de instalacin elctrica necesita tener tanto neutro como fase.
A diferencia de los dems dispositivos para lograr el funcionamiento del interruptor 45609, no fue
necesario modificar sus parmetros Z-Wave, fue suficiente con incluirlo a la red e inmediatamente
OpenHAB reconoci sus comandos.
4.5 Arquitectura del Software

Una vez seleccionados y configurados los elementos de la plataforma (RasberryPi, Rasbian, OpenHAB),
adems de los sensores y actuadores Z-Wave, se procedi a disear la arquitectura software reportada en
la Ilustracin 19. Esta grfica identifica las tres secciones definidas e independientes del sistema de
domtica.
Ilustracin 19 Arquitectura Software
La primera de estas secciones es la base de datos, que almacena los estados de los dispositivos, usando la
persistencia de OpenHAB y que guarda adems los comandos que el usuario realiz para operar el
interruptor en la tabla switch_next_state. La segunda seccin es el Gateway, componente hardware donde
se ejecuta el motor de sincronizacin que mantiene la coherencia entre el estado del interruptor y los
comandos que el usuario realiza para operarlo y donde tambin est instalado y configurado OpenHAB,
que es el encargado de administrar los dispositivos Z-Wave. La ltima seccin que conforma la
arquitectura es la interfaz grfica. En sta el usuario puede supervisar el estado de los sensores y operar el
interruptor. Tiene tres componentes bsicos: el HTML, el CSS y el JavaScript, donde este ltimo que
encarga de comunicar los estados entre la base de datos y la interfaz grfica usando el mtodo AJAX.
4.5.1 Bases de datos
La creacin de una base de datos hospedada en el servidor de HeliconiaTech fue necesaria para que los
estados de los dispositivos estuvieran disponibles a travs de Internet. Si bien es cierto que es posible usar
tcnicas como NAT traversal, que establecen y mantienen conexiones abiertas con dispositivos que se
encuentran en una red local y usarlas para acceder a la informacin de los estados directamente en el
Gateway, este tipo de tcnicas requieren configuraciones adicionales de la conexin a internet (router) que
solo puede hacer el ISP, problema que no se tiene con una arquitectura que use algn mecanismo de
sincronizacin en un servidor.
- 36 -
Otra ventaja de exportar la informacin de los dispositivos a una base de datos alojada en un servidor
externo, fue la posibilidad analizar estos datos y generar estadsticas y grficas. Este tema se describe en
ms detalle en la seccin 4.5.3.3.
La base de datos es de tipo MySQL, un poderoso sistema de gestin de base de datos, multihilo,
multiusuario y de cdigo abierto, que es especialmente popular al ser parte de la plataforma LAMP.
Actualmente MySQL es propiedad de Oracle.
La base de datos del proyecto tiene como nombre tesisdb y se implement con la siguiente estructura:
Ilustracin 20 Diagrama de la base de datos tesisdb
De la Ilustracin 20 las tablas se pueden dividir en dos categoras: las que conciernen a la persistencia de
OpenHAB (items, item1, item2, item3) y la tabla switch_next_state que consultada por el motor de
sincronizacin.
4.5.1.1 Persistencia MySQL de OpenHAB
La persistencia de OpenHAB exporta los estados de los dispositivos desde el Gateway hacia el servidor de
HeliconiaTech. La estrategia usada para este proceso es everyChange, donde cada vez que el estado de los
dispositivos cambie se va a agregar una nueva entrada a la base de datos. El proceso de configuracin de
esta persistencia fue descrito la seccin 4.2.4.
OpenHAB implementa la persistencia con dos tipos de tablas: items e items#. La primera contiene la
informacin de todos los items que tienen persistencia MySQL configurada y tiene las siguientes
columnas:
Columna Tipo Descripcin
Identifica al item al cual se le mantiene una

ItemId int(11)
persistencia
ItemName varchar(200) Nombre del item en OpenHAB
Tabla 19 Estructura tabla items
El estado de actual de los dispositivos se almacena en las tablas de tipo item#, donde el nmero (#) en el
nombre de estas tablas corresponde a ItemId en la Tabla 19.
Time datetime Hora a la que se grab el estado del dispositivo.
Value double Estado del dispositivo

Tabla 20 Estructura tablas item#
- 37 -
4.5.1.2 Tabla switch_next_state
Esta tabla tiene la funcin de almacenar los comandos que el usuario realiz para operar el interruptor.
Cada fila de la tabla es un comando y almacena tanto aquellos que ya se ejecutaron como los que estn
pendientes. El modo de diferenciar si un comando fue ejecutado es a travs del valor de la columna done,
donde 1 indica que ste ya se ejecut, 0 si est pendiente.
La tabla switch_next_state se implement con una estructura simple, lo suficientemente genrica para
soportar cualquier comando a cualquier item, lo cual se traduce en la capacidad de manejar una gran
cantidad de actuadores, an si este proyecto solo usa uno, sin embargo, se decidi esta implementacin
con el objetivo de dejar esta funcionalidad habilitada para desarrollos futuros.
Los campos de la tabla switch_next_state fueron definidos como lo muestra la Tabla 21:
id int(5) Identificacin individualmente a cada comando.

Indica al motor de sincronizacin si el comando
done int(1) ya se efectu. 0 si no ha realizado el comando, 1
si ya se realiz.
next_state varchar(3) Comando a ejecutar
Nombre del dispositivo sobre el cual se va a
itemname varchar(30)
ejecutar el comando
Tabla 21 Descripcin tabla switch_next_state

La funcin del motor de sincronizacin es la de mantener la coherencia entre el estado real del interruptor
y los comandos que el usuario realiza para operarlo desde la interfaz grfica. El lenguaje de programacin
que se utiliz para la creacin de este software fue C.
El motor de sincronizacin realiza una solicitud (query) a la tabla switch_next_state de todos los
comandos que estn pendientes por ser ejecutados para un cierto dispositivo, lo que est indicado por un
valor 0 en la columna done de la tabla. La C API de MySQL le permite al software establecer la conexin
con la base de datos. Si se desea tener para mayor profundidad en este proceso, esta temtica se retoma en
la seccin 4.5.2.2.
La respuesta de la base de datos es procesada y se almacena el ltimo comando pendiente para luego ser
transmitido a la REST API de OpenHAB a travs de un HTTP POST usando funciones de la biblioteca
cURL. Si el POST no obtiene respuesta, lo que quiere decir que OpenHAB o su REST API no estn
activos, el motor de sincronizacin reintenta enviar el mensaje asegurando de esta manera que OpenHAB
reciba y ejecute el comando especificado. Ms informacin sobre este mecanismo se encuentra en la
seccin 4.5.2.3.
Despus de que el motor de sincronizacin enva el comando a OpenHAB, genera una query a la tabla
switch_next_state para que todos los comandos anteriores al enviado actualicen el valor de su columna
done a 1, indicando as que estos comandos ya no se encuentran pendientes.
La secuencia de leer los comandos pendientes en la tabla switch_next_state, enviar el comando a
OpenHAB, y cambiar el valor de la columna done a 1, se repite cada segundo. Esto se logr ejecutando la
secuencia dentro de un ciclo con una pausa de un segundo antes de volver a iniciarla, generando as una
consulta constante de la base de datos, o polling. El cdigo es capaz de detectar la seal Ctrl+C ingresada
en consola para interrumpir este ciclo infinito y cerrar de manera limpia la aplicacin.
El archivo de origen principal es sync_engine.c, y corresponde al cdigo en el que se implement la
conexin a la base de datos, la lectura de los comandos y el polling, mientras que el fichero http_request.c,
contiene las instrucciones necesarias para realizar el POST HTTP.
- 38 -
4.5.2.1 Entorno de programacin
Para crear un entorno de programacin de tipo multi-plataforma se us la estructura estndar de una
aplicacin o biblioteca en Linux, es decir, se usaron las herramientas autotools que, en modo automtico,
generan una serie de archivos para la gestin de dependencias entre los componentes del cdigo fuente de
un programa. Estas dependencias se declararon en el archivo makefile.am ubicado en la carpeta src. La
siguiente es la organizacin del entorno de programacin:
Ilustracin 21 IZQ: Organizacin entorno de programacin del motor de sincronizacin; DER: Fuente del motor de sincronizacin
La mayora de estos archivos y carpetas son autogeneradas por la herramienta autotools, con excepcin de
la carpeta src que en donde se encuentran los archivos fuente del software, sync_engine.c y http_request.c,
y sus respectivos headers, sync_engine.h y http_request.h.
El archivo makefile.am, al interior de la carpeta src (ANEXO 4), contiene las dependencias necesarias
para compilar el cdigo, as como la ubicacin de las bibliotecas especiales instaladas en la seccin
4.1.3.2. En este archivo se especifica al archivo SyncEngine como el binario de salida.
Incluidas en el archivo de header sync_engine.h y http_request.h (ANEXO 4) se encuentran definidas las
bibliotecas usadas por este software, las que se describen en la siguiente tabla:
Bibliotecas Descripcin
Biblioteca estndar de propsito general, contiene funciones para gestin de

stdlib.h
memoria dinmica, control de procesos y otras.
Contiene macros, constantes, funciones y definicin de tipos usados por
stdio.h
operaciones estndar de entrada y salida.
Contiene macros, constantes, funciones y definicin de tipos para trabajar con
string.h
cadenas de caracteres.
Biblioteca que contiene funciones y definiciones de tipos necesarios para
mysql.h
comunicarse son un servidor MySQL.
Biblioteca que contiene funciones y definiciones de tipos necesarios para usar
curl.h
mtodos HTTP.
signal.h Biblioteca C para especificar cmo manejar seales mientras se ejecuta.
Tabla 22 Bibliotecas usadas en el motor de sincronizacin
- 39 -
Qu es una API?
API, abreviacin de Application Program Interface, es un conjunto de rutinas, protocolos y herramientas
para la construccin de aplicaciones software. La API especifica cmo interactuar con el software y sus
componentes, lo que significa que una compaa de software publica su API al pblico con el fin de que
los desarrolladores puedan disear productos que funcionan con su servicio.
MySQL C API
MySQL C API, es una API basada en C con la cual aplicaciones de cliente escritas en C pueden
comunicarse con un servidor MySQL. Las C API proporcionan acceso de bajo nivel al protocolo MySQL
y permite a los programas en C acceder a los contenidos de la base de datos. En este proyecto se utiliz la
versin con la biblioteca libmysqlclient, la cual se utiliza para aplicaciones que se comunican a travs de
una conexin de red a un servidor independiente.
4.5.2.2 sync_engine.c
El archivo sync_engine.c contiene la funcin main del software creado. En ste, con el fin de poder leer
las entradas de tabla swich_next_state, se us la API de MySQL para C. Esta API necesita una
configuracin previa, la cual se describe en la seccin 4.1.3.2. Las variables usadas son las siguientes:
Variable Tipo Descripcin
Indica si la seal Crtl+C se detect. 1 si no se ha detectado, 0 si

keepRunning int
se detecta.
time_loop int Establece en segundos el periodo del ciclo del polling.
conn MSQL Representa el manejo de la conexin a una base de datos. [15]
res MYSQL_RES Estructura que contiene las filas del resultado de una query. [15]
Es una representacin de una fila de datos. Esta implementado

como un arreglo de strings sin terminacin nula donde cada
row MYSQL_ROW
posicin del arreglo en una columna. Es importante aclarar que
este string no termina con carcter nulo (null terminated) [15]
server char host name del servidor.
user char Nombre del usuario MySQL
password char Contrasea del usuario MySQL
database char Nombre de la base de datos.
sql_query char [300] Contenedor de querys

Almacena la respuesta de la funcin POST_DATA. 0 si fue
res_post int
exitosa, -1 si hubo algn error. Inicia en -1.
Tabla 23 Variables de sync_engine.c
Antes de ejecutar cualquier funcin de la MySQL API para solicitar informacin, se establece la conexin
con el servidor a travs de la funcin mysql_real_connect. Esta funcin necesita la informacin del
servidor, del usuario y de la base de datos. Si la conexin no es correcta, el programa se detiene y el error
se muestra en standard output.
if (!mysql_real_connect(conn, server, user, password, database, 0, NULL, 0)){
fprintf(stderr, "%s\n", mysql_error(conn));
exit(1);}
Una vez establecida la conexin es posible empezar el polling para mantener la coherencia entre el estado
del interruptor y los comandos que el usuario realiz para operar el interruptor. El polling tiene un
intervalo time_loop, pero contina nicamente mientras la seal Crtl+C no sea detectada, es decir, si
keppRunning es 1.
- 40 -
/* EVERY time_loop SECONDS CHECK FOR UPDATES */
while (keepRunning){

/* SLEEP UNTIL NEXT CICLE */
sleep (time_loop);
}
De la tabla switch_next_state se quiere obtener cules son los comandos operados por el usuario que estn
pendientes por ser ejecutados, ordenados del ms reciente al ms antiguo. Esto se logra con la siguiente
query:
SELECT * FROM switch_next_state WHERE done=0 ORDER BY id DESC
La funcin de la API que ejecuta esta query es mysql_query, si la funcin es exitosa el resultado se
almacena en la variable res, en cambio si no es exitosa el programa se detiene y el error se muestra en
standard output.
/* CREATE THE QUERY IN STRING */
sprintf(sql_query,"SELECT * FROM switch_next_state WHERE done=0 ORDER BY
id DESC");
if (mysql_query(conn, sql_query))
{
exit(1);
}
/* SAVE THE RESULT */

res = mysql_store_result(conn);
A este punto, el ltimo comando pendiente por ejecutar se encuentra en la primera fila de la estructura res.
Estas filas se pueden leer con la funcin mysql_fetch_row(res) que retorna la siguiente fila de un resultado
res, es decir, cuando se llama por primera vez retorna la primera fila, si se llama una segunda vez retorna
la segunda fila, etc. Si el resultado est vaco mysql_fetch_row retorna NULL. El siguiente paso por lo
tanto, es obtener el ltimo comando pendiente por ejecutar, almacenarlo en la variable row y comprobar
que el resultado no este vaco.
/* VERIFIED THAT RES IS NOT EMPTY*/
if ((row = mysql_fetch_row(res)) != NULL)
{

}
Si el resultado no est vaco, el ltimo comando pendiente por ejecutar estar almacenado en row. Vale la
pena recordar que row es un arreglo de strings, donde cada posicin del arreglo corresponde a una
columna, ahora, de acuerdo a la Tabla 21, esto quiere decir que row[2] corresponde a la columna
next_state, y row[3] corresponde al nombre del item sobre el cual se quiere ejecutar el comando. El
siguiente paso es entonces enviar a OpenHAB el comando pendiente. Esto se hace a travs de la funcin
POST_data, la cual se encuentra en el fichero http_request.c y que se desarrollar en la siguiente seccin.
/* CONNECT TO THE REST API AND SEND THE NEWER COMMAND*/
if (strncmp(row[2], "ON", 2) == 0){
res_post = POST_data("ON",row[3]);
if (res_post != -1) {
DEBUG("Prendio");
}
}
else if (strncmp(row[2], "OFF", 2) == 0){

res_post = POST_data("OFF",row[3]);
if (res_post != -1){
DEBUG("Apago");
}
}
- 41 -
La funcin POST_data retorna 0 si el envo fue exitoso o -1 si hubo algn error, y este valor se
almacena en la variable res_post. Para asegurar que OpenHAB reciba el mensaje, el comando no se da por
ejecutado (done=1 en switch_next_state) si res_post no es igual a 0. Si en cambio res_post es igual a 0, la
query que establece como ejecutados los comandos es la siguiente:
UPDATE switch_next_state SET done=1 WHERE id<= <send command id>
Donde el id del comando que se envi a OpenHAB es row[0].
/* UPDATE THE REST OF THE COMMANDS TO DONE=1 IF POST IS A SUCCESS*/
if (res_post == 0){
sprintf(sql_query,"UPDATE switch_next_state SET done=1 WHERE
id<=%s", row[0]);
DEBUG(sql_query);
if (mysql_query(conn, sql_query))
{
exit(1);
}
/* DUMP THE RESULT */

mysql_free_result(res);
res_post = -1;
}
Lo ltimo que hay que realizar, antes de reiniciar el polling, es liberar el resultado con la funcin
mysql_free_result sobre la variable res.
Nota: El cdigo completo se encuentra en el ANEXO 4.
OpenHAB REST API
La REST API de OpenHAB sirve para diferentes propsitos: puede ser utilizada para integrar OpenHAB
con otro sistema, ya que permite el acceso a los items y sus estados, con permisos de lectura y escritura y
adems da acceso al sitemap, por lo que es la interfaz de comunicacin con el framework a ser utilizada
por usuarios remotos, como es el caso de este proyecto. Esto hace posible implementar una visualizacin
completamente independiente a la de OpenHAB. La URL de entrada para la REST API es:
http://localhost:8080/rest/.
cURL Linux
cURL es un paquete de software que consiste en herramientas de lneas de comando y una biblioteca para
la trasferencia de datos utilizando la sintaxis de URL. En este proyecto se usa para realizar un POST
HTTP.
4.5.2.3 http_request.c
En este archivo se encuentra la funcin POST_data usada en sync_engine.c. Esta funcin le comunica a la
REST API de OpenHAB un comando asociado a un item travs de un POST HTTP. Para lograr esto es
necesario usar la biblioteca libcurl, que requiere la configuracin descrita en la seccin 4.1.3.2.
Las variables usadas en este cdigo son:
Variable Tipo Descripcin

Es el handle y almacena las opciones que del mensaje que se
curl CURL
quiere mandar. [16]
Almacena el cdigo de error retornado por las funciones
res CURLcode
easy. Si el valor es CURLE_OK, la funcin fue exitosa. [16]
chunk struct curl_slist Es necesaria para establecer el header vacio.
url_to_post char [300] Almacena la URL en la que se va a hacer el POST.

Tabla 24 Variables de http_requesst.c
- 42 -
La funcin POST_data recibe dos variables: itemname, el nombre del item; y data, el comando.
Antes de poder llamar a cualquier funcin de la biblioteca curl.h es necesario inicializar el handler.
curl = curl_easy_init();
El mtodo POST necesita tener header, as que se le incluye uno vaco.

/* Blanck Header */
chunk = curl_slist_append(chunk, HEADER_POST_CONTENT);
/* Add the header */

curl_easy_setopt(curl, CURLOPT_HTTPHEADER, chunk);
La funcin curl_easy_setopt permite configurar el handle curl una opcin a la vez, y retorna un
CURLcode que informa si la configuracin fue exitosa.
CURLcode curl_easy_setopt(CURL *handle, CURLoption option, parameter) [16]
El primer parmetro es el handle a configurar, el segundo es la opcin a configurar y el tercero es el
parmetro con el que se va a configurar la opcin. Para el handle se configuraron 3 opciones la URL, el
mtodo HTTP y la informacin.
/* Set the URL */
sprintf(url_to_post,"http://localhost:8080/rest/items/%s",itemname);
curl_easy_setopt(curl, CURLOPT_URL, url_to_post);
/* Specify the method POST */

curl_easy_setopt(curl, CURLOPT_POST, 1L);
/* Now specify the data */

curl_easy_setopt(curl, CURLOPT_POSTFIELDS, data);
Una vez configurado el handle se realiza la peticin con la funcin curl_easy_perform y se almacena la
respuesta de la funcin en res. Por ltimo se evala si la respuesta es CURL_OK, si es diferente ocurri un
error y la funcin POST_data retorna -1, de lo contrario retorna 0.
/* Check for errors */
if(res != CURLE_OK)
{
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
return -1;
}
/* Cleanup */
curl_easy_cleanup(curl);
}
curl_global_cleanup();
return 0;
Nota: El cdigo completo se encuentra en el ANEXO 4.

4.5.3 Interfaz grfica
La interfaz grfica se implement para permitirle al usuario supervisar el estado de los sensores y operar el
interruptor, a travs de internet. Sin embargo, estas funcionalidades no fueron las nicas directrices que se
siguieron durante el diseo y la implementacin de la interfaz grfica. Para garantizar que la pgina fuera
accesible y funcional en la mayor cantidad de dispositivos, la filosofa de diseo que se sigui fue adaptar
la pgina al dispositivo, siguiendo los parmetros actuales de desarrollo usados al realizar una aplicacin
web. Con esto en mente, la estructura y las funciones de la pgina se implementaron para que trabajaran
de manera correcta primero en smartphones y luego en dispositivos con pantallas ms grandes. Esto
debido a que en una pantalla pequea no es fcil incluir demasiadas funciones, as que es aconsejable
definir la estructura de la pgina teniendo esto en cuenta. Fue conveniente entonces usar frameworks de
diseo web adaptativo, como es el caso de JQuery Mobile (este tema se desarrolla en la seccin 4.5.3.4).
- 43 -
El aspecto visual, tratado en la seccin 4.5.3.2, tiene un papel muy importante a la hora de desplegar
informacin. En una diagramacin congestionada no es fcil distinguir qu informacin es importante o
con qu objetos se puede interactuar, de tal manera que caractersticas como paleta de colores,
retroalimentacin a las acciones del usuario y sets de conos, ganan gran importancia. Todo esto posible
usando CSS, un lenguaje usado para definir el aspecto de un documento HTML.
En lo que respecta a las funcionalidades tcnicas de la interfaz grfica, esta fue concebida para que fuera
eficaz en futuros desarrollos de este proyecto. Esto implic que el cdigo fuera paramtrico en la mayor
cantidad de casos posibles, de esta manera no se limita a las especificaciones del sistema ac desarrollado,
expandiendo las posibilidades a ms dispositivos o a configuraciones de dispositivos ubicadas en ms de
un espacio.
El despliegue de grficas con estadsticas fue una caracterstica nueva que no era parte de la propuesta
inicial. Durante el desarrollo del proyecto se identific que era posible generarlas a partir de los estados de
los dispositivos almacenados en la base de datos. Dado que tal informacin ya estaba disponible, bast
usarla como se explica en la seccin 4.5.3.3. La herramienta escogida para esto fue la biblioteca
JavaScript Flot, basada en JQuery y enfocada en el trazo de grficas.
Por ltimo, como en el caso del motor de sincronizacin, se estableci un polling que lee los estados de
los dispositivos en la base de datos cada segundo. Con esto es posible supervisar los sensores en tiempo
real sin necesidad de recargar la interfaz grfica. Para lograr esto fue necesario usar la tcnica de
desarrollo web, AJAX.
Nota: El cdigo completo de la interfaz grfica puede ser consultado en el ANEXO 5.
4.5.3.1 Ambiente de desarrollo
En el servidor de HeliconiaTech se encuentran las siguientes carpetas usadas durante el diseo e
implementacin de la interfaz grfica.
Ilustracin 22 Ambiente de desarrollo de la interfaz grfica
Las carpetas icons e images, contienen las imgenes usadas por la interfaz. En images se localizan las
imgenes representativas de los dispositivos. En la carpeta javascripts estn ubicados todos los scripts
utilizados, varios de los cuales son bibliotecas JavaScript importadas para la implementacin de
funcionalidades especficas. En php_includes estn el cdigo PHP que se llama continuamente, como la
conexin a la base de datos. stylessheets contiene los archivos CSS que definen el aspecto de la pgina
web. index.php es el archivo principal de la interfaz grfica donde se implement la estructura HTML
bsica y las llamadas a los principales scripts.
4.5.3.2 Aspecto visual
La interfaz de usuario se implement con la finalidad de que fuera clara y sencilla. El usuario no tiene que
hacer ms de 2 clics para realizar cualquier accin. sta es adems completamente funcional en
smartphones y tiene caractersticas familiares para los usuarios de estos dispositivos, como el cono de
triple barra (), que es ampliamente reconocido como el acceso a un men.
- 44 -
El aspecto visual se configur usando principalmente CSS, un lenguaje usado para definir la presentacin
de las pginas web. La sintaxis de CSS es relativamente simple: primero se definen uno o varios selectores
que especifican que elementos se vern afectados y a continuacin se declara como se afecta el estilo de
estos elementos, siguiendo el formato propiedad:valor;. As que por ejemplo, el siguiente cdigo fue
usado para establecer el mximo ancho (propiedad) a 62.5em (valor) para los elementos de clase ui-
listview, contenidos en el elemento room_canvas (selector).
#room_canvas .ui-listview {
max-width: 62.5em;
}
Para este proyecto los selectores ms significativos son:
Selector Tipo Descripcin
room_canvas id Contiene la lista no ordenada de los widgets.
stats_canvas id Contiene el render de las grficas de las estadsticas.
nav-collapse clase Es la barra de navegacin.
widgetcont clase Es widget que contiene la informacin de los dispositivos.
widgetname clase El nombre del dispositivo.
deviceText clase Estado del dispositivo.
buttonSwitch clase Botones de ON y OFF para dispositivos de tipo interruptor.
deviceIcon clase cono del dispositivo.
flot-placeholder clase Imagen con la grfica de estadsticas.

Tabla 25 Principales selectores CSS
La paleta de colores que se us fue la oficial de HeliconiaTech, esta consiste de los siguientes colores en
formato hexadecimal: #ed275c (rosado), #8eba3e (verde) y #ababab (gris). El rosado est asignado a los
elementos con los que el usuario interacta, mientras que el verde identifica elementos o estados.
Las acciones del usuario estn retroalimentadas con efectos de volumen y de color. Un ejemplo de esto se
puede verificar cuando el usuario posiciona el cursor sobre un widget, el cual aparentemente se hunde
en la pantalla. Esta accin se realiz usando el selector li, junto a su pseudo-clase hover y la propiedad
CSS box-shadow.
Ilustracin 23 Ejemplo de retroalimentacin al usuario sobre el widget
4.5.3.3 Estructura
La interfaz grfica se divide principalmente en tres elementos HTML: el men, que le permite al usuario
navegar entre las posibles pginas; la pgina Home, que despliega la informacin de los dispositivos y le
permite operarlos; y la pgina Stats, que le informa al usuario los estados recientes de los dispositivos a
travs de una representacin grfica.
- 45 -
La siguiente ilustracin muestra la interfaz grfica en su diagramacin para pantallas grandes y resalta la
ubicacin del men de navegacin y de las pginas.
Ilustracin 24 Ubicacin del men y las pginas en la interfaz grfica
Men de navegacin
Con el men de navegacin el usuario puede escoger qu pgina desea visualizar. Las posibles pginas
son: Home y Stats. Para la apariencia de la barra de navegacin se utiliz el plugin de JavaScript
RESPONSIVE NAV (http://responsive-nav.com/). Este plugin no necesita bibliotecas y soporta distintos
tamaos de pantalla. La seccin 4.5.3.4 describe cmo el men es capaz de adaptarse a distintos
dispositivos.
El men de navegacin tiene la siguiente estructura HTML:
<div role="navigation" id="nav" class="nav-collapse closed" aria-hidden="false"
style="-webkit-transition: max-height 250ms; transition: max-height 250ms; position:
relative;">
<ul>
<li class="active"><a id ="home_menu" href="#">Home</a></li>
<li><a id ="stats_menu" href="#">Stats</a></li>
</ul>
</div>
<a href="#nav" id="toggle" aria-hidden="true">Menu</a>
En el archivo style.css ANEXO 5.

Home
El home es la pgina en donde se despliegan los widgets, nombre dado a la estructura que contiene el
nombre y el estado de cada dispositivo. El estado y el tipo de dispositivo se pueden ver representados en el
cono incluido en cada widget. Los conos se disearon para que reflejen de forma clara y concreta el
estado del dispositivo. Si esto no es posible, como en el caso del sensor de potencia, el estado actual se
visualiza en un elemento de texto.
Ilustracin 25 Ejemplo de un widget. Sensor de movimiento activado.
- 46 -
La estructura HTML de cada widget es la siguiente:
<div class="widgetcont">
//Aca se genera el cono
<img src="images/<'device type'>.png" class="ui-li-thumb deviceIcon <'device
name'>" data-itemid="<'item id'>" id="<'device name'>$icon">
//Aca se genera el nombre
<h2 class="widgetname"><'device name'></h2>
//Aca se genera el estado
<div class="ui-li-aside li-aside-btn">
<div class="deviceText ui-li-aside" data-itemid="<'item id'>"
id="<'device name'>$UPD">
N/A
</div>
</div>
</div>
Es importante mencionar que para un cono, los archivos de imagen tienen una codificacin como la
siguiente: tipo_de_dispositvo-estado.png. Estos archivos se encuentran en la carpeta images del ambiente
de desarrollo.
El widget responde en tiempo real a los cambios de estado del dispositivo. Sin embargo, para el cono esto
es posible nicamente en dispositivos con una cantidad finita de estados, ya que cada estado requiere una
imagen individual.
Estos cambios en tiempo real se implementaron usando la biblioteca de JavaScript JQuery. sta contiene
mtodos que responden a eventos HTML y permiten manipulacin de CSS, adems implementa funciones
con las cuales es posible escribir una sola lnea de cdigo para realizar tareas que requieren muchas lneas
de JavaScript regular.
La sintaxis de JQuery esta especficamente diseada para seleccionar elementos HTML y realizar una
accin sobre estos elementos. La sintaxis bsica de JQuery tiene la siguiente forma:
$(<selector>).<accin>()
El signo $ especifica que sta es una sintaxis JQuery, el selector especifica los elementos HTML, y la
accin es la funcin JQuery que se va a realizar sobre los elementos. Con JQuery es posible definir
acciones que se disparen nicamente con un evento HTML (onclick, onload, onmouseover, etc.)
Uno de los eventos HTML ms importantes en este proyecto es ready. Este evento indica que el
navegador ha cargado completamente el documento, ste es el momento ms recomendado para empezar a
ejecutar funciones.
$(document).ready(function(){
// Ac se puede empezar a trabajar sobre el documento que ya termino de cargar
});
Y es precisamente dentro de esta accin que se implementaron todas las funciones encargadas de
modificar en tiempo real la interfaz grfica, estas funciones se encuentran en el ANEXO 5.
Stats
La pgina stats contiene grficas que despliegan la historia de los estados de los dispositivos. Se
despliegan al menos los ltimos 20 estados disponibles en la base de datos. Para cambiar la visualizacin
entre la grfica de estados de un dispositivo y otro, se implement la siguiente barra de navegacin:
Ilustracin 26 Barra de navegacin de la pgina stats
La biblioteca JavaScript Flot fue utilizada para crear estas estadsticas. Flot renderiza las imgenes de las
estadsticas en un elemento HTML de clase flot-placeholder a partir de la configuracin que se encuentran
en el archivo flot.js ubicado en la carpeta javascript. Este archivo se encuentra en el ANEXO 5.
- 47 -
4.5.3.4 Autogenerado de los widgets
La interfaz grfica lee de la tabla items en la base de datos cuales son los items existentes y a partir de esta
informacin genera la estructura HTML para cada uno de estos. Esto se implement con PHP, que es un
lenguaje de programacin de lado servidor. Si las salidas (echos) PHP estn estructuradas como cdigo
HTML el web server es capaz de interpretarlos e imprimir la estructura de los elementos, de tal manera
que cuando el navegador est cargando la interfaz grfica los contenedores de los widgets ya estn
generados.
4.5.3.5 Diseo para celulares
Para enero del 2014 [17] se identific que la distribucin de los tamaos de pantalla de los dispositivos
con acceso a internet y que hacen uso de los principales navegadores fue la siguiente:
Ancho de Cantidad de
Pantalla Dispositivos 768 px y menor
menor a 768 px 37%
800 px
800 px 8%
900 px
900 px 13%
1024 px
1024 px 8%
1050 px 1050 px
5%
1080 px 1080 px
13%
1200 px 3% 1200 px
mayor a 1440 px 10%
Ilustracin 27 Tendencia de los tamaos de pantalla en enero del 2014
A partir de esto datos se crearon 3 intervalos de tamao de pantalla en los cuales la interfaz grfica
presenta una diagramacin especfica para cada uno. Los intervalos son los siguientes: menor a 768px,
entre 768px y 1022px, y mayor a 1022px.Para esto fue necesario especificar en CSS la apariencia de la
diagramacin para cada intervalo usando la siguiente sintaxis:
@media ( min-width: <'tamao en pixeles'> ) {
//Ac se modifican las propiedades CSS para cada intervalo de tamao de pantalla
}
El desarrollo se apoy en el framework JavaScript JQuery Mobile, el cual provee clases de elementos
HTML5 que se adaptan automticamente a los distintos tipos de pantalla.
Diagramacin para menos de 768px (48em)
Esta es la versin para celulares, que de acuerdo a la Ilustracin 27, corresponde al tamao de pantalla
ms usado. Ac los widget se despliegan como componentes de una lista no ordenada. El men de
navegacin se reduce a un cono de triple barra () que despliega las posibles pginas cuando es activado
por el usuario. El aspecto visual logrado para este tamao de pantalla es el siguiente.
Ilustracin 28 Diagramacin de la interfaz grfica para menos de 768px
- 48 -
Diagramacin entre 768px (48em) y1022px (63.75em)
Este tamao de pantalla corresponde a la mayora de las tabletas en modo landscape. Ac existe un poco
ms de espacio y es posible desplegar el men completamente. A los widget se les asigna un aspecto
cuadrado y se organizan en una cuadrcula a 2 columnas.
Ilustracin 29 Diagramacin de la interfaz grfica entre 768px y 1022px
Diagramacin para ms de 1022px (63.75em)

Para aprovechar ms el espacio, los widget se organizados en una cuadrcula a tres columnas, con un valor
de mximo ancho fijo lo que impide que los widgets se deformen demasiado en pantallas muy grandes.
Ilustracin 30 Diagramacin de la interfaz grfica para ms de 1022px
- 49 -
5. ANLISIS DE RESULTADOS
El sistema de domtica fue evaluado con respecto a cmo sera percibido por el usuario. Como la interfaz
grfica es la herramienta que le permite al usuario interactuar con el sistema, sta ser la principal
referencia de desempeo. Otras partes del sistema como el Gateway y la red Z-Wave tambin pueden
afectar la experiencia del usuario pero nicamente en casos de fallas crticas.
5.1 YSlow y PageSpeed Insights

Es preciso analizar el desempeo de la interfaz grfica como pgina web. Dos herramientas populares para
evaluar el desempeo de un sitio web son YSlow, desarrollado por Yahoo, y PageSpeed Insights,
desarrollado por Google. Ambas herramientas analizan la pgina, le otorgan una calificacin que indica
qu porcentaje de parmetros de evaluacin son superados y al final ofrecen consejos de cmo mejorar el
desempeo de la pgina
PageSpeed Insights mide el rendimiento de las pginas para dispositivos mviles y para ordenadores.
Obtiene la URL dos veces, una vez con un agente de usuario para mviles, y otra con un agente de usuario
para ordenadores. La puntuacin que otorga va de 0 a 100 puntos y mientras ms alta sea corresponde a un
mejor desempeo [18].
PageSpeed Insights mide cmo la pgina puede mejorar el rendimiento de los siguientes factores:
Tiempo de carga en la mitad superior de la pgina: Tiempo transcurrido desde el momento en que
un usuario solicita una pgina nueva hasta que el navegador muestra el contenido de la mitad
superior.
Tiempo de carga completa de la pgina: Tiempo transcurrido desde el momento en que un usuario
solicita una pgina nueva hasta que se muestra completamente en el navegador.
YSlow genera su resultado a travs de 3 fases [19]. La primera fase recorre el dominio y encuentra
todos sus componentes (imgenes, scripts, stylesheets, etc.), la segunda obtiene toda la informacin de
cada componente (tamao, tiempo de carga, compresin, errores de headers, etc.), y por ltimo se evala
cada regla independientemente y produce el resultado general.
En la pgina gtmetrix.com es posible obtener el resultado de estas dos herramientas al mismo tiempo, lo
que facilit el anlisis de los resultados. En un primer anlisis los resultados fueron: PageSpeed Insights
85% y YSlow 83%. Un tiempo de carga de 3.25 segundos y las siguientes reglas con una evaluacin
menor a 90%.
Leverage browser caching server: Es una regla de PageSpeed de lado server. Indica que existen
recursos a los que se les recomienda especificar una vida til de al menos una semana, lo que
mejora las visitas continuas a la pgina ya que varios recursos permanecen guardados en el cliente.
Add Expires headers: Es una regla de YSlow de lado server. Al igual que el anterior punto
recomienda aadir headers con fechas de vencimiento a los recursos para que el navegador no los
cargue en cada visita.
Use a Content Delivery Network: Es una regla de YSlow de lado server. Esta regla recomienda
establecer una red de entrega de contenidos, que es una red de computadoras que contienen copias
de los recursos de la pgina y se usan con el fin de maximizar el ancho de banda.
Optimize the order of styles and script: Es una regla de PageSpeed de lado cliente. Indica que se
deben no debe cargar scripts externos antes de que se carguen los stylesheets.
Defer parsing of JavaScript Es una regla de PageSpeed de lado cliente. Recomienda definir la carga
los archivos de JavaScript no indispensables en el final del documento, as ste carga ms rpido.
Optimize images: Es una regla de PageSpeed de lado cliente. Los navegadores modernos son
capaces de cargar y analizar recursos comprimidos, que son de menor tamao, no pierden calidad y
mejoran la carga de la pgina.
- 50 -
Las 3 primeras indicaciones estn relacionadas con el servidor y recomiendan tcnicas para conservar
recursos cargados y proporcionar ms ancho de banda. Estos temas se salen de los alcances de este
proyecto, por lo que estas indicaciones se tendrn en cuenta pero no se aplicarn.
Las siguientes reglas Optimize the order of styles and script y Defer parsing of JavaScript, comentan
sobre cmo el documento es cargado por el cliente y recomiendan reorganizar la posicin del JavaScript
en el cdigo para poder realizar varias solicitudes simultneamente. Una vez observado esto se procedi a
analizar el cdigo en el cual fue detectado que efectivamente muchos de los scripts en el head HTML
estaban incluidos antes de otros recursos como stylesheets y elementos HTML.
Fue suficiente con reorganizar el cdigo de manera que los archivos ms pesados se cargaran al final del
documento, incluidos el framework JQuery Mobile y los scripts de las estadsticas. Un resultado colateral
de esta reorganizacin fue que en los dispositivos de ms de 768px, qu tienen una diagramacin de la
interfaz grfica con los widgets ubicados en una cuadricula a 2 o 3 columnas, se percibi que durante un
pequeo instante en la carga de la pgina, los widgets estn aparentemente desorganizados y no tienen el
ancho correcto. Sin embargo este efecto es extremadamente corto por lo que no se consider como un
problema. Con los que respecta a las imgenes, se procedi a comprimir todos los conos y las imgenes
de background, usando la herramienta recomendada por gtmetrix, smush.it la cual es desarrollada por
Yahoo. Una vez completados estos cambios se volvi a evaluar la interfaz grfica en la gtmetrix y se
obtuvo el siguiente resultado, ampliamente satisfactorio:
Ilustracin 31 Resultado de gtmetrix para la interfaz grfica
5.2 Compatibilidad del sistema

Una vez el desempeo de la interfaz grfica fue mejorado considerablemente, fue posible proceder a
evaluar la compatibilidad del sistema con dispositivos y navegadores:
Dispositivo Tamao de pantalla Navegador
Motorola Moto G 720 x 1280 px Chrome Android 39.0.2171
LG G PAD 8.3 1920x1,200 px Chrome Android 39.0.2171
iPhone 4s 960x640 px Safari iOS 8.1
iPad 2 1024x768 px Safari iOS 8.1
MacBook Air 2013 1,440x900 px 1.0.3 Mac OS X v10.2 "Jaguar
Dell XPS 15 1366x768 px Chrome 39.0.2171.65 m

Tabla 26 Compatibilidad de la interfaz grfica con diferentes dispositivos
- 51 -
Con estos dispositivos se ejecutaron las siguientes pruebas que evalan las funcionalidades bsicas del
sistema:
Visualizacin correcta de la interfaz grfica. conos, nombres y diagramacin de los widgets de
todos los dispositivos.
Actualizacin automtica del estado e cono del sensor PIR del dispositivo AeonLabs Aeotec Z-
Wave Multisensor.
Actualizacin automtica del estado del dispositivo AeonLabs - Z-wave Smart Energy Switch
(DSC06106-ZWUS) cuando se le conectara una lmpara encendida.
Actualizacin automtica del estado e cono del dispositivo Jasco Z-Wave Lighting Control On/Off
Switch, (45609), cuando se operara el interruptor manualmente.
Encendido y apagado del interruptor Jasco Z-Wave Lighting Control On/Off Switch, (45609) a
travs de la interfaz grfica.
Actualizacin automtica del estado e cono del dispositivo Jasco Z-Wave Lighting Control On/Off
Switch, (45609), cuando se operara a travs de la interfaz grfica.
Todas las pruebas anteriores fueron exitosas en todos los dispositivos y navegadores. As mismo se
comprob la adicin exitosa a la interfaz grfica del sensor de luminancia presente en el dispositivo
AeonLabs Aeotec Z-Wave Multisensor.
A continuacin se muestra una captura de pantalla del iPhone 4s que muestra la diagramacin de menos
de 768px en este dispositivo:
Ilustracin 32 Captura de pantalla iPhone 4s. Diagramacin de la interfaz grfica para menos de 768px.
- 52 -
A continuacin una captura de pantalla del LG G PAD 8.3 en modo landscape que muestra la
diagramacin entre 768px y 1022px:
Ilustracin 33 Captura de pantalla modo landscape de LG G PAD 8.3. Diagramacin para pantalla entre 768px y 1022px
El resto de las capturas de pantalla de todos los dispositivos pueden ser encontradas en el CD anexado,
carpeta Compatibilidad.
Con la prueba de visualizacin se puede considerar un xito la implementacin del autogenerado de los
widgets, aadiendo sta como una caracterstica adicional a la propuesta original.
Otra funcionalidad adicional que se implement para este proyecto fue la pgina con estadsticas. sta
muestra la historia de hasta 20 estados para los 4 items: Luz, Movimiento, Consumo y Luminancia. La
ilustracin a continuacin es un mosaico de estas estadsticas con capturas de pantalla del iPhone 4s.
Ilustracin 34 Capturas de pantalla en el iPhone 4s de las estadsticas de Power, ON-OFF Switch, PIR Sensor y Luminance
Para crear estas grficas la biblioteca FLOT lee la informacin y luego renderiza la imagen con un ancho
fijo que se adapta a la pantalla en la que se est visualizando. Ahora, teniendo en cuenta que en un
dispositivo mvil el ancho de pantalla no es fijo ya que en cualquier momento el usuario puede cambiar la
orientacin del dispositivo, si los elementos no responden automticamente a estos cambios, como es el
caso con las estadsticas, pueden darse problemas particulares, como el que se demuestra en la Ilustracin
35, en donde la pgina de estadsticas fue renderizada con la orientacin portrait y momentos ms tarde la
orientacin del dispositivo fue cambiada a landscape.
- 53 -
Ilustracin 35 Capturas de pantalla del iPhone 4s cambiando orientacin de portrait a landscape
Como se puede observar, al cambiar la orientacin la grfica con las estadsticas no se expandi para
ocupar todo el ancho de la pantalla, aun si la grfica se encuentra todava disponible con toda la
informacin desplegada para el usuario. Desafortunadamente esta es una limitacin del mecanismo
utilizado por la biblioteca FLOT para la generacin de las grficas la cual no es posible resolver de un
modo sencillo. Como alternativa propuesta se podra pintar cada cierto tiempo la grfica, sin embargo esto
impactara fuertemente las prestaciones de la interfaz de usuario, consumiendo recursos innecesariamente
y afectando la facilidad de uso, criterio de suma importancia en este proyecto.
5.3 Estabilidad del sistema

Para comprobar la estabilidad del sistema se realiz un uso real de ste durante un periodo de una semana.
Como protocolo de verificacin se realizaron pruebas de las funcionalidades bsicas del sistema
regularmente con intervalos de tiempo diversos entre las acciones.
En cada punto de verificacin se revis el estado de la red Z-Wave, el log de OpenHAB, el debug en
consola del motor de sincronizacin y la actividad del procesador de la RaspberryPi. Los archivos de log
del sistema correspondientes a estas pruebas se encuentran en el CD adjunto a este documento y
corresponden al ANEXO 6.
5.3.1 La red Z-Wave
Como se explic en la seccin 4.3.4, HABmin tiene funcionalidades para administrar la red Z-Wave, entre
las cuales se incluye el estado actual de los dispositivos conectados. Esto se verifica a travs de un
pequeo indicador junto al nombre del dispositivo que puede ser gris, amarillo, verde o rojo. Si es gris,
entonces ste indica que el dispositivo no ha completado su inicializacin. Si es rojo, el nodo est
MUERTO, y si es verde, el nodo est VIVO. Si es amarillo, el nodo se encuentra operando de manera
correcta, sin embargo, ha estado muerto durante las ltimas 24 horas o tiene un contador de reintentos
de arranque mayor al 5%.
Durante el momento de la creacin de la red solo el dispositivo Smart Energy Switch tena su indicador en
amarillo, los otros 3 se encontraban vivos. A partir del segundo da el estado de todos los dispositivos era
el siguiente:
- 54 -
Ilustracin 36 Administrador Z-Wave de HABmin con todos los dispositivos vivos
El estado de la red Z-Wave del sistema completo se mantuvo en este estado durante toda la semana de
prueba.
5.3.2 Log de OpenHAB
En 5 ocasiones durante las pruebas peridicas de funcionalidad del sistema se detect que los estados en la
interfaz grfica no correspondan a los estados reales en los dispositivos, es decir no estaba funcionando la
actualizacin automtica de los estados. Durante estos eventos el siguiente mensaje apareci en el log de
OpenHAB:
ERROR o.o.p.m.i.MysqlPersistenceService[:345]- mySQL: Error count exceeded 1.
Disconnecting database.
Este mensaje indica que la cantidad de errores al realizar querys a la base de datos excedi el parmetro
mysql:reconnectCnt, que se encuentra definido en 1 en el archivo openhag.cfg. Este contador define la
cantidad mxima de errores que la persistencia MySQL de OpenHAB puede ignorar antes de intentar una
reconexin.
Sin embargo en cada una se estas 5 eventos el sistema presento un tiempo de recuperacin comprendido
entre 2 y 20 minutos, recuperando las funcionalidades de actualizacin automtica de los estados, es decir
que la conexin a la base de datos fue restablecida.
Estos errores pueden tener varios orgenes, lo ms probable es una interrupcin de la conexin entre el
gateway y la base de datos debido a intermitencia en la conexin a internet, o que el servidor de
HeliconiaTech no se encontrara disponible. Tambin puede ser un error en el addon de persistencia de
OpenHAB, factores externos al sistema e imposibles de controlar.
El sistema de domtica desarrollado tiene una arquitectura dependiente de que los estados reales de los
dispositivos encuentren en la base de datos, si esto falla no es posible controlar ni supervisar los
dispositivos.
Para la ejecucin de estas pruebas el motor de sincronizacin fue compilado y generado con la opcin de
debug activada. Ac es posible ver los errores de las bibliotecas usadas o si los POST HTTP fueron
exitosos. Durante la inicializacin de OpenHAB y el motor de sincronizacin, ste ltimo es mucho ms
rpido.
Ahora, en el caso particular de que exista un comando pendiente en la tabla switch_next_state esto quiere
decir que el motor de sincronizacin comienza a intentar transmitirle el estado a la REST API, la cual no
ha iniciado, caso que se encuentra cubierto por el sistema. El motor de sincronizacin reintenta la
transmisin hasta que pueda mandar el dato, durante cada iteracin se ve el siguiente mensaje en la
consola.
curl_easy_perfom() failed: Couldnt connect to server
El problema que se detect es que en la secuencia de inicializacin de OpenHAB, el web server Jetty,
encargado de interpretar los mtodos HTTP en OpenHAB, inicia primero que la REST API. Esta
particularidad en el arranque de los componentes de OpenHAB genera el siguiente mensaje en la consola
del motor de sincronizacin:
- 55 -
<html>
<head>
<meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/>
<title>Error 404 Not Found</title>
</head>
<h2>HTTP ERROR: 404</h2>
<p>Problem accesing /rest/items/Switch_Luz_Habitacion. Reason:
<pre> Not found</pre></p>
<body>
</body>
</html>
Este mensaje no es interpretado por la biblioteca cURL como un error, sino que simplemente es la
respuesta al mensaje transmitido, lo que se identifica equivocadamente como un xito. Esto implica que
este primer comando que estaba pendiente en la tabla switch_next_state se perdi.
Posibles soluciones a esta problemtica consisten en atrapar este mensaje y detectar el ERROR 404, para
identificar esta transmisin como fallida. Otra posibilidad es que luego de transmitir el comando se
verifique que el estado del item de OpenHAB fue actualizado con este comando, si no fue as se identifica
la transmisin como fallida, sin embargo tales validaciones fueron dejadas para futuras iteraciones de este
proyecto.
5.3.4 Rendimiento de la RaspberryPi
Para evaluar el rendimiento de la RaspberryPi se us el comando Linux top, que supervisa la actividad del
procesador en tiempo real, desplegando una lista de las tareas ms pesadas en cuanto a su carga
computacional en el sistema, ordenndolas por uso de CPU.
Durante la inicializacin simultnea de OpenHAB y del motor de sincronizacin, se detect una intensa
actividad en la CPU como lo indica la siguiente captura de pantalla de la consola. OpenHAB es el proceso
con identificacin 2400.
Ilustracin 37 Uso CPU IZQ: Durante inicializacin de OpenHAB IZQ: Todos los servicio de OpenHAB cargados
Una vez todos los servicios de OpenHAB terminaron de cargar, el uso de la CPU disminua
considerablemente. En ningn momento se detect que el uso de la CPU sobrepasara el 25%.
- 56 -
5.4 Anlisis econmico del sistema
En primera instancia se retomar el costo de los distintos elementos utilizados para el desarrollo del
sistema de domtica:
Dispositivo Precio (USD)
Accesorios varios 15,00
Aeon Labs Aeotec Z-Wave Multi-Sensor 48,45
Aeon Labs Z-Wave Smart Energy Switch 37,99
Canakit RaspberryPI Basic Kit (Black case) 70,67
Jasco 45609 Z-Wave Wireless On/Off Switch 39,99
TOTAL 212,10
Tabla 27 Costo de los elementos del sistema
El costo total de los dispositivos fue de 212,10 dlares Ahora si se quisiera comercializar el sistema habra
que aadir el precio de desarrollo y de las posibilidades del mismo, teniendo en cuenta posibles
competidores. Ahora, el precio del desarrollo depende del modelo de negocio que se implemente, en el
caso de una venta nica, sin suscripciones ni mensualidades, es una prctica comn que el precio del
desarrollo sea la mitad del costo del proyecto final. As que si los nicos gastos son el desarrollo y los
dispositivos obtenemos un valor final de 424,20 dlares.
- 57 -
6. CONCLUSIONES
El objetivo de este proyecto consista en controlar de manera remota una habitacin a travs de internet.
Tal meta se alcanz obteniendo adems conclusiones que van ms all de la posibilidad de controlar
completamente una casa o un edificio, como una visin de lo que puede llegar a ser el futuro y de cules
son las herramientas necesarias para participar en l. Teniendo en cuenta el potencial del IoT para los
prximos aos, la evolucin de las diferentes tecnologas asociadas y la integracin de ms y ms
dispositivos en la vida cotidiana de todas las personas, es interesante contemplar nuevos escenarios en que
un sistema similar al planteado en este documento tenga cabida. Por tal motivo y como se indic en
diferentes oportunidades, cada uno de los componentes del proyecto se dise y se desarroll pensando en
la realizacin de posibles trabajos futuros y ms iteraciones del mismo. OpenHAB es una herramienta
muy til para desarrollar e implementar tales escenarios. Con una comunidad siempre creciente de
desarrolladores es un claro ejemplo de lo que se puede lograr a travs de proyectos de software libre,
adems actualmente cuenta con soporte para una gran variedad de protocolos de comunicacin y
dispositivos, hecho que junto a su sistema de definicin de reglas para automatizar procesos con base en
eventos internos y externos al sistema, permite la creacin de novedosas y flexibles soluciones a distintas
problemticas y aplicables en diferentes contextos. Este proyecto es un ejemplo del potencial de este
framework y si bien no es un producto finalizado, es factible que a travs de la adicin de nuevos
dispositivos, mejoras en su seguridad y estabilidad a travs de procesos redundantes y de autenticacin, un
trabajo de diseo grfico y perfeccionamiento de la interfaz de usuario, as como la mejora continua en la
infraestructura del servidor haran de ste un sistema robusto para el control completo de una vivienda,
una oficinas e incluso grandes establecimientos comerciales, caractersticas que junto a su bajo costo de
implementacin hacen que sea econmicamente viable.
El desarrollar un sistema completo exigi especificar cmo cada elemento tendra que funcionar junto a
otro, incluso si estos no fueron diseados para trabajar juntos. Es esencial contar con las herramientas
adecuadas que tengan la flexibilidad y la potencia para conectar tales elementos as como con una
infraestructura que soporte estas caractersticas. La seleccin de la RaspberryPi como plataforma hardware
fue un factor importante para satisfacer dicha filosofa de desarrollo. Su versatilidad, soporte, y poder de
clculo permitieron que soportara la arquitectura software diseada para el sistema y teniendo en cuenta
que nunca se super un uso de sus prestaciones ms all del 25% de los recursos es posible reutilizarla en
desarrollos futuros en los cuales se necesite mayor potencia de procesamiento. OpenHAB, por su parte, se
identifica plenamente con esta ideologa puesto que su principal caracterstica es ser completamente
independiente de la plataforma en que se usa y de los dispositivos conectados al sistema. Por ltimo, una
interfaz de control web, que garantiza ser compatible con cualquier navegador moderno y por tanto con la
gran mayora de aparatos desde los cuales se quisiera interactuar con el sistema, completa el conjunto de
pilares que soportan el sistema.
Por ltimo, como cualquier avance en el campo de la tecnologa, los mecanismos y componentes
utilizados en el desarrollo de este proyecto no se encuentran exentos de problemas y limitaciones
prcticas. La necesidad de infraestructura dedicada, como es el caso del servidor, genera dificultades al
momento de difundir una solucin de este tipo en entornos sin acceso a este tipo de recursos. Las
interfaces grficas se basan en la experiencia de usuario, un concepto difcil de desarrollar debido a que no
todos sus parmetros son cuantificables y aunque en el proyecto se logr implementar una agradable
interaccin con los dispositivos en un ambiente controlado, si se desearan incluir nuevas funcionalidades,
sta tendra que ser replanteada. De igual manera, aun cuando Z-Wave es un protocolo de comunicacin
validado en el mercado y ya difundido en el campo, presenta algunos problemas, muchas veces invisibles
para el usuario final, pero que impactan en gran medida el funcionamiento del sistema.
- 58 -
7. BIBLIOGRAFA
[1] CISCO, The Internet of Things: How the Next Evolution of the Internet Is Changing Everything,
2011.
[2] Eclipse Foundation, Eclipse Luna, Febrero 2004. [En lnea]. Available:
https://www.eclipse.org/legal/epl-v10.html.
[3] R. Mohd y S. B. Mirza, Evolution of Home Automation Technology, BVICAMs International

Journal of Information Technology, 2009.
[4] J. Yick, B. Mukherjee y D. Ghosal, Wireless sensor network survey, ELSEVIER: Computer
Networks, 2007.
[5] D. Puccinelli y M. Haenggi, Wireless Sensor Networks: Applications and Challenges of Ubiquitous
Sensing, IEEE CIRCUITS AND SYSTEMS MAGAZINE, pp. 19-29, 2005.
[6] OpenHAB, OpenHAB, 2014. [En lnea]. Available: www.openhab.org.
[7] IQJAR, An overview and comparison of todays single-board micro computers, 15 01 2013. [En
lnea]. Available: http://iqjar.com/jar/an-overview-and-comparison-of-todays-single-board-micro-
computers/. [ltimo acceso: 10 10 2013].
[8] AeonLabs, Aeotec - Z-Stick 2E manual, AeonLabs, 2014. [En lnea]. Available:
http://aeotec.com/z-wave-usb-stick/913-z-stick-manual-instructions.html. [ltimo acceso: 2014].
[9] AeonLabs, Aeotec - Multisensor Manual, AeonLabs, 2014. [En lnea]. Available:
http://aeotec.com/z-wave-sensor/47-multisensor-manual.html. [ltimo acceso: 2014].
[10] AeonLabs, Aeotec - Smart Energy Switch Manual, AeonLabs, 2014. [En lnea]. Available:
http://aeotec.com/z-wave-plug-in-switch/942-smart-energy-switch-manual-instructions.html. [ltimo
acceso: 2014].
[11] Jasco, On/Off Relay Switch and 3-Way Switch Kit, 2009.
[12] OpenHAB, Explanation of items - openhab/openhab wiki, 3 10 2014. [En lnea]. Available:
https://github.com/openhab/openhab/wiki/Explanation-of-items. [ltimo acceso: 2014].
[13] C. Jackson, HABmin wiki - Z-Wave Configuration, GitHub, 11 05 2014. [En lnea]. Available:
https://github.com/cdjackson/HABmin/wiki/Z-Wave-Configuration. [ltimo acceso: 2014].
[14] AeonLabs, Aeon Labs MultiSensor(SW Version:V1.17), Manual.
[15] Oracle Corporation, MySQL 5.5 Reference Manual - 23.8 MySQL C API, [En lnea]. Available:
http://dev.mysql.com/doc/refman/5.5/en/c-api.html. [ltimo acceso: 2014].
[16] cURL, Using The libcurl C Interface, [En lnea]. Available: http://curl.haxx.se/libcurl/c/. [ltimo
acceso: 2014].
- 59 -
[17] Website Dimensions, Enero 2014. [En lnea]. Available: http://www.websitedimensions.com/.
[18] Google Developers, Acerca de PageSpeed Insights, [En lnea]. Available:

https://developers.google.com/speed/docs/insights/about. [ltimo acceso: 2014].
[19] YSlow, YSlow FAQ, [En lnea]. Available: http://yslow.org/faq/#faq_work. [ltimo acceso:
2014].
[20] CISCO, Embracing the Internet of Everything, 2013.
[21] Ericsson, More than 50 billion connected devices, 2011.
[22] R. J. Caleira, Home Automation - A Step Towards Better Energy Management, 2012.
[23] M. Aiello y S. Dustdar, Are our homes ready for services? A domotic infrastructure based on the
Web service stack, Pervasive and Mobile Computing, vol. 4, n 4, pp. 506-525, 2008.
[24] D. Bonino y F. Corno, Modeling, simulation and emulation of Intelligent Domotic Environments,
Automation in Construction, vol. 20, n 7, pp. 967-981, 2011.
[25] F. Mattern y C. Floerkemeier, From the Internet of Computers to the Internet of Things, 2011.
[26] M. Raffel, openHAB Empowering the Smart Home, Vienna University, 2014.
[27] Telkonet, EcoSmart Wireless Technology Coexists Seamlessly with Common In-Building Wireless
Networks, 2014.
[28] HES, Environmental Energy Technologies Division Lawrence Berkeley National Laboratory,
2014. [En lnea]. Available: http://hes-documentation.lbl.gov/calculation-methodology/calculation-
of-energy-consumption/major-appliances/miscellaneous-equipment-energy-consumption/default-
energy-consumption-of-mels. [ltimo acceso: 2014].
- 60 -
ANEXOS
ANEXO 1: ACRNIMOS
AJAX.. Asynchronous JavaScript And XML

API. Application Programming Interface
ARM... Advanced RISC Machine
CDMA Code division multiple access
CPU Central processing unit
CSS.... Cascading style sheets version
GPIO.. General Purpose Input/Output
GPRS. General Packet Radio Service
GUI Graphic User Interface
GSM.. Global System for Mobile Communications
HTML.... HyperText Markup Language
IBSG... Internet Business Solutions Group
IEEE... Institute of Electrical and Electronics Engineers
IoT... Internet of Things
ISP....... Internet Service Provider
IxRTT. Interexchange Radio Transmission Technologies
LAN Local area network
LAMP. Linux, Apache, MySQL, PHP
NOOBS New Out Of the Box Software
OSGi... Open Services Gateway Initiative
PIR Passive Infrared
PHP. Hypertext Preprocessor
RAM... Random Access Memory
REST... Representational state transfer
RISC... Reduced Instruction Set Computer
SBC. Single Board Computers
SO... Sistema operativo
SQL. Structured Query Language
SSH. Secure Shell
SW... Software
- 61 -
TCP/IP. Transmission Control Protocol / Internet Protocol
URL. Uniform Resource Locator
VM... Virtual Machine
XML eXtensible Markup Language
WSN Wireless Sensor Network
- 62 -
ANEXO 2: PREPARACIN DE LA PLATAFORMA
Con el objetivo de instalar y configurar Raspbian es necesario realizar los comandos indicados en esta
seccin.
Actualizacin del sistema operativo
pi@raspberrypi ~ $ sudo apt-get update
pi@raspberrypi ~ $ sudo apt-get upgrade
Instalacin JAVA 1.71

pi@raspberrypi ~ $ apt-get install oracle-java7-jdk
pi@raspberrypi ~ $ update-alternatives set java /usr/lib/jvm/jdk-7-oracle-armhf/jre/bin/java
Para verificar la instalacin correcta de JAVA se debe visualizar lo siguiente con el argumento version
pi@raspberrypi ~ $ java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode)
Instalacin biblioteca libmysqlclient

pi@raspberrypi ~ $ sudo apt-get install libmysqlclient-dev
Instalacin biblioteca libcurl

pi@raspberrypi ~ $ sudo apt-get install libcurl-dev
- 63 -
ANEXO 3: CONFIGURACIN DE OPENHAB
En el archivo de configuracin openhab.cfg se modificaron las siguientes lneas:
Lo primero es fijar MySQL como la persistencia por defecto.
34 # The name of the default persistence service to use

35 persistence:default=mysql
Configuracin de la persistencia MySQL.

286 ############################ SQL Persistence Service
##################################
287 # the database url like 'jdbc:mysql://<host>:<port>/<user>'
288 mysql:url=jdbc:mysql://heliconiatech2.bitnamiapp.com:3306/test_sql
289
290 # the database user
291 mysql:user=XXXXXX
292
293 # the database password
294 mysql:password=XXXXXX
295
296 # the reconnection counter
297 mysql:reconnectCnt=1
Nota: XXXXXX es informacin privada que se censur.

Indicar al framework donde se encuentra el adaptador de Z-Wave
931 ################################ Z-Wave Binding
######################################
932 #
933 # The Z-Wave controller port. Valid values are e.g. COM1 for Windows and
/dev/ttyS0 or
934 # /dev/ttyUSB0 for Linux
935 zwave:port= /dev/ttyUSB0
936
937 # Z-Wave nightly heal time. This is the hour (eg 2AM) at which the automatic
nightly
938 # network heal will be performed.
939 zwave:healtime=2
Configuracin de la persistencia
// persistence strategies have a name and a definition and are referred to in the
"Items" section
Strategies {
// if no strategy is specified for an item entry below, the default list will be
used
default = everyChange
}
/*
* Each line in this section defines for which item(s) which strategy(ies) should be
applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of
a group
* item (excl. the group item itself).
*/
Items {
// persist the rain values at every change and every hour
Energy_Consumo_Habitacion:strategy = everyChange, restoreOnStartup
Movement_Movimiento_Habitacion: strategy = everyChange, restoreOnStartup
Switch_Luz_Habitacion: strategy = everyChange, restoreOnStartup
Luminance_Luminancia_Habitacion: strategy = everyChange, restoreOnStartup
}
- 64 -
ANEXO 4: MOTOR DE SINCRONIZACIN
En el CD adjunto se encuentra el cdigo fuente completo de este paquete software, siguiendo la estructura
planteada en la Seccin 4.5.2.1, Entorno de programacin.
ANEXO 5: INTERFAZ GRFICA

En el CD adjunto se encuentra el cdigo fuente completo de este paquete software, siguiendo la estructura
planteada en la Seccin 4.5.3.1, Ambiente de desarrollo.
ANEXO 6: OPENHAB - RUNTIME

En el CD adjunto se encuentra la carpeta runtime de OpenHAB usada y configurada para el desarrollo de
este proyecto, siguiendo la estructura planteada en la Seccin 4.2, OpenHAB.
- 65 -
ANEXO 7: IMGENES DE LOS DISPOSITIVOS
Las siguientes son imgenes de los sensores y actuadores usados en este proyecto
Aeon Labs Aeotec Z-Wave Multisensor
Jasco Z-Wave Lighting Control On/Off Switch, (45609)
AeonLabs - Z-wave Smart Energy Switch (DSC06106-ZWUS)
- 66 -

Daniel Eduardo Martínez Vargas, "Sistema de Domótica para Control y Supervisión de Una Habitación de Manera Remota"

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Daniel Eduardo Martínez Vargas, "Sistema de Domótica para Control y Supervisión de Una Habitación de Manera Remota"

Enviado por

Direitos autorais:

Formatos disponíveis

SISTEMA DE DOMTICA PARA CONTROL Y SUPERVISIN DE UNA

HABITACIN DE MANERA REMOTA

DANIEL EDUARDO MARTNEZ VARGAS

PONTIFICIA UNIVERSIDAD JAVERIANA

DANIEL EDUARDO MARTNEZ VARGAS

ING. DAVID FERNANDO SUREZ DAZ, M.SC.

PONTIFICIA UNIVERSIDAD JAVERIANA

DIRECTOR DEL PROYECTO:

Artculo 23 de la Resolucin No. 13, del 6 de

LISTA DE ANEXOS ................................................................................................................... 11

2. MARCO CONCEPTUAL ..................................................................................................... 14

4. DESARROLLO DEL PROYECTO ..................................................................................... 24

5. ANLISIS DE RESULTADOS ............................................................................................ 50

Tabla 1 Especificaciones Hardware del Gateway ....................................................................................... 20

Ilustracin 1 Inicio IoT entre el 2008 y el 2009 [1] .................................................................................... 14

ANEXO 1: ACRNIMOS ......................................................................................................................... 61

2.2 Internet de las cosas (IoT)

Ilustracin 1 Inicio IoT entre el 2008 y el 2009 [1]

2.3 Wireless Sensor Networks

Ilustracin 2 Wireless sensor network data path

Ilustracin 3 Tamao representativo SBC.

2.5 Framework OSGi

Ilustracin 4 Arquitectura OSGi

Ilustracin 5 Arquitectura software OpenHAB

Ilustracin 6 Canales de Comunicacin OpenHAB

Ilustracin 7 Diagrama general del proyecto

Ilustracin 8 Diagrama de flujo del Sistema

Hardware Computador de placa reducida RaspberryPi

Conexin a Internet Ethernet o Wi-Fi (Adaptador USB Edimax EW-7811Un)

Marca y referencia AeonLabs Z-Stick 2E

Protocolo inalmbrico Z-Wave 900 MHz ISM band (US)

Sistema operativo Raspbian O.S.

Administrador OpenHAB HABmin 0.1.3

Motor bases de datos MySQL

Java Virtual Machine Oracle JDK Versin "1.7.0_40"

Bibliotecas stdio.h, stdlib.h, string.h, mysql.h, signal.h, curl.h

3.2 Interfaz Grfica

Alojamiento web Servidor de HeliconiaTech Bitnami/AWS (http://www.heliconiatech.com)

Entre 769px y 1019px 2

Mayor o igual a 1020px 3

Tabla 6 Diagramacin del widget de dispositivo

3.3 Sensores y Actuadores

Marca y referencia Aeon Labs 4 in 1 Multisensor

Protocolo inalmbrico Z-Wave 900 MHz ISM band (US)

3.3.2 Sensor de consumo

Ilustracin 9 Esquema para el sensor de consumo

Marca y referencia AeonLabs Smart Energy Switch

Protocolo inalmbrico Z-Wave 900 MHz ISM band (US)

3.3.3 Actuador para controlar una lmpara

Protocolo inalmbrico Z-Wave 900 MHz ISM band (US)

3.4 Base de datos

Sistema de gestin MySQL

Sistema Operativo Ubuntu Server 14.04.1 LTS (Long Term Support)

Servidor Web Apache/2.4.10 (Unix)

Alojamiento web Servidor de HeliconiaTech Bitnami/AWS (http://www.heliconiatech.com)

RAM (MB) 256 512 - 512 1024

Arquitectura ARM ARM x86 ARM ARM

Una caracterstica importante, pero difcil de cuantificar, es el soporte de la comunidad de desarrolladores.

RASPBIAN Debian Wheezy 3.12 2014-07-24 Yes

ARCH LINUX Arch Linux 3.12 2014-10-01 No

MOEBIUS ARM HF Debian 3.12 2014-05-01 Yes

Ilustracin 11 rbol de carpetas de runtime de OpenHAB

Ilustracin 12 rbol de la carpeta configurations de OpenHAB