Well, back in the day, chumby did power itself back on again, but the majority of the team thought that it was not intuitive power button behavior to have that happen (I don't personally understand the logic so I can't defend it, but I was also the odd man out on this one), so we changed the chumby to not do that. I guess it was one of those battles that just can't be won.
Modifying the power-on behavior of the chumby can be done by modifying the cryptoprocessor (CP) codebase and reflashing the CP device. This is not something that an automatic firmware update can do, unfortunately, so it will require you to open up your chumby and connect a JTAG cable to it. The CP does all the power management for the chumby, including monitoring the power-on state of the device and watching the power button. If you do this, be careful to flash only the F0 bank of flash, otherwise you will overwrite your crypto keys and you'll lose your chumby configuration profile (keys are kept in the F1 bank, you should be able to configure your JTAG burner to leave it alone). There's a unique ID in there and if everyone starts setting it to say, all FF's (like it would if it were just erased) then you'd all be contending for the same unique ID, which would make it impossible for you to use your chumby with the chumby network.
Of course, that's the "Big Hammer" way of fixing the problem. There's another solution, which currently chumby is planning on implementing in a firmware update, but I'm not yet sure when the feature is going to be released. The CP has built into it a failsafe facility that wakes up and resets the chumby some number of seconds into the future (assuming that there is either a battery installed or the DC power source is available at that time). Thus, the idea is that when you set an alarm in userland, you would also set the CP failsafe to wake up and reset the chumby a few minutes after the alarm. If the power did go out overnight then, what would happen is the chumby would be off for the rest of the night, but at the scheduled alarm time it would reboot and then sound the alarm. The reason why you want to set the CP alarm to be a few minutes after the scheduled alarm is you want to be able to clear the CP alarm flag if the normal alarm does fire, so that the chumby isn't reset during "normal" conditions.
The other option, of course, if you have small power outages is to take the beads out of the bottom of the chumby bag and put a 9V battery in there. It's designed to tie the chumby through brief power outages overnight--it doesn't have enough juice to power the chumby for any extended period of time, e.g. walking around the house while the chumby is active. Again, the current Insiders' chumby firmware lacks the software to control the on-battery behavior: the current behavior just leaves the chumby on until the battery is drained and then the system malfunctions and does silly things, instead of shutting itself off when the battery is too low for proper software operation. We also haven't advocated widely putting in the 9V battery because we haven't been able to write up the "how-to" guide on doing it. Many users are trying to leave the beads in, or they are distorting the leather cases, so that the control panel switch is permanently pushed down by the leather case, which is a problem. However, generally if you have a gentle finger and you remember to remove the beads, you should be okay installing the battery.
Once the feature is coded into the firmware, what's supposed to happen is that within a few seconds of power loss, the chumby will stay on, but then will eventually turn itself off to avoid running down the battery. This way, if the power is still out at your wakeup time, there is enough juice left in the battery to sound the alarm and wake you up.
I'm afraid to say that all these features are still in development in the firmware, so standby...it will get fixed.
7BAA 2E53 01C1 DCFF 497B E7F0 9699 A303 78F0 D9B9