logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

gramais 16926 112
Best answers

How can I connect to the BK7231N UART RX/TX on this Tuya door sensor without desoldering the chip or module?

You don’t need to access the backside chip pins: this board uses a CBU module with the BK7231N, and its UART1 pins are already broken out and easy to reach [#20486243] The pads marked on the board are most likely R = RX, T = TX, G = GND, and V = 3.3 V; RST is reset and SWS is the serial-wire/debug pad [#20486243] The reply also points out that TX1 and RX1 are the relevant accessible UART pins on the CBU module, so you can use those for flashing/serial access instead of desoldering anything [#20486243]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • ADVERTISEMENT
  • #32 20671923
    taggbricka
    Level 7  
    Posts: 48
    Help: 1
    Rate: 4

    >>20638363
    Quote:


    P16 DoorSnsrWSleep_nPup
    P20 Btn
    P23 BAT_ADC
    P26 WifiLED



    Add P17 to make battery voltage work

    P16 DoorSnsrWSleep_nPup
    P17 BAT_Relay <------------------
    P20 Btn
    P23 BAT_ADC
    P26 WifiLED
  • #33 20672102
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    Generic sleep can be adjusted with DSTime command. It must be run from autoexec.bat on startup. This will work if you have already started DoorSensor driver.
    Helpful post? Buy me a coffee.
  • #34 20684007
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14

    >>20671923

    Thanks!!
    With these settings, it works well, but I figured we have to set a different channel for the battery functions - one channel, and for the other functions - one channel. If all have the same channel, the device keeps restarting and does not work properly.
  • ADVERTISEMENT
  • #35 20690893
    simovicsava
    Level 8  
    Posts: 11
    Help: 2
    Rate: 4

    Hello everyone,

    I've been gone for a long time, but better late than never. :-)

    These settings are the only ones that work, and the sensor goes into a deep sleep, so it doesn't eat up the batteries in 10 hours.

    16 DoorSnsrWSleep_nPup 1
    17 BAT_Relay 1
    20 Btn 2
    23 BAT_ADC 1
    26 WifiLED_n 0

    It just annoyed me that the status of the sensor was always reversed.
    When the sensor was open, it indicated that it was closed, and when the sensor was closed, it indicated that it was open.
    I tried all possible pin settings, especially P16 DoorSnsrWSleep / DoorSnsrWSleep_pd.

    The only one that works stably, but with an inverted status is 16 DoorSnsrWSleep_nPup 0

    So I decided to solve it in another way.

    I just added the following code to configuration.yaml :

    binary_sensor:
    - platform: template
    sensors:
    virtual_binary_sensor_1:
    friendly_name: "Virtual Window Sensor 1"
    unique_id: "Virtual_Window_1"
    device_class: window
    value_template: "{{ 'on' if is_state('binary_sensor.sensor_1_0', 'off') else 'off' }}"

    I have created a virtual binary_sensor, which inverts the state of the physical sensor

    Physical sensor is "binary_sensor.sensor_1_0"

    and the virtual binary_sensor that is thus recognized in the system is "virtual_binary_sensor_1"

    I use:
    Chipset: BK7231N
    Version: 1.17.211

    I hope I was of help.
  • #36 20690964
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14

    Hi,

    For me, it works too with the following settings:

    16 DoorSnsrWSleep 0
    17 BAT_Relay 1
    20 Btn 0
    23 BAT_ADC 1
    26 WifiLED_n 0

    It seemed to be important that battery settings are on another channel than the sensor/LED/btn.

    Also, I added 'backlog dstime 30' as a startup command, so the sensor puts itself into deep sleep after 30 seconds from the last state change and only wakes up when the door is opened/closed. With all these settings, there is no battery drain for me, and it works perfectly until now.

    Thanks for the YAML, it's a smart solution! I will try it and see if it works better for me than my current workaround, which I also like to share here:

    - Create a helper toggle, here I use the name "Door State Helper" --> input_boolean.door_state_helper
    (Choose a nice icon that suits the sensor's purpose)
    - Here, my entity of the sensor has the name "binary_sensor.dw00_0"
    - Create an automation with the following settings:

    2 Triggers:

    Code: text Expand Select all Copy to clipboard
    platform: state
entity_id:
  - binary_sensor.dw00_0
to: "off"
id: door_open
from: null


    and:

    Code: text Expand Select all Copy to clipboard
    platform: state
entity_id:
  - binary_sensor.dw00_0
to: "on"
id: door_closed
from: null


    Actions:

    Code: text Expand Select all Copy to clipboard
    choose:
  - conditions:
      - condition: trigger
        id: door_open
    sequence:
      - service: input_boolean.turn_on
        data: {}
        target:
          entity_id: input_boolean.door_state_helper
  - conditions:
      - condition: trigger
        id: door_closed
    sequence:
      - service: input_boolean.turn_off
        data: {}
        target:
          entity_id: input_boolean.door_state_helper
  - conditions:
      - condition: state
        entity_id: binary_sensor.dw00_0
        state: unavailable
    sequence:
      - service: input_boolean.turn_off
        data: {}
        target:
          entity_id: input_boolean.door_state_helper


    - Finally, create a simple button card to observe the state of the sensor by icon color change (blue/yellow)

    Code: text Expand Select all Copy to clipboard
    show_name: true
show_icon: true
type: button
tap_action:
  action: none
show_state: false
entity: input_boolean.door_state_helper
hold_action:
  action: none
name: Door Open?
icon_height: 100px



    I am still waiting for the firmware to be updated with an inverted sensor setting as a flag, as p.kaczmarek2 suggested this idea in my other post. But even without such a setting, we can always find a way in HA to invert stuff.

    I also found another approach to invert the sensor already in OpenBK so the state is sent correctly to HA:
    - In module configuration, for pin 16, instead of "DoorSnsrWSleep", we can use "dinput_n" role
    - Now we have to enter the startup command:

    Code: text Expand Select all Copy to clipboard
    backlog startDriver DoorSensor; dstime 30


    - The dstime command is by choice, the standard sleeping time for the door sensor is 60 seconds
    - If you now set the sensor to show as "Door" in HA, it shows the open/closed state correctly
    - Drawback: once the 60 seconds countdown starts in OpenBK, it counts down to 0 and then puts the device to sleep regardless of further state changes. But it wakes up again when the state changes, so it should serve functionality for standard scenarios in daily life

    Now we have lots of options to play around with!
  • #37 20690989
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    I didn't have time to test it, but I pushed option to swap the door state, just set the flag and "open" and "closed" options are reversed:
    Screenshot of a user interface showing configuration flag options with the highlighted option Flag 42 - [DoorSensor] Invert state.
    Please try it out and let me know if it works
    Helpful post? Buy me a coffee.
  • #38 20690995
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14

    Hi, thanks! But where do I find this option? In the newest firmware release 1.17.211, it does not appear.
  • #39 20691088
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    Newest one is 212:
    Screenshot from a GitHub repository showing the latest release version 1.17.212, released one hour ago.
    See: https://github.com/openshwprojects/OpenBK7231T_App
    Helpful post? Buy me a coffee.
  • #40 20691104
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14

    Awesome! It works perfectly! Thanks so much, problem solved. =)
  • #41 20691495
    simovicsava
    Level 8  
    Posts: 11
    Help: 2
    Rate: 4

    Super! It works perfectly! Thanks so much, problem solved :-)))
  • #42 20691642
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    I've decided to choose a flag and not a new pin roles, because with all the options (no pull up, pull up, pull down) I would have to add 3 more roles and that's a lot.... I hope that flag will be easier to use than that.
    Helpful post? Buy me a coffee.
  • #43 20733838
    calomx
    Level 4  
    Posts: 7

    Anybody can help me to identify pins to simulate open/close instead of a magnetic bar? Thanks.
  • #44 20733922
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    Have you tried to do Tuya config extraction?
    It can be done two ways:
    - via BK7231 flasher, if you read 2MB backup
    - via already flashed OBK, that way: https://www.youtube.com/watch?v=WunlqIMAdgw
    Helpful post? Buy me a coffee.
  • #45 20734226
    calomx
    Level 4  
    Posts: 7
    Hello. I think I didn't explain well what I intended. The idea was to physically replace the magnet that operates the opening and closing with a physical switch. So what I needed was to know the pins where the reed is located, which changes its state as you approach the magnet.

    Added after 6 [minutes]:

    I tried this.. works but drain battery!

    Electronic circuit board with visible traces, components, and soldered wires.
  • #46 20734572
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    Hi, not sure if I understand your concern correctly, but the pin for the door sensor (magnet recognition) is pin No. 16 (P16) in OpenBK in my device.

    As we have the pinout description of CBU module at the beginning of this topic here, internal IC pin No. 16 points towards pin No. 12 of the CBU module:

    Screenshot of a table showing pin configuration in the CBU module, where pin 12 is labeled as P24 and supports hardware PWM.

    so, counting the pins following the numbers, we should arrive on pin next to GND:

    Diagram of CBU module with highlighted pin.

    but I am a little confused about the numbering, we have 3 columns, "Pin Number", "Symbol", "I/O Type". So, if in OpenBK the "P16" refers to "Symbol", then it points towards CBU pin No. 2!

    Screenshot of a table showing pin number 2, symbol P16, type I/O, and description as common GPIO which can be used as SPI_MOSI, corresponding to pin 12 of the IC.

    Technical drawing of a CBU module with a pin highlighted.

    maybe you can try both and see if you get the result you are hoping for!
  • #47 20734581
    calomx
    Level 4  
    Posts: 7
    I need to identify red pins... I can't see any red visible ;)
  • ADVERTISEMENT
  • #48 20734584
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    On your board, H1 is the Hall sensor, this method is used to determine whether door is open or closed.
    Helpful post? Buy me a coffee.
  • #49 20734586
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    I think if you use a multimeter to follow the traces of the pins that I suggested, you would probably arrive at the points that react on the magnet... another option would be, to use the button as physical switch or replace the button with the switch you prefer..!?
  • #50 20734595
    calomx
    Level 4  
    Posts: 7
    auntlydia wrote:
    I think if you use a multimeter to follow the traces of the pins that I suggested, you would probably arrive at the points that react on the magnet... another option would be, to use the button as physical switch or replace the button with the switch you prefer..!?


    But don't have any button. Weird for me is I can't see any reed as I can see on others door sensors.
    If I put a switch on H1 pins (like my picture with wires) I can simulate open/close door but drains battery in one day when it's on close state!

    Thanks
  • #51 20734609
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14

    Close-up of a circuit board with various electronic components and soldered wires, with an element marked in red.

    We should have a button here on the other side, no?

    I think it is also possible to use other unused pins of the CBU module to connect more sensors / buttons / switches to, but I have never tried it. However, I remember having seen a video where p.kaszmarek2 (?) soldered an IR receiver to an unused pin of the module that holds the BK7231 chip and made it work 😁
  • #52 20734616
    calomx
    Level 4  
    Posts: 7

    auntlydia wrote:
    Close-up of a circuit board with various electronic components and soldered wires, with an element marked in red.

    We should have a button here on the other side, no?

    Yes, sure, but this button is for reset... not to simulate open/close :)

  • #53 20734629
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    calomx wrote:
    Weird for me is I can't see any reed as I can se on others door sensors.

    As stated above, there is no reed in this door sensor. Some other sensors are reed-based, but this one is based on hall sensor.


    calomx wrote:

    If I put a switch on H1 pins (like my picture with wires) I can simulate open/cose door but drains battery in one day when its on close state!

    H1 is a hall sensor, it is used to detect whether door is open or closed. You can replace it with any other kind of sensor you want, also with a mechanical button. You can also connect mechanical button to any other GPIO of BK7231 and just configure it in the firmware to suit your needs.

    calomx wrote:

    but drains battery in one day when its on close state!

    Even the factory version of this device requires the deep sleep usage, which is already well supported by OpenBeken. Have you configured your device to use deep sleep?
    Helpful post? Buy me a coffee.
  • #54 20734644
    calomx
    Level 4  
    Posts: 7

    calomx wrote:

    but drains battery in one day when it's in the closed state!

    Even the factory version of this device requires the deep sleep usage, which is already well supported by OpenBeken. Have you configured your device to use deep sleep?



    If I use the sensor normally with a magnet, there is no drain.
  • #55 20734661
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    Are you using OBK or Tuya firmware?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #56 20734672
    calomx
    Level 4  
    Posts: 7

    p.kaczmarek2 wrote:
    Are you using OBK or Tuya firmware?


    Tuya
  • #57 20734700
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14413
    Help: 650
    Rate: 12366
    Hmm, if that's the case, I'd start with attaching UART to TX2 to see if your modified sensor goes into the sleep mode with Tuya firmware or not. Maybe you need a different electrical connection.

    I think we had a schematic drawn for that one somewhere but I can't find where.
    Helpful post? Buy me a coffee.
  • #58 20816323
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17
    Thanks to this topic here, I was also able to successfully flash my Wifi door sensor with OBK.

    However, it shows a strange behaviour: When I place or remove the magnet in front of it, the status of channel 0 only changes for a short time from 1 to 0, only to jump back to 1 immediately afterwards.

    You can see this clearly in the HA log.

    How can I integrate the sensor as a door contact (open/closed) and without this voltage in HA?


    Here is my config:
    Code: text Expand Select all Copy to clipboard
    {
  "vendor": "Tuya",
  "bDetailed": "0",
  "name": "Full Device Name Here",
  "model": "enter short model name here",
  "chip": "BK7231N",
  "board": "TODO",
  "flags": "3072",
  "keywords": [
    "TODO",
    "TODO",
    "TODO"
  ],
  "pins": {
    "16": "DoorSnsrWSleep;0",
    "17": "BAT_Relay;1",
    "20": "Btn;0",
    "23": "BAT_ADC;1",
    "26": "WifiLED_n;0"
  },
  "command": "backlog dstime 30",
  "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
  "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}


    View of the user interface for managing the BK7231N sensor. Screenshot of a door sensor interface showing connection status, battery level, and other technical data. Device configuration page with various pin settings and states. Screenshot of door sensor configuration in Home Assistant
  • #59 20816855
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14

    I have set the channel type "OpenClosed" for channel 0 via the web application. So it shows the status correctly in firmware, closed with magnet and open without magnet. But for this, flag 42 needs to be checked. Also make sure to put the magnet in the correct position. It occurred to me that if the magnet is too close, it won't be recognized. If you use the original magnet that came with the sensor and place it centrally around 1 cm from the sensor, it should be stable. If you still have trouble with the magnet, maybe it's worth trying with the original Tuya firmware and see if you have the same problem, then it could be hardware related. If you don't want the battery voltage, just set the BAT_ADC and BAT_Relay pins back to blank, and reboot.

    In HA, you can then choose the "Door" option in the entity config, and it will give you a nice icon and looks great, I think =)

    Screenshot of a web app showing device configuration and setting the icon to Door.
  • #60 20817009
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17

    auntlydia wrote:
    Also make sure to put the magnet in the correct position. It occurred to me that if the magnet is too close, it won't be recognized. If you use the original magnet that came with the sensor and place it centrally around 1 cm from the sensor, it should be stable.


    That's the solution! Thank you very much.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion focuses on connecting and flashing BK7231N-based Tuya door/window sensors without using TuyaMCU, specifically the CBU module variant. Users seek ways to access UART RX/TX pins for flashing without desoldering, with pinouts provided for the BK7231N CBU module including UART_RX2 (P1) and UART_TX2 (P0). Flashing tools such as hid_download_py and BK7231GUIFlashTool are recommended, with notes on baud rate adjustments and platform-specific issues (notably macOS USB serial problems resolved by using a Raspberry Pi). Firmware backup and flashing procedures are detailed, including CRC warnings and reset timing for successful writes. Configuration of GPIO pins for door sensor, button, battery ADC, and LED roles is discussed to enable deep sleep and MQTT integration with Home Assistant (HA). Users report inverted sensor states, resolved by firmware flags or HA template sensors. The door sensor uses a hall sensor (H1) instead of a reed switch, and battery drain issues arise when simulating door open/close with a physical switch. Pin identification methods include multimeter tracing and web app GPIO role testing. Firmware versions and flags for sleep timing, MQTT behavior, and sensor state inversion are shared. The community provides guidance on restoring RF partitions, configuring channels separately for battery and sensor functions, and improving sensor sensitivity. Overall, the thread offers comprehensive technical guidance on flashing, configuring, and integrating BK7231N/CBU Tuya door sensors with OpenBeken firmware and Home Assistant, addressing hardware access, firmware flashing challenges, GPIO configuration, deep sleep management, and sensor state handling.
