This ought to be simple, but I have searched all over for some help and I can’t find anything. So…
I would like to use XBee modules to create a simple automobile presence detection service as part of my home automation system. The idea is to mount an XBee/ZigBee module in each car, then whenever that module connects to or leaves (that may be harder) the network I could trigger something on the event.
I realize this is low security, and for the applications I have in mind that is not an issue. But, the question is what do I need to do to set up the Xbee modules (I have a couple of XBee Pro modules at the moment to play with) for this application (I.e. do they need to be in API mode) and then what, if anything, do I need to set in the Coordinator to get the join/depart events, and finally, what do the events “look” like.
FWIW I will probably write this in Python.
I am sure all of this is well documented, so a pointer to the right docs or examples is probably all I need.
Thanks for the quick response. I was hoping the Cordinator could generate an event so the Host processor could be essentially passive. However, maybe my thinking was upside down. Perhaps I should place the responsibility for notification in the car. If a processor (eg arduino) attached to the Router knows when a network has been joined, it could message the host processor.
So, does the Router tell an attached processor when it is connected to a net?
So, does the Router tell an attached processor when it is connected to a net?
Not that I recall. The attached processor must query the Router.
How far did you get on reading the XBee document???
Its downloadable for Digi’s web site.
A method that might work for you is to have some data sent from the Router/End Device XBee to the Coordinator continuously (like maybe once every 10-30seconds). Then if the Coordinator receives this data the car is within range. If the data is not received for some time period, say 2 minutes, then the car is not within range.
Again read the XBee Doc for possible ways to get the XBees to do what you need.
waltr:
…How far did you get on reading the XBee document???
Its downloadable for Digi’s web site…
Well, I didn’t read the entire document. But, I did read a lot about network joining.Enough to learn:
Joining Announce
All ZigBee devices send a ZDO Device Announce broadcast transmission when they join a ZigBee network (ZDO cluster ID 0x0013). These frames will be sent out the XBee’s UART as an Explicit Rx Indicator API frame (0x91) if AO is set to 1. The device announce payload includes the following information:
The Associate pin [pin 15, DIO 5] indicates the network status of a device. If the module is not joined to a network, the Associate pin is set high. Once the module successfully joins a network, the Associate pin blinks at a regular time interval. This is shown in the following figure.
So, it looks like a mobile Arduino/Xbee unit could “know” when it connects to a network (either by looking for the ZDO ANnounce broadcast, or by monitoring DIO5. It could then send some specific command(s) to the HA system.
And, I also tried searching for xbee proximity detection and found [this blog with pretty much the same suggestion you posted. Sending a continuous data “beacon”.
This route looks easier to get going, but does not offer much in terms of fine grained control. The Host processor would only know that the remote unit had appeared.
So, as soon as my shield gets here (tomorrow I hope) I will give some of this a try… and report back.
Ok. Using a SainSmart shield I now have 2 XBee Pro (ZigBee) modules talking.
What works: The Arduino is sending a fixed string every second and I can key off that from a Host processor Python script listening to the Coordinator device.
What does not work:
According to the manual (XBee®/XBee-PRO® ZB RF Modules, 90000976_M 9/25/12):
All ZigBee devices send a ZDO Device Announce broadcast transmission when they join a ZigBee network (ZDO cluster ID 0x0013). These frames will be sent out the XBee’s UART as an Explicit Rx Indicator API frame (0x91) if AO is set to 1.
But, there does not seem to be an AT AO command. Also, there is no mention of such an AT command, nor of the ZDO Device Announce function in the manual "XBee®/XBee-PRO® RF Modules, 90000982_J 12/5/2012. FWIW, my Xbees are marked IC:4214A-XBEE Note, I am presently running both XBees in AT mode.
The LED tied to DIO5 on the Router blinks continuously, even if the Coordinator is disconnected. The command ATD5 shows 1.
So, until I can either get the ZDO announce to work, or get DIO5 (Pin 15) to change states when the XBee is on/off the network, I cannot proceed with my preferred plan of sending data only on an “associate” event.
What is the Firmware Version in your XBees. This will ID exactly which features are available.
These frames will be sent out the XBee’s UART as an Explicit Rx Indicator API frame (0x91) if AO is set to 1.
This is for API firmware only. This is not sent out the UART with AT firmware.
The AT AO Command is described on page 132 of the XBee 90000976_M document. under Serial Interfacing Commands. It is an API option.
I run XBee ZigBee network. The Coordinator is running API firmware and is connected to a Host computer. The Host computer program is coded to send and receive API command packets. This gives the best options and has other benefits.
One important benefit is that every received packet has the sensing XBees address. Therefore if software can determine which XBee in the network send the data.
Use Digi’s X-CTU utility to change the firmware to API coordinator (Version 21xx). One warning first: API packets must be exactly correct including the checksum, else the packet is silently ignored. This can make getting this to work a bit frustrating but is well worth the effort.
The Router/End device can run AT firmware and still send correctly to the coordinator. Then with the AT AO = 1 set in the coordinator, the coordinator will send out the UART (to Host computer) a type 0x91 Frame that will have the address of the joining XBee.
The firmware version is: 10EC. Hardware is: 1745 (my XBee is an XB24-AWI-001 revE)
When I read the Modem Configuration (in X-CTU - running in wine on OS X) I see Modem XBEE: XB24 & Function Set: XBEE 802.15.4 Though I have not changed that yet.
So, I am assuming (still new at this) that I need to select a different Modem, probably XB24-ZB, since it shows an AO option, and then turn on API mode (ATAP1) and set AO. Is that right?
Also, any idea why I get the constant blinking in DIO5/Pin 15? If I could get that to work I might not need to switch firmware - or, maybe I need to switch firmware to GET that to work?
EDIT: So, after digging around it turns out that Instead of the Series-2 XBees I ordered (not from Sparkfun) I got Series-1. So, that probably explains most of the issues I’ve been having. Back to the manuals.
EDIT++: I have the End Point (Arduino) in API mode and it can use the status response from a send to tell if a packet has been received. So, I can just loop and send, loop and send until I see a response. At that point, if I wanted to send some other data, I could. Still, it would be nice to be a little more deterministic about being connected. Pin 15/DIO5 looks like the way to do that. But, it just keeps on flashing no matter what??? Time to go dream on this.
Thanks for the document number. And, Yes, the associated LED blinks constantly. I have looked at the docs pretty carefully and cannot find a setting that will make this work. I will try contacting Digi.
Ok. For those that care (probably nobody) here is the answer: The Series 1 XBees do not really support use of DIO5 to determine association. It can be made to work, but it requires intelligence on the remote end (end-point) to determine when the association is broken (like getting a send response error), and then issue an ATDA command to change the LED state. Of course, if the end-point knows that it can’t send, then who cares about the LED!
In the end, I think I will do what waltr first suggested, just send periodic ATND commands on the Host/Coordinator. If I do that, then all I need at the remote end is an XBee (and probably an explorer. for power), no Arduino, no nothing. Pretty simple really.
Series 1 don’t support ZigBee and that’s a good thing for simple non-mesh applications.
You have the choice of not using a PAN Coordinator at all. SImplifies. There’s an AT command to disable PAN coordinator, make a devices end devices, disable association required. That done, you simply send a frame to the desired destination 64 bit MAC address or the broadcast address, with MAC ACKs enabled.
The Blinking LED is the association LED and you can change its meaning (GPIO bit purpose) via AT command.
So I have learned. The ease of access to the rssi information on the series 1 devices is nice. OTOH, it would be nice to be able to create a mesh network so an XBee does not have to be within range of the destination XBee.
I understand I can disable the PAN and coordinator. However, I am not sure how, in my application, I gain anything from doing that - though I don’t see any harm either.
At this point I think I have a working architecture that test Ok on the bench. The remote/mobile unit is on an Arduino and transmits a “hello” packet to the host every 10 seconds. As long as the send packet status is 01, it sticks with the 10 second retry. However, if a send succeeds (00) it switches to 1 second timing. This lets the host use the rssi numbers to determine whether the car is approaching or departing.
It would be nice to have the mobile unit know when it had joined the network, and only then send packets. But, that does not seem possible.
It would be nice to have the mobile unit know when it had joined the network, and only then send packets. But, that does not seem possible.
One way to do this would be to program the remote XBees to repeatedly send measurements from their analog or digital I/O pins. On the ZB modules, you do this with the IR, D0-D8 and P0-P2 commands. The remote XBee will try to join the network whenever it can. Whenever it joins the network, it will begin sending sample measurements automatically. In this case, the remote radio would just need a 3.3V power supply – no external microcontroller. And it doesn’t matter if anything is connected to the pins, since you’re just trying to send frames/packets. The home device (with the coordinator radio) would just watch for frames and act based on the long source address.
To do this, you will need to run the coordinator in API mode. There’s a nice python library for this at http://code.google.com/p/python-xbee/ . One thing to watch out for: if AO is not set to 0 on the coordinator, the IO samples will come in as the wrong frame type (0x91 instead of 0x92), so the python library won’t parse them correctly. You’ll still get the frames, just as un-parsed data. This probably isn’t a problem in your case, but it caused me some headaches.
I don’t know how much of this is possible on the Series 1 radios. But I think you can also re-flash Series 1 (802.15.4) radios as Series 2 (ZB) using X-CTU.
).](