TFG - Daniel Sierra SolÃ S

Trabajo Fin de Grado
Grado en Ingeniería de las Tecnologías de Telecomunicación
Implementación de interfaz Z-wave para Raspberry

con aplicaciones para la monitorización de
condiciones ambientales
Autor: Daniel Sierra Solís
Tutor: José María Maestre Torreblanca
Dep. de Ingeniería de Sistemas y Automática

Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2014
Trabajo Fin de Grado
Grado en Ingeniería de las Tecnologías de Telecomunicación
Implementación de interfaz Z-wave para Raspberry

con aplicaciones para la monitorización de
condiciones ambientales
Autor:
Daniel Sierra Solís
Tutor:
José María Maestre Torreblanca
Departamento de Ingeniería de Sistemas y Automática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2014
A mi familia
Índice
Índice vii
Índice de Tablas xi
Índice de Figuras xiii
1 Introducción 17
2 Raspberry Pi 19
2.1 Hardware 20
2.1.1 Conector HDMI 20
2.1.2 Conector de red eléctrica 21
2.1.3 USB 21
2.1.4 Puerto LAN 21
2.1.5 Lector de tarjetas 21
2.1.6 Conector CSI-2 21
2.1.7 Conector DSI 22
2.1.8 Puertos JTAG 23
2.1.9 GPIO 23
2.1.10 Salida analógica de video 24
2.1.11 Salida de audio 24
2.1.12 LEDs 24
2.1.13 Integrado Broadcom BCM2835 24
2.2 Gestión de energía 27
2.3 Software 28
2.3.1 Raspbian 29
2.3.2 Instalación del sistema operativo 30
2.3.3 Proceso de arranque 31
2.4 Resumen de las características 33
3 Z-wave 35
3.1 Origen 35
3.2 Protocolo Z-wave 36
3.2.1 Capa MAC 36
3.2.2 Capa de transporte 37
3.2.3 Capa de enrutado 39
3.2.4 Capa de aplicación 40
3.3 Dispositivos 42
3.3.1 Esclavos 42
3.3.2 Controladores 42
3.3.3 Gestión de esclavos dentro de la red 43
3.3.4 Asociaciones 44
3.3.5 Grupos 45
3.3.6 Escenas 45
3.4 Desarrollo de aplicaciones 46
3.4.1 Kit de desarrollo de Sigma Desings 46
3.4.2 Z-way 48
3.4.3 OpenZWave 51
4 Aplicación desarrollada 60
4.1 Base de datos 61
4.2 Programa principal 66
4.2.1 Inicialización del programa 67
4.2.2 Cuerpo del programa 70
4.2.3 Ejecución del programa 75
4.3 Interfaz web 76
4.3.1 Inicio 77
4.3.2 Principal 78
4.3.3 Sección de nodos 83
4.3.4 Sección de recoger datos 87
4.3.5 Sección de visión de resultados 89
4.3.6 Sección de gestión de usuarios 96
4.3.7 Sección de configuración 98
5 Ejemplo de aplicación 101

5.1 Detalle de los elementos utilizados 104
5.1.1 Controlador USB Z-stick S2 Aeotec 104
5.1.2 Sensor Everspring ST814 105
5.2 Resultados obtenidos 107
6 Líneas futuras de desarrollo y conclusiones 109
7 Referencias 111
ÍNDICE DE TABLAS
Tabla 1.1. Funciones de los LEDs de una Raspbery Pi. 24
Tabla 1.2. Características entre los distintos tipos de modelo de Raspberry Pi. 33
Tabla 2.1. Compatibilidad de controladores USB con OpenZWave. 51
Tabla 2.2. Tipos de valores ValueID. 54
Tabla 2.3. Algunos valores del campo NotificationType de la clase Notification. 56
Tabla 3.1. Relación de valores del parámetro “m” con el contenido cargado. 80
Tabla 4.1. Características de Everspring ST814. 106

ÍNDICE DE FIGURAS
Figura 2.1. Distintivo identificativo de Raspberry Pi. 19
Figura 2.2. Identificación de elementos en una Raspbperry Pi modelo B. 20
Figura 2.3. Raspberry Pi conectada a una cámara mediante el puerto CSI-2. 22
Figura 2.4. Diagrama de componentes de ARM1176JZF-S [4]. 25
Figura 2.5. Diagrama de flujo de etapas de instrucción en la CPU de un ARM11 [4]. 26
Figura 2.6. Ejemplo de integrados conectados mediante packe-on-package. 27
Figura 2.7. Versiones de Debian en Raspberry Pi. 30
Figura 2.8 Instalación de Linux mediante NOOBS. 31
Figura 2.9. Secuencia de arranque de Raspberry Pi. 32
Figura 3.1. Torre de protocolos de Z-wave. 36
Figura 3.2. Formato de trama MAC utilizado en Z-Wave [11]. 37
Figura 3.3. Formato de trama de nivel de transporte en Z-wave [11]. 37
Figura 3.4. Ejemplo de envío de trama dirigida en Z-wave [11]. 38
Figura 3.5. Ejemplo de envío de trama multicast en Z-wave [11]. 38
Figura 3.6. Ejemplo de envío en difusión en Z-wave [11]. 39
Figura 3.7. Formato de mensaje con comandos Z-wave [11]. 40
Figura 3.8. Controlador estático Vera 3. 43
Figura 3.9. Controlador portátil modelo Z-URC. 43
Figura 3.10. Parte del kit básico de desarrollo de Z-wave [13]. 47

Figura 3.11. Interfaz de usuario de Zniffer, una de las herramientas del SDK de Z-wave. 48
Figura 3.12. Estructura de funcionamiento de un sistema con Z-Way. 49
Figura 3.13. Módulo Razberry conectado a las GPIO de una Raspberry Pi. 51
Figura 3.14. Secuencia de llegada de notificaciones en OpenZWave. 56
Figura 4.1. Estructura general de la aplicación desarrollada. 60
Figura 4.2. Diagrama E-R de la base de datos. 66
Figura 4.3. Representación de un nodo de la red en el programa. 68
Figura 4.4. Representación de la lista de nodos en el programa principal. 68
Figura 4.5. Llegada de una notificación de cambio de valor en un nodo. 70
Figura 4.6. Actualización de la tabla “acceso” en el bloque de estado de la red. 71
Figura 4.7. Cálculo del comienzo de la recogida. 73
Figura 4.8. Secuencia de funcionamiento del bloque de gestión de recogidas del programa principal.
74
Figura 4.9. Aspecto del programa en un terminal Linux. 75
Figura 4.10. Pantalla de ingreso al sistema. 77
Figura 4.11. Funcionamiento de la página de inicio. 78
Figura 4.12. Estructura de principal.php. 79
Figura 4.13. Funcionamiento de la página principal.php. 80
Figura 4.14. Funcionamiento general de la aplicación. 82
Figura 4.15. Funcionamiento de la sección de nodos. 83
Figura 4.16. Apartado “Listar nodos”. 84
Figura 4.17. Apartado “Modificar periodo de sueño”. 85
Figura 4.18. Apartado “Modificar periodo de sueño” tras un envío. 85

Figura 4.19. Apartado “Insertar nodo”. 86
Figura 4.20. Apartado “Eliminar nodo”. 87
Figura 4.21. Aspecto habitual de la sección “Recoger datos”. 88
Figura 4.22. Aspecto de “Recoger datos” cuando hay una recogida en curso. 88
Figura 4.23. Funcionamiento de iniciar_recogida.php. 89
Figura 4.24. Vista de la sección de lista de experimentos. 90
Figura 4.25. Funciones de los botones de gestión de cada experimento. 90
Figura 4.26. Muestra de resultados de una determinada recogida de datos. 91
Figura 4.27. Ausencia de resultados por URL mal formada. 91
Figura 4.28. Menú desplegable al pulsar el botón de gráficas. 92
Figura 4.29. Funcionamiento de generar_grafica.php. 92
Figura 4.30. Aspecto de la página de generación de gráficas (I). 93
Figura 4.31. Aspecto de la página de generación de gráficas (II). 93
Figura 4.32. Formulario de descarga de las muestras recogidas en formato texto. 94
Figura 4.33. Proceso de descarga del archivo con las muestras. 95
Figura 4.34. Usuario “prueba” siendo incapaz de borrar un experimento ajeno. 96
Figura 4.35. Eliminación de la misma fila desde el usuario administrador. 96
Figura 4.36. Aspecto de “Gestión de usuarios”. 97
Figura 4.37. Lista de usuarios en el sistema. 97
Figura 4.38. Inserción de nuevo usuario. 98
Figura 4.39. Borrado de usuario existente en el sistema. 98
Figura 4.40. Aspecto de la opción de reinicio. 99
Figura 4.41. Proceso de espera tras el reinicio. 99

Figura 4.42. Apariencia de la sección que permite apagar el sistema. 100
Figura 4.43. Instrucciones para volver a encender la Raspberry Pi tras solicitar el apagado. 100
Figura 5.1. Disposición de elementos durante la prueba. 102
Figura 5.2. Esquema de red. 102
Figura 5.3. Jardín vertical. 103
Figura 5.4. Disposición del ventilador en la pared opuesta. 103
Figura 5.5. Aeotec Z-stick S2. 104
Figura 5.6. Sensor Everspring ST814. 105
Figura 5.7. Finalización de la prueba en la aplicación web. 107
Figura 5.8. Gráfica de temperatura frente a tiempo (s) de la prueba. 108
Figura 5.9. Gráfica de humedad frente a tiempo (s) de la prueba. 108

1 INTRODUCCIÓN
E n el año 2011, investigadores de la Universidad de Sevilla instalaron en la Escuela Técnica

Superior de Ingeniería el primer jardín vertical activo de Europa, localizándose en el edificio
anexo de laboratorios de dicha facultad y ocupando una superficie total de 16 m2 [1].
Este tipo de elementos, como los techos verdes, actúan como biofiltros que depuran el aire proveniente
tanto del exterior como el interior del edificio, y consiguen un importante ahorro energético mediante
la disminución de la temperatura de la sala por enfriamiento evaporativo. La humedad y la cantidad
de CO2 también se ven modificadas de manera positiva, siendo especialmente interesante el aumento
de la primera cuando se utilizan equipos de aire acondicionado, evitando con ello que se resequen las
mucosas.
A estas ventajas hay que añadir su capacidad para actuar contra el denominado Síndrome del Edificio
Enfermo. Esta es una afección reconocida por la Organización Mundial de la Salud que se considera
existente cuando al menos el 20% de las personas que habitan o trabajan en un edificio sufren
afecciones médicas como vértigos, fatiga o infecciones respiratorias [2]. Los responsables de estos
hechos pueden ser diversos, pero cuando se trata de responsables químicos y físicos, el jardín vertical
17
18 Introducción
puede paliar la magnitud de los efectos.
En la sala donde se encuentra el jardín en cuestión, existen un conjunto de ventiladores distribuidos de

manera que se hace pasar por el interior del jardín el aire que proviene de las zonas más altas y también
el del exterior del edificio. Al salir del mismo, se consigue un aumento de la humedad y una reducción
de la temperatura de hasta diez grados centígrados si el aire proviene del exterior y es verano.
Todo ello hace que esta sala sea un interesante campo de estudio para observar como varían las
diferentes magnitudes ambientales en torno a él mediante la creación y análisis de distintos modelos
matemáticos. El presente trabajo tiene precisamente como objetivo facilitar la labor de los
investigadores en esta tarea, de forma que puedan obtener valores de humedad y temperatura de la sala
de una manera sencilla y configurable gracias al desarrollo de la herramienta apropiada.
Para esta labor se han utilizado dispositivos domóticos que permiten desplegar una red de sensores de
forma más barata a como se realizaría con herramientas específicas. La contrapartida es que al ser
elementos destinados al consumo en el hogar, su presión no siempre es la idónea, si bien en el
desarrollo de estudios preliminares continuarían siendo válidos.
La tecnología escogida ha sido Z-wave, uno de los ecosistemas domóticos más extendidos en la
actualidad. Cuenta con la participación numerosos fabricantes de dispositivos, y como consecuencia,
pone a nuestra disposición un gran número de sensores diferentes. El análisis de Z-wave se desarrollará
de manera profunda a lo largo del capítulo 3, junto con las diferentes posibilidades que se ofrecen para
el desarrollo de aplicaciones con él.
Para alojar la aplicación se ha tomado también un ordenador Raspberry Pi, idóneo por su tamaño para
este proyecto, y que como veremos, será el núcleo central de todo el desarrollo. El capítulo 2 versa
sobre este dispositivo, que analiza las capacidades que presenta.
Por último, el capítulo 4 está dedicado a la presentación de la aplicación desarrollada mediante las dos
herramientas anteriores, explicando la estructura y diseño que se han seguido para logarlo.
Implementación de interfaz Z-wave para Raspberry 19
2 RASPBERRY PI
aspberry Pi es un ordenador de pequeño tamaño desarrollado por la organización sin ánimo de

R lucro Raspberry Pi Foundation en 2011. El propósito de esta fundación, creada en el Reino
Unido y apoyada por el fabricante Broadcom y la Universidad de Cambridge, es contribuir al estudio
de las ciencias informáticas en el entorno escolar [3]. Este es el motivo principal por el cual posee un
precio relativamente asequible, circunstancia que a su vez ha propiciado que su difusión vaya más allá
del ámbito al que principalmente estaba destinado para pasar a ser una herramienta al alcance de todos
los desarrolladores.
Figura 2.1. Distintivo identificativo de Raspberry Pi.

20 Raspberry Pi
Es capaz de conectarse a un monitor o televisión y de usar un teclado estándar y ratón, actuando así
como un ordenador convencional. Sus aplicaciones van desde fines didácticos, como los mencionados
anteriormente mediante el uso de Python o Scratch (una herramienta educativa de iniciación a la
programación), hasta su uso como dispositivo empotrado en proyectos telemáticos o electrónicos.
Procedemos a analizar de manera más profunda las características del dispositivo, basándonos para
ello en el capítulo primero del libro “Practical Blackberry Pi” escrito por Brendan Horan.
2.1 Hardware
La Raspberry Pi se presenta en dos modelos, denominados A y B. El primero carece de puerto

Ethernet, posee menos memoria RAM y solo tiene un conector USB. El modelo B por el contrario
presenta dos, y sí posee conector RJ45.
Dado que el resto de características son similares y el presente trabajo se ha desarrollado utilizando el
modelo B, se procede a detallar a continuación los componentes que se pueden hallar en una versión
de este tipo.
El siguiente esquema muestra la localización física de los elementos, que se describirán a continuación.
Figura 2.2. Identificación de elementos en una Raspbperry Pi modelo B.
2.1.1 Conector HDMI
Permite la conexión de un dispositivo compatible con la interfaz HDMI 1.3 para la extracción de
señales de audio y vídeo digitales.
2.1.2 Conector de red eléctrica
Consiste en un simple conector micro USB tipo B que proporciona 5 V de tensión.
2.1.3 USB
Las funciones de USB están proporcionadas por dos conectores controlados por un integrado del
modelo SMSC LAN9512. Funcionan según el estándar 2.0 y proveen 100 miliamperios, frente a los
500 mA de un puerto normal USB. Esta cantidad es insuficiente para alimentar algunos dispositivos
como discos duros externos, pero es suficientes para un lápiz de memoria común.
2.1.4 Puerto LAN

El puerto RJ45 Ethernet que posee la Raspberrry Pi también está gestionado por el chip SMSC
LAN9512. Esto facilita que desde un mismo integrado se realicen varias tareas, con el consecuente
ahorro de espacio en el PCB. Sin embargo, el inconveniente es que el ancho de banda hacia la CPU es
compartido con los dos puertos USB, lo cual puede provocar problemas de rendimiento cuando se
realiza acceso simultáneo a la red y a un dispositivo externo USB.
Entre las funciones relativas a Ethernet que proporciona el SMSC, se encuentran Wakeon-LAN y la
capacidad de calcular el checksum de los paquetes TCP/UDP. Esta característica destaca por permitir
a la CPU liberarse de realizar la tarea por software, teniendo en cuenta que la CPU posee una cantidad
procesamiento no demasiado elevada.
2.1.5 Lector de tarjetas
Se encuentra en la cara posterior del PCB, es capaz de leer tarjetas SD/MMC/SDIO. La utilización de
una tarjeta flash suple la función de almacenamiento de memoria, al no existir ningún disco duro ni de
estado sólido incluido. Este provoca un abaratamiento el coste del conjunto, unido además a que
tampoco se incluye la tarjeta SD como parte de la Raspberry Pi.
2.1.6 Conector CSI-2
Consiste en un conector tipo bus para cables de 15 pines utilizado para añadir un dispositivo
compatible con la interfaz CSI-2 (o Camera Serial Interface versión 2, por sus siglas en inglés). Este
estándar permite a una cámara conectarse a otro dispositivo, diferenciando en su arquitectura entre los
22 Raspberry Pi
roles de maestro y esclavo.
La ventaja de usar esta tecnología es que se permite que el rol de maestro sea ejercido desde por una
aplicación hasta un por controlador de bajo nivel, como en el caso de la Raspberry Pi. En esta, el rol
de maestro se asigna a la GPU de Broadcom, de forma que se libera a la CPU de la tarea de procesar
el vídeo recibido desde la cámara.
No obstante, CSI únicamente define la interfaz a nivel de hardware, lo cual significa que el modo en
que se comunica la cámara y el dispositivo maestro queda a la elección del programador. Esto provoca
que aunque sea sencillo encontrar una cámara que sea conectable físicamente a la Raspberry y
compatible con CSI-2, es necesario que esté específicamente desarrollada para este ordenador, o de lo
contrario no funcionará.
Figura 2.3. Raspberry Pi conectada a una cámara mediante el puerto CSI-2.
2.1.7 Conector DSI
Se trata de un conector que físicamente es de idénticas características al anteriormente mencionado.

