Good article, but...
One thing I noticed with my two working Xbees is that if you use default Router and Coordinator destination addresses (zero on the Router so it talks to the Coordinator, and FFFF on the Coordinator to broadcast), I could NOT chat both directions. I could only get text to go from the Router to the Coordinator, but not the other direction. But when I switched back to hard coded destination addresses, text flowed both ways (with NO other changes to the XBees or the terminal emulators). Is that normal?
And that doesn't address communication using i/o pins. Should what I describe (and what the Series1 articles I link describe) "just work" with a Coordinator AT and a Router AT? Because in one instructional video I found, it seemed to imply anyway that one was going to need to be API and one AT, but I forget which it said. I think the one with the switch was supposed to be API and the one with the LED could be AT. Something about serial I/O being fine with both AT, but if you wanted I/O from input pins then it was going to need to send it using API frames. I'm still a bit fuzzy on that part.
And so even if you are saying pin based I/O should work based on your article (one Coordinator AT with a single pin as "digital input" and one Router AT with the same pin as "digital output HIGH"), is there any chance I hosed my two XBees, or should they work just like the series 1's in the article above? By that I mean with the same "circuit" on each end, I know the setup is different.
I totally get the Pan ID situation. And I have no other XBee interfaces locally that I know of, anyway.
--Donnie