logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[BK7231N / T34 ] Teardown Tuya Generic Wifi Wall Light Switch 3 Gang

CameronDev 34770 124

TL;DR

  • A Tuya Generic WiFi Wall Light Switch 3 Gang with a BK7231N/T34 was torn down and prepared for OpenBeken flashing.
  • The front glass lifts off from the bottom opening, and the motherboard unclips easily, but the T34 QFN chip has no exposed programming pads.
  • It shipped from AliExpress with firmware 1.3.10 and was already patched against the CloudCutter exploit.
  • Hot-air desoldering, jumper wires, and bk7231flasher were needed to dump and reflash the chip, and the T34 was resoldered successfully.
  • OpenBeken and ESPHome pin maps are provided, but the dump could not extract Tuya config, so this is a difficult mod to attempt.
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #91 21486400
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14612
    Help: 655
    Rate: 12630
    Well, I've posted it today :D btw, you have version without BL0937, so you really should use PowerSave. Add it to start script
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #92 21486409
    kalikum
    Level 5  
    Posts: 9
    Rate: 1
    Great job

    I was just thinking about the powersave (i read about it from another of your post) and I have doubts about the functioning of some automation of my HA does it affect somehow to activate it?

    I'm going to try anyway ^.^
  • #93 21486413
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14612
    Help: 655
    Rate: 12630
    As far as I know, PowerSave only affects BL0937 devices and we actually even have a solution for that, which should be merged soon. There will be alternate PowerSave option/command for such cases. If your device is not using BL0937, you can enable PowerSave even now.

    Well, maybe also except IR devices, but I'm not sure. IR is using a high speed timer so it may not like MCU sleeping.

    You can also enable SSDP:


    Helpful post? Buy me a coffee.
  • #94 21486484
    kalikum
    Level 5  
    Posts: 9
    Rate: 1
    Powersave activate.

    The temperature drops quite compared to when it was working without powersave, I will confirm automatisms operation on HA

    Screenshot displaying diagnostic data of a device, including temperature, WiFi signal, and MQTT connection status.

    Thanks again for the information.
  • #95 21486506
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14612
    Help: 655
    Rate: 12630
    Lower temperature is good, otherwise you may need to do this fix soon:
    https://www.elektroda.com/rtvforum/topic3898805.html
    Helpful post? Buy me a coffee.
  • #96 21487771
    kalikum
    Level 5  
    Posts: 9
    Rate: 1
    After a day with the porwersave, the temperature remains low but I cannot monitor it from the HA, it is not a problem, but is better if you know it in case someone uses it. Beyond this, automatisms work perfectly.

    I will still inform in the future, regards.
  • ADVERTISEMENT
  • #98 21619339
    jkwim
    Level 13  
    Posts: 186
    Help: 4
    Rate: 25
    >>21135586

    I have a T34 based 3 Gang Switch which has the same PCB.

    T34 PCB with visible chips and programming header pins

    I have obtained the backup successfully but the config file extraction fails.

    Then after many unsuccessful attempts, managed to flash.

    BK7231N Easy UART Flasher interface showing Write success! message

    Flash went successful but the unit does not come in to WiFi Access Point mode even after 5 power recycles.

    WiFi LED flashes once at low power on boot and then after a while goes into bright blue and stays lit.

    Attempted to Read OBK Config but that also failed.

    What could be going wrong here?
    BK7231 Easy UART Flasher interface with “Only 0xFF bytes read!” error


    Here is the beginning part of the log:
    Code: text Expand Select all Copy to clipboard
    
Preparing to write data file to chip - resetting bus and baud...
Getting bus... (now, please do reboot by CEN or by power off/on)
Getting bus success!
Going to set baud rate setting (115200)!
Will try to read device flash MID (for unprotect N):
Flash MID loaded: 15701C
Will now search for Flash def in out database...
Flash def found! For: 15701C
Flash information: mid: 15701C, icName: EN25QH16B, manufacturer: ESMT, szMem: 1000000, szSR: 1, cwUnp: 0, cwEnp: 7, cwMsk: 3C, sb: 2, lb: 4, cwdRd: 05-FF-FF-FF, cwdWr: 01-FF-FF-FF
Entering SetProtectState(True)...
sr: 40
final sr: 40
msk: 3c
cw: 0, sb: 2, lb: 4
bfd: 0
SetProtectState(True) success!
Going to do erase, start 69632, sec count 281!
Erasing sector 69632... ok! Erasing sector 73728... ok! Erasing sector 77824... ok! Erasing sector 81920... ok! Erasing sector 86016... ok! Erasing sector 90112... ok! Erasing sector 94208... ok! Erasing sector 98304... ok!


    Log file of the backup (last part):
    Code: text Expand Select all Copy to clipboard
    
