I purchased some ZY-D02 door sensors from AliExpress. Board ID: ZY-D02-CB3S-V1.3 Wi-Fi Module: T1-3S App: SmartLife I attached wires to the TX/RX pins and used the TuyaMCUAnalyzer to snoop on the communications between the TuyaMCU and the T1-3S module. The TuyaMCU is communicating using version...

thought about this the other day. The web app could definitely do with having the ability to restore from backup for exactly your scenario. Maybe even a 'scan for and move' function for users that did not take a BK7238 backup before conversion to OpenBK7238

That would be ideal. For this specific case, 'scan and move' might not work since I think OBK uses 0x1e3000 for its variables, and that is where the original RF data is.

I think OpenBK7238 expects the RF partition to start at 0x1e0000 Added after 15 [minutes]:though I did just get a little lost in this thread which seems to suggest 1e1000, but later 1e0000 confirmed by @jmkrzyszt was 1e1000 a typo @insmod ?

Interesting, so has anyone had a BK7238 device where the factory RF is at 0x1e0000? The posts you linked show the factory RF is at 0x1e3000. Would it be a good idea to have the GUI flasher read the RF from the factory location and write the RF to the OpenBK7238 location by default? Although it is mentioned in many places, I had a hard time finding the information. I guess it would be a nightmare to change OpenBK7238 to use the default factory RF location of 0x1e3000?

had a little look at the TLV location on all our dumps Code: TextLog in, to see the code Code: TextLog in, to see the code

I have had two quirks with this device that I want to resolve before I create a device report. The first was that the device would ignore any changes on wake-up that involved going to the (0) state. After two days, I finally tracked down the problem. When the channels are prepared during wake-up, the corresponding previous PIN states are just initialized to (0). So they were ignored. I've created a PR which solves that problem.The next problem is that the device will sometimes not go to sleep on the first try. I haven't figured out why exactly that is. Does anyone else have this issue? Any insights? Added after 34 [minutes]:This is my chicken-scratch diagram of the sensor connection. Both the _pd and the _nPup drivers seem to work. Which one is the proper one for the diagram I have drawn?

Restoring RF Calibration Data for T1-3S (ZY-D02) After OpenBK7238 Flashing Issues

protectivedad 381 6

Report a violation of the law

Reply | New topic

#1 21788033 23 Dec 2025 00:24

protectivedad protectivedad

Level 9
Topic author

Post #1
21788033 23 Dec 2025 00:24

I purchased some ZY-D02 door sensors from AliExpress.
Board ID: ZY-D02-CB3S-V1.3
Wi-Fi Module: T1-3S
App: SmartLife

I attached wires to the TX/RX pins and used the TuyaMCUAnalyzer to snoop on the communications between the TuyaMCU and the T1-3S module. The TuyaMCU is communicating using version 3 protocol.

Code: text Expand Select all Copy to clipboard
Sent by WiFi module: 55 AA   00   00      00 00      FF    Received by WiFi module: 55 AA   03   00      00 01   00   03

After capturing the information I needed, I used the BK7231GUIFlashTool-v181 to back up the original and flash OpenBK7238_QIO_1.18.229.bin.

The TX/RX lines used to flash the new firmware are already used to communicate with the TuyaMCU, so either the TuyaMCU or the T1-3S needs to be removed, or the TX/RX lines cut.

I removed the module (mistake: pulled up pads on the board)

For the startup command line I used:
Code: text Expand Select all Copy to clipboard
startDriver tuyaMCU; linkTuyaMCUOutputToChannel 101 bool 1; setChannelType 1 ReadOnly; linkTuyaMCUOutputToChannel 102 val 3; setChannelType 3 ReadOnly;

Don't use tmSensor; that will make the tuyaMCU driver only recognize version 0 information.

Configure startup to remember the last channel states. Select flags 37 and 51 for quick Wi-Fi connections.

At this point, the tuyaMCU driver will not recognize the state information from the tuyaMCU. After the TuyaMCU receives the Wi-Fi connection status:
Code: text Expand Select all Copy to clipboard
Sent by WiFi module: 55 AA   00   03      00 01   04   07

It will send the state information as:
Code: text Expand Select all Copy to clipboard
Received by WiFi module: 55 AA   03   34      00 0E   0B01000101010101016501000101   BE    Received by WiFi module: 55 AA   03   34      00 0E   0B01000101010101016604000102   C3

The tuyaMCU code will be updated to recognize this.

Currently, that is as far as I have gotten.

A problem I have is that the RF information for my T1-3S is at 0x1E3000. I'm not sure if that is where it was supposed to be, but OpenBK doesn't find it, and the MAC address is all messed up. I'd like some suggestions on how I can use the backups I have to "fix" the RF data in the OpenBK firmware.

Figured it out. In BK7231GUIFlashTool-v181, select "Show advanced options", use "Custom", and restore RF from backup. Start offset 0x1E3000.

Is there a way to do this in one shot with BK7231GUIFlashTool-v181? Or do I always have to back up the old, flash the new, and fix the RF? Also, can I fix the RF on my running OpenBK without tearing it apart? The web app has a flash page with "Read RF Config", "Download RF", and even "Restore (Recreate) RF". How about writing from my backup?
From Display to Complete System: How the Solution Team Creates Value at Unisystem [ad]

ADVERTISEMENT
#2 21788211 23 Dec 2025 10:18

divadiow divadiow

Level 37

Helpful post? (0)

