I really didn't want to get into the mess of trying to get another standard serial port working because I eventually want LEDs for indicators of things that are important and maybe even a display that I can put words on. Heck, I could decide to put voice on it at some point. So, since the Pi comes with two USB ports, I decided to move both of the XBees to USB. I started out with the USB explorer that I have to program the XBees:
I've had this board a long time and it just works. Never had a problem with it, so I just plugged it into one of the USB ports on the Pi and changed my code to point to it. It worked after a tiny bit of messing around. Now I could control my own stuff and read the Smart Switch as well. That proved that it could be done so I got two of these:
I chose this board so I could use a short USB cable to connect it, avoiding the problem of the bigger board above not fitting. With these plugged into the Pi, I could still control the house and have all my GPIO pins available for whatever else I decide to do someday. But, as usual, there was a problem. See, USB is designed to be plugged and unplugged so you can change devices on the Pi, that unfortunately means that the address of the XBee will change each time you unplug it from the USB port. So, one time I would have the smart switch on /dev/ttyUSB0 and the next time it would show up on /dev/ttyUSB1. Makes coding for it more complex, and I really don't want complex right now.
It turns out that there is another way to connect to it. Under the directory /dev is another directory 'serial'; looking in /dev/serial, I found two other directories by-id and by-path. The by-id directory holds the device ids of the USB to serial chip and that doesn't change as you plug and unplug it. So, I changed my code to define the serial port to this:
XBEEPORT = '/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901QLG3-if00-port0'
Yes, it's long and obscure, but that's what variables and comments are for. It's also hard to type in, but that's what copy and paste are good for. All in all, not a bad way to go as long as I don't reverse which little board I have the XBee plugged into. Remember this little trick when your USB device seems to disappear.
So, now I have all the GPIO pins available; wonder what I'm going to plug into them.
I just came across your blog and have found it very useful. Thanks for documenting this level of detail.
ReplyDeleteOne typo in this post - you say "USB ports on the XBee" vs the Pi.
oops, Thanks. I fixed it.
DeleteYou could also look into udev. It allows you to create rules and custom /dev names based upon device ids.
ReplyDeleteThank you. Frankly, I had no idea how dynamic devices worked and your pointer opened up an entirely new area to mess around. It's totally possible to write a rule that can find an XBee that was just plugged in and tell me all about it. I'm going to file this away for later in my projects when I get more devices to plug in and play with.
DeleteHave you ever played around with a Digi Zigbee Stick? It seems to basically be an XBee in a USB stick, acting as a coordinator.
ReplyDeleteNo I haven't; I ran across it a couple of times and the price turned me off. For $17 I can get an XBee and for another 20 I can get a USB adapter for it. I can get even cheaper than that with an FTDI adapter hooked to the serial pins, but that's ugly. So, for $37 (plus shipping) I can have a full blown USB XBee device and it will have all the capabilities. I think Digi made that dongle to satisfy customers that wanted a more turn key solution that what I've been using. It comes as a coordinator as the default and could be used to set up a ZigBee network for a set of light switches.
ReplyDeleteNice idea, but I'll stick with the full capabilities and cheaper solution. Besides, I have about 5 of them in a box I have to use up first.
Is there a way to rig this to work with smart things hub?
ReplyDeleteProbably, but I haven't looked at one of those.
Delete