For power:  I used a big ol 24V transformer in my AC unit to power my web enabled thermostats for my home.  When these are rectified and filtered they put out about 37V DC that has to be regulated to 5V somehow.  I used a really cool device
http://www.dimensionengineering.com/de-swadj.htm.  I have two of these and they have both been working really well for several months.  This saved me a lot of money and time searching for a transformer.  There are other options on that site as well.  You can then use the same AC voltage through the relays to run the solenoids.

Regarding XBees, if you are going to be doing other stuff via wireless control, such as monitoring the soil moisture in various spots, flipping on a light for yard accents, and so forth, the XBee is probably the better choice.  Sure, they are more complicated, but are they really more complicated than tuning, writing your own retry code, testing range yourself, addressing and such?  PaulS and I disagree on the complexity of Series 2.  Once you get two of them working (took me a week the first time and 12 minutes the second) adding another one is about 45 seconds of work.  I even built a remote temperature sender in around 45 minutes from the ground up using one of these and a few other parts.  Don't bother with a shield for these, contrary to what you hear and read, they can be hooked directly to the darn Arduino if you use the low power models.  You can use a cheap adapter board like the https://www.adafruit.com/products/126 if you want to use the high power devices.  The low power ones have a surprising range outside using the wire antenna.  Inside, not so good, so you might need a third one to relay; that is incredibly easy also.  And, you can get three of the low power ones for the price of one high power one (depending of course on where you buy it)

I might suggest that you use an arduino as the controller and web enable it.  The reason is that you will not have to have a computer hooked up and working all the time.  A little arduino controller is fun to build and can have timers (using timeAlarm library) that do things for you.  This way you can put it on the web and watch the sprinklers from Paris while you're on vacation.  But this is a decision you can make at any time.  You can also put the timers in the sprinkler arduino, but you would have more programming in it then.

Take a look at my blog draythomp.blogspot.com to see how I control my thermostats, measure the power in the house, control the swimming pool and such using XBees, Arduinos and such.  The thermostat tab is where I did something similar with 24V control, ethernet boards and relays.  My project is ongoing and will be until I get too old to hold the soldering iron.

This is a really cool idea.  If you really want to do it, the folks on this board will totally help you on it.  Let me start you off with a few questions that matter a lot.

How far is the coup from power?  Do you have something like a light to scare off the 'coons nearby?
How far is the coup from where some computer stuff is plugged in.  Like, do you have an ethernet plug somewhere nearby?  How hard would it be to run some wires to it.
Sunlight?  Maybe solar power is possible to recharge batteries.

See, the feeder has to be with the chickens, but the arduino can be somewhere else.  Suppose you built a screw driven conveyor that dropped corn and ran wires from it to the house?  If that's too hard or not fun enough, how about an XBee on the feeder with a little control circuitry that is wireless to an Arduino in the house.  If that isn't fun enough, put the arduino in the coup with the feeder hook an XBee to it and another one in the house hooked to something on the web.

Webcam?  You simply got to have a webcam !  We would all want to see how fat we could make your chickens.

Think about the physical aspects of doing this.  The electronics will be based on how you think it could be done the best.

Now, go edit the first post and add [Solved] to the subject line 

tee hee.

You're certainly welcome.  Remember though, there's about as many ways to do this as there are people on this forum.  My particular method has some advantages and some disadvantages; notably seeming waaay to complicated. The main purpose is to have some fun and accomplish something interesting.  If you implement Pauls's suggestion of an ending character, then the loop will get even simpler.  Just have a new case with that value, save your integers and go do something with them.

Working from memory here, so take it for what it's worth.  The DH, DL address is factory set for broadcast when shipped.  That means everything talks to everything in peer to peer mode.  That should make them talk, but not efficiently.  This doesn't mean that someone in the supply chain set up a test bed that changed the devices before you got them.  Once again, I have zero experience with Series 1, but that's what I've read people's experiences have been.  If you already have a couple of them running in the house in some other mode, there may be problems.  Series 2 will work out of the box if there is already a coordinator running.  If there isn't you gotta make one, then they work.

I took your code bit and compiled it for a Uno under ide 021 and it worked fine.  I realize you've been trying to find a problem and cutting and shaping code so I won't point out the little problems here and there, but it worked.

