[BK7231N/CBU] Door sensor without TuyaMCU - easy flashing and configuration guide

Question

Hi, first of all thank you for this amazing community and firmware, finally I got rid of Tuya apps thanks to OpenBK! I wanted to share my user experience on this device, since I successfully flashed and set up two of these recently, and they both worked exactly the same way. I believe it is the...

spln · Accepted Answer

>>20837792I also got a similar sensor, the PCB looks the same, but with different pin configuration so created a separate topic for it: ONENUO Tuya Wifi Door Sensor - 19JWTThe HAL sensor has neither pull-up nor pull-down, battery is read through a switchable voltage divider like above.

p.kaczmarek2 · Answer

Very nice and detailed guide. I have split it into separate topic, as it really deserves to be seen.

I am happy to see people making good use of "configure at flash time" feature that I've recently added to our flasher:
https://github.com/openshwprojects/BK7231GUIFlashTool
Good job!

Btw, here's the previous door sensor topic:
https://www.elektroda.com/rtvforum/topic3982902.html

Regarding the guide itself - I will just give here some hints:
- make sure to configure both sensor pin and button pin. Button pin can be used to emergency-wakeup device without moving door
- if device does not wake up from one of the states (for example closing doors wakes it up, but opening doesn't), try entering DSEdge setting in short startup command or autoexec.bat, there are 3 possible options for that, see our docs

Our docs:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md

auntlydia · Answer

Thanks for bringing this forward - I must say I enjoyed a lot playing around with your software and it actually works great! I flashed temperature/humidity sensors and hidden switch relays as well - it all works flawlessly once the configuration is done properly.
The option to preconfigure in the Windows flashing tool is very useful - especially for low power profile devices, as they seem troublesome to set up when we always have to find a workaround to reach the web interface during the short power-on intervals.

Now I still have two questions:
1. Is it possible for you to add the inverted DoorSnsrWSleep role to the list? In HA, there is always a way to invert buttons or actions, but the Door option is always the wrong way, so the status shows "Open" (which means On for the sensor) when the magnet is near the module, and "Closed" when the magnet is away. An inverted option in the module would solve this problem. I have tried the nPup and pd options but there is no difference. I realize in the other post this was already mentioned, however, I couldn't find the related setting in the current 7231N firmware.

2. With all the low-powered modules, I am running into some problems. After some troubleshooting, I am certain that it has to do with the MQTT connection. Whenever the sensors quickly disconnect (sleep) after having sent updated data to the server, some other devices (some connected to MQTT, some not but also managed by HA integrations) in my home network lose the connection shortly and reconnect. With a number of sensors installed, this can get very annoying, since some other devices rely on a stable connection. The router itself should not be the problem. I want to further look into other forums about this problem, too, but maybe you have some idea about this, is this a typical issue?

Thanks again, your work with this is very much appreciated!

p.kaczmarek2 · Answer

There are multiple DoorSnsrWSleep types already and adding invert would require us to duplicate them all.

What about a different approach: I can add a flag for you, flag saying "invert door sensor read state", which will work for all the door sensor types?

It would be easier to maintain and document.

Hmmm, that second issue seems very strange. I haven't seen anything like that before. The first thing I would suggest is to check if the problem persists without MQTT. Maybe... maybe your router doesn't like extra client connecting suddenly and then leaving?

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

Helpful post? Buy me a coffee.

auntlydia · Answer

Hi, thanks! Adding such a flag would be a great idea! I will test it once it's possible and give you feedback if it works.

As for the other issue, it could be quite complex. I found a thread that describes a similar problem: https://community.home-assistant.io/t/constant-mqtt-devices-disconnections-socket-error/83477

and it mainly concerns Tasmota devices and a Tapo camera. Both of these devices disconnect and reconnect to HA once one of the door or temperature/humidity sensors close their connection. The router seems not to be the problem because the devices don't lose their WiFi connection but the connection/availability to Home Assistant. It has to be something with MQTT or another Home Assistant integration. I will dig into that further because I need to fix this problem or else my smart home doesn't work properly. But it is another topic. Maybe keep this topic here to the door sensor setup, and I can open another topic once I have more information on it.

simovicsava · Answer

Hello everyone,Here you can find the correct settings, and a workaround to show the state of the sensor correctly: hope I was of help.

auntlydia · Answer

Thanks! As of the newly updated version 1.17.212, it is possible to invert sensor status with flag 42. It works, and the HA workaround is no longer necessary. Very nice!

As for my other problem I mentioned before, it turned out to be a router problem, so there was nothing wrong with the sensors, firmware, MQTT, or Home Assistant. All good. Thanks again!

simovicsava · Answer

Thanks! With flag 42, it works great and the HA workaround is no longer necessary!

woszu · Answer

Hello
I have a similar sensor, but a little differently organized hardware-wise (different BK pins). I've already arrived at what and how and it works nicely, but.....
I wanted to use the sensor to report the opening of a letterbox. Unfortunately, the mailman opens the box for too short a time for the sensor to report anything. After a deep sleep, it needs some time to connect. Is there any way to set a flag that there was a change in input state after waking up and before connecting?

p.kaczmarek2 · Answer

From what I remember, the latest version of the DoorSensor driver (the one that's on Github) keeps an eye on the situation where "the door was opened and closed before the sensor connected to WiFi" and even then it should report the status correctly. We tested this with colleague @nihildiximus .

Do you use the DoorSensor driver, or did you configure the whole thing manually, with a script?

woszu · Answer

I am using DoorSensor. The problem is that moving the magnet away (changing the input to OFF) wakes up the BK, but after a while reapplying the magnet changes back to ON before the device connects to the HA, and when it does, it reports the ON state (which is the current state), and I want to report this temporary OFF

auntlydia · Answer

Hi, based on the previous answer, this problem should be solved with the reporting of temporary states between WiFi connections..!? Have you updated to the latest OpenBK?

Also, I thought about a similar idea: to have a notification once a post has been inserted into my mailbox. Since my mailbox is not to be opened by anyone else than myself, the post is just inserted into it through a slot. How about installing a wireless motion sensor into the mailbox? It would report motion triggered by an inserted letter or packages.

Another idea: do you have the option to supply permanent wired power to the sensor? Then you would not need to set the sensor to Sleep-state, but could use a normal input with instant recognition and permanent WiFi connection.

p.kaczmarek2 · Answer

I am confused because I am sure that we've fixed that issue with @nihildiximus and that the door sensor indeed reports the state from before it connected to MQTT.

See:

After getting WiFi and MQTT, for the first 3 loops (first 3 seconds), it force-publishes the initial states of pins which is queried in new_pins.c ...

Maybe I need to check it myself, find some sensor...

@woszu - what about just reporting a custom value on every reboot? Doing a publish command or a SendGET in autoexec.bat?

woszu · Answer

And yet it works. I fired up MQTT Explorer and it does indeed report a 1 for 3s and then goes back to zero. Sorry for the confusion, I checked on the BK settings page and didn't see it there .

p.kaczmarek2 · Answer

Thanks for the info, as I was already wondering how it could have broken down since the last tests. And in that case it's good to hear that it continues to work.

If you have problems you can always manually do from autoexec.bat MQTT publish or HTTP GET.

If you have any other questions or need some functionality, go ahead and write.

emrecetinkaya86 · Answer

Hi all,First of all, thank you all for sharing information here. It is very much appreciated!I have the same device and successfully burned the firmware on it. I applied the template and tried all the pin configurations described here, but no matter what I do, I get the following result:- On the index page, the sensor value doesn't change no matter what I do (changing magnet positions).- In HA, the sensor sends a turned on/turned off message every 10 seconds while it's powered on, by itself, without any change with the magnet.It seems like the pin number 16 may be wrong, or what am I missing?Thanks

p.kaczmarek2 · Answer

Maybe they changed something., Try to extract the template (but disable door sensor driver for that time):

emrecetinkaya86 · Answer

Hi,Thanks for the answer. I've just tried but from binary, it says no meaningful data: And when I paste JSON in web app: I'm stuck... This is my first time with OpenBeken and I don't want to give up...

emrecetinkaya86 · Answer

>>20835677Hi @p.kaczmarek2 and all,Yes they changed something, which is the pin number of hall effect sensor. At first I'm happy that I'll contribute to the community with this experience for the first time, with my pleasure! What to do to add this change what I explained below to the templates?After looking twice, I've recognized that the module on the device is CBU-NL instead of CBU. This is how the module looks like:Also, the board is different than the one in this topic and others in the forum. I've traced the hall effect sensor pin from it to module pin and it corresponds to pin 22, instead of 16! And it's pulled down. Then I've changed my pin configuration (other pins are still the same, only the hall effect sensor pin number has been changed):I've also changed the channel type of channel 0 which hall sensor pin included to openclosed, so I can see on the index page the status more clearly.The only thing remaining now is, when the module is awake after pin change, it sends sensor turned on/off messages every 10 seconds and without any change. And the sensor value came automatically doesn't show the correct value, I've copied sensor yaml lines from OpenBeken web to configuration yaml in HA and it shows the correct value.And my last question is, when the module wakes up, it stays awake for at least a minute and then sleeps. Is there any way to set it up like do your job and sleep? Sorry again if I ask something which was explained before, as I'm a newbie.Enjoy

p.kaczmarek2 · Answer

Thanks for the info. Can you include template from the Web App so I can add it to devices list?

I think you can set a DSTime variable to adjust the time how long it's up.

Regarding on and off messages, is the status read in the OBK panel correct?

PS: I think you can change channel name from that "1" string to any other with setChannelLabel command

emrecetinkaya86 · Answer

Hi @p.kaczmarek2,

Here is the template:

Log in, to see the code

And this is the link to the product: https://www.aliexpress.com/item/1005005216868...der_detail.order_detail_item.3.63b443cepjkRkP

Thanks, I've changed the DSTime value to 15 seconds, as it's more than enough to send MQTT data.

Quote:
Regarding on and off messages, is the status read in the OBK panel correct?

I really don't have an idea about the answer... After I made MQTT configuration on the OBK web, I triggered discovery and those values showed up. And the value of "1" sensor doesn't change, as I said I manually added the sensor (which works very well) with this configuration to the YAML file of HA:

mqtt:
  binary_sensor:
    - unique_id: "doorsensormain_binary_sensor_0"
      name: "Maindoor"
      state_topic: "doorsensor/0/get"
      qos: 1
      payload_on: 1
      payload_off: 0
      availability:
        - topic: "doorsensor/connected"

Quote:
PS: I think you can change the channel name from that "1" string to any other with the setChannelLabel command

It's very useful information, thanks! I'll change it as soon as I make it work when the sensor value changes.

Thanks!

Xinayder · Answer

I have a very similar sensor I bought from AliExpress, branded as AUBESS: https://www.aliexpress.com/item/1005004699337230.html

I used the Windows flasher tool and it worked perfectly, it even loaded the configuration retrieved from the original firmware.

I also checked the door sensor guide on the forums and had to do a quick tweak on my sensor. By default, the battery relay/adc were set to the same channel as the door sensor, so whenever the HAL sensor was triggered, it would go to the opposite state because of the relay. To fix this, I set the battery ADC and relay to a different channel.

The HAL sensor pin was set to DoorSnsrWSleep (no pull down or pull up), as instructed in the guide: https://www.elektroda.com/rtvforum/topic3960149.html

I also enabled the quick wifi connect flag to prevent waiting a long time to broadcast the values. This is my template:

{
  "vendor": "Tuya",
  "bDetailed": "0",
  "name": "AUBESS Smart Wifi Door/Window Sensor (no TuyaMCU)",
  "model": "enter short model name here",
  "chip": "BK7231N",
  "board": "TODO",
  "flags": "1152",
  "keywords": [
    "TODO",
    "TODO",
    "TODO"
  ],
  "pins": {
    "16": "DoorSnsrWSleep;0",
    "17": "BAT_Relay;2",
    "20": "Btn;1",
    "23": "BAT_ADC;2",
    "26": "WifiLED_n;0"
  },
  "command": "",
  "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
  "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}

EDIT: I've also attached the original firmware extracted from the sensor.

pincopallino1010 · Answer

>>20683982Hi, @auntlydia @pkaczmarek262! I have 9 of these devices and am preparing to modify them. Once you follow this guide do you need to set/do anything else from the web interface? Is there anything to tweak/install to better manage the battery consumption of the devices?Also, how can I do to send a request to a webserver as soon as a port opening is detected?

pincopallino1010 · Answer

Nvm I was able to flash them without any problems! Thanks a lot for the guide

Just a couple of questions @auntlydia @pkaczmarek262 (sorry for the tag), is there anything to tweak/install to better manage the battery consumption of the devices? Is it possible to totally disable MQTT since I do not use it?
Also, how can I do to send a request to a webserver as soon as a door open/close is detected?

Thank you in advance!

pincopallino1010 · Answer

>>20683982Hi @auntlydia @p.kaczmarek2 (Sorry for the tag again). I flashed the firmware on one of these devices by following this guide (without entering any configuration via the tool) and unfortunately I can't figure out why the device seems to be not working. It boots but whatever configuration I enter (pin, flag, wifi...) this is not maintained and also the web application page does not load. The screen I end up in when I connect to the device is as follows (photo). Even if I enter the configurations through the tool nothing seems to change, plus the led doesn't seem to light up anymore...Can anyone help me? Thanks!

divadiow · Answer

I'd start by flashing an up-to-date version of OBK. The one in the screenshot is from August.

p.kaczmarek2 · Answer

Wait, do I understand correctly, you haven't configured it? I can see no drivers running, nothing is set... you need to configure it first, I guess.

pincopallino1010 · Answer

@divadiow I had already tried to install the latest version but it gave me the same problems, so I tried to install the one that is used in the guide

@p.kaczmarek2 Initially I followed the procedure from top to bottom (entering the configurations via the tool) but I was having the same problems, so I thought of entering them "by hand" after flashing the firmware but nothing... for example if I set the wifi network to connect to it doesn't work when rebooting and it keeps creating its wifi to connect. Same with the pins, every time I reboot the device all the fields reset.

What does it mean: "0 drivers active, total 35"
And: "boot incompletes 1 (might change to 0 If you wait to 30 sec)!"

Maybe they are the problem but I really don't understand what is going wrong....

insmod · Answer

Hardware mod, U2 is CHT8305. Now waiting for simultaneous pin and timer deep sleep support P7->CHT8305_SCK P8->CHT8305_SDA

Option	Best use	Main advantage	Main drawback
Preconfigure in BK7231GUIFlashTool	First flash of sleeping sensors	Works before the short wake window closes	Requires correct pin map upfront
Configure later in web app	Bench testing on stable power	Same end result	Harder on devices sleeping after 30–60 s
DoorSensor driver	MQTT/Home Assistant workflows	Handles wake, report, then sleep	Waits for MQTT by design
Script with PinDeepSleep + SendGET	HTTP-only alerts	No MQTT dependency	Needs manual logic and testing

[BK7231N/CBU] Door sensor without TuyaMCU - easy flashing and configuration guide

Topic summary

FAQ

Quick Facts

How do I flash an AUBESS or no-name BK7231N/CBU door sensor with OpenBeken using BK7231GUIFlashTool and preconfigure it during flashing?

Why do the battery relay and BAT_ADC need to be assigned to a different channel than the hall sensor in these Tuya door sensors?

What is DoorSnsrWSleep in OpenBeken, and how is it different from configuring a normal input pin manually?

What is DSTime in OpenBeken, and how does it affect how long a low-power door sensor stays awake before sleeping?

How can I invert the open/closed state of a BK7231N door sensor in Home Assistant using OpenBeken flag 42?

What should I try if my BK7231N door sensor wakes on one state change but not the other, and how does DSEdge help?

Why would a flashed door sensor keep sending on/off MQTT messages every 10 seconds even when the magnet position does not change?

How do I find the correct GPIO or hall sensor pin on a Tuya door sensor when the published template uses P16 but my board actually uses P22 or another pin?

What is the best way to extract or recover the original Tuya GPIO template from a BK7231N device before or after flashing OpenBeken?

Why does my OpenBeken door sensor show '0 drivers active' or fail to save Wi-Fi and pin settings after reboot?

How can I reduce battery usage on an OpenBeken door sensor, including PowerSave 1, backlog DSTime, and other low-power flags?

OpenBeken DoorSensor driver vs a script-based approach with PinDeepSleep and SendGET — which is better if I want HTTP notifications instead of MQTT?

How does OpenBeken handle a door that opens and closes before Wi-Fi or MQTT connects, such as for a mailbox flap or very short trigger event?

What wiring changes would be needed to replace the hall effect sensor with an NC or NO relay so a BK7231N door sensor can report a freezer power-loss event?

How can I fix a BK7231N door sensor that flashes successfully but will not boot, enters safe mode or a boot loop, or seems corrupted after low battery or bad configuration?