Pros And Cons Of Cloud Based Smart Devices
From early in the smart home industry’s life, makers of smart devices have relied upon cloud-based control of their products. There were few standards, limited technology options and no interoperability between brands or platforms. This meant device makers had to create their own apps to control their devices. In order to be able to provide that control from anywhere they had to access them over the internet, and that meant they had to have a server somewhere that could provide a connection between the devices and the customer’s phone.
Platforms like Alexa and Google Home sought to grab market share by providing ‘compatibility’ with as many smart devices as they could, but without any connectivity standards there was no way for their platforms to understand and communicate with every device maker’s implementation.
Instead, they opted to leverage each maker’s servers to provide the interconnection, simply giving the device makers a simple plugin format where they could specify what actions the customer could do, and the messaging required to their own servers to make it work. This gave these two platforms, and Alexa in particular, a huge leg up in attracting device makers, building brand awareness, and carving out market share in a rapidly growing eco system.
Apple chose to do things differently, by designing a robust and strictly enforced API that ensured their platform could talk to any devices made for it. This meant their platform, HomeKit, worked far better, faster, and more reliably, but suffered from a dearth of supported hardware for many years. Apple’s approach, it would turn out, was going to win in the end.
So, for many years, the vast majority of the smart home market was communicating entirely over the internet. Between the customers and their own devices, and between devices and the smart home platforms that provided automation and voice control across multiple brands. Dedicated smart home technology did exist, but it was poorly understood by the masses, and limited customers to specific brands or technologies that excluded many of the new, shiny, low-cost products getting all the attention.
Pros And Cons Of The Cloud
Is there anything wrong with smart devices using the internet for communication? It’s worked well enough for so long after all. While there are certainly advantages, indeed these are why we ended up where we are, the downsides are significant. Let’s look at a summary:
Pros
✔ Devices can use common Wi-Fi✔ No 'hub' required for connectivity
✔ Easy to intergate between platforms
✔ Broad interoperability possible through APIs
Cons
✘ Customers are exposed to hackers✘ Latency can impact responsiveness
✘ Functionality is limited by APIs
✘ Loose plugin requirements cause unreliability
✘ Devices only work as long as maker decides
✘ Internet or server outages break smart home
Connectivity
Being able to use the common communications technology of Wi-Fi was a big driver for the internet-based approach from the beginning. New customers jumping into smart homes for the first time didn’t want to have to understand the underlying technology or set up a controller first (often at significant extra cost), they just wanted to buy the thing and have it work. Everyone had Wi-Fi already, so it was an obvious choice. Amazon drove this thinking hard with their Alexa brand, creating an explosion of cheap smart devices that people would often buy through Amazon.
Dedicated technologies like Z-Wave and Zigbee could do a better job, but a lack of customer awareness, and the need to setup up infrastructure that (at the time) tended to lock people into a specific set of device options made them less appealing. They also didn’t integrate well, if at all, with the voice assistants that people saw as the ‘smart’ of smart homes.
The problem with Wi-Fi is that it only provides a way to send messages, not any definition of what those messages are. Everyone could get their devices connected to their phones and control them, but only with proprietary apps, and in order to ensure those apps could connect to the devices quickly they had to have a way to keep that connection alive, no matter where the customer went. So invariably, proprietary apps don’t talk to the devices in your home, they talk to the maker’s servers, which pass messages to the devices that are permanently connected to them.
Of course, should you have an internet outage, or there is a problem with the servers your devices rely on, you can no longer use those devices at all. If your investment in such devices is significant you could even lose control of your entire smart home. Automations stop working, voice control breaks, and you can’t access the devices through the app. It’s probably not a common occurrence, but when it happens, it really sucks.
Integration
Having everyone’s devices always connected to a server on the internet made inter-operability an easy proposition, in principle at least. With no standards in place to define smart device communication, either a device brand could provide an API and let third parties use it to connect to their stuff, like Philips Hue, or platforms could provide a plugin format that makers could opt into that would define the messaging with their specific devices, like Alexa Skills.
These methods had mixed success. Sometimes the brand’s API was very robust and gave third parties good control, sometimes it was unreliable and slow. Likewise, brands investment in making skills was a toss-up. Some brands did this well and offered the most functionality they could, with well supported plugins that would mostly work. Many cheaper brands used the ‘compatibility’ claim more as a marketing term, and the plugins would offer very limited functionality - if they worked at all.
In almost all cases, these factors limited what the smart platforms could actually provide. The focus was mostly on actions for voice assistants and not on the things like sensors that can actually drive smart behaviors. These cloud-based platforms had no way to poll for sensor data like temperature or occupancy, so many automation possibilities were out of the question. These sensor-based behaviors were possibly only on more tightly integrate platforms using things like Z-Wave, ZigBee, and Apple’s HomeKit.
Brand Support
This dependency on cloud servers to provide any connectivity to our devices has one particularly big implication:
Our devices will only work so long as the maker of those devices chooses to keep their servers running AND chooses to support their older devices on those servers.
Unfortunately, the smart home industry is awash with stories of companies going out of business, pivoting away from smart homes products, or simply deciding they don’t want to support older products anymore.
Some recent examples include Belkin essentially killing it’s Wemo brand of smart home products by turning off the servers. That hasn’t stopped them selling inventory of those devices though. How about Google’s shutdown of the entire Nest Secure system? We can throw in some of the older Nest Thermostat models as well. But it’s all good, Google will happily sell you replacements...until they get turned off as well.
Spotify released Car Thing, a device to allow Spotify use in older cars, but then they thought “meh, not really feeling it” and shutdown the cloud service it relied on to work.
The there’s companies like Chamberlain, who are so focused on selling people access to the devices they already bought that they pull the plug on third party access altogether, or Wink, who suddenly held their customers to ransom by demanding a subscription sign up or have their devices bricked.
These stories provide a very clear warning to consumers that cloud based products are a risk, and will only have a lifespan depended on the corporate benevolence, an oxymoron at the best of times.
Security
Another very significant implication of cloud-based control is that of security. While it is certainly possible to design and build secure cloud-based devices and infrastructure the big issue we have as consumers is a complete lack of transparency and accountability from the device makers. Having our smart devices exposed to the internet via our Wi-Fi creates two main areas of exposure to hackers.
The first is the devices themselves. Poorly designed communication methods and a lack of security focus on the firmware means that these devices can easily end up with vulnerabilities that can be found and exploited en masse. This is key, it’s easy to think no one will pay attention to you, your household, and your devices. This is likely true, but hackers are usually interested in individuals. Instead, exploitable flaws in specific mass market devices are highly sought after in order to utilize those devices in large botnets that can inflict real damage on companies and the internet in general.
The second is the servers that these devices depend on. These can also have flaws that can be exploited to steal personal data, intimidate and blackmail end users, or gain access to your private network - again for the purpose of stealing personal data that can be used for fraud.
Major brands have some incentive to invest in security on both ends. That intend to be a viable long-term business, and security breaches are bad PR. These bigger brands often go to pains to tout their security credentials and commitment to privacy. They also attract scrutiny from security researchers and the media which can help to uncover any issues. In the interests of customer confidence these are usually addressed in a timely manner, but not always. It’s still up to the companies to act, and we have to take them at their word with regard to their solutions in many cases where fixes cannot be externally verified.
Smaller brands are a far worse case. With limited funding, less expertise, and a focus on pushing out cheap products fast then moving on, security is often an afterthought. While bigger brands push out firmware updates automatically in many cases to resolve any issues, these smaller brands will only do so in a limited fashion, if at all. Many of these cheaper devices can essentially be abandoned, also escaping the attention of researchers who might be able to expose their issues.
How Can We Avoid These Issues?
For anyone concerned about reliability, functionality, security or privacy, it should be clear that cloud-based control carries more downsides than the simple convenience of common connectivity. Thankfully, the smart home industry is not unaware of these limitations and has been working for years to come up with solutions that can be widely adopted.
The answer to all of the problems associated with internet exposure can be summed up in one phrase: local control.
Local control is a feature of the dedicated technologies I’ve mentioned above. Z-Wave and ZigBee both work in this way, created a local private network that is encrypted, self-managing, and also provides a way for devices to communicate actions and status with each other. Apple’s Home Accessory Protocol also provides this over more common wireless technologies like Bluetooth and Wi-Fi, not requiring the end devices to have any internet access at all.
The thing preventing widespread adoption of any of these is that they are all closed protocols controlled by a single entity. Other platform providers are reluctant to adopt such technologies as they have no control over them and usually are locked into significant licensing fees. As a result, every platform tried to do their own thing, resulting in fragmentation of the market.
That is now changing, however, with some broad industry initiatives to create open standards that everyone can buy into. This has resulted in the Matter protocol, a new smart home standard supported by all the major industry players through the Connectivity Standards Alliance.
Matter is supported by another initiative, Thread. This is a new open communication protocol designed for high reliability, fast response, and low power consumption. Thread fills the gap for smart devices that need to be wireless by allowing long battery life while still remaining highly responsive - a role Z-Wave and ZigBee have long provided. Unlike those two, however, Thread is an open standard and can be used by anyone.
Combining Thread and Wi-Fi under Matter solves all of the old problems with connectivity and communication between devices. Matter provides a consistent language that allows all devices and platforms to talk to each other, and Wi-Fi and Thread ensure we don’t need to have a proliferation of hubs to make out devices work with different brands.
Both of these new standards prioritize local control and secure communication, coming full circle to Apple’s approach with HomeKit from the start. Indeed, Apple open-sourced their HAP API and gave it to the Matter project at the outset, leading to some close similarities in the design.
The adoption of these technologies by the wider smart home industry will forever eliminate the issues of cloud-based control of our smart homes, delivering higher reliability, faster performance, more functionality, and far better security than we’ve had in the past. If you’re building a smart home, you should be looking for platforms and products that support Thread and Matter to protect yourself and your investment.
