The continuation of this post is here <link>.
So, since I have the little Pi working with the internet, how about getting an XBee hooked to it and start receiving data from my home network? Well, it isn't hard to hook an XBee up to a Pi; the little device uses 3.3 volts and has an output pin, so I hooked one up. Four wires later, I had the XBee attached, powered and ready to go. Of course, the serial port (the only one on the Pi) is already used for a console, but there's (again) a thousand web sites out there that show how to change the init files to allow the serial port to be used directly, so I used one of the examples and freed the serial port for use.
A quick aside here. In looking around the web, I haven't found a single instance where someone successfully hooked a Pi up to an XBee and did something real with it. This didn't bode well for me, I want this thing to monitor a network of a dozen XBees and keep the devices they're attached to under control, not print pretty messages on the screen. It actually looks like a lot of people buy the Pi because it's cool and don't do much besides bring up a little web server on it.
But, the first thing is to see how I can read data from the XBee on the Raspberry Pi. So, prowling around I found an XBee library for Python and it seems to support everything I need as well as some things I might want to use someday. I installed it on the Pi and wrote a little test program to see what happens:
This actually wasn't as simple as it looks. This tiny little piece of code took almost all day to get to work and gave me a lot of trouble. Sure, it looks easy, but that's after failing over and over again. Most of my problems came from not having a clear example to work from and a horrible dearth of documentation. As usual, libraries provided by community efforts have minimal documentation, but this was an example of even less than that. There was also problems with not having any description of the proper XBee settings. For example, the author wrote that the XBee had to be in API mode, so following the Andrew Rapp library example, I set it to API mode 2. I got nothing. That led me to look at the code for the library and it turns out this library uses API mode 1 by default. Switching to API mode 1 allowed me to actually see data. And, there were a number of problems like that.
Another one that drove me nuts for an hour or so was that he (the author) sees the XBees as either Series 1 which uses different packets or Series 2 which is ZigBee based (mostly), but requires you to use special classes for each of them So, if you import like this:
from xbee import XBee
I won't work at all using a series 2 XBee running the various ZigBee software. It will work with the older software. That's why the example above has:
from xbee import ZigBee
The author didn't understand that the series 2 devices can run multiple styles and versions of the protocols.
So, I can read XBee packets and pick the data out of them to do something with, but now along comes another problem. All he supplies is a blocking read. That's about useless for any project that needs to be able to catch packets and do something else at the same time. He does have an asyncronous read in the code, but it uses threads to set aside a process that handles the XBee interaction, but since threads can't share data, it would require interprocess communication or queues to pass the data around.
Something like that takes all the usefullness out of an incredibly simple device like the XBee. If you have to have multiple processes, queues, locks, and such to read a message, no one is going to bother.
I'm still looking at it, but this particular path doesn't show much promise so far.
So, since I have the little Pi working with the internet, how about getting an XBee hooked to it and start receiving data from my home network? Well, it isn't hard to hook an XBee up to a Pi; the little device uses 3.3 volts and has an output pin, so I hooked one up. Four wires later, I had the XBee attached, powered and ready to go. Of course, the serial port (the only one on the Pi) is already used for a console, but there's (again) a thousand web sites out there that show how to change the init files to allow the serial port to be used directly, so I used one of the examples and freed the serial port for use.
A quick aside here. In looking around the web, I haven't found a single instance where someone successfully hooked a Pi up to an XBee and did something real with it. This didn't bode well for me, I want this thing to monitor a network of a dozen XBees and keep the devices they're attached to under control, not print pretty messages on the screen. It actually looks like a lot of people buy the Pi because it's cool and don't do much besides bring up a little web server on it.
But, the first thing is to see how I can read data from the XBee on the Raspberry Pi. So, prowling around I found an XBee library for Python and it seems to support everything I need as well as some things I might want to use someday. I installed it on the Pi and wrote a little test program to see what happens:
The Python Script
#!/usr/bin/python
import serial
from xbee import ZigBee
serial_port = serial.Serial('/dev/ttyAMA0', 9600)
zb = ZigBee(serial_port)
while True:
try:
data = zb.wait_read_frame() #Get data for later use
#print data # for debugging only
print data['rf_data']
except KeyboardInterrupt:
break
serial_port.close()
import serial
from xbee import ZigBee
serial_port = serial.Serial('/dev/ttyAMA0', 9600)
zb = ZigBee(serial_port)
while True:
try:
data = zb.wait_read_frame() #Get data for later use
#print data # for debugging only
print data['rf_data']
except KeyboardInterrupt:
break
serial_port.close()
This actually wasn't as simple as it looks. This tiny little piece of code took almost all day to get to work and gave me a lot of trouble. Sure, it looks easy, but that's after failing over and over again. Most of my problems came from not having a clear example to work from and a horrible dearth of documentation. As usual, libraries provided by community efforts have minimal documentation, but this was an example of even less than that. There was also problems with not having any description of the proper XBee settings. For example, the author wrote that the XBee had to be in API mode, so following the Andrew Rapp library example, I set it to API mode 2. I got nothing. That led me to look at the code for the library and it turns out this library uses API mode 1 by default. Switching to API mode 1 allowed me to actually see data. And, there were a number of problems like that.
Another one that drove me nuts for an hour or so was that he (the author) sees the XBees as either Series 1 which uses different packets or Series 2 which is ZigBee based (mostly), but requires you to use special classes for each of them So, if you import like this:
from xbee import XBee
I won't work at all using a series 2 XBee running the various ZigBee software. It will work with the older software. That's why the example above has:
from xbee import ZigBee
The author didn't understand that the series 2 devices can run multiple styles and versions of the protocols.
So, I can read XBee packets and pick the data out of them to do something with, but now along comes another problem. All he supplies is a blocking read. That's about useless for any project that needs to be able to catch packets and do something else at the same time. He does have an asyncronous read in the code, but it uses threads to set aside a process that handles the XBee interaction, but since threads can't share data, it would require interprocess communication or queues to pass the data around.
Something like that takes all the usefullness out of an incredibly simple device like the XBee. If you have to have multiple processes, queues, locks, and such to read a message, no one is going to bother.
I'm still looking at it, but this particular path doesn't show much promise so far.