logo elektroda
logo elektroda
X
logo elektroda

Configuring BC548 NPN Transistor for Tuya Wifi Water Leakage Detector CB3S

belveder79 1896 4

TL;DR

  • A Tuya WiFi Water Leakage Detector with a CB3S/BK7231N board is adapted for wake-from-sleep operation.
  • A BC548 NPN transistor bridges 3.3V through a 10k resistor to the sensor and connector, enabling the wake trigger.
  • The detector runs from 2 AAA batteries, and the added relay mapping uses pin 14 for BAT_Relay and pin 23 for BAT_ADC.
  • Touching the sensor wakes the unit, and it then sleeps again as expected.
  • The flashing-tool extraction is incomplete, missing the relay, and battery consumption is still unknown.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):

  • Just acquired another WiFi Water Leakage Detector from Aliexpress

    https://de.aliexpress.com/item/1005005754072819.html

    WiFi water leakage detector with a white sensor and cord on a map background.

    which is a little different to this one here, but it essentially works the same way.

    WiFi water leakage detector with open casing and packaging. Close-up of the water leakage detector PCB with labeled connections 3.3V, TX, RX, and Gnd.

    It is powered with 2 AAA batteries, and as in the previous post, it simply goes to sleep, but does not wake up.

    In order to make this work, I followed the same procedure as in the upper post and used a BC548 NPN transistor between 3.3V (+10k resistor), one pin from the sensor to base and the other one to the connector on the board.

    Works as expected - goes to sleep, wakes up if you touch the sensor.

    Close-up of a water leakage detector circuit board showing electronic components and wires.

    The extraction from the flashing tool is incomplete and misses the relay, as the board has also a buzzer on the bottom. In order to use that one, you have to add it as a relay and configure it properly like this:

    
    {
      "vendor": "Tuya",
      "bDetailed": "0",
      "name": "Tuya WiFi Smart Water Leakage Detector (CB3S, no TuyaMCU)",
      "model": "unknown",
      "chip": "BK7231N",
      "board": "CB3S",
      "flags": "0",
      "keywords": [
        "water leakage",
        "CB3S",
        "Aliexpress"
      ],
      "pins": {
        "7": "Rel;0",
        "8": "DoorSnsrWSleep_nPup;0",
        "14": "BAT_Relay;1",
        "23": "BAT_ADC;1",
        "24": "Btn;0",
        "26": "WiFiLED_n;0"
      },
      "command": "",
      "image": "https://obrazki.elektroda.pl/1396778400_1707649738.jpg",
      "wiki": "https://www.elektroda.com/rtvforum/viewtopic.php?p=20955712"
    }
    


    I don't know about battery consumption. I do NOT have any custom script, so I will see how long it "survives" without tweaking it.

    Cool? Ranking DIY
    About Author
    belveder79
    Level 6  
    Offline 
    belveder79 wrote 15 posts with rating 2, helped 1 times. Been with us since 2023 year.
  • ADVERTISEMENT
  • #2 20957109
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14615
    Help: 655
    Rate: 12631
    While I indeed think you did a good job on modification, I am not sure if it really was required. I think a correct pin setting (pull up, pull down or none) with a proper DSEdge setting (DSEdge 0, or DSEdge 1, or DSEdge 2) would work well enough in OpenBeken. I already had seen a door sensor which also at first seemed unable to wake up from a one certain state, but it turned out that I had to change just the DSEdge setting. You can search other topics for more details:
    https://www.elektroda.com/rtvforum/find.php?q=DSEdge
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #3 20957358
    belveder79
    Level 6  
    Posts: 15
    Help: 1
    Rate: 2

    Thanks...

    You are totally right. I'm sure that it has to work with proper settings in OpenBeken concerning some DSEdge parameters and such because the unmodified setup also works with the Tuya firmware... Openbeken certainly has the required features... As in the other post, it did not work with the standard settings of nPup etc from the module config. So it can't go without some custom setting...

    My major problem is the connectivity of the chipsets overall concerning WIFI with OpenBeken. Because they (any of them CBU, CB3S etc.) don't connect at all most of the time to my network, playing around with settings is a really time-consuming task. I did not find a workaround yet, so overall the sensors from Tuya are right now more something that I look into out of interest, rather as a real solution...
  • ADVERTISEMENT
  • #4 20957427
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14615
    Help: 655
    Rate: 12631
    Is your WiFi crowded, have you tried changing the WiFI channel setting or moving sensors closer to router?
    Helpful post? Buy me a coffee.
  • #5 20957434
    belveder79
    Level 6  
    Posts: 15
    Help: 1
    Rate: 2

    I wrote about my experiences with door sensors here.

    I indeed have around 50 devices in my network, but I can essentially (and I did) add another 20-40 devices from mobiles to laptops and others. None had any problem, but the OpenBeken simply won't connect most of the time at all, or it takes almost forever.

    Added after 25 [minutes]:

    I usually run my network in 802.11b/g/n mode. What I can say is that when I run the network in 802.11b/g mode only, it works considerably better - not great, but at least I get a connection in 80% of all cases within the 60 seconds that the device is supposed to be alive when on battery....
