Hacker News new | past | comments | ask | show | jobs | submit login
Nest Reminds Customers That Ownership Isn't What It Used to Be (eff.org)
735 points by DiabloD3 on Apr 5, 2016 | hide | past | favorite | 309 comments



> In an ideal world, Hub owners would be free to point their devices at a different central server, run by a third-party competitor or a trusted friend, or even run such a server on their own. They would likewise be free to collaborate on improved software that would unlock the potential of the Hub hardware or purchase such software from a competitor to Nest.

This ideal world exists, and it is glorious. I somewhat recently set up a Raspberry Pi 2 with https://home-assistant.io and a cheap z-wave USB stick. The interface is through a webpage (not an app), and I access it remotely using a OpenVPN server on my router.

It's interfacing with door sensors, motion sensors, wall switches, cameras, my stereo, HUE lights, etc. It can email me or send me SMS for notifications. When I wake up and walk past a motion sensor, the lights come on in a dim scene. When I come home and open the door, the lights turn on. I have tons of rules and it's super fun. Totally self-hosted, and the main server is completely open-source (written in Python3).

I haven't set it up with a thermostat but lots of other people have.


Author here. Thanks for the shout out.

As AcidBurnNSA said, Home Assistant is free, fully open-source and fully community driven - no company involved. We have over 240 components and platforms to include a wide range of products and services: https://home-assistant.io/components/

If you're attending OpenIoT Summit in San Diego, I'll be speaking tomorrow about Home Assistant 1:35pm - 2:25pm in Harbor Ballroom F: http://openiotelc2016.sched.org/event/6DBd/automating-your-h...


Man, I work about a block from there and would've registered in a heartbeat had I known about the conference. The talk sounds fantastic. Any idea if they sell day-of tickets? I don't see them anywhere but figured I may as well ask.


I don't know if they sell day tickets.

All videos will be recorded so you should be able to watch it online. I'm planning to give a similar talk soon at a Python SD user group meeting to practice for my PyCon 2016 talk.

You can find my sliders for tomorrow here: https://docs.google.com/presentation/d/1P2WsmwGSSni4gAriY5IA...


That's so cool! Something about the slides not being released yet made me want to read them more. It's Wikileaks of legitimate content =)

Good luck with your work, it looks really useful and interesting. I feel this is what we all dreamed up in the early internet years while watching Star Trek. Digital controls for everything, and not being beholden to others for the way in which we manage the controls.

I'm also interested in electricity monitors but I think that's a separate thing.


from both the slides and the demo UI, you've got a much stronger design sense than the average open source project. Lucky users!


Damnit. I also would love to attend, had I known about it in advance enough to take the coaster in.


Site looks great. Loving that it's Polymer.


Even if this is complex for the average homeowner theres an opportunity to start your own business setting this up for no tech savy homeowners in your locale.


Home Assistant user here, too. After my house got robbed it was either $1000-$2000 for commercial, cloud-locked systems or Home Assistant with $200 worth of X10 devices and IP cameras.

The commercial options couldn't automatically arm when I went to work. Nor could they use Pushover. Nor did they accept pull requests :)


I don't think you can compare anything Raspberry Pi with a polished consumer product. The ideal world does not exist for those who already spent $300 on the hub.


It's funny, but that's true of other categories of "products" as well. Sometimes, you can't really buy things that work well. You have to learn and build yourself, or do without.

Another example: security of computer systems.

The common thing here is the widespread demand in addition to the widespread lack of expertise. This results in the market being filled with "products" and "solutions" which are poor quality, but out-compete things which are good quality. Because most buyers can't tell. So if you don't have the expertise to judge for yourself, you'll end up with junk. Sometimes, there isn't a big enough market of buyers with expertise for there to be any decent options available to buy. You just have to cobble it together yourself with hobbyist/non-vendor produced parts.


In IoT, Raspberry Pi and a "polished consumer products" are two different categories. The latter usually looks pretty and comes in nice packaging, but it has little in terms of usefulness, adds some user-hostile features (like vendor's cloud dependance) and its actual hardware could be replicated by a hobbyist at 1/10 of the price with said Raspberry Pi and a short visit to Aliexpress.

Sadly, companies learn that spending money on sales&marketing has better ROI than spending it on making an actually useful product. And it seems to me that startups are bigger offenders than established companies here.


Yeah, when I first started playing with smart home stuff I looked at commercial hardware and saw that a lot of it requires a subscription on top of steep up front costs. So I broke out my oscilloscope and soldering iron and made my own for a tiny fraction of the cost and have had great fun doing it.

It used to be really hard to do this because wireless communication with hobbyist microcontrollers was either tedious or expensive (the old Arduino wifi shields were like $30-40). The RasPi and ESP8266 have really made things more accessible; you can build a central hub for $50 with a good wifi antenna and then something like a temp/light/humidity sensor is about $10. Or control lights with the $5 Sonoff switch from Itead (basically an ESP+relay on a well designed PCB, that is hobbyist friendly and lets you put your own firmware on it if you like). Or great free controller tools like Home Assistant and data management like InfluxDB and Grafana.

It's a great time to be an electronics hobbyist. The rise of IoT and smart home applications have produced a surge of new and interesting products for hobbyists that didn't exist before, I'm guessing as a side effect of dissatisfaction with the state of commercial products.


Did you document your hobby activities?


...Eventually. I have notes, but a writeup is in my list of things to do.


Great :-) Do you already have a blog/etc you intend to put it on?


I'll probably do it on Github and post it here.


Yeah, the article says the devices weren't fully operational when it was launched, and now never will be.

If that's commercial polish, I'll stick with the Pi!


Unfortunately, this is a huge market gap nobody's currently filling. "I want an open source platform, but I don't want to put together my own wiring" is a surprisingly open field. I saw an advert for ONE such device that claimed to be fully open source, but you can't buy it yet, so that doesn't really mean anything yet.


Once you start doing the numbers it becomes obvious. There is no margin in this. So many crowd funding projects start out like this only to find out months or years later it's impossible to build a sustainable company by selling pre-assembled open source devices. Especially because who care about the 'open' thing will download the image and burn an SD card themselves.


No margin, and you're in for your research. However OSS on IoT could be a huge competitive advantage, if you can persuade consumers not to buy knock-offs.

When Tesla and Nest created a high-end market, they created self-contained objects. They sold because they were good, not because they had a competitive edge on the closed-source software running them. I set Apple apart because they have high margins on accessories, so open APIs would be a drawback here. My point is: We spend that much money for those products because the're good quality in themselves.

The fact that they're closed source means knock-offs can't copy the internal design and will be crap. The only thing required for an open-source IoT company to lead is to persuade us that knock-offs will be crap too (e.g. "uncertified", then spread stories about knock-offs exploding, or shorter length of life, or other leaks of PII, or illegal). The rest of open-source is a huge competitive advantage for relevance in the long term, ecosystem, customer recognition, etc.

Knives are quite open-source but we still buy €200 knives from time to time.


"Knives are quite open-source but we still buy €200 knives from time to time."

The exact metallurgical details (chemical composition, manufacturing process) of high-end knives are closely guarded trade secrets. Making greats knives requires a lot of research, knowledge and experience, it's not something every joe schmoe with 100k can start a business in.

'Open source' is just not a competitive advantage. I have a drawer full of junk whose main selling point was 'it's open source!' to prove it. Starting from an open source project gets you 90% of the functionality; the other 90%, you have to do yourself. In the mean time, the 'community' (read: the 5 guys on your mailing list/forum who shout the loudest) demand that the 'company' 'gives back' (by sponsoring, blog posts on every minute detail, hand-holding everybody with a 5-line patch, ...) because now you're making money off 'other peoples' work'. But the moment you commit any code you wrote, there are a dozen Chinese (and non-Chinese) vendors who will take what you made and put it into their own product; which is usually just one of dozens; they are smart and diversify. In the mean time, you are left fighting the marketing game where you essentially have to convince every single customer to pay a 20, 30, 100% markup for - what really? Being the one who 'wrote it first'? Good luck. The Kickstarter graveyard is full of dreams like this.


Hardware is relatively difficult to knock off well. And with hardware, manufacturing quality is a huge point. Are their cheaper round Wi-Fi thermostats than Nest? Absolutely.

...I have yet to see a single one that even compares on build quality. And it's not like you can't take one apart and see how it's designed.


For those curious, this is the one I found. They're advertising this campaign on Facebook and crud. You can't search it, because it's all images, but they say they're open source.

https://www.indiegogo.com/projects/protonet-zoe-start-your-s...


There is this, which is built using a raspberry pi but is also very turn-key/works right out of the box:

http://www.amazon.com/Intulon-Z-Command-Controller-Z-Stick-Z...



Maybe that's because this demand is much lower than you imagine? Nobody cares about open source.


I think people care about open standards a lot, even if they don't know it. EG: When someone buys a USB device, they expect that they can plug it into any computer and (for non-specialized devices) have it Just Work.

A lot of the home automation world is a closed, proprietary mishmash right now. (Although there are some open standards ranging from old school stuff like X10 to newer Zigbee stuff, I don't think products like Nest use them).

I also think people expect that when they buy a device, some corporate decision isn't going to brick it. (Stories in this line in my opinion will eventually kill the current hype on the "cloud").

"Open source" is probably less important to most end users, but it can be quite important to developers, power users, and tinkerers. And enthusiasts can drive products.


We already have huge widespread popularity for things like the Raspberry Pi and the Arduino. The former is nearly a household name, even if people have no idea what to do with them. And even if you don't know what open source does, is, or means, the benefits of such a product will prove itself over on it's own.


Yeah, Open Source / Open Hardware in IoT is a step back in the direction of how things always were and how they are supposed to be - you buy the device, you own it. People understand that. They expect their washing machines and microwave ovens to work until the hardware itself breaks (let's forget for a moment about the sick practice of planned obsolescence). They expect to be able to repair them or find a third party that can.

People don't have to understand "open source". They will understand the concept of "works until hardware dies", or "can be taken to a repairman for fixing", or "I can go to a mall and buy an extension from some random vendor and it will work".


People do NOT expect to repair their home appliances anymore. Repair costs more than replacement.


This is doubtful. Nobody buys a new furnace when it has a problem. Ovens, fridges, and dishwashers are all generally far cheaper to repair with a local repairman than replace.

A lot of house or condo sales now come with "home warranties", where a flat fee guarantees your appliances for a year, and repairs only cost a $100 deductible.

Computers in most cases, even, are now appliance-like. They get replaced less often, and it's often more affordable to repair them than replace them.


Maybe in the US.


Huge as compared to? Yep, on HN you will get a sizeable proportion of those interested. The world is not HN though.


Nest isn't a polished consumer product unless your bar for "polished consumer product" starts and stops at the industrial design budget. If they didn't look nice anyone with sense would call these products what they are: trash.

And, anyone who wasted money on one... did in fact waste their money. They can still get on board with a working, non-Nest solution at any time.


>I don't think you can compare anything Raspberry Pi with a polished consumer product.

put it in a hummus tub :)


and put a "300$" price tag on it to complete the illusion.


Oh man. Thank you so much for posting this - it looks really well developed and surprisingly mature. (Or maybe I shouldn't be surprised?)

Anyways, I'm sure my wife will ha^H^H love you for giving me another "fun" home project. :)


I've also been using HA for a while, mostly with custom made devices over MQTT. Can honestly say that it is quite impressive and is remarkably reliable (important when it's controlling your lights or thermostat). My only knock is that there isn't a whole lot of flexibility in customizing the frontend, but the tradeoff is that configuration is more straightforward.

baloob is also very helpful on the issues page and seems to really love the project, so kudos to him.


Also great is the wow factor when you show off the mobile interface. Material design is a big time crowd pleaser.


No prob. I'm in the same boat. My wife rolls her eyes so hard when I show friends everything.


Rolls her eyes - but secretly impressed, am I right??


This is great , but less techie consumers need turnkey solutions, from names they trust. Is there a value-added reseller ecosystem on too of rPi platform? With an open-standards coalition?


I'm so going to set this up in my new flat. Could you please recommend starting guides / reading materials? Thanks



Good links. Also https://home-assistant.io/cookbook/ has lots of examples which will prove invaluable for setting up various rules.


Curious which router you're using. Time for an upgrade, and am open to advice.


I'm using a Buffalo WZR-600DHP and it's been keeping up pretty well. If you want to go all out, I sent my mom a Nighthawk (Netgear AC1900) because I wanted extra processing power, and therefore extra bandwidth, for remote ham radio operations stuff. It also works well.


This is illegal in Australia. A customer can reasonably expect that if they pay $300 for an electronic thermostat then it will function for a reasonable amount of time, otherwise the manufacturer will repair or refund/replace. The reasonable amount of time in this case, particularly for a $300 thermostat, would be at least 5 and probably at least 10 years.

There was a case that passed through the courts yesterday, Steam tried to exclude these warranties. They didn't get far with that. Source : http://www.gizmodo.com.au/2016/03/australian-federal-court-f...


Same in the Netherlands. Not sure there is legal precedence but warranty law says a product should keep working as long as 'reasonably expected'. This means you don't get 1 or 2 years of warranty, but potentially fifty if that would be reasonable. If the seller (they can't forward you to the manufacturer or anyone else, either) refuses however, I suppose there is little short of a lawsuit that will help you through.


I believe that's the same for the whole of the EU. The fact they were still on sale 18 months ago would make this pretty open and shut, as there's a mandatory 2 year warranty. The question is whether these were sold in the EU.


In Australia, you make a complaint to the ACCC and they will take all the legal action for you after they investigate.

Apple was probably the most famous case of where this occurred, but Samsung, HP and other well known brands are now super careful not to violate the law. It's very expensive and dreadful PR if they do, and they have no way of winning.


Same in Canada (Québec at least).

I even had Amazon US agree to it.


I think legally as the market grows there will be only a couple of possible outcomes.

The company will have to release a binary or open source a product that will allow the consumer or someone else to run a server that maintains all the functions of the last supported release and/or the hardware itself will have to be able to function indefinitely with the same feature set as the last release.

Its illogical to expect that Nest would continue to support and fund a product that they didn't want and wasn't bringing in any new revenue, but as a consumer it will make no sense to ever buy an IoT product that doesn't have a guarantee of working exactly the same as the last update.

It doesn't solve the issue of company planned obsolescence, but it atleast gives expectations to both sides of what to expect from a current hardware device.


Its illogical to expect that Nest would continue to support and fund a product that they didn't want

Eh? Then why did they buy it? The continued support for this component should have been factored in the buying price.


They aquihired the talent but didn't want to buy the obligations. Seller (investors) and Buyer got together and screwed the consumer.


There ahould be a law that when a company goes bankrupt, the source becomes public domain. After all, the public compensate for the losses. And this law should apply to discontinued products, and discontinued features. Like Parse or Google Reader.

Open software is a huge step on civilization, so we should work on making most of it public-domain by default.


Except that most of these products have proprietary components that are merely licensed. The company that goes bankrupt doesn't even possess the source code let alone the right to make it public.


Then they should post an escrow/insurance bond to perpetuate the licenses for X years.


Hence the importance if open protocols. Imagine if Ethernet had a proprietary protocol. The internet wouldn't have ever been born.


This whole saga serves less as a warning to customers and more as a warning to businesses. Be careful about acquiring other companies - liabilities come in many forms.

It may have seemed like a great deal when Nest bought Revolv - after all, we know acquihires are usually based on the fact that the acquired company was going under anyways. Pay a minimal amount for a failing company and get some great engineers.

But it sounds like they didn't anticipate the brand problem they would ultimately face for ending support for a product that was inevitably going to disappear in either case. Something early messaging (say, at the time of the acquisition) could have helped soften.

Nest didn't build this product - Revolv did. And they banked their company on its success and lost. Nest might be alive and healthy but it doesn't seem right to say they somehow acted dishonestly just because they picked up the pieces of a failed company but didn't want to prop up a product which nobody wanted.


> it doesn't seem right to say they somehow acted dishonestly just because they picked up the pieces of a failed company but didn't want to prop up a product which nobody wanted.

Agree with all of your comment except except this part.

Had Nest acquired the company after Revolv independently announced it would discontinue its product, then customers wouldn't have reason to be unhappy with Nest.

M&A is risky and research is important.

This case seems like a catch 22 for Nest. Acquire the assets early and inherit the legacy product burden. Don't do that, and risk losing access to the same assets. I'm sure they did their research.

What is not known at this point is the cost of keeping up the systems that enable Revolv's product. Were they more open about that, I might be more sympathetic. As it is I'm not sure what could be done to right this other than give Revolv customers a refund.


This is the key point indeed.

Some of us probably have a mental image of a large ec2 instance plugged into an Oracle RDS instance, nicely monitored, disaster recovery plan tested and ready, chugging away just fine. Maybe a few $10Ks per year to keep it running. Why would they piss their customers off just to save a few thousand bucks?

But in reality, maybe the back end is a teetering pile of doggy do, running on old bare metal machines in a couple of racks, backups not trusted 100%, lots of humans involved in keeping it running and answering customer support inquiries - so more like many $100Ks per year (indeed some companies would be able to spend $1Ms). In this case it would be crazy to try and keep it running, since there is no new business coming from it.

Likely the truth is somewhere in between.

Some transparency here from Nest would be a PR win.


The solution is to deploy new Nest firmware on the Revolv hardware, not axe your customer base. Then you at least get to exchange the loss of features with entree into the current Nest ecosystem. The message now is that all Alphabet supported hardware can't be trusted. Ha ha sucker. You just blew $300 on a fancy doorstop.


Yes, I can't help to compare this to what happened with Parse. They are shutting down but they released the backend as open source and customers could keep going on.

I think that companies should be more careful at offering "lifetime subscriptions" or similar stuff. You shouldn't be allowed to take back that. Can the people in their boards be sued for damages even if the company closes? I don't know about the USA but in other countries board members are personally responsible in some cases, for example frauds.


Or just ship a free Nest or $200 Nest/Google gift card to every Revolv customer still online as of Jan 1 2016.


I don't know how they could spin this in a positive light.

Here's a story from Joyent from about four years ago

https://news.ycombinator.com/item?id=4391669

I will bring this up every time someone wants to give Joyent money. Do NOT give Joyent money. They will screw you over.

Edit:

> In an ideal world, Hub owners would be free to point their devices at a different central server, run by a third-party competitor or a trusted friend, or even run such a server on their own. They would likewise be free to collaborate on improved software that would unlock the potential of the Hub hardware or purchase such software from a competitor to Nest.

> We work to improve the law and protect your right to tinker with technology. But there's another way to push back against untrustworthy devices, and that's refusing to buy electronics and software that prioritize the manufacturer's wishes above your own. Certainly Alphabet, which owns both Nest and Google, is going to have trouble selling its hardware in the future if it doesn't provide customers some assurance that they won't be left in the cold like those who rely on the Revolv Hub.

