[CBU/BK7231N] Tuya PIR motion sensor Krasław 120°, deep sleep, battery powered

I will present here the teardown, the principle of operation and the firmware change (in order to free it from the cloud and gain independence from the manufacturer's servers) of a cheap PIR sensor by Tuya, bought on one of the Polish shipping portals. Finally, I will provide its full configuration for OpenBeken, along with the template. Of course, we will configure the device to work with deep sleep and the PIR sensor will only wake it up when a movement is detected. This is essential for battery-powered gadgets with WiFi communication, otherwise battery would drain too fast.

Sensor purchase
The sensor was purchased by one of the users OpenBeken on a Polish auction site, with the intention of giving it to me so that I could change its firmware. Below are screenshots of the offer:

We paid only PLN 50 (about 12$), the shipment was free (in the package for regular customers of this portal).
Parameters, no specifics here:

Only in the features can we read, for example, that the sensor "holds" presence detection for 30 seconds, or at what distance it can detect:


This sensor is powered by three AAA batteries (they are not included in the set, they must be purchased separately).
The packaging, unfortunately, does not have specific markings:

Here's what we got in the kit:

There is a tape and a reset key.
The product also has a hook to stick to the wall (this is the tape), and after removing it, we have access to the battery, the ON-OFF button and the reset button (i.e. pairing):



The teardown of the sensor
Apparently the sensor has a warranty seal from the seller, but it is glued in such a way we don't have to remove it.

There is a module inside CBU , its documentation is on the Tuya website, a OpenBeken supports BK7231N.

Let's take a look at the board:

Not much happens on this board. The PIR sensor is typical, such as in popular modules for Arduino. My attention was caught by the U3 chip, i.e. 7333, 3.3V LDO regulator. I thought that there would be a slightly more efficient step down converter here, but no. All in all, it makes some sense, here there are three nominally 1.5V batteries, i.e. 4.5V in total, of course less and less with their discharge. Tuya battery powered products with converters instead of regulators are rather two batteries, then there is 3V, and the converter increases them to 3.3V.
The on-off button allows you to turn off the sensor completely without removing the battery:

Transistors R1 and A09T, whose roles I have not analyzed:

CBU:

This device does not use TuyaMCU. There is no additional microcontroller here, nothing is blocking UART1 from the CBU. The CBU controls everything by itself and falls into a deep sleep when nothing happens. This device wakes up and connects to WiFi only when a status needs to be reported.

Programming, configuration
We connect the common ground, RX and TX from the UART converter and possibly the power supply, start the flasher, and do the power cycle (off and on). Everything as described in our repo:
https://github.com/openshwprojects/BK7231GUIFlashTool
The same process can be seen on our YT channel:
https://www.youtube.com/@elektrodacom
Soldered wires:

Flasher in motion:

Flasher can also read Tuya configuration:

Here we have the JSON from Tuya, their device description format:

Text description of the same from my flasher:

Partially finished template in our JSON format:

Let's analyze what we've got here. First, there's the pairing button, Button, on the P20. There is a WiFi LED here on the P26. There is a PIR sensor on the P16. And we have a battery status control system, i.e. ADC + GPIO which turns on the resistor divider. These GPIOs are there to save energy and to make the resistor divider only let current when we make a measurement. Tuya also determines the maximum and minimum battery voltages, it is used for calculations.
There was already a topic about the battery controller here:
https://www.elektroda.com/rtvforum/topic3959103.html
Now it's all about deep sleep. The WiFi module cannot work all the time, it would drain the batteries too quickly. To do this, we will use the deep sleep solution described here:
https://www.elektroda.com/rtvforum/topic3960149.html
Also, check out this topic on deep sleep:
https://www.elektroda.pl/rtvforum/topic3972898.html
https://www.elektroda.com/rtvforum/topic3972898.html
In summary, here is what needs to be configured:
- set the Button role for the button to P20 to be able to wake the device from a deep sleep in an emergency
- set the role of LED (or WiFi LED - at your discretion, or LED_n) to P26, select channel 1 there
- set the role of DoorSensorWithDeepSleep for P16, because we will use the door sensor driver to report movement, also set channel 1
- additionally, depending on which PCB version you have, you may need to configure DSEdge to select the type of edge that wakes up the sensor (rising, falling, or respectively increasing when the system goes to sleep with a low state on the sensor or falling when the system goes to sleep with a high state on sensor)
- configure the battery driver, as in the previously linked topic
After that, you can perform Home Assistant Discovery to connect the device to the HA:
https://www.youtube.com/watch?v=pkcspey25V4

Just in case, here is the OBK documentation:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md
And any questions can be asked on our forum.

Here is the final result:

The LED lights up as soon as motion is detected.


Summary
That was a success - another device freed from the cloud and from the manufacturer's servers. In addition, once again we managed to encounter something using a battery controller based on the ADC input and the digital GPIO output, where the digital GPIO turns on the resistor voltage divider only for the time of measurement. I have seen it several times in this type of products, also in the case of a door sensor.
As for the configuration of the device itself, it is worth noting that it could also be handled "manually", through the OpenBeken script, simply by entering a simple loop with IF and GoTo, which will put it to sleep using the PinDeepSleep command when there are no changes on the sensor for while.
Here the question arises whether we want the device to "sleep" only when there is no movement (and it was "wake up" until the PIR reports the presence of movement), or to "fall asleep" in both states. When using the driver, DoorSensor falls asleep in both states. This is probably better in terms of battery life.
It is worth adding that in OBK such a device can control others even without Home Assistant - just script the SendGET command and, for example, send a new state for the light switch via IP.
That's probably it, at the end I'll just remind you that a static IP and placing the device close to the router will also extend the battery life to some extent.
Does any of the readers use this type of PIR sensors? And if so, is it in the "cloud" version related to the manufacturer's servers, or maybe in a fully local version?