Door Sensor D06 (BK7231N/CB3S) with TuyaMCU (DeepSleep)

CMY 13 Jan 2024 03:37 52 9942 Cool? (+3)

📢 Listen (AI):

TL;DR

Teardowns the Door Sensor D06 with a BK7231N/CB3S Wi‑Fi module and TuyaMCU, including its magnet sensor, battery reporting, and deep-sleep behavior.
The BK7231N talks only to TuyaMCU over serial, and even the LED and Wi‑Fi power are controlled by TuyaMCU.
Active current reaches ~75..80mA, sensor sleep is 13uA, and BK7231N DeepSleep still leaves the unit at ~20uA.
OpenBK firmware was uploaded via serial and worked well, with RX1/TX1 connected to TuyaMCU and channels mapped for door state and battery.
Tuya-cloudcutter failed because the binary appears patched, and firmware updates otherwise require desoldering the chipset since TX/RX are already tied to TuyaMCU.

Generated by the language model.

One more Door Sensor

First Look
WiFi Chipset BK7231N/CB3S connected only to TuyaMCU via serial interface. Even LED connected to TuyaMCU.
TuyaMCU has power control for WiFi module.

There are two pins on the bottom of the board P3 and P2. Seems like this is for external sensor like a water leak sensor. To use it need Q2, R10, R9. But it use the same TuyaMCU pin that used for Magnetic Field Sensor now. So U3 needs to be dismounted in this case. (??? maybe they have a HighZ output and can work at the same time)

Firmware update
Firmware update possible only by desoldering chipset because TX-RX already connected to TuyaMCU .

Or maybe OTA?

OTA is probably possible via tuya-cloudcutter project https://github.com/tuya-cloudcutter/tuya-cloudcutter/tree/main
I found 2 similar sensors there:
- https://github.com/tuya-cloudcutter/tuya-clou...es/tuya-generic-cb3s-door-sensor-v1.0.10.json
- https://github.com/tuya-cloudcutter/tuya-clou...b/master/devices/avatto-ds06-door-sensor.json
Last one looks better.

Unfortunately, my unit has a new firmware version, so tuya-cloudcutter doen't work for it. No OTA update for today.
I conected it via serial inteface, and download original firmware. (You don't need to desolder WiFi chip, easy way to take of TuyaMCU. I has only 8 pins)

tuya-cloudcutter/profile-building/build_profile.py gaves me this:

[+] Processing file='Tuya-Generic_DoorSensor-D06.bin' as Tuya-Generic_DoorSensor-D06
RBL containers:
        0x10f9a: bootloader - [encoding_algorithm=NONE, size=0xea20]
                extracted to Tuya-Generic_DoorSensor-D06
        0x129f0a: app - [encoding_algorithm=NONE, size=0xe0820]
                extracted to Tuya-Generic_DoorSensor-D06
Storage partition:
        0x1ee000: 60 KiB - 7 keys
        - 'gw_bi'
        - 'gw_di'
        - 'wf_start_md'
        - 'gw_wsm'
        - 'gw_ai'
        - 'record_head'
        - 'baud_cfg'
                extracted all keys to Tuya-Generic_DoorSensor-D06/Tuya-Generic_DoorSensor-D06_storage.json
App code `user_param_key`:
        - not found!
[+] Searching for known exploit patterns
[+] Matched pattern for BK7231N version SDK 2.3.1, payload type ssid
[!] The binary supplied appears to be patched and no longer vulnerable to the tuya-cloudcutter exploit.

OpenBK firmware was uploded via serial inteface and working good.

Draft config

Pins:
RX1 and TX1 connected to TuyaMCU.

TuyaMCU channels
#1 - Door Sensor (0-Closed, 1-Open)
#3 - Battery ( 2 -> 3V, 1-> ???, 0->??? )

Everything exactly like here Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

Just a log of TuyaMCU communication:

Info:CMD:[WebApp Cmd 'uartSendHex 55 AA 00 01 00 00 00' Result] OK
Info:TuyaMCU:TUYAMCU received: 55 AA 00 01 00 24 7B 22 70 22 3A 22 6E 79 77 72 76 67 68 7A 30 6F 32 74 71 32 67 34 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D B1 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"nywrvghz0o2tq2g4","v":"1.0.0"}