I saw what you're getting when I hit the reset button on the Arduino and also when I killed the serial window and restarted it.  What you're probably seeing is stuff that was coming in already and just hadn't gotten there yet.  If you want to see it like I did, upload it, then start the serial window so it starts off fresh.  This is pretty common in my experience when you're sending data to the serial out and start up the serial window.  It gets a burst of junk from the previous run.  Put a couple of Serial.println(); lines in before you print start to show the separation and have fun.

Naw, when you're waiting for Y, you're also collecting X data.  I could have bumped around on the X, but it was already getting too complicated for a simple illustration.  Sorta took the easy way out.

Dear Badly,

Thank you.  You gave me enough information to find the problem.  It wasn't me and this HAS been discussed a lot, but on the old board.  The 57600 baud rate is basically broken (at least under 021) and you can make it work by fudging the baudrate some.  I found that

  Serial.begin(58824);

made it work fine for long lines of input and such.  I'll look into this more and gather more data, but you got me over the hump.

Sigh.......

This little piece of code :

Code:

void setup() {
  Serial.begin(57600);
  Serial.println("just testing");
}

void loop(){
  char c;
  if (Serial.available() > 0){ // is there a character in the buffer?
    c = Serial.read();
    Serial.print("Incoming character is ");
    Serial.println(c);         //just shows the incoming character
  }
}

Doesn't work properly at 57600 baud,  Change the baud rate to anything else and it just takes off and works fine, even 115200.  If I send the Uno one character at a time, I get the character properly; if I send a line like "Hello there" I get the "He" ok and the rest is junk.  When I searched for other folks that had had this problem I noticed a bunch of them having problems with this baud rate for GPS applications, but nothing else.

What's up with this?  What am I overlooking?

This is a very different way to do this.  Suppose you don't want to hang around waiting for a character to arrive because you have other things the processor can be doing.  This little bit of code checks for a character and uses a minimal state machine to tell where you are in the input.  This is not meant to discount other methods, just to show you a different way.

Using this you can type X123 wait an hour, type Y456 and the values get assigned while the processor could be blinking lights and stuff.  Of course you'll have to modify it to make it work for your purposes.  It's just an illustration, think of it as a toy and play around.

Code:

#include <ctype.h>

void setup() {
  Serial.begin(9600);
  Serial.println("just testing");
}

#define waitforX 0
#define waitforY 1
#define waitforYdata 2

char data[50];
int xValue = 0;
int yValue = 0;
int state = waitforX;

void loop(){
  char c;
  /* just another way of doing it, this method doesn't block and
  is controlled by a switch statement.  You can do other stuff while
  you wait for the data to come in.  To see what happens uncomment
  the line below and watch the scrolling window while you type.  */
 
  //Serial.println("Loop running");
 
  // to get more of a feel for it, change to "no line ending" in the
  // terminal window (menu at the bottom) then send one character
  // at a time.
 
  if (Serial.available() > 0){ // is there a character in the buffer?
    c = toupper(Serial.read()); // I just got tired of pressing the shift key
    Serial.print("Incoming character is ");
    Serial.println(c);         //just shows the incoming character
    switch (state) {           //decide what need to be done with it
      case waitforX:           // haven't got the X yet
        if (c == 'X'){         // there it is
          Serial.println("got the X");
          xValue = 0;  //start the X value off with zero
          state = waitforY;    //gather data until the Y shows up
        }
        break;
      case waitforY:
        if (c == 'Y'){         // the Y came in, gather Y data
          Serial.println("got the Y");
          yValue = 0;          // start the Y off at zero
          state = waitforYdata;
        }
        if (isdigit(c)){       // ignore non numbers
          xValue = (xValue * 10) + (c & 0x0f); //gather incoming numbers
          Serial.print("current Value of X is ");
          Serial.println(xValue,DEC);
        }
        break;
      case waitforYdata:       // same kind of thing with the Y data
        if (isdigit(c)){
          yValue = (yValue * 10) + (c & 0x0f);
          Serial.print("current Value of Y is ");
          Serial.println(yValue,DEC);
        }
        if (c == 'X'){  // this just starts over again
          Serial.println("got a beginning X");
          state = waitforY;
        }
        break;
            default: //ignore anything else
        break;
    }
  }
}

This is obviously not a secure way to do it, that would be a really, really big example.  However, this will parse an input (a little bit) and gives you something to start with and expand upon.  This is ONLY a code fragment so you will have to adapt it to your code.  Just steal the idea to get you started.  I'm sure you will notice that I started with the same example you did.

