logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Tuya Water Sensor WiFi DY-SQ400B Flashing, Configuration for OBK Esphome/Tasmota style firmware

io2345 11367 113
Best answers

How to flash and configure the Tuya DY-SQ400B water sensor with its CB3S board for OpenBeken?

Flash it as a BK7231N/CB3S device, not TuyaMCU: make a 2 MB backup with BK7231GUIFlashTool first, then use the same tool’s Write option to flash OpenBeken [#21070016] [#21070089] [#21070895] The working pin map ended up as GPIO7 PWM for buzzer/LED on channel 5, GPIO8 DoorSnsrWSleep_nPup on channel 0, GPIO14 BAT_Relay on channel 1, GPIO23 BAT_ADC on channel 2, GPIO24 Btn_ScriptOnly, and GPIO26 LED on channel 5 [#21095640] For wake/sleep problems, the thread recommends DSEdge tuning (0/2 were both tried), and if the button causes unwanted actions, setting it to Btn_ScriptOnly; accidental childlock/disable-autostart flags should be cleared [#21072613] [#21086332] [#21403880] The final scripts used DSTime at the top of autoexec.bat for timed wakeups, with a loop that clears DSTime while $CH0==1 and an addChangeHandler to drive channel 5 to 80 when channel 0 goes high; DSTime must be the first line when used [#21089513] [#21091186] [#21095624] [#21095640] Battery reporting was calibrated with Battery_Setup values around 2800–2900 min, 3700–4100 max, 1.94 vdivider, plus Battery_cycle 20, and the new DSTime second argument can be used to force a periodic wakeup for battery updates [#21397320] [#21089513]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #91 21383516
    samoswall
    Level 5  
    Posts: 9
    Rate: 2
    >>21380844
    Yes, thank you! Moving to 1 line of DSTime works!

    Added after 33 [minutes]:

    A general question!
    We use the DoorSensor, and logically, opening is an important event!
    For a water leak sensor, on the contrary, closing is an important event.
    A binary sensor is automatically published in the Home assistant mqtt discovery.
    Code: text Expand Select all Copy to clipboard
    
{
  "dev": {
    "ids": [
      "Water_Leak_Posudomoika"
    ],
    "name": "Posudomoika",
    "sw": "1.18.12",
    "mf": "Beken Corporation",
    "mdl": "BK7231N",
    "cu": "http://192.168.1.23/index"
  },
  "name": "0",
  "~": "WaterLeakPosudomoika",
  "pl_on": "0",          <-- this
  "pl_off": "1",          <-- this
  "uniq_id": "Water_Leak_Posudomoika_binary_sensor_0",
  "qos": 1,
  "stat_t": "~/0/get"
}

    It would be more correct to change the water leak sensor.
    Code: text Expand Select all Copy to clipboard
    
  "pl_on": "1",
  "pl_off": "0",

    And add the device class moisture.
    I've set it up temporarily using MQTT Explorer.
    Is there any way to configure this, in the configuration for automatic changes?
  • ADVERTISEMENT
  • #92 21397272
    florianreus
    Level 5  
    Posts: 7
    Rate: 3
    Do you have a final autoexec script?
    - using the last ones sounds the alarm immediately
    - STime or DSTime? or is this the same?
    I'm sorry, I'm a beginner at openbeken.
  • ADVERTISEMENT
  • #93 21397320
    samoswall
    Level 5  
    Posts: 9
    Rate: 2
    >>21397272
    STime does not exist (DSTime is correct)
    My working autoexec.bat
    Code: text Expand Select all Copy to clipboard
    
DSTime 40 43200
Battery_Setup 2800 4100 1.94
Battery_cycle 20
delay_s 2
again:
delay_s 1
if $CH0==1 then DSTime clear
if $CH0==1 then setChannel 5 80
goto again
  • #94 21397367
    florianreus
    Level 5  
    Posts: 7
    Rate: 3
    hmm.
    then the alarm sounds immediately, and can not be turned off.
    the input is configured as doorsnsrwsleep_npup from the template.
  • #95 21397371
    samoswall
    Level 5  
    Posts: 9
    Rate: 2
    >>21397367
    As long as there is water, do not turn it off
  • #96 21397599
    florianreus
    Level 5  
    Posts: 7
    Rate: 3
    There's no water.
    With "old" autoexec alarm sounded when I connected the 2 pins. Now the alarm starts directly after boot
    And sleep did never work.
  • ADVERTISEMENT
  • #97 21397688
    samoswall
    Level 5  
    Posts: 9
    Rate: 2
    florianreus wrote:
    Now the alarm starts directly after boot

    Flag 42 - off
  • #98 21401601
    florianreus
    Level 5  
    Posts: 7
    Rate: 3
    thank you!

    last problem - it is never entering sleep state. Any idea? anywhere I can debug?
  • #99 21401937
    samoswall
    Level 5  
    Posts: 9
    Rate: 2
    >>21401601
    Insert DSEdge 0 into autoexec.bat in 2 lines
    DSEdge 0 was not activated in my configuration.
    But after several flashbacks, it was activated.
  • #100 21403880
    florianreus
    Level 5  
    Posts: 7
    Rate: 3
    and some trivial error - now I know I have to load the driver first.
    This is my working autoexec:

    Code: text Expand Select all Copy to clipboard
    startDriver DoorSensor
DSTime 40 43200
DSEdge 2
Battery_Setup 2800 4100 1.94
Battery_cycle 20
delay_s 2
again:
delay_s 1
if $CH0==1 then DSTime clear
if $CH0==1 then setChannel 5 80
goto again
  • #101 21403900
    samoswall
    Level 5  
    Posts: 9
    Rate: 2
    >>21403880
    DSEdge 0
    The "startDriver DoorSensor" is not necessary, because it starts automatically during configuration pins "8": "DoorSnsrWSleep_nPup;0"
  • #102 21405342
    florianreus
    Level 5  
    Posts: 7
    Rate: 3
    I'm quite sure pin 8 is configured. But without explicitly loading the driver I get "unknown command" for DSxx commands.

    Thanks for the help, and maybe my settings help someone.
  • #103 21417444
    tobb
    Level 9  
    Posts: 10
    Does anyone have experience with a different power supply? I have some spare 3.6 - 3.7 volt batteries that I could use. Will they fit? Will the voltage not be too high for this device?
  • #104 21417458
    tobb
    Level 9  
    Posts: 10
    Does anyone have experience with different methods of powering this device? I have some spare rechargeable batteries (Li-Ion, Li-MH) 3.6-3.7V. Will it work, or will the voltage be too high?
  • ADVERTISEMENT
  • #105 21417473
    LEDówki
    Level 43  
    Posts: 9358
    Help: 1305
    Rate: 2530
    You have a battery of 3 batteries connected in series. The minimum voltage is 3 V or 2.7 V when you charge this battery immediately. The maximum voltage of 3x1.54 V = 4.62 V can damage the circuits. You need to check what voltage they can be powered up to. A 2-battery battery may be a bit too low a voltage, as we have between 1.8 V and 3.08 V.
  • #106 21417489
    florianreus
    Level 5  
    Posts: 7
    Rate: 3
    I powered my first device using a Li-ion battery directly. It's not working anymore, but did work some time. It might be because of the too high voltage.
    My current device is powered with another 3.7 V battery, but I put in a Zener diode (I found in the house) in front so the voltage is limited to 3.3. This is working good.
  • #107 21417572
    LEDówki
    Level 43  
    Posts: 9358
    Help: 1305
    Rate: 2530
    LiFePO4 has a 3.65 V maximum. It does not need to be charged to the maximum voltage either. Discharge has to be finished at 2.5 V.
    NiMH 2 pieces connected in series will simulate a CR123A cell quite well Link .
  • #108 21417597
    tobb
    Level 9  
    Posts: 10
    Thank you for your help, I will try with 2xNiMH to start with
  • #109 21433583
    luki6991
    Level 2  
    Posts: 2
    Hello. Does anyone have a final autoexec.bat that is fully functional? I have a problem where my device cannot be awakened by high water after about 10 minutes. If someone has a completely working configuration, I would be grateful!
  • #110 21437976
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    The latest working autoexec.bat is in thread #100
  • #111 21440314
    luki6991
    Level 2  
    Posts: 2
    It still doesn’t work. Here is my import text:
    {
    "vendor": "Tuya",
    "bDetailed": "0",
    "name": "Floor sitting Water Leak Flood Sensor Alarm",
    "model": "DY-SQ400B",
    "chip": "BK7231N",
    "board": "CB3S",
    "flags": "8",
    "keywords": [
    "CR123A",
    "battery",
    "buzzer",
    "detector"

    ],
    "pins": {
    "7": "PWM;5",
    "8": "DoorSnsrWSleep_nPup;0",
    "14": "BAT_Relay;1",
    "23": "BAT_ADC;2",
    "24": "Btn_ScriptOnly;1",
    "26": "LED;5"
    },
    "command": "DSEdge 0",
    "image": "https://obrazki.elektroda.pl/6240569600_1714757661.jpg",
    "wiki": "https://www.elektroda.com/rtvforum/topic4052199.html"
    }

    Here is my autoexec.bat:
    startDriver DoorSensor
    DSTime 40 43200
    DSEdge 2
    Battery_Setup 2800 4100 1.94
    Battery_cycle 20
    delay_s 2
    again:
    delay_s 1
    if $CH0==1 then DSTime clear
    if $CH0==1 then setChannel 5 80
    goto again

    My device falls into such a deep sleep after a few minutes that not even high water can wake it up. I’m wondering if the issue could be with the flags. What flags should I have? Thanks!
  • #112 21859140
    tanyajeff03
    Level 2  
    Posts: 2
    does anyone have any insight on this. I have been messing around with this for a week. I can never get it to awake from deepsleep with moisture contact. only wakes up if i short the two probes.
    it's an sq400b-w a003
    dated 2023 03 11
    cb3s flashed with the open beken latest build from march 6 i believe.
  • #113 21859494
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14429
    Help: 650
    Rate: 12396
    The first thing to check would be DSEdge setting. Have you looked into it?
    Helpful post? Buy me a coffee.
  • #114 21859503
    tanyajeff03
    Level 2  
    Posts: 2
    >>21859494 >>21859494 Yes I have tried dsedge 0, 1 and 2 and none of them seem to make a difference!
    If it's awake and I wet the probes, the countdown for sleep resets and it trips every time. As soon as I let it go to deep sleep, then the only way to wake it up is to short the probes together. Been driving me crazy trying to figure this out! It worked properly with the stock firmware and the smartlife app. I have about 12 of these, but only flashed one to start to see if I can get it to work as I want to use it with home assistant and not be cloud connected.

    Added after 3 [hours] 13 [minutes]:

    So the latest I have it doing is it connects to Wi-Fi and all looks good. It goes to deep sleep and I wake it up by wetting the probes. Siren goes on and light goes on, but it doesn't reconnect to the Wi-Fi and power cycling doesn't allow it to connect again either until I go in safe mode, connect to the hotspot then exit safe mode and restart it.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on the Tuya WiFi Water Sensor DY-SQ400B equipped with a CR123A 3V battery and a CB3S communication board. Initial attempts to identify the device as a TuyaMCU-based module via UART communication failed, revealing no MCU communication on TX1 and unclear signals on TX2. Subsequent analysis confirmed the device uses a BK7231N chip rather than a TuyaMCU. Firmware backup and flashing were performed using the BK7231GUIFlashTool, enabling installation of OpenBeken (OBK) firmware. Configuration involved setting pin roles for sensor input, button, LED, buzzer (PWM on pin 7), and battery monitoring (BAT_Relay and BAT_ADC). The DoorSensor driver was adapted for water detection with deep sleep management to conserve battery life. Users developed autoexec.bat scripts to handle deep sleep wakeup on sensor trigger or button press, battery voltage reporting, and continuous alarm signaling during water detection. Issues addressed included configuring DSEdge to enable wakeup on both signal edges, managing MQTT message intervals, and separating button functions to avoid false alarms. The final working configuration includes scripted channel handlers to activate buzzer and LED alarms on water detection, with manual button wakeup without triggering alarms. The community also discussed firmware update procedures, file system management for autoexec.bat, and integration with home automation via MQTT. The thread concludes with a stable setup for reliable water leak detection, battery monitoring, and alarm signaling using OpenBeken firmware on the DY-SQ400B sensor.
Generated by the language model.
Today's popular

FAQ

TL;DR: A safe workflow starts with a 2MB backup and the CB3S/BK7231N pin map; as one maintainer put it, "Both flashing and TuyaMCU are using UART1." This FAQ is for DY-SQ400B owners who want OpenBeken deep sleep, MQTT, buzzer, and battery reporting without losing stock firmware first. [#21069433]

Why it matters: The DY-SQ400B can work well on OpenBeken, but deep-sleep wake behavior, DSEdge, battery scaling, and script order decide whether it becomes a reliable leak alarm or an unusable sensor.

Option Wake reliability from moisture Local buzzer/LED behavior Battery reporting
Stock Tuya firmware Worked reliably for affected users Native alarm behavior present Native cloud/app reporting
OpenBeken, basic template only Can fail or wake only on probe short Often incomplete until PWM/script tuning Wrong until Battery_Setup is tuned
OpenBeken, final tuned template + autoexec Reported working with deep sleep, buzzer, MQTT, and timed wake Works after PWM on pin 7 and script logic Works after DSTime and Battery_Setup tuning

Key insight: The DY-SQ400B is not a TuyaMCU device in this thread’s findings. The stable OpenBeken setup came from backup-based pin extraction, DSEdge tuning, a filesystem autoexec.bat, and a script that clears DSTime while channel 0 stays active.

Quick Facts

  • The device discussed uses a CB3S board with BK7231N, a CR123A 3V battery, and a stock firmware dump workflow centered on a 2MB flash backup before modification. [#21070110]
  • The extracted stock config mapped key pins as button P24, status LED P26, sensor P8, battery relay P14, battery ADC P23, and buzzer P7. [#21070110]
  • Early battery readings were badly wrong at about 4.4V to 4.8V, but later tuning with Battery_Setup produced realistic values around 3382–3403 mV and 73–75%. [#21086071]
  • A working timed wake example used DSTime 100 6000, where 100 is awake time and 6000 seconds is the auto-wake interval; later users confirmed timed wake works when DSTime is placed first in autoexec.bat. [#21089513]
  • Final shared working configs used pin 7 as PWM;5, pin 8 as DoorSnsrWSleep_nPup;0, pin 24 as Btn_ScriptOnly;1, and pin 26 as LED;5. [#21095640]

How do I flash a Tuya DY-SQ400B water leak sensor with a CB3S/BK7231N module to OpenBeken and make a safe 2MB firmware backup first?

Use the BK7231 GUI flash tool and read the flash before writing anything. 1. Open the case, connect UART1 on the CB3S, and power the board. 2. In the tool, use Read firmware to make a 2MB backup. 3. Only after that, use the write option to flash OpenBeken. The thread confirms the tool can do a backup first, and the maintainer explicitly pointed to the Read firmware button for a 2MB dump that can later extract device configuration. [#21070089]

What is DSEdge in OpenBeken, and how do I choose the right DSEdge setting for a DY-SQ400B water sensor that won’t wake reliably from deep sleep?

DSEdge is the deep-sleep wake edge selector, and you choose it by testing which transition wakes your specific sensor reliably. "DSEdge is a deep-sleep wake setting that selects which GPIO transition wakes the device, and its key characteristic is that different hardware reacts to different edges or both." In this thread, DSEdge 0 fixed one user’s device, while another later reported DSEdge 2 in a working setup. Start with 0, then test 1 and 2 with button fallback enabled. [#21075813]

What is autoexec.bat in OpenBeken, and where exactly do I create and edit it in the Web Application for the DY-SQ400B?

autoexec.bat is the startup script file that OpenBeken runs on boot, and you create it in the Web Application filesystem. "autoexec.bat is a startup script file that stores persistent commands, and its key characteristic is that OpenBeken executes it automatically after boot." 1. Open Launch Web Application. 2. Go to Filesystem → List Filesystem. 3. If autoexec.bat is missing, create it with Create File, then edit it in the file editor on the right. [#21339745]

Why does the DY-SQ400B sometimes wake only when the probes are shorted directly, but not when moisture is present on the contacts?

Because the wake circuit can react differently to a hard short than to a resistive moisture path. One 2026 user reported the sensor always woke when the probes were shorted, but not when moisture bridged them, even though stock Tuya firmware had worked correctly before flashing. That points to edge detection and wake-threshold behavior, not dead hardware. The practical fix in the thread was to test DSEdge values and confirm wake behavior with real moisture, not only metal shorting. [#21859503]

How do I configure the final working OpenBeken template for the Tuya DY-SQ400B, including PWM buzzer, DoorSnsrWSleep_nPup, battery ADC, and Btn_ScriptOnly?

Use the final shared template with pin 7 as PWM, pin 8 as DoorSnsrWSleep_nPup, pin 23 as BAT_ADC, and pin 24 as Btn_ScriptOnly. The last posted working JSON used: 7: PWM;5, 8: DoorSnsrWSleep_nPup;0, 14: BAT_Relay;1, 23: BAT_ADC;2, 24: Btn_ScriptOnly;1, 26: LED;5, plus command: DSEdge 0 and flags: 8. That template was shared after the buzzer, button, battery, and wake issues were resolved. [#21095640]

Why does the water leak alarm start immediately after boot on some OpenBeken configs, and which flags or script lines cause that behavior?

It starts immediately when the script forces the buzzer channel on at boot, not only on flood. In the thread, the culprit was setChannel 5 80 placed unconditionally near the top of autoexec.bat; that made the LED and buzzer activate right after boot. Another user also reported that turning Flag 42 off stopped immediate alarm behavior in a later setup. If you want alarm only on water, remove unconditional setChannel lines and trigger PWM from channel changes instead. [#21097688]

What is the difference between DoorSnsrWSleep, DoorSnsrWSleep_nPup, and the other DoorSensor variants in OpenBeken for battery-powered water sensors?

The variants mainly change input polarity and pull-up behavior, and that changes wake reliability. In this thread, plain DoorSnsrWSleep caused unstable behavior, while users reported that the other two door-sensor variants worked better for this water sensor, especially DoorSnsrWSleep_nPup. That variant became the final shared choice on pin 8. The practical rule here is simple: try the _nPup form first on the DY-SQ400B, then test other variants only if wake or state logic is inverted. [#21074406]

How can I stop the deep sleep countdown while a flood condition is active so the DY-SQ400B keeps alarming until the battery dies or the leak is cleared?

Loop on channel 0 and clear DSTime whenever the flood state stays active. The maintainer provided a tested approach: use an again: loop, delay_s 1, and if $CH0==1 then DSTime clear. A later working script added the buzzer with addChangeHandler Channel0 == 1 setChannel 5 80, so the siren starts when channel 0 goes high and the countdown keeps getting reset. That creates an effectively continuous alarm until power is exhausted or the leak clears. [#21095640]

What’s the right way to make the DY-SQ400B wake up automatically once a day to report battery values over MQTT while still using the DoorSensor driver?

Use the newer two-argument DSTime command in autoexec.bat, with the second value set to the auto-wake interval in seconds. The maintainer added this so DSTime 100 6000 means 100 seconds awake and 6000 seconds until forced wake. Users later confirmed the feature worked on hardware when placed correctly in the script. For once-daily reporting, use roughly 86400 seconds as the second argument and keep the DoorSensor-based flood wake on channel 0. [#21089513]

Why do DSTime commands only work when placed at the top of autoexec.bat on this Tuya water sensor?

Because the timed wake setting must be applied before later script logic and driver activity interfere with deep-sleep handling on this device. A user tested it directly and reported that timed wake worked only after moving DSTime to the first line of autoexec.bat. The same user said placing it at the end did not work. On this DY-SQ400B, treat DSTime as an early startup command, ahead of Battery_Setup, loops, and alarm handlers. [#21091186]

How should I tune Battery_Setup and Battery_cycle in OpenBeken so the DY-SQ400B reports a realistic CR123A battery voltage instead of 4.4V or 4.8V?

Tune Battery_Setup empirically against a multimeter and keep Battery_cycle moderate, such as 20 seconds while testing. Early untuned readings were about 4414–4823 mV, which was clearly wrong for a 3V CR123A device. Later working values included Battery_Setup 2900 3700 1.94 and Battery_cycle 20, producing readings around 3382–3403 mV and 73–75%. The shared thread conclusion was that battery reporting is usable only after calibration, not with extractor defaults alone. [#21095369]

How do I enable and tune the buzzer on pin 7 with PWM in OpenBeken, and what do setChannel and PWMFrequency actually do on this device?

Assign pin 7 to a PWM role, give it a PWM channel, and drive that channel from the script. The maintainer’s method was: set pin 7 to PWM, put it on a channel such as 5, enable raw PWM controls if needed, then test commands like PWMFrequency 1000 and setChannel 5 50. In this device, setChannel changed duty level and audibly drove the buzzer; one user preferred values around 78–99, describing the sound as a police siren. PWMFrequency had little audible effect on that buzzer. [#21077971]

Why does pressing the hardware button publish 100 to the MQTT state topic, and how does changing the pin role to Btn_ScriptOnly fix it?

Because the normal button role interacted with the LED driver and pushed channel 0 to dimmer-style values like 100. The logs showed button presses publishing led_enableAll, led_dimmer, and then 100 to the main MQTT state topic. The maintainer identified that as automatic button interaction and advised changing the role to Btn_ScriptOnly. After that change, the device still woke on button press, but it stopped publishing spurious 100 values to the water sensor state topic. [#21086332]

OpenBeken vs stock Tuya firmware on the DY-SQ400B: which one handles deep sleep wakeup and moisture detection more reliably?

Stock Tuya firmware handled moisture wake more reliably in the unresolved edge cases shown here. Multiple users got OpenBeken working well after tuning, but later reports still described devices that woke only on a hard short or failed to reconnect cleanly after moisture wake. One 2026 user stated the stock Smart Life firmware had worked properly, while the flashed unit did not reliably wake from deep sleep on wet probes. OpenBeken wins on MQTT, local scripting, and cloud-free control, but stock looked more robust by default. [#21859503]

What power options are safest for the DY-SQ400B besides a CR123A cell, and how do Li-ion, LiFePO4, or 2xNiMH compare for voltage compatibility?

The safest alternatives mentioned were LiFePO4 or 2xNiMH, not a bare 3.7V Li-ion cell. A user reported one device had worked for a while on direct Li-ion, then died, suggesting overvoltage damage. Another participant recommended LiFePO4 because its maximum is about 3.65V and said 2xNiMH in series simulates a CR123A reasonably well. In contrast, fresh 3-cell alkaline packs can exceed 4.6V, and even 3.7V Li-ion can be too high without regulation or a drop element. [#21417572]
Generated by the language model.
ADVERTISEMENT