[BK7231N ] Teardown and flashing of Tomzn TOMPD-63 WIFI (not to be confounded with TOMPD-63LW)

morgan_flint 19 Dec 2023 19:17 153 27594 Cool? (+8)

📢 Listen (AI):

TL;DR

Teardown and OBK flashing of the Tomzn TOMPD-63 WIFI smart circuit breaker, distinguished from the TOMPD-63LW model that also cuts neutral.
Inside, it uses two PCBs: a latching relay board with BL0942 metering and power supply, plus an LCD/Tuya MCU/WB3S board.
Tuya DpID extraction identified 13 IDs, including total forward energy, switch, leakage current, breaker id, and over-voltage protect/recovery timers.
OBK flashed through RX, TX, and GND without cutting traces, then autoexec.bat started the TuyaMCU driver, mapped channels, and enabled MQTT/Home Assistant discovery.
Some UI fields remain unclear, including the extra "t" setting, and "Alarm set 2" does not display well.

Generated by the language model.

A few days ago I received this device from Aliexpress Link:

The device is similar to others already treated here, for example Tomzn TOML-VA 63A and Earu EAMPDW-TY63, and also TOMPD-63LW mentioned in the title, although the latter is more complete and cuts both line and neutral.

But, despite the external similarities and in functionality, I see from the teardowns that they are different, so I think it's justified to create a new thread. Apart from this, is a good opportunity to put into practice the tutorial I wrote about extracting DpIDs and try to make it work with OBK starting from zero.

So let's start with some photos from the advertisement in Aliexpress, just in case the previous link gets broken:

Now the printed manual that came with the device:

You can already see some differences between the settings in the advertisement and those in the manual. The real thing also included another setting "t" (see next pictures), that can be set to "on" or to a number between 5 and 120.

I haven't been able to deduct what is this setting for.

Now, some photos of the teardown:

Opening the device is very easy: just unfasten the two screws in the holes of the first photo (after pushing apart the lower side lock). It's well constructed; there are two PCBs: the bigger one supports the relay (latching type, no need to keep the coil energized to set it on), the components for the power supply (12V output for the relay and two 3.3V outputs, one with a linear regulator from 12V and the other one with a switch mode one), and the energy metering chip BL0942 (attached English datasheet). The smaller PCB has the LCD screen, push buttons, the Tuya MCU (behind the LCD screen), and the WB3S WiFi module.

Also, here are some screenshots of the Tuya App; you can see there are also differences with the ones from the advertisement:

Now, let's start with the DpID identification process, which should be done before flashing OBK, as we need to access the device from Tuya's developer website. Following the first process in the tutorial, we get this:

{"1":"Total forward energy","6":"Phase A","9":"Fault","11":"Switch prepayment","12":"Clear energy","13":"Balance energy","14":"charge energy","15":"Leakage current","16":"Switch","17":"Alarm set1","18":"Alarm set2","19":"Breaker id","104":"Over Vol Protect Time","105":"Over Vol Recovery Time"}

The same info, written as a list:

"1":"Total forward energy",
"6":"Phase A",
"9":"Fault",
"11":"Switch prepayment",
"12":"Clear energy",
"13":"Balance energy",
"14":"charge energy",
"15":"Leakage current",
"16":"Switch",
"17":"Alarm set1",
"18":"Alarm set2",
"19":"Breaker id",
"104":"Over Vol Protect Time",
"105":"Over Vol Recovery Time"

We can see that there are a total of 13 DpIDs.

Now, jumping to the last method in the tutorial (signaled with [*]) and, after processing the Json as instructed there, we get:

Where, besides the DpID numbers, we have a more complete description of each of them. With this info in hand we will be able to configure OBK so now we can proceed with flashing.

To flash it with OBK, after unplugging the smaller board from the bigger one, is enough to solder just two wires to the RX and TX pads, as Vcc and Gnd can be connected to the header:

I didn't need to cut any traces to flash OBK as the Tuya MCU doesn't seem to interfere with the process (in principle, it should be shut off, as it gets the power from a different pin in the header). To avoid problems, I only connect TX, RX, and GND to the serial to USB adapter, and connect Vcc just after hitting the corresponding key to start flashing in BK7231Flasher.

Once flashed, we can connect our PC or phone to the access point provided by OBK and navigate to 192.168.4.1, where we configure SSID and password for our local WiFi. After rebooting, we have to find in our router the IP assigned to the device and access it with a browser to continue with the configuration. I first configured MQTT and then, by navigating "Launch web application" -> "Filesystem" -> "Create file" I created "autoexec.bat" with the following contents:

Let's explain briefly the contents: The first lines come from similar devices and are there to start the TuyaMCU driver and simulate the connection to the cloud. I commented out the NTP driver, as it doesn't seem to be necessary. The last line also comes from similar devices and, as I understand, is there to force the MCU to send the state periodically.

The lines in between correspond to the previously identified DpIDs, linking them to a channel and setting the channel type accordingly. To make things clearer, I preferred to assign channels with the same number as the DpIDs where possible. I also wrote the following table in Excel to help keep things clear, but it's not really necessary:

After saving the autoexec and rebooting the configuration is finished and we can start using the device with OBK:

In practice, it's not really needed to have so much info, so you can comment out or delete the corresponding lines in the autoexec.bat to eliminate the variables of less interest. Also, some of them don't work as expected (for example, Alarm set 2 doesn't show well, probably because it's too long), but I hope @p.kaczmarek2 will be correcting this in future versions.

Also, after going to "Config" -> "Home Assistant configuration" and hitting "Start Home Assistant Discovery", we can also control the device from Home Assistant:

And that's all for now! It's a long post and I hope I haven't bored you too much, but I think it is better to give as many details as possible for the most novices; the most experienced just can pass over them quickly ;-)

EDIT: corrected label from "Clear Prepayment" to "Clear Energy Counters", as this is what DpID 12 does (thanks, @AngelOf Death)
EDIT: Adding schematic:

Attachments:

359-BL0942-SSOP10L.pdf (952.39 KB) You must be logged in to download this attachment.

About Author

morgan_flint wrote 251 posts with rating 60 , helped 4 times. Live in city Sevilla. Been with us since 2018 year.

Comments

Add a comment

Angel0fDeath 28 Dec 2023 10:41

I have exactly the same device. All DpIDs match exactly. About DpID 104 - From the device I'm able to change the values from 0.5s to 30s with step 0.5s. However with tuya-mqtt.js I always receive this... [Read more]

morgan_flint 28 Dec 2023 13:38

Hello and thank you for your answer. Could be it's prepared for some present or future backlight version, as you say. Mine doesn't have any backlight also. From what you say, I understand your manual... [Read more]

Angel0fDeath 28 Dec 2023 13:41

My manual is exactly the same as yours and actually you have this in your manual - 10th bullet on the first page (Light source). Well I just flashed openbeken on my device have some comments on your... [Read more]

morgan_flint 28 Dec 2023 13:46

Ah, OK. I was missing it on the 2nd page, where it should appear between the last two screenshots, so I thought they might have corrected that [Read more]

Angel0fDeath 28 Dec 2023 17:17

So after I spent a few hours with openbeken firmware, I have the following observations: dpID 104: for 1.0s -> 55 AA 03 07 00 08 68 02 00 04 00 00 00 01 80 for 1.5s -> 55 AA 03 07 00 08 68 02 00 04... [Read more]

p.kaczmarek2 28 Dec 2023 19:10

@angel0fdeath , while you are mostly correct, this is not a bug. We just don't have parsing for raw data, well, maybe except for one format. We have a work around for that in place but it requires writing... [Read more]

morgan_flint 28 Dec 2023 20:29

@angel0fdeath, thanks for your analysis; we had already bumped into these issues with the other device, TOMPD-63LW, in its thread , for example in this post and the following ones. Fortunately, we... [Read more]

Angel0fDeath 28 Dec 2023 21:14

I checked it and the idea is not bad, but since this is a setup channel we will not only need correct parsing to mqqt but backwards also. These are setup values and they have ranges. According to me it... [Read more]

p.kaczmarek2 28 Dec 2023 21:17