Info:CMD:[WebApp Cmd 'uartSendHex 55 AA 00 02 00 01 04 06' Result] OK
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 01 00 01 00 22 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 19 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 1-bool and 1 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 1 byte: 0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 01 00 01 01 23 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 19 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 1-bool and 1 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 1 byte: 1
Info:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 19 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 3, dataType 4-enum and 1 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 1 byte: 2

Power consumption
~75..80mA - WiFi on and sending data to MQTT server
13uA - Sensor sleeping

For a test, I put BK7231N in to DeepSleep mode and all unit has ~20uA. So, It not so good as I was expected, and cutting power from WiFi chip is saving only ecreasing curent from 20uA to 13uA.
Cons of using TuyaMCU:
- no way to control main loop via BK7231N firmware (it will be power on only when TuyaMCU will do)
Pros:
- less power consumption
- TuyaMCU collect data (sensor status) while WiFi is booting. For example: door was opened, and closed several times during WiFi was booting. Tuya MCU will remember this, and will send this information to BK7231N.

Links
Aliexpress: https://www.aliexpress.us/item/3256805832136366.html

https://fccid.io/2ANK8-D06/Internal-Photos/09-D06-IntPho-4574559

https://www.elektroda.com/rtvforum/topic3866123-420.html#19982243

Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

Door Sensor 19JWT-B (BK7231N)

More information to come...

About Author

CMY wrote 6 posts with rating 5 . Been with us since 2024 year.

Comments

Add a comment

CMY 14 Jan 2024 19:15

I can't understand, what "startDriver tmSensor" for? Seems like it's in "src/driver/drv_tuyaMCUSensor.c" But it's doing nothing. All actions are commented now. [Read more]

p.kaczmarek2 20 Jan 2024 11:15

@cmy I know this is unfortunate, but tmSensor code is now integrated with TuyaMCU driver, so it is still required to run , it's just the functions are in the other file. Everything should be okay once... [Read more]

CMY 21 Jan 2024 22:30

Sure. But in this case better get this one "Door Sensor 19JWT-B (BK7231N)" https://www.elektroda.com/rtvforum/viewtopic.php?p=20906219 Or you can - remove power controll Triac, - connect WiFi... [Read more]

p.kaczmarek2 22 Jan 2024 08:27

Your concept is very interesting, @cmy , but wouldn't that reduce battery life, with both MCU and BK draining current slowly? [Read more]

CMY 22 Jan 2024 23:35

I alredy cheked it. So. Yes, 13uA vs 20uA. About +50% in deep sleep mode. It is all depends. But if i wanna do this, i will wakeup WiFi module like a every 5 min. And this will be more effected... [Read more]

divadiow 18 Aug 2024 07:59

https://github.com/OpenBekenIOT/webapp/pull/141/commits/879c3d9f8c0413b874174c440eacd1a73da4c7da [Read more]

divadiow 07 Nov 2024 22:38

backup from my own exact device + boot log V:BK7231N_1.0.1 REG:cpsr spsr r13 r14 SVC:000000D3 00401C1C 000033AC IRQ:000000d2 00000010 00401e0c de717d4f FIR:000000d1 00000010... [Read more]

hojnikb 09 Nov 2024 10:48

Would it be possible to remove tuyamcu entirely and use magnetic chip directly? And magentic chip would serve as a wakeup from deepsleep for wifi chip? I find that on my device, it's not working very... [Read more]

divadiow 09 Nov 2024 16:07

I believe so. @pkaczmarek2 has suggested such a step with other devices before though I've never actually progressed to trying. Is it basically trace the legs from TuyaMCU to each main component, button,... [Read more]

p.kaczmarek2 09 Nov 2024 21:29

We've been planning to make such tutorial with @DeDaMrAz . It should be possible to convert TuyaMCU devices to Beken-only DeepSleep. The magned sensor could be dinput as @divadiow says, but you can also... [Read more]

divadiow 11 Nov 2024 21:29

my hacky TuyaMCUless prototype. not 100% sure of the LED/GND situation. And I don't know if there's a BAT_ADC/BAT_REL - could the MCU have done this measurement internally? https://obrazki.elektroda.pl/1093702600_1731356814_thumb.jpg... [Read more]

p.kaczmarek2 12 Nov 2024 00:43

