How To Level Up Your IoT Device

Six years ago, before we came up with the Ubi, we were working on another device. It was a WiFi actuated wall plug that we wanted to call Peach Plug. We came up with the name by testing various names through AdWords (Pepper Plug, Salsa Plug, and others came in far after).

We had planned to launch it on Kickstarter as a very unique product but were beaten to the punch when another company launched one just before us. Two weeks into their campaign, however, Belkin came out with the WeMo and it took the wind out of the campaign's sales.

We went back to the drawing board to look at other branches of our product roadmap to see what other directions we could take. Since this was a plug, we figured - why not also add a microphone so that someone could command it through voice. While working on speaker details, it dawned on us that since the device was Internet-connected, if we could also add a speaker, the number of Applications and possibilities would sky rocket. It was a simple feature that ended up creating explosive and unique interactions and a new category of product.

The process that we went through with the Ubi is one that other IoT device makers can go through in order to assess the possibilities of their product. Essentially, it's a way to figure out what is needed to get their product to "level up". IoT devices can ascend through five levels of usefulness:

1. Reporting
2. Actuating
3. State Changing
4. Receiving Commands
5. Coordinating

• Acquiring data
• Storing information
• Sending information
• Confirming information

• How much information can be stored on the device?
• Should the information be sent in real time or batched?
• At what point does the device write over its store?
• When should a device report its data?
• Should the device report to a hub through some non-IP protocol or directly to the server?
• Should the device receive some confirmation that the data was recorded before writing over it?

Reporting is the basic necessity of an Internet connected device, but what happens next? ... Actuation - when the device is controlling something. The process of actuation involves:

• Receiving data
• Understanding the data
• Performing the action
• Reporting that the action is being performed
• Verifying that the action was completed
• Reporting back that the action was completed
• Receiving a confirmation of the report

Once a device can be actuated remotely, the next level is the allowing for third parties to be able to actuate the device. This usually means creating an API and some documentation to create.

An API could be used to allow third parties to subscribe to sensor data or control different actuators of a device. Some or all of the reporting features may be extended to these third parties but it's important to allow end users the ability to easily control who has access to their devices to prevent a "too many cooks" issue and losing track of who has what access.

Devices can ascend further by looking at adding features that are tangential to the main functionality. In plain terms, this means being able to actuate different things than the main purpose of the device.

Being able to turn the device itself on and off or being able to also change color vs just brightness are examples of state changes, as is mute vs unmute. It is possible that some devices may never have to evolve to this level as it doesn't fit their intended purpose, but this is for those that are looking to expand to more functionality.

Changing state requires the devices have some ability to process multiple actuation requests and also remember its state if the device loses power or connectivity. The ability to change state can increase the likelihood of a device maker finding the "killer app" for their product.

The last level a device can ascend to is the ability to coordinate autonomously with other devices. To do this means:

• The device has to have some intelligence built into it to discover and understand the devices around it
• It must have the ability to communicate with these devices directly
• It should receive commands from other devices

We can look at home for a few devices that can ascend the levels of IoT interaction.

Light Bulb

The device maker should also ask whether other services should be able to control it via an API. Lastly, should it be controllable by other devices? Can it coordinate automatically based on what's happening in its environment?

Wall Plug

Related to state change, can the voltage output be varied? What new applications could that open up?

For coordination, can the device be paired with other plugs so that if one changes from on to off, they all change? Can their power output be mirrored in some way?

Lock

Coordination could include sending a request to a nearby camera to snap a picture when someone enters through the door, playing music when the door is unlocked, having a master setup with multiple locks, or even unlocking based on geofence to a phone.

Music Speakers

Here, the API level is reversed - being able to let third party services stream to a speaker is a big step forward. Lastly, coordinating between multiple speakers or allowing devices to change the music or playlist would the highest level for these devices.  Of course, adding voice interaction completely changes the device.

Lessons for IoT Device Makers

• How much data will I need to collect? Will collecting this data add a lot of value?
• What should I allow users to control? What's the expected interaction?
• What additional features can I add to the device that will exponentially increase what can be done with the product?
• What benefit will be derived by opening up my device to third parties to control?
• What coordination can other devices have with mine to create unique experiences?