Accounting for air flow

[kiler129]

Hi,

First of all - hats off for bringing a rather complex project into reality, and in addition making an affordable and well designed kit! I unfortunately missed the last batch by a few hours on Tindie, but that led me into a bit of a rabbit hole which I'm not sure if anyone explored :)
While the project appears to be originally directed into measuring differential pressure, seeing that it has been extended to facilitate ΔT measurements, I decided to open a discussion about a topic of airflow.

Not only pressure

I believe the most common use-case (as mentioned in the readme) is detecting HVAC filter load. However, over the last few days I learned the reality is more complex, and to determine filter change, in addition to pressure differential, the air flow has to be accounted for. I found a great summary article discussing the topic: "How to Do Filter Differential Pressure Alarming the Right Way" (archived copy). I also saw this being partially discussed in one of the issues in the repo as well.

The article concludes with the following graph, which I think encompasses the whole issue:

Home HVACs

I started digging only because I was trying to test pressure sensors I had in hand, and I was getting strange/inconsistent results. It turns out, even cheap consumer HVACs use multiple blower speeds creating false-positives. As a tinkerer, I naturally began looking into all my family member's HVAC units and asked a few friends too. I discovered 3 configurations:

1. Old and/or cheap units with single-speed blower
2. 2-3 fixed speed blowers, usually with high speed for cooling mode, medium for "fan only" mode, and low speed for heat
3. Variable speed blowers with more complex controller logic

By far the most common one is the second one with 2 or 3 speeds. Example of how the output looks in my HVAC, where the control board supports up to 5 speeds and is wired to a 3 speed blower:

Technical diagrams appear to be available only to HVAC techs, but can be easily found online (archived copy).

Solutions to account for air flow

Perfect & overcomplicated solution

Obviously the ideal solution would be to actually measure the air flow. However, this to my knowledge is in practice quite complex. Either anemometer or a MAF has to be used. The former is a mechanical device, which isn't really suitable for 24x7 deployment in a duct. The later is expensive and complex, as it usually relies on heating up a wire and converting temperature drop to flow.
I wouldn't go this route, even if money and complexity weren't objectives. I'm just throwing it here for completeness sake, as this is how commercial systems do it.

Good compromise

The vast majority of blowers (except the single variable speed one I saw) rely on multiple windings. The control board simply puts 120VAC on one of them at the time to change the speed. I think detecting this condition would be the best compromise, as it covers most cases.

I'm not an expert in EE, but I know just enough to be dangerous, so I hope the author can chime in here :) I see a few ways to detect which fan "channel" is being used:

1. Current transformers

   • This is by far the safest and easiest method, as it's fully isolated from mains
   • There are many pre-made modules available for cheap (e.g. 5pcs ZMCT103C with amplifiers for $10)
   • Such modules can be wired to individual ADC pins. From what I'm seeing ESP32-C3 used in the project contains 5 usable channels. However, looking at the GPIOs exposed on the board only digital I/O is possible as of now
   • I see a few disadvantages with these modules:
     • They're are rather large if we need 3-4 of them next to each other
     • Each one requires to be powered, creating a spaghetti of wires
     • Using a CTs is IMO an overkill, if only presence of 120VAC is needed
     • I didn't measure it (yet), but I have a feeling the surrounding EMF may cause false positives d/t proximity

2. Mains measurement

   • Since most blowers run on 120VAC, so measuring presence of the voltage on each of the "channels" seems like a viable option
   • When done properly with optoisolation, it's perfectly safe. I personally wouldn't roll my own circuit here as there are a few gotchas and almost nobody wants to deal with mains ;) Premade modules, including multi-channel ones, are readily available and rated for mains usage (e.g. 3 channels for $10).
   • I didn't test it yet, but I think simple digital pins can be used here. IIRC ESP32 digital inputs can operate at realistic max ~100kHz, which is way more than 50Hz.
   • On the software side, ESPHome includes pulse_counter module which appears suitable here.
   • I see two potential problems of this solution:
     • Connecting to mains outputs of the control board and securing anything touching 120VAC requires a bit of care
     • The back-EMF may trigger all channels, regardless of which channel is powering the motor. It's just an educated guess so far, as I didn't have a chance to scope it yet.

3. Control signal measurement

   • In short, digital input pins on the ESP32 can be used to check which output channel is commanded to be operated by the HVAC control board.
   • As the control logic uses 5V signaling, it's safe and relatively easy to probe & detect.
   • This method IMO is more of a honorable mention here, as it requires direct modification of the control board. Each one of them is similar, but with slightly different circuit, so it requires a user to actually have electronics knowledge to pull this off. Also, despite all boards I've seen being classic single layer through-hole constructions, they're conformally coated, making it annoying to work with. In addition, in case of a magic smoke, replacements are often in the range of $300-500.

Sort-of acceptable solution

