Failed Attempts at Flashing Generic Tuya OEM WiFi Door Sensor with CB3S Chip using BK7231 Tools

Hi all,
First of all, this is my first post on this forum, so apologies if it's not in the correct forum/topic.
I recently purchased a generic (Tuya OEM?) WiFi door sensor which has a CB3S chip (runs on 2xAAA) as shown in the attached photos from Aliexpress.
I tried flashing it with the BK7231 GUI Flash Tool and with bk_writer1.60 as well, but both are giving errors.
I also tried flashing OpenBK7231N_QIO_1.17.165.bin with "BK7231Flasher," but it gives an error as shown in the screenshot.
While bk_writer1.60 throws an error with "unprotecting failed" as shown in the screenshot.

BK7231 flasher, while taking backup, provided the following configuration it thought exists:


I'm not sure what I'm missing. Can someone help?

Hello, can you try the hid_download_py method from this video?

https: //github.com/OpenBekenIOT/hid_download_py
Please also provide us a firmware backup if you have it.

Keep in mind that after flashing you will have to configure door sensor with deep sleep in order to avoid draining the battery too quickly.

Thanks for the video link. I am not able to find the procedure to install the Python program you have mentioned. Can you provide a documentation link?
Attached is the backup.

>>20638561
Got the hid_download_py installed, however still not able to flash. Error below:

python3 uartprogram OpenBK7231N_QIO_1.17.165.bin --unprotect -d COM10 -w --startaddr 0x0
UartDownloader....
program....
WriteSector 1 Failed: |##3 |[ 2.42k/s]

Added after 17 [minutes]:

Failed with reduced baud as well:

python3 uartprogram OpenBK7231N_QIO_1.17.165.bin --unprotect -d COM10 -b 115200 -w -s 0x0
UartDownloader....
program....
WriteSector 1 Failed: |##3 |[ 1.43k/s]

Is the internal flash write protected purposefully to inhibit others from flashing it with open source firmware?

Some questions:

- are the batteries present? (if not you can use the power from the USB to UART adapter - just be sure you are using 3.3V not 5V!!!)
- try lowering your port speed to 115200 does that work?
- can you provide the link to the product (link form AliExpress store)?

@DeDaMrAz
Hi
Yes, the AAA batteries are present. Using FTDI with common ground & RX/TX pins (not using power from the FTDI).
Here is the Aliexpress link for the product:
https://www.aliexpress.com/item/1005005021005....order_list.order_list_main.17.282f1802iGFLTZ
Tried with lower baud but that is not fixing it.
Thanks

sandyk wrote:

@DeDaMrAz
Hi
Yes, the AAA batteries are present. Using FTDI with common ground & RX/TX pins (not using power from the FTDI).
Here is the Aliexpress link for the product:
https://www.aliexpress.com/item/1005005021005....order_list.order_list_main.17.282f1802iGFLTZ
Tried with lower baud but that is not fixing it.
Thanks

Start the GUIflasher and then ground for the short time CEN pin on the module as the module will not self reset if powered previously.

Also try 115200 for the port speed.

Maybe the device goes asleep before you try to flash? Try pressing onboard pair button several times before and during flashing.

Maybe try another USB dongle?

@p.kaczmarek2 Changing the FTDI adapter seemed to have helped. I am able to flash the device, and it is now configured to connect to my WiFi.
Now the next hurdle is to figure out the pin mapping/configuration. Based on the configuration the flashing tool was able to detect, are you able to help with the correct pin mapping in OpenBK, please?
Thanks in advance.

Pin mapping can be automatically extracted from a 2MB backup of the device flash. It can also be recovered from OBK after flashing. Here's a tutorial:

Are you thinking of only replacing the Tuya firmware with OpenBeken and continuing to work "Online" with Tuya servers (original config still on the chip), and having additional extras like web access and all OpenBeken (like MQTT) features, only as an option to "work like a Tuya device"?

I am not sure how feasible it would be. The idea seems good but no one else so far requested it and keeping it working with Tuya would basically mean that we would need to somehow reimplement all Tuya functionality and of course we would need to understand how their protocols are working. Maybe we could use their open source SDKs as reference, but still, that would be a very hard task.

mminkov wrote:

Are you thinking of only replacing the Tuya firmware with OpenBeken and continuing to work "Online" with Tuya servers (original config still on the chip), and having additional extras like web access and all OpenBeken (like MQTT) features, only as an option to "work like a Tuya device"?

Hmm, as far as no one requested... hey that would be cool! But I agree, hard to implement as Tuya keeps changing things.

Technically one can add Tuya to Home Assistant. I've done so for years and to be fair, it works well and allows integrations with various other brands and custom commands, just like flashed devices do. Sure it doesn't tackle the privacy issues, or if Tuya ever pulls the plug leaving us in the dark. But hopefully something better would have taken by then.

Perhaps worth to mention that Tuya also has Zigbee sensors, and those don't need any hacking to get into HA. Only a suitable radio to pair.
They are more expensive, but worth it on the time saved messing with things, IMHO. And you can always go back to Tuya with them, if you wish.

Zigbee is more energy-efficient so I always recommend it for battery-powered devices. It's also much easier to handle in case of such sensors. The only drawback is that you actually have to have HA, and in case of WiFi devices I can just access them directly via WiFi.