What if all household appliances, tools, devices, and equipment came with only an internet-enabled interface? This would allow all controls to be customized to suit their users’ tastes. If a user was blind, the interface would be customized to include a braille keypad; if a user was of limited cognitive ability, the interface would be customized to be used only with a subset of available features, without exposing all of the device’s functionality (something like the Jitterbug phone). Likewise, if a user was picky about font styles or UI aesthetics, the user would be able to customize the interface to their preference.
Perhaps a physical switch would make managing these settings a lot easier. To accomplish this, I hit upon the idea of a “language” for customizing UI design, which does the following:
1. Hook up a control (e.g., smartphone app, a physical switch, or a sliding control on the wall) to a “feature” of a given device. An example would be using the “language” to specify that a particular switch is going to control a specific device. The nature and functionality of the switch is at the user’s own choosing.
2. Perform complex networked operations to control devices. For example, use the output of a “clock” device, coupled with the latest weather report from a smartphone, to control the lawn sprinklers in someone’s yard. Why should the lawn sprinkler have its own sensors? Moreover, if the sprinkler turns itself on every day at 5:00am, there’s no way for it to predict that it’s highly likely to rain that evening. The sprinkler would thereby save water by not turning itself on. Future appliances and gadgets may come with no UI at all (but for an internet connection). Why should the oven control be right on the oven? What if someone prefers a “kitchen console” to control all kitchen appliances, or if someone else would rather do all of it with just their iPad?
3. Pay attention to safety and security. Let’s say the home oven has no physical “OFF” switch (because someone customized it this way). However, when there’s liquid boiling over, requiring someone in the kitchen access to an “OFF” switch is a must for safety. What if the iPad that controls it all runs out of charge? The gadget design language compiler must not allow this, but instead must provide the controls designer with an “error message.” Also, the security of the system should be foolproof, because outsiders must not be allowed to snoop into homes through, for example, access to an internal camera monitoring system.
To bring this idea to life, I experimented with one of the most ubiquitous household appliances, the light bulb. In its current state, the Philips Hue light bulb, which has no UI except a smartphone app, has several noticeable problems. For one thing, there is no way to store a custom intensity and hue setting for a given light bulb. Each time the light switch is turned off, the user must sift through a “color chooser” to pick their preferred color again. Though a dimmer switch for the Hue already exists, it is limited to only changing the intensity of light—not accommodating the variation of colors or interfaces to suit a particular user.
Along with the Philips Hue, I am using a Raspberry Pi, which is a full-fledged computer smaller than a deck of cards that provides HD output to a TV Set. It is based on a Broadcom ARM (Advanced Reduced Instruction Set [RISC] Machine) architecture chip running at 900 MHz. A standard keyboard and mouse can be plugged into two of four of the Pi’s USB ports. The Pi (pictured) has a WiFi dongle plugged into another USB port. The Raspberry Pi runs the Raspbian operating system, a version of the Linux Debian distribution compiled for the Pi’s processor. The Pi comes with 1 GB of random access memory (RAM) and a micro-SD slot into which is plugged in an 8 GB card.
The Raspberry Pi has physical sensors that can control and detect the states of its General Purpose Input/Output (GPIO) pins. It is unique because it is the only general purpose computer with this capability that can run Linux.A Philips Hue light bulb pictured with the RaspHueTin:
After studying the API of the Philips Hue, I used the Raspberry Pi to write a Python program that communicates with the hub of the Hue over WiFi.
The Hue uses a RESTful interface that communicates using HTTP verbs. The Python program utilizes the JSON objects specified by the Hue API. The state of the Hue is queried by the “GET” verb and changed by the “PUT” verb, as demonstrated below:
In my prototype, known as RaspHueTin, I use a switch that allows the light to be turned on and off and a potentiometer that changes the color of the light. The assignment of each analog feature to its designated function is arbitrary, of course; if someone wanted either side of the switch to represent two different colors, or perhaps the potentiometer to represent a gradient of intensities, that could be done as well. In addition, the interfaces could be customized to fit the needs of people with physical or cognitive disabilities. An analog to digital converter called the ADC V2 is required to convert the analog signals from the potentiometer into digital inputs for the Raspberry Pi.
The following video includes a demonstration of how RaspHueTin manipulates the Philips Hue, as well as how the Hue could be customized to suit a video gamer’s backlighting preferences: