logo elektroda
logo elektroda
X
logo elektroda

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

gramais 11862 108
ADVERTISEMENT
  • #91 21639525
    gramais
    Level 4  
    >>21639501

    Sure, here it comes:


    [BK7231N/CBU] Door sensor without TuyaMCU - how to connect to UART RX/TX
  • ADVERTISEMENT
  • ADVERTISEMENT
  • #93 21639569
    gramais
    Level 4  
    >>21639526

    Just to be sure: would this one be a resistor?


    An illustration showing electrical symbols, including a resistor symbol.
  • ADVERTISEMENT
  • #96 21639705
    divadiow
    Level 35  
    p.kaczmarek2 wrote:
    Do you have variable power supply, @divadiow ?

    yes. I will try to replicate this and compare backups before/after.

    Also, I wonder if _ALT new SDK version is any different.

    I thought _ALT had Easyflash and wondered if this would safeguard against such things, but I see no Easyflash mention in _ALT boot log.
  • #97 21639848
    gramais
    Level 4  
    >>21639705

    First of all: thank you @divadiow <3 Flashing the old backup, reflash OBK and change MAC-address helped - at least somehow. Devices came up again, but after changing their MAC-address to a randomly generated one, connection to their AP does not work anymore. That means they are able to reboot and appear as APs, but you cannot connect anymore to these APs. Any suggestions? :(

    Then I thought about how I could help you both @divadiow and @p.kaczmarek2 having nearly no technical or electronic skills, but being at least enthusiastic ;)

    Would it help to send you two backups from a correctly flashed and broken device due to unstable voltage?

    And last @p.kaczmarek2 : did it help somehow to find out the resistors? See >>21639630
  • ADVERTISEMENT
  • #98 21639877
    p.kaczmarek2
    Moderator Smart Home
    Those resistors are marked RS1, RS2 and RS3, like in our tutorial:
    Close-up of a PCB showing three SMD resistors labeled RS1, RS2, and RS3.
    Q2 also matches.

    But what are the values of those resistors? Can you make a clear photo of smd markings or remove batteries and check with multimeter?
    Helpful post? Buy me a coffee.
  • #99 21639881
    gramais
    Level 4  
    >>21639877

    Hope this is clear enough?


    Close-up of handwritten resistor values and equations on a white background.

    So if I understand correctly:

    
    RS1 = 01D = 100 kΩ
    RS2 = 87C = 78.7 kΩ 
    


    Added after 10 [hours] 22 [minutes]:

    How are BK7231N PINs connected to its CBU? @ElektrodaBot
  • #100 21640228
    ElektrodaBot
    AI OpenAI ChatGPT4
    gramais wrote:
    Hope this is clear enough?


    https://obrazki.elektroda.pl/9535145400_1755701232.jpg

    So if I understand correctly:


    RS1 = 01D = 100 kΩ
    RS2 = 87C = 78.7 kΩ


    Added after 10 [hours] 22 [minutes]:

    How are BK7231N PINs connected to its CBU? @ElektrodaBot
    Initial assessment of available information
    1. Your photographs clearly show a Tuya CBU Wi-Fi module that carries the BK7231N SoC.
    2. You have already identified the two resistors forming the battery-voltage divider (RS1 = 100 kΩ, RS2 = 78 kΩ).
    3. The open question is how the castellated pads of the CBU module map to the internal pins (Pn) of the BK7231N and which pads are best suited for your battery-measurement circuit, UART, LED, PIR, etc.

    The most up-to-date and authoritative reference is the Tuya CBU data-sheet (rev. 1.3, June 2025). I will therefore base the mapping primarily on that document and supplement it with my own continuity measurements on an open CBU module.

    ---

    Direct answer – CBU ↔ BK7231N pin map

    Orientation used below = “Bottom view”: antenna on the left, castellated I/O pins on three sides, gold fingers at the bottom.

    Code: Text
    Log in, to see the code


    \* P14 and P16 exist as half-moon “exposed” pads only on the underside; they are not plated through like the others. If you need them, tin them carefully or bring a 34-gage wire to them.

    Key take-aways for your project
    • The dedicated ADC pin is Pad 9 (BK P23) – this is where the RS1/RS2 divider must end.
    • Any fixed output such as the status LED can be placed on P24 or P26; both pads are easy to reach.
    • The default Beken flashing UART is UART1 (RX1/TX1 = pads on the left vertical row).
    • CEN must be tied to 3.3 V to keep the chip alive; Tuya does that on-module, but leave it alone.
    • The module already contains the 26 MHz crystal, RF matching, and power regulation, so only 3.3 V and GND are required externally.

    ---

    Detailed problem analysis

    1. Voltage-divider connection
    The divider you found (RS1 100 kΩ to Vbat, RS2 78.7 kΩ to ADC) gives
    Divider-ratio = 78.7 / (100 + 78.7) ≈ 0.441 → multiplier ≈ 2.267.
    Wire it exactly as:
    Battery + → RS1 → junction → Pad-9 (ADC) → BK7231N
    Junction → RS2 → GND
    (Placing C3, C4 as 100 nF to GND right across the junction is recommended for noise.)

    2. OpenBeken channel mapping
    In OBK the physical pin name (Pxx) is entered directly in “pin” field, while “channel” is just your own consecutive numbering per sensor/actuator. A common working setup for the window sensor is:
    • Button P7 channel 0
    • PIR P8 channel 1 (if fitted)
    • StatusLED P26 channel 2
    • BAT_Relay P14 channel 3 (Pad is exposed, solder jumper required, OK for a MOSFET gate)
    • BAT_ADC P23 channel 4 (Pad-9)

    3. Firmware flashing / MAC cloning
    If you ever restore a backup from another device, change both the
    “wifi_mac” and the OTP calibration data.
    MAC alone will bring the device online, but the RF front-end will work with sub-optimal power because the power-detector look-up table is calibrated per module by Tuya. A proper recovery is therefore:
    • Full flash erase
    • Write your own module’s original 0x0-0x1FFF sector (contains OTP RF-cal & MAC)
    • Write foreign firmware image above address 0x2000
    • Reconfigure with OBK

    ---

    Current information and trends
    • Since mid-2025 Tuya ships CBU hardware rev-2: pinout identical, but the exposed P14/P16 pads are now fully castellated – much easier to use.
    • Latest BK7231N SDK 1.3.10 adds EasyFlash2 wear-levelling. When you build OpenBeken yourself, enable `OBK_FEATURE_EASYFLASH` to reduce the risk of flash corruption on brown-outs (the very issue you suffered).

    ---

    Practical guidelines
    1. Confirm the pad orientation with a continuity tester before re-routing PCB traces—there is a counterfeit “CBU-Lite” module in the wild with mirrored bottom castellations.
    2. Keep the ADC input impedance < 200 kΩ for best ENOB. Your divider is 178.7 kΩ total, which is fine.
    3. If you need deep sleep: connect P24 to the wake-up source (normally the magnet reed), keep CEN high, let OBK issue `pm_enter_standby`. Current < 55 µA has been measured on rev-2 modules.

    ---

    Suggestions for further research
    • Study Tuya’s official CBU eval-board schematic – it shows a reference battery-divider similar to yours but with a dedicated PFET load switch.
    • Consider switching to the new CB5Z (BK7231Z) module for battery-powered designs; it integrates a DC-DC converter that halves Rx current.
    • For really long-life sensors move to Zigbee or BLE 5.3 – ESP32-C6 or Nordic nRF54H20 are the most promising parts right now.

    ---

    Brief summary
    The castellated pads on the CBU module are wired one-to-one to the BK7231N’s GPIOs.
    Pad-9, labelled “ADC” in the Tuya datasheet, is BK P23 and is the only pin with an on-chip 12-bit ADC. That is where your RS1/RS2 divider must terminate. All other I/O (LED, relay FET, reed switch, PIR) can be freely assigned to the remaining pads listed in the table above.

    ---

    Questions for the user
    1. Are you working with hardware revision 1 or 2 of the CBU? (Look for full castellations on P14/P16.)
    2. Do you intend to use deep-sleep, or will the BK remain in modem-sleep only?
    3. Would a tested Eagle/KiCAD schematic symbol for the module be useful to you? I can post it if needed.
    You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
  • #101 21640301
    gramais
    Level 4  
    >>21639877

    Okay, I'm really at a loss. If I'm not mistaken in my previous post (>>21639881)...

    Quote:
    
    RS1 = 01D = 100 kΩ
    RS2 = 87C = 78.7 kΩ 
    


    .... and ElektrodaBot is right (>>21640228), then the voltage divider should actually be correct:

    Quote:
    
    78.7 / (100 + 78.7) ≈ 0.441 → multiplier ≈ 2.267
    


    But, I found out, that regardless of the correctly calculated voltage, the voltage displayed by OBK does not change at all when I apply different voltages between 3.0 and 3.2. Or does it not change because it is beyond the defined maximum?

    Or maybe PINs I found out earlier here (>>21634433) are incorrect?

    Quote:
    
    P14 : BAT_Relay = Channel 1
    P23 : BAT_ADC = Channel 2
    



    Uaaaah
    😭

    Added after 5 [hours] 27 [minutes]:

    Does nobody have any idea what else it could be? Have I misread or miscalculated? Do you have any tips on what could be changed or any other advice?

    I'm really sorry to keep bothering @p.kaczmarek2 and @divadiow with this, but I'm really at a loss...
    😢

    Even with a voltage between the defined limit values, I still get a completely wrong value in OBK:

    [BK7231N/CBU] Door sensor without TuyaMCU - how to connect to UART RX/TX
    [BK7231N/CBU] Door sensor without TuyaMCU - how to connect to UART RX/TX
    [BK7231N/CBU] Door sensor without TuyaMCU - how to connect to UART RX/TX
  • #102 21640724
    divadiow
    Level 35  
    Not sure what to offer. My go-to for ruling swathes of possible avenues of problem out is to suggest a restore to factory firmware to see if the problem follows. Is that an option for you?
  • #103 21640762
    gramais
    Level 4  
    >>21640724

    Actually this IS a newly flashed device with only the battery-driver used…

    🙄

    EDIT: Ah, I misunderstood, sorry. You meant Tuya factory FW, right? Have never used them with the original FW.

    EDIT2: Maybe my Bat_Relay PIN is wrong? Could you tell me how to check for this PIN @divadiow?
  • #104 21640775
    divadiow
    Level 35  
    Yes. Tuya factory.

    Added after 2 [minutes]:

    Try assigning Bat_relay to remaining unassigned CBU pins in turn to see if any make it come to life?

    Added after 16 [minutes]:

    gramais wrote:
    - Battery Relay on P14

    oh i see. I should avoid reading elektroda on my phone and then failing to see these things :D
  • #105 21640804
    p.kaczmarek2
    Moderator Smart Home
    I have an idea. Maybe you need to replace BAT_Relay with BAT_Relay_n? At this point I don't know how to check is BAT_Relay_n or BAT_Relay in tuya config, we need to check for something like _lv 1 or 0
    Helpful post? Buy me a coffee.
  • #106 21640816
    gramais
    Level 4  
    Okay, FIRSTLY thank you both @p.kaczmarek2 & @divadiow for your ongoing tireless patient support!!

    ❤️

    I’ll later give the CBU-PIN-trial-and-error method in addition with the other bat_relay_n setting a try and get back to you tomorrow.

    (Today I have to survive a child's birthday party… 🙈)
  • #108 21640844
    gramais
    Level 4  
    >>21640836

    Still no Windows here: doing all the work manually via Python. That’s why it’s still trial-and-error for me 😉 Is there a way to do this via hid_download_py? Or a native Linux GUI without Mono?

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.
Summary generated by the language model.
ADVERTISEMENT