Wednesday, July 23, 2014

Arduino, XBee, and a Freezer Defroster

I have an upright freezer.  Living a ways from town and the climate make this necessary.  I load a cooler in the car, go to the store get my frozen goods and some ice, pack the food in the cooler with the ice and come home.  When it's over 114F outside, you have to take some special precautions to keep the food from becoming a puddle in the back of the car.

A while back I discusssed how my freezer uses power; it's relatively efficient except for one item, the defroster <link>.  A freezer's defroster is a combination of a timer, a heater, and a thermostat to monitor the temperature of the evaporator.  What bothered me was the timing of the defrost cycle.  Every 11 hours or so, it would defrost, and this meant that the heater would be on during peak usage period.  Since I pay a lot for peak usage it would be nice to have better control of the timing of the defrost cycle.  So, an examination of the defrost circuitry showed a clear opportunity for an accurate timer and a simple SPDT relay as a replacement for the conventional method.

So, since I had a couple of arduinos that weren't doing anything, I got one of these:
This shield has both the relays and the XBee socket I wanted to use, perfect.  I have a few XBees that I picked up, so I configured one and plugged it in.  A little code later I was reading my house clock transmissions and setting off a timer every 12 hours.  I chose 08:15 and 20:15, times that are outside the peak period, now all I had to do was wire it in and test it.  Here's an image of the schematic of the circuitry:

I circled the defrost timer to make it obvious.  Notice that it simply switches between the compressor circuitry and the defrost heating assembly.  This makes it simple to wire into the circuitry, so I took out the timer and used the plug that went to it to wire into the relay of the arduino shield.  It was ready to test, and I hooked up a wall wart power supply and plugged the arduino into the same power monitor that I use on the freezer.  It worked like a charm.  Now my freezer goes into a defrost cycle at the programmed times and runs for 30 minutes.  I checked the evaporator pretty often to make sure it was running the heater long enough and everything seems fine.

While I was programming the device I threw in some code to allow me to set off the defrost cycle any time I want to as well as having it report through the XBee the status of the defroster.  This leaves a clear opportunity for installing a temperature sensor, compressor sensor, door sensor, etc.  Over time I may well do some of these things.  I could go nuts and use the arduino to control the entire freezer; these appliances are relatively simple devices and a little arduino and some relays could take over the entire operation.  I'm not sure there's any real point to that since it works well already, but I may get bored some hot summer day.

A temperature sensor would be pretty nice though.  I could send the temp to my house controller <link> and set up a piece of code to check for the temperature getting too high.  A too-high situation could easily send me mail or light up an LED somewhere to alert me to a problem.  Or both.   

Here's a chart of my freezer power usage over a 24 hour period:

The freezer is the black line.  Notice the two humps, one at 08:15 and the other at 20:15?  That's the increased power usage from the heating units (one on the evaporator and the other on the drain tube).  Now I have this power using mode scheduled for the lower rate periods.  With the new LED lights I installed in the freezer to replace the incandescent ones, this device is getting cheaper to run all the time.

Before you tell me that the wall wart and arduino probably use 5 watts continuously, remember my goal was to move the higher usage away from peak billing periods.  I'd rather have 5 watts continuous than 400 watts for thirty minutes during peak.  Peak usage is really expensive in my area.

No, it's not a major savings, but every little bit helps.  Heck, I'll probably get back the money I spent on the shield and arduino in ... what ... 10 years or so.

Saturday, July 12, 2014

OpenWrt on the HLK-RM04, Reality Check

There's a ton of pixels out there about OpenWrt.  It's open source router software that can do an excellent job of expanding the capabilities of some routers way beyond what the manufacturers provide.  I had an OpenWrt router for a while, it eventually went up in smoke and I've been using what the DSL provider recommends ever since.  However, I ran into the HLK-RM04 <link> through the suggestion of a reader and decided to look into expanding the capabilities of this little device and OpenWrt seemed like a good choice to use as software for it.

There's a few threads on the OpenWrt forum and a couple of interesting repositories on github that relate to the device and they look reasonably promising,  So, I read the threads, and all of them suggested either picking up a binary they created or building my own.  There were involved instructions on the build, so I thought, "Why not?"  Thus began my misadventures with building OpenWrt for the HLK-RM04.

First, I tried the binary that was created by one of the guys that frequents the OpenWrt forum.  This binary seemed to have great possibilities since, once you have a version of OpenWrt running, you can add to it and update it pretty easily.  So I followed the instruction to install the uboot boot loader and then installed the image that the guy put in github.  This process went pretty well, but very little worked on the router.  I could get an ethernet connection, but wireless and any outside access wouldn't work.  When I tried to enable wireless, the rm04 ran out of memory.  Fine, I'll build my own and learn about the configuration of the software while going through the process.

