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

morgan_flint 27594 153

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.

Report a violation of the law

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI):

#151 21510809 07 Apr 2025 19:38

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 60
Topic author Helpful post? (+1)

Post #151
21510809 07 Apr 2025 19:38

rufus4 wrote:
I don't think this is certified to be used in any legal electrical installation.

Some of them come with the CE marking, but this isn't a real guarantee. You probably know about the "China Export" thing 😂😂

Anyway, my opinion is that they are not so dangerous. If you connect them downstream to the appropriate protective devices that should already be present at the input of your electrical installation, they shouldn't pose a higher risk than any other Chinese-made appliance. On the other hand, I probably wouldn't trust them as a primary protective device.

Also, I'm not sure, but maybe Aliexpress's products shipped from inside the EU are better controlled than those shipped from China.
ADVERTISEMENT
#152 21556824 22 May 2025 11:34

Zorlak Zorlak

Level 2

Posts: 3
Helpful post? (0)

Post #152
21556824 22 May 2025 11:34

>>21504906

Good afternoon. Is everything working fine for you after the firmware? I have the same device, I want to flash it. Is there anything I need to know and do before flashing?
ADVERTISEMENT
#153 21556910 22 May 2025 12:52

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
Helpful post? (0)

Post #153
21556910 22 May 2025 12:52

Make sure to take 2MB backup first.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#154 21624931 03 Aug 2025 18:28

Huaweimoboile Huaweimoboile

Level 1

Posts: 1
Helpful post? (0)

Post #154
21624931 03 Aug 2025 18:28

Hi to all programmers and electronics masters. I have a question regarding to Atroch GR2PWS.
Is there any way to turn of it's relay when it power on. It turn on for 10 seconds when I plug it in then it measure voltages and ampare and goes to working mode. I mean what if when power comes back voltages are high and device turns on relay and appliance gets damage within 10 seconds when power comes on.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

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, firmware flashing, and integration of the TOMPD-63 WIFI smart breaker, distinguishing it from the similar TOMPD-63LW model. Users share experiences with device internals, including LED backlight control, DpID mappings, and firmware behavior. Key technical challenges addressed include parsing and handling of TuyaMCU raw data (notably DpIDs 9, 17, 18, and 19), bidirectional setting of configuration parameters, and fault detection reporting. Solutions involve custom parsing implementations in OpenBK7231T firmware, development of alternative web control pages independent of channel mappings, and enhanced MQTT and REST API support for raw and string data types. The community collaboratively refines autoexec.bat scripts for channel mapping and control, improves fault status decoding, and optimizes prepayment energy counter handling. Firmware updates introduce features like hex string representation of raw data, JSON-formatted DpID queries, and flexible REST commands. Practical aspects such as LittleFS storage limitations for hosting HTML control pages, OTA flashing procedures, and device-specific quirks (e.g., reaction and recovery times for protections) are also discussed. The final outcome includes stable firmware builds, comprehensive control interfaces, and shared resources for both TOMPD-63 WIFI and TOMPD-63LW devices, facilitating advanced home automation integration and device customization.
Generated by the language model.

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.