Close
0%
0%

RaspiBright

Reverse-engineering the Aqueon OptiBright 433MHz remote control

Similar projects worth following
0 followers
Reverse-engineering the Aqueon OptiBright 433MHz remote control and re-implementing on RPi PicoW (or ESP32-S2, or whatever I have laying around at the time I get to it)

I decided to start this project when I eventually grew frustrated with the lack of scheduling options for the Aqueon OptiBright LED aquarium light. It comes stock with a fairly simple remote control, offering individual on/off schedules, brightnesses, and (for the RGB channel) colors for three channels: White, Blue, RGB. My goal will be to re-implement the remote's functions on a WiFi enabled project board, enabling advanced scheduling, scheduled color changes, direct connection to Home Assistant, etc.

While it works great for what I initially bought it for, it could be better! Rather than replace it with a new (more expensive) WiFi connected unit, I figured "How complicated could it be?" and decided that this would be my first hardware reverse-engineering project. Of course I had to pick one that involved radio, because why should it be simple? I've sniffed out Zigbee packets to create SmartThings device handlers with a degree of success before, though the Zigbee Alliance provides documentation for the protocol. For this one, I'm on my own.

The FCC listing for the remote (FCCID AD8Y-15720) has sparse details, appearing to have some info withheld at the request of the manufacturer. It does have some teardown shots, revealing a RFM110 ASK/OOK radio module, confirming my assumption that this is a 433MHz device and that it's using a fairly simple modulation scheme.

Next steps, acquire an SDR dongle and start capturing some transmissions!

dump2.txt

tweaked decoder a bit, all level values for only blue and only rgb

plain - 387.30 kB - 03/02/2026 at 18:45

Download

dump.txt

rtl_433 dump using custom flex decoder

plain - 255.02 kB - 02/27/2026 at 18:48

Download

  • Progress!

    Mitch Pond3 hours ago 0 comments

    Finally cracked what is going on with the checksum. The CRC algo is running on an 8 byte value, but our data is 7 long. The low byte is being padded with 0x00 due to the buffer being initialized to 0x0000000000000000 and the packet shifted in. CRC byte is added to the end of the packet, there appears to be a zero stop bit or some other inter-packet padding that rtl_433 was interpreting as data. D'oh!

    Yeah, this is my first time reverse engineering an RF protocol...

View project log

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates