FAQ
TL;DR: With 320 KB SRAM and a quoted breakthrough — "XR auth disabled" — this FAQ shows XR806/WXU thermostat modders how to open Tuya TRVs, dump firmware, build XR806 SDK demos, and understand why OpenBeken now boots and serves a web UI, while Wi‑Fi stability and TuyaMCU work still need fixes. [#21524634]
Why it matters: This thread turns a vague "WXU might be XR806" hunch into a repeatable path for teardown, flashing, SDK builds, and first-boot OpenBeken testing on real Tuya thermostats.
| Option |
Result in thread |
Main limitation |
| Stock Tuya WXU firmware on original device |
Boots, exposes TuyaOS logs, Wi‑Fi + BLE seen |
Closed firmware, no alternative control path proven |
| Dumped WXU image flashed onto XR809 |
Did not boot |
XR806/XR809 firmware mismatch |
| XR806 SDK demos |
hello_demo and Wi‑Fi demos built and ran |
menuconfig options needed |
| OpenBeken on XR806/WXU |
Boots and later serves web UI |
Wi‑Fi, config, MAC, and TuyaMCU issues remained during testing |
Key insight: The project stopped being blocked by flashing and basic booting. The real breakthroughs were proving that WXU is XR806-class hardware in practice, and then finding that the missing XR806 web GUI was caused by HTTP auth behavior, not a dead HTTP server.
Quick Facts
- Tuya WXU was discussed as XR806-class hardware because logs showed XR806 SDK v1.2.1/v1.2.2, 160 MHz CPU, 40 MHz HF clock, Wi‑Fi, and BLE on real thermostat hardware. [#21429243]
- The thread compared memory claims directly: Tuya WXU listed 320 KB SRAM, while one XR806 spec mentioned 288 KB SRAM, which caused early confusion about whether WXU was a Tuya-specific variant. [#21429143]
- A real TuyaOS boot log on WXU showed TuyaOS V3.6.3 built on 2024-07-18, with xr806_lowpower_common_ty 1.1.4 and a product AP named SmartLife-4649. [#21429243]
- XR806 flashing and logging used different serial paths in practice: successful tests showed firmware output on the flashing UART, while boot logs from stock firmware were often captured on a different UART. [#21430698]
- OpenBeken config saving started working after moving XR806 sysinfo to 0x1FC000, leaving about 12 KB free before the end of a 2 MB flash. [#21533999]
How do I open a Tuya TRV heater device with the WXU/XR806 module without damaging the display or board?
Open it in four careful steps. 1. Pull off the plastic turning wheel with steady force. 2. Remove the round battery cover underneath it. 3. Unclip the display with a small screwdriver. 4. Remove the 3 top screws and lift out the board. This sequence was reported as "very easy to open" and was used successfully before board removal and flashing work.
[#21429214]
What is the Tuya WXU module, and how is it related to the XR806 chip used in thermostats and TRVs?
The Tuya WXU module is an embedded Wi‑Fi and BLE module that appears XR806-based in these thermostats. "WXU is an embedded wireless module that provides Wi‑Fi and Bluetooth Low Energy connectivity, and in this thread its boot logs matched XR806 SDK builds, clocks, and radio firmware." The strongest evidence was real boot output showing XR806 SDK, 160 MHz CPU, 40 MHz HF clock, and TuyaOS on a WXU-equipped TRV.
[#21429243]
What is TuyaMCU, and why does it matter when replacing firmware on a WXU/XR806-based thermostat?
TuyaMCU is the separate device-side controller that exchanges commands with the Wi‑Fi module over UART. "TuyaMCU is a microcontroller-side protocol layer that handles thermostat logic and sensors while the Wi‑Fi module exposes cloud or custom firmware features, usually over serial links such as 115200 baud." It matters because the original TRV used TuyaMCU, so OpenBeken must match that serial behavior before core heating functions work correctly.
[#21429324]
Why does flashing a dumped WXU firmware image onto an XR809 boot fail even though OpenBeken itself boots on XR809?
It fails because the dumped firmware targets XR806-class hardware, not XR809. A direct test flashed the WXU backup to XR809 successfully, but the board showed no life, no current draw, and no output on RX0 or RX1. In contrast, flashing OBK back onto XR809 restored a normal boot log on RXD0. That result strongly points to platform mismatch rather than a bad dump or bad flashing process.
[#21429353]
XR806 vs XR809: what are the practical differences for SDK compatibility, flashing pins, and OpenBeken porting?
They are similar enough for HAL reuse, but different enough to break direct firmware swaps. The thread found XR809 HAL code was about 99.9% reusable, and GPIO examples looked very similar between SDKs. The important practical differences were boot-pin behavior, build-system details, flash layout, and at least one efuse field difference such as EFPG_FIELD_MAC. That is why OpenBeken could be ported, yet still needed XR806-specific fixes.
[#21435819]
How do I put an XR806 or Tuya WXU module into download mode, and which boot pins actually need to be grounded?
Ground PB02 to enter XR806 download mode. Early testing assumed PB02 and PB03 both had to be grounded, mirroring XR809 habits. Later notes in the same work said only PB02 needs to be pulled low on XR806, including successful flash reads from a WXU after grounding PB02. That makes XR806 easier to place in download mode than expected.
[#21502313]
Why do I get a sync or 'synchron waiting' error when trying to read or flash an XR806, and how should TX/RX be wired?
Sync errors usually came from using the wrong UART pair or wiring TX/RX the wrong way. One tester fixed an XR-series sync issue after realizing the correct lines were UART0, not UART1. Another note added that for one XR case, RX had to go to RX and TX to TX for boot-log capture. If you see "synchron waiting," verify UART0 pins first and avoid assuming classic cross-over wiring.
[#21429353]
Which UART on the XR806/WXU is used for flashing and which one outputs the boot log?
They are not always the same UART in practice. A key test showed an XR806 sample did work, but its output appeared on the flashing UART rather than the log UART the tester first monitored. Earlier stock-firmware work also captured boot text from RXD0. The safe rule is to probe both serial paths before assuming the board is dead.
[#21430698]
How do I build XR806 SDK examples like hello_demo, wlan_demo, or at_demo with make menuconfig under WSL?
Build them from WSL with the SDK root as your working directory. 1. Install prerequisites such as build-essential and ncurses development packages. 2. Set the ARM GCC path in gcc.mk to the toolchain under sdk/tools. 3. Copy a demo defconfig, run
make menuconfig, then
make build or
make image. This flow worked under WSL2 after GCC and ncurses were fixed.
[#21432260]
What causes the lwip/netif.h missing error or OTA-related build failures in the XR806 SDK demos, and which menuconfig options fix them?
Those errors came from disabled network components in menuconfig, not from broken demo code alone. The
lwip/netif.h failure appeared while building at_demo, and enabling lwIP, WLAN, AP/STA options, and OTA made the build progress. The thread also called out
CONFIG_WLAN_AP,
CONFIG_WLAN_STA,
CONFIG_WLAN_MONITOR, and
PRJCONF_NET_EN as required for full WLAN command support.
[#21430812]
Why did OpenBeken on XR806 initially open port 80 but return no web GUI or empty HTTP responses?
The HTTP server thread was alive, but replies were blocked before a usable page reached the browser. Tests showed port 80 open on 192.168.51.1, accepted clients on fd 3, and received packets of about 453 to 479 bytes. Yet browsers reported
ERR_CONNECTION_TIMED_OUT or
ERR_EMPTY_RESPONSE. That proved the failure was in request handling or response generation, not in AP mode or TCP accept itself.
[#21524592]
How was the XR806 HTTP issue tracked down to web authentication, and what changed to make the custom OpenBeken page finally load?
It was traced to HTTP auth logic, then fixed by disabling the XR806 auth block path. Debug builds showed packet receipt, then repeated
HTTP packet with auth fail messages. After changing the XR806 auth behavior, logs switched to
XR auth disabled and
postany: send ..., and the custom OpenBeken page finally loaded. That was the first confirmed custom HTTP page running on XR806 in the thread.
[#21524634]
Where should the sysinfo/config flash offset be placed on XR806 so OpenBeken settings are saved correctly without breaking XR809 or XR872?
Place XR806 sysinfo at 0x1FC000 and gate it with an XR806-specific platform check. Direct testing showed OpenBeken started saving config correctly at 0x1FC000, with about 12 KB left before the 2 MB flash end at 0x200000. The thread explicitly warned not to hardcode that address globally, because XR809 and XR872 use different layouts and need separate handling.
[#21533999]
What is PhoenixMC, and how is it used with XR806 firmware images or upgrade commands during development?
PhoenixMC is the flashing utility used in this thread to parse, read, and write XR806 images. It successfully parsed SDK-built images, flashed stock and test binaries, and was later discussed as the possible path for an
upgrade command that could avoid manual boot-pin grounding. In practice, it was the main tool for dumping firmware, restoring backups, and verifying whether new XR806 builds booted.
[#21430654]
What are the remaining blockers for a fully working OpenBeken/OpenXR806 port on Tuya WXU devices, especially unstable Wi-Fi, MAC handling, config saving, and TuyaMCU support?
The main blockers were unstable Wi‑Fi behavior, wrong MAC handling, incomplete config persistence before the sysinfo fix, and unfinished TuyaMCU integration. One tester reported OpenBeken booted, exposed the web UI, but did not keep settings, did not enter STA mode, and still showed MAC inconsistencies. Another recurring issue was Wi‑Fi association without completing the full connection flow. By May 2025, XR806 builds existed, but the port was still a development target, not a finished daily-driver firmware.
[#21524739]
Generated by the language model.
