logo elektroda
logo elektroda
X
logo elektroda
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
📢 Listen (AI):
  • #121 21363680
    mr_crabs
    Level 6  
    Posts: 5
    Help: 1
    Rate: 4
    Hello folks! First of all thanks for the great piece of work you did!

    Inspired by your upgrade of this relay, I've started my teardown. First of all, I faced quite a different PCB with the Tuya CBU module instead of the one mentioned in this topic. The next thing that prevented me from proceeding was being unable to flash it in place, which seemed to happen because TuyaMCU interfered with UART. The "easiest" way was to desolder the wifi module and flash it. Thanks God and that LCD is made of "crystals" so my overheated areas perfectly cured themselves slowly 😅 

    Spoiler:
    Here is the PCB itself. Even the pinout for GND and 3.3V were shifted compared to one from the topic.
    Electronic module with a circuit board and Tuya CBU component. 


    The most recent problem was that I've been struggling to make things work properly with the latest autoexec.bat posted by AngelOfDeath which also is included in the OpenBeken repository. If I use this one, the main relay toggle goes off constantly. Just in a second after switching it on it goes off on the WebUI and also the same behavior with the physical button. Only the "original" autoexec.bat was working and some of the next revisions. Nothing interesting was mentioned in the logs so I had to perform manual debugging by commenting out the most needed features line by line.

    And as for now my learning is that placing "combined energy dpid" to the channel before the main relay one fixes the issue. What I mean by that is that combination DpID 16 -> channel 1, DpID 6 -> channel 2,3,4 wont work, while DpID 6 -> channel 1,2,3 DpID 16 -> channel 5 works fine.

    Here is the code that works fine on my device:

    
    clearIO
    SetFlag 46 1
    
    // start TuyaMCU driver
    startDriver TuyaMCU
    tuyaMcu_setBaudRate 9600
    
    waitFor MQTTState 1
    // tuyaMcu_defWiFiState 4
    
    // Breaker Id - Dpid 19 "breaker_id" -> channel 0
    linkTuyaMCUOutputToChannel 19 str 0
    setChannelType 0 ReadOnly
    setChannelLabel 0 "Breaker ID"
    
    // Measurements - Dpid 6 "phase_a" - channel RAW_TAC2121C_VCP -> channel(s) 1,2,3
    // TAC2121C VoltageCurrentPower Packet
    // This will automatically set voltage, power and current
    linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
    setChannelType 1 Voltage_div10
    setChannelLabel 1 "Voltage"
    setChannelType 2 Power
    setChannelLabel 2 "Power"
    setChannelType 3 Current_div1000
    setChannelLabel 3 "Current"
    
    // Main Relay - Dpid 16 "switch" -> сhannel 4
    linkTuyaMCUOutputToChannel 16 bool 4
    setChannelType 4 toggle
    setChannelLabel 4 "Relay"
    
    // Prepayment on-off - Dpid 11 "switch_prepayment" -> channel 5
    linkTuyaMCUOutputToChannel 11 bool 5
    setChannelType 5 toggle
    setChannelLabel 5 "Prepayment"
    
    // Clear Energy Counters - Dpid 12 "clear_energy" -> channel 6
    linkTuyaMCUOutputToChannel 12 bool 6
    setChannelType 6 toggle
    setChannelLabel 6 "Clear Energy Counters"
    
    // Total energy - Dpid 1 "total_forward_energy" -> channel 7
    linkTuyaMCUOutputToChannel 1 val 7
    setChannelType 7 EnergyTotal_kWh_div100
    setChannelLabel 7 "Total Energy"
    
    // Leakage current - Dpid 15 "leakage_current" -> channel 8
    linkTuyaMCUOutputToChannel 15 val 8
    setChannelType 8 Current_div1000
    setChannelLabel 8 "Leakage Current"
    
    // Fault - Dpid 9 "fault" -> channel 9
    linkTuyaMCUOutputToChannel 9 raw 9
    setChannelType 9 ReadOnly
    setChannelLabel 9 "Fault"
    
    // Settings 2 - Dpid 18 "alarm_set_2" -> channel 10
    linkTuyaMCUOutputToChannel 18 raw 10
    setChannelType 10 ReadOnly
    setChannelLabel 10 "UV, OV, Max. Current Protections Settings"
    
    // Prepaid energy - Dpid 13 "balance_energy" -> channel 11
    linkTuyaMCUOutputToChannel 13 val 11
    setChannelType 11 EnergyTotal_kWh_div100
    setChannelLabel 11 "Total Prepaid Energy"
    
    // The above are read only channels. Except Settings 2 (mapped on channel 10), but since we cannot set it due to wrong parse of TuyaMCU driver - for now read only
    
    // Charge Prepayment - Dpid 14 "charge_energy" - channel 12
    linkTuyaMCUOutputToChannel 14 val 12
    setChannelType 12 TextField
    setChannelLabel 12 "Purchased Energy [kWh*100], i.e. 1kWh = 100"
    
    // Settings 1 - Dpid 17 "alarm_set_1" - channel 13
    linkTuyaMCUOutputToChannel 17 val 13
    setChannelType 13 TextField
    setChannelLabel 13 "Leakage Current Protection Settings"
    
    // Protection Reaction Time - Dpid 104 "over_vol_protect_time" (applied for all protections, regardless the name of DpID) -> channel 14
    linkTuyaMCUOutputToChannel 104 val 14
    setChannelType 14 TextField
    setChannelLabel 14 "Protection Reaction Time [s]"
    
    // Protection Recovery Time - Dpid 105 "over_vol_recovery_time" (applied for all protections, regardless the name of DpID) -> channel 15
    linkTuyaMCUOutputToChannel 105 val 15
    setChannelType 15 TextField
    setChannelLabel 15 "Protection Recovery Time [s]"
    
    tuyaMcu_sendQueryState
    


    Can anyone explain to me what's going on with that channels case?

    P.S. Right now, when I somehow have operational autoexec, I tried to upload alternative web UI but failed 🥲 I guess that the alternative web page is too big to be uploaded (POST request just fails) So I plan to rewrite the web page from scratch with some frontend best practices but keeping it close to the original. Will share with you if come up with anything good.
  • ADVERTISEMENT
  • #122 21363688
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    RAW_TAC2121C_VCP has been recently updated and maybe I need to improve backwards compatibility, but the suggested usage is as in self test:
    Code: C / C++
    Log in, to see the code

    I will fix the default behaviour now, but the preferred usage is to specify the Voltage channel index and it will then assume that after voltage comes current and then power.
    Helpful post? Buy me a coffee.
  • #123 21363758
    mr_crabs
    Level 6  
    Posts: 5
    Help: 1
    Rate: 4
    >>21363688 Thank you for your fast response! It worked like a charm.
    I've created Pull Request with these modifications just in case, so feel free to close it if it isn't needed.
  • #124 21363782
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    Yesterday I fixed (tried to fix?) 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 now?
    Helpful post? Buy me a coffee.
  • #125 21367632
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    >>21363758 There's an error in your PR; because of the fixes made to RAW_TAC2121C_VCP, if you add the first channel number at the end of "linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP X", then you have to respect the order Voltage, Current, and Power (VCP) in the following channel type definitions:
    Comparison of two code versions with highlighted changes in parameter order.

    If you don't specify the first channel number after RAW_TAC2121C_VCP, then you can change (at least) the order of C and P, as in the original autoexec, and still get good results, so we have good backward compatibility. The first channel number is necessary for multi-phase meters but can be skipped in single-phase devices.

    More detailed info here and also in the previous posts
  • ADVERTISEMENT
  • #126 21369339
    mr_crabs
    Level 6  
    Posts: 5
    Help: 1
    Rate: 4
    >>21363782 Hi thank you! Updated firmware recently and checked - autoexec.bat without channel for VCP works as expected 👍

    PS. I'm still struggling with file uploads. Seems that device reboots when it receives a payload larger than 20000 or something. But will get back to it after I finish with mime types things. They seem not to be working as well 🥲
  • #127 21407056
    quantum8
    Level 2  
    Posts: 2
    Rate: 1
    After successfully flashing one of these devices, I ordered a second one but it appears they've changed the PCB layout again.

    This version has the wifi module mounted on the main board via a soldered in riser.

    I haven't attempted flashing it yet but will report back afterwards.
    Attachments:
    • [BK7231N ] Teardown and flashing of Tomzn TOMPD-63 WIFI (not to be confounded with TOMPD-63LW) IMG_20250124_074216.jpg (1.47 MB) You must be logged in to download this attachment.
  • #128 21407060
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    Make sure to take 2MB flash backup, it can help us with futher configuration.
    Helpful post? Buy me a coffee.
  • #129 21412055
    koshov
    Level 1  
    Posts: 1
    Rate: 1
    Hi everyone, I'm currently using 3 of these devices on each phase of my 3Ph+N grid supply as a means of protecting against abnormal voltage. I haven't yet torn down and re-flashed them, however I recently added them to Home Assistant using the Tuya Local integration and noticed that the power meter on the device reports much lower values than other metered relays.
    I have several DIN rail "Tongou" Tuya smart relays connected to single large loads that report values in line with what I'd expect for e.g. a heat pump, however the power usage on the 3 main phases reported by these Tomzn devices never exceeds ~100W and subsequently the metered values are a fraction of what I know is used "downstream" of them.
    It's worth mentioning that all loads on the 3 phases are connected to a common Earth/Neutral rail, thus I had to disable the leakage protection of the Tomzn - could that be the source of the issue?
    I wanted to check if folks here have similar experience and these devices just aren't suitable for metering before I go down the teardown and flashing rabbit hole. Cheers!
  • #130 21413748
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    koshov wrote:
    the power usage on the 3 main phases reported by these Tomzn devices never exceeds ~100W

    I've tested mine with ~2 kW and it reports power well
    koshov wrote:
    It's worth mentioning that all loads on the 3 phases are connected to a common Earth/Neutral rail, thus I had to disable the leakage protection of the Tomzn - could that be the source of the issue?

    Could you post the schematics for this, including how you connected the Tomzns?

    EDIT: I've added this schematic to the first post:
    Circuit diagram of TOMPD-63 WiFi device

    As you can see, the current measurement shunt is inserted in the neutral, so how it's connected downstream of the device may affect the measurements. In my case, neutral is isolated from earth (at home, not at the utility's transformer), and each circuit downstream of the switchboard has independent phase and neutral wires so that I wouldn't have that problem
  • #131 21435942
    pexicele
    Level 3  
    Posts: 7
    Hi morgan_flint , acording to your schematic it seems that Tomzn can measure DC also, correct ? did you try it ? thank you.
  • #132 21436515
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    >>21435942
    I didn't try, but I don't think so, as the BL0942 is, in principle, an AC-only metering chip... It could be funny to see how it treats DC, but if, for example, it employs AC voltage zero crossing for something inside, it would have problems with DC.

    Apart from this, the DC/DC converter (PN8035Q) could work well from a certain DC voltage, if the positive is connected to the phase because of D2.

    Of course, leakage current wouldn't work, as it depends on a current transformer.
  • ADVERTISEMENT
  • #134 21453780
    quantum8
    Level 2  
    Posts: 2
    Rate: 1
    A quick update on the board I have as I finally had a little time this evening;
    It appears you don't need to solder anything to flash this device as all the pins are accessible via the headers now.

    Electronic board with cables connected to headers for Vcc, GND, Tx, and Rx.
  • #135 21487634
    leśny_ziutek
    Level 12  
    Posts: 52
    Help: 3
    Rate: 9
    As the VoltageSet, CurrentSet, PowerSet commands doesn't work with this device (see >>21487463) is there any way to calibrate it? May ones require voltage calibration (3-4 V error).
  • #136 21487791
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    >>21487634
    Unfortunately, I don't think there's a simple way to calibrate it. As @p.kaczmarek2 says in the post you linked, in this case, the communication between the measuring IC (BL0942) is handled by the
    TuyaMCU, which serves the elaborated measurements info to the WiFi module, so any calibration should be done in the Tuya MCU's firmware, not accessible for us.

    In other similar TuyaMCU devices, I've seen calibration parameters in the settings menu and/or in the DPIds that could adjust for errors directly in the Tuya MCU but, apparently, that's not the case in this one, at least in the version installed in my device.

    If the error only affects voltage measurements, you could try a hardware approach by adjusting one of the resistors (R14-18 or R19) in the voltage divider connected to pin 4 of the BL0942, (see schematic at this post).

    Blue printed circuit board with various electronic components, including resistors marked in red.
  • #137 21487906
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    @leśny_ziutek maybe add here argument - delta?
    Screenshot of documentation related to TuyaMCU, showing a table with links and parameters.
    Helpful post? Buy me a coffee.
  • #138 21488607
    leśny_ziutek
    Level 12  
    Posts: 52
    Help: 3
    Rate: 9
    @p.kaczmarek2 I didn't found anything about "delta" param. Is it an offset or a scale?

    @morgan_flint Mayby I'll try such hardware mod if anything on the software side doesn't help. So far I've managed to repair the filled down backlight connections on one of my units:

    TOMZN electronic energy meter on a wooden table.
    Close-up of a printed circuit board with an attached LCD display.
    Stack of circuit boards mounted against a wooden background.
  • #139 21488862
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    leśny_ziutek wrote:
    @p.kaczmarek2 I didn't found anything about "delta" param. Is it an offset or a scale?

    It was an idea. A suggestion. I said that I can add something like that if you think that it would be useful.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #140 21489087
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Could something like a general "channel scale" or "channel math" function be useful for this and/or other applications? Starting with an offset + linear scale, for example...
  • #141 21491237
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14622
    Help: 655
    Rate: 12638
    @leśny_ziutek I added delta now.
    https://github.com/openshwprojects/OpenBK7231...mmit/b80fff5d409947ae9120712865df6af3fc469f28

    @morgan_flint there is already scale...
    
    linkTuyaMCUOutputToChannel [dpId] [varType] [channelID] [bDPCache] [mult] [inv] [delta]
    

    This is per dpID. Not for VCP yet.


    For VCP, we might use our WIP berry integration... but it depends on what do you need.

    Futhermore... well, @leśny_ziutek , we can only calibrate data sent to HA and shownin OBK. We can't calibrate data on screen, because it's sent directly from MCU to screen. OBK can't access that
    Helpful post? Buy me a coffee.
  • #142 21493013
    leśny_ziutek
    Level 12  
    Posts: 52
    Help: 3
    Rate: 9
    p.kaczmarek2 wrote:
    We can't calibrate data on screen, because it's sent directly from MCU to screen. OBK can't access that

    Yes, I understand this. As a "software way" I was thinking about some way to send calibration data to the TuyaMCU (if it's possible at all and a way to do it will be discovered in the future). Apart from that a general linear scaler (multiplier and offset) can be useful on its own.
  • #143 21504906
    pexicele
    Level 3  
    Posts: 7
    Hi, I have Tompd 63 SW - wifi (color display) - flashed (OpenBK7231N_1.18.72) - i need an working autoexec.bat, I had tried many versions - none of them works ok, I even flashed my device with old firmware versions - no succes. I'm not able to update .html files - (it shows size 0 after upload.) There is something else updated since 1-2 years ago ? (i see posts with perfectly working devices..)
    Thanks for your help.

    LE : this seems to works ok :
    linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
    setChannelType 5 Voltage_div10
    setChannelLabel 5 "Voltage"
    setChannelType 7 Current_div1000
    setChannelLabel 7 "Current"
    setChannelType 6 Power
    setChannelLabel 6 "Power"

    this not (return wrong value for 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"

    and another thing: the device that "seems to work" has a non linear error for currrent (smaller current = bigger error) , I've attached pictures for a not-flashed and flashed devices.


    Display of TOMZN TOMP 63SW device with voltage, current, and power meters.
    Color display of the TOMPD 63SW device showing electrical measurements.

    Ok, sorry for spam, it seems that now there is not enough memory for autoexec + html file, don't know the reason. I was forced to slim down the autoexec file and remove comments and also the "Prepaid" part since I have no interest in this. Now is working.
    Attachments:
    • autoexec_minimal.zip (619 Bytes) You must be logged in to download this attachment.
  • #144 21507679
    rufus4
    Level 11  
    Posts: 65
    Rate: 9
    Would be nice if somebody could give me some information about the functionality/behavior of this product.

    Where I live the low voltage grid is all distributed in the air with power cables on posts. So we have a lot of interrupts and failures coming from the grid.
    Sometimes it happens that the power goes and comes on several times in a very short period. This creates dangerous voltage peaks killing electrical devices.
    (I'm connected with one phase only to the grid.)

    To prevent damages I installed a relay and a delay timer to wait 1-2 min. before connecting to the grid again after a failure. There is as well a voltage controler for over- and undervoltage.

    My question now is, does this power meter have a possibility to do the same delay after a power cut, or does it switch the relay straight away after power comes back on?
    And my second question, is the relay silent? I mean really silent and not noticeable if you stay in front of the power box where it's built in.

    thanks in advance!
  • #145 21508925
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    rufus4 wrote:
    My question now is, does this power meter have a possibility to do the same delay after a power cut, or does it switch the relay straight away after power comes back on?

    After a power cut, it remembers the previous state and, if it was "on", then it waits the time programmed in "restart time setting" (see pictures in the first post of this thread) before reconnecting. This time can be set from 1 to 500 seconds and is the same time it waits before reconnecting in case of actuation of any of the protections (over-under voltage, overcurrent, or leakage current)

    rufus4 wrote:
    And my second question, is the relay silent? I mean really silent and not noticeable if you stay in front of the power box where it's built in.

    No, it's not silent; there's an audible "click" when it changes state.

    You can see how it waits for the restart time and hear the sound in the attached video (the first "click" is from another device; the one from this device sounds when the countdown reaches 0):


  • #146 21509049
    rufus4
    Level 11  
    Posts: 65
    Rate: 9
    >>21508925 Thanks a lot for your helpful informations, thats very kind.

    About silent, I was thinking that maybe the relay makes noises when its armed like a electric contactor. Actually this is the biggest negative point of this product. It cuts L only and it uses a relay instead of a contactor.

    Anyway, all in all it still can be useful and it is very cheap.

    Maybe I could use it in combination with a quality contactor. Then it should be save.
  • #147 21510427
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    rufus4 wrote:
    ctually this is the biggest negative point of this product. It cuts L only and it uses a relay instead of a contactor.

    If you're concerned about this, there's a similar device which cuts both:
    https://www.elektroda.com/rtvforum/topic3995777.html
    You can see the two relays in the photos here and here
    By the way, these relays are bistable, so the coil is not fed continuously to keep them connected.
    I don't think a contactor would be less noisy than them.
  • #148 21510587
    rufus4
    Level 11  
    Posts: 65
    Rate: 9
    morgan_flint wrote:
    By the way, these relays are bistable, so the coil is not fed continuously to keep them connected.

    Okay, good to know. This is the answer about noise, there is none. Thanks again!

    About the contactor, usually you use these for bigger and possibly high inductive loads. I do not have so much confidence in this chinese branded relay. I'm afraid it will overheat because of worn-out contacts one day.

    Probably I do have to get one of these relays and take it appart into peaces for a visual check. And a "powerful sparky" short with 400V will show if the contacts are good. As an example: cheap quality circuit breakers (even european brands) can't stand this and contacts burn off, good ones do survive this torture sovereign.

    Added after 12 [minutes]:

    Oh, an other quiet important thing I realised now. If these relays are bestable. How can it happen that the relay is off after a power cut? Because then in practise it would be needed to first switch off after power returns.
    Is it guaranteed bestable?
  • #149 21510731
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    rufus4 wrote:
    I do have to get one of these relays and take it appart into peaces for a visual check

    I've already done that some time ago 😉

    As the relay I took apart was from another device (but similar to this one's), I've just posted the photos on that device's thread.

    Also, in the first post of that thread, you can find the Chinese datasheet of the relay driver IC. I didn't draw the schematic for that device, but the relay driver part must be very similar to this device's. You can see the schematic of this one here


    rufus4 wrote:
    Oh, an other quiet important thing I realised now. If these relays are bestable. How can it happen that the relay is off after a power cut?

    Good question!
    I don't know how it really does it (could be the Tuya MCU's firmware or a feature of the driver IC...) but, after disconnecting it from AC input, during the brief moment the display is still on (due to the internal power supply's electrolytic capacitor) you can hear the "click" of the relay switching off.

    EDIT: Maybe "latching relay" or "magnetic latching relay" is the correct name for this type... Here's a YouTube video showing one that looks much like the one on these devices (except for the 3-terminal coil; in our case, the driver IC inverts the polarity)

    Also, adding video where you can hear it disconnecting at the beginning. Also, I can check with a lamp connected to the output that it doesn't turn on after reconnecting the input to the device:


  • #150 21510782
    rufus4
    Level 11  
    Posts: 65
    Rate: 9
    morgan_flint wrote:
    Good question!
    I don't know how it really does it (could be the Tuya MCU's firmware or a feature of the driver IC...) but, after disconnecting it from AC input, during the brief moment the display is still on (due to the internal power supply's electrolytic capacitor) you can hear the "click" of the relay switching off

    Okay, so it must be done by a solution that when "power-off" a condensator is discharging through the coil of the relay and triggers it (or similar?!).

    morgan_flint wrote:
    As the relay I took apart was from another device (but similar to this one's), I've just posted the photos on that device's thread.

    nice... <thumbs-up>
    More and more I do realise that this is a energymeter-wifi-switch-toy and nothing else. It has absolutely nothing to do with safety. And it definitely pretends this with the leakage-ammometer, overvoltage and under/overcurrent functions. I don't think this is certified to be used in any legal electrical installation.

    Actually I would be aware of this product being used seriously. (On your picture of the relay, the shunt-resistant is positioned directly on the case of the relay, and so on....)
    At least my consent is to leave the fingers from that toy. Life is too valuable.

    Thanks again for all these helpful informations!
📢 Listen (AI):

Topic summary

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

FAQ

TL;DR: This FAQ helps OpenBeken users flash the Tomzn TOMPD-63 WIFI and map its 13 DpIDs correctly. "Everything seems to be ok" once DpID raw access is enabled, but DpIDs 17, 18, and 19 need special handling, and DpID 12 clears both energy counters on this model. [#20925322]

Why it matters: The TOMPD-63 WIFI looks similar to other Tuya breakers, but its hardware, relay behavior, raw DpIDs, and counter logic differ enough that a copied configuration can fail.

Model Relay switching Key DpID differences Energy clear behavior
TOMPD-63 WIFI Cuts line only DpIDs 1, 6, 9, 11–19, 104, 105 DpID 12 clears total and prepaid energy
TOMPD-63LW Cuts line and neutral Adds DpIDs 21 and 101; different 104/105 meaning Counters can be cleared separately

Key insight: Treat the TOMPD-63 WIFI as its own platform, not a TOMPD-63LW clone. The breakthrough was OBK raw DpID access over HTTP/MQTT, which exposed DpIDs 17, 18, and 19 as usable hex or string data instead of broken integers. [#20931165]

Quick Facts

  • The TOMPD-63 WIFI teardown identified 13 DpIDs: 1, 6, 9, 11–19, 104, and 105, before OBK flashing began. [#20869137]
  • The protection action time in DpID 104 is documented as 1–30 s, but device users reported menu control in 0.5 s steps from 0.5 s to 30 s. [#20879436]
  • The recovery delay can be set from 1 to 500 seconds, and the action time and recovery time affect real protection behavior after faults and restarts. [#21508925]
  • One user bought the device for 11.56€, with a more typical price around 19€, which explains why it became a popular hacking target despite firmware quirks. [#20883189]
  • Newer hardware revisions appeared with CB3S, CBU, and header-accessible modules; one late board revision no longer required soldering because RX, TX, VCC, and GND were reachable through headers. [#21453780]

How do I flash a Tomzn TOMPD-63 WIFI with a BK7231N/WB3S or CB3S module using OpenBeken, and which RX, TX, VCC, and GND connections are needed?

You can flash it over UART by wiring RX, TX, VCC, and GND to the Wi-Fi module pads or header. 1. Disconnect the small display/Wi-Fi board from the power board. 2. Solder only RX and TX if VCC and GND are already on the header. 3. Power VCC only when the flasher starts, because that avoids interference from the Tuya MCU. Early WB3S boards needed two wires plus header power; later revisions exposed all pins on headers, and CB3S units also flashed successfully with uartprogram ... -w --unprotect -s 0x0. [#21453780]

What is the difference between the TOMPD-63 WIFI and the TOMPD-63LW, especially in relay switching, DpIDs, and energy counter behavior?

The TOMPD-63 WIFI cuts only the line, while the TOMPD-63LW cuts both line and neutral. Up to DpID 19, most DpIDs match, but the LW adds DpID 21 for leakage test and DpID 101 for clearing the main energy counter, and its DpIDs 104 and 105 mean power factor and frequency instead of protection timing. The biggest user-visible difference is DpID 12: on the WIFI model it clears both prepaid and total energy, while on the LW it clears only prepaid energy. [#20921587]

How can I extract and identify the Tuya DpIDs for the TOMPD-63 WIFI before replacing the stock firmware with OBK?

Extract the DpIDs from Tuya first, then flash OBK after you know the map. 1. Use the Tuya developer workflow described in the linked tutorial to pull the product JSON. 2. Read the abilityId, code, and typeSpec fields for each property. 3. Build your OBK autoexec.bat from those DpIDs. The TOMPD-63 WIFI exposed 13 DpIDs, including phase_a on DpID 6, fault on DpID 9, switch on DpID 16, and timing controls on DpIDs 104 and 105. [#20869137]

Why does DpID 104 on the TOMPD-63 WIFI show only integer values in OBK or tuya-mqtt.js when the device menu allows 0.5 second steps?

It shows integers because the Tuya MCU reports DpID 104 as an integer value even when the device UI offers 0.5 s steps. Users verified that setting 0.5 s on the breaker appears as 0 in OBK, while 1.0 s and 1.5 s both transmit the same integer payload. The thread conclusion was that the limitation comes from the Tuya MCU firmware or protocol handling, not from the front-end page. That makes 0.5 s steps visible on the device itself but not reliably readable through OBK or tuya-mqtt.js. [#20880051]

What does the mysterious 't' setting on the Tomzn TOMPD-63 WIFI actually control, and how was the LCD backlight pad identified?

The t setting controls the LCD backlight timeout. A user reopened the device, found two unused pads on the small PCB, and traced one to ground and the other through a resistor and transistor that looked like an LED driver. After soldering an LED to those pads and setting t to a low value, the LED turned on after a button press and switched off after the programmed time. The manual called it a “light source,” and the hardware test confirmed it was a prepared backlight function. [#20883603]

How should I configure autoexec.bat for the TOMPD-63 WIFI so DpID 6, 9, 17, 18, 19, 104, and 105 work correctly in OpenBeken?

Use TuyaMCU, enable Wi-Fi-paired behavior, and map raw or string DpIDs carefully. DpID 6 should use RAW_TAC2121C_VCP; DpID 9 should be mapped as raw for full fault bitmaps; DpIDs 17 and 18 should be kept as raw or handled via raw send commands; DpID 19 should be mapped as str; and DpIDs 104 and 105 should be mapped as val. Start with clearIO, SetFlag 46 1, startDriver TuyaMCU, tuyaMcu_setBaudRate 9600, and tuyaMcu_sendQueryState. That arrangement was the stable end-state after several revisions. [#20954679]

Why do raw TuyaMCU DpIDs like 17, 18, and 19 fail to parse correctly as integers or strings in some OBK builds, and what workaround was added?

They fail because those DpIDs are longer raw or string payloads, not simple 32-bit values. DpID 17 is 4 bytes and can sometimes fit, but DpID 18 is 12 bytes and overflows integer-style parsing, while DpID 19 is a string like ETU9-IOT-WIFI. The workaround was to add raw DpID access so OBK could expose raw payloads as hex strings and strings directly over HTTP and MQTT instead of forcing broken integer conversion. That feature landed through the Dp and DPxx commands with a flag-controlled implementation. [#20924258]

How can I read raw TuyaMCU data as hex over HTTP or MQTT using the OBK Dp and DPxx commands?

Enable the raw DpID feature, map the DpIDs, then query them with Dp or DPxx. Dp returns a JSON array of all mapped DpIDs, including id, type, and data, while DP23 returns one DpID only. Over HTTP, users called IP/cm?cmnd=Dp; over MQTT, the same command published JSON to the stat topic. Raw fields appear as hex strings, and string DpIDs like 19 appear as decoded text. This solved the long-standing visibility problem for DpIDs 17, 18, and 19. [#20925335]

What is RAW_TAC2121C_VCP in OpenBeken, and how does it map the phase_a packet into voltage, current, and power channels?

“RAW_TAC2121C_VCP” is a packet parser that decodes Tuya’s phase_a raw meter frame, splitting one 8-byte payload into voltage, current, and active power channels. It exists because DpID 6 is not a plain number; it is a packed VCP measurement block. In newer OBK usage, you should provide the first channel index after RAW_TAC2121C_VCP, and OBK will place voltage first, current next, and power last in VCP order. If the channel order is wrong, readings or relay behavior can break. [#21363688]

What is a DpID in the Tuya ecosystem, and why does it matter when migrating a smart breaker from Tuya firmware to OpenBeken?

“DpID” is a Tuya data-point identifier that links one device function to a defined payload type, access mode, and meaning, such as a relay state, fault bitmap, energy counter, or raw measurement packet. It matters because OBK must map each DpID correctly to a channel or parser. If you guess wrong, the breaker can show bad values, miss alarms, or reject writes. On this device, DpID 6 carries raw VCP data, DpID 9 is a fault bitmap, and DpIDs 17–19 need special raw or string handling. [#20869137]

Why does the TOMPD-63 WIFI clear both total energy and prepaid energy with DpID 12, while the TOMPD-63LW clears them separately?

The TOMPD-63 WIFI simply implements DpID 12 differently from the TOMPD-63LW. Users tested it and confirmed that triggering DpID 12 on the WIFI model resets both DpID 13 prepaid energy and DpID 1 total energy. On the LW model, separate DpIDs exist for separate clears, so the logic is cleaner. The mistaken “Clear Prepayment” label in early OBK examples came from copying the LW setup, then it was corrected to “Clear Energy Counters” after testing. [#20881929]

What is the best way to decode the TOMPD-63 WIFI fault bitmap from DpID 9 into readable alarms in Home Assistant, FHEM, or a custom web page?

The most reliable method is to treat DpID 9 as raw data and decode the bitmap in software. The thread showed a simple loop that checks each bit against a 17-item label array, then builds readable text such as Overvoltage, Overcurrent, or Leakage Current. Users also found that single-byte and two-byte fault payloads confused integer parsing, while raw handling fixed it. In practice, a custom page or server-side script is better than forcing OBK text channels, especially when multiple alarms are active at once. [#20883083]

How do I host the alternative TOMPD-63-WIFI HTML control page on LittleFS when the file is too large, and what can I trim or reconfigure to make it fit?

Trim the HTML and autoexec.bat, or increase usable LittleFS space. Users made the page fit standard LittleFS by removing comments, blank lines, and indentation, reducing the HTML to 20,316 bytes and autoexec.bat to 1,733 bytes. Another option is to reconfigure LittleFS size and block settings, then restore files after OTA if needed. A newer WebApp also added an “Upload file” button, which helped Linux and Android users upload the trimmed files without drag-and-drop issues. [#21310442]

Why does the relay toggle misbehave when using certain channel orders with RAW_TAC2121C_VCP, and how should VCP channels be assigned in newer OBK builds?

The misbehavior comes from newer RAW_TAC2121C_VCP parsing rules. Once you specify the starting channel index, OBK expects VCP order: voltage first, current second, power third. One user saw the relay toggle switch off after one second when DpID 16 and VCP channels were arranged badly, but the issue disappeared after moving the VCP block earlier and respecting its channel order. Later fixes restored backward compatibility for the old no-index style, but the safer method in new builds is explicit VCP ordering. [#21367632]

How can I make an Atroch GR2PWS or similar Tuya-based power relay stay off at power-up until voltage conditions are safe, instead of energizing the relay for several seconds first?

You may not be able to do that with the stock startup behavior. A later user reported that the Atroch GR2PWS energizes its relay for about 10 seconds after power-up, then starts measuring and enforcing rules, which creates a risk window if mains voltage is already unsafe. The thread did not provide a confirmed OBK-side fix for forcing an always-off boot state on that model. For safety-critical use, treat that startup pulse as a known limitation until a model-specific workaround is tested and verified. [#21624931]
Generated by the language model.
ADVERTISEMENT