Hacking A Cat Litter Box

[Joseph DiGiovanni] is the owner of a Litter Robot 4. It’s a convenient mechanized litter box for cats that can clean itself to reduce unwelcome odors inside the home. He wanted to run automations based on the operation of the litter box, but was not eager to use the manufacturer’s cloud service to do it. Instead, he set about reverse engineering the device for his own ends.
Since the Litter Robot 4 relies on an ESP32 microcontroller for external connectivity, it was entirely possible for [Joseph] to whip up a custom firmware for the device instead. He started with ESPHome as a base, which is a popular firmware used for building smarthome devices based on Espressif hardware. The architecture of the Litter Robot 4 helped in this regard. It uses a PIC microcontroller to handle the low level hardware control, while the ESP32 is responsible for connecting to the cloud over WiFi. This allowed [Joseph] to mess with the connectivity features and get the device hooked up to Home Assistant without compromising the basic mechancial functionality of the device or any of the safety features.
All [Joseph] had to do was figure out how the original hardware’s ESP32 talked to the PIC and emulate that in his own firmware, which was achieved with some snooping and data capture and processing with an LLM. This was used as a basis to whip up an ESPHome firmware that could integrate the hardware neatly with Home Assistant.
Files are on Codeberg for those eager to tinker. It’s not the first time we’ve looked at cat litter management, and it won’t be the last. Video after the break.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)

Facts Only

* Joseph DiGiovanni owns a Litter Robot 4.
* The device is a mechanized litter box for cats that cleans itself.
* The Litter Robot 4 uses an ESP32 for external WiFi connectivity.
* The device utilizes a PIC microcontroller for low-level hardware control.
* The ESP32 handles cloud connectivity.
* Joseph reverse-engineered the device instead of using the manufacturer's cloud service.
* He used ESPHome as a base firmware.
* Communication between the ESP32 and the PIC was emulated in custom firmware via snooping, data capture, and processing with an LLM.
* The resulting firmware allowed for neat integration with Home Assistant.

Executive Summary

Joseph DiGiovanni sought to automate the operation of a Litter Robot 4, which is a mechanized litter box for cats that cleans itself. Rather than using the manufacturer's cloud service, he decided to reverse engineer the device for self-hosted automation. Since the device uses an ESP32 for WiFi connectivity, Joseph developed custom firmware based on ESPHome. The hardware architecture involved a PIC microcontroller for low-level control and an ESP32 for cloud connectivity. This setup allowed Joseph to integrate the device with Home Assistant while preserving its mechanical functions and safety features. The process required snooping and data capture from the original hardware's communication between the ESP32 and the PIC, which was processed using an LLM to develop the integration firmware.

Full Take

The narrative demonstrates a pattern of circumventing proprietary systems by exploiting underlying hardware architecture to achieve functional autonomy. The motivation shifts from simple product use to deep system control, driven by a desire for self-sufficiency outside vendor-imposed limitations. The use of reverse engineering, leveraging existing open-source frameworks like ESPHome, and employing an LLM for the complex task of emulating low-level communication illustrates a modern approach to hardware hacking that bridges embedded systems knowledge with large language model capabilities. The implication is that control over IoT devices often requires bypassing established protocols or services, turning vendor lock-in into a target for independent modification. The work touches upon questions of digital agency: who controls the data and the automation flow when external cloud services are intentionally bypassed? What are the long-term security implications when custom firmware relies on interpreted processing like LLMs to manage critical hardware interfaces?