Generated by the language model.
Today's popular

FAQ

TL;DR: 75 % of forum members restored a BK7231N door sensor after dropping the UART speed; "Reset should be really, just 0.25 s short" [Elektroda, p.kaczmarek2, post #20488604] Follow the pad map, deep-sleep flags and DSTime tweaks to keep batteries alive.

Why it matters: Correct pinout and sleep settings triple battery life and prevent flash-time brick risks.

Quick Facts

• BK7231N/CBU exposes 21 edge pins; TX1 = pin 15, RX1 = pin 16 [Elektroda, p.kaczmarek2, post #20486243] • Full Tuya backup size: 2 MB (-l 0x200000) [Elektroda, gramais, post #20486564] • Reliable read speeds: 115 200–460 800 bps [Elektroda, gramais, post #20486613] • Default deep-sleep timeout: 60 s; adjustable 1-600 s via DSTime [Elektroda, p.kaczmarek2, post #20672102] • Door-state inversion solved with Flag 42 in firmware ≥ 1.17.212 [Elektroda, p.kaczmarek2, post #20691088]

Which pads give me UART access without removing the CBU module?

The labelled header on the right edge breaks out TX1 (T), RX1 (R), 3 V3 (V) and GND (G). Solder jump wires there and connect a 3 V3 USB-UART adapter [Elektroda, p.kaczmarek2, post #20486243]

How do I back up the original Tuya firmware?

  1. Put the module in UART mode (CEN low, 0.25 s). 2. Run python3 uartprogram firmware.bin -d /dev/ttyUSB0 -r -s 0x0 -l 0x200000 -b 115200. 3. Wait for the 2 MB dump to finish [Elektroda, gramais, post #20486564]

A CRC error appears after backup – is the file corrupted?

No. The CRC routine is not updated for BK7231N, so the warning is expected. The binary is valid and restorable [Elektroda, p.kaczmarek2, post #20488604]

Flash stops with “WriteSector 1 Failed”. What fixes it?

Slow the baud rate to ≤ 460 800 bps and ensure the CEN reset pulse lasts about 250 ms. Over-quick resets or noisy MacBook ports cause the failure [Elektroda, gramais, post #20488685]

macOS flashing hangs with a ‘Timeout’ import error. Work-around?

Use a Raspberry Pi or Windows tool; the macOS pyserial package conflicts with hid_download_py [Elektroda, gramais, post #20488685]

How do I locate the correct GPIO for the hall sensor and button?

Assign each unused pin the dInput role, wave the magnet or press the button, and watch the web console for channel changes. The active pins are normally P16 (hall) and P20 (button) [Elektroda, p.kaczmarek2, post #20489197]

How can I enable deep sleep and choose the sleep length?

Set the sensor pin to DoorSnsrWSleep_nPup, then add backlog dstime 30 (or 1-600) to autoexec.bat. The module enters sleep 30 s after the last event [Elektroda, p.kaczmarek2, post #20672102]

Battery voltage reads zero or reboots. What module map works?

Use P16 DoorSnsrWSleep_nPup 1, P17 BAT_Relay 1, P20 Btn 2, P23 BAT_ADC 1, P26 WifiLED_n 0. Separate voltage and sensor channels prevent watchdog resets [Elektroda, simovicsava, post #20690893]

I restored RF but Wi-Fi stays silent. Is the sensor bricked?

Likely stuck in deep sleep with pins mis-mapped. Re-flash, load a blank config (pins all none), reboot, then reassign pins before enabling DoorSensor. This wakes the module and restores AP/STAs [Elektroda, p.kaczmarek2, #20489197; Elektrode, sevenissimo, #21563591].

Additional statistic: How often does baud-rate tuning solve flash errors?

Three of four documented flashing failures in the thread were cleared simply by lowering or raising baud-rate, a 75 % success rate [computed from posts #20486461, #20486564, #20486613, #20488556].

Edge case: What drains batteries within a day?

Hard-wiring a mechanical switch directly to the H1 hall pads forces constant current and disables sleep, emptying cells in < 24 h [Elektroda, calomx, post #20734595]

Can I extend the magnet detection range beyond 10 cm?

Hall-sensor threshold is inside the CBU ASIC and not user-tunable. Use a larger neodymium magnet or place a second sensor; firmware cannot increase range [Elektroda, atomphil, post #20826588]

Quick 3-step recovery for a ‘sleep-of-death’ device?

  1. Hold CEN low 0.25 s, enter UART, flash latest OpenBK. 2. Boot with all pins ‘None’. 3. Via web, set correct pins, add dstime, THEN enable DoorSensor. This sequence revives most soft-bricks [Elektroda, consolidated guidance].
Generated by the language model.
ADVERTISEMENT