Midiendo la energía: 21 Integrando con el X4

Si la semana pasada fué dura… esta lleva el mismo camino… es una pena porque estoy en un punto muy interesante.

En el artículo anterior teníamos lista la parte de HW de la PDU, estábamos enviando la información en modo texto a través de la red Zigbee emulando un puerto serie y nos planteábamos el modelo a seguir con la activación (o mejor dicho la desactivación) de los relés. A decir verdad en el tema de la desactivación de los relés he cambiado de opinión, despues de mucho sufrimiento para lograr entender como funcionan los drivers del X4 he visto que parece bastante sencillo, enviando la órden para que sea controlada a través del micro podemos añadir una «feature» a la PDU, podemos configurarla para que desconecte el relé en el momento en el que la tensión (o la corriente podemos hacerlo configurable) pase por cero. Parece un a característica tonta, pero ofrece un valor añadido importante, si desconectamos en ese momento no hay picos de tensión y se reduce la posibilidad de poder estropear el equipo en el apagado. Esta no es una posibilidad provocada por la PDU, existe incluso cuando se apaga a mano.

I Digi Día

En la parte del microprocesador de la PDU (recuerdo que estaba basado en un Atmel 328 con el botloader de Arduino por la simplicidad) enviaremos los datos utilizando la librería Xbee-Arduino, que está disponible en Google Code de forma gratuita. El tipo de paquete que enviaremos es el Transmit Request, que se corresponde con el API frame 0x10 de Xbee. Podríamos haber enviado el paquete con el API frame 0x11 (que nos hubiera permitido elegir el cluster, el profile y el endpoint), pero no es necesario, trabajaremos con los de Digi, de momento no buscamos interoperabilidad con nada que no sea de este fabricante. Los datos los meteremos en el payload del paquete con el formato que queramos, intentando respetar el tamaño máximo del payload de 72 bytes. De momento para simplificar esta parte el payload que estoy enviando es la frase «Prueba PDU». De momento también estoy enviando un paquete cada 5 segundos y comprobando unicamente que le llega al acknoledge del coordinador conforme lo ha recibido. Las pruebas de comunicación las estoy haciendo con un Arduino Duemilanove, una Xbee Shield u un módulo Xbee.  Como la UART del Arduino la tengo ocupada con el Xbee he instalado la librería newsoftserial que permite emular otra UART por SW para mandar mensajes de debug a un terminal. No he hecho demasiados cambios sobre el ejemplo de la librería Xbee.

Cuando pones en marcha eso te quedas con la incertidumbre absoluta, en teorías manda paquetes por la red (que no ves) en el coordinador tampoco ves nada, pero reciber un paquete de ACK (que tampoco ves). Pruebo con el sniffer y veo los paquetes de ida y de vuelta.

Entender la parte de X4 no es fácil, por lo menos para mi. El X4 es un gateway, una plataforma de HW que incorpora un FW y toda una serie de pantallas de configuración. El FW del X4 es capaz de correr un intérprete de Pyhton, Python es un lenguaje de programación que corre en la mayoría de las plataformas, que está bastante estructurado visualmente y que, para el que lo conozca, debe de ser muy productivo.  Recientemente la gente de Digi ha sacado un IDE basado en Eclipse que a decir verdad facilita bastante las cosas, hasta ese momento se creaba un fichero de configuración, se comprimía el código y las librerías en un .zip, se hacía un upload al gateway y se arrancaba mediante una ventana de terminal, ahora la cosa ha mejorado un poco, es un poco más visual, pero ha empeorado para mi porque tampoco conocía el Eclipse, es una cuestión de práctica.

He modificado un driver existente, que utilizaba el mismo formato de paquete (0x10). He entendido como procesa los paquetes el driver, como se definen sus propiedades, etc. El siguiente paso será definir el formato del payload, parsearlo con el Python y asignar valores a las propiedades. La verdad es que ayer llegué a pensar que era imposible que llegara a hacer algo, hoy soy mucho más optimista.

Nos quedan cuatro «cosillas» y tendremos:

• Un PDU gestionable claramente mejorable (pero eso es fácil)
• Una forma de comunicar estándar dentro de su entorno, supongo que también mejorable.
• Un conocimiento de como tratar las comunicaciones hacie y desde el X4, lo cual nos permitirá acelerar los siguientes desarollos.

Nos faltará:

• Ser capaces de sacar toda la información que somos capaces de meter en el X4 y representarla, ya lo sabemos hacer con Pachube y hay ejemplos para graficar con los APIS de Google, pero esto está «chupao»..