[BK7231N/CBU] Door sensor without TuyaMCU - how to connect to UART RX/TX

To align the magnet and device during installation, it can be helpful to assign pin 26 to the LED instead of WifiLED_n. This allows you to see immediately whether the magnet is triggering or not.



You can set it back to WifiLED_n afterwards.

btw. Is there a way to increase the sensitivity of the sensor or adjust the threshold value? Background: I have a window with two sashes and would like to attach the device to one and a stronger magnet to the other to monitor both. So far, I have achieved a detection distance of approx. 10cm, which is about 5cm short of a reliable detection.

Hi everyone,
I'm new to OpenBeken and I need some help with my Beken BK7231N door sensor.
It seems to be bricked and I'm at a loss on how to proceed.

Here's the story:
I flashed OpenBeken using the GUIFlashTool, performing a backup and extracting the Tuya config. The device then entered AP mode. I set up the network SSID, MQTT, and the module config (initially, the first one I found in a thread, which wasn't quite right). It connected to my Wi-Fi, and the door sensor worked, but it wouldn't enter deep sleep (the timer kept resetting at 60 seconds).

After reading more of your forum, I tried new module configurations. The device then seemed to enter deep sleep, but I couldn't wake it up, especially not with the button, as it wasn't configured on the correct pin but on the wrong channel. Since it was in deep sleep, I couldn't access the web interface to correct the configuration.

I attempted a soft reset with multiple consecutive power cycles. During some of these, the LED configured as Wifi_n would light up. Then, that stopped working too. After several attempts, the module now seems completely unresponsive, only emitting a buzzing sound when powered.

Initially, I was using rechargeable NiMH batteries. Since it seemed to have died, I've switched to new alkaline batteries, which should provide the expected power.

Today, I tried reconnecting it via serial. I can still read and write to the chip.

First, I read, modified, and rewrote the configuration – first the correct one for the hall sensor and button, then all to None:0. But after rebooting, still no sign of life (no AP, no STA). I then tried to rewrite the firmware. Reboot, nothing. I even tried restoring the RF partition (which required a lower baud rate). Reboot, still nothing.

It really feels like it's in a "sleep of death."
I'm quite new to OpenBeken and have no idea how to fix this. Any suggestions would be greatly appreciated!

Dear forum,

First of all, I would like to apologize for my disappearance, but I am happy to finally find time for my hobby again after many years.
;(
My excuse: between 2023 and today, I had two children, but now they are slowly getting old enough that I have time to devote to other things again.Of course, that doesn't mean I can lock myself in the basement for days on end again, but there are moments. I'm sure some of you know what I mean...

In any case, following @p.kaczmarek2 and my own instructions, I managed to successfully flash and configure the second (of a total of 25) sensors for the house and connect it to the WiFi and MQTT.

However, I am facing two problems that someone may already have solved:

1) Despite the WiFi AP being within 5m range and having a fixed IP, the sensor usually takes 7-8 seconds for the sensor status to finally change in HA.

2) In HA, the status is exactly the opposite: if the window is closed, it is open in HA and vice versa.

It will certainly take me a few weeks to refresh my memory, so I would appreciate your help in getting started!
Thank you!
<3

)

Gramais

Welcome back! We are still here, ready to help, as always.

1. Try new fast connect flag introduced by @insmod , he may know more about it. Also set static IP.
2. There are multiple ways to do it, the first one is to change DoorSensor to DoorSensor_n , I guess.

>>21631381

Great - thank you :)

1) Would be happy to hear from @insmod. Setting both flags 37 and 51 halved the time (yay!! ) to about 4s until MQTT-Status has been published. Any further ideas to - at least - get to let's say 2s?

2) For the Inverse, I am not sure what you meant @p.kaczmarek2 with "Door_sensor_n"? There are only "DoorSensor", "DoorSensor_pd"and "DoorSensor_nPup"....

Thank you in advance!

Ahhh, there is no inverted door sensor pin role, my memory failed me... I am starting to behave like LLM, I must have hallucinated. Okay, I checked the source, and the correct solution is to set flag 42, which is called "invert door sensor state", can you try that?

