I've mentioned this in previous posts, but I thought I should start a new thread, since those posts were older and not always for this same project (but related ones). Anyway, I've been working on a V2 of my "Marvin the MircoParticle Machine (Bento) Filter V1" which is a bento box type filter that gets placed inside a 3D printer to help reduce fumes and microparticles. I used the original V1 design for well over a year, and it worked well, but I gave it away to a relative along with one of my printers, and have been missing it. The V2 update has been long planned, but the problem was that the 4 wire (PWM) 5020 blower fans I planned to use have become really hard to find (and expensive). Fortunately the basic 2 wire (dumb) 5020 blower fans are still available and relatively cheap. The reason this mattered was that I wanted to have some form of smart control over the fans and 4-wire PWM fans make that much simpler from the hardware side of things. It's still possible to smartly control a 2-wire fan, but it requires adding some additional MOSFETs to actually control the fans (since the fans draw more current than can be switched from a microcontroller). This is pretty standard stuff for anyone who makes stuff with micros, and I could have just bolted a mosfet board to an ESP32 and gone on my merry way. But recently I found a ESP32-32E board which covers all the bases, except that it lacks almost any documentation lol.
This is an ESP32-32E based board, with an onboard buck controller which will take 5-60 volts input, has an onboard 3.3v linear regulator (to give all the 3.3v sensors and the ESP32 a stable voltage source), USB-C power input (5V only) which is really only useful for programming, and most importantly, two MOSFETs which are controlled by GPIO pins (via some transistors). They also have a four MOSFET version, but two is enough for this project.
The pinouts, which I discovered based on tracing things on my board are:
CHANNEL 2 = G17
Channel 1 = G16
Status LED = G23
Switch = G0
Those pin mappings should be considered a starting point, since I don't know if all these boards are the same (they may look similar but they could be wired differently). I took a close look at mine (and from what I can make out), it uses a NCE6020AK MOSFET (60V/20A n-channel), with a small "J3Y" transistor (40V/0.5A NPN) which drives it. There is also a AMS117 3.3V/1A linear regulator for supplying the ESP32 and sensors.
The design goals of the project to update the filter are:
So far all these goals have been met, or are in progress and almost completed. The fans are working very well at a low (70%) and high (100%) speed. I'm testing the automation using ESPHome and Home Assistant currently, and the major functions are working OK. The sensors are working as well as can be expected. The ENS160+AHT21 TVOC sensor is pretty cheap, and combines an ENS160 TVOC sensor with a AHT21 temperature and humidity sensor in one board. The downside is that the temperature and humidity sensor (AHT21) is used to calibrate the ENS160 TVOC sensor, but the ENS160 has a small heater which it needs to work, and that can affect the temperature sensor... which is used to calibrate the ENS160. That said I don't think it will be a big deal, since the board will be getting airflow, and really the TVOC value is just gonna be a relative thing, so the value doesn't have to be 100% accurate. I could add a 2nd temperature sensor, but that seems like it's just more complication and expense.
The OLED screen is small at 0.96", but it is readable. I may update the design to add the possiblity of using a larger 1.3" OLED, but those seem to be harder to find.
The switch is the one component I am a bit concerned about, since I had to order it from AliExpress. I didn't see any momentary RGB button switches that were reasonably priced on Amazon. However an RGB switch is not a requirement, and a non-RGB momentary (16mm) switch could be used instead. The RBG LED will be used to indicate fan or operational states, but other than that it just looks cool.
I still have to make some cosmetic adjustments to the UI, but all the functionality seems to be working well. I'm waiting on a momentary button switch with an RBG LED, but once I have that, the rest should come together, since the CAD design is over 95% complete.
Ultimately, when this project is done, I will be able to use this same controller (with some software tweaks) to control the window vent fan and booster fan which have been sitting at an almost done state for quite a while. A variation of this may even end up in the next version of the StoopidAire CR-Filter.
The pinouts, which I discovered based on tracing things on my board are:
CHANNEL 2 = G17
Channel 1 = G16
Status LED = G23
Switch = G0
Those pin mappings should be considered a starting point, since I don't know if all these boards are the same (they may look similar but they could be wired differently). I took a close look at mine (and from what I can make out), it uses a NCE6020AK MOSFET (60V/20A n-channel), with a small "J3Y" transistor (40V/0.5A NPN) which drives it. There is also a AMS117 3.3V/1A linear regulator for supplying the ESP32 and sensors.
The design goals of the project to update the filter are:
- Use cheap 2 wire 12v 5020 blower fans
- Local fan control with high, low and off speeds
- Optional automatic control of the fans using ESPHome and Home Assistant, but only when enabled
- Optional OLED display with 4 buttons to navigate and change settings
- Optional TVOC, Temperature and Humidity sensors
- Optionally the filter can be made with just 2 fans and a switch (full manual control, without any smart features)
So far all these goals have been met, or are in progress and almost completed. The fans are working very well at a low (70%) and high (100%) speed. I'm testing the automation using ESPHome and Home Assistant currently, and the major functions are working OK. The sensors are working as well as can be expected. The ENS160+AHT21 TVOC sensor is pretty cheap, and combines an ENS160 TVOC sensor with a AHT21 temperature and humidity sensor in one board. The downside is that the temperature and humidity sensor (AHT21) is used to calibrate the ENS160 TVOC sensor, but the ENS160 has a small heater which it needs to work, and that can affect the temperature sensor... which is used to calibrate the ENS160. That said I don't think it will be a big deal, since the board will be getting airflow, and really the TVOC value is just gonna be a relative thing, so the value doesn't have to be 100% accurate. I could add a 2nd temperature sensor, but that seems like it's just more complication and expense.
The OLED screen is small at 0.96", but it is readable. I may update the design to add the possiblity of using a larger 1.3" OLED, but those seem to be harder to find.
The switch is the one component I am a bit concerned about, since I had to order it from AliExpress. I didn't see any momentary RGB button switches that were reasonably priced on Amazon. However an RGB switch is not a requirement, and a non-RGB momentary (16mm) switch could be used instead. The RBG LED will be used to indicate fan or operational states, but other than that it just looks cool.
I still have to make some cosmetic adjustments to the UI, but all the functionality seems to be working well. I'm waiting on a momentary button switch with an RBG LED, but once I have that, the rest should come together, since the CAD design is over 95% complete.
Ultimately, when this project is done, I will be able to use this same controller (with some software tweaks) to control the window vent fan and booster fan which have been sitting at an almost done state for quite a while. A variation of this may even end up in the next version of the StoopidAire CR-Filter.
6/13/2026: The ESP Home side of things seems to be working well, but I need to tweak the screens since some of the text should look better if it's centered. I discovered that a simple thing like centering text in ESPHome can be a bit of a pain though, since every change means a re-compile, so I'm trying to find a better way to do it. It's not a big deal though, since it's only cosmetic, though I still want it to look decent.
I've been working on the Home Assistant side today with Perplexity, and I have to say our new AI overlords are pretty good at this stuff. They can sometimes forget where they were, but when they get their bearings they can really put some cool stuff together code-wise. I've tested the automation of the printer filter with my X1C, found a few bugs, optimized things and then retested, and now it's finally banging on all cylinders. The only downside is that putting the Home Assistant part together requires two "automations" and a "timer" (which is a "helper" in Home Assistant-speak). That is something I will need to write up, since before last week, I'd never set any of that stuff up in Home Assistant. Really though, it's not too difficult once the basics of Home Assistant are understood (or at least grasped). I think I'm getting there thanks to this project.
Below is a simple dashboard I set up in Home Assistant, which tracks some parameters on my X1C, and the "Printer Filter" (which is actually sitting on my desk). The dashboard has "sections" which are filled with "cards" that show all the interesting stuff. The cards look like they must be hard to set up, but really it's just a couple clicks and they work, since most are pre-templated and already have the parameters set up so they are ready to go.
On the left is the X1C related stuff, including a "tile" with a "Bambu Lab Print Status Card" which is something I found in the "community cards section when I went to set up the dashboard. Below that is an "Entity Card" with three "Entities" which are just parameters which Home Assistant (via the BambuLab-HA integration) is pulling from my X1C. These include the "Print Status" (running, failed, idle, etc), the "Aux Fan Speed" (this is the fan on the side of the printer), and "Print Error" which is just an error status (normally OK). One thing I didn't find was anything for the AMS filament loadout, however I need to look into that a bit more.
On the right side is where the fun begins for me. That's the section with some of the parameters that are available from the "Printer Filter" (which runs ESPHome on an ESP32-32E). The TVOC data is pulled from the ENS160+AHT21 module attached to the ESP32-32E, and the temp and humidity data are also pulled from that same module. All that stuff is sitting on my desk and barely held together with some jumper wires, worn out Dupont connectors and a splash of hope (and a breadboard). The cards on top show the "Printer Filter Mode" which is "High (100%)" currently, since a print is "running". The card next to that is "Printer Filter Auto Mode" which is "On". The ESPHome config is set up so the filter can be in "auto" or "manual" mode, where auto mode is required for Home Assistant to control it. The other cards are pretty self explanatory, but I thought the graphs for the Temp, Humidity and TVOC data were really cool. They are easy to set up in the dashboard too, since it's pretty much a few clicks and bam, there they are (no special config or coding required). Not shown (they are below where I screen grabbed the image), are cards showing the "Printer Filter IP Address", "Printer Filter SSID", "Printer Filter Uptime" and "Printer Filter RSSI" (which is measure of the WiFi signal strength).
Now that the Home Assistant and ESPHome configs are mostly done, I'm getting back to polishing up the CAD design of the V2 filter, with a few more optimizations and goodies (all internal changes, but may be appreciated during the build). And as I mentioned earlier, I still need to tweak the screens a bit on the filter, but that will just take some time and banging away at it till it looks better.
I've been working on the Home Assistant side today with Perplexity, and I have to say our new AI overlords are pretty good at this stuff. They can sometimes forget where they were, but when they get their bearings they can really put some cool stuff together code-wise. I've tested the automation of the printer filter with my X1C, found a few bugs, optimized things and then retested, and now it's finally banging on all cylinders. The only downside is that putting the Home Assistant part together requires two "automations" and a "timer" (which is a "helper" in Home Assistant-speak). That is something I will need to write up, since before last week, I'd never set any of that stuff up in Home Assistant. Really though, it's not too difficult once the basics of Home Assistant are understood (or at least grasped). I think I'm getting there thanks to this project.
Below is a simple dashboard I set up in Home Assistant, which tracks some parameters on my X1C, and the "Printer Filter" (which is actually sitting on my desk). The dashboard has "sections" which are filled with "cards" that show all the interesting stuff. The cards look like they must be hard to set up, but really it's just a couple clicks and they work, since most are pre-templated and already have the parameters set up so they are ready to go.
On the left is the X1C related stuff, including a "tile" with a "Bambu Lab Print Status Card" which is something I found in the "community cards section when I went to set up the dashboard. Below that is an "Entity Card" with three "Entities" which are just parameters which Home Assistant (via the BambuLab-HA integration) is pulling from my X1C. These include the "Print Status" (running, failed, idle, etc), the "Aux Fan Speed" (this is the fan on the side of the printer), and "Print Error" which is just an error status (normally OK). One thing I didn't find was anything for the AMS filament loadout, however I need to look into that a bit more.
On the right side is where the fun begins for me. That's the section with some of the parameters that are available from the "Printer Filter" (which runs ESPHome on an ESP32-32E). The TVOC data is pulled from the ENS160+AHT21 module attached to the ESP32-32E, and the temp and humidity data are also pulled from that same module. All that stuff is sitting on my desk and barely held together with some jumper wires, worn out Dupont connectors and a splash of hope (and a breadboard). The cards on top show the "Printer Filter Mode" which is "High (100%)" currently, since a print is "running". The card next to that is "Printer Filter Auto Mode" which is "On". The ESPHome config is set up so the filter can be in "auto" or "manual" mode, where auto mode is required for Home Assistant to control it. The other cards are pretty self explanatory, but I thought the graphs for the Temp, Humidity and TVOC data were really cool. They are easy to set up in the dashboard too, since it's pretty much a few clicks and bam, there they are (no special config or coding required). Not shown (they are below where I screen grabbed the image), are cards showing the "Printer Filter IP Address", "Printer Filter SSID", "Printer Filter Uptime" and "Printer Filter RSSI" (which is measure of the WiFi signal strength).
Now that the Home Assistant and ESPHome configs are mostly done, I'm getting back to polishing up the CAD design of the V2 filter, with a few more optimizations and goodies (all internal changes, but may be appreciated during the build). And as I mentioned earlier, I still need to tweak the screens a bit on the filter, but that will just take some time and banging away at it till it looks better.
6/28/2026: Since the Home Assistant and ESPHome code seems to be done, aside from some possible cosmetic tweaks to the text, I've been working on a few optimizations to the CAD design. I also added some parts to accomodate the four types of OLED display boards with buttons that I've acquired over the course of this project. There will now be options to use a 0.96" or a 1.3" OLED display (of which there are three types). The 0.96" OLED board seems to be very common and consistent as far as the design, but the1.3" OLED displays seem to be more difficult to source with several variants (unless of course they are bought from AliExpress, and then it's no problem to find them). I've found that there are two sizes of the 1.3" OLEDs with the buttons to the side (which look very similar, see pics 2 and 3 below), so I designed parts for each type to avoid problems with sourcing parts. I also made the buttons larger and better to read.
Although I expect that people would power the filter with a DC power supply, I've made a USB-C PD trigger option as a power input. Unfortunately, 24V fans are not really supported by the common USB PD modes, so 12V fans are the only real option for using the PD trigger. I've also been testing some 6000rpm 12V 5020 blowers, and have found they are a nice upgrade over the somewhat generic "GDSTime" 5020 fans I've been using. Both will however work, and I think the PWM fans I was using in the V1 of this design (which I gave away so cannot check), were not high power fans either, and they worked fine.
Since this design is meant to be flexible, one of the goals was to make it work with a number of different budgets. The high end design could cost $40-50 for the parts (or more depending on sourcing and shipping costs), while the low end design could be built for as little as $10. So I've also been working to make sure the simplest builds will also have some options to use different parts. The most basic configuration would be the fans, a power switch and a DC jack. Some WAGO blocks will simplify wiring (but are optional), and the design will accomodate 12 or 16mm switches, with or without a wiring clip. The swicthes I'm designing around are about 3 bucks on AliExpress, though any switch that fits a 12mm or 16mm diameter panel mounting hole should work. Those switches (which were linked) are only for the basic configuration though, since the configuration with all the Home Assistant stuff will require a lower profile 16mm momentary switch, due to the limited space inside the electronics compartment.
Right now I'm waiting on one more batch of parts from Adafruit. They have a neat I2C hub board, which will really help to clean up the wiring on the "smart" version of this fan. I should be getting those parts this next week, and can then do some final test builds to check everything out.
Although I expect that people would power the filter with a DC power supply, I've made a USB-C PD trigger option as a power input. Unfortunately, 24V fans are not really supported by the common USB PD modes, so 12V fans are the only real option for using the PD trigger. I've also been testing some 6000rpm 12V 5020 blowers, and have found they are a nice upgrade over the somewhat generic "GDSTime" 5020 fans I've been using. Both will however work, and I think the PWM fans I was using in the V1 of this design (which I gave away so cannot check), were not high power fans either, and they worked fine.
Since this design is meant to be flexible, one of the goals was to make it work with a number of different budgets. The high end design could cost $40-50 for the parts (or more depending on sourcing and shipping costs), while the low end design could be built for as little as $10. So I've also been working to make sure the simplest builds will also have some options to use different parts. The most basic configuration would be the fans, a power switch and a DC jack. Some WAGO blocks will simplify wiring (but are optional), and the design will accomodate 12 or 16mm switches, with or without a wiring clip. The swicthes I'm designing around are about 3 bucks on AliExpress, though any switch that fits a 12mm or 16mm diameter panel mounting hole should work. Those switches (which were linked) are only for the basic configuration though, since the configuration with all the Home Assistant stuff will require a lower profile 16mm momentary switch, due to the limited space inside the electronics compartment.
Right now I'm waiting on one more batch of parts from Adafruit. They have a neat I2C hub board, which will really help to clean up the wiring on the "smart" version of this fan. I should be getting those parts this next week, and can then do some final test builds to check everything out.
7/7/2026: Few things ever works out as planned seems to be a rule I keep hitting in projects like this. I thought I had the design finalized, so printed some parts only to find that there was an interference problem I had missed. At least it wasn't an obvious problem, but it required some major reworking of some parts which will take hours more to re-print. I have a growing collection of parts that were almost (but not quite) there, sitting around my desk. Fortunately I have enough filament (I hope) to complete this project in the colors I would like to use for it.
Building the prototype also informed me on how much I hate soldering tiny wires to boards. These are wires which are 28ga or smaller so they really are not meant to be soldered into through holes on boards like the dev board I'm testing, but for a prototype it's fine. Soldering pin headers designed for through hole soldering is much easier, so I decided to see if there was room for a breakout board on top of the ESP32, and it appears there is (though it has limitations in this design). There is no breakout board for the dev board though, so I knew it would mean trying to remember how to design one from scratch. I've used Eagle many years ago for a few projects and though it was difficult it still worked out, so decided to go for it. I posted a bit about the breakout board below, which took much longer than expected but I'm happy (so far) with the result. I haven't ordered them yet, but plan to do that later this week, once I've given the board another fresh look to make sure I didn't screw something up.
The user interface is however done, or at least enough that I'm happy with it. I made some tweaks to it to clean up the text formatting and used Figma to help with the layout of the OLED screen. There is no tool I found that would help to design the layout, so Figma was useful to position text and other elements (MDI Icons), on a 128x64px field. From there I was able to use the pixel positions for the elements and bring those values into the ESPHome YAML by hand. It saved time but is not a perfect process, which took several iterations to get things just right. The images below show some of the screens and how the final design should operate based on the program. The electronics side in the final design will be similar, just with another option of using a breakout board to simplify the wiring. The rats nest of wiring in the images is actually not that bad once the wire management is taken advantage of, but since the wire manager sits where the breakout will go, I will need to design another option for wire management with the breakout.
The last image shows a 470μF electrolytic capacitor on the power input of the board, which was put there due to the board controlling fan motors (inductive loads). I wasn't having any problems with the prototype during testing without that capacitor, but it's one of those things which is just nice to have. I've said this before, but I'm no expert with electronics, and have not tested with my cheap scope multimeter, but usually with motors there can be an initial spike when they start up, which can cause some instability of the power flow to the more sensitive componenets like the ESP32 or the I2C sensors. The capacitor may help clean that up a bit, which may help in the long run. I could also put capacitors on the fans leads, but I think that may be unnecessary since they are so small and don't pull much power. Something to note about electrolytic capacitors is that they are polarized, so they must be installed with the stripe (with a small "-" sign) on the ground side, or they can get really unhappy and pop. My understanding is that it's also a really good idea to use a capacitor that has about twice the voltage rating of the voltage being used. I'm running the board at 12v, so that capacitor has a 25v rating. I think of it like a cup, if I need to fill it up with 12 oz of water, I don't want a cup that holds only 12oz of water, a 24oz cup would be much better. The capacitor rating of 470μF was just a guess, and was chosen since I had one handy and it should be more than enough for the job.
Building the prototype also informed me on how much I hate soldering tiny wires to boards. These are wires which are 28ga or smaller so they really are not meant to be soldered into through holes on boards like the dev board I'm testing, but for a prototype it's fine. Soldering pin headers designed for through hole soldering is much easier, so I decided to see if there was room for a breakout board on top of the ESP32, and it appears there is (though it has limitations in this design). There is no breakout board for the dev board though, so I knew it would mean trying to remember how to design one from scratch. I've used Eagle many years ago for a few projects and though it was difficult it still worked out, so decided to go for it. I posted a bit about the breakout board below, which took much longer than expected but I'm happy (so far) with the result. I haven't ordered them yet, but plan to do that later this week, once I've given the board another fresh look to make sure I didn't screw something up.
The user interface is however done, or at least enough that I'm happy with it. I made some tweaks to it to clean up the text formatting and used Figma to help with the layout of the OLED screen. There is no tool I found that would help to design the layout, so Figma was useful to position text and other elements (MDI Icons), on a 128x64px field. From there I was able to use the pixel positions for the elements and bring those values into the ESPHome YAML by hand. It saved time but is not a perfect process, which took several iterations to get things just right. The images below show some of the screens and how the final design should operate based on the program. The electronics side in the final design will be similar, just with another option of using a breakout board to simplify the wiring. The rats nest of wiring in the images is actually not that bad once the wire management is taken advantage of, but since the wire manager sits where the breakout will go, I will need to design another option for wire management with the breakout.
The last image shows a 470μF electrolytic capacitor on the power input of the board, which was put there due to the board controlling fan motors (inductive loads). I wasn't having any problems with the prototype during testing without that capacitor, but it's one of those things which is just nice to have. I've said this before, but I'm no expert with electronics, and have not tested with my cheap scope multimeter, but usually with motors there can be an initial spike when they start up, which can cause some instability of the power flow to the more sensitive componenets like the ESP32 or the I2C sensors. The capacitor may help clean that up a bit, which may help in the long run. I could also put capacitors on the fans leads, but I think that may be unnecessary since they are so small and don't pull much power. Something to note about electrolytic capacitors is that they are polarized, so they must be installed with the stripe (with a small "-" sign) on the ground side, or they can get really unhappy and pop. My understanding is that it's also a really good idea to use a capacitor that has about twice the voltage rating of the voltage being used. I'm running the board at 12v, so that capacitor has a 25v rating. I think of it like a cup, if I need to fill it up with 12 oz of water, I don't want a cup that holds only 12oz of water, a 24oz cup would be much better. The capacitor rating of 470μF was just a guess, and was chosen since I had one handy and it should be more than enough for the job.
RSS Feed
