Project Logs

Collapse

• So does it work?

  Tim Rightnour • 12/10/2020 at 19:05 • 0 comments

  It's been at least a year since I fired this thing up.  The short answer is, absolutely, yes.

  If we take a look at the histogram below (which I found is the best way to visualize this data) we can see how it trends towards higher and higher readings, until we hit the point around 0.8 or so, which it should definitely have been replaced just before.

  So basically, if I watch this graph, I can see when the filter should be replaced.  And it's pretty accurate.  I have been examining the filter visually during the period, and the graph basically matches it.
  

  I ended up building one more of these sensors, but basically just attached 2 BME280's and then wired them in ESPHome, super simple.  Need to install that in one of my other units.  But short answer is, I'm more or less happy with this!
  

• Anatomy of an AC Failure

  Tim Rightnour • 08/22/2019 at 01:12 • 1 comment

  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:

  May 2014 Failure

  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.
  

• The experiment

  Tim Rightnour • 08/17/2019 at 17:06 • 4 comments

  So here is the experimental setup:

  • Remove the filter, shut off the AC, turn the fan on.
  • gather data for 10 minutes.
  • Place brand new filter in for 10 minutes and gather data.
  • Place existing filter in for 10 minutes and gather data (medium dirty).
  • Place super nasty filter in for 10 minutes and gather data.
  • Shut system down

  So lets start with a few bits of data.  First, here are the graphs for the event.  This is an exported grafana dashboard that will let you see the data and zoom in, etc etc.
  

  Live Grafana dashboard of experiment

  
  Now for the filters:

  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:

  1. No filter at all, AC off, FAN On.
  2. Brand new filter
  3. Medium filter
  4. Dirty Filter
  5. System returned to normal
  6. Resume normal AC operation

  And now drumroll... the data (averages over each time period):

  State	Pressure difference (mb)	Power Draw (W)
  No filter	-0.856	456.61
  New Filter	-0.479 (0.377 adjusted)	433.02
  Medium Filter	-0.429 (0.427 adjusted)	430.51
  Dirty Filter	0.009 (-0.438 adjusted)	387.03

  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!).

  Initial thoughts:

  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".
  
  

• Interesting Data.

  Tim Rightnour • 08/15/2019 at 02:12 • 0 comments

  Lets see some cool things!

  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

  1. 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.
  2. Notice that it eventually reached equilibrium with the other sensor.
  3. When the AC switches back on, the "quality" is almost immediately improved.
  4. 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?
  

  1. When the air sits stale in the upper part of the return, it gets HOT.
  2. The air in the return loses humidity too!
  3. 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.
  4. 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!

• BME680 is weird

  Tim Rightnour • 08/15/2019 at 01:45 • 0 comments

  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.

  2) Pressure:
  

  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 - Hook up pressure sensors

  Tim Rightnour • 08/14/2019 at 01:51 • 0 comments

  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.
  

View all 6 project logs