So, I thought to myself, I really should make sure I could restore the rm04 to factory settings.  Oops, too late.  Once you install uboot on the device, the factory software is gone and can't be recovered.  Even though it's in a different part of the device, there just isn't any way to get to it.  Sure, I could have spent about a month learning the ins and outs of the JTAG interface and bit banged myself a backup, but that didn't seem like a valuable skill to pursue.  There were two reasons I was tardy in looking at a way to back it up.  The first was because there really aren't any useful instructions out there on how to backup.  Sure there's a OpenWrt <link> wiki page on it, but I couldn't get enough information out of it to even attempt anything.  The 'How To' was full of 'could', 'maybe', and 'beware', with no real examples.  Like I said, I'd have to learn the intricacies of JTAG to have a chance.  The second was because there isn't a serial interface to control the chip.  There's a serial line, but you can't log into it and do anything.  I really don't understand why manufacturers do this, do they want to sell these things?

I guess I better make OpenWrt work.

I downloaded OpenWrt, configured it the way the instructions said and started make.  Six hours later, it failed.  Following the instructions, I used the V=s option to see what was failing.  It turns out that OpenWrt installation only installs part of the code, the makefile goes to various servers and their mirrors and downloads more.  The file it failed on was a little over two meg, so I tried it again.  Of course, it failed again.  I set up a little script to restart the make if it died and went to bed.

The next morning, it was still trying to load files.  Yes, I got the two meg and several others, but the files were getting enormous.  I watched it fail five times on an eight meg file and decide this wasn't working, so I hunted down the retry count and timeout amount in the scripts and changed them to 25 retries and a full minute timeout.  Ran it again and it seemed to stumble through some of the downloads.  However, when I watched the log, it was failing quite often with a 404 error on a file that it had been previously reading; what?  So, I changed the retry to 50 to allow for server errors and let it go again.

It chugged along for many hours and then I noticed that the file size was getting larger and larger.  There were files over 90Mb that were trying to be loaded.  The internet, my little machine, and bad luck were really conspiring because at one time I noticed the load speed was two bytes (yes bytes) a second.  Obviously, this wasn't going to work, at least in the time I have left on the planet.

Time to try another tactic.  I saw three possibilities 1) Configure various things out of the binary version I had previously tried until I got the bare minimum and see what I could get running.  2) Download and install a version I ran across that said that they had already stripped it to almost nothing.  3) Try to get the original software from somewhere and put it back, then start off with some other tactic.

I did all three.  I went to the OpenWrt image I had running, but ran out of memory, and started cutting things out.  Problem with this was that when I cut something out that I shouldn't, the little board died and I had to start over cutting things out.  This got tiring, but I got really good at loading software on the board and backing up the OpenWrt config files such that it was only tedious to restore it, not a real pain.  However, I never did get enough out of the distribution of OpenWrt to allow wireless to run without it failing from running out of memory.

So I went to step 2 above and loaded a bare minimum system on the board.  This one held some promise, but I couldn't get past the configuration changes necessary to make the board do something useful.

Step three was now the remaining option.  I dropped a note to the manufacturer asking for the very latest version of the boards software.  I hoped they would send it then I could try loading it on the board with uboot to see if that would get me back to the starting point.  I also dropped a note to a person that had posted that he had the manufacturer's files and had used them.  I fully expected to get no response from either of them, ... but:

The other customer that had the files posted them to github so folk could pick them up there.  So, the last two versions of the board's OS are out there to be tried.  The manufacturer actually answered me and sent a lot of documentation that appears to be correct.  They said they would send me the files as well, but I haven't received them yet.

This was totally unexpected.  Two total strangers responded extremely rapidly and there are possible solutions that I can try.  Gathering up enough cables and wires to make a huge mess, I tried loading the factory files to the board with uboot.  No luck there, I got the horrible message, "Bad Magic Number," and the boot failed.  I tried to look into the magic number, thinking that I could change it and get the file to execute.  No such luck.  One (get this only one) person had fought the battle against this message and posted about his trials <link>.  Turns out that it wasn't just a magic number, it's a 60 byte header that includes compression type, CRC checksum, and a bunch of other stuff I didn't know and couldn't think of a way to find out.

I'm out of options.

It's not as bad as it sounds though.  Remember, I bought this board as a tool that I could use to monitor devices and possibly make changes with.  It was truly compelling because it's relatively small and cheaper than most solutions out there.  Wait, cheap?  I ordered another chip for the board.  Since the board is just interfaces and mounts, a new chip will give me a second chance to try and get everything I need working, and I have loads of experience with it now to keep from making some of the mistakes that got me into this mess.

