logo elektroda
logo elektroda
X
logo elektroda

Flashing ONENUO Tuya Wifi Door Sensor BK7231N CBU-NL with Tasmota Replacement

spln 5226 2

TL;DR

  • ONENUO Tuya Wifi Door Sensor 19JWT with a Tuya CBU-NL BK7231N module was opened and prepared for a Tasmota replacement.
  • The PCB uses a surprising button wiring: P14 and P16 both see BTN_n, while P15 drives WifiLED_n and P23 reads BAT_adc.
  • It runs from 3V via 2x AAA batteries and was bought on AliExpress for $3.69.
  • The latest firmware flashed successfully with hid_download_py, but the sensor appears to be a new PCB revision with a different pin configuration and no labeling.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):
  • Module name: ONENUO Tuya Wifi Door Sensor - 19JWT
    Protocol: WiFi 2,4GHz
    Power: 3V (2x AAA battery)
    Wifi module: Tuya CBU-NL (BK7231N) datasheet

    This is the door sensor version of the module, but based on the PCB layout they also build other sensors with the same panel.
    Bought it on aliexpress for $3.69 on sale: Link
    Another sensor with seemingly the same PCB was discussed here, but this one has a different pin configuration. Probably a new PCB revision, however no labeling about it.

    Flashed latest release with python flasher: hid_download_py
    Code: Bash
    Log in, to see the code


    Pictures of the module:
    Packaging of the Tuya Wi-Fi door and window sensor. Packaging of Tuya Wifi Door Sensor with SKU code and manufacturer information. Tuya Wi-Fi door sensor set with packaging and user manual.


    Tear-down pictures:

    ONENUO WiFi door sensor module with disassembled casing ONENUO Tuya door sensor module with visible PCB layout and Wi-Fi module CBU-NL.

    Pin config:
    Surprisingly the push button is connected to both P14 and P16, but with different pull-ups. This might be used for some kind of debouncing or?

    P15: WifiLED_n (Bat+ > R8 10k > LED1 > R3 1k > P15)
    P14: BTN_n (Bat+ > R8 10k > P14)
    P16: BTN_n (Bat+ > R8 10k > P14 > R9 10k > P16)
    P20: BAT_rel (R1 10k - R2 10k voltage divider switched with Q3 through R4 4k7)
    P22: DoorSnsrWSleep (Q3 sensor directly connected)
    P23: BAT_adc (Bat+ > R1 10k > ADC > R2 10k > GND)

    Original firmware:
    orig-firmw...i-door.bin (1.1 MB)You must be logged in to download this attachment.

    JSON config:
    Code: JSON
    Log in, to see the code

    Cool? Ranking DIY
    About Author
    spln
    Level 5  
    Offline 
    spln wrote 7 posts with rating 10, helped 1 times. Been with us since 2023 year.
  • ADVERTISEMENT
  • #2 20975237
    hojnikb
    Level 12  
    Posts: 45
    Rate: 2
    Hi!

    Is there a deepsleep enabled in this profile? And when does it sleep; when the magnet is present or absent?

    Thank you!
  • #3 20975941
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14467
    Help: 650
    Rate: 12480
    The pin role called DoorSnsrWSleep is automatically starting DoorSensor driver on every reboot. There is no script required because all is done in the firmware. The DoorSensor driver handles the sleeping.

    The DoorSensor driver sleeps in both situations.

    Keep in mind that you can also script the device sleep manually with PinDeepSleep command, but that approach is more complicated and requires some basic scripting knowledge.
    Helpful post? Buy me a coffee.
📢 Listen (AI):

FAQ