>>21631403
First - disable flag 10. Sending diagnostics data takes time.
Set mqtt_broadcastItemsPerSec in start command to at least 4.

For door sensor - flag 42.

>>21631414

Thanks, but I don't get it - sorry. It's been too long :)

What would be the correct startup-command syntax to set the number of mqtt broadcast items per second? Was it really just...

mqtt_broadcastItemsPerSec=3

... and push "Submit"?

>>21631424
Yes, but without '='
mqtt_broadcastItemsPerSec 3

Really? With just a space in-between?

And when you say "at least 4" what would be best? 5? 6?

>>21631439
Since this is a battery powered device, set it to amount of sensors that shows up in HA.
I use 4 on door sensors (3 in HA + 1).
Oh, an be sure to activate flag 35 and activate HA discovery again.

4 Sensors?

So, 1) The ReedSensor, 2) The Reset-Button, 3) The Battery-Voltage and 4) ... ?

Could you tell which device you are using exactly? Mine is (see pics first page of this post) a BEKEN 7231N with white colored board. Maybe we could have the same ones?

So far I just managed to find out the contact-sensors PIN and am looking at least for the battery-voltage/ remaining relative power percentage...

By the way: what is the default value for "mqtt_broadcastItemsPerSec"?

>>21631455
Battery percentage and voltage are sent separately.
So, Door, Button, Battery and Voltage.

I have one white board, but don't use it.
The one in use is blue board + cb3s. There are no mentions of it on the forum.
Still, they are all pretty similar.

Default mqtt_broadcastItemsPerSec is 1. For main powered it's ok, for battery - not so much.

My cb3s sensor operates since mid-january on ni-mh 1000mah. Started at 2800mv, currently 2690mv.

>>21631471

Cool Sounds promising. Got mine to about 2-max.3s to update state - thanks to you :)

Would mind sending me your config? as they're all really similar maybe used PINs are too?

>>21631484
It's in use, so pin config is from backup


And in autoexec, if i remember correctly, only
waitfor mqttstate 1
delay_s 2
pindeepsleep


Be sure to have a backup. If batteries discharge completely - it may die in a way that first a backup must be restored, and then reflash obk.
Or take a backup with obk already installed/configured, and restore it.

Good morning!
☀️

Okay, the device I opened up this thread for is a reed contact sensor whereas yours seems to be an PIR motion sensor, right? Following this Link it seems as if TY01 has no „real“ battery sensor:

„There is no function in Tasmota for battery power dpID so we will use a rule to report battery status (high, medium or low) to a custom topic.“

Or does this not apply to the openBeken-FW?

Any way to enter this code or to at least find out what these Tuya data codes stand for?




Added after 9 [minutes]:

And I just realized another problem: after the sensor goes to sleep it becomes unavailable in HA due to the fact that it is asleep and therefore not reachable for periodic status updates.

Is there a command/ option/ flag I can set to send an MQTT--message with or something similar?

>>21631674
It's not a PIR sensor, it's just from tuya standpoint, pir and reed sensors are the same.
Both of them are "basic_pin_pin", and config extractor recognizes it as PIR.

You said you have a white colored board. If so, then tasmota config is useless for you, white board doesn't have tuyamcu.

Unavailable -

insmod wrote:

>>21631439
Oh, an be sure to activate flag 35 and activate HA discovery again.

Your device is not using TuyaMCU if you managed to extract config, so this won't help.

For unavailable...
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/flags.md

Quote:

35 [HASS] Deactivate avty_t flag when publishing to HASS (permit to keep value). You must restart HASS discovery for change to take effect.

as @insmod said

>>21631881

Okay, so I am not pretty sure how to set these up: For "Status LED", "Battery relay" and "Battery ADC": what channel numbers do I have to enter beside each configured PIN? Just enumerate from 0, 1, 2 ... and so on?

@p.kaczmarek2 , would you mind taking a look at my previous post and please help me set up the LED and „battery relay“ and „battery adc“ like mentioned here:

- Button (channel 0) on P7
- Status LED on P26
- PIR sensor on P8
- Battery Relay on P14
- Battery Max Voltage: 3000
- Battery Min Voltage: 2200
- Battery ADC on P23

Here is battery driver tutorial: [OpenBeken] Battery measurement driver based ADC with voltage divider
It should work well with extracted values.

Thank you @p.kaczmarek2 ❤️ I’ll dig into this!

Another thing I stated today is that retained MQTT state is not kept in HA after HA-reboot. It becomes
unavailable. Either it’s the state itself or the discovery message that maybe needs to be preserved at the broker too?

Is there a retain-flag for the HA-Discovery?

Added after 10 [hours] 16 [minutes]:

>>21636346

Okay, so I have set to channel and to channel in module config section. And I am pretty sure startup command syntax is incorrect (see screenshot below) as get these supposedly incorrect values:

Hi,

I am really sorry to ask again, @p.kaczmarek2 but I'm still having trouble with the battery tutorial. I don't want to be annoying but I am afraid, I am too much of an electronic noob to find a solution even after searching the forum for days now :(

In addition, three of the 25 sensors are now dead: they no longer respond (via their own AP) and cannot be reached even after reflashing.

I suspect that this is related to the fact that frequent opening and closing of the window has led to the batteries being almost completely discharged very quickly. Perhaps the low voltage repeatedly interrupted the boot process towards the end during the last window movements, which may have caused permanent damage.

Therefore, I would like to ask you again to help me before I lose even more devices.

Here's what I've set up so far:



Startup command:


Unfortunately, I am getting incorrect values:


What can I change to measure the battery voltage correctly?


I would appreciate any help!

gramais wrote:

In addition, three of the 25 sensors are now dead: they no longer respond (via their own AP) and cannot be reached even after reflashing.

these can probably be salvaged. have you tried re-flashing full factory backup from 0x0 and then doing OBK conversion again? Did you take backup of each originally, otherwise you'll end up with mac conflicts if single image flashed back to multiple devices

Unfortunately I've stopped backing up each after 10 or so devices were flashed successfully. Would have never thought of them being bricked again after over a dozen of successful flashes.

But I think this isn't that much a problem as they were bought over 2 years ago. So probably there's no benefit for forum members that can't buy these old ones today anymore. Therefore actually I could flash a newer Tuya device bought yesterday with a similar BK7231N which I will publish in the forum later.

Nevertheless I would like to save the older ones before they got lost too. It would be quite a waste of so many devices if I can't get the battery voltage issue under control.

;(

Maybe you got incorrect vdivider value? Maybe you can check with multimeter how is ADC connected.

It is usually recommend to first get Battery driver working withou configuring deep sleep, and then move to deep sleep.

Still, I don't have that much experience with WiFi battery powered devices. WiFi isn't too efficient in general (even with Tuya firmware), probably Zigbee is safer when it comes to battery-powered devices.

The issue with devices not booting is known, but we don't have final solution yet. Of course, restoring flash backup should work. Otherwise we might need to try to reproduce it ourselves, maybe with variable power supply and investigate which part of flash breaks, exactly. Do you have variable power supply, @divadiow ?

Okay, I’ll check ADC with multimeter. Would you mind explaining a noob where to measure exactly and what value to expect…?

❤️ Would be really kind ❤️

Thank you!

>>21638939

@divadiow
But couldn't I just reflash with the one and only backup I ever made, then put openBEKEN on it again and afterwards change its MAC address in openBEKEN?

@p.kaczmarek2
Or is there a way to manipulate the original firmware backup with a randomly generated MAC address?

gramais wrote:

But couldn´t I just reflash with the one and only backup I ever made, then put openBEKEN on it again and afterwards change it's MAC-address in open BEKEN?

yes, true

Hm can you make a photo of your board? How is your ADC connected? How it corresponds to the schematic from tutorial topic?
If you have the version as in this topic, then here is CBU pinout:

Does it connect to two resistors?


I think you can change MAC in OBK for Beken but you will still have imperfect RF calibration (taken from another device)