Smartest House

iBeacons for Home Automation

My home automation system has been able to reliably understand which rooms are occupied for many years through a combination of many different sensors: PIR, strain-gauges under the floor, IR remote control sensing, door contacts, PBX extension usage, light switches, … and some limited reasoning. But it doesn’t know WHO is in a given room.

I have tried figuring out who is home by continually scanning the local network to see what devices have connected and I have a dashboard that shows every device that ever connects to the home network and when it was connected. It also happens to track visitors if they connect to the guest wifi. This has proven useful for finding devices: “Well, you had your iPod with you when you came home at 5PM and it’s still in the house somewhere”, but it’s not 100% reliable (sometimes pings aren’t answered and it assumes a device has gone away) and it can’t locate any more precisely than “Somewhere in the house or barn” (The barn is half a mile away but via a 900Mhz link is on the same subnet).

So, the next logical step was to give it that capability and iBeacon technology seemed like a good option to achieve that. Since we all carry cell phones almost 100% of the time we already have a personally identifiable iBeacon receiver with us most of the time. If I just mount enough iBeacons around the living areas I can tell who is home and perhaps even which room they are in.

So tonight I added code to my Xamarin home automation app for smartphones to detect iBeacons and to report back to the home automation system (via HTTP POST) whenever a phone enters or leaves the area covered by the beacons. I also added a couple of geo-fenced areas for good measure and code to report when it starts seeing any individual beacon.

On iOS this works in the background even when the app is not running which is great and I was hoping that this would allow the home automation system to know reliably whether I am home, at the barn, in the kitchen or in my office. I started with three beacons from Estimote, added another three from Sensoro and have another 12 on order.

Figuring out where to place the iBeacons and how strong to set their signal strength is probably worth a blog post of its own. The folks at suggested a couple of articles with some good advice on iBeacon placement: &  and I’ve been trying various locations and signal strengths to see what works.

One of the challenges for iBeacons within a house is that the signal travels vertically just as easily as it does horizontally and thus the room above the kitchen is as close to the beacon in the kitchen as anywhere else in the kitchen itself. This leads me to think that maybe I need to place beacons near the floor of the basement and the ceiling of the upstairs and then try to intersect the ‘spheres’ of coverage that each provides in order to get a precise fix on which floor you are on.

I may also be able to use the other motion sensors to disambiguate which floor you are on but that’s going to be a much more complex programming exercise and will be part of the machine learning project I’m planning.

The other beacons I’ve ordered are from a variety of manufacturers, some with AAA batteries, some USB, others coin-cell powered. I’ll blog again when I’ve had a chance to test them.

What I’d really like would be iBeacons with directional antennae. If you could buy ones with different patterns: half-sphere, corner, … it would be easier to create a system capable of precise location within a home.

BUT, and it’s a fairly large BUT, it turns out that in the background the iPhone only checks about once every 15 minutes for zone entry/exit status. This makes it totally useless as a real-time sensor for which room you are in. It also eliminates many of the other scenarios for which I was hoping to use iBeacons. If the app is running and in the foreground it can sense beacons but that’s a far smaller use case than I had planned.

Given this limitation I could still location-enable my iOS App for use-cases where the app is in the foreground. For example, you could maybe type “play 90’s” or “thermostat 70F” without having to specify a location. But this is a lot less than I had hoped for.

I’m also going to look at using iBeacons “in reverse” by placing them on moving objects (cars, backpacks, …) and having a fixed receiver (not using iOS) that is continually scanning for them and reporting their position. This will overcome the 15 minute issue but it’s not going to be able to track cell phones within the house. For that it looks like I will need a Bluetooth or GSM sniffer.

The Internet of Hubs (and things) #iot

Over the past year many large companies have been scrambling to jump on board the so-called ‘Internet of Things’ bandwagon and many small companies have launched new internet connected devices. Sadly, based on my decade plus of experience connecting devices to my home automation system I have to report that there are many misguided ideas going around.

People are promoting ideas that, in the long-run, are either far too simplistic, simply not interesting, or downright annoying. I watch product managers (with no real smarts in their own homes) explaining scenarios that I’ve tried, found to be utterly pointless (either personally or with input from family and friends experiencing them), and have since removed from my home automation system.

My voyage has been motivated not just by trying to figure out what’s possible but equally what features are compelling not just immediately but after months or years of use.

Maybe someone can learn from these comments and we can move more quickly to scenarios that really matter and features that really work in a way that improves lives instead of adding ever more alerts that we don’t need to our already over-interrupted lives.

Here’s my top ten Internet Of Things fallacies:

1) Devices will talk directly to each other.

A typical news story about the internet of things proposes a scenario with one sensor (e.g. a garage door switch) telling one light to come on. In reality the appropriate decision to turn a light on (or off) is far more complex. It might involve multiple occupancy sensors including motion and doors; it might be sensitive to the time of day; it might take into account what state the house is in (party, vacation mode, …); it might even consider how bright it is outside; and it might rely on vast quantities of stored history that are needed for it to learn effectively which lights to turn on in which circumstances. You will instead have one or more hubs that concentrate data from multiple sensors, that store that data, that execute complex rules, and which then control multiple devices.

It isn’t going to be an “internet of things”, more an“internet of hubs talking to things”.

2) One protocol to rule them all

These hubs will often use protocols other than IP to talk to the sensors and they will use wireless technology other than Wifi in order to punch through 1,000 feet of space and walls. In my own home there are at least eight different types of hardware connection including three different wireless frequencies (2.4GHz, 900Mhz and 433Mhz) and even more protocols flowing across them.

Worse, many of these proposed #iot protocol standards have no concept of metadata. We need standards that allow rich metadata for every sensor so that they can be discovered and incorporated into the algorithms that will run our smart houses. Metadata such as the type of sensor, its location, its distance to other nearby sensors and metadata about the home itself (rooms, floors, connections between rooms, audio pathways, visual pathways, …) will be necessary in order to ‘do the right thing’ autonomously and without complex programming.

It’s going to be a polyglot world for a long-time to come and home automation hubs need to communicate over many different protocols.

3) No home will need more than 256 devices.

Yes, amazingly, in 2014 I’ve seen proposals for protocols that allow only 256 devices per home and product managers explaining how this will be sufficient: “Scalable to connect 250+ devices into a single network supporting multiple hops”. 256 devices wasn’t sufficient back in the days of X10 and it still isn’t. Our house is already well beyond 256 devices and the number grows every month.

4) Logic for home automation will be simple If-This-Then-That type logic

Many vendors are claiming that we’ll be programming our houses with simple if-this-then-that type logic. In reality, to do a great job, the logic for even a single light coming in is vastly more complex. Frustration with the home automation software available at the time when I started down this path was precisely because that’s all they could do then. I developed my ‘Sequential Logic Blocks’ technology (akin to Rx but with persistence) to move beyond the simplistic approach. Take the example of a bathroom light: the logic that decides it should come on involves the sensors in the room next to it, the door sensor, the motion sensors in it, the light level outside and the time of day. And it doesn’t just come on, it comes on at a brightness level that’s time of day appropriate because nobody wants to be blinded by a light at 100% in the middle of the night.

5) All the logic can live in the cloud

In reality, when you open a door you expect the light to come on within 100ms. Anything more than that is noticeable. If all sensor data is sent to the cloud and then the signal is sent back you are already into the realm of ‘this feels slow’. I’ve upgraded my home automation server three times over the years and finally have a responsive system running on a Core-i7 Intel NUC.

6) No need to store data, just compute it using data-flow approaches (with no persistence)

In reality, to do a great job the home needs a lot of historical data, not just days or weeks, but months or years worth of data. Only with this volume of data can we start to use machine learning to learn all the possible scenarios that can occur and how the house needs to adjust its behavior. Even after 10 years I’m finding new scenarios that create unexpected behavior – like the arrival of our new puppy and 3AM trips to the garden.

7) All the data can live in the cloud

Maybe some day this will be true, but today this would be cost prohibitive even for the data I’m accumulating today. Monthly storage costs for the data I already have would be >$20/month, and that’s S3 pricing not some indexed, NO-SQL database in the cloud. And, even when you do have all the data in the cloud, you will still need to store recent state locally to allow rapid decisions (see #5).

8) Users will program their homes at all