A few years of deprecation warnings alongside a free and open source server that works as a drop in replacement for the server would mitigate much of this bad will. Alphabet cannot isolate this to just Nest.

This leaves a bad mark for unrelated projects including on hub https://on.google.com/hub/

> OnHub keeps getting better.

> Future friendly

> OnHub is designed to support a growing number of "smart devices" over time because it includes Bluetooth® Smart Ready, 802.15.4 and Weave.

> Always improving

> OnHub often updates its router software with newly released features without any interruptions to your Wi-Fi.

> Stays secure

> OnHub's software includes advanced and always-evolving security features to keep your network safe.


"We appreciate and value you as one of Joyent's lifetime Shared Hosting customers. As this service is one of our earliest offerings, and has now run its course, your lifetime service will end on October 31, 2012."

"Lifetime..." "has now run its course..."

/me smh


There are numerous ways they could have transitioned customers... open sourcing the server or providing an upgrade path to newer path to newer devices or even providing a date in the future to transition by.

The path they chose is the one with the least fore thought for their brand and customer relationship.


That's the risk you run when you acquire a company - you get their liabilities and their assets.

Nobody should shed any tears for Nest, Google or Alphabet. They bought the company and if they didn't do sufficient due diligence, then tough. They can't just abrogate their responsibilities when they don't feel like it!


They probably saw this hazard and determined early-on to cut the product. Most likely, all messaging up until now has been lies.


When you pick up a piece of a company, you pick up assets AND liabilities. I'm not sure how it could work any other way.

If a "lifetime warranty" can define lifetime as "until we don't want it to live any longer", then it lacks meaning. But unless they can get away with such a claim, they acquired the liabilities of those warranties and should honor them.


Actually, in the U.S. it is very common for acquirers to structure an acquisition as an "asset purchase" precisely so that they can pick and choose the assets they are purchasing and the liabilities they are agreeing to assume. In general, the buyer and the seller are free to agree to whatever arrangement they wish in the purchase agreement.

There are of course limitations in background law for protection of creditors, employees, the environment, and the government's interest in certain kinds of government contracts. Also the Common law concept of "successor liability" is sometimes applied to buyers that try to escape liability.

But there is no general principle requiring liabilities to follow the assets of a business.


> Nest didn't build this product - Revolv did. And they banked their company on its success and lost. Nest might be alive and healthy but it doesn't seem right to say they somehow acted dishonestly just because they picked up the pieces of a failed company but didn't want to prop up a product which nobody wanted.

When you buy a company, you inherit its customers as well as its assets. If you decide that you don't need those customers and can afford to alienate them, that's your decision to make, but you don't get to blame the previous owners for your own actions.


  If you decide that you don't need those customers and can afford to alienate them, that's your decision to make
I don't know about American law, but herearound, when you acquire a company you acquire the contracts, which this company has underwritten. You can't just tell your counterparties: "Tough shit and sorry mate! We apologiese for the inconvenience!" and just tear up valid, legal contracts at your discretion.


In America, most contracts customers get with devices like this read along the lines of "we can eat your children and you're required to applaud while we do so".


In many cases, what you read about as "acquisitions" are actually "asset sales," meaning that the seller and the acquirer have specifically agreed on what assets have been transferred (say, real estate, IP, brand names, machine tools, whatever), and what have not. Similarly for liabilities. There are, of course, laws relating to fraud, consumer protection, etc.

It's only when you actually acquire the company (buy the outstanding shares) that basically "everything" transfers to the purchaser. And even there, they can agree on carveouts for specific liabilities or other things, such as existing customer support.


Nest could've handled this a lot better by doing the followings:

1. Provide 2 more years of support.

2. Provide incentives to current owners by letting them upgrade to new version at discount, or offer discount to other Nest products.

Yes, people are pissed because they're bricking their devices. But people are more pissed because the compensation Nest is offering is nil and comes across as absurdly greedy.


My guess as to why they're offering nil

1. Alphabet is tightening the purse strings

2. Nest's hub, coded named 'Flintstone', is really behind schedule. It's so behind schedule that Google came out with their own hub, called OnHub.

This was a really botched acquihire


I hope you mean nest when you said it. Occam's razor

> CEO Tony Fadell, a former Apple exec, has tried to infuse his former company’s DNA across Nest. That means a preference for only pushing polished products out the door, an antithetical approach to its sister company, Google.

> Since joining Google’s fold two years ago, Nest, the connected-device maker, has yet to release its own new connected device.*

> * Its only new hardware, the Nest Cam, was a repackaging of its acquired Dropcam product.

https://recode.net/2016/03/24/nests-next-frontier-for-the-sm...

I'd say Tony Fadell is the weakest link here. Things work differently outside the reality distortion field.

> "Larry Page is said to be a friend of Fadell, but he would do very well to stay completely out of it," remarked Mr Gwyther.

http://www.bbc.com/news/technology-35925139

As an outsider, I think whether alphabet and Tony Fadell part ways soon or not will be indicative of things to come.


The OnHub is a quite polished product.


I have no direct experience with it. However, I was the pilot program cr-48 Chromebook program and that is one little engine that could (and mostly still can .. All these years later)

And Google/Alphabet is willing to lose all this goodwill with Nest.


From personal experience, it's not:

1. When I lose internet service, I couldn't manage my OnHub since everything is in the cloud including my router logs.

2. It doesn't support standard router features like NAT loopback.

The list goes on.


So what you're saying is a company can buy another and get all of its assets and none of it's liabilities? Wow that's a win-win situation!


Of course. Buy the assets, sign hiring agreements with the old people, close down the door on the old company once everything is transferred.


I think the issue is mostly how they're bricking the device. Can't they let it keep running while no longer providing any support?


What I love is the number of people who keep espousing cloud services of every other nature. "Everything is already there! They're better at security than you!"

And then history shows services close down, change ownership, prices fluctuate, and there are inside and outside attacks and data loss.

You try to tell people that though and they just close up and repeat the same argument.

This is why I think repeatable installs / setups of infrastructure is important, and tested on self hosted infrastructure before bubbles pop.


