
How three connected hardware companies killed their devices - OberstKrueger
https://medium.com/@gigastacey/memo-to-nest-how-3-connected-hardware-companies-killed-their-devices-7f2368a5710b
======
xirdstl
One problem with the IoT for consumers is that in many cases we're replacing
devices that we're used to lasting many years, but vendors want them to have
the lifetime of a smartphone.

We're still in an early adopter phase on a lot of it though, so it's hard to
judge how it will play out.

Caveat: staunchly an IoT skeptic.

~~~
stormbeta
Agreed. Even beyond the monetary aspect, it'd be an absolute headache to have
to replace this stuff with any frequency.

The biggest reason I'm a skeptic though is the incredibly carefree and
reckless approach I've seen used by many IoT devices.

The Nest is a great example - I was shocked to discover there's no division
between the part that directly controls the furnace/AC/etc and the rest of the
device. That should've been a no-brainer, because first and foremost the
device shouldn't cause harm, and when the "smart" portion inevitably has a
problem (even if temporary), a user shouldn't wake up to a frozen or
overheating home.

This stuff _needs_ a higher level of safety and guarantee, and treating them
like smartphone apps is going to end very poorly.

~~~
Natanael_L
Like I've written before, I want a segmented IoT chip design.

[http://www.metzdowd.com/pipermail/cryptography/2016-March/02...](http://www.metzdowd.com/pipermail/cryptography/2016-March/028666.html)

It should be possible to split up the functionality across a trusted
controller with hard safety limits (only accepting signed updates) from a
powerful CPU providing the IoT logic and control functions, with all the I/O
components wired such that the trusted controller has the ability to
disconnect them.

Ideally they'd also have all traffic routed through a home server acting as a
firewall (and would ONLY work while firewalled after "firmware expiration").

~~~
bigiain
I was involved with a hardware/IoT startup a few years back - we built
Christmas tree lights (so nothing _nearly_ as big a deal if it broke tha your
thermostat or door locks,,,) - but even for that our hardware design had baked
into it the "do not ruin Christmas" design principle - while it required the
Linux half of the controller to allow wifi connection to your phone and all
the other "connected" stuff - there was also a microcontroller directly
driving the lights, which all on it's own (in the absence of the Linux half
coming up) could at least do some minimal blinky light patterns, so that the
nearest thing we had to "critical functionality" could be delivered even
if(/when) the most-complex-by-far piece failed.

(It did, though, add enough to our BOM cost that I have very little doubt that
if we'd got to the "get enough investment to find a production run of 100,000"
part of our plan, the requisite "adult supervision" that investment would have
brought along with it would have fought tooth and nail to reduce our unit
costs by a dollar or two, at the expense of all the reliability/redundancy
we'd engineered in there...)

------
deegles
I'm working on building all of my own IoT (outlets, lights, sensors) using
ESP8266's, Amazon Alexa, and a Raspberry Pi as the "hub". If Alexa gets
deprecated, or I want to use some other voice control, I can (hopefully)
easily swap her out with whatever is cool then.

Of course, this is cheaper in $$ but way more expensive in my own time.
Fortunately I think of it as a hobby and not work.

~~~
digitalinfinity
Can you share more details on your work? I've wanted to build my own connected
outlet for a while and if you have any pointers to resources on this, I'd love
to see them.

~~~
05
This could be as simple as directly connecting ESP8266 GPIO to a solid state
relay and programming ESP8266 to change the state of the pin in response to a
HTTP post, e.g. [1]

Note that you should probably familiarize yourself with basic electrical
safety rules when working with mains voltage, as well as fire safety. An intro
to digital electronics would probably be a logical next step. Lastly, SSRs
have an undesired feature of failing in connected state, so don't connect any
loads that could overheat when plugged continuously.

[1] [https://www.openhomeautomation.net/control-a-lamp-
remotely-u...](https://www.openhomeautomation.net/control-a-lamp-remotely-
using-the-esp8266-wifi-chip/)

~~~
digitalinfinity
Super helpful, thanks!

------
brudgers
My biggest concern with the precedent the Nest decision sets. What happens
when a company disables devices with health and safety implications?

At the edges maybe a company disables a refrigerator -- or worse smoke alarms.
At the core is bricking a medical device such as an insulin pump.

~~~
danso
...On the other hand, what happens when a company stops supporting a product
but allows it to keep functioning afterwards...and at some point, the
maintenance-mode device fails and hurts the user? One of the purported
benefits of connected hardware is that a company can push out updates and
fixes and users don't have to worry about paying attention (as much) to
warnings and recalls when it comes to software.

When a product is initially released, users come to expect that support. If a
company needs to shut down a product line and continued support...sure,
ideally, users will pay attention and slowly migrate to new hardware when they
can, just like people are still getting by with cars that have deadly airbags
because they haven't had the time to leave their car at the shop...but as
devices continue to have a feature set more dependent on the cloud and
instant-push-updates...is there potential harm in letting a life-critical
device function in zombie mode in such a way that it's good enough for months
or even a year after the shutdown, but may be deadly sometimes afterward? The
additional problem that connected devices add to the mix is that consumers
have a hard time distinguishing between what features require the cloud and
which features can work independently.

Obviously, there should never be the situation in which a critical device just
dies as soon as the company shuts down its servers. Life-critical time-
sensitive things, such as a heart pump, should thus be designed to operate
independently, with connectedness being an optional feature.

But for other things, such as a smoke alarm...if a company designed it in such
a way that connectedness is essential to its functionality, and that its
usefulness in zombie mode can't be predicted a year down the road...can't it
be argued that it's more responsible for the company to give the user a hard
cutoff, rather than allowing the user the false comfort of zombie mode?

~~~
farzadb82
As someone in a different thread put it "It's not so much about the cost of
the device as much as it's about the time invested in setting things up".

It's very poor form to sunset a product without offering users (your early
adopters none the less) a easy migration path to another product. Had there
actually been data standards for setup and captured data, I'd expect the
ability to export my setup and data so that I can use it to configure an
alternative product.

