Tuesday, March 18, 2008

Sensor network bridge

So I've got all these little wireless gadgets...low datarate things like thermometers and humidity sensors. Maybe motion detectors or something goofy like that. Probably connected by Zigbee or some proprietary standard. It's not really viable to have those directly connected to the Internet. To do that you'd have to have cellular or WLAN or something else involving a nontrivial network stack.

So we make a box that works like your Kindle. It's on the Internet, and you don't care how. It's transparent. That box acts as a bridge to your low-power, low-datarate wireless network. So at the other end of that box's 'net connection is a server, which could well be EC2-based. That server provides a few things. The first is a web-based interface to your net. You can look at information real-time, or send stuff. Whatever. The second is a logging function, with pay-by-the-byte storage. Basically subletting your S3 space. The third is an API that allows you to send data from your PC to your devices via the 'net so that you can write your own apps. The last is a driver that runs on the PC and abstracts the API, presenting it as a series of virtual serial ports on your PC. This is for folks who don't even want to bother writing software to talk to the 'net. They'd rather just talk to a "serial port". You could also use a terminal program like HyperTerm to chat with your devices.

...And there's no reason you couldn't do the same thing with WLAN and leverage some existing site infrastructure. The only problem there is that there'd be some configuration of the bridge because there's no real standard for self-configuration of WLAN. I mean, you could search for any open access point and try to grab an IP from it, but that's a long shot. The beauty of the other bridge is that it's basically a box with a power hole that you put somewhere central. There's a power LED and that's it. No UI whatsoever. Since it's transparently connected to the server, all configuration happens through that route...you get a control panel through the main server that configures your box.

Another idea: have a sandbox controller on the thing that allows the system to act locally as well. Say you have an RFID reader and a light switch. One could talk to the other through the hub without intervention via the net. You could download micro code via the main server.

And another...rather than being tied to a particular wireless technology, just have a hole in the bridge that allows you to plug in a Zigbee, Wibree, Bluetooth, Cypress, or Nordic radio module, all of which would be abstracted to use a common interface. Worst case the radio module would have to have an EEPROM on it that has special code that gets loaded into the bridge at runtime. Well, boot time.