logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
UV printer on your desk?
UV printer on your desk? Discover eufyMake E1 »
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

New firmware for WT5 Multi-Channel LED controller with RF - TuyaMCU?

Kinsi55 13272 107
Best answers

Can I flash alternative firmware on a WT5 multi-channel LED controller and use it as a TuyaMCU device with RF still working?

Yes — the WT5 was identified as a TuyaMCU-style device, so flashing the WB3S Wi‑Fi module is supported, and the RF side should keep working because the RF is handled by the secondary MCU, not by the Wi‑Fi firmware [#20687286][#21364024] A working OpenBeken setup was posted with `startDriver TuyaMCU`, `tuyaMcu_setBaudRate 115200`, `tuyaMcu_defWiFiState 4`, and `tuyaMcu_setupLED 24 0`, and users confirmed that OBK works on these WT5/TuyaMCU LED controllers [#20785808][#20838429] The device’s TuyaMCU protocol was also captured and mapped to dpIDs like 20 for on/off, 22 for brightness, 23 for color temperature, and 24 for RGB color, so OBK can control the light through those TuyaMCU values [#20885149][#20884346] One remaining issue was that OBK could overwrite the MCU’s saved startup state, but that was later addressed with `tuyaMcu_enableAutoSend 0` to suppress automatic sending during boot [#21619412]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #91 21364024
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14631
    Help: 655
    Rate: 12647
    TuyaMCU does the RF, so RF will still work after you change WiFi module firmware.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #92 21378760
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17
    >>21364024 But if you use RF and WiFi at the same time and switch via the supply voltage, the last setting is started correctly for a short time after switching on, but then overwritten with the values from the web interface after starting the WiFi module. These differ from the last value if the RF was used.
    Simultaneous use is not practical. I have therefore deactivated the WiFi control on my WT5 again, as the unwanted sending of the web interface values to the TuyaMCU at the start cannot be deactivated and we also want to use the RF.

    Hinzugefügt nach 6 [Minuten]:

    >>20889438 Do these findings perhaps also apply to the WT5?
  • #93 21379163
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14631
    Help: 655
    Rate: 12647
    These findings are for devices that are not using the usual WiFi state mechanism:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_defWiFiState 4

    if tuyaMcu_defWiFiState is not working, then the linked findings apply, but as far as I can tell, WT5 is using tuyaMcu_defWiFiState and also it has no extra pin from MCU to WiFi module so it is not affected by what you linked.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #94 21379847
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17
    Could you please implement an option where OBK only sends the values to the TuyaMCU that have been changed (via web interface, HA etc.) and the sending of all other values for synchronization is suppressed?

    Yes, this would mean that the web interface would not be synchronized with the actual light status when using the RF, but this is irrelevant in daily operation if you only use the RF and HA (Zigbee switches and scripts).
    If used exclusively without RF, it is theoretically also not necessary to send the data for synchronization, as the TuyaMCU saves the last status.

    Without this option, mixed operation of the WT5 is not possible, as the current settings are always overwritten with those saved in OBK after power-on.
  • #95 21379936
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14631
    Help: 655
    Rate: 12647
    Ok, can you point exactly what's being sent from OBK that you want to disable?
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_tuyaMCU.c
    As far as I can see, in general the TuyaMCU_OnChannelChanged callback does the sending, but for LED, we have a special mechanism, TuyaMCU_OnRGBCWChange, which is called from cmd_newLEDDriver.c (apply_smart_light).
    I can see that apply_smart_light can be called on boot only if remember state flag is set:
    Code: C / C++
    Log in, to see the code

    but I'm not sure, if you want to test, disable this flag or just use online compilation system to test your own changes:
    https://www.elektroda.com/rtvforum/topic4033833.html#20946719
    Helpful post? Buy me a coffee.
  • #96 21380520
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17
    I haven't quite understood what's going on yet.

    The controller always has a life of its own with the Tuya driver activated, regardless of how OBK_FLAG_LED_REMEMBERLASTSTATE is set.
    The difference is when OBK_FLAG_LED_REMEMBERLASTSTATE = 1, the last setting from OBK is set and with the value 0 cold white full brightness.
  • ADVERTISEMENT
  • #97 21407597
    c0m4r
    Level 11  
    Posts: 40
    Rate: 4
    I have such a WT5 controller with a CB3S module. Using the BK7231 Easy UART Flasher I have uploaded the software (unfortunately without making a copy) and in the end everything is ok but unfortunately the module does not connect to my wifi nor after doing erase all does it expose its AP. I flash several times and each time it is ok but the wifi is not there. What can I do next to look for the cause of the problem?
  • #98 21407695
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14631
    Help: 655
    Rate: 12647
    Have you entered your SSID and password in the options, in configure WiFi?
    Helpful post? Buy me a coffee.
  • #99 21407749
    c0m4r
    Level 11  
    Posts: 40
    Rate: 4
    I have tried both filling in the OBK settings in the flasher so that it immediately connects to wifi and leaving it unfilled so that the AP appears to connect. Each time without success. Neither connects to my wifi nor puts out an AP.
    I have checked the read "read only OBK settings" and the data about my wifi stored in the chip is ok.
    I tried to connect with the putty to the TX2 pin (from the RX programmer to the TX2 pin, without the other lines) the power supply I have applied normal to the whole device but some bushes are

    Screenshot from PuTTY showing garbled characters in the terminal.
  • ADVERTISEMENT
  • #100 21407774
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14631
    Help: 655
    Rate: 12647
    From TX2 collect the log at baud 115200. In flasher you can still do a restore RF partition.
    Helpful post? Buy me a coffee.
  • #101 21407812
    c0m4r
    Level 11  
    Posts: 40
    Rate: 4
    I did the RF restore, checked the Read OBK config again, log below, looks all ok.
    As I connect from the 3.3V/GND converter and from RX to TX2 (11pin) in CB3S, I run putty on the same COM as I programmed, baud 115200 and nothing happens, empty terminal.
    If I leave only the RX to TX2 line connected and supply the controller with 12V there is one line in the terminal
    PuTTY terminal with unreadable characters displayed on a black background. .
    When I still connect the TX lines from the converter to RX2 from CB3S it flies very quickly fffff itself

    Screenshot of PuTTY program with unreadable characters in the terminal.

    Code: text Expand Select all Copy to clipboard
    Starting write test!
Now is: piątek, 24 stycznia 2025 15:16:49.
Flasher mode: BK7231N
Going to open port: COM5.
Serial port open!
Getting bus... (now, please do reboot by CEN or by power off/on)
Getting bus success!
Going to set baud rate setting (921600)!
Will try to read device flash MID (for unprotect N):
Flash MID loaded: 1560EB
Will now search for Flash def in out database...
Flash def found! For: 1560EB
Flash information: mid: 1560EB, icName: TH25Q16HB, manufacturer: TH, szMem: 1000000, szSR: 2, cwUnp: 0, cwEnp: 7, cwMsk: 407C, sb: 2, lb: 5, cwdRd: 05-35-FF-FF, cwdWr: 01-FF-FF-FF
Entering SetProtectState(True)...
sr: 0
sr: 0
final sr: 0
msk: 407c
cw: 0, sb: 2, lb: 5
bfd: 0
SetProtectState(True) success!
Going to read encryption key...
Encryption key read done!
Encryption key: 510fb093 a3cbeadc 5993a17e c7adeb03
Erasing sector 0x1D0000... ok! 
All selected sectors erased!
Writing sector 1900544... ok! Starting CRC check for 1 sectors, starting at offset 0x1D0000
CRC matches 0x890D0AC8!
Write success!
Starting read!
Read parms: start 0x1D1000 (sector 465), len 0x1000 (1904640 sectors)
Now is: piątek, 24 stycznia 2025 15:17:17.
Flasher mode: BK7231N
Going to open port: COM5.
Serial port open!
Getting bus... (now, please do reboot by CEN or by power off/on)
Getting bus failed, will try again - 0/100!
Getting bus success!
Going to set baud rate setting (921600)!
Will try to read device flash MID (for unprotect N):
Flash MID loaded: 1560EB
Will now search for Flash def in out database...
Flash def found! For: 1560EB
Flash information: mid: 1560EB, icName: TH25Q16HB, manufacturer: TH, szMem: 1000000, szSR: 2, cwUnp: 0, cwEnp: 7, cwMsk: 407C, sb: 2, lb: 5, cwdRd: 05-35-FF-FF, cwdWr: 01-FF-FF-FF
Entering SetProtectState(True)...
sr: 0
sr: 0
final sr: 0
msk: 407c
cw: 0, sb: 2, lb: 5
bfd: 0
SetProtectState(True) success!
Going to read encryption key...
Encryption key read done!
Encryption key: 510fb093 a3cbeadc 5993a17e c7adeb03
Going to start reading at offset 0x1D1000...
Reading 0x1D1000... Ok! 
Basic read operation finished, but now it's time to verify...
Starting CRC check for 1 sectors, starting at offset 0x1D1000
CRC matches 0x2E171159!
All read!
Loaded total 0x1000 bytes 
OBK config loaded. You can now view it by clicking 'Change OBK settings' button.
You can also edit it whatever you want.
You can also use 'Write OBK config' button to write it back with your changes.
    .
  • #102 21407847
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14631
    Help: 655
    Rate: 12647
    Maybe you have removed the bootloader for yourself? Enable "overwrite bootloader" in flasher.

    Erase All doesn't need to be done at all, or maybe you did it so now flashing OBK leaves an empty space after the bootloader, so you have to re-upload it....
    Helpful post? Buy me a coffee.
  • #103 21407915
    c0m4r
    Level 11  
    Posts: 40
    Rate: 4
    Bootloader, it was :) Thank you.
    The logs came up, the device logged into the Wi-Fi, but unfortunately the webpanel does not open.
    First I tried with DHCP, on the router it got the address 192.168.2.88, then I made a reservation for this address and in BK config I made a static IP with the same address. Unfortunately the webpanel does not report :( .
    Screenshot of a terminal showing device connection logs to a Wi-Fi network. .
  • #104 21407939
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14631
    Help: 655
    Rate: 12647
    What do you mean with webpane? The basic web panel should work. The Web App, on the other hand, only works if you have internet access because the Web App is a script from the open Github repository downloaded from the web (with the option to host this at home);.
    Helpful post? Buy me a coffee.
  • #105 21407977
    c0m4r
    Level 11  
    Posts: 40
    Rate: 4
    I am referring to the basic web panel - the page is not loading. I understand that it works on standard port 80? Is there anything in the logs to check if the panel is okay?
  • #106 21407983
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14631
    Help: 655
    Rate: 12647
    You may have messed up the RF partition with this Erase All. Perform Restore RF partition in flasher. Is the device responding to the ping? The site should work normally on port 80.
    Helpful post? Buy me a coffee.
  • #107 21408440
    c0m4r
    Level 11  
    Posts: 40
    Rate: 4
    I think I know what the problem is. There's a bug in either the firmware or the flasher that doesn't set dhcp=1 correctly when you edit the static IP address. I removed the network settings in flasher and set all addresses to just 0 so that there was dhcp, uploaded the flash, RF and bootloader again and the module issued its AP. I have configured my WiFi, the module has connected to the network, but the dhcp still has the 0 flag, which means it can't/won't set itself the IP address the router has assigned it, so even though I go to the address the router has assigned, the module can't see the address - you can see this well in the logs
    Console logs showing DHCP and MQTT issues.

    EDIT:
    I couldn't get a deal with DHCP, only setting a static IP address + reservation on the router sorted it out and the web panel works. Thanks for helping me get it up and running, now I'll be connecting and fighting with the LEDs ;) .
  • #108 21619412
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17
    >>21379936
    I finally managed to solve my problem. There is now a function that can suppress the sending of OBK to the TuyaMCU.
    New command: tuyaMcu_enableAutoSend [0/1] – enables control via the console or autoexec.bat

    See here: https://github.com/openshwprojects/OpenBK7231T_App/pull/1739


    My autoexec.bat now looks like this:

    Code: text Expand Select all Copy to clipboard
    
startDriver TuyaMCU
startDriver SSDP
PowerSave 1

tuyaMcu_setBaudRate 115200
tuyaMcu_defWiFiState 4
tuyaMcu_setupLED 24 0

# Disable automatic sending to prevent overriding TuyaMCU's saved state during boot
tuyaMcu_enableAutoSend 0

# Optional: Enable automatic sending after a delay if you want normal operation
addRepeatingEvent 12 1 tuyaMcu_enableAutoSend 1
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on the WT5 Multi-Channel LED controller with RF remote support, focusing on firmware flashing, TuyaMCU protocol integration, and OpenBeken (OBK) firmware usage. The WT5 uses a WB3S Wi-Fi module and an SC95F8615 secondary MCU controlling MOSFETs, with RF communication handled by an LT8900SSK chip via SPI. Users successfully dumped the 2MB flash, confirmed TuyaMCU communication at 115200 baud, and captured UART data to analyze DPIDs for LED control functions such as on/off (DP20), mode (DP21), brightness (DP22), temperature (DP23), and color data (DP24). OpenBeken firmware supports TuyaMCU devices, allowing Wi-Fi and MQTT integration, but challenges remain in synchronizing RF remote inputs with Wi-Fi state, especially for color and brightness updates. The Wi-Fi module overwrites LED states at startup, causing desynchronization with RF inputs; a proposed workaround involves delaying or suppressing initial state transmissions from Wi-Fi to MCU. SPI slave mode is not supported on WB3S, complicating passive listening to RF-MCU SPI communication; hardware modifications or bit-banged SPI on WB3S pins are considered. The WB3S is not 5V tolerant; level shifting via resistor dividers is recommended. Users report successful flashing and configuration of WT5 and related WB5 devices with OpenBeken, including integration with Home Assistant. Issues with web panel access and Wi-Fi connectivity were resolved by restoring bootloader and RF partitions and configuring static IP addresses. The community developed and tested firmware updates to improve TuyaMCU DP handling, reduce state update loops, and enhance RF and Wi-Fi coexistence. Documentation and tools such as TuyaMCUAnalyzer and OpenBeken web app guides support ongoing development and user assistance.
Generated by the language model.
Today's popular

FAQ

TL;DR: With 115200 baud and 5 confirmed core dpIDs, the WT5 works in OpenBeken via TuyaMCU; as one maintainer put it, "It’s TuyaMCU device." This FAQ is for WT5 owners who want stable RGB+CCT control, RF coexistence, correct autoexec.bat setup, and a fix for boot-time state overwrite using tuyaMcu_enableAutoSend. [#20687286]

Why it matters: A WT5 can appear fully working after flashing, yet still break daily use if OpenBeken overwrites the TuyaMCU’s RF-restored state a few seconds after power-up.

Approach RGB+CCT control RF coexistence Boot-state behavior Effort
OpenBeken + TuyaMCU Works Yes Needs autosend control for best coexistence Low
ESPHome on WT5 Partial in-thread, later working but less documented here Unclear Not resolved in-thread Medium
Replacing secondary MCU / direct RF driver Possible in theory Custom Fully custom High

Key insight: The easiest stable WT5 setup is to keep the secondary MCU and RF path intact, run OpenBeken as the Wi-Fi side over TuyaMCU at 115200, and suppress automatic resend on boot when RF state retention matters. [#21619412]

Quick Facts

  • WT5 boards discussed in the thread use WB3S or CB3S Wi-Fi modules plus a secondary MCU, and the PCB was traced as a 5-MOSFET design where PWM outputs go to the MCU, not directly to the Wi-Fi module. [#20687084]
  • The confirmed TuyaMCU UART speed for WT5 is 115200 baud, found in flash config and later used successfully with the analyzer and OpenBeken. [#20688328]
  • Confirmed WT5 Tuya dpIDs include 20 = on/off, 21 = mode, 22 = brightness, 23 = color temperature, 24 = color string, and 26 = countdown/state-related value 0 in query output. [#20699088]
  • RF still works after flashing OpenBeken because the secondary TuyaMCU handles RF locally; this was confirmed in practice after OBK flashing. [#20699117]
  • A later OpenBeken command, tuyaMcu_enableAutoSend 0, was added specifically to stop OBK from overwriting the TuyaMCU’s saved state during boot; an example autoexec re-enables autosend after 12 seconds. [#21619412]

How do I configure a WT5 Multi-Channel LED controller with a WB3S/CB3S module in OpenBeken using TuyaMCU and autoexec.bat?

Use TuyaMCU at 115200 baud and place the commands in autoexec.bat, not the Import page. A working minimal setup is:
  1. startDriver TuyaMCU
  2. tuyaMcu_setBaudRate 115200
  3. tuyaMcu_defWiFiState 4 and tuyaMcu_setupLED 24 0 Several users confirmed this works on WT5 units with WB3S and CB3S modules. The Import page only runs once, while autoexec.bat runs on every reboot, which fixes the “works until power cycle” problem. [#21052871]

Why does the WT5 restore the correct RF-set lighting state at power-up and then get overwritten by OpenBeken a few seconds later?

Because the TuyaMCU restores its own last state first, then OpenBeken later pushes its saved LED state back to the MCU. Users observed the light power up correctly from RF memory, then switch a few seconds later to OBK’s stored value or to cold-white full brightness when the remember-state flag was off. The root cause is OBK’s automatic send path for LED synchronization during boot. That behavior remained the practical blocker for mixed RF and Wi-Fi use until autosend control was added. [#20873136]

What is TuyaMCU, and how does it communicate with the Wi-Fi module in devices like the WT5 LED controller?

"TuyaMCU is a secondary control MCU that drives the real device functions while the Wi-Fi module exchanges high-level state over a serial protocol, usually on UART at a fixed baud rate." In the WT5, the WB3S/CB3S module talks to the secondary MCU over UART, and the thread confirmed the working rate is 115200 baud. The RF remote path stays on the secondary MCU side, which is why RF can still work after flashing the Wi-Fi module. [#20686758]

What is dpID in TuyaMCU, and which dpIDs are used by the WT5 for on/off, brightness, temperature, RGB color, and mode?

A dpID is the Tuya data-point identifier for one device function. On the WT5, the thread mapped dpID 20 = on/off, 21 = mode enum, 22 = brightness, 23 = color temperature, 24 = RGB color string, 26 = countdown/state value, and discussed 28 as an additional compound control string. Those mappings came from UART captures and later tuyaMcu_sendQueryState results on flashed devices. For practical OpenBeken control, dpIDs 20, 21, 22, 23, and 24 are the important ones. [#20699088]

Which OpenBeken commands are needed for the WT5, such as tuyaMcu_setBaudRate, tuyaMcu_defWiFiState, tuyaMcu_setupLED, and tuyaMcu_enableAutoSend?

The core WT5 commands are tuyaMcu_setBaudRate 115200, tuyaMcu_defWiFiState 4, and tuyaMcu_setupLED 24 0. Later, tuyaMcu_enableAutoSend 0 was added to suppress OBK’s automatic resend during boot, and one proven example re-enabled it after 12 seconds with addRepeatingEvent 12 1 tuyaMcu_enableAutoSend 1. Use startDriver TuyaMCU first, then the baud and Wi-Fi-state commands, then LED setup. That sequence preserves RF coexistence and fixes the common startup overwrite issue. [#21619412]

How can I capture and analyze TuyaMCU UART traffic from a WT5 using a logic analyzer or TuyaMCUAnalyzer?

Capture the WB3S/CB3S serial lines at 115200 baud and log both state changes and app or RF actions. The thread workflow was: 1. verify whether TX1/RX1 connect to the secondary MCU, 2. run a logic analyzer or TuyaMCU analyzer at 115200, 3. trigger known actions such as on/off, mode, brightness, and temperature changes. That method exposed dpIDs 20, 21, 22, 23, 24, and color-string formats. One maintainer explicitly said UART captures for each app operation were “very useful” for determining color format. [#20687757]

Why do RF remote changes on the WT5 update DP20 but sometimes not fully sync RGB, brightness, or CCT back to the OpenBeken web interface?

Because the WT5 does not report every RF-originated state back to the Wi-Fi module consistently. The thread repeatedly showed DP20 on/off arriving reliably, while RGB changes often produced no dpID 24 updates, and some scene or remote buttons produced no log entries at all. Later builds improved dpID 22 and 23 feedback, but users still reported missing RGB sync and scene-based changes that never appeared in the web UI. So the RF path works, yet full mirror-back to OBK remains partial on this device family. [#20891466]

What is the purpose of tuyaMcu_enableAutoSend in OpenBeken, and how does it prevent OBK from overriding the TuyaMCU saved state during boot?

tuyaMcu_enableAutoSend turns OpenBeken’s automatic TuyaMCU sending on or off. Setting it to 0 stops OBK from pushing its stored LED values during boot, so the TuyaMCU can keep the last RF-restored state instead of being overwritten a few seconds later. A WT5 user later posted a working solution with tuyaMcu_enableAutoSend 0 and optional re-enable after 12 seconds. That command was added specifically to solve the long-running WT5 mixed RF and Wi-Fi startup problem. [#21619412]

How do I use tuyaMcu_sendQueryState to see which TuyaMCU dpIDs the WT5 reports in CCT mode versus RGB mode?

Run tuyaMcu_sendQueryState from the web console with the log open, first in CCT mode and then in RGB mode. In the thread, query results in CCT returned dpIDs 20, 21, 22, 23, and 26, while RGB-mode query also returned dpID 24 with the 12-byte color string. That makes tuyaMcu_sendQueryState the fastest way to verify what the MCU will actually report back on your unit. It also exposes cases where RGB state exists internally but is not pushed during normal RF use. [#20886598]

What differences were found between dpID 24 and dpID 28 on the WT5, and how is the Tuya ASCII color format interpreted?

dpID 24 was identified as the main RGB color string, while dpID 28 looked like a longer compound string that may include both RGB and white-channel information. For example, one captured dpID 24 string decoded to 00 73 03 e8 03 e8 for a green test, matching a known Tuya color format already seen in another OpenBeken topic. The thread’s working conclusion was that dpID 24 is the actionable RGB field, while dpID 28 remained less certain and appeared to mirror extra white-related data. [#20689271]

OpenBeken vs ESPHome for a WT5 Tuya LED controller: which approach works better for RGB+CCT control and RF coexistence?

OpenBeken worked better in this thread because it got a documented TuyaMCU setup, working RGB+CCT control, and later a boot-overwrite fix. One CB3S user reported ESPHome flashed successfully but had no RGB working at first, while another later confirmed OpenBeken handled CCT and RGB on the same hardware. OpenBeken also preserved RF because it kept the TuyaMCU path intact. If you want the most evidence-backed path from this thread alone, OpenBeken is the safer choice for WT5 RGB+CCT plus RF coexistence. [#20884069]

How can I troubleshoot a flashed CB3S/WB3S WT5 that joins Wi-Fi incorrectly, does not expose an AP, or does not open the basic web panel after flashing?

First restore the bootloader and RF partition, then verify network settings. The thread fix was: 1. enable overwrite bootloader in the flasher if you used Erase All, 2. perform Restore RF partition, 3. test AP mode or set a static IP if DHCP behaves incorrectly. One CB3S user had no AP, no web panel, and partial Wi-Fi until restoring the bootloader; later, static IP plus router reservation made the basic web panel work. Also remember the basic panel is on port 80. [#21408440]

What is the RF partition and bootloader in BK7231 flashing, and why can 'Erase All' break Wi-Fi or web access on a WT5?

The bootloader starts the BK7231 firmware, while the RF partition stores radio calibration and related wireless data. On the WT5, a maintainer warned that Erase All can wipe critical areas, leaving OBK flashed but with broken Wi-Fi, no AP, or no basic web panel. In one real case, restoring the bootloader solved missing Wi-Fi logs and network startup. Restoring the RF partition was also recommended when the device responded oddly after full erasure. So Erase All is risky unless you are ready to rebuild those partitions. [#21407847]

How safe is it to monitor the WT5 serial lines or RF chip SPI lines, and what precautions matter when the device power supply may or may not be isolated?

It is safe only when you know the power domain and voltage levels. The thread explicitly warned that if the device uses a non-isolated supply, connecting UART directly to a PC can damage both the PC and the controller. A safe case is an isolated 12 V DC powered device, where UART capture can be done without extra opto-isolation. The WT5 discussion also rejected calling WB3S “5 V tolerant”; users were advised to use a resistor divider when listening to 5 V logic. [#20873671]

How would you approach adding direct RF support in OpenBeken for the WT5's LT8900-based receiver, and when is using TuyaMCU easier than replacing the secondary MCU?

Use TuyaMCU first unless you specifically need custom RF features. The thread eventually identified the RF chip as LT8900-compatible over SPI with a fifth interrupt/status line, but OpenBeken did not support that RF path directly. The proposed direct-RF route was to capture SPI traffic, use GPIO interrupt plus software or hardware SPI, and possibly remove the secondary MCU if needed. Even then, the maintainer still said TuyaMCU control was “a much easier way” because most device behavior already existed in the shipped firmware and RF kept working after Wi-Fi reflashing. [#20688417]
Generated by the language model.
ADVERTISEMENT