Getting to a Better Internet of Things

I’m going to describe a fantastic new option that solves all the problems I’ve brought up in this series.

Like a magic wand if you touch your implanted security tag to a device, it immediately connects to Skynet where your data now (and in the future) will be available to you via your visual implant.

Sorry. I don’t really have an instant fix.

Apple showed off a neat solution where you tap your iPhone against your Apple TV and they shared passwords, auto-configuring via Bluetooth (BTLE). Despite having both devices, I haven’t seen it in person. Note that it requires a single vendor and a very trusted device.

Using a trusted device and a secondary communication mechanism seem to be a model that will continue: USB has been a way for printers to share WiFi configuration for years.

NFC is also used to do a tap-to-share configuration. WPS configuration involves pressing a button on your device and on your WiFi router, but security issues and lack of market penetration means users won’t use and/or don’t have WPS, even if devices support it.

Bluetooth 4.1 is reported to work in a mesh configuration (allowing devices to pass information along to gateways) and to use home routers as a gateway. [1]

The continuing possibilities of metro area networks make always-available 802.11 devices more interesting. On the other hand, the few current, large-scale deployments often have poor signal inside homes so it isn’t likely to replace cell modems quite yet.

The technology is coming to help solve the problems I’ve described. However, if you are making a device this year, or next, consider your options.

As the Internet of Things intersects more with consumers, engineers need to understand how the choices they make ramify through the whole system. My goal with this series has been to:

1. Describe the problem, describing current options and their major malfunctions: What Marketing Won’t Tell You About the Internet of Things (and What We Can Do About It).
2. Build a way of looking at devices as part of a larger system: IoT System Framework.
3. Create flowcharts for how devices are configured, annotating them with failure points in: How Users (Fail to) Set Up IoT Devices
4. Identify questions to help engineers and designers to determine how the technical choices will affect the product as a whole: Building an IoT System: Weighing the Trade-offs

Understanding how the current systems fail goes a long way to enable us to build better systems in the future.

For now, I think the path forward is by hiring a skilled team that cares about your users. Once you have a team, stress the users as a priority, strive to not make consumers feel dumb.

Finding skilled software engineers is not an easy but I hope the above figure helps you determine which skills you are looking for, maybe gives you some ideas for what to put in the job requirements. Note that I didn’t show hardware, focusing only on the software skills. Hardware (and mechanical) will be critical, especially if you are creating a wearable or other battery- based device.

Don’t expect to find these diverse skills all in one person. It is hard to find this level of breadth. The diversification of computer science means that deeply embedded engineers often have trouble talking to server engineers.

As far as signal processing, processor selection, battery handling, interfaces to peripherals, and optimization goes, I've got those skills down (I did write the book on Making Embedded Systems). However, working with a connected device requires an expansion of skills (or teams). In working on connectivity issues, I've needed to learn

• Javascript, HTML5 (and CSS)
• Server side programming  (i.e. PHP)
• How TCP/IP works and how to use Wireshark (not as trivial as it sounds)

I’m still sadly weak on web-based user interfaces and running the server (I’m easily distracted by bits and bytes so new devices call to me).  I like to learn new things but admit to wanting to kill my little internet-enabled stuffed animal when a vendor suggested that Ajax would have the functionality that I needed, that I should learn it.

You do have some off-the-shelf options.

One interesting one is Electric Imp (802.11 WiFI). They are trying something a little different, more of an integrated solution. The configuration requires a smart phone, which, thinking back to the flow charts in How Users (Fail to) Set Up IoT Devices, limits users. The smart phone application blinks the screen to send the SSID and password to a receiver on the device. It also takes some of the burden from the device developers by creating a device WiFi plus system cloud solution. However, it still requires multiple parts:

• device software (developed in Squirrel, a C-like but not C language)
• monitoring agent on their server (also Squirrel)
• web interface (Ajax, HTML5, CSS).

I love using Electric Imp for hacking together home things, a monitor to see if the stove has been turned off or a way to let loved ones know everything is good.[2]

Using the Electric Imp in a product means letting them store your data working with them to connect users with devices in manufacturing so there are definite tradeoffs. It’s an option, definitely a good prototyping one that lets you get a system up and running quickly.

Then you can determine what you truly need to get a good user experience for your internet enabled fishbowl or BTLE coffee cup: ask your list of questions, understand the tradeoffs and how the details ramify through the system, and, always, expect users to complain.

To summarize:

Making connected devices is pretty easy.

Making connected devices easy is actually quite difficult.

References

[1] http://www.computerworld.com/s/article/9247932/Cloud_savvy_Bluetooth_4.1_to_reach_devices_by_year_end

[2] https://learn.sparkfun.com/tutorials/are-you-okay-widget