Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
p.kaczmarek2 wrote:maybe we can skip the UART capture process which is risky and requires isolation for USB to UART converter, and just try to flash OBK?
morgan_flint wrote:The rest of the hardware seems to be the same (I will add photos later on)
p.kaczmarek2 wrote:Have you tried to look up the full list of datapoints at Tuya developer website?
{"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","21":"Leakage current test","101":"Clear Energy","104":"Power Factor","105":"Grid Frequency","106":"刷新上报","116":"Voltage","117":"Current","118":"有功功率"}| DP Instruction | Standard Instruction | DP ID | Description | total_forward_energy | total_forward_energy | 1 | Total forward energy | phase_a | phase_a | 6 | Phase A | fault | fault | 9 | Fault | switch_prepayment | switch_prepayment | 11 | Switch prepayment | clear_energy | energy_reset | 12 | Clear energy | balance_energy | balance_energy | 13 | Balance energy | charge_energy | charge_energy | 14 | charge energy | leakage_current | leakage_current | 15 | Leakage current | switch | switch | 16 | Switch | alarm_set_1 | alarm_set_1 | 17 | Alarm set1 | alarm_set_2 | alarm_set_2 | 18 | Alarm set2 | breaker_id | breaker_number | 19 | Breaker id | leakagecurr_test | leakagecurr_test | 21 | Leakage current test | clr_all_energy | - | 101 | Clear Energy | power_factor | - | 104 | Power Factor | supply_frequency | supply_frequency | 105 | Grid Frequency | refresh | - | 106 | 刷新上报 (Refresh report) | output_voltage | - | 116 | Voltage | output_current | - | 117 | Current | output_power | - | 118 | 有功功率 (Active Power) |
p.kaczmarek2 wrote:I think we may also need to know the variable types
| DP ID | Code | Type | Values | 1 | total_forward_energy | Integer | {
"unit": "kW·h", "min": 0, "max": 99999999, "scale": 2, "step": 1 } | 6 | phase_a | Raw | {} | 9 | fault | Bitmap | {
"label": [ "short_circuit_alarm", "surge_alarm", "overload_alarm", "leakagecurr_alarm", "temp_dif_fault", "fire_alarm", "high_power_alarm", "self_test_alarm", "ov_cr", "unbalance_alarm", "ov_vol", "undervoltage_alarm", "miss_phase_alarm", "outage_alarm", "magnetism_alarm", "credit_alarm", "no_balance_alarm" ] } | 11 | switch_prepayment | Boolean | "{true,false}" | 12 | energy_reset | Enum | {
"range": [ "empty" ] } | 13 | balance_energy | Integer | {
"unit": "kW·h", "min": 0, "max": 999999, "scale": 1, "step": 1 } | 14 | charge_energy | Integer | {
"unit": "kW·h", "min": 0, "max": 99999, "scale": 1, "step": 1 } | 15 | leakage_current | Integer | {
"unit": "mA", "min": 0, "max": 1000, "scale": 0, "step": 1 } | 16 | switch | Boolean | "{true,false}" | 17 | alarm_set_1 | Raw | {} | 18 | alarm_set_2 | Raw | {} | 19 | breaker_number | String | {
"maxlen": 255 } | 21 | leakagecurr_test | Boolean | "{true,false}" | 105 | supply_frequency | Integer | {
"unit": "Hz", "min": 0, "max": 1000, "scale": 1, "step": 1 } |
| DP ID | Code | Type | Values | 11 | switch_prepayment | Boolean | "{true,false}" | 12 | clear_energy | Boolean | "{true,false}" | 14 | charge_energy | Integer | {
"unit": "kW·h", "min": 0, "max": 99999, "scale": 1, "step": 1 } | 16 | switch | Boolean | "{true,false}" | 17 | alarm_set_1 | Raw | {} | 18 | alarm_set_2 | Raw | {} | 21 | leakagecurr_test | Boolean | "{true,false}" |
p.kaczmarek2 wrote:This looks somewhat complete, altough I am not sure why dpID 9 is marked as bitmap and not as raw bytes data.
morgan_flint wrote:If this is true, "0" in the reports would be no alarm, and "8" would be "self_test_alarm", which is the 8th in the list (I made some self-tests of the leakage current with the device by pressing the button labeled "T")
morgan_flint wrote:I still have to figure out the meaning of the cryptic values of "Phase A", "Alarm set 1", and "Alarm set 2"
morgan_flint wrote:Following the ideas in this post (specifically, base64 to hex conversion), I think the meaning of "Phase A" is now clear:
setChannelLabel 4 Something
// start TuyaMCU driver
startDriver TuyaMCU
// always force 0x04 WiFi state (paired to cloud), otherwise TuyaMCU might skip some data points
tuyaMcu_defWiFiState 4
startDriver NTP
// let's choose that channel 1 will be main relay state
setChannelType 1 toggle
// label it
setChannelLabel 1 "Relay"
setChannelType 2 Voltage_div10
setChannelType 3 Power
setChannelLabel 3 "Power"
setChannelType 4 Current_div1000
setChannelLabel 4 "Current"
setChannelType 5 EnergyTotal_kWh_div100
setChannelLabel 5 "Energy"
setChannelType 7 toggle
setChannelLabel 7 "Prepayment"
// MF "power factor"
setChannelType 10 PowerFactor_div1000
setChannelLabel 10 "Power Factor"
// MF "supply frequency"
setChannelType 11 Frequency_div100
setChannelLabel 11 "Grid Frequency"
// link id 16 "switch" to channel 1
linkTuyaMCUOutputToChannel 16 bool 1
// link id 1 "total forward energy" to channel 5
linkTuyaMCUOutputToChannel 1 val 5
// TAC2121C VoltageCurrentPower Packet
// This will automatically set voltage, power and current
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
// link id 11 "switch prepayment" to channel 7
linkTuyaMCUOutputToChannel 11 bool 7
// MF link id 104 "power factor" to channel 10
linkTuyaMCUOutputToChannel 104 val 10
// MF link id 105 "supply frequency" to channel 11
linkTuyaMCUOutputToChannel 105 val 11
// NOTE: addRepeatingEvent [RepeatTime] [RepeatCount]
// code below will forever toggle relay every 15 seconds
addRepeatingEvent 10 -1 tuyaMcu_sendQueryState 
setChannelLabel 12 "Leakage Current"
linkTuyaMCUOutputToChannel 15 val 12
p.kaczmarek2 wrote:I will add Frequency_div10 for you, but in general, we may consider something more flexible in the future, of course, with backwards-compatibility included
p.kaczmarek2 wrote:I think you need a leakage current channel type for leakage current.
| 55 AA | 03 | 07 | 00 08 | 11 | 00 | 00 04 | 0401001E | 49 | HEADER | VER=03 | State | LEN | dpId=17 | Raw | LEN=4 | V=67174430 | CHK |
| 55 AA | 03 | 07 | 00 10 | 12 | 00 | 00 0C | 01010013 030100FA 040100D2 | 21 | HEADER | VER=03 | State | LEN | dpId=17 | Raw | LEN=12 | Values | CHK |
morgan_flint wrote:BTW, there's a string in the logs (55 AA 03 07 00 10 12 00 00 0C 01 01 00 13 03 01 00 FA 04 01 00 D2 21) that gives an error in TuyaMCUAnalyzer:
p.kaczmarek2 wrote:Good progress, keep it on! I will try to add required channel types tomorrow.
{\ -> {\n
,\ -> ,\n
\" -> "
[{ -> [\n{
}] -> }\n]
]} -> ]\n}
p.kaczmarek2 wrote:Yes, please do, we can send you an Elektroda gadget for doing such tutorial. A guide from start to finish, how to get dpIDs.
Still, keep in mind that it may be also possible to use online JSON formatters/beautifiers
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.
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]addRepeatingEvent 10 -1 tuyaMcu_sendQueryState produced practical refreshes every 10 s instead of waiting for the long factory interval. [#20702297]bk7231flasher_1.1.1 and OpenBK7231T_UA_1.17.221.bin. [#20697176]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]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]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]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]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]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]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]