Hey Mike,

Did you upgrade the library from a previous version?  If so you need to delete XBee.o.  Otherwise it won't compile the new library.  I think they changed this in Arduino 17 so that it always recompiles libraries.

Andrew

FYI, I have since updated the xbee-arduino library (http://code.google.com/p/xbee-arduino/) to support i/o samples.  See this example for series 1:

http://code.google.com/p/xbee-arduino/source/browse/trunk/examples/Series1_IoSamples/Series1_IoSamples.pde

and this one for series 2:

http://code.google.com/p/xbee-arduino/source/browse/trunk/examples/Series2_IoSamples/Series2_IoSamples.pde

sorry, that should be

if ((xbee.getResponse().getFrameData()[8] & (1 << 4)) {
// it's on

}

of course arrays start at 0

You should be able to use the xbee-arduino library to do this.  Although it doesn't implement i/o samples yet, it should parse any valid xbee packet.

In your loop:

xbee.readPacket();
   if (xbee.getResponse().isAvailable()) {
      
      if (xbee.getResponse().getApiId() == RX_16_IO_RESPONSE) {
// got a i/o sample
// now we just need to pick out the relevant parts
// we can access the packet with xbee.getResponse().getFrameData()
// per the doc http://xbee-arduino.googlecode.com/svn/trunk/docs/api/class_x_bee_response.html#d958f0b5200138545bdd762111299a94
// the frame data starts with the byte  that follows the api id
// now open your manual to page 62 http://ftp1.digi.com/support/documentation/90000982_A.pdf
// we can see the fifth byte takes us to the RF data -- the meat of the packet.
// now go to page 12.  the first byte is # samples, then the channel indicators.  you're looking for dio4 and that's the fifth bit of the fifth byte (not making this up). So really byte # 9.  So this should do it:

if ((xbee.getResponse().getFrameData()[9] & (1 << 4)) {
// it's on

}
}
}

Let me know if this works.  Hopefully I got the correct byte.  I can look into adding this feature to the library if there's enough interest.

How are you planning to trigger the D0 low/high change?  

If you want a low input on the coord. to drive the remote radio pin low see this http://www.ladyada.net/make/xbee/ref.html and http://www.adafruit.com/blog/2009/04/21/using-xbees-to-control-relays/

If you want to send a serial command to the coord to drive it low/high, you could use the Remote AT command.  This requires API mode.  There may be a way to do in in AT mode but I'm not sure.

ahh.. didn't realize you bought them already.  don't worry, it'll still work.  As I said before, you need to solder some headers on the regulated to access the xbee pins.  then power the board from arduino 5v and connect rx/tx and ground.

You can use an unchipped arduino to configure the xbee with x-ctu.  Firmware upgrades require rts/cts (which neither arduino or xbee regulated expose), so you really need an xbee explorer, but you are probably ok with the default firmware.

Don't bother with the xbee regulated.  You don't need it.  All you need is 2 XBee shields.  They are available in a kit, or assembled for a bit more.  The shields expose arduino i/o pins, provide 3.3 power, and link serial comm. between arduino and xbee.

The xbee explorer will make it easier to configure the xbee with x-ctu and upgrade firmware. You can configure xbees via arduino sketches, or even unchip an arduino and use it like an xbee explorer.

There's a ton of examples out there.. just use the search button

You could go that route but if you look close at a photo of the regulated, there are no headers to expose power and i/o, so you'd need to get some and solder them on.  You would also need a breadboard or female/male jumpers to interface the two.

If you are using arduinos (shield compatible), I'd go with xbee shields http://www.nkcelectronics.com/freeduino-arduino-xbee-shield-kit.html (assembly required).  About the same cost and they interface much nicer.  NKC also sells XBees.

You may also want one of these for upgrading xbee firmware http://www.nkcelectronics.com/xbee-explorer-usb.html , which you'll likely want to do as they typically ship with old firmware.

Either series 1 or 2 will work but series 1 are easier to work with and a better choice for point to point.

Both series 1 and 2 radios support I/O samples (receive i/o data from standalone xbee) and remote at (turn off/on pins on remote standalone xbee) but series 1 would be a better choice.

I had thought series 2 radios always have the sif header.  See photo at top of this doc http://ftp1.digi.com/support/documentation/90000866_C.pdf

In case that's not 100% correct, you can also look at the command set.  Series 1 support the EC command, series 2 do not.

But the safest method is to always use the "Read"  feature first and let X-CTU determine the radio type, then it will display the allowable commands/firmware versions.

Andrew

Whoa, don't short your radio! You need to set D1 to digital input, not DO low.   DO low would just set the pin at GND and nothing would ever happen -- not interesting.  

First do the basic config here
http://code.google.com/p/xbee-api/wiki/XBeeConfiguration
Now your radios should be talking.

Then look at the I/O samples section here http://code.google.com/p/xbee-api/wiki/DevelopersGuide and configure your remote radio for i/o samples and change detect.

Now when you connect D1 (or whatever pin you configured) to ground, it should send a sample to the coordinator, and when you remove GND it will send another sample, indicating D1 is high (technically it's floating).

Hi Chris,

The I/O samples feature requires API firmware.  With API firmware you communicate with the radio by sending/receiving packets.  Just load the API firmware on there and you should be good.

Even with AT firmware, you should not have gotten any errors when uploading.  When the jumpers are in the usb pos., the xbee is not involved.  I think you may need to unplug the usb cable before switching the jumpers.

Andrew

This is really easy.  You can use change detect with I/O samples on the remote xbees.  The remotes will send a packet to the main (coordinator) whenever the i/o pin goes low.

I'm not sure why you have a arduino between the xbee and computer, unless you are just using it as a usb-serial (unchipped).  You can use this software http://code.google.com/p/xbee-api/  to collect the samples on your pc or this http://code.google.com/p/xbee-arduino/ to collect the data on an arduino/xbee.  The dev guide talks about i/o samples and change detect http://code.google.com/p/xbee-api/wiki/DevelopersGuide

Andrew

Opps.  At first I thought you had ethernet at the coffer maker. Now I see you were talking about eth over powerline.  I would consider a wifi router/access point to provide ethernet at the coffee maker.  You can probably find a cheap used one on ebay.  This of course assumes you have wifi already.  If you can do this, you only need one arduino and don't need to leave your computer on all the time for monitoring/control.  With an openwrt router, you could ditch the arduino eth and do serial interface with the arduino.

You mention "cheapest", so I'm going to say, eliminate the master arduino (just saved you $30) and use ethernet (wiznet) with the coffee maker arduino.  You can run webduino for remote control.  I would use an RBBB ($12) with a wiznet module from nkc electronics (~$20).  

XBees are fine and good, but will cost you more  (2*XBees + Arduino + shields/breakout)  and while probably reliable enough, they're never as reliable as ethernet.  X10 is just plain unreliable, and will cost you more as well.