Willy Firmware turns an ESP32 board into a Flipper Zero alternative

The same ideas as Flipper, on hardware you can buy for less

The pitch is stated plainly in the README: this firmware is an alternative to Flipper Zero for ESP32, and it is always updated from the original Flipper ideas, which is what the author calls making it the most stable alternative. The board is an ESP32 T-Display-S3, the radio module is a CC1101, and the display is a touchscreen. The stated goal is to benefit from the same functions as the Flipper Zero but on an ESP32, which is cheaper and easier to obtain in some countries, with regular updates driven by what the community wants. The project also points at a V3 firmware in a separate repository, and the site is willy-firmware.com with a Discord banner for the community. The two features the author highlights as the differentiators are breadth and stability. The firmware is described as feature rich, including all common applications in the SubGhz, infrared, BLE and WiFi areas as well as new features, and as stable, with many hours spent rewriting core parts of the firmware and some of its apps. The repository is not archived, the last push was on 2026-08-28, and there are no GitHub releases, so the firmware is distributed as source and images rather than as tagged binaries.

Read RAW and Read are different tools with different decoders

The SubGhz section is where the substance is, and the first distinction is between two reading modes. Read RAW reads and decodes signals in a raw format, including signals from remotes with unknown protocols, and you can save 30 signals in the memory. Read, by contrast, reads and decodes signals based on known protocols, and if the protocol is static then Willy decodes the signal, again with 30 signals savable in the memory. From either mode you can then send the signal or save it to the SD card for use later. The two lists of supported items are not the same, and that asymmetry is worth understanding before you buy hardware. The decoders list is shorter and is what Read can turn into a named protocol.

[Supported decoders]

* Ansonic (12bit)
* BETT (18bit)
* CAME (12bit)
* Chamberlain (7bit)
* Clemsa (18bit)
* Doitrand (37bit)
* Dooya (50bit)
* FAAC SLH (64bit)
* Hormann HSM (44bit)
* KeeLoq (64bit)
* Linear (10bit)
* Marantec (49bit)
* Nice FLO (12bit)
* Princeton (24bit)
* Starline (64bit)

The transmit list is longer still, because generating a signal needs the encoder for a protocol, and the extra entries include vendor specific variants that a decoder does not need.

[Supported protocols]

* Alutech AT-4N (72bit)
* Ansonic (12bit)
* CAME Atomo (62bit)
* Genie (64bit)
* Holtek (40bit)
* Hormann BiSecur (176bit)
* KingGates Stylo4k (89bit)
* KIA (61bit)
* LinearDelta3 (8bit)
* Megacode (24bit)
* Nice FloR-S (52bit)
* Security+ 2.0 (62bit)
* Somfy Keytis (80bit)
* Somfy Telis (56bit)
* UNILARM (25bit)

Scanner finds a frequency, jammer makes noise, and the law is watching

Two more SubGhz features complete the picture, and one of them carries a warning. The scanner works by having the device scan signal strength, RSSI, at all the frequencies available in the frequency configuration, then display the frequency with the highest RSSI value, with signal strength higher than configured. From there you can apply the found frequency to the general settings, which is the practical part: you point the device at a remote, find the frequency the remote actually uses, and configure the radio to it. That is a genuinely useful tool for anyone working with these systems, because the frequency is often the thing you do not know. The jammer function generates noise, and the README is direct about the risk: be careful when using this feature and ensure you follow the laws in your country, because this may cause interference and potentially disrupt the proper operation of some devices. That sentence is not boilerplate. A jammer is a radio transmitter by another name, and in many jurisdictions deliberately interfering with radio equipment is an offence regardless of intent. The repository also carries a Disclaimer section in its navigation, which tells you the author treats this as a real constraint rather than a footnote.

What the repository actually contains, and what it does not

The top level listing is short: an Image/ directory, README.md and an SD/ directory. That is a documentation and asset repository, not a firmware source tree, and the images in the README confirm it, since every screenshot points at a raw.githubusercontent.com path under a different repository, Willy_Firmware_CC1101. The image directory holds the logo and the photographs of the device, and the SD/ directory is for the SD card contents the firmware reads and writes, since the README repeatedly mentions saving signals to the SD card for later use and the decoders and protocols are the kind of data you would keep on a card rather than in firmware. The primary language for the repository is listed as HTML, which is consistent with a README that is mostly markup and screenshots. So the practical consequence for anyone evaluating this project is that you do not find the firmware source here, and the build instructions are not in the README either. The navigation links to Introduction, Features, Build, Contact and Disclaimer, so a Build section exists in the fuller README, but the excerpt available here stops partway through the features. The Board, Module and Display are named in the repository description, which is the most concrete hardware guidance on offer, and the file compatibility with Flipper Zero is stated there too.

Saving, sending and the memory limit of 30 signals

The workflow the README describes is consistent across the SubGhz features, and it is worth understanding because it defines what the device is for. You read a signal, either raw or decoded, and from there you can send it or save it to the SD card for use later. The memory limit is 30 signals for both Read RAW and Read, which is a small number and reflects the constraints of an ESP32 with a touchscreen, where storing captured waveforms is not free. The saved signals can then be transmitted by generating a signal based on a known protocol and key, and the transmit side has its own settings for repeat count, visible in the settings screenshots referenced for the transmit feature. The SD card is the answer to the memory limit, and it is also what makes the device useful as a capture tool: you read something once, save it, and the file is out of the device's internal memory. The Scanner output feeds the same loop, since the frequency you find becomes the general setting for the radio. The result is a device that can capture a signal it does not understand, file it, and transmit it later, which is the whole reason the raw mode exists in a product that otherwise just reproduces the Flipper feature set.

How it compares to the Flipper Zero it imitates

The comparison the project invites is with the original, and it is worth being precise about what is being matched. The claim is that the firmware is always updated from the original Flipper ideas, and the description states the file compatibility, so a Flipper file should be usable. What that does not claim is application parity, and the README does not list Flipper's full app set as a target. The difference in approach is the hardware and the price. A Flipper Zero is a dedicated device with a radio, a display and a well known app ecosystem, and the reason someone would replace it with an ESP32 board is cost and availability, as the author puts it, cheaper and easier to obtain in some countries. The difference in consequence is openness. The original is a commercial product with a curated application set and a controlled update process, while this is source you can read and change, and the repository's own release history is empty, so the firmware you run is whatever you flashed. Against a purpose built SDR dongle, the difference is that this device has a screen, a touchscreen and the familiar Flipper interaction model, so you get a display and a UI on hardware that would otherwise need a laptop. Against a jammer built for the purpose, the difference is that this one also does legitimate work first, which is the argument the author is making, and also the argument you have to make yourself before pressing the button.

Editorial conclusion

Willy Firmware suits a student or security engineer who wants to learn SubGhz decoding and transmission on a ten dollar board instead of a Flipper Zero, and who is prepared to flash firmware and solder a CC1101. It is the wrong tool if you need the Flipper ecosystem's own apps, since the compatibility claim is about files rather than the full application set, and it is the wrong tool in any country where the jammer function is illegal, which the README itself warns about. Before you build one, read the supported decoder and protocol lists in full, because the two lists are not the same and knowing which of your remotes is in which list is the difference between a working device and an afternoon spent in raw mode.

Frequently asked questions

Official sources

1. h-RAT/Willy_Firmware_V2_ESP32_Flipper_Zero_Alternative on GitHub
2. Issues
3. README