Basic read operation finished, but now it's time to verify...
Starting CRC check for 512 sectors, starting at offset 0x00
CRC matches 0xD6EB617C!
All read!
Loaded total 0x200000 bytes 
Wrote 2097152 to readResult_BK7231N_QIO_2025-28-7-17-02-36.bin
Backup 2MB created, now will attempt to extract OBK config.
It's not an OBK config, header is bad
OBK config not found.
Backup 2MB created, now will attempt to extract Tuya config.
Tuya config extractor - magic is at 2023424 
Saving debug Tuya decryption data to lastRawDecryptedStrings.bin
Failed to extract Tuya keys - no json start found
Sorry, failed to extract keys from Tuya Config in backup binary.
    Attachments:
    • readResult_BK7231N_QIO_2025-28-7-17-02-36.bin (2 MB) You must be logged in to download this attachment.
  • #99 21619354
    divadiow
    Level 38  
    Posts: 5059
    Help: 438
    Rate: 893
    regarding the config extraction try the attached version
    Attachments:
    • BK7231GUIFlashTool.zip (443.22 KB) You must be logged in to download this attachment.
  • #100 21619518
    jkwim
    Level 13  
    Posts: 186
    Help: 4
    Rate: 25
    >>21619354
    Thanks for that quick reply.
    Just to be sure I flashed a few more devices that I had with the same PCB and managed to successfully configure them.

    I reflashed the original unit using higher baud rate of 230400. Flashing becomes successful but it does not open up the WiFi AP. The WiFi LED get lit up after a while and then stays litup.

    I wonder whats wrong there.

    Other units which could be successfully flashed are of the same type.

    BTW the config file should be as follows:
    Note that I had to swap channels 1 & 3 from the original Tuya Config to get the proper button orientation on the GUI.

    The working config

    Code: text Expand Select all Copy to clipboard
    Device configuration, as extracted from Tuya: 
- WiFi LED on P7
- Button (channel 1) on P8
- Relay (channel 3) on P9
- Button (channel 2) on P14
- Relay (channel 2) on P15
- Button (channel 3) on P16
- Relay (channel 1) on P17
- Pair/Toggle All Button on P24
Device seems to be using T34-3 module.
And the Tuya section starts, as usual, at 2023424


    Added after 4 [hours]:

    Thought of sharing my new setup for flashing here as well so that others also can get some inspiration.

    Some time back I ordered these probles/needles from Aliexpress.
    https://www.aliexpress.com/item/1005007471008008.html

    Those are essentially some metal rods with pogo pins at one end and a female jumper wire headers at the other end.

    So I created a small setup like this:

    PCB under pogo pins mounted through holes in a plastic container lid

    I was hoping to get a nice stand made with acrylic sheets later but for the time being this works.

    The vertical probes rest on the solder pads/pins using their weight and the pogo needle points.

    Close-up of four pogo pins touching pads on a printed circuit board with a microcontroller.

    It takes some skill in accurately positioning the needle points of the pogo pins.

    For Power I used a 1.27mm female pin header to directly connect to the pin header on the PCB so that no soldering is required.

    I managed to flash a bunch of T34 devices quickly today using this setup (one device has some issue though).

    Added after 25 [minutes]:

    Hoping to recover the failed unit I tried flashing the backup file back into the device.

    I am getting the following error.

    Code: text Expand Select all Copy to clipboard
    All selected sectors erased!