Back when I started experimenting with the board I managed to make a reasonable 802.11 b/g/n gateway with it.  That was a nice bonus because it meant that I definitely could get some use out of it as a wifi device.  If I can get the serial port to send data over wireless, that would just be icing on the cake.  That's worth another 10-12 bucks investment.  If I'm lucky, the newer software, better documentation, and experience could lead to a nice versatile addition to my network.

The problem with OpenWrt is that it is too versatile.  Over the years many people have contributed to the project and it has grown to the point where one needs a quad processsor running at light speed to build it the first time.  Of course that also means a quantum link to the ethernet or access to the buss of the server.  If you can get it loaded and built, you've actually got something that you can do something with because the ability to update it is really nice.  It's that first time that will test your patience.  When I finally gave up, it was over 2G and still growing; allow for this in your plans.

Now I'm waiting for the new chip and holding on to the updated manufacturer's software.  I have notes on how to do things that shouldn't kill the board and understand a whole lot more about the device.

C'mon mail.

Saturday, July 5, 2014

Playing with the HLK-RM04 Serial to Ethernet Convertor

I went on ebay and got me one of these:

This is a HLK-RM04 serial to ethernet device.  When I got it, I thought, why does it have two ethernet plugs?  Why does it have a wireless antenna plug there too?  Does it work with TTL serial like the Arduino, Raspberry Pi, and XBee do?  So, I started playing with it to see what it could do.

I found out that it is probably an incredible little device.  I couldn't get it to sign on to my wireless network using the built in web server, the darn thing would try, but it just wouldn't connect.  So, I looked around the web and noticed that it had a 'secret' web page I could play with.  A lot more messing around and I found out that the software that comes with it is incredibly buggy.  No, I'm not surprised, just disappointed.  Why do folk that come out with devices like this hate doing reasonable documentation?  Why do the leave out significant features that could sky rocket their sales to the Makers out there?  Do they need these things as something to lower their reputation?


I managed to turn this little device into a wireless ethernet bridge that supports 802.11 b/g/n at full speed, which is a blessing to me because my old house DSL modem is much slower and starting to get a bit flaky.  Did you catch that?  I have a nice wireless interface to my network at 'n' speeds without spending a fortune.  Also, I can put one of these anywhere I have an ethernet plug and extend my wireless for a small fraction of what Linksys or Belkin would like me to pay.  It cost me less than $25 complete with wall wart and 2db antenna included. Free shipping too.

All I had to do was overcome the crappy software and disgustingly incomplete documentation.  There's even an article on how to load openwrt on the device, but I kind of want to avoid that if possible (enough eggs on the fire right now ... thank you).

First though, my device isn't exactly like the one pictured above; mine's a little different:

Notice that there's an RF shield over the components that handle the RF?  That's probably to maintain the various certifications.  It has a LAN plug as well as a WAN plug besides the two serial ports and wireless.  Talk about stuffing ten pounds in a five pound sock!  What I will eventually be able to do with this series of boards should be a lot of fun.

One of my readers suggested I use this board.  My original intent was to use the serial input to monitor my pool controller for more protocol decoding that I haven't gotten to.  He and I embarked on a project that I'll write up later, and I got really tired of wandering from the house outside with a laptop and a bunch of tools to hook up and gather some data.  The idea was that I'd put this board out there and just watch it from inside where the temperature isn't approaching 115F in the full sun.  I can't do that yet, I didn't conquer the serial input before I discovered some of it's other capabilities.

Just so you folk don't think I'm just teasing you, the 'secret' web page for the settings that the manufacturer wants to keep us from playing with is  See, this configurable router is complete.  It can do all the encryptions, routing, tunneling, UPNP, etc that the expensive devices can do.  Sure, it's not a gigabit device, but neither is my house wiring.  You could put this behind the DSL modem at your house and totally stop the phone company from looking around your network.  I know, that sounds paranoid, but it is the 21st century and they ARE out to get me.

So, go to the 'secret' web page on one of these devices and experiment away.  You could have a cheap working Wifi access point in about 45 minutes.  You'd have a second one in about 2 minutes; there's a little learning curve to it.  Setting it up as a bridge is really simple.  The hardest part was finding the place where I could change the SSID.  There's a couple of different places for this depending on what you configure the device to be.

Now I can replace the old DSL modem I'm using in the garage to extend my wireless as well as the flaky wireless on my connected DSL up in the attic.

I have a letter to the vendor complaining about how the serial configuration failed; maybe he can get me some better documentation or something.  Meanwhile, I may just hunt for a couple more of these little things.  The darn ethernet plugs and antenna would cost me as much as the entire assembly did.

Monday, June 30, 2014

Perils of Using Cloud Services

So far, I've been a fan of cloud services.  I say, "so far," because it's a great idea on the surface.  For free, or a small fee, web businesses provide storage, blogging, graphs, and many specialized services.  It seems like the perfect solution to problems that we little folk have.  Some of us want to investigate power (me), others want to share pictures, still others want long winded political diatribes, and there are sites out there that cater to us.

