It is intrinsically unsafe connect direct to the power mains.  Anyone who comes here asking how to do it is assumed to be not experienced enough to recommend the practice to (at the risk of encouraging dangerous behavior.)

I've seen this over and over, the question is:  why?  I just don't accept that anything is intrinsically unsafe that is done by device after device that you can get in the marketplace.  Every single extension cord is connected to the mains.  Every X10 or insteon device is hooked to the mains.  Every wall wart is connected to the mains.  We mess with mains voltage every time we replace a socket on a table lamp.  Or, for that matter every time we change a light bulb.  The much touted kill a watt is connected to the mains.  This kind of thing just doesn't hold water if you actually examine the statement.  As for encouraging dangerous behaviour, don't encourage me, just tell me why it's dangerous to use a voltage divider.

Also, don't make assumptions about my experience level or the experience level of anyone else that posts. Assumptions about people's experience is not nice, ask if you wonder about it.

The safest way to measure power mains voltage is to simply use an inexpensive (perhaps even free) AC wall wart and simply rectify and filter the voltage. The DC voltage out of the circuit will be directly proportional to the RMS power mains voltage. And there are various ways of measuring current also. There are Hall-effect devices for measuring DC (or isolated AC), and there are clip-on current transformers, etc.

I don't want the rectified and filtered voltage stepped down by a transformer to what people assume is a 'safe' voltage.  I want the instantaneous voltage taken at many points in the cycle both above and below the zero reference; a filter would destroy that data.  I would rather not have the phase offset caused by the inductive load of a transformer, this can be calibrated away, but avoiding it entirely would be better.  I know about the hall effect devices and plan on using something like http://www.allegromicro.com/en/Products/Part_Numbers/0758/index.asp to get the instantaneous current.  That device will hook directly in line with wall power. 

I'm not at all afraid of 110, 220, 440 etc.  I have a healthy respect for the current capability and the possibility of higher voltages causing problems that are somewhat unexpected, but I just don't buy that it's intrinsically unsafe.  It might be less safe, but one must take care with anything that one does.  Heck I've had 12V blow a hole in a 440 stainless adjustable wrench when I didn't pay enough attention an shorted a car battery; that's a voltage everyone on this forum has used.

So, now that we've both got that off our chests, what's wrong with a voltage divider?

I'm not sure if this is what you need, but I made a really simple temperature sensor hooked to an XBee for measuring outdoor temperature.  I plug it into an outdoor outlet and just let it run.  Took two 10K resistors, a wall wart, and an XBee and of course, a wall plug.  Since the XBees can forward for each other, you could easily get by without buying the expensive pro models.  Last time I looked the pro modules cost 3x the lower powered ones and outside, you can get pretty good range.  The problems with transmission distance come when there are walls involved, especially outside walls that have some kind of metal lathe.  If you want to see my little device, go to my web site at draythomp.blogspot.com and look behind the tab "world of XBee"  a picture of it is at the bottom of the page.

I just compiled SimpleServer from the examples under IDE version 21 with no problem.  What are you trying to compile?

Since you're using the AT command configuration, there's only a few things you need to do.  Take a look at my site draythomp.blogspot.com behind the tab that says "World of XBees" and I describe the things that can cause you trouble getting them to talk.  It's not really hard.  Just pick a pan id, note the addresses of the XBees and start configuring them.  The easiest way to get them talking is to have both of them plugged into the same computer.  If you have the hardware to do this I highly recommend it.  You would need a couple of devices of some type to connect them to the computer and open two instances of XCTU to connect to the XBees and just configure and test away until you understand their interaction.

The very first time I did this I used two arduinos with the XBees connected to them and each arduino was USB connected to a laptop.  Lots of hardware, but it's what I had at the time.   Now, when I experiment I have one XBee to USB adapter and an Adafruit adapter plugged to an FTDI cable.  It's just too convenient to be able to change and test each XBee and immediately see the results.

In direct answer to your question ATDH and ATDL are necessary, but you may have to do a couple of other things as well.

Google is your friend when you're trying this.

Thanks for the description.  I've worked with 120 @ 60 a lot, take a look at the power monitor I built  draythomp.blogspot.com it's behind the tab about how I monitor power.  What I'm looking for is why there is so much bad press about messing with the mains.  If you open an X10 device, it is hooked directly to the wall plug and these things don't seem to kill anybody.

See, a voltage divider would directly follow the power levels and I could sample it around 3K times a second to get the instantaneous levels.  There's no reactance from a transformer or capacitor to deal with so no phase delays to worry about in the calculations.  It just seems like the perfect solution, but there is post after post on the web telling people not to do this.  I just can't see why not.

The solution of turning the thing off is actually a darn good one, but I've got an arduino.....I just have to get it involved somehow.  The idea of monitoring the freezer to be sure the temp is low enough, controlling when it uses power, maybe tracking the door to see if someone is trying to steal a steak is pretty darn appealing.

Dryer?  Did I mess up?  This particular project is for the freezer.  The dryer will come, but not right now.  See, the dryer must be turned on by a human, and I can put a contactor in to stop a human from turning it on.  The freezer cycles on its own and goes into the defrost mode based on some timer inside it somewhere.  The idea is to eventually control it such that the fans in it can run, the compressor and defrost modes would be suppressed during peak charge periods and maybe an LED somewhere telling people to keep the darn door shut.

It plugs directly into one of those regular three prong plugs common on our walls in the US.  

There are two problems with the transformers 1. cost and size  2. phase angle change that affects the power factor measurement.  The phase angle changes are not a big deal and I can only hope for a close approximation of the actual power usage, so I maybe could ignore that after I understand what the difference is.

See, I plan on building two of these, one for the freezer and one for the refrigerator.  By letting them talk to each other or setting aside time slices I can keep them from turning on their separate compressors at the same time.  Each one only uses a few hundred watts, but when they both come on, it can add up.  I can also keep the defroster off until off-peak billing periods, then let it run it's little heater to its hearts content.  But first I want to study the power profile of the devices; that means measuring and recording the power over some period of time.  And Yes, I realize that this project will probably expand to replacing most of the control circuitry in these devices.  But one has to start somewhere.

Heck, by controlling them properly I may be able to actually turn on an air conditioner occasionally, summer's coming.

As some of you know, I'm on a continuing quest monitoring and controlling my power usages....successfully.  Now, I'm seeking input on a new phase of the project.  I want to measure the power to my freezer.  Yes, I could use a tweet a watt, but that's been done and I would like to create another solution.  My first problem is measuring mains voltage.  I have split phase 220 which means I have 110 at the plug for the freezer.  Why the heck can't I use a voltage divider?

Something like:  Hot wire -> 1M resistor -> some other value resistor ->1M resistor -> neutral wire.  I would measure the voltage across the middle resistor at the arduino and tailor the value to keep it in the 1-2 volt range.

There's a ton of posts on the web telling everyone not to do this because it will kill you.  Huh?  Sure the resistors could cook and short out putting the mains voltage at the arduino pins, but aren't there resistors designed not to do that?  I could put a 1 or 2 milliamp fuse in line as well. 

What really are the dangers?  There are so darn many devices out there that connect direct and don't have a transformer that the danger must be overstated.  Doesn't it?

It is totally possible with the series 2 XBees.  Depending on how you do it, you may have to reconfigure the XBee.  Can you send anything from the XBee end device to the coordinator?  You may need to give a few more details about what you're trying.

So what I understand from this is that it will not even be on the serial port of XBEE2, i.e Serial.available() < 0.

No, you can't see it at all.

If I use ATND and get all the names of the Routers in range and I have more than 10 nodes next to the XBEE, will I have enough buffer size to get all of that data on Arduino FIO?
Do you have any better solution?

You should be able to get a list of all the devices on the entire network if that's what you need.  In AT mode you get a series of lines back with data in them about the various nodes and you have to parse it yourself.  In API mode you get a series of messages, one per device out there that responded.  The limit isn't the XBee, it's how fast you can grab the data and store it in a meaningful fashion (meaning something you can actually use).  This is the method I would use.  You can't tell how far away it is, but you can use a broadcast message and set the maximum hops to 1.  That should limit which devices receive it to those in range (I have not tested this).  From there you can send messages specifically and make them send their RSSI back.  This will be a lot of work.

what I meant was how to check, is there an AT command that provides this or should I connect PWM of XBEE to a DIO of an Arduino?

ATDB will give back the signal strength of the last packet received.  There's some restrictions on this so look at the documentation to be sure how to use it.  http://ftp1.digi.com/support/documentation/90000976_G.pdf  page 132.  And yes, I actually have read most of that document.

1 - Assuming we have three XBEEs, one is configured as a coordinater, XBEE1, and the others as router/end-devices, XBEE2 and XBEE3. If the coordinator is configured to send to XBEE3, by using DH and DL, but XBEE3 is not in its range but XBEE2 is in both of XBEE1 and XBEE2 ' s range. The message will be routed to XBEE3 through XBEE2, I know. But can XBEE2 change the content of the message or it only acts as a " Data Link" layer?

No, based on Digi's documentation, none of their devices can change a message targeted for a different device.  In your example XBee1 sends, XBee2 forwards without looking at the payload data at all and XBee3 receives.  As best I can tell, the fancy programmable XBees (more on these devices below) can't get at the forwarded paylod either.

2 - If I have  100 xbees let's say, and they all have the same PAN ID. However, for a certain situation, I want let's say XBEE 67 to send a message ONLY to the XBEEs in its range without them routing it to other xbees in the network. Can that be done? I'm thinking of giving each node a node identifier and then at the node that wants to send to the ones next ot it, it only has to send atnd and get the NIs of the nodes next to it and use ATDN to send to them. Is that feasable using only the 128 bytes of serial buffer on the arduino FIO?

Yes, you can do this.  It isn't part of the XBee's operation, but you can certainly give them meaningful names, and then send to the appropriate devices using something like an arduino to set up the messages by getting the addresses based on the names.  If you are building your own simple table of names and addresses, you can send to specific devices based on the lookup.

3 - For two adjacent nodes, how can I get the RSSI value of one of them from the other?

You have to read it, then send it.  I can't find anything in their documentation about remotely reading another XBee's RSSI value.  Or, if you mean how can you tell the signal strength of a nearby XBee, send it something it has to respond to and check the RSSI of its response.  The reason for two answers is because I'm not totally sure what you want to do.

2 - What do you mean by " Normal " XBEEs?. I'm putting the XBEE on Arduino Shields, if that's what you're asking.

There's a bunch of different kinds of XBees.  Most of us talk about Series1 or Series2 embedded modules like the XB24-Z7CIT-004 this is what is normally referred to as 'normal'.  However, last year Digi introduced a number of other devices to confuse us.  They have programmable XBees like the XBP24BZ7WITB003 which one can actually program to do something special and not add a separate processor as well as the special purpose sensors I mentioned before.  However, best I understand, the programmable XBees require the Digi development kit appropriate to them and use a different IDE for developing code.  I have no interest in these devices for a couple of reasons.  First, I can easily use one of the tiny arduinos to handle the programming and second, I can't find out how much the darn things cost.  One of the really small 3V arduinos + a wall wart power supply + a 'normal' Xbee would be an extremely powerful combination.

Did I get all the questions?  Did any of the answers make any sense at all?

I was trying to answer your question and got totally confused by the Digi documentation.  Digi's support site will drive you nuts if you let it.  However, I think there's a couple of things you should consider.  First, here's the (correct, not what you get on the support site) description of the various versions:

** XBee-ZB Firmware Versions **

XBee version numbers will have 4 significant digits. A version number is reported by issuing an
ATVR command.  The response returns 3 or 4 numbers. All numbers are hexadecimal and can have a
range from 0-0xF. A version is reported as "ABCD". Digits ABC are the main release number and D
is the revision number from the main release. "B" is a variant designator. The following
variants exist in ZB firmware:

•   “0" - Coordinator, AT Command Mode (AP=0)
•   “1" - Coordinator, API Mode (AP=1,2)
•   “2" - Router AT Command Mode (AP=0)
•   “3" - Router API Mode (AP=1,2)
•   “8” – End Device, AT Command Mode (AP=0)
•   “9” – End Device, API Mode (AP=1,2)

Digi has developed an assortment of sensor adapter products that use the ZB firmware.  (See
www.digi.com for details.)  Adapter firmware versions include the following variants:
•   “4" - Router/End Device Sensor Adapter
•   “5" - End Device Power Harvester Adapter
•   “6" - Router/End Device Analog IO Adapter
•   “7" - Router/End Device Digital IO Adapter

So, the router/End Device designations you see in XCTU are for the special sensor devices like zigbee temperature sensors and smart plugs http://www.digi.com/pdf/ds_xbeesensors.pdf, not the 'normal' XBees that we usually mess with.  So, you want to use either Router or End Device configurations.  Don't worry, those configurations will support the I/O pins; I tested the router configuration to be sure.  I suspect this is why the Faludi book skips over the descriptions of what all those choices are for.

Now, back to the problem you're researching.  Routers and Coordinators route; that can't be stopped.  End Devices don't route, they just receive the messages and keep quiet about it.  So to fit the model you describe, the XBees in range will have to be End Devices to keep them from forwarding.  This makes total sense because the model of networking that the XBees adhere to requires the devices do everything they can to get the message through to the endpoint.

Perhaps there is another method of doing what you want?

I'm not seeing the ability to hook the XBee anywhere but the main serial port.  When I prowled down through the version (0.2.1) you cited I found

Code:

void XBee::sendByte(uint8_t b, bool escape) {

if (escape && (b == START_BYTE || b == ESCAPE || b == XON || b == XOFF)) {
// std::cout << "escaping byte [" << toHexString(b) << "] " << std::endl;
Serial.print(ESCAPE, BYTE);
Serial.print(b ^ 0x20, BYTE);
} else {
Serial.print(b, BYTE);[/b]
}
}

That won't even support the multiple usart ports on the mega board.  I hate having to remember to unplug the XBee each time I try to download data to the arduino. 

I set mine up for XB24-ZB and the ZIGBEE COORDINATOR API version 2170 and haven't gotten an echo like you're describing.  I'll try to figure out how to get the library you're talking about to try.  There's a slim possibility of it being a library thing.

With the lastest version of xbee-arduino libraries (available as the latest svn update),

Sorry, I don't understand, what's a 'svn'?

which currently is broadcast (DL=0xFFFF, DH=0x0000) as it was forced this way by X-CTU.

Forced?  You can't change it?  Which brings up my next question:

That would be the behavior I would expect too! Anyway I am still receiving a frame with Type-ID 0x90!

Which modem and software are you choosing from the menus in XCTU?

Every answer you ever wanted can be found here http://ftp1.digi.com/support/documentation/90000976_G.pdf.  This is the actual guide to using and configuring them.  In direct answer to your question, no, you cannot program the XBee, you configure it.  There are a ton of options and possibilities.  The easiest one is the one suggested by Jack, have it transmit a voltage periodically.  However, this requires you go to API mode and that requires you program for receipt of packets to get to the data.  Or, you can just notice that you got a packet and move on.  Depends on what you really want to do with it.

Read through the document and you'll see why you get differing answers from different people.  The possibilities with these little radios goes on forever.