IoT Device on-boarding for real people

Did your grandmother walk 5 miles to school?  Uphill?  Both ways?

Each generation has their hardship stories.  I remember telling my kids “When I was your age, I had to walk all the way across the living room to change the TV channel.  Uphill.  Both ways.”  My kids might tell their kids “When I was your age our DVRs didn’t tell time.  We had VCRs and it was always 12:00 Midnight.”

Apparently it really was a hardship because the clocks on virtually all the VCRs ever manufactured have blinked 12:00 midnight continuously since the day the VCR was invented.  Well, not continuously.  Everyone tried to set the time on their first VCR.  Some even succeeded.  But even those Mensa candidates gave up after the first few power outages and let the VCR clocks blink.  Often they blinked hidden behind a strip of black duct tape, but blink they did.

So why are the jokes about blinking VCR clocks anachronistic now?  It isn’t because we got rid of the VCR.  It’s because a time signal is fed to the clocks in DVD and DVR boxes though the cable, from a local radio time server or over the Internet.  We relieved the device owner of ever having to set the clock.  This suggests an answer to something that’s been puzzling me for a while now.  Cisco says that 50 billion devices will be online by 2020 whereas the folks at MAYA Design predict trillions of devices.  Why the big disparity?  Perhaps Cisco anticipates we’ll get a lot of the User Interface wrong and MAYA figures we’ll get it right.  Cisco’s version may account for trillions of devices existing but only 50 billion of them successfully connected to the network.

Though a bit tongue-in-cheek, this scenario is depressingly plausible.  So let’s agree to fix that right from the start because without dead-simple on-boarding we have a bunch of really expensive dumb devices.  On-boarding should be the FIRST thing we solve really well in the Cambrian Explosion of IoT.

Here’s my proposal:

User experience on-boarding a new device

  • User signs onto a local web-based dashboard and enters or scans the unique ID of the device.
  • User powers up the device and presses the WPS button on the router.  (Don’t worry, I realize WPS is horribly, horribly broken.  This is covered later)
  • The device is now provisioned locally.  The dashboard is populated with the device details including version, supported behaviors, etc.
  • If there is network connectivity, the dashboard is also populated with vendor information.
  • Depending on the device type, the dashboard may also now display options to send data to the vendor and/or receive data from the vendor.  These options could include graduations in the granularity or types of data and even the ability for the vendor to send control commands for some device types.
  • Depending on device type, the dashboard may offer options to send data to 3rd parties.  For example, a dimmable bulb might offer to participate in discretionary load control by exchanging data with the power company.
  • On the local network, the device publications can be subscribed by any authorized user app or device.

 

Under the covers

Many devices coming to market today require you to first set up a gateway device, then bond the device to the gateway.  Some gateways are severely limited in the number of devices they can host.  Worse, the gateways are proprietary and add considerably to the base cost of a system.  Once you invest $199 for a gateway, you really don’t want to switch to another vendor’s device.  This is not accidental.

In my scenario, the gateway device isn’t vendor specific but just an MQTT app running on the local network.  It can be in a set-top box, game console, NAS drive, PC or whatever. I also require a DHCP server capable of performing port forwarding and a guest network that doesn’t route anywhere.  A standard consumer-grade router like the Linksys WRT-54G is capable of doing most of this today.  It just needs a slight tweak to allow internal port forwarding.

How does the device find the MQTT broker?  There’s a little bit of magic in the provisioning, but not much.  The DHCP server has to be configured to internally route incoming connections on the MQTT port to the IP address of the MQTT broker. This is known as Port Forwarding and is standard on most consumer-grade routers.  Once it is set up, any connection to the router on that port is forwarded to the configured IP address.  For our purposes, the router needs the ability to forward connections on the internal network while blocking those from the external network, or to do both.

From the perspective of the device, it simply acquires a DHCP address in the usual way, then connects to that same address on MQTT port requesting access to the pre-provisioning topic.  The DHCP server is the one local IP address the device will always know so there’s no complex discovery mechanism or exotic protocol required.  The connection is forwarded by the router to the MQTT broker using the port forwarding described earlier.

During the connection, the device provides it’s X.509 certificate as part of the SSL handshake.  The broker matches the identity in the X.509 certificate to the expected identity which the user previously scanned or keyed into the dashboard.  Assuming the two things match, the device is allowed to connect and publish a provisioning request on the pre-provisioning topic.  The message contains a unique random string (nonce).

