ESPHome CC1101 Success with MinkaAire Ceiling Fan (303.875 MHz)

txwindsurfer · June 3, 2026, 8:25pm

I recently set up the new ESPHome CC1101 component on an ESP32 DevKit board and wanted to share some findings that may help others.

Hardware
ESP32 DevKit VROOM
CC1101 8-pin module

Wiring:
CC1101 Pin 1 GND → ESP32 GND
CC1101 Pin 2 VCC → ESP32 3.3V
CC1101 Pin 3 GDO0 → GPIO26
CC1101 Pin 4 CSN → GPIO5
CC1101 Pin 5 SCK → GPIO18
CC1101 Pin 6 MOSI → GPIO23
CC1101 Pin 7 MISO → GPIO19
CC1101 Pin 8 GDO2 → GPIO27

Initial Results
The CC1101 initialized correctly and could immediately receive RF traffic.
The fan remote turned out to operate on 303.875 MHz rather than 433.92 MHz.

Using frequency: 303.875MHz allowed reliable reception of the MinkaAire remote. And,
ESPHome successfully decoded button presses using:

remote_receiver:
  pin: GPIO27
  dump:
    - rc_switch
  tolerance: 50%
  filter: 100us
  idle: 10ms
  buffer_size: 30kb

Example decoded values:
Stop: 000000111101
Speed 1: 000000110111
Speed 2: 000000110101
Speed 3: 000000101111
Speed 4: 000000100111
Speed 5: 000000011101
Speed 6: 000000011111
Reverse: 000000111011
An end code of:
000000111111
was transmitted after commands.

However this produced weak and unreliable operations transmitting the codes using:

- remote_transmitter.transmit_rc_switch_raw:

and the fan would only respond at very close range and often required multiple attempts.

Solution
Switching to raw codes produced dramatically better results. Captured the original remote waveform with:

remote_receiver:
  pin: GPIO27
  dump:
    - raw
  tolerance: 50%
  filter: 100us
  idle: 10ms
  buffer_size: 30kb

and replayed the captured waveform using for example this button for Stop:

 - platform: template
   name: MinkaAire Stop
   on_press:
     - remote_transmitter.transmit_raw:
         code: [300, -376, 650, -376, 625, -400, 626, -375, 651, -375, 625, -376, 650, -701, 300, -726, 300, -700, 301, -725, 301, -375, 625, -726, 300]
         repeat:
           times: 16
           wait_time: 20ms

Home assistant performance became comparable to the original remote and reliability improved substantially.

Recommendation
If you can successfully decode a device with rc_switch but transmission is unreliable, try capturing the actual waveform and replaying it with transmit_raw rather than relying on protocol-based retransmission.

For my MinkaAire fan this was the difference between "barely works" and "works like the factory remote."

Karosm · June 3, 2026, 9:33pm

If you set high tolerance, you always can get signal decoded with rc-switch. But it's total crap at certain point. 50% is not usable in any case.
And yes, always start with raw, at least you see how the real signal is.

busman · September 1, 2026, 2:46am

I haven’t been able to get the rc_switch or raw codes to work. I’m wondering what else to try.

I’m using an antenna from a 315Mhz garage opener – and I looked at it with my VNA and it does seem pretty good for that frequency. My CC1101 is probably a standard 433Mhz type.

Neither of these buttons work, for example:

remote_transmitter:
  - pin: ${pin_d1_cc1101_gdo2}
    carrier_duty_percent: 100%


button:
  - platform: template
    name: "Fan Off"
    icon: "mdi:stop"
    on_press:
      - logger.log: "Fan Stop"
      - remote_transmitter.transmit_rc_switch_raw:
          code: '001111000101'
          protocol: 6
          repeat:
            times: 5
            wait_time: 20ms

  - platform: template
    name: MinkaAire Stop
    on_press:
      - logger.log: "MinkaAire Fan Stop"
      - remote_transmitter.transmit_raw:
          #code: [300, -376, 650, -376, 625, -400, 626, -375, 651, -375, 625, -376, 650, -701, 300, -726, 300, -700, 301, -725, 301, -375, 625, -726, 300]
          #code: [337, -337, 674, -338, 574, -6486, 653, -679, 340, -350, 648, -697, 312 ]
          code: [300, -376, 625, -400, 626, -701, 300, -700, 301, -700, 300, -726, 275, -401, 125]
          repeat:
            times: 16
            wait_time: 20ms

It’s curious that the rc_switch sending doesn’t work because the codes I receive are pretty consistent. Here’s stop pressed:

[19:42:09.802][I][remote.rc_switch:260]: Received RCSwitch Raw: protocol=6 data='001111000101'
[19:42:09.819][I][remote.raw:035]: Received Raw: 311, -387, 624, -387, 405, -104, 127
[19:42:09.902][I][remote.raw:035]: Received Raw: 590, -702, 316, -354, 661, -682, 316
[19:42:09.920][I][remote.raw:035]: Received Raw: 338, -351, 641, -390, 618, -717, 291, -692, 316, -709, 243, -749, 220
[19:42:13.171][I][remote.rc_switch:260]: Received RCSwitch Raw: protocol=6 data='001111000101'
[19:42:13.191][I][remote.raw:035]: Received Raw: 312, -385, 634, -364, 649, -690, 314, -691, 317, -707, 286, -719, 265
[19:42:13.289][I][remote.rc_switch:260]: Received RCSwitch Raw: protocol=6 data='001111000101'
[19:42:13.307][I][remote.raw:035]: Received Raw: 312, -385, 600
[19:42:13.390][I][remote.raw:035]: Received Raw: 661, -677, 309

Karosm · September 1, 2026, 9:00am

Why should it work? Rc-switch protocol 6 uses 450, 900 pulse pairs.
Rc-switch sgnal captured with 50% tolerance is waste of time here.

busman · September 1, 2026, 4:36pm

Ok. When I run the tolerance lower no rc_switch values are printed, and if 50% is a waste of time then the curious part I mentioned is that the values it prints out are consistent.

Maybe that makes sense.

I’m not very clear what this means. Or why the number of pulse pairs impacts that:

tolerance (Optional, int, Time or mapping): The percentage or time that the remote signal lengths can deviate in the decoding process. Defaults to 25%.

Anyway, the other issue is on my SDR I can see the pulses sent by the MinkaAire remote (although they seems to have very wide bandwidth compared to, say, my garage door opener).

But, I cannot see anything on the SDR when I have the ESP transmit. I don’t know if that’s a bad CC1101, or if the common CC1101s I buy are so filtered for 433MHz that the 303MHz signal is completely filtered.

Looking at the CC1101 gdo2 pin with a scope I do see the pulses:

I’ve been looking for 315Mhz-labled CC1101s, although I just bought this “315MHz 3dBi SMA Male Antenna” and on the VNA it looks like this, which isn’t 315Mhz… It’s completely flat at 315MHz ;). So, not sure trust the CC1101 labeling.

Karosm · September 1, 2026, 6:04pm

Doesn’t sound good if your SDR generally works.

I’m not totally following you here with different equipment tests and I suggest you to open your own topic explaining what you have tried and what was outcome. You have nice set of tools, I’m sure this can be resolved. Also, post your whole code related to remote, including receive code and CC.

Few observations:
-Changing antenna doesn’t make your CC pure 315MHz device, the antenna circuit still remains tuned for 433.
-I remember successful use of 433MHz CC (with 433 antenna) for ~300MHz signal here on this forum. Quality and range suffer little bit but still acceptable.
-50% tolerance is no-sense because it just gives illusion that signal got decoded as protocol 6 even if it wasn’t protocol 6 signal. Also the pulse length range is getting so wide that 1 and 0 can overlap. And when you re-send this signal, it goes out with 450/900 timing and obviously that’s not what the original signal was.
-Clean raw dump is all you need, forget decoding completely.

busman · September 1, 2026, 7:29pm

Ok, I’ll create a new topic about the transmit not working.

Right, which is why I brought it up. Using an antenna tuned to the frequency I’m sending at is important – but doesn’t help if the CC1101 is filtering anything too far outside of of 433MHz.

It was dumb not to try trasmitting at 433MHz and see if the SDR can see it then. I’ll give that a try. A nice spectrum analyzer would be handy, but is still outside my price range…

Update: answer is nothing seen when transmitting at 433MHz. I assume bad CC1101. Verified wiring again.