I recently wrote an article about the dozen or more IoT alliances that have popped up (opens in new tab) in the past few months all vying to be ‘the one ring that binds them all’.
Frankly I don’t think any one alliance can be comprehensive enough to support the dozens of different IoT (Internet of Things) devices that are currently on the market or are expected to ship in the coming years. And forcing device manufacturers to support multiple platforms probably isn’t going to work either because traditional home-based hardware appliance manufacturers are barely waking up to Wi-Fi let alone interconnectivity. If they have made efforts to ‘smarten up’ their formerly unconnected passive devices, they have generally built towards their own proprietary systems (everybody wants that pie – and they don’t just want a slice, they want it all).
In fact, companies like Apple, Google, Microsoft and even Salesforce all want to own that pie. They are forming these alliances in the hope that device manufacturers will start writing custom connect interfaces to their alliance’s specifications. If they can get enough companies on board following their specs then a snowball effect might push them into the VHS or Blu-ray category versus the Betamax or HD-DVD category.
I also said in the article that I believed the company or companies that will win this particular battle will separate the control aspects away from the devices themselves, and move the control functions into the cloud. Let the device makers focus on the devices and let the cloud based ‘traffic cop’ manage the interoperating.
This type of system would allow device manufacturers to build things that connect to a user’s home Wi-Fi network (using a unique ID), transmit the data they were designed to transmit, and receive information back from the network that they were designed to receive. The traffic cop application in the cloud (or wherever) would receive and process all this information, make decisions based on user settings, and send any necessary information back to the devices.
This way a smart thermostat wouldn’t have to have its own dedicated app or even an interface. It could simply transmit temperature readings to the home network and wait for any response. If it received a signal to raise or lower the temperature it would simply raise or lower the temperature as instructed, and wait for the next update phase. This would also give device manufacturers the ability to ‘transmit’ new firmware updates to devices without actually having to write the code required to do that.
This could also be used to elevate some passive devices to ‘smart’ status. A webcam that knows nothing about automated lights or security systems, or even how to store what it sees, could be connected to a system like this. When the security system detects an intrusion, the traffic cop turns on the lights so the webcam can see, starts streaming the images to the cloud to be recorded, sends a notification to the owner’s smartphone and perhaps even calls the police. The webcam manufacturer doesn’t have to develop all the back-end infrastructure of a full-blown surveillance system – the traffic cop could do all that.
If a manufacturer wanted to build a more smart device all they would have to do is register with the traffic cop back-end, tell it what type of device they want to ship, what type of data it collects and can receive, and even what protocol it uses to send and receive that data. Then all they have to do is make sure the device can connect to a home network.
Retrofitting a device that already exists and is using a proprietary protocol (or uses one of the other dozen alliance specifications) would be a simple matter of sending an email to the traffic cop website telling them about the device and how it prefers to communicate.
The traffic cop would figure out all the rest.