Rob Tennyson

Minimal List Debut

rob@robtennyson.us — Mon, 31 Dec 2012 10:52:21 -0500

Over the holidays I created and published a new web application - Minimal List (http://www.mnmllist.com). From the application's about page:

Minimal List was created to solve a need my daughter and I had - a simple way to have our weekly grocery list online.

You can read the rest of the about page for more detail, but that pretty much sums it up. This post was indeed meant to introduce the app, but more than that, I wanted to talk about the geekier details of the project :).

When my daughter and I decided we needed (yes, needed!) this application, we knew that a mobile application was in order because one of the primary places we'd be using it is at the grocery store - to check off items as we put them in the cart of course. Well, anyone who knows me well knows I'm a web guy and tend to avoid rich clients if possible. However, I don't have anything against an application that looks like it is a native mobile app. I just prefer HTML and javascript over any of the proprietary stuff for the UI. I'm obviously building on the MS stack (ASP.NET, MVC4, C#, IIS, SQL Server), but I like the UI to be a browser (usually Firefox or my phone's browser for me personally - iPhone for the daughter).

jQuery Mobile

jQuery Mobile (JQM) was created exactly for this purpose - a native mobile feeling, but served from the web. It's also something I've wanted to play with for a while now - again, if you know me you know I'm horrible at just "playing" with things in spikes and throw away code. I like putting things in production and seeing how things go in real scenarios. So finally, a legitimate reason to play :).

I was quite pleased with the development experience using JQM. In the editor, the footprint is actually quite small. Mostly simple and regular HTML elements that are just tagged with some special JQM attributes. The existence of these attributes (after including JQM css and js of course) is what causes all the magic to happen. So once I got to know which attributes to use, things started moving along rather fast because the rest is just plain web application development like I've done for years.

However, the first real test at the grocery store wasn't all that great. My daughter went to Oregon for the holidays, so I didn't get to see what it is like on an iPhone, but the performance on my Windows Phone 7 was completely crappy. I spent a lot of time standing there waiting on screens to load as I was updating my shopping list items with either price or isle information. Completely unacceptable user experience.

Other than performance though, it worked as advertised! No bugs or issues and the grocery trip experience was exactly what I was looking for (not too surprising since I designed the app specifically for the experience I was looking for).

Next Step

The next step is obvious - improve the UX. Not sure how I'll do it yet, but there are a few paths I can take.

First, part of JQM is AJAX navigation. It intercepts local links and queries for the resource AJAX-style instead of navigating away from the current page. It then takes the response and loads it into the existing DOM all fancy like so it feels more like the native experience. This also makes the UX faster because your browser doesn't have to re-run all the javascript and whatnot that happens on a full page load. However, when you navigate to a page where you've already been, it just shows the page it already has in the DOM instead of re-requesting the URI. This sounds great, but can be challenging with data-heavy pages because the data obviously isn't going to be fresh. To get by this for now, I just turned off the AJAX functionality for most of my links and form posts. So this is something I can look into - there would obviously have to be javascript watching for those page transitions so it could dynamically update the data on the page if necessary.

Second, I could take a more SPA approach - Single Page Application. I could still use JQM for the UI and page requests and whatnot. But the main feature sections would become small SPA islands and I wouldn't do any page transitions at all within the context of that feature. This might be a good time to start playing with knockout.js or something.

And of course, I could always completely abandon JQM. I've created web apps before that were careful to be a good UX even in a phone browser, but didn't look at all like a native phone app. But where's the fun in that?!

The Code

I decided to leave the code in a public repository for all to see:

Momo

Project codename named after Momo from Avatar: The Last Airbender

You'll also notice a link to the commit that created the currently released version in the footer of every page on the site. However, when things move on and you want to see it exactly the way it was as of this post, that commit is ceef281.

That's it for now. I hope you all have had an excellent holiday season.

Toph - Early Architecture Decisions

rob@robtennyson.us — Fri, 09 Nov 2012 12:29:27 -0500

In Another Gig Completes, I mentioned planning to start a new project to help track consulting gigs. Here I introduce you to:

Toph

Project codename named after Toph from the Avatar: The Last Airbender

As I mentioned before, this project is meant not only to help organize my consulting gigs, but also give me a public project and codebase I can point to. I also hope to use the project as blogging fodder. Speaking of which...

Early Architecture Decisions

I've spent the vast majority of my career joining existing projects. There is always that sense of "that's not the way I would have done it". Well, I finally get to do it my way! It was tempting to go crazy with it and implement everything cool I've been reading about recently - whether needed or not, I might add. In the end I decided to go with a pragmatic approach that is much more likely to be a useful example I can point to when talking to developers as I continue consulting.

Visual Studio Projects

I'm still a fan of and will continue to advocate onion architecture (some might say Hexagonal Architecture). One difference you'll find between Toph and what I normally do though, is the lack of an Infrastructure project.

There seems to be a theme going around the blogosphere that is advocating the removal of unnecessary abstractions and part of the theme has been the combining of projects. The idea is that it is perfectly possible to create an architecturally sound solution without using Visual Studio projects to enforce it. In case you're wondering how they "enforce" it, realize that Visual Studio projects won't allow circular references between two projects - whether by directly referencing each other, or indirectly (A - B - C - A would not compile). Therefore if you have a UI and a Core project with UI referencing Core, you couldn't reference UI from Core. Thus, this usually prevents you from directly doing UI type actions from within Core since you couldn't touch the controllers or view models.

I'm almost always a fan of pragmatic programming. As it turns out, the Infrastructure project never proved that exciting for me as a standalone project. So I just created a namespace within UI called Infrastructure and dumped everything in there. You see, everything usually consider Infrastructure is generally only used during application startup anyway as I'm building up the inversion of control container.

However, I still very much like having my Core separate. It just feels right. So, I decide three projects are all we'll need in this solution

Toph (I decided there was no reason to call it Toph.Core)
Toph.UI
Toph.Tests

Even if I end up adding another project in the future for scheduled tasks (to be run on some application server somewhere), leaving Infrastructure under UI should still be fine. That's because I generally just invoke endpoints in the UI from those background tasks rather than directly dealing with the domain or application's database.

UI

New projects should always be started with the latest and greatest, right? I went with ASP.NET MVC 4 of course. Specifically, I started with the Internet Application project template.

Data Access

That template starts with using a local database and using Entity Framework as its ORM of choice. As expected if you know me, I changed that use SQL Server 2012 Express and NHibernate. To do that...

Delete InitializeSimpleMembershipAttribute. This is the attribute added to AccountController that ensures the database exists and is initialized. There is only one line in there that is needed: WebSecurity.InitializeDatabaseConnection. I moved that into Application_Start
Delete UsersContext. This is the EF DbContext
Move UserProfile from the Models directory into the domain and kill the EF attributes
Add Fluent NHibernate
Do all the normal NHibernate config and mapping stuff
Change your connection string
Create the database with the single UserProfile table
Run the application

That should do the trick.

Other notables

The only other things I added to the project were Structuremap and my personal code library RobTennyson.Common.

I also stuck with restricting domain access to a Service Layer like I usually do. One difference I thought I'd toss into the mix this time is a bit of CQS goodness (not full blown CQRS, mind you). We'll see how this turns out as the project grows.

Grabbing a copy and playing

If you're interested in playing around with this, but sure you get the code specifically from this commit: 91a19e9f8b

I'll be moving on with the project of course, but at that exact point, the project is still basically just the default template - well, juiced up a bit, but basically still has nothing to do with the real project in it yet.

Happy coding

October 2012 - Another Gig Completes

rob@robtennyson.us — Tue, 30 Oct 2012 12:39:52 -0500

A couple weeks ago I wrapped up my last contract. I mentioned it in Drowning in New Technologies. Again, awesome, awesome contract – I learned a ton and got to work with some really cool people.

What’s Next

The last time I had a break between contracts I started playing with electronics (see ZigBee Garage Door Opener – yes, it's still working like a champ). I've thought about picking that adventure back up, but am hesitant because of a couple roadblocks I had started to run into before. First was cost – tinkering with electronics isn't crazy expensive or anything, but if you wanted to replace every plug in your house with a smart plug for example, it adds up quick. The true low cost solutions are really only present in bulk – massive bulk. The other road block was simply my hesitation to truly devote to something so big. You see, I tend to over-do everything I get into. If I was going to get serious about it, that meant starting a journey of mastering all aspects of electronics – everything from the basic electronics knowledge needed to get a circuit working to learning all I could about physics. Knowing how to do something doesn't cut it for me. I have to know exactly why every piece of the puzzle works. People spend years and sometimes entire careers mastering this. I'm not sure I'm excited enough to devote myself that completely to it. Maybe being a hobbyist is the key here; not working out how to profit from it.

I think I'll stick to software and stick to the aspect of it I know best - enterprise web development. For a while yet, that means continuing to consult. I still hope to create a product of my own though and consulting might be the key to that as well. You see, I've worked out a cobbled together way of managing my gigs, billable hours, invoices, and whatnot. It's a mixture of folder structure, documents, an Outlook calendar for keeping time, Excel templates for the invoices, and a lot of copying/pasting followed by printing to PDF.

I'm pretty sure there are solutions out there for this, but creating my own will do two important things for me. First it will potentially turn some profit if it turns into something others find useful as well. Second it will give me the codebase of a real world application that I can use for both pointing potential consulting clients to and as an example when trying to explain a concept to another developer. It is sometimes rough when someone wants to see some of what I've done or they want to see an example of whatever pattern I'm prattling on about, but everything I've done is internal and proprietary. I'm good at coding on the fly and coming up with sample applications, but nothing speaks truer than code running in production.

So that is my immediate plan. I've upgraded to Windows 8, Visual Studio 2012, and ReSharper 7.0. I've also purchased ASP.NET MVC 4 in Action to make sure I haven't missed anything over the last year. Once I've gone through that, I'll get started on my first product. My intention is code it publicly (GitHub of course) and blog along the way about why I've done this or that in the codebase.

That is, unless I change my mind 12 seconds after clicking publish on this post, or unless another gig comes along much sooner than I expect it to. Wouldn't be so bad if I could manage to write some code in the evenings and weekends. Stupid Warcraft! Yes, I still play - have long since given up raiding, but I do indeed have a level 90 Druid already and have a young panda monk decked out in heirloom gear anxiously awaiting my attention.

Wish me luck!

July 2012 - Drowning in New Technologies

rob@robtennyson.us — Sun, 22 Jul 2012 09:14:07 -0500

Since April (around the time of my last blog post!), I've been on a gig with a company out of Indianapolis. It's your classic big corp, big ball of mud, type of application. Nothing new to me since I've spent my entire career in corporate America and I'm pretty sure I've created a few balls of mud myself.

The cool thing about this gig, however, is the team. After some turn-over and apparently a breaking point that caused them to get much more picky about hiring decisions, the team I joined seems to be a team of rock stars. Most have figured out they can come to me with questions on just about anything code related and here's the cool thing - answering their questions is always easy. I mean, they just get things insanely fast - every single one of them! Now, I've worked with some freaky smart developers before (last team I worked with at Tyson for example), but rarely do you see a team of dozens where all of them are freaky smart. There is always a handful of laggards (no, I don't think you are one of them).

Additionally, I've gotten to learn a few new things on this gig.

SOLR

I haven't become a SOLR or Lucene expert or anything, but I've had to do a couple things with SolrNet. Seems to be all that I've read about over the years. Can't say I'm enjoying this from a developer's perspective though. You see, they have all the environments setup for it, but when developing locally, the internal SOLR abstractions hit DEV instead of local. This means if you're working on UI that uses the search indexes, it sucks because your local changes obviously aren't going to show up in the indexes from the DEV database. It also means I must be connected to VPN to touch UI using SOLR.

An implementation of the gateway and/or facade patterns would take care of this nicely I think.

Automapper

I'm not entirely sure how I feel about AutoMapper yet. I've heard nothing but praise about it for years now, but this is the first time I've been on a project where it is actually being used. Maybe it's the way they're using it, or maybe I just haven't seen the light yet, but at this point I'm not digging it.

Sure, it does make your controller actions much smaller. It also takes care of DRY if you're mapping between two objects in many places. But mostly I find myself constantly having to hunt down the mapping logic to figure out exactly what is being copied between the objects, or, more frequently, to find out why something is not mapping correctly. I'm sure I'll come around, but right now it seems like a mix of voodoo and magic. Most importantly, there is no "go to definition", search results is the only way to find the mapping.

Topshelf

This one was fun. I played briefly with Topshelf in the past as a spike - never made it to production if memory serves. This time though, we're using it to take care of the Windows service that handles all of the project's scheduled background work. The API is crazy easy and lightweight. Can't think of anything negative to say about this at all.

NServiceBus

Holy crap this thing is cool. NSerivceBus has been on my radar for a long time - as well as Mass Transit. We had a bit of trouble with MS DTC and permissions and whatnot, but it has otherwise been nothing but goodness. I love the feeling of isolation and extremely small units of work you get when dealing with service bus architecture - each message is its own unit of work and tends to be a small one.

I think that pretty much covers it. Well, there are a couple of others (like their internal email handler/service/thingy), but I'm afraid a recruiter might see and start offering me gigs utilizing them. Kind of like the fact that you won't find assembly, C, C++, or BASIC on my resume. I don't want people knowing I know that stuff!

fit-PC2 FTW!

rob@robtennyson.us — Tue, 03 Apr 2012 12:09:00 -0500

This is a picture of the box top for my new toy. Thanks to a comment from a friend on one of my past posts, I've been looking for a reason to justify buying one. Exactly as his comment suggests, I've grown tired of having to leave my beast of a desktop running to serve as a home server and to host the radio I use to interface with my remote sensor network.

I love this little thing! It's small, quiet, and uses practically no power. I got the fit-PC2 Value model, which comes with everything I need: 1.1 GHz CPU, 1 GB RAM, Ethernet, DVI display port, 6 USB ports, and an empty internal bay for a 2.5" SATA HDD. I already had a 100 GB 7500 RPM drive I could use (left over from a past upgrade on the wife's mac).

Here you can see the fit-PC sitting next to our Time Capsule for a good size reference. I used the Time Capsule as the router for the fit-PC's ethernet. The little thing in the middle is the XBee radio I use to communicate with my garage door opener.

It sits there next to the router drawing very little power, making no noise, and hardly even warms up. I would even go as far as saying it looks pretty cool too - it lives in our living room on a small table next to the TV.

Communicating with the XBee

The OS I decided to put on it is Ubuntu. This means the .NET console application and the ASP.NET application I used on my development box wasn't going to cut it (without getting Mono involved of course). Instead I went with the classic LAMP stack (the 'P' being PHP in this case).

For the time being, I'm not listening with the radio which means I'm no longer getting temperature readings. Instead I'm just using it to open and close my garage door. I did this because I'm hoping to move from using XBee/ZigBee to 6LoWPAN in the future (more on that another time). For that reason I didn't see the need to much time into this. I just wanted to be able to continue operating my garage door opener with my phone!

For anyone interested, this is the PHP code I'm using to open the serial port and send the XBee messages to the remote XBee controlling the garage door opener. The php_serial.class.php that I'm including was pulled from here.

<?php

  if ( isset( $_POST["btnSubmit"] ) ) {
    ini_set( "display_errors","On" );

    include "php_serial.class.php";
    $serial = new phpSerial;
    $serial->deviceSet("/dev/ttyUSB0");
    $serial->confBaudRate(9600);
    $serial->confParity("none");
    $serial->confCharacterLength(8);
    $serial->confStopBits(1);
    $serial->confFlowControl("none");
    $serial->deviceOpen();

    $serial->sendMessage("\x7E"); // Frame start
    $serial->sendMessage("\x00\x10"); // Frame length
    $serial->sendMessage("\x17\x00"); // Frame type (AT command)
    $serial->sendMessage("\x00\x13\xA2\x00\x40\x86\x97\xCB"); // Destination address
    $serial->sendMessage("\xFF\xFE"); // 16 bit dest addr (unknown)
    $serial->sendMessage("\x02"); // apply AT command immediately
    $serial->sendMessage("\x44\x31"); // "D1"
    $serial->sendMessage("\x05"); // HIGH
    $serial->sendMessage("\x92"); // checksum

    sleep(1);

    $serial->sendMessage("\x7E"); // Frame start
    $serial->sendMessage("\x00\x10"); // Frame length
    $serial->sendMessage("\x17\x00"); // Frame type (AT command)
    $serial->sendMessage("\x00\x13\xA2\x00\x40\x86\x97\xCB"); // Destination address
    $serial->sendMessage("\xFF\xFE"); // 16 bit dest addr (unknown)
    $serial->sendMessage("\x02"); // apply AT command immediately
    $serial->sendMessage("\x44\x31"); // "D1"
    $serial->sendMessage("\x00"); // OFF
    $serial->sendMessage("\x97"); // checksum

    $serial->deviceClose();
  }

?>

Enjoy!

Visual Studio + Resharper Intellisense

rob@robtennyson.us — Wed, 21 Mar 2012 07:57:36 -0500

I've always turned off the auto-appearance of intellisense in Visual Studio. I feel that it's faster to just finish typing the word than it is to pause slightly and pick the right one from the intellisense dropdown that appears. Whenever I'm typing something really long or when I'm not entirely sure what the method or class name is, then I just hit Ctrl+Space to make the intellisense appear on-demand.

Visual Studio 2010 + Resharper 5.1

In ReSharper's options:

And in Visual Studio's options:

That should do the trick. Enjoy!

Resistor Decoder

rob@robtennyson.us — Tue, 13 Mar 2012 10:37:45 -0500

A friend shared a link to his post about an extremely cool video of Bret Victor's talk at CUSEC 2012 titled Inventing on Principle.

After watching the very inspiring video, I started snooping around Bret's site. Talk about a treasure trove of goodies! When I stumbled across the below, I had to share (as well as put it in a place I would always remember). I thought it was the coolest way to decode resistors I've seen to date.

Enjoy!

ZigBee/XBee Garage Door Opener

rob@robtennyson.us — Thu, 23 Feb 2012 16:47:54 -0500

I mentioned in my last post that I have three xbee radios that need to be used (played with!) and that we only have one garage door opener between the two of us - I am not the keeper of said opener. Here I present version one of our new networked garage door opener!

The Old Garage Door Switch

The black box you see with the duck tape is a keyless entry system that was here when we bought the house. I'm the only one who used it (being the one without a remote) so I decided to unplug it and steal the wires that run from the garage door opener. The wires are already run and it's conveniently near a wall outlet so it seemed the right thing to do.

In case you don't know (I didn't at first), the wires that run from your garage door opener (the real one attached to the door) to your standard wall switch works by merely closing the circuit between the two wires temporarily. So your wall switch is just a mechanical switch with two electrical contacts that, when the button is pushed, close the circuit. Releasing the button re-opens the circuit, or breaks the connection between the two wires.

With the knowledge of just how simple it is to activate a garage door opener, all I needed was a way to electronically close the circuit between the two wires. That is exactly what a relay is for.

The XBee Garage Door Switch

What this is, is the remote temperature sensor I had already created plus one additional component (and a few wires).

So the stuff at the bottom of the breadboard is still the power management componentry. It takes the 9 volts coming in from the power supply and regulates it down to exactly 3.3 volts for the xbee. Plus a couple of capacitors to smooth out the current.

Above that is the temperature sensor (tiny black thing) and a few resistors used to get the sensor's reading down to a level the xbee can read. And then there's the xbee itself with the temperature sensor still connected to AD0 (pin 20).

The new piece is the light blue component at the very top. That is a Compact 5VDC/1A SPST Reed Relay. I just connected the two wires from the garage door opener to each side of the relay and then ran a wire from AD1 (pin 19) on the xbee through the relay to ground. To trigger the relay, I just have to turn on AD1. So recalling what I said about the garage door switch, I just turn on the pin, closing the circuit with the relay, and then turn it right back off to re-open the circuit. Just like pushing a button switch :)