Nice, does deep sleep work as well? Also... your MCU was in SO8 case? That seems unusual for me. I saw many devices with SO16-etc MCUs. [Read more]

divadiow 12 Nov 2024 08:14

yes. with: "7": "DoorSnsrWSleep;1", "8": "Btn;2", "14": "WifiLED;2" same wake with button. no additional DSEdge config. Closed/magnet = channel 1 value 0, open/no magnet = channel... [Read more]

p.kaczmarek2 13 Nov 2024 09:21

So it's easier than I expected. Please consider making a separate guide for Smart Home Tutorials section. I see you also labeled pins on the MCU - so there is not BAT_ADC pin? I guess you may need to... [Read more]

divadiow 13 Nov 2024 10:08

could.do. I also have the solder-less flashing thing to do. I didn't want to distract from you and @dedamraz's upcoming guide and I didn't document what I did in infinite detail ;) I don't *think*... [Read more]

hojnikb 03 Dec 2024 13:25

Could you provide schematic or some sort of tuturial on how to make it tuyaless ? Or at least which connections to bridge, so it would work without the MCU. [Read more]

divadiow 03 Dec 2024 16:33

I didn't do any more, but the steps to date can be boiled down to: -remove TuyaMCU with solder sausage method (demonstrated here https://www.youtube.com/watch?v=fSbeKwCCMHM) -solder wires between these... [Read more]

hojnikb 03 Dec 2024 17:34

Thank you! [Read more]

divadiow 03 Dec 2024 20:32

bit more info. The P558K component is a hall-effect sensor. This is what the magnet needs to get close to https://obrazki.elektroda.pl/2642279600_1733254347_thumb.jpg [Read more]

FAQ

