logo elektroda
logo elektroda
X
logo elektroda

[BK7231N] Teardown and flashing of Atorch GR2P-WS: DIN rail device with graphic screen

morgan_flint 12711 83

TL;DR

  • Teardown and OpenBeken flashing of the Atorch GR2P-WS DIN-rail power monitor with a graphic TFT screen and Tuya app support.
  • Inside, it uses a CB2S module with BK7231N, a CH573F Tuya MCU, BL0942 metering chip, PN8016 supply, and a bistable relay driver.
  • The power board measured 10.1V from the rectified AC and 3.23V on the downstream regulator, and the Tuya model exposed 44 DpIDs.
  • After isolating TX1/RX1 and flashing with bk7231flasher 1.1.6, the relay, network parameters, and programmed values worked in OpenBeken.
  • Mapping remains incomplete because some DpIDs act oddly or as read-only, and leakage-current hardware is not populated, though spare PCB space exists.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):
  • Hello to all!

    I recently bought this one for my collection, got it very cheap on sale, but the normal price is also good Link:
    Advertisement for GR2PW WiFi-enabled electricity meter.

    I found it interesting, compared to the other two similar devices I've been playing with (TOMPD63-WIFI and TOMPD63-LW because of the graphic screen. OTOH, it doesn't have residual current measurement (this version, at least, as we'll see later). Anyway, I don't think software-based RCBOs like those two should replace "conventional" (or this better kind of smart ones), because of safety reasons.

    Ok, let's start with a print of the description from the advertisement (in case the link gets broken), enclosed as the first attachment. It includes a good gallery of screenshots from the device itself and the Tuya app, so I'll skip my own related photos. Also, here's a link to the manual from the manufacturer's page (also attached, in case the link breaks).

    Now, the teardown gallery:
    View of the label on a rail-mounted measuring device. View of GR2PWS device with N-OUT and L-OUT labels. Photo of the front part of an electrical device with ports labeled N-IN and L-IN. Two energy meter modules with displays. Electronic board inside a device with visible wires and components. View of the inside of an electronic device with visible wires and components. Image of a part of an electronic device with visible internal components. Internal view of an electronic module with visible components and wiring. Close-up of the inside of an electronic device with colorful wires and capacitors visible. Close-up of a circuit board with buttons and various electronic components. HEZ 802 relay with 9V DC coil and marking 100A 250V AC against a manual. Close-up of an electronic module with visible components on a circuit board. Close-up of a GR2PW electronic device circuit board with three switches. Close-up of a circuit board with visible electronic components, including attached wires and a CH573F microcontroller. Circuit board with various electronic components. Electronic circuit board with mounted components and connected wires. View of the inside of a plastic enclosure with four mounted screw terminals. Rear view of the GR2PW device circuit board. Close-up of a circuit board with an attached ribbon cable labeled GMT154-01.

    As we can see, it uses the CB2S WiFi module (datasheet), which employs BK7231N chip, so it is possible to flash OpenBeken on it.

    As for the rest of main components, we can see them in the following image:
    Close-up of a circuit board with numbered components.

    "1" (CH573F) is the Tuya MCU.
    "2" (BL0942) is the AC metering chip
    "3" (PN8016) is an unisolated DC/DC switch mode converter, to get 9V (presumably, as this is the relay's coil voltage) from the rectified AC (measured 10.1V).
    "4" (marked HAHA A) is a switched mode regulator, to get (presumably) 3.3V (measured 3.23) from the previous 9V converter. This one feeds the Tuya MCU, the WiFi module, and the Power indicator LED. I couldn't find anything meaningful related to the markings but, from the peripheral components and connections could be similar to SY21031
    or RT6200
    "5" (marked 762A) is the bistable relay driver (Chinese datasheet)
    Other main components are the relay and the TFT graphic screen (labeled GMT154-01, similar to this one).

    Now, let's continue with the DpIDs identification. Following my tutorial, this is the result of "Query Things Data Model", once formatted and translated:
    Code: JSON
    Log in, to see the code


    That means a total of 44 DpID's!! Let's put them in a more legible format:
    Table of device parameters with description and specification.
    (also attached as pdf)

    After doing this with the original FW, we can now proceed to make a backup of it (attached) and then flash OBK. I tried first without isolating CB2S TX1 and RX1 signals from the main PCB, but got errors. I managed to isolate them without removing the module (just cleaning the solder bridge) and kept soldered Vcc and GND (CEN signal was already isolated). I have to say I had some problems trying to flash with bk7231flasher_1.3.3 (freezing at a certain point), so I finally did it with 1.1.6.

    With so many DpIDs, this is still "work in progress". I've found some of them don't seem to work. Others, supposedly read-write, behave as read-only, etc. But the autoexec.bat at this moment is the following:
    Code: Javascript
    Log in, to see the code


    As you can see in some of the comments, this one is derived from the TOMPD63-LW's autoexec, which works well with @Angel0fDeath web page for TOMPD63-WIFI, provisional adapted version. For this reason, and anticipating the possibility of adapting that web page also for this device, I've tried to keep the same channels for the same sensors.

    These are screenshots of OBK's main screen and Home Assistant page for this device:
    Screenshot of the OpenBK7231N interface showing various indicators and control buttons. Screenshot of control panel showing configuration and parameters of a device using TuyaMCU. Screenshot of the user interface of an energy monitoring system.

    Everything seems to work fine (except for "strange" DpIDs) and I am able to properly command the relay, read network parameters, program values, etc.

    And this is all for now. As there aren't enough channels to map all 44 DpIDs, I've been using channel 30 to test other DpIDs but still have to decide which of them will be chosen for the final mapping (as I said before, some of them don't work and others don't seem to have a real function). I'll keep you informed of the results!https://www.elektroda.com/rtvforum/posting.php?mode=editpost&p=21142057#

    EDIT (18/07/24): I´ve been making some progress with the device, and I think I'm almost at the point of considering the work finished ("almost" because you can always find something to add/improve when dealing with this things...). So, the changes are:

    1.- (almost) definitive autoexec.bat:
    Code: Javascript
    Log in, to see the code

    Also attached as GR2PWS_autoexec.bat_p.txt. I would recommend clearing all comments when copying to little FS to save space there.

    This is the aspect of OBK's main page:
    Screenshot of the OpenBK7231N interface for a device with BK7231N chipset Screenshot of a smart device user interface with channels and measurement values..
    (the labels in these screenshots do not correspond with the autoexec, as it's a debug version that includes channel numbers and DpIDs to facilitate debugging)

    And from Home Assistant's device page:
    Device information panel for BK7231N with various data sections.
    BTW, @p.kaczmarek2 , in this page all the diagnostics sensors appear like "unknown", while in OBK's main page they have values. What could be the cause?
    Also, I see there's no channel type for currency... Do you think it would be interesting to add a "generic currency" channel type? (I understand adding it for all the main currencies would mean too many types).

    2.- Custom web page, modified from @Angel0fDeath versions for the other devices cited before, attached as GR2PWS_rev3pr.html.txt. Heavily commented, so the original author can check/validate the mods, if he wants. I'd also clear all comments if loading it to little FS on the device, to avoid space problems.

    Here is the screenshot of this custom web page:
    OpenBK7231N user interface with device settings and data.

    One comment about this: The fault treatment in this device (DpID 132) is completely different than from the other two devices cited at the beginning, as in this one type is "enum", and in those it was "bitmap". The consequences are that in the other ones, several faults (overcurrent and overvoltage, for example) could be signaled at once, while in this device only one at a time, in the order of priority overvoltage-overcurrent-overpower-undervoltage-low prepaid energy-leakage" (if we have overcurrent and overvoltage, for example, it will show overvoltage and, once this disappears, then it'd show overcurrent, if still persisting).

    3.- I've also updated the table of DpIDs with more info:
    Device parameter table with DpID identifiers and technical details.
    Also attached as .pdf (deleted previous one). If someone would like to have the original spreadsheet (.xlsx), just ask.

    I´ve left a good amount of DpIDs out from the .bat (and .HTML), as there are not enough channels in OBK to accommodate all of them, nor they're really needed for normal remote operation. Also, although the necessary hardware is not implemented, for now, I've left the DpI'd related to the leakage current, as I've seen in the PCB that there's space left for the associated components, and I may give a try to install them and check if the TuyaMCU's firmware is prepared to read leakage current. To use the device as is, comment out or delete these lines in the .bat and .html.

    Also, after writing my original post, I found there were already two posts about other Atorch products, with similar characteristics, especially the first one, but with some differences in DpIDs and functionality: AT4P(WP/BW) Smart Energy monitor, and S1-B/W/T/H Smart Socket Energy Monitor. The autoexec's posted there used only a small subset of the full range.

    I see there have been no comments on this thread since I first posted it :-( ... Anyway, I hope it can be of help to others who buy this interesting device, and I'll PM @gulson to see if he can put it in the devices list (I don't know if I can do it by myself)

    Finally, many thanks to @p.kaczmarek2 again for this fantastic software that gives so many possibilities to experiment with these devices!!
    Attachments:
    • GR2PWS_DpIDs_2.pdf (446.39 KB) You must be logged in to download this attachment.
    • GR2PWS_rev3pr.html.txt (33.62 KB) You must be logged in to download this attachment.
    • GR2PWS_autoexec.bat_p.txt (6.05 KB) You must be logged in to download this attachment.
    • GR2PWS_Reset_BK7231N_QIO_2024-23-6-20-54-08.bin (2 MB) You must be logged in to download this attachment.
    • 20240621141828.pdf (15.33 MB) You must be logged in to download this attachment.
    • GR2PW AC50-320V 100A Smart Electricity Meter Tuya WiFi Din Rail Power Energy Meter Digital Display Monitor Voltage Curve Ammeter.pdf (39.94 MB) You must be logged in to download this attachment.

    Cool? Ranking DIY
    About Author
    morgan_flint
    Level 14  
    Offline 
    morgan_flint wrote 251 posts with rating 59, helped 4 times. Live in city Sevilla. Been with us since 2018 year.
  • ADVERTISEMENT
  • #2 21262901
    sawadee
    Level 1  
    Posts: 1
    >>21142057
    Wonder if I could get some help getting my Atorch GR2PWS units reprogrammed to remove Tuya calling home?
    I have connected to the wifi module that has the BK7231N chip. I downloaded the original firmware and saved it. I then flashed OpenBK7231N_QIO_1.17.745.bin which was the latest available.
    There was no OBK info to download. I used bk7231flasher_1.3.3 to flash OBK with my wifi info and added what MQTT info (and all else) that looked needed (really a guess). I reinstalled the module and powered up. All looked good as it booted up normally. but did not connect to my wifi.
    The Encryption key: 510fb093 a3cbeadc 5993a17e c7adeb03 is the standard one for this device but did not see where to put it in the firmware to upload.
    I do not have any experience with this device or with Tuya reprogramming. Really would appreciate some guidance to get me going.
    Plan is to use this with Home Assistant. I have over 80 devices running in Home Assistant, but this one is new to me.
    Thanks
  • #3 21264172
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    sawadee wrote:
    There was no OBK info to download

    AFAIK, this is normal with Tuya MCU devices, as this one.

    sawadee wrote:
    I used bk7231flasher_1.3.3 to flash OBK with my wifi info and added what MQTT info (and all else) that looked needed (really a guess). I reinstalled the module and powered up. All looked good as it booted up normally. but did not connect to my wifi.

    Did you include this information with "Change OBK settings for flash write"? I usually do it by accessing the device's access point, which appears after flashing without this info, and setting WiFi there, but it should be the same. You can try reflashing without this info or resetting the device by powering it on and off 5 times (without letting boot to complete, about 1 second or so), and then connect to the device's access point, access 192.168.4.1 and set your wifi name and password there.

    If you decide to flash it again with bk7231flasher, you don't really need to desolder the module, I did it just by soldering wires for RX, TX, 3V3 and GND, of course with the device disconnected from the mains voltage, powering the module (and the MCU, but this didn't was a problem) from the USB to serial adapter. Sometimes It's also necessary to disconnect the trace from the MCU's TX to the module's RX, to avoid the MCU interfering with the flashing process.

    After that and reboot, check that you can access the device's web interface in the IP given to it by your router, and set up there all the remaining info: MQTT, Home Assistant, etc. Then, with "launch web application", go to "Filesystem"->"Create file" and create autoexec.bat, copy and paste there the one in my previous post and reboot the device. After that, go to http://192.168.1.xxx/ha_cfg (or "config"->"Home Assistant Configuration") and hit "Start Home Assistant discovery" (configure MQTT before there, if you hadn't done it before). Then, it should show up in Home Assistant under MQTT devices

    sawadee wrote:
    The Encryption key: 510fb093 a3cbeadc 5993a17e c7adeb03 is the standard one for this device but did not see where to put it in the firmware to upload

    I don't remember having needed to use that
  • #4 21266881
    sawadee2u
    Level 2  
    Posts: 2
    >>21264172 Hello Morgan, First, thank for the reply and help. I am still having issues. If I flash the .bin file you have attached, GR2PWS_Reset_BK7231N_QIO_2024-23-6-20-54-08, the device does not connect to my wifi. Yes. I have used Change OBK windows to input my wifi and mqtt info. Then flash this to the device. I also have restarted the program and downloaded the OBK info to check that it is indeed on the device. I flashed this three times after a new download ever time, just to be sure. What is interesting is that with your .bin file loaded I can get wifi working only by connecting the unit to the ATORCH Smart Energy Meter App on my iphone. It shows up in my router (Ubiquity UDM-Pro) as a Tuya device with the name of wlan0. So, I am confused that it will only connects to Tuya.
    Also, I have flashed firmware "OpenBK7231N_QIO_1.17.747.bin (now 748)" from the BK7231 easy UART flasher and the device quickly connected directly to my wifi and I was able to connect to it and see the various programs on it. I also see that it connects and sends mqtt info. But this flash seems to be set up for different lighting devices.
    So, what am I missing or screwing up?
    Thanks,
  • #5 21269095
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21266881
    sawadee2u wrote:
    If I flash the .bin file you have attached, GR2PWS_Reset_BK7231N_QIO_2024-23-6-20-54-08, the device does not connect to my wifi

    That bin is a backup of the original FW, posted it in case someone has problems and wants to go back to Tuya, or for experts here to analyze it for other features. To get the device going with OpenBeken, you should flash the latest OpenBeken .bin available for BK7231N (OpenBK7231N_QIO_1.17.750.bin at the time of writing) but you can download it from the BK7231Flasher directly, as you did.

    sawadee2u wrote:
    What is interesting is that with your .bin file loaded I can get wifi working only by connecting the unit to the ATORCH Smart Energy Meter App on my iphone.

    That's logical, as it's a backup of the original FW

    sawadee2u wrote:
    Also, I have flashed firmware "OpenBK7231N_QIO_1.17.747.bin (now 748)" from the BK7231 easy UART flasher and the device quickly connected directly to my wifi and I was able to connect to it and see the various programs on it. I also see that it connects and sends mqtt info. But this flash seems to be set up for different lighting devices.
    So, what am I missing or screwing up?

    sawadee2u wrote:
    What is interesting is that with your .bin file loaded I can get wifi working only by connecting the unit to the ATORCH Smart Energy Meter App on my iphone.

    After flashing OpenBeken, you need to create "autoexec.bat" with the contents of the first post, as I explained in my previous one, to adapt OpenBeken to this device
  • #6 21286695
    sawadee2u
    Level 2  
    Posts: 2
    >>21269095
    Ok, have my head on straight now, mostly...
    Have programmed four units and all report the following in home assistant:
    sensor.obk_87fb00029_current
    sensor.obk_87fb00029_voltage
    sensor.obk_87fb00029_power
    sensor.obk_87fb00029_total_energy
    sensor.obk_87fb00029_frequency_hz
    sensor.obk_87fb00029_power_factor
    sensor.obk_87fb00029_temperature (32.59 in "C" - would like this in "F") (***) see below
    sensor.obk_87fb00029_remaining_prepaid_energy
    sensor.obk_87fb00029_total_electricity_cost
    sensor.obk_87fb00029_alarms (0 currently)

    The following are listed in Home Assistant but reporting UNKNOWN:
    sensor.obk_87fb00029_build
    sensor.obk_87fb00029_ip
    sensor.obk_87fb00029_rssi
    sensor.obk_87fb00029_ssid
    sensor.obk_87fb00029_temperature
    sensor.obk_87fb00029_uptime

    (***)
    CPU Temperature was not reporting at all so I followed your format in the Autoexec.bat and got it reporting:
    // Total cpu Temperature - id 135 "ele" -> Ch 23 (ro)
    linkTuyaMCUOutputToChannel 135 val 23
    setChannelType 23 Temperature_div100
    setChannelLabel 23 "CPU Temperature"

    Would like to see RSSI and the other payloads working but just don't know enough to do so.
    RSSI, IP, SSID and others are reported as UNKNOWN on a new unit prior to entering the autoexec.bat. While the data that is reported after the autoexec.bat is entered do not show at all prior to doing so. So assume they require a different method that I don't understand.

    So that is as far as I have been able to progress to date. If you could point me to anything I have missed, I would appreciate it.
    Thanks
  • ADVERTISEMENT
  • #7 21286845
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    I'm having the same problem with OBK "internal" sensors (see the first attached image), although the values show up on OBK's main web page (second image). This also happens to me with some other devices, but it works well on another one. Maybe @p.kaczmarek2 can tell us what we're doing wrong.

    Screenshot showing a device diagnostic panel with values labeled as Desconocido. Display showing information about internal temperature sensors, Wi-Fi signal strength, and reboot reason.

    This is a device where that's working well:
    Screenshot showing device sensor and diagnostic information with data on battery level, humidity, temperature, and Wi-Fi network.
  • #8 21295352
    divadiow
    Level 38  
    Posts: 4962
    Help: 435
    Rate: 886
    here's the MCU binary downloaded when accepting the 1.0.3 update offered by the Tuya app for this device
    Device software update screen with information about the new version 1.0.3.
    Attachments:
    • Atorch_GR2P-WS_MCU_1.0.3.bin (262.89 KB) You must be logged in to download this attachment.
  • #9 21295745
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21295352
    Thanks!
    How can you install it in the MCU if you have flashed OBK?
  • #10 21295750
    divadiow
    Level 38  
    Posts: 4962
    Help: 435
    Rate: 886
    That I do not know. Not yet anyway.
  • #12 21301854
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21296793 Thanks for adding it, I don't have very clear the procedure to do that

    Added after 2 [minutes]:

    >>21295750 I Imagine I can flash the Tuya FW back from the backup, update the MCU FW from there and then go back to OBK, but it'd be good to have a simpler way, preferably OTA
  • ADVERTISEMENT
  • #13 21302093
    divadiow
    Level 38  
    Posts: 4962
    Help: 435
    Rate: 886
    morgan_flint wrote:
    I Imagine I can flash the Tuya FW back from the backup, update the MCU FW from there and then go back to OBK

    indeed. who knows if the changes in these MCU updates warrant the effort though.
  • #14 21302809
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21301854
    morgan_flint wrote:
    it'd be good to have a simpler way, preferably OTA

    I imagine it would be necessary to implement this in OBK to be able to update MCU FW via OTA, but probably, it's not worth the effort, I think MCU FW updates are not so common for these devices.


    BTW, I just checked in mine and FW version seems to be 1.0.4:
    Display of the ATORCH GR2PWS device with version 1.0.4 settings menu.
  • #15 21373484
    agaletski
    Level 2  
    Posts: 2
    Hi.
    I have two of those devices. I'm happy to find this discussion and people were able to reflash and manage this device directly from HA.
    I want to reflash my device too and have question about MCU FW 1.0.4 I saw my device was also updated to 1.0.4 from Tuya. Is it causes any issues working with OBK flashed module? Is it possible to reflash MCU back to 1.0.3? How to do this ?

    Answer to my question above -^. )
    Flashed my device (MCU FW 1.0.4) with latest OpenBK7231N 1.17.822, and configured (using provided autoexec.bat, without comments) as described above.
    Everything works better than expected. ) Someone asked about buttons and screen function after reflash.
    It does work without changes as it is managed by tuya MCU which remains unchanged.
    Only communication module is reflashed to OBK firmware.

    Thank you guys!
    This is my second device which have been cut from tuya cloud.
  • #16 21375420
    agaletski
    Level 2  
    Posts: 2
    Hello.
    I have found how to activate the Diagnostic data (actual RSSI, IP, SSID and others ) are reported to HA via MOTT topics. (mentioned in earlier messages)
    We can just enable those states report in Flags section of OBK config web page.
    "flags 0 " directive in autoexec.bat clears all flags on boot, so I believe it is better to remove it.   

    Screenshot of settings showing MQTT flags in the GR2PWS_OBK7231N_0AFC device configuration.
  • #17 21424563
    misharexsezan
    Level 2  
    Posts: 2
    Super Cool! Just installed today and everything is working just fine!!!
  • #18 21424708
    crg1darkspr1te
    Level 9  
    Posts: 22
    Help: 2
    Rate: 12
    For those that are interested in the update mechanism for MCU side it is document in code here
    https://github.com/tuya/tuya-wifi-mcu-sdk-ard...3888d720ac910b0c181d766986/src/TuyaDefs.h#L81
    and here
    https://github.com/tuya/tuya-wifi-mcu-sdk-ard...8d720ac910b0c181d766986/src/TuyaWifi.cpp#L274
    First is update command then is transfer. This is WIFI to MCU comms and not APP to WIFI comms
    I am currently waiting for a WCh programmer as i have 2 damaged AT4P units on my desk that still have working mcu/wifi/lcd but the relay+SMPS is damaged. Anyway, when i have the programmer i will be able to work on the MCU OTA update side, I already have a GD32E230 based device which i was able to dump the f/w from (bootloader+app) and once i have the CH573f dump i will have two chips in which to test my update code (or others)

    darkspr1te
  • ADVERTISEMENT
  • #20 21425111
    crg1darkspr1te
    Level 9  
    Posts: 22
    Help: 2
    Rate: 12
    >>21424743
    AT4P 1.0.4 , AT4PW 1.0.7 ,AT4PBW 1.0.6 are what i have on hand working devices but not dumped MCU wise, i do have the BK side though

    darkspr1te

    Added after 4 [minutes]:

    >>21425111
    Oh and i compared the tuya-t2-sdk code to the 1.0.9 code for the gd32e230 device and they were almost bang on so you can assume the arduino sdk/t3 sdk's for wifi are the same code.
  • #21 21451899
    misharexsezan
    Level 2  
    Posts: 2
    Hello everyone, this is a modified autoexec.bat file with SSDP and Timer added. If anyone needs explanation, let me know. I'll attach comments
    clearIO
    flags 0
    SetFlag 43 1
    SetFlag 46 1
    SetFlag 39 0
    SetFlag 25 1
    startDriver TuyaMCU
    tuyaMcu_defWiFiState 4
    startDriver NTP
    ntp_setServer 150.214.94.5
    ntp_timeZoneOfs 6
    startDriver SSDP
    startDriver Wemo
    linkTuyaMCUOutputToChannel 1 bool 1
    setChannelType 1 toggle
    setChannelLabel 1 "Relay"
    linkTuyaMCUOutputToChannel 139 bool 2
    setChannelType 2 toggle
    setChannelLabel 2 "Prepayment"
    linkTuyaMCUOutputToChannel 126 bool 3
    setChannelType 3 toggle
    setChannelLabel 3 "Real Time"
    linkTuyaMCUOutputToChannel 120 bool 4
    setChannelType 4 Toggle
    setChannelLabel 4 "Over-limit ctrl"
    linkTuyaMCUOutputToChannel 20 val 5
    setChannelType 5 Voltage_div100
    linkTuyaMCUOutputToChannel 18 val 6
    setChannelType 6 Current_div1000
    linkTuyaMCUOutputToChannel 19 val 7
    setChannelType 7 Power_div100
    linkTuyaMCUOutputToChannel 134 val 8
    setChannelType 8 PowerFactor_div100
    linkTuyaMCUOutputToChannel 133 val 9
    setChannelType 9 Frequency_div100
    linkTuyaMCUOutputToChannel 123 val 10
    setChannelType 10 EnergyTotal_kWh_div1000
    linkTuyaMCUOutputToChannel 102 val 11
    setChannelType 11 ReadOnly
    setChannelLabel 11 "Total electricity cost"
    linkTuyaMCUOutputToChannel 140 val 12
    setChannelType 12 EnergyTotal_kWh_div100
    setChannelLabel 12 "Remaining Prepaid Energy"
    linkTuyaMCUOutputToChannel 132 val 13
    setChannelType 13 Readonly
    setChannelLabel 13 "<br><br>Alarms"
    linkTuyaMCUOutputToChannel 104 val 14
    setChannelType 14 TextField
    setChannelLabel 14 "Overvoltage limit"
    linkTuyaMCUOutputToChannel 105 val 15
    setChannelType 15 TextField
    setChannelLabel 15 "Overcurrent limit"
    linkTuyaMCUOutputToChannel 106 val 16
    setChannelType 16 TextField
    setChannelLabel 16 "Power limit"
    linkTuyaMCUOutputToChannel 119 val 17
    setChannelType 17 TextField
    setChannelLabel 17 "Undervoltage limit"
    linkTuyaMCUOutputToChannel 143 val 18
    setChannelType 18 TextField
    setChannelLabel 18 "Low prepaid energy alarm"
    linkTuyaMCUOutputToChannel 137 val 19
    setChannelType 19 TextField
    setChannelLabel 19 "Overvolt recov. delay"
    linkTuyaMCUOutputToChannel 125 val 20
    setChannelType 20 TextField
    setChannelLabel 20 "Refresh interval"
    addRepeatingEvent 5 1 setChannel 20 1
    linkTuyaMCUOutputToChannel 101 val 21
    setChannelType 21 TextField
    setChannelLabel 21 "Electricity price"
    linkTuyaMCUOutputToChannel 142 val 22
    setChannelType 22 TextField
    setChannelLabel 22 "Recharge Prepaid Energy[kWh*100],1kWh=100"
    startDriver httpButtons
    linkTuyaMCUOutputToChannel 141 bool 23
    setButtonEnabled 0 1
    setButtonLabel 0 "Clr Prepaid Energy"
    setButtonCommand 0 "setChannel 23 1"
    linkTuyaMCUOutputToChannel 113 bool 24
    setButtonEnabled 1 1
    setButtonLabel 1 "Clear acc. data"
    setButtonCommand 1 "setChannel 24 1"
    setChannelLabel 32  "<b style='color:orange'>Time left</b>"
    setChannelType 32 TimerSeconds
    addChangeHandler Channel1 == 0 setChannel 32 0
    setButtonEnabled 2 1
    setButtonLabel 2 "Timer 1H"
    setButtonCommand 2 "setChannel 32 3600"
    setButtonEnabled 3 1
    setButtonLabel 3 "Timer 30M"
    setButtonCommand 3 "setChannel 32 1800"
    setButtonColor 3 "green"
    setButtonEnabled 4 1
    setButtonLabel 4 "Timer 30S"
    setButtonCommand 4 "setChannel 32 30"
    setButtonColor 4 "green"
    setButtonEnabled 5 1
    setButtonLabel 5 "Timer +30S"
    setButtonCommand 5 "addChannel 32 30"
    setButtonColor 5 "#f89705"
    setButtonEnabled 6 1
    setButtonLabel 6 "Stop Timer"
    setButtonCommand 6 "setChannel 32 0"
    setButtonColor 6 "red"
    setChannelLabel 33  "<b style='color:orange'>Set timer[s]</b>"
    setChannelType 33 TextField
    addEventHandler OnChannelChange 33 if $CH32!=$CH33 then setChannel 32 $CH33
    addEventHandler OnChannelChange 32 if $CH32!=$CH33 then setChannel 33 $CH32
    alias addTimer backlog POWER ON;addRepeatingEventID 1 -1 9 addChannel 32 -1 0 999999;setChannel 34 1
    addChangeHandler Channel32 == 0 if $CH34==1 then backlog POWER OFF;cancelRepeatingEvent 9;setChannel 34 0
    addChangeHandler Channel32 > 0 if $CH34==0 then addTimer
    addRepeatingEvent 6 1 tuyaMcu_sendQueryState
    loglevel 0
  • #22 21510715
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    Adding pictures of the internals of the relay:

    Electromagnet with visible copper coil on a blue background.
    Interior of an electrical switch with visible metal components on a blue surface.
    Close-up of a solenoid coil with copper wire in a plastic casing.

    These pictures are for user @rufus4, who is asking about this kind of relay in another thread but as the images belong to the device of this thread, I think it's better to post them here.

    EDIT: the red, blue, and green braided cables at the top of the relay are connected to the current measuring shunt (yellow and blue), and to the input voltage (red), as the shunt is integrated on one of the relay's terminals. You can see it better in the 9th photo of the first post of this thread.

    EDIT2: Adding the datasheet for the relay's driver IC, already linked in the first post, but Google-translated into English:
    Attachments:
    • 2011252110_Shanghai-Mingda-Microelectronics-MD7620A_C920529 (Eng).pdf (887.34 KB) You must be logged in to download this attachment.
  • #23 21563984
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21424743
    Hello again to all.

    I recently purchased another GR2PWS, and I've found that it has newer versions for both the main module and the MCU, as well as the previous one (which I had flashed with OBK).

    So, I decided to reflash the first one with the backup I had saved before flashing OBK to see if I could update its MCU firmware with the newer version from the Tuya App.

    But, to my surprise, when I get to the corresponding screen in the App, it shows "No updates available"...

    The next screenshots belong to that screen for the older and newer ones:

    A screenshot from an IoT device management app showing no firmware updates available for the main and MCU modules. App screen showing no updates available for the device, with Main Module v3.1.17 and MCU v1.0.6 versions.

    @divadiow or @crg1darkspr1te:
    Do you know if there's a way to force the update from the Tuya App, or another method to do it?

    I also see in your post and repository that there's already a 1.0.9 version for AT4P, very similar to GR2WS. I imagine newer GR2P should come with this one (or a newer one)

    With that in mind, and also wanting to inspect the HW differences with GR2PWS, I have ordered (and am waiting for its arrival) a GR2PWSL (with external leakage current transformer). In the advertisement, some pictures of the device's screen are different from my devices, or even don't exist in them, but are similar to those in AT4P advertisements. So I'm also curious to check the FW version in this new acquisition. In one of the ad's screenshots it says "BengFang Sys Settings 2.0.1":
    BenFang Sys system settings screen with setting descriptions and example menu screens in English and Chinese.

    EDIT: Regarding the differences between GR2PWS and GR2PWSL, I suspect they are limited to the missing components shown in the following photos:
    Close-up of a GR2PWS circuit board with missing components highlighted, visible buttons, and wire labels.
    Close-up of a GR2PW circuit board with three red-labeled points marked 1, 2, 3 on the edge.

    The toroidal residual current transformer would be connected to pads 1 and 2. Pad 1 is connected to GND, and the missing component in 3 (probably a shunt resistor) is connected between 1 and 2. The missing components circled in the other photo are probably a capacitor to GND and a resistor between pad 2 and pin 28 of the MCU, which would be configured as an analog input for residual current measurement:
    Hand-drawn simple electrical diagram showing two pads connected via a shunt resistor, capacitor, and resistor to MCU pin 21.

    My doubt is how this arrangement gets rid of the negative half-wave. Maybe there's a diode instead of a capacitor, but I'll check that when my recent purchase arrives and post here
  • #24 21565241
    divadiow
    Level 38  
    Posts: 4962
    Help: 435
    Rate: 886
    morgan_flint wrote:
    Do you know if there's a way to force the update from the Tuya App, or another method to do it?

    I have never explored trying. There must be a reason it's not offering an update though? Maybe your new variation has a different schema ID and the different OTA MCU update offering is tied to that.

    If you really wanted to you could work out how to dump the entire flash of the CH573F from the 1.06 device and flash to the other. I wonder. I do have CH573F somewhere.

    Do you have a main fw dump of your newer device?
  • #25 21565668
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21565241
    I haven't still opened it, but will do and compare hardwares.
    I'll also make a backup of the WiFi module's FW, but I don't know how to dump the flash of the MCU. I have tools for Atmel (USBASP) and STM32 (STLink), and also an EEPROM programmer based upon CH341; I don't kow if any of these is aplicable to CH573 MCU...

    Added after 7 [hours] 15 [minutes]:

    divadiow wrote:
    Maybe your new variation has a different schema ID and the different OTA MCU update offering is tied to that.

    Here are both devices, new and old, side by side; they seem to be exactly the same:
    Two identical electronic modules, one above the other, showing PCBs, buttons, and colored wires.

    I've traced the connections of the 5 pin port at the upper side of the board. From left to right:
    1- Vcc, connected to the input of the 3.3V regulator, which is the output of the PN8016 DC/DC switch mode converter, to get 9V for the relay (as I said in the first post)
    2- GND
    3- CH573F pin 17 (Boot?) Also connected to one of the copper pads that can be seen below it. The other one is connected to pin 16
    4- CH573F pin 13 (UD-)
    5- CH573F pin 12 (UD+)

    According to the schematics in this page, pins 12, 13, 16, and 17 of CH573F are used for USB programming, so I think it would be possible to read the FW using the tools here.

    Finally, I've also made a backup of the CB2S module's FW (attached)
    Attachments:
    • readResult_BK7231N_QIO_GR2PWS_2_reset_NoVcc_2025-31-5-19-26-07.bin (2 MB) You must be logged in to download this attachment.
  • #26 21566482
    divadiow
    Level 38  
    Posts: 4962
    Help: 435
    Rate: 886
    thanks for the backup. it seems to be the newer Tuya key vault type where the product id isn't easily retrievable like before. I cannot get the crucial bit of info to determine how its schema compares to the older model. I don't suppose you have the full boot log with what the real MCU sends as its ID, assuming that's visible in the log?
  • #27 21566579
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21566482 I can make a log but, if for ID you mean Tuya's "virtual ID", and you only need that I have it from the screenshot of the Tuya App and also from the Tuya Developer's web, as I repeated the procedure in [url=https://www.elektroda.com/rtvforum/topic4021129.html]my tutorial/url] to check if the new device had different dpIDs (it doesn't).

    Is it harmless to share it here, or is it better to PM it to you?
  • #28 21566588
    divadiow
    Level 38  
    Posts: 4962
    Help: 435
    Rate: 886
    ah, well if you've already seen it in Tuya dev then the pid will be in there

    Screenshot from Tuya IoT Platform showing device details, with the product_id highlighted in yellow.

    unless it's all changed and it's not done like that with new Tuya

    the device schema can also be looked up here

    Screenshot of Tuya IoT Platform API interface with Query Things Data Model highlighted and response showing modelId field with value exvou0 highlighted.
  • #29 21566612
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21566588
    It seems like the same ID:

    Screenshot of the API Explorer in Tuya IoT Platform showing a device query request and detailed JSON result for a smart energy meter.
    Screenshot of Tuya IoT Platform API Explorer panel showing device model query details and JSON response with highlighted model exvou08.

    Do you want me to record the boot logs for anything else?
  • #30 21566618
    divadiow
    Level 38  
    Posts: 4962
    Help: 435
    Rate: 886
    ah ok. interesting. dunno then really. maybe something new in the main 3.1.17 fw that means MCU also requires different firmware? I'm going to interrogate my CH573 soon in Atorch S1
📢 Listen (AI):

Topic summary

✨ The discussion centers on the teardown, firmware flashing, and integration of the Atorch GR2P-WS DIN rail energy meter featuring a graphic screen and BK7231N WiFi module. Users share experiences flashing OpenBK7231N firmware to replace the original Tuya firmware, aiming to eliminate cloud dependencies and enable local control via Home Assistant. Challenges include configuring WiFi credentials, MQTT setup, and linking Tuya MCU outputs to OBK channels through customized autoexec.bat scripts. The MCU firmware (CH573F) versions (1.0.3, 1.0.4, 1.0.9) and update mechanisms are discussed, with attempts to dump and reflash MCU firmware via USB ISP and UART ISP modes proving difficult due to bootloader restrictions and hardware specifics. Newer GR2PWSL versions with external current transformers and different MCU firmware are noted, with similar device schema IDs but differing update availability in the Tuya app. Diagnostic data reporting (RSSI, IP, SSID) to Home Assistant via MQTT is enabled by adjusting OBK flags. The relay internals and driver IC datasheet are shared. Community members contribute modified autoexec.bat configurations adding SSDP, NTP, and Wemo drivers. The discussion also covers the translation of Chinese JSON strings in device models to English for better integration. Overall, the thread provides detailed technical insights into hardware teardown, firmware flashing, MCU communication, and Home Assistant integration of Atorch GR2P-WS devices using BK7231N and CH573F chips.
Generated by the language model.

FAQ

TL;DR: With 44 DpIDs and “flash OpenBeken on it,” this thread shows GR2P-WS owners how to replace Tuya cloud with OpenBeken, map TuyaMCU datapoints, and restore Wi‑Fi, MQTT, and Home Assistant reporting on both CB2S/BK7231N and newer T1-2S-NL variants. [#21142057]

Why it matters: This FAQ turns a long reverse-engineering thread into a fast, quotable setup guide for getting Atorch GR2P-WS energy breakers working locally.

Variant Wi‑Fi module / chip TuyaMCU baud rate reported Key flashing note
GR2P-WS, early CB2S / BK7231N 9600 Needed RX/TX isolation; bk7231flasher 1.1.6 worked reliably
GR2PWSL Different main MCU + same TuyaMCU-style mapping Not highlighted as changed Added leakage CT hardware and newer schema details
GR2P-WS, late T1-2S-NL / BK7238-class handling 115200 Needed OpenBeken BK7238 path and corrected autoexec

Key insight: GR2P-WS is not a simple standalone smart relay. It is a TuyaMCU design, so flashing OpenBeken only replaces the Wi‑Fi module; the device works correctly only after you map the right DpIDs and baud rate in autoexec.bat.

Quick Facts

  • The early GR2P-WS schema exposed 44 DpIDs, including relay control, voltage, current, power, total energy, prepaid functions, alarms, frequency, power factor, and display settings. [#21142057]
  • On the early CB2S board, measured rails were about 10.1 V from the PN8016 supply and 3.23 V for logic, with the relay coil presumed to be 9 V. [#21142057]
  • The GR2PWSL leakage version adds an external residual-current transformer with a reported 1:1000 ratio plus roughly 510 Ω shunt and ~500 Ω series parts for leakage sensing. [#21572984]
  • A late T1-2S-NL GR2P-WS worked only after switching TuyaMCU speed to 115200 baud; using DpID 19 for power fixed the broken power reading. [#21787724]

How do I flash OpenBeken on the Atorch GR2P-WS with a CB2S BK7231N module and get it working with the TuyaMCU autoexec.bat?

Flash the CB2S module with OpenBK7231N, then add the TuyaMCU mapping file. 1. Disconnect the device from mains, wire 3V3, GND, RX, and TX, and isolate CB2S RX1/TX1 if flashing fails. 2. Flash OpenBeken, boot it, join its AP or web UI, and configure Wi‑Fi and MQTT. 3. Create autoexec.bat in LittleFS, paste the GR2P-WS TuyaMCU mapping, reboot, and run Home Assistant discovery. The original working map used startDriver TuyaMCU, tuyaMcu_setBaudRate 9600, and linked relay, voltage, current, power, and energy channels. [#21142057]

Why does the Atorch GR2P-WS sometimes fail to flash with bk7231flasher 1.3.3, and why did version 1.1.6 work better for some users?

Some users saw bk7231flasher 1.3.3 freeze during flashing, while 1.1.6 completed successfully on the same hardware. The failure appeared when CB2S TX1 and RX1 still interacted with the main PCB, so cleaning the solder bridge and isolating those lines helped. One user explicitly reported errors without isolation, then a successful flash after isolating signals and switching from 1.3.3 to 1.1.6. That makes the issue a tool-and-bus-interference problem, not a GR2P-WS lockout. [#21142057]

What is a TuyaMCU device, and how is it different from a standalone OpenBeken device?

A TuyaMCU device uses one MCU for the product logic and a separate Wi‑Fi module for networking, so OpenBeken does not control the hardware directly. "TuyaMCU" is a controller architecture that keeps the relay, display, metering, and buttons on a dedicated MCU, while the BK Wi‑Fi module only exchanges datapoints over UART. On GR2P-WS, the early board used a CH573F as the Tuya MCU and a CB2S BK7231N module for Wi‑Fi. That is why flashing OpenBeken alone shows no useful values until you map DpIDs in autoexec.bat. [#21142057]

What are DpIDs in TuyaMCU devices, and how do I extract the GR2P-WS schema or Things Data Model from Tuya Developer?

DpIDs are Tuya datapoint identifiers that represent functions like switch state, power, voltage, or alarms. "DpIDs" are protocol fields that define each readable or writable function, including type, scale, unit, and access mode. For GR2P-WS, the thread extracted the Things Data Model from Tuya Developer using “Query Things Data Model,” then reformatted it into a readable table. The early model exposed 44 DpIDs, while a later T1-2S-NL dump still matched modelId e1kylf6c, confirming the same basic schema even on newer hardware. [#21784596]

Why does the original GR2PWS_Reset_BK7231N backup reconnect to Tuya instead of behaving like OpenBeken firmware?

Because that file is a backup of the stock Tuya firmware, not OpenBeken. One user restored GR2PWS_Reset_BK7231N_QIO_2024-23-6-20-54-08.bin and saw the device appear in the router as a Tuya client again, which matched the expected behavior. The thread author clarified that the backup exists for rollback and analysis only. To run locally, you must flash a real OpenBK7231N build and then load the GR2P-WS autoexec.bat. [#21269095]

How can I make an Atorch GR2P-WS show up correctly in Home Assistant over MQTT, including sensors like current, voltage, power, and total energy?

Configure MQTT in OpenBeken, add the correct TuyaMCU mapping, then start Home Assistant discovery. The working mapping linked DpID 18 to current, 19 to power, 20 to voltage, and 123 to total energy. After reboot, users were told to open the device web UI, create autoexec.bat, paste the mapping, then use the Home Assistant Configuration page and press “Start Home Assistant discovery.” That produced MQTT entities such as current, voltage, power, total energy, frequency, and power factor. [#21264172]

Why do OBK internal diagnostic entities like RSSI, IP, SSID, uptime, and build show as unknown in Home Assistant even when values appear on the OpenBeken web page?

They show as unknown when the relevant OpenBeken state-report flags are not enabled for MQTT reporting. A user later found that RSSI, IP, SSID, and similar diagnostics started reporting after enabling those states in the Flags section. The same post noted that flags 0 in autoexec.bat clears all flags at boot, so removing that line is the safer fix if you want diagnostics in Home Assistant. The web page can still show local values even when MQTT entities remain unknown. [#21375420]

What is the difference between the Atorch GR2PWS and GR2PWSL hardware, especially around leakage current measurement and the external current transformer?

GR2PWSL adds real leakage-current hardware, while the older GR2PWS board leaves that section mostly unpopulated. The GR2PWSL version included an external residual-current transformer with a measured 1:1000 ratio, plus a roughly 510 Ω shunt resistor, a series resistor near 500 Ω, and a capacitor to ground. Earlier GR2PWS boards exposed DpIDs for leakage functions, but the thread marked that hardware as “not implemented.” That means GR2PWSL can report and trip on leakage, while the plain GR2PWS usually cannot without board modification. [#21572984]

How does the GR2P-WS compare with the TOMPD63-WIFI, TOMPD63-LW, and Atorch AT4P family for OpenBeken flashing and TuyaMCU mapping?

GR2P-WS is broadly similar to those TuyaMCU breakers, but its screen, DpID mix, and fault handling differ. The author reused parts of the TOMPD63-LW mapping because channel layouts for current, voltage, power, and energy were similar. Compared with TOMPD63-WIFI and TOMPD63-LW, GR2P-WS had a graphical TFT screen and no implemented leakage hardware on early boards. The thread also linked Atorch AT4P-family posts, noting they share related functionality but only use subsets of the full DpID range. [#21142057]

What is the best way to recover Wi-Fi access on a freshly flashed GR2P-WS if it does not join the network after OpenBK7231N is installed?

Reset the device into AP mode and configure Wi‑Fi through the OpenBeken web interface. The thread recommends reflashing without embedded credentials or power-cycling the device five times, without letting each boot fully complete, to trigger the AP. Then connect to 192.168.4.1, enter the SSID and password, and reboot. This worked better than guessing Wi‑Fi and MQTT fields in the flasher. If needed, reflash again with only OpenBeken and add network settings later from the UI. [#21264172]

How do I map the GR2P-WS power reading correctly in autoexec.bat, and why did using DpID 10 instead of DpID 19 break the power sensor?

Map power to DpID 19, not DpID 10. A late T1-2S-NL user posted an autoexec.bat that incorrectly linked linkTuyaMCUOutputToChannel 10 val 6, which broke the power sensor. The fix was to restore the original mapping: linkTuyaMCUOutputToChannel 19 val 6, then setChannelType 6 Power_div100. After that change, the power value started working. This matches the earlier CB2S schema, where DpID 19 is cur_power and DpID 10 is not the live power datapoint. [#21787724]

Why does a newer GR2PWS with a T1-2S-NL chip need different OpenBeken handling, including BK7238 firmware and a 115200 TuyaMCU baud rate?

Because the late hardware revision replaced the CB2S/BK7231N path with a T1-2S-NL module that users handled as BK7238 and at a faster UART rate. A user flashed the new module as BK7238 and initially saw no values. The breakthrough came when the thread switched the TuyaMCU baud rate to 115200 instead of 9600 and kept the same core DpID map. Once corrected, relay, measurements, and custom HTML worked on the new revision. [#21788001]

What troubleshooting steps help when a T1-2S-NL based GR2PWS shows no TuyaMCU data at all after flashing OpenBK7238?

Check UART setup first, then verify the module still talks to the MCU. 1. Confirm the device runs on mains again and OpenBeken boots normally after reassembly. 2. Set startDriver TuyaMCU, try tuyaMcu_setBaudRate 115200, and test tuyaMcu_sendQueryState; one user got OK only after fixing setup. 3. If nothing changes, restore the stock backup to prove the hardware still works, then reflash OpenBeken and correct the mapping. The thread also tested flag 26 for UART swap, but the durable fix was proper baud plus correct power mapping. [#21785449]

How can the CH573F MCU in older Atorch GR2P-WS units be accessed over USB boot mode, and what limits prevent full firmware dumping or reflashing?

You can enter CH573F USB boot mode, but full firmware extraction is blocked by read protection. One user wired USB D+, D-, GND, and grounded the BOOT pin, then WCHISPStudio detected the MCU with bootloader version 2.90. The tools could read the 32 KB EEPROM, but not the full code flash. Another user’s wchisp info showed CFG_ROM_READ 0, which disables normal flash readout. That protection, plus possible encryption, stopped practical full dumping and easy reflashing. [#21568865]

What options are there for updating or restoring the Atorch GR2P-WS MCU firmware, including Tuya app OTA, USB flashing, and backup-based recovery?

The practical options are Tuya app OTA when stock firmware still runs, restoring the Wi‑Fi-module backup to rejoin Tuya, or risky MCU-side USB experiments. The thread confirmed a rollback path: flash the saved BK backup, pair with Tuya again, and use the app if an MCU update is offered. Users also shared an MCU OTA binary for version 1.0.3, but later recovery attempts could end in boot loops. A January 2025 report showed MCU firmware 1.0.4 still worked fine with OpenBK7231N 1.17.822, so updating the MCU is not required for normal OpenBeken use. [#21373484]
Generated by the language model.
ADVERTISEMENT