CheckRespond_FlashWrite4K: bad value returned?
Writing sector 0x11000... Writing sector 69632 failed!
Writing file data to chip failed.


    Does anybody know what this means?
  • #102 21636218
    jkwim
    Level 13  
    Posts: 186
    Help: 4
    Rate: 25
    roman0213 wrote:
    >>21619518 Hello, i have same board as you I'm not able to even read flash. how did you connect? just connect cen to ground, or did something else? I have separate 3,3v power supply I have tried also https://github.com/libretiny-eu/ltchiptool/releases did you tried?

    Thanks


    Actually the CEN trick did not work.

    What worked for me was to lift the TX Probe on and off the pad few times in my setup above and the communication got triggered.

    I still have not been able to recover the dead unit but others are ok.
  • #103 21637380
    roman0213
    Level 3  
    Posts: 4
    >>21636218 so you had setup like

    Probe connected to UART RX, UART TX, and CEN pins on a PCB.

    and you played with tx uart probe? I have 2 of these boards but no luck:( any idea?
  • #104 21638276
    jkwim
    Level 13  
    Posts: 186
    Help: 4
    Rate: 25
    roman0213 wrote:
    >>21636218 so you had setup like

    Probe connected to UART RX, UART TX, and CEN pins on a PCB.

    and you played with tx uart probe? I have 2 of these boards but no luck:( any idea?


    Yes, it was not intentional but accidentally discovered that the make/break connection established the communication. To this date I haven't gone back to check what really happened as I had few units to be flashed and got them flashed in one go.
  • ADVERTISEMENT
  • #105 21656671
    roman0213
    Level 3  
    Posts: 4
    jkwim wrote:
    roman0213 wrote:
    >>21636218 so you had setup like

    Probe connected to UART RX, UART TX, and CEN pins on a PCB.

    and you played with tx uart probe? I have 2 of these boards but no luck:( any idea?


    Yes, it was not intentional but accidentally discovered that the make/break connection established the communication. To this date I haven't gone back to check what really happened as I had few units to be flashed and got them flashed in one go.

    Finally, I have successfully flashed the device by interrupting the 3.3V pin. But are you using ESPHome and Home Assistant, or something else? I’m wondering how I can turn off the blue LED on the switch.

    Added after 3 [hours] 22 [minutes]:

    ok I found solution
    Code: text Expand Select all Copy to clipboard
    
switch:
  - platform: gpio
    id: switch_1
    name: Relay 1
    pin: P17
  - platform: gpio
    id: switch_2
    name: Relay 2
    pin: P15
  - platform: gpio
    id: switch_3
    name: Relay 3
    pin: P9
  - platform: output
    name: "Status LED"
    output: status_led

output:
  - platform: gpio
    pin: P7
    id: status_led
    inverted: true  
  • #106 21688587
    jkwim
    Level 13  
    Posts: 186
    Help: 4
    Rate: 25
    roman0213 wrote:
    Finally, I have successfully flashed the device by interrupting the 3.3V pin. But are you using ESPHome and Home Assistant, or something else? I’m wondering how I can turn off the blue LED on the switch.


    Yes you could do the inversion but then you would loose the blue light on the buttons as well.

    That is what I am struggling with now. It appears that Tuya does some kind of PWM to make the WiFi LED go off but the switch LEDs will remain lit. The schematic that I was able to derive in earlier posts may have something to do with it. I haven't figured out yet.
  • #107 21689976
    jbolanosg
    Level 1  
    Posts: 1
    >>21117203 I just bought 3 similar switches from the green box, but the board is a little different. I’m attaching images… Does anyone know if there’s a way to change the firmware without removing the chip? The chip is way too small to do it with needles… Would it be possible to find pins 25 and 26 on the traces and connect to them?
    Two blue PCB modules with electronic components and contact pads
    Close-up of a blue circuit board with microchip and conductive traces
    Close-up of a blue PCB with integrated circuit, SMD parts, and conductive traces
    Close-up of a blue PCB with ICs, soldered components, and circuitry traces
  • ADVERTISEMENT
  • #109 21694097
    divadiow
    Level 38  
    Posts: 5059
    Help: 438
    Rate: 893
    are 26/27 routed out anywhere from the chip?

    Diagram of BK7231N chip orientation and pinout with a photo of the chip.
  • #110 21710611
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14612
    Help: 655
    Rate: 12630
    Hey @jkwim , how did it go, we have a user with similar device here:
    https://www.elektroda.com/rtvforum/topic4147474.html
    Helpful post? Buy me a coffee.
  • #111 21740122
    DanShi73
    Level 1  
    Posts: 1
    Hi to all. I bought 3 similar ones on Aliexpress and successfully flashed them, but the button only works when released. I set Flag 6 but nothihg changed. Can anyone recommend anything?
  • #112 21745355
    dgel27
    Level 8  
    Posts: 19
    >>21694097 in my case, only P26 routed outside. But it possible reach P20-P23 if remove RF MCU. If it possible flash via P20-P23?
    Thanks!
  • #113 21810381
    Sllaci01
    Level 4  
    Posts: 7
    >>21656671
    I have successfully updated three of these switches.
    All of them matched the green PCB version.
    The instructions made it very easy
    Thanks!
    I would also like to solve this so that the Wifi LED does not light up, only when it indicates a connection.
    I am not familiar with programming. Can someone help me?
    Thanks!!!
    Laszlo
  • #114 21810436
    Tilator
    Level 12  
    Posts: 133
    Help: 2
    Rate: 13
    >>21810381

    Setting the pin to Wifiled or Wifiled_N does flash the led while connection is not yet established. One of those does lit led up when connection is set up and the other keeps it off.

    So - have you tried both Wifiled and Wifiled_N settings for it?
  • #115 21810549
    Sllaci01
    Level 4  
    Posts: 7
    >>21810436
    Thank you, that was really easy.
    Original setting was Wifiled_n.
    Changed Wifiled now turns off after connecting

    Thank you very much!!!
  • #116 21825374
    arthur_koba
    Level 2  
    Posts: 2
    Rate: 3
    I thought this might be useful to someone. I bought a smart touch switch, but couldn't find any wiring examples, so I'm sharing my method. The idea of ​​desoldering the processor and reflashing it isn't exactly appealing to me. It's too complicated and tedious. But drilling down to the contacts with a Dremel is quite a good idea, so that's what I ended up using.
    By the way, I borrowed this meI thought this might be useful to someone. I bought a smart touch switch, but couldn't find any wiring examples, so I'm sharing my method. The idea of ​​desoldering the processor and reflashing it isn't exactly appealing to me. It's too complicated and tedious. But drilling down to the contacts with a Dremel is quite a good idea, so that's what I ended up using.
    By the way, I borrowed this method from >>21741840 and modified it a little by soldering one wire core. Now for the basic board information: I've marked VCC (3.3v) and GND on the connector. I've also marked the processor's RX and TX pins in yellow and purple, respectively. However, it is important to note that the board originally had a resistor R1 and a capacitor C1 (together an RC circuit), which distorted the signal from my USB TTL converter. It took me a long time to figure out why the processor wasn't flashing, but when I connected the oscilloscope, everything became clear to me. I soldered them out and the firmware started to flash. As I understand it, they were specially added to distort the signal and they can not be returned after flashing. And yes, for the RX firmware, the wire can be soldered to the upper solder contacts of the resistor and capacitor. The lower one can be used as GND. But the TX line is not connected to anything, you either need to get to the contact with a needle or a thin wire, or, like me, just take off part of the processor case with a nap, seal the contact and solder. Good luck with the firmware.

    Close-up of blue PCB with green and blue wires soldered onto it
    [BK7231N / T34 ] Teardown Tuya Generic Wifi Wall Light Switch 3 Gang

    Update. If you have a squeak on a board with relays and AC/DC and it is critical for you, it is solved by adding a capacious capacitor (I used 200uF+) between GND and 3.3V (I soldered the capacitor to the terminals of the connector connecting the two boards). Also, AC/DC can also emit a squeak at low load due to sleep mode, I solved this by connecting a quenching resistor (330 ohms) between GND and 12V, as well as reducing the capacitor capacity of this line from 1000uF to 200uF. Now the whole system works almost silently... I can only hear the treble beep when I bring the switch to my ear, from 50 cm I can no longer hear it even if I listen.
    Attachments:
    • readResult_BK7231N_QIO_touch-light-switch_2026-31-1-19-42-05.bin (2 MB) You must be logged in to download this attachment.
  • #117 21923087
    Blisk
    Level 7  
    Posts: 33
    I just can't flash anything anymore, I have T34 chip which I flashed 7 of them before, but now not possible anymore, I checked connection and all is ok, any idea? I laso changed USB TTY and it is the same.
  • #118 21923095
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14612
    Help: 655
    Rate: 12630
    Is your USB to UART converter broken? Have you tried another one? If by "changed USB TTY" you mean you have tried another one, then maybe something on PC side?
    Helpful post? Buy me a coffee.
  • #119 21923122
    Blisk
    Level 7  
    Posts: 33
    >>21923095 yes I have 3 more and tested all of them and flashing doesnt work. I tried on my PC and laptop and it is the same, just doesn't work.
  • #120 21923353
    Tilator
    Level 12  
    Posts: 133
    Help: 2
    Rate: 13
    >>21923122

    Are they exactly similar to those you flashed before?

    Or is it possible, the connections are different on the motherboard. It only takes for example one more capacitor connected to TX or RX line and flashing is prevented.

    Chinese manufacturers change them all the time.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion focuses on the teardown and flashing process of Tuya generic WiFi wall light switches based on the BK7231N chip and T34 board, particularly 3-gang and 2-gang variants. The T34 chip is in a QFN package with no accessible programming pads, requiring desoldering for flashing with OpenBeken firmware. Users share detailed methods for desoldering and resoldering the T34 chip using hot air guns (temperatures around 350-480°C), flux, and soldering techniques, emphasizing the difficulty due to tiny pads and risk of PCB damage. Alternatives like needle probes for direct serial connection are discussed but often limited by concealed pads. Flashing is done via UART or SPI using FTDI232RL or CH340G-based USB-TTL adapters, with baud rates up to 921600. Some users report success without grounding the CEN pin by interrupting 3.3V supply to enter flash mode. Firmware extraction challenges include missing or manually created JSON configs. The devices often include additional components like BL0937 power measurement chips and WF480RA RF transceivers for remote control, sometimes unadvertised. Community members provide pin mappings for relays, buttons, and LEDs, and share templates for OpenBeken configuration. PowerSave mode and local NTP server support in OpenBeken are also mentioned. The discussion includes warnings about the complexity of flashing T34 devices, recommending caution and skill in SMD rework. Some users note differences in PCB versions, with older white-box versions having accessible TX/RX pads. Overall, the thread serves as a comprehensive resource for hardware hacking and firmware replacement on T34-based Tuya switches.
Generated by the language model.
Today's popular

FAQ

TL;DR: At 480°C and 921600 baud, one expert conclusion was: "Bridge CEN is not needed." This FAQ helps OpenBeken users flash hard-to-access Tuya T34/BK7231N wall switches, recover pin maps when config extraction fails, and avoid common UART, power, and LED pitfalls on 1–3 gang boards. [#21007722]

Why it matters: These Tuya switches can look identical at purchase time, yet one version may flash from exposed pads while another requires chip removal, needles, or pogo-pin probing.

Method Hardware access Risk level Proven result in thread
Hot-air chip removal Full T34 desolder High Worked, but described as "not for the faint of heart"
Needle / sewing-needle UART Touch hidden pins in-circuit Medium Successful dump and flash without desoldering
Pogo-pin probe rig Weighted vertical probes Medium Used to flash multiple T34 devices quickly
Exposed factory pads Direct board pads Low Some later boards flashed easily from pads

Key insight: The hardest part is usually not OpenBeken itself. It is gaining stable electrical access to T34 UART, then keeping power, contact pressure, and baud rate stable long enough to read or write flash.

Quick Facts

  • One 3-gang T34 switch shipped with Tuya firmware 1.3.10, blocked Cloudcutter, and had four board pads where only 3.3 V and GND were identified as useful for power, not direct flashing. [#20968165]
  • Reported hot-air settings ranged from 400°C to 480°C, with one successful T34 removal taking under 60 seconds and another user running the fan at maximum speed. [#21049685]
  • Successful direct flashing reports used 921600 baud and also 230400 baud on similar T34 boards, but unstable setups produced read or write failures even after a nominally successful erase. [#21007722]
  • One buyer paid 1.87 euro per switch on 2024-03-18, which explains why some users still accepted the extra rework needed for T34 packages. [#21008716]
  • A cheap $50 hot-air station could fail at 450°C, while a $400 station removed the same part at 350°C; the temperature number alone was not a reliable benchmark. [#20975908]

How do you flash a Tuya T34/BK7231N wall light switch with OpenBeken when the module has no exposed programming pads?

You flash it by either removing the T34 or reaching its hidden UART pins in-circuit. 1. Open the switch by prying off the glass front and unclipping the board. 2. Expose UART by hot-air desoldering the QFN T34 or by touching RX/TX with needles or pogo probes. 3. Dump first, then write OpenBeken with a BK7231N-compatible tool and restore the board carefully. One successful 3-gang case needed full T34 removal because no programming pads reached the chip. [#20968165]

Why does Tuya config extraction sometimes fail on T34 firmware dumps with 'no json start found', and how can you recover the pin mapping manually?

It fails because the dump can contain Tuya data that the extractor does not parse cleanly, even though the configuration still exists in flash. You can recover the mapping by reading decrypted strings or boot logs and matching relay, button, and LED pins manually. On one 3-gang dump, the author rebuilt the map by inspection and published P8 as WiFi LED, P14/P26/P28 as relays, and P22/P23/P24 as buttons. That gives a working template even when automatic extraction fails. [#20968165]

What is the CEN pin on a T34 or BK7231N, and how is it used during flashing?

CEN is a control pin used to reset or enable the chip during entry to flashing mode. Early attempts grounded it because that was thought necessary, but later successful T34 flashes showed it was not required. A direct report stated, "Bridge CEN is not needed," and flashing started by interrupting 3.3 V on pin 8 instead. That makes CEN optional in this thread’s T34 cases, not a mandatory wire for every setup. [#21007722]

What is the BL0937 chip in Tuya smart plugs and switches, and why does it matter for OpenBeken PowerSave settings?

"BL0937 is an energy-measurement IC that reads electrical parameters, uses timing-sensitive signals, and appears in some Tuya plugs and switches, which makes aggressive MCU sleep settings more sensitive than on simple relay-only boards." It matters because one OpenBeken maintainer said PowerSave is fine on devices without BL0937, but BL0937 devices may need a different PowerSave approach. A 2025 plug example without BL0937 ran cooler after PowerSave, while BL0937 cases were called out as exceptions. [#21486413]

Which hot air settings work best for desoldering and resoldering a T34 QFN chip without frying the PCB or blowing away nearby SMD parts?

No single temperature works best; station behavior matters more than the number on the display. The safest thread-backed practice was: 1. Use Kapton tape on nearby parts. 2. Use a narrow nozzle and the lowest setting that actually melts solder on your station. 3. Verify on scrap boards before touching T34. Reported successful settings ranged from 400°C to 480°C, but a maintainer showed that 350°C on different stations produced very different real temperatures and heating times. [#21050033]

When flashing a T34, why might interrupting 3.3V or briefly making and breaking the TX connection work better than grounding CEN?

It can work better because the chip often enters the bootloader on a power-state transition or a momentary valid UART event, not from a permanent CEN short. One T34 user flashed successfully by interrupting 3.3 V on pin 8, and another later discovered that briefly lifting and re-touching the TX probe triggered communication. Those reports point to timing and contact quality as the real issue on hidden-pin T34 boards. [#21636218]

What OpenBeken pin configuration works for the Tuya Generic Touch Light Switch 3 Gang with T34 and BK7231N?

A proven 3-gang OpenBeken mapping is P8 = WifiLED;55, P14 = Rel;1, P22 = Btn;3, P23 = Btn;2, P24 = Btn;1, P26 = Rel;2, and P28 = Rel;3. The same thread also shared an ESPHome layout using P22/P23/P24 for buttons, P28/P26/P14 for relays, and P8 as an inverted status LED. That configuration came from a firmware dump and manual reverse-mapping after extractor failure. [#20968165]

How can you flash a T34 directly in-circuit with needles, pogo pins, or trace access instead of removing the chip?

You can do it by contacting the hidden UART points mechanically and avoiding full chip removal. 1. Solder stable 3.3 V and GND first. 2. Touch RX and TX with sewing needles, pogo probes, or accessible traces. 3. Start the flasher, then adjust contact pressure or re-touch TX until the bus syncs. One user dumped and flashed a concealed-leg T34 entirely in-circuit with sewing needles, and another later flashed multiple boards using vertical pogo-pin rods resting by weight. [#21117908]

BK7231GUIFlashTool vs hid_download_py: which is better for backing up and flashing T34/BK7231N devices?

Neither was presented as universally better; the thread treats them as complementary. BK7231GUIFlashTool is convenient for guided UART flashing, while hid_download_py was suggested when readout problems persisted and users needed an alternative path. One maintainer explicitly recommended trying the Python tool after UART read issues, alongside timeout tuning and shorter wires. In practice, the better choice in this thread was the one that matched your adapter, wire quality, and board behavior on that specific T34. [#21031906]

Why does a freshly flashed T34 switch sometimes fail to start the OpenBeken WiFi AP even though the write process reports success?

The usual cause is not the firmware file alone; it is unstable flashing, bad contact, or a partial write that still looked successful during the session. One 2025 case erased and wrote sectors, but the switch never entered AP mode after five power cycles, the WiFi LED flashed weakly once, then stayed bright blue, and even writing the original backup back failed at sector 0x11000. That pattern points to corrupted flash contents or unreliable electrical access during programming. [#21619518]

What causes UART flashing read or write errors on T34 boards, and how do wire length, baud rate, power supply quality, and USB-TTL adapters affect reliability?

Long wires, unstable 3.3 V, noisy supplies, weak USB-TTL adapters, and mismatched baud rates all cause failures. The thread gave concrete fixes: shorten wires, tune UART timeouts, try 115200 to 921600 baud, and avoid relying on the UART adapter’s 3.3 V pin for full module power. One user fixed repeated read errors simply by changing the lab supply, while others reported old adapters failing and FTDI232RL or CH340G working better. Enough current matters, especially once Wi-Fi starts. [#21032083]

How do you configure the WiFi LED on T34-based wall switches so it turns off after connecting instead of staying bright blue all the time?

Set the LED pin to the opposite WiFi LED polarity. A 2026 report solved the always-on blue LED by changing the original setting from WifiLED_n to WifiLED. Another 2025 ESPHome example used an inverted GPIO output on P7, but that could also change button backlight behavior. The simplest OpenBeken fix in this thread was to try WifiLED versus WifiLED_n on the same LED pin until the post-connect state matches your hardware. [#21810549]

What’s the difference between T34, CB2S, and CB3S Tuya modules when choosing a smart switch that is easier to reflash?

T34 is the risky choice when the board hides UART and exposes no usable pads. The thread repeatedly warned against buying T34-based switches because flashing often required chip removal, needles, or rework. By contrast, older stock in white boxes and some CB2S-based units were reported with accessible TX/RX pads, making them much easier to reflash. One buyer even advised looking for white-box stock specifically to avoid T34 trouble. [#21009070]

Which USB-to-UART adapter is more reliable for T34 flashing, CH340G or FTDI232RL, and why do some adapters fail on these boards?

Both CH340G and FTDI232RL can work, but the thread gave FTDI232RL a slight edge for stability on difficult boards. One user used an FTDI232RL-based red adapter successfully and said CH340G also works, while another failed with older adapters and had to switch hardware before flashing succeeded. Adapters fail when they provide noisy power, insufficient current, or marginal UART timing. The chip choice matters less than clean 3.3 V, solid contact, and a converter that handles the board reliably. [#21049770]

How could you program or access a T34 through alternative pins like JTAG or board-side MCU pads when RX and TX are hard to reach?

The thread did not provide a confirmed JTAG flashing method for T34. One later analysis noted that some board-side pads appear to reach a small companion MCU and that T34 pins P22 and P23 map to JTAG TDO and TDI in normal operation, but this stayed a hypothesis. The only proven alternatives in the thread were UART through hidden legs, exposed traces, removed companion parts, or board pads that happened to break out power and serial. Treat JTAG access here as unverified. [#21326143]
Generated by the language model.
ADVERTISEMENT