>>21110395 I am referring to the default version of the device having data captured for a few days. I have seen a few videos of unboxing and showing the functionality of this device. I have attached screenshots of the app where this section is mentioned.
>>21358884 Hello, @paoliniluis, and Merry Christmas to all
I don't remember well (it was more than a year ago...), but I've opened it and see that there are remains of having soldered wires to CBU pins 13, 14, 15, and 16 (GND, 3.3V, TX1, and RX1, respectively), so I guess, I powered it from the USB to serial adapter used for flashing it.
I've checked that there are resistors between CBU's RX1 and TX1 and the MCU, so there's little risk of ruining the MCU's TX pin, which could happen if the programmer tries to output a different level than the MCU (it occurred to me with one of my TH08's...).
I'm attaching my actual autoexec.bat for this device:
Added after 17 [minutes]:
@p.kaczmarek2 :
I've found a misfunction in this device after upgrading OBK: voltage and current stopped working, and also the relay switched on by itself after switching off from the web interface.
I noticed this when updating to OpenBK7231N_1.17.808; then went back to previous versions I had in my HD and saw it worked again OK with OpenBK7231N_1.17.769.
Then, I started a dichotomic search to find out which was the version where the error started and found it was OpenBK7231N_1.17.796: with 795 everything went well but, after flashing 796, voltage and current values showed 0 while they were 230 V and 0.08 A with 795 (power was 0 for both, but probably it was because of its low value and/or resolution/rounding in 795).
In Github's releases page, changes for version 1.17.796 states: "support multiple RAW_TAC2121C_VCP channels for devices with 3 phases, etc (6e176a3)", so it seems the changes to RAW_TAC2121C_VCP don't go well for this single phase device... This doesn't directly explain the auto-resetting of the relay but could be a side effect.
This is the part of the autoexec.bat where I call RAW_TAC2121C_VCP, just in case the syntax should be changed to work with ver. 796:
// Measurements - Dpid 6 "phase_a" - channel RAW_TAC2121C_VCP -> 5,6,7
// TAC2121C VoltageCurrentPower Packet
// This will automatically set voltage, power and current
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
setChannelType 5 Voltage_div10
setChannelLabel 5 "Voltage"
setChannelType 6 Power
setChannelLabel 6 "Power"
setChannelType 7 Current_div1000
setChannelLabel 7 "Current"
EDIT: Checked it also with TOMPD-63-WiFi, with the same results: Version 1.17.796 showing V, I, P as 0, and reconnecting relay by itself when switching off from the web or even from the device. Version 1.17.795 works OK
Attachments:
TOMPD-63LW_autoexec.bat.txt(4.12 KB)
You must be logged in to download this attachment.
There was indeed a bug. I've added a support for multiple VCP dpIDs for 3 phase meters, but the old behaviour of VCP, which was not working before because I forget that channel was unsigned integer. Here is my fix:
https://github.com/openshwprojects/OpenBK7231...mmit/f229e2c2047134b59e1e80c5e5ef3a05a214b62f Can you check whether the old VCP approach (without channel index in command) works again now?
The relay was auto-resetting because device tried to write voltage to channel 0 i guess. Current to 1, power to 2, etc.
>>21363783 Thanks, I'll try the fix ASAP.
I had already found after reading your post here that, if I added the voltage channel to the syntax of RAW_TAC2121C_VCP, in my case:
// Measurements - Dpid 6 "phase_a" - channel RAW_TAC2121C_VCP -> 5,6,7
// TAC2121C VoltageCurrentPower Packet
// This will automatically set voltage, power and current
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP 5
setChannelType 5 Voltage_div10
setChannelLabel 5 "Voltage"
setChannelType 6 Power
setChannelLabel 6 "Power"
setChannelType 7 Current_div1000
setChannelLabel 7 "Current"
(added 5 at the end of linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP)
Then the problem with the switch dissapeared, and it started showing the correct voltage, but the values for power and current weren't good:
The first image is ver. 795 with "old" autoexec (without channel number at the end), the second, ver. 812 with old autoexec (shows 0 witha ll measurements), the third, ver. 812 with autoexec corrected (shows correct voltage, but higher power and current). The last one is to check if the new syntax works OK with old version (795), which apparently does, but it would be better for the new versions to work without the channel number after "linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP", to avoid having to update the autoexecs after updating versions. All of them are for TOMPD-63WIFI.
I'll check the behavior of the fix with these issues. Thanks again!
Added after 6 [hours] 27 [minutes]:
>>21363783 Ok, tried ver. 813 with the same results as 812...
Ver. 813 with "old" autoexec (without channel number afer linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP) gives 0 for voltage, current, and power, and restarts relay, while adding channel number after it gives correct value for voltage but wrong values for current and power (.4 A instead of .2 and 170W instead of 40; Im using a 40W lamp as load and old versions values match with the device's display), but relay doesn't restart when switching off
It's VCP, as in title, Voltage, Current, Power. You seem to have Voltage, Power, Current order. So Current value goes to Power and Power goes to Current.
>>21365272 True!! 🤦♂️
Its curious that it worked OK with old syntax and that it worked also well with old versions and the same autoexec 🤔
I'll try changing the order of the measurements, but now I'm away from home
CONCLUSIONS: 1.- With the old (single phase) syntax (no number after RAW_TAC2121C_VCP), it seems to put power and current in the corresponding type channel, regardless if channel order is V-C-P or V-P-C.
2.- With the new syntax (ready for multi phase), if V-C-P order is not respected, it shows current in the second channel and power in the third, regardless the channel type.
3.- This behaviour is good, in the sense older autoexecs with bad order will continue to work; in new autoexecs for multi-phase devices, it's not tolerant to errors in the order, so attention should be paid to put channels in the correct one (which shouldn't be a problem).
Many thanks to @p.kaczmarek2 for all his work!
EDIT 2: Just for the sake of testing it, I tried changing also the order of voltage with the "old" syntax. Works perfectly, so the "backwards compatible syntax" for single-phase devices is completely tolerant to channel order:
>>21615305 First, I'd try illuminating the screen from outside with a flashlight, as some LCDs can be seen this way well enough to navigate to the corresponding setting. This probably would work with the first version of this device ("black and white" LCD). I've tried with the colour one and it doesn't work, probably because it's OLED and not LCD.
If that doesn't work, after powering off and on (so the device is in a known state), I'd try navigating blindly to the setting (very easy in this case, as it's the first one), and change it. The sequence would be: long press of the set key, ten or more arrow up short presses (more than 10 seconds of light on), and long press of the set key again. Once this has worked, set it to the time you want (or permanently on, after 200 seconds).
Hi all! New version of TOMPD-63-LW with CBU module inside and color screen was purchased. OpenBeken v. 1.18.177 was flashed successfuly, but I have some questions:
1. Is it possible to fix default "Current" channel data? No load connected, but channel data are about 170, it doen't look like breakers's inside power consumption.
2. I can't understand how to calibrate VCP channels, division is only divider of channel data, but how to fix it to real measurement, for example with 40W bulb?
3. Is it possible to change channel 13 data?
P.S., @pkaczmarek2 , am I right, that it can be fixed only with addEventHandler OnChannelChange X setChannel Y $CHX+calbration because TuyaMCU doesn't exist internal channel calibration mechanism?
Hi!
I need to change this device's default power-on state to off, so that it will not turn on the load unless some kind of API request is received.
I'm new to the whole OBK thing.
Could you please advise if this is possible?
Hi, thank you for your awesome work!
I bought the device (color screen version), flashed it, all work.
But I've got a couple of question.
Is there a chance to get an indication of state? My red indicator blinks depending on load, but it would be useful if it is just on, when the relay is on.
And could be voltage/power indicator always on?
Thank you
✨ The discussion centers on the TOMZN TOMPD-63-LW Wifi Multi Function DIN power meter, specifically its compatibility and configuration with OpenBK firmware on the BK7231T platform. Users explored flashing the device with OpenBK, including safe UART data capture methods, backup procedures, and flashing techniques involving the TuyaMCU secondary MCU (HC89F0541). The device features dual relay switching for line and neutral, rated for 63A at 230V, 50/60Hz, with remote control, measurement of voltage, current, leakage current, power factor, and energy consumption, and configurable protection thresholds via the Tuya SmartLife app.
Key technical challenges included identifying UART pins, managing the TuyaMCU communication protocol, and mapping Tuya datapoints (dpIDs) to OpenBK channels. Users successfully extracted and analyzed dpIDs such as relay state (dpID 16), voltage/current/power (dpID 6), total energy (dpID 1), leakage current (dpID 15), alarms (dpID 9, 17, 18), and others. The community developed and refined autoexec.bat scripts to correctly interpret and display these datapoints, including handling raw data packets (RAW_TAC2121C_VCP), scaling factors, and channel labeling.
Firmware updates addressed issues like leakage current scaling, frequency display, and string termination for device identifiers. The device supports negative power detection (export), though the sign is not reported to the OpenBK interface. Users also discussed Tuya cloud API access for device shadow properties and the challenges of missing or write-only dpIDs (e.g., dpID 21, 101). The community contributed improved web interfaces and scripts for enhanced usability, including periodic state refresh commands (tuyaMcu_sendQueryState) to reduce data update latency from minutes to seconds.
Overall, the thread documents the collaborative reverse engineering, firmware customization, and integration of the TOMZN TOMPD-63-LW power meter with OpenBK, enabling local control and detailed monitoring beyond the original Tuya cloud ecosystem. Generated by the language model.
TL;DR: With a 2 MB flash backup first, this breaker can run OpenBeken reliably; as one expert put it, "It’s TuyaMCU". This FAQ helps TOMZN TOMPD-63-LW owners flash WB3S/CBU versions, decode dpIDs, fix slow updates, and restore full relay and metering behavior. [#20694223]
Why it matters: This thread turns a hard-to-flash Tuya DIN breaker into a documented OpenBeken target with known wiring, dpIDs, and working refresh tricks.
Option
Best fit
Main advantage
Main drawback
OpenBeken
TOMPD-63-LW with TuyaMCU
Full local control, dpID mapping, custom UI
Requires UART flashing and setup
ESPHome
Users already on HA
Familiar YAML workflow
Thread did not map this model fully
Tasmota
Users comparing ecosystems
Popular tooling
Thread provided no complete TOMPD-63-LW config
Key insight: The critical hurdle is not the Wi-Fi module itself. It is the secondary TuyaMCU link on UART, which must be isolated by reset or trace separation during flashing, then mapped correctly in OpenBeken.
Quick Facts
The breaker is rated 230 V, 50/60 Hz, up to 63 A, and the product description listed adjustable thresholds such as undervoltage 140–210 V, overvoltage 225–295 V, overcurrent 1–63 A, reconnect delay 1–500 s, and action time 1–30 s. [#20693422]
A successful flash path on the WB3S version used a full 2 MB backup, bk7231flasher_1.1.1, and OpenBK7231T_UA_1.17.221.bin; grounding pin 22 of the HC89F0541 reset line enabled UART read/write without permanent board cutting. [#20697176]
dpID 16 was confirmed as the main relay, dpID 6 carries the combined voltage/current/power packet, dpID 1 is total energy, and dpID 9 is the fault bitmap rather than a single numeric alarm. [#20697712]
The Tuya cloud model exposed at least 20 dpIDs on later units, including 104 power factor, 105 supply frequency, 106 refresh, 116 voltage, 117 current, and 118 active power, beyond the earlier basic set. [#20837470]
Default reporting was slow enough to frustrate users, but adding addRepeatingEvent 10 -1 tuyaMcu_sendQueryState produced practical refreshes every 10 s instead of waiting for the long factory interval. [#20702297]
How do you safely flash OpenBeken onto a TOMZN TOMPD-63-LW with a WB3S or CBU module, including backup, UART wiring, and handling the TuyaMCU connection?
Yes—make a full backup first, then flash over UART with the TuyaMCU isolated. 1. Connect 3.3 V, GND, TX1, RX1 to the WB3S or CBU pads and read a 2 MB backup. 2. Keep the mains side isolated and disable the secondary MCU, usually by reset or temporarily breaking its UART path. 3. Flash OpenBeken, reboot, then restore from backup if needed. On the WB3S unit, this worked with bk7231flasher_1.1.1 and OpenBK7231T_UA_1.17.221.bin. [#20697176]
What is TuyaMCU in the TOMZN TOMPD-63-LW, and how does it communicate with the WB3S or CBU Wi-Fi module?
"TuyaMCU" is a secondary control MCU that reads measurements, drives the front panel, and exchanges datapoints over UART with the Wi-Fi module. In this breaker, the Wi-Fi board is only one part of the design; the HC89F0541-class MCU handles protection logic and LCD tasks. OpenBeken talks through that UART link, so dpIDs come from TuyaMCU rather than directly from the relay hardware. That is why flashing and runtime mapping depend on the UART relationship between TuyaMCU and WB3S or CBU. [#20694223]
What is RAW_TAC2121C_VCP in OpenBeken, and how does it decode voltage, current, and power from dpID 6 on the TOMPD-63-LW?
RAW_TAC2121C_VCP is OpenBeken’s parser for the 8-byte Tuya raw packet on dpID 6. It splits one packet into voltage, current, and active power channels automatically. The Tuya model describes the format as 2 bytes voltage at 0.1 V, 3 bytes current at 0.001 A, and 3 bytes power at 0.0001 kW. The thread later confirmed the packet decodes exactly that way, which is why removing the mapping made channels 2, 3, and 4 fall back to zero. [#20707655]
Why do some TOMZN TOMPD-63-LW units need the HC89F0541 reset pin tied to GND before UART read/write will work?
They need it because the TuyaMCU shares the same UART lines used for flashing the Wi-Fi module. If the HC89F0541 stays active, it drives or listens on that bus and blocks clean UART read/write. One successful workaround grounded pin 22, the reset pin, during backup and flashing. That let UART access work without desoldering the resistor links between the TuyaMCU and the WB3S module. [#20694223]
How can I use tuyaMcu_sendQueryState or addRepeatingEvent to force faster refresh updates on a TOMPD-63-LW that otherwise reports very slowly?
Use tuyaMcu_sendQueryState directly, or schedule it with addRepeatingEvent. The working example was addRepeatingEvent 10 -1 tuyaMcu_sendQueryState, which polls every 10 seconds. That solved the complaint that power values updated only about every 2 minutes under the stock behavior. The command can also be triggered manually from the Web App command area when you want an immediate state dump. [#20702297]
Which dpIDs have been identified for the TOMZN TOMPD-63-LW, and what do dpIDs 1, 6, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 21, 101, 104, and 105 mean?
The key dpIDs are known. 1 total energy, 6 phase A V/I/P raw packet, 9 fault bitmap, 11 prepayment switch, 12 clear prepaid energy, 13 balance energy, 14 charge energy, 15 leakage current, 16 relay switch, 17 alarm_set_1, 18 alarm_set_2, 19 breaker ID, 21 leakage test, 101 clear all energy, 104 power factor, and 105 supply frequency. Later cloud data also exposed 106 refresh, 116 voltage, 117 current, and 118 active power on newer units. [#20854635]
How do channels and dpIDs differ in OpenBeken, and how should linkTuyaMCUOutputToChannel be used correctly on a TuyaMCU breaker?
dpIDs are fixed Tuya datapoints; channels are OpenBeken variables you assign yourself. You can map any suitable dpID to any free channel, but the meaning and type of the dpID do not change. The correct syntax is linkTuyaMCUOutputToChannel [dpId] [varType] [channelID]. In practice, the thread used mappings like linkTuyaMCUOutputToChannel 16 bool 1 for the relay and linkTuyaMCUOutputToChannel 1 val 5 for total energy. [#20700864]
Why does dpID 9 on the TOMPD-63-LW behave like a bitmap, and how can its fault bits be mapped to alarms such as overload, leakage, overvoltage, undervoltage, or low balance?
dpID 9 is a bitmap because each bit represents one fault flag, not one numeric state. Testing showed values such as 4, 8, and 32768, matching single-bit alarms rather than sequential IDs. The Tuya model labels include overload, leakage current alarm, overvoltage, undervoltage, and no-balance alarm. For example, a leakage self-test produced 8, which matched the self-test or leakage-related bit position, while low balance matched a high-order bit. [#20842982]
How can I decode and use alarm_set_1 and alarm_set_2 raw packets from dpIDs 17 and 18 for protection thresholds on the TOMPD-63-LW?
Decode them as 4-byte records per protection: byte 1 = protection code, byte 2 = trip mode, bytes 3–4 = threshold. The thread decoded dpID 17 payloads like 04 01 00 1E as leakage protection enabled, trip-on-fault, threshold 30 mA. dpID 18 grouped three protections in 12 bytes, for example overcurrent, overvoltage, and undervoltage. These packets are mainly useful for reading or writing thresholds, but the actual active fault state still reports through dpID 9. [#20849043]
What is the best way to remove leftover buttons or fields from the OpenBeken web UI after changing or clearing autoexec.bat on this breaker?
Set the old channels back to Channel Type = none in the Web App. Clearing autoexec.bat alone does not remove previously stored UI channel types, so the empty controls remain visible. The fix was confirmed after manually resetting those channel types to default, which cleaned the main interface without a hard reset. If you change autoexec layouts often, clear channel types before assuming the script failed. [#20710443]
How do you get the full Tuya data model and dpID list for a TOMZN TOMPD-63-LW from the Tuya developer platform or cloud explorer?
Use Tuya Developer, not guesswork. 1. Create a Tuya developer project and bind the device. 2. Copy the device ID from the cloud device page. 3. In Cloud Explorer, run the Query Things Data Model request to return the full model JSON with abilityId, access mode, code, scale, and units. This method exposed items like dpIDs 104, 105, 106, 116, 117, and 118 that were not obvious from the early UART logs alone. [#20854635]
OpenBeken vs ESPHome vs Tasmota for a TuyaMCU-based DIN breaker like the TOMZN TOMPD-63-LW: which approach fits best and why?
OpenBeken fits best when the device is TuyaMCU-based and you want full local datapoint control. The thread began with users comparing OpenBeken, Tasmota, and ESPHome, but all concrete progress happened with OpenBeken: successful flashing, dpID discovery, custom autoexec files, fault decoding, and faster polling. One user did mention a similar breaker already flashed with ESPHome, but no equivalent TOMPD-63-LW mapping was developed there. For this exact model, OpenBeken is the only fully documented path in the thread. [#20693722]
Why can leakage current, current, and VCP-based channels interfere in some OpenBeken versions, and what changed with LeakageCurrent_div1000 and RAW_TAC2121C_VCP fixes?
They can interfere because older VCP handling wrote values into channels by channel type, creating race conditions when more than one current-like channel existed. That caused leakage current to mirror the main current or swap values unpredictably. The thread led to two fixes: a dedicated LeakageCurrent_div1000 type and later RAW_TAC2121C_VCP changes so multi-phase and shared-current cases behaved correctly. The maintainer explicitly merged a fix so VCP would only target the intended current channel. [#20871205]
What steps can bring the TOMPD-63-LW screen back if screen bright time was accidentally set to off and the display is no longer visible?
You can recover it blindly from the front keys. 1. Power-cycle the breaker so the menu state is predictable. 2. Long-press the set key, then press the up arrow about 10 times to raise screen bright time above zero. 3. Long-press set again to save. A flashlight may help on the older monochrome LCD, but the blind sequence alone was confirmed to restore a fully dark screen on this model. [#21615685]
How can the TOMZN TOMPD-63-LW be configured to stay off after power-up and only energize the relay after a web, MQTT, or API command?
The thread does not provide a finished power-up-off recipe for this breaker, so there is no confirmed TOMPD-63-LW startup command sequence here. What is confirmed is that relay state is exposed as dpID 16 and mapped in OpenBeken with a toggle channel, so any solution must act on that relay channel after boot. A later user asked for exactly this behavior, but no tested answer was posted in the thread. [#21740935]