I'm working out a concept based around the long tail of slowly-realised costs. It's another economic market problem, similar in regards to informational asymmetries (all information isn't equally available to all parties), but here, all information isn't equally available at all times.

Market perceptions are based on promptly-evident information. If the immediate impression of a good is negative, then even large long-run benefits tend to be strongly discounted. If the immediate impressions are good, then even large long-run negative benefits are discounted. All the more so if those long-run effects aren't trivially evident. Take Thomas Midgely. Invented two compounds both of which had immediately evident benefits: freon and tetraethyl lead. Unfortunately for him, they both also had exceptionally bad long-term costs.

I'm not aware of any similar concept in economics, though Gresham's Law is perhaps related.


Sadly with home automation, most of the commercial turnkey products are cloud based and they can't run locally. Wink, Smarthings, Kasa, Homekit, Hue, Onhub, Nest, Mama... nearly everything relies on the cloud.

Hopefully open source can provide a good substitute.


How does hue rely on the cloud? It doesn't even need internet access unless you want to update the FW.


You're right. Hue doesn't require cloud access. Neither does MiCasa or WeMo.


As the owner of a nest thermometer, a couple nest cams, and a nest fire alarm I sure hope that nest reverses their policy on the Revolv hub. I have been pretty happy with my nest products so far, but this makes me seriously reconsider buying any more.


Well... they just told you: You don't really own those devices. You're paying upfront for a lease that lasts until they decide to deprecate the service. Yay, IoT!


Next up: cars!


Reminds me of a short scifi story I read in the ~1992, cant remember the title of the novel or the book it was published in :(

Deep space mission is send to a distant solar system where signals of civilisation have been discovered. As they approach the planet all the signs, radio waves, artificial lights, etc progressively disappear. Meanwhile on the planet we are introduced to the civilization that solved all of the world problems by providing everyone with a job, all thanks to invention of a timed catalyst able to disintegrate any matter after coded period. Every item on the planet is programmed to turn into dust when expired. Clothes one year, car 3 years etc, perfect planned obsolescence on a global scale. Unfortunately there is an accident at one of the catalyst producing plants at the time deep space mission approaches. Giant spill creates chain reaction eating everything on its way. Narrator goes back to the space mission, now landing on a barren planet, with astronauts embarking and looking around confused at the sight of an empty world.


Found it! It is "...et in pulverem reverteri", a short story by Janusz Zajdel, one of the best polish scifi writers, think Lem/Asimov/K.Dick https://en.wikipedia.org/wiki/Janusz_Zajdel

It was published in a collection https://pl.wikipedia.org/wiki/Ogon_diabła

Google translate: https://translate.google.com/translate?hl=en&sl=pl&u=http://...

Whole collection is high quality scifi, equal to Asimovs 'The Last Question' for example.


"What do you mean my four-year-old car has been end-of-lifed?"


- Where's my car?! - Discontinued. It drove itself back to us last night.


>"What do you mean my eighteen-month-old car has been end-of-lifed?"

FTFY


Just do what Japan does and put into place super strict vehicle maintenance and emissions standards...that go into full effect when the car is six or so years old. Though in this case it wouldn't be a truly complete obsolescence, since the owner could just spend more to keep up with the standards.


I was considering upgrading to a nest smart home, but this has shown they don't care about customers. They have lost my trust and gained animosity... I won't give them a penny and I will discourage anyone from buying their products.


Just stick with basic thermostats and controls. Using these over-engineered devices will be a nuisance if you decide to sell your property or temporarily hand over control to someone else. Never mind the problems with cloud based vendor lock-in.


The joy of free markets. Sometimes they work!


I "own" a Nest Protect alarm. I liked it and was planning on outfitting the rest of the house with them during renovations this summer. I will not be buying any more Nest products/services now. The risk is too high to have them in my home.


I got given one for Christmas. It appears to work as advertised. But it also slightly spooks me that it is an Internet-connected black box with a microphone, and the kind of thing that under the UK's proposed Investigatory Powers Bill the government could probably insist be hacked to spy on me. (The microphone is used as part of the self-test routine, to check the thing is sounding properly).


Replace them with Z-Wave or Zigbee products instead. There are a lot of hubs out there which don't require cloud connectivity or a monthly connection.


INSTEON does a solid job. Their protocol is proprietary, but the devices aren't cloud dependent. You can either use a cloud hub device, or just a serial adapter to a PC or third party controller. They have no ability to take away my Insteon thermostat's functionality, or mine data from it. Because all translation of it's communication protocol goes through my computer, and is interpreted by open source software.


I would stay away from anything Zigbee. It has become a complex mess


We bought a Dropcam, which worked great until they decided they no longer wanted our non-US credit card. Replaced with Ubiquiti UVC cameras. What a waste.


I think they'd have major legal issues to shutting off people's thermostats. Losing control over heat and cooling could be a major health and safety risk.

That said, I wouldn't be surprised if nest cams were on the chopping block.. despite how many parents use them for monitoring infants.


Do they really stop working without network connectivity? I just assumed that they would "fail-safe" into a local/manual mode, but am I mistaken?


You are reconsidering. And you admit that you are heavily personally invested in the brand. What will it take for you to not buy any of them any more?

We like to protect our investments. These investments are in time, money, effort and psychological face. We would rather wait and see if our investment still is worth something after all we put into it.

Brands, if we have invested in them sufficiently, are able to get away with much more than other companies because the consumers who have invested so much are unwilling to lose their investment.


Surely this is illegal? If a Nest tech turned up at your door and when let in to do "service" he took a hammer to the device destroying it, people would be suing left and right for property damage. Surely this is just the same?


Happened with my iPhone.

Its screen started to behave unreliably, and it was still on extended warranty, so I brought it back to the point of sale.

After keeping it for 1.5 months, they told me it was damaged by liquid (it wasn't, so no warranty for me, the phone is beyond repair, and I have to pay them €80 for their efforts). They would also physically destroy it.

I told them to [redacted], threatened to sue them, so they waived this €80 fee, but still won't repair the phone despite the warranty.


Are they actually damaging the devices or are they just turning off the remote servers that the devices rely on?


The devices were sold with the implicit promise that the servers operated by the manufacturer would remain in service, so I don't think there's much of a real distinction between bricking a device by shutting down servers vs. hitting it with a hammer.

That said, they probably tried to weasel themselves out of any obligation via the EULA.


The company, Revolv sold this product to people - then nearly went bankrupt in 2014:

http://recode.net/2014/10/24/nest-acquires-home-automation-h...

Another company swooped in, and bought them in 2014 - they immediately stopped all sales of Revolv products, but decided to keep the Revolv service running for nearly two years afterwards, for the older customers.

However, eventually, they seem to have decided to pull the pin - perhaps they knew it'd just keep bleeding money. After all, Revolv never made money, and they haven't sold any units in nearly two years, so they have zero revenue to show for it.

Either way - how exactly do you see it as reasonable that they should keep them up ad infinitum?

I mean, say Revolv had just gone under, and nobody had swooped in to save them, and keep them on life-support for two more years.

Would you still be yelling about the EULA means a bankrupt company should still keep paying it's server bills?

I somehow doubt Jeff Bezos is coming to leap in and be like, "Gee, you're bankrupt. Don't worry, here's a couple million dollars of AWS credits, to keep your servers running for two years. And don't worry, in two years, I'll give you a few million dollars more, cause I'm just a nice guy. Oh, and here, let me load you five of my software engineers, and a couple of my site reliability engineers, in case it crashes."


This is nonsense. A company "swooping in" to buy a company assumes the liabilities of that company.

If Alphabet were to buy a struggling company, they don't get to go to it's creditors and say "We will pay you $1, which you should consider a blessing, since if the this company went out business you would have got nothing".

Similarly, if the company made sales of a product on the notion of "lifetime support and updates", a purchasing company is absolutely responsible to uphold those guarantees (this is the type of thing companies do due diligence for before acquiring a business).


Yeah, right because this company that swooped in to do the saving did it out of the goodness of their hearts and did not see any benefit to doing so whatsoever.

Well, if this company happens to be a publicly held company then its investors should be mad about this habit of going in and buying companies that are not of value to them.

But I bet they did see a value, but where there is value there can also be liabilities and you have to assume both of them. You don't get to choose just the value.


I never said they did it from the goodness of their hearts.

I said, they swooped in - then ceased all sales of Revolv products. I have no insight into why - but perhaps they figured Revolv nearly went bankrupt selling these damn widgets, why would we keep selling them as well. But then instead of shutting the servers down right then, decided to pay to keep them running for nearly 2 years.

I'm sure they had rational reasons for buying Revolv, even if the product never took off.

And perhaps they had reasons for delaying the shutdown for two years.

See, that's the thing I don't get - the company basically failed - somebody comes in and buys it up, and keeps the lights on for two years, possibly to avoid exactly the nerd rage we're seeing now. But then the nerds rise up and rage anyway =).

Hell hath no fury like a nerd with a grudge...haha.

Seriously, some of the things that we as a company get up in arms about - if you actually talk to mainstream people, they're like, huh?


The picture you paint is confused at best. It's clear that the company had some assets that made it worthwhile to "swoop in" instead of allowing the company to shutter and to buy the assets in a fire sale during bankruptcy.

But it appears that those assets were not it's products, and not it's customers. So, now that they own the company, and the relationships with the customers, they decide to not honor their product with those customers.

I suppose that's fine. But you should not be surprised if people read that as a signal that Nest will do the same thing with any of their other products.


If they didn't want the customers maybe they should not have bought the company.


If you've got a device that can't run without access to remote servers, despite purely local functionality, then turning off the servers is just as pointlessly destructive as coming to your house and hitting the device with a hammer. If this was a device whose core functionality legitimately required connectivity, that might be different, but it's not.


Does it matter? The effect is the same, and it's a choice not that the company is insolvent so cannot continue.


What's the difference between damaging the device and making it no longer able to perform the function it was designed and sold as?


Physical destruction.

The nest is affixed to a wall via quick-release bolts so that if it's mounted too high to reach, you can remote-eject it.

Properly reprogrammed, the incendiary charge on the quick-release can act as an autodestruct. Beyond vaporizing the device, in some cases it's taking out a chunk of wall or the family pet.


I would bet good money that you are from .eu, .au, or .nz.


From The Verge, "Nest says it may offer 'compensation' to Revolv users for disabling smart home hub:"

http://www.theverge.com/2016/4/5/11374358/nest-revolv-smart-...


Probably would have been a good idea to sell the bridge before burning it.


"Here's a $20-off coupon for a Nest thermostat" might be what they deem "compensation", though.


Now we know they will give back something but are not sure how much.

The Nest/Revolv situation is reminiscent of when Netflix raised prices in 2011 [1]. It was a great product, and despite being the industry leader, customers disappeared overnight. Then Netflix made the correction and recovered strong as ever. In that moment Netflix was touch and go and needed money. Fortunately for consumers, they survived.

[1] http://www.cnet.com/news/netflixs-lost-year-the-inside-story...


Netflix just hiked their prices up 60%. That's definitely high. But Nest bricked hardware that customers have already paid for. I have less sympathy for Nest here.


I'm talking about the price hike years ago when Netflix was still building steam. These days Netflix is more widely used and they have more money in the bank. Nest today is still building steam and could be hurt by negative PR.


studentrob: > Netflix was still building steam.

Netflix's stock price went down, but they already had a huge streaming business and were not distressingly low on cash.

In fact, raising prices generated record revenue.

So your comments don't make any sense to me.

However, if you had said, "Hollywood could rape Netflix any time they wanted on licensing fees," then that is actually true and the reason Netflix is a sketchy investment, and why they are creating their own content.


> So your comments don't make any sense to me.

What I meant was, before the price hike, Netflix's future looked bright. After the price hike, the future looked a lot less bright. The drop in stock price shows that investors agreed.

> Netflix's stock price went down, but they already had a huge streaming business and were not distressingly low on cash.

I agree not distressingly low, thanks for the correction. In 2011 they had $376 million [1]. That's still low given your point that they needed to generate their own content. This year they plan to spend $6 billion on creating their own content [2]. That's an expenditure that didn't exist previously.

In 2011, Netflix's streaming business was huge and competitors were popping their heads up. Hastings' job seemed to be on the line and there was some light talk about whether they could be acquired or taken over [3]. That was unthinkable six months earlier.

> In fact, raising prices generated record revenue.

Raising prices may have generated revenue in the short term. They also lost a lot of customers by doing so. Long term, they felt they were better off building a stronger user base first. The low stock price probably did hurt their balance sheet.

Bringing this back to Nest, I see this as a pivotal point for them. I could be wrong, that's just my opinion.

> throwaway_xx9

Do you really need a throwaway to discuss Nest and Netflix? ;-). You make some great points. Even if you were the one who decided to do the Netflix price hike or Nest/Revolv retirement I wouldn't fault you. You never know how users will react. I don't agree with all of your points but I'm not an analyst, just a programmer. The trick is not to stress over the past. It's to understand the past, assess what's happening today and react, and consider the future.

[1] http://money.cnn.com/2011/09/19/technology/netflix_cash/

[2] http://www.ew.com/article/2016/01/17/netflix-too-much-tv

[3] http://fortune.com/2011/12/14/if-netflix-is-for-sale-who-sho...


That clearly depends on how sustained and loud the pushback is for announcing the bricking of 18 month old devices.


It is kind of funny that we discussed here a service few weeks back with life time usage granted to the users and my argument was that I cannot take anything like that seriously from a company that was not around 10+ years at the very least. This move from Nest/Google just confirms that we cannot trust these companies with "lifetime" promises.


Time to buy a new car because Google no longer wants to support yours.

The wonders the future holds.


Well, I read that the current system for self-driving cars by Google relies on a lot of data from Google (i.e., its system does not purely work through in-car sensors). So if Google decided to pull the plug on that data, or even if they stopped keeping the data current, we'd be in precisely that scenario.


I think you'll find that while Google is good at throwing a lot of money on expensive experiments, Google would be a terrible car manufacturer. Car companies are already doing their own research, and making better user-focused designs than Google's "people are stupid, take away their steering wheels" mindset.


I do think the potential for self-driving cars is vast. Personally I'd rather not own a car, but subscribe to a fleet of self-driving cars. Then the issue I made a sarcastic comment about would be moot.

This is appealing to me because I have no special attachment or interest in cars other than as a means to get from point A to point B. I understand many people enjoy car ownership and the culture surrounding it, but I just want a tool.


People are stupid, and should have their steering wheels taken away. I trust an algorithm driving way more than a stupid, moody, aggressive human.


Which is an unfortunate position given that human drivers are still vastly safer than any algorithm. The way Google presents its marketing for Self-Driving Cars is meant to downplay that.

Their cars are deathtraps without human drivers.


According to what source? I've not looked into it, but everything I've seen shows that self-driving cars are much safer. Likewise: Self-Driving cars are going to get safer, whereas I see no reason for humans to do so.


According to Google, actually. They're just very deceptive in their marketing. Google reported to the California DMV that across 424,000 miles driven, Google cars would've been in 13 accidents (10 of which would've been their fault) without human drivers interceding. Even if you only count the at-fault accidents, that's an accident every 42,000 miles. Which is a terrible record.

Meanwhile, insurance companies estimate humans average about 250,000 miles between accidents. Factor in unreported incidents and we get a safe estimate that human drivers could be closer to 150,000 miles between accidents.

At the most generous factor I can provide, humans are three times better drivers on average than Self-Driving Cars.

...But wait. During the same 424,000 miles, the cars' automated driving system had a system failure, reverting to the human driver, 272 times. (Roughly every 1,500 miles.) Without a human driver to take the wheel, who knows how many more accidents they could've caused.

The secret to the Self-Driving Car's safety record isn't their software. It's humans. Google's "1.4 million miles driven" isn't a really useful statistic, because it ignores all of the "hard parts" of driving where humans had to take over and save the car. Bear in mind, Google's test drivers are trained, and are attentive and alert at all times to quickly take over control. The human test drivers, therefore, are better than the human average, and that's where your safety figure comes in.

Source: http://static.googleusercontent.com/media/www.google.com/en/...


You're thinking Apple. Android 2.x still has 2 or 3 percent of users just fine.


Not sure what you mean but Android 2.x has been been unsupported for awhile now - https://en.wikipedia.org/wiki/Android_Gingerbread


Ah yeah, Google never ditches or turns off products.


[flagged]


I don't really expect a phone to be supported beyond 2 years because that's the standard contract length, although I do think it's wasteful and I've had my phone longer than that. My basic heating system control unit is about a decade old and I'm sticking with it.


Recent phones (i.e. less than 5 years or so) still work pretty well even with the latest OS updates, there is really no reason to make them obsolete apart from the laziness on the part of Google / manufacturers. Even Apple has been supporting the original iPhone for much longer than 2 years.

Buying a new phone every 2 years is not just a waste, it's expensive. You pay for it with your contract. I live SIM-free and i go for the cheapest providers without buying a new phone that often. Works fine and I have yet to see any application that's not running fast enough. The only missing piece of the lack of OS updates.


And my wife is still on iOS 6 on her 4s just fine, so what? Noone is releasing patches for either.


Actually Google does, it's called the support library and its very much used.


And it doesn’t help Android <5 devices to get support for TLS.


Hey, I just sent you a message on Orkut.


Not quite the same thing to discontinue a free service, or brick a device for which you shelled out actual cash, based on a promise, which turned out to be a pretty filthy lie.


Politicians, or the one's that care about their constituents, need to nip this in the bud.

Something like the Massachusetts Right to Repair Initiative.

The inititative would have to go deeper, and include all the issues brought up in this article.

I am so tired of throwing away perfectly good items I bought because I can fix it, can't get parts, can't afford the Authorized Repair Center, not agreeing to one sided TOS, not having access to their sacred propriatiatry systems, etc.

Obviously, the initiative will need a lot of thought put into it, but it's time. I'm still on the fence when it comes to original propriatiatry information, but most of it is not original, or inventive. It's just information they don't want us to have!

My biggest gripe is not this Nest product Google bought.

It's not having access to my cars electricial system, schematics to electronic devices (the one's the company technicians use--they are like cartons. Company technicians have wonderful repair information.), appliance repair information, all electronic devices, and even the factory oiling diagram of that Rolex on your wrist.

Right to buy parts if available from the company would be tacked onto the bill. Oh yea, the intentional bricking of any devise would become illegial, or only warrantied in special cases--that would be decided by a judge.

I just want information, and parts, and some protection from sneaky ways to brick a product. The initiative won't be perfect, but it will give a company second thought when they decide to get Cute/Slick. Not having access to the repair of your product is sneaky way to keep you spending.

The time has come. The average consumer could care less. They seem to buy whatever looks shiny. You people will have to push for some protection.


I am curios to see what Tesla will do when their cars get old. Will they open up or will they just brick them?

I really don't linke where this is going. Apple started it with the phones by making repair very difficult. Now others have also gone that way. Even the MS Surface has its battery fused so you can't replace it easily.

I understand it if you make a device that is water proof but for anything else there is no reason.


To me, the solution to this is simple: if you eol a product that renders it useless, open source it. Allow someone else to support it and perhaps at a profit. The same would happen if a phone or cable company decided to drop and unprofitable area.


Wouldn't this be a little tricky if such a step can expose proprietary parts in the closed-off products, given that one can expect a reasonable rate of reuse?


If you care about proprietary tech, it's not going to be with a product you've kicked to the curb. Besides all anyone really needs to support the hardware is a firmware version that allows net configuration and its api.


Given that Revolv's server software was presumably running before Nest acquired them, and from all rumors, not improved since, what possible proprietary Nest code could it have?


The really hairy stuff is usually not the first-party proprietary stuff (e.g. "This stuff is so important to our business we need to keep an exclusive license.") It's usually possible to make an argument to the right business-person that the cost is not so high when compared with the extra brand goodwill and free maintenance.

Rather it's the third-party proprietary stuff. Someone else owns proprietary code you deeply rely on but doesn't share any of your business goals and needs. And when dealing with hardware, there is a whole raft of firmware and drivers that could be licensed this way.


Who said it was Nest's?

Maybe it runs on Oracle. Maybe it has third-party stuff licensed for their use but not open source distribution.


Then you keep running the official servers..? There shouldn't be a third option available here.


More eletronic devices, more broken devices.

More smart devices, more devices infected by viruses.

More IoT devices, chaos.

The only people who are able to use smart devices are the ones who projected them. There's no point in trying to sell to the large public a lot of things they will not understand, this will only make them dependent.


> There's no point in trying to sell to the large public a lot of things they will not understand, this will only make them dependent.

That's the goal (added emphasis).


This kind of behavior is reverse piracy: instead of people pirating Big Corp's music and movies, it's Big Corp that's leaving people without the use of their products. So, the internet gods requested two sacrifices: privacy and ownership. Did I miss any?


Security


I think it is more generally a warning to anyone relying on the cloud.

If you develop an app that is hosted in one of the main cloud providers, not the sort of app you have a team developing actively, rather the sort of app you develop once and forget. The cloud is a living thing and doesn't guarantee stability.

First there is always a small risk that they may terminate your account as a result of whatever change of policy.

But mostly the technologies on which your app rely (web framework, storage API, cache API, etc) will likely be retired on a short notice. Outside of a VM, the cloud is not the right place to host something you want to run for 10 years without having to take care of it.


The fact that software drives everything now means that we never quite own the product we initially purchased. I remember thinking this a year or two ago when Samsung dropped from my Smart TV an app for a streaming service that I used quite a bit.

While this Nest situation is an extreme case, we're now always one update away from products being altered in ways that make them very different from what we originally purchased.


At least many of these IoT devices still work if their Internet service goes away. An unsupported smart TV still works as a dumb display for a more modern streaming stick. An unsupported smart fridge still keeps food cold. my smart scale can still weigh me even if it can't upload the reading. I'm not sure if a Nest thermostat can work offline indefinitely, but I sure hope it can.

The question is, what will most consumers do when they discover their smart device is no longer smart simply because it's "old"? Considering the lifespan of the dumb versions of these products, I'm guessing the owner's definition of "old" will differ from the manufacturer's. Not many consumers would consider a 15 year-old refrigerator to be old, but it's hard to believe Samsung will still be maintaining the software on their 2016 smart fridges in 2031.

Will most people say "well, that was nice while it lasted" and keep using it as a dumb device, or will they be so used to the smart features that they'll go out and get the latest, supported model - deciding that a thermostat or a bathroom scale is now something that needs to be replaced regularly like a phone or a PC?


>Considering the lifespan of the dumb versions of these products

And what's ironic about that is that in theory the lifespan of the product should be longer, given that that it can theoretically be "enhanced" OTA vs in a pure hardware situation. But, of course, there's no financial incentive.

We may start seeing more paid software upgrades for new features.


Roku 4 remote has a dedicated Pandora button, that didn't last long. I'm sure a few TV's had Pandora as a feature.


Similar to another commenter’s note about Raspberry Pi, this seems like an argument that an well-supported, and ideally open, OS is the way to go for devices. Android comes to mind, even iOS would be unlikely to leave customers in a lurch.


Yeah, if only there was a well-supported open-source OS that is generally regarded as reasonably secure and has been ported to pretty much everything under the sun. It would be nice if it ran the GNU userland for easy development and had a fast and portable kernel.


Since the Revolv products themselves already run such an OS it might just be a matter of popping a root shell, curling a dropbear, and killing the update daemon.


GNU/Windows



Yeah, that kind of OS is unheard of. :)


It is amazing that so many are so desperate for shiny new tech that they're willing to put up with this kind of stuff. I used to consider myself an early-adopter, but its clear they're being played for fools...


Ok, I was thinking about buying a Nest, definitely avoiding it like the plague now! My home is a long term investment!


I was going to buy a nest, but now I'll just rig myself something up with a Raspberry Pi. Lower cost and I know it will still work in a few years.


I actually had a Nest in my Amazon shopping cart about a week ago and just hadn't pulled the trigger...This decision was the end of that idea.

I have (embarrassingly) come to accept that everything I own will eventually be always connected to the internet, streaming back data to sell me more crap. However, I reject the notion that a hardware device should ever require an internet connection to work. Frankly, that is and will remain a bridge to far.

Working with engineering students has taught me that often the most meaningful experience that students have is so called 'service projects' where they work for people who have had vastly less privledge life experiences than themselves. The entrepreneur, techno-weanie, early adopter loves SV and startups. The side of my brain as an educator and a member of a larger society is becoming increasingly concerned about the same people who seem to increasingly live in an echo chamber. My research and teaching focuses on entrepreneurship. A few peers and I have coined the term entrepreneursplaining for the tone deaf actions and responses in situations like this.


I never understood the need for anything beyond a standard programmable thermostat. M-F turn on/off depending on temp and then Sat/Sun do something slightly different because I'm here. I end up messing with thermostat maybe 4-5 times/year at most?


Be careful doing that. A smart thermostat isn't exactly trivial, and doing it wrong can be bad.


> A smart thermostat isn't exactly trivial, and doing it wrong can be bad.

That's sarcasm, right? I automated my HVAC in the '90s and even then there were a ton of roadmaps to follow by people who had done it before. It was an afternoon project using something similar to these: https://www.sparkfun.com/products/245


As Nest demonstrated time and again.

Their thermostats had a defect at one point (not sure if it was ever actually fixed) where if your heating or cooling system caused a surge in your wiring, your nest would get stuck with both heating and cooling at full blast, or something equally silly. The Nest thermostat was certainly not designed to fail safely or sanely.


What do you mean? The home-hobbyist community has been doing this for years using protocols like X10, Zwave, etc. And we used Usenet groups like comp.home.automation to meet and discuss stuff. Home Automation has a very long tail of history and those of us who came up that way all knew Nest was going to be a joke.


I don't know why you've been downvoted, as you're absolutely correct. A defective thermostat can easily shorten the lifetime of your HVAC system. If your furnace itself is already defective, a buggy thermostat could even cause it to overheat and start a house fire.

EDIT: to those who mention the hobbyist scene, consider that such projects are not necessarily trivial, and that getting it wrong remains potentially catastrophic. I believe the parent's point still stands.


if temperature > max(desired_range):

  activate_ac()

  deactivate_heat()
elif temperature < min(desired_range):

  deactivate_ac() 

  activate_heat()
else:

  deactivate_heat()

  deactivate_ac()


While it's tiresome to read comments on HN like the GP's that seem to come from a "Look at me, I'm more Catholic than the Pope" mentality, the reality is that a good thermostat algorithm is a fair bit more complicated than that.

You need to take hysteresis into account, temperature overshoot/undershoot, your compressor's duty cycle and startup latency (especially as it impacts MTBF), emergency/backup furnace control, failsafes to make sure the house doesn't freeze or overheat if/when any of the above goes wrong... lots of stuff like that.

The spec for an HVAC control system isn't overwhelming but it does warrant some thought.


In the UK, many homes and older office buildings still have traditional bi-metal mechanical thermostats. For typical domestic applications they work just fine.

For finer control of room temps, people often use mechanical radiator thermostats. They work just fine too.

New electronic models are usually just a thermistor with some analogue hysteresis. They work fine as well.

I might expect something with the extras you're describing to appear in a new office building, but in the UK at least adding PID and/or some kind of learning system to a domestic thermostat is overkill.

Generally, simple solutions are less likely to go badly wrong.

That's the tragic irony of Nest. The design is great, but the added value offered by a buggy and overcomplex implementation is negative.


In home systems aren't most of those problems handled by the furnace/ac system itself? Thermostats are pretty dumb.


Depends on the hardware. An old-fashioned bimetallic strip/mercury switch thermostat has mechanical hysteresis built in. (Actually, they can have too much lag -- some of them include heating elements to 'accelerate' their response.) Old-school mechanical devices aren't always as dumb as they look.

As far as short-cycling the compressor goes, my current HVAC is smart enough to disallow that, but I've lived in older houses where that wasn't the case. You could potentially damage the compressor by wiggling the thermostat back and forth, forcing it to start up against back pressure.

Understanding the requirements is really job #1, and first on the list of reasons why HVAC control isn't just a simple "if too cold then turn on heat else turn on A/C" statement. That doesn't mean people shouldn't jump in and try it, of course. It's the best way to learn, if not always the cheapest.


Code review #1: You're going to want to add debounce logic, or you're going to be erratically turning on and off your heat and ac when the temperature is exactly equal to the ends of desired_range.


Nitpick: it's not "debounce logic" (that's for handling pushbuttons, because the contact physically bounce, meaning you get multiple on/off readings within a few milliseconds), the word you're looking for is "hysteresis".

