Aunque en realidad el proyecto de nuevo tiene poco ya que empezó hace más de tres años. En abril del año 2010, como parte de nuestro proceso de aprendizaje quisimos medir la energía y el consumo eléctricos (Midiendo la energía (primera parte: Leer la tensión)), este fue el primero de toda una serie de más de 20 artículos dedicados al tema. Fuimos escribiendo a la vez que aprendíamos y este fue el resultado de aquello: Midiendo la energía: 25 Tachannnnnnnn!!!. En ese proceso desarrollamos un medidor de energía basado en una App note de Atmel simplificada con un microprocesador de propósito general.

Con la finalidad de incrementar la precisión y hacerlo compatible con Zigbee hicimos un segundo invento inacabado con un procesador específico para la medición de la energía: bMotes Energy meter V2: Medidor de energía Zigbee compacto con ADE7753. El proyecto y la idea han evolucionado hacia lo que os explico en este post.

Tal como os contaba en el último artículo uno de nuestros últimos proyectos ha sido la creación de una empresa dedicada a la eficiencia energética (A3 servicios energéticos), como somos conscientes de que para mejorar hay que ser capaces de medir pretendemos aprovechar toda la experiencia que hemos adquirido en el campo de las mediciones.

El panorama en la medición de la energía es el siguiente:

• Empiezan a verse medidores comerciales, pero la mayoría son bastante caros.
• El interfaz con los seres humanos que tienen los medidores comerciales es un display.
• En algunos casos tienen alguna salida con un protocolo industrial, como Modbus.
• Instalar un medidor de este estilo implica recoger los datos de Modbus, buscar la forma de sacarlos del cuadro eléctrico, que los lea un software de SCADA y tener unas posibilidades de explotación de los mismos reducida.
• Otra alternativa es utilizar software específico de dashboard energético, generalmente caros y no compatibles con todos los productos.

De aquí surge la idea que hemos ido trabajando hasta llegar al punto en el que estamos, en este momento con el desarrollo del hardware finalizado, el del firmware también, la placa trazada y encargadas las primeras versiones para los prototipos beta.

En este primer artículo me limitaré a describir la idea, os prometo artículos posteriores en los que vaya concretando, si todo va bien tendremos la ocasión de probarlas en proyectos reales y, posteriormente de compartir el “invento”.

Estas son las características principales:

