The difference between the two is that the XBee will automatically retry the transmission.  This means a longer transmission time if it can't get the message out.  This will use a little more power, but it doesn't sound like enough to kill things.  I'm not familiar with the shield, could it have something floating around the reset pin?  Maybe pull it high as an experiment or something.

I had an arduino close to a permanent magnet motor (a big one) and the reset pin had a wire running to a switch on the side of the enclosure.  The arduino would reset sometimes because the wire picked up enough noise from the motor to actually reset the board.  Totally random event and it was easy to fix by filtering the stupid wire.  Took a while to figure out though since my presence in the noise field would cause it to stop having a problem.  Every time I sat and watched the thing to see what was going on, it quit failing.

Before you give up on the idea though, take a quick check of the voltage to the power pin on the processor.  It could drop while the VIN is staying stable.  I've never seen this on an arduino, but I have on other devices where the 3.3 volts is derived from 5V regulator instead of the VIN.  I suspect it is staying stable because it didn't die when you moved the antenna.

But, there a lot of arduinos out there that have nothing hooked to the serial pins when they are running, and they're putting debug info out the serial port all the time without any problem.  I have a bunch of those and they never reboot because of buffer overflows.

No, the arduino doesn't reset when the serial buffer overflows.  I took a look at your code and didn't see anything that would obviously cause it to reboot.  However, it's just slightly possible that your robbing the device of power during transmission.  I say this because I had an arduino that was rebooting (I didn't know, it was hidden away) when it was transmitting.  Seems the XBee was sucking the life out of the power supply and lowering the voltage enough to cause a reboot periodically and unpredictably.  A new power supply fixed this problem.

shields are nice and make the combination of devices convenient, but not absolutely necessary.  The serial pins are 5V tolerant and the arduino has a 3V supply.  I recommend choosing a shield that will meet your needs, but if you haven't when the XBees arrive, you can always wire them in direct to start your project.  Also, you don't need a full blown shield, there are breakout boards that can do the job.  Sparkfun and adafruit both have them and there are others out there.  Search around and read their capabilities before choosing, don't just grab the first one you run across.

Let me sure I understand.  You want one arduino to be both a client and a server, and you have another arduino that you want to be a server.  So, the PC as a client sends to the first arduino which turns on a light, then that arduino sends to the second one that also turns on a light.

If I got that correct, you can certainly do it.  You'll have to combine the server and client examples in the playground on one of the arduinos which is a little confusing, but I've done it a few times successfully.  The the second arduino is just the client example, or you can duplicate the first arduino and just not use the client code until later when you expand the system.

The current clamp methods do work, but are nowhere near as accurate , mainly because they dont measure the voltage, only the current.

Go look at the site above, they measure the voltage.  They also have done a lot of comparisons with various wattmeters and come out pretty darn close.  Using the pulses from the power meter is probably the best way to go, if you have pulses.  A heck of a lot of us don't have pulses to measure.  My setup measures the voltage and the current and compares very, very favorably with the power meter.  I don't accumulate the readings, too many power failures, but I can tell you instantaneous usage on a second by second basis, which the power company won't tell me.

Go to the playground and look at the Time and TimeAlarms library.  You don't have to actually set the time, but you already have an RTC, so it should be easy to do.  In the Time header file are a lot of macros including days between dates and such.  Also, out on the web are a ton of days between dates routines that you can use.  Most of the samples also have the seconds between date that will work for you as well, although saving the unix time when you start and just subtracting it from the current time will give you seconds pretty easily.

Yep, it's mentioned a few times on the site.  http://openenergymonitor.org/emon/

You probably need to sprinkle them around more places.  I've had to go so far as to put them before the return of many routines to get a clue what was happening.  Sometimes when you're recursing, the level of recursion can get so deep that you run out of memory.  If it returns, the memory unwinds back to a good level.  This can happen when some routine allocates and then calls something else as well.

You can get lost and not have any idea what the heck happened until you really start to dissect it.

But then, you could also just be running past the end of some buffer somewhere and clobbering yourself.  These problems can be tough to find.  Been there, done that...sigh.

Check in the playground for memory usage.  There are a couple of routines there that can tell you how much you have left at any given time.  I use them extensively to keep away from running out of memory.  You can put them in temporarily to measure what you have left and isolate a problem area then fix whatever is needed.

In a couple of hard cases, I put them in the loop() and automatically rebooted the board to clean things out when free memory reached a low number.  This was a stop gap measure I used while I tried to figure out what the heck was going on.  These days, I try desperately to avoid using Strings and use the old reliable strcat, strcmp, etc. instead.

Something like:

Code:

#include <avr/pgmspace.h>

void showMem(){
  uint8_t * heapptr, * stackptr;
 
  strcpy_P(Dbuf,PSTR("Mem = "));
  Serial.print(Dbuf);
  stackptr = (uint8_t *)malloc(4);   // use stackptr temporarily
  heapptr = stackptr;                // save value of heap pointer
  free(stackptr);                    // free up the memory again (sets stackptr to 0)
  stackptr =  (uint8_t *)(SP);       // save value of stack pointer
  Serial.println(stackptr - heapptr);
}

// and then sprinkle these around to get a feel for what is going on

    showMem();

Or maybe you would prefer:

Code:

#include <MemoryFree.h>

void showMem(){
  strcpy_P(Dbuf,PSTR("Mem = "));
  Serial.print(Dbuf);
  Serial.println(freeMemory());
}

// and then, as above, I sprinkle these around to see what is happening

showMem();

I use both in different applications.  Don't have a preference either way.

LOL, many people have exactly the same problem with the language.  Even after you get proficient enough with the words, you'll have problems with the jargon.  Each sub-field has a specific language they speak.  Get volts, amps, resistance, and reluctance under control first then you'll have a much easier time understanding.

With your particular project, you'll be facing wires that are bigger than you expected and hard to bend, hook together, or even purchase due to the content of metal in them.  But, it's a really cool and useful thing to do and well worth the effort.

But people love to help with projects like this, so you won't have too much trouble getting advice and suggestions.

Mikee, after you experiment with timers, and get an understanding, come back to the forum and talk with us about temperature sensors and humidity sensors.  You could use both of these in your house.  Also, you can even sense airflow so you'll be sure the exhaust hasn't been plugged by something.

This will be a nice project.

The current draw is the big item.  The higher you go, the harder it is to deal with physically.  I measure up to 200A and wanted to avoid devices that were put in series with the current, so I used a current sensor (google it).  The device you show is fine up to 50A or so, although the wires get pretty darn big there as well.  For real accuracy, you will want to measure the voltage also so think about how you're going to sample that.  There's a web site that discusses this is huge detail openenergymonitor.org take a look there for ideas.

They're in Wales so you should be able to drop them a note if you want to.

Yes, you can do outside temperature by simply putting a sensor outside under an eave or something.  You can also get the weather off the internet and do it that way. 

Have fun.

I'm starting to understand, but remember that I can't guess what you want to do, you have to actually tell me.

But, look in the arduino playground for the Time library and the TimeAlarm library.  With these two libraries you can set up the arduino to know the time, then you can set alarms to do things like turn on the relay at a given time or for a given duration.  So, set the time, then set up alarms based on the day and time, then set an alarm for the duration to turn it back off.  You can do this based on the actual day you want something to happen or you can set it up to operate on outside temperature...whatever you need.

I have alarms that change the temperature inside my house based on the time of day.  For example at 7:00PM, I set the house up for night time, then at 8:00AM, I set the temperature for daytime.  I turn my hot water heater off during the day so that it doesn't run unnecessarily when no one is using hot water.  You loop code can do practically nothing once you set the alarms up and they're easy to change if you want to.

Does this help?