Originally published at: https://boingboing.net/2018/09/26/outage-outrage.html
…
5 Likes
So the solutions so far to the problem of “make it possible to manipulate these controls without actually physically standing and walking over to the control panel” are:
-the internet of pwned things,
-the internet of things that will not work if the mothership ever goes offline, and
-the internet of things that siphon up all of your personal information and sell it to ad agencies.
Are there any companies making simple, secure, private, and non-mothership reliant app controllable devices that are actually useful (ie, basic stuff like electrical outlets, thermostats, and light switches, not refrigerators or toasters)?
How does one find such unicorns in the wilderness of pwnable, spying, mothership-reporting crap?
9 Likes
While I can’t say that this outage impacted me, I can say that Honeywell’s connected systems are crap through and through. The features are awkward, when they work at all. It’s like one guy said “I need it to be remotely accessible “, and then all development work was shipped overseas for nine months to people who have never lived in a climate requiring thermostats, and who have been taught never to question their client’s requirements.
For example, if you add a Vacation to the thermostat’s schedule, it will hold the air conditioning temp to the energy-saving value you set, like 85. If you are heading home a day early, and want to arrive at a cool house, you might expect to remotely log in and set the thermostat lower, right? Wrong - the remote app gives you an error that you can’t remotely change the thermostat because it’s in vacation mode.
It’s that bad. I would never buy any Honeywell smart thermostat again.
8 Likes
I doubt it. Creating dependency on shoddy tech is much more profitable than selling reliable robust systems that work without permission from the manufacturer. Welcome to the rentier economy 2.0, now with the illusion of ownership.
7 Likes
When will engineers and software developers get it into their heads: It doesn’t need to phone home to function, unless its function is to phone home.
A light bulb is there to provide me light. A company’s servers going down should not interfere with that element of its functionality.
8 Likes
Can you still get hold of X10-based stuff?
1 Like
This is where I think BoingBoing store could really shine, by recommending and selling such items if they existed.
Ultimately, though, the only way we’ll get your unicorns is by third-party maker hacks to cheap white-label hardware where the firmware improves the encryption, blocks connections to device by remote bad actors, and cuts out the centralised server that caused so many problems in this place.
7 Likes
I have these, they have outages from time to time, an occasional erroneous alerts, such as “the temperature has risen to over 90deg”. But otherwise they’ve worked fine, even if the apps GUI is weak - they were cheap.
1 Like
It could be worse. Suppose you’ve added a behavior to Alexa so that you can tell it to turn up the heat without getting out from under the covers? Voice -> Amazon -> Honeywell -> Thermostat. What a lot of points of failure!
Hopefully people take this into account when throwing junk together for space missions.
“Open the pod bay door Hal.”
“I’m sorry Dave, I can’t do that … right now. The command is on its way to the airlock company on Earth, and it will take 87 minutes for the unlock command to return (assuming the corporate backend is up).”
10 Likes
I have one of these, came preinstalled in our current home. It’s good enough when it works, lets me set a schedule and change the temp when I want. Otherwise, I mostly use the app to read the hygrometer on the thermostat to see if I need to adjust our ERV settings.
Yesterday was the first time it didn’t work, but, so what if I have to go adjust it manually. What gets me is people who somehow depend on that functionality working. What kind of use case needs that? I guess something like Airbnb? In which case, don’t you want to go for an internet-focused companies thermostat, rather than a thermostat-focused company?
5 Likes
Yes. Property managers in general. Perhaps hotels and co-living spaces, too.
Either way, what you don’t want is the needless* dependency on a centralised server at the vendor for all customers that caused this problem.
[* except for the data-mining vendor looking for an extra revenue stream]
5 Likes
Given the issue at hand, I still think it’s genius that somebody figured how to sell $200.00 thermostats.
3 Likes
No. Given the current state of networking, it is actually shockingly hard to make a simple to use network controlled widget that does not call into a mothership. Between NAT, OS firewalls (many of which render multicast discovery useless), native app installation problems, multi client scenarios (computer + mobile app) and more, it is a real pain to get “regular” users to be able to even access a screenless device in their house. By contrast, making a HTTPS connection to the public internet almost always works. So it is just much easier to go that route.
7 Likes
There was X10 stuff that wasn’t shoddily made and unreliable? That’s news to me.
1 Like
Every now and then I think “I could do my own thermostat with a Raspberry Pi!”. Sanity quickly arrives to kick butt.
3 Likes
There’s a reason why space agencies the world over prefer tried-and-true tech they know inside and out, even if it’s a generation or two behind the cutting edge.
2 Likes
I think the tendency towards using a cloud-based control system got kicked off because of choices made in network node addressing as part of the Internet Protocol version 4 (IPv4), helped along by an exponential increase in security risks, as the popularity of the Internet exploded in the 1990s. This caused a huge imbalance between the number of desired Internet hosts, and the number of available host addresses. Today, even though Internet Protocol version 6 (IPv6) remedies the IP address deficit, the use of a cloud-based control system is fairly well entrenched, and going back to direct-control of on-premise endpoints by end-user devices may take a while.
In the early days of the Internet, if you wanted to control something remotely, your control app connected to the IP address of the thing to be controlled, and you controlled it. As Internet usage exploded however, the spectre of IP address exhaustion loomed. A quick hack called NAT/PAT (Network Address Translation/Port Address Translation) made it possible to use one public IP address to service a whole network of of private IP addresses, which alleviated the crisis. This approach worked well for the dominant use case where many hosts on the private network wanted to access resources on the public network (i.e., most web access, which was what was driving the exponential rates of Internet adoption). The result is that practically all home and many/most commercial entities connect to the Internet today using some kind of a NAT/PAT gateway, so much so that the use of private network addresses (such as 192.168.0.1-255) is now thought to be “normal.”
This hack made the reverse communications much more difficult - public IPs can’t directly access hosts on a private network (behind a NAT/PAT gateway) without additional configuration. Most NAT/PAT gateways can make an internal, privately-addressed host externally visible by linking a public IP to it, or at least making a particular combination of an IP address and TCP or UDP port number accessible to the public, but the wits to configure this are not readily available to many consumers, even small to medium enterprises.
A clever way around this impasse was developed by businesses who wanted to offer remote control capabilities for devices they sold to consumers. The business provides a publicly-addressable server on the Internet to which the consumer-owned devices connect to from behind their owner’s NAT/PAT gateway; this kind of outward-bound connection works without additional configuration. The business also provides a control app to the consumer; the consumer runs this app on a smartphone, tablet, laptop, or desktop computer that is connected to the Internet, and the app connects to the business’s publicly-addressable server on the Internet. The publicly addressed server run by the business thus realizes communications between the control app and the device to be controlled without any wit on the part of the consumer.
IPv6 solves the availability of IP addresses such that we can go back to using all public addresses, with no more private address spaces required. If IPv6 can be fully adopted, we could theoretically go back to having control apps able to reach controlled devices directly, with a fairly easy (but not dead simple) configuration process, and no intermediate server run by the business that sells the devices and the control app. However… there are still security issues, and the vendor lock-in (and for the overly cynical the vendor visibility into private data) afforded by cloud-based solutions may inhibit a trend back towards direct controls even after IPv6 is fully deployed.
Have you converted to IPv6 yet?
4 Likes
The best one that I’ve found (so far) is the Kasa line from TP-Link. They connect over WiFi and don’t require you to set up an account or go through a mothership to control them. Do they phone home occasionally? Probably because everything else does. But if my Internet or TP-Link’s servers go down, I can still control my bulbs and plugs locally using the Kasa app or HomeAssistant.
I haven’t heard them be pwned (and would be very interested in hearing if they have).
I realize that they only cover 2/4 of your requirements (simple and non-mothership relying), but like I said: they’re the best ones that I’ve found so far.
EDIT: After writing this, I found this article on IoT threats that listed TP-Link as being the second-most popular device maker of pwned devices. So maybe just take everything I’ve said with a grain of salt.
3 Likes
I might do it with an Arduino or ESP8266, where I could control all the software on the device, and have a chance that it’d fail safe, but the sticking point would be insurance.
I bet that any claim, even if the thermostat/furnace wasn’t involved, would get sticky once the insurance company spotted the homebrew thermostat.
I read something recently where the writer pointed out that very soon now all IofS devices will use the same Internet chip, because they can. All the problems of monocrop, lack of updates, plus extra functionality running on devices that don’t need it.
1 Like
To be clear, although it is an IoT device it does NOT need to “phone home to function”. I installed it a while back as I needed wireless link between new boiler/HW controls and hot water tank (a wired link was a nightmare). It works just fine in the house and has no need of links to a server EXCEPT if you wish to use a smart device away from the home to adjust heating remotely. It comes with its own remote for the house. So people are not complaining “my CH controls do not work while the server is out” but rather “my REMOTE CONTROL of my CH controls do not work on my SMARTPHONE while the server is out”
I admit if you are housebound and installed it specifically for smart device usage it is stil a bummer but the remote it comes with for use in the house is mobile within the house.
Yes I hate IoT shit as much as anyone, but this is a subtly different situation.
ETA
I did not think so! Value for money, maybe, but not at all cheap.
And @orenwolf - what you said, too.
Have either of you guys had issues with various TC components randomly not talking to each other (“lost connection”) temporarily? I suspect it is my house and its thick walls and distance between units… (I said routing a wire would have been a nightmare!) 
1 Like