Post #2
21788211 23 Dec 2025 10:18

protectivedad wrote:
The web app has a flash page with "Read RF Config", "Download RF", and even "Restore (Recreate) RF". How about writing from my backup?

thought about this the other day. The web app could definitely do with having the ability to restore from backup for exactly your scenario. Maybe even a 'scan for and move' function for users that did not take a BK7238 backup before conversion to OpenBK7238
ADVERTISEMENT
#3 21788422 23 Dec 2025 14:20

protectivedad protectivedad

Level 9

Topic author Helpful post? (0)

Post #3
21788422 23 Dec 2025 14:20

divadiow wrote:

protectivedad wrote:
The web app has a flash page with "Read RF Config", "Download RF", and even "Restore (Recreate) RF". How about writing from my backup?

thought about this the other day. The web app could definitely do with having the ability to restore from backup for exactly your scenario. Maybe even a 'scan for and move' function for users that did not take a BK7238 backup before conversion to OpenBK7238

That would be ideal. For this specific case, 'scan and move' might not work since I think OBK uses 0x1e3000 for its variables, and that is where the original RF data is.
#4 21788459 23 Dec 2025 15:30

divadiow divadiow

Level 37

Helpful post? (0)

Post #4
21788459 23 Dec 2025 15:30

I think OpenBK7238 expects the RF partition to start at 0x1e0000

https://github.com/openshwprojects/BK7231GUIF...110847b3/BK7231Flasher/RFPartitionUtil.cs#L42

Added after 15 [minutes]:

though I did just get a little lost in this thread which seems to suggest 1e1000, but later 1e0000 confirmed by @jmkrzyszt

https://www.elektroda.com/rtvforum/topic4106397.html#21764552

was 1e1000 a typo @insmod ? https://www.elektroda.com/rtvforum/topic4106397.html#21650956
ADVERTISEMENT
#5 21788501 23 Dec 2025 16:04

protectivedad protectivedad

Level 9

Topic author Helpful post? (0)

Post #5
21788501 23 Dec 2025 16:04

divadiow wrote:
I think OpenBK7238 expects the RF partition to start at 0x1e0000

https://github.com/openshwprojects/BK7231GUIF...110847b3/BK7231Flasher/RFPartitionUtil.cs#L42

Added after 15 [minutes]:

though I did just get a little lost in this thread which seems to suggest 1e1000, but later 1e0000 confirmed by @jmkrzyszt

https://www.elektroda.com/rtvforum/topic4106397.html#21764552

was 1e1000 a typo @insmod ? https://www.elektroda.com/rtvforum/topic4106397.html#21650956

Interesting, so has anyone had a BK7238 device where the factory RF is at 0x1e0000? The posts you linked show the factory RF is at 0x1e3000. Would it be a good idea to have the GUI flasher read the RF from the factory location and write the RF to the OpenBK7238 location by default? Although it is mentioned in many places, I had a hard time finding the information. I guess it would be a nightmare to change OpenBK7238 to use the default factory RF location of 0x1e3000?
#6 21788600 23 Dec 2025 17:46

divadiow divadiow

Level 37

Helpful post? (0)

Post #6
21788600 23 Dec 2025 17:46

had a little look at the TLV location on all our dumps https://github.com/openshwprojects/FlashDumps/tree/main/IoT/BK7238

Code: Text
Log in, to see the code

Code: Text
Log in, to see the code
ADVERTISEMENT
#7 21795316 01 Jan 2026 02:21

protectivedad protectivedad

Level 9

Topic author Helpful post? (0)

Post #7
21795316 01 Jan 2026 02:21

I have had two "quirks" with this device that I want to resolve before I create a device report. The first was that the device would ignore any changes on wake-up that involved going to the (0) state. After two days, I finally tracked down the problem. When the channels are prepared during wake-up, the corresponding previous PIN states are just initialized to (0). So they were ignored. I've created a PR which solves that problem.

The next problem is that the device will sometimes not go to sleep on the first try. I haven't figured out why exactly that is. Does anyone else have this issue? Any insights?

Added after 34 [minutes]:

This is my chicken-scratch diagram of the sensor connection. Both the _pd and the _nPup drivers seem to work. Which one is the proper one for the diagram I have drawn?
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)

Reply | New topic

Report a violation of the law

Topic summary

The discussion centers on restoring RF calibration data for the T1-3S WiFi module used in ZY-D02 door sensors after flashing OpenBK7238 firmware. The original device, a ZY-D02-CB3S-V1.3 board with a T1-3S module running TuyaMCU protocol version 3, was interfaced via TX/RX pins to capture communication data. Flashing OpenBK7238_QIO_1.18.229.bin was performed using BK7231GUIFlashTool-v181, but the shared TX/RX lines between the TuyaMCU and the WiFi module complicated the process, leading to physical damage when removing the module. The main challenge is recovering or restoring the RF calibration data lost or corrupted during flashing, which is critical for proper WiFi operation. The discussion implies the need for careful handling of serial lines during flashing and suggests that RF calibration data may be stored in specific memory sectors or require backup before firmware updates. The use of TuyaMCUAnalyzer for protocol snooping and BK7231GUIFlashTool for firmware management are key tools mentioned.
Summary generated by the language model.

Restoring RF Calibration Data for T1-3S (ZY-D02) After OpenBK7238 Flashing Issues

Didn't find an answer? Ask Artificial Intelligence

Topic summary