TL;DR: If you own a D06 or ZY-D02, expect about 13 µA asleep and 75–80 mA during Wi‑Fi send; the practical lesson is: "startDriver tmSensor" is still required. This FAQ helps OpenBeken users flash, map TuyaMCU datapoints, remove the MCU if needed, and fix deep sleep, battery, and Home Assistant discovery issues. [#20906465]

Why it matters: These sensors look simple, but their behavior changes completely depending on whether TuyaMCU still controls power or CB3S runs the hall sensor directly.

Approach	Sleep current	Control model	Main advantage	Main drawback
D06 with TuyaMCU intact	~13 µA	TuyaMCU wakes BK7231N	Lowest standby current	BK firmware cannot control main loop
D06 with BK7231N DeepSleep, TuyaMCU still present	~20 µA	BK deep sleep	More firmware freedom	Only ~7 µA worse than full cut-off
Beken-only conversion	not quantified in-thread	BK7231N controls sensor directly	Full OpenBeken control, DoorSensorWithDeepSleep works	Requires MCU removal and rewiring
Beken-only model such as 19JWT-B	not quantified in-thread	Native BK design	Simpler for OBK control	Different hardware choice

Key insight: On this hardware, TuyaMCU saves only a small amount of standby current versus BK deep sleep, but it limits control. If you want reliable, fully configurable OpenBeken behavior, removing TuyaMCU and using DoorSensorWithDeepSleep is the cleanest end state.

Quick Facts

Measured current on the D06 was ~75–80 mA while Wi‑Fi was on and sending MQTT data, and 13 µA while sleeping under TuyaMCU power control. [#20906465]
With BK7231N forced into DeepSleep, the whole unit measured ~20 µA, so cutting Wi‑Fi power saved only about 7 µA versus deep sleep alone. [#20906465]
The confirmed TuyaMCU mapping is channel 1 = door state with 0 = closed, 1 = open, and channel 3 = battery enum, where 2 ≈ 3 V. [#20906465]
A working TuyaMCU-less prototype used CB3S roles P7 = DoorSnsrWSleep, P8 = Btn, and P14 = WifiLED, with wake on both door change and button press. [#21299423]
Home Assistant MQTT discovery failed for one device even though OBK published discovery JSON, because the device name contained a Polish character that broke MQTT discovery parsing; removing it fixed detection. [#21593286]

How do I flash OpenBeken on the D06 door sensor with BK7231N/CB3S and TuyaMCU when the UART lines are already connected to the TuyaMCU?

You usually flash it over serial after physically isolating the Wi‑Fi module from the TuyaMCU path. 1. Remove the small 8-pin TuyaMCU instead of desoldering BK7231N. 2. Connect to the CB3S serial interface and back up the original firmware. 3. Upload OpenBeken, then restore wiring or continue with a TuyaMCU-less mod. OTA via tuya-cloudcutter did not work on the newer sample discussed, while serial flashing worked immediately once the MCU was lifted. [#20906465]

Why does tuya-cloudcutter fail on newer D06 firmware versions, and how can I tell from the extracted backup whether the firmware is patched against the exploit?

It fails because newer D06 firmware can match the exploit pattern yet still be patched. In the extracted backup, the key line was: the binary matched BK7231N SDK 2.3.1 exploit patterns, but the tool still reported it was "patched and no longer vulnerable". That is the decisive indicator. The sample backup also showed app storage keys such as gw_bi, gw_di, and baud_cfg, but user_param_key was not found. [#20906465]

What is the tmSensor driver in OpenBeken, and why does a battery-powered TuyaMCU sensor still need startDriver tmSensor even though its code was merged into the TuyaMCU driver?

You still need startDriver tmSensor because OpenBeken keeps that startup hook for battery sensors, even after moving the logic into the TuyaMCU code path. "tmSensor" is a legacy OpenBeken driver entry that enables battery-powered TuyaMCU sensor handling, preserving old startup behavior even though the functional code now lives inside the merged TuyaMCU driver. A maintainer stated that this requirement remains for compatibility, and the sensor should work once both drivers are started. [#20918886]

How are TuyaMCU datapoints mapped on the D06 sensor, and what do channel 1 and channel 3 represent for door state and battery status?

The D06 maps TuyaMCU datapoint 1 to door state and datapoint 3 to battery status. Channel 1 reports 0 = closed and 1 = open. Channel 3 is an enum battery value where 2 corresponds to about 3 V; the meanings of 1 and 0 were not decoded in the thread. A working draft command linked dpID 1 to channel 1 and dpID 3 to channel 3 with linkTuyaMCUOutputToChannel. [#20906465]

What power consumption should I expect from the D06 sensor in normal operation, sleep, and BK7231N deep sleep with the TuyaMCU still installed?

Expect about 75–80 mA during active Wi‑Fi transmission, about 13 µA while the stock TuyaMCU-controlled design sleeps, and about 20 µA when BK7231N uses DeepSleep with TuyaMCU still installed. Those are direct measurements from the D06 board. The important practical takeaway is that deep sleep already gets very close to the stock standby current, so the power-cut architecture does not buy a dramatic reduction. [#20906465]

Why does removing power from the BK7231N save only a small amount of current on this D06 design compared with using deep sleep alone?

It saves little because most standby efficiency is already achieved once BK7231N enters DeepSleep. The measured difference was only 20 µA versus 13 µA, or about 7 µA. That is roughly a 50% increase in standby current, but the absolute gap stays very small. The same test also showed that wake intervals, such as periodic Wi‑Fi checks every 5 minutes, can affect battery life more than that 7 µA difference. [#20923837]

What is DoorSensorWithDeepSleep in OpenBeken, and how is it different from using a plain dInput or dInput_n pin role for a hall sensor?

DoorSensorWithDeepSleep is the better choice when the hall sensor directly wakes a Beken module. "DoorSensorWithDeepSleep" is an OpenBeken GPIO role that reads a door contact and automates sleep and wake behavior, including edge-triggered wake handling, so the device can run without a custom autoexec sleep script. A plain dInput or dInput_n only reads level state. With the deep-sleep role, you may still need to test pull-up mode and one of the three DSEdge options. [#21296021]

How do I convert a TuyaMCU-based D06 or ZY-D02 sensor into a TuyaMCU-less Beken-only deep sleep setup, including which CB3S pins are typically wired to the hall sensor, button, and LED?

You remove the TuyaMCU and rewire the CB3S to the original sensor circuitry. A proven test setup used P7 = dInput or DoorSnsrWSleep, P8 = Btn, and P14 = LED or WifiLED. 1. Desolder the 8-pin TuyaMCU. 2. Bridge the hall sensor, button, and LED pads to free CB3S GPIOs. 3. Assign roles in OpenBeken and test wake behavior with the button first. One working report confirmed deep sleep, button wake, and door wake with no extra DSEdge setting. [#21299423]

D06/ZY-D02 with TuyaMCU versus a Beken-only sensor like the 19JWT-B — which approach is better for battery life, reliability, and control in OpenBeken?

A Beken-only design is better for control, while TuyaMCU-retained hardware is better for lowest standby current. On the D06, TuyaMCU sleep measured 13 µA, versus 20 µA with BK DeepSleep. The trade-off is firmware authority: with TuyaMCU installed, BK7231N cannot control the main loop and only wakes when the MCU allows it. The thread explicitly suggested choosing a 19JWT-B instead when full BK control matters more than a small standby-current advantage. [#20922013]

What is BAT_Relay in OpenBeken, and how does it work together with BAT_ADC, Battery_Setup, and autoexec.bat on a battery-powered CB3S sensor?

BAT_Relay is the OpenBeken role that switches the battery measurement path only when needed. "BAT_Relay" is an OpenBeken battery-control role that momentarily enables a resistor-divider path for ADC measurement, reducing idle drain on battery devices that cannot leave the divider permanently connected. In the shared setup, BAT_ADC was on P23, BAT_Relay controlled a transistor path, and autoexec.bat used Battery_Setup 2000 3300 2.15 2400 4096, Battery_Cycle 4, DSTime 5, and DSEdge 0. [#21353072]

How can I add battery voltage measurement to a TuyaMCU-removed D06/ZY-D02 using P23 ADC, the existing resistor divider, and OpenBeken battery settings?

Use the existing divider, route it to P23 / ADC3, and configure both BAT_ADC and a relay-controlled measurement path. One working idea reused the onboard 1 kΩ and 10 kΩ divider, then wired CB3S pin 2 / P23 to that node. A tested OBK-style configuration used BAT_ADC on P23, a separate BAT_Relay, and Battery_Setup in autoexec.bat to define min, max, divider ratio, critical voltage, and 4096 ADC counts. The thread also corrected an LED wiring mistake: P14 should go to the former MCU pin 6 pad. [#21352505]

Why does Home Assistant MQTT discovery sometimes fail on an OpenBeken door sensor even when MQTT publishes are visible in the logs, and how can device names or special characters break discovery?

Discovery can fail even when OBK publishes valid topics because the device name itself breaks Home Assistant or MQTT parsing. In the reported case, logs showed retained config publishes to homeassistant/binary_sensor/.../config, but Home Assistant still ignored the device. The root cause was a Polish character in the device name. After removing that special character from the garage name, discovery worked. If logs show discovery JSON but HA sees nothing, sanitize the name first. [#21593286]

What is the hall sensor used in the D06 board, such as P558K or 2063P, and how does it signal the TuyaMCU or BK7231N when the magnet opens or closes?

The D06 family uses a hall-effect sensor, reported as P558K on one board and 2063P on a near-identical ZY-D02 variant. It senses the nearby magnet and changes its digital output, which the TuyaMCU reads to decide when to wake CB3S and report state. In the stock design, the hall sensor does not talk directly to BK7231N. In a TuyaMCU-less conversion, that same signal can instead feed a CB3S door input role. [#21350150]

How can I replace the original hall sensor input with a simple NO switch or button while keeping the stock firmware or OpenBeken behavior intact?

You can replace the hall output with a simple contact that pulls the MCU input high or low through a resistor. One working stock-firmware test cut the hall line, tied the MCU input to BAT+ through 10 kΩ, and connected a NO pushbutton from that input to BAT-. Pressing the button produced Door Sensor Close; releasing it produced Door Sensor Open. For OpenBeken, a maintainer added that DoorSensorWithDeepSleep already includes an internal pull-up, so a contact to ground should be enough. [#21474825]

Why does a flashed Flood Sensor D06 with OpenBeken show almost no TuyaMCU responses, restart when the sensor input changes, or ignore query-state commands, and what baud rate or driver setup should be checked first?

Check the driver pair and UART speed first. Battery TuyaMCU sensors need both startDriver TuyaMCU and startDriver tmSensor, and they may not answer manual query-state commands at all. The first settings to verify are 9600 and 115200 baud, because both were identified as common. If the flood input change restarts CB3S, the MCU may be trying to wake a module that is normally power-cycled rather than permanently powered. A maintainer also pointed to a newer, more stable tmSensor implementation. [#21708842]

Generated by the language model.