Reworking temperature profile generation

After a couple weeks of planning (and maybe a little bit of stalling), I finally sat down last weekend and started writing the algorithm that generates all the scores I talked about when I built the GUI mockup. I've done this once, but it was quick & dirty and has some issues.

The new algorithm isn't conceptually much different than the old one. It simply needed to be rebuilt to be more efficient, handle some new concepts, and be a bit easier to debug.

The Algorithm
This is actually pretty simple. For all scores, I simply have to loop over the entire date range, find all blocks of time where the HVAC system and outdoor temperature were in a consistent state, then average the change in indoor temperatures together. The most complex part is handling homes with more than one zone. In those situations, one zone will actually affect the temperature in another zone, so some care has to be taken to adjust for that.

More efficient
Calculating the scores requires looping over tens of thousands of rows of data. I'm using PHP, and dealing with a year of data for a single thermostat uses about 200mb of memory (there's a lot of overhead). That isn't terrible for one person, and since this particular calculation will run fairly infrequently it's not the end of the world, but I prefer to keep things as lean as possible. I spent a couple hours analyzing memory usage and the new version is nicely capped at 64mb regardless of number of thermostats or time range. If that ever becomes an issue it's trivial to change the memory usage.

New concepts
Today, beestat has a "Home Efficiency" graph which is what I'm presently calling "Insulation Score" in the new version. I'm adding two new scores to the roster: heating score and cooling score. Those scores are simply linked to the rate at which your home heats/cools when the heat/AC is running. Also new is the concept of a "thermostat group". For the 75% of users with a single thermostat, this won't even exist. For everyone else, it will. A thermostat group is going to be an automatic construct based off of your thermostat address. This is because your scores are intended to be for a single physical location; so if you have multiple thermostats in one home they can be grouped together and reported as if they were a single entity.

Easier to debug
My process for building the algorithm last time involved a lot of copy/pasting tables into excel to see what the graph looked like after I made a change to the algorithm. This is pretty awful, especially since I need to look at a lot of different graphs to see how they look. This time around I've built some rudimentary outputs that can simply graph the results. As an example, see the images below. It's now very easy for me to fiddle with the algorithm and compare results. Also I can generate a bunch of these graphs and quickly scan through them to look for problems.

Here are a couple examples where I change a parameter to see how the output is affected. The first changes the granularity, or the number data points on the x-axis. The effect of this is generally a smoother raw graph that better matches the linear fit. Overall the score isn't affected much. This is expected.

The second graph shows what happens if you change the duration. For insulation score, that means the HVAC system must be completely off for this amount of time before I accept that data into the average. Interestingly, this affects the score pretty significantly which tells me I've probably done something wrong. Intuitively, I would expect to see fewer data points on the x-axis and a smoother raw graph.

Overall things are looking promising for the next version. Everything is designed and figured out, so other than the things that inevitably come up during implementation all that's left is to write the code. A tentative release date for this version is March 1. Early Access Patrons may have something available early February.