After decoding an XN297-style 2.4GHz protocol, a DIY builder rebuilt the light’s remote in hardware and turned its wall switch into a Home Assistant controller.
A homeowner has shown how a bargain-bin ceiling light with a proprietary radio remote can be folded into Home Assistant, but only after a lengthy process of sniffing the control protocol, rebuilding the transmitter around an ESP32 and nRF24L01+ module, and then reworking the wall switch so that it no longer cuts power to the lamp. The project began with a simple but awkward setup: the wall switch controlled mains power, while the remote handled the lamp’s richer functions such as brightness, colour temperature and mode changes.
The first task was identifying the radio technology. The obvious candidates were infrared, Bluetooth Low Energy, or a proprietary 2.4 GHz system. The author ruled out infrared quickly, then tested several phone apps that can bind to BLE-based lighting products. When that failed, the remote was opened and examined more closely. Its board markings and antenna layout pointed to 2.4 GHz radio, most likely in the nRF24/XN297 family rather than standard Bluetooth.
From there, the builder assembled a sniffing rig around an ESP32-S3 and an nRF24L01+ module, with an electrolytic capacitor placed directly across the module’s supply pins to stabilise it. The capture process relied on a promiscuous-style setup that listens for anything near the preamble of a packet, then logs repeated patterns while different buttons are pressed. That approach is similar to other ESP32-and-nRF24 reverse-engineering projects, including a Quntis light-bar controller and several Home Assistant guides that capture proprietary remote codes before replaying them from ESPHome. ESPHome’s own IR/RF Proxy component and community examples show the same general pattern of turning radio remotes into API-driven smart-home entities.
The captured traffic turned out not to be simple raw packets. Instead, the signal was scrambled in a way consistent with XN297-style devices, and the first successful decode came only after the correct bit rate was identified and the payload was unscrambled before checking the CRC. Once that was working, the protocol became readable: a five-byte address, an eight-byte payload, a phase byte, a device ID, command bytes and a checksum. The button presses were not absolute settings so much as relative actions, with separate commands for power, night mode, day mode, brightness up, brightness down and colour temperature cycling.
That mattered later, because the transmission side had to behave like the original remote rather than a conventional smart light. The ESP32 was turned into a transmitter that sends the same packet bursts on command from Home Assistant, with repeated frames to compensate for the lack of acknowledgement from the lamp. The author also considered the possibility that the device might reject replayed packets if a counter value was wrong, but the first lamp did not enforce that check. In practice, the system became a normal Home Assistant light entity plus extra controls for the functions the remote already exposed.
The wall switch proved more complicated than the radio link. Since the lamps now need constant power, the old switch could no longer interrupt the mains feed. Instead, the switch had to generate events for Home Assistant only. A Zigbee dimmer was repurposed for that job, while the live wire was permanently bridged so the ceiling light would stay powered. Home Assistant then interpreted single presses, double presses and brightness buttons to select between two lights and trigger their respective actions. The result is functional, if not especially elegant: there is a small delay, double clicks must be deliberate, and the setup depends on automation logic rather than a direct hardware circuit.
The story is not entirely finished. The first lamp now works from the phone, from voice control and from the wall, but the second fixture remains stubborn despite apparently using the same radio protocol and the same commands. The author suspects the replacement driver board in that lamp has tighter frequency expectations than the nRF24-based transmitter can match. A CC2500-based transmitter, which allows finer frequency adjustment, may be the next step. For now, though, the project stands as a detailed example of how far an ESP32, some radio analysis and an external ESPHome component can be pushed when a cheap remote-controlled light needs to become part of a proper smart-home system.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.