Hey, your idea 1 is incorrect because we don't know what is the byte size of each variable, it could be 2, or 4, or maybe 1. I'd phrase it differntly, here are my 3 ideas: A. you can (or maybe even... [Read more]

Angel0fDeath 28 Dec 2023 21:33

My idea 1 was just for splitting and nothing more. I know it is not good since everybody should read docs and to know how splitting works. Your suggestion about HEX string is good enough. I know it is... [Read more]

p.kaczmarek2 29 Dec 2023 11:03

I'm working on it, along with a self test, I hope this will suit your basic needs, then we will work on more advanced version: https://obrazki.elektroda.pl/8567259800_1703839632_thumb.jpg Is the... [Read more]

Angel0fDeath 29 Dec 2023 12:26

The path doesn't matter, I hope it is for testing only. About reaction time - yes you are correct, the user will not notice the difference unless there are some fingers in some socket :). However this... [Read more]

p.kaczmarek2 29 Dec 2023 13:04

So what kind of path would you like? This is almost ready for use, so if you have any feedback, let me know. Once we have this feature tested, we will look into other, more specific solutions. [Read more]

Angel0fDeath 29 Dec 2023 16:03

Leave the path as it is Just for information... It looks like the driver has also problems with string parsing: Info:GEN:No change in channel 10 (still set to 0) - ignoring Info:TuyaMCU:TUYAMCU... [Read more]

morgan_flint 29 Dec 2023 19:28

Yes, the same in mine, it clears both counters. I should correct the label (EDIT: done in the first post) , which is like that because there are two different DpIDs in the other device to clear both counters... [Read more]

Angel0fDeath 29 Dec 2023 21:31

About prepayment - yes correct you cannot change anything until prepayment switch is off, and yes you have blackout and alarm 65536 until you enter something where necessary. This is a poor user manual.... [Read more]

Angel0fDeath 30 Dec 2023 13:56

@morganflint Here is the code to process the fault in HA server It is in perl, but I think you can easily write it in any other language. Although I never received 2 faults at same time I left full processing... [Read more]

morgan_flint 30 Dec 2023 14:36

I share your opinion about the device (and this kind of Chinese devices in general): it has some details that can be/should be improved and the manual is very poor. But, on the other hand, the hardware... [Read more]

Angel0fDeath 30 Dec 2023 18:45

Concerning dpID9 - it is not necessary to reserve 17 channels if you want to resolve this in device - 2 channels are enough - 1 channel for num value and 1 channel for text value - 2 changehandlers 1 i... [Read more]

FAQ

TL;DR: This FAQ helps OpenBeken users flash the Tomzn TOMPD-63 WIFI and map its 13 DpIDs correctly. "Everything seems to be ok" once DpID raw access is enabled, but DpIDs 17, 18, and 19 need special handling, and DpID 12 clears both energy counters on this model. [#20925322]

Why it matters: The TOMPD-63 WIFI looks similar to other Tuya breakers, but its hardware, relay behavior, raw DpIDs, and counter logic differ enough that a copied configuration can fail.

Model	Relay switching	Key DpID differences	Energy clear behavior
TOMPD-63 WIFI	Cuts line only	DpIDs 1, 6, 9, 11–19, 104, 105	DpID 12 clears total and prepaid energy
TOMPD-63LW	Cuts line and neutral	Adds DpIDs 21 and 101; different 104/105 meaning	Counters can be cleared separately

Key insight: Treat the TOMPD-63 WIFI as its own platform, not a TOMPD-63LW clone. The breakthrough was OBK raw DpID access over HTTP/MQTT, which exposed DpIDs 17, 18, and 19 as usable hex or string data instead of broken integers. [#20931165]

Quick Facts

The TOMPD-63 WIFI teardown identified 13 DpIDs: 1, 6, 9, 11–19, 104, and 105, before OBK flashing began. [#20869137]
The protection action time in DpID 104 is documented as 1–30 s, but device users reported menu control in 0.5 s steps from 0.5 s to 30 s. [#20879436]
The recovery delay can be set from 1 to 500 seconds, and the action time and recovery time affect real protection behavior after faults and restarts. [#21508925]
One user bought the device for 11.56€, with a more typical price around 19€, which explains why it became a popular hacking target despite firmware quirks. [#20883189]
Newer hardware revisions appeared with CB3S, CBU, and header-accessible modules; one late board revision no longer required soldering because RX, TX, VCC, and GND were reachable through headers. [#21453780]

How do I flash a Tomzn TOMPD-63 WIFI with a BK7231N/WB3S or CB3S module using OpenBeken, and which RX, TX, VCC, and GND connections are needed?

You can flash it over UART by wiring RX, TX, VCC, and GND to the Wi-Fi module pads or header. 1. Disconnect the small display/Wi-Fi board from the power board. 2. Solder only RX and TX if VCC and GND are already on the header. 3. Power VCC only when the flasher starts, because that avoids interference from the Tuya MCU. Early WB3S boards needed two wires plus header power; later revisions exposed all pins on headers, and CB3S units also flashed successfully with uartprogram ... -w --unprotect -s 0x0. [#21453780]

What is the difference between the TOMPD-63 WIFI and the TOMPD-63LW, especially in relay switching, DpIDs, and energy counter behavior?

The TOMPD-63 WIFI cuts only the line, while the TOMPD-63LW cuts both line and neutral. Up to DpID 19, most DpIDs match, but the LW adds DpID 21 for leakage test and DpID 101 for clearing the main energy counter, and its DpIDs 104 and 105 mean power factor and frequency instead of protection timing. The biggest user-visible difference is DpID 12: on the WIFI model it clears both prepaid and total energy, while on the LW it clears only prepaid energy. [#20921587]

How can I extract and identify the Tuya DpIDs for the TOMPD-63 WIFI before replacing the stock firmware with OBK?

Extract the DpIDs from Tuya first, then flash OBK after you know the map. 1. Use the Tuya developer workflow described in the linked tutorial to pull the product JSON. 2. Read the abilityId, code, and typeSpec fields for each property. 3. Build your OBK autoexec.bat from those DpIDs. The TOMPD-63 WIFI exposed 13 DpIDs, including phase_a on DpID 6, fault on DpID 9, switch on DpID 16, and timing controls on DpIDs 104 and 105. [#20869137]

Why does DpID 104 on the TOMPD-63 WIFI show only integer values in OBK or tuya-mqtt.js when the device menu allows 0.5 second steps?

It shows integers because the Tuya MCU reports DpID 104 as an integer value even when the device UI offers 0.5 s steps. Users verified that setting 0.5 s on the breaker appears as 0 in OBK, while 1.0 s and 1.5 s both transmit the same integer payload. The thread conclusion was that the limitation comes from the Tuya MCU firmware or protocol handling, not from the front-end page. That makes 0.5 s steps visible on the device itself but not reliably readable through OBK or tuya-mqtt.js. [#20880051]

What does the mysterious 't' setting on the Tomzn TOMPD-63 WIFI actually control, and how was the LCD backlight pad identified?

The t setting controls the LCD backlight timeout. A user reopened the device, found two unused pads on the small PCB, and traced one to ground and the other through a resistor and transistor that looked like an LED driver. After soldering an LED to those pads and setting t to a low value, the LED turned on after a button press and switched off after the programmed time. The manual called it a “light source,” and the hardware test confirmed it was a prepared backlight function. [#20883603]

How should I configure autoexec.bat for the TOMPD-63 WIFI so DpID 6, 9, 17, 18, 19, 104, and 105 work correctly in OpenBeken?

Use TuyaMCU, enable Wi-Fi-paired behavior, and map raw or string DpIDs carefully. DpID 6 should use RAW_TAC2121C_VCP; DpID 9 should be mapped as raw for full fault bitmaps; DpIDs 17 and 18 should be kept as raw or handled via raw send commands; DpID 19 should be mapped as str; and DpIDs 104 and 105 should be mapped as val. Start with clearIO, SetFlag 46 1, startDriver TuyaMCU, tuyaMcu_setBaudRate 9600, and tuyaMcu_sendQueryState. That arrangement was the stable end-state after several revisions. [#20954679]

Why do raw TuyaMCU DpIDs like 17, 18, and 19 fail to parse correctly as integers or strings in some OBK builds, and what workaround was added?

They fail because those DpIDs are longer raw or string payloads, not simple 32-bit values. DpID 17 is 4 bytes and can sometimes fit, but DpID 18 is 12 bytes and overflows integer-style parsing, while DpID 19 is a string like ETU9-IOT-WIFI. The workaround was to add raw DpID access so OBK could expose raw payloads as hex strings and strings directly over HTTP and MQTT instead of forcing broken integer conversion. That feature landed through the Dp and DPxx commands with a flag-controlled implementation. [#20924258]

How can I read raw TuyaMCU data as hex over HTTP or MQTT using the OBK Dp and DPxx commands?

Enable the raw DpID feature, map the DpIDs, then query them with Dp or DPxx. Dp returns a JSON array of all mapped DpIDs, including id, type, and data, while DP23 returns one DpID only. Over HTTP, users called IP/cm?cmnd=Dp; over MQTT, the same command published JSON to the stat topic. Raw fields appear as hex strings, and string DpIDs like 19 appear as decoded text. This solved the long-standing visibility problem for DpIDs 17, 18, and 19. [#20925335]

What is RAW_TAC2121C_VCP in OpenBeken, and how does it map the phase_a packet into voltage, current, and power channels?

“RAW_TAC2121C_VCP” is a packet parser that decodes Tuya’s phase_a raw meter frame, splitting one 8-byte payload into voltage, current, and active power channels. It exists because DpID 6 is not a plain number; it is a packed VCP measurement block. In newer OBK usage, you should provide the first channel index after RAW_TAC2121C_VCP, and OBK will place voltage first, current next, and power last in VCP order. If the channel order is wrong, readings or relay behavior can break. [#21363688]

What is a DpID in the Tuya ecosystem, and why does it matter when migrating a smart breaker from Tuya firmware to OpenBeken?

“DpID” is a Tuya data-point identifier that links one device function to a defined payload type, access mode, and meaning, such as a relay state, fault bitmap, energy counter, or raw measurement packet. It matters because OBK must map each DpID correctly to a channel or parser. If you guess wrong, the breaker can show bad values, miss alarms, or reject writes. On this device, DpID 6 carries raw VCP data, DpID 9 is a fault bitmap, and DpIDs 17–19 need special raw or string handling. [#20869137]

Why does the TOMPD-63 WIFI clear both total energy and prepaid energy with DpID 12, while the TOMPD-63LW clears them separately?

The TOMPD-63 WIFI simply implements DpID 12 differently from the TOMPD-63LW. Users tested it and confirmed that triggering DpID 12 on the WIFI model resets both DpID 13 prepaid energy and DpID 1 total energy. On the LW model, separate DpIDs exist for separate clears, so the logic is cleaner. The mistaken “Clear Prepayment” label in early OBK examples came from copying the LW setup, then it was corrected to “Clear Energy Counters” after testing. [#20881929]

What is the best way to decode the TOMPD-63 WIFI fault bitmap from DpID 9 into readable alarms in Home Assistant, FHEM, or a custom web page?

The most reliable method is to treat DpID 9 as raw data and decode the bitmap in software. The thread showed a simple loop that checks each bit against a 17-item label array, then builds readable text such as Overvoltage, Overcurrent, or Leakage Current. Users also found that single-byte and two-byte fault payloads confused integer parsing, while raw handling fixed it. In practice, a custom page or server-side script is better than forcing OBK text channels, especially when multiple alarms are active at once. [#20883083]

How do I host the alternative TOMPD-63-WIFI HTML control page on LittleFS when the file is too large, and what can I trim or reconfigure to make it fit?

Trim the HTML and autoexec.bat, or increase usable LittleFS space. Users made the page fit standard LittleFS by removing comments, blank lines, and indentation, reducing the HTML to 20,316 bytes and autoexec.bat to 1,733 bytes. Another option is to reconfigure LittleFS size and block settings, then restore files after OTA if needed. A newer WebApp also added an “Upload file” button, which helped Linux and Android users upload the trimmed files without drag-and-drop issues. [#21310442]

Why does the relay toggle misbehave when using certain channel orders with RAW_TAC2121C_VCP, and how should VCP channels be assigned in newer OBK builds?

The misbehavior comes from newer RAW_TAC2121C_VCP parsing rules. Once you specify the starting channel index, OBK expects VCP order: voltage first, current second, power third. One user saw the relay toggle switch off after one second when DpID 16 and VCP channels were arranged badly, but the issue disappeared after moving the VCP block earlier and respecting its channel order. Later fixes restored backward compatibility for the old no-index style, but the safer method in new builds is explicit VCP ordering. [#21367632]

How can I make an Atroch GR2PWS or similar Tuya-based power relay stay off at power-up until voltage conditions are safe, instead of energizing the relay for several seconds first?

You may not be able to do that with the stock startup behavior. A later user reported that the Atroch GR2PWS energizes its relay for about 10 seconds after power-up, then starts measuring and enforcing rules, which creates a risk window if mains voltage is already unsafe. The thread did not provide a confirmed OBK-side fix for forcing an always-off boot state on that model. For safety-critical use, treat that startup pulse as a known limitation until a model-specific workaround is tested and verified. [#21624931]

Generated by the language model.