Actúa como puerto DSI (Display Serial Interface), que permite la conexión de pequeñas pantallas
LCD directamente a la GPU del dispositivo. A diferencia de la interfaz CSI, DSI sí define el protocolo
de comunicación entre ambos dispositivos.
Sin embargo, a pesar de lo que cabría pensar, no existe ningún dispositivo que sea compatible en la
actualidad con este conector, dado que Broadcom nunca ha publicado documentación técnica sobre su
GPU.
2.1.8 Puertos JTAG
Consiste en dos filas de pines con forma de agujeros que atraviesan el PCB. Ambas JTAG o Joint Test
Action Group son utilizadas para las labores de programación inicial y testeo de hardware durante el
periodo de fabricación. La fila P2 corresponde a la JTAG del integrado de Broadcom, mientras que la
P3 al SMSC LAN9512.
De nuevo, su utilidad de cara al desarrollador es nula, al desconocerse su interfaz de uso.
2.1.9 GPIO
Las salidas/entradas de propósito general de la Raspberry Pi están estructuradas en un bloque de 26

pines. Cuando se nombra un pin del grupo se utiliza el formato P1-XX por convención, donde XX es
el número de pin dentro del bloque. Esto es debido a la posible confusión que puede existir al
referenciar a las GPIO que el integrado de Broadcom contiene de por sí.
Cada GPIO puede proporcionar una cantidad máxima de corriente, de forma que en ningún caso se
deben superar los 16 mA para todo el conjunto. Si se excede este nivel, se puede dañar el pin y, en el
peor de los casos, destruir la fuente de 3,3 V que posee la Raspberry Pi.
Algunas consideraciones sobre las funciones de cada pin son las siguientes:
 El pin P01-02 se puede utilizar como fuente de alimentación de 5 V alternativa de la Raspberry

Pi.
 Los pines P01-06, P01-09, P01-14, P01-17 y P01-20 no deben conectarse a ningún elemento.
El resto de pines se pueden utilizar como GPIO, con la excepción de algunos casos como los
que prosiguen, en los que se consideran funciones alternativas.
 Los pines P1-08 y P1-10 ejecutan las funciones de receptor y transmisor UART. Por defecto
funcionan a una velocidad de 115200 bits por segundo, de modo que no es necesaria su
configuración y puesta en marcha desde el sistema operativo, sino que al encender la
Raspberry Pi su ejecución es automática.
 P1-03 y P1-05 se pueden utilizar como bus de I2C. Contienen una resistencia de pull-up de 1,8
KΩ, lo que implica que se puede establecer el bus a nivel alto o bajo sin necesidad de añadir
de manera externa la impedancia.
24 Raspberry Pi
2.1.10 Salida analógica de video
Está configurada como un conector RCA compuesto. El usuario debe elegir entre utilizar este método
o bien la salida HDMI, siendo imposible utilizar ambos a la vez.
La activación de salida analógica se debe realizar desde el sistema operativo, indicando en un fichero
de texto explícitamente el sistema utilizado: NTSC, NTSC-J, PAL estándar o PAL-M.
2.1.11 Salida de audio
Consiste en un conector jack estéreo de 3,5 mm. Del mismo modo que en el caso anterior, no es posible
utilizar este método de extracción de audio a la par que la salida HDMI.
2.1.12 LEDs
Situados en uno de los bordes de la placa se encuentran cinco diodos LED. Su función consiste en
aportar información sobre el estado de la Raspberry Pi. A continuación se muestra el objetivo
específico de cada uno:
Tabla 2.1. Funciones de los LEDs de una Raspbery Pi.
Identificador Identificador Función

D5 Verde Acceso a la tarjeta SD / Sistema ejecutándose
correctamente
D6 Rojo Alimentación de red correcta
D7 Verde Full dúplex / Half dúplex si apagado
D8 Verde Actividad LAN
2.1.13 Integrado Broadcom BCM2835
Este es de tipo system-on-a-chip o SoC, engloba el microprocesador ARM1176JZF-S, la GPU modelo

VideoCore IV de Broadcom y 512 megabytes de memoria RAM en un único integrado.
2.1.13.1 Mircroprocesador ARM1176JZF-S
Su núcleo está constituido siguiendo la arquitectura ARM11 RISC de 32 bits y funciona a 700MHz.
El diagrama de bloques con sus componentes responde a la siguiente estructura:
Figura 2.4. Diagrama de componentes de ARM1176JZF-S [4].
El set de instrucciones está basado en ARMv6, que admite los siguientes conjuntos [5]:
 Juego de instrucciones principal de 32 bits de ARM. Normalmente la mayoría de aplicaciones

utilizan este modo.
 Juego de instrucciones de 16 bits Thumb. Este es un tipo de instrucciones diseñado por ARM
que consiste en un subconjunto de instrucciones de 16 mapeadas en su mayoría a las del juego
principal. Es utilizado normalmente en sistemas empotrados que no tienen capacidad
suficiente para trabajar en 32 bits.
 Conjunto de instrucciones de 8 bits que permite ejecutar byte code Java.
Por otro lado, existen dos subtipos especiales de instrucciones que se añaden a las anteriores:
 Instrucciones DSP (Digital Signal Processing): proporciona mejoras para el procesado de

señales digitales y multimedia. Instrucciones de este tipo se encuentran en procesadores
digitales de señal.
 Instrucciones SIMD (Single Instruction Mutable Data): también proporciona mejoras como
las anteriores. Capaz de doblar la velocidad de procesado de flujo MPEG-4 y audio digital.
26 Raspberry Pi
La arquitectura ARM11 establece una estructura en pipeline de ocho etapas, frente a la versión ARM9
anterior que diferenciaba cinco. Es capaz de procesar más información en un mismo ciclo de reloj
como consecuencia.
Figura 2.5. Diagrama de flujo de etapas de instrucción en la CPU de un ARM11 [4].
Es importante destacar también que se incluye un cooprocesador de vector de punto flotante

denominado VFP11. Este sigue el estándar IEEE 754 de aritmética de punto flotante y proporciona al
ARM11 una manera barata y de alto rendimiento de llevar a cabo este tipo de operaciones en hardware.
En cuanto a la memoria, el coprocesador CP15 que está integrado en el núcleo es el encargado de la

gestión de la memoria principal y las caché, siendo los buses entre ambas de 64 bits.
La memoria principal se abordará más adelante, dado que realmente no forma parte del ARM11. Cada
fabricante puede decidir qué tipo de memoria desea acoplarle, y en nuestro caso como se ha
mencionado ya, es de 512 kB.
Por otro lado, la memoria caché está distribuida en dos bloques del siguiente modo:
 Caché L1. Constituida por dos memorias caché independientes para datos y para instrucciones,
cada una de 16 kB.
 Caché L2. Al contrario a lo que cabría pensar, este bloque no actúa como segundo nivel de
memoria, sino que Broadcom ha decidido asignarla enteramente a la GPU. La CPU escribe
las peticiones que desea realizar a la GPU en ella.
2.1.13.2 Memoria RAM
Consiste en un chip de memoria DDR2 de 512 kB. Si bien se ha mencionado que el SoC de Broadcom
es un único integrado, realmente la memoria RAM por un lado y la GPU con el microprocesador
ARM11 por otro, son dos integrados distintos que están dispuestos de forma package-on-package.
Figura 2.6. Ejemplo de integrados conectados mediante packe-on-package.
De esta manera se encuentran dos piezas la una sobre la otra, estableciéndose la conexión entre ellas
mediante conductores que se encuentran en las caras acopladas.
2.1.13.3 GPU VideoCore IV de Broadcom
Su frecuencia de funcionamiento es de 250 MHz y sirve para acelerar contenidos multimedia con una
resolución de hasta 1080p, así como capturarlos. Además de funcionar autónomamente, es capaz de
ejecutar cantidades limitadas de código ARM.
Esta parte del SoC está protegida por acuerdos de confidencialidad en su diseño y API, lo cual provoca
que sea complejo para la comunidad de desarrolladores de Raspberry Pi llevar a cabo programas que
utilicen la GPU de la mejor manera posible. La explicación reside en que el principal mercado objetivo
de esta GPU es el de telefonía móvil, un sector altamente competitivo.
La cantidad de memoria que tiene asignada (denominada video memoria o VRAM) puede ser
establecida mediante la escritura en la tarjeta SD de un fichero. La Raspberry Foundation provee tres
variantes de este fichero: arm128_start.elf, arm192_start.elf y arm224_start.elf, donde
el número indica la cantidad de memoria que se asegura para el uso como memoria principal, siendo
el resto asignado como VRAM. Tras renombrar uno de esos ficheros a start.elf y encender la
Raspberry, la GPU lo leerá y pasará después el control a la CPU.
2.2 Gestión de energía

La Raspberry Pi presenta diferentes modos de alimentarse según a las características de su
microprocesador. Se distinguen los siguientes [4]:
 Modo en ejecución. Todas las funcionalidades del núcleo del ARM11 están ejecutándose. Este
es el estado por defecto del ordenador y habitualmente es suficiente para cualquier usuario.
 Modo en reposo o WFI (Wait for interrupt o a la espera de interrupción en español). En él

todas las características están apagadas, exceptuando los circuitos de alimentación. Las
28 Raspberry Pi
instrucciones de la CPU no se estarían ejecutando por lo tanto, si bien el núcleo puede volver
a encenderse rápidamente mediante una interrupción.
 Modo apagado. Lógicamente en este modo no existe ningún tipo de corriente circulando.
 Modo latente. El núcleo del microprocesador está apagado, pero todos los dispositivos caché
se mantienen alimentados y por lo tanto sin borrar. Este modo está solo parcialmente soportado
por el ARM1176JZF-S.
2.3 Software
El sistema operativo que se ejecuta es GNU/Linux. Existen actualmente multitud de distribuciones,
siendo algunas de ellas [6]:
 Raspbian. Basada en Debian, es la distribución recomendada por la Raspberry Pi Foundation.

Se analizará más adelante.
 Arch. El lema de los contribuidores de esta versión de Linux es que el usuario debe tener pleno
control sobre el software que se instale, de modo que únicamente incluye unas pocas
herramientas. No porta ningún paquete de escritorio.
 RISC OS. Proviene de la versión original creada por Acorn Computers en 1987, debíendose
su nombre al tipo de arquitectura RISC sobre la que fue diseñado. Posee muchas
características diferentes de una arquitectura Linux habitual, por ejemplo no tiene soporte para
multiusuario, se basa fuertemente en el uso del ratón y menús contextuales o utiliza un sistema
de ficheros propio denominado ADFS (Advance Disk Filing System), de prestaciones muy
limitadas [4].
 OpenELEC. Es un sistema operativo empotrado, diseñado específicamente para ejecutar

XBMC, un centro de entretenimiento multimedia de código abierto. El objetivo de su
desarrollo es permitir al usuario utilizar de forma sencilla la Raspberry Pi desde su televisión
desde el primer momento. Evita de este modo tener que hacerle pasar por las tareas previas de
configurar, descargar e instalar los paquetes necesarios para ello.
 RaspBMC. Su propósito es idéntico a OpenELEC, basándose en Debian con XBMC para

lograrlo.
 Pidora. También denominado Fedora Ramix, contiene paquetes provenientes del proyecto
Fedora y otros creados específicamente para Raspberry Pi.
 Gentoo. No posee interfaz gráfica, se apoya en la utilización de terminal. Por otro lado no está
basada en versiones, sino que es una metadistribución, es decir, que es una versión actualizable
durante toda la vida.
2.3.1 Raspbian
Se trata de la versión de Linux más estable y ampliamente utilizada en Raspberry Pi. Fue liberada por
primera vez en Junio 2012 gracias a Mike Thompson y Peter Green, si bien su comunidad de
desarrolladores ha crecido notablemente desde entonces. Es una distribución que a pesar de estar
basada en Debian, no constituye un proyecto oficial de este ente, ni tampoco de la Raspberry Pi
Foundation.
Sin embargo, el proyecto Debian posee varias adaptaciones oficiales para ARM. Para la arquitectura
ARMv6 posee una adaptación denominada “armel”, mientas que para la ARMv7 ha desarrollado
“armhf”. La diferencia entre ambas reside en que mientras “armel” efectúa las operaciones de punto
flotante por software, “armhf” lo hace utilizando el VFP (coprocesador de punto flotante). Existen
además otras desventajas menores, siendo “armel” incapaz de hacer uso de las instrucciones más
avanzadas de las que dispone ARMv6.
Esto afecta de lleno a Raspberry Pi, que como se ha visto, posee un VFP y juego de instrucciones de
tipo ARMv6. La consecuencia es que aun siendo capaz de realizar operaciones aritméticas de punto
flotante por hardware, las realiza por software si ejecuta una versión oficial Debian. Este es el caso de
la primera adaptación que realizó la fundación, basándose en Debian Squeeze “armle” logró una
distribución de un rendimiento menor a lo que podría obtenerse.
El origen del desarrollo de Raspbian se basa precisamente en este hecho, realizaron una adaptación
desde la versión Debian Wheezy “armhf” para que fuera compatible con el set de instrucciones
ARMv6 [7].
30 Raspberry Pi
Figura 2.7. Versiones de Debian en Raspberry Pi.
Raspbian se presenta con el gestor de escritorio LXDE, el navegador Midori y varias herramientas de
programación. Está compuesto por más de 35000 paquetes de software compilados específicamente
para ARMv6 con VPF, una cantidad superior a los que posee “armel” o “armhf”.
2.3.2 Instalación del sistema operativo

Para utilizar una de las versiones de Linux existentes, existen tres alternativas: adquirir una tarjeta SD
preconfigurada con la distribución deseada, configurar una manualmente o utilizar la herramienta
NOOBS (New Out Of the Box Software) [8].
Para configurar una tarjeta SD desde cero es necesario formatearla y grabar en ella la imagen del
sistema operativo por el que sea haya optado.
La utilidad NOOBS, por otro lado, está especialmente recomendada para usuarios noveles por parte
de la Raspberry Pi Foundation. En lugar de grabar en la SD directamente la distribución escogida, se
hace lo propio con esta herramienta que proporciona la fundación. La ventaja reside en que provee una
instalación guiada y sencilla de la distribución que se seleccione durante el proceso, de entre las
siguientes:
- Raspbian
- OpenELEC
- Arch
- RaspBMC
- Pidora
NOOBS se presenta en dos variantes: una en línea, que requiere de conexión a internet para realizar la
descarga de la versión seleccionada y otra completa, que conlleva guardar las cinco imágenes de las
distribuciones en la SD, con el gasto de memoria que ello implica.
Figura 2.8 Instalación de Linux mediante NOOBS.
2.3.3 Proceso de arranque

Una vez que la Raspberry Pi se conecta a la corriente eléctrica, y con independencia de la distribución
instalada, el proceso de arranque que sufre es el siguiente [4]:
1. El núcleo del microprocesador ARM se mantiene apagado, pero la GPU se despierta.
2. La GPU comienza a ejecutar el gestor de arranque primario, que se halla programado en el

SoC y es inmodificable.
3. El gestor de arranque primario comienza a ejecutar entonces el gestor de arranque secundario

denominado bootcode.bin. Este se encuentra en la L2, que como se ha mencionado se
32 Raspberry Pi
encuentra mapeada a la GPU.
4. bootcode.bin activa la memoria RAM. A continuación copia en ella el archivo

loader.bin, que debe existir en la tarjeta SD y se considera el tercer gestor de arranque. Le
pasa el control.
5. loader.bin lee el archivo start.elf de la SD.
6. start.elf lee y lleva a cabo las acciones requeridas que se encuentren en los archivos de
configuración config.txt y cmdline.txt, en caso de que existan.
 config.txt: alberga parámetros de configuración, del mismo modo que en un PC lo

hace la BIOS.
 cmdline.txt: utilizado para pasar argumentos al kernel de Linux, que se ejecutará
en el siguiente paso.
7. Lee kernel.img, que representa el kernel de Linux y le pasa el control. Comienza a ejecutarse
el núcleo del ARM11.
Figura 2.9. Secuencia de arranque de Raspberry Pi.

2.4 Resumen de las características

Tabla 2.2. Características entre los distintos tipos de modelo de Raspberry Pi.
Característica Modelo A Modelo B
SoC Broadcom BCM2835 (GPU + CPU + Memoria DDR2)
CPU ARM1176JZF-S a 700 MHz
GPU Broadcom IV VideoCore a 250 MHz
Memoria RAM 256 kB 512 kB
Puertos USB 1 2
Salidas de vídeo Salida compuesta RCA
HDMI 1.3
Pantalla LCD vía DSI
Salidas de audio Conector jack 3,5 mm
HDMI 1.3
Conexión LAN Ninguno 10/100 Mbit/s Ethernet
Almacenamiento Soporte para tarjetas SD
Periféricos de GPIO
bajo nivel SPI
I2C
UART
Reloj Ninguno
Fuente de 5 V vía micro USB

alimentación
5 V vía pin GPIO
34 Raspberry Pi
Sistemas Múltiples: Debian (Raspbian), Fedora (Pidora), Arch, Slackware Linux,

operativos
RISC OS, Gentoo, …
3 Z-WAVE
-Wave es una tecnología de comunicación inalámbrica diseñada para la domótica en el hogar,

Z centrada en el control remoto aplicado a entornos residenciales y pequeños espacios comerciales.
Aunque inicialmente fue propiedad privada de la empresa Zensys, Z-Wave, ahora se constituye como
estándar parcialmente abierto, siendo ratificado por la ITU (Unión Internacional de
Telecomunicaciones) en 2012.
Para el desarrollo de esta sección se utilizarán los documentos oficiales de Zensys: “Z-wave Technical
Basics” y “Z-wave Protocol Overview”, además del proyecto de final de carrera “Análisis e
implementación de un sistema domótico Z-wave”, escrito por Rocío Ledesma Álvavez.
3.1 Origen
La empresa Zensys fue quien desarrolló y puso a la venta en 2003 la primera generación de hardware.
La pieza clave para el desarrollo del sistema Z-Wave fue la creación en 2005 de la Z-Wave Alliance.
36 Z-wave
Una alianza de fabricantes industriales de este sistema cuyo objetivo principal era llegar a acuerdos
para garantizar la interoperabilidad de los diferentes dispositivos Z-Wave y que en 2009 contaba con
más de 200 afiliados.
Zensys define el nivel radio el tipo de codificación durante la transmisión y cómo organizar la red
mediante librerías de firmware precompiladas que los fabricantes no pueden modificar; pero por otro
lado, define algunas funciones específicas a nivel de aplicación, siendo los fabricantes quienes deben
optimizarlas. Tests de certificación que verifican que la capa de aplicación cumple con el estándar y
garantiza al interoperabilidad son realizados por los fabricantes en sus dispositivos.
En año 2008 Zen-Sys fue adquirida por la asiática Sigma Design. La concesión de la segunda licencia
de fabricación a la empresa Mistsumi en 2011 permite a los fabricantes contar con un proveedor
alternativo de integrados Z-wave, que aunque inicialmente está fabricando para el mercado japonés,
tiene licencia para fabricar para el mercado global.
3.2 Protocolo Z-wave

El protocolo que implementa Z-wave está diseñado para proporcionar una comunicación inalámbrica
fiable de mensajes de control de pequeño tamaño [11].
Se distinguen cuatro capas dentro del protocolo:
Figura 3.1. Torre de protocolos de Z-wave.
3.2.1 Capa MAC

Esta capa tiene por objetivo controlar el acceso al medio radio. La trama consta de: preámbulo, inicio
de trama (SOF por sus siglas en inglés), cuerpo de trama y delimitador de fin de trama (EOF). Se
utiliza codificación Manchester y mecanismo little endian para transmitir la información.
Figura 3.2. Formato de trama MAC utilizado en Z-Wave [11].
La capa MAC tiene un mecanismo de elusión de colisiones que evita que el nodo comience a transmitir
mientras otros lo están haciendo. Esto se consigue escuchando el canal durante unos instantes antes de
transmitir la trama que tiene preparada, y de estar ocupado, no enviar nada.
3.2.2 Capa de transporte

Esta capa cumple la función de controlar la transferencia de información entre los dos nodos que
establecen una comunicación, incluyendo las retransmisiones, sumas de integridad y asentimientos.
Existen cuatro tipos distintos de tramas que pueden enviarse en esta capa, pero todos siguen el siguiente
prototipo de mensaje:
Figura 3.3. Formato de trama de nivel de transporte en Z-wave [11].
Los distintos tipos de comunicación dados son:
- Trama de asentimiento. No contiene ningún dato efectivo y sirve como acuse de recibo.
38 Z-wave
- Trama dirigida. Es aquella que se envía directamente desde un nodo hacia otro. El receptor
asiente el mensaje, de manera que el nodo transmisor puede saber que ha llegado
correctamente. En caso de que no llegue asentimiento, la capa reenvía el mensaje de nuevo.
Figura 3.4. Ejemplo de envío de trama dirigida en Z-wave [11].
- Trama multicast. Son aquellas que se dirigen a un conjunto de nodos. No soportan

asentimiento del mensaje, lo que provoca que sean menos fiables.
Figura 3.5. Ejemplo de envío de trama multicast en Z-wave [11].
- Tramas de difusión. Son dirigidas a todos los nodos de la red. Tampoco se permite su
asentimiento.
Figura 3.6. Ejemplo de envío en difusión en Z-wave [11].
En la trama de este nivel viajan dos parámetros HomeID y NodeID, que identifican de manera unívoca
a cada dispositivo o nodo del sistema Z-Wave: dos nodos que pertenezcan a una misma red no pueden
tener el mismo identificador individual, ni ningún nodo puede tener dos HomeID.
- HomeID: es un identificador de red Z-wave no modificable por el usuario. Posee una longitud
de cuatro octetos.
- NodeID: constituye el identificador de nodo dentro de la red. Es un campo de un octeto, lo

que significa que una red como máximo puede estar compuesta de 256 nodos.
3.2.3 Capa de enrutado

Su función es encaminar de manera correcta las tramas que se intercambian los nodos. Tanto los
controladores como los esclavos pueden participar en el proceso, siempre que tengan la recepción
activada y posean posición fija.
La ruta por la que discurre un mensaje entre dos nodos puede ser directa o través de otros nodos. Esto
permite que mensajes de nodos que no están en el radio de cobertura de otros nodos puedan ser
recibidos. El número máximo de saltos para este tipo de envío es cuatro, dado que un número
demasiado alto provocaría altos retrasos en el proceso de entrega.
Un nodo lleva la cuenta de aquellos nodos que tiene accesibles a su alrededor y le comunica esta
información a su controlador en el momento de la inclusión o cuando se lo solicita. Con ello se
consigue que el controlador mantenga una tabla de encaminamiento, que el usuario puede comprobar
con el fin de mejorar la distribución topológica de su red.
40 Z-wave
A pesar de que el enrutado salto a salto sea posible, el controlador siempre trata de enviar un mensaje
directamente al nodo.
3.2.4 Capa de aplicación

La capa de aplicación es la responsable de decodificar y ejecutar comandos en la red Z-wave. Estos
comandos se transfieren mediante un mensaje de aplicación con el siguiente formato:
Figura 3.7. Formato de mensaje con comandos Z-wave [11].
3.2.4.1 Clases de comando
Los comandos (también denominados comandos de aplicación) están englobados en un nivel

jerárquico superior formando las clases de comando. Aquellas que poseen un valor dentro del rango
que va desde 0x0 a 0x1F están reservadas para el funcionamiento del protocolo Z-wave, pero el resto
son utilizables por los desarrolladores.
Esto permite agrupar comandos que tienen funciones relacionadas en un mismo grupo e identificar de
forma clara qué capacidades tiene un dispositivo o no. Por ejemplo, cuando un fabricante anuncia que
su dispositivo implementa la clase de comando COMMAND_CLASS_SENSOR_MULTILEVEL,
está indicando que permite el envío y recepción de un conjunto de comandos individuales que
informan sobre medidas de magnitudes como humedad, luz o temperatura.
La clase de comando COMMAND_CLASS_PROPIETARY_FUNCTION permite definir

funcionalidades específicas avanzadas que aún no están definidas de forma estándar. Una
funcionalidad propietaria no es habitual y está condiciona a la aprobación de la Alianza Z-Wave.
Existe una clase de comando especial que existe en todos los dispositivos Z-wave, esta es la
denominada clase de comando básica. Su objetivo es asegurar que el dispositivo posee una interfaz
básica sin necesidad de conocer qué otras clases de comando implementa. Consta de dos peticiones y
una respuesta:
 SET: orden de establecer un determinado valor entre el rango de valores que va desde 0 hasta
255.
 GET: petición al dispositivo del valor almacenado.
 REPORT: respuesta desde el dispositivo al comando GET.
La utilidad de esta clase varía de un dispositivo a otro, en un actuador binario por ejemplo, si se le
envía un valor 255 se encenderá, mientras que si se le envía 0 se apagará. Un termostato aclimatará la
habitación a la temperatura predefinida si recibe 0, mientras que si recibe un valor superior se pondrá
en modo de ahorro de energía.
3.2.4.2 Clases de dispositivos
Las clases de dispositivos hacen referencia a un modelo concreto y definen los comandos que un
dispositivo tiene que soportar obligatoriamente, permitiendo la interoperabilidad entre equipos de
distintos fabricantes. Se organizan en una jerarquía de tres niveles:
 Básica: sólo distingue si el dispositivo es controlador, esclavo o esclavo de encaminamiento.
 Genérica: define la función básica que el dispositivo soporta como controlador o esclavo.
 Específica: define una funcionalidad específica. Una clase genérica está formada por varias
específicas.
Las clases de comando dentro de una clase de dispositivo pueden ser: obligatorias, permiten la
compatibilidad entre fabricantes; recomendadas, promueven la interoperabilidad; u opcionales,
permiten diferenciarse de otros fabricantes, el estándar define como se han de soportar las funciones.
Para que el controlador pueda manejar un dispositivo, la trama de información del nodo en el momento
de la inclusión transporta la clase de dispositivo y las clases de comandos.
De este modo, un dispositivo que cumpla con el estándar Z-Wave debe:

42 Z-wave
- Pertenecer a una clase de dispositivos básica y una genérica, soportar las clases de comando
obligatorias de cada una de ellas e informar de ello a través de la trama de información de
nodo.
- Tener definida una clase de dispositivo específica, también soportar las clases de comando
obligatorias asociadas y debe ser anunciada a través de la trama de información de nodo bajo
petición, al igual que las clases de comando opcionales implementadas.
3.3 Dispositivos
Se distinguen dos tipos de roles en una red Z-wave: los esclavos y los controladores. En ambos casos
los dos pueden estar tanto alimentados por baterías como por corriente eléctrica.
3.3.1 Esclavos
Los esclavos son aquellos cuya tarea es responder a mensajes que han recibido previamente desde la
red. Todos conocen los vecinos que tienen a su alrededor, pero dependiendo de si poseen capacidad
de reenvío de mensajes existe la siguiente distinción:
 Esclavo normal: son aquellos que no poseen capacidad de enrutado y que son instalados en
una posición fija. Un actuador de persianas es un ejemplo de este tipo.
 Esclavo con capacidad de reenvío: tiene un conocimiento parcial de la tabla de

encaminamiento. Estos suelen ser dispositivos alimentados por baterías como termostatos o
sensores de presencia.
En caso de que el nodo no esté alimentado por la red eléctrica, entonces no siempre estará escuchando
el canal, de forma que tendrá periodos de sueño ajustables con el fin de ahorrar baterías. Esto es lo que
se denomina periodo de wake-up.
3.3.2 Controladores
Los controladores son los elementos de red que tienen acceso de manera completa a la tabla de reenvío,
y que pueden comunicarse sin restricciones con cualquier esclavo que se halle dentro de su influencia.
Dependiendo de sus características encontramos:
 Controlador estático: son aquellos que están destinados a su instalación en una posición fija
definida, habitualmente estando conectados a la red eléctrica. En caso de que se decidan
desplazar es necesario reorganizar la red.
Figura 3.8. Controlador estático Vera 3.
 Controlador portátil: están alimentados por baterías, permitiendo su desplazamiento de

manera libre. Para conseguir un ahorro energético, el tiempo que están escuchando la red es
limitado, de forma que no siempre estarán disponibles para realizar encaminamiento.
Figura 3.9. Controlador portátil modelo Z-URC.
3.3.3 Gestión de esclavos dentro de la red

Se denomina inclusión y exclusión a los procesos de inserción y eliminación de nodos en una red Z-
wave.
3.3.3.1 Inclusión
El controlador primario es el encargado de la inclusión de los demás nodos de la red. Una vez el
controlador pasa a modo inclusión, mediante botón o software, cada nodo que se quiera incluir en la
red tiene que confirmarlo. Todos los dispositivos Z-Wave tienen un botón de operación local
específico para ello y hay que realizar un número de pulsaciones específicas que dependerá del tipo de
dispositivo y fabricante. Habitualmente los dispositivos requieren realizar una o tres pulsaciones. Por
no suponer ningún conflicto y facilitar el proceso a los usuarios, se recomienda realizar tres
44 Z-wave
pulsaciones.
Tras la confirmación, el nodo envía la trama de información (node information frame o NIF) al
controlador con el HomeID, NodeID, y según los identificadores que reciba, se pueden dar dos
situaciones:
 HomeID no asignado: el nodo en cuestión no pertenece a ninguna red. El controlador le asigna

identificación dentro de su red (HomeID, NodeID). Una vez el nodo es añadido a la red Z-
Wave, el controlador solicita lista actualizada de vecinos a todos los nodos y actualiza la tabla
de encaminamiento. El indicador LED del nodo parpadea dos veces para confirmar la
inclusión.
 HomeID de otra red: el nodo envía un paquete de información con HomeID diferente al del
controlador. El dispositivo ya pertenece a otra red y el paquete de información es ignorado.
Para poder ser incluido, tiene que ser excluido de la red original.
Ahora el controlador pasa a modo exclusión y al igual que antes, la confirmación por parte del nodo
se realiza con una o tres pulsaciones en el botón de operación local específico.
3.3.3.2 Exclusión
Ahora el controlador pasa a modo exclusión y al igual que antes, la confirmación por parte del nodo
se realiza con una o tres pulsaciones en el botón de operación local específico. Tras la confirmación,
el nodo envía un paquete de información y de nuevo se dan dos situaciones. El paquete puede
transportar un:
 HomeID válido: el dispositivo pertenece a la red del controlador. Éste lo excluye borrando las
entradas correspondientes en la tabla de encaminamiento y lo resetea, el nodo vuelve a los
valores de fábrica.
 HomeID no válido: no se ejecuta ninguna operación.
3.3.4 Asociaciones
En el proceso habitual de comunicación el controlador es el que solicita información o cambia estado
del esclavo. Si por ejemplo queremos que al detectar presencia se encienda una lámpara, las
comunicaciones tienen que pasar por el controlador con lo que tardan más. Además este dispositivo
tiene que estar siempre escuchando, lo que obliga que sea estático, y es una fuente de error añadida
Para optimizar el uso de la red, Z-Wave permite crear relaciones entre dos dispositivos del tipo esclavo.
Gracias a las asociaciones se reduce el tiempo de las comunicaciones, el uso del canal inalámbrico y
se simplifica el proceso.
Una asociación describe una acción específica entre un nodo fuente y nodo destino. El nodo fuente
envía una señal de control al nodo destino. Se distinguen:
- Asociación directa: Entre esclavos estándares. El nodo fuente en modo asociación espera hasta
recibir el NodeID en la NIF del nodo al que se va asociar para confirmar el proceso. Requiere
alcance directo sin encaminamiento.
- Asociación asignada: Requiere un controlador que conozca toda la red y tenga dentro de su
alcance los nodos fuente y destino. En modo asociación hace de mediador para solicitar la NIF
de los dos nodos implicados y enviar la NIF del dispositivo destino al dispositivo fuente.
El número máximo de nodos destinos asociados al dispositivo estará limitado por la capacidad de
memoria del mismo, habitualmente cinco. En dispositivos sin memoria puede ser más.
3.3.5 Grupos
Los grupos se suelen usar para asignar dispositivos Z-Wave a los botones de los controladores
implementados en forma de mandos a distancia. Es el conjunto de nodos que pueden ser controlados
de forma simultánea por un mismo mensaje proveniente del nodo fuente, estando limitado a cinco
receptores para el caso de dispositivos con capacidad de memoria. El número de grupos de un nodo
fuente dependerá del fabricante y un mismo nodo receptor puede pertenecer a varios.
Generalmente los dispositivos usan la clase de comando básica para el control. En este caso no es
obligatorio agrupar dispositivos similares, pero sí recomendable para evitar comportamientos
anómalos: al mezclar un dimmer y un interruptor, el primero terminará operando como interruptor.
Existen dispositivos que permiten configurar la clase de comando para el control.
3.3.6 Escenas
Son usadas para crear una relación entre un grupo de nodos destinatarios y uno origen de modo que el
origen sea un controlador predispuesto a enviar comandos de control distintos a cada destino. Esto
significa que aumentan las posibilidades respecto a los grupos, siendo más flexibles y potentes, a
cambio de hacer uso de una mayor cantidad de memoria.
46 Z-wave
3.4 Desarrollo de aplicaciones

