logo elektroda
logo elektroda
X
logo elektroda

Power Meter KWS-302WF: Switching from Shunt to Transformer with HT7017 Chip sometime in the futur ..

Lusant 10590 30
Best answers

Can I change the KWS-302WF from shunt-based current measurement to a transformer-based one by modifying the Wi‑Fi/CBU firmware?

No — changing the measurement method from shunt to transformer is not something you can do just by flashing the Wi‑Fi/CBU module, because the PY32F002A MCU handles the measurements and most of the device logic, then sends data to the CBU over UART [#21226735][#21226744] To make a shunt-to-transformer change, you would likely need to modify or replace the PY32F002A firmware, which was described as the hard part and probably protected against easy reading [#21226735][#21226744] The CBU firmware can be changed to OpenBeken/OpenBK7231 to control the TuyaMCU link and the relay/display mappings, but that does not move the current-sensing job away from the MCU [#21226735][#21226744] The captured data can still be useful for building an autoexec.bat and mapping dpIDs, but it won’t by itself solve the hardware measurement change [#21226735][#21226744]
Generated by the language model.
ADVERTISEMENT
  • #31 21617102
    DGAlexandru
    Level 7  
    Posts: 7
    Help: 1
    Rate: 1
    Hi Lusant,

    thanks for the file... it makes some more light into those "unknown" dpIDs:
    "switch_schedule" for "dp_id": 122 - now it makes sense. In the Smart Life App you can define schedules to control the relay. I think they used a different dpID for this than the 0x10 / 16 one just to have a trace of the owner of the command :P

    I confirm that pressing + and - buttons on the device, for 5s, resets all the values in the device, including this dpID 0x7b / 123. The screen puts underscores "___" at all the values for about 1 second then it switches the Relay to Off and changes the screen to "Relay Off" mode and stays like that.
    It also resets the configured values for UnderVoltage, OverVoltage and so on to their default values.
    Great find!

    Now if I could make Ghidra help me in decompiling the MCU firmware to something I can work with so I can modify it to have at least a "recovery time" option :)

    Added after 25 [minutes]:

    Revised autoexec.bat version based on the new findings now draws the GUI like this:
    KWS-302WF interface with control buttons and electrical parameter readings

    (I edited my previous message with the autoexec.bat code and updated it there)
  • ADVERTISEMENT

Topic summary

✨ The discussion centers on modifying the Power Meter KWS-302WF to switch its current measurement method from a shunt resistor to a transformer. The device uses an HT7017 measurement chip from HitrendTech, controlled by a PY32F002A MCU, which interfaces with a TM1622 display driver and a WiFi module identified as CBU (likely BK7231N). Communication between HT7017 and PY32F occurs at 4800 bps, while between CBU and PY32F it is at 115200 bps. Efforts include intercepting UART communications and backing up firmware to enable custom firmware flashing, particularly on the CBU WiFi module, using OpenBeken firmware and TuyaMCU protocols. Challenges include potential MCU protection and limited documentation on HT7017. The community provides resources such as firmware backups, dpID mappings, and autoexec.bat configuration examples for TuyaMCU integration, enabling relay control, voltage display, and parameter settings like overvoltage and overcurrent protection. Additional observations highlight incomplete frequency parsing in OpenBK firmware and the absence of recovery time settings after protection trips. A hardware fault involving the U3211 power supply chip is also discussed, with datasheets and sourcing advice provided.
Generated by the language model.

FAQ

