Nest killed its smart home hub: What do they owe customers?

Revolv promised "lifetime subscriptions" for buyers of its home automation hub. Then Google's Nest Labs bought the company and killed the product. What rights do customers have?
Written by Jason Perlow, Senior Contributing Writer

Like many other people who are home automation nuts, I use quite a few smart devices -- these include Nest's thermostat and smoke alarm, SenseMe-enabled Big Ass Fans, Belkin WeMo and Philips Hue Smart Bulbs and switches, and a Scout internet-connected alarm system.

I even have a Zodiac iAqualink swimming pool controller which allows me to remotely control the pump and heating from a smartphone, should I desire to have my hot tub ready for use at a perfect 104 degrees when I get home.

Some I even have connected to Amazon's Echo, which accepts voice commands using its Alexa service.

While several of these are connected to my home network via Wi-Fi and can still function independently without an internet connection, there are increasingly more and more devices which are cloud-dependent and will literally stop working if those services end.

That's exactly what is going to happen to users of Nest's Revolv device smart hubs and cloud service, who were given six weeks' notice yesterday.

The shuttering of Revolv is occurring a mere 18 months after Nest's (and Google's) parent company, Alphabet, purchased the company, which was founded in 2013. Nest itself was bought by Google for $3.2B in January of 2014.

In my opinion, this is unconscionable. The Revolv devices, which were sold with "lifetime subscriptions," are a mere two years old.

While a $200 device is not a huge tragedy to replace, Nest's Revolv customers also made a significant time investment to learn how to use and integrate this system and pair it with compatible components.

They will now have to look for alternatives, and there is no guarantee all of their components will work with said replacement.

While most of these home automation components are not mission-critical, there is the potential for actual customer harm here.

Imagine, for example, if Nest itself went out of business, and the cloud service to control and integrate the thermostats and smoke detectors stopped working.

In theory, the thermostats should continue to function as standalone. But what if they literally brick if they can't phone home? What if there is some behavior or bug in the firmware that is unaccounted for when it becomes disconnected for a protracted period of time?

As a result of a software bug, this actually happened in January of this year.

If you are an elderly person in New York City or in another northern metropolitan area during the middle of winter in the United States and your HVAC system in your home stops functioning, there's potential for a life-threatening situation here.

This isn't as much a concern with dumb thermostats that have been on the market for ages from long-established companies like Honeywell, which also service the commercial market and now have their own smart devices for both residential and commercial use.

There's a certain level of confidence that a company with feet in both worlds, such as a Honeywell or General Electric, is less likely to disappear and abandon support for its products.

But what's the risk of a company like Nest going under? Well, apparently, such a concern would not be completely unfounded.

This Reddit thread, which was recently deleted but is still in Google's cache, is reportedly an anonymous account by an engineer at Nest that details various systemic management problems the company is experiencing.


Additionally, comments by Nest's own executives at a recent expose by The Information (email registration required) strongly seem to indicate a highly dysfunctional corporate culture in place within the company, which is suffering from substantial employee churn.

Case in point: The founder of Dropcam, Greg Duffy, who sold his company to Nest, now deeply regrets the decision and has knives out for Nest's CEO, Tony Fadell, who has had disparaging things to say about the engineering and management teams that came in from Dropcam as part of the acqui-hire.

The Nest subsidiary is also seen as underperforming within Alphabet, with only $340M in revenue.

Whether Nest is or isn't at risk of going under is difficult to say. But if such a thing were to happen, the damage to the reputation of the IoT movement would be catastrophic, as the company has been seen as the poster child for connected devices since shipping its first product in Q4 of 2011.

While the exact number of Nest devices in the field is not known, it is easily on the order of a million or more units. As of January 2014 at the time of the acquisition by Google, the company was reportedly shipping some 100,000 devices per month.

A million units suddenly turning into Nest-branded bricks would be bad news for the IoT industry indeed. It would put a terrible taste into everyone's mouth.

If Nest's behavior regarding Revolv is unconscionable, what's the right thing to do?

Well, IoT vendors need to think about what I'd like to refer to as "Dead Man's Firmware" or DMF, for short.

In essence, this would be firmware code or software that would switch on in the event of a product being end-of-lifed, such as with the Revolv scenario, or if a company that manufactures IoT devices meets its demise.

This software would essentially turn the device into a cloud-independent, standalone device. So in the case of Nest, it would still work as a regular thermostat. Perhaps not a crowdsourced intelligent thermostat, but it would have some minimum level of functionality that would allow it to keep performing its basic tasks.

This firmware/software would essentially, upon death of the product and/or company, be made available on an escrowed server, that is funded in perpetuity (or for a certain period of time after the company or product dies) or made available on a site run by an independent third party.

This may include apps or other software that would be open sourced and include simple interface documentation so that any third-party, such as an open-source project, could support it if it wished.

There is already a precedent for DMF: the Aether Cone streaming speaker, whose parent company and the cloud service it used, Rdio, both went out of business at the same time.

Aether graciously issued a final firmware update that preserved the Bluetooth and Airplay functionality, but kept the device from phoning home to the cloud, which would have made the device unusable.

While I am not a huge proponent of government intervention, I think in this instance this is where there should be legal constructs in place to compel device makers to not only develop DMF for every single one of their connected products as part of their regular support lifecycle, but also to enact laws that require a minimum level of support for IoT devices as a whole.

The EU already has consumer protection laws for statutory warranties that are broadly applicable to these scenarios.

  • "European consumer and marketing law is based on the notion that the asymmetry of information, where the seller knows more about the product or service than the consumer, is open to abuse."
  • "Sellers of consumer goods within the EU are obliged to guarantee the conformity of the goods with a contract, for a period of two years after the delivery of the goods."
  • "Certain standards exist for assessing when conformity can be assumed and when not. If the goods are not delivered in conformity with the sales contract, consumers can ask for the goods to be repaired, replaced, and reduced in price or for the contract to be rescinded."

As it pertains to IoT devices and potential legislation similar to the EU's that could be enacted in the United States, I would extend that conformity of goods contract for a period of five years, and a ten year claim period at a bare minimum.

17 ways the Internet of Things can go horribly wrong

In the meantime I think the following guidelines, which Wes Miller outlined so well on his blog, should be followed closely as it relates to purchasing IoT devices in the future:

  • Buying devices with open APIs or open firmware. If the APIs or firmware of Nest were opened up, the devices could have had alternative apps built against them by the open-source community.
  • Buying devices with standards-based I/O (Bluetooth 4.0, Wi-Fi) and apps that can work without a Web point of contact.
  • Buying devices from larger companies.
  • Buying "dumb" alternatives. A minimalist programmable or simple non-programmable thermostat again.

Do we need mandatory Dead Man's Firmware and legislation to require minimum levels of support for IoT devices? Talk Back and Let Me Know.

Editorial standards