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

Hi! I just installed firmware on two of these devices following this guide, but what do these two warnings mean and how can I solve them?

First message means that MQTT is missing so sensor is not able to report data to your Home Assistant. It is currently waiting for MQTT to become online but it will emergency sleep soon to save the battery.

Second message can be ignored, it's normal.

Thank you! How can I disable the first warning (as I will not be using MQTT and home assistant)?



In the settings I cleared the host field but apparently it's still on

It's not a warning, it's just instruction. You have already disabled MQTT.

OK so there is no risk of it going off since there is that countdown...
In any case, I should have already followed all the steps, is there by any chance some configuration to be applied to limit the power consumption?
Or am I good to go with these configurations?



Flags 10, 11, 35 and 37 + startup command: "backlog dstime 30"

You can enter:

in either short startup command (use backlog for multiple commands) or in autoexec.bat

Ok it works great! Just one thing, is it possible to avoid the emergency sleep timer? Even if it goes into emergency sleep can it capture the opening/closing of the door?

Well, by "emergency" I mean it will sleep without reporting via MQTT because there is no MQTT connection. The sleep itself is the same in both cases, no matter whether it's an emergency or not. So, it will still wake up on door event after emergency sleep and it will try to report state via MQTT again...

Um ok, but since I will not use MQTT on the doorsensor but I will use something like this:

Handlers addChangeHandler Channel1 == 0
SendGet http://192.168.1.10:9876/?imsi=0

Will it still send the open/close event even if he is sleeping?
I have a web server listening on that port that receives events from the sensor and handles them via a python script (in my case it sends messages via telegram bot)

The DoorSensor driver is using MQTT by default. It required so it know when it can go back to sleep.

Without MQTT, it will wait for some longer time for MQTT.... and waste your battery. This is not recommended, no one wants to replace batteries often.

We have basically two options.
1) I can try to modify the door sensor driver for you, add some option for that to work without MQTT, but we would need to think about it together and test it well
2) you could also try just a script-based approach, you know, write autoexec.bat file with commands like PinDeepSleep, SendGet, etc and manually just report state via HTTP, maybe also include some "emergency button" in your script so you can still OTA and configure your device later

pincopallino1010 wrote:

Will it still send the open/close event even if he is sleeping?

That's a very strange question, do you know how deep sleep works? How doorsensor driver works? It basically wakes up on IO events, waits for WiFi and MQTT and then reports state (via MQTT) and go to sleep again. So opening/closing door causes a wake up.

You basically want the same, but without the "wait for MQTT" part.

Here is a hint for you: https://www.elektroda.com/rtvforum/find.php?q=PinDeepSleep

Hello team,
I have been doing a lot of mucking around with a couple of these devices that I brought to repurpose. I have not been getting very far with that so started some google research. Then found this post.
You seem to have figured out a lot - so I would like to draw on that.
What I am trying to do is bypass the hall effects switch and trigger it instead through a NC relay. What I am trying to achieve is the NC relay to open when the power is removed from the relay so the device will tell Alexa that the "door is open" - i.e. the power has gone off) to send me an alert. My problem is that the freezer in my garage defrosts when the RCD switch does not reset the power after a brief power cut.
So, if the NC relay is mimicking the hall sensor thinking that the door is closed (magnet nearby), when the power goes off this would have the same effect as removing the magnet.

What wiring changes would you make to the hall effect component to achieve this?

Hoping you can help
Thanks
Gordon

Added after 15 [minutes]:

>>21205190
P.S.
Would I be better off with any wiring changes suggested, to use NC or NO to mimic the hall effects component to minimise the drain on the switch's battery? That is, which would use the least power being used by the switch?

What I am thinking at the moment is:
With no magnet in proximity to the switch, the sensor is probably in the "open" state - so no voltage is travelling from the 3V3 pin to pin 22 - the switch is in "sleep" mode consuming low current and thinks the "window" is closed.
When the magnet is removed (window open) the sensor goes to the "closed" state and current is fed to pin 22 triggering the "window is open" state so it is now drawing current.
So, if I insert the relay between the 3V3 wire and the current terminal on the sensor using the normally closed connection on the relay, and leave the magnet attached, the circuit will stay in the "window closed" state (consuming only standby current) until the relay opens (when the power is removed from the relay) and the switch will then trigger the "window is open" event. Effectively the same as removing the magnet.
So, while the relay is closed (and the magnet close to the sensor) no current is drawn and the switch thinks it is in the "window closed" state.

