Reverse Engineering Lutron Clear Connect A (433 MHz)

Lutron makes lighting controls. Most of their product lines — Caseta, RadioRA2, parts of Homeworks — communicate over 433 MHz using a protocol Lutron calls Clear Connect Type A, or CCA. It's a one-way radio protocol: remotes and sensors transmit, dimmers and switches receive. No encryption, no acknowledgment packets, just commands broadcast into the air.

I've a lot of time poking at this protocol, first casually and then with increasing intent. The work builds heavily on research by Andrew Dodd and Corry Lazarowitz, who identified key details like the CRC polynomial and modulation parameters years before I got involved. What I've added, with substantial help from Claude Code as an analysis tool, is enough understanding to transmit arbitrary CCA packets and pair virtual devices to real hardware.

The code is available at github.com/alxgmpr/lutron-tools.

Background

Lutron's product lines share a lot of hardware but are segmented by firmware. A Caseta dimmer and a RadioRA2 dimmer might use the same radio and the same physical chipset, but a Caseta device won't pair to a RadioRA2 system and vice versa. This extends across their commercial lines too — Vive, Quantum, and others all use CCA but maintain their own pairing boundaries.

The practical consequence is that a surplus Vive PowPak module (commonly available on eBay for well under $100, since commercial surplus doesn't move fast) can't talk to a $360 RadioRA3 hub, even though it's the same radio technology underneath. And building a system large enough to hit the device count limits on a Caseta hub means buying additional bridges and stitching them together through HomeKit or Home Assistant.

None of this is malicious on Lutron's part — product segmentation is standard practice, and the firmware differences serve real purposes like enabling different feature sets at different price points. But it does mean there's a large pool of capable, affordable hardware that's artificially isolated.

How CCA works

CCA devices are addressed by hardware IDs, similar in concept to MAC addresses. When you pair a Pico remote to a dimmer, the dimmer enters a pairing mode and listens for remotes broadcasting their IDs and capability parameters. The dimmer stores the remote's ID and from then on responds to commands from that address.

Pico remotes are stateless. They don't know what the light is doing. When a Pico does something that seems stateful — like saving a favorite light level — it's actually sending a "save favorite" command to the dimmer, which stores the value against that remote's hardware ID.

The command vocabulary is richer than you might expect from a one-way protocol:

• Basic on/off/raise/lower/favorite from Pico remotes
• Scene commands from 4-button Picos
• Favorite-save and scene-save commands
• Reset commands (makes devices in earshot forget a specific ID)
• Press/hold/release states for each button
• Set-level and report-level events between dimmers and bridges
• Beacon commands that put Caseta dimmers into bridge-pairing mode

Bridge-paired devices get a richer set of capabilities. A dimmer paired to a Caseta Smart Bridge can report its current level, accept specific percentage commands, and be configured remotely. The bridge pairing process is slightly different from simple remote pairing and involves a handshake I haven't fully replicated yet.

Every CCA transmission follows the same on-air framing: a 32-bit preamble for clock sync, a 0xFF sync byte, the literal bytes 0xFA 0xDE as a secondary framing marker, and then a 24-byte payload encoded with 8N1 bit framing at 62.5 kBaud. The payload carries a type byte, sequence number, 4-byte device ID, a format byte that determines the command structure, and a CRC-16 computed with Lutron's specific polynomial (0xCA0F). The sequence number increments by 6 per key event — each increment maps to one TDMA slot (12.5ms), so +6 = one 75ms frame boundary. Click through the fields below to see how a packet is assembled:

How I got here

I'd tried the obvious approaches before and gotten nowhere. rtl_433 with an RTL-SDR Blog V4 could receive signals but I couldn't make sense of them in isolation. FlipperZero replays didn't work — CCA isn't a simple on-off-keyed signal you can record and play back.

The approach that finally worked was building a feedback loop. I soldered leads to the button pads of a physical Pico remote and wired them to optocoupler relays driven by an ESP32. I paired that Pico to a real dimmer. Then I pointed an RTL-SDR at the whole setup and gave Claude Code programmatic access to both the GPIO pins (to trigger button presses) and the SDR receiver (to capture the resulting transmissions).

This created a closed loop: the agent could press a button, observe the RF output, form a hypothesis about the packet structure, and test it. The existing research from Andrew and Corry provided the foundation — the modulation scheme, the CRC polynomial, the general packet framing — and the agent could iterate on the remaining unknowns much faster than I could manually.

I'm not particularly good at RF. I'm a software person, and RF analysis involves a lot of analog thinking that doesn't come naturally to me. The agent approach let me contribute what I could (physical hardware setup, device collection, system knowledge) while offloading the signal analysis iteration.

It took about three days of continuous work before the first successful virtual pairing — a device ID I made up, transmitted from a CC1101 module, accepted by a real Lutron dimmer as if it were a genuine Pico remote.

What matters about this

The immediate practical result is that you can pair arbitrary virtual devices to any CCA hardware. An ESP32 with a CC1101 radio module (total cost around $10) can impersonate any number of Pico remotes, which means it can control any CCA device regardless of which product line it belongs to. This effectively removes the firmware-level boundaries between Lutron's systems for anyone willing to set up the hardware.

The longer-term possibility is an open source bridge that exposes CCA devices over a local API. Where a Caseta Smart Bridge tops out at 75 devices, an ESP32 has no such limitation. And where Lutron's bridges only work within their own product line, a custom bridge could address devices across all of them.

Open questions

The bridge pairing protocol is the main gap. Remote pairing is solved — I can pair virtual Picos to any CCA device and send the full range of remote commands. But bridge pairing unlocks features like setting exact dim levels, reading back current states, and configuring device parameters (fade rates, trim levels, LED behavior). I have partial captures of bridge pairing sequences but haven't been able to replay them successfully yet.

What's next: CCX

With CCA increasingly understood, the natural next target is Clear Connect Type X — Lutron's newer 2.4 GHz mesh protocol. CCX is a fundamentally different animal: encrypted, bidirectional, and based on Thread/802.15.4. It powers RadioRA3, Homeworks QSX, and the Ketra line. I'll write about that separately.