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.
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.
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?
Hi!
Is there a deepsleep enabled in this profile? And when does it sleep; when the magnet is present or absent?
Thank you! [Read more]
p.kaczmarek2
24 Feb 2024 08:59
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... [Read more]
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:
Connect the sensor board to /dev/ttyUSB0.
Run python3 uartprogram ./fw_release/OpenBK7231N_QIO_1.17.391.bin -d /dev/ttyUSB0 -w -u -s 0x0.
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]
Comments
Hi! Is there a deepsleep enabled in this profile? And when does it sleep; when the magnet is present or absent? Thank you! [Read more]
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... [Read more]