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.
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:
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...
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.
The commercial options couldn't automatically arm when I went to work. Nor could they use Pushover. Nor did they accept pull requests :)
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.
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.
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.
If that's commercial polish, I'll stick with the Pi!
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.
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.
...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.
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.
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".
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.
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.
put it in a hummus tub :)
Anyways, I'm sure my wife will ha^H^H love you for giving me another "fun" home project. :)
baloob is also very helpful on the issues page and seems to really love the project, so kudos to him.
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...
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.
I even had Amazon US agree to it.
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.
Eh? Then why did they buy it? The continued support for this component should have been factored in the buying price.
Open software is a huge step on civilization, so we should work on making most of it public-domain by default.
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.
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.
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.
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.
Here's a story from Joyent from about four years ago
I will bring this up every time someone wants to give Joyent money. Do NOT give Joyent money. They will screw you over.
> 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.
"Lifetime..." "has now run its course..."
The path they chose is the one with the least fore thought for their brand and customer relationship.
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!
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.
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.
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
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.
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.
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
> 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.
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.
As an outsider, I think whether alphabet and Tony Fadell part ways soon or not will be indicative of things to come.
And Google/Alphabet is willing to lose all this goodwill with Nest.
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.
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.
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.
Hopefully open source can provide a good substitute.
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.
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.
That said, I wouldn't be surprised if nest cams were on the chopping block.. despite how many parents use them for monitoring infants.
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.
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.
That said, they probably tried to weasel themselves out of any obligation via the EULA.
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."
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).
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 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?
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.
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.
The Nest/Revolv situation is reminiscent of when Netflix raised prices in 2011 . 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.
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.
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 . 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 . 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 . 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.
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.
The wonders the future holds.
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.
Their cars are deathtraps without human drivers.
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.
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.
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 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.
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.
Maybe it runs on Oracle. Maybe it has third-party stuff licensed for their use but not open source distribution.
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.
That's the goal (added emphasis).
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.
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.
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?
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.
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.
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
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.
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.
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.
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.
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.
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.
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 :)
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.
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.
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.
if (temp > max + error)
if (off (ac))
if (temp < max - error)
if (on (ac))
if (temp < min - error)
if (off (heat))
if (temp > min + error)
if (on (heat))
The take-away is that like programming lift controllers it's not quite as simple as it might first seem - many many edge cases.
 http://play.elevatorsaga.com/ (for example)
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.
Here's an Arduino sketch showing a simple way of doing it. https://www.arduino.cc/en/Tutorial/Debounce
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.
That would be the functional lifetime of the device. "All these on this list are dead." Promise fulfilled.
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.
Silly consumer, not _your_ lifetime, the lifetime of the product.
BTW, we just declared your 300$ gadget end of life. kthxbai...
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!"
We're creating a culture where it's ok to throw fully functional hardware into a landfill because of bad code.
> 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).
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.
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.
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.
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.
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.
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.
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.
If they sold it to me with the claim that the drivetrain had a lifetime warranty, and the fault was there?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
> 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?