Home Automation has always been a hobbyist, hacker -type activity. If the installation involves coding (even fairly simple coding), then most people are not going to do it.

What’s needed instead is vastly more complex algorithms using machine learning that can produce the desired results with relatively little user input.

9) Your house will alert you constantly to what’s happening

I saw a video recently where the house speaks the weather when you open a cupboard door in the kitchen. This is one of the many ‘alert’ or ‘notification’ scenarios I see vendors touting all the time and it honestly isn’t very interesting, in fact, it’s really rather annoying. There are also countless Kickstarter projects that will notify your smartphone when a garage door opens or such-like.

I’ve tried announcements like this, and notifications for simple events, and after a while they have all been turned off. a) Announcing the weather in detail isn’t interesting most days – my house might explain the weather as “same as yesterday” which is all you need to know; b) If the weather is the same as yesterday you really don’t need to know; c) Other people will open the cupboard door and be surprised by this announcement (cleaners, visitors, …).

The ideal home automation system only alerts you when something unusual happens and to do that it needs historical data and smarter logic.

10) Bleeping, binging or other noises are suitable alerts

No, no and no. The ideal alert noise is a noise that you will recognize but that your friends wouldn’t even hear if they were over. A subtle bird tweeting, an owl hooting, or no sound at all, just a glanceable RGB LED projecting onto a wall are all better ways to communicate alerts.

The ideal home automation system will blend into the fabric of the house itself giving subtle cues without adding to the ‘notification-noise’ already drowning out our thoughts.

So that’s my top ten. There’s a lot more detail behind each of these and a lot more ideas for what home automation systems need to look like to be successful. There are also many anecdotes to tell along the way, like the time Google crawled my house and turned every light on and off, one-by-one.

I’ve had the opportunity to consult with at least one of the largest consumer electronics companies on the world on this topic, I have a data-sharing partnership with some of the top researchers in this field, and I’ve also spoken at some local meetups about my work as I continually strive to improve what I believe is probably the “World’s Smartest House”.

Showing home status with just a single RGB LED

This week I decided to try out the Bluno (Bluetooth + Arduino Uno) and WiDo (WiFi + Arduino Lenardo) modules that I’d ordered from DFRobot.

The Bluno investigation was fairly short-lived: it works as advertised but it cannot scan for Bluetooth devices which is how I was hoping to use it.

Moving on to the WiDo, this is a very cheap way to get an Arduino + WIFI. It worked well despite the rather small on-board WIFI antenna. I added a NeoPixel single RGB LED to it on digital output 6.

After a short while configuring it to scan for SSIDs and connect to my local network I was able to get it calling out to my home automation server using POST requests. I quickly added a new API to report how recently each major area of the house had been occupied (minutes since last triggered) that produces JSON like this:

"first": 1.5860427216666666,
"second": 29.900604178333335,
"basement": 196.46606494,
"barn": 446.73795961333332,
"driveway": 162.16262138333335,
"kitchen": 86.293791955

I quickly found many of the ways the WiDo could hang during Http requests and SSID scanning / joining networks so I plugged one of my Arduino Watchdog boards on top after moving the jumper from the ~10s position to ~40s.