Actualmente existe un número limitado de herramientas de desarrollo para Z-wave, principalmente
por el hecho de que se trata de una tecnología que no está abierta en cuanto a documentación al público.
De este modo, al margen del kit de desarrollo oficial, han surgido otras alternativas que no proveen de
la misma funcionalidad que esta, pero que siguen siendo válidas.
A continuación se analizan los SDK más populares.
3.4.1 Kit de desarrollo de Sigma Desings

Consiste en un conjunto de herramientas desarrolladas de manera oficial por Sigma Design que
permiten la elaboración de proyectos tanto a nivel electrónico como de aplicación. Entre otros
elementos, se provee de: documentación técnica, sniffer de mensajes, prototipos, placas de prueba,
aplicaciones de ejemplo, herramientas software y API de desarrollo.
Este kit está destinado específicamente a fabricantes, que deben adquirirlo a través de un distribuidor
autorizado por Sigma Designs a un precio que oscila entre los 3000$ [12]. Posteriormente, el
comprador debe firmar un acuerdo de privacidad sobre el producto.
El contenido del kit de desarrollo en su serie 500 está compuesto por tres componentes [12]:
a) Kit regional Z-wave. Consiste en diseños modulares de referencia Z-wave que están
preparados para funcionar en tres de las bandas de radiofrecuencia que utiliza el sistema. De
este modo, dependiendo de si se quiere trabajar a 908 MHz, 868 MHz o 920 MHz, es necesario
adquirir una versión u otra de esta parte. Se entregan los siguientes dispositivos:
- 4 módulos ZM5202 y 4 módulos ZM5304 a modo de ejemplo de diseño. Ambos

funcionales e implementados habitualmente por fabricantes.
- 2 placas de desarrollo modelo ZDB5202.
- 1 placa de desarrollo modelo ZDB5304.
- 1 pasaralea IP ZIPR-CE.
- 1 controlador USB.
- 1 sniffer USB.
b) Kit básico Z-wave. Entre los elementos que contiene se encuentran:
- 4 placas de desarrollo ZDP03A.
- 4 antenas flexibles para los módulos ZDB y ZM anteriores.
- 1 pack de baterías para hacer la placa ZDP03A portátil.
- 1 cable USB para conectar la ZDP03A.
- 1 cable de programador.
- 4 cables de alimentación para la ZPD03A.
- 1 guía de inicio rápido de Z-wave.
Figura 3.10. Parte del kit básico de desarrollo de Z-wave [13].
c) SDK Z-wave. Alberga toda la información técnica necesaria para el desarrollo de la parte de
aplicación. Incluye:
- Torre de protocolos de Z-wave.
- Ejemplos de programas para sistemas empotrados.
- Ejemplos de programas para PC.

48 Z-wave
- Herramientas software de desarrollo.
- Documentación extra para el desarrollador, como FAQ y sección de errores

frecuentes.
Figura 3.11. Interfaz de usuario de Zniffer, una de las herramientas del SDK de Z-wave.
Como parte del producto, Sigma Desings incluye asistencia técnica gratuita y acceso a eventos de
aprendizaje técnico.
En conjunto, el kit de desarrollo proporciona la opción más completa para la realización de cualquier
tarea que se quiera llevar a cabo utilizando la tecnología Z-wave. Como contrapartida, la curva de
aprendizaje frente a opciones que se verán a continuación y su elevado precio, hacen que no sea la
idónea para cualquier proyecto y usuario.
3.4.2 Z-way
Z-way es un software que implementa de forma completa la torre de protocolos de Z-wave y permite
al programador crear sus propias aplicaciones mediante una API basada en peticiones HTTP. Estas
peticiones son atendidas en el PC donde esté instalado mediante un servidor web empotrado que
responde con datos JSON. También incluye una aplicación web de ejemplo que actúa como interfaz
gráfica del escenario de la red Z-wave, permitiendo a un usuario corriente utilizar sus equipos
domóticos sin necesidad de escribir su propio software a partir de la API.
Por un lado se comunica con el controlador Z-Wave mediante la API oficial de Sigma Desings. De
este modo, si se conecta al equipo un controlador con un transceptor Sigma, el software funcionará de
manera automática.
Figura 3.12. Estructura de funcionamiento de un sistema con Z-Way.
Al otro lado, la API basada en HTTP está disponible en forma de funciones JSON, pero también se
proporciona una librería en C que hace uso de ellas para permitir programar en este lenguaje. La API
está dividida en cuatro partes [14]:
- API de dispositivo Z-Wave. Implementa funciones que permiten el acceso directo a la red Z-
Wave mediante el identificador de nodo. Las funciones de interacción con los dispositivos
son las clases de comando ya mencionadas anteriormente. Adicionalmente permite el acceso
mediante otras funciones a la interfaz de gestión de la red mediante las denominadas clases
de función. Su acceso se realiza mediante llamadas a la dirección
http://IP:8083/ZWaveAPI/*.
Ejemplo. Esta petición provoca que el dispositivo ID 2 se encienda gracias a la clase de

comando básico (en este caso, establecer a 255 equivale a encendido y 0 a apagado):
http://IP:8083/ZWaveAPI/Run/devices[2].instances[0].Basic.Set(255)
- API de tecnologías de terceros. Implementa la misma lógica de la API de dispositivo Z-Wave

50 Z-wave
para otros sistemas inalámbricos como EnOcean.
- API JavaScript. Permite escribir funciones JavaScript que son añadidas al servidor web como
módulos, de forma que pueden ser utilizadas como las que vienen por defecto. Se utiliza
realizando llamadas a http://IP:8083/JS/Run/*, sustituyendo el asterisco por el código a
ejecutar.
Ejemplo. El siguiente acceso web provocaría que se llamara a la función Get del nodo con
ID 2 cada 300 segundos:
http://IP:8083/JS/Run/setInterval(function() {
zway.devices[2].Basic.Get();
}, 300∗1000);
- API de dispositivo virtual. Constituye un módulo JavaScript que asigna a cada dispositivo
físico y función un dispositivo virtual. El objetivo de esto es permitir simplificar el desarrollo
e implementación de la interfaz de usuario al programador.
Z-Way es compatible con diversos controladores Z-Wave de distintos fabricantes, además de ser
multiplataforma.
El dispositivo más conocido que utiliza Z-Way es Razberry, un pequeño módulo que se conecta a las
GPIO de la Raspberry Pi y se comunica a través de la UART con ella. Contiene un módulo Sigma
Desings ZM3102 capaz de emitir en la banda europea, americana y rusa [15].
Figura 3.13. Módulo Razberry conectado a las GPIO de una Raspberry Pi.
3.4.3 OpenZWave
OpenZWave es un conjunto de librerías multiplataforma y de código abierto escrito en C++. Tiene
como fin proporcionar a las aplicaciones soporte para la comunicación con dispositivos Z-wave sin
requerir previamente de un grado de conocimiento profundo sobre esta tecnología.
Está diseñado específicamente para hacer de interfaz con un controlador USB para PC. Actualmente
el propio proyecto reconoce la compatibilidad con los siguientes:
Tabla 3.1. Compatibilidad de controladores USB con OpenZWave.
Fabricante Tipo de conexión
Tricklestar USB
ACT ZCS101 RS232
Z-troller RS232
Aeon ZStick USB
Seluxit ViaSens 100 USB
Z-Wave.Me Z-Stick USB
Uno de los motores que provocó el inicio del proyecto es la ausencia en Z-wave de una API oficial y
pública que, sumado al elevado coste del SDK de Sigma Designs, provocó que una comunidad de
usuarios trataran de llevar a cabo su propia versión. De hecho, buena parte del desarrollo de
OpenZWave está basado en ingeniería inversa, analizando los paquetes que se intercambian los nodos
52 Z-wave
de una red Z-Wave, y en código proveniente de la distribución LinuxMCE [16].
También existe el proyecto Python-OpenZWave cuyo fin es encapsular las funcionalidades de

OpenZWave en Python.
OpenZWave ha sido la opción escogida para desarrollar este trabajo. Permite utilizar toda la potencia
del lenguaje C++ de manera nativa, sin recurrir a adaptaciones hechas para otros lenguajes, y sin
realizar desembolso alguno. Como contrapartida, al tratarse de una librería aún en desarrollo, existen
opciones de comunicación entre controlador-red que aún no están soportadas y la documentación es
escasa en ocasiones. Sin embargo, esto no es nada grave para nuestros propósitos.
3.4.3.1 Funcionamiento
El funcionamiento de OpenZWave está basado en torno a la clase Manager, esta contiene todos los
elementos necesarios para realizar una aplicación completa. Permite enviar y recibir información de
los nodos, además de configurar la red. Los desarrolladores admiten que no se trata de la opción más
eficiente de estructurar un programa orientado a objetos, pero este modelo permite un desarrollo más
robusto y resistente a fallos [17].
Un programa que utiliza las librerías OpenZWave normalmente comienza implementando una única
instancia estática de la clase Manager y finaliza destruyendo la misma. Durante el transcurso del
programa, cuando tiene que llamar a algún método presente en el Manager, debe obtener dicha
instancia mediante el uso de Manager::Get(), y a continuación acceder al método deseado a través
de ella.
 Controladores
OpenZWave es capaz de gestionar varios controladores USB a la vez, utilizando para representarlos
la clase Driver. Como se ha mencionado, no es necesario utilizar clases más allá de Manager para
crear un programa, y si bien es posible interactuar con el objeto Driver directamente para realizar
ciertas tareas, lo habitual es delegar en Manager la creación y utilización del mismo. Es decir, llamando
a Manager::Get()->AddDriver(param), Manager se encarga de crear el elemento Driver
asociado al controlador USB físico y de gestionar el objeto. El parámetro que recibe el método es la
ruta al dispositivo USB, de forma que en Linux tendrá el formato habitual /dev/ttyUSBX.
Una vez el controlador se ha iniciado correctamente, OpenZWave recibe el HomeID de red, siendo
capaz de distinguir los distintos mensajes que recibirá de un determinado controlador u otro.
 Nodos
Cuando OpenZWave se percata de que existe un nodo en la red, recibe el identificador NodeID que le
pasa el controlador y le asocia un objeto Node con la información que posee del mismo. En futuras
actualizaciones sobre su estado, los atributos que posee irán variando, de modo que mediante la
consulta su objeto asociado se puede averiguar toda la información actual disponible sobre él.
De nuevo no es necesario el tratamiento directo con los objetos Node para llevar a cabo una aplicación,
al ser accesible los nodos mediante Manager. Sin embargo, uno de los parámetros más interesantes
que alberga es el estado de consulta de nodo, que es la percepción que tiene OpenZWave sobre la
conexión con él.
La librería también incluye soporte para asociaciones y escenas mediante los métodos CreateScene
y AddAssociation.
 Valores
Un elemento ValueID representa un valor asociado a una clase de comando Z-wave de un

determinado nodo, y constituye la manera más simple de leer y modificar la información contenida en
ellos. Por ejemplo, si un nodo implementa la clase de comando que permite leer su estado de batería
COMMAND_CLASS_BATTERY, entonces habremos de buscar un ValueID que posea el valor
asociado a dicho comando (en este caso 0x80) y leer el valor.
Es necesario hacer notar que en ocasiones, para un mismo valor de clase de comando, existen diversos
ValueID, para diferenciar entre ellos es necesario comprobar entonces otro campo: el índice.
Existen ValueID de escritura/lectura, de solo lectura y de solo escritura; el valor de batería

anteriormente mencionado será lógicamente de sólo lectura. Del mismo modo, OpenZWave distingue
entre distintos tipos de dato dentro de los valores, estos son:
54 Z-wave
Tabla 3.2. Tipos de valores ValueID.
Nombre dentro del Descripción

ValueType_Bool
enumerado
Booleano, verdadero o falso.
ValueType_Byte
Valor de 8 bits sin signo
ValueType_Decimal
Representa un valor decimal como cadena de caracteres.
ValueType_Int
Entero de 32 bits con signo.
ValueType_List
Lista de elementos.
ValueType_Schedule
Tipo complejo utilizado en la clase de comando
COMMAND_CLASS_CLIMATE_CONTROL_SCHEDULE.
ValueType_Short
Entero de 16 bits con signo.
ValueType_String
Cadena de texto.
ValueType_Button
Valor de solo escritura que es equivalente a pulsar un botón para
enviar un comando al dispositivo.
ValueType_Raw
Colección de bytes.
Afortunadamente, la clase Manager provee de métodos para trabajar con ValueID de manera muy
sencilla:
- GetValueLabel(v_id): permite conocer qué representa el dato que alberga el ValueID.
- GetValueUnits(v_id): devuelve las unidades en las que se mide el dato. Si por ejemplo se
está leyendo el valor de la energía consumida en un actuador eléctrico, este método podría
indicar que las unidades se encuentran en mWh.
- GetValueMin(v_id) y GetValueMin(v_id): indican el rango admisible del dato de un
ValueID. En caso de que escribamos un valor que excede estos valores, el nodo lo ignorará
o lo pondrá al extremo más cercano.
- isValueReadOnly(v_id) e isValueWriteOnly(v_id): determinan si un ValueID es

modificable o es de lectura.
- GetValueAsString(v_id): devuelve el valor del ValueID en forma de string,
independientemente del ValueType que tenga asignado.
- SetValue(v_id): permite establecer el valor del ValueID de manera igualmente
independiente.
Uno de los conceptos importantes sobre los nodos es el de sondeo o “polling”. El comportamiento
ideal de un nodo es aquel en el que cada vez que despierta informa de cambios en sus valores medidos,
sin embargo esto no ocurre siempre, especialmente en nodos que son más antiguos. Para solventar este
factor, es necesario declarar a OpenZWave nuestro interés en que consulte activamente el ValueID
deseado. Esto es lo que denominamos “polling”.
Manager proporciona métodos específicos para realizar este proceso de manera automática durante
todo el programa con EnablePoll(v_id, intensidad). Otra posibilidad es solicitar de manera

manual el sondeo siempre que deseemos con el método RefreshValue(v_id).
 Notificaciones
La programación con OpenZWave se basa en eventos, uno de los primeros pasos en la codificación
de un programa es la inserción de una función de callback que permita discernir entre los diferentes
eventos que han llegado desde el controlador y tratar cada uno de manera apropiada. Esta función debe
ser creada por el programador y declarada explícitamente ante OpenZWave mediante el método
Manager::Get()->AddWatcher( FuncionCallback, NULL ). Tan sólo debe existir una función
de este tipo en el código, dado que con independencia del número de controladores que existan, se
llamará siempre a la misma función especificada.
Siguiendo con lo anterior, cada evento está representado de manera lógica por un objeto de la clase
Notification, que es el objeto que OpenZWave crea programáticamente cada vez que recibe nueva
información sobre algún nodo. En la práctica, la función de callback debe analizar este objeto
analizando los atributos que posee y actuando en consecuencia.
56 Z-wave
Figura 3.14. Secuencia de llegada de notificaciones en OpenZWave.
Entre los campos que posee una notificación se encuentran el HomeID, NodeID y objetos ValueID
relativos al nodo afectado, pero el más importante es el de tipo de notificación. Alguno de los valores
que puede tomar este campo son:
Tabla 3.3. Algunos valores del campo NotificationType de la clase Notification.
Nombre dentro del enumerado Descripción
Type_NodeAdded
Se ha incluido un nuevo nodo en la red o bien se acaba
de descubrir en un primer arranque del programa.
Type_NodeRemoved
Se ha excluido un nodo de la red.
Type_DriverReady
El controlador USB se ha iniciado y está listo para su
uso. Devuelve el HomeID de la red.
Type_DriverFailed
El controlador USB ha fallado.
Type_ValueChanged
El valor del comando de un nodo ha cambiado con
respecto al que poseía previamente.
Type_AllNodesQueried
Todos los nodos han sido interrogados y se puede
esperar que funcionen correctamente.
Type_AllNodesQueriedSomeDead
Todos los nodos han sido interrogados, se han hallado
algunos que están ausentes.
 Configuración
OpenZWave hace uso de tres archivos para su configuración escritos en formato XML.
El primero de ellos es options.xml, que contiene parámetros de funcionamiento establecidos por el

usuario. Existe un cierto número de opciones configurables en él, destacando la activación del modo
de depuración, que permite imprimir por pantalla todos los eventos que estén ocurriendo en la lógica
de OpenZWave.
Ejemplo. El siguiente código provocaría que la librería tratara de inicializar el controlador un

máximo de tres veces y que la visión de la red se guarde en un archivo al finalizar el programa.
<Options xmlns='http://code.google.com/p/open-zwave/'>
<Option name="DriverMaxAttempts" value="3" />
<Option name="SaveConfiguration" value="true" />
</Options>
El archivo de opciones puede crearse de manera manual en cualquier directorio deseado o bien de
manera dinámica en tiempo de ejecución, pero siempre es necesario codificar en el programa la ruta
hacia el mismo.
La clase Options es la encargada de interactuar con el fichero options.xml, siempre debe ser
declarada en un programa y su instanciación debe ocurrir siempre antes de que se declare el Manager.
Durante su inicialización mediante Options::Create(param1, param2, param3), recibe la ruta
en la que el usuario desea guardar los ficheros .xml de los que hace uso OpenZWave, así como el
directorio donde se hallan los esquemas XML que contienen la sintaxis válida para su lectura y
escritura.
58 Z-wave
Si el programador decidiera modificar las opciones llegados a este punto, tan sólo debería hacer uso
del método Options::Get()->AddOptionInt(“parametro”,valor) si se trata de un entero.
Métodos similares existen para los casos de booleanos y cadenas de texto. Una vez haya realizado
todos los cambios oportunos, debe bloquear el objeto mediante Options::Lock() y podrá entonces
instanciar el Manager.
El segundo de los archivos de configuración que utiliza OpenZWave es zwcfg.xml. Este actúa como
memoria caché de la visión que tiene la librería sobre la red, además de servir para descubrirla más
rápidamente la próxima vez que se inicie el programa.
Ejemplo. El siguiente ejemplo ha sido generado con una red en la que sólo existe un controlador
estático USB.
<Driver xmlns="http://code.google.com/p/open-zwave/" version="3" home_id="0x014d0428"

node_id="1" api_capabilities="8" controller_capabilities="28">
<Node id="1" name="" location="" basic="2" generic="2" specific="0" type="Static
Controller" listening="true" frequentListening="false" beaming="true"
routing="false" max_baud_rate="40000" version="3" query_stage="Complete">
<Manufacturer id="0086" name="Aeon Labs">
<Product type="0002" id="0001" name="Z-Stick S2"/>
</Manufacturer>
<CommandClasses>
<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1"
after_mark="true" create_vars="true">
<Instance index="1"/>
<Value type="byte" genre="all" instance="1" index="0"
label="Basic" units="" read_only="false" write_only="false"
verify_changes="false" poll_intensity="0" min="0" max="255"
value=""/>
</CommandClass>
</CommandClasses>
</Node>
</Driver>
El último archivo de configuración es la base de datos de dispositivos de OpenZWave. Consiste en

varios ficheros XML que contienen la descripción de distintos dispositivos Z-wave y que le permite
modificar su comportamiento en base a ellos, aunque en la mayoría de los casos su utilidad se restringe
a permitir conocer el modelo y fabricante de un determinado nodo en base al ID que reporta.
Estos ficheros se encuentran en la ruta open-zwave/config del proyecto, siendo el punto de entrada
principal el fichero manufacturer_specific.xml. A raíz de este, si el dispositivo posee alguna
particularidad, se remite a otro fichero XML donde se describen las características especiales del
mismo.
Ejemplo. El siguiente ejemplo muestra parte del fichero manufacturer_specific.xml. El

segundo producto posee características especiales que se desarrollan en el archivo 2gig/ct100.xml:
<ManufacturerSpecificData xmlns='http://code.google.com/p/open-zwave/'>
<Manufacturer id="0098" name="2GIG Technologies">
<Product type="1e12" id="015c" name="CT30 Thermostat" />
<Product type="6401" id="0105" name="CT100 Thermostat"
config="2gig/ct100.xml"/>
</Manufacturer>
...
</ManufacturerSpecificData>
60 Aplicación desarrollada
4 APLICACIÓN DESARROLLADA
a aplicación consta de tres componentes: el programa servidor escrito en C++ que se comunica
L con la red Z-wave mediante la interfaz OpenZWave, una base de datos y la interfaz gráfica
basada en HTTP.
Figura 4.1. Estructura general de la aplicación desarrollada.

La interfaz HTTP permite al usuario obtener una visión simple y clara del estado de la red, iniciar la
recogida de muestras y obtener información sobre los datos recogidos. Dado que el objetivo clave del
proyecto es precisamente la información obtenida, la web permite procesar los datos mediante la
generación de gráficas, así como la descarga de archivos para su posterior análisis y tratamiento en
programas informáticos.
Se ha escogido una web como interfaz de usuario por simplicidad de operación, al ser la Raspberry Pi
un dispositivo portátil y normalmente carente de pantalla, teclado o ratón. Habitualmente lo más
simple es conectar el dispositivo a una red LAN, de forma que de no utilizar una interfaz web, las
alternativas a la obtención de los datos recogidos con los sensores pasarían entonces por procesos
como establecer una conexión mediante Telnet/SSH a la Raspberry Pi o descargar la información
mediante un lector de tarjetas SD.
Por otro lado, la base de datos cumple el papel de almacenamiento de las muestras de humedad y
temperatura, la composición de la red Z-wave, su estado y las peticiones que el cliente realiza al
servidor.
Por último, el programa principal se encarga arrancar el controlador USB y gestionar la parte lógica
de la red Z-wave. De esto modo, cada vez que sucede algún evento en la red que es relevante para
nuestros propósitos, el programa es capaz de tratarlo y procesarlo gracias a la interfaz OpenZWave.
Un ejemplo de este tipo es un cambio en la topología de la red, cuando el controlador avisa de que
existe un nuevo nodo en ella, el programa lee la información sobre el mismo y actualiza la tabla de
nodos de la base de datos. De la misma manera, cada vez que tiene que actuar ante una petición del
cliente, es capaz de enviar órdenes a los nodos y ejecutar las acciones precisas para llevar a cabo la
tarea requerida. Una situación de este tipo es la solicitud de actualización de tiempo de wake-up de los
nodos, cuando el programa principal se percata de la petición, utiliza OpenZWave para enviar un
mensaje a cada nodo de la red solicitándoles que cambien su tiempo de sueño al establecido por el
usuario.
4.1 Base de datos

Se ha seleccionado una base de datos PostgreSQL que está ejecutándose constantemente en el sistema
operativo Raspbian de la Raspberry Pi. El motivo de esta elección es la sencillez de su integración en
el desarrollo de aplicaciones C++ a través de su conector oficial “libpqxx” frente a MySQL, que
requiere la instalación de varios paquetes adicionales.
Con respecto al servidor web Apache utilizado, también ha sido necesario la instalación de los módulos
“php5-pgsql” y “libapache2-mod-auth-pgsql”.
PostgreSQL se ha configurado para funcionar con un usuario propio “proyectousr” por motivos de
seguridad, dejando configurado el usuario “postgres” con una contraseña distinta a la que venía por
defecto. Bajo el nuevo usuario se ha creado la base de datos “proyectodb”, que es la que alberga las
cinco tablas que se explican a continuación.
La tabla “acceso” contiene la información relativa a los usuarios que están permitidos en el sistema.
Un usuario que no esté en esta tabla no podrá acceder a la interfaz web y por lo tanto llevar a cabo las
tareas de lanzamiento de recogida de datos y visionado de resultados. Alberga los siguientes campos:
- usuario: es una cadena de caracteres que identifica unívocamente al usuario. Es clave
primaria de la tabla.
- clave: contiene una cadena de caracteres que corresponderá con la huella MD5 de la
contraseña que haya seleccionado el usuario.
- rol: es un número entero que se utiliza para identificar si el usuario es administrador del
sistema (1) o un usuario corriente (0). Se comprueba activamente en el gestor de la base de
datos que el campo cumple con alguno de estos dos valores al introducir una nueva fila en la
tabla.
Ejemplo.
usuario | clave | rol
---------+----------------------------------+-----
admin | 81dc9bdb52d04dc20036dbd8313ed055 | 0
prueba | 81dc9bdb52d04dc20036dbd8313ed055 | 1
La tabla “configuración” alberga peticiones que son leídas y posteriormente borradas por el
destinatario de la información. Los dos interlocutores son evidentemente la aplicación web y el
programa principal. A modo de ejemplo, cuando el usuario solicita la cancelación abrupta de una toma
de medidas, se escribirá en esta tabla una entrada mediante PHP a modo de solicitud, que cuando el
programa principal lea, borrará y actuará.
Aunque a priori utilizar la base de datos para transmitir información no parezca la manera más
ortodoxa de hacerlo, protocolos como SNMP utilizan este mecanismo, y cualquier otra alternativa
pasaría por añadir un nuevo componente al sistema. Es necesario añadir que el periodo de
comprobación de elementos nuevos en el programa principal es muy bajo, de unos 30 segundos, con
lo que no existen problemas de rendimiento debidos a una consulta demasiado recurrente.
Los atributos de esta columna son sólo dos:
- parámetro.
- valor.
La tercera de las tablas es “nodos”. Esta trata de reflejar el estado real de la red, con información
reportada por OpenZWave a través del programa. El programa principal escribe en ella y actualiza los
valores cuando recibe información reciente, mientras que la aplicación web es la consumidora de los
datos.
- id_nodo: es un entero que identifica a un nodo dentro de una red Z-wave establecida. Este
número viene determinado por el controlador físico, que lo asigna normalmente en función
del órden de inclusión en la red. Es la clave primaria.
- marca: cadena de caracteres que alberga el nombre del fabricante del nodo, en caso de que se
conozca esta información.
- modelo: contiene la denominación del modelo que le ha asignado el fabricante al dispositivo.
- tiempo_dormido: entero que almacena el número de segundos de wake-up que el

controlador cree que posee el nodo.
- muerto: booleano que se activa cuando el controlador percibe que el nodo de la red no
funciona como es debido.
Ejemplo.
id_nodo | marca | modelo | bateria | tiempo_dormido | muerto

---------+-----------------+-----------------+---------------------+----------------+--------
6 | Everspring | ST814 | 100 | 60 | f
7 | ( desconocido ) | ( desconocido ) | Corriente eléctrica | 60 | t
La tabla “experimentos” alberga información relativa a cada proceso de recogida de muestras. Así
mismo, gracias a este concepto, posteriormente se pueden aglutinar las diferentes muestras que
pertenecen a un mismo experimento. Sus campos son:
- id_experimento: consiste en un entero que sirve como identificador único del experimento.
Se ha escogido que su valor corresponda con el instante en el que el usuario solicita su
comienzo, en formato de tiempo UNIX. Este factor se aprovecha para utilizarlo como clave
primaria.
- usuario_creador: guarda el nombre del usuario que propuso el experimento. Impide que
desde la aplicación web un usuario pueda borrar la información de otro usuario, con excepción
del administrador. Es clave externa del campo usuario de la tabla “acceso”.
- tiempo_inicio: corresponde con el instante efectivo de comienzo de recogida de datos. Es
calculado por el programa principal y asegura que todos los nodos han despertado y sido
informados de que deben ponerse a medir para cuando haya transcurrido.
- tiempo_fin: instante efectivo tras el que no se tomarán más medidas de humedad y

temperatura. También es calculado por el programa principal en función del instante efectivo
de inicio y la duración deseada.
- duración: es el periodo de tiempo en segundos durante el que el usuario desea recopilar

medidas.
- muestreo: alberga en intervalo de tiempo que debe transcurrir entre medidas. Por cuestiones
de diseño de los nodos de Z-wave, este número nunca puede ser inferior a los 60 segundos.
- estado: refleja la situación del experimento programado por el usuario. Puede tomar cuatro
valores:
o 0: indica que el usuario ha solicitado el experimento pero está a la espera de que el

programa principal lea la petición y la acepte.
o 1: significa que el programa principal ha iniciado o está procesando la toma de

medidas.
o 2: la recogida de datos ha terminado satisfactoriamente.
o 3: indica que el usuario ha finalizado el experimento sin esperar a que finalice.
Ejemplo. Nótese como la segunda tupla carece de tiempos de inicio y fin al ser su estado “0”, dado
que el programa principal aún no procesado la petición.
id_experimento | usuario_creador | tiempo_inicio | tiempo_fin | duracion | muestreo | estado
----------------+-----------------+---------------+------------+----------+----------+--------
1404646208 | admin | 1404646291 | 1404649891 | 3600 | 60 | 2
1404664507 | admin | | | 1800 | 90 | 0
La tabla “muestras” alberga los valores de temperatura y humedad que han sido recogidos por los
distintos nodos de la red Z-wave.
- id_experimento: clave externa del campo homónimo de la tabla “experimentos”.
- nodo_remitente: clave externa del campo id_nodo de la tabla “nodos”.
- tiempo_muestra: instante de tiempo en el que la muestra ha sido tomada. Junto con los dos
atributos anteriores conforma la clave primaria de la tabla.
- temperatura: valor de temperatura reportado por el nodo.
- unidades_temperatura: unidades de la temperatura. Es necesario porque un mismo nodo

puede trabajar tanto en grados Fahrenheit como Celsius.
- humedad: valor de la humedad.

- unidades_temperatura: mismo caso que unidades_temperatura.
Ejemplo.
id_experimento | nodo_remitente | tiempo_muestra | temperatura | unidades_temperatura | humedad
| unidades_humedad
----------------+----------------+----------------+-------------+----------------------+---------+---
1404646208 | 6 | 1404646291 | 28.4 | C | 44 | %
1404646208 | 6 | 1404646351 | 28.4 | C | 44 | %
1404646208 | 6 | 1404646411 | 28.3 | C | 44 | %
1404646208 | 6 | 1404646471 | 28.2 | C | 44 | %
En el siguiente diagrama se muestran las relaciones entre las distintas tablas. Las claves primarias se
encuentran subrayadas mientras que las externas se indican con flechas.
Figura 4.2. Diagrama E-R de la base de datos.
4.2 Programa principal

Se encuentra escrito en C++ con el objetivo de que pueda utilizar las librerías de OpenZWave, escritas
en el mismo lenguaje. Debido a la falta de documentación y ejemplos de implementación de
OpenZWave, se ha partido desde la única aplicación de ejemplo que acompañaba a las librerías,
denominada MinOZW.cpp.
Los objetivos en el desarrollo del programa han sido los siguientes:
 Servir de interfaz entre la aplicación web y la red Z-wave.
 Gestionar las peticiones de recogidas de muestras de humedad y temperatura de manera

transparente al usuario.
 Proporcionar información sobre el estado real de la red.
El programa se estructura en torno a un archivo fuente Main.cpp que hace uso de BaseDatos.h.
Este último define la clase BaseDatos, que se instanciará como objeto vehicular para acceder a la base
de datos PostgreSQL instalada en el sistema.
4.2.1 Inicialización del programa

Como se ha explicado en el apartado de funcionamiento de OpenZWave, lo primero que se realiza en
la codificación de un programa que use esta librería es la declaración de un objeto Options, que
permite conocer dónde se guardarán los archivos XML de opciones y de escena. Tras este proceso se
bloquea el objeto e instancia la clase Manager.
Una vez creado este último, se le indica dónde se halla el controlador USB, que por defecto estará en
/dev/ttyUSB0 si se acaba de arrancar la Raspberry Pi y no existe ningún otro dispositivo conectado.
A continuación se indica la función de callback que gestionará todos los eventos recibidos desde el
controlador mediante el método AddWatcher, en nuestro caso, NotificacionRecibida será la
encargada.
Antes de comenzar a explicar cómo funciona la función de callback, es necesario analizar la manera
que tiene el programa de guardar la información sobre los nodos. Para ello se utiliza la estructura
NodeInfo, que representa a un nodo mediante los siguientes campos:
- m_homeId: entero que alberga el HomeID del nodo, dado que la Raspberry Pi tan sólo
funcionará con un único controlador, este número será idéntico para todos.
- m_nodeId: guarda el NodeID del dispositivo.
- m_polled: booleano que se activa cuando se ha establecido el sondeo o polling para el nodo.
- m_values: consiste en una lista de objetos de la clase ValueID, de forma que se almacenan
todos los valores que un nodo posee debido a las distintas clases de comando que implementa.
Figura 4.3. Representación de un nodo de la red en el programa.
Una vez se tiene definida la estructura del nodo, el siguiente paso es la agrupación de las distintas
estructuras que representan a cada nodo de nuestra red en una lista. Es decir, un elemento
list<NodeInfo*> que en el programa se identifica con el nombre g_nodos.
Figura 4.4. Representación de la lista de nodos en el programa principal.
Partiendo de esta base, ya conocemos los objetos de referencia con los que se va a tratar durante el
programa y cómo hacerlo. Cuando se quiera conocer algo sobre un nodo o modificar su
comportamiento será necesario buscar en la lista aquel que nos interese y con las funciones apropiadas
de Manager, manipularlo. Es interesante hacer notar también que hasta ahora no se ha hecho ninguna
discriminación entre nodos que son capaces de reportar humedad y temperatura (las magnitudes que
queremos medir) y los que no. Esto se realizará más adelante, de forma que la lista de nodos contendrá
todos con independencia de su naturaleza.
La función de callback se sirve de una función auxiliar denominada GetNodeInfo. Cuando llega una
notificación, es necesario conocer sobre qué nodo de nuestra red está versando la información que
porta, de modo que la función GetNodeInfo es capaz de averiguar si esa información es relativa a un
nodo existente o no, y de serlo, devolver el objeto NodeInfo afectado que está insertado en nuestra
lista de nodos g_nodos.
Finalmente, la función NotificacionRecibida, que como recordamos hemos definido como de

