--- title: "FreeFall 800 removes the cloud from a grill without replacing its controller" locale: "en" url: "https://irz.fr/en/articles/freefall-800-open-firmware-en" markdown_url: "https://irz.fr/en/articles/freefall-800-open-firmware-en.md" category: "tech" tags: ["firmware", "reverse-engineering", "ESP32", "repair", "open-source"] published_at: "2026-08-19T08:22:00.000Z" author: "Manon Girard" translation: "https://irz.fr/fr/articles/freefall-800-open-firmware-fr.md" --- # FreeFall 800 removes the cloud from a grill without replacing its controller The Gravity 800 controller already contained a programmable ESP32. FreeFall 800 keeps that board and moves remote control back onto the local network, with explicit security limits. A connected grill can keep heating long after its app becomes useless, and that split is exactly what makes FreeFall 800 worth examining: the physical machine may be healthy while part of its normal use still depends on infrastructure elsewhere.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) PRBS23 approached the Masterbuilt Gravity 800 from the opposite direction. Rather than replacing the whole controller, FreeFall keeps the existing electronics and changes the firmware, allowing the ESP32 inside the grill to serve its own web interface on the local network.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) In hindsight, the route looks almost obvious, because so much of the required computer was already sitting inside the controller. We only know that after somebody opened the box. ## The useful surprise was already on the board The project began with a mundane repair after a power lead had been pulled from the controller. Opening the enclosure revealed an ESP32-WROOM-32UE and an accessible programming header on the board, which turned a proprietary appliance controller into a plausible reverse-engineering target.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) Masterbuilt had already chosen a general-purpose Wi-Fi microcontroller, so most of the electrical relationship between probes, fan and front panel already existed in the board. If we look at the project from that point of view, the hard part moves into understanding the behaviour of the factory firmware and reproducing the useful pieces of it. After several months of work, FreeFall 800 v0.1.0 can handle chamber and probe temperatures, fan control, alarms, timers, calibration and over-the-air updates on the local network.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) The firmware is written in Rust and released under GPLv3.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/)[2](https://gitlab.com/prbs23/freefall_800/) None of this gives the grill a spectacular new talent; the useful change is in the path of control, because one external dependency disappears. ## The commands take a shorter route In the factory system, remote features rely on Masterbuilt's mobile app and hosted infrastructure. In FreeFall, the web application is served from the controller itself, so a phone or computer in the same network can talk directly to the grill.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) Most of the everyday remote-control loop therefore moves into the home: temperature plots, set points, probe targets and fan information are handled in the local network, with no remote account in the middle of those interactions.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) The trade-off appears as soon as the user leaves home, because Masterbuilt's service acts as an intermediary for remote access while FreeFall deliberately stays inside the local network unless the owner builds another route into it.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) To be sure, removing a service does not remove the work that service used to perform. It changes who has to perform it. ## Reverse engineering becomes missing documentation An exposed programming header lowers the hardware barrier, but it says very little about the rest of the appliance. The work still includes the mapping of sensor inputs, fan control, buttons, display behaviour and interlocks, along with the conversion of electrical readings into meaningful temperatures. FreeFall even migrates the calibration already stored by the factory firmware during initial setup.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) That detail captures the difference between running software on the correct chip and replacing the embedded logic of an appliance: the relationship between the code in the ESP32 and the machine producing real heat has to survive the transition. The public repository therefore becomes a kind of executable service manual.[2](https://gitlab.com/prbs23/freefall_800/) It records what the community has learned about the controller, what currently works and where the project remains fragile, giving owners a second maintenance path for hardware that was never sold as an open development platform. ## Local control also inherits local problems The project's own warnings matter here. Version 0.1.0 is explicitly alpha, was developed against a specific controller revision and factory firmware version, and may behave differently on other revisions.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) More importantly, the current release has no serious authentication layer. A person who can reach the controller over the network may be able to control the appliance, which is why the author warns against exposing it directly to the internet.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/) A simplistic “local good, cloud bad” story falls apart here. A remote service creates dependency, but it may also provide authentication, distribution of updates and easy access from outside the home; taking control back means inheriting some of those operational responsibilities. On an appliance that regulates heat and pushes air into burning charcoal, that responsibility is not theoretical. So if we want a useful question, “cloud or local?” is too small. **Who maintains each layer, and for how long?** gets closer. ## A proprietary controller becomes a computer again While everything works, connected features feel like permanent properties of the object. Buy a grill with a Wi-Fi icon and it is easy to assume that the metal, microcontroller, phone app and remote service will all age on the same schedule. They do not. Mechanical parts, embedded electronics, mobile software and hosted infrastructure can each outlive or abandon the others, and a failure at one layer can remove features from hardware that remains entirely capable of doing the underlying job. FreeFall 800 shows what can happen when the electronics leave enough access for the software layer to be rebuilt. There is no promise of universal compatibility or immortality; what changes is simpler. The existing board stops acting mainly as a terminal of someone else's service, and the ESP32 becomes an embedded computer its owner can once again understand and program.[1](https://www.prbs23.com/blog/posts/announcement-freefall-800/)[2](https://gitlab.com/prbs23/freefall_800/) That is already a meaningful repair. Nothing on the board had to be replaced. The repair changed who controlled the useful part of the computer already inside it. ## References 1. [PRBS23, Announcement: FreeFall 800 v0.1.0](https://www.prbs23.com/blog/posts/announcement-freefall-800/) 2. [FreeFall 800 source repository](https://gitlab.com/prbs23/freefall_800/)