Home Automation

A RESTful API for sensor data

Recently I’ve been expanding my home automation system using Netduino devices that post data back to the main server over HTTP. The advantage of this approach is that I don’t have to run separate wires and each Netduino I add can handle multiple analog, digital and OneWire inputs.

The protocol to post values is very simple: the Uri includes the unique Id of the sensor and the payload is the value. The return value however includes a min frequency, a max frequency and a desired accuracy.  This allows the server to throttle a chatty sensor to send less data by reducing the resolution or by limiting how often it is allowed to send. The third frequency specifies how often the device MUST report a value even if it is unchanged. This allows the server to detect when a sensor has stopped working.

One issue with using the Netduino and the various low level socket APIs it provides is that it’s far too easy to hang the device. I’m currently building a watchdog timer circuit that will reset each Netduino if it fails to report in.

Raw sensor data is interesting but the real power comes by applying the various time-series aggregation methods I have in the system.  For example calculating the average in a given window of time, differencing two sensors, … Currently that’s all internal to the home automation system but I am considering expanding the RESTful API to allow querying of the raw and aggregated sensor data.

I’m also looking at MQTT and various other protocols for sending sensor data to see if there’s an existing standard out there that would be suitable.

My Internet of Boilers

Yellow cable contains 10 temperature sensors

Yellow cable contains 10 temperature sensors

The latest addition to my home automation system is a set of 10 DS18B20 temperature sensors that monitor all aspects of our underfloor heating system. Each zone has a hot pipe going out to it and a cold pipe coming back. There are also sensors on the pipes to and from the boiler and on the hot water tank pipes.

The sensors are mounted on small pieces of circuit board which were then soldered in-line in a CAT5 cable then covered in heat-shrink tubing but leaving the sensor body exposed. The sensor is then taped onto the pipe. By marking the wire ahead of time each sensor was placed at the right spot to align with the pipes I wanted to monitor.

The heating system in this case is a fairly complex one with four separate zones, a hot loop to the boiler and the hot water tank and then ‘mixed’ loops to serve each zone. There’s a controller that has a few temperature sensors including one outside so it can adjust the temperature of the water to the floor according to the ambient temperature also. For the most part it’s been a very reliable system and unlike a forced air system this one needs a very small current to keep the pumps running in the event of a power outage.

On the other end of the CAT5 wire is a Arduino running a simple polling loop that posts the temperatures to my home automation server whenever they change by more than 0.5 of a degree Celsius. One interesting tweak on the protocol I created for that API is that the server replies with a message that says how often it wants to receive updates and to what accuracy. That way I can update the server and all the Netduino hosted sensors around the house will change their update frequency or accuracy. Other than that the API is a simple POST of the temperature value to an address that includes the OneWire unique identifier. The home automation server collects all these timed-values, stores them in MongoDB and provides some analysis capabilities on top. Each sensor has its own graph, or I can define graphs like the one shown here that combine two sensors: an input and an output so you can see what the temperature drop (or gain) is.

Outgoing and return temperatures


The graphs generated by what is really a fairly simple boiler controller are surprisingly complex. Between the boiler running, the mixing valves opening and the valves to individual zones opening and closing, the temperature graphs trace some fairly complex patterns. My initial observation is that the boiler is running far more often than I would have expected so I’ll be trying to figure out why that is happening and what I can change in my thermostat setting algorithms so it runs less often.  I’m also wondering if I can tweak the controller’s various set points to make the system work more efficiently, e.g. reduce the water temperature going to the zones by a degree or two.

Longer-term I’d also like to add some alerting into the system for conditions like the tank temperature falling below a certain set point. This normally indicates that someone has knocked the earthquake-shut-off valve and it needs resetting.  I’m also wondering if I can calculate boiler efficiency and create an alert to have it serviced when the efficiency falls below a given value.

VariableWithHistory – making persistence invisible, making history visible

In a typical .NET application variables have a short lifetime. When they go out of scope or the application ends their value is lost. Also, you cannot ask a variable what its value was 1 hour ago, or what its average, maximum or minimum value was yesterday.

