[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: Good job! Btw, here's the previous door sensor topic: 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:

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?

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: 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: Code: JSONLog in, to see the code And this is the link to the product: Thanks, I've changed the DSTime value to 15 seconds, as it's more than enough to send MQTT data. 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: Code: text Expand Select all Copy to clipboardmqtt:   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 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: 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: I also enabled the quick wifi connect flag to prevent waiting a long time to broadcast the values. This is my template: Code: text Expand Select all Copy to clipboard{   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:    wiki:  } 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 35And: 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

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

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary