When you walk into my utility room, the lights come on. If it’s dark. The latest evolution in my long term project to make my dumb (but very pretty) old house smart is a rules engine. Every time I step in and my way is lighted, my heart leaps a little. It’s a simple thing but it entertains. I’m still getting used to not having to turn the lights off though.
In the utility room and my office, both rooms down in the cellar, the rules are pretty simple: it’s always dark, you always need the lights on. But as I’ve started thinking about rolling these rules out across the rest of the house, I’ve realised things aren’t going to be so simple elsewhere.
Take the living room. Imagine you have a similar rule there: if it’s dark, and someone enters the room, turn on the lights. Great. But then you want to turn the lights down, get cosy and… watch a film. What then? Every time you turn the lights off, the system turns them back on again.
So you start to get into conditionals: if someone turns the light off, leave it off. Then you come in the next night and stub your toe because the lights don’t come on.
Maybe you put it on a timer to reset. Maybe you have a series of programmable ‘mood’ macros that set the rules depending on what you’re doing at the time. The point is not that there aren’t solutions. It’s that they are inevitably complex and need thinking about. They need designing.
Lessons from Santander
Demonstrating points like this in practical terms is part of the reason I started Project Santander, my home automation project, named after the home of the European smart city project run by Telefonica. The home is a good proxy for the city, where these design issues are only magnified.
Instead of having to satisfy my wife and children’s understandable demands for a house that doesn’t frustrate more than automate, imagine having to satisfy a whole city of people. This is the challenge facing the mayor of Santander and the team working with him from Telefonica and the University of Cantabria.
As I’ve highlighted before, the hardware challenges of Project Santander were (relatively) straightforward. I now have nodes around my house collecting temperature, humidity, light level, and presence, and allowing me to control things like the lights above. These nodes are not dissimilar to what’s being used in Santander. Yet they cost me just £10 each and were built entirely from off-the-shelf, open source, hardware and software. In Santander they rolled out 20,000 sensors for just EU1m — their pricing is not an order of magnitude different to mine.
These 20,000 sensors generate relatively little data to transfer and store: when there were 12,000 sensors in the city, they were storing just 5MB of data per day. This makes sense: a temperature reading can be stored as a single byte of data — potentially less. Do the maths:
- 1 byte per reading
- 60/5 = 12 readings per hour = 12 bytes per hour
- 12×24 = 288 readings per day = 288 bytes per day per sensor
- 12,000 x 288 = 3,456,000 bytes per day = 3,375 kbytes per day = 3.29 MB per day
Bear in mind the temperature probably doesn’t change every five minutes. And even if it does, you can do some smart things to store many fewer readings than this, or store them more efficiently. Likewise with humidity, noise level, light, parking space usage. This is what accounts for the fact that many nodes have more than one sensor. This stuff is not particularly ‘big’ data.
So it’s cheap and easy to collect, transmit and store. What’s the challenge?
Making it useful. Making it intuitive. Making it human.
This is a user experience (UX) challenge. A design challenge. And it’s an opportunity that I don’t think that much of the tech community — particularly those with the biggest skills for and focus on user interface design — has yet grasped.