~~~
danso
Oh no doubt, I think _these_ instances are poor form, and in this young age of
IoT, companies as big as Nest/Google should bend over a bit backwards for
early adopters when it comes to sunset period and possibly even rebates...if
nothing else than to treat them like loss leaders.

But later on, as always-on-devices are the norm...I do think it'll be more
acceptable -- with the appropriate regulations and consumer protections -- to
kill a device at the end of the cycle instead of designing it to operate as a
zombie, in the same way that users accept that MMOs and other multiplayer-
heavy games are heavily dependent on company servers...though in that case,
it's easier to design a game to allow non-official servers so that the
community can carry on after the official shut-off...but that's where the
analogy of video game == important home device ends, of course.

------
WalterBright
I looked into wiring up the house as a "smarthome" in 1999. That stuff is all
ludicrously obsolete today. Glad I didn't bother.

But I did run cat5 everywhere, and that has paid off nicely.

~~~
Terr_
I've heard that good architecture involves doing just enough to responsibly
_defer_ decisions... But in your case it's technical _and_ physical :p

------
username223
> The key in doing so is communicating your decision to users in a clear
> manner... For example, [J Random Company] explained that customers’ devices
> would still work but would start losing functionality as partners, such as
> Pandora and Spotify, changed their code...

Which is it? "Communicating in a clear manner," or "keeping the servers
running and not breaking people's stuff?" I would guess it's the latter, since
Nest seems to have communicated pretty clearly that it's bricking people's
Revolv devices. The lesson for "Internet of Shit" companies is completely
clear: if you want happy buyers of physical devices, keep the servers running
until the devices physically break. Yes, this will cost you a bit more money.

------
codedokode
I really don't like all these IoT things. Modern software (except for Apple
mobile devices) is full or bugs and vulnerabilities. So yesterday a hacker
could break into your PC and see your files and tomorrow NSA or some bored
teenager will be able to turn off the light and open the doors in your home.

And I don't like the idea of having critical parts of a device or
infrastructure somewhere in a foreign country. Today "smart" phones, TVs or
even cars send encrypted data over Internet to their manuacturers. How do you
check they don't spy on you?

"Cloud" services have much in common with proprietary software: user cannot
have full control over them.

~~~
Silhouette
_Modern software (except for Apple mobile devices) is full or bugs and
vulnerabilities._

A search for "ios brick" suggests that your exception isn't much of an
exception, unfortunately.

------
datashovel
It seems the IoT community should push for manufacturers to provide up front
guarantees that if they discontinue a device / platform they will open source
the entire system for the community of users to continue as they wish.

That way first adopters will feel safe in their purchases no matter what the
outcome.

------
joezydeco
My dead Chumby still sits on my desk. It's been what...3 years now?

I know people have revived part of the network, I'm just too lazy to do all
the work to revive it.