callback, cumple las funciones de procesar los objetos Notification que le son pasados por
OpenZWave. Cuando la función es llamada se lanza un hilo que produce su ejecución. Con el fin de
que resto del programa no modifique la lista de nodos g_nodos mientras NotificacionRecibida
está en curso, es necesario realizar un bloqueo de hilos mediante semáforos, entrando en lo que se
denomina como zona crítica.
Ya se explicaron en la sección de OpenZWave los tipos de notificaciones que existían, y como son un
elemento clave para su discriminación. NotificacionRecibida está estructurada como una simple
cadena de casos que actúa sobre el programa o la lista de nodos dependiendo de lo recibido. A
continuación se explican alguno de estos:
- Ante una notificación de tipo Type_ValueAdded, Type_ValueRemoved o

Type_ValueChanged se utiliza la función GetNodeInfo antes descrita para localizar al nodo
dentro de la lista g_nodos y modificar el ValueID sobre el que la notificación está

informando. Es la situación en la que el programa acaba de averiguar que ha cambiado el valor
de la temperatura de un nodo.
Figura 4.5. Llegada de una notificación de cambio de valor en un nodo.
- Ante la llegada de una notificación con tipo Type_NodeAdded, se crea un objeto NodeInfo y
se inserta en la lista g_nodos mediante el método push_back.
- Cuando se recibe Type_NodeRemoved se elimina el nodo de la lista utilizando el método

erase.
- Type_DriverFailed provoca que se active la bandera global g_inicioFallido.
Volviendo a la situación de inicialización en la que nos hallábamos con el Manager creado, el siguiente
paso es entrar en el bucle infinito del programa, aunque esto nunca ocurrirá si la bandera que se acaba
de mencionar está activa.
4.2.2 Cuerpo del programa
El bucle se recorre cada segundo, al existir una sentencia sleep al final de él. Posee cuatro partes
funcionales con un temporizador cada una, de forma que se ejecutarán cada ciertos segundos.
Previamente se crea el objeto BaseDatos y se purgan las tablas “muestras”, “nodos” y “experimentos”
para que el programa empiece a funcionar de manera consistente. Esto se lleva a cabo mediante el
método limpiarTablas que está presente en la clase.
4.2.2.1 Bloque de estado de la red
La función de este apartado es leer la configuración de la red Z-wave y actualizar los valores que
existen en la tabla “nodos” de la base de datos. Para ello, se activa el bloqueo de zona crítica y se pasa
a recorrer la lista de nodos g_nodos que posee el programa mediante un elemento iterador.
Para cada elemento de la lista se leen los distintos valores que se incorporarán a la tabla, de este modo,
se toma el elemento NodeInfo que tome el iterador, y mediante los métodos de Manager
GetNodeManufacturerName, GetNodeProductName e IsNodeFailed se pueden rellenar los
atributos de “marca”, “modelo” y “muerto” de la tabla respectivamente. Hay que recordar que el
identificador de nodo era un campo de la estructura NodeInfo, y que por lo tanto se puede obtener el
valor de “id_nodo” directamente accediendo al campo m_nodeId de ella.
El último campo, el de “tiempo_dormido”, se obtiene iterando sobre la lista de valores que posee el
nodo (recordemos que era el último de los elementos de la estructura NodeInfo), de forma que es
necesario recorrer la lista para buscar aquel ValueID que posea la clase de comando definida por la
constante COMMAND_CLASS_BATTERY, y dentro de esta, el índice BATTERY_INDEX. Estas poseen lo
valores decimales 128 y 0.
Figura 4.6. Actualización de la tabla “acceso” en el bloque de estado de la red.
El programa además almacena el mayor tiempo de dormir de entre todos los nodos en la variable
mayor_tiempo_dormir.
Una vez ha finalizado el bloque, se procede a salir de la zona crítica y se sale de él.
4.2.2.2 Bloque de detección de nuevos experimentos
Se ejecuta cada periódicamente en función del número de segundos que indique

INTERVALO_LECTURA_EXPERIMENTOS. Su objetivo es comprobar la existencia de nuevas solicitudes
de recogidas de muestras programadas por el usuario en la tabla “experimentos” de la base de datos y
procesarlas. Recordemos que esto se corresponde con la existencia de una fila cuyo valor de atributo
“estado” sea 0, hecho que se comprueba llamando al método
base_datos.existeNuevoExperimento. En caso de que se obtenga un resultado negativo el
programa ha finalizado el bloque, en caso contrario accede a la tupla de la tabla y se copian los datos.
En este punto se realiza la planificación temporal de la recogida, calculándose el momento efectivo en

el que comenzarán a recogerse los valores.
Es necesario explicar que se posee una red en la que cada nodo puede tener un periodo de wake-up
diferente, de modo que un nodo A puede despertarse cada 200 segundos y un nodo B cada 100. Si
suponemos ahora que el usuario ha solicitado un periodo de muestreo de 60 segundos, es fácil ver que
hay que indicar a ambos que deben cambiar su periodo de sueño a este valor previamente al comienzo
de la recogida de datos. De esta forma, cada vez que se despierten e informen con la nueva frecuencia,
nos aseguraremos que se verifica el muestreo en 60 segundos.
Este proceso se realiza recorriendo la lista g_nodos, y accediendo a aquellos que implementen la clase
de comando propia de los sensores de luz y humedad (definida por la constante
COMMAND_CLASS_SENSOR_MULTILEVEL, cuyo valor es 49). Si se verifica esta condición se indica al
nodo que debe despertarse cada 60 segundos (siguiendo con el ejemplo propuesto) mediante la
modificación del ValueID dado por COMMAND_CLASS_WAKEUP. Esto se traduce en un mensaje radio
que se enviará desde el controlador hasta el nodo cuyo valor se ha cambiado.
OpenZWave deja en espera los mensajes que van dirigidos a un nodo que está dormido, de forma que
cuando se despierta se lo envía. Se deduce en definitiva que tan sólo hay esperar el mayor tiempo de
espera de todos los nodos para asegurarnos de que todos han despertado al menos una vez y por tanto
recibido la orden de ajustar su nuevo periodo de wake-up a esos 60 segundos. Una vez hecho esto, la
simulación puede comenzar.
Figura 4.7. Cálculo del comienzo de la recogida.
Concretamente, el tiempo de inicio es calculado como la hora UNIX actual más

mayor_tiempo_dormir, y del mismo modo se calcula el tiempo de fin de simulación mediante la
suma del tiempo de inicio y la duración que ha escogido el usuario. Estos valores son actualizados en
la fila de la tabla “experimentos” correspondiente, además de marcarse el experimento como iniciado
(es decir, el estado pasa a valer 1) mediante base_datos.cambiarEstadoExperimento. De este
modo el usuario puede ver en la interfaz gráfica que su solicitud ha pasado a procesarse y las horas de
inicio y finalización.
Por último, la bandera experimento pasa a ser distinta de cero, con las consecuencias que se tratarán
a continuación.
4.2.2.3 Bloque de gestión de la recogida de datos
Este bloque nunca se ejecuta, a no ser que el bloque anterior haya decidido iniciar una recogida
mediante el establecimiento de la bandera experimento. En este caso se pueden dar dos situaciones,
que el periodo de guarda que asegura el ajuste de los periodos de sueño anteriormente descrito haya
transcurrido o no lo haya hecho.
En el caso de que no haya transcurrido, el bloque queda a la espera de que transcurra. En caso contrario,
se verifica que la hora actual no haya excedido el tiempo de finalización del experimento y se comienza
a ejecutar un pedazo de código periódicamente cada periodo de muestreo.
Este pedazo tiene como fin almacenar en la tabla “muestras” los valores de humedad y temperatura
que han reportado los nodos de la red en el instante dado. Para ello, se seleccionan de nuevo los nodos
de nuestro interés accediendo en la lista g_nodos y tomando los que implementan la clase de comando
de los sensores multinivel. Una vez hecho esto, se copian los valores de humedad y temperatura
mediante la comprobación de que los índices poseen los valores TEMPERATURE_INDEX y
HUMIDITY_INDEX.
Figura 4.8. Secuencia de funcionamiento del bloque de gestión de recogidas del programa principal.
El siguiente paso es insertar en la tabla “muestras” los valores recogidos, este proceso se ejecuta con
el método insertarMuestra de la clase BaseDatos.
Cuando el tiempo de finalización haya concluido, entonces la variable experimento se pone a valor
nulo, con lo que el bloque no se volverá a ejecutar. Además el experimento será marcado en la tabla
“experimentos” con el estado 2, que significa que ha concluido satisfactoriamente. El último paso es
enviar un mensaje a todos los nodos para que recuperen el valor de periodo de sueño que poseían
previamente.
4.2.2.4 Bloque de configuración
Permite leer periódicamente la tabla “configuracion” de la base de datos, actuando en consecuencia

con lo que se indique en ella. Actualmente el único mensaje que puede aparecer en la tabla es una
solicitud de cancelación de recogida en curso, de modo que cuando el programa se encuentre ante ella,
borrará la fila y ejecutará las acciones necesarias para finalizar el proceso.
Estas acciones son similares a las que se toman cuando una recogida finaliza de manera natural, es
decir, que se marca la variable experimento con valor nulo y se restablecen los periodos de sueño de
los nodos. La excepción es que la fila afectada de la tabla “experimentos” pasa a tener valor 3, que
significa que el experimento está cancelado. Esto permite al usuario discernir a través de la interfaz
web que el programa efectivamente ha procesado su solicitud de manera correcta.
4.2.3 Ejecución del programa

La aplicación está diseñada para ser ejecutada en segundo plano como un servidor. No obstante, si se
desea se puede observar a través del terminal las operaciones que se llevan a cabo en el mismo. El
propósito de esto es permitir depurar errores y comprobar el estado de la red en vivo.
Figura 4.9. Aspecto del programa en un terminal Linux.
En la figura se pueden ver como los distintos mensajes se corresponden con fases ya descritas
anteriormente. Para facilitar la legibilidad se distinguen diferentes prefijos en cada línea:
 [EST] hace referencia al estado de la red. Se corresponde con la entrada del programa en el
bloque de código de mismo nombre, mostrando el resultado tras su paso por él.
 [RADIO] indica que una notificación de humedad o temperatura acaba de llegar al controlador
y se está procesando en la función de callback.
 [DET] corresponde al bloque de detección de experimentos. Refleja los cálculos de tiempo

que se han realizado para iniciar la recogida de datos, así como la solicitud de cambio de
periodo de sueño.
 [EXP] muestra mensajes relativos al desarrollo de una recogida de datos en cursos. Se

muestran las muestras tomadas y la finalización del experimento.
 [CFG] hace referencia a los procesos que se llevan a cabo en el bloque de configuración.
4.3 Interfaz web

Para esta parte ha sido necesario instalar un servidor web Apache con los módulos de PHP y
PostgreSQL. Se ha escogido PHP por ser un lenguaje idóneo para proyectos de esta envergadura,
frente a opciones como JSP que son más apropiados para páginas web de grandes dimensiones. Otra
alternativa habría sido utilizar CGI, sin embargo esto hubiera requerido de la codificación de un nuevo
programa desde el que se perdería toda la potencia de un lenguaje específicamente orientado a la web
como PHP.
Para el diseño CSS se ha utilizado la librería Bootstrap, una herramienta de software libre diseñada
por Twitter que facilita el diseño gráfico de aplicaciones y sitios web. Entre los componentes que
ofrece se encuentran formularios, botones, menús, paneles y extensiones Javascript.
La utilización de la base de datos se realiza mediante el conjunto de funciones definido en el archivo

base_datos.php. Este contiene además toda la información necesaria para realizar la conexión a la
base de datos, como el usuario y clave usado en PostgreSQL. La mayoría de ficheros de la aplicación
web hacen uso de este archivo para interactuar con la base, estando de este modo exentos de formar
una sentencia SQL y ejecutarla cada vez que se desee realizar una consulta.
Para la generación de gráficas se ha usado la librería de código abierto JpGraph, que es gratuita para
fines educativos y no comerciales [18]. Está escrita en PHP y permite la creación de multitud de
gráficas de manera muy configurable, requiriendo para su funcionamiento la instalación del módulo
GD de PHP.
A continuación se detalla el funcionamiento de cada parte.
4.3.1 Inicio
Se trata de index.php. Esta página incluye, aparte de su propio código, el código que se encuentra en
base_datos.php y control_acceso_index.php. Esta última se encarga de verificar si el usuario
ya tiene una sesión iniciada en el servidor, en cuyo caso le remite directamente a la página
principal.php, o no la tiene, para mostrarle una página de ingreso con un formulario en el que puede
introducir su usuario y clave.
Figura 4.10. Pantalla de ingreso al sistema.
Una vez ha enviado los datos, la información se contrasta con la base de datos, y si existe en la tabla
“acceso” una fila que contiene la huella MD5 de la clave remitida y el nombre de usuario, se obtiene
un resultado positivo. Esto implica que el usuario queda autorizado en el sistema, inicíandose una
sesión en la que se mantienen como variables su nombre de usuario y rol. En caso contrario, el usuario
vuelve a encontrarse con el mismo formulario de acceso, mostrándose un aviso de error.
Figura 4.11. Funcionamiento de la página de inicio.
A lo largo de toda la aplicación web, los diferentes paneles de error o información se muestran
mediante la función mostrar_alerta, que se halla en la página funciones_aviso.php. La
inclusión de este fichero en el resto de archivos que a continuación se detallan debe darse por supuesta
aun cuando no se mencione, al igual que base_datos.php.
4.3.2 Principal
La página principal.php contiene el esqueleto básico de la aplicación. Carga un menú a la izquierda

que presenta las diferentes opciones que presenta la web (en la figura marcado con la etiqueta 2), una
barra superior (etiqueta 1) y una zona con el contenido efectivo de la página (etiqueta 3).
Figura 4.12. Estructura de principal.php.
La barra superior permite volver a la página de inicio desde cualquier lugar en el que esté en el usuario,
así como cerrar la sesión en cualquier momento mediante el botón “Salir” que presenta.
El menú por otro lado permite acceder a cinco secciones:
- Nodos: da acceso a información sobre la composición de la red Z-wave y cómo insertar o

excluir nodos.
- Recoger datos: permite comenzar la recogida de valores de humedad y temperatura.
- Ver resultados: da acceso a la lista de experimentos realizados y la información que alberga

cada uno.
- Gestión de usuarios: lista y permite eliminar o crear usuarios.
- Configuración: da acceso a las opciones de apagado y reinicio de la Raspberry Pi.
Técnicamente esta página es la única que es llamada durante toda la navegación, de forma que siempre
estará presente en la URL solicitada por el usuario. La página irá insertando código de otros archivos
PHP según se indique un parámetro u otro en la URL, y con esto se consigue la apariencia de que el
usuario accede a distintas páginas. Será la zona de contenido la que se modifique dependiendo del
valor que tome el argumento de nombre “m”.
Esta estructura se ha escogido porque posee la ventaja de que el menú es el mismo en cualquier punto
de la aplicación en la que se halle el usuario. De lo contrario, cualquier ligero cambio en el menú o la
barra superior conllevaría la modificación manual de todas las páginas en las que aparecieran.
Figura 4.13. Funcionamiento de la página principal.php.
Cuando por ejemplo el usuario accede a la dirección http://IP_RASPBERRY/principal.php?m=nodos,

está solicitando que se cargue el menú y barra superior con el contenido presente en nodos.php. A
continuación se muestran los diferentes valores que puede tomar el parámetro:
Tabla 4.1. Relación de valores del parámetro “m” con el contenido cargado.
Valor del parámetro Código cargado en el contenedor Descripción del

