TLDR; Batteries would actually last for ages if you put the digispark to sleep - cheap radios from ebay work great and the transmitters use no power when not in use, reed switches are cool.
Personally, I\'d just use a battery and a digispark, with 433.92mhz radios. If you search ebay for \"433.92mhz ook\" you can get a pair of 433.92mhz radio transmitter and receiver for about five bucks - sometimes much less. These only require a short length of wire as an antenna, and each have a data pin which connects to one of the digital IO of the digispark or similar gadget. Functionally, they work a bit like morse code - you send pulses through the data pin, and can send information by the varying length or interval between your pulses. This is the same system used by those cheap radio doorbells, and a lot of car remotes and other little random home RF gadgets. Better still, the transmitter boards are very tiny (smaller even than the digispark) and consume entirely no power at all when they aren\'t transmitting a data pulse.
By using the sleep modes of the AVR, you can have the digispark go in to a deep sleep where it uses far far less than a milliamp, and wakes up resuming your program as soon as one of the IO pins changes state. By connecting a reed switch you can have the digispark go to sleep and wake up whenever it detects a change, broadcast out a few times a little message announcing the new state, and have a computer, arduino, or another digispark pick up the message somewhere else in the building and relay it to whichever web services you want. If you like, you could even repurpose infrared remote control libraries to do this work for you - they already implement simple protocols for sending button presses over unreliable mediums, and are well maintained for the arduino platform. Otherwise I\'d be inclined to have the receiver digispark or arduino time the distance between each pulse and send a message to the host computer with those numbers - then you can have a little ruby, python, or c program look at those and compare them to a list of recognised commands and see if the timing closely resembles your door gadget. Alternatively you can recognise the codes inside the digispark and have it emulate a keyboard and just type in some hotkey on the host computer which launches a little notifier script somehow - I ended up using a script which watches my digispark-equivilent doorbell receiver because I found hotkeys didn\'t work when my mac\'s screen was locked.
If the digispark\'s come with brown-out detection disabled, you should be able to have the digispark consume roughly 0.0001ma while asleep, watching for changes. If you used a pair of 3v lithium button batteries and a diode to knock the 6v down to about 5.4 (which the digispark can accept directly). Button batteries have a capacity of roughly 200ma, which gives you a sleep time per battery change of about 7 years. Broadcasting would happen for about 10 milliseconds each time the state changes, with power consumed during pulse send only, and that power is about 10ma, so you can probably figure broadcasting consumes about 5ma for a moment. For comparison, a tv remote uses about 50ma when sending, averaging about 20ma between the on and off pulses, but they also transmit slower and for longer, and transmit repeatedly when holding buttons down.
Just food for thought.
Of course, if I had this problem I\'d be more inclined to solve it with lasers and mirrors, not computers and radios.
