FAQ
TL;DR: For OpenBK users flashing the QS-WIFI-S10-C04, the key facts are 2MB full backup size and this expert rule: "the backup should be full 2MB". This FAQ helps you wire, flash, template, and script the CBLC9/BK7231N version safely, including relay interlock and button logic. [#21049729]
Why it matters: This module can drive a curtain motor directly, so a bad template or missing interlock can energize both directions at once.
| Method |
Hardware needed |
Main risk |
Best use |
| UART flashing |
USB-UART, short wires, stable power |
"getting bus" failures |
Reliable recovery and full backup |
| Tuya Cloudcutter |
No soldering if exploit works |
Newer secure batches may fail |
Fast OTA-style conversion |
| Tasmota-style shutter UX |
Different firmware behavior |
Better HA button layout, not the same scripting model |
Users prioritizing UI parity |
Key insight: Treat the CBLC9/BK7231N module and newer look-alike revisions as different devices. The original thread template fits the 2024 CBLC9 board, but a later 2025 revision reportedly changed MCU and pinout.
Quick Facts
- Board reported in the working teardown: QL-0887 Rev. A, dated 2024.01.23, with CBLC9 / BK7231N and named QS-WIFI-S10-C04 Mini WiFi Curtain Module. [#21049246]
- Confirmed working pin map for the original board: P7 = relay down, P9 = relay up, P8 = WiFi LED, P24 = internal push button, P6 and P26 = external switch inputs, VCC = 3.3V. [#21049246]
- Full flash backup should be 2MB, not about 1.1MB. The short dump blocks later config extraction. [#21049729]
- A stable read often requires the flasher to start first, then a power replug on 3.3V so the tool catches boot and gets the bus. [#21049246]
- One user measured about 19V AC on an inactive relay output and 220V AC when active, with no motor connected; the thread treated the off-state reading as normal leakage on cheap hardware. [#21628727]
How do I flash the QS-WIFI-S10-C04 curtain module with a CBLC9/BK7231N board using OpenBK and a UART adapter without desoldering the module?
You can flash it over exposed UART pads without desoldering the module. 1. Connect GND, 3.3V, and the CBLC9 UART lines with very short wires. 2. Start the OpenBK Python flasher or BK7231GUIFlashTool and let it try to detect the bus. 3. Briefly disconnect and reconnect 3.3V so the tool catches boot, then read or flash. A working report used the Linux CLI flasher and said detection happened only after reconnecting 3.3V during the attempt.
[#21049246]
Why does BK7231GUIFlashTool get stuck on "getting bus" or crash near 100% when reading the QS-WIFI-S10-C04, and what wiring or power changes usually fix it?
It usually fails because of weak power or long wiring. The thread points to three fixes: use much shorter leads, avoid powering from a weak 3.3V pin on a USB-UART dongle, and start the read first so the flasher waits at "getting bus" before you cycle power. One user reached 100/100 and then crashed, while the reply called the wires "unacceptably long" and asked whether the board was powered from a proper supply path instead of a low-current UART adapter.
[#21125926]
What is the correct pinout and OpenBK template for the QS-WIFI-S10-C04 Mini WiFi Curtain Module with the CBLC9 board?
For the original CBLC9 board, the thread template maps
P6 = Btn;1,
P7 = Rel;2,
P8 = WifiLED_n;0,
P9 = Rel;1,
P24 = Btnl;32, and
P26 = Btn;2. The board table also labels P7 as relay down, P9 as relay up, P24 as the internal push button, and VCC as
3.3V. The posted JSON identifies the device as
QS-WIFI-S10-C04, model
Mini WiFi Curtain Module, chip
BK7231N, board
CBLC9, with
PowerSave 1.
[#21049246]
What's the best way to enter flashing mode on a BK7231N module when the flasher only detects the bus after reconnecting power?
The best method is to let the flasher wait first, then power-cycle the module. 1. Enable read or flash so the tool starts "getting bus." 2. Disconnect 3.3V from the WiFi module side for a moment. 3. Reconnect power so the flasher catches boot. This exact pattern was confirmed in the thread, and another reply repeated the same idea: start the flasher first, then cut and restore power so it "catches" the chip booting up.
[#21125926]
Why does Tuya Cloudcutter fail with "The profile you selected did not result in a successful exploit" on some QS-WIFI-S10-C04 devices?
It fails because newer batches may already be secured, and the device may not actually be in the required AP pairing mode. The thread says many new devices are secure and that newer batches of this model may also resist exploitation. The same reply also says the error text suggests AP pairing mode was not set correctly, so failure does not prove the exploit is impossible. That makes this a batch-dependent and setup-dependent failure case.
[#21124664]
What is Tuya Cloudcutter, and how is it different from flashing a BK7231N curtain module over UART?
"Tuya Cloudcutter" is an OTA exploit tool that tries to replace Tuya firmware without opening the device, unlike UART flashing, which uses direct wired access to the chip bootloader. In this thread, Cloudcutter was tried with a
tuya-generic-2ch-curtain-module profile and could save device config, but selected profiles sometimes failed to exploit. UART flashing needed exposed pins, short wires, and power timing, but it gave direct read and write access even when OTA methods were blocked.
[#21124638]
What does "interlock" mean for a curtain or roller shutter module, and how do I configure it in OpenBK so both relays can’t turn on at the same time?
"Interlock" is control logic that prevents opposite motor directions from energizing together, a key safety feature for curtain and shutter modules. In this thread, missing interlock caused both relays to turn on at once, which the user said could burn the motor. The practical OpenBK fix was to script every open or close action so it first forces both channels off, then enables only one relay after a short
delay_s 0.1. The posted aliases used
Set_Stop before
Set_Open or
Set_Close.
[#21142835]
How can I make the QS-WIFI-S10-C04 internal or external buttons behave like the original Tuya firmware in OpenBK, with open, stop, and close logic instead of energizing both relays?
Map the physical buttons to scripted actions, not directly to raw relays. In the working examples, OpenBK uses aliases such as
Start_Opening,
Start_Closing, and
Stop_All, then binds button events with
addEventHandler so a press runs logic that first stops both relays and only then starts the requested direction. That avoids the bad case where pressing the opposite direction leaves one relay on and brings the second on too. One working setup used
GPIO 24,
26, and event handlers for hold and click actions.
[#21142835]
Why do GPIO 6 and 26 stop working as Button in OpenBK on this curtain module while dInput still detects presses?
The thread shows that
Button can stop detecting state changes on this module, while
dInput still works. One user tested OpenBK
1.17.654 and
1.17.656, downgraded again, and still saw the problem. They also used the GPIO finder and reported that
Button showed no value changes, but
dInput did. Another later working state-machine example explicitly chose
dInput for pins
6,
24, and
26 because
Button would not work reliably.
[#21194168]
How do I write an autoexec.bat for OpenBK that adds proper open, close, stop, and timed position tracking for a BK7231N curtain controller?
Use aliases plus relay change handlers and one travel-time channel. A proven script in the thread sets a full-travel time with
setChannel 40 42, creates
Open and
Close toggle channels, then updates a read-only position channel
41 once per second with repeating events until the relay auto-stops. That design gives open, close, stop, and approximate timed position in seconds. If you want a simpler model, another user built a 5-state machine with
20 seconds travel and separate soft buttons.
[#21151245]
Why does the position channel in my OpenBK shutter script go below 0 or above the full travel time when I press Open or Close repeatedly?
It happens because the script keeps counting past the valid range when repeated commands restart movement without clamping the position. In the reported case, channel
41 should stay between
0 and
42, but repeated
OPEN could push it to
-42, and repeated
CLOSE could push it to
84. The fix is to clamp the channel or use a state-machine approach that cancels prior repeating events before starting a new motion. A later example used
ClampChannel 43 0 4 for state control and cleaner transitions.
[#21151245]
How do I send custom OpenBK aliases like btn-open and btn-close from Home Assistant over MQTT or HTTP?
You can call them directly over HTTP or publish them to the OpenBK command topic over MQTT. One user confirmed HTTP syntax such as
http://deviceip/cm?cmnd=btn-open and
...btn-close. A later reply says to do it in Home Assistant "just like with Tasmota" by publishing under the
cmnd topic. That gives you two clean integration paths: raw HTTP calls or MQTT command publishing.
[#21708902]
OpenBK vs Tasmota for curtain modules in Home Assistant — which one gives better shutter controls, MQTT behavior, and UI buttons?
In this thread, Tasmota gave the better Home Assistant shutter-style UI. A user compared both and said the Tasmota controls matched the function much better, with
up/down arrows and a center stop button, while OpenBK exposed a different layout and MQTT behavior. OpenBK still worked, but users often needed custom scripts or aliases to mimic curtain semantics cleanly. So if you want native-looking shutter controls, Tasmota looked better here; if you want flexible scripting, OpenBK offered more customization.
[#21217204]
Why do I measure about 19V AC on the relay output of the QS-WIFI-S10-C04 when the relay is off, and is that normal for this hardware?
Yes, the thread treats that as normal for this hardware. One user measured about
19V AC on the relay output when off and about
220V AC when on, with no motor connected. The later reply said this is correct and blamed the small off-state voltage on cheap hardware design. In practice, that means you may see ghost voltage on a high-impedance meter even though the relay is not actively driving the motor.
[#21628727]
How can I identify whether a new-looking QS-WIFI-S10-C04 revision uses BK7231N, BK7238, or Tuya T1-M hardware, and when should it be treated as a different device template?
Open the device and verify the PCB, MCU family, and working pinout before reusing any old template. The original working unit was
CBLC9 / BK7231N on board
QL-0887 Rev. A 2024.01.23. A later 2025 report described a fresh revision with different MCU, different pinout, and PCB changes, readable as
7238, while another reply linked it to
Tuya T1-M logs and said it should go to a new topic because of changed hardware. Treat any such revision as a different template immediately.
[#21750025]
Generated by the language model.