In the spirit of looking at what a minimum viable solution would be, I think looking at what is being commanded to the HVAC unit can be used as a "proxy" of the blower state. Without a smart thermostat, it's a bit of mess as there's no single standard. However, all inputs are simple 24VAC so a simple optocoupler module can be used with digital pins.

At the absolute minimum, assuming smart thermostat, this can be done purely in software by checking whether it calls for heat or cool or just the fan is running. I poked around that and it's better than nothing but the control board, despite being pretty primitive, appears to apply its own logic to what the thermostat calls for and often will e.g. limit fan duration or extend it.

WDYT?

This is sort-of a summary of my research on the topic. I think to facilitate air flow consideration for a general user a few, hopefully small, things can be implemented here:

• Providing analog inputs on the next revision of the PCB, along with a few more 3V3 & GND pads
• Add example configuration for ESPHome
• Add some docs (maybe derived from this post?) regarding the topic, with a diagram of how to connect things

While I cannot don't feel confident helping on the hardware side, I could certainly contribute in the ESPHome software side and with docs.

[gcormier]

Awesome post and very comprehensive!

I agree with the challenges. I have an ERV in the mix, and it was installed using the return air duct method, as opposed to dedicated send/returns to various rooms. (Both valid installs) So when the ERV kicks in, it plays with my pressure.

I had looked into tackling that challenge, but since my ERV runs for a fixed duty cycle (10mins per hour), the pattern is pretty obvious in the graph when its running.

My assumption is that anyone playing in this space has a smart thermostat, and can view the different heat/cool/fan calls over software. I personally have an Ecobee, and I can pull this data.

That said, there have been previous requests to develop more of a general HVAC control board. I even started designing a prorotype,

This has opto isolated inputs for reading 24VAC, relay outputs, temp probs, differential pressure, CO2 headers and PM2.5 headers. At that point, you could have a full esphome thermostat capable of controlling your furnace.

I definitely think opti-isolated inputs using the 24VAC controls is the way to go. As you mentioned, nobody touching high voltage :) And touching control boards directly is also out for the same risks you mentioned.

An aside, for air speed, check this out - https://www.kele.com/product/flow/air-flow-stations-and-switches/series/fxp-series - was shared by one of the purchasers of this board. It uses differential pressure to measure air speed across different duct sizes.

Another idea I've been chewing on is to move the actual pressure sensor to some sort of dedicated PCB, since it's the most expensive component by FAR. This would allow for me to offer other designs, with only 1 inventory of sensors, but also allow me to expand the pressure ranges if there is any need for it for other applications (I've yet to hear any). Possibly an M.2 style PCB.

[curious-ninja]

OO I'm very interested in your general HVAC control board..

I was getting ready to make a post in the discussions to see what it would take to modify the board to accept multiple pressure sensors. I looked through the datasheets and unsure if the sensor i2c address can be changed from factory default, so that may be an issue.
My goal is to monitor pretty much every parameter of my HVAC unit. Currently I'm using shellys like the other users in that thread you had linked (#6).

So far it only has temps and some power monitoring. I'd like to convert the entire thing to esp32 and expand to include the following:

1. Filter drop delta-P
2. Air handler total external static pressure (prefer to use 2 separate sensors (1 return, 1 supply), and do the delta-P calc in home assistant. This way I can see which side has issues. It's a zoned system, a lot happening with damper controls.
3. Coil drop delta-P
4. Measure airspeed to calculate CFM. Original planned method was this hot wire anemometer:
   https://moderndevice.com/products/wind-sensor-rev-p
   But I also really like the Kele pitot/static tube you linked. May end up trying both to compare accuracy.

You mentioned your prototype has opto-isolated inputs, that's for each wire from the thermostat?
Monitoring each call to the AHU/HP is also on my list.
Overriding calls would also be a great feature for testing various modes, even though I know most smart thermostats already do this.

Long-term I'd like to also monitor and override the calls going to my zone dampers, so the entire device is a zoned hvac monitor and controller. Pretty much all available zone controllers I've come across leave a lot to be desired for feature set. I'd like to command my dampers in different ways during different seasons, and add zone sizes into the control algorithm. All of which can easily be done with some home assistant or node-red automations.

Your esphome-pressure is a great starting point for this stuff, but with the general control board you mentioned...sign me up.
How can I support?

[gcormier]

If you can find 5-10 who are interested, I could do a run of boards. Or I can release it for hand assembly as well from just the PCB's.

The pressure sensors can't change the address, so you'd need to put each on it's own digital IO pin and use seperate i2c busses, or, use an i2c multiplexer like a TI TCA9546A

[curious-ninja]

Unfortunately I don't know of any friends that are into this stuff lol. Finding people in the home assistant forums may work. If you don't pursue the design further could you share the prototype files so I can potentially get a board made for myself? Thanks. My use of kicad is limited but enough to get by.

[gcormier]

Added a new discussion, if you want to add your thoughts @curious-ninja on what you'd like to see #22