“m” en la URL contenido
nodos.php
nodos Opción “Nodos” del
menú.
datos.php
datos Opción “Recoger datos”
del menú.
resultados.php
resultados Opción “Ver resultados”
del menú.
usuarios.php
usuarios Opción “Gestión de
usuarios” del menú.
configuracion.php
configuracion Opción “Configuración”
del menú.
resultados/mostrar_resultados.php
mostrar_resultados Muestra los resultados
de un determinado
experimento.
resultados/generar_grafica.php
generar_grafica Muestra las gráficas
asociadas a un
determinado
experimento.
resultados/seleccionar_descarga.php
seleccionar_descarga Permite descargar los
valores de una recogida
de datos.
Cualquier otro valor Ninguno, se ejecuta código de la propia página. Muestra un mensaje de
bienvenida por defecto.
Las diferentes páginas que aparecen en la tabla, a excepción de las que no están relacionadas con el
menú, cargan en la zona de contenido de principal.php una barra de pestañas en la parte superior
con los subapartados de los que hacen uso, dejando el resto del cuerpo de página vacío. Es decir, que
si por ejemplo se accede a principal.php?m=nodos, aparecerá un conjunto de pestañas con las opciones
que preste la sección de nodos.
Por otro lado, debajo de la citada barra, el resto de la página se cargará a su vez dependiendo de la
pestaña que se encuentre activa en el momento, o bien la que seleccione el usuario.
Es necesario hacer notar que bajo este esquema se han cargado dos páginas dentro de una. Por un lado,
el contenedor de principal.php está cargado mediante lo que el parámetro “m” indique, y a
continuación esta carga el código que toque dentro de sí mediante un nuevo parámetro que varía según
la sección. En el caso de los nodos este por ejemplo es “a”.
La siguiente figura muestra la estructura descrita, donde las cajas que se hallan dentro de las páginas
son los componentes cargados en ella. Las flechas indican de dónde viene el código cargado y la
leyenda “f(‘x’)” significa que el contenido es función del valor que toma el argumento “x” presente en
la URL.
Figura 4.14. Funcionamiento general de la aplicación.
Hay que destacar que se consigue una estructura jerárquica en los ficheros, de modo que todas las
páginas que están relacionadas con una opción determinada del menú se encuentran bajo un mismo
directorio y son accedidas desde un mismo archivo.
4.3.3 Sección de nodos
Como ya se ha mencionado, la página nodos.php se muestra en el contenedor principal cuando el

usuario envía una petición HTTP con el parámetro “m=nodos”. Esta página presenta un menú superior
con las diferentes opciones de la sección, distinguiéndose entre: listar nodos, modificar periodo de
sueño, insertar nodo y eliminar nodo.
Tal y como se ha explicado, de nuevo se procesa otro argumento de la URL, el parámetro “a”. Cuando
se detecta que posee un valor correspondiente a un determinado apartado, la página incluye el código
que proceda en la zona inferior al menú.
Figura 4.15. Funcionamiento de la sección de nodos.
Si suponemos que se ha cargado la opción de modificar el tiempo de sueño de los nodos, entonces la
URL tendría el siguiente aspecto: http://IP_RASPBERRY/principal.php?m=nodos&a=tiempo.
Cada una de las pestañas se detallan a continuación.
4.3.3.1 Lista de nodos
Este apartado se carga por defecto cuando el usuario pulsa en la sección de nodos del menú, o bien
cuando selecciona “Listar nodos” hallándose en otro apartado dentro de la sección de nodos.
Figura 4.16. Apartado “Listar nodos”.
La página muestra un conjunto de paneles con la visión de la red Z-wave que posee el controlador.
Esta información se recupera a través de la tabla “nodos” de la base de datos, que como recordamos,
su contenido se encarga el programa principal de actualizar según los datos de los que le provee el
controlador.
El contenido se obtiene mediante la función sql_listar_nodos() presente en base_datos.php,

para a continuación procesar las celdas de manera gráfica siguiendo el formato de Bootstrap.
4.3.3.2 Modificar periodo de sueño
Cuando el usuario pulsa en el apartado “Modificar periodo de sueño” se carga el contenido de esta
página. Su objetivo es permitir modificar el tiempo de wake-up de todos los nodos de la red,
excluyendo los nodos estáticos.
Figura 4.17. Apartado “Modificar periodo de sueño”.
Figura 4.18. Apartado “Modificar periodo de sueño” tras un envío.
Se ha permitido que el usuario modifique este parámetro porque es un valor clave a la hora de ejecutar
una recogida de datos, así como en el consumo de energía que poseen los nodos. Dado que es necesario
esperar a que todos estén despiertos para comenzar un experimento, probablemente el usuario quiera
ajustar con antelación suficiente este tiempo antes de lanzar la recogida de datos.
4.3.3.3 Insertar nodo
Consiste en la tercera página de la barra de pestañas de la sección nodos. Permite al usuario obtener
información sobre cómo realizar la inclusión de un nodo en la red Z-wave utilizando un controlador
USB de Aeotec que está conectado a la Raspberry Pi.
Figura 4.19. Apartado “Insertar nodo”.
4.3.3.4 Eliminar nodo
Es la cuarta opción del menú de pestañas. Del mismo modo que el anterior, aporta las instrucciones a
seguir para ejecutar la exclusión de un nodo que está incluido en la red.
Figura 4.20. Apartado “Eliminar nodo”.
4.3.4 Sección de recoger datos

Siguiendo con la estructura descrita, el apartado de recoger datos del menú se carga cuando en la URL
aparece el parámetro “m=datos”, estando su código en datos.php. Una vez dentro, se muestra una
barra de menú con una única opción, la de iniciar una recogida nueva.
Posteriormente datos.php carga debajo de sí el contenido de /datos/iniciar_recogida.php con

la barra de pestañas.
Figura 4.21. Aspecto habitual de la sección “Recoger datos”.
Primeramente, la página comprueba si se está ejecutando actualmente alguna recogida de datos en

curso, mediante la función sql_existe_recogida_en_curso(). Esta función devuelve verdadero
o falso en función de si existe en la tabla “experimentos” alguna fila que posea el atributo de estado a
0 ó 1 (esto es, solicitado o en curso). En caso afirmativo, se muestra una advertencia al usuario
indicando que no es posible ejecutar una recogida, dado que existe una actualmente en proceso. Si el
usuario decide parar la recogida, entonces se inserta una fila en la tabla de “configuracion”, con el fin
de que el programa principal la lea y procese la cancelación del experimento.
Figura 4.22. Aspecto de “Recoger datos” cuando hay una recogida en curso.
En otro caso, se muestra un formulario en el que se permite introducir los parámetros de

funcionamiento de la recogida de muestras. Estos son la duración de la recogida y el tiempo de
muestreo, siendo requisito que el segundo esté acotado entre 60 segundos y 24 horas, además de ser
inferior a la duración.
Cuando se envía el formulario se comprueban que los campos sean correctos y se procede a insertar
una fila en la tabla “experimentos”. Se rellena con los parámetros que ha establecido el usuario,
indicando como ya se mencionó previamente el ID del experimento como la hora UNIX actual y el
estado 0. De este modo, el programa principal leerá periódicamente la tabla y cuando detecte que existe
algún elemento solicitado (es decir, con el estado a valor 0) podrá iniciarlo.
Figura 4.23. Funcionamiento de iniciar_recogida.php.
4.3.5 Sección de visión de resultados

Constituye la sección más compleja de la página, debido a que la recogida y tratamiento de la
información obtenida de los nodos se realiza aquí. Se muestra cuando se accede a “Ver resultados” en
el menú. Esto desemboca a que se llame a la página principal mediante el argumento “m=resultados”,
que incorpora al contenedor el código que aparece en resultados.php. Este a su vez carga la barra
de pestañas y el único elemento que existe: la lista de los experimentos realizados, que se halla en
/resultados/listar.php.
Figura 4.24. Vista de la sección de lista de experimentos.
Se muestra una tabla con la lista de experimentos que existe en el sistema, apareciendo el estado de las
mismas, el usuario que las creó, la fecha de creación, la fecha de comienzo del proceso, la duración y
el muestreo. Esto se consigue mediante la lectura de la tabla “experimentos” con la función de la base
de datos sql_listar_experimentos().
Junto a cada una, aparece un conjunto de botones que permiten gestionar cada experimento, siendo
meros enlaces a otras páginas que se detallarán a continuación. Las funciones a las que dan lugar son
las siguientes:
Figura 4.25. Funciones de los botones de gestión de cada experimento.
4.3.5.1 Botón de mostrar resultados
Cuando el usuario pulsa en él, es conducido a una URL del tipo

http://IP_RASPBERRY/principal.php?m=mostrar_resultados&id_experimento=ID_EXP. Esta
página corresponde con el código que se halla en /resultados/mostrar_resultados.php, y

muestra en una tabla todas las muestras que han sido recogidas por los distintos nodos en el
experimento que se haya seleccionado.
Figura 4.26. Muestra de resultados de una determinada recogida de datos.
La página comprueba primeramente si existe algún experimento en la base de datos con el

identificador que aparece en la URL, en caso afirmativo procede a leer todas las muestras que tiene
asociado en la tabla “muestras”. En caso de que no exista el identificador o bien aún no se hayan sido
recogido muestras, se presenta un error al usuario, como en el siguiente caso:
Figura 4.27. Ausencia de resultados por URL mal formada.
4.3.5.2 Botón de generar gráficas
Este botón presenta al usuario un menú desplegable desde el que puede seleccionar el nodo reportante
con el que desea realizar las gráficas.
Figura 4.28. Menú desplegable al pulsar el botón de gráficas.
Una vez se ha seleccionado una opción, se enlaza a una dirección del tipo:
http://IP_RASPBERRY/principal.php?m=generar_grafica&id_experimento=ID_EXP&nodo=N
ODO. La aplicación se encarga de sustituir los parámetros “id_experimento” y “nodo” por los valores
adecuados lógicamente.
Figura 4.29. Funcionamiento de generar_grafica.php.
Cuando se selecciona una opción, se provoca que se cargue la página

/resultados/generar_grafica.php, que comprobará primeramente si existe el ID de
experimento dado por la URL. A continuación, en caso de que exista, se analizan los nodos que han
sido reportantes de dicha recogida, y si existe al menos una muestra que haya sido proporcionada por
el nodo dado por el parámetro “nodo”, se procede a dibujar la gráfica.
Figura 4.30. Aspecto de la página de generación de gráficas (I).
Figura 4.31. Aspecto de la página de generación de gráficas (II).
Como ya se ha comentado, se utiliza la librería JpGraph, que proporciona las gráficas en un fichero
.png. Genera dos gráficas, una para cada magnitud que miden los nodos. Así, dependiendo de si la
gráfica es de temperatura o humedad, se le pasa a JpGraph un vector con todas las muestras leídas de
la base de datos como eje de ordenadas y por último otro vector con el momento en segundos en el
que fueron tomadas para el eje de abscisas.
Se provee al usuario de la posibilidad de ajustar la frecuencia con la que desea que se muestren las
etiquetas en el eje X, dado que en simulaciones muy largas, a veces se pueden solapar.
4.3.5.3 Botón de descarga
Este botón carga el contenido de la página /resultados/seleccionar_descarga.php, que

procesará el argumento “id_experimento” presente en la URL
http://192.168.1.129/principal.php?m=seleccionar_descarga&id_experimento=ID_EXP.
En caso de que dicho identificador exista dentro de la base de datos, se obtienen todos los nodos que
han participado en el experimento, y se muestra un formulario en el que el usuario puede escoger qué
información descargar y acerca de qué nodo.
Figura 4.32. Formulario de descarga de las muestras recogidas en formato texto.
Cuando el usuario rellena correctamente el formulario, la página recorre la tabla de muestras que existe
en la base de datos y lee todos los valores de temperatura o humedad (según se haya seleccionado una
u otra) junto al instante de tiempo en el que fueron tomadas. Finalmente vuelca el contenido en un
archivo denominado muestras.txt que presenta en forma de enlace para su descarga.
Figura 4.33. Proceso de descarga del archivo con las muestras.
El archivo con las muestras se sobrescribe siempre que se demanda una descarga, de forma que
siempre se encuentra en el directorio de la aplicación web. Al usuario sólo se le muestra el enlace una
vez haya pasado por el proceso de generación de un nuevo contenido, de lo contrario estaría
descargando información correspondientes a otras muestras.
Ejemplo. Siguiendo con la simulación de la figura, si se selecciona el nodo número 6, en modo

temperatura y escala de tiempo absoluta, se tendría el siguiente contenido:
28.1 1404818364
28.1 1404818424
28.2 1404818484
28.2 1404818544
28.2 1404818604
28.1 1404818664
28.1 1404818724
28.2 1404818784
28.2 1404818844
28.3 1404818904
28.3 1404818964
28.3 1404819024
28.4 1404819084
28.4 1404819144
28.5 1404819204
4.3.5.4 Botón de borrado
Este botón llama a la propia página de lista de experimentos en la que se halla con el fin de borrar una
determinada recogida de datos. Técnicamente es un enlace a la propia página, añadiendo en la URL el
parámetro “eliminar” con un valor correspondiente al ID de experimento a borrar.
La única particularidad de este proceso es que se comprueba si el usuario que solicita el borrado es el
mismo que creó del experimento, en caso de que lo sea se elimina, en caso contrario se muestra un
error. La excepción es el administrador, que posee capacidad para purgar cualquier entrada de la lista.
Figura 4.34. Usuario “prueba” siendo incapaz de borrar un experimento ajeno.
Figura 4.35. Eliminación de la misma fila desde el usuario administrador.
En caso de que la fila que se trata de borrar esté siendo una recogida de muestras en curso, el usuario
tampoco podrá eliminarla.
4.3.6 Sección de gestión de usuarios

Esta sección del menú tiene como objetivo permitir a distintos usuarios interactuar con el sistema. De
este modo, permite proteger e identificar las distintas muestras de humedad y temperatura que un
determinado usuario ha decidido recabar sin el riesgo de que otro pueda eliminarlas.
El contenido que despliega la página se encuentra en el directorio /usuarios, habiendo tres ficheros
que corresponden a cada opción de la barra de pestañas que muestra usuarios.php:
Figura 4.36. Aspecto de “Gestión de usuarios”.
El primero de ellos es el apartado de modificar usuario, que permite cambiar la contraseña que uno
mismo posee. La página accederá a la tabla “acceso” de la base de datos y comprobará que la huella
MD5 del campo de clave antigua es la misma que la que está almacenada en la tabla, posteriormente
la cambiará por la que el usuario ha escrito en el campo de clave nueva si procede.
El segundo apartado es la lista de usuarios, que recoge los nombres de usuario que se encuentran en la
tabla “acceso”.
Figura 4.37. Lista de usuarios en el sistema.
La tercera sección se corresponde con la opción de insertar un nuevo usuario, proceso que únicamente
puede llevar a cabo el usuario que haya sido designado administrador.
Figura 4.38. Inserción de nuevo usuario.
Y por último, la opción de eliminar usuario, que se corresponde con la eliminación de tuplas en la tabla
“acceso”. Este proceso también es exclusivo del administrador.
Figura 4.39. Borrado de usuario existente en el sistema.
4.3.7 Sección de configuración

Esta sección se carga en el contenedor de principal.php cuando se pulsa en el botón de configuración.
A partir de configuracion.php aparece un menú superior en el que el usuario puede acceder a dos
opciones.
La primera de ellas se encuentra en /configuracion/reiniciar.php, y como su propio nombre

indica, permite al usuario reiniciar la Raspberry Pi mediante el formulario que presenta. La acción se
lleva a cabo mediante la ejecución del comando /sbin/reboot de terminal Linux en la función
exec() de PHP.
Figura 4.40. Aspecto de la opción de reinicio.
Una vez se ha ejercido la acción, comienza una cuenta atrás de tres minutos mediante Javascript hasta
que el sistema vuelve a estar disponible, entonces se reinicia la página.
Figura 4.41. Proceso de espera tras el reinicio.
El segundo proceso es análogo, permitiendo el apagado de la Raspberry Pi remotamente gracias al

comando /sbin/poweroff.
Figura 4.42. Apariencia de la sección que permite apagar el sistema.
Figura 4.43. Instrucciones para volver a encender la Raspberry Pi tras solicitar el apagado.
5 EJEMPLO DE APLICACIÓN
E l 10 de Julio de 2014 se llevó a cabo una prueba con el fin de comprobar el correcto
funcionamiento de todo el sistema y mostrar las posibilidades de la aplicación en un entorno real.
Durante un periodo de tres horas se procedió a la captura de muestras de humedad y temperatura cada
sesenta segundos en la sala donde se halla el jardín vertical.
Debido a que el espacio es compartido con personal laboral, el sistema de aire acondicionado se
mantuvo encendido durante todo el proceso, si bien la sala permaneció vacía durante la recogida de
datos. Esto provocó que la temperatura y humedad se vieran modificadas frente a una situación con
ambiente natural.
Los elementos escogidos para realizar el proceso fueron un controlador Aeotec Z-Stick S2 para
conectar a la Raspberry Pi y un sensor de humedad y temperatura Everspring ST814. La disposición
de los elementos fue la siguiente:
102 Ejemplo de aplicación
Figura 5.1. Disposición de elementos durante la prueba.
Para lanzar la simulación y recoger los datos fue necesario acceder a la aplicación alojada en el servidor
Apache de la Raspberry Pi, para este proceso se montó una pequeña red utilizando un router
convencional y un portátil con un navegador web instalado. El esquema de la misma es el que sigue:
Figura 5.2. Esquema de red.
Por otro lado, el nodo Z-wave se dispuso físicamente justo en el centro de la sala, entre el jardín vertical
y la pared opuesta, donde se halla un ventilador que hace circular el aire desde el exterior del edificio
hacia el interior.
Figura 5.3. Jardín vertical.
Figura 5.4. Disposición del ventilador en la pared opuesta.