Because there's a giant surge current when you start up a motor (like that in an A/C compressor), and it's just plain bad and even annoying to have your A/C cycle between on and off rapidly, a thermostat will intentionally overshoot the set point when cooling, and then undershoot that same set point when waiting for the house to heat up before it turns the A/C back on (or vice versa for heating).

Hysteresis is absolutely necessary to avoid both this problem, and also the problem where your temperature sensor isn't perfectly accurate and the readings from it will vary a bit from reading to reading.


Both are necessary.

You are absolutely right that you need to account for hysteresis.

Debounce is also necessary for sensors that have precision problems, where, in boundary conditions, they bounce back and forth between a measurement that would cause an "on" signal and a measurement that would cause an "off" signal. But, I think we're agreeing with each other :)


Yep, we're just disagreeing over minutiae :-)

For the sensors, it seems to me that a debounce routine wouldn't work, and (this is assuming the sensor is giving an analog reading, not an on-off binary reading) what you really want there is some kind of averaging routine. Usually, the way a debounce routine works is that you look for a state transition (off->on), and then wait 30ms (general rule of thumb for human-actuated switch) and look again to make sure that the state is still "on" and then you do your operation based on that. But for analog sensors, you probably want something that's more like a running average so the readings don't vary too much, and one erroneous or too-extreme reading doesn't affect things much.

