4 ms·

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 asser

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-wifi-battery-notifications http://blog.lockitron.com/post/84539548097/debugging-jams-wi... [2] http://community.lockitron.com/t/sense-will-it-sense-if-my-phone-is-inside-or-outside-of-the-house/161/3?u=pmg http://community.lockitron.com/t/sense-will-it-sense-if-my-p... [3] https://developer.nest.com/ https://developer.nest.com/ [4] http://blog.dropcam.com/tag/dropcam-alerts/ http://blog.dropcam.com/tag/dropcam-alerts/ [5] http://serverfault.com/questions/316637/100-uptime-for-a-web-application http://serverfault.com/questions/316637/100-uptime-for-a-web... [6] https://lacklustre.net/bluetooth/ https://lacklustre.net/bluetooth/ [7] http://en.wikipedia.org/wiki/Lee_Felsenstein http://en.wikipedia.org/wiki/Lee_Felsenstein [8] http://www.wired.com/2011/05/lockitron-unlock-your-home-with-your-cellphone/ http://www.wired.com/2011/05/lockitron-unlock-your-home-with...

bravo22 12y ago
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 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.

bravo22 12y ago

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 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.