Tying Everything Together

I left the temperature sensor on the circuit and I left the xbee configured exactly as-is. This means the console app that I used before still works like a champ. I connected the coordinator xbee to my PC, plugged in the above breadboard, ran the application, and I immediately started getting temperature readings from my garage. All I needed then was to be able to send a command to the remote xbee telling it turn on AD1 and then again to turn it back off.

Digi made this really easy with the xbee API. All I need to do is send it a remote AT command configuring AD1. Specifically, I send a Remote AT Command Request to the address of the remote xbee passing the AT command D1 (configure analog/digital pin 1) with the parameter of 5 to turn on high digital output (3.3 volts). I sleep for half a second and then send the same command again with a parameter of 0 turning the pin back off.

Of course, I needed a way to tell my console application to send those commands. For now I just listen for incoming connections on a named pipe. I created a single ASPX page sitting on my local IIS that, on button click, would open a connection to that named pipe and send it the message "Garage Door". The console app triggers the garage door every time it gets this message. Sweet!

To get to that from my phone, I opened up HTTP traffic in my firewall to private network traffic and gave my PC a static IP address. So as soon as my phone connects to my wireless router, I can open and close the door with my phone. In fact, anyone who knows the password to my router and knows the IP address of my PC can now open and close the door. Unlimited remotes!!