5.1 Detalle de los elementos utilizados

5.1.1 Controlador USB Z-stick S2 Aeotec
Constituye un nodo controlador Z-wave que tiene alimentación incorporada gracias a una pila, un
botón y un indicador LED luminoso. Cuando se conecta a un ordenador es capaz de comunicarse
mediante la API serie de Sigma Desings, a través de la interfaz USB y gestionar hasta 232 esclavos
[6].
Figura 5.5. Aeotec Z-stick S2.
El dispositivo es capaz de operar en tres modos distintos [7]:
5.1.1.1 Modo de inclusión
Es el que permite insertar nuevos nodos en la red Z-wave, necesitando estar el dispositivo
desconectado de cualquier PC. Para ello es necesario realizar los siguientes pasos:
1. Estando desenchufado el USB, pulsar el botón. La luz comenzará a parpadear lentamente.
2. Acudir al nodo esclavo que se desea incluir y seguir los pasos del fabricante para activar la
asociación en el mismo. Una vez hecho, el controlador permanecerá con la luz LED encendida
durante tres segundos para indicar que el nodo se ha incluido.
3. La luz volverá a parpadear lentamente, si se desea seguir añadiendo esclavos, repetir el paso
2.
4. Para salir del modo una vez se ha finalizado se pulsa de nuevo el botón.
5.1.1.2 Modo de exclusion
Permite realizar la operación opuesta al proceso anterior, de forma que se eliminan de la red tantos
nodos como se quieran. Las instrucciones de uso son:
1. Estando el USB desconectado, dejar pulsado el botón durante tres segundos. El LED
parpadeará rápidamente.
2. Acudir al nodo que se desea desasociar y ejecutar los pasos que indique el fabricante para su
exclusión. La luz del USB permanecerá encendida entonces durante tres segundos.
3. Cuando la luz vuelva a parpadear de manera rápida, continuar excluyendo nodos acorde al
paso 2 si se desea.
4. Pulsar el botón para salir del modo.
5.1.1.3 Modo API serie
Este modo se ejecuta automáticamente cuando el dispositivo se conecta a un PC. Permanecerá

constantemente escuchando el canal y respondiendo a las órdenes que reciba por parte del programa
alojado en el ordenador. La pulsación del botón físico no tendrá ningún efecto sobre él.
5.1.2 Sensor Everspring ST814

Consiste en un dispositivo compatible Z-wave con capacidad para detectar la humedad y temperatura
ambientales. Tiene capacidad para establecer umbrales que servirían para enviar alertas al dispositivo
controlador, herramienta de la que no se hace uso en el presente proyecto.
Figura 5.6. Sensor Everspring ST814.
Presenta un panel indicador LED luminoso que informa sobre la temperatura y humedad actuales,
además de cuatro botones que permiten su programación in situ.
5.1.2.1 Especificaciones
El dispositivo tiene las siguientes características [8]:

Tabla 5.1. Características de Everspring ST814.
Frecuencia de operación 867.42 MHz / 908,42 MHz
Rango de operación de temperatura -10ºC – 50ºC con un decimal de precisión
Rango de operación de humedad relativa 20% - 90% sin ningún decimal
Unidades de temperatura soportadas ºC / ºF
Tipo de alimentación 3 pilas AAA de 1,5V
Distancia máxima de operación Hasta 30 metros en línea recta en interiores
Versión de SDK de Z-wave 5.02
Por otro lado, las clases de comando que soporta son las siguientes:
- COMMAND_CLASS_BASIC.
- COMMAND_CLASS_VERSION.
- COMMAND_CLASS_WAKE_UP_V2.
- COMMAND_CLASS_CONFIGURATION.
- COMMAND_CLASS_ASSOCIATION_V2.
- COMMAND_CLASS_MANUFACTURER_SPECIFIC.
- COMMAND_CLASS_SENSOR_MULTILEVEL_V2.
- COMMAND_CLASS_MULTI_INSTANCE_V2.
Como se puede apreciar, este dispositivo será compatible con la aplicación desarrollada, puesto que
implementa las clases de comando que se han utilizado en el mismo.
5.1.2.2 Inclusión y exclusión del dispositivo.
El fabricante establece que la tecla de función marcada con “Cº Fº” es la que hay que utilizar para
añadir y eliminar el nodo de la red Z-wave. En cualquiera de los dos casos, es necesario pulsarla tres
veces dentro de un periodo de 1,5 segundos para entrar en el modo de inclusión/exclusión, de modo
que la acción que se lleve a cabo será la que se haya decidido en el controlador. Esto significa que si
se tiene el controlador de Aeotec en modo exclusión y se pulsa tres veces esta tecla, el sensor
Everspring se eliminará de la red.
El nodo también permite realizar un restablecimiento total de sus parámetros, esto se consigue
accediendo al modo inclusión/exclusión y a continuación pulsando la tecla “Cº Fº” de nuevo hasta que
suene una señal sonora.
En cualquier caso, es posible verificar físicamente en el nodo si se encuentra asociado a una red Z-
wave o no. Para ello se navega a través de los menús hasta acceder a una sección en la que se indica
con dos dígitos el HomeID de la red a la que está unido. Si este valor aparece a cero (es decir “00” en
la pantalla), significa que aún no se ha realizado ninguna inclusión.
5.1.2.3 Periodo de sueño
El sensor permanece en estado latente la mayoría del tiempo, y de igual forma a como hace un nodo
portátil genérico Z-wave ya descrito, se despierta periódicamente. El tiempo que permanece despierto
son diez segundos, lo que significa que si durante este periodo comunica con el controlador y no hay
ningún mensaje para él, vuelve a dormir. En caso de que sí exista, alarga el tiempo otros diez segundos.
Independientemente del tiempo de wake-up del nodo, es posible forzar que se despierte y contacte con
el controlador pulsando tres veces el botón “Cº Fº”, tal y como se haría para entrar en el modo
inclusión/exclusión.
Por otro lado, el tiempo que permanece dormido es lógicamente configurable en el nodo, se pueden
seleccionar valores que se encuentren en el intervalo de 60 segundos a 4660 horas (194 días).
5.2 Resultados obtenidos

Tras trascurrir el periodo de tres horas programado, la aplicación web muestra el aviso de que la
recogida de datos ha concluido satisfactoriamente:
Figura 5.7. Finalización de la prueba en la aplicación web.
Es necesario indicar que las horas de creación e inicio del experimento son incorrectas porque
Raspberry Pi no contiene ningún sistema que le permita almacenar y llevar la cuenta de la hora cuando
no tiene alimentación eléctrica, necesitando recuperarla cada vez que arranca de manera manual o bien
a través de un servidor de tiempo NTP preestablecido de Internet.
El listado completo de las muestras recabadas a lo largo de toda la recogida se ignora aquí por
simplicidad, pero las gráficas generadas a partir de ellas son:
Figura 5.8. Gráfica de temperatura frente a tiempo (s) de la prueba.
Figura 5.9. Gráfica de humedad frente a tiempo (s) de la prueba.

6 LÍNEAS FUTURAS DE DESARROLLO Y

CONCLUSIONES
L a aplicación desarrollada tiene como objetivo la instalación sobre la marcha de una red de
sensores de humedad y temperatura para la recogida de datos en el momento. Sin embargo, la
disposición permanente de esos nodos en la sala del jardín vertical permitiría el desarrollo de nuevas
características y ventajas a los usuarios de la misma.
En esa situación, un aspecto interesante a incorporar dentro de la aplicación consistiría en añadir la

capacidad de activar o desactivar el aire acondicionado o calefacción mediante el ajuste por modelos
de confort térmico. Con ello conseguiríamos mejorar las condiciones de los trabajadores que
permanecen en la sala durante las horas laborales, e incluso prepararla con antelación antes de su
llegada. Para este objetivo sería necesario añadir soporte vía Raspberry Pi al control electrónico del
sistema de climatización de la sala, para posteriormente actuar sobre él en función de las condiciones
110 Líneas futuras de desarrollo y conclusiones
de humedad y temperatura que reporten los nodos dispuestos a lo largo de ella.
En cuanto a la mejora en su propósito inicial de recopilación de muestras para su estudio, podría

introducirse la capacidad de medir otras magnitudes que afectan o están relacionadas con las
condiciones ambientales de la sala. Existen dispositivos Z-wave que son capaces de medir el nivel de
dióxido de carbono ambiental, así como la cantidad lumínica que recibe el jardín vertical. Esto
permitiría cuantificar la variación de este gas en la sala debido a la convivencia del jardín y el personal
laboral.
Mediante la inclusión de nodos en el exterior de la sala, se conseguiría cuantificar analíticamente el

impacto que ejerce el jardín en función de las condiciones exteriores. Y si además se recogen muestras
en otra sala anexa que no esté bajo las influencias de él, el análisis sería más completo, al poder
realizarse una comparativa en función de las condiciones del exterior frente a la evolución interna con
y sin jardín presente.
Llegados a ese punto, una integración más profunda con las herramientas que utilizan los
investigadores tendría sentido, frente a los ficheros de texto plano que se ofrecen ahora. La adaptación
de la información y su procesado mediante Matlab no supondrían un coste desmesurado, y
especialmente en condiciones más complejas como las descritas anteriormente, sería deseable.
Respecto a la realización del proyecto, la parte más costosa la ha constituido el acceso y control de la
red Z-wave desde el ordenador Raspberry Pi. Partiendo de que no existe mucha documentación sobre
esta tecnología, la situación se ha visto complicada porque la librería OpenZWave escogida está aún
en fase de desarrollo, presentando con ello la ausencia de programas de ejemplo que faciliten su uso.
7 REFERENCIAS
[1] V. d. I. -. U. d. Sevilla., «La Universidad de Sevilla cuenta ya con el primer jardín vertical
activo de Europa.,» [En línea]. Disponible en: http://investigacion.us.es/noticias/239.
[2] T. S. Olivera, PFC - Aplicaciones de redes inalámbricas de sensores para control y

certificación de condiciones ambientales, 2009.
[3] «Wikipedia,» [En línea]. Disponible en: http://www.wikipedia.org/.
[4] B. Horan, Practical Raspberry Pi, Apress, 2013.
[5] ARM, «Information Center,» [En línea]. Disponible en: http://infocenter.arm.com/.
[6] E. Linux, «RPi Distributions,» [En línea]. Disponible en: http://elinux.org/RPi_Distributions.
[7] Raspbian, «FAQ,» [En línea]. Disponible en: http://www.raspbian.org/RaspbianFAQ.
[8] R. P. Foundation, «Downloads,» [En línea]. Disponible en:

http://www.raspberrypi.org/downloads/.
[9] R. L. Álvarez, PFC - Análisis e implementación de un sistema domótico Z-wave.
[10] Z-wave, «Z-wave Technical Basics,» [En línea]. Disponible en:

https://www.domotiga.nl/attachments/download/1075/Z-Wave%20Technical%20Basics-
small.pdf.
[11] Zensys, «Z-wave protocol overview,» [En línea]. Disponible en:

http://wiki.ase.tut.fi/courseWiki/images/9/94/SDS10243_2_Z_Wave_Protocol_Overview.pdf.
112 Referencias
[12] Z-wave, «Developer Kit,» [En línea]. Disponible en: http://z-

wave.sigmadesigns.com/docs/brochures/Z-Wave_Dev_Kit_br.pdf.
[13] E. electronics, «Z-wave 500 series Dev Kit,» [En línea]. Disponible en:
http://www.edgeelectronics.com/z-wave-dev-kit.asp.
[14] Z-Way, «Z-Way Developers Documentation,» [En línea]. Disponible en: http://razberry.z-
wave.me/docs/zway.pdf.
[15] Razberry, «Hardware overview,» [En línea]. Disponible en: http://razberry.z-

wave.me/index.php?id=9.
[16] OpenZWave, «OpenZWave Introduction,» [En línea]. Disponible en:

http://www.openzwave.com/dev/.
[17] OpenZWave, «Reference: Manager Class,» [En línea]. Disponible en:

http://www.openzwave.com/dev/classOpenZWave_1_1Manager.html#details.
[18] JpGraph, «Download,» [En línea]. Disponible en: http://jpgraph.net/download/.
[19] Aeotec, «Aeotec - Z-stick,» [En línea]. Disponible en: http://aeotec.com/z-wave-usb-stick.
[20] Aeotec, Manual de usuario de Aeon Labs Z-Stick Series 2.
[21] Everspring, Manual de usuario de Everspring ST814.

113

TFG - Daniel Sierra SolÃ S

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TFG - Daniel Sierra SolÃ S

Transféré par

Droits d'auteur :

Formats disponibles

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías de Telecomunicación

Implementación de interfaz Z-wave para Raspberry

Autor: Daniel Sierra Solís

Tutor: José María Maestre Torreblanca

Dep. de Ingeniería de Sistemas y Automática

Implementación de interfaz Z-wave para Raspberry

Daniel Sierra Solís

José María Maestre Torreblanca

Departamento de Ingeniería de Sistemas y Automática

Escuela Técnica Superior de Ingeniería

Índice de Figuras xiii

5 Ejemplo de aplicación 101

6 Líneas futuras de desarrollo y conclusiones 109

Tabla 1.1. Funciones de los LEDs de una Raspbery Pi. 24

Tabla 2.1. Compatibilidad de controladores USB con OpenZWave. 51

Tabla 2.2. Tipos de valores ValueID. 54

Tabla 2.3. Algunos valores del campo NotificationType de la clase Notification. 56

Tabla 4.1. Características de Everspring ST814. 106

Figura 2.1. Distintivo identificativo de Raspberry Pi. 19

Figura 2.2. Identificación de elementos en una Raspbperry Pi modelo B. 20

Figura 2.3. Raspberry Pi conectada a una cámara mediante el puerto CSI-2. 22

Figura 2.4. Diagrama de componentes de ARM1176JZF-S [4]. 25

Figura 2.5. Diagrama de flujo de etapas de instrucción en la CPU de un ARM11 [4]. 26

Figura 2.6. Ejemplo de integrados conectados mediante packe-on-package. 27

Figura 2.7. Versiones de Debian en Raspberry Pi. 30

Figura 2.8 Instalación de Linux mediante NOOBS. 31

Figura 2.9. Secuencia de arranque de Raspberry Pi. 32

Figura 3.1. Torre de protocolos de Z-wave. 36

Figura 3.2. Formato de trama MAC utilizado en Z-Wave [11]. 37

Figura 3.3. Formato de trama de nivel de transporte en Z-wave [11]. 37

Figura 3.4. Ejemplo de envío de trama dirigida en Z-wave [11]. 38

Figura 3.5. Ejemplo de envío de trama multicast en Z-wave [11]. 38

Figura 3.6. Ejemplo de envío en difusión en Z-wave [11]. 39

Figura 3.7. Formato de mensaje con comandos Z-wave [11]. 40

Figura 3.8. Controlador estático Vera 3. 43

Figura 3.9. Controlador portátil modelo Z-URC. 43

Figura 3.10. Parte del kit básico de desarrollo de Z-wave [13]. 47

Figura 3.12. Estructura de funcionamiento de un sistema con Z-Way. 49

Figura 3.14. Secuencia de llegada de notificaciones en OpenZWave. 56

Figura 4.1. Estructura general de la aplicación desarrollada. 60

Figura 4.2. Diagrama E-R de la base de datos. 66

Figura 4.3. Representación de un nodo de la red en el programa. 68

Figura 4.4. Representación de la lista de nodos en el programa principal. 68

Figura 4.5. Llegada de una notificación de cambio de valor en un nodo. 70

Figura 4.6. Actualización de la tabla “acceso” en el bloque de estado de la red. 71

Figura 4.7. Cálculo del comienzo de la recogida. 73

Figura 4.9. Aspecto del programa en un terminal Linux. 75

Figura 4.10. Pantalla de ingreso al sistema. 77

Figura 4.11. Funcionamiento de la página de inicio. 78

Figura 4.12. Estructura de principal.php. 79

Figura 4.13. Funcionamiento de la página principal.php. 80

Figura 4.14. Funcionamiento general de la aplicación. 82

Figura 4.15. Funcionamiento de la sección de nodos. 83

Figura 4.16. Apartado “Listar nodos”. 84

Figura 4.17. Apartado “Modificar periodo de sueño”. 85

Figura 4.18. Apartado “Modificar periodo de sueño” tras un envío. 85

Figura 4.20. Apartado “Eliminar nodo”. 87

Figura 4.21. Aspecto habitual de la sección “Recoger datos”. 88

Figura 4.23. Funcionamiento de iniciar_recogida.php. 89

Figura 4.24. Vista de la sección de lista de experimentos. 90

Figura 4.25. Funciones de los botones de gestión de cada experimento. 90

Figura 4.26. Muestra de resultados de una determinada recogida de datos. 91