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
  • #31 21055729
    donotos
    Level 2  
    Posts: 2

    Only the T34 chip is directly soldered 3.3v on pin 8 and GND on pin 32 for this first attempt.
  • ADVERTISEMENT
  • #32 21231803
    Tilator
    Level 12  
    Posts: 130
    Help: 2
    Rate: 13
    Any chance to flash with cloudcutter?
  • #34 21231985
    Tilator
    Level 12  
    Posts: 130
    Help: 2
    Rate: 13
    divadiow wrote:
    do you have a T34 device? what version fw?


    I have T34 device, but haven't yet even plugged it in.

    I suppose FW version can only be found by coupling the device with Tuya system?
  • #35 21231992
    divadiow
    Level 38  
    Posts: 4880
    Help: 427
    Rate: 869
    Tilator wrote:
    I suppose FW version can only be found by coupling the device with Tuya system?


    The only other way I think is by boot log or firmware backup but if you can get those you're already one step away from UART flashing anyway.
  • #36 21238788
    Tilator
    Level 12  
    Posts: 130
    Help: 2
    Rate: 13
    divadiow wrote:
    The only other way I think is by boot log or firmware backup but if you can get those you're already one step away from UART flashing anyway.


    I UART flashed it because it was the easiest way right now.

    However I took a backup from the original Tuya FW. I try to attach it here in case it's useful for you or anybody.
    Attachments:
    • T34_Tuya_bup_2024-24-9-00-22-37.bin (2 MB) You must be logged in to download this attachment.
  • #37 21238817
    divadiow
    Level 38  
    Posts: 4880
    Help: 427
    Rate: 869
    interesting. fw version 1.3.16 - which is not in the known patched list https://github.com/tuya-cloudcutter/tuya-cloudcutter/wiki/Known-Patched-Firmware nor mentioned in any profiles already existing https://github.com/tuya-cloudcutter/tuya-cloudcutter.github.io/tree/master/devices

    Here is the boot log for that fw.

    Code: Text
    Log in, to see the code


    looking at the date of the build though I think it'll be patched. log lists all the pin assignments

    Code: Text
    Log in, to see the code


    submitting to CC team to look into

    Added after 11 [minutes]:

    The image shows an icon of a T34 Smart Plug with the label OFF.
  • ADVERTISEMENT
  • #38 21238842
    Tilator
    Level 12  
    Posts: 130
    Help: 2
    Rate: 13
    >>21238817

    Excellent.

    Is there some kind of simulator to boot it?
  • #39 21238851
    divadiow
    Level 38  
    Posts: 4880
    Help: 427
    Rate: 869
    >>21238842 alas, no. there is no emulator to run Beken binaries
    I just flash to my little dev board and grab/pair with that
    Developer board with an inserted module and a connected USB cable.

    Added after 10 [hours] 11 [minutes]:

    1.3.16 has been added to the known-patched list
  • #40 21293454
    silver_mc
    Level 13  
    Posts: 76
    Rate: 11
    Hello!
    I own a few sockets from openbeken but only the first one from T34. I found an interesting bug. It doesn't matter if I set start value 1 or -1 for channel 0 or in autoexec I add setChannel 0 1 always the socket starts with relay state 1 then immediately changes state to 0. I have the flags set at the factory, only 10 is checked. I'm weak with logs but noticed this one on reboot: Info:GEN:CHANNEL_Set channel 0 has changed to 0 (flags 0). I think this may be affecting this behaviour but please correct me. on other bl602 or ln882 chips this problem does not occur. anyone have any ideas?
  • ADVERTISEMENT
  • #41 21293465
    silver_mc
    Level 13  
    Posts: 76
    Rate: 11
    Hello!
    I have several sockets with openbeken but only one with T34. I found an interesting bug. It does not matter whether I set the start value 1 or -1 for channel 0 or add setChannel 0 1 in autoexec, the socket will always start with relay state 1 and then immediately change state to 0. I have the oem flags set, only 10 is selected. I am not good with logs but I noticed this during restart: Info:GEN:CHANNEL_Set channel 0 has changed to 0 (flags 0). I think that this may have an impact on this behavior but please correct me. On other chips bl602 or ln882 there is no problem. Does anyone have an idea?

    Quote:
    Info:MAIN:Time 165, idle 186974/s, free 46976, MQTT 1(1), bWifi 1, secondsWithNoPing 95, socks 2/38
    Info:MAIN:Module reboot in 1...
    Info:MAIN:Main_Init_Before_Delay
    Info:CFG:####### Boot Count 258 #######
    Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 10 changes count.
    Error:CMD:no file early.bat err -2
    Info:EnergyMeter:Read ENERGYMETER status values. sizeof(ENERGY_METERING_DATA)=32
    Info:MAIN:Started BL0937.
    Info:GEN:PIN_SetupPins pins have been set up.
    Info:MAIN:Main_Init_Before_Delay done
    Info:MAIN:Main_Init_Delay
    Info:MAIN:Main_Init_Delay done
    Info:MAIN:Main_Init_After_Delay
    Info:MAIN:Using SSID [xxxxxxxxxxxxxx]
    Info:MAIN:Using Pass [xxxxxxxxxxxxxxxx]
    Info:MQTT:MQTT_RegisterCallback called for bT OpenBK_T34_gniazdko3/ subT OpenBK_T34_gniazdko3/+/set
    Info:MQTT:MQTT_RegisterCallback called for bT T34_gniazdko3/ subT T34_gniazdko3/+/set
    Info:MQTT:MQTT_RegisterCallback called for bT cmnd/OpenBK_T34_gniazdko3/ subT cmnd/OpenBK_T34_gniazdko3/+
    Info:MQTT:MQTT_RegisterCallback called for bT cmnd/T34_gniazdko3/ subT cmnd/T34_gniazdko3/+
    Info:MQTT:MQTT_RegisterCallback called for bT OpenBK_T34_gniazdko3/ subT OpenBK_T34_gniazdko3/+/get
    Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
    Info:GEN:CHANNEL_Set channel 0 has changed to 1 (flags 0)

    Info:MQTT:Channel has changed! Publishing 1 to channel 0
    Info:CFG:####### Flash Save Channel 0 as 1 #######
    Info:NTP:NTP driver initialized with server=194.146.251.100, offset=0
    Info:MAIN:Started NTP.
    Info:NTP:NTP server set to 194.146.251.100
    Info:NTP:NTP offset set
    Info:MAIN:Main_Init_After_Delay done
    Info:MAIN:Time 1, idle 255802/s, free 79856, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Time 2, idle 191915/s, free 79856, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Time 3, idle 185325/s, free 79856, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Time 4, idle 193511/s, free 79856, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Time 5, idle 185316/s, free 79856, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Registered for wifi changes
    Info:MAIN:Connecting to SSID [xxxxxx]
    Info:MAIN:ssid:silverro key:xxxxxxxxxxxxxxxxxxxxxx
    Info:MAIN:Time 6, idle 182662/s, free 75120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Boot complete time reached (5 seconds)
    Info:CFG:####### Set Boot Complete #######
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Time 7, idle 185834/s, free 74272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Time 8, idle 84885/s, free 74248, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Time 9, idle 0/s, free 74248, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Time 10, idle 0/s, free 74248, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
    Info:GEN:dhcp=0 ip=0.0.0.0 gate=0.0.0.0 mask=0.0.0.0 mac=b8:06:0d:28:61:99
    Info:GEN:sta: 0, softap: 0, b/g/n
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
    Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
    Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
    Info:MAIN:Time 11, idle 74910/s, free 74512, MQTT 0(0), bWifi 1, secondsWithNoPing -1, socks 3/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:NTP:Seconds since Jan 1 1900 = 3939990605
    Info:NTP:Unix time : 1731005405
    Info:NTP:Local Time : 2024-11-07 18:50:05
    Info:MAIN:Time 12, idle 187926/s, free 74760, MQTT 0(0), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MQTT:mqtt_userName xxxxxxxxxxxxxxxxxxxxxx
    mqtt_pass xxxxxxxxxxxxxxxxxxxxxxxx
    mqtt_clientID OpenBK_T34_gniazdko3
    mqtt_host xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    Info:MAIN:Time 13, idle 196328/s, free 74672, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
    Info:MQTT:mqtt_connection_cb: Successfully connected
    Info:MQTT:mqtt_subscribed to OpenBK_T34_gniazdko3/+/set
    Info:MQTT:mqtt_subscribed to T34_gniazdko3/+/set
    Info:MQTT:mqtt_subscribed to cmnd/OpenBK_T34_gniazdko3/+
    Info:MQTT:mqtt_subscribed to cmnd/T34_gniazdko3/+
    Info:MQTT:mqtt_subscribed to OpenBK_T34_gniazdko3/+/get
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic OpenBK_T34_gniazdko3/0/set
    Info:MQTT:MQTT client in mqtt_incoming_data_cb data is 0 for ch 0
    Info:GEN:CHANNEL_Set channel 0 has changed to 0 (flags 0)

    Info:MQTT:Channel has changed! Publishing 0 to channel 0
    Info:MQTT:Publishing val 0 to OpenBK_T34_gniazdko3/0/get retain=0
    Info:CFG:####### Flash Save Channel 0 as 0 #######
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic OpenBK_T34_gniazdko3/0/get
    Info:MQTT:Publishing val OpenBK_T34_gniazdko3 to OpenBK_T34_gniazdko3/host retain=0
    Info:MAIN:Time 14, idle 170270/s, free 74672, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Will scheduled HA discovery in 9 seconds
    Info:MQTT:Publishing val OpenBK7231N 1.17.766 Nov 6 2024 13:53:29 to OpenBK_T34_gniazdko3/build retain=0
    Info:MAIN:Time 15, idle 183098/s, free 74672, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Will scheduled HA discovery in 8 seconds
    Info:MQTT:Publishing val b8:06:0d:28:61:99 to OpenBK_T34_gniazdko3/mac retain=0
    Info:MAIN:Time 16, idle 190375/s, free 71880, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Will scheduled HA discovery in 7 seconds
    Info:MQTT:Publishing val 60.05 to OpenBK_T34_gniazdko3/temp retain=0
    Info:MAIN:Time 17, idle 205965/s, free 74672, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Will scheduled HA discovery in 6 seconds
    Info:MQTT:Publishing val silverro to OpenBK_T34_gniazdko3/ssid retain=0
    Info:MQTT:Publishing val 228.1 to OpenBK_T34_gniazdko3/voltage/get retain=0
    Info:MQTT:Publishing val 1.00 to OpenBK_T34_gniazdko3/power_factor/get retain=0
    Info:MQTT:Publishing val 0.153 to OpenBK_T34_gniazdko3/energycounter_yesterday/get retain=0
    Info:MQTT:Publishing val 3096.700 to OpenBK_T34_gniazdko3/energycounter_3_days_ago/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic OpenBK_T34_gniazdko3/voltage/get
    Info:MAIN:Time 18, idle 187248/s, free 74296, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Will scheduled HA discovery in 5 seconds
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic OpenBK_T34_gniazdko3/power_factor/get
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic OpenBK_T34_gniazdko3/energycounter_yesterday/get
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic OpenBK_T34_gniazdko3/energycounter_3_days_ago/get
    Info:MQTT:Publishing val 1731005411 to OpenBK_T34_gniazdko3/datetime retain=0
    Info:MAIN:Time 19, idle 171636/s, free 74672, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Will scheduled HA discovery in 4 seconds
    Info:MQTT:Publishing val 2 to OpenBK_T34_gniazdko3/sockets retain=0
    Info:MAIN:Time 20, idle 191345/s, free 74672, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:GEN:dhcp=0 ip=192.168.10.131 gate=192.168.10.1 mask=255.255.255.0 mac=b8:06:0d:28:61:99
    Info:GEN:sta: 1, softap: 0, b/g/n
    Info:GEN:sta:rssi=-70,ssid=silverro,bssid=a8:6e:84:83:59:0f,channel=9,cipher_type:CCMP
    Info:MAIN:Will scheduled HA discovery in 3 seconds
    Info:MQTT:Publishing val -69 to OpenBK_T34_gniazdko3/rssi retain=0
    Info:MAIN:Time 21, idle 191876/s, free 74672, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Will scheduled HA discovery in 2 seconds
    Info:MQTT:Publishing val 21 to OpenBK_T34_gniazdko3/uptime retain=0
    Info:MAIN:Time 22, idle 195141/s, free 62976, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38
    Info:MAIN:Will scheduled HA discovery in 1 seconds
    Info:MQTT:Publishing val 74672 to OpenBK_T34_gniazdko3/freeheap retain=0
    Info:MAIN:Time 23, idle 192100/s, free 74672, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Will do request HA discovery now.
    Info:HTTP:HASS counts: 1 rels, 0 pwms, 0 inps, 0 excluded
  • #42 21293488
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    silver_mc wrote:
    Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
    Info:GEN:CHANNEL_Set channel 0 has changed to 1 (flags 0)

    Info:MQTT:Channel has changed! Publishing 1 to channel 0
    Info:CFG:####### Flash Save Channel 0 as 1 #######


    What's the content of your autoexec.bat?

    Added after 6 [minutes]:

    silver_mc wrote:
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic OpenBK_T34_gniazdko3/0/set
    Info:MQTT:MQTT client in mqtt_incoming_data_cb data is 0 for ch 0
    Info:GEN:CHANNEL_Set channel 0 has changed to 0 (flags 0)

    Info:MQTT:Channel has changed! Publishing 0 to channel 0
    Info:MQTT:Publishing val 0 to OpenBK_T34_gniazdko3/0/get retain=0
    Info:CFG:####### Flash Save Channel 0 as 0 #######


    Is the channel set via mqtt?
  • #43 21293505
    silver_mc
    Level 13  
    Posts: 76
    Rate: 11
    >>21293488

    setChannel 0 1 <= this command is only for test
    startDriver NTP
    ntp_setServer 194.146.251.100
    ntp_timeZoneOfs 1
    scheduleHADiscovery 10


    Quote:

    Is the channel set via mqtt?


    I hope not, but I could be wrong. do you think the command comes from HA?
  • ADVERTISEMENT
  • #44 21293917
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    Autoexec looks ok for me.

    I only saw the log showing a mqtt set followed by a "CHANNEL_Set", so it's a question to someone with more HA/MQTT knowledge.

    But you could also try to disable MQTT for a test to see if the behavior changes...
  • #45 21293951
    silver_mc
    Level 13  
    Posts: 76
    Rate: 11
    >>21293917

    You right. After disconnect MQTT and reboot socket relay state is 1. Now I need to find out what happened with MQTT. Thanks for the right lead.
  • #46 21294022
    Tilator
    Level 12  
    Posts: 130
    Help: 2
    Rate: 13
    What happens if you use some other channel?
  • #47 21294027
    silver_mc
    Level 13  
    Posts: 76
    Rate: 11
    I have no idea. :)
  • #48 21294093
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14444
    Help: 650
    Rate: 12414
    Maybe try enabling two "retain" flags from here:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/flags.md
    and then repeat Home Assistant Discovery.
    Helpful post? Buy me a coffee.
  • #49 21294145
    silver_mc
    Level 13  
    Posts: 76
    Rate: 11
    Problem solved.

    What I did. First I disconnected MQTT. Then I deleted the device in HA. Then I changed the name of the client topic and group topic, reconnected MQTT and repeated the discovery.

    Everything works as expected.
  • #50 21299716
    Tilator
    Level 12  
    Posts: 130
    Help: 2
    Rate: 13
    rufus4 wrote:
    That is truth. Leaving the device overnight without active GUI, power dropped much more.
    Finally I added a DHT22 and do start to really love it, even with the T34.


    What GPIO did you use to add the sensor?
  • #51 21300166
    hojnikb
    Level 12  
    Posts: 45
    Rate: 2
    aliexpress wrote:

    I just wanted to mention that I also received this very same T34 type Smart Plug.
    My strategy to get the device flashed:
    - keep the T34 on the PCB
    - use enameled copper wire to attach on the device side ("Kupferlackdraht" in German), I had one with 0.25 mm diameter. The advantage is that this wire is very thin and can fit better to pins of ICs. It also is light and quite flexible - when you move it, it does not provide high forces to the IC pins, so less chance of breaking them off, or stripping off the copper layer of the PCB. Disadvantage: To get the insulation layer off to be able to apply solder is sometimes a bit of a challenge. Then I used ordinary cables to extend these thin wires to attach to PSU and to Serial converter.
    - For P25, I soldered directly to IC pin.
    - For P26, I used the connection at the resistor
    - 3.3V and GND I attached directly to Pins 1 and 2 of AMS1117

    For flashing, I had to power cycle for like 5 times or so until the serial connection was established.
    The dump of original firmware did not contain Tuya keys, according to flasher tool. The socket was Tuya activated before.


    I have the same device, but I'm struggling to get a connecting. I also soldered a thin wire to the pad and empty pin on the motherboard. But no luck.

    Btw, what baudrate is needed for openbeken flash with this particular device?
  • #52 21300624
    Tilator
    Level 12  
    Posts: 130
    Help: 2
    Rate: 13
    >>21300166

    I flashed the same device some weeks ago and I had also some trouble.

    If I remember it right, a CH340 based TTL adapter did not work. I had to use an old PL2303 based Nokia serial adapter. I think the Nokia adapter might be 5V version. Maybe normal 3,3V voltage is not enough while the chip stand on the board.

    An other device was problematic before and I managed to flash it using Cubietruck.
  • #53 21300713
    hojnikb
    Level 12  
    Posts: 45
    Rate: 2
    >>21300624

    I was able to successfully flash it via PL2303 also. But it required me to use an external 3.3V power supply and a quick power off/power on cycle to get it to flash.

    Quite annoying device to bring openbeken to, but it works.
  • #54 21322974
    fatalbullethit
    Level 3  
    Posts: 5
    I was able to flash the T34 as described, however, I'm wondering whether the power metering capabilities can be used at all - any ideas?
  • #55 21323033
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14444
    Help: 650
    Rate: 12414
    Do Tuya Config extraction, set BL0937 pins and it will work well.


    Helpful post? Buy me a coffee.
  • #56 21324532
    rmoriz
    Level 2  
    Posts: 3
    Greetings,

    I just received two Smart Plugs within the same packaging as OP, however the board looks different and the T34 seems to be smaller, around 6x6mm, see photos.

    Thanks
    Roland

    Close-up image of a circuit board with visible electronic components, including integrated circuits and capacitors. Close-up of a circuit board with an integrated circuit labeled T34. Close-up of a circuit board with electronic components, including a T34 chip. Close-up of a circuit board with a T34 2422GWMCP X31CPC microchip. White Smart Plug with a power button on the front.

    Printed circuit board with electronic components, including capacitors and connectors.
  • #57 21324546
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14444
    Help: 650
    Rate: 12414
    Another LSPA9 with T34.... well, it seems they are really using it more often now. I still remember ESP8266 LSPA9 times:
    https://www.youtube.com/watch?v=bnr3DADYcgU
    Then I saw WB2S LSPA9 (not documented by myself).
    and later I of course played with CB2S LSPA9 as well:
    https://www.elektroda.com/rtvforum/topic3887748.html
    And now they are T34-based, hm...

    Anyway, did you attempt to flash it already?
    Helpful post? Buy me a coffee.
  • #58 21324552
    rmoriz
    Level 2  
    Posts: 3
    >>21324546
    My eyes and my hands are too bad to solder anything on that 0,2mm that is left. This looks like a hot air job which is currently not feasible for me. (hot air station is in storage, no space left)
  • #59 21324829
    Tilator
    Level 12  
    Posts: 130
    Help: 2
    Rate: 13
    rmoriz wrote:
    >>21324546
    My eyes and my hands are too bad to solder anything on that 0,2mm that is left. This looks like a hot air job which is currently not feasible for me. (hot air station is in storage, no space left)


    I had the same trouble twice before even though they were not exactly same devices.

    I used a normal sewing needle. Connected it to the TTL adapter wire. It just should be sharp enough to hold still on the leg of the chip.

    I only needed one needle because it was possible to solder a wire to the other serial line.

    Once I got it flashed and up, I updated FW using normal WebUI. Just in case not all flashing was well enoug made by the "needle trick".
  • #60 21325178
    rmoriz
    Level 2  
    Posts: 3
    >>21324829
    thanks for the tip!

    I'm still a bit confused they made it so hard. I can't imagine they flash before assembly. Almost everyone else has pinpoints to flash afterward (using "pogo pins" or other removable solution)
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