But (remember, there's always a 'but'), the darn providers want to constantly change what they provide and charge ever increasing amounts of money for the services.  I've talked about my disappointment with Xively (Cosm, Pachube) over the years as they got bought out by various companies and abandoned the ideals and price point they started with.  Some of the services start off with a bang and dwindle to a whimper decreasing services down to an almost unusable level.  Others unexpectedly change things and don't let you know in advance, or even after the fact ... you have to find out because things quit working (usually over the weekend), and it takes time and patience to ferret out what the heck they did.

In the last couple of weeks I've encountered this annoying activity in regards to my charts that are displayed on this site.  One day (a Monday naturally), all my charts based on Xively storage stopped working.  It took me a while to figure out what happened and fix it.  It seems that Xively stopped responding to the old Pachube URLs and didn't give any warning at all.  I checked their blog, site, twitter account and my spam folder, nothing.  So, I had to visit each use of the charts and change the word 'pachube' to 'xively' to make it work.  Not a bad thing, and it wouldn't have mattered if they dropped me a note or put something somewhere that this was going to happen.  But, it was really annoying to have it sneak up like that.

Then, the charts stopped working again.  Nope, it wasn't Xively messing around, this time it was dropbox.  They tightened up the security and forced their old http links into https.  This is normally considered a good thing, but when you have a number of embedded charts that all look at http, it is a pain to change all of them.  Especially when they didn't say a word about it.  Nope, it didn't come in the email, no mention anywhere I could find.

After chasing down the various references, I got them fixed and working again (I think).

This has happened to me before; actually several times, google dropped support for their .png charts, I had to scramble to find another way.  A cloud storage service disappeared, that's how I decided to move to dropbox.  One of the quicken services became Mint and the transition sucked for me; I just dropped that idea altogether.  Etc.

I still think Cloud Services are a good idea, but the specific implementations seem to be ridden with various problems we have to adapt to.  The biggest being some corporate know-it-all that decides to change things without communicating it.  True, it is their service and they can do what they want.  I have the choice of staying with them or leaving for something else that fits my needs or doesn't tick me off as much.

However, I also have the choice of grabbing one of the great new little computers, hanging a big ol' drive on it that I can pick up for a song these days, and rolling my own in-home cloud services.  I mean, how hard can it be to record the data I send up the wire locally?  A nice free database manager (there are dozens), a little front end code that listens to http, and away I go.  Sure, it'll expose a machine to the internet if I want to make it public (I do) and I'd have to actually invest in a real router to isolate the rest of the house, but I wouldn't be subject to the changing whims of some corporate MBA that will only hold the job for a few months before leaving for greener pastures.

I haven't decided to abandon the cloud yet, but it's getting more and more compelling all the time.

Friday, June 20, 2014

I'll try to explain XBee API Mode and How to Set it Up

I've gotten hundreds of questions on XBee API mode.  API mode is necessary for setting up an XBee network of more than three devices because AT mode (also called transparent) will cause fragmentation and mixing of data over time.  I have a post somewhere about this that explains my experience when I finally exceeded what the XBee was capable of when using AT mode <link>.

So, what is API mode?  It's simply a protocol between the serial port on the XBee and your controller.  Be it Raspberry Pi, Arduino, Galileo, whatever, you talk to an XBee through a serial port and what goes over the serial port isn't what the XBees send amongst themselves.  First, a simple picture:
I'm not an artist, so use your imagination.  The term 'API mode' refers only to the two serial links that connect your controllers to the XBee.  What goes over the RF link is not affected and shouldn't be; that's something that Digi takes care of quite nicely.

In AT mode, what you send out the port is what you want to be sent to the other controller.  You want, "Hello World," that's exactly what you send.  The XBee will collect the characters and put them in an RF packet and send them to the other XBee.  If the other XBee is in AT mode as well, it will parse the characters out and send them through the serial port to the other controller.  Simple, easy to understand, and the way almost everyone starts out with the XBees.

Now a little bit about API mode.  API mode allows you to shape a packet complete with checksum, destination address, and other things that give you control over what goes on.  It also allows you confidence that what you send gets to the other end complete and in one piece.  See, AT mode will send some of it, wait, then send the rest of it.  This depends on traffic and RF noise, so it's possible to get part of a message, then the rest of it later.  If you have a number of XBees, you'll actually get messages that have been mixed together and made unusable.  You get all the stuff that was sent, but it may be jumbled up.  API mode is the way to go after you've played with AT mode some to get a feel for things.

So, how to you set up an XBee to transmit in API mode?  I only work with Series 2 and later XBees, so everything here applies to them, if you're working with series 1, you're going to have to look somewhere else for examples.  Remember that API mode only applies to the serial links; I've labeled them in the drawing, so there are two things you have to change to get API mode on the XBee: the software you load on the device, and the serial interface you choose.

I use modem setting 'XB24-ZB' and Function Set 'ZIGBEE COORDINATOR API'.  These are found in the Modem Configuration tab of XCTU up at the top.  I always choose that latest software version on the far right.  Here's a picture to help you find it:

This software, once you load it on the XBee will give you API mode.  The XBees come defaulted to AT mode, so you'll have to download XCTU and change them yourself.  Of course, if you're programming a router, choose 'ZIGBEE ROUTER API' as the 'Function Set.'

Now you have to change the various parameters to be specific for your usage.  Things like Pan ID, Channel, that kind of stuff.  I address these things in other posts, so look them up there, or use one of the jillion tutorials out there.  Once you get that stuff in, you can set which API mode you want to use.  On the Arduino using Andrew Rapp's XBee library, you'll need to use API mode 2.  For the Raspberry Pi using the XBee package, you'll need to use API mode 1.  Don't worry, they will work fine together.  Remember above where I told you API mode only affects the serial link to the controller and not the RF link between XBees?  This is the beauty of these little devices, the mode doesn't change how the XBees talk to each other, just how they talk to the controller.

API mode is set under 'Serial Interfacing' a little bit down the screen, so scroll down until you find it.  The values are (duh) 0, 1, or 2.  Zero means no API, 1 is for API mode 1, and 2 is for API mode 2.  What's the difference?  I talk about this and the interaction of the various modes here <link>.  Why do I need different API modes on the different controllers?  Because the authors of the libraries wrote them that way and we have to adjust ... or heaven forbid ... write our own code to handle it.

Write the parameters to the XBee and you have now set up the XBee to work in API mode using whichever mode ( 1 or 2 ) is appropriate.   In case you need to save this configuration, there is a profile save button on the screen.  Use it to keep the various profiles you try over time.  You can simply reload it and avoid all of this next time.

One other thing: now you have to change the settings on the first screen of XCTU to talk to it properly.

About half way down the screen there's a box 'API,' check the 'Enable API' setting, and depending on how you configured the XBee, check the 'Use escape characters' box.  In API mode 1, you don't check it; in API mode 2, you do.

Now you have to change the code you're running on the controllers to use the new mode.  It's worth it because you can check the checksum on a message to see if it got clobbered on its way to you, address specific XBees so you don't have unnecessary traffic.  Use end devices that don't have a controller attached, just use the native pins on the XBee.  It makes the little devices much more versatile.  For examples, I have posts about some of the libraries on this blog, Just type XBee in the search box on the upper left and look around.

Saturday, June 14, 2014

Cell Phone Charging and Power Usage.

One of the comments on this blog made me start wondering about the little parasitic devices we have all over the house.  I've always assumed that they drew so little power they wouldn't matter when compared to to the kilowatt guzzling motors and heating elements we have in the larger appliances.  One little device that annoys me is the cell phone charger.  Every time the phone gets to a full charge it tells me to unplug the charger to save energy.  Sheesh, leave me alone, let me worry about how much power I'm using.

However, the commenter said his measuring device recorded 15 watts for several of his devices.  If I can confirm that, I may have to think about doing something since I have a bunch of them around the house.  So, I'll take on an annoyance and see what the power usage really is for my cell phone charger.

This little phone sucks 12 watts when it first starts out, so I need a really good wall wart that can supply over two amps to get the quickest charge.  Since I used the 'genuine' Samsung charger for this test, I let the phone drain down to (approximately) the same point and tried one of those 'Samsung' chargers that are available on Ebay.

Don't let the scale confuse you, this charger never gets over 1 watt.  Since my granularity (using this monitor device) is 1 watt, it could have gone a little higher or lower and still read this way, so I plugged in an amp meter in series and watched a while and it didn't ever go over 500 mA.  It doesn't have the stair steps of the real Samsung charger and took much longer ( less than an hour compared to over 2.5).  It looks like buying a real brand name may result in much, much better performance.  However, how the heck do you tell if it's really from the manufacturer?  Both of them are labeled 'Samsung' and they are the same form factor.  The ratings on the side are the same, so how do us folk out here in the world tell the difference?

I don't have an answer to this, and I'm certainly not going to buy a few hundred different ones and try them out.  I'm seriously thinking about making a load to test these things before I try to depend on them for anything.  If they fail the test, I'll do some serious complaining to the supplier.  The other thing I'm thinking about is putting together a power supply that will give me 5V at three amps reliably.  This would be useful to see how the charge characteristics of the phone look when it has enough current available.

Just for fun, I weighed each of them.  The real Samsung charger weighed 37 grams and the other one came in at 25 grams.  The real one has 12 grams more stuff in it, or thicker plastic.  Since I plan on using the fake for other things, I'm not going to dismantle it ... yet.  But here's a picture of the two of them:

The fake is the black one.  

Just to let you folk know though, there are two differences between them. 1. The real one has a UL certification on it, the fake doesn't.  That's really easy to overcome, they simply add another certification stamp to it.  2. The fake says 5.0 volt at 2 amp, and the real one says 5.3 volt at 2 amp.  Once again, that's easy to overcome.  I've already mentioned the weight, but no supplier tells you the weight of the device.

Anyway, I started this as an investigation into parasitic power and wound up researching chargers and their capabilities.  Sigh.  At any rate, let the buyer beware.

Saturday, June 7, 2014

Taking apart the Iris Smart Switch

I decided to take the plunge and finish off the 120V appliances I want to monitor right now.  There will probably be others in the future, but for now the two freezers and refrigerator will be the devices I keep an eye on.  I also want another Iris Smart Switch to wander around the house with.  It was nice to be able to evaluate the new smoker <link>, and I'm sure I'll want to do that again with some other appliance (TV, wall warts, maybe a Raspberry Pi) from time to time.

This time though, I'll finish the software to monitor the appliances and take the switch apart to modify it to make sure the appliances can't be turned off accidentally.  It's been a concern of mine that the switch can be both locally and remotely controlled and my major appliances are fed through it.  I don't want a power surge or EMF pulse to shut down my freezers.  So, I got out the screwdriver and a knife.  I peeled the label covering one of the screws and took the thing apart.

I was expecting something like the X10 devices I've dismantled over the years, and was I ever surprised, this thing is really well made:

Notice that there's a well laid out circuit board, nice large wires to handle the load, and substantial connectors for the power in and out.   Right off I noticed that they had a resistor in the circuit for power.  Yes, they're using a real shunt resistor to measure power.  Talk about old school, tried and true, easy to work with design.  There's a pretty substantial set of filtering caps to keep noise out of the circuitry and a 16A Omron relay for control.  The point I wanted was where the power is broken by the relay; I just need to short across the relay connections and I'll be done.

For the folk out there that want to see the rest of it, here's the back side of the board:

The relay is a single pole, double throw and they use both sets of contacts.  I was impressed by the construction and may, someday, take the board out and use it for control of something else.  For now, having it at the plug is really great.

After I shorted across the relay pins --- go look up the relay to get the pins <link>, I don't want to be responsible for you messing it up and screwing up the switch --- I put it back together and started working on the code.  The way I did it is, if a new device shows up, I put an entry in my Sqlite3 database holding the fields I'm interested in (all I use) and assigned it the name of 'unknown'.  Then I go ahead and let the switch join.  It will immediately start sending data, and I save it to the new record in the database.  Then using the command line interface for Sqlite3, I just give it a name and it is now part of my network.  If you want to store it in some other fashion, just change the code to accommodate whatever technique you are using.  However, I really like the Sqlite3 database, it serves as storage for all my devices and has worked like a champ for months now.  If you're doing this on an Arduino, you can use the non-volatile storage capability.  I'm not going to port this code to the Arduino though, I have no need for it there.

The Python Script
#! /usr/bin/python
# This is the an implementation of monitoring the Lowe's Iris Smart
# Switch that I use.  It will join with a switch and does NOT allow you 
# to control the switch
# This version has been adapted to support more than one switch and will 
# add a new record to my database to hold the data.  Adapt it as you need 
# to.
# Have fun

from xbee import ZigBee 
from apscheduler.scheduler import Scheduler
import logging
import datetime
import time
import serial
import sys
import shlex
import sqlite3

# the database where I'm storing stuff

# on the Raspberry Pi the serial port is ttyAMA0
XBEEPORT = '/dev/ttyUSB1'

# The XBee addresses I'm dealing with
BROADCAST = '\x00\x00\x00\x00\x00\x00\xff\xff'
UNKNOWN = '\xff\xfe' # This is the 'I don't know' 16 bit address


# this is the only way I could think of to get the address strings to store.
# I take the ord() to get a number, convert to hex, then take the 3 to end
# characters and pad them with zero and finally put the '0x' back on the front
# I put spaces in between each hex character to make it easier to read.  This
# left an extra space at the end, so I slice it off in the return statement.
# I hope this makes it easier to grab it out of the database when needed
def addrToString(funnyAddrString):
 hexified = ''
 for i in funnyAddrString:
  hexified += '0x' + hex(ord(i))[2:].zfill(2) + ' '
 return hexified[:-1]

#------------ XBee Stuff -------------------------
# Open serial port for use by the XBee
ser = serial.Serial(XBEEPORT, XBEEBAUD_RATE)

# this is a call back function.  When a message
# comes in this function will get the data
def messageReceived(data):
 #print 'gotta packet' 
 #print data
 clusterId = (ord(data['cluster'][0])*256) + ord(data['cluster'][1])
 #print 'Cluster ID:', hex(clusterId),
 if (clusterId == 0x13):
  # This is the device announce message.
  # due to timing problems with the switch itself, I don't 
  # respond to this message, I save the response for later after the
  # Match Descriptor request comes in.  You'll see it down below.
  # if you want to see the data that came in with this message, just
  # uncomment the 'print data' comment up above
  print 'Device Announce Message'
 elif (clusterId == 0x8005):
  # this is the Active Endpoint Response This message tells you
  # what the device can do, but it isn't constructed correctly to match 
  # what the switch can do according to the spec.  This is another 
  # message that gets it's response after I receive the Match Descriptor
  print 'Active Endpoint Response'
 elif (clusterId == 0x0006):
  # Match Descriptor Request; this is the point where I finally
  # respond to the switch.  Several messages are sent to cause the 
  # switch to join with the controller at a network level and to cause
  # it to regard this controller as valid.
  # First the Active Endpoint Request
  payload1 = '\x00\x00'
   dest_addr_long = data['source_addr_long'],
   dest_addr = data['source_addr'],
   src_endpoint = '\x00',
   dest_endpoint = '\x00',
   cluster = '\x00\x05',
   profile = '\x00\x00',
   data = payload1
  print 'sent Active Endpoint'
  # Now the Match Descriptor Response
  payload2 = '\x00\x00\x00\x00\x01\x02'
   dest_addr_long = data['source_addr_long'],
   dest_addr = data['source_addr'],
   src_endpoint = '\x00',
   dest_endpoint = '\x00',
   cluster = '\x80\x06',
   profile = '\x00\x00',
   data = payload2
  print 'Sent Match Descriptor'
  # Now there are two messages directed at the hardware
  # code (rather than the network code.  The switch has to 
  # receive both of these to stay joined.
  payload3 = '\x11\x01\x01'
   dest_addr_long = data['source_addr_long'],
   dest_addr = data['source_addr'],
   src_endpoint = '\x00',
   dest_endpoint = '\x02',
   cluster = '\x00\xf6',
   profile = '\xc2\x16',
   data = payload2
  payload4 = '\x19\x01\xfa\x00\x01'
   dest_addr_long = data['source_addr_long'],
   dest_addr = data['source_addr'],
   src_endpoint = '\x00',
   dest_endpoint = '\x02',
   cluster = '\x00\xf0',
   profile = '\xc2\x16',
   data = payload4
  print 'Sent hardware join messages'
  # now that it should have joined, I'll add a record to the database to
  # hold the status.  I'll just name the device 'unknown' so it can 
  # be updated by hand using sqlite3 directly.  If the device already exists,
  # I'll leave the name alone and just use the existing record
  # Yes, this means you'll have to go into the database and assign it a name
  dbconn = sqlite3.connect(DATABASE)
  c = dbconn.cursor()
  # See if the device is already in the database
  c.execute("select name from smartswitch "
   "where longaddress = ?; ",
  switchrecord = c.fetchone()
  if switchrecord is not None:
   print "Device %s is rejoining the network" %(switchrecord[0])
   print "Adding new device"
   c.execute("insert into smartswitch(name,longaddress, shortaddress, status, watts, twatts, utime)"
    "values (?, ?, ?, ?, ?, ?, ?);",
    time.strftime("%A, %B, %d at %H:%M:%S")))

 elif (clusterId == 0xef):
  clusterCmd = ord(data['rf_data'][2])
  if (clusterCmd == 0x81):
   usage = ord(data['rf_data'][3]) + (ord(data['rf_data'][4]) * 256)
   dbconn = sqlite3.connect(DATABASE)
   c = dbconn.cursor()
   # This is commented out because I don't need the name
   # unless I'm debugging.
   # get device name from database
   #c.execute("select name from smartswitch "
   # "where longaddress = ?; ",
   # (addrToString(data['source_addr_long']),))
   #name = c.fetchone()[0].capitalize()
   #print "%s Instaneous Power, %d Watts" %(name, usage)
   # do database updates
   c.execute("update smartswitch "
    "set watts =  ?, "
    "shortaddress = ?, "
    "utime = ? where longaddress = ?; ",
    (usage, addrToString(data['source_addr']), 
     time.strftime("%A, %B, %d at %H:%M:%S"), addrToString(data['source_addr_long'])))
  elif (clusterCmd == 0x82):
   usage = (ord(data['rf_data'][3]) +
    (ord(data['rf_data'][4]) * 256) +
    (ord(data['rf_data'][5]) * 256 * 256) +
    (ord(data['rf_data'][6]) * 256 * 256 * 256) )
   upTime = (ord(data['rf_data'][7]) +
    (ord(data['rf_data'][8]) * 256) +
    (ord(data['rf_data'][9]) * 256 * 256) +
    (ord(data['rf_data'][10]) * 256 * 256 * 256) )
   dbconn = sqlite3.connect(DATABASE)
   c = dbconn.cursor()
   c.execute("select name from smartswitch "
    "where longaddress = ?; ",
   name = c.fetchone()[0].capitalize()
   print "%s Minute Stats: Usage, %d Watt Hours; Uptime, %d Seconds" %(name, usage/3600, upTime)
   # update database stuff
   c.execute("update smartswitch "
    "set twatts =  ?, "
    "shortaddress = ?, "
    "utime = ? where longaddress = ?; ",
    (usage, addrToString(data['source_addr']), 
     time.strftime("%A, %B, %d at %H:%M:%S"), addrToString(data['source_addr_long'])))
 elif (clusterId == 0xf0):
  clusterCmd = ord(data['rf_data'][2])
  # print "Cluster Cmd:", hex(clusterCmd),
  # if (clusterCmd == 0xfb):
   #print "Temperature ??"
  # else:
   #print "Unimplemented"
 elif (clusterId == 0xf6):
  clusterCmd = ord(data['rf_data'][2])
  # if (clusterCmd == 0xfd):
   # pass #print "RSSI value:", ord(data['rf_data'][3])
  # elif (clusterCmd == 0xfe):
   # pass #print "Version Information"
  # else:
   # pass #print data['rf_data']
 elif (clusterId == 0xee):
  clusterCmd = ord(data['rf_data'][2])
  status = ''
  if (clusterCmd == 0x80):
   if (ord(data['rf_data'][3]) & 0x01):
    status = "ON"
    status = "OFF"
   dbconn = sqlite3.connect(DATABASE)
   c = dbconn.cursor()
   c.execute("select name from smartswitch "
    "where longaddress = ?; ",
   print c.fetchone()[0].capitalize(),
   print "Switch is", status
   c.execute("update smartswitch "
    "set status =  ?, "
    "shortaddress = ?, "
    "utime = ? where longaddress = ?; ",
    (status, addrToString(data['source_addr']), 
     time.strftime("%A, %B, %d at %H:%M:%S"), addrToString(data['source_addr_long'])))
  print "Unimplemented Cluster ID", hex(clusterId)

def sendSwitch(whereLong, whereShort, srcEndpoint, destEndpoint, 
    clusterId, profileId, clusterCmd, databytes):
 payload = '\x11\x00' + clusterCmd + databytes
 # print 'payload',
 # for c in payload:
  # print hex(ord(c)),
 # print
 # print 'long address:',
 # for c in whereLong:
  # print hex(ord(c)),
 # print
  dest_addr_long = whereLong,
  dest_addr = whereShort,
  src_endpoint = srcEndpoint,
  dest_endpoint = destEndpoint,
  cluster = clusterId,
  profile = profileId,
  data = payload
# This just puts a time stamp in the log file for tracking
def timeInLog():
 print time.strftime("%A, %B, %d at %H:%M:%S")
#------------------If you want to schedule something to happen -----
scheditem = Scheduler()

scheditem.add_interval_job(timeInLog, minutes=15)


# Create XBee library API object, which spawns a new thread
zb = ZigBee(ser, callback=messageReceived)

print "started at ", time.strftime("%A, %B, %d at %H:%M:%S")
while True:
  sys.stdout.flush() # if you're running non interactive, do this

 except KeyboardInterrupt:
  print "Keyboard interrupt"
  print "Unexpected error:", sys.exc_info()[0]

print "After the while loop"
# halt() must be called before closing the serial
# port in order to ensure proper thread shutdown
Of course, I have to update my storage out there to hold the new appliance and start charting it.  That means, for now, updating my legacy feeds on Xively and then adding the new feed to my appliance chart.  Then when I get (yet) another one of these, I'll have to make similar updates for it.  I know, I could spend a few days coming up with a way to automate this, but why bother?  It only takes an hour or so to add a new monitor device and I don't have any current plans for a new one.  Here's the latest chart, notice I can now monitor the freezer out in the garage.

Sure, the chart looks too busy to understand, but remember you can click on the legend items on the bottom and turn off whatever you don't want to look at right now.  It looks like my garage freezer is roughly equivalent to a 50W light bulb running all the time.  I guess I need to figure out what that costs me, but it takes a spreadsheet to do it.  I have seasonal rates and demand billing, that will take some thought.

So, I'll add one more device to float around the house measuring things that may catch my interest from time to time.  The kill-a-watt is cool, but you don't get a feel for how a particular device will behave over time.  The kill-a-watt didn't tell me that the freezer defrost timer was hitting during the peak period when it could just as well operate during off-peak periods.

Now I have to open the other two devices and install a jumper, have fun.