Wednesday, March 23, 2011

Using XBee Broadcast

OK, I have no life; I admit it.

I modified the sketch for the power monitor to transmit the power reading over my (brand new) XBee network. Now I can plug an XBee into my laptop and watch the power reading stream by every five seconds.  That was cool so I used a breakout board from SparkFun and added an XBee to the House Clock.  Now I have the time coming out every 10 seconds from it as well.  There were a couple of reasons for doing this:  First, I wanted to see what happens with collisions.  Second, how well do these things work over time?  They seem to handle collisions (where they both try to transmit at the same time) perfectly.  Never have a short or garbled frame from them.  The second item will have to wait a few days.

What was amazing is how easily it was to install the two devices.  I simply hooked up power, ground and transmit on one of them and found someplace to mount it.  It just worked fine, the very first time.  Not often one has this kind of thing happen.  Of course, I spent a couple of weeks figuring out how to use them.  The two deployed ones are running in AT (transparent) mode and just sending broadcasts so there is something on the network a lot of the time.  This is NOT the way one would work if there were battery operated end devices out there.  The battery devices would be on most of the time catching the broadcasts, but for now, this is a fine way to get more experience.

And yes, it is during peak period and I'm using a little over 700 watts.  This is a really good number, so far my demand number is running 1.4KW and my bill has stayed low.  Note that this is with my new swimming pool pump running water through my solar heater.  That used to take 2800 watts all by itself so I couldn't run it at all in the afternoon.  I'm so proud.

Monday, March 21, 2011

Still messing with XBees, probably will be for a long time

I just published my findings on XBee implementation.  It's really not the fault of the designers of these little devices that they seem hard to use.  Anything that will set up its own network and handle store forward without operator intervention will have some things that are counter-intuitive and difficult to understand.  Early results are that these devices work really well and can do a ton of stuff for the home experimenter.  However, there are some gotchas that aren't mentioned by most of the tutorials on the web.  I'm not sure why this is since I ran into them right off the bat and had to overcome them to move forward.  So, take a look at my XBee page to see the kind of problems a new user will likely encounter.

I also updated the Power Monitor page to include the schematic.  I'm not going to figure that thing out again.  I'll probably put the new sketch in for transmission over XBee at some point, but currently I'm changing it every couple of days.  The device is now off the breadboard and actually has parts soldered down.  I guess I should post a new picture as well.....

Wednesday, March 9, 2011

First XBee running

Spent most of the day rebuilding the power monitor in the garage and interfacing it to an XBee.  I had forgotten how I built the monitor so I had to create the schematic by reverse engineering then take it apart and rebuild it.  This time I'm keeping the schematic!.  Anyway, I learned a lot more about the XBee module that I haven't seen online in one place.  I'll record as much of what I found out as I can remember for the next person that has to overcome some of the same problems.

Anyway, the power monitor is serving the power levels on both wifi and XBee.  I plan on modifying the code in the satellite clock to serve the levels on wifi and forward them to Pachube so I can take the broken wifi adapter out of the power display and get the data I need from the satellite clock for display.  This is a serious redo of the architecture I originally envisioned, but what the heck.  I'll have to serve the time and power levels over the XBee network and I haven't quite decided how I want to do that yet.

However, there's nothing to prevent me from using the XBees just like small web servers and allow them to be interrogated by the coordinator radio.  The coordinator can simply poll each XBee for data and then hold it for an internet request.  This doesn't have to be too hard to get working.  This will probably mean I have to go into API mode on the coordinator radio and implement some kind of round robin interrogation to gather data, but that is somewhat doable if I can get good documentation on the API mode.

For those of you that didn't understand most of what I said, I'll be documenting this stuff as I go along.  It's really not that hard, just strange sounding.

Tuesday, March 8, 2011

Time to rebuild some stuff

I've been experimenting with XBees and they seem to work if you try hard enough and follow enough conflicting instructions from various places on the web.  The problem with these little devices seems to be that there are just too darn many models of them with differing firmware to run.  Add to this the intricacies of protocol layers and libraries written by computer science majors that weren't given any usability reviews and you have a mess.

I got mine to work.

So, I'm going to pull the power monitor out of the garage and modify it to use both XBee and wifi communication to push the power readings out.  Then, I'll start implementing other devices based on the ZigBee protocol around the house.  I'm going to avoid the libraries if I can.  Those things may make it easier to code, but they make it infinitely harder to understand for normal people.

The two thermostats that control the heat pumps will remain ethernet, they are wired devices and work quite well so I won't fix what isn't broken.

No wonder I can't pick up girls at a bar.........

Saturday, March 5, 2011

Hardware failure.....darn

After a few months of working perfectly I had a WiShield die.  It failed in a rather obscure way though; the darn thing is causing my power display to reboot every 2.5 to 3 minutes.  The interesting part of it is that the code I had for recovery worked perfectly and the device reboots and just keeps on trucking.  The time even updates properly.  The most serious outcome is annoyance.  The other WiShield in the power monitor is working just fine.

Just to add insult to annoyance, Asynclabs.com hasn't been updated or attended to since early December last year, so just replacing the hardware isn't an option.  The forum has lost a lot of interest and people are looking elsewhere for wireless solutions.  So, I've dug out a couple of Xbee radios and have started a project to populate them around the house as a replacement for wifi.  Granted, wifi is fun and easy to monitor and the ZigBee protocol is a pain, but I can create a gateway at the coordinator node and forward whatever I need to the wifi from there.  Besides, we NEED a simpler method of using the XBee devices.  If you look around the web, you see a ton of outdated instructions and people looking for help to get these things running.  I suspect a lot of the XBees sold are in boxes on a shelf somewhere because most folk just give up on making them work.

But, let's be real about this.  An extendable network that has acknowledgement and forwarding would overcome a lot of problems we face monitoring and controlling things.  The extremely low power consumption won't hurt either.