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

p.kaczmarek2 1398 7

This content has been translated

View the original version here.

Reply Cool? Ranking DIY | New topic

Notify about new articles

» | Helpful post? (+4)

#1 10 Jul 2023 08:53

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:

Code: json
Log in, to see the code

Text description of the same from my flasher:

Code: text Expand Select all Copy to clipboard
Device configuration, as extracted from Tuya: - Button (channel 0) on P20 - Status LED on P26 - PIR sensor on P16 - Battery Relay on P17 - Battery Max Voltage: 3000 - Battery Min Voltage: 2200 - Battery ADC on P23 Device seems to use Battery Driver. See more details here: https://www.elektroda.com/rtvforum/topic3959103.html Device seems to be using CBU module, which is using BK7231N. And the Tuya section starts, as usual, at 2023424

Partially finished template in our JSON format:

Code: json
Log in, to see the code

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?

Cool? Ranking DIY
Do you have a problem with Arduino? Ask question. Visit our forum Arduino.
About Author
p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Offline

Joined: 26 Dec 2014

Posts: 5843

Help: 279

Posts rating: 5827

Points: 52838
p.kaczmarek2 wrote 5843 posts with rating 5827, helped 279 times. Been with us since 2014 year.
#2 15 Aug 2023 13:08

pippo_franco pippo_franco

Level 2

Helpful post? (0)

#2 15 Aug 2023 13:08

Hello,

I have the same sensor and I was able to flash it with OpenBK after using the cloudcutter tool.
Everything seems to be working using the provided configuration, I just had to put the PIR sensor and the battery ADC/relay on different channels, otherwise deep sleep was never triggered because the timer was restarting after every battery update.

However, it seems to be slower compared to the original firmware.
Using the original firmware and the official Tuya HA integration, I was able to see the status update in HA after roughly 4/5 seconds, now the status is updated after 7/8 seconds.

Is there any way to speed up the reboot without impacting too much on the energy consumption? I have already set a static IP, however it took around 5 sec to connect to the Wi-Fi network and then 2/3 seconds to connect to MQTT and send the status update.

Additional question: is there any way to change the LED behavior? In the original firmware, the LED blinks a moment when a motion is detected, then it is turned off; with OpenBK I see the led always on while the PIR sensor detects a movement, then it goes off only when no movement is detected (or when it goes into deep sleep). Since I would like to use it to turn on/off the bathroom light in the night, it would be better to keep the LED on as minimum as possible.

Thanks
#3 15 Aug 2023 13:13

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Topic author Helpful post? (+1)

#3 15 Aug 2023 13:13

LED could be very easily scripted to behave as you wish. For example, you can put LED on channel 4 (or any other one), and then in autoexec.bat do:
Code: text Expand Select all Copy to clipboard
// turn on LED setChannel 4 1 // schedule an event, after 2 seconds, turn off LED (this is non-blocking call) // NOTE: addRepeatingEvent [RepeatTime] [RepeatCount] addRepeatingEvent 2 1 setChannel 4 0

If you have already static IP set, you can also try to enable quick connect flag in options. Let me know if it helps in your scenario.

Is your 7 seconds delay a time to MQTT connect or a time to WiFi connect?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#4 15 Aug 2023 16:24

pippo_franco pippo_franco

Level 2

Helpful post? (+1)

#4 15 Aug 2023 16:24

Thanks, I will try with the script as suggested and see if it works. If I properly understood, that script is going to turn on the LED as soon as the device is turnt on, and not when the PIR detects a movement, correct?

Quick connect has been enabled, I forgot to mention it (sorry about that). I will try to deactivate the option to see if there is any difference, just for test purposes.
Unfortunately I cannot check at the moment, I will be back home in a couple of days, but as far as I can remember the log were displaying an uptime of 5 seconds when the device was on and connected to the Wi-Fi, so I believe it is the time to connect to the Wi-Fi. Moreover, if I continue to refresh the device web page, I can see that it is reachable and the MQTT state is “disconnected”, then becomes “connected” after a few seconds. To me the biggest delay is the time required to the device to turn on and connect to the Wi-Fi, but if there is any way to provide more detailed logs please let me know and I’ll do it.

Thanks again
#5 15 Aug 2023 17:23

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Topic author Helpful post? (+1)

#5 15 Aug 2023 17:23

pippo_franco wrote:
Thanks, I will try with the script as suggested and see if it works. If I properly understood, that script is going to turn on the LED as soon as the device is turnt on, and not when the PIR detects a movement, correct?

You are correct. If you want to link LED behaviour to PIR channel, you should do smth like that:
Code: text Expand Select all Copy to clipboard
// set channel to 1 and after 2 seconds set it to 0 // NOTE: addRepeatingEvent [RepeatTime] [RepeatCount] alias blinky backlog setChannel 4 1; addRepeatingEvent 2 1 setChannel 4 0 // when channel 1 becomes 1 addChangeHandler Channel1 == 1 blinky

pippo_franco wrote:

log were displaying an uptime of 5 seconds when the device was on and connected to the Wi-Fi,

You can try to use SendGet to control another device without waiting for MQTT connect. This may be faster and it will work even when HA is offline.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#6 16 Aug 2023 11:02

pippo_franco pippo_franco

Level 2

Helpful post? (0)

#6 16 Aug 2023 11:02

Thanks a lot for the quick feedback, I’ll try with the provided script and let you know if I have further questions.

Regarding the SendGet approach, if I properly understood it means that I will need to use the SendGet command to call the HA API described in the HA documentation, correct? Is there a documentation on how to use the command? Do I need to call it in the autoexec.bat, similarly to the LED blink script?

Anyway, I think I will have similar problems if the delay is caused by the Wi-Fi connection; without a Wi-Fi connection I will not be able to do HTTP calls, so I’m not sure if it will reduce the delay, but I’ll give it a try.

Thanks
#7 16 Aug 2023 11:11

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Topic author Helpful post? (0)

#7 16 Aug 2023 11:11

Well, you could certainly call HA API that way, but I was thinking about using SendGet directed towards a lamp IP and sending a Tasmota-style cm interface POWER ON call. That way PIR communicates directly with lamp. You can fire OBK script alias that way as well, if you want lamp to turn off after some time.

Sample script:
Code: text Expand Select all Copy to clipboard
// add emergency sleep clause - if needed? - in case that there is no WiFI connection in 30 seconds or so // Not needed if you are using door sensor driver instead of scripting everything manually... // NOTE: addRepeatingEvent [RepeatTime] [RepeatCount] // addRepeatingEvent 30 1 PinDeepSleep // wait for wifi to become WIFI_STA_CONNECTED waitFor WiFiState 4 // send data SendGet http://192.168.0.112/cm?cmnd=Power0%20ON // wait for GET to be sent delay_s 3 // do anything more if needed

Our docs are here:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#8 16 Aug 2023 14:11

pippo_franco pippo_franco

Level 2

Helpful post? (0)

#8 16 Aug 2023 14:11

Got it, thanks. The lamp is actually controlled using a Shelly 1 with the original firmware and connected to HA, that’s why I would prefer to have it controlled with an automation in HA. I’ll try to do additional tests in the upcoming days, maybe I can retrieve some additional logs to better understand where the delay is and if there is a way to reduce it.

I’m just surprised that the original firmware seemed to be faster, considering that the device has to connect to the Tuya servers to do the update, while in this case the MQTT broker is on the same network.

Anyway, thanks a lot for the help and for the quick returns
Create an account, log in and become active in a forum and ads will not appear. You will receive points by participating in discussions.
Join this discussion.

Log in with Google

Reply Cool? Ranking DIY | New topic

Notify about new articles