Replaying a "Universal 24V Fan Controller" (rtl_433 decoder #286) remote — fan doesn't respond despite clean, checksum-valid transmissions

Hi everyone! I’m trying to find support in using a ESP32 device to replicate the RF signals of two 433 MHz remotes that control 2 ceiling fans so that I can automate them in HA. I tried multiple receivers and transmitters, together with a SDR dongle and SDR_433, but I’ve had no luck so far. I’m trying to summarize my findings below. **Goal** Replace/replicate two physical 433MHz remotes (Eubea DC ceiling fans, rebranded “UniFan-24V” / rtl_433 decoder 286, “Universal (Reverseable) 24V Fan Controller”) with an ESP32-based transmitter, so Home Assistant can control the fans directly. **Protocol (confirmed via rtl_433 decoder 286 source)** - OOK, PWM encoding - 0 = 756µs pulse + 252µs gap; 1 = 256µs pulse + 756µs gap - Sync pulse ~3616µs, frame repeated ~7x with ~8200µs gaps - 33-bit frame: 20-bit address, 5-bit button code, 3-bit repeat-index (not a security rolling code — just a frame-repeat counter, confirmed by observing it cycle 0-7 automatically every ~2s independent of button presses), 4-bit checksum (XOR-fold of first 4 bytes must equal 0xA), 1 fixed trailing bit - Real remote’s Transmitter button codes confirmed via live capture: All Off=25, Speed 1-6=15/13/3/21/16/19, Fan(Breeze)=10, Fan Off=9, Forward=27, Reverse=14. Light-related buttons (Light On/Off=30, Luminance+=17, Luminance-=28) decode as “Unknown” in the generic decoder table but pass checksum validation — likely a manufacturer-specific overlay on the base protocol. **What’s confirmed working** - Real remote reliably controls the fan from ~20-25 meters through multiple concrete floors (fan audibly beeps on accepted commands) - Reconstructed frames (encoded from scratch using the known protocol spec, not replayed captures) pass checksum validation and decode correctly via rtl_433 as valid {33} frames matching the intended button code - Real remote’s actual carrier measured via RTL-SDR: ~433.902-433.906 MHz (varies slightly run to run), about -14 to -18 kHz off nominal 433.92 MHz - Hardware tried - ESP32 + STX882 (fixed SAW resonator ASK TX module) — clean, checksum-valid transmissions confirmed via rtl_433, but carrier consistently ~+37 to +38 kHz off nominal (measured against the real remote’s ~433.906 MHz, this module sits close to 433.958 MHz) — no fan response even at point-blank range - ESP32 + FS1000A (same class of module) — same story, carrier off by +49 to +55 kHz, no fan response - ESP32 + CC1101 (SPI-controlled synthesizer transceiver, native ESPHome cc1101: component, dual-pin wiring GDO0→remote_transmitter, GDO2 unused) — frequency is programmable and was tuned to match the real remote (~433.906-433.923MHz tried, converged to within about 3kHz of the real remote’s measured carrier via side-by-side RTL-SDR comparison) — still no fan response even at point-blank range, despite matching peak signal strength (about -20dB) to the real remote on the same SDR at the same distance **The open anomaly** With the CC1101, rtl_433 (-A pulse analyzer mode) intermittently fails to decode the transmission at all (“Guessing modulation: No clue…”, garbled pulse widths mixed with the expected 772µs/272µs timing — spurious ~48-170µs fragments appear inconsistently). This happens unpredictably: same config, same distance, sometimes decodes perfectly ({33}7a3fcc838-style clean output matching intended payload), sometimes fails completely. Not clearly correlated with power level (10dBm vs 11dBm), distance, or the specific frequency setting tried. **What would help** - Has anyone seen this generic-24V-fan-controller protocol before, or knows if there’s a receiver-side quirk (minimum RSSI gate, specific preamble requirement, timing tolerance) beyond what rtl_433’s generic decoder captures? - Any experience with CC1101 native ESPHome component producing intermittent/garbled OOK output specifically (vs. clean output at other times) — config issue vs. hardware fault? - Suggestions for isolating “digital pulse train from ESP32/CC1101 before RF stage” — planning to use a logic analyzer/oscilloscope to probe the actual GDO0 pin directly, bypassing RF entirely, as the next diagnostic step, and would appreciate validation that this is the right next move vs. something else worth trying first. **Tools/references used so far** - rtl_433 v25.12 + Nooelec NESDR SMArt v5 (RTL-SDR) - SDR++ v1.3.0 for spectrum/waterfall visualization - ESPHome 2026.7.0/2026.7.4, native cc1101: component ([CC1101 Low-Power Sub-1 GHz RF Transceiver - ESPHome - Smart Home Made Simple](http://esphome.io/components/cc1101/)) - Reference project with a different but architecturally similar fan (different protocol, same STX882 hardware, succeeded): [GitHub - GuillaumeBerland/ArubaPlusInspire · GitHub](http://github.com/GuillaumeBerland/ArubaPlusInspire)