Yet, such a variable would be extremely useful when writing a Home Automation System because you often need to make comparisons between a current value and some historical average, or between two ranges (e.g. was the kitchen more or less occupied than yesterday). Now, normally you wouldn’t want to mix persistence up with the representation of a value in your code (see ‘Separation of Concerns’), but in this case I decided that it was worth mixing the two concepts because the benefits of doing so were so great.

So I created a class called VariableWithHistory<T> which is the abstract base class for IntegerWithHistory, DoubleWithHistory, BoolWithHistory, StringWithHistory and a number of others.  The first property worth noting on these classes is the .Current property.  This always gives you the latest value that has been set.  Setting the .Current value stores both the value and the DateTime (Utc of course) at which the value became current.  A history of all past values is maintained in MongoDB up to some suitable limit per variable (each variable can have its own adjustable history size in bytes by using MongoDB’s capped collections).  If the new value is the same as the old one no update is made, the implicit behavior being that the value changed and stayed there until it changes again, so if you want to know what the value is now it is the same as the last change recorded.

With this new variable type in place any object in the house can have any number of persistent fields on it (bool occupied, double temperature, string triggeredBy, …).  Updating these values is as simple as assigning to their .Current property.  When the system loads, each value comes back with the value it had when the system was shut down.  To accomplish this every VariableWithHistory is given a unique id (based on the unique id of it’s parent, e.g. a room).

So far so good, shut down, restart and the house doesn’t need to query a device to know if it’s on or off and all the long running Sequential Logic Blocks I use for rules (e.g. .Delay(days:2)) carry on running as if nothing happened.  This is particularly useful since I typically deploy a new version almost every day and some logic blocks have long delays built into them.

But besides providing simple recovery from a reboot, these persistent variables allow me to do some much more interesting things.

int CountTransitions(DateTimeRange range, T direction);
Counts how many transitions there have been to the value T in a given time range, e.g. how many times did the driveway alarm go ‘true’ this evening?

Dictionary<T, double> Fractional(DateTimeRange range);
Builds a histogram of all the values seen in the time range, e.g. 50% hot, 20% cold, 30% warm for a string variable that tracks temperature

DateTimeOffset LastChangedState
e.g. when was this sensor last triggered?

TimedValue<T> ValueAtTime(DateTimeOffset dt)
What was the value at a given time in the past, e.g. what was the temperature at the same time yesterday?

Each specific type of VariableWithHistory<T> may also have additional methods relevant to the type T.  For example, on DoubleWithHistory there is a method double Average(DateTimeOffset minValue, DateTimeOffset maxValue) which gets the average value over the specified time range.  On BoolWithHistory there is a method double PercentageTrue(DateTimeRange range) which you could use to find the average occupancy for a room yesterday.

My initial implementation waited for the database to write each update before allowing any queries but now I simply cache the Current value and assume that queries will probably get executed after updates and that the average temperature yesterday is close enough with or without the last 100ms of updates.  I did try to keep this class isolated from MongoDB but in the end the benefit of some of the atomic update capabilities in MongoDB made it easier to just take the dependency.

My previous implementation of this feature used my own in-memory database, MongoDB has slowed it down a bit but I’ve gained the ability to archive terabytes of sensor data which should prove useful for my next project which is to add some machine learning to the system.


A Quantified House – My Talk to the Seattle Quantified Self Meetup

I delivered the following presentation to a meetup of the Quantified Self group in Seattle tonight. The evening was a fascinating fusion of medicine, technology and personal improvement. My talk fell between a session on personal genome sequencing and another on measuring the effects of coffee on blood pressure.

Integrating an Android phone into my home automation system

My home automation system has long had the capability to communicate with a Panasonic PBX. From the PBX it gets a flow of information about every phone call in or out the house. It also has a couple of caller-ID-to-serial-port devices that give it an earlier notification of incoming calls with Caller ID information. Using these various inputs it builds a database of every caller and every call (time of day, duration, person).

If it sees a call from someone not already in the database it will ask (via chat) for you to enter their full name. It then updates its database replacing the caller ID name (which is often useless, especially for mobile numbers). You can also query it using the natural language interface to ask about any calls you might have missed, or to lookup a number by time of day or by a fragment of their name. You can even ask complex queries like “who called last year on a friday after 5pm” and it will construct an efficient SQL query to get the results.

It also synchronizes all these contact records with Google Contacts.

But until recently my mobile phone hasn’t been part of the home automation system. Yes, I can use it as an input device for Google Talk, and yes, the house still notices when it comes and goes because the house tracks every device that ever gets an IP address on the local network, but other than that it really doesn’t ‘understand’ much about my cell phone.

But that’s about to change. Recently I installed Tasker on my Android phone and using that app I can now set up a whole variety of triggers that can report back to the home automation system information such as phone calls made or received, GPS location, wifi-located position, phone unlocks, shakes and more.

So I’ve extended the web interface on the Home Automation web server to accept POSTs from Tasker with updates from my cell phone. These are placed into a PubSubHub implementation that uses SignalR to distribute messages to any connected clients. The home automation server is itself a client of this service (it publishes information about every device change in the house and the PubSubHub shares those updates with any connected Web client) so you get real-time updates for what’s happening in the house on the house’s web page. Extending that architecture to include messages from remote devices like the Android phone was easy and I plan to use it in the future for other remote devices, such as a Netduino with a collection of environment and HVAC sensors on it (more about that later).

As to precisely what I’ll do with this new capability I have a long list of features to implement now:

1) Logging all cell phone calls to the same database, automatically building my contacts list
2) Tracking how long it takes to get to work by each of the various ways I can go, correlating that with the traffic flow information and automatically figuring out which route I should take for future trips
3) Shake cellphone to change music in the house
4) Adjusting the heating at home based on how far away we are (and thus the soonest we could get back)
5) Finishing up my semantic, location-aware shopping list (knows which store you are in and what you need there and presents it in order by aisle)
6) Automatically delivering notifications by the best possible means (talking on the speakers at home, XMPP, or by email if I’m in a different time zone)

The Internet of Dogs

In my previous post about GreenGoose I described my initial experiences with this “Internet Of Things in a box” product. Recently I’ve been trying their API and have integrated it into my Home Automation System.

Click image to see it all.

The initial integration was easy, I used the new ASP.NET WebApi Core Libraries (from Nuget) together with Newtonsoft Json.Net. GreenGoose’s datetime format is somewhat quirky but hopefully they’ll move to a more standard one soon. They are, however, also about to switch to OAuth so it’s going to require some more work when that happens.

Aside from a few simple WebAPI calls and some Json parsing the rest was just a matter of connecting up the appropriate TimeSeries classes that I use to track values that vary over time, declaring a few graphs, and deciding what to log. With that in place I can now spin up a home automation ‘sensor’ corresponding to any GreenGoose sensor Id and my home automation system will add all of the relevant graphs and charts, triggers and more for that device.

What’s interesting is that a single sensor potentially serves a couple of different purposes. The dog collar sensor for example polls regularly back to the base station so it can potentially be used to sense both how much exercise the dog has had but also simply whether the dog is at home or not which could be really handy for anyone with a dog that’s learned to ignore the invisible fence! Each sensor can, through the TimeSeries objects also offer additional data and triggers that can be used elsewhere in the home, for example, an alert if the dog was walked less than half and hour each day.

GreenGoose Review

GreenGoose Hardware
One of the conclusions I’ve reached from my many years experimenting with home automation is that one of the missing ingredients is affordable, wireless sensors with long battery life. One of the best solutions I’ve found so far is to use CADDX alarm sensors because they are wireless, have exceptionally long battery life and can be connected to a PC using a reliable serial connection. Proponents of the Internet of Things talk about every device having an IP address and recently some wifi-connected sensors have appeared. I’m skeptical of that approach: it seems unlikely however that they will get the kind of battery life you need to be practical and you really don’t need a separate IP address for every single sensor.

What I believe we need is a hub device that connects to the internet and then really cheap wireless sensors that communicate back through it using a connection technology that requires much less power than wifi. So when GreenGoose recently announced their sensors I was one of the first to place a pre-order and this week I received one of their first device shipments. This blog post discusses some of my initial impressions.

First off I have to say I don’t like the egg shape or the color of the hub. Fortunately it’s in the wiring closet next to the router so I don’t need to see it.

GreenGoose Mounting on food containerThe sensors themselves are remarkably small considering they claim a battery life of 1.5 years and the fact that they include both a sensor, some intelligence and a wireless transmitter. Two of the sensors were stick-on devices which I stuck on the dog and cat food containers respectively even though one was labelled food and the other treats. The other two were shaped like dog tags. Here you can see one of the stick-on sensors mounted inside the lid of a dog food container.  You can view a teardown of the GreenGoose sensors and hub on this Flickr page.

Connecting the sensors up to my account took two attempts, three sensors were found on the first try and the remaining sensor on the second try. That’s apparently fairly normal. There were a few configuration problems with my account and the iPad software (actually iPhone software in 2x mode) and the web site is clearly still under development with daily bug fixes and improvements happening each time I try it. But, I have to say the folks at GreenGoose have been incredibly responsive to my every comment or bug report.

GreenGoose User Interface
So now I’m getting reports from the sensors on their web site and overall things seem to be working quite well. It’s certainly not 100% reliable yet in terms of capturing every event so I don’t think these are going to be the perfect home automation sensor that I’m still waiting and hoping for, but, in all fairness, the folks at GreenGoose aren’t selling these sensors as alarm panel sensors, but as more of a fun game tracking activity and reminding people to go walk the dog. I’ll update this blog when I have a better idea exactly how accurate they are at capturing activity.

The biggest gotcha however is that my original plan to use the sensors on different devices has been somewhat thwarted by the realization that each different sensor type is calibrated to detect a specific kind of motion. You cannot re-purpose them like you would a normal motion or contact sensor. So putting the dog collar sensor on my key chain isn’t producing the results I’d expected. We will have to wait for GreenGoose to come out with sensors to put on doors, cars, shoes, cellphones, iPads and whatever else we want to track. I’ve suggested to GreenGoose that they explain this better on their web site as many hobbyists will try to repurpose the sensors for applications other than the ones for which they were designed.

Another issue at the moment is that the web site forces you to assign the sensors to a specific pet and they only support one pet name. They say they’ll add multiple-pet support soon.

Next I plan to try their API and will report back on how that goes.

Bottom line: this is remarkable technology – a mems accelerometer, some computing power, a radio transmitter and a 1.5 year battery in a package the size of a stick of gum is quite a feat of engineering. Some of the software is a bit ‘immature’ but it’s improving daily. Overall this is a very affordable way to try out some ‘quantified self’ ideas for yourself, it might help you walk the dog more often (our dogs wouldn’t let you forget to do that, but maybe yours would!), and the support from GreenGoose has been great.

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.

Home power meters revisited

In an earlier post I discussed the utility (or otherwise) of the 24 hour power consumption graph and questioned why Google and Microsoft were both investing in this approach to home energy efficiency. Since then both Google and Microsoft have stopped their efforts in this area.

Interestingly, in Europe I’m seeing more and more homes with devices like the one shown here that provide real-time power consumption information. One of the more interesting uses for devices like these is as a check that everything has been turned off when a homeowner is about to leave the house. A quick glance at the meter can reveal if a heater has been left on in a bedroom. Of course the main water heater has the largest impact on the reading but homeowners learn what numbers represent ‘normal’ and can see at a glance when something else has been left on. Clearly a true smart home that can turn devices off when they are no longer in use is still a better long-term solution for this scenario but it’s interesting to see how a fairly simple device can at least provide an indication that everything is off without a significant investment in replacing light switches and device controllers. What would be nicer however would be if the meter included some kind of machine learning so it could show at a glance if the home is in a minimal power state or not.