logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Configuring Door Sensor 19JWT-B (BK7231N) (DeepSleep)

CMY 6123 15

TL;DR

  • Configuring the 19JWT-B BK7231N door sensor for DeepSleep and Smart Life use, with custom pin mapping for this cheap variant.
  • LED uses P15, the magnetic field sensor P22, the battery relay P20, ADC P23, and the button P14 with a 10k pull-up resistor R8.
  • Firmware update works through P2 with 2 mm spacing; the header order is TX P2-5, RX P2-4, CEN P2-3, GND P2-2, VCC unused.
  • The button is not added to the config yet, and this version lacks capacitor C2.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):
  • Electronic module on a blue circuit board with visible components and a CBU-NL model sticker.

    Tuya Wi-Fi door and window sensor with open casing showing battery compartment, and closed unit with branding on the packaging. Close-up of a door sensor circuit board with three casing elements. WiFi Smart Door Magnetic user manual with Alexa logo and specification details.

    Very similar to this one: https://www.elektroda.com/rtvforum/topic3964392.html
    But uses another pins.
    Original app: Smart Life App

    Pins
    - LED on P15
    - MagnetField Sensor on P22
    - Battery Relay on P20, ADC on P23
    - Button on P14. Has 10k pull up resistor (R8). Plus place for capacitor C2 (but no capacitor in this cheap version)
    (I didn't add Button to config yet)

    Config and Battery settings
    Code: JSON
    Log in, to see the code



    Firmware update
    Close-up of a circuit board with connected wires.
    Firmware update can be done via P2, no soldering needed. Step is 2mm, so normal 2.54mm pins cannot be soldered. But 2.54mm wires are good for firmware update.
    Pins from left to right:
    - TX (orange) - P2-5
    - RX (yellow) - P2-4
    - CEN (grey) - P2-3
    - GND (green) - P2-2
    - VCC (not used) - P2-1

    Links
    Very similar to this one: https://www.elektroda.com/rtvforum/topic3964392.html
    Link to aliexpress: https://www.aliexpress.us/item/3256805743653289.htm

    Cool? Ranking DIY
    About Author
    CMY
    Level 2  
    Offline 
    CMY wrote 6 posts with rating 5. Been with us since 2024 year.
  • ADVERTISEMENT
  • #2 20906240
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14635
    Help: 655
    Rate: 12649
    The configuration seems to be missing a button. Do you know which pin is used for button? This can be handy for emergency wakeup feature that we plan to add soon.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #3 20906259
    CMY
    Level 2  
    Posts: 6
    Rate: 5

    I was sure that button is Reset Button and wired to some CEN or reset.

    But you are right:
    Button on P14. Has 10k pull up resistor (R8)
    I can't check config because my unit was burned by accident.
  • ADVERTISEMENT
  • #4 20983455
    delfinok
    Level 2  
    Posts: 2
    Hi! Will it be added to config templates of OpenBeken Webapp? I do not see it in hw tempalte. Thankx!
  • #5 20983465
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14635
    Help: 655
    Rate: 12649
    Thank you for pointing that out, we must have missed that.
    Ok, I have added it now:
    https://github.com/OpenBekenIOT/webapp/commit/d3e7ab9b3c603002ea13d5e629e51888e21eabf2
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #6 20983476
    delfinok
    Level 2  
    Posts: 2
    Thanks! But you should add P14 Btn too. The config misses that!
  • #7 20990122
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14635
    Help: 655
    Rate: 12649
    Thank you for pointing that out! This button can be useful as an emergency wake up method. Here is updated template:
    https://github.com/OpenBekenIOT/webapp/commit/26b08ba3afabbdac2debeb62e563ee4dc4aa2ead
    Helpful post? Buy me a coffee.
  • #8 21075261
    ferbulous
    Level 18  
    Posts: 419
    Help: 8
    Rate: 56
    Hi, how is the battery life so far? And how quick does it update the open/close status

    I have a similar one like this but i haven’t flash it yet
  • #9 21411736
    levsha
    Level 4  
    Posts: 3
    I have this device configured. Everything works well with HomeAssistant. Except one problem: it doesn't turn off WiFi, so it drains a battery just within couple of days.
    I guess I missed something. Sorry, not so much familiar with this firmware yet.
    I've flashed it with the latest firmware:
    
    Chipset: BK7231N
    Build: Built on Jan 23 2025 22:12:58 version 1.18.24
    

    The current configuration:
    
    {
      "vendor": "Tuya",
      "bDetailed": "0",
      "name": "Full Device Name Here",
      "model": "enter short model name here",
      "chip": "BK7231N",
      "board": "TODO",
      "flags": "1024",
      "keywords": [
        "TODO",
        "TODO",
        "TODO"
      ],
      "pins": {
        "14": "Btn;2",
        "15": "WifiLED;0",
        "20": "BAT_Relay;1",
        "22": "DoorSnsrWSleep_pd;0",
        "23": "BAT_ADC;1"
      },
      "command": "Battery_Setup 2000 3000 1.98 2400 4096",
      "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
      "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
    }
    
  • #10 21411895
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14635
    Help: 655
    Rate: 12649
    Do you when DoorSensorWithDeep sleep driver shown as running on your main device page?
    Helpful post? Buy me a coffee.
  • #11 21411993
    levsha
    Level 4  
    Posts: 3
    p.kaczmarek2 wrote:
    Do you when DoorSensorWithDeep sleep driver shown as running on your main device page?

    Nope: "0 drivers active". My understanding it should have started automatically?
    Oh, also "incomplete boots: 1" - could that be the hint of the problem?

    Screen of the OpenBK7231N sensor with status information and configuration options.
  • #12 21412131
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14635
    Help: 655
    Rate: 12649
    Maybe you have disabled "Autostart drivers" flag. You can also start driver manually in short startup command or via autoexec.bat
    Helpful post? Buy me a coffee.
  • #13 21412559
    levsha
    Level 4  
    Posts: 3
    p.kaczmarek2 wrote:
    Maybe you have disabled "Autostart drivers" flag. You can also start driver manually in short startup command or via autoexec.bat

    Looks like it, "Autostart drivers" flag was somehow set.
    I don't remember setting it explicitly. It was probably set because I was trying various configs. So I've reset the sensor to initial settings and reconfigured it again.
    DoorSensor started now:
    IoT device management interface screen displaying door sensor status information.
    However with this configuration the sensor never came back after it went to sleep, doesn't matter how many times I've tried to trigger open/close.

    So i've tried this configuration: https://www.elektroda.com/rtvforum/topic4026894.html#20896810 (internal board is exactly the same, just the case color is different).
    With that configuration addtionally TuyaMCU and tmSensor drivers are starting (that I guess is right for this sensor):
    Screenshot of a device interface showing status and configuration information.
    With this configuration it wakes up now.

    Added after 55 [minutes]:

    So, it wakes up well on the sensor within few minutes after going to sleep. But after longer period of time it wakes up (the LED turns on) but never appears online. My guess is it can't recover WiFi connection, maybe because of WPA2/WPA3...
  • #14 21910566
    GreedyMagnetometer
    Level 2  
    Posts: 17
    hi. I flashed a similar sensor, set it up, everything works, but... after going to sleep, he comes out of sleep for a long time, 15 seconds. It connects to wifi for 10 seconds, and transmits a message to mqtt for 5 seconds. has anyone solved the problem of a long connection after sleep? With the original firmware, it works after 2-3 seconds after opening the door.
  • #15 21910801
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14635
    Help: 655
    Rate: 12649
    Probably first steps are setting up static IP and quick connect flag.
    Helpful post? Buy me a coffee.
  • #16 21910967
    GreedyMagnetometer
    Level 2  
    Posts: 17
    >>21910801 I set up a static address right away, and I chose the quick activation section with flags.
📢 Listen (AI):

Topic summary

✨ The discussion focuses on configuring the Tuya-based door sensor model 19JWT-B with BK7231N chipset, particularly addressing DeepSleep functionality and pin assignments. Key pins include LED on P15, MagnetField Sensor on P22, Battery Relay on P20, ADC on P23, and a button on P14 with a 10k pull-up resistor. Initial configurations missed the button pin, which was later added to the OpenBeken Webapp hardware templates to support emergency wake-up features. Users report issues with battery drain due to WiFi not turning off, linked to driver autostart settings. Proper driver activation, including DoorSensorWithDeepSleep, TuyaMCU, and tmSensor, is necessary for correct operation and wake-up behavior. Resetting the sensor and ensuring autostart drivers flag is enabled resolves some boot and sleep issues. The sensor wakes reliably on door open/close events after applying the updated configuration and driver setup. Firmware version 1.18.24 (built Jan 23, 2025) is used in testing.
Generated by the language model.

FAQ

TL;DR: For OpenBeken users, map 5 pins correctly and keep driver autostart enabled; as one expert reply put it, "0 drivers active" is a red flag. This FAQ helps 19JWT-B owners fix deep sleep, battery drain, and wake-up failures on BK7231N door sensors. [#21411993]

Why it matters: A battery door sensor only becomes practical when deep sleep, wake-up, and Wi‑Fi reconnect all work together.

Option Pin/template state Drivers seen Observed result
Initial 19JWT-B template P14 button originally missing 0 when autostart was off Wi‑Fi stayed on and battery drained fast
Updated 19JWT-B template P14 button added DoorSensor started Sensor slept, but one test unit did not always wake back
Similar template from post 20896810 Same internal board, extra drivers 3 drivers active Woke up correctly after sleep in one test

Key insight: Correct GPIO mapping is necessary, but not sufficient. If Autostart drivers is disabled, the deep-sleep driver will not run, the page can show 0 drivers active, and the sensor may stay on Wi‑Fi instead of sleeping.

Quick Facts

  • The published 19JWT-B mapping uses P15 for the Wi‑Fi LED, P22 for the magnetic door sensor, P20 for the battery relay, and P23 for battery ADC. [#20906219]
  • The button is on P14 and has a 10 kΩ pull-up resistor marked R8; the board also has a place for C2, but no capacitor was fitted on the cheaper version. [#20906259]
  • Firmware flashing uses the P2 header with 2 mm pitch; left to right the pads are TX, RX, CEN, GND, VCC, and ordinary 2.54 mm wires were reported usable for temporary flashing. [#20906219]
  • The battery command shown in the template is Battery_Setup 2000 3000 1.98 2400 4096, and one later test unit ran firmware built on January 23, 2025 at 22:12:58, version 1.18.24. [#21411736]

How do I configure the Tuya 19JWT-B door sensor with a BK7231N chip for OpenBeken deep sleep mode?

Use the 19JWT-B template with BK7231N, map the sleep-capable door input to P22, and include the battery pins. A working JSON example sets P15=WifiLED;0, P20=BAT_Relay;1, P22=DoorSnsrWSleep_pd;0, and P23=BAT_ADC;1, with flags set to 1024. Add P14 as the button if you want emergency wakeup support. Use the battery command Battery_Setup 2000 3000 1.98 2400 4096. [#20906219]

Which GPIO pins are used on the 19JWT-B for the LED, reed switch door sensor, battery relay, battery ADC, and button?

The 19JWT-B uses P15 for the LED, P22 for the magnetic reed door sensor, P20 for the battery relay, P23 for battery ADC, and P14 for the button. The thread also notes a 10 kΩ pull-up resistor on the button line at R8. Those five pins are the core mapping for OpenBeken on this board. [#20906259]

What is the DoorSensorWithDeepSleep driver in OpenBeken, and how does it affect battery-powered door sensors?

"DoorSensorWithDeepSleep" is a driver that manages a door sensor’s sleep-and-wake behavior, letting a battery device power down Wi‑Fi between events while still reacting to door changes. Its key characteristic is automatic low-power operation tied to the sensor input and wake logic. In the thread, when the driver was not running, Wi‑Fi stayed on and the battery drained within a couple of days. [#21411736]

How can I flash firmware on the 19JWT-B through the P2 header without soldering, and what are the TX, RX, CEN, GND, and VCC pin positions?

You can flash it through the P2 header without soldering by pressing temporary wires onto the pads. 1. Use the 5-pad P2 header with 2 mm pitch. 2. Wire the pads left to right as TX on P2-5, RX on P2-4, CEN on P2-3, GND on P2-2, and VCC on P2-1. 3. Use normal 2.54 mm jumper wires only as temporary contact wires, because the pad spacing is not 2.54 mm. [#20906219]

Why does a BK7231N door sensor stay on WiFi and drain the battery in a couple of days instead of entering deep sleep?

It stays on Wi‑Fi when the deep-sleep driver is not actually running. In the thread, one user reported battery drain within a couple of days, and the device page showed 0 drivers active instead of the DoorSensor driver. That means the template alone was not enough; the driver also had to start correctly. [#21411993]

Where should the P14 button be added in the OpenBeken template for the 19JWT-B, and why is it useful for emergency wakeup?

Add the button as pin 14 in the pins section, for example "14": "Btn;2". The thread first noted that P14 was missing from the template, then confirmed it should be added because the button can serve as an emergency wakeup method. That matters on a sleeping battery sensor when normal wake behavior fails. [#20990122]

What is the purpose of the 'Autostart drivers' flag in OpenBeken, and why would a device show '0 drivers active' when it is disabled?

The Autostart drivers flag tells OpenBeken to launch configured drivers automatically at boot. If it is disabled, the main page can show 0 drivers active, even when the GPIO template looks correct. In the thread, re-enabling that behavior made the DoorSensor driver start and changed the device state from idle to active. [#21412131]

Why would the 19JWT-B go to sleep correctly but fail to wake up and reconnect to WiFi after a longer idle period?

The thread shows that wake behavior can differ between templates and over time. One test unit woke correctly within a few minutes of sleeping, but after a longer idle period the LED turned on and the device never came online. The same user suspected Wi‑Fi reconnection failure after long sleep, not a pure GPIO wake failure. [#21412559]

How do I start the DoorSensorWithDeepSleep driver manually in OpenBeken using the short startup command or autoexec.bat?

Start it manually by adding the driver start command either to the short startup command field or to autoexec.bat. The thread does not publish the exact command text, but it clearly states those are the two supported places to launch the driver when autostart is off. Use this path when the device page shows 0 drivers active. [#21412131]

What does 'incomplete boots: 1' mean on an OpenBeken device page, and how can it help diagnose wake or boot problems?

incomplete boots: 1 means the device recorded one boot that did not complete normally. In the thread, that counter appeared together with 0 drivers active, so it helped point attention to startup and wake sequencing rather than only pin mapping. Use it as a clue that the sensor may be resetting or failing during resume. [#21411993]

How well does the 19JWT-B battery life hold up in real use, and how fast does it report open/close status changes to Home Assistant?

The thread does not provide measured battery-life or response-time results for a healthy 19JWT-B. One person asked about battery life and open/close update speed on May 9, 2024, but no numeric follow-up was posted in the provided discussion. The only concrete battery-life report is a failure case where Wi‑Fi stayed on and the battery died within a couple of days. [#21075261]

What differences are there between the 19JWT-B template and the similar Elektroda door sensor configuration at topic3964392 or post 20896810?

The main practical difference is that the similar configuration was reported to start additional drivers and wake more reliably on one unit. The 19JWT-B thread began with a template missing P14, while the alternative configuration started DoorSensor, TuyaMCU, and tmSensor on hardware described as internally identical except for case color. In that user’s test, the alternative template woke after sleep when the first one did not. [#21412559]

When using Home Assistant with OpenBeken, what is the best way to verify that a battery-powered door sensor is actually sleeping and waking as expected?

Check the OpenBeken main page first, not only Home Assistant. Verify that the DoorSensor driver is running, confirm the device does disappear during sleep, and then trigger open/close after a short idle period and again after a longer one. In the thread, the decisive checks were DoorSensor started, the number of active drivers, and whether the sensor reappeared online after wake. [#21412559]

How should I tune the Battery_Setup values '2000 3000 1.98 2400 4096' for a BK7231N door sensor to get accurate battery readings?

The thread gives the exact Battery_Setup 2000 3000 1.98 2400 4096 command, but it does not explain how to tune each number. You can safely reuse that baseline on the 19JWT-B because it was posted as the working template value set for this board. For calibration beyond that, the discussion provides no per-cell voltage targets or measured ADC correction steps. [#20906219]

Why might a Tuya/OpenBeken door sensor wake up physically with the LED turning on but never come online on a WPA2/WPA3 WiFi network?

The thread points to Wi‑Fi reconnection as the likely failure point after long sleep. One user observed that the LED turned on, proving physical wakeup occurred, but the sensor never appeared online after a longer idle period. That same report specifically suspected mixed WPA2/WPA3 as the network condition preventing the BK7231N device from reconnecting. [#21412559]
Generated by the language model.
ADVERTISEMENT