Hacker News Reader

Wow, you are all over this thread. I take issue with the way you are jumping in here with a lot of assumptions. Please give me a moment to respond to your assertions point by point.

There is nothing glamorous about airing our faults and where we went wrong along the way, the points you enumerate were our beliefs to a 'T' when we launched our second product a year and a half ago. A handful of these are right while others are mostly wrong or misguided.

1) This is a tough one to address. I see elsewhere in this thread you made the same mistake we did - namely thinking we could get 2mA with PS-POLL. While possible in the lab, that is simply not the case when working under conditions we've seen in the wild. Hypothetically if that were true you could see near instantaneous WiFi all the time. We were optimistic this may be possible but didn't want to bet on it. We made the call that WiFi is advertised with instant response when someone is at the door and delayed response when in power save mode. If there is confusion we are quick to correct on Facebook, Twitter, and even our own blog[1]. Firmware updates to our WiFi chipset look promising but we are not committing to this.

2) Determining intent is a hard problem but hardly a fool's errand. We don't do this through just one BLE radio using RSSI alone as your comment implies[2]. The examples you give are both solvable with what we've built today. The harder problems come from platform inconsistency between iPhone and Android API's. Android for instance only recently announced BLE support and when they did, the phone could only operate in one out of the two roles. Clearly other companies think similar home vs away intent is worth developing too[3][4].

3) Building a proper prototype without functional mechanicals is insane. Don't do this. The other huge rabbit hole here is the word 'reliably.' It's like a client of a web design firm asking for 100% uptime.[5] The best you should do at the 'hardware startup making a prototype' phase is to get it working on your target platform and solve known bugs so it works for 90 to 99.9% with loose specs or 100% of the time under tight optimal conditions. That said, things change. The way we were doing BLE security when we launched was thought to be secure. A ShmooCon talk instilled some doubts that while not broken it may not be the best foundation [6]. We rebuilt a lot of that with Diffie-Hellman and HMAC instead. We saw some connectivity issues with the new approach that were subsequently addressed. Other things change too. Our BLE chip switched from not using signed licenses to using signed licenses between updates. This caused us a bunch of frustration.

4) 40 hours of work to review a design is probably too little. We spent closer to 300 hours on the EE side with the most senior hacker we knew [7]. We worked with another firm on mechanics for 11 months prior to launch. In retrospect that feels about right for how much weight mechanical problems are vs electrical.

That $25-$30 number you site IS misleading. As an analogy, it is almost certainly possible to build a robot which can walk a straight line across a plastic table for this but getting it to walk across arbitrary terrain will cost you if your operating specs are unbounded (think Mars rover.) We know how to build a device that fits over locks for $25 without PCB - we are not happy with what level of performance that gets us.

5) This product however is not designed to be a replacement lock. We have made one of those in the past[8]. Saying something is wrong/inefficient is true for anything asked to do something other than what it is made for. This model of Lockitron is designed to fit over a wide variety of existing locks precisely so that it can work for renters who can not change their locks. It is designed to do it in a way that it does not requires you to take your lock apart so it can be installed quickly and with next to zero mechanical aptitude. It does these things insanely well.

The numbers you site for gear vendors are again misleading. Yes, one can get gears for this cost in this time but you are shifting the burden of development and tooling elsewhere. Making this tradeoff in this case gets us towards a local maxima that is not the product's desired function.

6) This is a bit naive. You don't build to the spec if you're seeing different results in the field. We saw this to be the case with sticky locks and jammy door frames. Other new locks can be put on a clean installation, we have to work with what's there. Similarly, the Bluetooth 4.0 and 4.1 specs promise a lot of things which neither Apple nor Android support. In this case we build for what effects our customers experience not a certification checkbox - especially when that means exceeding the certifications standards.

And if anything that is the takeaway here. Building something to spec is a finite task with an estimable amount of work and calculable delivery date. Having real world conditions conflict with what was spec'ed introduces delays. Having conflicts across your product from metals and plastics up to software interfaces means these delays propagate.

You make the tough calls. You ship.

[1] http://blog.lockitron.com/post/84539548097/debugging-jams-wi... [2] http://community.lockitron.com/t/sense-will-it-sense-if-my-p... [3] https://developer.nest.com/ [4] http://blog.dropcam.com/tag/dropcam-alerts/ [5] http://serverfault.com/questions/316637/100-uptime-for-a-web... [6] https://lacklustre.net/bluetooth/ [7] http://en.wikipedia.org/wiki/Lee_Felsenstein [8] http://www.wired.com/2011/05/lockitron-unlock-your-home-with...

Paul,

thanks for jumping in.

1) I wasn't misled by PS-POLL. I used 2mA as a conservative estimate. I know you can get a lot worse. That's why I think instant WiFi unlocking isn't/wasn't realistic.

A lot of your users expected and expect instant WiFi unlocking. You even advertise using NFC tags for unlocking which would work through the phone and over WiFi! I don't think the limitations of WiFi have been made clear to mainstream, non technical users. Based on what criteria does lockitron enter power saving mode?

You linked to a blog post on May 2nd of 2014. It clearly says that unlocking via WiFi for instantaneous entry isn't practical. You guys should probably make the distinction clear on your main page as well and your video. That's where people buying your products go.

EDIT: Here is a review from one your backers I just came across: https://www.youtube.com/watch?v=jmn6A7HStH4

2) My understanding is that you also do this through who was closest when the thumbturn is turned. I know there are others doing BLE proximity unlocking as well but Kevo for example uses two radios (and they took out a patent on this), and even their customers aren't happy with the results (as you yourself have pointed out on Lockitron community website)

The link you post to says one can set lockitron for different modes (passageway, etc). I'm talking about using it in the front door of my house, or an apartment and not getting confused on who comes in and who goes out.

Also, whether the problem is with Android API, or Apple API, or whatever else, the point is you advertised a feature before having tested that it would work. Good advice is to not do that.

Finally the other companies you linked to are Nest and Dropcam and in both scenarios they don't really care EXACTLY where you are. They care that you are WITHIN RANGE. To unlock my door properly you NEED to know that I am on the CORRECT SIDE OF THE DOOR and that I actually want to unlock it, not that I am standing near the door chatting with a door knocker, sitting on my porch, or working on the flower bed near the porch. Yes I actually have a bed of flowers right by the door and sometimes I work on them.

3) I am talking about two different things here: The mechanical portion that turns the thumbturn and all the logic, API, signals that go into deciding to turn it or not. You guys obviously have problems with both. It would have been wise to solve the problems separately at least at fist before taking a dime from someone, but that's just my personal opinion.

You can later build a manufacturing prototype that combines both.

I disagree with your approach to product development, but that's just based on my personal experience. The goal is to minimize the COST of things when they go wrong so you start with deal breakers first -- battery life, etc. then you move it down to things that you can fix with firmware update. As for things like doing Diffie-Hellman, here is a tip: You can always use rotating PSK to encrypt communication, and initial code can be set using Diffie-Hellman or whatever else you'd like.

Furthermore Bluetooth security hasn't been safe since 2.0.

Also BLE chips don't do much beyond minimum stack. The rest would be in your firmware or whoever wrote the firmware for you. The comment about the chip moving from signed licenses to unsigned ones doesn't make a lot of sense to me but I could be wrong.

4) I was being conservative, but even at 40 hours someone could tell you the FUNDAMENTAL problems with your approach. It is a quick sanity check before you walk down a path.

While I'm sure your current device costs more than $30 to build as you say, I don't believe a properly designed one in high volumes would. I've designed quite a few WiFi based products, and a few electro-mechnical products.

5) I know lockitron goes OVER an existing lock but you have a mechanical component that is driven by motor and turns left or right. This is very, very similar to all other motor driven locks in this aspect. How the movement is transferred to the lock -- via thumbturn or via the main shaft in the case of an actual deadbolt -- is mostly a function of the shape of the piece that mates to the output shaft. It doesn't need different gear configurations to turn the actual deadbolt shaft than to turn the thumbturn.

Also this was in response to Cameron asserting that everything had to be custom designed. I disagree. There are many, many other products that use a motor to turn something. I'm sure a lot of that can be referred to for inspiration or certainly reused in terms of basic gears.

And about gear vendors you say that getting gears ready made from them shifts the cost of tooling elsewhere... where? They give you gears that are ready to use. I've bought gears from a number of vendors and customized them too. They charge you NRE, and give you the gears at the promised time. They cost a few cents a piece. You can evaluate the quality of their gears by looking at the existing gears they make. A TON of products use gears and motors, even cheap plastic toys too. Buying and getting gears is fairly common, like screws and springs; 90% of time you stick with existing catalogue.

6) The spec defines the torque required for the thumbturn. You can certainly add a safety margin as I suggested but it gives you a minimum floor. Clearly this minimum floor wasn't established properly. After all human hands turn these deadbolts with relatively the same force.

Comparing requirements of a standard to features of another standard (BLE 4.0/4.1) is not the proper comparison. Your analogy would be valid if Android BLE operated on 2.6GHz while BLE spec says 2.4.

Thanks for you detailed response. Our goal is to continue to improve our product. Indeed this is why we talk about our problems (and solutions) such as in the above post. We have discussed much of what you have brought up here over the past few years. If our implementations on these matters are different than your opinions I think it must be due to the closeness that comes with building and iterating on the concept rather than commenting on one generation of it.

I am not quite sure how to respond to your other claims in this thread that suggest we are acting irrationally other than to say we have an "EE that had experience in product development", we did consult with multiple other companies to check our "sanity", the "pitfalls" we encountered are common to many other products which don't disclose development details - we are no worse for having addressed and solved them, and that we don't engage in used-car salesman tactics.

Regarding your questions above:

Lockitron enters power save mode when not in use for a few seconds.

Using a pre-fabbed gears or gearboxes from other vendors on one level can introduce complications with motor selection, housing, industrial design, and yield between batches; on another level it provides a gap for manufacturers to shift accountability. Simpler is to use standard gears from a gear manufacturer which also makes your gearbox which is what we do.

Paul, thanks for responding.

I didn't accuse you of used-car salesman tactics. I was pointing out that nowhere on your main product page is WiFi sleep mode, or knock-to-wake are mentioned. I think it is a fair point and has significant impact on the user experience, and it is fair to expect a company to mention that when selling you a product.

With respect to steps you have taken to complete the product, frankly that is between you and your customers. It is unfortunate that you've encountered delays and I'm sure of all the parties involved you are most motivated to ship a product that gets good reviews and has few returns.

Your company decided to outline the troubles you've encountered so far. That is commendable. In this, Cameron outlined a number of problems and lessons, some of which my experience tells me are not necessarily true and is the wrong conclusion. For example I don't think it is true that going to China means you have to make everything "bespoke" from switches, to motors, to screws and I also don't think designing a motor and gearbox that turns a deadbolt -- of any torque -- requires ~40 moving parts.

I'm sure you've had your reasons for developing the product the way you did and I'm sure you've had good people review your work and help you along the way but the inescapable fact is that almost 2 years later the product isn't out, and from what one gathers through google searches and your own product support forum the few users who have received it have troubles with it.

It is one thing to say our path didn't yield what we expected and here is what we did, than to say building hardware is hard and none of it was really because we lacked the experience and made a number of mistakes, should have had better prototypes, etc.

If you read your customers feedbacks elsewhere, and in this thread, one of their chief complaints I see is that you say the most recent problem is the last remaining problem and that it'll be fixed and units will ship out soon. I truly believe you really think everything is solved and would ship within a month and are being honest when you send the update, but fixing one bug only uncovers another and in my experience this is a problem of product development process and methodology more than anything else. There are analogues of this in Software world which many HN readers I'm sure are familiar with.

I am certain product development doesn't have to be this way and I make that statement relying on hundred of new products of greater complexity being introduced around the world every month and on my own experience.

It is not the normal, yet Cameron's article makes it sound that it is and the fix is better vendors and more time.

The past has passed and whatever pitfalls I've outlined in my original post aren't really useful to your situation because you're at a different stage. There are many aspiring and budding entrepreneurs who read HN and read Cameron's article. My goal by putting in my $0.02 is to balance out some of Cameron's assertions and lessons learned that I don't believe to be necessarily correct so that they may avoid delays and customer dissatisfaction in their own development.

