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?
1. HomeKit is positioned very well to solve the the “App Fragmentation” problem on the IOS device – it is a framework that will enable having an application that can control multiple Home Automation devices through a single User Interface. The foundational premise of HomeKit for solving the challenge is to have a common database, and a common taxonomy. Apps using HomeKit will store the information related to the Home Automation devices (or Accessories as Apple calls them) in common database locally on the IOS device. Apple is enabling developers to go after the really hard part of having the best user experience of using home automation by coming up with HomeKit.
2. Apple with its HomeKit has defined a common language and hierarchy to discover, define, and communicate with devices – or what are called “Accessories” in the Apple parlance. The root of the hierarchy starts with the “Home”, then works its way down to the “Room” and to “Accessory”. Accessory is the “thing” – the lamp or the switch that controls the lamp – and it has characteristics. There are ’services’ associated with Accessories.
3. Zones, Scenes, and Service Groups can be created.
4. HomeKit supports APIs for discovering, pairing, and organizing accessories, and associated actions with them using the extensive, but simple to use HomeKit framework. Accessories, and services to an extent can be assigned names – and here is the interesting part – because they have ‘names’ – Siri can be leveraged. Xcode will support a simulator that would mimic accessories supporting the HomeKit protocol – allowing developers to get started.
5. Common accessories such as Garage Door Openers, Lights are defined and to open up the eco-system – both Custom Accessories and Custom Services can be defined by manufacturers and partners.
6. There is “HomeKit” protocol defined between the IOS device and the Accessory (or the thing/device). The APIs on the HomeKit leverage this protocol to communicate with the accessory.
7. While no specific mention of ZigBee or Z-Wave was made, non-HomeKit accessories or things will be supported using the notion of a “bridge” [for example the Philips Hue bridge, whose functioning I covered here]. The bridge would be a device or piece of software that can translate between the HomeKit protocol and whatever is on the other side.
8. My guess is that ‘licensing’ the HomeKit protocol is covered under the MFi program (just as AirPlay is Apple-licensed protocol).
Pew Research Center recently released a report titled The Internet of Things Will Thrive By 2025. This was, obviously, picked up by many news and blog sites. Washington Post’s Mohana Ravindranath wrote about it in a post titled “Some see possible drawbacks in ‘Internet of Things’”, and provides a good summary. The post has one typo – it claims 1,900 people responded, whereas actually of the 12,000 people canvassed 1,606 responded. He has summarized inputs fromVint Cerf, Andrew Bridges, John Senall and Miguel Alcaine. Mohana has captured good set of quotes from one of the authors of the report – Lee Rainie, director of Pew’s Internet & American Life Project. Wired has good summary of the report as well.
Scot Stelter over at RFID Journal mentions the report but points out the lack of coverage in that report with respect to RFID, his post (RFID Stakeholders Need to Prepare for the Internet of Things) has good insight into how RFID will be important, and professionals in the RFID field need to be prepared for IoT.
Last week was the week before Apple’s WWDC – and lot of speculation on how Apple is going to play in Home Automation and IoT started out by Financial Times in Apple seeks to work Jobs magic on the internet of things (paywall). GIgaOm’s Stacey Higginbotham explains it well in Here’s how Apple’s smart home program will work. EETimes in “Apple’s IoT ‘Good Housekeeping’ Label: MFi “ gets into a little bit more detail and indicate that it involves around the MFi program (just as Stacey’s post) but indicate that it would support ZigBee protocol as well. Roger Kay at Forbes jumped in with “Will Apple Play Nice On The Internet Of Things?“. Roger makes the case that Apple won’t be in a position to dominate unlike the Smartphone or Tablet segment. While I agree with that analysis, Apple may continue to influence and benefit because Smartphones & Tablets will be an integral part of most IoT solutions.
The Economist gets into the over-hype around IoT – a very nice and thought provoking article titled The internet of nothings. It covers the chart put together by ZDNet on showing the surge in Google search aassociated with IoT, how the acquisition of Nest marks a tipping point. Two interesting observations:
#1. The post points out the real challenge is connecting the Cloud and the Node (Sensor or Actuator):
Devising sensors and algorithms to handle the front- and back-ends of the IoT are the easy part. Unfortunately, few developers are tackling the really difficult bit in the middle—the myriad infrastructural gaps that lie between the sensors in things at the edge of the internet, and the data collection and analysis performed by servers in the cloud at the centre.
#2. It questions the numbers being published (on number of connected devices) especially claims being made by Cisco:
…while Cisco Systems, a network-equipment firm in California, expects there to be no fewer than 50 billion. Cisco is so enamoured of the IoT that it has installed a “connections counter” on its website. On May 26th, the number of “things” connected to the internet was over 12.4 billion and counting.
The vast majority of the billions of things connected to the internet on Cisco’s website, for instance, are not the toasters, refrigerators, thermostats, smoke detectors, pace-makers and insulin pumps that the IoT’s true believers enthuse about. Almost exclusively, they are existing smartphones, tablets, computers and routers, plus a surprising number of industrial components used to beam performance statistics back to corporate headquarters.
Talking about Google, Business Insider is covering its rumor to buy DropCam (originally reported by The Information). It is probably pure speculation but if it bears fruit – Google could be really powerful in combining Dropcam, Nest, and Android (and YouTube/GoogleTV/Chromecast in the living room) and bringing order to Home Automation & Monitoring. Dropcam cameras have motion detection, Nest has a proximity sensor and between the two they could make for a solid, self-managed security system as well.
This week’s links also has a story with a cliche headline “With ‘Internet of Things,’ your fridge will know when milk is low“. This resulted in an interesting exchange on Twitter which you can read here. The blog post title is misleading because the focus is more on security. It has been distributed over many different websites – for example you can find it here and here.
Intel, Qualcomm and Freescale are three semiconductor companies that tend to show up in IoT Articles. This week I came across a post by Lee Schafer that starts off going over the Texas Instruments Launchpad:
On the Texas Instruments eStore it takes only $19.99 to jump into “the Internet of things” by purchasing a Connected LaunchPad unit to bring an everyday device onto the Internet. Better be patient, however, because they are sold out.
Finally a post on Wired is definitely worth reading - ‘Beautiful mistakes’ will form groundwork for the internet of things. The essence of the post:
Similarly, it will take user-generated products and hacked physical connections for brands to make sense of the internet of things. It will be ugly, soldered-together networked devices (not the gamified toothbrush) that will light the way for them. Beautiful mistakes and unexpected outcomes that will form their strategies.