Brad Fitzpatrick
2 HN recommenders · recommended in 16 months, 2015–2025
5:57 · 1M views · Feb 13, 2015
Brad Fitzpatrick records himself struggling to silence a set of first-generation Nest Protect smoke alarms that keep beeping and triggering one another.
HN cites it as the famous example of how over-clever smart-home devices can fail at something as basic as a smoke alarm.
17 comments from Hacker News
(googler, opinions are my own) I honestly like bradfitz's youtube video the best to show the Nest Protect (the smoke alarm) issues[0]. They have since fixed these issues, as this was the gen one protect. For your #2 (no insider knowledge), that looks like people's accounts getting hacked and then the hackers talking through them. All home camera cloud based cameras have had these cases. I think Nest moving to Google account login system for Nest is probably the best protection against this kind of thing happening. Account takeovers happen, and guarding against them at scale is hard (especially when people reuse passwords). For #1, I think the culture has changed a lot as it's been absorbed into Google's hardware division. Hopefully it's better, but I couldn't say anything of value there. [0] this video (warning, loud video)
In line with this is the classic "It Can't Be Hushed Here" Nest bug video, by Brad Fitzpatrick from last year: this video [Warning: contains extremely annoying Nest smoke detectors beeping. So prepare to lower your volume] Brad looks very annoyed and it was no fun for him, but on an artistic level it is really well done, it is an epic battle between human and machine.
> I'm curious how many people think this is valuable as a stand-alone device? Does it need to have it's own screen and interface? I see a device whose dominant use case would be direct, at-a-glance interaction. It doesn't strike me as sensible that a typical user would generally care about data whose practicality matters only when he/she is physically present in the datalogged space...almost as insensible as texting someone sitting right beside you. Furthermore, omission of direct UI immediately eliminates the unconnected market segment. I would imagine that "mobile app" isn't exactly a driving parameter when people are looking for an air quality monitor, but in today's connected age, it does seem to add modern appeal and a sense of (perhaps misguided?) relevance. > Would it make more sense built into something like a thermostat? This isn't a thermostat, which makes the proposition sound like feature creep. -Placement consideration: Think where thermostats are typically mounted in a home: places that are clear from passing obstruction but not where people generally spend much time in. Places I'd expect to find this device: kitchen counter, living room table, bedside night stand, computer desktop, garage workbench...in other words, where people linger, within arm's reach, and generally not anywhere near a thermostat. -Safety consideration: Designing a 4-20mA temperature control circuit is a straight forward affair. Designing a fault-tolerant, high-reliability, regulation-compl
You definitely don't have to write your own an OS. You use existing tools, for example FreeRTOS. It's surprisingly simple. With a microcontroller, you can have a pretty much complete understanding of the whole machine. All you need is a basic knowledge of C, and most of the people who would solder stuff to a Raspberry Pi already have that or are willing to learn. Say you're making a thermostat. By convention, you leave address 0x0 empty, since dereferencing the NULL pointer is bad form :) At address 0x4 you have a int containing the target temperature. At address 0x8 you have a int containing the current measured temperature. Your whole app uses 8 bytes of memory, plus a few more for the stack. You write a loop. It reads a few GPIOs, updates those two values, does a bit of logic to decide whether to turn on the heat, then writes one more GPIO to turn the heater on or off. GPIOs are "general purpose IO", metal pins that can be individually set to, say, +5V or 0V. The beauty of this is that if you write it cleanly and debug it and test it once, it will work perfectly forever. It will never throw up a popup that says "a new version of Ubuntu is available". It will never ask you to download 80MB of Java. It will never auto update. The server will never go down, because there is no server. It feels totally different from typical software development. You're writing a bit of C, but you're not making an "app" with all the complexity and flakiness that entails. You're creating an emb
I'm very surprised parent-of-parent got so downvoted; I agree the point isn't very rigorous (as parent argues), but parent-of-parent isn't particularly less rigorous or more incendiary than average HN comments. There are plenty of solid reasons to doubt Google given the points that parent-of-parent draws: * Android was purchased and has plenty of product sharp edges. E.g. there are several ways to send texts. There's the issue of fragmentation. The new Google Photos has embarrassing auto-tags for African-Americans. Google has a solid whole product right now, but so did RIM. They will need to push really hard on projects like Tango and Project Fi to compete in future markets. * Nest is garnering a reputation for being untrustworthy due to absurd bugs like: this video * Google is the most published self-driving car manufacturer, but w/out a shipping product they aren't clearly a leader. All early reviews of their car indicate that it's currently too conservative. There's also an issue: do people actually want the whole product? It looks like Tesla and Mercedes will very likely beat Google to market with core self-driving features. I agree with parent-of-parent that Google appears to be trying to position itself more aggressively in many consumer product markets. Google is an excellent technology company, but most of their products have been niche hits. There's plenty of room for their competitors to leverage better customer relationships to own good chunks of the markets that Goog