• Es un producto modular, montado en cajas de carril DIN para poder integrarlas en el cuadro de luces.
• Hemos conseguido alojar cada módulo en una caja de las más estrechas, 15 milímetros.
• El primer dispositivo es un compañero ideal para un medidor estándar, el Socomec Diris A10. Nuestro dispositivo es capaz de comunicar a través de Modbus con el medidor y publicar con un API REST la información del medidos estándar a intervalos regulares. El dispositivo funciona por wifi, Tan sencillo como montar al lado de uno de los medidores más económicos trifásicos que hay en el mercado, configurar y ya tenemos la información disponible para poder explotarla. la configuración es realmente sencilla, se activa un switch, el dispositivo crea una red inalámbrica adhoc, te conectas con un portátil y le configuras la red principal y la de backup. El dispositivo se encarga del resto. De esta forma resolvemos el tema de la precisión (
• El segundo dispositivo es compañero del primero, es un dispositivo de muy bajo coste, con el mismo formato de caja que permite tomar de una fase hasta cinco medidas diferentes. Es decir, una medida de tensión y cinco de corriente. El objetivo de este dispositivo es ser capaz de segregar las medidas en los cuadros, separando el consumo en cada uno de los ICP del cuadro y permitiendo medir de una forma sencilla las mejoras de eficiencia aplicadas. El segundo dispositivo no lleva conectividad wifi, simplemente es leido por el primero a través de Modbus y el primero es el que se encarga de “subir” las lecturas a la aplicación.
• El segundo dispositivo no tiene un microprocesador de propósito específico al ser un equipo de bajo coste, pero es capaz de calibrarse de forma automática con el primero. Tenemos una medida con mucha precisión, el segundo equipo simplemente leerá la lectura precisa y se calibará para tener la misma precisión.
• La idea es montar en una instalación un medidor Socomec Diris A10, más el primer dispositivo para subir las lecturas de cada fase a la aplicación y añadir tres unidades del segundo dispositivo (una por fase), en total dispondremos de una lectura por fase general más 15 lecturas de consumos desagregados. En una instalación sencilla, rápida, no invasiva, etc. Eso nos permitirá aplicar medidas de eficiencia en los clientes y medir los resultados.

Por el momento nada más, aunque prometo detalle. Este proyecto es la evolución de un proyecto que ya dura años y, por el momento, nunca hemos llegado tan lejos.

Seguiremos informando…

Bookmark to:

Simplemente para que os hagáis una idea, tengo muchos líos y he sigo un poco desconectado, aunque espero retomar y rematar en breve.

Demo bmotes for Opendomo

Podéis acceder a través de este link, la demo es interactiva, podeis probar a desplegar los nodos, por ejemplo:

http://www.bmotes.com/opendomo/iphone/

Podéis conocer un poco del funcionamiento aqui:

http://www.zigbe.net/archivos/1270

Si tenéis propuestas, dudas o comentarios podéis publicar un comentario, tarde o temprano prometo responderlo.

Bookmark to:

Pues os podéis imaginar, trabajo, nuevos proyectos, poco tiempo y prioridades incompatibles, no hemos desaparecido, nos estamos re enfocando un poco hacia los proyectos relacionados con la eficiencia energética, de hecho en paralelo con esto, con la familia, con las aficiones y con muchas otras cosas  iniciamos un nuevo proyecto profesional A3 Energía.

En estos meses también hemos seguido haciendo el friki, pero con algunos temas un poco más enfocados al mundo de la medición de la energía. No hemos abandonado los proyectos, simplemente hemos desviado un poco el foco, siguen activos.

Con respecto a los proyectos que tenemos abiertos siguen en el mismo punto, finalizados desde un punto de vista de desarrollo y a falta de algunos remates. Prometo en breve publicar información, liberar cosas, etc. y pido disculpas.

En diciembre defendía en el foro de Opendomo las ventajas de Zigbee con respecto a Wifly (Wifi en vez de Zigbee) Respondí en ese foro que las características de Wifly me parecían buenas, pero que estaba pensada para otra cosa.

Wifly

Como era de esperar he probado este módulo para sacar mis propias conclusiones y porque me parece una buena idea para determinados montajes, a pesar de que sigo defendiendo que no es lo mismo.

A favor:

• Muy fácil de configurar y de utilizar.
• Consumos eléctricos muy ajustados.
• Existe una librería de Sparkfun para Arduino que permite hacerla funcionar de la misma forma que la librería Ethernet.
• El mismo factor de forma de Xbee.
• Rapidez de conexión.
• El stack TCPIP está integrado en el módulo.
• Incorpora configuraciones muy enfocadas a sensores inalámbricos en el propio módulo
• El precio
• La posibilidad de montar sensores sin gateways.

En contra:

• Ver todos los argumentos del link a la página de Opendomo, en principal es que Wifi no es una tecnología pensada para que los nodos duerman, eso hace que este módulo sea muy adecuado para despertar y enviar lecturas de sensores, pero no para recibir a través de la red, ya que si el módulo está dormido el paquete se perderá (Zigbee lo almacenaría en la red para entregarlo en el momento en el que despertara)
• No está muy bien documentado, especialmente uno de los aspectos que considero importantes, solo admite una conexión TCP simultánea (El Shield Ethernet de Arduino 4), lo cual lo invalida para hacer de servidor web por ejemplo.

Conclusiones:

Absolutamente recomendable para hacer motes que envíen periódicamente una información a Internet, sin la necesidad de gateways y con consumos ajustados que permiten incluso el funcionamiento con baterías. Especialmente para motes basados en sensores analógicos, ya que es capaz de enviar las lecturas de los puertos, de forma periódica sin un microprocesador adicional y con una circuitería mínima. Imposible su uso en nodos que funcionen en modo Sleep, lo cual lo hace inutilizable en cualquier mote que tenga que recibir información y funcione a baterías.

Actualmente estamos acabando un gateway que es capaz de extraer la información energética de analizadores de red comerciales a través de protocolo Modbus sobre el puerto RS485 y enviarla a través de Wifi a una página que hace de broker de datos en una dirección pública de Internet. Con el objetivo de almacenar la información para después analizarla y presentarla. He de reconocer que para esta aplicación (alimentada de forma permanente y solo de salida) el módulo Wifly es la opción perfecta.

Seguiremos…..

Bookmark to:

Este artículo nace de una necesidad, que todavía no está resuelta del todo. Como habréis podido ver últimamente trabajo en “rematar” el gateway para Opendomo. Tal como os comentaba el interfaz se carga en el cliente, el cliente pide al gateway información por Ajax de forma asíncrona y, una vez la recibe, la aplicación Javascript que corre en el cliente se encarga de generar la página escribiendo en el DOM y de actualizar los datos. Aquí empieza el problema.

Desde el cliente te conectas al Gateway (sin problemas), el Gateway redirige al cliente a una página pública de Internet pasando la IP del Gateway como parámetro (porque un ATMEGA 328 no tiene capacidad para servir el contenido). El cliente descarga los ficheros de la página pública la primera vez que se conecta (las siguientes los tiene en su caché, por lo que no es preciso tener una conexión con Internet). Los ficheros contienen el interfaz vacío, los gráficos y los programas de Javascript. Lo primero que hace el programa de Javascript es solicitar al gateway un par de JSON, uno con la configuración y otro con el contenido de los nodos y los puertos, con esa información construye la página y la actualiza en el navegador.

En este punto ya tenemos la aplicación con todos los datos en la pantalla.

Ahora empieza lo bueno, necesitamos que nos llegue al navegador cualquier actualización de los puertos y que se refresquen de forma inmediata.

Primera opción: disparar polls al servidor de forma periódica, cada x segundos se solicita un nuevo Json con los puertos que se han actualizado desde la última petición. El gran inconveniente de este sistema es que si se retrasa alguna petición se puede solapar con las siguientes, eso provoca más retraso y pueden acumularse muchas.

Segunda opción: disparamos los polls al cabo de un tiempo predefinido después de recibir la petición anterior. Con respecto a la opción anterior tiene la ventaja de que nunca se van a acumular las peticiones, si disparamos cada dos segundos y una petición tarda tres en ser respondida la siguiente se solicitará dos segundos más tarde de la recepción.

Tanto en una como en otra los puertos tardan un poco en actualizarse, en función de los retrasos en la red, lo que esperas cuando pulsas un botón es que el cambio se refleje inmediatamente en el interfaz, por lo que he decidido mejorarlo.

Como ya sabréis HTTP es un protocolo “sessionless”, por lo que no es posible mantener una conexión abierta y que el gateway le mande las notificaciones cuando se produzcan los eventos. Esto se ha resuelto en HTML5 con los websockets, pero parece ambicioso utilizarlos en un Arduino por cuestiones de espacio, la mejor solución parece una técnica que se llama Long Poll.

Tercera opción Long Poll: Desde el cliente hacemos la petición Ajax estableciendo un timeout de 30 segundos o de un minuto, el gateway no responde hasta que se produce el evento, en el mismo momento en el que se produce el evento el Gateway responde a la petición, si se supera el timeout sin que se haya producido un evento desde el Javascript lanzamos otra petición.

Long Poll

Las primeras pruebas son sencillamente impresionantes, impresionan por la poca costumbre que tengo de ver cosas en un navegador en tiempo real, pero ahora nos queda implementarlo en el gateway.

El primer problema viene de tener una conexión abierta, pueden cruzarse una petición de la aplicación con una respuesta pendiente, por lo que decido utilizar dos sockets diferentes, uno para la comunicación normal y otro para los long poll, las primeras irán por el puerto 80 y las segundas por el 1730. He ido avanzando y obteniendo progresos, pero las librerías ethernet de Arduino parecen tener dificultades para manejar comunicación en dos sockets de forma simultánea (si…. ya se que el manual del chip Wiznet dice que hasta cuatro, pero no parece funcionar). llevo unos días sin progresos, por lo que es posible que, de momento, opte por la segunda opción y deje que la tercera madure sola en mi mente.

En el camino he intentado multitud de opciones, utilizar timer interruptions, poner varios loops, etc. en todos los casos con los mismos problemas.

Seguiremos informando.

Bookmark to:

El resultado sale del uso de toda una serie de tecnologías, cualquiera que haga cosas con micros ATMEGA328 es perfectamente consciente de que no se pueden hacer interfaces muy complejos, 30K de nvram y 2K de RAM no dan demasiado de si, podríamos llenarlos con un único icono.

En el primer intento el SW que genera el interfaz residía en el propio gateway, básicamente texto y poco más, por las limitaciones de la plataforma. La primera idea fué cargar las hojas de estilo desde un nodo en una dirección de Internet, lo siguiente trasladar algunos cálculos al navegador (como por ejemplo el chequeo de las direcciones IP en la pantalla de configuración), lo siguiente fué trasladar los iconos. La reflexión final fué ¿porqué no poner todo fuera exceptuando los datos puros?. Así es como nace este proyecto.

Dispositivo móvil

La idea es sencilla, en un ordenador en Internet están todos los ficheros de la aplicación, sin ningún dato, siempre son los mismos y se cachean en el navegador, por lo que solo es necesaria la conectividad con Internet en el primer uso.

Una vez que funciona la aplicación en el navegador esta consulta en el Gateway los datos de los nodos que ha encontrado en la red Zigbee y genera la lista de nodos, cada cierto tiempo (configuirable) se consultan las actualizaciones de los puertos y se actualizan.

La aplicación funciona con CCS3 y HTML5, en cualquier dispositivo que soporte esta especificación del lenguaje, está optimizado para dispositivos táctiles porque funciona con jquery mobile. Se puede empaquetar con Phonegap para convertir en aplicaciones nativas para Iphone, Android, Blacberry, Windows, Linux y un largo etcétera de dispositivos.

En próximas entregas os iré dando detalles, en la entrada de ayer sale un vídeo funcionando sobre un PC con Windows 7, a continuación un link en el que se ve el SW en acción en un iphone, en un móvil Android Samsung Galaxy ACE, en una tableta Samsung galaxy tab de 7 pulgadas y en un Ipad. hay algunos pequeños fallos que corregiremos….

http://youtu.be/16GV7FuZSeE

Bookmark to:

Hola,

Hace tiempo que no escribimos nada en el blog, la realidad es que estamos muy ocupados, aun así la actividad del maestro “Carlos” no cesa y como muestra os dejo este video que ha realizado con nuestros avances… en breve os seguiremos ofreciendo más capítulos de los progresos con la soluciones Zigbee y la Internet of Things

Bookmark to:

No, mientras espero unos materiales estoy avanzando en el siguiente paso que queríamos dar, de nuevo la medición de energía.

Hace ya más de un año publiqué una serie de artículos sobre la medición de la energía, el prototipo que contruimos era una PDU inteligente, capaz de activar y desactivar salidas y medir tensiones, potencias, corrientes, etc. en cada salida. El prototipo hacía las mediciones y las integraciones con un microprocesador ATMEGA 328  el prototipo fué funcional, pero no compacto.

Uno de los últimos posts del medidor de energía

Viendo que es un tema que tiene bastante futuro, y que existen en el mercado medidores especializados nos animamos a hacer uno con Zigbee, un ATMEGA328p a 8 Mhz y un ADE7753, que es un procesador especializado en la medición de la energía.

La idea es hacer una placa que integre toda la parte digital del invento, para poderla acoplar en medidores de carril DIN, enchufes, PDU’s, etc. En cada uno de estos productos se pondrá la parte analógica y de alimentación correspondientes.

Contra todo pronóstico he conseguido “meter” toda la parte analógica debajo del módulo Xbee, con un temaño de circuito de 2,5×2,5 cm.

El circuito además es monocapa, para poder hacer los prototipos antes de encargar las placas.

Próximamente publicaré  esquemas y firmwares, simplemente quería compartir, de momento, el circuito impreso para que os hagais una idea del grado de integración.

Placa de medición de energía compacta

¿qué os parece? Promete ¿no?

Bookmark to:

Después de muchas pruebas  la solución ha sido ubicar el sensor fuera de la caja, el producto es menos compacto, pero nos ha dado una serie de ventajas.

No tenemos que limitarnos a un único tipo de sensor, como conector con el mundo exterior hemos utilizado un RJ11 6/6, lo que nos da un total de 6 conexiones posibles: una la utilizamos para la masa, otra para la tensión de alimentación del sensor, hemos puesto también una de las entradas analógicas y nos queda espacio para tres puertos digitales. En la versión actual (la casi definitiva), tenemos la posibilidad de conectar un sensor Sensirión (de la serie SHTXX), la de conectar un sensor DHT, también de temperatura y humedad (más económico y supongo que un poco menos preciso) o una “ristra” de sensores onewire.

La idea de la ristra es especialmente interesante, podemos poner hasta 64 sensores en un único cable al estilo de unas luces de Navidad. En la aplicación en la que pensamos (monitorización de CPD’s) eso nos puede permitir tomar temperaturas en varias partes de un rack (la de entrada del aire, la superior, la inferior, etc. Lo cual nos da un control mucho más preciso de las condiciones del entorno.

En la entrada analógica podemos conectar cualquier tipo de sensor analógico, otra posibilidad en la que estoy pensando es en utilizarlo (con un divisor de tensión característico para cada tipo de sensor) para que el mote detecte que le estamos pinchando y se autoconfigure.

Llegados a este punto estamos dando los últimos “toques”, un problema importante es el mecanizado de las cajas. Obviamente no es mi objetivo dedicar mi tiempo a mecanizar cajas manualmente, pero siendo realista los inicios son complicados y hay que buscar alternativas artesanales. En esa línea me he hecho una plantilla con un perfil de pladur.

El resultado es esta especie de chapuza:

Vista superior de la plantilla con una carcasa

Vista inferior de la plantilla

Como podéis ver la técnica para hacer la plantilla no es muy depurada, pero me permite mecanizar cada caja en un tiempo record de 5 minutos, con una precisión muy buena.

Para finalizar unas fotos del resultado y de mis sensores del prueba, un DHT22 y una “ristra” con un par de sensores onewire en paralelo.

bMote ETH, entrada Ethernet y alimentación

bMote ETH entrada de los sensores

Sensores de prueba

Bookmark to:

Actualmente tenemos la versión 97 del Gateway con Opendomo, funcionando sin ningún problema en una placa con un ATMega 328p, la placa funciona con nodos A (sin micro) y con nodos B (que llevan micro). La placa se autoconfigura en la red Ethernet y en la red Zigbee y con la versión de Opendomo 0.9.3 se han resuelto los problemas de compatibilidad con el dimmer y, finalmente, podemos guardar de forma persistente la configuración de los nodos.

Estamos haciendo algunas pequeñas series de algunos de nuestros prototipos. Los que ya nos conozcáis ya os imaginaréis que hemos aprovechado para arreglar y mejorar algunas cosas:

bMotes Dimmer:

El montaje original funcionaba con 8 niveles, la versión V3 funciona con 16 niveles de iluminación. Proximamente publicaremos el esquema completo, ahí va un avance.

bMotes Dimmer V3

bMotes LTC:

Hemos mejorado el sensor de flancos (simplificandolo).

bMotes LTC V9

bMotes ETH:

Hemos ubicado el sensor fuera de la caja con un conector RJ11 6/6 para evitar el problema de la contaminación térmica y hemos cambiado la disposición de algunos elementos. Aprovechando que ahora tenemos más líneas de comunicación con el micro haremos versiones con  sensores onewire, analógicos, etc.

bMotes ETH V3

Además una nueva incorporación, el bMotes Router:

el bMotes Router es una implementación con un coste mínimo de un router para ampliar el rango de la red Zigbee.

bMotes Router V1

También hemos diseñado una nueva versión mejorada del medidor de energía, ahora basado en un micro de propósito específico. próximamente escribiremos algún artículo sobre el tema.

En estos días montaremos los prototipos y seguro que escribimos un montón de artículos interesantes.

Bookmark to:

En el mundo de los sistemas embebidos suele haber un pequeño programa que se llama bootloader, su función es poder cargar los programas en la memoria nvram sin la necesidad de un programador. Poniendo como ejemplo la placa Arduino, con la ayuda de un programador siempre podemos cargar un programa, pero si ponemos un bootloader podremos hacerlo a través del puerto serie. El micro se inicia, arranca el bootloader y este se encarga de escuchar por el puerto serie o por el puerto USB durante un tiempo después del reset para ver si queremos cargarle un programa en la nvram.

Normalmente la UART de los micros funciona con niveles lógicos de 0 y 5V (o de 0 y 3,3V), mientras que el puerto serie de un ordenador lo hace con +-10 ó 12 V (perdonad la imprecisión), por lo que es necesario un circuito que adapte los niveles. Si lo intentamos hacer a través de un puerto USB también necesitamos un circuito que adapte los niveles y los protocolos, generalmente con un chip de FTDI.

Nosotros intentamos hacer nodos pequeños y baratos, como esta circuitería adicional solo sirve para cargar el programa no es necesario que sea una parte fija del nodo, como norma general lo que se suele hacer es dejar unos headers (pines) en el nodo y utilizar una placa aparte como la de la foto.

Placa de FTDI para convertir de USB a UART

Todo esto en el campo parece un poco complicado, para actualizar el firmware tienes que abrir la caja del nodo, conectar esta placa, un PC con un puerto USB, el entorno de desarrollo y, posteriormente, actualizar el FW de la placa.

Pensando en la forma de simplificarlo he estado mirando bootloaders alternativos, que nos permitan actualizar de una forma más sencilla:

• TFTP: Es el más obvio, a través de la red, he encontrado dos https://github.com/mharizanov/TFTPBootloader_0_2 y https://github.com/mharizanov/arduino-netboot, el segundo no me sirve demasiado, porque exige configurar un servidor BOOTP, un poco complicado para lo que lo quiero. El primero lo he probado, pero no he conseguido hacerlo funcionar.
• SD: Una forma alternativa de actualizar el FW es poniendo un fichero en la tarjeta SD, simplemente hay que conectar la tarjeta SD a un PC, arrastrar el fichero HEX con un nombre concreto y el nodo al arrancar actualizará su firmware. Combinado con la posibilidad de que el propio programa del nodo busque en Internet actualizaciones, las descargue y las coloque en la SD nos da un procedimiento sencillo para actualizar, si la necesidad de sacar la tarjeta. Podemos tener un repositorio en Internet y que los nodos comparen la versión de FW que tienen con la última, si hay una posterior que la descarguen y la graven en la propia tarjeta, la proxima vez que reinicemos la placa se actualizará mágicamente.

He encontrado esto 2boots, que es un bootloader para Arduino que permite la carga por la UART y por la SD. Me falta probarlo, pero parece una buena idea….

seguiremos informando

Bookmark to: