So my smart thermostat has been doing its homework and keeping itself abreast of new developments.  I’ve been tweaking the automation code and adding bits of logic to accommodate my particular nuances.

You may recall that one of the most important features of my setup is an ability for the system to automatically determine home/away status.  This is based on Bluetooth detection; and while I’ve still to add a large antenna to extend the detection range, I’m also acutely aware that this method of determining home/away status will always be reactionary vs. predictive.

As usual, the Wifey Factor(tm) is playing a critical role here.  A comment was made recently – well, a question actually – as to whether the HVAC system knows when we’re on the way home so that it can start heating/cooling the house automatically.

Admittedly, such a usage of the system leans more on the side of comfort than efficiency.  And I’ve already made a concession to comfort by setting a small(er) offset between home/away temps.  (IIRC, it’s something like 1C in cooling mode and 1.5C in heating mode).  I’ve also approximated a “should be getting home soon” decision process by setting evening programs which differ from the daytime programs; ideally, you’d really only need an overnight program and a not-overnight program, and the occupant detection would determine the home/away offset.

But I digress. In an effort to solve this little problem while also furthering my understanding of web-based technologies (ie, the Cross-Pollination(tm) effect, search the blog 🙂 I decided that the answer may lie in utiliizing the Google Latitude API.

We already use Latitude for tracking purposes, so the privacy concerns have been addressed already.  The premise, then, is simple – my automation system polls Google, gets our locations as reported by Latitude, and then does some calculations to determine if we’re on the way home.

Simple in practice, yes.  More difficult in execution, but only marginally.  One of the unknowns here was OAuth, which serves as Google’s (and many web services’) API authentication/authorization method.  I’d heard about OAuth, but never had a need to look into it – either for work or personal means.

And that’s a shame, really. Anyhoo, OAuth is done and done and now I’ve got my automation system pinging Latitude, calculating distances, and producing raw-ish data that I’ll later analyze to determine the most suitable “peeps are on the way home” algorithm.  I may even use it to supplement the Bluetooth detection method, which is sometimes hit-or-miss in lieu of that big antenna…

One of the more challenging aspects has been deciding what to do with outlier data points.  Latitude has this habit of sending you off 100’s of kilometers in some random direction for no apparent reason; we certainly don’t want the automation system going bonkers by thinking we’re flying in at Mach 5 from some random city in the US. And while I’m sure that there are many statistical methods that one can use to clean a data-set, such an endeavour would be secondary to the purpose of this project.

So to that end I’m currently using a “line of best-fit” (aka the Least Square Method) to fit a straight line to my Latitude data points.  It doesn’t completely solve the outlier problem, but it lessens the impact somewhat.  Anyhow I’ll pore over the resultant distance calcs over the next few days and…

… I’ll post back when I’ve got useful performance data.

[update 2011/09/15] Seems to be working well!  Check out the thermostat post for info.