Hardware Case Study: Why Lockitron Has Taken So Long To Ship
techcrunch.com
techcrunch.com
After owning it for nearly a year and having it only work reliably probably 20% of the time I had one galvanizing experience with it that made me arrive at the realization that it is fundamentally flawed.
It is a motorized lock connected to WiFi with a back up of a standard key lock. As it turns out, if the Lockitron runs out of battery mid way through actuating the lock it will freeze the lock in that position. No amount of manual force though just the key backup will work.
I spent several hours locked out of my apartment one night requiring emergency service from my complex management and asking a guy to wake up my neighbor so they could climb a ladder and break into my apartment via my balcony.
Cameron and the Lockitron staff I interacted with was very good and understanding at all times- but I just could not trust the Lockitron any more. Since it was a battery hog and the battery dying midst turn is a critical problem and there was no notification whatsoever of the battery condition (at the time) AND I couldn't use the manual back up, I had to return it.
You also usually can't tell exactly if the battery is too low for it to turn
If you're into RC is looks a lot like a "servo-saver".
After the first year it became clear the Lockitron was just an idea. I have no idea why the YC team made a testimonial for it as if it were a finished product.
The second year the e-mail updates were constantly "X is wrong and we are fixing it. We want to make the best product possible." Blah blah. Yeah, whatever.
What it comes down to is that Lockitrons entire campaign was misleading, from their website, to the YouTube videos, to the Kickstarter -- the entire company is smoke and mirrors. The company is really good at explaining why things are wrong, but is terrible at actually fixing them. My frustration stems from them constantly promising things, but missing their deadlines by months, and in this case, years. Not once, but several times.
I cancelled my order a while ago, the Lockitron brand is destroyed in my mind, and I have been hesitant to back any hardware projects ever since.
I really wanted to believe.
The YC team, while growing, is still a fairly small collective of amazingly brilliant people. The HN team is, at the end of the day, largely anonymous people on the internet. (Albeit the most amazingly brilliant collective of largely anonymous people on the internet I've ever come across.)
http://techcrunch.com/2011/05/13/lockitron-lets-you-unlock-y...
It would be nice if pg had said something closer to "I hope this new product works as well as the version we are using", but it's difficult to go back and try to figure out the context he would have been commenting in.
The preorder page from that time does paint the picture of a well developed product, making declarations about all the things Lockitron does:
https://web.archive.org/web/20121004125521/https://lockitron...
But it's not that hard to understand; it's the difference between a hacked-together MVC or early release that might fall over with 10k users versus a mature platform that can handle 10mm concurrent users with no problems.
Not bringing competent manufacturing capabilities in-house is the same as supposing that you can run a tech startup strictly using short-term contractors or people from oDesk. With no real stake in the final outcome, only in meeting their contracted deliverables, they don't care if the whole thing succeeds or fails. As long as they get paid for their little part the bigger picture is irrelevant.
Having misaligned incentives is a fairly straightforward way to have problems.
If you have experience developing a hardware product, I'll defer to your experience, but what I've seen from being on the periphery of a couple hardware projects doesn't jive with what you're saying are the lessons learned from trying to ship a polished hardware product with a small team on a limited budget.
I sort-of agree with you there and sort-of don't.
IF (and this is a HUGE if) you already know EXACTLY what your product is going to be THEN you MIGHT be able to save a bunch of money using Chinese suppliers and factories.
But when you're doing a hardware Kickstarted kind of product you don't necessarily know exactly what the product is and how it will work. You might well be inexperienced too.
Manufacturing in-house gives you the ability to rapidly iterate and close the feedback loop (which any good software engineer will tell you is critical) so that you can go from sorta-working to working to working perfectly.
3d printed parts are not the same as injection molded parts for myriad reasons. The screws for assembly you buy off of mcmaster carr will almost assuredly be different than the ones your Chinese supplier gives you, especially if you don't know to ask what the material is, what the tolerances are, etc. A screw is a screw right? Not even close.
Software guys often have a lot of trouble understanding hardware because software is so pure. A bit is a bit and it always will be. An object has a type which often fully defines it. Bits can largely be counted on not to flip. If it passes the tests in dev and test it should work in production, and if it doesn't we can revert it.
When you do all this stuff in China your feedback loop might be 3-6 months long. That means that you might spend two years (4 to 8 iterations) getting from an idea to a worthwhile product. Doing manufacturing in-house can bring your feedback loop from months to hours, days or weeks. For the same 4-8 iterations you might only spend a few months. That's the difference between "very nearly success" and "quite late, eventual delivery way behind schedule and expectations"
Not true for mechanical things.
Injection molding machines are now all electrical and sit in the quarter million dollar range. CNC machines similarly. A million dollars gets you a very nice mechanical production line and machine shop that lets you fabricate precision metal parts AND high volume plastic parts.
Now, your only expenses are salary and production inputs.
I deal with this every day. How many tooling charges at $5,000 to $10,000 per charge do you have to take before that machine shop makes sense? Not many. I've eaten that charge 22 times in the last 3 years. I'm starting to accumulate the machine shop...
I will put together a decent production line for much less than a million, probably much less than $100k in capital equipment. At that point the rent and air conditioning start to become substantial (Texas, so it's HOT).
Every time I read someone saying "software is eating the world!" and all the smart people rushing into software I always have a little chuckle. I really love it. It means that anything that's not software has a dearth of smart folk and that puts me at a huge competitive advantage.
Otherwise, yes, lots of used stuff is available.
I'm also partial to having a couple of machines instead of just one because of the reliability. If I spend $250k upfront (which I don't have) I get one machine that's going to be extremely reliable but if it does break I'm losing you know $500 an hour or whatever it is.
If I spend $20k on one machine and $30k on another and $50k on a third I end up with no single point of failure. Yeah they will break more but I'll (probably) never be stuck with no ability to make parts. It's easier capex too since revenue from the first finances the second and revenue from those two finance the third.
What kind of stuff do you do? I don't interact with many people on here who have mechanical aptitude. Obviously products of some kind. Can you talk about it? I'm intrigued.
And my problem is always the mechanical side--and has been since 2000.
In a former life, I'm an electrical engineer. However, I've had to deal with thermal and packaging back at a big company I worked for. I eventually got so tired of all the NRE problems that I went to the community college and took their CNC milling and CAD classes to see where the problems were (don't get me started on that--the classes were excellent but the whole idea of an error prone person rather than a computer converting my 3D Solidworks to a 2D MasterCAM CAD surface appalled me). I also had clamp problems--the manufacturer suddenly couldn't hold the clamp in round (we're talking visibly egg-shaped--almost 160mils on an 8inch diameter clamp). Being originally from Western Pennsylvania, this drove me CRAZY. This is the kind of stuff that men used to do in their garage for crying out loud. Local machinists could hand this kind of stuff back to you the same day back in the 70's.
The thing that drove it all home was touring Sullins Connector Corp (whom I recommend HIGHLY). They had their own machine shop and injection molding machines. Their average run on the machines is about 150! They are constantly swapping molds. That was good, but wasn't the big thing.
I needed a custom connector. Described roughly what I wanted and gave them some drawings. Figured we'd talk about it some more and get a quote. About a week and a half later--I get 5 connectors in the mail made out of high temp plastic with gold contacts. They had looked in their future runs, found one with the correct opening and pin spacing, injected a couple of extra, milled the dimensions down by hand, populated the pins and bent them by hand so it was right angle, and sent them to me FOR FREE. And then quoted me for both the hand work (only a little more than a Molex connector that wasn't really right) on the smaller volume, as well as a changeover point when they would cut me a mold.
That's when I realized that US companies can compete. Most of them just suck. It's also when I realized that product companies need machine shops even if they are idle 99% of the time. The 1% is what gets you the business. This is a hard sell to the executives and beancounters. Fortunately, the CEO I'm currently working with has been brainwashed. He personally had to add holes to a bunch of plastic cases--and discovered that his milling machine saved him $5,000.
Although, to be fair, I have this same problem at the electrical engineering side on a different level--VLSI design. There are lots of design I can do on a chip, but I can't afford the NRE to build one.
People (especially on kickstarter) think that if they have a pretty 3D drawing of the thing the hardware is going to be a breeze. Oh and they're going to use Arduino for it
Funny. Not.
I think Arduino made people think "everybody can work with hardware now wohoo!!" Oh but they don't know Ohm's law.
"We quickly learned that there was no concept of “off the shelf” when manufacturing in China."
Well, of course there is. Unless the existing parts don't fit your project. Then you'll need a lot of parts specd for your need. Tip: don't do that.
You'll already have to do the case, circuit board and maybe power source, this is enough trouble. Add in mechanics and you're in for a tough ride.
I've seen hardware bugs in reference implementations from people that should've known better. Manufacturing reliability is always lower than you think it is.
Another common approach to further mitigate manufacturing reliability issues is to contract a single vendor to make and assemble the mechanical unit. Basically everything from input shaft to output shaft goes into a box. You put the motor in and build a contraption to measure the output torque, etc.
You only pay them for units that actually pass the test. The failed units are their problem. Look at the price they'll quote you for this and you'll know how reliable they really think their process is.
Well, shit, that means they are like 95% done right?
The silly thing is an Arduino bypasses possibly the easiest part of a microcontroller project. While they do have some convenience, if you need an Arduino you have no business tackling a sophisticated electrical project...
They have been singing the same song for 2+ years.
Personally I could care less about their delays. My beef with the company is that EVERY update they lead on customers, saying "We're almost there!". No, you're not.
I cancelled my order after the 4th delay.
How hard is it to write some code that checks for shipping estimates that are about to become false, updates them, and notifies the people in question?
I think bravo22 already covered some of the choices they made up front that got them in to trouble. It appears they didn't have the knowledge or experience to put a good plan together when they suddenly had to scale from 1000 or so units to multiple thousands. Here are a few (more) reasons:
1. Unaware of the environment. bravo22 already touched on the existing deadbolt standard and current products on the shelf. Whether they knew about these or not, it sounds like they chose to go in to production with their prototype (buggy) design instead of sourcing or modifying an existing solution.
2. Lack of specific knowledge. They expressed difficulty meshing the electronic and mechanical parts of their system. There are plenty of engineers that have electro-mechanical design experience that they could have leaned on, either hired on to do the redesign or to guide them in the right direction for things like gear-train torque calcs, material selection and fabrication methods (think redesigning a part for injection molding), power consumption calcs, part count reduction... Much of this may only be a Google search away, but if they don't have enough knowledge to know how to apply it correctly then that leaves them at the mercy of either fate or their suppliers.
3. Documentation. "While there is some truth to this, making hardware at scale is still incredibly difficult — if not for the actual physical manufacturing itself but for the compounding complexity of suppliers, tooling and testing." You need good documentation. Part drawings with realistic tolerances that produce parts that make functional assemblies. Work instructions that spell out things like order of operations, screw torque specifications, inline QC checks, etc. The documentation is often your contract with the supplier and if it's poor or not well thought out then the product quality suffers.
These guys are going through an awesome trial by fire. They have a well funded, very public, product that they are trying to turn out and they should be commended for sticking with it for that last two years, and for being willing to talk about their challenges. Just like any other start-up, succeed or fail, they're going to be a better position when they do it again.
1- WiFi drains battery fast, therefore advertising instant WiFi unlocking was foolish, if not purposefully misleading from the beginning. (Look through their posts on HN when Lockitron was first announced and you'll see that they admit that instant WiFi unlocking isn't feasible yet that's not the impression they gave the backers)
2- Determining intent (i.e. I want to unlock the door) through proximity is a fool's errand. You'll have an impossible time trying to get user's position right without multiple receivers and have to resort to wonky logic they use today which won't work for a vast number of people: if user A unlocks the door then ignore his phone until he exist... hmm what if user A enters with user B, or user A leaves though the car in the garage but wants come back through the door?
3- BUILD A PROPER PROTOTYPE. It means critical functionality being there, like unlocking via BLE and unlocking via WiFi. Does it work reliably? No? Fix it. Don't promise anything! Don't put up a video until you have a proper prototype.
Heck, you don't even need mechanicals. Light up an LED to indicate unlocking for all anyone cares. If it doesn't work here in your lab, it won't work out there. There is no magic fairy dust that reduces power consumption or makes something work at scale when it doesn't work in your lab.
4- Knowing how to use an Arduino doesn't make you a product developer, just as knowing Javascript doesn't mean you can deploy a backend that supports 1M users and you only get to deploy it once. Pay an experienced EE or consulting company for 20, 30, 40 hours of work to review your design, plan, and feasibility.
Done right Lockitron is about ~$25-$30 in parts + PCBA cost -- not considering mold amortization.
5- Cameron enumerates a number of mechanical and electrical problems. The fact is you can get a number of low cost electrical locks from China today that have reliable turning mechanisms. It has been done. Those factories will gladly OEM an entire lock for you -- or in this case just sell you the parts or the whole assembled mechanism. Tear apart a Kwikset keypad lock and see how few gears it has. Their main problem seems to be that they started with the wrong/inefficient mechanical design and tried to make everything fit that.
There are lots of existing, inexpensive, gearboxes you can buy that would give you the torque you need. At worst you'd have to get a custom designed output gear. Even then there are many Chinese vendors who make gears. I've bought from them before. They have a large catalogue, and if you want something they don't have NRE is about $1200 + 4 week delivery.
6- "The resulting power and torque requirements of our gear box required a number of changes on our circuit board that would have been nearly impossible to predict from our prototype units". This could have been avoided by buying the ANSI/BHMA deadbolt standard which specifies maximum torque required for the thumbturn. Add 25% safety margin and you should be good with virtually all locks sold in north america as they are ANSI/BHMA compliant.
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.
So, what's the 2mA module?
Electric Imp gets close to that but they are over it a bit I believe.
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.
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.
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?
That is a very good question. I am in interested in that too.
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.
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 :)
It is incumbent on Lockitron to seek their advice and review for their own sanity and meeting their legal obligations to their backers.
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)
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.
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.
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.
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.
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'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.)
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?
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.
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.
You definitely need someone that has product development experience.
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...
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.
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.
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.
This was a great article. One of the things that is sorely under estimated by folks is that that "pipeline" from parts to product requires several dozen specially trained people to function well. As a small organization you have to train each group from start to finish to get to the point where the end product can ship. When I worked for Tut systems the manufacturing process was amazing, and where a software process is designed with testing to insure modules work, a hardware process is filled with processes that quickly identify problems before they get assembled into the product.
Very rewarding though, and very doable, you just have to budget the time to do it and go in knowing you are training up a pipeline. There is no "magic" manufacturer that can take your idea and make it.
The submitter added it to get around the dupe detector. The article was previously posted (https://news.ycombinator.com/item?id=8028073). Since the previous post had no discussion, and wasn't killed by flags or by a moderator, the repost is ok.
referer isn't sent in a lot of cases, including when a link on an HTTPS page goes to an HTTP page.
Those are your parts; the designs are owned by you. You are always free to ask around for other manfs to make them.
> Even what seemed to be commodity components like switches, screws and motors would be made to spec.
This makes the product sound terrible. I really doubt they need to make screws or switches.
I thought the same thing. It reminded me of the genie garage door openers at my rental property. The end limit switches are were obviously designed in house and are basically two strips of some copper alloy spring material that come into contact as the door passes.
The problem is that a garage is a dirty/corrosive environment. On a yearly basis I have to sand the contacts. All this to save a few pennies vs just buying a standard micro switch!
I can't determine if its was incompetence, cost cutting, or just planned obsolescence.
Of course, I just posted a few things on another board about how I think the lack of software licensing leads to the lack of "software standards" where everyone and their brother is basically doing the equivalent of building their own screws, with their own thread pitches and head patterns or using whatever happens to be "cool" this month.
I don't remember seeing them in Germany
But there are models that are made to go on an apartment door/main door.
However, they don't usually replace the whole lock, but are there for authorized people to go during business hours
Yeah, not really a replacement for Lockitron
They have been adopted widely. In businesses. It's mostly a perception issue, where such locks are perceived as a product for a business.
That said, it's a lot more convenient to walk up to a door and have it unlock automatically because it detects your phone ... than to stand there and enter a code.
As for the convenience factor, it might be more convenient, but I don't think it's a lot more convenient to have Lockitron instead of a conventional keypad lock. Unless Lockitron can also automatically open/close the door for you, I just don't see the difference as being that great.
In any case, I think the real business opportunity lies in figuring out how to market keypad locks to a broader audience.
It may be a local issue, though, I'm not in the US, and shipping is usually not cheap.
I feel like I'm not understanding this passage.
Is he saying iterating in batches of 1,000 is impossible because it would add $3-5 cost to a product that they sell for $179?
Though in that case it's very much because their software platform utterly sucks - given how the Lockitron works I'm amazed they have anything at all.
No local LAN support - everything tries to go over the internet, and their servers are unreliable. Lag time of something like 30 minutes is not uncommon.
Doesn't integrate with a lot of existing doorbell/intercom systems (ostensibly it'll work with AC ones, it didn't work with mine which is admittedly some type of DC - but simple enough, short to ring and all that).
It is all round a terrible product which was launched in an unusable state, with really poor design decisions.
How's the battery life on door bot?
No real idea about battery life - its been sitting on a bench somewhere for the past year or so, since we gave up when we realized it was going to be either the Doorbot or the doorbell which actually rang, and found the notifications on phones were unreliable. We also realized that at home, you usually don't have your phone on you or even necessarily nearby - hence the doorbell.
The one nice thing about the Doorbot was they were trying to solve the battery issue by letting you draw power of the doorbell circuit - but since ours isn't AC (or has to low of a "ring" current) we couldn't use that.
There also appears to be no progress being made to resolve these issues. Just look at the reviews for the android app.
(As a consumer myself, my immediate reaction is that a battery operated deadbolt for my door is far, far down the list of gadgets I lust for. It's so far down the list it's not even on the list. The ability for a third party company to operate my door lock is even on the list of things I'd pay to avoid. I just imagine there to be a nest of insurance liabilities there and I wouldn't want to touch something where that wasn't worked out first.)
At best if this product really worked out, you'd have a small company selling thousands (not hundreds of thousands) of units to consumers with all the support liabilities that entails. Not something that usually thrills investors.
Normally you would see such a company start out with high margin stuff where installations are built on a case basis anyway.
To make it more concrete, here's an example:
Step one: Decide that the app is your core product. Start working with an existing electronic doorlock system.
Step two: Sell to offices. Maybe hotels. A flashy app could very well be enough to tip potential sales in your direction. Develop functionality where the app gives you an edge (could be integration with AD, useful revocation, whatever).
Step three: Either get acquired by a giant in the business ("profit") or spread out to alarm systems. Those are ugly and hard to use. Use this leverage to get a foot in the notoriously difficult consumer market and grow from there.
The underlying ideas here are that existing players in this space are notoriously bad at software, and that you should stick to use cases where electric locks or sensors are already in place and play off that.
But perhaps this niche is already taken by Nest and that's why they went for this particular consumer niche? I don't know but it would sure be interesting to read a future post mortem analysis, if things turn out that way.
I'm sure there's an economic or business reason why it's unfolding the way it is, but that doesn't reduce my frustration. So many things feel backward about it. Starting with a cheap, bolt-on almost-solution? That doesn't seem right for a part of your home that you interact with every day. Using consumers as beta testers? That feels wrong for a security device that controls access to your home and everything you own. Developing a home keyless entry system without exploiting the human capital developed on successful keyless entry systems for cars? Definitely the hard way. It seems like the right way for a home keyless entry system to be developed would be for a company with lots of resources and relevant experience to develop a reliable, durable, convenient solution and then work on bringing the cost down from a thousand bucks to something reasonable. Instead, we have little companies trying to scrape by selling not-quite-there products at early adopter prices. (I paid over $200 for the Kevo despite Amazon reviews reporting, among other things, accidental engagement of the deadbolt while the door is swinging shut.)
I don't hold any of this against Lockitron. They're taking the route they are out of necessity, and I'm grateful for it, because without them and other upstarts, the market wouldn't be moving forward at all. At this point I feel conflicted, because I'd hate to see their work rewarded by getting blown out of the water by a bigger, better-funded competitor, but on the other hand, that seems like the fastest way for me to get a product I really like.
(As a final note/aside, determining intent to unlock the door is an unsolvable problem with traditional door hardware. Usability is going to suck until all the lock/latch/knob hardware is redesigned for keyless entry. Everything until then is just intermediate steps until home hardware catches up to the standard set by automobiles.)
Hardware seems so simple. But it really isn't.
"We soon learned" ... "It quickly became apparent" ... if this learning process was quick, how come you discovered none of it until after you took everyone's money?
Would this work?
If the battery life is still a problem then I wouldn't have a problem with having a detachable module for the Nest that can be removed once a week and manually recharged.
Generally, these allegations come about because of the shipping/delivery delays, and there are a whole bunch of factors that contribute to the delays, such as unrealistic expectations on the part of the inventor -- what the startup hopes to deliver in a product (eg. 10 high specification features packed into a keychain sized device) versus what current technologies and materials can actually do (eg. 5 high spec features in a palm-sized device).
Another factor is the sophistication of a product. In general (from conversations with project managers who worked at Asian OEMs/ODMs), the typical time taken to develop and build a product (of similar quality to iProducts) takes at least 12-18 months. Unless your product can be whiteboxed (or a similar product has been done before), this is the typical minimum time-frame required to build consumer electronics. And if your product falls under a new category (eg. key-sized food scanners), then more time will be required to research, develop and find the right technologies/materials to build the product. The product is not impossible to build, but just requires more time to make it happen.
Of course, the inventor can turn to any factory in Shenzhen to manufacture the product (which may agree to a shorter manufacturing time-frame in order to get your business), but what you get eventually is a product that doesn't work well after investing a large sum of money (http://arstechnica.com/gadgets/2014/07/how-one-kickstarter-p...).
The reason why hardware takes a long time to make and bring to market is because, unlike software, after the molding is done, the product needs to undergo many iterations, testing, certifications, blah blah blah... Also, before a product is shipped, at least over 30 key decisions typically need to be made and over 400 tasks need to be completed in sequence at different stages--and missing a task may result in weeks-long delay.
For software developers looking to make hardware and have no previous hardware-making experience, suggest you involve someone familiar with the manufacturing process and pitfalls right from the start (eg. product concept stage). The person could be an in-house or external expert, and by involving the person early, you can ensure that your design/specs/expectations are feasible --> in turn giving a realistic manufacturing time-frame.
If you need to get an estimation of the time needed for your hardware product development, check out this SaaS navigation tool: http://www.forbes.com/sites/jlim/2014/07/08/the-new-hwtrek-g....
It's easy to have opinions when you aren't the one building it.