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
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.
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?
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?
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
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?
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.