Idiots guide to getting an esp32 to control AC Infinity Cloudline EC fans esphome/HA

lemo-uguu said:

I started in Fritzing too and felt its limits fast. KiCad has a steeper learning curve but it’s completely free, rock-solid, and way more powerful for real-world PCB work. Once you get comfortable with schematics, footprints, and the 3D viewer, you’ll never look back. And the community library support keeps growing, so you rarely have to build a part from scratch.

Click to expand...

I needed a footprint for something and it wasn't in the library. I started Googling and found a lot of things about, "DO NOT ASK US TO DESIGN FOOTPRINTS!" and realized that a lot of people must have expected to get footprints designed. I looked up info on that and found it was really easy to do it. Once you get used to KiCad, it makes sense. So many times technical programs are so tough to get anything done on them unless you have spent years using it, but KiCad's UI is well designed.

lemo-uguu said:

Yes, you can absolutely hack a D1 Mini to bit-bang ~12–14 kHz using a timer interrupt—it’ll spin the fan fine for bench tests or a single-fan breadboard prototype. In my testing, I scoped the stock AC Infinity controller’s D– line and saw right around 13–14 kHz, so I matched that with a hardware timer on the ESP8266.

Click to expand...

So you are doing well with testing your device hooked up to the fan? That's always an exciting and satisfying step - when you get your designs to just "drop in" to another system and to work well with them!

lemo-uguu said:

• Heads-up: at that rate you’re servicing an ISR ~24 000×/s, so Wi-Fi and HA MQTT can stutter under load. It works for a prototype, but for Rev 2 I’m moving to an ESP32-C3 so I can offload the PWM to the LEDC hardware PWM peripheral—no CPU hit and rock-solid timing.

Click to expand...

I'm not sure, but I *think* that ESPHome uses ledc for PWM, so wouldn't that be doing the same thing?

lemo-uguu said:

Running a small OLED (SSD1306) over I2C on an ESP8266 is doable (plenty of examples in ESPHome), but if you want a full-color TFT + touch you’ll want the extra RAM and SPI channels of the ESP32. I’d prototype on the D1 Mini for the PWM & tach logic, then switch to a C3 or C2 dev module when you add the UI layer, but since you're already using an ESP32, I wouldn't worry about going backwards to an ESP8266. It's just what I had lying around and I've got a ton of them. lol

Click to expand...

I don't need full color - B&W would work. Of course, color is nice. The issue I'm having is that I need a good scope, since my cheap one doesn't always show waveforms like it should. But, hey, it was a $45 o-scope! Considering that, when I was learning basic electronics, scopes were those big things on carts, like the old Tektronics ones, I'm just amazed there can be ANY kind of o-scope that cheap AND small!

Anyway, there are other ESP32 projects that are better at working with screens than ESPHome - but they don't output PWM that I can verify is good and useable with my fans (without a good scope). So I can either use a good scope and adjust the frequency in the source code and recompile whatever project I use, or I can use ESPHome and deal with the pain it'll take to get it working with a good touch screen I can get easily. A side note on this is also that a lot of screens take a number of pins and I still need 4 GPIO pins I can use to control the fans.

lemo-uguu said:

I've done extensive searching but unable to find anything to just 'plugs in' to their EC fans and allows control via ESPHome / Home Assistant. You’re right to be cautious. I’d brand it “Universal EC Duct Fan Controller” or something generic, and in the fine print note “compatible with AC Infinity Cloudline.” Avoid using their name in your product title or logo to stay under the trademark radar. Worst case, they may send a Cease & Desist, but keeping things generic and noting “for 10 V PWM EC fans” usually keeps you in the clear. Plus does AC Infinity really want to spend the resources and lawyers for a $20-30k market? lol

Click to expand...

I think we're in sync with those issues. I haven't seen anything, but I suspect it's because nobody wants to market their device for a lot of reasons. (Especially liability.) In my case, my device works, but I also would not market it without adding a touch screen. Beyond that, though, I cobbled it together. I'd have to pay an electrical engineer to review the design and verify I didn't do anything stupid and that it will work as I think it does before I'd market it.

