COSM XBee Temp Monitor Network in AT Mode?

Hello All,
I have been working on this project for some time now and I've just about given up on finding any threads or tutorials to answer my questions.
What I want to do isn't exactly a beginners project but shouldn't be all that uncommon either-
I want to set up a network of 5 Arduino boards (1 Fio, 1 Micro, 1 Leonardo and two Uno's) with four collecting temperature values from DS18B20 One-Wire Sensors and transmitting through XBee Series 2 radios to a COSM dashboard via coordinator module on an Arduino w/Ethernet Shield running the COSM sketch.
It was easy enough to figure out how to get the various sensor nodes to read and transmit the temperature values. And the new Arduino IDE has a pretty straight forward "transmit to Pachube" sketch. My main problem is that every tutorial and example of XBee temp networking I can find, and there are many, configures the XBees in API mode. I assume this is because Rob Faludi used a temp network to demo API mode in his excellent "Building Wireless Sensor Networks" book. But API mode is not only beyond my abilities of comprehension at this moment, it also appears to be something of an overkill for a project which, for the time being consists of relatively simple communications.
So can anybody recommend a good tutorial or example sketch for configuring 4 XBee Series 2 radios in AT Mode to communicate to a base station and have that base station transmit each nodes values to COSM?
I figure just using an Uno and Ethernet Shield should be the simplest base station set-up for now. Unless such a set-up is beyond its capabilities. In such a case, I have a number of other options available including a Raspberry Pi, an ASUS WL-520gu Router w/ OpenWRT, a UartsBEE FTDI adapter,a MegaADK or even a Arduino Due.
But all these possibilities are meaningless until I can find a reliable means of configuring the network itself.
Any help will be GREATLY appreciated!!!

My main problem is that every tutorial and example of XBee temp networking I can find, and there are many, configures the XBees in API mode. I assume this is because Rob Faludi used a temp network to demo API mode in his excellent "Building Wireless Sensor Networks" book.

No, it is because in API mode, the "who sent 14.7" bit is dealt with.

You could make each Arduino send data differently ("<1:14.7>", "<2:14.8>", etc.). Then, on the coordinator, parse the data and determine who sent it.

But API mode is not only beyond my abilities of comprehension at this moment, it also appears to be something of an overkill for a project which, for the time being consists of relatively simple communications.

The XBee library makes it pretty simple.

roundhouselabs:
It was easy enough to figure out how to get the various sensor nodes to read and transmit the temperature values. And the new Arduino IDE has a pretty straight forward "transmit to Pachube" sketch.

I figure just using an Uno and Ethernet Shield should be the simplest base station set-up for now. Unless such a set-up is beyond its capabilities. In such a case, I have a number of other options available includinga MegaADK

Once this progresses, you may want local backup and display. You are then very likely to run short of memory, and it would be smart to grab the Mega now.

There are new libraries from cosm. You will be better off using them and the latest examples, and ignoring the stuff in the Arduino IDE. This applies even if you have had some joy already.

As odd as I find it to be agreeing with PaulS (just kidding, Paul! :D), API mode makes this sort of thing much easier actually. There is a bit of a learning curve in understanding the object model implemented by the library, but there are good examples that come with the library. If you're not already aware, get it here: GitHub - andrewrapp/xbee-arduino: Arduino library for communicating with XBee radios in API mode

I avoided API mode like the plague until I found out it can split packets. I use regular old text between devices to carry my data, so things like,"temp1,70" were flying around between devices. This was fine until I got a few devices out there and with the collisions and retries I started seeing things like "temp1" a couple of packets from other devices and then, ",70". The problem was actually much worse than this because I have a couple of devices that send long text strings, "device1,On,Off,Open,Closed,someotherstuff," and those devices would get chopped up mercilessly.

I dug for quite a while trying to find a solution and couldn't, so I bit the bullet and went to API mode. Suddenly, all the packets were complete and things settled down. I was still avoiding the XBee library until there were some changes made to it to support software serial ports and the additional serial ports on the 2560. That was too tempting. I grabbed the library that supports this and tested it.

Yes, now you can have API mode, using the library, at nice speeds, on alternate ports (giving you the serial for debugging and status). Really freaking cool. I still send text between the devices (well, most of them) because I want to watch the traffic from time to time to see what is going on. Even after months of the devices working, bugs show up.

It really isn't all that hard to figure out what the heck is going on and get your first project running with the library. I have two examples that I commented the heck out of so newbies to the library can get a kickstart. They both use a 2560 and one of the additional serial ports, but it would be really easy to switch to software serial for the XBee. Both examples leave the regular serial port available for other things. The code will run on a 328 just fine using software serial, you don't need the 2560; I just wanted to use my spare 2560 for something to be sure it actually worked.

Steal them if you want them:

Also, you can have your controller, concentrator, whatever you're using in AT mode and still see what is going on. The XBees transmit between each other in their own protocol and convert to whatever mode you have them set to. So, a remote XBee can be in API mode and sending stuff and the one plugged into your laptop can be in AT mode and still give you stuff you can read. This works great for getting a node running. It won't work if you use the analog or digital pins on the XBee, because they require API mode for that, but the stuff coming in the serial port works fine.

While you're at it, think about avoiding broadcast for the final running devices. Broadcast has its own particular problems that can drive you nuts over time. However, broadcast is great for getting a device up and running; then change it when you trust it.

Thank you all for the great advice! Looks like the road ahead will use the new XBee-Arduino API Library, with draythomp's tutorials as a reference point, the new COSM library (updated since 1.0.3) and my MegaADK as the Base Station.
I'll post the results here once I get it working, and (not to get ahead of myself...) I'll also post results of any further experiments combining different Arduino boards with XBee or with Raspberry Pi/OpenWRT. I finally got the serial header working on my Asus WL-520gu router running OpenWRT last night, so I might just end up converting that to my base station.
But first things first I guess its time to get over my aversion to API mode!
Thanks Again!

One last thing. Terry King has a cool example of using the Cosm library somewhere on this board. If you haven't seen it yet, do a quick search and take a look. It may simplify the work even more.

draythomp:
One last thing. Terry King has a cool example of using the Cosm library somewhere on this board. If you haven't seen it yet, do a quick search and take a look. It may simplify the work even more.

Do you know if he has a screen name? Searching "Terry King" only turns up this thread...

Thanks Again!