📢 Listen (AI):

FAQ

TL;DR: For OpenBeken users fixing a Tuya CB3S leak sensor that sleeps but will not wake, a 2xAAA device was restored with a BC548 at 3.3 V through 10 kΩ; one expert noted, "a correct pin setting... would work well enough" without extra hardware. [#20957109]

Why it matters: This thread shows the practical trade-off between a hardware wake-up fix that works immediately and a software-only OpenBeken configuration that may solve the same problem more cleanly.

Approach What was changed Wake result Main drawback
BC548 hardware fix BC548 NPN, 3.3 V, 10 kΩ, sensor-to-base wiring Sleep and wake worked on touch Extra hardware modification
OpenBeken tuning Pull-up/pull-down and DSEdge settings Suggested as sufficient Requires testing and correct edge setup
Original Tuya firmware No hardware change Wakes correctly Does not solve OpenBeken behavior

Key insight: The hardware transistor mod proved the wake circuit can work, but the thread strongly suggests OpenBeken pin and DSEdge settings are the cleaner root-cause fix.

Quick Facts

  • The detector uses 2 AAA batteries, and the working hardware mod added a BC548 NPN transistor, 3.3 V, and a 10 kΩ resistor. [#20955712]
  • The posted OpenBeken export identifies BK7231N as the chip and CB3S as the board in a no TuyaMCU water leak detector. [#20955712]
  • The shared pin map assigns GPIO 7 = Rel;0, 8 = DoorSnsrWSleep_nPup;0, 14 = BAT_Relay;1, 23 = BAT_ADC;1, 24 = Btn;0, and 26 = WiFiLED_n;0. [#20955712]
  • On battery power, the device is expected to stay awake for about 60 seconds, and switching WiFi from 802.11b/g/n to 802.11b/g improved connection success to roughly 80%. [#20957434]
  • The reported network had about 50 devices already connected, and even adding 20–40 more did not affect other clients the way OpenBeken sensors were affected. [#20957434]

How do I wire a BC548 NPN transistor to make a Tuya CB3S WiFi water leakage detector wake up properly in OpenBeken?

Wire the BC548 between the sensor and the board so the detector can wake reliably. 1. Connect 3.3 V to the transistor path through a 10 kΩ resistor. 2. Connect one sensor pin to the base. 3. Connect the other sensor pin to the board connector. In the reported build, that made the 2xAAA detector sleep normally and wake when the sensor was touched. [#20955712]

Why does this Tuya WiFi water leakage detector go to sleep but not wake up without the BC548 transistor modification?

It sleeps correctly, but the wake signal is not interpreted correctly with the standard OpenBeken setup used in the thread. The unmodified device worked under Tuya firmware, which points to configuration rather than a dead sensor path. The BC548 fix effectively reshaped the trigger so touch on the leak probe produced a usable wake event. [#20957358]

What is DSEdge in OpenBeken, and how does it affect wake-up behavior for battery-powered sensors?

"DSEdge" is an OpenBeken configuration setting that selects which signal edge a deep-sleep sensor input reacts to, with options such as DSEdge 0, 1, or 2. It matters because the wrong edge can let a battery sensor sleep but block wake-up from one state. The thread notes that changing only DSEdge solved a similar door-sensor case. [#20957109]

What does the OpenBeken pin role DoorSnsrWSleep_nPup mean on a CB3S water leakage detector?

It is the pin role assigned to the leak-sensor wake input on this board export. In the shared configuration, GPIO 8 is set to DoorSnsrWSleep_nPup;0, which indicates a door-sensor-style wake/sleep input with an active pull-up-related behavior. That role is the key OpenBeken mapping for the sensor line on this CB3S leak detector. [#20955712]

How should I configure the buzzer on a Tuya CB3S water leakage detector when the flashing tool export misses it?

Configure the buzzer as a relay in OpenBeken. The flashing-tool export was incomplete and omitted the bottom-side buzzer, so the working fix was to add it as Rel;0 in the device JSON. In the posted map, that relay function is assigned to pin 7, which restores buzzer control. [#20955712]

Which OpenBeken pin mapping works for the Tuya WiFi Smart Water Leakage Detector with CB3S and no TuyaMCU?

The working mapping is the one explicitly posted for the BK7231N / CB3S / no TuyaMCU version. It uses 7=Rel;0, 8=DoorSnsrWSleep_nPup;0, 14=BAT_Relay;1, 23=BAT_ADC;1, 24=Btn;0, and 26=WiFiLED_n;0. That map was shared as the corrected export after accounting for the missing buzzer. [#20955712]

What is the difference between using a hardware BC548 transistor fix and changing DSEdge or pull-up settings in OpenBeken for wake-up issues?

The BC548 fix changes the electrical behavior, while DSEdge and pull settings change only OpenBeken input handling. The hardware method already worked in practice with 3.3 V and 10 kΩ, but it adds parts. The software route is cleaner because it may solve wake-up with no soldering if the correct pull-up, pull-down, and edge mode are found. [#20957109]

Why might a Tuya sensor wake correctly with the original Tuya firmware but fail to wake with standard OpenBeken settings?

It can happen because Tuya firmware already uses the correct wake logic, while the default OpenBeken role settings may not. The thread states the unmodified setup works with Tuya firmware, yet standard nPup-style settings in OpenBeken did not wake the sensor correctly. That points to missing edge or pull configuration rather than a hardware defect. [#20957358]

How can I troubleshoot poor WiFi connectivity on BK7231N devices like CB3S or CBU when running OpenBeken?

Start with channel and placement checks, then simplify the WiFi mode. The thread suggests testing whether the WiFi is crowded, changing the router channel, and moving the sensor closer to the router. Those steps target the exact complaint that CBU and CB3S devices often failed to connect or took a very long time under OpenBeken. [#20957427]

What router settings help OpenBeken battery sensors connect more reliably, especially 802.11b/g/n versus 802.11b/g mode?

Using 802.11b/g instead of 802.11b/g/n helped significantly in this case. The reported result was not perfect, but connection success rose to about 80% during the roughly 60-second awake window on battery power. That makes legacy mode a practical test setting for unstable OpenBeken battery sensors. [#20957434]

How does a crowded WiFi network affect OpenBeken connection times on Tuya battery-powered sensors?

A crowded network may worsen connection time, but this thread did not show a general network failure. The user already had about 50 devices online and could add 20–40 more phones, laptops, and others without issues. The slow or failed association mainly affected OpenBeken-based Tuya sensors, which suggests a device-or-firmware sensitivity rather than simple client count alone. [#20957434]

What is CB3S, and how is it used inside Tuya WiFi water leakage detectors?

"CB3S" is a Tuya WiFi module board that hosts the main wireless SoC and board-level GPIO functions inside compact IoT products, including battery leak detectors. In the posted export, the water sensor uses a CB3S board with a BK7231N chip and no TuyaMCU, and OpenBeken pin roles are mapped directly to that module. [#20955712]

How can I test whether changing pull-up, pull-down, or DSEdge settings will fix wake-up problems before adding external hardware?

Test software settings first by changing only the sensor input behavior and checking whether wake returns. 1. Keep the hardware unmodified. 2. Try pull-up, pull-down, or no-pull on the wake pin. 3. Cycle through DSEdge 0, 1, and 2 and retest wake from sleep. The thread specifically recommends this path because a similar deep-sleep sensor was fixed by DSEdge alone. [#20957109]

What should I monitor to estimate battery life after modifying a 2xAAA Tuya leak detector for OpenBeken?

Monitor survival time in real use, because the thread gives no measured current draw. The modified detector runs from 2 AAA batteries, and the author explicitly said there was no custom script and battery consumption was still unknown. Track how long it stays functional between battery changes after repeated sleep and wake events. [#20955712]

What alternatives are there if a Tuya CB3S water leak sensor is unreliable on OpenBeken and I need a practical long-term solution?

Use the original Tuya firmware or avoid relying on this hardware as a final deployment device. The thread author says these Tuya sensors are currently more an object of experimentation than a real solution because WiFi joins are often unreliable under OpenBeken. That is the clearest edge-case warning if you need dependable long-term leak alerts. [#20957358]
Generated by the language model.
ADVERTISEMENT