What we have done for our development version is set it up so it can be in one of three modes. Always on (for passageways) so it consistently locks as you walk up and unlocks as you walk away. Always off (always disabled). Or Manual override.

With the Manual override it still unlocks as you approach and locks again as you depart, but it also allows you to lock the door by hand after you come in and will stay locked until you manually unlock it by hand again or send it a direct command from your phone. This way it doesn't unlock randomly while you're walking up to the door to answer it.

It's our first pass at making this particular feature happen.

So say if I've been GPS "home" for five minutes it assumes 'inside'. Then when a Bluetooth sense happens next it is extremely likely I'm going outside. Do not unlock.

Same three minutes without a BT sense pass, it's now nearly certain I'm "outside" still instead of going in and out. Coarse GPS event happens showing the phone is moving from the home geofence? DEFINITELY gone. Do unlock when the next BT sense happens.

Edit: I don't think I'm being clear enough on this telephone keyboard. I feel that with enough GPS logic and location history you should be able to infer when the user is likely home and thus disable auto-unlock. This all explodes when two locks are used, though... Or two authorized users... Or two egress points... Hrm. This is hard. :)

There are some good ideas in here. Thank you.

I don't want my door toying with me like this.

This could be an added incentive for customers to purchase your hardware for both their front and back doors. Then they've got two radios.

In two-door installations, it may be possible to look at the signal strength as received at the back door to tell when the user is inside the house. That could get you out of the time-of-arrival calculation business.

Another possibility is a small, cheap IR sensor. If there's a person inside the house within ~10 feet of the door, it doesn't unlock automatically. The basic idea would be similar to the sensors on toilets and urinals in public restrooms.

In any case I'm glad to hear that my Tom Swift amulet is finally being made. Next up, the Triphibian Atomicar!

Sunlight will be an issue though...maybe IR and ultrasonic?

I had a daemon running inside my house which looked for my iPhone on the internal WiFi network. When my phone went off-line it signaled that I had "left" and after a certain duration went into "watch-to-unlock" mode. When my phone reappeared on my network I would signal to unlock.

I know you are probably trying to keep as much of the logic off the perimeter of your ecosystem (Phone App and in-home hardware) but, it was the best way I could figure it out.

I'm not sure how easily you could implement this sort of detection on Lockitron's end, though. I use a static DHCP lease on my router and simply ping the phone.

Just thinking out loud here! Wifi presence seems super useful from my limited experience, and I'm not sure why more tech things aren't using it.

Great stuff and good luck!

Don't you mean the other way?

Also, anyone that's seriously worried about the security of this device should be mostly concerned that the standard keyhole still exists on the other side of the door because they're trivial to bump or pick.

Have you considered any sort of pingdom style monitoring for that sort of thing?

(Obviously, it's a really unlikely scenario right now, but if they can keep it off the air long enough to open the door and introduce it to Mr Big Hammer, notifications may not be forthcoming :) )

http://en.wikipedia.org/wiki/Spark-gap_transmitter

Building a proper one is still pretty easy. It's carting around a big enough battery that's the problem.