I could be wrong though; this is probably highly application-dependent.


Or just put in a deadband, that's what most thermostats do.

Also, you should note that most of them also don't show the exact temperature in the room... it's an algorithm. Your furnace might heat to 68 on the display but the actual temp may be between 67 and 69, but if your display temp constantly bounced it would result in mass consumer disappointment.


You can use this logic if the range is wide enough and you don't check that often. Or better yet wait 5 min after changing state to check again. You often have at least high and low heat which adds complexity.

Also, overshooting you ideal temp is fairly easy to do as there can be a lot of hot air in the vents even after you turn down the heat. So a little predictive modeling can be useful.


Also you can decouple the handling of ac and heat, and check the current state to prevent a redundant transition into the current state.

  if (temp > max + error)
    if (off (ac))
      turn_on (ac);

  if (temp < max - error)
    if (on (ac))
      turn_off (ac);

  if (temp < min - error)
    if (off (heat))
      turn_on (heat);

  if (temp > min + error)
    if (on (heat))
      turn_off (heat);


If in between samples you go from above max to below min you'll have both heat and ac on.

The take-away is that like programming lift controllers[0] it's not quite as simple as it might first seem - many many edge cases.

[0] http://play.elevatorsaga.com/ (for example)


I think that's wrong, because all 4 if-statements are evaluated for each sample.

But yes agreed, in general there are lots of edge cases. I actually wrote a finite state machine specification for an elevator in a logic class once. Without having really thought about it much, it looks like the biggest problems with thermostats are dealing with scalars, sampling frequencies, and sampling error.


I'd prefer a nice fuzzy logic rule set with some variable speed on the heat/fans.


I know what debouncing is, but I don't really grok it. Is there a Khan Academy-style explaination somewhere?


