logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

TOMZN TOMPD-63-LW Wifi Multi Function (DIN) WB3S (BK7231T)

crash1912 31992 134

TL;DR

  • TOMZN TOMPD-63-LW 63A WiFi DIN power meter targets dual-line cutoff and uses a WB3S/BK7231T platform.
  • It supports remote on/off, live current, voltage, leakage current, and total kWh monitoring, plus timer control in the SmartLife Tuya app.
  • The configurable protections include 230V 50/60Hz operation, 140V-210V undervoltage, 225V-295V overvoltage, and 1A-63A overcurrent limits.
  • OpenBK compatibility remains unresolved, and no forum thread confirming this exact model working correctly was found.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):
  • #91 20990133
    ElektrodaBot
    AI OpenAI ChatGPT4
    Posts: 8812
    Help: 357
    Rate: 937
    p.kaczmarek2 wrote:
    How to change this javascript:

    r = data.find(t => t.id == leak_test).data

    to work even if given data point is not found? Handle all possible NULL variables correctly.
    It seems like you're dealing with a situation where you're trying to find an object within an array that matches a specific condition based on the object's `id` property. Your current approach works fine when the object is found, but you're looking to handle cases where the object is not found in a graceful manner.

    Let's analyze the code line you've posted and then discuss how to modify it to handle null variables or cases where the data point is not found.

    Your current line of JavaScript:
    Code: Javascript
    Log in, to see the code

    This line searches through the `data` array for an object where the `id` matches the `leak_test` variable. Once found, it attempts to access the `data` property of that object. There are two potential issues here:

    1. The `find` method returns `undefined` if no matching element is found. Trying to access a property (`.data`) on `undefined` will result in a TypeError.
    2. Assuming the object is found, but its `data` property is undefined or null. You might want to handle this case too.

    To handle these cases, let's break down the solution:

    ### Step 1: Safely Finding the Object

    First, let's safely find the object without immediately accessing its `data` property.

    Code: Javascript
    Log in, to see the code


    ### Step 2: Handling the Case Where the Object is Not Found

    Now, let's handle the case where `foundObject` is `undefined`.

    Code: Javascript
    Log in, to see the code


    ### Step 3: Handling Possible Null `data` Property

    If there's a possibility that the `data` property itself could be `null` or `undefined`, and you want to handle that specifically, you can extend the previous step:

    Code: Javascript
    Log in, to see the code


    ### Putting It All Together

    Combining everything, you get a robust way to handle the potential issues:

    Code: Javascript
    Log in, to see the code


    This approach ensures that you handle cases where the object isn't found in the array, as well as cases where the object's `data` property is null or undefined.

    Do you have any specific conditions or further details about what you'd like to do in each of these error-handling cases? This could help tailor the solution more precisely to your needs.
    You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
  • ADVERTISEMENT
  • #92 20990164
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    >>20990124

    Hehe... Will try it :)

    Thanks...
    And how can I use this bot in private?

    Added after 15 [minutes]:

    @morgan_flint rev7 works for me perfect. The only change from rev. 6.1 is the script grabs device type and revision number from the file name. Rev7 from the tutorial differs only by more comments inside the file. No code changes. So rev7 should work for 63-WIFI device.
    For 63-LW device - I was able to test up to changing dpID 104 and 105 purpose, since these are presented in my device. I was not able to test what happens with dpID 21 and 101. This is the reason I left r=0 in the script. If searching in dpID array is without result - the script will crash. You can try by uncommenting both r=0 lines and commenting the previous lines. This should work without status of dpID 21 and 101. Then you can try to return dpID 101 and after that dpID 21. As I said the problem according to me is there is no report for dpID 21 in your logs.
    And actually not finding dpID21 in response array was our discussion with @p.kaczmarek2 above... It seems the bot makes perfect analyses :) . Now I must learn how to use this feature :)
  • #93 20990219
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Angel0fDeath wrote:
    @morgan_flint rev7 works for me perfect

    Sory, I deleted that post but I'm afraid I was late; after comparing things, I found a type mismatch in the URL (had added "/" at the end :-(). Rev 7 for the other device works perfectly and there were no changes in the autoexec.

    I've just checked that I committed the same error also for this device (I copied the URL from the browser to avoid errors but doing so includes "/" at the end...). So, I repeated the tests with LW and it shows values correctly and toggles the relay ok. I will test the rest of the features and report back
  • #94 20990272
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    ok. I'm glad there is movement forward :).
    Don't worry about deleted post. I saw it accidentally while I was writing an answer. And after that until I respond you, you deleted it. But don't worry. I'm trying to help.
  • #95 21000410
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint Any news on testing?
  • #96 21001731
    njhuiz
    Level 5  
    Posts: 10
    Rate: 1
    Close-up of a circuit board with electronic components, including capacitors and an integrated circuit.

    I've just got a brand new device with a colored display. It seems to be the same like the other one on page 2 from November 2023.
  • #97 21001993
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    How is the readability of the display at angles and from the distance?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #98 21002417
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Angel0fDeath wrote:
    @morgan_flint Any news on testing?

    Hello and sorry for the delay!

    In general, everything seems to go well, but there are some label/scale errors, as you can see in the following images with the comparison between the standard OBK and the improved one :
    Screenshot of the OpenBK7231N interface with marked areas needing label and scale corrections. Screenshot of the OpenBK7231N user interface with errors in displayed data.
    1: The power factor is wrong by a factor of 10 and should have no units (shows 10 W and should be 1.000 (in the device's display it has 3 decimals, so that must be the real resolution, although 2 decimals could be good enough)
    2: The button labeled "Clr All Counters" in the improved one only clears prepaid energy, so it should be "Clr Prepaid Energy" (the one labeled "Clr All Energy" clears both, so this label is Ok but could also be "Clr All Counters")
    3: Breaker ID in the app was only 1234 (see here). Also, 825373492 that shows in the OBK for that DpID translates to 31 32 33 34 hex so 1234 in ASCII. This must be because this field in this device is half the size of the same one for the other device.
    4: The total energy counter is out by a factor of 10, as it shows 0.015 kWh while in the display is 0.1, and in OBK it shows 0.15. From the DpID value, I think the real resolution is 2 decimals

    Also, OBK interface shows SSID; if it's not too complicated, it would be good to have this also in the improved one, possibly only if "Show settings" is activated. I also see a temperature shown in OBK's interface... @p.kaczmarek2 : Where does it come from? Maybe an internal sensor in BK7231? Because it's not between the DpIDs and, although the Tuya App had a page with 4 temperatures, all of them showed NaN

    Added after 8 [minutes]:

    njhuiz wrote:
    It seems to be the same like the other one on page 2 from November 2023

    Yes, the PCB is exactly the same as mine

    p.kaczmarek2 wrote:
    How is the readability of the display at angles and from the distance?

    In my case, no problems with angles or distance, but a bit difficult to read under direct sunlight (not a common situation, anyway). What I've noticed is some dimming when using the device's buttons, probably because the case presses on the display when pressing them. A bit annoying as this is the situation when you need it more!. I've tried reseating the board into the case with no luck, maybe adding some more length to the buttons by glueing a shim of plastic on top could help, as you won't need to press the buttons so hard.

    In any case, I think the original LCD is better for this application than the colored one, as it's more readable an colors don't add value in this case
  • #99 21004367
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint Ok. Will make the corrections. What about dpID 21. Did you isolated it or now everything is ok?
    Breaker ID - your response (DP command) for this dpid returns "1234("B" (see your previous post). However from raw answer (in the same post) I can see tuyaMCU sends only 31 32 33 34 and then makes integer. This means we have again wrong parsing or maybe not zeroing the array. @p.kaczmarek2 Can you please check this issue?
  • #100 21005072
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Angel0fDeath wrote:
    What about dpID 21. Did you isolated it or now everything is ok?

    DpID 21 (test leakage) works well, and also DpID 12 (clear prepaid energy counter).

    However, there is something I don't understand with the behavior of some bool DpIDs with "toggle" type. These are:
    LabelDpIDChannel
    Relay161
    Prepayment112
    Clr Prepaid Energy123
    Test Leakage2121
    Clr All Counters10122

    In OBK's original web interface, all of them, except for the last one, seem to work as expected (change status when clicked). In the case of DpIDs 12 and 21, they only perform the associated action when changing from 0 (red) to 1 (green) and nothing happens in the opposite transition, as we could expect. In the case of the last one (DpID 101), after resetting the device it appears in red but, once clicked, it stays at green forever, but even in this case, clicking on it clears counters as it should.

    In the improved web interface, there's a difference on DpIDs 12 and 21 (Clr prepaid and test leakage), as clicking on them performs the corresponding action but they stay red. I think We commented on this before and it is intentional, as it avoids having to toggle back them to 0 manually. It would be nice a nice feature if they "blinked" to green momentarily, to have visual feedback when clicked, but it's not mandatory.

    DpID 101 "strange" behavior is a bit perplexing; I don't think it's a problem neither in OBK nor in the improved web, but probably a bug in the device's FW... What do you think?
  • #101 21005116
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    morgan_flint wrote:

    I also see a temperature shown in OBK's interface... @p.kaczmarek2 : Where does it come from? Maybe an internal sensor in BK7231? Because it's not between the DpIDs and, although the Tuya App had a page with 4 temperatures, all of them showed NaN

    This is BK7231 internal sensor and it's available on all BK7231 devices.


    Angel0fDeath wrote:
    @morgan_flint Ok. Will make the corrections. What about dpID 21. Did you isolated it or now everything is ok?
    Breaker ID - your response (DP command) for this dpid returns "1234("B" (see your previous post). However from raw answer (in the same post) I can see tuyaMCU sends only 31 32 33 34 and then makes integer. This means we have again wrong parsing or maybe not zeroing the array. @p.kaczmarek2 Can you please check this issue?

    Can you provide more information on the issue or at least tell me which dpType I should investigate?

    Maybe TuyaMCU sends a string without NULL terminating character so I need to add that manually?
    Helpful post? Buy me a coffee.
  • #102 21006284
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2

    This is part of the answer of Dp command:
    {"id":19,"type":3,"data":"1234("B"}]


    And this is raw tuyaMCU:

    Info:TuyaMCU:Received: 55 AA 03 07 00 08 13 03 00 04 31 32 33 34 F5 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 19 type 3-str len 4
    Info:TuyaMCU:ParseState: int32 825373492


    Both taken from earlier post of @morgan_flint
    Definitely tuya sends only the string without termination. The strange is this is ok on the other device, but with this device definitely something wrong
  • #103 21006655
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    Ok, I have added extra NULL terminating character to the buffer:
    https://github.com/openshwprojects/OpenBK7231...mmit/4cfdd1893d01dfc39509bbc648c0928f5121a4e3
    Can you update and recheck?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #104 21006694
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2 I cannot check - don't have such device. By me with 63 WIFI device everything is ok, but the string is longer...

    @morgan_flint must check this!
  • #105 21006715
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    The following problem will appear randomly, depending on the RAM content when the buffer is allocated. The string length does not matter in this case. If the RAM happens to be zeroed just after the allocated string buffer, then string will be displayed correctly. Otherwise some extra random characters will be displayed at the end of the string until the target buffer size runs out or until a NULL byte is hit.
    Helpful post? Buy me a coffee.
  • #106 21006810
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2 This is the reason, after dynamic definition of the buffer, one would like to zero it... Something like setmem(buffer, 0). After dynamic definition there could be everything in the buffer.
    The other way is to add after the string #0 after parsing
  • ADVERTISEMENT
  • #107 21006997
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    Actually not, doing a memset 0 or in Windows slang ZeroMemory on that buffer would not help in most cases because the old code was allocating only the reported byte length from the TuyaMCU, so there was no space for extra NULL terminating character. In the revised version I posted above, I am manually adding one byte to the buffer length and I am setting that extra byte to 0 to make sure that string is terminated.
    Helpful post? Buy me a coffee.
  • #108 21007021
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    Understood.
    But still I cannot test it. @morgan_flint should do this, because he has such device...
  • #109 21007376
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Just tested with the latest compiled version of OBK (1.17.509) and the problem is solved:
    Screenshot of the OpenBK7231N user interface with energy settings and values.

    >>21004367
    @angelofdeath, another suggestion for the improved web page, if you consider it right: The box to add purchased energy disappears when "Prepayment" is off:
    Screenshot of the OpenBK7231N interface with visible settings and buttons.
    I understand you did this on purpose, as loading prepaid energy only makes sense if you're using the prepayment function, but I find it interesting to be able to load this counter before switching prepayment on. For example, if you have cleared counters and then switch prepayment on, the relay switches off until you load prepaid energy. In the same situation, with the standard OBK interface, you can load prepaid energy before switching prepayment on, thus avoiding the momentary blackout:
    Screenshot of the OpenBK interface regarding prepaid energy functionality.
  • #110 21007451
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint I think, I have read somewhere you cannot set prepaid energy, if Prepaid function is off. Or at least that was the case with the other device. This is the reason the box disappears. Will check this with my device again. But if you are sure with this device you can set prepaid energy I will remove disappearing in this version of the script only.
    Will have time at some point in the afternoon to make all changes.
  • #111 21007466
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Just checked it again and it's possible. I also remember what you said, maybe it's not the case in the other device. I'll connect it and try

    EDIT: Connected the other device (TOMPD63-WIFI) and it's like you say: in OBK's web, with prepayment off the prepaid energy counter won't change even if you send something to DpID 14 (channel 12 stays at 0, while if you send something with prepayment on, this channel would reflect the figure).

    So this modification would be only for TOMPD63-LW. Thanks!!
  • #112 21007508
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    ok. Will do it for this device only.
  • #113 21045967
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Angel0fDeath wrote:
    ok. Will do it for this device only.

    Hi, @Angel0fDeath
    Some time ago, I was able to correct the scale/label issues, but the visibility seemed more difficult, as I don't know HTML or Javascript...

    But today I decided to give it a try, and I think now it works as I intended. Just modified the condition at the beginning of function Settings_Prepaid_visibility(vis).

    Maybe there's a more efficient way of doing this, but this seemed easier for me...

    I'm attaching it as "rev3prov(isional)", until you give your OK. Thanks again for your work!
    Attachments:
    • TOMPD-63-LW_rev3prov.html.txt (22.22 KB) You must be logged in to download this attachment.
  • #114 21100924
    stefanbratu74
    Level 3  
    Posts: 3
    >>21045967>>21045967
    Can anyone pls post the setup for this module....
  • #115 21101033
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    Hello @stefanbratu74 ! Which module do you have exactly? Have you managed to get 2MB backup and flash OBK there? Have you seen autoexec.bat text on the previous page of this topic?

    Btw, check also our docs: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
    Helpful post? Buy me a coffee.
  • #116 21101080
    stefanbratu74
    Level 3  
    Posts: 3
    Ok, I start to understand how it works, I just OTA Flash the module and didn't find the settings for it. In the web app if i select the module and press Copy device settings nothing happened. I found the autoexec.bat file https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecs/TOMPD-63-WIFI.bat and after restart it seems to work...
    Thank you for your help
  • #117 21101089
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    So your device is working out of the box with out autoexec.bat? Whoa, that's very nice! Tuya tends to change things often so I expected that we will have to do some adjustments.

    Have you tried our custom HTML page as well?
    Helpful post? Buy me a coffee.
  • #118 21104444
    stefanbratu74
    Level 3  
    Posts: 3
    Not quite. The device is few years old, I use it until now with localtuya and blocked internet access in router firewall. Recently I found that some resourceful guy(s) managed to break tuya protocol and I tought to give it a try (I'm glad i did). I use it now in HA and it works just fine.
    Thank you and keep up the good work
  • #119 21110386
    sakki143
    Level 2  
    Posts: 2
    I am looking for the "downloaded data file" (a csv maybe) of Tomzn TOMPD 63-LW. The purpose is to see how frequently the data (voltage, amp, and kwh) is logged.
    It would be much appreciated if someone could update that file here.
    Thanks
  • #120 21110395
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    Hey @sakki143 , are you referring to OBK version? We have raw dpIDs http interface: https://www.elektroda.com/rtvforum/topic4049908.html
    Helpful post? Buy me a coffee.
📢 Listen (AI):

Topic summary

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

FAQ

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]
Generated by the language model.
ADVERTISEMENT