The Internet of Things (IoT) enables a new class of service – Product as a Service. A world where devices, things, appliances, objects become a service being offered. This had started at the high end of market many years ago even before IoT went mainstream and technology analysts forecasting numbers on the “billions” of devices that would be connected. A great example was that of Rolls Royce and its airplane engine division that even before 2009 was generating significant service revenue by monitoring the jet engines while in flight: Britain’s lonely high-flier.
Imagine a world where you don’t pay for the light bulbs or doors or HVACs upfront but you pay monthly – it sounds preposterous – doesn’t it? Take it a step further – home builders could bundle all these services – team up with a finance company and include it all in a single lease? It does sound preposterous but attempts of this nature are real. Consider what BMW & Solar City are doing – buy an EV from BMW, and you can have Solar Power included in your lease – it is the value being generated by connecting and controlling everything!
Last week I blogged to walk the talk, and getting on with IoT. I came across a blog post covering the AHR Expo – AHR is show focused on air conditioning, heating and refrigeration expo. Nest after being acquired by Google last year made HVAC, Thermostats and IoT popular. The acquisition was a major driver in throwing visibility on IoT. The reality, though, was that thermostats (and hence HVAC) were being enabled by IoT for quite sometime. But I digress…
Businesses of all sizes use HVAC, Refrigeration and Building Automation. And companies such as Honeywell, Schneider, Daiken, and Rheem have been enabling their products to be smart and connected. HVAC and Building Automation systems are installed & maintained, typically, by third parties. The third party integrators, contractors form the backbone of this business.
A sign of success is when contractors who install these “AHR” systems, and support them for repairs and maintenance – are benefitting from enabling smart connectivity on the systems. This leads to a win-win for both the contractors and the consumers or business owners. First step is to enable smart connectivity to their equipment, next step is to train and make the IoT-enabled tools available to the contractors.
Kevin Ashton, the father of IoT, has a simple advice for companies looking to leverage and benefit from IoT – “Begin”. In Why the Internet of Things isn’t like the Big Bang Kevin says, and I quote:
In what Ashton calls “the wild frontier of IoT,” the best advice he can give is “Begin.”
“There’s too much sitting around in meetings, staring at PowerPoints, waiting for someone to tell you the answer. When someone else knows the answer, you’ve already lost.”
But where to begin? Pick an internal project, and enable it with IoT. Roll it out to a limited set of customers, learn, tweak and update the solution. Analytics is supposed to be the big killer app – the data coming in from these sensors, and things that would unlock the potential of Big Data or Small Data. But to begin – collect the data. Or if you are already collecting the data (and many industrial companies have been doing “IoT” for a long time) – figure out a way of putting a wrapper around that system, and APIfy it.
That’s how to begin…
Scott Jensen introduced The Physical Web project in October 2014. It was a result of Scott’s thinking on this subject even before he joined Google (in his own words – his thinking boiled down to 10 minutes in this TEDx video). The “launch” was covered by several blogs and being categorized as an IoT standard! It is a neat idea. I can see why Google would want to promote it whose business model is based on searching, indexing the entire web. This discussion has strong similarities to the subject of Native vs. Web Apps (for a great summary – read John Gruber’s post – summarized nicely here.). URL for Everything on the same topic (using URLs for Things/IoT) by Duncan Cragg recently led to a Twitter conversation, and it triggered my observations on this subject.
Let’s dig deeper.
#1. It is about Category of Devices, not individual things
The motivation for Physical Web is “interaction on demand” and given the number of connected devices – “each new device will require its own application just isn’t realistic”. The following reproduced from the Physical Web’s webpage:
The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device – a vending machine, a poster, a toy, a bus stop, a rental car – and not have to download an app first. Everything should be just a tap away.
(BTW Wasn’t the QR Code – incidentally at a point of time – the answer to this? It wasn’t for Smart Devices but rather for small businesses – the concept was similar being able to go the right web page and find out more, get more information. How well did that work?)
In the examples above – barring the example of a toy – rest of them are to be encountered outside of your own home network. Bear in mind the notion that each device needs an application is absurd. The right comparison is not individual devices – an application will serve a category of devices. So while there would be trillions of devices connected – at any given point of time a consumer would be interested in interacting with a “category” – not all the bus stops but bus stops in a given city. Bus stops are a great idea to be connected.
#2. App-less Interaction Complicates the UX
Let’s think through the process continuing with the bus stop as an example. First you need to have a Bluetooth Beacon, that is advertising the URL. My SmartPhone needs to support BLE (which soon all of Smartphones will), and in a mode to listen to the Beacon. The Beacon would notify me when I am around the bus stop or physically launch into discovery mode (and hopefully it does not get drowned in the many other notifications fighting for my attention). Now I can navigate to the web page and discover information about bus arrivals. And next time I am at the bus stop – the theory goes I will bookmark the web page. Now think about the UX as you keep interacting and bookmarking this pages! Solving the app problem with URLs/Web Pages gives birth to another discovery problem (going by the same argument if you have many devices you want to interact with – you will end up having many bookmarks).
#3. Connecting and Discovering is just the start, the real challenge is in the System
Let’s look at the same example from another perspective – that of the Transport authority responsible for the Bus Stop. As I always say – Connectivity is a small step in unlocking value. The transport authority now has to integrate its scheduling/logistics backend into the Bus Stop so that the arrival time can be communicated. And the buses need to be equipped with real time tracking and two way communication (Fleet Management) to provide status on where they are, and what time they will arrive. If the Transport Authority is going to implement this system – it will be foolish for them to make discovery and interaction ad-hoc….
The City Mayor along with the Transport Authority would be touting the Connected Travel experience. At the very least they probably be using strategic real estate on that bus stop to advertise how to use their app – the citizen would not need discovery! Not to mention a native apps with QR Codes to download would be mentioned prominently – an app would be drop in the bucket if not in the ocean compared to the challenge of making the entire system work together.
#4. Separate the Data from the UI
Serving “web pages” implies some notion of the User Interface is embedded in the device – and that makes the support after launch harder. Any bugs or potential challenges with the UI will have to addressed. [Duncan’s URL for Everything is one step better in this respect]
#5. Use Cases should drive the approach
The Physical Web project cites another example of paying at the Vending Machine or renting a car:
How does this change things?
Once any smart device can have a web address, the entire overhead of an app seems a bit backward. The Physical Web approach unlocks tiny use cases that would never be practical:
- A bus stop tells you the next bus arrival
- Parking meters and vending machines all work the same way, letting you pay quickly and easily
- Any store, no matter how small, can offer an online experience when you walk in
- A ZipCar broadcasts a signup page, allowing you to immediately drive away
I don’t think so. Why would I want to pay through a complicated process of web pages or even find out that I can pay through URLs? A Vending Machine company is more likely to invest in supporting Apple Pay or Google Wallet, and it will make sure that each of its machine when it supports those payments is advertized loud and clear.
For a store to advertise it’s online presence – does it really need to be connected? If the business owner is digitally savvy – she probably has a website already, or a Facebook page or a Twitter handle.
I am not against the premise of the Physical Web “standard” (to leverage Beacons, URLs and Web Apps for interaction in IoT). The argument in favor of using Physical Web starts losing value once viewed in the context of the system or the entire IoT solution. I am reminded of relentless drive by Steve Jobs on Simplicity – simplicity also means avoid complicated steps.
Rethinking the Internet of Things: A Scalable Approach to Connecting Everything (which BTW if free for the Kindle Edition) makes the case for a Non-IP (non Internet Protocol) stack approach for “things” to be connected. While I am in agreement in the author, the approach seems to be all or nothing – which is not true either. I feel that for constrained devices, that emit limited data and require low bandwidth – a non-IP approach makes sense. I am not entirely clear on how many of those billions of connected devices are really simple/constrained devices.
There would be three categories of “things” based on how they connect to the Internet:
1. Devices/Things that have the resources (CPU/Memory/Connectivity) to support and run the TCP/IP stack similar or identical to ones found in PCs/Macs/Tablets/Smartphones.
2. Simple, Standalone Devices or Things: More like sensors that have limited resources making it unsuitable even for running the constrained version of IP stack – 6LoWPAN and its variants – will need to support a connectivity protocol/stack that is ideal for the low bandwidth, long battery life requirements.
BTW these type of devices/things have been around for decades now – however getting them connected to the “Internet” allows making their data available, and hence unlocking the value.
3. Complex Devices/Things – These are hybrid of 1 and 2 that is they have their own “network” not based on IP – and may leverage connectivity/protocol specific to its industry or use case. And it has a integrated gateway or bridge that takes relevant data back and forth between IP and its internal Non-IP network. A great example of this is an Automobile (now popularly in the IoT vernacular being called “Connected Car”) – the automobile makes use of CAN Bus (since the 1980s). Autos are now connecting up to the Internet using Wi-Fi or 3G/LTE (or both), and they are building in functionality to go back and forth over an IP connection to the CAN Bus as well.
Amazon is investing heavily in voice recognition – the Fire TV, and now followed by Echo. I have signed up for an invite to buy the Echo – but what I am really waiting for is Amazon opening up developer access to the Echo. Echo could be the Home Butler, the Digital Assistant to automate and manage the home. It is a step in the right direction – pulling out your Smartphone to control devices is not ideal – yes you don’t have to get up from the couch to turn off the lights (with the phone that is) but asking “Alexa” to do so wouldn’t be just cool, but mighty useful!
HomeKit defines a language, API, taxonomy (albeit for IOS devices only) to discover, pair, and control home automation devices (more about it here). The technology is very interesting, but it has implications and raises questions:
1. AllSeen/AllJoyn defines a protocol for a proximal network (i.e. local to the premise) and is limited to Wi-Fi with some support for Bluetooth. HomeKit is solving a very similar if not identical challenge. What would manufacturers prefer – AllJoyn/AllSeen or HomeKit? With limited resources would they give priority to AllSeen/AllJoyn?
2. The basis of HomeKit, appears to be a common database where information on the Accessories is stored – there location within home, the common name given to them, rooms they are in etc. Would for example the IOS App for Comcast Xfinity Home or AT&T Digital Life be willing to give access to their devices to other app developers? I am willing to bet because their solutions are anchored on professionally managed security, they probably will not.
3. AT&T and Comcast (as an example because their home automation & security service is widely deployed in the US) may not open up access to devices their systems control in their IOS apps however consumer apps for Philips Hue or NetAtmo using HomeKit would probably allow access. Do you think the likes of Philips Hue or NetAtmo would be ok with that? Or would be their policy controls in place during app approval or access controls allowing some degree of control to Philips and NetAtmo as an example?
4. HomeKit will have complex scripting capabilities – going beyond what IFTTT can do. HomeKit possibly solves the software challenge much better than Revolv with its consolidated app for controlling many things through its hardware (in reality controlling the Wi-Fi or Ethernet connected devices such as Philips Hue or Sonos does not require their hardware/gateway). What role do companies like IFTTT (from a HomeAutomation perspective only, not the many other functions it provides. IFTTT has simple if-then rules only today operating through the latency of an internet connection) or Revolv play with HomeKit? Did Apple disintermediate the likes of IFTTT for Home Automation and Revolv?