Configuring BC548 NPN Transistor for Tuya Wifi Water Leakage Detector CB3S

belveder79 11 Feb 2024 12:06 4 1896 Cool? (+2)

📢 Listen (AI):

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.

Just acquired another WiFi Water Leakage Detector from Aliexpress

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

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

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.

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.

About Author

belveder79 wrote 15 posts with rating 2 , helped 1 times. Been with us since 2023 year.

Comments

Add a comment

p.kaczmarek2 11 Feb 2024 22:11

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... [Read more]

belveder79 12 Feb 2024 07:24

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...... [Read more]

p.kaczmarek2 12 Feb 2024 08:34

Is your WiFi crowded, have you tried changing the WiFI channel setting or moving sensors closer to router? [Read more]

belveder79 12 Feb 2024 09:10

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... [Read more]

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.