I used the Adafruit library to connect to the server and make the request. Avoiding memory allocations is usually the best approach on a small memory device like this so I have a fixed buffer into which I read the response rather than using `String` or any other class that makes dynamic allocations.

  int count = 0;

  /* Read data until either the connection is closed, or the idle timeout is reached. */
  unsigned long lastRead = millis();
  while (www.connected() && (millis() - lastRead < IDLE_TIMEOUT_MS)) {
    while (www.available()) {
      char c =;
      if (count < responseBufferLength)
        responseBuffer[count++] = c;
      lastRead = millis();

Parsing JSON in Arduino isn’t trivial. There is a library that many people recommend but it takes up a fair amount of RAM and I wanted something simpler so I used my trusty ‘cheat’ parsing code that looks for a string, skips a few characters and then reads a number:

static double getJsonDouble(const char* buffer, const char* name) {
  char* p = strstr(buffer, name) + strlen(name) + 2;
  if (p != NULL) {
    return atof(p);
  return -1;

static int getJsonInt(const char* buffer, const char* name) {
  char* p = strstr(buffer, name) + strlen(name) + 2;
  if (p != NULL) {
    return atoi(p);
  return -1;

Using this it’s easy to get each of the values being passed back from the API call:

     double firstFloor = getJsonDouble((char*)responseBuffer, "\"first\"");

I decided to color the LED with Blue for barn, Green for house and Red for driveway with the brightness fading out the longer it has been since the last trigger. I also blip the LED to off each time any of the values reduces because that indicates it was triggered since last time it was read.

So now, at a glance I can see what’s happening at home: Red = a car came down the drive but nobody is home, Yellow = a car came down the drive and someone is home, Green = someone is home, Blue = Someone is in the barn, White = lots happening, Black = all quiet, nobody around! Based on the brightness I can tell how recently each area was occupied.

Single RGB LED
Overall this one solitary RGB LED conveys quite a lot of information about what’s happening at home. With a quick reconfigure of the SSID and password I had it running on my desk at work. Now I just need to put it in a translucent orb casing to make it look more attractive.

I’m also planning on building a few more to indicate other interesting data about the house, maybe one connected to my traffic alerts, another to my delta-weather reports, … But rather than putting these out on desks as visible orbs I’m planning on putting them in places where they can cast a subtle light onto a wall – i.e. not something a visitor would notice but something we can see as we walk around – a ‘glanceable information source.

A wireless sensor network using Moteino boards

Over the past few months I’ve been experimenting with the Netduino and Arduino as ways to expand the inputs on my home automation system without running more wires off to various corners of the house. An Arduino with Ethernet can have a group of local sensors attached to it which it can process and then POST the sensor values to a REST API on the main home automation computer. The Arduino is, itself, quite remarkable both for the number of inputs it has and for its relatively low cost.

I should also mention the Netduino. I started out with a few of those, hoping that I could keep the whole system in C#. But, sadly my experience was not great as they would simply hang when performing web requests back to the home automation computer. Reluctantly I switched to Arduino and since then all my effort have been on the Arduino platform. Of course, I immediately hit every possible combination of buffer overrun, bad pointer arithmetic, … and other problems you get from writing in a language with no safety checks, but my C++ skills gradually returned. I was delighted to find the `String` class but immediately abandoned it when I realized how critical memory usage was and how much everyone on the Arduino forums hated it.

The Arduino worked great, I have a few with Ethernet shields on them but switched quickly to the Arduino Ethernet which has Ethernet built right in. Sadly it does not have the low-profile ethernet jack that the Netduino has so you need to use extra long stacking headers or a second layer in order to avoid physical collisions.

One Arduino now handles all 1-Wire inputs from the boiler and radiant floor monitoring system, another handles the solar sensor and an external temperature sensor. They run quite reliably, posting updates at regular intervals.

One idea I developed for this was an API where after posting a new value the server responds with three values: Resolution, Minimum Interval and Maximum Interval. The Arduino then adjusts how it sends future updates to respect these new values. This allows the sensor configuration to be changed on the server without deploying new code to the devices. The Resolution and Minimum Interval values throttle the amount of data that is being sent (e.g. 0.5 degree resolution, no more than once a minute) whilst the Maximum Interval is used to make sure every Arduino is still alive even if the sensor isn’t changing value. A fairly simple API but it works well.

      public class SensorResponse
            /// <summary>
            /// Sequence number - increments each time a value is added
            /// </summary>
            public long sequence { get; set; }

            /// <summary>
            /// Minimum interval between calls (seconds)
            /// </summary>
            public double min { get; set; }

            /// <summary>
            /// Max interval between calls (seconds)
            /// </summary>
            public double max { get; set; }

            /// <summary>
            /// Minimum change between calls
            /// </summary>
            public double resolution { get; set; }

Sensor values are stored using VariableWithHistory that I blogged about previously.

Arduino Watchdog

Watchdog PCB for Arduino

This all works well, but I wanted even higher reliability so I set about building a hardware watchdog shield using a 74HC4060 chip and instructions you can find online. This works as follows: within the main loop you need to trigger a given digital output once every few seconds, if you don’t (because the code has hung) then the reset line is brought low automatically and the Arduino reboots. The only snag is that a larger sketch may take too long to upload, so simply disconnect the watchdog shield during development and connect it when it’s time to deploy. I also decided that I wanted a PCB version of this watchdog board so I contracted someone on ODesk to design one for me and it’s now off being manufactured. I added a prototyping area to the board and the necessary connector and resistor for a 1-Wire connection. I have a small initial run coming and if there’s interest I may produce more for sale.

But then my Spark Core devices arrived. These have Wifi on board and an Arduino compatible programming language. The IDE however runs in the cloud and you have a web interface to program them. It took a full evening to get them to work correctly, most of the instructions I followed simply did not work and left the cores flashing one of their many color combinations that mean “not working”. Eventually I connected using Putty and was able to enter my network SSID and passphrase and got them online. But the problems continued – failures to connect to the devices, somewhat annoying UI where the currently selected Core isn’t shown on the main IDE page so it’s easy to push to the wrong core. But the final nail in their coffin was a bug whereby long running HTTP requests simply hang the device (known issue, they are working on it). I haven’t given up on them totally, but for now they are just a toy and aren’t going to be playing any part in the home automation system.

This tiny board houses an Arduino Uno compatible chip and a 433Mhz radio.

This tiny board houses an Arduino Uno compatible chip and a 433Mhz radio.

And then I discovered what may be the best device yet for wireless home automation: The Moteino. This is an Arduino Uno clone but much smaller, with the option for an on-board 433Mhz radio. I ordered some with the RFM69, high powered option and the flash memory chip which brings the price up to $24.95. That’s still a lot cheaper than an Arduino Ethernet or an Arduino Uno with an Ethernet shield. Unlike the WIFI option of the Spark, which has a fairly poor range when using the onboard antenna, this thing, with a small whip antenna (actually just a piece of wire about 6″ long), can reach from one end of our house to the other.

After soldering on the antenna it took just a few minutes to download my first send/receive program and they were soon flashing LEDs happily to each other across the room in perfect sync.

I created a quick ‘Sender’ based on the samples provided. I post sensor data as JSON but create the JSON using sprintf because a full JSON library isn’t realistic for these small devices. But now, instead of posting the data directly to my server it sends it out over the 433Mhz radio to be received by a gateway device that I built. One trick I used to allocate unique device numbers was to use the unique serial number in the Flash chip to create the radio ID number. Of course there’s no guarantee that two won’t collide but the odds are fairly good (for now) and if I do find a collision I’ll adjust the XOR calculation to find one that doesn’t create collisions with the devices I have.

     nodeId = 27;
     for (byte i=0;i<8;i++) 
       nodeId ^= flash.UNIQUEID[i]; 

RFM69HW Arduino

RFM69HW connected to an Arduino Ethernet

The gateway device consists of a RFM69HW module coupled to an Arduino Ethernet. I was going to order an adapter board that could handle the small spacing on the RFM69W module but couldn’t wait for it so I ran solid core wires from each pad down to an Arduino prototyping shield and left the radio module floating above the board suspended by the wires. The only other tricky piece here was that the Ethernet and the radio need to share the Serial Peripheral Interface (SSI). I had to move the Slave Select (SS) from the RFM69W’s normal connection pin (D10) to a different pin and set that new pin in code.

radio.setCS(9);      // Change SS pin if necessary (conflicts with Ethernet)


Other than that the gateway code was very simple, it receives a message from a numbered device and posts the message to the home automation server along with the device number and the received signal strength.

        public string MoteinoGateway(int uid, int rssi, MoteinoStatus status)

I plan to locate the Gateway device in the attic so it has excellent coverage of the whole house and beyond …

Since the range on these is so good I may try adding some sending nodes to our cars. I might even put some extra gateway devices around the place so I can triangulate on signal strength, maybe even put one at the barn and one at work so the house knows exactly when I arrive at each location. And since the device will be mobile it can also begin to collect information as I drive about. Now the house can be aware of where each car is, how much time I spend driving each day, how long it took me to get to work and home, … and many more, potentially interesting things. As always, I don’t know exactly what I’m going to use all this data for but sometimes interesting scenarios just happen!

The home as a user interface

Recently I’ve spent a lot of time thinking about the future of home automation.  There’s a lot of chatter about the internet of things, most of which relates to having lots of sensors reporting data back to servers so you can see what’s happening at home.  That’s all very well, but personally I think that sensors in the home can also act like a gigantic input device.  In effect the sensors you have in your home become a giant keyboard, and as you ‘type’ by simply moving around, opening doors and such like you are providing input to a home automation system that will then act and respond.  The interface of the future isn’t fancy touch-screen keypads in every room, it’s an invisible network of sensors that know you walked upstairs, opened a door, are standing near the fridge etc.

For example, in our house, you don’t look at a screen to find out who called while you were out, instead the mere act of coming home, opening the garage door and then moving into the kitchen triggers an announcement over the speakers telling you that you missed a call while you were out.  You didn’t need to press anything, you didn’t need to look at anything, the house simply responds like a human butler would do and speaks to you at an appropriate time.  The algorithm is actually rather more complex than I implied as it doesn’t blurt it out right away as you stagger through the back door with arm fulls of groceries, instead it waits until you’ve moved around in the kitchen for a while and then it makes the announcement.

Another example is the link between open doors and air conditioning. If you leave a door open to the outside, after five minutes it will warn you and then after a few more it will turn the A/C off.

Yet another example if the warning it issues in the evening if you left the garage doors open.  A simpler system might just repeat an annoying warning over the speakers every half hour after 8PM. My system waits until you are up and moving about before telling you so you get the alert when you are ready to act on it and it never disturbs you while you are sat still watching TV.

The house is the user interface.

A traffic service that answers “which way should I go?”

Which way should I go?  Traffic

Most traffic reports (on the radio or in text message alerts) are fairly useless. Like weather reports they contain lots of irrelevant information that could be eliminated with just a bit of extra context. In fact, most of the information they deliver is completely irrelevant to you as an individual located in one spot and hoping to get to another spot. Furthermore they aren’t actionable – telling me the traffic is slow on SR-520 and on I-90 isn’t interesting unless you can tell me which is the best way to go given where I am now and where I want to be.

So this weekend I added a new feature to the home automation that uses the WSDOT’s excellent traffic feed API to calculate a traffic report just for me. Recently I’ve started driving from the north end of Bellevue to the south end of Sammamish during rush hour. There are two very different paths I can take: SR-520 or I-405 to I-90. If either route has a problem I should take the other. So now I get an XMPP (chat) message from 4PM to 6PM whenever the optimal path changes from one route to the other. It’s the absolute minimum information I need and it’s 100% actionable.

For the moment the calculation is fairly simple, I simply maintain a list of the FlowDataID values along each route and then calculate a total ‘slowness’ factor based on the sum of those segments. If one way is much better than the other it generates an alert. If it goes back to being roughly equal the alert is cleared.

Since the calculation is purely relative (route A vs route B) it’s also fairly immune to day-of-week / school-holidays and other factors that have a significant impact on traffic but no impact on the only actionable decision I need to consider.

One other interesting point from the graph is just how spiked the traffic is on SR-520 compared to I-90.

Programming a smart home with a fluent, domain-specific language

In response to a question I received recently, here is an example of the fluent extensions to C# that my home automation system uses to define how it should behave. In effect this is a domain specific language for modeling home automation behavior as a finite state machine. Note how you can use either a purely declarative sequence or you can use procedural code within a Do() block.

                .Then(Entrance.HallBeam, 30)
                .PulseStretch(10 * 60)      // don't announce it too often - every 10 minutes
                .Do("Garage doors warning", () =>
                if (Garage.GarageDoors.AreAnyOpen)
                    FirstFloor.Kitchen.AllMediaZones.AnnounceString("Excuse me, I think you may want to close the garage doors.");

In many ways this is similar to the Reactive Framework from Microsoft except my work on this predates the availability of Reactive Framework and unlike the Reactive Framework my ‘sequential logic blocks’ include persistence logic so the entire state can be saved to disk (as it is every second). This is important because some transitions in the state machine might be several hours or even days long and you need to be able to restart the system and carry on exactly where you left off.

One key benefit of the declarative approach over the procedural approach is that the declarative approach can explain itself. So, the log entry for a light going on can show that the light was turned on because ‘it was dark’ and ‘we had visitors’ and ‘someone came into the room’. Compared to traditional home automation systems where you either have no logging at all or you have a log of what happened, this kind of logging is invaluable for figuring out what went wrong when the logic gets complicated. So in this example I should have moved the test for Garage.GarageDoors.AreAnyOpen out to a Provided clause which would allow it to be part of the reverse-chain logic explanation.

Partial results can be captured at any point in these logic chains and then reused in other chains because each partial result is itself a Sensor device that implements the full fluent interface.

Ultimately I plan to hook the logging for what happened back up to the NLP engine which will allow users to ask the home ‘Why did you put the driveway light on last night around 9pm?’ and ultimately I plan to allow the logic itself to be defined using natural language.

Holiday Season (Christmas) in our Smart Home

Smart Home lighting for the Christmas Tree

So what does a smart home do at Christmas time?

Well, obviously it controls the Christmas lights, both the ones on the exterior and the ones on the Christmas tree and around the house. The indoor lights come on automatically at dusk and stay on provided the room they are in is occupied. Leave the house and they go off automatically. Walk back in and a strain-gauge under the living room floor detects your arrival and the tree lights and rope lights come right back on. Why waste energy lighting your Christmas tree if nobody can see it and why press light switches if you don’t need to?

The exterior lights come on at dusk and go off around 9PM. During holiday seasons the permanent Christmas lights along the eaves of the house come on automatically too. But the house also understands whether it has visitors. This isn’t something you need to tell it, it just figures it out by counting cars arriving and people coming in through the front door. If the house thinks it has visitors it will leave all the outside and Christmas lights on until the visitors have left. Again, there’s nothing you need to tell it, this is a ‘smart’ home not a ‘dumb’ home, and this is real ‘home automation’ not ‘home control’.

Another change that happens automatically during the holiday season is that the alert for a car coming down the drive changes to a subtle jingle bells sound. Normally the sound is the distant tweeting of birds and it’s played quietly so that visitors don’t even notice it. The residents of course know that there isn’t some bird tweeting outside but that a car is approaching the house. The dogs know the sound too and go running to the door barking. With the change to jingle bells sound the dogs quickly figure that one out too. The only problem is that now, when jingle bells are heard on TV they both run off barking to the front door! If only home automation systems were as easy to train as dogs! The driveway sensor by the way is one of those magnetic detectors buried about 120′ away to the side of the drive. It gives sufficient warning to prepare for a visitor before they even get to the front door.

One final change that happens automatically at this time of year concerns the music system in our house. My home automation software includes multi-channel audio playback through a zoned-audio switch. This allows any one of three sound cards to be connected to any set of speakers in the home. This means you can have exactly the same music playing across a whole floor, or indeed throughout the house, without any lag between rooms. In effect this is a poor man’s Sonos as the cost of each additional source is about $7.50 for a USB sound card plus about $150 for a single zone amplifier. You instruct the music system to play back music either by chatting to it on Instant Messenger (it has its own XMPP address), by emailing it, or by putting an entry on the house’s own Google calendar telling it when to start playback. For example, ‘play songs added this week in office’ would begin playback of any new music added to the system this week. And, the change that happens at this time of year is that the music playback subsystem allows Christmas music to play. That’s right, for the rest of the year, no matter what random selection of music you ask it to play (e.g. every song with the word ‘Bing’ in the title, artist or album) you will not hear any Christmas music. This is one feature iTunes and every other music player should adopt!

Home Automation Top Features

Home lighting

Lighting probably uses more electricity than anything else in your home

Someone recently asked me what the top features are in my home automation system. That’s a tough question, I have several favorites and there are so many features in there already or under development. But, here’s a current list of some of my favorites:

  • Lights turn themselves off automatically – saves 40% on electricity usage
  • Lights turn on ahead of you at night as you walk around
  • Intelligent heating and A/C control (based on actual and expected occupancy, ‘optimum start’, weather forecast and local thermostat control)
  • Monitor house from anywhere, see at a glance what’s happening
  • Play music, news, podcasts, … in any room or zone
  • House speaks: caller ID, alarm clock, reminders, missed calls, weather forecast, … with professional quality ducking of background music
  • Automatic phone book learns the name of everyone who calls
  • Chat interface with natural language control: understands complex sentences like “who called last week on Friday after 4pm”, tells you what’s happening (calls, cars, …)
  • Calendar integration to record what happened and accept future instructions
  • Turn TV down or off remotely (“dinner’s ready” feature)
  • House can sense what’s happening and act accordingly: different behavior for away on vacation, not-occupied, occupied, visitors staying over, party
  • House generates a local, sports-specific weather forecast and alerts when there’s fresh snow, pass closures, really bad traffic
  • House can explain what it did and why it did it
  • Programming features for defining new behavior based on events, times, past history, forecasts, …

Passive Air Conditioning to reduce Energy Consumption

Creative Commons License photo credit: dynamosquito

Technology to heat or cool buildings naturally and without expending huge quantities of energy has existed for thousands of years.  In Iran this ‘badgir’ has a natural cooling system made with mud bricks and Adobe. It uses the air circulation between two towers passing through a dome refreshed by the flow of water into an underground channel named Qanat.

By contrast, typical American home construction affords few opportunities to use nature to help heat or cool the spaces we live in.  Homes here are built with thin walls making them poor insulators and although modern homes are well insulated with fiberglass insulation in the walls and roof spaces that is done primarily to keep the heat in; it provides little thermal inertia and has the unintended consequence of trapping heat in the house during summer months when there is plenty of sunlight streaming through large windows but no way out.  Worse still, in modern construction, windows and doors are kept tightly closed and the building itself is built so tight that it needs a fan to bring in outside air regularly to improve the air quality in the building.  That fan uses energy and runs on a dumb timer, sucking in potentially cold air in winter and hot air in the summer.

Having already reduced my total electricity consumption by over 40% and made inroads in how much gas we use for heating I’ve recently begun to look at how we can reduce the amount of cooling needed to keep our house comfortable in the summer.

Temperature Variation Near Seattle In a location where there is a significant variation between daytime and night time temperatures there ought to be an opportunity to heat or cool a house naturally using free energy from the environment. Here near Seattle for several months each year we have just such an environment as you can see on the graph to the right (click to enlarge). The nighttime lows are currently below 70°F and the daytime highs are well above 70°F.

Since we already have a fan connected up that’s forcing external air into the house why not connect that fan to the home automation system and dispense with the dumb timer that was driving it.  Now the house has control of that fan it can change the time of day when fresh air is brought into the house to use warmer air in winter (around 3PM) and cooler air in summer (around 3AM).  It can also use this fan in conjunction with the air conditioning system.  For example, it knows you are upstairs and that it’s too warm up there tonight, the air conditioning has been running but it’s now past midnight and although it’s still 72 inside it’s dropped below 70 outside.  In this situation it can simply open the external damper, turn on the fan and turn off the air conditioning.  Cool air flows in and the compressor is idle.

All this seems like a good theory but because I’ve only had it installed for a few days it’s too early to say how well it will work.

Passive Cooling - Open The Doors

But what about houses with no circulation fan?  Could we simply use doors and windows to improve comfort and reduce costs by telling the occupants when to open and close them?  Today for example I was up early and it was cool outside so I opened up all the doors to the deck.  The graph below shows what happened: a much bigger temperature drop than the day before even though it’s a much warmer day today overall.  What I failed to do today, however, was to close them at the right time so the early gains in ‘coolness’ were soon offset by the rapidly rising outdoor temperature and before lunch it was already warmer inside than the day before.  But what if the house calculated what to do and told you so that you could do an optimum adjustment to doors and windows to achieve free cooling?

My home automation system tracks the temperature in each zone in the house using an Aprilaire communicating thermostat with RS485.  It can display graphs for any variable or collection of variables using the ASP.NET charting control.  These graphs and experiments like the one this morning are helping me understand the dynamics of our house and figure out the best ways to achieve passive cooling (or heating).