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

n el año 2011, investigadores de la Universidad de Sevilla instalaron en la Escuela Técnica E 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.

19 Implementación de interfaz Z-wave para Raspberry 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

21 Implementación de interfaz Z-wave para Raspberry 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.

23 Implementación de interfaz Z-wave para Raspberry 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.

25 Implementación de interfaz Z-wave para Raspberry 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.

27 Implementación de interfaz Z-wave para Raspberry

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.

29 Implementación de interfaz Z-wave para Raspberry  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

31 Implementación de interfaz Z-wave para Raspberry - 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.

33 Implementación de interfaz Z-wave para Raspberry 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, …

35 Implementación de interfaz Z-wave para Raspberry 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.

37 Implementación de interfaz Z-wave para Raspberry

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.

39 Implementación de interfaz Z-wave para Raspberry

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.

41 Implementación de interfaz Z-wave para Raspberry 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.

43 Implementación de interfaz Z-wave para Raspberry

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

45 Implementación de interfaz Z-wave para Raspberry 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.

47 Implementación de interfaz Z-wave para Raspberry 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

49 Implementación de interfaz Z-wave para Raspberry 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].

51 Implementación de interfaz Z-wave para Raspberry

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.

53 Implementación de interfaz Z-wave para Raspberry 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 enumeradoValueType_Bool 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

55 Implementación de interfaz Z-wave para Raspberry 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

57 Implementación de interfaz Z-wave para Raspberry 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.

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.

routing="false" max_baud_rate="40000" version="3" query_stage="Complete">

after_mark="true" create_vars="true">

label="Basic" units="" read_only="false" write_only="false"

verify_changes="false" poll_intensity="0" min="0" max="255"

value=""/>

59 Implementación de interfaz Z-wave para Raspberry

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:

config="2gig/ct100.xml"/>

...

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.

61 Implementación de interfaz Z-wave para Raspberry 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

62 Aplicación desarrollada

“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

63 Implementación de interfaz Z-wave para Raspberry 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

64 Aplicación desarrollada

------+------+------+------+------+------

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

65 Implementación de interfaz Z-wave para Raspberry 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.

66 Aplicación desarrollada

- 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

67 Implementación de interfaz Z-wave para Raspberry 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.

68 Aplicación desarrollada

- 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 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.

69 Implementación de interfaz Z-wave para Raspberry 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.

70 Aplicación desarrollada

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

71 Implementación de interfaz Z-wave para Raspberry 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.

72 Aplicación desarrollada

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.

73 Implementación de interfaz Z-wave para Raspberry

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

74 Aplicación desarrollada 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

75 Implementación de interfaz Z-wave para Raspberry 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:

76 Aplicación desarrollada

 [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

77 Implementación de interfaz Z-wave para Raspberry 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.

78 Aplicación desarrollada

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).

79 Implementación de interfaz Z-wave para Raspberry

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

80 Aplicación desarrollada

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

81 Implementación de interfaz Z-wave para Raspberry 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.

82 Aplicación desarrollada

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.

83 Implementación de interfaz Z-wave para Raspberry 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.

84 Aplicación desarrollada

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.

85 Implementación de interfaz Z-wave para Raspberry

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.

86 Aplicación desarrollada

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.

87 Implementación de interfaz Z-wave para Raspberry

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.

88 Aplicación desarrollada

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.

89 Implementación de interfaz Z-wave para Raspberry 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.

90 Aplicación desarrollada

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

91 Implementación de interfaz Z-wave para Raspberry 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

92 Aplicación desarrollada 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.

93 Implementación de interfaz Z-wave para Raspberry

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

94 Aplicación desarrollada 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.

95 Implementación de interfaz Z-wave para Raspberry

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

96 Aplicación desarrollada

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:

97 Implementación de interfaz Z-wave para Raspberry

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.

98 Aplicación desarrollada

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.

99 Implementación de interfaz Z-wave para Raspberry

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.

100 Aplicación desarrollada

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.

101 Implementación de interfaz Z-wave para Raspberry 5 EJEMPLO DE APLICACIÓN

l 10 de Julio de 2014 se llevó a cabo una prueba con el fin de comprobar el correcto E 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.

103 Implementación de interfaz Z-wave para Raspberry

Figura 5.3. Jardín vertical.

Figura 5.4. Disposición del ventilador en la pared opuesta.

104 Ejemplo de aplicación

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:

105 Implementación de interfaz Z-wave para Raspberry 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]:

106 Ejemplo de aplicación

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

107 Implementación de interfaz Z-wave para Raspberry 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

108 Ejemplo de aplicación

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.

109 Implementación de interfaz Z-wave para Raspberry 6 LÍNEAS FUTURAS DE DESARROLLO Y

CONCLUSIONES

a aplicación desarrollada tiene como objetivo la instalación sobre la marcha de una red de L 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.

111 Implementación de interfaz Z-wave para Raspberry 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