logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
UV printer on your desk?
UV printer on your desk? Discover eufyMake E1 »
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

[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.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #31 20889059
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12638
    Angel0fDeath wrote:

    Since this is the most complex html, you can consider to add the final version to your examples. If you want to do that will write some comments inside html file.

    Sure, please do, and maybe open a pull request?

    Angel0fDeath wrote:
    When have some more time, will try to host it on my NAS. I didn't found any instructions about that, but I think I have an idea how to do this...

    You just need a HTML hosting, even a static one will work, and then in OBK change web app URL and it should work out of the box.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20891478
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    Quote:
    Sure, please do, and maybe open a pull request?


    For sure, but will do this with the final script version.
    Currently awaiting correct data parsing to the channels, to finalize it.
  • #33 20918142
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2 It looks like no development on this issue... I mean raw data parsing, of course
  • #34 20918223
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12638
    I apologize for the delay, we are currently working on new platform support, namely LN882H.

    Regarding the parsing, would you like to get a flexible, scriptable parse system, or just a custom dpType that will fit your device?

    The custom hardcoded dpType will be way faster. Here is an example of already existing custom dpType for TAC2121C:
    C code snippet for parsing data of type DP_TYPE_RAW_TAC2121C_VCP.
    How good is your C knowledge? Maybe we could add a required parser for you together?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #35 20918717
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2 Parsing - for me it doesn't matter how exactly will be done as long as it works. The most important is that since these are settings after user modifies the values the driver must read them back and set them in device. so this parsing should work forth and back.
    Regarding C knowledge - not the best but all my ESP8266 devices (about 10) are running with code written by me.
  • #36 20919785
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Hello all!

    Angel0fDeath wrote:
    The most important is that since these are settings after user modifies the values the driver must read them back and set them in device. so this parsing should work forth and back.


    Regarding this, I've tried modifying DPId 17 (Alarm set1, which is shorter than DPId 18 - Alarm set2). The web interface says "Changed channel Alarm set 1 17 to 67174430!" (writing 67174430 on the textfield, with a previous value of 67174480) and, although the textfield stays at 67174430 even after refreshing the page, the settled value in the display stays at 80 mA and the protection doesn't trip with a leakage of 50 mA, so it's not really changing anything.

    I tried the same in the other device with a slight difference: the value in the textfield returns to the previous value shortly after the attempt of changing it.

    The Tuya App did allow to change the settings with the Tuya firmware, so there must be a way...
  • #37 20920314
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint This is because probably not correct set command is issued. To find correct set command for DpID 17 and 18 probably we will need to sniff communication between WB3S and tuyaMCU with original firmware.
  • #38 20920514
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Ok, I can do that; I bought the isolators to be able to sniff even if connected to AC, but I think it's not really needed, as that "sniffing" does not require real AC measurements, so it can be done just feeding the board with low voltage DC
  • ADVERTISEMENT
  • #39 20920630
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint Don't do it. It is again parsing problem:
    I was able to set DpID 17 via raw sent command

    uartSendHex 55AA00060008110000040401002047 -> this will set DpId to protection on and 32mA leakage current.

    EDIT:
    The same is valid for DpID 18:

    uartSendHex 55AA000600101200000C0101003F030100FA040100AA21 -> all protections on 63A 250V 170V

    uartSendHex 55AA000600101200000C0100003203000104040000B426 -> all protections off 50A 260V 180V

    You can try it if you want and check settings in the device, but it works :)

    EDIT2:
    The good thing is I can send these commands via url. Already tested. And this means I can implement them in alternative html control page.
    The driver more or less reads correct DpID17. The only thing we need is to read correct DpID 18....

    EDIT3:
    @p.kaczmarek2 Is there any way to capture the output from tuyaMcu_sendQueryState via url?
    I mean send command via IP/cm?cmnd=tuyaMcu_sendQueryState and to capture the whole output
  • #40 20920806
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Tested and also works in the other device, so everything developed here can also be applied to it. Thanks!
  • #41 20920900
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint At the moment I'm adding the above to breaker.html. Will post it later when ready.
    In the other device DpID's are the same or not? I'm speakin for DpID 17 and 18. Currently I'm using a constant string for these 2 DpID's to set. Changing only the bytes necessary. If DpID's are different should think for somethin else...

    Added after 1 [hours] 27 [minutes]:

    @morgan_flint Ok. Setting DpID 17 & 18 added to alternative control page (attached).
    Don't forget to change IP address, with IP address of your device.
    Initial values for settings derived from DpID17 are correct.
    Initial values for settings derived from DpID18 are NOT correct since we don't read this correct.

    In general we can set all settings, but to verify some of them is possible in device only.
    After we find a way to read correct dpID18 will add correct initial setting of these values.

    PS: It is also possible to verify settings via web app issuing command tuyaMcu_sendQueryState and checking the raw answer for dpID18.
    Enough for today. If you can find some work around to obtain dpID18 reading will incorporate it in html page :)
    Attachments:
    • Breaker_rev3.zip (5 KB) You must be logged in to download this attachment.
  • #42 20921165
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2 Now since I am able to set all settings with raw send command, it is only needed to receive data from this channel. Probably the easiest way will be just to convert data array to hex string. Actually type 'raw' for me sounds exactly like this - either receive byte array with values or hex string.
  • #43 20921587
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Angel0fDeath wrote:
    In the other device DpID's are the same or not? I'm speakin for DpID 17 and 18. Currently I'm using a constant string for these 2 DpID's to set. Changing only the bytes necessary. If DpID's are different should think for somethin else...


    Yes, DpID 17 and 18 are the same.

    This is a comparative table for both devices' DpIDs:
    Comparison table of DpID identifiers for two devices TOMPD-63WIFI and TOMPD-63WL.

    Until DpID 19 all DpIDs are the same, with a slight difference in DpID 12: on the other device it only clears the prepayment counter, while on this one it clears both energy counters (prepayment and total). Also, DpID 19 is 14 bytes long in this one and just 4 in the other one (content is 45 54 55 39 2D 49 4F 54 2D 57 49 46 49 00, translated to ASCII, "ETU9-IOT-WIFI " for this one and 31 32 33 34 "1234" for the other one). We could try to change these with uartSendHex to see what happens, although, supposedly, it's read-only.

    DpID 21 and 101 only exist in the other device; the first one simulates a leakage current test (trips switch for the scheduled time, not very useful in my opinion as it doesn't really provoke a real leakage current, as the test in "hardware" RCDs) and the second one clears the main energy counter.

    DpID 104 and 105 are completely different; in this device they set the parameters of overvoltage protection and in the other one they are for power factor and frequency, respectively.

    DpID 106 doesn't appear in OBK's logs; in Tuya's logs it appeared occasionally with "app client" as source and "appName:Tuya Smart,ios-packageName:com.tuya.smart,android-packageName:com.tuya.smart,model:2201116SG,os_system:13,app_version:5.7.0. App uid: eu16778378437609KUvs" as content. Not very sure what it represents but not useful for us, I think

    Finally, DpIDs 116 to 118 don't appear in any log, but were defined in one of the archives downloaded from Tuya developers page (like the one in the first post of this thread, for DpID descriptions). Probably something that wasn't finally implemented as is redundant with DpID 6 (or maybe not so redundant, as "output" could indicate "export" in this case, because the other device is capable of detecting reverse power in the display, but doesn't report it on DpID 6; in any case, it is not implemented)
  • #44 20921689
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint Since I have only this device, lets try first to get all features working, then I can easily adapt for the other device. Can easily change everything in JS script, but to know with which device we deal, I think it is good idea if we read dpID19 - braekerID and to identify with which breaker we are communicating.
    At least you can test last version of breaker.html and give feedback. If there are some problems - let me know - will fix them. I can test this only on 1 device while you have a lot :)

    So please test the last revision of breaker.html and give some feedback.

    About missing dpID's - if you issue tuyaMcu_sendQueryState do you receive something for these channels (even not mapped in the log you should see something)
    Also - Please send tuyaMCU package for the missing dpID's from the log - tuyaMcu_sendQueryState -> full answer, which means even what tuya driver tries to do.
    Example:

    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 11 00 00 04 04 01 00 1E 49
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 17, dataType 0-raw and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 67174430
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 12 00 00 0C 01 01 00 3F 03 01 00 FA 04 01 00 B4 2F
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 18, dataType 0-raw and 12 data bytes
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 0E 02 00 04 00 00 13 88 C0
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes

    From the above it is clear driver is doing something with dpID17, and it is also clear cannot manage dpID18
  • #45 20922173
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Angel0fDeath wrote:
    I can test this only on 1 device while you have a lot


    Well, just two :-)

    Angel0fDeath wrote:
    So please test the last revision of breaker.html and give some feedback.


    I've been doing some tests and here's some feedback:
    - The units for power should be W instead of kW
    - Setting the thresholds works perfectly
    - Fault status always says "Everything is OK"., regardless of the fault. I've tested leakage, overvoltage, and overcurrent in all possible combinations. These are the results:
    Code: text Expand Select all Copy to clipboard
    FAULT(S)				DpID 9 FROM LOGS			BIN Payload	Ch 10 (Fault Numeric)