First off, I see you're a new account, so thank you for starting your HN life with such detailed comments.

Second, you seem to have some experience with manufacturing and electric locks. How much of an expert would you say you are in Lockitron's domain -- would they have had to pay you tens of thousands of dollars in consulting, or are the issues you raise something that would have been brought up over a beer with a recent EE/ME grad or even a general home contractor?

Thanks! I figured I should stop being a lurker at some point.

I'd say almost any EE that had experience in product development would have been able to call out these issues. Battery/power issues are fundamentals. When I first saw their video I knew the WiFi issue would be problematic, as well as their claim about "Sense" BLE unlocking, and I hadn't made a door lock.

Someone experienced in supply chain and product manufacturing should have also been able to warn them about some of the other issues.

I agree with you, but just to add some information for the parent (from the perspective of a relatively recent EE grad with even more recent experience in product development):

a) Experience in product development is almost entirely unrelated to experience gained in school (hackers will say it shouldn't be that way but it's just a reality of the amount of information involved).

b) Experience in supply chain and product manufacturing is also unrelated to all of that, and often by some distance. ie. It's more of a business-person problem (er, for lack of a better term--it obviously requires technical knowledge as well).

In other words, you're extremely unlikely to find that combination of knowledge in a junior EE, and depending on their career trajectory it is entirely possible for an EE to spend their entire career without amassing that particular assortment of product development knowledge on top of their EE knowledge. So while it's true that any EE should have questions about (for example) battery/power issues right away, it's not true that any EE would immediately flag those issues as problems (ie. over a beer, I'd probably trust the guy telling me he thought he could do it, even as I told him I wasn't convinced).

Note that I'm not suggesting any of that knowledge is rare or hard to find, just that you might not find it all in the same person easily, especially not a junior EE.

Good points!

You definitely need someone that has product development experience.

> Pay an experienced EE or consulting company 20, 30, 40 for hours worth of work to review your design, plan, and feasibility

Would be interesting if projects disclosed that consulting company A has signed off on their design, such that backers can review the delivery track record of other projects vetted by consulting company A.

How should hardware projects source such a company? Is there a directory?

> How should hardware projects source such a company? Is there a directory?

That is a very good question. I am in interested in that too.

http://www.californiaconsultants.org/Home.cfm is a good place to find reputable EE consultants in the area.

The "pitfalls" Lockitron encountered were so obvious, from the get go than a decent EE reviewing things would have been able to warn them. The similar thing holds true for ME.*

* ME = Mechanical Engineer.

Thank you! This is very informative.

If they were also looking for manufacturing services, all the big EMS companies do product design (EE, mechanical, PCB layout, software, + Potpourri for $1000, Alex), too. One of the biggest value adds in EMS is DFM work, where a customer brings in the "next big thing" that turns out is impossible to reliably or inexpensively build (Bloom boxes are an item I have some personal history with, for example). This is also why there is a pretty big EMS presence in San Jose / Fremont / Sunnyvale / Milpitas, and why Flextronics decided to open their hardware incubator (Lab IX) there, too. Besides all this, even the biggest usually only have a minimum investment of a few thousand dollars.

I've spent the past 14 years in the EMS world and am happy to help/advise anyone who has a hardware or manufacturing problem.

> I've spent the past 14 years in the EMS world and am happy to help/advise anyone who has a hardware or manufacturing problem.

You should include an email or url in your HN profile :)

My email is there (at least, I can see it).

I used to work at one: http://www.mindtribe.com

Noted.

There are product dev companies everywhere but I doubt any would go on record to vet anything. A good lawyer could hold them legally responsible. There are so many, many caveats that they wouldn't want to be legally held accountable for anything, and rightly so.

It is incumbent on Lockitron to seek their advice and review for their own sanity and meeting their legal obligations to their backers.

There's a very good one that does this. http://www.dragoninnovation.com/services/certification

