My goal of this project is to understand the air filter, and how it relates to the air conditioner itself. Can I build a model that accurately says "the most optimal time to replace your filter is today"? Can I somehow prove or disprove the "common wisdom"? Can I blow an outrageous amount of time and money to save probably $3 on air filters? Here are the questions I want to answer:
1) By measuring the pressure differential on both sides of the filter during operation of the fan, can we see a difference between a clean and dirty filter?
2) Can we see a difference between clean and dirty filters by measuring the watt usage on the fan?
3) Can we see a difference between clean and dirty by any means?
4) Assuming yes, can we find an optimal point to replace a filter. Is there a line in the sand where we must replace it?
5) Side project. Do different filters "stress the motor" like the AC guy tells you they do? Can we measure that?
I want to know exactly when to do something. Not "every month because I said so". I want proof. Evidence. So this is me being crazy and getting it.
We start with the basic idea. The main intake on your air conditioner pulls air through a filter. When you forget to replace your filter for a long time, it becomes covered in dirt. When you finally replace it, you notice that it's being sucked up into the vent, in a big dome. Presumably, this means that there is negative pressure on the inside of the vent. Can we measure that? Can we measure it accurately enough to do something with the data?
So step 1 is easy. I have a Venstar thermostat. This is a really nice WiFi thermostat that has a fully documented API. It was trivial to hook it up to my home automation system, and start pulling data. Now I know exactly when the fan is on, and off.
Oh, I guess I forgot step 0. Write home automation software, from scratch, because you are crazy. Yes. Do that first.
Step 2. Find an accurate pressure sensor, buy two, and hook them up on either side of the filter.
So right up front, I have multiple AC units. This failure was on my second unit, not on the one with the test installed. This has nothing to do with my tests. It just so happened that it failed yesterday and my automation system let me know.. though.. in a roundabout way... So this is unrelated to the experiment, but still interesting in the context.
So the secondary AC failed around 6am (that I noticed). What is interesting, is how. I've managed to capture data on two different AC failures over the years.. and each one has been really interesting from a data point of view. (Way less so from a heat and money point of view). My original capture log is here:
As I later discovered, that failure was a capacitor failure. This one is very different:
In this image, we see the blue (the big AC unit with the experiment running on it) and the yellow, the smaller unit. You can see how the previous morning, it was running a bit often, but mostly okish. Then around 2pm or so, we see a sharp downward spike in power usage. At which point, it seems to not shut off really. As we get later into the evening, it runs less and less, and then in the morning, it turns on, spikes up, and then never shuts off.
I'll know tomorrow, but I believe this to be a fan failure. I think the downward spike is the fan shutting off entirely, and the unit just tries in desparation to cool, but it cannot, because no airflow. I tried turning on just the fan, but no power usage, no blowing, dead.
And before you ask, yes I change the filters on that one.
The more failures I encounter, the better I'm getting at diagnosing them with just the power logs. I'll let you know tomorrow what the official word is.
From left to right, brand new 3M, used 3M, super nasty off-brand. Sadly, I did not have a dirty 3M lying about. Wait a month. :)
And just a tiny bit of data on the used 3M filter:
The thermostat, by default, comes configured to alert me at 90 days, or 300 hours of FAN runtime. It tracks the hours of runtime of the fan itself, between times that I click "changed filter". So I know this filter is about 50% "dirty" by it's standards.
Now lets look at the data, because this was both fun, and surprising.
Here we have a graph of the pressure differentials between the different stages of the experiment. I've noted with the blue lines, each phase. The phases in order are:
No filter at all, AC off, FAN On.
Brand new filter
System returned to normal
Resume normal AC operation
And now drumroll... the data (averages over each time period):
Pressure difference (mb)
Power Draw (W)
-0.479 (0.377 adjusted)
-0.429 (0.427 adjusted)
0.009 (-0.438 adjusted)
So I still need to pore over this a bit, and do some thinking.. but I can see a few things:
The dirty filter was obvious. Massive difference between it and no filter.
No filter gives us the baseline calibration difference of the two sensors from one another. Again, they are accurate to movement, just not calibrated. The adjusted numbers show the difference from the baseline of no filter.
The power draw figures completely amazed me. I thought it would be the other way around. The dirty filter uses LESS power. Wow. No idea.
While the medium filter isn't exactly that dirty, still, I expected a little more of a difference.
What does all this mean? I think I need to keep this experiment going, for a long period of time. I need to collect data over the next 150-250 hours of runtime on the current filter. How does it change over time? The super dirty filter was an abomination, so it was expected to show an incredible difference (a 0.8 mb difference!).
Yes. I can see the difference from the various filter states. There isn't a massive difference between clean and somewhat dirty, but in theory, if we went the whole 300 hours runtime, it might be as high as 0.1mb.
I do not yet know the answer, when should I change. I feel this will require longer term study of filter as it dirties.
The power draw also seems to be a really decent indication. The difference between clean and medium was only 3 watts, but the dirty one was a whopping 46 watts. That means it moves as dirt gets in there. It might even be an easier way to track this, than the pressure sensor setup.
None of these, not even the super dirty filter, moved the gas sensor on the BME680 at all. It is definitely not picking up "dirt".
Here is a graph showing the inside (on the "filtered" side) and outside (the house interior). This is the air quality sensor in Ohms. Remember, that higher numbers are better quality.
A few things to note
The normally high values of 200k or so are produced when the AC is on. That huge dip, is when I turn the AC off for 1-2 hours.
Notice that it eventually reached equilibrium with the other sensor.
When the AC switches back on, the "quality" is almost immediately improved.
This also tells me that the sensors aren't just producing random numbers. When allowed to sit long enough, in the same air, they produce the same number.
Now this is a fun one. The red lines are where the fan is ON. What can we learn here?
When the air sits stale in the upper part of the return, it gets HOT.
The air in the return loses humidity too!
I'm not adjusting here for the 0.89 offset of the pressure sensors in the graphs. Once you do a little math in your head on this, what it shows is that there is *measurable* negative pressure inside the return when the AC is ON.
I don't necc. need to adjust for the 0.89 here, because what we are looking for, is that as the filter gets dirty, the difference changes noticeably, not so much the actual value yet.
One last graph here. My AC unit runs the fan, all by itself, with the compressor off, for a few minutes at the end of every cycle. By carefully discarding values, I can now see those numbers. Here it shows an average of 413 watts over 6 hours. So now we are all set up to do actual experiments!
So, working with the BME680 has left several odd impressions.
1) The gas sensor
No idea what it is measuring, but it does measure something. For example, a Sharpie, immediately picked up. It reads in Ohms. Range seems to be around 10k - 250k.
When you set up the sensor, they suggest doing a "burn in" of the gas sensor for up to 5 minutes before taking readings. I've found this really needs to be more like 10-20 minutes before it actually stabilizes.
The sensor is activated, by basically turning on a little internal heater. This heater does something or other, and then the sensor produces values. Side effect? The builtin thermometer is affected by this! Once I set my heat cycle up, I noticed that the thermometer read high by 2C! This is ok, as long as you know this up front. My code simply subtracts 2.
Because I have 2, I can put them right next to each other, and see how consistent they are. The temperature is pretty consistent between the two, however, the pressure, not so much. They are off from one another by about .89mb. This isn't to say they are inaccurate. For example, they both move together perfectly. So if one gains 5mb, the other does too. The curves don't diverge up and down, they stay exactly .89 apart. I guess without a calibrated test environment, I will never know the actual pressure. However, for my experiment, this is irrelevant. They are accurate to moves up and down, so as long as I subtract the appropriate 0.89, I get the difference readings I need.
Step 2 is the hardware portion of our experiment. We need 2 pressure sensors, set up on either side of the filter.
For this, I selected a PI Zero (because it was easy to program), and a pair of BME680 sensors. They claimed really good accuracy on the barometric side, and to boot, they had these neat "air quality" probes, which, I figured might be interesting at least.
The Adafruit ones are nice, because they have the ability to change the i2c address by grounding one of the contacts. This means I can run both on one Pi.
Essentially, without needing a ton of details here, I hooked both sensors up to the pi, with about 8" leads on them, and powered the whole thing up. Then it was a matter of writing the software.
The code to read the sensors is really easy to write in python. Just install the bme680 library from pip, and follow the simple example. Where it all gets kinda fiddly is the gas sensor.
Basically, the gas sensor reads some kind of VOC data. If you put a sharpie near it, it immediately registers. But it's super unclear what it's actually picking up. The sensor itself reads in Ohms. They include a library that will convert it into some kind of magical "Air Quality" value. However, looking at how it calculates this, part of the formula involves the humidity. They consider "dry" or "wet" to be bad air quality. This might be true for comfort, but for my use, this is not helpful at all. Therefore, I plan to just read the raw ohms values and store those.
For the curious, I didn't just write a simple gather and store program. For many years, I've been writing my own Home Automation software. It's called "Gnhast" (Garbled's Nasty Home Automation Scripting Tools). I integrated these sensors right into the network of stuff feeding my data. I also feed all the data from my HA software into Influx, so I can make pretty graphs with Grafana. (I just upgraded to that from RRD, which I used for many years).
So not only do I have things like the Venstar Thermostat wired in and feeding data, but I also have a Brultech GEM that feeds watt usage data for every circuit in the house into this thing. That means I can pull all kinds of data together, and try to really figure this problem out.