TL;DR: The KWS-302WF uses 115200 bps between the CBU and MCU, and one expert summary says, "We’re always changing just firmware of the WiFi module". This FAQ is for modders who want OpenBeken on a KWS-302WF, need the right TuyaMCU mapping, and want to avoid chasing impossible hardware changes on the wrong chip. [#21226744]

Why it matters: The thread shows that OpenBeken control is practical on the Wi-Fi module, but core metering behavior stays locked behind the PY32F002A MCU.

Option Confirmed in thread Main limitation
Tuya Cloudcutter Firmware 2.1.6 has a profile 2.1.17 is described as patched
Direct serial flashing with BK7231GUIFlashTool Backup and flashing workflow discussed repeatedly You may need to disconnect the shared UART
Replacing shunt sensing with a current transformer Explored as a hardware goal MCU firmware, not CBU firmware, controls measurement logic [#21340504]

Key insight: Flashing the CBU/BK7231N can give you local control, telemetry, and usable dpID mapping, but it does not rewrite how the PY32F002A talks to the HT7017 or how current sensing is fundamentally implemented. [#21226735]

Quick Facts

  • The KWS-302WF uses 4800 bps on the HT7017↔PY32F002A link and 115200 bps on the CBU↔PY32F002A link, so you must sniff the correct UART for the job you are doing. [#21226741]
  • The extracted Tuya model maps key telemetry dpIDs as 101 voltage, 102 current, 103 power, 105 energy, 106 power factor, 107 frequency, and 108 temperature. [#21338483]
  • Writable protection ranges exposed in firmware include 100–220 V low-voltage, 130–290 V over-voltage, 0–100000 mA over-current, 0–22000 W over-power, and -20 to 150 °C over-temperature. [#21338456]
  • One captured CBU backup reports baud 115200, firmware 2.1.6, product version 0.1.7, and platform bk7231n, which is enough to build an OpenBeken TuyaMCU profile. [#21338456]

1. How can I flash OpenBeken onto a KWS-302WF power meter with a CBU/BK7231N module and set up the correct autoexec.bat for TuyaMCU?

You flash the CBU module, then configure OpenBeken for TuyaMCU at 115200 baud. 1. Make a full 2 MB backup first. 2. Disconnect or remove the CBU from the shared UART path before flashing. 3. Start tuyamcu, set tuyaMcu_setBaudRate 115200, then map dpIDs like 16, 101, 102, 103, 105, 106, 107, and 108 to channels in autoexec.bat. One working setup already controlled the relay and showed voltage correctly, which confirmed the basic mapping. [#21348761]

2. What is TuyaMCU communication, and how does it work between the CBU Wi-Fi module and the PY32F002A in the KWS-302WF?

TuyaMCU communication is the 115200 bps UART protocol between the Wi-Fi module and the main MCU. "TuyaMCU" is a serial control protocol that lets a Wi-Fi module exchange datapoints, status, and commands with a separate device MCU, while leaving sensor handling and local logic on that MCU. In this meter, the CBU sends heartbeat, product-info, network-state, and query commands, while the PY32F002A answers and reports dpIDs. A captured boot exchange showed commands 0x00, 0x01, 0x02, 0x03, 0x08, and 0x0A in active use. [#21614456]

3. What is dpID in Tuya devices, and how do I map KWS-302WF dpIDs like 101, 102, 103, and 118 to useful OpenBeken channels?

A dpID is the device-side identifier for one function or value. "dpID" is a Tuya datapoint identifier that names one readable or writable object, such as voltage, relay state, or reset action, and each dpID carries a defined type like bool, value, or enum. For this meter, map 101 to voltage_div10, 102 to current_div1000, 103 to power_div10, and 118 to a momentary reset-style control for clearing energy. The thread also confirmed 16 as the relay switch and 105 as total energy. [#21338483]

4. Why is changing the KWS-302WF from shunt-based current sensing to a current transformer so difficult when the PY32F002A controls the HT7017?

It is difficult because the CBU is not the metering brain. The PY32F002A handles the MCU side, receives data from the HT7017, drives the TM1622 display, and reports measurements over UART to the Wi-Fi module. Flashing OpenBeken on the CBU changes only the Wi-Fi side, not the measurement algorithm or calibration path. The thread’s clearest expert answer was that a shunt-to-transformer change would likely require changing PY32F002A firmware, which is the hard part. [#21226735]

5. Which UART baud rates does the KWS-302WF use for HT7017-to-PY32F002A and CBU-to-PY32F002A communication, and how do I capture them correctly?

The HT7017↔PY32F002A link runs at 4800 bps, and the CBU↔PY32F002A link runs at 115200 bps. Capture the 4800 bps bus if you want metering-chip traffic, and capture the 115200 bps bus if you want TuyaMCU datapoints and OpenBeken mapping. The thread author soldered into both paths and logged each separately, which is why both protocol layers became visible. If you sniff the wrong UART, your dpID analysis will fail even though the meter is working. [#21226741]

6. What is the HT7017 chip, and what role does it play inside the KWS-302WF energy meter?

The HT7017 is the dedicated metering chip in the KWS-302WF. "HT7017" is an energy-measurement IC that reads electrical quantities for the meter, while a separate MCU interprets the results, applies device logic, and forwards values to the display and Wi-Fi module. In this design, the HT7017 talks to the PY32F002A, not directly to the CBU. That separation explains why OpenBeken can expose readings but cannot easily redefine sensing hardware or MCU-side calculations. [#21226708]

7. How do I make a safe 2MB flash backup of a BK7231N/CBU module before replacing Tuya firmware with OpenBeken?

Make the backup before any flash attempt and keep the file untouched. The thread advice was explicit: create a 2 MB flash backup first, then read the TuyaMCU guide, then proceed with flashing. That backup matters because one user paused the whole project specifically because they were unsure whether they could return to stock firmware afterward. In practice, the safe path is backup first, sanitize second, and only then test OpenBeken or Cloudcutter. [#21226735]

8. Why does the same UART port on the CBU need to be disconnected from the MCU when flashing OpenBeken on a TuyaMCU device?

It needs disconnection because the flashing UART is also the live TuyaMCU UART. The thread warns that the same serial port used to program the CBU is shared with MCU communications during normal operation. If the PY32F002A remains connected, it can interfere with flashing traffic or hold the lines in ways that break the process. One practical workaround in this device is to desolder the 4-pin CBU module and flash it off-board. [#21226735]

9. How should I configure OpenBeken channels for KWS-302WF measurements like voltage, current, power, energy, power factor, frequency, and temperature?

Use TuyaMCU value channels with the scaling already proven in the thread. A working layout used 101→voltage_div10, 102→current_div1000, 103→power_div10, 105→EnergyTotal_kWh_div1000, 106→PowerFactor_div100, 107→ReadOnly for frequency, and 108→ReadOnly for external temperature. Relay control used dpID 16 as a bool toggle. Later users expanded the same pattern to include thresholds, countdown, and total-energy counters without changing the core measurement mapping. [#21617021]

10. What do KWS-302WF dpIDs 112, 117, 122, and 123 actually do, and which ones are still not fully understood?

dpID 122 is the schedule-triggered relay command, and dpID 123 is the device’s total energy counter. The thread later confirmed that dpID 123 resets only after holding the device’s + and - buttons for 5 seconds, which also restores MCU defaults. dpIDs 112 and 117 remain weakly understood: 112 is labeled “Poweroff Time,” 117 is labeled “Power Down Memory,” and both appeared to revert after CBU reboot during testing. Those two still lack a reliable, user-visible behavior model. [#21617102]

11. How can I emulate the PY32F002A MCU OTA protocol to capture or re-download KWS-302WF MCU firmware from Tuya or Smart Life cloud?

You can emulate the MCU side of TuyaMCU during boot and lie about the MCU version. 1. Sniff the CBU↔MCU boot exchange. 2. Reply to product-info with the same product key but a lower MCU version, such as changing 0.2.1 to 0.2.0. 3. Let the CBU request OTA with command 0x0A, then collect the 0x0B data blocks. One successful capture reported an MCU image size of 0x2F0C, which is 12,044 bytes. [#21614456]

12. Why does the frequency value from KWS-302WF dpID 107 appear without a decimal in OpenBeken logs, and is the last byte data or just a checksum?

The last byte in the shown TuyaMCU frame is a checksum, not the missing decimal digit. A later correction in the thread explained that a packet like 55 AA 03 07 0008 6B02000400000032 B4 contains data ending at 32, while B4 is the modulo-256 checksum. That means the “49.9 Hz from the last byte” interpretation was wrong. The decimal issue, if real, must come from another encoding path or later processing step, not from the checksum byte. [#21614509]

13. Tuya Cloudcutter vs direct serial flashing with BK7231GUIFlashTool on the KWS-302WF — which approach is better for firmware versions like 2.1.6 and patched 2.1.17?

Direct serial flashing is the safer path when firmware is patched. The thread says backup firmware 2.1.6 now has a Cloudcutter profile, while 2.1.17 is a known patched version. That makes Cloudcutter attractive only on compatible units, but unreliable on later patched ones. Serial backup and flashing with the BK7231 toolchain stays relevant across versions because it does not depend on an unpatched cloud exploit. If you are unsure which build you have, verify the version from backup first. [#21340504]

14. What recovery time options exist on the KWS-302WF after overvoltage or undervoltage protection trips the relay, and is there any dpID for configuring that delay?

No confirmed dpID for recovery delay was found in the thread. Users asked specifically for a post-trip recovery time after overvoltage or undervoltage events, but no matching datapoint was identified in the extracted dpID list. The later reverse-engineering work also treated recovery time as a missing feature that would likely require MCU firmware changes, not just OpenBeken configuration. So today’s practical answer is simple: the thread exposes threshold settings, but not a proven recovery-delay control. [#21365919]

15. What is the faulty power-supply chip marked U3211 in the KWS-302WF, where can I buy it, and how do I confirm it is the reason Wi-Fi and the display stopped working?

U3211 is part of the KWS-302WF power supply, and the thread identifies it as the failed part when both Wi-Fi and the display died. A later reply also says you can find it by searching for “uni u3211”, and another post attached a U3211 datasheet. The practical confirmation path is visual failure first, then power-rail diagnosis around that supply stage, because loss of both the display and Wi-Fi points to a common supply fault rather than two independent logic failures. [#21527175]
Generated by the language model.
ADVERTISEMENT