Awesome, But Not Finished Yet

So now everyone who has access to my router can open and close the garage door. That's cool and all, but I'm not done yet. There are several things I don't like about the situation...

First, I want to be able to tell whether or not the door is currently open. No brainer! Not cool if the opening and closing is automated, but I still have to leave my lazy boy to see whether or not I need to close it at the end of the day.

Next, having a breadboard and exposed components dangling on the wall of my garage isn't cool. It's also not good for the circuit being exposed to dust and whatnot. Mostly it isn't cool though.

More importantly are the implementation details. Currently everything is had coded in a very brittle way. First I assume that any message received at the coordinator is going to be a temperature reading on AD0. Second is the garage door opener. Its address is hard coded to that exact xbee module. The pin is hard coded to AD1. And finally, I'm using named pipes to communicate with a console application from a .net application.

Oh, and I'm not logging the temperature readings, so no cool graphs. Not that there would be many readings coming in yet. Still have to solve the cost problem of creating dozens or remote sensors.

I'm definitely excited about what I have so far. And excited about the fact that I can open and close the door from my truck of course. But I have a lot of work (can I even call it that?) ahead of me.

ZigBee Simple Sensor Network Part 2 - Never Mind

rob@robtennyson.us — Sat, 18 Feb 2012 10:06:13 -0500

