How three connected hardware companies killed their devices
medium.com
medium.com
We're still in an early adopter phase on a lot of it though, so it's hard to judge how it will play out.
Caveat: staunchly an IoT skeptic.
The biggest reason I'm a skeptic though is the incredibly carefree and reckless approach I've seen used by many IoT devices.
The Nest is a great example - I was shocked to discover there's no division between the part that directly controls the furnace/AC/etc and the rest of the device. That should've been a no-brainer, because first and foremost the device shouldn't cause harm, and when the "smart" portion inevitably has a problem (even if temporary), a user shouldn't wake up to a frozen or overheating home.
This stuff needs a higher level of safety and guarantee, and treating them like smartphone apps is going to end very poorly.
http://www.metzdowd.com/pipermail/cryptography/2016-March/02...
It should be possible to split up the functionality across a trusted controller with hard safety limits (only accepting signed updates) from a powerful CPU providing the IoT logic and control functions, with all the I/O components wired such that the trusted controller has the ability to disconnect them.
Ideally they'd also have all traffic routed through a home server acting as a firewall (and would ONLY work while firewalled after "firmware expiration").
(It did, though, add enough to our BOM cost that I have very little doubt that if we'd got to the "get enough investment to find a production run of 100,000" part of our plan, the requisite "adult supervision" that investment would have brought along with it would have fought tooth and nail to reduce our unit costs by a dollar or two, at the expense of all the reliability/redundancy we'd engineered in there...)
I recently replaced my old $15 thermostat with a $200 smart one. The old one lasted for a decade and a half (for $1/year), and is still completely functional; I really hope the new one lasts as long, but I really don't know that it will.
What I absolutely want to avoid is having to buy another smart thermostat in a year, or five years, or even a decade. Will I be able to avoid that? Probably not, but … we'll see.
You probably would think it'd be absurd if you had to pay your ISP $600 upfront for the 16MBit/s router model and then the ISP stopps the service after two years.
Of course, this is cheaper in $$ but way more expensive in my own time. Fortunately I think of it as a hobby and not work.
Note that you should probably familiarize yourself with basic electrical safety rules when working with mains voltage, as well as fire safety. An intro to digital electronics would probably be a logical next step. Lastly, SSRs have an undesired feature of failing in connected state, so don't connect any loads that could overheat when plugged continuously.
[1] https://www.openhomeautomation.net/control-a-lamp-remotely-u...
Also, my hub has Echo integration for most things. I can't turn the heat up but I can turn off any light or light grouping.
In the end, everything works much better and I switched to building robots for the kids.
At the edges maybe a company disables a refrigerator -- or worse smoke alarms. At the core is bricking a medical device such as an insulin pump.
When a product is initially released, users come to expect that support. If a company needs to shut down a product line and continued support...sure, ideally, users will pay attention and slowly migrate to new hardware when they can, just like people are still getting by with cars that have deadly airbags because they haven't had the time to leave their car at the shop...but as devices continue to have a feature set more dependent on the cloud and instant-push-updates...is there potential harm in letting a life-critical device function in zombie mode in such a way that it's good enough for months or even a year after the shutdown, but may be deadly sometimes afterward? The additional problem that connected devices add to the mix is that consumers have a hard time distinguishing between what features require the cloud and which features can work independently.
Obviously, there should never be the situation in which a critical device just dies as soon as the company shuts down its servers. Life-critical time-sensitive things, such as a heart pump, should thus be designed to operate independently, with connectedness being an optional feature.
But for other things, such as a smoke alarm...if a company designed it in such a way that connectedness is essential to its functionality, and that its usefulness in zombie mode can't be predicted a year down the road...can't it be argued that it's more responsible for the company to give the user a hard cutoff, rather than allowing the user the false comfort of zombie mode?
It's very poor form to sunset a product without offering users (your early adopters none the less) a easy migration path to another product. Had there actually been data standards for setup and captured data, I'd expect the ability to export my setup and data so that I can use it to configure an alternative product.
But later on, as always-on-devices are the norm...I do think it'll be more acceptable -- with the appropriate regulations and consumer protections -- to kill a device at the end of the cycle instead of designing it to operate as a zombie, in the same way that users accept that MMOs and other multiplayer-heavy games are heavily dependent on company servers...though in that case, it's easier to design a game to allow non-official servers so that the community can carry on after the official shut-off...but that's where the analogy of video game == important home device ends, of course.
Bricking the device remotely may be a criminal offence if it's not specifically permitted in the EULA. And if it is permitted in the EULA, that term may not be enforcable. And if it is enforcable, then all consumer reporting/review organisations should point advise you never to buy the product.
Certainly if one of my devices got remote-bricked I'd be taking legal action.
This is the irresponsible part.
It's still not fixed.
But I did run cat5 everywhere, and that has paid off nicely.
Which is it? "Communicating in a clear manner," or "keeping the servers running and not breaking people's stuff?" I would guess it's the latter, since Nest seems to have communicated pretty clearly that it's bricking people's Revolv devices. The lesson for "Internet of Shit" companies is completely clear: if you want happy buyers of physical devices, keep the servers running until the devices physically break. Yes, this will cost you a bit more money.
And I don't like the idea of having critical parts of a device or infrastructure somewhere in a foreign country. Today "smart" phones, TVs or even cars send encrypted data over Internet to their manuacturers. How do you check they don't spy on you?
"Cloud" services have much in common with proprietary software: user cannot have full control over them.
A search for "ios brick" suggests that your exception isn't much of an exception, unfortunately.
That way first adopters will feel safe in their purchases no matter what the outcome.
I know people have revived part of the network, I'm just too lazy to do all the work to revive it.