RaspBerry Pi como sistema de control domótico

Por Juan Angosto Herrmann
Web Developer de OpenSistemas

En el post anterior, traté de presentar un dispositivo que dio lugar a un concepto nuevo de ordenadores capaces de dar servicios cotidianos con un rendimiento aceptable y a muy bajo coste. Este producto, llamado Raspberry Pi (RbP), es el protagonista de un proyecto, llevado a cabo junto a un compañero, que consiste en un sistema distribuido de control de variables ambientales para una vivienda, es decir, un sistema domótico. Uno de los objetivos definidos, es que el usuario pueda controlar cualquier parte de su casa mediante una interfaz web, evitando así la necesidad de instalar una aplicación especifica para este propósito.

En esta publicación intentaré exponer un problema que se presentó a la hora de desarrollar el módulo que controla la iluminación. Se trata de un simple slider que el usuario puede mover de manera libre, y, a tiempo real variar la intensidad lumínica. Pero antes de nada voy a describir un poco la estructura del sistema.

Los elementos de la vivienda que van a permitir fijar las variables ambientales, llamadas “plantas” en el mundo de los sistemas de control (luminarias, calefacción, persianas, alarmas, …), son controlados por dispositivos diseñados y montados por nosotros, que consisten en un microcontrolador de la familia 80C51 y todo lo necesario para hacerlo funcionar. Estas placas disponen de un módulo XBee, para permitir una comunicación inalámbrica entre ellas. Otro elemento que entra en este grupo de conversaciones wireless es nuestro amigo RbP, que dispone también del mismo módulo de comunicación y hace de cerebro en el sistema global, enviando las órdenes adecuadas para que la casa esté en todo momento en las condiciones deseadas por el usuario. Este último, puede “configurar” su casa gracias a una interfaz web servida por un apache alojado en el RbP.

Las plantas que entran en juego en la intensidad de la luz son tiras de LEDs instaladas en cada una de las habitaciones de la casa. El usuario puede variar esta intensidad moviendo un elemento de la interfaz que envía una petición Ajax al servidor (el RbP) para que este mande la orden “enciende la luz a esta potencia” al controlador correspondiente. Y aquí empieza nuestro problema.

Puesto que queremos que la luz varíe a tiempo real, por cada paso que da el usuario en el control de intensidad, tenemos que enviar un mensaje por medio de Ajax al servidor, unos 100 mensajes por segundo de media dependiendo de la velocidad a la que la persona mueva el dimmer. El problema es que Apache tarda un tiempo comprendido entre unos 4 y 200 milisegundos en contestar. Un margen demasiado grande y un tiempo inaceptable para este tipo de funcionalidad. La consecuencia de esto es que la luz varía a trompicones debido a la pérdida de mensajes que Apache no es capaz de procesar.

Una solución sería que en vez de enviar un mensaje por cada paso del control, se envíe por cada 5 o 10, reduciendo así la cantidad de peticiones por segundo. Esto provoca una baja resolución en la variación de la luz y no queda tan bonito a la hora de utilizarlo. Por tanto lo único que nos queda es saltarnos Apache a la hora de enviar mensajes desde la interfaz. Para ello, hemos implementado un demonio en C que crea un socket en un puerto del servidor y que escucha continuamente en él para recoger los mensajes que entren. Este método toma las peticiones en un margen de tiempo comprendido entre 0 y 1 milisegundo, unos valores enormemente positivos. En este punto, lo único que debemos hacer es enviar los mensaje por medio de Ajax al puerto donde hayamos creado el socket.

La conclusión extraída en esta parte del desarrollo es que cada cosa sirve para lo que ha sido desarrollada, no se puede contar con un servidor web para hacer funcionalidades que disponen de margenes críticos de tiempo.

No quiero despedirme sin antes dar las gracias a Iván Garrido y a Adrián Boubeta por las ideas aportadas en la mejora de esta parte del proyecto.