And if I did, I would be doing just what you said. Advertise it as a generalized device, but include that it works with AC Infinity fans of certain models. (And I'd find other fans to find out which other ones it could work with - I think that's increase the market for it. It'd be nice to market it and say it works for half a dozen to a dozen fans. (That would be after testing it with them all, of course.) I'm sure it'd be possible to include a few things like DIP switches or jumpers so people could configure it for different fans. (For instance, other fans may use a different PWM frequency. I can think of several ways to use DIP switches to set the frequency.)

ImaginaryTango said:

I'm not sure, but I *think* that ESPHome uses ledc for PWM, so wouldn't that be doing the same thing?

Click to expand...

By default on an ESP32 ESPHome’s output.ledc platform drives the PWM pin through the built‐in LEDC hardware peripheral, not a software ISR. That means your duty-cycle is rock solid at whatever frequency you choose, with zero CPU overhead (unlike the bit-bang method on an ESP8266). Really using PWM with the ESP32 can change the frequency via software, so no DIP switches would be needed.

ImaginaryTango said:

Anyway, there are other ESP32 projects that are better at working with screens than ESPHome - but they don't output PWM that I can verify is good and useable with my fans (without a good scope). So I can either use a good scope and adjust the frequency in the source code and recompile whatever project I use, or I can use ESPHome and deal with the pain it'll take to get it working with a good touch screen I can get easily. A side note on this is also that a lot of screens take a number of pins and I still need 4 GPIO pins I can use to control the fans.

Click to expand...

You mentioned you don’t need full-color. An I²C SSD1306 OLED uses only two pins (SDA/SCL), leaving you 2–3 more GPIOs for buttons, sensors or LEDs. That keeps your interface footprint small and avoids wrestling with an SPI-TFT driver in ESPHome.

lemo-uguu said:

By default on an ESP32 ESPHome’s output.ledc platform drives the PWM pin through the built‐in LEDC hardware peripheral, not a software ISR. That means your duty-cycle is rock solid at whatever frequency you choose, with zero CPU overhead (unlike the bit-bang method on an ESP8266). Really using PWM with the ESP32 can change the frequency via software, so no DIP switches would be needed.

Click to expand...

It's a trade-off. Doing it with hardware adds an expense. I thought about doing it with software, but I was thinking in terms of safety. At some point, I'll be needing a part-time employee to help me with handling CNC work and keeping the 3D printers going from one project to the next. I figure 99% of the time the fans will be controlled automatically, by the controller I'm making for the CNC. (It'll turn them on when the laser goes on and will have a delay when it goes off, to allow smoke to be vented, then turn them off.) But I always design for any "what-if" I consider at all reasonable to happen. I could see a time when someone else may be using the ESPHome webpage to turn the vent fans on or off.

If the frequency control is handled purely by software, then it's on the web page, where someone can accidentally (or out of curiosity) change it. The idea of DIP switches (or jumpers) is that they would be on the board, within the 3D printed case. So they'd only be accessible if the case was opened up and most people know not to touch such things. (Yes, they can still mess it up - but I think that makes it hard enough to get to the configuration settings that it takes a pretty determined person or one who wants to break things to mess it up.)

If the ESPHome webpage could be password protected, I would consider doing it with software only.

lemo-uguu said:

You mentioned you don’t need full-color. An I²C SSD1306 OLED uses only two pins (SDA/SCL), leaving you 2–3 more GPIOs for buttons, sensors or LEDs. That keeps your interface footprint small and avoids wrestling with an SPI-TFT driver in ESPHome.

Click to expand...

Thank you! Do you know, off the top of your head, if it works with ESPHome? You mention the need to not have to mess with drivers, but it'd still need setup through ESPHome and to communicate with the settings. (And I like that it's not an "Alibaba only" product - very frustrating when it can take weeks to get a component!)

ImaginaryTango said:

It's a trade-off. Doing it with hardware adds an expense. I thought about doing it with software, but I was thinking in terms of safety. At some point, I'll be needing a part-time employee to help me with handling CNC work and keeping the 3D printers going from one project to the next. I figure 99% of the time the fans will be controlled automatically, by the controller I'm making for the CNC. (It'll turn them on when the laser goes on and will have a delay when it goes off, to allow smoke to be vented, then turn them off.) But I always design for any "what-if" I consider at all reasonable to happen. I could see a time when someone else may be using the ESPHome webpage to turn the vent fans on or off.

Click to expand...

This is where Home Assistant 'Automations' come into play. Eg, if CNC is on, turn fan on. If CNC turns off from on state, leave fan running 5mins. Or you could get super fancy and do some sort of air sensor that will kick the fan on when co2 or particulate ramps up. You can get as creative as you want.

ImaginaryTango said:

If the frequency control is handled purely by software, then it's on the web page, where someone can accidentally (or out of curiosity) change it. The idea of DIP switches (or jumpers) is that they would be on the board, within the 3D printed case. So they'd only be accessible if the case was opened up and most people know not to touch such things. (Yes, they can still mess it up - but I think that makes it hard enough to get to the configuration settings that it takes a pretty determined person or one who wants to break things to mess it up.)

Click to expand...

In my rev2 board, I've added a bunch of fail safes. It'll have 2 USBC ports, one for programming the ESP32 and one for the fan input, but I've put controls in place in the event someone swaps the plugs, or even has both of them plugged in at the same time. Mainly diodes for the power rails, and I've added an USBLC6-2SC6 for each port as well to be extra careful with static or any sort of hazardous environment the sensor might find itself in.

ImaginaryTango said:

If the ESPHome webpage could be password protected, I would consider doing it with software only.

Click to expand...

I'm pretty certain you can have a password for the webpage, but like I mentioned earlier, it's better to do a flow with Home Assistant so it will do it automatically so you don't have to mess with it, then there will be options in Home Assistant to toggle it on and off. HA has a very robust security function for authentication and has users with group permissions if you want to go that far.

ImaginaryTango said:

Thank you! Do you know, off the top of your head, if it works with ESPHome? You mention the need to not have to mess with drivers, but it'd still need setup through ESPHome and to communicate with the settings. (And I like that it's not an "Alibaba only" product - very frustrating when it can take weeks to get a component!)

Click to expand...

Currently my only use case is with ESPHome, then tied into Home Assistant for all my automations. I have a bad habit of smoking cigars in the garage and with some of the air sensors I placed around the house and garage, I want the exhaust fan (The Air Infinity 8" fan) to run on till the air sensors read normal again when I decide to tinker out in the garage without killing myself 'faster'. lol

lemo-uguu said:

This is where Home Assistant 'Automations' come into play. Eg, if CNC is on, turn fan on. If CNC turns off from on state, leave fan running 5mins. Or you could get super fancy and do some sort of air sensor that will kick the fan on when co2 or particulate ramps up. You can get as creative as you want.

Click to expand...

I'm doing this a little differently. I know I can forget things, like turning fans on and off. But I also know I can dive in and set up an automation and forget about how I did it or what it needs. So I try to get things set up to allow for that. In this case, in ESPHome, you can make a copy of an object and add to it. It reminds me of inheritance, but it's not really that. So I have my binary sensors for the switches for the machinery. Then I have the copies and those copies have a delay for turning off, so that does the delay all in the control box. I'm thinking, since that box is bigger than the fan control, of adding either an LCD digit display and a control knob to set the delay length, or using an LCD touch screen to change the delay settings. I have thought about sensors, and may change to then, but I also want to see if I want the fans to remain on even when I was just using the CNC instead of the laser. I may want that as well, since it'll help keep the sawdust it generates from blowing out into the rest of the room. But even that (the sawdust) may be seen by a sensor.

Please don't think I'm just trying to shoot down every idea - you have some good ones and they are things I keep in mind if my plans change!

lemo-uguu said:

In my rev2 board, I've added a bunch of fail safes. It'll have 2 USBC ports, one for programming the ESP32 and one for the fan input, but I've put controls in place in the event someone swaps the plugs, or even has both of them plugged in at the same time. Mainly diodes for the power rails, and I've added an USBLC6-2SC6 for each port as well to be extra careful with static or any sort of hazardous environment the sensor might find itself in.

Click to expand...

Sounds like you're kind of paranoid in a good way - like I am!

One thought on the USB ports - could you change the programming one to USB-B? Personally, I have a strong preference for USB-C for multiple reasons, but I was just thinking using 2 different types of ports would make it impossible to swap the plugs. But it sounds like you've got that issue solved within the circuitry itself. Just tossing out the thought.

lemo-uguu said:

I'm pretty certain you can have a password for the webpage, but like I mentioned earlier, it's better to do a flow with Home Assistant so it will do it automatically so you don't have to mess with it, then there will be options in Home Assistant to toggle it on and off. HA has a very robust security function for authentication and has users with group permissions if you want to go that far.

Click to expand...

I think you can use a password on the webpage - the issue is that if I did that, anyone working for me might need to get to the speed and on/off settings, and what I'd want to do is protect ONLY the config settings.

lemo-uguu said:

Currently my only use case is with ESPHome, then tied into Home Assistant for all my automations. I have a bad habit of smoking cigars in the garage and with some of the air sensors I placed around the house and garage, I want the exhaust fan (The Air Infinity 8" fan) to run on till the air sensors read normal again when I decide to tinker out in the garage without killing myself 'faster'. lol

Click to expand...

I like Home Assistant but - and I may have recently voiced this rant here - an upgrade can break it for several days while I spend a lot of time doing research on why things aren't working after I upgrade it. So everything will be controllable through HA, but the actual automations, like turning the fans on and off and setting the speeds, will be MQTT. I'm also setting up a warning sign at the workshop door, so I can alert people when a laser is in use so they can wear safety glasses before opening the door. That'll connect to the control box through MQTT as well.

I can see why the sensors would help if you're smoking cigars!

ImaginaryTango said:

I'm doing this a little differently. I know I can forget things, like turning fans on and off. But I also know I can dive in and set up an automation and forget about how I did it or what it needs. So I try to get things set up to allow for that. In this case, in ESPHome, you can make a copy of an object and add to it. It reminds me of inheritance, but it's not really that. So I have my binary sensors for the switches for the machinery. Then I have the copies and those copies have a delay for turning off, so that does the delay all in the control box. I'm thinking, since that box is bigger than the fan control, of adding either an LCD digit display and a control knob to set the delay length, or using an LCD touch screen to change the delay settings. I have thought about sensors, and may change to then, but I also want to see if I want the fans to remain on even when I was just using the CNC instead of the laser. I may want that as well, since it'll help keep the sawdust it generates from blowing out into the rest of the room. But even that (the sawdust) may be seen by a sensor.

Please don't think I'm just trying to shoot down every idea - you have some good ones and they are things I keep in mind if my plans change!

Click to expand...

I love the idea of baking in per-switch “off” delays in ESPHome itself—you’re right, copying a binary_sensor and tacking a delay_off on it keeps things self-contained. For Rev2 I’m planning to expose that delay as a variable in the firmware, too—so whether you tweak it over MQTT. That way you get both the “set-and-forget” convenience in Home Assistant and a physical override right at the box.

ImaginaryTango said:

Sounds like you're kind of paranoid in a good way - like I am!

One thought on the USB ports - could you change the programming one to USB-B? Personally, I have a strong preference for USB-C for multiple reasons, but I was just thinking using 2 different types of ports would make it impossible to swap the plugs. But it sounds like you've got that issue solved within the circuitry itself. Just tossing out the thought.

Click to expand...

Yep—I went a bit over-protective on the power rails (Schottky diodes, USBLC6 on both ports) so that swapping the prog and fan cables can’t hurt anything. I still like your USB-B suggestion for the prog port—it’d force folks to use the right cable for flashing. I’ll look into footprint size, but if I can fit a tiny Type-B it’d be a neat mechanical safeguard on top of the electrical ones.

ImaginaryTango said:

I think you can use a password on the webpage - the issue is that if I did that, anyone working for me might need to get to the speed and on/off settings, and what I'd want to do is protect ONLY the config settings.

I like Home Assistant but - and I may have recently voiced this rant here - an upgrade can break it for several days while I spend a lot of time doing research on why things aren't working after I upgrade it. So everything will be controllable through HA, but the actual automations, like turning the fans on and off and setting the speeds, will be MQTT. I'm also setting up a warning sign at the workshop door, so I can alert people when a laser is in use so they can wear safety glasses before opening the door. That'll connect to the control box through MQTT as well.

Click to expand...

Totally hear you on the split between local webpage and HA. My plan is to ship with MQTT controls only (no built-in web UI), then let users either talk straight to the device or put it under Home Assistant’s auth umbrella. That way I’m not wrestling with dual-passwords, and everything’s locked down behind whatever HA users/groups you’ve already got.

ImaginaryTango said:

Just note I was not saying that as an expert, more as someone who has read a lot of posts here and there are a few threads about it on Arduino forums. Basically, PWM is a way of setting voltage. I didn't dig into the details on how it's done. As for scopes, as I mentioned, I have a cheap one, I think it was $40 or $45. I'm going to get a good one. I can't remember the one I've seen recommended as a good starting scope that's solid and that I'll grow into, but it's something like $350. I've seen it recommended in a number of sources.

Click to expand...

Hey! sorry for the delay. Got some upcoming renovations at home and had to prepare things.

So my o-scope is a mid-range-ish one, a Hanmatek HO52 handheld (~150€). As I'm a hobbyist I didn't want to spend 300$+ in a scope.

ImaginaryTango said:

I am concerned that you're getting a clean square wave from the ESP32 and not one from there. What's the duty cycle on that wave? Is it close to 90%?

Click to expand...

The clean square wave comes out of the stock USBc controller. Not the ESP32

ImaginaryTango said:

I can't get the link to the Spain version of Amazon to open properly, even after filling out a CAPTCHA. Is it basically the same MOSFET that I linked to? I did not see anything like what you have from the output of my MOSFET. I would ask about it on Reddit's Ask Electronics subreddit. They're good at helping people there.

Click to expand...

It's the one the OP mentioned, this one:


I'm going to ask around about that. thanks!

ImaginaryTango said:

Is that USB-C cable with the leads coming out of it to your fan? I wouldn't connect until you're sure your circuit is putting out the right square wave. But no waves at all? I don't know. Could be an issue with the MOSFET ratings. And I'm sure you've done this, but double-check your pinouts. I've seen a few situations where I think I'm using one GPIO pin and I get the number of the GPIO mixed up with the actual pin number. Right now I wouldn't wire the fan in on it - just make sure you get the right square wave coming out of the MOSFET.

Click to expand...

It's not... yet . It's a workaround for debugging, but the power is coming from a cheap lab PSU with adjustable voltage/amps. I wanted to test it as close as possible to the final setup.


I also found this github where the guy uses a Shell RGBW2 flashed with ESP Home. But I'm having a hard time trying to flash it with an USB to TTL adapter.

Still trying tho!