Is my logic here correct?

Thanks

Hi all,
I have a door sensor like the board in post #18, but a CBU, not a CPU-NL. Trying to write the new firmware after a while I get always a writing error at sector 0xE2000. I tried several baud rates, but it is always the same. Has anyone an idea what is going wrong? Reading the old firmware was ok, but I got no OBK data.

What does your cabling look like and how are you powering the device?

Maybe try lower baud?

>>21274326 I found the solution now, there was a hint in another thread. The problem was the USB-Serial converter. I changed it and it was working.

Hinzugefügt nach 2 [Stunden] 11 [Minuten]:

>>21274970
After the door sensor is working, i found a small problem. On the board is a step up converter from battery voltage to 3.3V. This device is not enabled while the system is active. On the original software this is working. How can i fix it?

Hinzugefügt nach 2 [Stunden] 34 [Minuten]:

Chip Enable of the step up converter is connected to Pin22 (Hardware Pin 10), high active.

I have very similar Door Sensor, also bought it on AliExpress, and also it was described as "AUBESS Door Sensor"


It is also BK7231N FU144JFQ version but the board is FL-S59-V1.3 HD 2245

I was lucky that the cloudcutter method worked for it so I was able to flash it with OpenBeken without even opening it. The problem was that the settings for pins didn't work so I was playing with different options found for similar sensors... and at some point unfortunately my sensor stopped booting.

I may have bricked it but I decided to try flashing it again. Because it is not booting anymore this time I have to do it the hard way by connecting all the pins etc. as described in this topic.

The flash was successful but unfortunately the device is still not booting (the LED never blinks on it, not visible on WiFi, no access point).
Does anyone have any idea how can I make it boot again? Or maybe it is really bricked for good and nothing can really be done at this point?

Here's the device's board pictures:





Here's the flashing result screenshot:



And the full flash log attached.

Maybe you have a starting script that turns on deep sleep on start? But that would still give some log output on TX2...

Or what do you mean by "not booting", are you checking TX2 output?

Anyway... Make a full 2MB backup of current device state (just in case), and then try to flash full 2MB dump from , well, any device (with same chip), you can get dumps here: https://github.com/openshwprojects/FlashDumps
Then check if it boots, later overwrite it with fresh OBK firmware.

Thank you @p.kaczmarek2!
I didn't know flashing with 2MB backup makes any difference compared to flashing OpenBK image but it worked!

I've managed to configure almost all the pins except the button, which is strange. Open/Close detection works, led works, battery level and percentage too, but not the button for whatever reason.
I can live without it since the sensor wakes with any Open/Close but it's just a bit strange.

Here's my pins setting:
"pins": {
"8": "DoorSnsrWSleep_nPup;1",
"14": "BAT_Relay;0",
"23": "BAT_ADC;0",
"26": "WifiLED_n;0"
},

I've tried assigning "Btn" to each single one of the pins but neither worked. Maybe someone has any idea about that?

I have the same door sensor with CBU-NL. Successfully flashed with the latest OpenBeken firmware. Worked for two months, then the batteries died. After replacing the batteries, the device turns on the blue led [and displays the log below in the UART1]. The device does not appear on the network, does not turn on the access point. Re-flashing does not help. The firmware is read (backup) and flashed again without any problems. What could have happened?

This sounds consistent with the experience of others I've seen when the battery gets too low and something happens to the flash to corrupt something. I believe a definite fix is to flash your factory firmware backup in its entirety and convert again to OBK.

i guess i was unlucky. i tried the original firmware, then OpenBeken. i tried cleaning and restoring the RF part, and then OpenBeken firmware again. And now i have a stable bootloop:

Hmm ok. I think I'd make a point of erasing entire flash from 0x0 using BKFIL then flashing whole backup again. I think EF only erases from 0x11000.

Hi, I have this device and I'm new to hacking Tuya devices, my sensor isn't working in HA and I don't know which pin is the correct one, thanks in advance for your help.

UART pads may be on the other side of the board. You need to desolder battery contacts.

>>21641104 Ok thx I'll do it in a minute, but how can I see what is the correct GPIO pins ?

Added after 21 [minutes]:

done

Are you asking for GPIO for flashing or for configuration?

Our easy flasher extracts GPIO roles, do 2MB firmware backup.
https://github.com/openshwprojects/BK7231GUIFlashTool

>>21641213 okay thanks but can I still do it with the firmware already flashed?

If you already flashed it, then you can use this method: