I’m putting together an architecture that looks like this:
The application is a smart-home/safe-home system supporting a combination of
- Place basedobjects: primarily sensors, e.g., stovetop monitors, water overflow sensors, etc.,
- Person basedobjects: either prompting/facilitating (flashing lights, feedback tones, vibration) devices, or sensors facilitating a quantified self paradigm (steps, heart rate, blood pressure).
At first glance this architecture looks overly complicated: why have the ZigBee network at all, wouldn’t it be possible to achieve the same result without it, and if so, wouldn’t that be preferable?
ZigBee Sensor Network Advantages
I was driven to this architecture from two directions, first on the ZigBee side: The ZigBee communication fabric is designed for high capacity sensor networks -- in this case high capacity means many sensors, rather than high bandwidth. Considerations included:
- ZigBee is used in the Phillips Hue lighting system -- which can control up to 50 (!) bulbs from a single gateway. Their website contains a paper which discusses potential interference issues, demonstrating how unlikely it is that interference will be an issue in practice
- ZigBee is low power -- the radio can run off of batteries for a “long time” (battery life varies with radio settings). A single radio can report on up to 4 different sensors without requiring an Arduino or other micro controller. This not only increases battery life but also substantially reduces costs (any Arduino is more costly that an XBee radio, and uses substantially more power).
- ZigBee is a self-healing mesh network. The advantage is that each radio only needs to reach another radio that has access to the gateway rather than requiring it to directly reach the gateway. This architecture allowed Digi to build a robust demo system connecting 500 sensors at the Moscone center during Google IO -- you’re not going to get a much worse RF environment than the Moscone center, during Google IO.
- ZigBee is the basis of the projects examined in Building Wireless Sensor Networks , so there’s a well vetted guidebook for getting it up and running.
Once you have the ZigBee sensing network in place, getting the data up to a cloud is straightforward using one of Digi’s gateways (I’m using a ConnectPort X2 at the moment). Digi runs their own cloud service etherios.com geared towards sensor networks. Etherios provides the service at no cost for a small number of gateway nodes -- a nice way to get going and see if your ideas have any traction.
With the sensor data securely stored in a cloud service, caregiver facing applications can access this data via a REST interface.
Smartphone Prompting/Effector Network
Output device connectivity is an area where “smartphones” shine. I currently only work with iPhones, since I’m familiar with iOS development, and the libraries provided for building user interfaces are complete, well tested and constantly improving. Smartphones also provide a rich set of information about the user situation, with GPS, accelerometer data, etc..
Smartphones have become the default target for consumer facing add-on devices as they support bluetooth, wifi and cellular data connections. The net effect is that an iPhone app can use bluetooth to integrate with a sphero robot, and wifi/cellular data to access the data cloud and control Phillips Hue lightbulbs.
In addition, the phone’s GPS and geo fencing capabilities allow checks to be run before leaving the house (stove off, backdoors locked, etc.), making the system potentially attractive to many people, some of whose only “cognitive disability” is having a hectic life.
On a more speculative level, multiple new sensor types are becoming available in the quantified selfspace. There are a number of startups developing tools to track and measure your activities along with associated apps and API’s. I expect this area to evolve rapidly as companies with a track record of developing high quality consumer products acquire these technologies. Just to pick one example: Jawbone recently acquired BodyMedia
Although the functionality->network partition is flexible. It isn’t arbitrary. Low power, sensors requiring reliable, robust transmission will gravitate towards the ZigBee network. The network’s “self healing mesh” topology gives a higher level of assurance and has the advantageous knock-on effect that more nodes increases rather than decreases reliability.
Aside: As I was writing this up, I read an article in the August issue of Computer describing Washington State’s CASAS project, which has similar characteristics