Code:

   Client ControlClient = Control.available();
   if (ControlClient) {
    // an http request ends with a blank line
    while (ControlClient.connected()) {
      if (ControlClient.available()) {
        char c = ControlClient.read();
        // if you've gotten to the end of the line (received a newline
        // character) you can send a reply
        if (c != '\n' && c!= '\r') {
          netbuf[index++] = c;
          if (index >= sizeof(netbuf)) // max size of buffer
            index = sizeof(netbuf) - 1;
          continue;
        }
        netbuf[index] = 0;
        Serial.println(netbuf);
        // standard http response header
        strcpy_P(general, PSTR("HTTP/1.1 200 OK"));
        ControlClient.println(general);
        strcpy_P(general, PSTR("Content-Type: text/html"));
        ControlClient.println(general);
        ControlClient.println();
        if (strstr_P(netbuf,PSTR("GET / ")) != 0){   // This will put up the time if you have it.
          strcpy_P(general, PSTR("<html><body><h1>"));
          ControlClient.print(general);
          strcpy_P(general, PSTR("My Web Site<br>"));
          ControlClient.print(general);
          tNow = now();
          strcpy_P(Sgeneral,PSTR("%d:%02d:%02d %d/%d/%d"));
          sprintf(general,Sgeneral,hour(tNow),minute(tNow),second(tNow),month(tNow),day(tNow),year(tNow));
          ControlClient.println(general);
          strcpy_P(general, PSTR("<br></h1></body></head></html>"));
          ControlClient.println(general);
          break;
        }
        else if (strstr_P(netbuf,PSTR("GET /supersecretpassword")) != 0){ // obviously not totally secure, but you can check stuff this way
          tNow = now();
          strcpy_P(general,PSTR("Wow, you guessed it !"));
          ControlClient.println(general);
          break;
        }
        else{
          strcpy_P(general,PSTR("You messed it up dummy"));
          ControlClient.println(general);
          break;
        }
      }
    }
   }
   ControlClient.stop();

I noticed that in the description, but the schematic link didn't work and there just aren't enough smd resistors on the board to provide voltage dividers for the pins, nor is there a buffer chip on the visible part of the board.  They could well have some stuff on the bottom of the board, but they don't show a picture of that.

So, it may well have conditioning of some kind, but I just couldn't find it.  Let us know when you get it.

Good point markbee.  I never considered the power eaten up by the LEDs, I was always fascinated by the way they flash.  I'll keep that in mind when I build a solar powered sensor.  Probably put the LEDs in when I'm testing it and take them out before I deploy it for real use.

There's just something cool about flashing lights.....

I was coordinating my house clocks using a NIS server until....it was down for several hours.  I'm a bit of a nut about having the little machines monitor their own operation and reboot as necessary and when the NIS server went down, I lost my clock because it rebooted at the end of every retry interval.  That prompted me to get a (relatively) cheap GPS module and take time from the satellites.  That is working really, really well.  In my case I provide the time from a single clock over my ethernet network and a XBee broadcast.  That way I can sync devices based on either protocol.  The little GPS module has a RTC in it too so I don't have to be as careful about reboots.

Your clock is a really cool device.  Doing it from the ground up is impressive and fun.  I would have made the cancel button about 100% larger though; my aim is bad in the morning.

I exclusively use series 2 XBees so I don't have anything definitive on the series 1 for you, but I have never, ever made the XBee work reliably connected to the usart ports at the same time I'm using the USB port.  Tried it a couple of times and there were so many complications I just gave it up forever.  I do what you did.  I create a softwareSerial port on two different digital pins and transfer between this and the usart port (digital 0 and 1).

If you only use pins 0 and 1 for the XBee and disconnect the USB it will work fine; just never worked at the same time as the USB for me.

Oh, I don't have any problem with the series 2 devices working the first time I power them up. That is, if I already have a coordinator running somewhere.  The XBee comes configured as a router with DL set to broadcast and it finds the coordinator and just starts working.  However, if I reprogram it, all bets are off.  About 80% of the time the darn things have some problem or other during programming and I lose various items that have to be programmed back.  Now, if I try to bring two of them up and no coordinator already running, they can't talk since there is no coordinator (new ones always arrive as routers).  One of them has to be set up as a coordinator before there's any hope of them working.  For that very reason, my coordinator is in a device that has almost nothing to do.  It just serves as the house coordinator and a simple clock.  That way I always have a coordinator on line.

Net, the solution you arrived at is almost exactly the same one that I arrived at.  Good job.