Imp no wimp

Hours after posting on-boarding for real people I ran across the Electric Imp web site.  I hate the architecture, love almost everything else about it, especially the on-boarding.  Take a look:

(Note that the Electric Imp isn’t the thing you see in the video.  That’s just a breakout board.  The Imp is the SD card slotted into the breakout board.  Cool, huh?)

Does it address a lot of my issues with on-boarding?  Absolutely.  Would my on-boarding process change with Electric Imp?  You betcha!  Do I love it?  Hell yes!  Would I use it?  Hell no.  Not in its present form.  Here’s why.

In my original scenario, the hard part was to get the device provisioned to the network.  It needs to know the SSID and password, plus the address of the MQTT broker.  We want it to be dead-simple for the user but it needs to be secure.  I took the approach of a separate guest network dedicated to this function and using WiFi Protected Setup (WPS) to deliver the provisioning data.

The Electric Imp uses an app on your phone to flash the screen into a photo-electric sensor and use the pulses to transmit the data.  Job done.  Drop-dead simple provisioning.

So why would I not use it in its present form?  The biggest reason is it uses the Encrypted-Tunnel Vision architecture.  The Imp will only talk to the vendor’s cloud and that sucks for a lot of reasons:

• You are not the first owner of your device data.  Your vendor gets the data and you get whatever they feel like passing along.
• You have no option to withhold the data from your vendor.  Closely related to the previous bullet, I believe that you should have all the data the device produces and have the option to release some or all of it to the vendor for their use.
• Screw the data, you have no control over actuation of the device!  If one day they have a hiccup or a breach over at Electric Imp (it happened to RSA, you think Imp is immune?) and your devices start cycling on an doff for no apparent reason you have no control and must take them offline.  (Don’t EVER put one in a Chuckie doll!  The name alone should have given you that clue, though.)
• Functionality degrades catastrophically if your Internet access is down and the device can’t contact the Orc Horde Imp Cloud, or you intentionally take them offline.  (See previous bullet.)
• 3rd party participation is gated through the vendor.  The real value of Internet of Things, or any network really, is in connection density.  When any new integration has to go through the vendor, then the only things that get done are those that promise the biggest return on the development investment.
• As much as I like the company, I have to ask…what if it goes away?  All your devices are bricked.
• The data is not signed.  I suppose I’ll have to dedicate a post to this but I’ll sum up briefly.  If you start with the premise that you are the first owner of your data then any second-tier owner who provides valuable incentives in return for the data (rate discounts, enhanced service, etc.) needs to know that the data they receive is authentic and intact.  The encrypted-tunnel back to the Imp Cloud provides this assurance but does so by hiding your own data from you.  Signed data can be validated after it passes through many hands or with the passage of time.
• It’s point-to-point.  P2P doesn’t scale to 50 billion devices, let alone trillions of devices, as easily as pub/sub does.  The differences are readily apparent at a few hundred nodes.  They will be crushingly massive at billions of nodes.
• It’s REST.  Let’s say I have 1,500 smart devices in my home.  Must I really poll the Imp Cloud 1,500 times a second to detect state changes reasonably quickly?  MQTT can scale to tens of thousands of devices and push state changes out in real time.  (Of course the real reason to use MQTT here is because it’s wicked cool and, as we all know, there’s no REST for the wicked.)

So, yeah, I love blinkUp for the on-boarding but to say I’m not fond of the rest of the implementation would be a ginormous understatement.  In a blue-sky brainstorming session, I’d graft the blinkUp provisioning to the front of my on-boarding process.  It replaces the guest network and WPS.  If there’s no option for user-defined fields, then I’d want to tweak blinkUp to also pass the address of my MQTT broker.

All the rest would be the same.  The device would still operate over MQTT, still publish its metadata on connection or power-up, still talk locally, etc.

Does this mean I’d ditch the on-boarding from the previous post?  No way.  Depending on the cost and nature of the device, we’ll need a variety of means by which to get it on the network.  Some we’ll just plug in on a hard line.  Some may need more power and stronger signal than Electric Imp can provide.  Some may be so minimalist that Electric Imp is overkill and overpriced for their application.  The key is a clean division between getting the device on the network and what happens once it is connected.  An improved Imp can play in that first space, and I believe do so quite well.  But in that second space local pub/sub seems to me to be a mandatory requirement and the only way to deliver fully on the promise of IoT.  The two combined would be killer.