none: 					55 AA 03 07 00 05 09 05 00 01 00 1D 	0000 0000		0
leakage: 				55 AA 03 07 00 05 09 05 00 01 08 25 	0000 1000		8
leakage + overcurrent: 			55 AA 03 07 00 06 09 05 00 02 01 08 28 	0001 0000 1000		8
leakage + overcurrent + overvoltage: 	55 AA 03 07 00 06 09 05 00 02 05 08 2C 	0101 0000 1000		8
overcurrent + overvoltage: 		55 AA 03 07 00 06 09 05 00 02 05 00 24 	0101 0000 0000		0
overcurrent:				55 AA 03 07 00 06 09 05 00 02 01 00 20	0001 0000 0000		0
overvoltage:				55 AA 03 07 00 06 09 05 00 02 04 00 23	0100 0000 0000		0

    Something curious here is that the payload has one or two bytes length, depending on the alarms; they could have chosen a constant length even if the most significant byte was 00... Also, the result for channel 10 only depends on leakage (which belongs to the least significant byte), it doesn't seem to take the most significant one when it exists (overcurrent and/or overvoltage).

    Angel0fDeath wrote:
    About missing dpID's - if you issue tuyaMcu_sendQueryState do you receive something for these channels (even not mapped in the log you should see something)
    Also - Please send tuyaMCU package for the missing dpID's from the log - tuyaMcu_sendQueryState -> full answer, which means even what tuya driver tries to do.


    Tried that on the other device; DpIDs 116 to 118 didn't appear in the logs even after sending tuyaMcu_sendQueryState
  • #46 20922247
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint Open script with text editor. After IP address is mapping of channels. Check it is as yours in config. If necessary edit and save. Im using channel 9 for fault and not channel 10. Once mapping is corect you can repeat your tests
  • #47 20922375
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Done. I hadn't considered that because I had the autoexec.bat you posted some time ago, so I thought we had the same channel settings.

    Now it detects correctly leakage, but not the other two alarms. Furthermore, if I provoke the three alarms and then retire leakage, channel 10 stays at 8 and leakage alarm is detected.

    I'm afraid it's due to OBK not treating well DpID 9 when its payload changes from one to two bytes, something similar to DpID 17 vs. DpID 18

    I see also "Breaker ID" shows as 0:
    User interface showing power device information, displaying ON status, breaker ID, and current energy and current values.

    I have this for DpID 19 in autoexec.bat:
    Code: text Expand Select all Copy to clipboard
    // Settings 2 - Dpid 19 "breaker_id" - channel 19