If you hook up an oscilloscope to a physical button, you will see that there's not a nice clean on/off when you press it [1]. The signal bounces on and off for quite some time after. This is a problem in a lot of situations. If, for example, a momentary push button is used as a power button on a device, it might be connected to an interrupt on a microcontroller. Without debouncing the device will rapidly switch on and off dozens of times over a millisecond. While there are easy ways of debouncing in hardware, most don't bother, as it's very simple to do in software. The simplest is just to ignore or disable the interrupt for a short period (a few milliseconds, perhaps).

Here's an Arduino sketch showing a simple way of doing it. https://www.arduino.cc/en/Tutorial/Debounce

[1] http://www.labbookpages.co.uk/electronics/files/debounce/bou...


Many thanks


It sounds simple, but this algorithm will very quickly break both your ac and heating units.

You want a PID controller in there (in some cases you might get away with just PI, but that needs analysis of the specific case)

Ideally of course you'd want to model the exact energy loss curve of the specific building you're in but nobody really does that.

The best part is of course that a PID controller sounds complicated, but the simplest one is actually just around 15 lines of code.


Throw an anti-short-cycle delay in there. You've never programmed HVAC have you.


And also PID control... and defrost or heat exchanger cooldown intervals... and further checks to avoid overcycling and damaging anything with a compressor. And probably a dozen or a hundred other things I don't know about because I'm not a process controls engineer.


Pretty sure you just illustrated GP's point


I'm really just looking for a thermostat that I can adjust from bed. Maybe add some scheduling in. I dont really want something "smart", just programmable.


In my last (rental) house, I actually went to the trouble of moving the thermostat off the wall and mounting it on my nightstand, courtesy of 50' of Cat5 UTP cable. Highly recommended "life hack."


Remember when Google's guiding philosphy was "Don't be evil"?


Alphabet's is currently "Do the right thing". But anyone who knows anything knows that the people claiming the most they're doing the right thing, are usually the ones doing the opposite.


It's more like "Do the right thing to make the most profit."


>customers who reasonably expected that the promised "lifetime" of updates would enable the hardware they paid for to actually work,

That would be the functional lifetime of the device. "All these on this list are dead." Promise fulfilled.


We're buying products whose core functionality, or for which bricking functionality, relies on software outside the device that costs money to maintain.

If you're buying stuff that relies on the cloud to run, you're just buying the plastic and silicon, not the actual capabilities those deliver.

Maybe the law needs to define what "lifetime" means, and whether a company that buys another company inherits the lifetime of their products. Maybe Nest should have spent some time and money updating the services so that things would run off of existing Nest cloud services and turn these Hubs in to weird-colored Nest devices.

But, the bigger issue is thinking that we're buying capability when we're buying just the plastic and bits through which the capability arrives.

If we want to buy the capability, we need to start demanding that again.


I didn't catch it in the article, but I assume they're turning them off because they have a back end service that's going to do nothing but cost them money if they continue to run it. Does anyone know if that's the case?


> Lifetime support

Silly consumer, not _your_ lifetime, the lifetime of the product.

BTW, we just declared your 300$ gadget end of life. kthxbai...


We better get used to hardware-as-a-service.

Cars will soon be all-electric, self-driving and pretty much unrepairable.

IoT and smart devices will push everything to subscription model.

Your television and the Internet will no longer be the only place you are served ads. When you reach into the fridge for your store brand dairy product, the fridge will say, "Start living healthier now with almond milk! It's currently on sale! Just tap OK on the screen to order a gallon!"


Maybe a stupid question, but is there a follow-up/replacement to the product they are turning off, and why didn't they contact their customers and propose free replacement? Would be such an easy way to completely avoid this customer relations nightmare.


There's no reason cloud devices can't have a limited fallback service. This is just lazy software.

We're creating a culture where it's ok to throw fully functional hardware into a landfill because of bad code.


So my thermostat stops working when the internet connection goes down? No sale.


It's always nice to see the author of such serious articles is in fact human. Can we use this as a way of detecting the robot writers? (is being actually fun hard for AI?)

> Customers likely didn't expect that, 18 months after the last Revolv Hubs were sold, instead of getting more upgrades, the device would be intentionally, permanently, and completely disabled. (To be fair, the Revolv Hub design resembles HAL from Space Odyssey: 2001, so perhaps someone saw this betrayal coming).


This is the frustration I have with "cloud" devices, and why I try to avoid using them.

Sure, they're convenient as all hell, but if it points to a webservice that I don't/can't control, it inherently has a shelf-life.

The issue is that while I totally could figure out how to set up a self-hosted home-automation thing, I'm not sure that the average non-technical user could, which means these cloud-devices are here to stay.


Pretty sure this would be illegal in the EU. Seems a bit flying by the seat of your pants to me.



I was interested in Nest devices, but will now never buy one.


If you excavate any square yard of ocean you'll find a bunch of sharks' teeth in the sediment. They're like tree rings for ocean paleoclimatology. They're 'high tech' (in the sense that an apex predator uses them), effective and constantly being replaced.

Now do the same thing with a landfill and you'll find generations of silicon doodads in the strata.

My point: we shouldn't be too surprised when things are disposable. Sharks' teeth aren't useful after they fall out. Companies can't be supporting ten generations of gadgets.


>Companies can't be supporting ten generations of gadgets.

Yes they can. Car companies support ten model years and more just fine, and keeping servers alive is a lot easier than constantly replacing mechanical parts.


Yes, but how many cars do you know that sell for $300?

This sort of logic is enshrined in consumer law as well - the courts idea of a reasonable lifetime for a product is tied to the amount you pay.

If you buy a $50,000 car new, sure, a reasonable person could expect it to last 5-10 years.

You buy a $200 webcam? I somehow doubt you'll be able to argue that it must work 3 years later - if it does, great. If it doesn't, well, what's a reasonable lifetime?

And a lot of armchair commentators seems to underplay the amount of sheer engineering effort or cost involved in these sorts of things - it's not a case of spinning up some AWS instances, and hacking together some PHP on your weekend and deploying.

To get a reliable service, with some decent SLA, which handles changing load and tolerates failures probably takes significant infrastructure (cloud or bare-metal), as well as a team of software engineers and site reliability engineers. Not to mention support teams.


Okay, but from my perspective as a consumer, I can buy a dumb programmable thermostat that will almost certainly keep working for 20 years for $25. If you, as a company, want to convince me it's worth 10x that for a thermostat I can adjust from my phone, the damn thing better work just as long. When you brick other "smart" devices because you don't feel like supporting them anymore, that makes the $25 dumb white box look like a much better value proposition than the $250 shiny circle that might stop working whenever you decide it's time for everyone to buy shiny circle 2.0.


> If you buy a $50,000 car new, sure, a reasonable person could expect it to last 5-10 years.

I just had to pick this one. Five years for a car? I expect clothes and computers to last 5 years, for $50k car I'd expect 20-30 years with proper maintenance and repairs. Not that I'd likely use it myself that long, but the expectation would still be within that timeframe.


Are you actually telling me you'd go back to your car manufacturer after 20 years, and demand they fix your car for free?

Or if you buy a shirt and wear it for 5 years - you'd go back to Kmart after 5 years and say, your shirt wore out, give me a refund?

The sense of entitlement in that statement is...pretty high. I'm just going to leave it at that.


This was about expected lifetime for a product, not the warranty period. I don't know how you came up with that.

If I expect shoes to last 10 years, I'm also prepared for some basic maintenance such as regular polishing and the odd sole replacement. The same obviously applies to car repairs.


"Are you actually telling me you'd go back to your car manufacturer after 20 years, and demand they fix your car for free?"

If they sold it to me with the claim that the drivetrain had a lifetime warranty, and the fault was there?

Yes.


> And a lot of armchair commentators seems to underplay the amount of sheer engineering effort or cost involved in these sorts of things - it's not a case of spinning up some AWS instances, and hacking together some PHP on your weekend and deploying.

I see this all the time with people that know zilch about technology, but it really disappoints me when I even see my fellow technologists underestimate the amount of engineering effort it takes to get something simple like a server up and running reliably.


Here's the thing. Creating and updating a system costs a lot more than leaving it alone. They already did the expensive part. To abandon basic maintenance is pretty disappointing.


No, it really doesn't.

Computers don't exist in a vacuum - the environment is constantly changing.

Let me put a real-life example.

Say there's a new SSL vulnerability or zero-day discovered - you go and check to make sure all your servers and packages are patched. Or maybe there's no patch yet, and you need to run a mitigation.

You better go check all your logs, to make sure nobody got in already though. Hmm, maybe you should contact your NOC as well, just in case.

Load just increased - you better spin up some new servers. Whilst AWS might like you to believe this is all one-button and it works with no human intervention - it probably isn't.

Oh, drat, one of the uptream endpoints you rely on just broke their API. You better whip up a patch. Then you need to test it, and make sure your CI server passes all the tests for it. Oh, and then hire some testers.

The point is - things are more complex in the real world, particularly running at any kind of scale.


This sort of logic is enshrined in consumer law as well - the courts idea of a reasonable lifetime for a product is tied to the amount you pay.

Not exactly; in the UK it's tied to "reasonable expectations" for that kind of product. Certainly non-smart heating controllers would have an expected life time of 10-20 years, so why do the more expensive smart ones get away with a lifetime of less than 3?


Are you actually saying that you'd be able to successfully take a company to court, because their non-smart heating controller stopped working after 10 years?

Heck, even 5 years?

