My custom Wii remote dev log.
The ESP32 devkit is on the bench and talking to the Wii.
We got pairing working and built a quick adapter: your computer sends button commands over UART, the ESP32 broadcasts them as real Wiimote button presses. You can control the console in real time from the keyboard. It works, and it’s pretty cool.
That’s the firmware proof-of-concept out of the way. Next step is actually designing the board.
Started building a 2026 version of a Wii remote.
Why? My Wii remotes are dying. The only replacements are 10-year-old units on eBay that are also dying, or third-party knockoffs that are uniformly terrible. Nintendo stopped making these years ago and the supply is just slowly evaporating.
The Wii Remote is a surprisingly simple device once you crack it open:
That’s basically it. The sensors talk to the Bluetooth chip over I²C at 100 Hz, the Bluetooth chip packs the data into HID reports, and the Wii does the rest. There’s no fancy fusion happening on the remote, no proprietary handshake (well — there’s some XOR “encryption” on the extension port but it’s been fully reverse-engineered for over a decade).
The Bluetooth protocol is completely open source thanks to the WiiBrew community and projects like fakemote. Every HID report format, every register address, every weird edge case in the pairing flow — all documented. So the firmware side is “tedious but tractable,” not “research project.”
Modern silicon is just better. The original Wiimote shipped in 2006 with:
In 2026, the equivalents are dramatically better and often cheaper. A modern ESP32 has 10× the processing power and built-in Bluetooth Classic. A BMI270 or ICM-42688 IMU is a real 16-bit 6-axis sensor with way better noise performance. PixArt’s current MOT sensors track 16 blobs at 140° FOV instead of 4 at 33°. A Li-ion + USB-C beats AA batteries on every axis. And we can integrate the MotionPlus gyro into the base device instead of needing the dongle.
The goal: a remote that the Wii cannot tell apart from a real Wiimote, but feels better to use because of better motion sensing, wider IR field of view, USB-C charging, and (probably) better build quality than a 20-year-old molded plastic shell.
Phase 1 is firmware. The microcontroller dev board (an ESP32-DevKitC-32E — uses the WROOM-32E module, which is the only current ESP32 variant that still supports Bluetooth Classic; everything else went BLE-only) arrives this week. The single most important thing to verify, before I spend a dollar on a custom PCB, is:
Can an ESP32 convince a Wii that it’s a real Wiimote?
If yes, the whole project is just engineering from there. If no, I need to rethink the radio choice. So that’s milestone 1.
The work is mostly building the right Bluetooth SDP service record (the Wii is picky about it — wrong vendor ID, wrong HID descriptor, wrong reconnect flags, and it just refuses to pair) and then making the ESP32 advertise as Nintendo RVL-CNT-01 with VID 0x057E and PID 0x0306. The fakemote project on GitHub already has every byte of the Wiimote’s SDP record reconstructed, so it’s mostly porting that to ESP-IDF.
Once pairing works, I’ll add hardcoded button reports, then wire up an MPU-6050 I already have for accelerometer data (it’s an older, worse IMU than what I’ll use for the final build, but for “does the bowling ball in Wii Sports respond to tilt” it’s totally fine), then the IR camera, then I have a fully functional janky breadboard Wiimote.
The IR camera is the only really annoying part of this project, because the Wiimote doesn’t actually use an “IR camera” in the normal sense — it uses a sensor with hardware blob detection. The sensor doesn’t return an image; it returns coordinates of bright IR spots, processed onboard at 100 Hz. That’s how the original remote did pointing with a 2006-era 24 MHz CPU.
So I have two options:
Option 1 it is.
Once the breadboard prototype talks to the Wii, the rest is honestly the fun part — just designing the actual PCB in KiCad and picking peripherals:
JLCPCB for fab and assembly. The only part that’s going to be a pain to source is the PAJ7025R3 (PixArt sells primarily B2B), but a few hobbyists have made it work — worst case, hand-solder it after JLC does the rest of the board.
The skeptical version of this project is “Nintendo had a whole hardware team working on this, what makes you think you can do it solo.” The honest answer is that I’m not really inventing anything — the WiiBrew community already reverse-engineered every protocol, the open-source firmware projects already wrote the hard parts, and 2026 silicon is doing in one $3 chip what Nintendo needed five separate ICs to do in 2006. I’m mostly just integrating.
The architecture is genuinely simple. Two sensors, one radio, a bit of bit-packing in firmware, a power circuit, a shell. The hard parts are already solved. I just need to put them together.
Parts arrive this week.