Wifi has always been a tricky problem for small devices. However, I think there are some good tricks that people have been using involving playing around with sleep times, skipping beacon intervals, etc. - tricks that the electric imp, the Wifi board used in Lockitron, utilizes to lower the current consumption by a bit.

You're totally correct that always-on-instant-unlock feature is a fool's errand as that would mandate always-on Wifi, spelling death for battery life.

I think one feasible method is sleeping the Wifi and using an external input (like a button or a "knock" sensor) that wakes up the Wifi, tells the chip to check the server for updated lock state, and then go back to sleep. I've played around with capacitive sensing on a door handle to wake up the Wifi and check the server as soon as someone lays hands on the door. Cap sensing is also incredibly low power so it had minimal impact on battery life.

This of course introduces all kinds of problems, but if Wifi is absolutely necessary, then this is one solution.

Either that, or wake up to poll Wifi every 5, 10, 15 minutes (destroying instant lock/unlock)

Good points.

The skipping of beacon intervals is called PS-POLL and is why I said 2mA otherwise it is closer to 100mA -- which for example is what TI's CC3000 module burns since it doesn't have PS-POLL.

I agree that there are alternative ways to wake up WiFi. They said at one point in HN that they were thinking of having WiFi wake up when you knock. The problem with this is that the experience is markedly different from what they're advertising to users.

You'd pull out your phone, bring up the app, hit unlock, then knock on the door, wait for WiFi to turn on, associate with access point, get to cloud, "see" the unlock command and then unlock the door. That's easily 7-10 seconds at best.

Screw that. I'll just take out my key.

Giving WiFi long life by keeping it off is relatively easy. Making it instantly responsive, which is what anyone using the lock would expect, is impossible at the quoted battery life.

It is kind of like selling a car saying it'll get 500mpg but not telling the buyers that you only get that if you go say 10mph.

It would be pretty easy to have a phone app that notices you're arriving home and sets the lock to open. All that's left for you to do is walk up to your door and knock.

As well, their software learns your habits over time and can be awake when it expects you to arrive.

These tricks and others will improve over time. Enough to where it's more than an acceptable experience for many, if not for you.

They actually are doing the knock to wake. BLE works and is an instant lock/unlock. Sending a command via wifi will let you know (on the phone) that the lockitron is in a power save mode and the command will be executed in 20 minutes (or whatever the actual time) or when you knock on the door. So if you leave the house and forgot to lock the door, you could lock it remotely and know it'll lock itself eventually. Knocking does work consistently to wake the device up.

It's definitely not the same experience though. I live in a condo and have the lockitron on my unit's door. I have the choice between opening the lockitron app in the elevator and send the unlock signal via wifi, but that means I'll need to knock for sure. Or I could wait until the elevator gets there and try to unlock, and if i'm really lucky it will be via BLE and unlock instantly, but generally the BLE hasn't managed to connect yet and I get no indicator, so I send the command to early and I need to knock anyway.

Speed is such a critical factor here. It doesn't take that long to pull your keys out, and it feels more awkward to stand and wait at your own front door than it does to fumble with the keys for a while. If I'm carrying groceries or a baby, then Lockitron has the potential to make things easier, but currently I still need to fiddle with my phone for a while (maybe in the elevator, but still) and knock so it doesn't really feel easier than using a key.

What would your insurance company say if you said "well I knew I forgot to lock the door, but I sent the command and I know it locks itself eventually"? It's cool but not really a mass market product.

The reaction would probably be better than "I didn't know I forgot to lock the door" or "I knew I forgot to lock the door, but was too lazy to go home and so I hoped for the best."

Plus, locks are trivially pickable, so it's not like they stop someone that wants to break into your house from breaking into your house.

Locks are not trivially pickable. It only looks that way if you watch a skilled person do it. It's much harder than many impressive juggling tricks, for example. Smashing in a window, now that's trivial.

