logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[T34/BL0937] Teardown Generic Wifi Smart Plug with Energy Measurement

Raufaser 36009 143
Best answers

How can I flash a T34/BL0937 smart plug when the UART pads are hard to access?

Use a very fine-wire or needle method instead of trying to solder thick leads directly to the T34. The most practical setup in the thread is to leave the T34 on the PCB, solder 3.3V and GND to the AMS1117 pins, take TX from the exposed pad/resistor point, and touch RX with a sewing needle or thin enameled wire on pin 25; several users also needed an external 3.3V supply and a few power cycles before the flasher connected [#21044837] [#21373301] [#21334978] One reply notes that only one UART line is actually broken out on some boards, so flux and very precise soldering are needed, and if all else fails you can desolder the T34 and flash it off-board, though that is risky [#21005230] If your revision uses a BL0942/BL0492 energy meter instead of BL0937, flashing can be easier by connecting to the meter chip’s UART pins 9/10 plus VCC and GND, without modifying the T34 itself [#21364027] [#21420827]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #121 21439997
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14444
    Help: 650
    Rate: 12414
    The button doesn't work because probably the wrong pin index is configured? Try extracting the configuration with this method:
    https://www.youtube.com/watch?v=WunlqIMAdgw
    or use GPIO Doctor: https://www.elektroda.com/rtvforum/topic3976371.html
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #122 21440258
    EchoSin
    Level 9  
    Posts: 3
    >>21439997 .
    Extracting the configurations by means of the video failed: `Failed to extract keys` (from both the 2 MB file and the 72 kB file).
    I clicked through all the pins in GPIO Doctor and found 3 pieces from relay, button and wifi led and they turned out to be the same as in the configuration I imported earlier (QNCX) Generic Smart Plug with Energy Measurement (T34) (LSPA9 clone).

    I re-imported this configuration and, to my delight, the button started working!

    Chip temperature: 58 °C. Is this the normal temperature of the socket standby chip?

    Thanks for your help.
  • #123 21440305
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14444
    Help: 650
    Rate: 12414
    This is a tiny temperature and in addition it is only shown for reference, it is not a precise measurement. For comparison, my dev board:
    OpenBK7238 user interface with temperature and humidity readings. .
    My LEDs above the window:
    Screenshot of a user interface displaying BK7231T system parameters. .
    If you want to try to reduce the temperature and you are not using BL0937, you can try to autoexec.bat or to the startup command line add PowerSave 1 .
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #124 21440480
    EchoSin
    Level 9  
    Posts: 3
    >>21440305 .
    Thanks, you've cleared up my doubts.
    I care about the energy measurement, so I'll leave it as is.
    I may end up taping the housing already (maybe I'll try to add a screw or two).
  • #125 21451164
    Slash402
    Level 5  
    Posts: 8
    Hi everyone,
    I've been following this thread because I'm interested in flashing a smart plug that uses these chips. However, I'm quite new to this topic and would really appreciate some guidance.

    1. Which schematic should I follow to perform the flash? Should I connect to the T34 chip, or are the flashing pins also available on the BL0937?
    2. Is the 3V supply from the TTL-USB adapter sufficient, or do I need an external power source?
    3. Which specific firmware should I flash?

    Thanks in advance for any help!
  • #126 21451202
    rufus4
    Level 11  
    Posts: 65
    Rate: 9
    welcome,
    1. Go the way that suits you. If it does not work, choose another.
    2. This depends on the adapter. If it has a big capacitor, it could work. If not, better use an external power supply.
    3. Go with the newest, maybe visit the changelog to be informed about bigger changes.
  • #127 21451367
    Slash402
    Level 5  
    Posts: 8
    >>21451202
    1. I'd rather not, we're talking microsoldering here, I don't wanna go trial and error if people have already done and found the correct way before me. Also, that doesn't really answer my question regarding if the pins on the BL0937 can be used or not.
    2. This is the adapter that I have https://www.amazon.it/dp/B07TFSZ3ZP is there a way to tell if it's gonna work?
    3. Umm, I only know about this tool https://github.com/openshwprojects/BK7231GUIFlashTool and I'm not really sure what chip to select when flashing as none of the ones I have are listed?
  • #128 21451911
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    Slash402 wrote:
    >>21451202
    1. I'd rather not, we're talking microsoldering here, I don't wanna go trial and error if people have already done and found the correct way before me. Also, that doesn't really answer my question regarding if the pins on the BL0937 can be used or not.
    2. This is the adapter that I have https://www.amazon.it/dp/B07TFSZ3ZP is there a way to tell if it's gonna work?
    3. Umm, I only know about this tool https://github.com/openshwprojects/BK7231GUIFlashTool and I'm not really sure what chip to select when flashing as none of the ones I have are listed?

    Trying to answer your questions:

    If the layout of your T34 chip allows to access the pins with needles, you may try to adopt the solutions shown in this thread:
    https://www.elektroda.com/rtvforum/topic4051203.html
    The pins are not connected to the BL0937.

    Usually it's impossible to tell if a specific adapter works, but they usually do. I would advise to use a separate power supply in every case, but it might be sufficient to power the pins of the plug with a power supply, sometimes 12 to 15V is enough to start the plug without connecting to high voltage.

    T34 is the "BK7231N" chip.
  • #129 21453078
    Slash402
    Level 5  
    Posts: 8
    Thanks, that clarified things quite a bit.

    max4elektroda wrote:
    Usually it's impossible to tell if a specific adapter works, but they usually do. I would advise to use a separate power supply in every case, but it might be sufficient to power the pins of the plug with a power supply, sometimes 12 to 15V is enough to start the plug without connecting to high voltage.

    I'm not quite sure about one thing: why do I need to supply 12/15V if the pin requires 3.3V? Wouldn't I risk damaging something by providing 12V?

    Also, I noticed that some people add a capacitor to the TTL. Why is that? Is there a guide I can read to understand how to do it? Unfortunately, I couldn't find much on the forum.
  • #130 21453241
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14444
    Help: 650
    Rate: 12414
    I think Max meant that you can connect 12V DC to the input of the plug directly. Not to the 3.3V rail, of course! That would burn WiFi module.

    Capacitor to TTL or to AMS1117-3.3V? If you mean the later, then answer is in the AMS1117 datasheet. It's recommended and required for stable voltage.
    Helpful post? Buy me a coffee.
  • #131 21453273
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    p.kaczmarek2 wrote:
    connect 12V DC to the input of the plug directly. Not to the 3.3V rail

    Exactly, sorry if this was not clear.
    I have some plugs which works perfectly on 12V on the "high voltage input", the plugs contacts, usually plugged into the power outlet, some which obviously will need more voltage and won't start that way.
    As long as you have a decent 3.3V supply, use that.
  • #132 21454169
    Slash402
    Level 5  
    Posts: 8
    >>21453241
    p.kaczmarek2 wrote:
    I think Max meant that you can connect 12V DC to the input of the plug directly. Not to the 3.3V rail, of course! That would burn WiFi module.

    Oh I see. So instead of connecting to the 3V3 pin, I can just try to power the device using 12/15V?

    p.kaczmarek2 wrote:
    Capacitor to TTL or to AMS1117-3.3V? If you mean the latter, then answer is in the AMS1117 datasheet. It's recommended and required for stable voltage.

    I mean things like this I saw in the forum https://obrazki.elektroda.pl/6133912500_1714225565.png (capacitor attached to the TTL adapter).
  • #133 21523164
    Slash402
    Level 5  
    Posts: 8
    >>21454169
    Update. I managed to flash it fine, just by using the TTL adapter and nothing else.
    Just a couple of questions if anyone knows.
    1. Is it possible to set up a routine (eg. turn on at X time, turn off at Y time) that will keep working without being connected to a network?
    2. Is it possible to flash ESPHome via OTA in case I'd like to?
    Thanks.
  • ADVERTISEMENT
  • #134 21584105
    spleefer90
    Level 7  
    Posts: 17
    Help: 1
    Rate: 5
    I wish I had found this thread before doing everything - this is my working attempt, I held the 3v3 with my hand which came handy when I was resetting power.

    [T34/BL0937] Teardown Generic Wifi Smart Plug with Energy Measurement
    [T34/BL0937] Teardown Generic Wifi Smart Plug with Energy Measurement
  • #135 21622865
    Drakarah
    Level 6  
    Posts: 8
    Help: 1
    Rate: 2
    I have a variant of this board (bought from https://nl.aliexpress.com/item/1005008591175083.html), which at first I thought was the board from https://www.elektroda.com/rtvforum/topic4099021.html but in green as the antenna layout is the same, but it comes with a BL0937 instead of a BL0942.

    Smart plug PCB with visible power terminals and microchips, close-up view

    The T34 has a different serial 244TGF187 but the pinout is the same, I confirmed 3.3v and GND with the pins on BL0937, and TX is also broken out to an unpopulated pad, which leaves RX being the hardest pin to tap into. I don't think that pin is used anywhere so I'll have to use the needle method or push my luck with trying to solder some enameled wire to a 0.2mm exposed area (I have never micro soldered before).

    Edit:
    To my own surprise I managed to solder the wires

    Close-up of a PCB with thin wires soldered to microcontroller pins

    And was able to dump the firmware


    Edit2:

    Flashed succesfully and the config for the pins is working (https://www.elektroda.com/rtvforum/topic4042412.html#21030449). The wifi is really bad though, worse RSSI than other smart plugs on the same location.


    Edit3:

    It doesn't seem to like HA discovery, the moment it queues the HA discovery it warns about low heap memory and then ultimately reboots
    Code: text Expand Select all Copy to clipboard
    
Info:MAIN:Time 44, idle 222630/s, free 62504, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic TuyaSmartplug10/power_apparent/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic TuyaSmartplug10/power_reactive/get
Info:MAIN:Will do request HA discovery now.
Info:HTTP:HASS counts: 1 rels, 0 pwms, 0 inps, 0 excluded
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic TuyaSmartplug10/power_factor/get
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_0/config, 1 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_138/config, 2 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_1/config, 3 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_2/config, 4 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_9/config, 5 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_10/config, 6 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_11/config, 7 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_3/config, 8 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_4/config, 9 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_7/config, 10 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_6/config, 11 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_12/config, 12 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_13/config, 13 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_8/config, 14 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_20/config, 15 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_21/config, 16 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_22/config, 17 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_23/config, 18 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_sensor_24/config, 19 items in queue
Info:MQTT:Queued topic=homeassistant/switch/TuyaSmartPlug10_relay_0/config, 20 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_temp/config, 21 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_rssi/config, 22 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_uptime/config, 23 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_build/config, 24 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_ssid/config, 25 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/TuyaSmartPlug10_ip/config, 26 items in queue
Info:MQTT:Publishing val (324 bytes) to homeassistant/sensor/TuyaSmartPlug10_sensor_0/config retain=1
Info:MQTT:Publishing val (350 bytes) to homeassistant/sensor/TuyaSmartPlug10_sensor_138/config retain=1
Info:MQTT:Publishing val (324 bytes) to homeassistant/sensor/TuyaSmartPlug10_sensor_1/config retain=1
Error:MAIN:Low heap warning!
    Attachments:
    • readResult_BK7231N_QIO_testT34_2025-01-8-10-27-19.bin (2 MB) You must be logged in to download this attachment.
  • #136 21705855
    Slash402
    Level 5  
    Posts: 8
    I didn’t get any replies last time, so I’ll try again:
    Is it possible to set up a routine (for example, turning on at time X and off at time Y) that will still work even if the device is not connected to a network? If yes, how?
    Thanks.
  • ADVERTISEMENT
  • #137 21705865
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14444
    Help: 650
    Rate: 12414
    Maybe addClockEvent?

    As long as NTP gets time and device won't reboot, it will work.

    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md

    If your device will get a reboot (power off and on), then time will be lost - it's not possible to maintain time due to the power loss. You'd have to use battery backup like CR2032 etc

    Added after 1 [minutes]:

    EDIT: I don't know about ESP stuff, they have used some strange OTA format that is not easily generated by our SDK. But I can help you with getting clock automations running.
    Helpful post? Buy me a coffee.
  • #138 21706189
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    @Slash402 can you explain a bit more the conditions?
    You don't have any internet at the place or don't trust it?
    How complex is the switching schedule?
    Don't get me wrong, but for a simple on off at the same time every day a common cheap timer will provide all you need, usually including a battery backup for the clock.

    The problem is, as pointed out, the loss of time if device loses power or restarts e.g. on a watchdog event.
    Modifying the switches is a bit risky, usually the pins like GND will have mains potential, so all connections need to be well isolated or need an optocoupler or another galvanic isolation.
    If modifying is an option you might add an rtc with battery backup or go for an alternate time source like GPS or a radio time like DCF77 in Germany.

    You might also go for an approach with a second device with a stable time source acting as access point for your smart switch and providing the time.

    Added after 48 [minutes]:

    A "simple complex" setup, like the one I use, would be this (I have it as startup command) to switch on a light "while it's dark outside".
    (caution: I had to remove comment lines on LN882H or it would reboot on saving - though it was successfully saved)

    Code: text Expand Select all Copy to clipboard
    // start NTP and set timezone and daylight saving time
startdriver ntp
ntp_timeZoneOfs 1
CLOCK_CalcDST 0 3 1 2 60 0 10 1 3 0
// set geo to later calculate sunrise sunset
ntp_setLatLong 52.5244  13.4105
waitFor NTPState 1
// initially set on or off - relay is on channel 0
// on if it is before sunrise or after sunset
// off if it is after sunrise but before sunset
if $hour*3600+$minute*60+$second-$sunrise<0||$hour*3600+$minute*60+$second-$sunset>0 then setChannel 0 1
if $hour*3600+$minute*60+$second-$sunrise>0&&$hour*3600+$minute*60+$second-$sunset<0 then setChannel 0 0
// repeatedly (every day = 0xff) turn on on sunset / turn off at sunrise
addClockEvent sunset 0xff 31 setChannel 0 1
addClockEvent sunrise 0xff 32 setChannel 0 0
  • #139 21710347
    Slash402
    Level 5  
    Posts: 8
    p.kaczmarek2 wrote:
    Maybe addClockEvent?

    As long as NTP gets time and device won't reboot, it will work.

    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md

    If your device will get a reboot (power off and on), then time will be lost - it's not possible to maintain time due to the power loss. You'd have to use battery backup like CR2032 etc

    EDIT: I don't know about ESP stuff, they have used some strange OTA format that is not easily generated by our SDK. But I can help you with getting clock automations running.


    I see, thanks for the information. Yes, I’d really appreciate your help setting up the clock automations.


    max4elektroda wrote:
    can you explain a bit more the conditions?
    You don't have any internet at the place or don't trust it?
    How complex is the switching schedule?
    Don't get me wrong, but for a simple on off at the same time every day a common cheap timer will provide all you need, usually including a battery backup for the clock.


    Yes, the plug is located in an area of the house with no internet access (at least for now, I might add an access point in the future).
    It’ll only be used there for about 15–20 days a year, so not for a long time. Precision isn’t really important, even if it drifts by a minute per day, that wouldn’t be an issue for this setup.

    The automation should be very simple: turn on at a specific time and off at another. The plug will stay powered the whole time, so it shouldn’t lose power. If that ever happens, I can easily reach it and connect through a phone hotspot, for example. That would also work if it needs an internet connection for the initial setup.

    I know a cheap timer plug could probably do the same job, but since I already have this smart plug, if setting up this automation isn’t too complicated and the time drift over those few days isn’t significant, I’d rather just use it.
  • #140 21710407
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    I would think this is a good case for my extension to the clock in PR#1729.
    I will later add one for your device which will provide a simple method to set the clock to your devices time in the GUI (ENABLE_CLOCK_PMNTP - I christened it "poor man's NTP"). No need for a network, you can leave it even in AP mode as long as no one will misuse the open AP.

    Then a simplified version of the above is sufficient: only add two repeated events every day to switch the relay on and off.

    Added after 1 [hours] 8 [minutes]:

    Set clock with GUI:

    [T34/BL0937] Teardown Generic Wifi Smart Plug with Energy Measurement


    Possible "Script" (e.g. as startup command):

    Code: text Expand Select all Copy to clipboard
    addClockEvent 19:00:00 0xff 11 POWER ON
addClockEvent 23:00:00 0xff 12 POWER OFF
    Attachments:
    • OpenBK7231T_App_BKN_PMTP_6c0b05210aa2_OpenBK7231N_powerMetering.zip (3.1 MB) You must be logged in to download this attachment.
  • #141 21710799
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    If you don't want it in startup command, but use in "Execute User Command" you can insert two commands with "backlog" like

    backlog addClockEvent 19:00:00 0xff 11 POWER ON ; addClockEvent 23:00:00 0xff 12 POWER OFF

    Command Tool interface with entered command scheduling power on/off times
  • #142 21718107
    Slash402
    Level 5  
    Posts: 8
    >>21710799 Ok, thanks. Quick update: I successfully flashed your firmware, and setting up the time works perfectly. However, I tried configuring the two commands both through “Execute User Command” and as Startup commands, but nothing happens when the scheduled time is reached. Any idea what might be wrong?

    EDIT. The issue was backlog. Launching one command at a time fixed the issue and now it's working correctly.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on the teardown, flashing, and firmware modification of generic WiFi smart plugs featuring the T34 chip with integrated energy measurement capabilities, primarily using the BL0937 or BL0942 power metering ICs. Users report challenges soldering to the T34 chip due to fragile pads and limited access to UART pins, with some resorting to desoldering the chip or using fine wires and needles to establish serial connections. Flashing is typically done via UART with external 3.3V power supplies to ensure stable operation, as USB-TTL adapters alone often lack sufficient current. The T34 chip is identified as BK7231N-based, treated either as a chip or board module in firmware configurations. Firmware flashing is performed using OpenBeken and BK7231Flasher tools, with users sharing pin mappings and configuration templates for BL0937 and BL0942 drivers. PowerSave mode behavior is discussed, with reports of inconsistent functionality in newer firmware versions. MQTT integration issues affecting relay startup states are resolved by resetting MQTT configurations and rediscovering devices in Home Assistant. The community shares detailed hardware photos, pinouts, and flashing procedures, emphasizing the need for precise soldering, proper power supply, and correct firmware settings to enable WiFi connectivity and power metering features. Variants of the smart plug with different power metering chips and PCB layouts are noted, with some devices requiring specific handling of UART lines routed through the BL0942 chip. Overall, the thread provides comprehensive technical guidance for hardware hacking, firmware flashing, and configuration of T34-based smart plugs with energy measurement.
Generated by the language model.
Today's popular

FAQ

TL;DR: With 3.3 V external power and 10 µF restored at the regulator, these T34/BK7231N plugs can be flashed and fully used with OpenBeken. As one expert put it, "T34 will be treated as board". This FAQ is for people converting generic Tuya smart plugs with BL0937 and solving hard-access UART, weak Wi‑Fi, backup, and power-meter setup issues. [#21052849]

Why it matters: These plugs look identical outside, but the thread shows that module type, meter chip, and flashing difficulty can differ drastically between revisions.

Variant Meter chip Flash access OpenBeken setup
T34 + BL0937 BL0937 Hardest; one UART line is awkward, often microsoldering or needle work Use BL0937 pins 6/7/8 plus relay/button/LED pins
T34 + BL0942 BL0942 Easier; UART1 is available on BL0942 pins Start BL0942 driver and calibrate
Older LSPA9 lookalikes ESP8266 / WB2S / CB2S / T34 Varies by module hidden inside Same outer shell can hide different internals

Key insight: The enclosure tells you almost nothing. On these LSPA9-style plugs, the safest workflow is to identify the actual module and meter chip first, then choose wiring, driver, and template from that specific hardware path.

Quick Facts

  • Typical current draw reported for the T34 + BL0937 plug was 4–6 mA idle and 9–13 mA with relay on after the device sat without an active GUI; earlier live-GUI measurements were higher at about 6–8 mA and 11–15 mA. [#21033260]
  • The working BL0937 OpenBeken mapping reported in the thread was: P6 = BL0937CF, P7 = BL0937CF1, P8 = BL0937SEL, P24 = relay, P26 = button, P28 = WiFi LED. [#21052214]
  • A missing capacitor near the AMS1117/AMS117-3.3 regulator was recovered by replacing 5 µF with 10 µF; energy measurement started working again after the 10 µF swap. [#21039554]
  • One stock Tuya boot log exposed the factory configuration directly: relay on P24, main button on P16, total key on P26, Wi‑Fi LED on P28, and BL0937 on P6/P7/P8. [#21238817]

How do I flash a T34/BK7231N smart plug with BL0937 to OpenBeken when the UART pads are hard to access?

Flash it by keeping the T34 on the PCB and using the few accessible points that users verified. 1. Solder or probe 3.3 V and GND at the AMS1117 pins, connect one UART line directly to the T34, and take the other from the nearby resistor point. 2. Use very thin enameled wire, a needle, or clip probes to avoid lifting pads. 3. Power-cycle several times until the flasher catches the bootloader, then back up and flash OpenBeken. This method avoided full chip removal and worked on multiple plugs in April 2024. [#21044837]

What are the correct OpenBeken pin settings for the generic T34 smart plug with BL0937 energy measurement?

The confirmed OpenBeken mapping is P6 = BL0937CF, P7 = BL0937CF1, P8 = BL0937SEL, P24 = Rel, P26 = Btn, and P28 = WifiLED. A later correction changed the LED entry from a generic LED role to the Wi‑Fi LED role so both LEDs behaved correctly. If you import a template, verify the LED entry before testing status indication. [#21031175]

Why does BK7231GUIFlashTool keep showing "Getting bus failed" when flashing a T34 smart plug, and what usually fixes it?

"Getting bus failed" usually means the plug is not entering the bootloader cleanly because power or reset timing is wrong. The most common fixes in the thread were an external 3.3 V supply, very short wires, repeated power cycling, and better ground placement. Several users reported that USB-TTL power alone looked alive but still failed until external power was added. One user also fixed the issue by moving GND to the correct point near the BL0942 pins. [#21420827]

What's the best way to power a T34 smart plug during UART flashing: USB-TTL 3.3V, an external 3.3V supply, or low-voltage input to the plug?

An external 3.3 V supply is the safest proven option in this thread. USB-TTL 3.3 V sometimes worked, but many users hit disconnects, stalled reads, or endless boot failures until they switched to a separate supply. Low-voltage input to the plug can work on some models, but the most repeatable T34 method was direct 3.3 V to the module or regulator area. One user explicitly said the USB-TTL could not keep the device stable and needed external power instead. [#21054371]

How can I back up the original Tuya firmware from a T34 plug, and why do CRC errors or key extraction failures happen?

Back up the full flash first, but expect two different failure classes. CRC errors usually point to unstable flashing conditions, while "Failed to extract keys" means the backup was read yet the extractor could not find usable Tuya JSON. The thread includes a full 2 MB read with matching CRC that still failed key extraction, proving those are separate problems. Another user later managed a successful original Tuya backup after stabilizing wiring and setup. [#21327647]

Why does Wi‑Fi stop working or have very weak RSSI after flashing a T34 plug, and how can bad soldering or RF calibration affect it?

Weak or dead Wi‑Fi on this plug was usually a hardware rework problem, not an OpenBeken template problem. In the clearest case, Wi‑Fi became usable only after the T34 was removed, pads cleaned, and the module hot-air soldered back properly; afterward both Wi‑Fi and the second LED worked again. The thread also warns against clearing RF partitions because factory RF calibration is valuable. If the MAC ended in 00:00:00, that would suggest broken RF data. [#21040846]

What capacitor value should be used near the AMS1117/AMS117-3.3 regulator on this smart plug if the original SMD capacitor is missing?

Use about 10 µF. One user first fitted a 5 µF replacement and regained no normal behavior, then replaced it with 10 µF and restored energy-measurement operation. Another expert reply said the capacitor at the AMS1117/AMS117-3.3 regulator input is usually 10 µF and not highly critical, which matches the successful repair. [#21039554]

How do I get BL0937 power monitoring working in OpenBeken on a T34 plug, including template import and calibration?

Import a BL0937-capable template, reboot, then calibrate the meter in OpenBeken tools. The thread’s working template uses P6/P7/P8 for BL0937 and P24/P26/P28 for relay, button, and Wi‑Fi LED. Users who saw no wattage often had either no BL0937 driver pins configured, had not rebooted after importing, or still needed calibration before watts displayed sensibly. The practical fix was to load the template, reboot, and then calibrate against a real load. [#21327657]

When should I use the BL0937 driver versus the BL0942 driver on T34-based smart plugs with energy measurement?

Use the driver that matches the actual meter chip on your board, not the shell or seller listing. If the plug has an 8-pin BL0937, use BL0937 pin assignments; if it has a 10-pin BL0942 on UART1, start the BL0942 driver. One user had both configured and later removed the BL0942 startup driver after confirming the chip was marked 0937. Mixed setup can cause confusion even if switching still appears to work. [#21375327]

What is LSPA9 in the context of these Tuya smart plugs, and why do visually identical plugs ship with different modules like ESP8266, WB2S, CB2S, or T34?

"LSPA9" is a smart-plug hardware family designation that identifies a recurring Tuya-style plug design, while the internal radio/module can change between production runs. In this thread, the same outer style appeared with ESP8266, WB2S, CB2S, and T34 modules, so the shell was not a reliable indicator of flash method or template. That is why users kept warning that identical-looking plugs may require completely different OpenBeken workflows. [#21005347]

What is the T34 module exactly, and why is it treated as a board/module in OpenBeken while the chip is still BK7231N?

"T34" is a Tuya Wi‑Fi module that integrates the support parts around a BK7231N, so it behaves like a module/board even though the underlying MCU is still BK7231N. The thread settled on treating T34 as the board and BK7231N as the chip because that matches how Tuya presents it and how OpenBeken templates are organized. This distinction matters because pin numbering and template naming follow the module context, not raw silicon naming alone. [#21052849]

How does PowerSave work on BK7231N/T34 devices in OpenBeken, and why can the web UI or logs prevent the plug from entering low-power mode?

PowerSave works, but any frequent HTTP refresh or log polling can keep the device awake. The expert explanation in the thread says even the native main page can disturb sleep because it refreshes state often enough to block low-power entry. Real measurements supported that: current dropped more after users left the plug overnight without an open GUI, reaching about 4–6 mA idle instead of the higher live-view numbers. [#21033183]

What caused the relay state on a T34 plug to switch on at boot and then immediately turn off again, and how was MQTT/Home Assistant involved?

MQTT and Home Assistant state handling caused it, not the relay pin mapping. The log showed channel 0 being set to 1 at boot and then an MQTT message arriving on the set topic with data 0, which forced the relay back off. The problem disappeared after the user disconnected MQTT, deleted the device in Home Assistant, changed the client and group topics, and repeated discovery. That proved the boot glitch was external state replay. [#21294145]

Which GPIO did users choose to connect a DHT22 sensor to on the T34 smart plug?

The thread does not provide a confirmed GPIO for the DHT22 on this BL0937 T34 plug. A user said they had added a DHT22 and liked the result, but no follow-up post in this thread names the exact pin. If you need a verified GPIO, this thread alone does not answer it and you would need GPIO testing on your specific revision. [#21299716]

T34 smart plug with BL0937 vs the newer T34 revision with BL0942 — which variant is easier to flash and configure in OpenBeken?

The BL0942 revision is easier to flash. The reason is simple: BL0942 sits on UART1, so users could tap RX and TX from BL0942 pins 9 and 10 without fighting the hidden T34 pads. By contrast, BL0937 versions often forced awkward access to one UART line, resistor-side pickup, or needle work on the T34 itself. After flashing, the BL0942 version also only needed the BL0942 driver started and then calibration. [#21334813]
Generated by the language model.
ADVERTISEMENT