Revolv and the problem with closed IoT systems

5th April 2016


We heard this week that Nest (the Google-owned smart home company) is turning off the cloud service for its Revolv smart home hub. The device, which allows you to control various smart-home devices though a single app, requires a permanent connection to its cloud service in order to function so this move effectively renders the devices useless. This isn’t the first time an IoT device has been “bricked” by its creators: when BERG announced it was closing in September 2014 this also left its customers with a rather expensive paperweight.

These two incidents underline what we believe is one of they key issues facing the Internet of Things (IoT) today: the hard coding of IoT devices to cloud services.  When a device is hard-coded to a specific service it is beholden to that service being available. If the company either goes bust or decides to stop running the service, then the product is rendered useless and the customer is left with a very expensive brick. Incidents like this can only make consumers wary and less inclined to buy IoT products in the future. This in turn will lead to fewer opportunities for IoT vendors and less potential for innovation in the IoT market generally.

So why did this happen and what can we do about it? Hard coding devices to cloud services is the prevalent model used by consumer IoT vendors today, with the justification being user experience. Despite using the same underlying technologies as the web, the way we interact with the IoT is fundamentally different. For example, you can use a computer to access any web service in the world by simply typing in its URL to its web-browser. However, this is simply not possible on IoT devices as most do not have a user interface, so as a result they are pre-configured to only connect with a single service. This is the equivalent of having a computer that can only visit a single website, and has a huge impact on interoperability between IoT systems from different vendors.

In the consumer market this issue is exacerbated by the fact that the software on the device is generally inaccessible, meaning that device owners are unable to reconfigure their device to use a different service. Even in the generally more open world of enterprise IoT this problem of lock-in still exists to some extent. While the software on devices used by enterprises is generally more accessible, if a device’s owner wishes to change where it is sending their data, say switching from Microsoft’s Azure IoT Hub to Amazon’s IoT Platform, they they need to reconfigure and install new software on the device. This is an onerous task when you only have a few devices, but quickly becomes unfeasible for larger deployments, meaning that you are effectively locked-in to these platforms too.

What is needed is a layer of abstraction between IoT devices and services, removing the need for hard-coding. On the good old internet, the Domain Name System (DNS) fulfils this task, providing mapping between the names of domains and locations of servers and thus decoupling the two. At Nominet R&D we have taken this concept and applied it to the IoT, developing a system that uses DNS to route traffic between IoT devices and cloud services. This tool, called the IoT Registry lets you to remotely configure where your data is sent to, creating a more flexible IoT system that lets you avoid the pitfall currently faced by Google’s customers. If you are interested in finding out how the IoT Registry can future-proof your IoT network, then please get in touch at [email protected].