Neither matters though, because a big purpose of locks is to show that you took reasonable precautions in order for your insurance to be valid. (YMMV, IANAL, etc. but that's the case here.)

I'm about as unskilled a lockpicker as you can get, and I can pick the four-pin locks on my apartment fairly easily. Someone with practice could do it even more easily.

(I've never used a pick gun, but I hear that makes it even easier. Especially for locks that don't have any particular anti-picking features, like the majority of locks on people's homes.)

In the U.S., there usually isn't any language in a homeowners policy about doors being locked, so if you have a police report, they don't say anything.

Ah, I didn't know that. That's one less issue for them to worry about.

As per #1, is WiFi really that bad? Because Geofencing is used quite extensively in the iOS ecosystem and doesn't seem to affect my battery that much at all... although I'm likely just missing what the feature was advertised as, possibly its something different.

The challenge with door locks is that I'd like to change the battery every couple years, particularly on infrequently used doors. Most people can understand having to change batteries every couple months on a door they use frequently, but let's say you have a storage locker - it kind of sucks that every time you go to the locker, the battery is dead.

I wouldn't mind it if I had to mechanically charge the other side of the lock from the outside. Attach something to the door knob so I can "jiggle" it from the outside to wake up the unit and have it do its thing.

Bluetooth LE is ideal for this sort of application. WiFi was really the wrong direction to go for a door lock.

You recharge your phone's battery. :)

Best WiFi today will consume about ~2mA when in standby. They are using ElectricImp which is a little worse.

People often look at "sleep" current of a WiFi module and think "oh boy I can run this for 2 years at like 100 micro amps". That is true if the WiFi module is turned off; useful if you are waking up, taking a reading, pushing data to the cloud, and then going back to sleep. But for a door you need to be listening on the network for an incoming packet all the time. How else would you know that the user wants you to open the door right now?

Alkaline AA batteries AT BEST have ~2600mAh of capacity. They run at 1.5V. You have 2600 x 1.5v = 3900 mWh of energy in each.

A Wifi module consuming ~3mA and 3.3V runs through that power at around 3900 / (3.3 * 3) = ~394 hours or about 16 days. 4 AA batteries and you'll get about 64 days or little over 2 months of usage.

Of course you'll get FAR LESS because:

A) You have to convert battery voltage to 3.3V and you'll get about 85% efficiency for a high current (300mA peak) needed for a WiFi device

B) You burn more energy when you actually send packets

C) You need quite a bit of power from those 4 AAs to actually turn the lock so you can't do the math assuming all your power is available for WiFi.

Yeah, I was looking at it from the wrong angle, I didn't realise that the lock itself was running on battery! That makes a lot more sense then :)

>> Best WiFi today will consume about ~2mA when in standby.

So, what's the 2mA module?

A number of Qalcomm Atheros chips like AR4100P. Gainspan's GS1011 and their newer GS2000. Pretty much anyone supporting PS-POLL should get around that range.

Electric Imp gets close to that but they are over it a bit I believe.

Thanks! What's your opinion on which ARM Cortex uC uses the least amount of power?

Difference is you're charging your iPhone every day. WiFi is power hungry, but the iPhone 5 has ~1,500 mAh of power, and WiFi takes a continuous ~50 mAh. That gives you around 30 hours of constant wifi usage on an iPhone. Now that's not counting everything else happening on the iPhone, which is quite a lot, but this is back of the envelope math and I'm hoping I can reveal the order of magnitude involved.

On the Lockitron, it depends how long it takes to wake up and ping while maintaining a low latency. In this case it's probably something along the lines of: wake up for 25ms every 1s and check if somebody's unlocking. This saves you 95% of power usage (950ms/1s aren't spent powering wifi) with a max of 1s latency. But I'm not sure if 25ms is enough to ask for new messages over wifi. This still gives you 2.5 mA averaged, which will drain that iPhone battery in 600 hours, which is only 25 days.

And I bet this sports a smaller battery than 1,500 mAh.

Your phone has a couple thousand milliAmp-Hours and expects to be recharged every 12-48 hours.

A door lock might be able to store twice that... but it needs to last a year according to spec. The power budgets aren't comparable.

I'm currently working on a very similar product within a greater product offering. Any chance you're available for freelance work, bravo22?

Unfortunately not but there are many product development companies out there that can help you.

Anybody you can recommend? We're in the midst of talks to use the Kwikset part, bu Inhave reliability and cost concerns.