Repositorio Institucional de Documentos

! Proyecto!Fin!de!Carrera! ! ! Estudio!de!una!aplicación!domótica! para!la!gestión!de!una!vivienda!vía! satélite! ! Autor! ! Alexandra!Ubau!Rubio! ! ! ! Director! ! JeanAClaude!Patalano! ! Ponente! ! Jesús!Alastruey!Benedé! ! ! Escuela!de!Ingeniería!y!Arquitectura! ! Zaragoza,!Febrero!de!2014! Agradecimientos A Jean-Claude Patalano, a todo el departamento de RF/AR del CNES y a Jesús Alastruey Benedé por su ayuda, seguimiento y dedicación durante el desarrollo del proyecto. A mi familia, especialmente a mis padres y a mi hermana por estar a mi lado en los momentos más difíciles a lo largo de todos estos años. A mis amigos y compañeros de carrera por acompañarme durante todo este tiempo lleno de buenos y no tan buenos momentos. Resumen La proliferación de dispositivos tecnológicos para el hogar y su rápida evolución ha aumentado el interés de conectar todos ellos en red para integrarlos en un sistema de monitorización y control y poder gestionarlos de forma centralizada. En este trabajo se estudia el control de una vivienda desde cualquier parte del mundo. En este contexto, el organismo gubernamental francés CNES (Centro Nacional de Estudios Espaciales), encargado del desarrollo espacial en Francia, propone el estudio del envío de la información necesaria para la gestión de una vivienda a través del enlace vía satélite. Es evidente que no se trata del medio óptimo para ello, pero hay casos en los que, aunque el retardo sea elevado, lo verdaderamente importante es que exista la posibilidad de comunicarse, siendo éste el objetivo último de los estudios que se realizan dentro del departamento de Radiofrecuencias y Aplicaciones Telemáticas en el que tuvo lugar mi estancia en dicha empresa. El objetivo del proyecto es la puesta en marcha de una plataforma de pruebas compuesta por sensores, accionadores y dispositivos de control conectados a una red de manera que puedan ser controlados mediante un protocolo domótico y el posterior estudio de la viabilidad del satélite como medio de transmisión. Para ello se estudiaron diferentes protocolos domóticos existentes en el mercado y se seleccionó uno adecuado para nuestro caso. Puesto que no se disponía de equipos domóticos reales, se eligieron una serie de dispositivos no domóticos (Arduino, indicadores luminosos, pulsadores,…) que fueron usados para establecer nuestra plataforma de pruebas. El siguiente paso fue la elaboración de diversos subsistemas que nos permitieron ir aumentando progresivamente en complejidad hasta llegar al sistema en el que quedaba establecida la red domótica. Y finalmente se llevo a cabo el escenario final en el que se integraba el satélite como medio de transmisión. Durante este proyecto se han utilizado diversas plataformas y herramientas hardware y software como Arduino, para crear los periféricos domóticos necesarios, LabVIEW para simplificar la programación de las placas Arduino, Python, para crear menús interactivos para manejar dichas placas, Wireshark, para el análisis de los paquetes transmitidos a través de las redes y Netdisturb para simular las perturbaciones debidas al tránsito de la información a través del satélite. Se trata de un proyecto que fue propuesto como el inicio de un largo estudio y se prevé que sea finalizado gracias a posteriores colaboraciones. Con dicho proyecto realizado durante mi estancia en el CNES, queda cubierto el objetivo inicial de establecer las bases para poder llevar a cabo este gran estudio. vii Índice Tabla de Figuras ............................................................................................... ix Lista de acrónimos y abreviaciones ............................................................... xi Capítulo 1. Introducción ................................................................................... 1 1.1 Contexto del proyecto y motivación .................................................... 1 1.2 Objetivos ................................................................................................ 2 1.3 Organización del documento ............................................................... 2 Capítulo 2. Estado del arte ............................................................................... 5 2.1 Los soportes de transmisión .................................................................. 5 2.1.1 Por cable ............................................................................................. 5 2.1.2 Inalámbricas ........................................................................................ 5 2.2 Tecnologías de transmisión y normas .................................................. 6 2.2.1 KNX ..................................................................................................... 6 2.2.2 X10 ...................................................................................................... 6 2.2.3 EHS ..................................................................................................... 6 2.2.4 X2D ..................................................................................................... 7 2.2.5 Z-Wave ................................................................................................ 7 2.2.6 OpenWebNet ...................................................................................... 7 2.2.7 xPL ...................................................................................................... 7 Capítulo 3. Protocolo xPL ................................................................................. 9 3.1 Definición del protocolo .......................................................................... 9 3.2 Funcionamiento del protocolo ............................................................... 9 3.2.1 Interfaces (Gateways) ....................................................................... 10 3.2.2 Aplicaciones de estadística y de seguimiento ................................... 10 3.2.3 Aplicaciones de control ..................................................................... 11 3.2.4 Hub xPL ............................................................................................ 11 3.3 Aspectos técnicos ................................................................................. 11 3.4 Portabilidad ............................................................................................ 11 3.5 Mensajes ................................................................................................. 11 Capítulo 4. Herramientas ................................................................................ 13 4.1 Arduino ................................................................................................... 13 4.1.1 Introducción ....................................................................................... 13 4.1.2 Arduino Ethernet Shield .................................................................... 13 4.1.3 Tinkerkit ............................................................................................. 14 4.2 LabVIEW ................................................................................................. 14 4.3 Python ..................................................................................................... 15 4.4 Wireshark ............................................................................................... 15 4.5 Netdisturb ............................................................................................... 16 Capítulo 5. Trabajo experimental y resultados ............................................. 17 5.1 Subsistema 0. LabVIEW ........................................................................ 17 5.1.1 Diagrama de bloques ........................................................................ 18 viii 5.1.2 Panel frontal ...................................................................................... 18 5.2 Subsistema 1. Pulsador - Led ............................................................... 19 5.2.1 Funcionamiento ................................................................................. 19 5.3 Subsistema 2. Arduino y Ethernet ....................................................... 20 5.3.1 Ethernet 1. Construcción de una red local ........................................ 20 5.3.2 Ethernet 2. Cliente - Servidor ............................................................ 21 5.4 Subsistema 3. Interactuar gracias a Python ....................................... 21 5.5 Subsistema 4. Creación de una red LAN añadiendo un segundo servidor ......................................................................................................... 21 5.6 Subsistema 5. Uso de una tarjeta de memoria microSD ................... 22 5.7 Sistema domótico. Protocolo domótico xPL ...................................... 22 5.7.1 Envío de paquetes “heartbeat” .......................................................... 22 5.7.2 Establecer una red xPL con las placas Arduino ................................ 23 5.7.3 Seguimiento de la red xPL à xPLHal ............................................... 24 5.8 Escenario final. Envío de la información vía satélite ......................... 26 Capítulo 6. Conclusiones ............................................................................... 31 Bibliografía ....................................................................................................... 33 Anexos ............................................................................................................. 35 Anexo I. Descripción detallada Arduino ....................................................... 37 Descripción .................................................................................................. 37 Tabla de características ............................................................................. 37 Alimentación ............................................................................................... 37 Memoria ..................................................................................................... 38 Entrada y salida ......................................................................................... 38 Comunicación .............................................................................................. 39 Entorno Arduino .......................................................................................... 39 Bibliotecas .................................................................................................... 40 Monitor serie ................................................................................................ 40 Anexo II. Pulsador - Led ................................................................................. 41 Código del microcontrolador Arduino emisor .......................................... 41 Código del microcontrolador Arduino receptor ....................................... 42 Anexo III. Servidor - Cliente ............................................................................ 43 Código Arduino - Ethernet .......................................................................... 44 Anexo IV. Interactuar gracias a Python ......................................................... 49 Código servidor (placa Arduino) ................................................................ 50 Código Cliente (ordenador) ........................................................................ 51 Anexo V. Creación de una red LAN añadiendo un segundo servidor ....... 53 Servidor 1 ..................................................................................................... 53 Servidor 2 ..................................................................................................... 54 Menú Python ................................................................................................ 55 Anexo VI. Uso de una tarjeta de memoria microSD ..................................... 57 Código microSD lectura/escritura .............................................................. 57 Anexo VII. Protocolo domótico xPL .............................................................. 61 Código xPL Arduino emisor ....................................................................... 64 Código xPL Arduino analizador ................................................................. 66 ix Tabla de Figuras Figura 1. Esquema .......................................................................................... 1 Figura 2. Esquema ejemplo de una red xPL ................................................. 10 Figura 3. Mensaje del tipo comando ............................................................. 12 Figura 4. Vista frontal Arduino Ethernet ........................................................ 14 Figura 5. Vista posterior Arduino Ethernet .................................................... 14 Figura 6. Placa y módulos Tinkerkit .............................................................. 14 Figura 7. Esquema de funcionamiento de Netdisturb ................................... 16 Figura 8. Diagrama gráfico LabVIEW ............................................................ 18 Figura 9. Panel frontal asociado al diagrama ................................................ 18 Figura 10. Esquema Pulsador-Led ................................................................ 19 Figura 11. Situación inicial ............................................................................ 20 Figura 12. Pulsado del interruptor ................................................................. 20 Figura 13. Red xPL final ................................................................................ 24 Figura 14. Monitor xPL .................................................................................. 24 Figura 15. Esquema pila OSI ........................................................................ 25 Figura 16. Esquema satelital ......................................................................... 26 Figura 17. Simulación del envío por satélite con NetDisturb ......................... 27 Figura 18. Ping a las placas Arduino para verificar el retraso introducido con NetDisturb ..................................................................................................... 28 Figura 19. Port forwarding de las placas Arduino ......................................... 29 Figura 20. Toma de alimentación externa ..................................................... 37 Figura 21. Pines de alimentación .................................................................. 38 Figura 22. Lector microSD ............................................................................ 38 Figura 23. Pines de entrada y salida ............................................................. 38 Figura 24. Entorno Arduino ........................................................................... 39 Figura 25. Navegador Firefox establecido como cliente ............................... 43 Figura 26. Verificación del proceso del programa ......................................... 43 Figura 27. Menú creado con Python para interactuar con la placa Arduino . 49 Figura 28. Monitor serie que muestra la correcta recepción de datos .......... 49 Figura 29. Creación y lectura de un fichero de texto ..................................... 57 Figura 30. Definición del contenido de los paquetes enviados por la placa Arduino .......................................................................................................... 61 Figura 31. Aplicaciones xPL .......................................................................... 61 Figura 32. Creación y envío de un mensaje xPL .......................................... 62 Figura 33. Captura del paquete que muestra el correcto funcionamiento del protocolo xPL ........................................................................................... 62 2 Este proyecto surge en el departamento RF/AR (Departamento de Radiofrecuencias y Aplicaciones Telemáticas) del organismo gubernamental francés a cargo del desarrollo espacial nacional, CNES. En dicho departamento, sea cual sea la materia o el tema a tratar en cada uno de sus proyectos, se elige siempre el satélite como medio de transmisión, puesto que su misión es buscar nuevas aplicaciones de tecnología espacial, hecho que es posible gracias al acceso que tienen a los satélites y la parte del ancho de banda que se reserva de estos para las pruebas y estudios pertinentes. Por tanto, aunque a priori el uso del satélite como medio de trasporte para enviar la información necesaria para el manejo y control de un sistema domótico no sea el más eficaz, debido a su gran coste y a otros factores como la necesidad de instalar antenas para recibir la señal, su gran retardo… en este caso, prima la posibilidad de comunicarse aunque no sea el medio óptimo, siendo esta la razón por la cual se propuso este proyecto. En nuestro caso más concreto, el objetivo podría ser reducir la conocida brecha digital que existe en la región de Aragón, sobre todo por la presencia de los Pirineos y cuya solución se basa en dos grandes alternativas: las conexiones inalámbricas (WiMax) o las conexiones vía satélite. 1.2 Objetivos Los objetivos principales del proyecto son verificar la capacidad del satélite y la viabilidad o los posibles problemas e impedimentos a la hora de transmitir la información necesaria para el funcionamiento de una casa "inteligente", identificar nuevas aplicaciones posibles gracias a las características de las comunicaciones vía satélite y validar el principio. Para lograr estos objetivos, las tareas propuestas fueron: • Identificar las áreas de aplicación en domótica para las cuales el satélite puede ser utilizado. • Estudiar el estado del arte de los distintos sistemas, dispositivos, redes y protocolos domóticos existentes en el mercado. • Diseñar una plataforma de pruebas compuesta por sensores, actuadores, dispositivos de control y redes controladas domóticamente que podrían insertarse en el segmento satelital. • Desarrollar las pruebas y ensayos, análisis, extracción y síntesis de los resultados obtenidos. • Analizar y obtener las conclusiones de los resultados obtenidos. 1.3 Organización del documento El documento está organizado de la siguiente forma: • El primer capítulo está dedicado a la introducción del documento. • El segundo capítulo se centra en el estudio del estado del arte. 3 • El tercer capítulo está centrado en la definición y explicación del protocolo xPL, elegido para el desarrollo de este proyecto. • En el cuarto capítulo se describen todas las herramientas y programas utilizados para la puesta en marcha del proyecto. • El quinto apartado se centra en el trabajo experimental realizado durante los seis meses que duró mi estancia en el CNES, el cual se ha dividido en diferentes subsistemas hasta llegar al escenario final. También se exponen en este apartado los resultados correspondientes. • En el sexto capítulo se exponen las conclusiones que se obtienen después de la finalización del proyecto. • Y la séptima y última parte está compuesta por los anexos que amplían detalles sobre los contenidos del documento principal. 5 Capítulo 2. Estado del arte La rápida aparición y evolución de las redes domésticas ha causado la creación de un cierto número de tecnologías y de protocolos, algunos de utilización específica en el hogar y otros heredados de la industria. En un primer momento, las entidades intentaban imponer sus propias iniciativas bus, pero más tarde se vieron obligadas a crear protocolos estandarizados para facilitar la introducción en el mercado de los productos domóticos. Fue a partir de entonces, cuando empezaron a surgir protocolos y normas domóticas como KNX, X10, EHS, X2D, Z-Wave, Openwebnet, xPL… En el presente capítulo presentaremos los diferentes tipos de tecnologías utilizadas en las comunicaciones y los soportes físicos apropiados para el uso en viviendas. 2.1 Los soportes de transmisión El transporte de la información necesita de un medio de transmisión, que puede ser físico (por cable) o por aire (inalámbrico). 2.1.1 Por cable • Coaxial: transmisión de señales eléctricas a alta frecuencia. • Par cruzado: conexión en la que dos conductores son entrelazados para tener menos interferencias, aumentar la potencia y limitar la diafonía entre cables adyacentes. • Fibra óptica: generalmente utilizadas en redes de datos, la información es enviada en forma de impulsos luminosos. • PLC (Power Line Communications): para las tecnologías que utilizan las líneas eléctricas clásicas para transmitir datos con el objetivo de comunicar. 2.1.2 Inalámbricas • Wi-Fi: envío de datos que utilizan las ondas radio. • GPRS (General Packet Radio Service): extensión de Global System for Mobile Communications o GSM, para la gestión del envío de paquetes. • Bluetooth: especificación industrial para redes inalámbricas WPAN que permite la transmisión a distancias cortas de la voz y de datos entre diferentes aparatos a través de un enlace radio en la banda ISM de 2,5 GHZ. • Radiocomunicación por microondas y WiMAX: funcionan en la banda situada entre 1 a 40 GHz y 2 a 66 GHz respectivamente, donde las informaciones pueden ser transmitidas utilizando una onda portadora proveniente de un generador situado en una antena. • Infrarrojo: radiación electromagnética en la que la longitud de onda es de 700 nanómetro a 1 micrómetro. • ZigBee: nombre de un conjunto de protocolos de alto nivel de comunicación digital inalámbrica y de baja potencia. Está dirigida a las aplicaciones que necesitan una comunicación segura para poca cantidad de datos y una vida larga de sus baterías. 6 2.2 Tecnologías de transmisión y normas Las tecnologías de transmisión son los protocolos o las reglas que los dispositivos de comunicación que deseen comunicarse deben comprender y utilizar para permitir la conexión, la comunicación y la transferencia de datos. Los estándares son un conjunto de recomendaciones y de normas que las empresas deben seguir con el fin de asegurar que sus productos puedan interactuar con otros periféricos de otras marcas. A continuación presentamos algunos de los protocolos más conocidos. 2.2.1 KNX El protocolo estándar KNX (Konnex) se convirtió en la norma domótica estándar internacional ISO / IEC 14 543-3. Se trata de una norma europea establecida en 1987, que reagrupa actualmente más de 190 fabricantes como Hager, ABB, JUNG, SCHNEIDER, BOSCH, ELECTROLUX, ... El desarrollo paralelo de KNX y EIB hace que los proyectos realizados en el pasado sigan siendo compatibles con los dispositivos más recientes. El protocolo KNX se basa en el principio de BUS, todos los participantes KNX de un proyecto (pulsadores, actuadores ...) interactúan entre sí a través de este bus. A diferencia de otros protocolos de automatización, éste no funciona en modo maestro/esclavo, cada controlador es independiente de los otros. 2.2.2 X10 La norma X10 es el estándar creado hace más de 20 años por la sociedad Powerhouse para controlar los electrodomésticos en los Estados Unidos y en el resto del mundo. Al igual que cualquier arquitectura de automatización tradicional del hogar, el estándar X10 utiliza la tecnología PLC para construir su red. El principio consiste en tener los emisores y los receptores conectados a la red eléctrica y comunicarlos entre sí. 2.2.3 EHS El "European Home Systems" es un protocolo domótico de comunicación abierto que utiliza el PLC. La especificación EHS se ha definido de manera que los aparatos puedan comunicarse y compartir recursos entre ellos. El protocolo EHS se basa en un sistema de comunicación común y en definiciones inequívocas de la funcionalidad del dispositivo. El modelo de comunicación EHS sigue la estructura del modelo OSI. El protocolo EHS especifica la capa física, la capa de enlace de datos, la capa de red y la capa de aplicación. 7 2.2.4 X2D El protocolo X2D es un protocolo de comunicación desarrollado por Delta Dore desde hace más de veinte años. Utiliza la tecnología de comunicación mediante cable eléctrico o radio (868 MHz) y permite la comunicación y el control de los equipos eléctricos siguiendo un concepto de automatización. Utiliza las frecuencias radio 434 MHz y 868 MHz. Garantiza una transmisión con un alcance de radio de 200 a 300 metros en campo abierto. El uso de dos frecuencias completamente diferentes mejora la calidad de la transmisión. Dichas frecuencias se emiten al mismo tiempo para que la una o la otra sea recibida por la central. La frecuencia de 868 MHz no es perturbada por las emisiones continuas como: auriculares inalámbricos, WiFi, ... 2.2.5 Z-Wave Z-Wave es un protocolo para la comunicación inalámbrica entre dispositivos electrónicos. Este protocolo tiene como características principales: • Está principalmente destinado a la automatización del hogar. • Es relativamente seguro. • Es de doble sentido (cada componente es a la vez transmisor y receptor). • Se utiliza en un sistema de red en malla. Al igual que cualquier señal RF inalámbrica, el alcance de una señal Z-Wave está fuertemente influenciada por el entorno en el que se emite. Utiliza frecuencias radio para las comunicaciones y permite que dos componentes electrónicos Z-Wave discutan juntos para intercambiar información. 2.2.6 OpenWebNet OpenWebNet es un protocolo de comunicación diseñado y desarrollado por BTicino desde el año 2000. Dicho protocolo fue creado para permitir la interacción entre todas las funciones del sistema de automatización del hogar "MyHome". Una evolución reciente ha permitido utilizar OpenWebNet para interactuar con cualquier sistema de automatización con el uso de pasarelas adecuadas. 2.2.7 xPL xPL es un protocolo abierto creado para permitir el control y la vigilancia de los dispositivos de automatización del hogar. El objetivo principal de xPL es proporcionar un amplio conjunto de características conservando una estructura de mensaje específica. El protocolo incluye capacidades de auto-configuración que soportan una arquitectura totalmente "plug-n-play" esencial para asegurar una buena experiencia para el usuario final. Las comunicaciones entre las aplicaciones xPL en una red de área local (LAN) utilizan el puerto UDP 3865. 9 Capítulo 3. Protocolo xPL Puesto que decidimos utilizar el microcontrolador Arduino para llevar a cabo nuestros experimentos creímos que el protocolo xPL podría ser una buena opción, ya que cuenta con una biblioteca específica para Arduino y existen muchos ejemplos que combinan el protocolo xPL con Arduino y están disponibles en la Web. 3.1 Definición del protocolo Uno de los principios de la domótica es lograr que diferentes dispositivos de la vida cotidiana lleguen a comunicarse entre ellos para conseguir que el conjunto sea más inteligente, controlable y extensible. Partiendo de esta base, una de las dificultades a las que nos enfrentamos es la complejidad a la hora de interconectar las diferentes tecnologías existentes en un sólo sistema domótico. Teniendo en cuenta que somos capaces de utilizar diferentes tecnologías (PLCBus, Zwave, x10...) pero que estas sólo tienen interés si se usan conjuntamente, necesitamos un medio que nos permita manejar y reunir toda esta información para que luego podamos utilizarlo en un sistema de automatización del hogar, sin tener que entrar en los detalles de implementación de cada tecnología. El protocolo llamado xPL (eXtremely simPle protocoL) tiene como objetivo permitir precisamente el control y seguimiento de todos los equipos del hogar mediante un único lenguaje de comunicación. En sus inicios el proyecto se llamaba XAP. Este sistema permite, mediante el intercambio formateado de texto con un patrón muy específico, comprender los diferentes eventos que se producen en la red doméstica y ejecutar comandos que actúen sobre los equipos domóticos. En enero de 2003, Ian Lowe y Tony Tofts crearon un proyecto en paralelo llamado xPL. Dicho protocolo, que requiere una red IP clásica y XML, permite la autoconfiguración y autodescubrimiento de los equipos permitiendo una integración simple en la red. 3.2 Funcionamiento del protocolo El principio del protocolo xPL es simple. Un software sirve de pasarela (HUB), cada equipo compatible con dicho protocolo transmite mensajes (eventos, estados u órdenes) hacia el hub y este a su vez lo retransmitirá hacia el resto de equipos conectados en la red. Un posible ejemplo de una red xPL sería: 10 Cada óvalo en el diagrama anterior es una aplicación independiente que se encuentra en la mayoría de los casos instalada en un ordenador de mesa, pero pueden estar también integradas en otros equipos. 3.2.1 Interfaces (Gateways) Las Gateways son aplicaciones que hacen de enlace entre las diferentes tecnologías y el protocolo xPL. Se trata de aplicaciones que conocen los detalles de implementación de las diferentes tecnologías. Por ejemplo encontramos puertas de enlace como las siguientes: • X10 (que luego se conecta a la interfaz CM11 por ejemplo). • RFXCom (que se conecta con el producto del mismo nombre y a continuación permite establecer una interfaz con todas las tecnologías conocedoras de RFXCom). • CurrentCost (que se conecta a la consola de ENVI para medir el consumo eléctrico de la casa). • SMS (que le permite enviar SMS). • 1wire (utilizado para comunicarse con toda la gama de sensores 1Wire). • ZWave (para comunicarse con la gama de automatismos ZWave). 3.2.2 Aplicaciones de estadística y de seguimiento Estas son las aplicaciones que sólo reciben información y no emiten nada. Por ejemplo, podemos guardar todos los cambios de estado de los equipos de la casa en una base de datos o almacenar los datos provenientes de diferentes sensores para posteriormente analizarlos. Figura 2. Esquema ejemplo de una red xPL 11 3.2.3 Aplicaciones de control Se trata de las aplicaciones que contienen la inteligencia y toda la lógica del sistema domótico. Estas son por ejemplo las aplicaciones que van a decidir apagar la luz cuando es de día o bajar la calefacción cuando la casa esté vacía. Éstas reciben todos los datos provenientes de las aplicaciones (gateways) mediante el protocolo xPL y emiten sus órdenes hacia dichas pasarelas utilizando el mismo protocolo. 3.2.4 Hub xPL Es el elemento indispensable en una red xPL. La presencia del hub es necesaria en cada uno de los equipos en los que se ejecutan una o más aplicaciones xPL. El hub no tiene inteligencia de control pero es él quien se encargará de encaminar los mensajes a sus aplicaciones xPL destino. 3.3 Aspectos técnicos Las transmisiones en las que se basa el protocolo xPL se hacen en broadcast UDP. Es importante entender que dichas transmisiones no son un broadcast propiamente dicho como se conoce en telemática, sino que se le llama así porque el principio de funcionamiento del protocolo es el envío de paquetes a todos los equipos existentes en la red, de ahí el “broadcast”, por lo que de ahora en adelante cada vez que aparezca dicho término en el documento será con esta definición particular. Así pues, las aplicaciones emiten sus mensajes en la red y el hub los redistribuye a sus destinatarios. Por la propia definición del funcionamiento del protocolo, todas las aplicaciones reciben todos los mensajes incluidos los que ellas mismas han enviado. Gracias a este mecanismo, el hub mantiene una lista de las aplicaciones que están conectadas. Al recibir un mensaje de una nueva aplicación la registra en la lista para actualizar todas las aplicaciones existentes en la red en ese preciso instante. 3.4 Portabilidad Es esta la característica que hace más potente al protocolo que es a su vez open source y sencillo. Hay aplicaciones xPL disponibles para los sistemas operativos más utilizados: Windows, Linux, MacOS. Por lo tanto, es posible tener diferentes sistemas operativos en la misma red xPL que podrán comunicarse entre ellos sin mayor problema gracias al protocolo. 3.5 Mensajes Existen tres tipos de mensajes xPL: 18 5.1.1 Diagrama de bloques El siguiente diagrama es el código gráfico implementado en LabVIEW con el que conseguimos abrir el archivo en cuestión, leer su contenido y ejecutar la acción correspondiente que en nuestro caso consistía en encender o apagar el led verde situado en la parte derecha del diagrama. La programación resulta bastante sencilla gracias a las funciones prediseñadas existentes en LabVIEW y que corresponden con los bloques amarillos que vemos en el diagrama. Figura 8. Diagrama gráfico LabVIEW 5.1.2 Panel frontal A continuación se presenta el panel frontal que se crea simultáneamente mientras se diseña el diagrama de bloques y que muestra el resultado visual del código implementado. Figura 9. Panel frontal asociado al diagrama 19 La ventaja de trabajar con LabVIEW es que podemos, por ejemplo, añadir un fondo de pantalla que puede hacer que la interfaz creada sea más realista. El resultado mostraba que el LED se iluminaba si en el archivo aparecía la palabra clave "on" o se apagaba si la palabra era "off". Modificando ligeramente el código podríamos no desencadenar ninguna acción si la palabra contenida en el fichero no corresponde con ninguna de las palabras clave. 5.2 Subsistema 1. Pulsador - Led Para aprender a manejar las placas Arduino y familiarizarse con el lenguaje de programación correspondiente adaptamos el siguiente ejemplo. El propósito de este ejemplo era comunicar dos placas Arduino entre ellas y ejecutar comandos que pueden ser útiles para administrar un hogar a distancia como encender la luz del salón (u ordenar cualquier otra acción) presionando por ejemplo un botón (en nuestro caso concreto, el pulsador Tinkerkit que aparece en la siguiente imagen) en un panel de control remoto al dispositivo que se desea controlar. La definición de una placa como emisora y la otra como receptora nos permitió comenzar a establecer una comunicación sencilla entre las dos placas, para posteriormente ir incrementando la dificultad, añadiendo otras etapas para llegar a comunicarlas por medio de un satélite. De ahí la importancia de este ejemplo del que presentamos el esquema a continuación. 5.2.1 Funcionamiento El funcionamiento del programa se basa en la transmisión a través del puerto serie de ciertos caracteres (en este caso los caracteres "a" y "b") que son enviados por la placa emisora cuando presionamos el pulsador. La placa receptora es la responsable de leer los datos entrantes por el puerto serie y en función del valor de la lectura del carácter, encender o apagar el led que está conectado a dicha placa. Figura 10. Esquema Pulsador-Led 20 Las imágenes siguientes muestran cómo se apagaba el led rojo una vez que presionábamos el pulsador y a su vez se encendía el led azul, lo que indica el correcto envío del carácter “a” y su correcta recepción. El código correspondiente a este escenario lo encontramos en el Anexo II. El interés de intercambiar texto en lugar de señales es la posibilidad de utilizar un sistema de reconocimiento vocal como hemos mencionado en el escenario anterior. Con este sistema podríamos controlar la vivienda inteligente por medio de comandos de voz como "encender la luz", "cerrar las persianas" ... El sistema transformaría los comandos de voz en texto y el envío del texto en este ejemplo daría lugar a acciones de manera similar. 5.3 Subsistema 2. Arduino y Ethernet Los siguientes ejemplos permiten el uso de Ethernet con las placas Arduino. En nuestro caso nos será muy útil ya que la idea es crear dos redes independientes y posteriormente establecer la comunicación entre ellas vía satélite. Es por esta razón que, si es posible el uso de Ethernet, la integración de Arduino en las redes será mucho más fácil ya que el "box" proporcionado por los proveedores de acceso a Internet (terrestre o satélite) ofrecen todas conectividad Ethernet. 5.3.1 Ethernet 1. Construcción de una red local En este primer ejemplo se define una red local formada por una placa Arduino y un PC, con el propósito de establecer el microcontrolador Arduino como servidor http gracias a la conexión Ethernet. Este ejemplo nos ha permitido crear una red LAN inicial para posteriormente poder añadir más componentes a la red. Figura 11. Situación inicial Figura 12. Pulsado del interruptor 21 5.3.2 Ethernet 2. Cliente - Servidor Ampliando el código anterior conseguimos establecer la tarjeta Arduino como servidor y el navegador Firefox como cliente. El programa que corre en el microcontrolador Arduino envía un código hacia el navegador y este a su vez lo muestra por pantalla en forma de texto simple. Dicho proceso se puede controlar simultáneamente gracias al monitor serie del entorno Arduino. Gracias a estos ejemplos hemos conseguido el siguiente paso que es el uso del microcontrolador como un dispositivo más de una red LAN. Los códigos correspondientes se encuentran en el Anexo III junto con las diferentes especificaciones necesarias para establecer dichas redes y las imágenes que muestran el correcto funcionamiento. 5.4 Subsistema 3. Interactuar gracias a Python La domótica ofrece la posibilidad de comunicarse con los diferentes dispositivos de la casa de forma interactiva. Podemos hacerlo a través de un menú, en una pantalla colocada a la entrada de la casa, desde un ordenador, un teléfono móvil, una tablet ... Es por eso que decidimos llevar a cabo este ejemplo, con el propósito de establecer el Arduino como servidor y un ordenador como cliente que nos permita utilizar un menú interactivo creado con el lenguaje de programación Python. La explicación detallada se encuentra en el Anexo IV. Con este ejemplo mostramos que se pueden activar acciones de manera remota a través de otros dispositivos colocando placas Arduino en las distintas estancias de la casa. Este paso también nos permite acercarnos a la gestión de la casa sin pensar en la distancia a la que nos encontramos de la vivienda en cuestión. 5.5 Subsistema 4. Creación de una red LAN añadiendo un segundo servidor Se trata de un ejemplo próximo al anterior con el que se pretende añadir otra tarjeta Arduino a la red. El interés de añadir otro periférico es la necesidad de instalar un switch en dicha red para poder interconectar todos los dispositivos. El objetivo de esta prueba es acercarnos cada vez más a la simulación de una vivienda real pudiendo elegir entre las diferentes estancias de la casa, es decir, en nuestro caso particular, entre las diferentes placas Arduino colocadas en la red. La explicación detallada se encuentra en el Anexo V. 22 5.6 Subsistema 5. Uso de una tarjeta de memoria microSD Puesto que las placas Arduino tienen una memoria interna reducida y nosotros necesitamos más espacio para almacenar código o crear y leer ficheros, existe la posibilidad de ampliar dicha memoria con una microSD. En nuestro caso, es una opción bastante interesante puesto que es de gran interés poder leer y crear ficheros para poder registrar más información como el tiempo, la temperatura... El código con el que ponemos a punto la placa para permitir el uso de la microSD se encuentra en el Anexo VI. 5.7 Sistema domótico. Protocolo domótico xPL La siguiente etapa consiste en introducir el protocolo domótico xPL para conectar los diferentes dispositivos de la casa entre sí. Como ya hemos explicado con anterioridad, el protocolo xPL (extremely simple protocol) dispone de funciones de auto-descubrimiento y auto-configuración que le permiten ser « Plug and Play » contrariamente a muchos de los otros protocolos domóticos. El objetivo de llevar a cabo este escenario es poner en marcha el protocolo elegido en este proyecto y verificar su funcionamiento para poder alcanzar uno de los objetivos fundamentales del proyecto. El principio consiste en lo siguiente, cada máquina (la mayor parte del tiempo un PC pero no necesariamente tiene por qué serlo) que forma parte de una red xPL tiene instalada un "hub xPL" que permite encaminar los mensajes entre los diferentes clientes xPL que existen en dicha máquina, pero además debe difundir estos mensajes a la red local a la que pertenece. Estos mensajes serán recibidos a su vez por los otros "hubs xPL" y en consecuencia por los clientes conectados a estos "hubs". En este ejemplo hemos ido introduciendo progresivamente las diferentes herramientas de las que disponíamos permitiendo así el correcto funcionamiento del protocolo xPL en la red. Para ello nos servimos de la biblioteca xPL disponible en la página web3. 5.7.1 Envío de paquetes “heartbeat” Para este ejemplo partimos de una red LAN formada por un solo PC y por un microcontrolador Arduino. El rol del PC es el de alojar el "hub xPL" que permitirá enviar los mensajes a los diferentes dispositivos xPL que dicho PC gestiona (en esta primera etapa sólo el Arduino). Estos mensajes son los que nos permiten conocer los dispositivos presentes en la red a medida que van conectándose. El rol de la placa Arduino es ser vista como un periférico que trabaja con el protocolo xPL, enviando periódicamente mensajes (heartbeat) a la red para informar de su presencia en la misma. Dichos mensajes son 3 http://connectingstuff.net/blog/connectingstuff/ 23 enviados a todos los equipos que tengan asignada una red ip, pero, dado que no es posible escuchar varias aplicaciones al mismo tiempo en un sólo puerto, el "hub xPL" que corre en el PC reenvía los mensajes a todas las aplicaciones que están conectadas a dicho PC. Gracias a todo este proceso se construye una lista de las aplicaciones existentes, de ahí el interés del envío de los llamados hearbeats. En dicho ejemplo y tal y como se detalla en el Anexo VII, vemos como efectivamente el microcontrolador Arduino envía cada 10 segundos un paquete heartbeat para indicar su presencia en la red. Como podemos comprobar en la captura de pantalla (Figura 30) del Anexo VII, la dirección de envío de estos paquetes es la dirección broadcast correspondiente a la red en la que se encuentra. Es importante recordar que no se trata del broadcast conocido comúnmente sino que es un broadcast específico del protocolo, en el sentido que es enviado a todos los elementos de la red xPL. 5.7.2 Establecer una red xPL con las placas Arduino Para crear una red xPL se debe tener en cuenta que el protocolo presenta una serie de restricciones. Una de las restricciones es que en un PC sólo puede haber una aplicación que reciba mensajes por el puerto designado (el protocolo xPL tiene asignado el puerto 3865). Para salvar esta restricción es necesario que cada PC que albergue al menos una aplicación xPL ejecute a su vez "hub xPL". Dicho hub estará a las escucha de los mensajes xPL que provengan del puerto 3865 y cada vez que reciban un mensaje lo retransmitirá al resto de los programas que se estén ejecutando en el PC. El hub es conocedor de los programas que están siendo ejecutados y de los puertos que están a la escucha gracias a la información proporcionada por el envío periódico de los heartbeat en la red. De esta forma eliminamos la problemática que impone el protocolo al trabajar sólo con el puerto 3865. El envío de mensajes en una red xPL es mucho más simple que la recepción de los mismos. Las aplicaciones xPL sólo se dedican a enviar estos mensajes de tipo broadcast a la red a la que pertenecen. Son los hubs los que manejan verdaderamente la comunicación entre los Pcs, puesto que reciben dichos mensajes y los retransmiten a las aplicaciones xPL locales. Por tanto el componente principal de una red xPL es el hub. En nuestro caso particular hemos usado el hub propuesto en la página web4. Se trata de un hub que funciona en Java y lo elegimos puesto que este hub, llamado xPL4Java, es una plataforma que puede ejecutarse en cualquier ordenador que disponga de Java. En el Anexo VII se detalla el proceso seguido y los códigos utilizados. Con este ejemplo llegamos a comprobar que efectivamente a partir del momento en el que conectamos el segundo Arduino, empiezan a aparecer en la ventana de Wireshark los paquetes heartbeat con la dirección ip asignada a dicho periférico. 4 http://www.xpl4java.org/ 24 5.7.3 Seguimiento de la red xPL à xPLHal xPLHal es el corazón de un sistema domótico xPL instalado en Windows. Es el responsable del tratamiento de los mensajes xPL entrantes, del envío de nuevos mensajes, de la ejecución de los programas y permite la configuración de periféricos xPL. La red final implementada para verificar el funcionamiento del protocolo xPL es la siguiente: El programa xPLDiag, encargado del chequeo de los diferentes componentes de la red xPL para su correcta puesta en marcha, se instaló en uno de los ordenadores que forma parte de la red. Dicho programa nos permite visualizar todas las aplicaciones existentes en ese momento en la red. Las imágenes de dichas aplicaciones se adjuntan en el Anexo VII (Figura 31). Una vez visualizada la correcta inicialización de las aplicaciones, comprobamos que el envío de paquetes era viable definiendo los paquetes en el programa xPLHal Manager (envío detallado en el Anexo VII, (Figura 32)) y observamos en el monitor xPL que los mensajes habían sido enviados como se muestra en la siguiente figura, donde el paquete seleccionado en dicho monitor es el que se ha enviado a través de dicho programa. Figura 13. Red xPL final Figura 14. Monitor xPL 25 La representación visual de los diferentes tipos de paquetes con distintos iconos, como se ve en la ilustración precedente, hace que el análisis de los paquetes se realice de una forma mucho más rápida y sencilla. En el monitor se observan varios heartbeat (simbolizados en el programa con el corazón rojo) provenientes de las diferentes aplicaciones existentes en la red, mensajes de trigger, de comando y de estado, enviados por las máquinas y que sirven para configurar la red. Para verificar el correcto funcionamiento procedimos al envío de un paquete desde el PC1 donde se encuentra instalado dicho programa y analizamos con Wireshark el proceso seguido por dicho paquete. Efectivamente vimos como el paquete había sido enviado, pero vimos también que dicho paquete fue reenviado por otro de los Pcs, el PC2, hacia el resto de los dispositivos existentes en la red. Hecho que muestra el correcto funcionamiento del protocolo xPL ya que es el hub instalado en este segundo PC el que reenvía el paquete redireccionándolo hacia todas las máquinas de la red. La captura de pantalla que lo muestra se encuentra en el Anexo VII (Figura 33). Con este ejemplo queda demostrado que el protocolo funciona como se define en la teoría, cubriendo así uno de los objetivos propuestos, es decir, hemos verificado la existencia de las funciones de auto-descubrimiento y autoconfiguración que permiten al protocolo xPL ser « Plug and Play ». Gracias a Wireshark hemos visto pasar todos los paquetes emitidos por cada aplicación y hemos visto también como eran difundidos por los hubs hacia todas las aplicaciones asociadas a esos hubs, creando así la lista de dispositivos existentes. Para concluir, el protocolo xPL presenta ciertas ventajas como la simplicidad de conexión de equipos de distintas marcas. Otra ventaja es la capacidad del protocolo al ofrecer la conexión « Plug and Play ». Esta propiedad permite añadir sin dificultad nuevas aplicaciones y nuevos periféricos xPL en la red. Las diferentes herramientas xPL existentes ayudan a monitorizar los intercambios que se producen en la red, a gestionar el envío de mensajes y permite la configuración de los dispositivos xPL en la red. Sin embargo, uno de los mayores inconvenientes es el envío de mensajes de tipo broadcast que permiten a los hubs descubrir el estado de la red en cada instante, pero que no pasan por los routers ya que estos no dejan pasar por definición los mensajes del tipo x.x.x.255. El protocolo trabaja a nivel aplicación por lo que una posible solución al problema sería la utilización de pasarelas. Figura 15. Esquema pila OSI 26 Para ello, habría que colocar la pasarela en el enlace de subida y en el de bajada. El rol de la pasarela del enlace descendente será desencapsular la cabecera añadida por la pasarela del enlace ascendente para poder encaminar los paquetes hacia todos los periféricos. Otra solución posible consistiría en subir los paquetes xPL en un servidor Web accesible por todos los periféricos xPL. Los clientes podrían interrogar el servidor periódicamente y activar las órdenes pertinentes. Otro inconveniente es que la puesta en marcha del protocolo con los programas que hemos utilizado no es evidente. La inicialización de la red xPL es caprichosa y requiere bastante tiempo. La definición y puesta a punto de la red xPL requiere un procedimiento particular detallado en el Anexo VII (inicialización de los hubs, lanzamiento del programa xPLHal Manager, lanzamiento del programa xPLDiag…) que reduce en gran medida estas dificultades. 5.8 Escenario final. Envío de la información vía satélite La última etapa de la parte experimental del proyecto se basa en el envío de los datos vía satélite para gestionar la vivienda a distancia y en el estudio de la viabilidad del enlace propuesto. El esquema propuesto y llevado a cabo para comunicar dos redes independientes a través del satélite se presenta en el siguiente esquema: Figura 16. Esquema satelital 27 El problema impuesto por el protocolo xPL para poder llevar a cabo esta etapa está ligado a las características fundamentales en las que se basa dicho protocolo. El hecho de que el protocolo utilice periódicamente el broadcasting para conocer los dispositivos que se encuentran conectados a la red en cada momento, impide el envío de datos vía satélite puesto que la presencia de los routers para establecer el enlace no permiten el envío de paquetes mediante broadcast. Desafortunadamente, la proximidad al final de mi estancia en la empresa y el retraso en cuanto a la recepción del material necesario para poner en práctica esta última etapa en el laboratorio, no nos permitió solucionar este problema pero se procedió al estudio de las posibles soluciones al mismo. Para analizar el comportamiento del enlace satelital retomamos el subsistema 4, en el cual manejábamos las placas Arduino gracias al menú implementado con Python, el cual nos permitía seleccionar la placa con la que queríamos interactuar. Antes de comunicarnos a través del satélite real, realizamos una simulación con el programa Netdisturb con el fin de observar el comportamiento del protocolo xPL y el efecto de los retrasos debidos al satélite. Así pues, conectamos el PC en el que se ejecutaba el menú Python a una de las tarjetas Ethernet del PC que albergaba Netdisturb para simular el cliente y las placas Arduino a la segunda tarjeta Ethernet de dicho PC para simular los periféricos xPL que representan distintas estancias de la casa. Figura 17. Simulación del envío por satélite con NetDisturb 34 19. Protocolo xPL. http://xplproject.org.uk/wiki/index.php?title=Main_Page [En línea] 20. Protocolo xPL http://en.wikipedia.org/wiki/XPL_Protocol [En línea] 21. Protocolo xPL. http://www.poulpy.com/2010/02/xpl-one-protocol-to-rule-them-all/ [En línea] 22. Protocolo XAP. http://www.xapautomation.org [En línea] 23. Proyecto xPL. http://xplproject.org.uk/wiki/index.php?title=XPL_Specification_Document [En línea] 24. Internet vía satélite. http://fr.wikipedia.org/wiki/Internet_par_satellite [En línea] 25. Labview. http://labview.developpez.com/faq/?page=2-1 [En línea] 26. Placa Arduino. http://www.lextronic.fr/P23528-platine-sensor-shield-pour-arduino.html [En línea] 27. Programación sockets. http://venom630.free.fr/geo/tutz/programmation/python/sockets/ [En línea] 35 Anexos 37 Anexo I. Descripción detallada Arduino Descripción La Arduino Ethernet es una placa electrónica basada en el microprocesador Atmega328. Cuenta con 14 pines de entrada/salida digitales, 6 entradas analógicas, un oscilador de cuarzo de 16 MHz, una conexión RJ45, una toma de alimentación y un botón de reinicio. Tabla de características Tabla 1. Características Arduino Ethernet Alimentación Para alimentar la placa Arduino existen dos posibilidades, un convertidor ACDC o una batería, basta con conectar el convertidor a la clavija de alimentación de la tarjeta y para utilizar la batería es necesario conectar los cables a los pines digitales Vin y GND de la placa. La placa Arduino puede ser alimentada por una fuente de alimentación externa de 6 a 20 voltios. El rango recomendado es de 7 a 12 voltios para no dañar la placa y evitar el sobrecalentamiento. Los pines correspondientes a la alimentación son: Figura 20. Toma de alimentación externa 38 • Vin: pin para la alimentación externa. • 5V: pin para alimentar el microcontrolador y otros componentes de la placa. Esta tensión puede provenir del pin Vin o de la conexión USB del ordenador al cual está conectada la placa. • 3V3: fuente de tensión generada por el chip FTDI. La corriente máxima es de 50 mA. • GND: pin a tierra. • IOREF: tensión de referencia para el microcontrolador. Memoria El microcontrolador ATmega328 tiene 32 KB de memoria flash, 2 KB de SRAM y 1 KB de EEPROM. Esta placa incluye una ranura para insertar una tarjeta de memoria micro SD, ya que el microcontrolador no posee mucho espacio para almacenar datos y existen algunos ejemplos en los que se necesita crear archivos de texto para almacenar la información que se recibe por el puerto serie. Entrada y salida Hay 14 pines digitales que podemos utilizar como entrada o salida: • Serie: 0 (RX) y 1 (TX). Pines que permiten recibir y transmitir información a través del puerto serie. • Interrupciones externas: 2 y 3. Pines a través de los cuales se pueden enviar interrupciones a la placa. • PWM: 3, 5, 6, 9, y 10. Pines de salida PWM. • SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). Comunicación SPI utilizando la biblioteca SPI. • LED: 9. Este pin está asociado al LED integrado en la placa. • A0 - A5. Estos seis pines son entradas analógicas. • TWI : A4 (SDA) y A5 (SCL). Dichos pines permiten la comunicación TWI usando la librería Wire. • AREF. Voltaje de referencia para las entradas analógicas. • Reset. Pin para reiniciar el microcontrolador. Figura 21. Pines de alimentación Figura 22. Lector microSD Figura 23. Pines de entrada y salida 39 Comunicación Se puede comunicar la placa Arduino con el ordenador, otro Arduino, u otros microcontroladores. Los diferentes medios de comunicación son: • El puerto serie con la ayuda de la biblioteca Software Serial Library. • Comunicación SPI y TWI con las bibliotecas SPI y TWI. • Puerto Ethernet (biblioteca Ethernet). • Lector microSD (librería SD) . Entorno Arduino El entorno de Arduino está disponible en el sitio web oficial5. Existen diferentes versiones en función del sistema operativo con el que se trabaja. En este caso hemos utilizado la versión de Windows Arduino 1.4 para la realización del proyecto. Este entorno está constituido de un editor de texto para escribir el código, una parte dedicada a los mensajes de error, un monitor serie, una barra de herramientas con los botones más prácticos y diferentes menús. Gracias a este software podemos cargar el código y comunicarnos con la placa Arduino. 5 http://arduino.cc/es/Guide/Environment Figura 24. Entorno Arduino 40 Bibliotecas Podemos encontrar una gran variedad de bibliotecas que nos permiten sacar el máximo partido a la placa. En la web oficial, existen muchas bibliotecas que podemos descargar de forma gratuita. En este caso particular, descargamos las siguientes bibliotecas para poder poner en práctica los ejemplos necesarios para llevar a cabo el presente proyecto: • Ethernet, para comunicarse con el microcontrolador Arduino a través del puerto Ethernet. • SD, para escribir y leer los datos de la tarjeta de memoria SD. • SdFat, para los intercambios con la memoria SD. • Tinkerkit, funciones prediseñadas que permiten gestionar los componentes Tinkerkit. • xPL, biblioteca que contiene los archivos para ejecutar el protocolo xPL en la placa Arduino. Monitor serie El entorno Arduino incluye un monitor serie para enviar o recibir datos. El monitor muestra los datos que se envían desde la placa Arduino. Para enviar información a la placa basta con escribir una línea de comandos en el monitor serie y hacer clic en “enviar”. Para que el monitor serie funcione correctamente es necesario determinar la velocidad (tasa en baudios) de intercambio entre la placa y el monitor serie. En nuestro caso, por defecto, utilizamos 9600. 41 Anexo II. Pulsador - Led A continuación se presentan los códigos utilizados para la puesta en marcha del segundo escenario definido en el capítulo 5 del documento. Código del microcontrolador Arduino emisor /* Button Turns on and off a T010111 LED Module connected to O0, when pressing a T000180 pushbutton attached to I0. This example code is in the public domain. created in Dec 2011 by Federico Vanzati based on http://www.arduino.cc/en/Tutorial/Button */ // include the TinkerKit library #include <TinkerKit.h> // creating the object ‘button’ that belongs to the ‘TKButton’ class // and giving the value to the desired input pin TKButton button(I0); // creating the object ‘led’ that belongs to the ‘TKLed’ class // and giving the value to the desired output pin TKLed led(O0); void setup() { // TinkerKit ‘object’ eliminate the need for pin declaration with pinMode() Serial.begin(9600); } void loop() { // check if the pushbutton is pressed if (button.get() == HIGH) { // if it is, the button.state() is HIGH led.on(); // turn LED on Serial.println('a'); // Enviamos 'a' por Tx (puerto serie) delay(1000); // Retardo de 0,1 s } else { // if it is not, the button.state() is LOW led.off(); // turn LED off Serial.println('b'); // Enviamos 'b' por Tx (puerto serie) 42 delay(1000); // Retardo de 0,1 s } } Código del microcontrolador Arduino receptor #include <TinkerKit.h> TKLed led(O0); int byte_entrada = 0; void setup() { Serial.begin(9600); // Inicio el puerto serie a 9600 baudios led.on(); } void loop() { if (Serial.available()>0) { // lee si al puerto Rx le llegan datos byte_entrada = Serial.read(); // almaceno en byte_entrada el dato que llega al puerto Serial.print("J'ai recu : "); Serial.println(byte_entrada, DEC); if (byte_entrada == 'a') // Si es una 'a' { led.off(); delay(2000); } else // if (byte_entrada == 'b') // Si es una 'b' { led.on(); } } } 43 Anexo III. Servidor - Cliente Para comprobar que nuestro programa funcionaba, verificamos escribiendo la dirección ip de la placa Arduino en la barra del navegador de internet y como vemos en la siguiente captura de pantalla, obtuvimos en el navegador Firefox el cliente que habíamos programado. Y como podemos ver en el monitor serie del entorno Arduino, el proceso de petición de la creación del navegador como cliente sigue una evolución correcta como se establece en el código presentado en el siguiente apartado. Figura 25. Navegador Firefox establecido como cliente Figura 26. Verificación del proceso del programa 50 Código servidor (placa Arduino) #include <SPI.h> #include <Ethernet.h> /* Détails technique de la connexion ethernet */ byte mac[] = { 0x90, 0xA2, 0xDA, 0x0D, 0xDA, 0x47 }; byte ip[] = { 172,16,55,41 }; // Attachement d'un objet "server" sur le port 1337 EthernetServer server(1337); void setup(){ // Configuration de la ethernet shield et du server Ethernet.begin(mac, ip); server.begin(); Serial.begin(9600); // Mise en sortie de la broche avec notre led (par défaut éteinte) pinMode(9, OUTPUT); digitalWrite(9, LOW);} void loop(){ // Attente de la connexion d'un client EthernetClient client = server.available(); if (client && client.connected()) { // si le client nous envoie quelque chose if (client.available() > 0) { // On regarde ce que le client nous demande switch(client.read()){ case 'A': // allumer la led Serial.println ("J ai recu un A --> allumer la led "); digitalWrite(9, HIGH); break; case 'a': // éteindre la led Serial.println ("J ai recu un a --> eteindre la led"); digitalWrite(9, LOW); break; } } }} 51 Código Cliente (ordenador) import socket print "Client WebLed" s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("172.16.55.41", 1337)) q = 0 while q != 3: print "- Menu WebLed -" print "(1) Allume la led" print "(2) Eteint le led" print "(3) Quitte le programme." q = int(raw_input()) if q == 1: print "Allumage de la led ..." s.send('A') continue if q == 2: print "Extinction de la led ..." s.send('a') print "a+ !" s.close() raw_input() 53 Anexo V. Creación de una red LAN añadiendo un segundo servidor Las diferencias de este ejemplo con respecto al anterior son sólo la declaración de un segundo servidor mediante las siguientes líneas de código: >> s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >> s2.connect(("172.16.55.42", 50322)) Servidor 1 #include <SPI.h> #include <Ethernet.h> /* Détails technique de la connexion ethernet */ byte mac[] = { 0x90, 0xA2, 0xDA, 0x0D, 0xDA, 0x47 }; byte ip[] = { 172,16,55,41 }; // Attachement d'un objet "server" sur le port 1337 EthernetServer server(1337); void setup(){ // Configuration de la ethernet shield et du server Ethernet.begin(mac, ip); server.begin(); // Mise en sortie de la broche avec notre led (par défaut éteinte) pinMode(9, OUTPUT); digitalWrite(9, LOW);} void loop(){ // Attente de la connexion d'un client EthernetClient client = server.available(); if (client && client.connected()) { // si le client nous envoie quelque chose if (client.available() > 0) { // On regarde ce que le client nous demande switch(client.read()){ case 'A': // allumer la led Serial.print ('J ai reçu un A'); digitalWrite(9, HIGH); break; case 'E': // éteindre la led 54 Serial.print ('J ai reçu un E'); digitalWrite(9, LOW); break; } } }} Servidor 2 #include <SPI.h> #include <Ethernet.h> /* Détails technique de la connexion ethernet */ byte mac[] = { 0x90, 0xA2, 0xDA, 0x0D, 0xDB, 0x22 }; byte ip[] = { 172,16,55,42 }; // Attachement d'un objet "server" sur le port 1337 EthernetServer server(50322); void setup(){ // Configuration de la ethernet shield et du server Ethernet.begin(mac, ip); server.begin(); // Mise en sortie de la broche avec notre led (par défaut éteinte) pinMode(9, OUTPUT); digitalWrite(9, LOW);} void loop(){ // Attente de la connexion d'un client EthernetClient client = server.available(); if (client && client.connected()) { // si le client nous envoie quelque chose if (client.available() > 0) { // On regarde ce que le client nous demande switch(client.read()){ case 'a': // allumer la led Serial.print ('J ai reçu un a'); digitalWrite(9, HIGH); break; case 'e': // éteindre la led Serial.print ('J ai reçu un e'); digitalWrite(9, LOW); break; } } }} 55 Menú Python import socket print ("Client WebLed") s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s1.connect(("172.16.55.41", 1337)) s2.connect(("172.16.55.42", 50322)) print (s1.getpeername()) print (s2.getpeername()) q = 0 while q != 5: print ("- Menu WebLed -") print ("(1) Allume la led carte 1") print ("(2) Allume la led carte 2") print ("(3) Eteint le led carte 1") print ("(4) Eteint le led carte 2") print ("(5) Quitte le programme.") q = int (input()) if q == 1: data="A" print ("Allumage de la led carte 1...") s1.send(data.encode()) continue if q == 2: data="a" print ("Allumage de la led carte 2...") s2.send(data.encode()) if q == 3: data="E" print ("Extinction de la led carte 1...") s1.send(data.encode()) if q == 4: data="e" print ("Extinction de la led carte 3...") s2.send(data.encode()) print ("a+ !") s1.close() s2.close() 57 Anexo VI. Uso de una tarjeta de memoria microSD Para comprobar el correcto funcionamiento, creamos un fichero de texto que se almacena en la tarjeta micro SD para posteriormente poder ser leído. Leemos dicho contenido y lo mostramos en el monitor serie para verificar el funcionamiento del programa. Código microSD lectura/escritura /* SD card read/write This example shows how to read and write data to and from an SD card file The circuit: * SD card attached to SPI bus as follows: ** MOSI - pin 11 ** MISO - pin 12 ** CLK - pin 13 ** CS - pin 4 created Nov 2010 by David A. Mellis modified 9 Apr 2012 by Tom Igoe This example code is in the public domain. Figura 29. Creación y lectura de un fichero de texto 58 */ #include <SD.h> File myFile; void setup() { // Open serial communications and wait for port to open: Serial.begin(9600); while (!Serial) { ; // wait for serial port to connect. Needed for Leonardo only } Serial.print("Initializing SD card..."); // On the Ethernet Shield, CS is pin 4. It's set as an output by default. // Note that even if it's not used as the CS pin, the hardware SS pin // (10 on most Arduino boards, 53 on the Mega) must be left as an output // or the SD library functions will not work. pinMode(10, OUTPUT); if (!SD.begin(4)) { Serial.println("initialization failed!"); return; } Serial.println("initialization done."); // open the file. note that only one file can be open at a time, // so you have to close this one before opening another. myFile = SD.open("test.txt", FILE_WRITE); // if the file opened okay, write to it: if (myFile) { Serial.print("Writing to test.txt..."); myFile.println("testing 1, 2, 3."); // close the file: myFile.close(); Serial.println("done."); } else { // if the file didn't open, print an error: Serial.println("error opening test.txt"); } // re-open the file for reading: myFile = SD.open("test.txt"); if (myFile) { Serial.println("test.txt:"); 59 // read from the file until there's nothing else in it: while (myFile.available()) { Serial.write(myFile.read()); } // close the file: myFile.close(); } else { // if the file didn't open, print an error: Serial.println("error opening test.txt"); } } void loop() { // nothing happens after setup } 66 Código xPL Arduino analizador /* * xPL.Arduino v0.1, xPL Implementation for Arduino * * This code is parsing a xPL message stored in 'received' buffer * - isolate and store in 'line' buffer each part of the message -> detection of EOL character (DEC 10) * - analyse 'line', function of its number and store information in xpl_header memory * - check for each step if the message respect xPL protocol * - parse each command line * * Copyright (C) 2012 [email protected], [email protected] * Original version by [email protected] * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ #include <SPI.h> #include <Ethernet.h> #include <EthernetUdp.h> #include "xPL.h" xPL xpl; // Enter a MAC address and IP address for your controller below. // The IP address will be dependent on your local network: byte mac[] = { 0x90, 0xA2, 0xDA, 0x0D, 0xDB, 0x22 }; IPAddress ip(172, 16, 55, 42); IPAddress broadcast(172, 16, 55, 255); EthernetUDP Udp; void SendUdPMessage(char *buffer) { Udp.beginPacket(broadcast, xpl.udp_port); 67 Udp.write(buffer); Udp.endPacket(); } void AfterParseAction(xPL_Message * message) { if (xpl.TargetIsMe(message)) { if (message->IsSchema_P(PSTR("lighting"), PSTR("basic"))) { Serial.println(PSTR("is lighting.basic")); } } // show message Serial.println(message->toString()); } void setup() { Serial.begin(115200); Ethernet.begin(mac,ip); Udp.begin(xpl.udp_port); xpl.SendExternal = &SendUdPMessage; // pointer to the send callback xpl.AfterParseAction = &AfterParseAction; // pointer to a post parsing action callback xpl.SetSource_P(PSTR("xpl"), PSTR("arduino"), PSTR("test")); // parameters for hearbeat message } void loop() { xpl.Process(); // heartbeat management int packetSize = Udp.parsePacket(); if(packetSize) { char xPLMessageBuff[XPL_MESSAGE_BUFFER_MAX]; // read the packet into packetBufffer Udp.read(xPLMessageBuff, XPL_MESSAGE_BUFFER_MAX); // parse message xpl.ParseInputMessage(xPLMessageBuff); } }