All of this for some cheap widget? (I assume from your description it's cheap).

If you can find a single case (or similar case) where this happened, I will stand corrected.

If this was a $2000 laptop, I can absolutely see that - e.g. Apple Macbooks in Australia have a statutory warranty longer than the manufacturer's 1 year warranty. But I think you'd be hard pressed trying to claim after 3-4 years that it should still apply there. And this is for a $2000 laptop.


The consumer protection law stands for 6 years. Price is taken into account. What's "reasonable" is certainly something that can be argued one way or the other. http://www.whitegoodshelp.co.uk/faulty-appliances-sale-of-go...

Here's an example of how it often works in practice, although on a shorter timescale: http://forums.pepipoo.com/index.php?showtopic=52242

Laptop power socket fails within 6 months. Is repaired, fails again. Demands refund, is refused. Takes company to small claims court; they fail to mount an effective defence and are in any case in the wrong, so he wins £400+costs.


Software is ever-changing. A camshaft within some tolerance will work even if it's been in the warehouse for N years.

Almost a million ford F-150 trucks were sold in 2006 and most haven't been 'rewritten' in the intervening years. Also, each repair event comes with new money. Neither of these conditions is true for server software.


This is server software for equipment that's not being sold any more. Nothing is changing. If they weren't willing to commit later money, they should have put some in a trust up front.


Err, no - anybody who actually works in software will tell you everything is changing.

Server and package vulnerabilities get discovered all the time.

And load is never constantly - it's not like you have 1000 users, and they do the same thing every day, 365 days a year.

And there are an army of script kiddies out there trying to break into your servers. Or maybe somebody more skilful, trying to break in and steal some PII (personally identifiable information).

Point is - the environment and your users are constantly changing. If you don't take that into account, it can blow up pretty bad.


Updating a server and redeploying should be automated and take only minutes in the vast majority of cases.

Load isn't constant, but if you're not selling the device any more it's doubtful you'll have significant load increases after the first year.

Shutting down a tiny fraction of your servers isn't going to protect you against hacking.

Worst case scenario: Remove all PII from the server, and have a single employee spend a few hours a week checking on the server and updating anything necessary. It might go down occasionally, but it's infinitely better than no server at all, and it costs basically nothing compared to the original development effort.


> Updating a server and redeploying should be automated and take only minutes in the vast majority of cases.

There's much more to running a product than 'running a server'.

Eventually, the software is going to stop working on my SOE. Which means more and more boxes are going to be running non-standard deployments in my environment (or it costs me to update). Every maintenance window, infrastructure upgrade, disaster recovery exercise (and event), has to take those servers into account.

Perhaps I pay licenses for those servers to run - OS, support, databases, backup, whatever. Maybe I have a contract with an SI to run all this as a managed service and this costs. There's opportunity cost in terms of resources for keeping all these legacy products on as well - both infrastructure and resource related.

And that's just the technology related part of it. There's business and accounting impacts as well.


> Eventually, the software is going to stop working on my SOE. Which means more and more boxes are going to be running non-standard deployments in my environment (or it costs me to update). Every maintenance window, infrastructure upgrade, disaster recovery exercise (and event), has to take those servers into account.

If you're fussy about nonstandard servers on your infrastructure, go get a handful of basic servers from hetzner or amazon. Completely silo them. No access from them to your 'real' servers, and don't include them in maintenance windows or disaster recovery. The person who is paid to spend a few hours per week keeping the server mostly-up will use part of their time on basic updates and backups, and nobody needs to worry if something occasionally breaks.

> Perhaps I pay licenses for those servers to run - OS, support, databases, backup, whatever. Maybe I have a contract with an SI to run all this as a managed service and this costs.

If you have license/contracting costs, you should have pre-allocated money for that when you released the product. If it sold to expectations, a later decision to discontinue the line shouldn't be a problem.

> There's opportunity cost in terms of resources for keeping all these legacy products on as well - both infrastructure and resource related.

There should be no infrastructure impact, and the equipment/employee cost should have been part of the initial product scope, not treated as an externality that can be trimmed at will.

> And that's just the technology related part of it. There's business and accounting impacts as well.

Like what, having to process a quarterly bill for the servers?

Let me put it this way: While the costs are real, they were expected, and can be made pretty low. They should be able to run or outsource a basic legacy server without any hurting. I bet if there was a contract saying they had to refund $2 to every customer for every month the servers were down, they could get plenty of offers to take over hosting for half that price.


What makes Nest's actions deplorable is not just that they don't want to support and maintain the product; they are also deliberately destroying pieces of hardware purchased and owned by customers.


nest is doing the world a favor. we need to learn the lesson of closed hardware sooner rather than later.


The only people talking about this are people who already know the risks.


I agree we need to learn the lesson, but am not convinced Nest's actions are overall beneficial. Learning a hard lesson isn't the only way to learn a lesson. We need more tech companies who can lead with positive messages about openness


Have you got any evidence that they are destroying hardware?

I know it sells headlines, but I've seen zero evidence at all to back up these claims.

From what I can tell, they're simply pulling the plug on the service.

They already stopped all sales of the units nearly two years ago - in fact, that's one of the first things they did when they bought out the failing Revolv company.

So they've basically paid to keep it running for two years - and this is just speculation, but maybe they decided, this is enough, it's just bleeding money, we have zero revenue to show for it all (since we haven't sold any units in two years), we need to pull the pin on it eventually.


More likely everything is running on autopilot, well documented so low level support personnel can address any issues that might crop up, and consuming a minimal amount of revenue since the number of Revolv users is fairly static and most likely decreasing over time. I doubt it costs more than $1000/mo to operate the Revolv infrastructure, not counting the humans supporting it, who are probably spending 80%-90% of their time on non-Revolv items anyway.

The real reason for pulling the plug on Revolv is to try and drum up Nest sales, but it was executed poorly since they haven't made any particular effort to steer the screwed Revolv users to Nest, or offered any concession.

Tony Fadell will no doubt shit his pants when he reads this post, but despite how accurate it is, I don't even work there.


I should note that I think this whole thing was handled poorly, and I think there's a lot of room for our entire industry to come up with some best practices surrounding sunsetting (and, in my happy place with free ponies for everyone, mandatory open-sourcing of the backends needed with clear instructions for how customers can switch to running their own. But that's my free pony land.)

But that said, I think it's more than that. There's no such thing as autopilot on the Internet, particularly for a company that deals with customer PII (and I count the ability to control stuff in your home in that category. :-). You can imagine the rathole -- we've all been down it a few times: You need to upgrade the kernel/libc on your EC2 instance because of the security vulnerability du jour. But libraries X and Y won't run after the upgrade, so you need to upgrade them. But the developer of those libraries changed the interface, so now you need to... yadda, yadda. One or two of those changes you can probably just hack in, but depending on how disgusting the codebase is (and let's be honest here - it was an acqui-hired startup that was probably in panic mode towards the end!), at some point, it starts looking like a choice between a total rewrite or tossing it to the wind. Suddenly that takes you up to an FTE, who in the valley is going to cost you >= $20k/month. Then you divide by the # of still-active devices (I have no idea what this # looks like) and suddenly it looks like a big resource drain for no benefits.

(Imagine, for example, that the engineers became aware of a firmware-level vulnerability that exposed all customer devices to remote exploits and control -- and somewhere between the acquisition and then the build system for rebuilding and testing the firmware had gotten screwy. Or the last set of test devices in the lab finally broke. Or that, plus it turns out the remote firmware update mechanisms had never worked in the first place, and fixing all the bugs would require not just fixing them, but actually creating and deploying an entirely new update path. Or, or....)

Of course, one can wish that were the case something like that, it had been communicated. My fingers are crossed that maybe Nest - and other companies - can use this as a learning experience and come up with policies, with teeth about acquisitions, governing the sunsetting of cloud based services that are essential for the operation of customer hardware. I'm not optimistic yet, but I'm glad to see the EFF raising the issue.


If the number of active devices is too low for Nest to justify continue running the service, then they can do a "buy back" or replace it with a similar Nest device.


Ok, so you buy some widget for $300.

You get a couple years use out of it - do you really expect the company at the end of it to be like, gee, let me buy the gadget back off you?

I mean, come on....

It'd be super swell if the company decided to just throw money out at people like that, but come on, the sense of entitlement of some people here is nuts.

Look, I bought the Titanfall game. It's multiplayer-only. I knew that when I bought it. Just like the people who bought Revolv 3 or 4 years ago.

If Respawn (makers of Titanfall) decides to shut down the servers tomorrow, sure, I'll be upset, but I'm not exactly going to go on some massive nerd-rage, because I believe they should just keep it running forever.

Do you really think I'm going to turn around and demand a refund, a year later?

I work in tech - so I know how much it costs to keep infrastructure running, and the teams of people that work behind the scenes to keep it all running smoothly.

Surely we're not so disconnected that we know that we engineers get paid a pretty good amount, right?


> > If the number of active devices is too low

> do you really expect the company at the end of it to be like, gee, let me buy the gadget back off you?

Yes. If it is cheaper to migrate (or compensate) a handful of existing customers for free than to keep running a legacy service, the company should be making this call.

I mean, come on...

I knew that when I bought it. Just like the people who bought Revolv 3 or 4 years ago.

You don't really know what every person knew that bought Revolv, do you?

I work in tech

Especially since it is your business to know more about this than the average consumer?


Don't these pieces of hardware rely on their service being provided? Their service is what they want to shut down, after all; this can't have started from a desire to brick hardware devices.


The right thing to do, then, would be to release an update allowing users to direct the device to another server without having to violate DMCA's anti-circumvention clause.


Isn't the server it connects to proprietary?


People can repurpose hardware to work with a new backend, but only if the hardware is unlocked.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: