Request for Help – Flashing Della Minisplit WiFi Module (WBR3 on TCWBRCU1)

Edit:
I’ve started a detailed teardown and modification guide for the Della Mini Split TCWBRCU1 module. It’s a work in progress but may be helpful:
https://www.elektroda.com/rtvforum/topic4125928.html

Hey everyone,

I’ve been digging into the WiFi module in my minisplit and could use some guidance on next steps. My goal is to run OpenBeken or another fully local solution — something cloud-free like LocalTuya, but flashed directly onto the device for better performance and independence.While I’ve tried LocalTuya in the past, I’ve run into permission issues, and I’d like to move away from Tuya entirely if possible.

I will be updating this post with images later today. These will include pictures of the module, the internal layout, and the desoldered WBR3 module.If anyone has experience flashing WBR3 modules or working with minisplits like this, I’d really appreciate your input.

Minisplit Details
- Make: Della
- Model: Optima Series
- OEM Manufacturer: Align, Inc
- Indoor Unit Model: 048-TP-9K2V-23S-IN
- Outdoor Unit Model: 048-TP-9K2V-23S-OUT
- Amazon Link: Link
- Type: Mini Split Air Conditioner
- Cooling Capacity: 9,000 BTU
- Heating Capacity: 9,000 BTU
- Power Supply: 115V, 60Hz
- Installation Type: Wall-mounted (Indoor), Outdoor unit with condenser coil
- Features: WiFi control, Bluetooth capabilities

The indoor unit has a removable USB WiFi + Bluetooth module. You can remove it by taking off the plastic clip that holds it in the housing, then sliding the module out.

Module Breakdown
- Main Module: TCWBRCU1
- Soldered Chipset Module: WBR3

The WBR3 is a separate module soldered onto the TCWBRCU1 board. I’ve opened the housing and taken clear photos of both modules and the internal layout. I haven’t desoldered the WBR3 yet, but I plan to do that later today to access the pins and take more detailed pictures for flashing.

Chipset ID (speculation):
Based on my research and comparisons to similar modules, I believe the WBR3 uses the Realtek RTL8710BN, which is part of the AmebaZ2 family. However, I haven’t confirmed this yet — some sources also mention RTL8720CF in relation to these modules. Once I can inspect the chip directly, I’ll confirm the markings.

What I Know So Far
- The WBR3 is listed as supported on the OpenBeken GitHub under the AmebaZ2 family (e.g., BW15, W701, WBR2, WBR3).
- It may be flashable via UART, and I’ve found a walkthrough for flashing, so the process seems achievable.
- The TCWBRCU1 base module is associated with the RTL8720CF, but the soldered WBR3 is likely doing the WiFi/Bluetooth work here.
- However, I haven’t found a matching template for this minisplit model or module combination in OpenBeken, which is causing concern for the functionality after flashing.

My Main Concern
While flashing the module via UART seems feasible, my biggest worry is maintaining the full functionality of the minisplit post-flash. Without a template specifically for my minisplit model (048-TP-9K2V-23S-IN), I’m not sure if critical features (like temperature settings, mode switching, or IR control) will continue to work correctly once the firmware is updated.

I want to ensure that I don’t lose important functionality after flashing OpenBeken or another local solution to the module.

What I'm Hoping For
- Be able to flash OpenBeken to the board
- Configure the minisplit functionality (temperature settings, mode switching, IR control, etc.)
- Create a device template once everything is working correctly
- Provide the template to the community to help others with similar devices

Reference Material
- TCWBRCU1 Datasheet
- WBR3 Datasheet

AI: Once you have the WBR3 module desoldered, could you provide detailed photos or a diagram of the pinout and any markings on the chip? This will help confirm the exact wiring needed for UART flashing and chipset identification.
Yes

AI: Do you have any information (from the datasheets, PCB traces, or logic analysis) about the communication protocol between the WBR3 module and the main TCWBRCU1 board? Knowing whether it uses UART, SPI, I2C, or something else is key to ensuring OpenBeken can support all the minisplit’s functions after flashing.
At this point, I haven’t fully traced or confirmed the communication protocol between the WBR3 and the TCWBRCU1 board. However, here’s what I’ve observed and what I plan to do:

Pin Inspection (Planned): Once I desolder the WBR3 module later today, I’ll be inspecting and tracing the pins to determine how it connects to the TCWBRCU1. I'll also look at any silkscreen or labeled test pads for hints.

Datasheets: The Tuya WBR3 datasheet mentions UART and PWM support, and some SPI/I2C capabilities, but it doesn’t explicitly describe how the WBR3 communicates in this specific configuration.

Assumption (Working Theory): Since many Tuya modules communicate with their host boards via UART (e.g., simple serial commands for control and status), I'm speculating that UART is likely being used here. That said, I haven't validated this yet.

Logic Analysis: I plan to probe the board and possibly do some logic analysis once it’s powered back up, ideally with the stock firmware still intact, to sniff communication between the WBR3 and the TCWBRCU1 if needed.

TCWBRCU1_V1.0.0 & WBR3 Images
Top view of the left WBR3 pins while still soldered to TCWBRCU1.


Top view of the right WNR3 pins while still soldered to the TCWBRCU1.


Bottom view of the TCWBRCU1 while WBR3 is still soldered.


Closer image of the bottom view. I am fairly certain these are pass through holes to the WBR3 flashing pins. According to the datasheet, these should be pins A_0, A_1 and A_15.



Edit 1:
Updated title and added images (Apologies for the cat hair in the pics).

Edit 2:
Updated additional mini split details.
Added links.

Your device is most likely using TuyaMCU, so you can do the initial reading here:
TuyaMCU flashing, setup and configuration guide - configure dpIDs for Home Assistant
You can extract datapoints this way:
Extracting DpIDs for TUYA MCU devices
Once flashed, you can also use new Berry integration for data points that are not yet supported by OBK code:
Berry scripting for various IoT platforms - tutorial for OBK new script integration part 1
Don't worry if it seems much, we can do it step by step. So, for a start, I suggest two things:
1. make detailed photos of device and what Tuya app offers, how is WiFi module connected, is it connected to the TuyaMCU via first UART port? Or is it a non-TuyaMCU solution?
2. try to do it: Extracting DpIDs for TUYA MCU devices

Thank you for the response!

I've updated the initial post to include images of both modules. I believe there are passthrough holes available for programming the WBR3 without needing to desolder it from the TCWBRCU1 board. One of the pictures highlights which WBR3 pins are available through those holes, so it should make things a lot easier.

I will attempt flashing the module tonight and report back my findings. I will also gather the requested images and update the initial post with them.

The following datapoints were collected during my initial testing:

Collected Datapoints via Tuya IoT Platform Website

DPID	Key	Name	Type	Unit	RW	Range/Notes
1	Power	开关	bool		true
2	temp_set	设置温度	value	℃	true
3	temp_current	当前温度	value	℃	false
4	mode	工作模式	enum		true	cold, hot, wet, wind, auto
5	windspeed	风速	enum		true	strong, high, mid_high, mid, mid_low, low, mute, auto
18	humidity_current	当前湿度	value	%	true
19	temp_unit_convert	温标切换	enum		true	c, f
20	Fault	故障告警	bitmap		false
23	temp_current_f	当前温度 ℉	value	℉	false
24	temp_set_f	温度设置 ℉	value	℉	true
101	pm25	PM2.5	value		false
102	fresh_air	新风	enum		true	auto, low, mid, strong, off
103	freshair_filter	新风脏堵	bool		false
104	SN_SW_ver	SN及软件版本	raw		false
105	sleep	睡眠	enum		true	off, normal, old, child
110	markbit	标识位	bitmap		false
113	up_down_sweep	上下扫风	enum		true	0, 1, 2, 3
114	left_right_sweep	左右扫风	enum		true	0, 1, 2, 3, 4, 5, 6, 7
115	totalN	电量整数	value		false
116	totalP	电量小数	value		false
119	money	省钱看的见	enum		true	0, 1, 2, 3
120	energy	发电机模式	enum		true	off, L1, L2, L3
122	fault2	故障报警2	bitmap		false
123	boolCode	布尔型	string		true
125	airquality	空气质量	enum		false	great, good, middle, bad, verybad, veryverybad

Smart Life Application Screenshots


Edit: Added Smart Life App screenshot images.

This seems supportable, maybe not fully out of the box, but I can't see any serious problems. There are some data points that do not have a matching ChannelType in OBK yet but we can work on it. I can add channel types per request if needed, and we also have Berry scripting right now, so we should be able to figure things out.

When flashing, make sure to get device backup first, so you can recover it if something goes wrong.

I will also need to check whether UART and TuyaMCU drivers are already enabled on this Realtek platform, unless @divadiow and/or @insmod already know the answer? If they are not, we will need to enable them first.

All realteks support UART, and TuyaMCU driver is enabled by default on all of them.
Berry support will be added soon, also by default.

This is better than expected. And my Berry integration is already able to parse TuyaMCU datapoints, as can be seen here:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/selftest/selftest_berry.c
I just need to prepare a tutorial for that.

we have a dump from a Della Mini Split (with WBR1 module) here https://github.com/openshwprojects/FlashDumps/tree/main/IoT/RTL8720CF
This is from a user on Discord where I see @dressyspider has also posted. I've posted reference to this thread there

Thank you all for the information.

I didn’t get home until later than expected yesterday, so I did not attempt to back up or flash. I will be trying in a few hours though and will report back.

Added after 3 [hours] 15 [minutes]:

>>21536969 Should I use this as a starting point or no?

Added after 3 [hours] 12 [minutes]:

My project is on hold for now. I tried using a solder sucker to desolder the WBR3, but it did not go very well. I was able to solder some Dupont wires to the WBR3 through the holes in the TCWBRCU1, and everything was looking good. That changed when I started wiring everything up on a breadboard. The trace for A_0 lifted, which is only the second time I have ever lifted a trace.

It looks like I am now in the market for a new WBR3, and possibly a replacement TCWBRCU1 if I can find one. Unless I can desolder the WBR3, the scratch to expose some of the trace.

I will post an update once I have a new module.

I guess there's no guarantee the dpIDs for the WBR1 version are the same, so probably not. If it was me I'd start by capturing boot log and de-soldering so a flash backup could be taken.

You don't need realtek. You can use any module that fits and run obk. WB3S or CB3S also should be good, I believe. Or a WB3S-NiceMCU from Aliexpress (the one on BK7238, not BK7231T), altough I don't remember testing UART on the "Nice" one.

>>21540508 >>21540508 Darn, I already ordered a replacement. It should be delivered soon. I also got some better tools for de-soldering SMB components. I'll be trying again tomorrow.

Going to de-solder, then I will be exposing the trace and soldering to it directly to see if a dump/flash is still possible.

Well, the good side of having the same module as replacement is the fact that this will allow you to try or return to factory firmware as well.

I was able to:
- De-solder the WBR3 module from the TCWBRCU1 module, but lifting GND pad in the process
- Repair lifted GND pad
- Scratch the bus line for A_0 and solder a line to it
- Solder all points to communicate with UART cable
- Connect soldered points and UART adapter leads to a breadboard via dupont cables

As I was unplugging the EN cable on the breadboard, the A_16 pad lifted from the WBR3. This time I could not repair the lift. These module boards are very fragile and/or I am very out of practice.

I am curious about using a WB3S because I cannot seem to locate a reliable place to order the WBR3 from. The layout is a bit different though. Would this one work? There is a drop down to choose just the chip.

Edit 1:
Found and ordered the WBR3 on aliexpress

Edit 2:
Update: I will be able to try again and will be receiving a replacement on Friday (MST)(UTC-07:00). 
Instead of de-soldering, I am printing this PCB workstation to make life easier. 

I will update again after my next dump/flash attempt.

@p.kaczmarek2 I was able to desolder the new WBR3. I have it connected to a UART adapter, but am not able to get past the "getting bus" message in BK7231 flash tool. Can you take a look at my wiring and let me know if you see anything obviously wrong?

-This is what I have done after wiring everything up:
-Verified it's COM4.
-Tried the other preset baud rates.
-Shorted EN to GND after clicking "Do firmware backup 'read' only". (I have also tried removing power from VCC on the WBR3 with the same timing)

Easy Flasher does not backup from or write to any Realtek chips. AmebaZ2 backups should be taken with ltchiptool for now and writing can be performed with AmebaZ2 PG Tool

see https://www.elektroda.com/rtvforum/topic4097185.html for flashing. Tool downloadable from https://github.com/openshwprojects/FlashTools/blob/main/Realtek/AmebaZII_PGTool_v1.2.47.exe

Please also backup and share the new module flash, it may contain interesting testing firmware.

>>21544726 Sweet, Thank you. I will try now. Also, I was planning on sharing the dump and creating a separate teardown for anyone else with the same/similar mini split models.

Edit: Looks like it's backing up.

 

Added after 56 [minutes]:

@p.kaczmarek2 @divadiow

Do these files look correct? One is from choosing the "Read Flash" option and the other if from choosing "Read ROM". 

yes, the rom should be 384kb


and your 2mb backup does boot

Great! Thank you for checking. I’m calling it a night, but will be flashing tomorrow evening after I get home.

I have successfully flashed the WBR3 and configured it to be on my IoT SSID.



I am a bit confused here because the names do not line up with the data points that were collected earlier.

ah, it's TuyaMCU so no GPIO assignments. You'll need to start with something like https://www.elektroda.com/rtvforum/topic4038151.html

There are many TuyaMCU devices in the device list that will probably show the journeys others have taken https://openbekeniot.github.io/webapp/devicesList.html

example autoexecs for devices with TuyaMCU https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md

looks like you've got your work cut out for you https://www.elektroda.com/rtvforum/topic4119999.html#21536711

I am genuinely curious, how can you tell? Im very new to flashing these kinds of chips and have only flashed Sonoff S31s with tasmota.

Is it possible I flashed the incorrect BIN? I used "OpenRTL87X0C_1.18.99.bin"

Also, would it make a difference if I swapped the WBR3 with another similar module? My guess is no because it appears the TuyaMCU handles the actual commands?

Thanks for the links @divadiow . I went through them and they really helped clear things up. I have a better understanding of how TuyaMCU devices work now and I’m going to try the recommended approaches.

I appreciate your help with this.

Also, I managed to get my original WBR3 working again, so I guess I’ve earned myself another chance to break it! Haha. I’m thinking I’ll just keep that one stock for now as a backup.

dressyspider wrote:

Also, would it make a difference if I swapped the WBR3 with another similar module? My guess is no because it appears the TuyaMCU handles the actual commands?

Obk runs on many platforms but, as far as i know, all popular WBR3-format modules have UART in the same place, just like TYWE3S, so as long as you get OBK-compatible module with TuyaMCU support it should work just fine. For example, CB3S or WB3S would certainly work.

Altough... you may need first to double-check if the basic pinout is really matching. Ground, 3.3V, RESET, UART. Other gpio positions change between modules but it should not be a problem here...

Thanks for the clarification. I am going to stick with the stock WBR3 for now since it appears to be functional and I am still able to communicate with it via OpenBeken.

In the meantime I have ordered a link analyzer to capture and analyze UART traffic between the WBR3 and the TuyaMCU. While I wait for it to arrive I am gathering as much data as possible from the Tuya IoT platform using the original firmware. I am especially focusing on identifying which DPID values correspond to which commands like power control and timers and how they are structured such as types and timing fields.

Once the analyzer is here I plan to correlate the cloud commands with the actual UART traffic to fully map out the control scheme. If I learn anything useful I will share it here in case others are doing similar TuyaMCU reverse engineering.

Added after 6 [hours] 16 [minutes]:

Quick recap of where I’m at:
• I flashed OpenBeken 1.18.99 onto a WBR3 (RTL87X0C)
• Reinstalled it into the TCWBRCU1 module, which is connected to a Della 048-TP-9K2V-23S-IN unit
• MQTT is working with Home Assistant
• The TuyaMCU driver loads fine, but I don’t have access to TuyaMCU_RX/TX roles in /cfg_pins
• Commands like setTuyaMCUBaudRate and tuyaMcu_sendQueryState either aren’t available or don’t return anything useful
• There’s no DPID logging even when I use the original IR remote
• I know the Tuya Cloud API uses { "switch": "true" } to turn on the unit, but I haven’t found a working DPID or OBK command that does the same

Am I using the wrong commands to test TuyaMCU comms with the RTL87X0C? I've tried the commands available in the cmd_tool section at "http://10.1.107.12/cmd_tool" and also within the webapp logs at "http://10.1.107.12/app?".

It seems your device is not a TuyaMCU, but using a custom protocol.
See https://github.com/adaasch/AC-hack
https://github.com/lNikazzzl/tcl_ac_esphome/tree/master

Thanks, that actually clears up a lot. I had a feeling something wasn’t adding up with TuyaMCU.

I’ll take a look at those links you shared, especially the TCL AC protocol ones. It makes sense now if this Della unit is using a custom serial format and not the standard Tuya DPIDs. That would explain why commands like tuyaMcu_sendState and setTuyaMCUBaudRate weren’t doing anything, and why I’m not seeing any DPID logs even when using the IR remote.

I’ve got a logic analyzer arriving soon, so once I get some UART captures between the WBR3 and the main board, I’ll try to match it with what the Tuya cloud is sending. If it looks like the TCL format, I might go the ESPHome route or see if I can make a driver for OpenBeken.

I’ll post whatever I find in case it helps others with similar setups.

Appreciate the help!

Interesting, I haven't seen such non-TuyaMCU device yet. I can try to draft a driver for it tomorrow if I manage to find some spare time.

What information could I provide you to make it easier for you to draft a driver?

Which command would be most suitable for testing? Setting mode? Off, cool, dry?

I'm porting one of linked drivers here:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1635

Added after 2 [hours] 17 [minutes]:

I've did quick port of single send.
https://github.com/openshwprojects/OpenBK7231T_App/pull/1635
Maybe @insmod can review.
Usage:

then ACMode 1, ACMode 2, etc

Reply parse is not ported yet, it seems one of the sends is using parsed reply, i hope it will not cause issues

I tried running startDriver TCL, but it looks like the driver is not included in this build yet.

OBK Log output:


The command still returns OK, but the driver does not seem to be active.

What is the best way to try it out? Should I wait for a build that includes the TCL driver, or is there a recommended way to test it now?