linkTuyaMCUOutputToChannel 19 03 19
setChannelType 19 textfield
setChannelLabel 19 "Breaker Id (19)"

    And also tried:
    Code: text Expand Select all Copy to clipboard
    // Settings 2 - Dpid 19 "breaker_id" - channel 19
linkTuyaMCUOutputToChannel 19 val 19
setChannelType 19 ReadOnly
setChannelLabel 19 "Breaker Id (19)"

    With the same results. This channel shows 0 in both cases, and I can't see its mapping in the script
  • #48 20922407
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    I rearranged some channels in autoexec.bat depending on they are read only or read-write in order to show read only channels in device control page before read-write channels and without possibility to change them.
    About fault - probably you are correct. I tested processing of the fault giving all possible combinations in random order, so I'm pretty sure in processing. However processing process what it reads from fault channel so the problem is probably with this reading...

    Added after 1 [hours] 38 [minutes]:

    @morgan_flint Breaker ID is always 0 because of the same parsing problem - a lot of bytes in data field of tuya package.
    Otherwise mapping for this channel in script is this:
    let breaker_id_ch = 0;

    All other mappings are following this line.
    Attached is my autoexec in order not to have mistakes.
    Attachments:
    • Breaker_autoexec_20240101.zip (1.34 KB) You must be logged in to download this attachment.
  • #49 20923736
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12638
    Angel0fDeath wrote:

    @p.kaczmarek2 Is there any way to capture the output from tuyaMcu_sendQueryState via url?
    I mean send command via IP/cm?cmnd=tuyaMcu_sendQueryState and to capture the whole output

    I understand what you're trying to do and it's a good idea in general, but sadly it would be very problematic. This is because TuyaMCU reports all data with delay and we can never ever be sure when it finishes the reporting.

    From what I can understand, you're trying to extend the REST page, right?

    Your idea is not viable but it gave me another idea. What about storing all TuyaMCU dpIDs as strings and giving the REST API access to them?

    That way you would be able to query the OBK via REST page for, let's say, dpID 19 and retrieve it in a form of hex string like "FFAABBCC", etc.

    That seems for me like a suprisingly good solution for the issue that have been discussed here for some time already.

    I can try adding it for you tomorrow.

    What do you think?
    Helpful post? Buy me a coffee.
  • #50 20923939
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2 I think this is a good idea, I mean hex string will do the trick
  • #51 20924258
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12638
    Here is a self test of this feature:
    Visual Studio console displaying test code for the TuyaMCU function.
    I think you can already infer the JSON structure from it. It will work both through HTTP and MQTT.

    Added after 1 [hours] 12 [minutes]:

    Raw type will be shown as hex string:
    Screenshot of a code snippet from a test function sending MQTT packets.

    Added after 2 [hours] 45 [minutes]:

    @Angel0fDeath here is a preview, can you check?
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1048
    You need to enable a flag first.
    Then, try executing "Dp" command via HTTP to get JSON
    Helpful post? Buy me a coffee.
  • #52 20924987
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2 I don't see the build on provided link
  • #53 20924998
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12638
    You need to click on one green ticks, to get build details, a page like this:
    https://github.com/openshwprojects/OpenBK7231...tions/runs/7627074885/job/20775034317?pr=1048
    Screenshot showing GitHub Actions page for the OpenBK7231T_App project, displaying build details.
    Then you need to click "Summary" and scroll down:
    Screenshot from GitHub Actions showing build run details with a list of built versions and an Artifacts section.
    Then you will get a zip file:
    Screenshot showing download info for OpenBK7231T App zip file.
    With all the builds:
    Screenshot of a ZIP archive with several binary files and their size information.

    Added after 47 [seconds]:

    PS: I will add more self tests for this functionality soon
    Helpful post? Buy me a coffee.
  • #54 20925150
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    Aha... Thanks. Downloaded it.

    @p.kaczmarek2 Hmm. Something wrong. Flag 46 -> enabled
    command:
    IP/cm?cmnd=Dp -> nothing happens

    Web app -> Logs Dp
    Info:CMD:[WebApp Cmd 'Dp' Result] Unknown command

    MQTT - not tested, since obviously will not get result.

    I tried it with my autoexec.bat and with empty autoexec.bat. Same results.

    However I noticed even Flag 46 is enabled, in the beginning of flag config page always states;
    Flags (Current value=0)

    I don't know if this is the reason nothing to happen, but in general this is a bug. It seems you don't set corresponding bit in flags :)
    ... or you set it but you have overflow...
  • #55 20925221
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12638
    Ok, I'm on it, let me check

    Added after 1 [minutes]:

    BTW:
    Angel0fDeath wrote:

    I tried it with my autoexec.bat and with empty autoexec.bat. Same results.

    I will only work for dpIDs with mappings, even dummy ones

    Added after 2 [minutes]:

    EDIT:
    Hmmm
    Screenshot showing JSON data in a browser.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #56 20925228
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    Screenshot showing a blank webpage with an address bar containing an IP address. Yep, work with mappings. It will be easier. Web browser screenshot showing a blank page.
  • #57 20925230
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12638
    The current flags display seems to be misleading, it reads only first 32 bits:
    Screenshot of programming code showing a function displaying flag values.
    That's a thing to fix
    Helpful post? Buy me a coffee.
  • #58 20925243
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    Well thats definitelly longint overflow. But I don't know how you keep them...
  • #59 20925259
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12638
    I think I've got it. Wait

    Added after 10 [minutes]:

    @Angel0fDeath try latest build (please note that the just display of flag numbers is not fixed yet)
    Helpful post? Buy me a coffee.
  • #60 20925322
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    Now everything seems ok :)

    Screenshot of a web browser displaying a JSON page with variables.

    Even string dpID 19 shown correct
    I can read everything with javascript.

    How it is supposed to obtain the same with MQTT?

    EDIT: About flags - I don't think printing in web page some longint or 2 longints for flags status brings some important information even for you :), unless you are able to perform bitwise operations without pc or calculator. Probably more suitable will be just to print
    Current active (or enabled) flags - 1, 21, ..... (for instance)
    No one uses all flags and this number in web page speaks nothing, while flag numbers (if printed) give more info and more understandable info.

    @morgan_flint Please check on other device also. Will rework alternative html control page during the weekend. Will be out of the town for the next 2 days.
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.
Today's popular

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.
ADVERTISEMENT