OpenBK CB3S Door/Window Sensor Issues: PB-69W VER1.4, Battery Life, Rear Alarm Button

Hello!

I bought some door/window sensors on Aliexpress a few days ago. When they arrived, I was able to verify that they contain the CB3S chip. So I have flashed it with OpenBK, latest version. They seem to work fine. But two of them that are the ones I'm working with. A few hours after flashing it, they stop working.
I have tried to reflash, but now it seems that the chip does not work. I changed the batteries and it has power. I will continue to investigate what happened to him.

The PCB is named as PB-69w VER 1.4.
It has a magnet with which it detects the closed door
A rear alarm button in case it is disassembled
a reset button
And a status led.

So far I have managed to make the Led act as an inverted wifi led (P9) to know if it is connected to the wifi.
I know when the door opens and closes (P7)
But the rear alarm button, I don't know how to make it work.

Another issue is that the batteries (2xAA) last about 5 or 6 hours.
In the options I already have the options marked (I think there are 3. 2, 10 and 19).

I hope someone has already reached out to them too and we can help each other!

Hello, the first temporary fix would be to enable PowerSave, dynamic powersave, with "PowerSave 1" command in autoexec.bat or short startup command.

But this won't suffice, and I think this device might need a DeepSleep feature with wakeup on IO event.

It is already implemented for firmware but not prepared for door sensor, as my doors sensors are using TuyaMCU:
https://www.elektroda.com/rtvforum/topic3914412.html
I can try to figure out something better for you.

PinDeepSleep currently supports wakeup either on falling on raising edge.

It seems we might need some kind of driver or specific sensor for that...

@dheenhasty , is this functional?
https://github.com/openshwprojects/OpenBK7231...mmit/1391097885c9aa85a2c363e0edc6f1a8b8b36965

It seems we need to add a very simple code snippet that checks door state at boot, reports it to MQTT, and then, once reported, checks door state and if high does sleep with "wake up on falling" and if low then does deep sleep with "wake up on raising"....

Hmmm I think I can try to setup this today for you. Let me look into it....

You are going to forgive me; but I'm advancing as I learn...
How can I know if this device also works with MCUTuya?
The device comes ready to work with Tuya. But the truth is, I flashed the three devices as soon as I received them and I have lost the original FW...
Thanks for the help! There are already several devices that I have working with this OpenBK

The driver is ready! I will be posting the guide in 24 hours, first on polish site and then the translation.

4139ggn wrote:

I flashed the three devices as soon as I received them and I have lost the original FW...

Three other devices? Please post teardowns as well.
https://www.elektroda.com/rtvforum/topic3952160.html

4139ggn wrote:

How can I know if this device also works with MCUTuya?

TuyaMCU is a protocol of communication between MCU and wifi module. MCU looks like this:


MCU is always connected to WiFi module by UART1 port on Beken, RX1 and TX1.

There is no MCU on your board.

p.kaczmarek2 wrote:

The driver is ready! I will be posting the guide in 24 hours, first on polish site and then the translation.

Yeah!

p.kaczmarek2 wrote:

Three other devices? Please post teardowns as well.

But they are the same model I bought several at the same time.

p.kaczmarek2 wrote:

TuyaMCU is a protocol of communication between MCU and wifi module. MCU looks like this:

Understood! So, in my device, nothing manages the power of the CB3S, right?

In your device CB3S is all time on and takes 100mA at average.

With deep sleep, we can go down to:


Have you managed to do the Home Assistant pairing already?

>>20455596

Yes it works, the issue you can have is the delay of boot for the device. You might need to lower boot complete time.

And on this kind of device remove the battery and replace them will wake up the device.

@dheenhasty the boot success time was lowered from default 30 to new default - 5, few days ago. So all new users will now get configs with 5 seconds requirement for correct boot. I think that is a better setting.

p.kaczmarek2 wrote:

Have you managed to do the Home Assistant pairing already?

Yes. When I flashed them I inserted them into Home Assistant and they worked without a problem. Until they ran out of batteries or fell asleep.
Since then, I haven't even been able to get them to connect to the WiFi...

@4139ggn have you used automatic HA discovery?

You will need to add them again to HA (remove old entity) after you update to newest firmware version (the one with deep sleep).

I will post the tutorial tomorrow.

If I remember correctly, Mosquitto detected it alone.
I added to "configuration.yaml" all the information that the Fw gives. And it works! Well, until it stops...
What I don't understand is: Why after having reflashed it, I still can't find it?

Waiting for tomorrow to reflash!

Hum when battery is low on this kind of sensor, it failed to start. so try to change battery and check on local wifi, there's good chance the sensor has gone on failsafe mode.

For best results, when I publish the tutorial for Deep-sleep based door sensor, do not paste Yaml - use automatic home assistant discovery.

This is because auto-generated yaml might have "availability topic" which must not be included on sensors like that, because those sensors are most of the time offline and only report changes.

The automatic Home assistant discovery works for door sensor now. Details tomorrow.

And if you don't know what Home Assistsant Discovery is, take a look here:
https://www.youtube.com/watch?v=pkcspey25V4

Added after 9 [hours] 14 [minutes]:

A configuration guide for OpenBeken deepsleep door sensor with wakeup on IO is ready!
@4139ggn @dheenhasty

The English version will be up in the few days at most. Here are the links.
Door sensor without TuyaMCU - deep sleep and power saving, configuration, OpenBeken - ENGLISH
Czujnik drzwi/okna bez TuyaMCU - głęboki sen i oszczędzanie energii, OpenBeken - POLSKI

Good morning! This morning I tried to resuscitate one of the sensors I have. Flash version 1.15.487.bin with the tool. It flashes fine. But then it doesn't do anything else. Neither do I create PA, nor does it connect to the configured Wi-Fi network... Nothing.

If you connect the RX of USB to TTL converter to the TX2 of CB3S (debug log output), what does the log say in Realterm?

Battery is ok ? you sure you don't see a failsage AP mode ....

i have detected some bug with putting deepsleep in autoexec.bat it might go in boot loop mode.
until https://github.com/openshwprojects/OpenBK7231T_App/pull/692 is checked and put in release, i suggest to do a different file in lfs (for example myroutine) and change the startup command to "startScript myroutine"

i don't know how you flash it, but if it's via uart, it might not has erased the autoexec.bat you have created. so it boot loop until comming in failsafe.

Wait, @dheenhasty , did he put that command in autoexec.bat?
Did you, @4139ggn ?

If so, I can add a "erase file system" command to flasher".

But....... if he put that in autoexec, the device will quickly do five power on/off cycles and will detect a problem and go back to AP mode. So I don't think that's it. In safe mode (AP mode) autoexec is not run. So his issue is most likely different. It should come as AP mode very quick.

I am not sure what might have happened so far, @4139ggn do you have any other information that can be useful?

Of course, I have an idea of last resort fix, but we will try that later.

@4139ggn if you have a flasher hooked up, you can do a full 2MB read backup and send us file, possibly first by replacing characters of your WiFi pass with the same amount of other characters (do not change the amount of bytes in the file).

Just a supposition as the default file you create on Filesystem panel is autoexec.bat i suppose every user just copy/paste command in a autoexec.bat file..... until now it was not an issue maybe some misbehaviour regarding delay, but with deepsleep it can be really troublesome.

For the AP failsafe Mode, for this kind of device it drain the battery really quick, so the sensor began to behave strange when your below 2,2 v (as the voltage regulator is only guarantee for 2,2V low voltage).

first action i will suggest to put new battery on the device and check for the AP to show (and don't forget that failsage deactivate all pin and led !!!! so your device might be running but don't seems like it's running )

About what you comment; I have tried turning on/off five times.
Before they fell asleep, like this, I would go into AP mode. Since they fell asleep, they do nothing.

p.kaczmarek2 wrote:

@4139ggn if you have a flasher hooked up, you can do a full 2MB read backup and send us file, possibly first by replacing characters of your WiFi pass with the same amount of other characters (do not change the amount of bytes in the file).

I have read with the app. But I don't know how to proceed...

Added after 2 [minutes]:

dheenhasty wrote:

first action I will suggest to put new battery on the device and check for the AP to show (and don't forget that failsafe deactivates all pin and led !!!! so your device might be running but doesn't seem like it's running )

I already have 3 packs of 4 batteries...

Added after 1 [minutes]:

p.kaczmarek2 wrote:

If you connect the RX of USB to TTL converter to the TX2 of CB3S (debug log output), what does the log say in Realterm?

What program should I read with? I have tried with Arduino and I have not seen anything

@4139ggn did you use deep sleep command? if so, remove batteries, and wait few minutes to make sure that is discharges capacitors...

RealTerm, it will work as long as you make sure you are connecting to TX2 for log and not for TX1 (which is for programming) and set baud 115200

This is what I see in Real Term

seems like a corrupt firmware ... you need to reflash . you had a backup of your tuya firmware ?

dheenhasty wrote:

you need to reflash .

Once reflashed, I get this message.
There is a previous screen, but I can't capture it.


By the way, I have lost the original FW... This is me.....


this is what it shows when booting

Do firmware backup, then do full erase in the flasher and then do RF restore and then write obk again.
https://github.com/openshwprojects/BK7231GUIFlashTool

Yeah! For now, at least create an access point. Powered from UART.
I have installed version 1.15.493.

To be sure - it created AP after RF restore? Without RF restore it was not able to do that?

Before, I had not seen the "erase all" button. Once I clicked there, everything was rolled. Flash and reboot, the AP appeared. Also, at the same time, I had another UART reading the data from TX2. So I was seeing more coherent messages. I don't know how, but the device, when it started, also had the shutdown order. So it kept turning on and off. When I plugged it back in, it turned on and off.

The links you posted this morning aren't available yet, are they? PowerSave is already 1. Besides that, what else should I do until the FW we talked about before comes out? To save battery. The led, I have left it as LEDn so that only when it is open, it is on. Also so I can see if it's on or not. Another question I have is: How do I find the rest of the buttons to give it a function? There is one that is a pick-up alarm. But I don't know which P it belongs to, and I don't know how to look it up either. It has another reset button. That the truth, I do not know if we could give it another use, or how to apply the reset button. The battery level: Could we see it somehow?

Thank you very much for your help and I hope this helps someone else!

Good job for the bringin it back too life

4139ggn wrote:

The battery level: Could we see it somehow?

if you startDriver Battery, it will show you on the front page the level and voltage. it can be lower than actual voltage but it's due to a bug i identify and correct here : https://github.com/openshwprojects/OpenBK7231T_App/pull/692

if you use Home Assistant with mqtt configure, after starting the Battery Driver you can launch a scheduleHADiscovery, it will update your sensor automatically with voltage and percentage

after that you can play with PinDeepSleep you need to define button/rel/input in module befor and be sure to write a separate script to do that. my recommendation: create a "myroutine" script. and call startScript myroutine in startup command.

the autoexec.bat is not safe for playing with deepsleep.

for your usecase something like that will do the trick :

Quote:

PowerSave
startDriver Battery
Battery_Setup 2000 3000
scheduleHADiscovery
delay_s 60
PinDeepSleep

it will wake the device on every button relay input change for 60 sec and send the Battery Level

to detect which button is connect where, you can do a try and check assign button on each pwm and check with one came up when you press it
or do some deep tracing on your board : https://developer.tuya.com/en/docs/iot/cb3s?id=Kai94mec0s076

Wait a moment, @dheenhasty

dheenhasty wrote:

Code: text Expand Select all Copy to clipboard

PowerSave
startDriver Battery
Battery_Setup 2000 3000 
scheduleHADiscovery
delay_s 60
PinDeepSleep

The DoorSensor driver, which is always started when you set a DoorSensor pin, will do automatically PinDeepSleep 60 seconds after MQTT connection is present or after 300 seconds without MQTT connection. There is no need for scripts in this case. Please consult tutorial linked above (so far only polish version is up so Google Translate is the way).

As I said - no script writing is required for beginners.

Understood. so you think the Battery driver should be started automatically (thru flag or a specific rel input for battery ? )