# OpenBK7231T_App: firmware that turns cheap Tuya modules into MQTT devices

> An open firmware alternative to Tasmota for Beken, Tuya and a widening list of chipsets, built for the specific problem of reflashable Wi-Fi modules found in budget smart home hardware.

**openshwprojects/OpenBK7231T_App** — Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601, BL602, LN882H, Realtek chips and more

- Repository: https://github.com/openshwprojects/OpenBK7231T_App
- Website: https://openbekeniot.github.io/webapp/devicesList.html
- Stars: 2,317 · Forks: 623
- Language: C
- License: not declared
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/openshwprojects-openbk7231t-app

## A repository named after one chip that now covers a dozen vendors

The repository name says OpenBK7231T_App, and the README addresses that directly. It says the project has evolved into a multi-platform application supporting builds for chipsets from ESWIN, Transa Semi, Lightning Semi, Espressif, Beken, WinnerMicro, Xradiotech and Allwinner, Realtek, and Bouffalo Lab.

The Beken chips remain the origin story. The list starts with BK7231T, naming modules such as the WB3S and WB2S that Tuya sells, then BK7231N with the CB2S and CB2L, BK7231M described as a non-Tuya version of BK7231N with zero keys, BL2028N from Belon, then BK7236, BK7238 and BK7239N. There are also T-series variants, the T34 among them, which the README says can be flashed as if it were a standard BK7231N.

The Tuya detail matters more than it first appears. Tuya modules ship with keys burned in at the factory, and those keys authenticate your device to Tuya's cloud. Flash firmware built with zero keys and you break that link, which is precisely why someone flashing this needs to read the section about keys carefully. The README describes BK7231M and BK7231S as non-Tuya versions that usually come with 00000000 keys, and notes that a BK7231U intended for camera and display boards can be updated via SPI to use BK7231T firmware built with zero keys.

Beyond Beken the list runs long: XR809 and XR806 from Allwinner, BL602 from Bouffalo Lab, LeapFive's LF686, the TG7100C from T-Mall, WinnerMicro's W800 through W803 and W600 and W601, Lightning Semi's LN882H, Espressif's ESP32 family through the C61 and the ESP8266 and ESP8285, and several Realtek Ameba families including RTL8710B, RTL8710C, RTL8720C and RTL8720D.

## Some of these chips can only be recovered over JTAG, so read before you flash

The README is candid about recovery, and this is the single most important thing to read before touching any of this hardware.

The RTL8711AM entry says it requires SDRAM, and that it cannot be flashed via UART, only via JTAG or SPI. If your board uses that chip and you do not have a JTAG adapter, you cannot recover it from a bad flash. The same entry names the WRG1 module.

Several BL602 entries carry a similar warning with a workaround. For the TG7100C and LF686, the README says to use the latest toml file in BLDevCube for 2MB BL602 parts, and it provides separate forum guides for factory firmware backup and restore. That phrasing tells you the factory firmware is something you are expected to save before overwriting, not recover afterwards.

The release notes repeat the same warning on every build. Versions tagged alpha are described as development builds that may not be stable, with a direct instruction not to flash all your devices at once and a reminder to make sure you can recover them via UART in case of unexpected issues.

That is good practice stated plainly, and it is the reason to treat this as a project for people who already own JTAG tools or have a board they are willing to experiment on. The linked device list at the project homepage is where you check whether your specific board is supported before anything else.

## A Makefile of named variants over a pile of vendor SDKs

The build system is the clearest description of the project's shape. The root Makefile carries an unusual compatibility shim at the top, commented as a hack for when COMPILE_PREX is defined, which keeps an original SDK build script working. It notes the requirement not to break old build_app.sh lines 74 through 77, which tells you this project grew alongside a vendor toolchain rather than replacing it.

Under that shim sits a simpler Makefile of its own, and its most informative feature is the variant table. Named build targets map to numeric variant identifiers:

```makefile
ifeq ($(VARIANT),berry)
OBK_VARIANT = 1
else ifeq ($(VARIANT),tuyaMCU)
OBK_VARIANT = 2
else ifeq ($(VARIANT),powerMetering)
OBK_VARIANT = 3
else ifeq ($(VARIANT),irRemoteESP)
OBK_VARIANT = 4
else ifeq ($(VARIANT),sensors)
OBK_VARIANT = 5
```

The remaining variants are hlw8112, battery, btproxy and 2M, 4M and 2M_berry, where the flash size variants also set ESP_FSIZE. So the project's feature targeting is expressed as build variants: a power metering build, an infrared remote build, a sensor build, a battery build. That is a pragmatic way to handle a fleet of heterogeneous hardware where no single build fits.

The repository tree confirms the shape. There is a platforms/ directory holding vendor toolchains, an sdk/ directory, a src/ directory for the application, plus BUILDING.md and FLASHING.md as separate documents. There are also Windows batch files for specific targets, including obk_ln882h_build.bat, obk_rtl8710b_build.bat and run_800x600_port80.bat, along with a Visual Studio project for the Win32 simulator.

## A Gulp pipeline for the web interface, and a Python dependency on esptool

Some devices expose a configuration web interface, and that interface is built by a separate asset pipeline. The package.json at the root is named obk-builder with the description Gulp based script content builder, and it pulls in gulp 4 along with plugins for minification, gzip and renaming:

```json
"devDependencies": {
  "gulp": "^4.0.2",
  "gulp-cssnano": "^2.1.3",
  "gulp-gzip": "^1.4.2",
  "gulp-rename": "^2.0.0",
  "gulp-uglify": "^3.0.2",
  "through2": "^4.0.2"
  }
```

There is one real script, `getcommands`, which runs a script that scrapes commands out of the source so the web UI knows what the firmware supports. That is a small but telling design, since it means the interface cannot drift out of sync with the actual command set.

Flashing has its own dependency, and the requirements file is two lines long:

```bash
virtualenv
esptool
```

esptool is the standard tool for writing firmware to Espressif chips over serial, which tells you the flashing path for ESP devices is a well-trodden one. Other vendors have their own tools, which is why the BL602 instructions reference BLDevCube and why several README entries link to forum threads describing device-specific flashing sequences rather than one universal procedure.

One inconsistency worth flagging: package.json declares the license as ISC, while GitHub reports no license for this repository. The README does not state a license, and no LICENSE file appears in the tree. For firmware you are considering putting on devices you own, that gap is worth raising with the project before you build on it.

## Releases at a steady cadence, on a project with a very large issue count

The release history suggests an active project with a fast cadence. The three most recent tags are 1.18.314 from 2026-09-27, 1.18.313 from 2026-09-18 and 1.18.312 from 2026-09-15, and the last push recorded matches the newest release closely. Three releases in roughly two weeks, on a version line that has reached 1.18.314.

Every one of those release notes carries the same alpha warning, which is worth interpreting carefully. Because the numbered releases themselves carry the warning, the caution about alpha tags seems aimed at separately tagged development builds rather than at the version line generally. Either way, the instruction to recover over UART before updating applies.

The scale of the project shows up in the issue tracker, which has 634 open issues, alongside 611 forks and 2,308 stars. An issue count that large is what you would expect from a firmware project supporting dozens of chipsets across a long tail of device models, where each new unsupported board produces its own thread. It is a support burden rather than a quality signal, but it does mean the issue tracker is worth searching before you start, since your exact device may already be discussed there.

For orientation, the README lists device datasheets and forum threads rather than documenting each board itself, and the project homepage links to a devices list. That division is sensible given the variety, but it means the README's value is as a map of what is supported rather than as a set of instructions.

## Conclusion

The problem this firmware solves is narrow and real: a smart plug or sensor built on a three-dollar Wi-Fi module from Tuya or Beken, with an undocumented cloud protocol and a factory firmware that will stop working the day the vendor loses interest. Flashing open firmware onto that hardware is the only way to keep it useful, and this project supports an unusually wide chipset range to do it. What it is not is a general purpose firmware platform, and the build system reflects that: it is a collection of vendor SDKs under platforms/ driven by a Makefile with named VARIANT targets, plus a Gulp pipeline for the web interface. If your device is on the supported list, the README's flashing documents and the linked device list are where to start, and confirm your recovery path over UART before you begin, because a failed flash on some of these boards is otherwise unrecoverable.

## FAQ

### What is OpenBK7231T_App used for?

It is open firmware for cheap Wi-Fi modules found in budget smart home hardware, positioned as an alternative to Tasmota and ESPHome for Tuya and Beken-based devices. Flashing it gives the device local control over MQTT and Home Assistant instead of a vendor cloud protocol, which keeps the hardware useful after the vendor stops supporting it.

### Which chipsets does OpenBK7231T_App support?

The Beken BK7231T, BK7231N, BK7231M, BK7236, BK7238 and BK7239N are the origin targets. The README also lists BL2028N, the T-series including the T34, XR809 and XR806, BL602, LF686, TG7100C, WinnerMicro W600 through W803, LN882H, the Espressif ESP32 and ESP8266 families, and several Realtek Ameba families including RTL8710B, RTL8710C and RTL8720D.

### Can I recover OpenBK7231T_App if a flash goes wrong?

Usually over UART, and the release notes tell you to confirm this works before updating. Not every board is recoverable that way: the README notes the RTL8711AM, used in modules such as the WRG1, cannot be flashed via UART and requires JTAG or SPI. For BL602 parts it recommends backing up factory firmware first, since restoring it later depends on that backup.

### How do you build a specific firmware variant?

Builds are selected with the VARIANT make variable, where names such as berry, tuyaMCU, powerMetering, irRemoteESP, sensors, hlw8112, battery and btproxy each map to a numeric variant identifier, and 2M, 4M and 2M_berry set the flash size instead. The Makefile derives the app name from the folder and stamps a development version from the current timestamp unless you set one.

## Sources

- [Issues](https://github.com/openshwprojects/OpenBK7231T_App/issues)
- [openshwprojects/OpenBK7231T_App on GitHub](https://github.com/openshwprojects/OpenBK7231T_App)
- [Project website](https://openbekeniot.github.io/webapp/devicesList.html)
- [README](https://github.com/openshwprojects/OpenBK7231T_App/blob/main/README.md)
- [Releases](https://github.com/openshwprojects/OpenBK7231T_App/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openshwprojects-openbk7231t-app