djb_rh:
I'll test that broadcast/coordinator ID chat again soon. I assumed it was going to work and was a bit surprised when it didn't, but didn't dig further. The only settings that had been touched were PAN ID and the Destination addresses, but maybe I screwed something up there and just didn't notice.
PAN ID doesn't matter, as long as they are both the same of course. But be sure DH and DL are set to their default values, OR set DH and DL to zero for the router (which is the default) and set the coordinator's DH and DL to those of the router. That'll get things into a unicast situation which is what I would want anyway.
I wasn't trusting the pinouts of the Series1 articles in any way, just using them as a guide. I know I connected power/ground correctly from my 2xAA battery pack. The only other thing I connected was on one of them a switch that was pulling an input pin to ground (DIO pin 0 configured as a digital input) and on the other DIO pin 0 was connected to the long leg of an LED with the other end connected to ground and it was configured as "digital output HIGH". I assumed the HIGH/LOW part was just what state to put it in as bootup and that from then it would flip it however it was told to. (And I was using two Sparkfun breakout boards, which have the pinouts labeled where you can see it easily over the breadboard.)
Given that, I can't see how I could have hosed them. I would think it would be especially odd to hose them such that they both APPEARED to work fine as far as XCTU was concerned but simply wouldn't talk over the radio. I would have assumed total annihilation, or just for the input/output pin itself to quit working. But obviously with these things anything is possible, I guess.
Always, always, always use a series current-limiting resistor with an LED. Further, the XBee I/O pins have very limited current source/sink ability, only a few mA. I usually use a 1K resistor for LEDs with XBees. If the LED was still working, maybe things are OK, maybe not.
So my application is pretty simple. I'd like to make a long range gate trigger. I could probably drop back and punt to Series1 devices, but I was hoping to use Series2 in case I need to put a router in to extend my range. I own a lot of property BEFORE you get to the gate I want to trigger (which only needs to close a relay on the receiving side, so that's dead simple), so I could get a router further out. Basically the gate is SLOW and I'm impatient. I can actually open the stupid thing with my cellphone already, but that's not reliable due to cell coverage in the area.
And I was HOPING to do it without an Arduino in the mix, since it's really a simple button press on one end to flip a relay on the other. I'm guessing I can still do it, but it sounds like it's a good bit more involved using Series 2, and may be easier to just add the Arduino on the receiving end (I do want to have multiple senders and was planning to add the encryption layer for security).
Very much doable and straightforward with the ZB modules. The difference is at least one microcontroller will be required, which may not be the case with the 802.15.4 modules. Just off the top, having just an XBee at the gate, and an Arduino/XBee combo for the control should work fine. Basically the Arduino would just send a remote command to set a pin high or low on the gate XBee. Add an Arduino at the gate and then it could transmit its status back to the control node. Actually that might be doable without an MCU too, just by enabling periodic I/O transmissions. That would be cool because as soon as the control was in range of the gate you could have a notification of that fact, plus the current status of the gate, i.e. open or closed. Add a limit switch to tell when the gate is really closed and it could be a fairly robust system.
Good luck!