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:
- Reporting
- Actuating
- State Changing
- Receiving Commands
- Coordinating
When it comes to reporting, this is the basic necessity of a device. Can it provide feedback on its usage or some other sensor data? Basic functionality should be:
- Acquiring data
- Storing information
- Sending information
- Confirming information
For the product designer, there are a number of considerations that they’ll need to take into account:
- 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?
For basic reporting, it might involve receiving a query from a server and reporting back the last setting of the device.
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
The handshaking is important to ensure that the action isn’t double performed. Usually, people make Internet connected devices to do something rather than just report, so actuation is the next logical step for a device.
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
When devices can do this, they can then start to learn about us and be managed without us needing to create rote rules for them to follow.
We can look at home for a few devices that can ascend the levels of IoT interaction.
Light Bulb
The first step for a light bulb would be to report when its on or off. Should it report when a setting is changed as well? Is there an app that will control the light remotely? In terms of state change, can the light be dimmed? Can it change colors?
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
Internet-connected wall plugs make the ascension first by reporting their state, like on or off, or sensor data, like power consumption. Then, can the plug be turned on or off through an app? An API would then be very useful for allowing a web service to either get usage data or turning the lights off because of other events.
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
A basic functionality of an Internet connected lock would be to report if the device is locked or unlocked. Ideally, these devices are designed to be remotely locked or unlocked, such as through an app, or opening an API to report the status of the device. Adding a new state could include the ability to warm the lock or knob if it’s cold, reporting if the door is ajar or closed, or even the proximity of people to the 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
Simple reporting of what song is playing is the first step for a connected speaker (think of FM radios that first had this capability). The next step, actuation, is to be able to pause, play, and fast forward/rewind via Internet remote. Changing state would include being able to stream music from multiple sources directly to the speaker.
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
Those looking to take their device to the next level should ask themselves these questions when designing their product:
- 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?
Making devices that ascend to new levels of interactions will mean much more exciting devices for us to use in our homes – and a more exciting future.
New Episode
Latest IoT News
