La verdad es que ando un poco aburrido entre el Pyton, el Asp.NET, los servicios web, el brokerage de datos, etc. Por lo que me he decidido a hacer algo divertido.
Hace algunos post os había hablado de algunos inventos nuevos que tenía preparados, uno de ellos era un mote capaz de leer tarjetas o tags RFID de 125 Mhz. La placa la tenía hecha porque aproveché cuando revelé la del red button, por o que me he puesto manos a la obra.
La idea es sencilla, un mote que sea capaz de leer un tag y enviar la lectura al coordinador a través de la red Zigbee, el coordinador de la red es el encargado de validarlo con una lista o de enviarlo a otro equipo que lo valide y ejecute una acción concreta. Por ejemplo: abrir una puerta, encender la luz o dar el acceso a un servidor.
La filosofía es la misma que en los demás, intento hacer un dispositivo de bajo consumo, que funcione con dos pilas AAA y que dure por lo menos un par de años. la placa es como las demás (25mmx50mm), justo el tamaño de un portapilas para dos pilas AAA. me he encontrado con un problema que de momento no he resuelto, la forma de detectar que se ha acercado una tarjeta para despertar al mote y al lector, porque de lo contrario no podemos garantizar la autonomía. De momento lo dejo y lo que pondremos es un dispositivo que detecte sin consumir, por ejemplo un pulsador.
Imagen virtual de la placa del bMotes RFID
El lector RFID (un ID-12) funciona a 5V, pero el mote está alimentado con dos baterías de 1,5V, por lo que he incluido step-up converter que eleva la tensión hasta los 5V.
Al ir a montar el circuito me he dado cuenta que el integrado L6920DC tenía un encapsulado MSOP8 y que no coincidía con el tamaño del que había utilizado en la placa, he mirado la librería del componente y como no la encontré la hice yo mismo, por error con un encapsulado TSOP, como resultado de ello la placa no es aprovechable.
Por hacer algo, he cambiado el encapsulado en el Eagle, re trazado de nuevo las pistas de la placa y he probado el Eagle 3D para generar una imagen virtual de la placa en 3D. Como podréis ver hay varios componentes que no han salido, el propio módulo Xbee, algunos condensadores, los conectores, etc. Hay alguna forma de ponerlos con el eagle 3d, pero me ha parecido complicado, prefiero hacer la placa y «echarle» una foto. De todas formas os dejo la imagen.
Como me da un poco de pereza ahora ponerme a hacer una placa nueva aprovecharé, acabaré la del anemómetro y alguna más que tengo pensada con un ATMEGA328p integrado y en unos días lo vemos.
De momento echaré un rato más con los servicios web.
Hola,
Tengo una consulta, estoy trabajando con ZigBee Series 2 en modo API. Lo que logré hacer es enviar datos con el comando 0x10, hacer broadcasts e interpretar los datos que recibí.
Tengo 2 dudas, la primera es que cómo sé si se está efectuando Mesh o no, hay que configurar algo para que opere con Mesh o lo hace por defecto?
La otra consulta es, con el comando 0x11 se puede transmitir como el 0x10 pero además fijar el endpoint, cluster y profile. No tengo ni idea que sos estas cosas, sobre todo el endpoint que lo vi en varios lados ya. Para qué y como se usan?
Muchas gracias!
Kuropatula,
perdona, pero no había visto tu mensaje anterior, te respondo los dos.
Sobre la actualización de firmware Digi tiene muchas referencias diferentes para el mismo HW en función del FW que llevan instalado. En la web de Digi hay una matriz con los diferentes HW, todos son el mismo, de hecho yo me compré por error unos módulos 802.15.4 (los más baratos y los actualicé a ZB sin problemas)
Del tema de que no se actualicen te comenté que hay una cierta parte de misterio, lo único que se me ocurre es que intentes cargar algún FW que te deje (por ejemplo coordinador AT) y después lo intentes con el que necesitas, a mi me ha funcionado en alguna ocasión.
Para que opere con Mesh lo que tienes que cargar es el FW de DigiMesh, una vez hecho esto tendrás que configurar con cuidado los parámetros de Sleep. Puedes tener una red Mesh que no duerma porque no funcione a baterías, pero para eso también podrías hacer una red ZB en la que todos los nodos fueran routers.
El endpoint es a una red Zigbee lo que el puerto es a una red Ethernet, en un paquete defines el endpoint de destino, eso permite que en el nodo de destino puedas tener varias aplicaciones, cada una respondiendo a un endpoint. El profile es un convenio, si quieres que toda una serie de dispositivos de diferentes fabricantes sean interoperables tienes que definir que es lo que tienen que hablar, a través de que cluster y en que endpoint.
Digi utiliza su propio profile enviando los paquetes con el API frame 0x10 que tiene un endpoint concreto. El frame 0x11 es un paquete explícito, que te permite enviar cualquier cluster a cualquier endpoint (que tu definas) y, por lo tanto te debe de permitir la interoperabilidad con otros fabricantes.
Para empezar yo utilizaría el profile de Digi si no tienes que comunicar con dispositivos de otros fabricantes.
Hola Carlos, muchas gracias por tu respuesta!
Según lo que leí sobre DigiMesh, es para la Serie 1. Yo estoy trabajando con la serie 2. Me parece que es por eso que puedo bajarle casi cualquier FW menos el de DM. Es por esto que estoy trabajando con el FM de ZB, en modo API. Voy relativamente bien.
Mencionaste algo en tu comentario que quiero confirmar. Al operar con ZigBee con todos Routers se trabaja automáticamente con Mesh? No hay que configurar ningún otro parámetro?
Entendí muy bien el concepto de los endpoints, voy a llevarlo a la práctica para comprenderlo mejor.
Cualquier cosa te sigo consultando por aca?
Muchas gracias nuevamente.
Saludos,
Daniel.
No es cierto, los serie1 son para 802.15.4, creo que el digimesh solo funciona en los de la serie2.
En una red ZB los routers hacen mesh, es su función, enrutar los paquetes de la red, si un router desaparece la red busca unncamin alternativo. ¿Cual es la ventaja de la red mesh?…
En una red ZB los routers tienen que estar siempre encendidos para cumplir su rol, por lo que no es viable una red alimentada con baterías, tendrían muy poca autonomía. Eso si, los end nodes pueden dormir y los routers pueden hacer de end nodes siempre que no duerman.
En Digimesh los routers pueden dormir, por lo que pueden fncionar a baterías, para resolver los tiempos de espera por el modo sleep al final lo que hacen todos los nodos de la red es sincronizar ls tiempos, todos duermen y todos se despiertan a la vez.
La verdad es que no conozco con mucha profundidad com funciona el tema de DM, porque no lo he usado, supongo que es fundamental para las soluciones de exteriores, pero aún no he llegado a ese punto.
Hola Carlos,
Bien, por ahora me quedó todo lo que necesitaba claro. Estoy jugando bastante con los módulos en modo API y hasta ahora no tuve muchos inconvenientes. Cuando monte la red que va a tener unos 200 dispositivos creo que empezarán nuevos problemas.
En realidad tuve un problema, en un caso un router me quedó en otro canal, lo reseteé y se solucionó, pero cuando tenga mi red montada no voy a poder hacer eso. Lo que pensé es mandar broadcasts periódicos como si fueran keep alives del comando ND (en modo API desde el coordinador) y si no le llega a algún módulo en determinado tiempo lo reseteo desde del micro controlador. Hay alguna forma más simple de hacer esto?
Muchas gracias por toda tu ayuda, cuando tenga más dudas te consulto. Espero algún día poder ayudarte en algo.
Saludos!
Es bastante raro, no entiendo como se puede haber quedado en otro canal, ojo que no tuvieras dos coordinadores.
Si reseteandolo te funciono posiblemente la mejor opción sea Un watchdog timer en el micro y los vas reseteando periodicamente.
Consulta de todas formas en el manual de los módulos, me suena que si un router o un end node estaban más de un tiempo determinado sin parent se ponían en modo búsqueda.
Si un módulo por alguna razón queda fuera de la red (queda en otro canal) se puede setear (previamente) el parámetro NW (Network Watchdog) el cual saca al módulo de la red si este no recibe datos o ACKs (o sea, algo previamente enviado y que llegó satisfactoriamente) por un tiempo determinado por 3*NW en minutos. Al pasar ese tiempo si el módulo no recibió datos, sale de la red. Para buscar una nueva red el parámetro JV (Channel Verification) debe estar seteado a 1. Para que el coordinador se entere que hay un nuevo módulo en la red, el parámetro JN (Join Notification) debe estar a 1 al igual que el AO (API Output Mode) a 1 para activar el modo de recibir notificaciones en el módulo receptor.
Kuropatula,
mira este link: http://todigi.blogspot.com/2010/05/xbee-obituaries-xbee-returns-from-grave.html
Después de un buen rato con unos módulos que no me funcionaban esto me ha funcionado a la primera.
Hola Carlos, bueno, por fin puedo compartir algo.
Si un router queda por alguna razón en otro canal, se puede seter (previamente) el campo NW (Network Watchdog Timeout) para que si en un tiempo determinado como 3*NW minutos, el módulo no recibe ni envía datos (y recibe ACK), se desconecte de la red y busque una nueva. Para que busque una nueva, el parámetro JV (Channel Verifcation) debe estar en 1. Yo particularmente también tengo configurado JN (Join Notification) para que mi coordinador sepa que hay un nuevo módulo presente.
En conclusión, para que un módulo no quede accidentalmente fuera de la red, hay que enviarle datos desde el coordinador en un período menor a 3*NW minutos.
Hola, había posteado algo y creo que no se guardó bien. Lo escribo otra vez.
Respondiendo a lo que me pasó previamente de cómo solucionar si un módulo queda fuera de la red, comento lo siguiente.
Si un módulo por alguna razón queda fuera de la red (queda en otro canal) se puede setear (previamente) el parámetro NW (Network Watchdog) el cual saca al módulo de la red si este no recibe datos o ACKs (o sea, algo previamente enviado y que llegó satisfactoriamente) por un tiempo determinado por 3*NW en minutos. Al pasar ese tiempo si el módulo no recibió datos, sale de la red. Para buscar una nueva red el parámetro JV (Channel Verification) debe estar seteado a 1. Para que el coordinador se entere que hay un nuevo módulo en la red, el parámetro JN (Join Notification) debe estar a 1 al igual que el AO (API Output Mode) a 1 para activar el modo de recibir notificaciones en el módulo receptor.
Gracias por la aporteción…