Well, I wired my Easy Button with an XBee. After all that hassling over reading serial data in Processing, I realized it was more appropriate for this project to use the simpler I/O Line Passing Mode of the 802.15.4 "Series 1" XBee nodes.
The way I/O line passing works, the status of any enabled digital or analog inputs on the transmitter will be echoed by the corresponding digital pins or PWM pins on the receiver.
(Alternatives ranged from sticking a hard-to-get to battery pack inside to installing a complete charge circuit for a lithium-poly battery. However, the LiPo's run as high as 4.1V when fully charged, meaning to protect the XBee you'd need to add a voltage regulator. The regulator provided on the commonly available XBee breakouts from Sparkfun and Adafruit drop about a volt, however, meaning the usable charge of the LiPo is severely limited. I have ordered a low-dropout regulator from Digikey, but I'm not sure I want to spend the time wiring up an LDO as well as LiPo charge manager!)
(Yet another alternative is to use a 3.3V boost power converter, that ramps up and regulates the output of a pair of AAA cells...all the way down to the output of one nearly-discharged cell (something like 0.8 volts) before it finally gives up. I have one of these on order as well!)
Oh, and I already had the other end:
And it all worked great on the bench, and I soldered up everything and closed up the button.
And then I did the plugs-out test and it failed.
Battery usage was fine...it went past twelve hours on a fresh-charged pair. But the transmission was very much line-of-sight; at ten feet, it couldn't even transmit through my own body if I held it behind my back.
This is as against the original proof-of-concept, when I got 120 feet of range through several set-pieces. The primary flaw appears to be the nature of the I/O Line Passing Mode itself. It appears to transmit only when the status of the digital input line changes (which makes for great battery life, at least). This means that not only is there no re-try, but the I/O pins can lose synchronization and have to be "reminded." Which is NOT good behavior for a theatrical effect.
However. I've gone back into the transmitter and set IR to FF -- that is, forcing the node to take a sample of its inputs (and transmit the results) every 255 milliseconds. And I'm reading up on sleep modes, which should accomplish the same thing with a better power economy. This has increased the robustness of the transmission enough to where I can transmit reliably at 20 feet and through one wall. I probably need to juggle settings on the receiver as well to make sure it resets the outputs within a quarter-second of any break in radio contact.
I don't know yet if the batteries can handle this greater transmit volume, but as of this moment I've been operating for one hour and 7 minutes on the same pair of batteries.
I believe the more robust option is going to have to be full serial transmission, for which I need to add an AVR (and which means I finally have to learn how to use the UART on an ATtiny). Other options are going to regulated power (and supplying the transmitter with the full designed 3.3 volts), using wire antenna instead of chip antenna XBee models, and upgrading to XBee Pro (which have much greater output power and spec at over twice the effective range).
In the meanwhile, I could try to use this current unit, by locating the receiver close to the stage. But the show has been rehearsed already with a visual sound cue instead of an actor-operated one, and there's no real point to changing now (and even less reason to introduce the risk of new technology).
The batteries made it past ten hours in the new mode. On further reading, and tentatively confirmed in testing, when IR is set at other than the default of "0" the node does wait for an ACK and re-try up to three times if it doesn't get one. And I lowered my sample interval to about 100 millseconds. And also set a 100 millisecond automatic reset interval on the receiver's pins using the Tn command so if it loses contact with the transmitter it won't "hang."
In the theater, it made it from the stage to the back of the house but only when there was a clear line of sight. Next step, then, is to swap out the existing node with a Pro node instead.
ADDENDUM TWO: with an XBee Pro node installed, I was able to achieve reliable trigger from stage to sound booth. In fact, it triggered semi-reliably from all the way back in the dressing room. My first test was actually from orchestra pit to lobby -- I had the parts spread out on the Concessions counter while I was putting in the Pro node, and I draped a wireless mic over my laptop computer then went down and listened to the computer through the band vocal monitor!
As I said in an earlier post (Theater Should Not be a Hackerspace) although it works and the actor admired it very much, it will not be used in this show. We are already rehearsed with taking the sound cue manually. But now the button is ready for any application down the road where I need to hand a button to an actor or band member or Stage Manager to trigger an event wireless-ly.