In my last post I left off with saying that I planned to continue in the book with the second piece of the Simple Sensor Network project - switching the remote sensors to end devices and using batteries instead of the 9v plugs. I also thought I'd create my own PCB instead of using the breadboards. Didn't happen...

I really dig the idea of having one of these temperature sensors in literally every room in the house. Maybe one out front and one out back as well. I can picture having rich graphs showing me the temperature rise and fall from all around my house. Ideally all of the internal sensors would rise and fall in sync as the central air kicks on and off. If one of the rooms fell lower in the winter or rose higher in the summer in between heating/cooling cycles, that would tell me that particular room isn't insulated as well as the rest. Or it would tell me someone left a window cracked, or a varmint decided to make their own entry. All good information to have and at the very least I'd have those cool graphs to show off to oldsters who visit :)

The problem with the XBee-based sensor though, is the cost. The radio itself is roughly $20 and then there are the rest of the components. So we're talking close to 30 bucks per sensor. Not cool if I want to buy more than a dozen (every room - not just bedrooms, outside, attic, etc.). If I plan to implement this idea of a zigbee network of temperature sensors, I need to find a much cheaper solution for end devices.

So I'm done with the book Building Wireless Sensor Networks. Even though I don't think I'll continue using xbee radios everywhere, I am so glad I got the book. It has introduced me to all sorts of fun and coolness that I've never played with before. And I can see using those radios in spots (like the controller or more extravagant devices that use more of the module's functionality), so I'm sure it will be a great reference in the future. It's an excellent addition to my library.

What's Next

I am left with the three xbee radios I've already purchased. I was thinking about what I might do with them as I was leaving to take the kids to school the other morning. As I pulled out of the garage and lamented once again that I still haven't gotten a second remote for the door (the wife has our one remote in her car of course), the idea of creating my own formed. I've read of others doing it with arduinos and netduinos so there's plenty out there on the subject. My next post will show how I accomplished it with a couple of my left over xbee radios. Good times!

ZigBee Simple Sensor Network

rob@robtennyson.us — Mon, 30 Jan 2012 10:40:26 -0500

This is the project I mentioned in Configuring My First XBee Radios where I'm going to setup the sensor network from chapter 5 in Building Wireless Sensor Networks. I'm going to end up with two remote temperature sensors that are mesh-networked together to stream their data to a base station radio connected to my PC.

Preparing the radios

Coordinator

This is a simple matter of connecting to the xbee with X-CTU and switching its mode from AT to API (along with ATAP = 2). I also went ahead and zeroed out ATDH and ATDL since the coordinator will be receiving data only.

Routers

These stay in AT mode, but need the following settings:

ATID - set to the same PAN ID as the coordinator
ATDH - 0 (forces the radio to use 16-bit addressing)
ATDL - 0 (destination is the coordinator for both routers)
ATJV - 1 (rejoin network on restart)
ATD0 - 2 (puts pin 0 in analog mode)
ATIR - 3E8 (sample rate of 1,000 milliseconds - polls for the temperature once a second)

Something that might be worth noting here. When I first unplugged the coordinator and plugged in the first router, my computer's USB completely stopped working. Yep, I lost both my mouse and keyboard and no amount of unplugging and plugging them in helped. I tried every USB port on my computer. I eventually had to do a hard restart (and luckily only lost a little progress on this post - I save often). I did notice I had left X-CTU running when I did the switch. This time I closed X-CTU in between configuring the two routers and everything worked fine. Don't know for sure if that was the problem since I don't care to reproduce it, but wanted to put it out there just in case you run into the same thing.

Preparing the sensor boards

This was an experience for me. It seems like I have a vague memory of having soldered before, but we might as well say I've never done it. I'm proud to say I finished with only one burn (right index finger). The solder jobs themselves look horrible.

Working with all the parts was interesting as well (transistors, resistors, etc.). Very neat and I'd say rather satisfying when the end product is a physical thing instead of software. Good times!

This is a picture of the first one I put together (the second looks identical). The little black thing poking up right below (in the picture) the XBee is the actual temperature sensor. The mess of stuff near the bottom is the voltage regulator (from 9-volt to 3.3-volt) and the capacitors (to get rid of noise in the power supply). Prototyping on those breadboards is super easy.

Capturing the sensor data

The book actually supplies a program ready to use that will allow you to visually see on your computer all the data being sent from your remote sensors. It's a Processing program that uses some Java libraries to communicate with the XBee radio over the COM port. I could have used that I suppose...

Being the developer that I am though, I wrote my own in .net. I put the code out on github in a project called XBee (real stretch for a project name, I know). You can see the library I wrote along with the project specific to this example at https://github.com/rtennys/XBee. The format of the messages sent from the XBee radios in API mode are very easy to work with. It was a fun little exercise for sure.

What's Next

I think I'm going to do two things next. I'm going to kind of stick with the book moving on to creating temperature sensors that are configured as end devices instead of routers. This allows them to be much more conservative on the energy they consume thus allowing me to use a battery power supply instead of having to plug them in. In addition to what the book shows though, I'm going to create my own PCB instead of using the breadboard.