TL;DR: This FAQ helps ONENUO 19JWT owners reflash and map a BK7231N door sensor. With 5 verified GPIO roles and the note "different pin configuration," it solves the common problem of flashing similar CBU-NL boards safely with OpenBeken and matching the right JSON profile. [#20896810]

Why it matters: These sensors can look identical across PCB revisions, so a verified pin map and sleep behavior prevent bad profiles and wasted troubleshooting time.

Method Sleep handling Setup effort Best use
DoorSnsrWSleep + built-in DoorSensor driver Automatic, handled by firmware Low Standard battery door sensors
PinDeepSleep command + script Manual, script-controlled Higher Custom sleep logic

Key insight: On this BK7231N door sensor, DoorSnsrWSleep starts the DoorSensor driver automatically after reboot, and that driver manages deep sleep in both magnet states. [#20975941]

Quick Facts

  • The ONENUO 19JWT uses Wi‑Fi 2.4 GHz, runs from 3 V on 2× AAA batteries, and carries a Tuya CBU-NL module with a BK7231N chip. [#20896810]
  • The unit was bought for $3.69 on sale, which makes it a low-cost target for OpenBeken replacement firmware experiments. [#20896810]
  • A successful flash used OpenBK7231N_QIO_1.17.391.bin with uartprogram and start address 0x0. [#20896810]
  • Battery measurement uses a switched divider: R1 10k + R2 10k feed the ADC, while Q3 and R4 4k7 control the relay path. [#20896810]

How do I flash an ONENUO Tuya WiFi Door Sensor 19JWT with a BK7231N CBU-NL module using the hid_download_py Python flasher?

Flash it with hid_download_py by writing OpenBK7231N_QIO_1.17.391.bin to address 0x0 over a USB serial adapter. Use this 3-step flow:
  1. Connect the sensor board to /dev/ttyUSB0.
  2. Run python3 uartprogram ./fw_release/OpenBK7231N_QIO_1.17.391.bin -d /dev/ttyUSB0 -w -u -s 0x0.
  3. Reboot and apply the matching JSON pin profile. This exact command was reported as successful on the ONENUO 19JWT with the CBU-NL BK7231N module. [#20896810]

What pin configuration was identified for the ONENUO Tuya WiFi Door Sensor 19JWT after teardown?

The teardown mapped five active functions: P15 = WifiLED_n, P14 = BTN_n, P20 = BAT_rel, P22 = DoorSnsrWSleep, and P23 = BAT_adc. The notes also show P16 tied into the push-button network, even though the JSON profile uses P14 as the button input. This mapping came from the inspected ONENUO 19JWT PCB, not from a generic CBU-NL template. [#20896810]

Why is the push button on this ONENUO 19JWT sensor connected to both P14 and P16, and what might that dual connection be used for?

The button is wired to both P14 and P16 through different pull-up paths, which suggests a hardware filtering or debounce function. The teardown notes say P14 goes to battery through R8 10k, while P16 is linked through R9 10k from the P14 path. No confirmed firmware explanation was given, so the safe takeaway is that the dual connection exists in hardware and may support debounce-like behavior. [#20896810]

What is the DoorSnsrWSleep pin role in OpenBK/OpenBeken, and how does it work on a BK7231N door sensor?

DoorSnsrWSleep is the pin role that automatically starts the DoorSensor driver after every reboot. "DoorSnsrWSleep" is a firmware pin role that starts the door-sensor driver, enabling automatic sleep handling for battery-powered magnetic sensors without a custom script. On this BK7231N sensor, that means you assign the role once and the firmware takes over the sleep logic. [#20975941]

How does the DoorSensor driver handle deep sleep on the ONENUO Tuya WiFi magnetic door sensor?

The DoorSensor driver handles deep sleep automatically in firmware. You do not need a script when the sensor uses the DoorSnsrWSleep role, because the driver is started on reboot and then manages the power behavior itself. That built-in path is the thread’s recommended simple setup for this type of battery-powered magnetic door sensor. [#20975941]

When does the ONENUO BK7231N door sensor go to sleep in OpenBeken or Tasmota-replacement firmware: when the magnet is present, absent, or both?

It goes to sleep in both cases. The firmware author answered this directly: the DoorSensor driver sleeps in both situations, so sleep does not depend on only the magnet-present or only the magnet-absent state. That behavior applies when you use the DoorSnsrWSleep role with the built-in driver. [#20975941]

What is the PinDeepSleep command, and how is it different from using the built-in DoorSensor driver?

PinDeepSleep is a manual sleep-control command that you use from a script instead of relying on the automatic DoorSensor driver. The built-in driver needs no script and manages sleep on its own, while PinDeepSleep is more complex and requires basic scripting knowledge. Use the command only when you need custom logic that the standard door-sensor flow does not provide. [#20975941]

Which GPIOs on the CBU-NL board are used for the WiFi LED, button, battery measurement, and door sensor input in the ONENUO 19JWT?

The ONENUO 19JWT uses P15 for the Wi‑Fi LED, P14 for the button input, P20 for BAT_rel, P23 for BAT_adc, and P22 for the door sensor with sleep handling. The teardown also notes a secondary button-related connection on P16 through a resistor network. Those assignments match the posted JSON profile for the CBU-NL board. [#20896810]

How is battery voltage measured on this BK7231N door sensor using BAT_Relay and BAT_ADC?

Battery voltage is measured through a switched divider that feeds the ADC only when needed. Bat+ goes through R1 10k to the ADC node and R2 10k to ground, while Q3 switches the divider path through R4 4k7 using BAT_rel on P20. P23 reads the resulting BAT_adc value, which reduces always-on measurement load in a battery device. [#20896810]

What firmware version and flashing command were used successfully on the ONENUO Tuya WiFi Door Sensor 19JWT?

The successful firmware was OpenBK7231N_QIO_1.17.391.bin. The reported command was python3 uartprogram ./fw_release/OpenBK7231N_QIO_1.17.391.bin -d /dev/ttyUSB0 -w -u -s 0x0, using the Python flasher from hid_download_py. That exact combination was stated as working on this ONENUO 19JWT sensor. [#20896810]

What is the Tuya CBU-NL module, and how does it relate to the BK7231N chip in WiFi sensors?

The CBU-NL is the Wi‑Fi module fitted on this sensor, and the posted device data identifies its chip as BK7231N. "CBU-NL" is a Tuya Wi‑Fi module that hosts the BK7231N SoC, providing the radio and control hardware used inside compact battery-powered sensors. In this thread, the ONENUO 19JWT is explicitly described as a CBU-NL-based design. [#20896810]

How does the DoorSensor driver compare with manual PinDeepSleep scripting for battery-powered magnetic door sensors?

The DoorSensor driver is simpler because firmware handles sleep automatically, while PinDeepSleep gives more control but needs scripting. For a standard magnetic door sensor, the built-in path reduces setup work and avoids script errors. Choose manual PinDeepSleep only when you need custom timing or logic beyond the default driver behavior. [#20975941]

What should I check if my ONENUO or similar Tuya door sensor seems to use the same PCB layout but has a different pin mapping?

Check the actual GPIO wiring on your board before reusing any JSON profile. The thread explicitly warns that a seemingly identical sensor PCB had a different pin configuration, likely from a newer PCB revision with no clear labeling. That means matching enclosure, brand, or layout is not enough; verify each LED, button, ADC, and sensor pin from the board itself. [#20896810]

How can I create or adapt a JSON device profile for an ONENUO 19JWT magnetic door sensor in OpenBeken?

Create the JSON profile by assigning the verified roles from the teardown to the matching GPIOs. The posted example uses chip BK7231N, board CBU-NL, flags 1024, and pins 14=dInput_NoPullUp_n;2, 15=WifiLED_n;1, 20=BAT_Relay;4, 22=DoorSnsrWSleep;0, and 23=BAT_ADC;3. If your board revision differs, adjust the pin map first and then update the JSON. [#20896810]

Where can I find the datasheet, teardown details, and original firmware information for the ONENUO Tuya WiFi Door Sensor 19JWT?

You can find all three in the thread’s main post. It links the Tuya CBU-NL datasheet, shows exterior and teardown photos, lists the measured pin configuration, includes a screenshot of the original firmware, and provides a ready-made JSON profile. That single post is the thread’s primary technical reference for the ONENUO 19JWT. [#20896810]
Generated by the language model.
ADVERTISEMENT