What you’d need before you open the lid
A spare Litter-Robot 4 mainboard, an ESP-Prog-2 debug adapter, a 6-pin header, a fine-tip soldering iron, and a scalpel to scrape conformal coating off an unpopulated debug pad. That was the bench setup Joseph DiGiovanni worked from when he replaced the Wi-Fi firmware on Whisker’s automatic litter box with ESPHome. Buying the spare board first is the part worth copying: it lets you probe UART traffic and flash bad builds without bricking the unit sitting in your hallway.
What the firmware actually buys you
The stock Litter-Robot 4 routes its status through Whisker’s cloud, so an ISP outage or a discontinued service takes your automations with it. The ESPHome build talks straight to Home Assistant over the LAN. Start and pause cycles, reset the machine, toggle the night light, lock the front panel, change the cycle delay, and read litter level, drawer status, motion, and weight — all locally, with no telemetry leaving the house. The weight readings are precise enough to tell two cats apart, which the official app cannot do. Sleep schedules also become per-day across all 7 days instead of one weekday/weekend split.
Why swapping the firmware is not as reckless as it sounds
The mainboard carries two processors. A PIC microcontroller owns the motors, safety sensors, weight cells, and buttons. The ESP32 next to it does almost nothing except bridge Wi-Fi to UART, relaying packets between the cloud and the PIC. Reflashing the ESP32 changes how the box talks to the outside world and never touches the safety logic that stops a running drum. That split is also what made the reverse engineering tractable: DiGiovanni soldered onto the exposed 3.3 V debug header, captured serial traffic while pressing physical buttons and firing commands from the phone app, then diffed the hex packets against known status changes until the protocol fell out. He prototyped in ESPHome YAML first, then moved the working decode into a proper C++ ESPHome component that builds commands, parses replies, and publishes entities.
Where it stands
Mainboard firmware updates are still unsupported, LitterHopper is not wired up yet, and only the Litter-Robot 4 is covered. The original firmware can be dumped and restored, so a failed experiment costs you an afternoon rather than the appliance. If you want the same trick on a cheaper target, the general recipe transfers: find the ESP32 that acts as a bridge rather than the brain, sniff its UART at 115200 baud, and rebuild the protocol in YAML before you commit to C++. Read the full teardown at Hackster, and grab an ESP32-S3 dev board from Circuit.Rocks if you want to practice the UART sniffing on something you do not mind breaking.
Frequently Asked Questions
Is reflashing the ESP32 risky for the machine’s motors?
No. The Litter-Robot 4 mainboard splits duties between two chips: a PIC microcontroller drives the motors, weight cells, and safety sensors, while the ESP32 only bridges Wi-Fi to UART. Reflashing the ESP32 changes the communication layer and leaves the safety-critical control logic untouched. The stock firmware can also be backed up and restored.
What hardware do I need to attempt this?
An ESP-Prog-2 (or any ESP32 JTAG/UART programmer), a 6-pin header soldered onto the board’s unpopulated debug pads, a fine-tip iron, and something to scrape the conformal coating. A spare mainboard is strongly recommended so you are not experimenting on the unit you use daily.
What will I learn if I build this?
Serial protocol reverse engineering, which is a transferable skill for thesis and capstone work: capturing UART traffic, diffing hex packets against known state changes, and rebuilding the decode as a reusable component. You also pick up ESPHome YAML, custom C++ component authoring, soldering onto fine-pitch debug headers, and how to reason about which processor in a two-MCU design is safe to modify.
