So I'm browsing for new technology items and I come across this
link about the Zigbee protocol. This has me interested. Yet another variant of 802.x, this time 802.15.4. It's another standard like Bluetooth and the soon-to-be-released Ultra WideBand (supposed to be USB unplugged). Of course, that just makes it yet another wireless standard. Its claim to fame is inexpensive hardware, low power consumption, low data-rate, and security. They claim incredibly long battery life -- up to 1000 days! This is mostly due to the ability of the devices to sleep most of the time if necessary.
Many devices will use Zigbee for monitoring purposes. Imagine your utility meters, a pacemaker, a parking meter, or vending machines that can send status information or ask for help. Zigbee also shines in range (matching WiFi's ~100 feet) and network topology (dynamic star and mesh networks of over 65,000 nodes!). Data rate is low at 250kbps but what do you need for control?
The thing about this, is it still seems to be a step away from an idea I've had brewing for a few years now. We already have low bandwidth, relatively low power with Bluetooth. Battery power is closer to a week, but all these numbers are so dependant on usage. My idea sits a layer above the transport layer. What I propose is an HTML-like interface standard for control. As you come into range of a device, not only can your controller detect the device, it can download a user interface. Just as accessing any web site provides you with the organization's "user interface" in the form of the web content itself, the device could expose a simple layout of buttons, sliders, checkboxes, and display labels. This would use compact markup tags to enable an interface to be transmitted in ~5k. The controller device could cache the interface by default, rolling off least frequently used ones as memory needs dictate. Imagine walking in front of your home stereo, and your controller displays a list of controllable devices: DVD player, TV, tuner, CD jukebox. Select one from the list and its device-specific interface appears. It would be very light on bitmap graphics, maybe limited to 1k each, primarily used for logos. Then you not only control, but get flexible feedback. The screen could be touch-sensitive, with several hard buttons for returning to the device list, device controller menu, whatever else.
The beauty of the portable UI isn't just the convenience of dynamic discovery and customized interface (though that is much of it), but the power-to-the-user that it enables. Most devices that are small suffer from poor interface design by neccesity. Think of your alarm clock (or mine anyway). I have a clock radio with environment sounds (never use that feature). The stupid thing has at least 12 buttons on it, plus several multi-position switches and the tuner and volume dials. The only display it has is the clock display, and the labels on the switches themselves. Imagine how a web designer would create an interface to that clock. You could easily imagine multiple alarm time settings, each with a different alarm choice (radio, buzz, nature sound) and volume. It's not practical to do that now because it would be too clumsy and confusing to use. If adding a complex user interface/display was a matter of adding a $5-$8 chipset, you could see all sorts of devices exposing these interfaces. Your furnace could provide full diagnostics with intuitive controls, as could your hot water heater or refrigerator. You could also have smart real-estate signs in front yards that transmit pictures and house info as you drive up. I've seen small-range radio transmitting real-estate signs, but this would be much more powerful than pre-recorded audio.
Taking it yet further, devices could stop implementing interfaces at all and simply be logic units with a transmitter attached. The alarm clock only needs to display the time. Any other function could be exposed wirelessly. Your thermostat could be a hidden temperature sensor. Why provide displays and buttons on such devices at all? Some of the wireless cost could even be offset this way. Picture a controller device built into wrist band (just a thought!). Your pager and cell phone in your pocket, your iPod, your car even could send information to your wrist band allowing further shrinkage in size. Why have displays on every device? Sure your digital camera may need a display for viewfinding, but why not review the images on the controller while the camera sits in your bag? This controller could easily be a stand-alone device, or software-based running on a PDA or PC/laptop. Units could differentiate themselves by color vs. mono, LCD vs. OLED's vs. e-Ink for visual and power-consuming differences. I would love a single unit that could control all of these devices while allowing the actual devices to be simplified.
Security could be accomplished through the use of hardware ID's in the controller being bound to the device, or leaving the device open depending on need. This would prevent walk-by hijacking of private devices. I think the possibilities that exist when the interface and display are externalized are truly staggering. If anyone has any thoughts or comments I'd love to hear them!
Of course this idea would work regardless of transport protocol, working just fine even with WiFi, but it would probably be overkill. Zigbee would be a good choice due to low batter consumption, but Bluetooth would work fine too probably. So many wireless protocols!
posted @ Monday, March 14, 2005 11:27 PM