The dashboard app replies to the request with the SSID and password of the private network, plus the nonce.  This message is signed by the app and encrypted with the public key of the device so it can’t be read if intercepted, and man-in-the-middle, spoofing and replay attacks are prevented.

The device stores the provisioning configuration into memory, disconnects and then reconnects to the private network.  Each time the device connects or powers up, it publishes it’s metadata to the dashboard: device type and ID, vendor, vendor publication and subscription URLs, etc.  These populate the dashboard and activate the options seen by the user.

 

What’s outstanding?

First, we need the routers to perform internal port forwarding.  For proof-of-concept implementations the Tomato or DD-WRT firmware could be modified with this functionality.  If a market emerges, I’d expect Linksys, Netgear and others would add this support.

The other router modification is that WPS is required on the guest network but not the private network.  The guest network is configured so that all traffic addressed to anything but the router goes to the bit bucket.  The only connection the router accepts on the guest network is forwarded to the MQTT broker and that is authenticated with a certificate and Client ID.  So WPS on the guest network is OK because we don’t depend on it for security.  We just like the button that allows a device to connect.  But since WPS is broken, we need it disabled on the private network where we can’t afford for it to be hacked.  The tricky part here is that Tomato and DD-WRT undoubtedly have WPS disabled and may in fact not even have code for it.  I haven’t checked yet but I will.

Obviously, the dashboard is required.  For a POC, this could be as simple as shell scripts.  For the real-world Average Joe user a nice GUI would be expected.  Since all this runs on MQTT, the dashboard could run on anything including Raspberry Pi, Arduino, Roku, X-Box, NAS drive, Plug PC, desktop PC, whatever.

Other than that, it’s mainly a matter of defining the topic schema so devices know how to query for provisioning details.

 

Flexibility

I can hear some of the objections already.  “The user has to set up port forwarding?  An MQTT broker?  Guest and Private networks?”  Not necessarily.  It makes sense that the device vendor would provide basic, free implementations of the dashboard and MQTT broker on their own web site.  If the user can just get the device connected, it can by default publish and subscribe at the vendor’s broker.  Now the question is how does the user connect the device?  Well, there’s no reason the guest network has to be hosted in the user’s router.  It would be simple and easy to sell a cheap consumer router, customized and pre-configured to provide the guest network and WPS.  The user plugs the dedicated router into their existing network and it tells any devices that connect to route all traffic back to its vendor’s web site.

Since you can buy a cheap WI-Fi router for about $50, I’m guessing that would be the price point for the customized version, assuming the vendor didn’t just give it away as a loss leader.  The Philips Hue Bridge adds $20 to the price of 3 LED bulbs but it interacts only with Hue devices and supports no more than 50 of them.  Our customized $50 Wi-Fi router would work with any device using this protocol and support thousands of them.  So, yeah, it’s as much as $50 but then it’s far more functional and you can build on it.

 

User-friendly tiers of functionality

My design goals for the on-boarding were to support unlimited local functionality and 3rd party participation, full user control of the data and who gets what, dead-simple setup, but that all this would degrade gracefully all the way down to a disconnected smart device that still manages to work as you’d expect.

So the degrees of functionality are:

  1. No network:  Device behaves like dumb version of same category device.  Requires nothing of the user.  Plug-and-go.  I didn’t talk about this earlier but it s an assumed requirement.  My house must not blue-screen if the network goes down.  (Although if I had LED bulbs like Hue or LIFX, I’d program them to glow the same shade of blue on fatal errors.  I know, I’m sentimental.)
  2. Custom gateway or Current technology WPS router, no local NAT, no local MQTT broker: Gateway or WPS router connects the device to the network.  Device connects to the vendor who provides additional functionality, web app, phone app, dashboard, etc.
  3. Device finds local MQTT broker, attempts to register, registration fails: Falls back to #2 if device is registered at the vendor’s web site.  The owner receives an exception notice.  If the device is not registered and the vendor does not have an anonymous service (some devices are report-only and would support anonymous publication to the vendor) then the device falls back to #1.
  4. Device finds local MQTT broker, successfully provisions: Bob’s your uncle.

Note that the most the user must do is to run a local MQTT broker and dashboard, then configure their router with port forwarding and activate the guest network feature.  That’s worst case.  It’s comparable to setting up a multi-function printer today and it can only get better because consumer-grade routers will need to change if we are to provision 50 billion devices.  In fact, we should expect to see competing premium versions of the dashboard that provide advanced features.  These could be drop-in replacements for your router or delivered as installable software for your PC, NAS drive, plug computer or whatever.  At some point the anonymous WPS network and port forwarding will be built into the router right out of and enabled the box.

Between these price points will be the customized routers that implement a turnkey guest network with WPS enabled.

The absolute worst-case here is far better than the best case for proprietary gateways that lock you in the vendor’s walled garden.  It is even better than the Philips Hue where the bridge has an open API but supports only 50 devices and uses REST instead of pub/sub.  We have a use case that demands a bit more of the user today but comprised of tasks that can be easily automated so the user’s experience is on par with the clock on their DVR.  Plug and go.

Future generations

We have a 6 year-old in the house.  I don’t know hat hardship story his mom will tell him in a few years.  But if I have my way,  I know what it wont be:  “When I was your age we had to type 50 commands before our devices attached to the network and became smart.  And the keyboard was tilted uphill.  Both ways.”

About T.Rob

Computer security nerd. WebSphere MQ expert. Autist. Advocate. Author. Humanist. Text-based life form. Find me on Facebook, Twitter, G+, or LinkedIn.
This entry was posted in Clue train, PClouds, Tech, VRM and tagged , , , , , , , , , . Bookmark the permalink.

4 Responses to IoT Device on-boarding for real people

  1. Pingback: Imp no wimp | The Odd is Silent

  2. Pingback: It all changes when “things” get APIs | Michael Curry: Information Explosion

  3. A great description of the issues involved in booting the IoT! Here’s a follow-on problem: When everything starts trying to tell you something, how will they compete for attention? When the number of devices in our media centers exploded, intelligent remotes were created, and it was good. Current IoT devices report into some type of console/dashboard app for monitoring & control. The smartphone is probably the best place to currently run consumer console apps, and industrial consoles vary from websites to situation room displays. But the smartphone and web dashboards are only the near-term solutions and future situation awareness will require enhanced analytics and ubiquitous adaptive displays. I’m betting that at some point, my furnace is going to learn out how to communicate an urgent issue to me by changing the color of my shirt. My waffle iron will be pissed that the furnace figured it out first.

    • T.Rob says:

      Good questions. The answer is that much of this should just fade into the background. What I anticipate is that we’ll have the home automation equivalent of “themes” and “profiles.” A theme would correlate events from not just your devices but from anywhere, and translate that into some set of preferred light, sound and other human interface signals. For example, we have a popular bird feeder here at Casa de Wyatt. (Magat gave it f seeds!) We listen to a near constant background of bird calls when the windows are open. But occasionally some rowdy crows or jays show up and cause a commotion. We walk away with the impression that we only have crows at the feeder because we pick out the different sound and go look out the window.

      I’d apply the same principle to event notification. As long as things are going well, then all day long in the house I hear a low level of birds chirping, just as if the windows were open. But I attach the sound of some crows to the “mail arrived” event. Maybe the washer and dryer get the sound of a woodpecker. If a stock I’m watching breaks a threshold, the system triggers a hawk call. If there’s a fire or the water heater bursts, the birds go dead silent and if nobody signs on shortly an alarm sound starts.

      Profiles are more about overall behavior and include things like occupancy detection and individual recognition. There’s a power-save mode for when the house is empty. That’s obvious. But when Aunt Betty who doesn’t hear very well comes to visit, the house adopts a profile just for her. Doorbells and phones trigger visual alerts with flashing lights. Possibly these are in different colors or patterns – the visual equivalent of Distinctive Ring service. If an alarm goes off, the monitoring company is told to alert first responders of a deaf person in the house. A display outside may do the same thing.

      I expect the most popular dashboards will support profiles and themes and that communities will spring up that write and package them. Most of the device interaction isn’t in your phone but rather rules-based behaviors that just happen. Although the rules may be complex, these will be incorporated into themes and profiles just as Windows themes today package up all the arcana of the Windows event API into something a user can just install and then select from a menu.

      This is, of course, just a taste. The possibilities are endless. Example: I expect pay-per-view events to interact with the home. When you sign up for the next MMA fight, you go through the card and check the fighters you are rooting for, then subscribe your rules engine to the PPV broker which downloads the theme and profile. Leading up to the event, you begin to get notifications. Lights flash, sounds fire, etc. During the event when your guy scores or wins, lights all over the house flash and cheers sound. Other guy scores or wins, red lights and boos. The PPV production company supplies custom event messages that drive the rules engine to trigger the behaviors in real time. Their free version sends you the major events (rounds begin and end, wins/losses, etc.) about a minute late and you can program the behaviors yourself.

      Don’t even get me started on social media interaction. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s