logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

CMY 9450 52

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.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #31 21354464
    spin55
    Level 17  
    If you try to control Q1 from P26 it will never work, because if you set P26 to Low Q1 will interrupt GND and will never wake up until you remove and reinsert the batteries. Please note that the firmware is now on this CB3S module and needs to be permanently powered. That is why the PinDeepSleep command is used, which is already integrated into the autoexec drivers. It is this command that lowers consumption to the minimum in Sleep state.

    To be able to control GND with Q1 you could do it whit Gate is connected to the output of U3 (Hall effect transistor). This way you could send the alert via MQTT to Home Assistant, but when you close the door again you could not send the information because Q1 would cut off GND.

    And if you open the door and close it again quickly you wouldn't even have time to send the notification to HA.

    Electronic schematic showing connections between CB3S module, BK7231N chip, MOSFET transistor, and resistor.
  • ADVERTISEMENT
  • #32 21354680
    daherbst85
    Level 4  
    spin55 wrote:
    If you try to control Q1 from P26 it will never work, because if you set P26 to Low Q1 will interrupt GND and will never wake up until you remove and reinsert the batteries.


    Right, that was the idea, a suicide switch ;-)
    Once the battery is critically low the door sensor should commit suicide until the batteries are exchanged. Underpowered electronics tend to do weird things and should be cut from power permanently. Of course this requires that P26 would be high during deep sleep (not sure whether that's possible or how it behaves in deep sleep - that might be the crux, if it stays high during deep sleep Q1 would maintain the GND connection).

    Anyhow, you raised some valid points and I'll give it a shot.
  • #33 21357822
    ghanatracking
    Level 2  
    Hi,
    I'm relativly new to openbeken, so might be my question is answered somewhere.
    I have this sensor (ok, the water sensor version), flashed to openbeken. Set it up to connect to my mqtt & Homeassistant. It's working so far, but I don't get any sensors, so I don't get the information about open / close.
    Screenshot of an interface showing device information for BK7231N from Beken Corporation with firmware 1.17.739 and an MQTT icon.

    I have another door sensor, and another water sensor, where it's working as expected.
  • ADVERTISEMENT
  • #34 21358109
    daherbst85
    Level 4  
    Have you configured mqtt in your HA configuration.yaml?

    This is what I use for the window/door sensor:
    Code: text Expand Select all Copy to clipboard
    
mqtt: 
  - binary_sensor:
    # Window and Door Sensors using OpenBK
    - unique_id: "BK7231N_01_binary_sensor_1"
      name: "BK7231N_01_windoor"
      state_topic: "BKwindoors/BK7231N_01/1/get"
      qos: 1
      icon: "mdi:door"
      payload_on: "1"
      payload_off: "0"
      device_class: door

    I assume that in your case HA runs a regular mqtt broker (I am running a broker on a separate server, outside of HA).
    Of course you need to configure a user, password, and permissions for HA to access the topic.
    After adding this to your configuration.yaml, you have to reload the yaml. Then you should be able to find the sensor (binary_sensor.bk7231n_01_windoor).

    In the OpenBK web interface, you want to set the retain flag.
  • #35 21361558
    plekke
    Level 4  
    Hand-drawn electronic circuit diagram with a module on a piece of paper.


    my 2 cent , i made this schematic , and the i dicovered this topic ( incl schematics already made )
    nevertheless , maye i can be added and also be usefull
  • #36 21365781
    ghanatracking
    Level 2  
    >>21358109
    I have homeassistant with embedded mosquitto.
    View of water sensor temperature details in Home Assistant.

    I have never used config.yaml to edit devices. Do you have therefore an idea how to edit the already existing device? Would "watersensor2" be the unique id, when this is one othe the topics "sensor.watersensor2_temperature"?
  • #37 21370467
    meillagimeil
    Level 5  
    What do you think about replacing tuya mcu with attiny85? The vcc/gnd are not in the same place, but retracing 2-3 connection is nothing compared to all the wires needed for no tuya solution.
  • ADVERTISEMENT
  • #38 21379680
    ssllaawweekk
    Level 20  
    I would like to replace the hall sensor in the sensor with the original software with a simple NO button/switch. Is there a ready solution for this? What signals does the hall sensor communicate with the MCU? I read that the sensor output is of the push-pull type.
  • #39 21392216
    ssllaawweekk
    Level 20  
    ssllaawweekk wrote:
    I would like to replace the hall sensor in the sensor with the original software with a simple NO button/switch. Is there a ready solution for this? What signals does the hall sensor communicate with the MCU? I read that the sensor output is of the push-pull type.

    I have broken the connection between the Hall sensor and the MCU. By now connecting the sensor input on the MCU to +3V or 0V via a 5kohm resistor I get the ability to set open/closed states.
    If this is not the best solution - please comment.
  • #40 21442587
    meillagimeil
    Level 5  
    So, is there a final working solution? That is the wiring solution? I'm confused.
  • #41 21453622
    ssllaawweekk
    Level 20  
    I've been lacking the time to finish this project lately but I'll try this week.
  • #42 21474825
    ssllaawweekk
    Level 20  
    I currently have the circuit I needed assembled. I have an external NO button with which I force the state change from open to closed. In my circuit, the input for the hall sensor on the MCU is connected to the BAT+ pin via a 10kohm resistor. Of course, the signal from the hall sensor is interrupted and does not reach the MCU. A NO mono-stable contact is plugged in between the aforementioned input in the MCU and the BAT- pin. When I press the button I get the message: Door Sensor Close, and when I let go: Door Sensor Open. I am currently testing the battery life with this solution and in the future I still need to find a way to properly mount the contact in the lock because that is the goal.
  • #43 21476701
    p.kaczmarek2
    Moderator Smart Home  
    @ssllaawweekk you've done rather well. From what I gather, the role of the DoorSensorWithDeepSleep pin, has an internal pull up resistor, so all you need is a contact shorting it to ground and then the whole thing should work properly.
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/ioRoles.md
    I didn't go that far into those Tuya sensors based on the Hall sensor, but there the DSEdge setting was still needed: https://www.elektroda.com/rtvforum/find.php?q=DSEdge

    Well, but that's in OBK, as long as you have the original software, it should work from the get go....
    Helpful post? Buy me a coffee.
  • #44 21477804
    ssllaawweekk
    Level 20  
    >>21476701 .
    I use the original software because its functionality is sufficient for me.
    I added a pull-up resistor just in case.
  • #45 21530581
    sta_rob
    Level 1  
    Hi,
    I'm new to this forum and to OpenBeken so please bare with me. I have a ZY-D02 door sensor and installed Openbeken on it. I can connect through WiFi and configure it but it does not work as expected. I followed this thread https://www.elektroda.com/rtvforum/topic3914412.html and created the autoexec.bat with the content below but I have issues:

    - The MCU does not wake the Wifi chip when using the magnet
    - There is no state change for channel 0 when attaching/detaching the magnet

    So I realized that there is a difference between a D06 and a D02 sensor. It seems that to make D02 work the MCU needs to be removed and some wires need to be added. Is this required or does OB also support this board with the MCU installed?

    Thanks, Robert

    autoexec.bat:

    startDriver TuyaMCU
    startDriver tmSensor

    // may be needed, depends on device
    //tuyaMcu_setBaudRate 115200

    // map dpID 1 to channel 1
    linkTuyaMCUOutputToChannel 1 val 1
    setChannelType 1 OpenClosed

    // map dpID 3 to channel 3
    linkTuyaMCUOutputToChannel 3 val 3
    setChannelType 3 Custom
  • #46 21591965
    GAAD
    Level 17  
    Hi.
    I removed the MCU from my sensor and made the connections as described. The sensor works very nice but HA does not detect it like all OBK devices in MQTT.

    On the sensor page this info:
    Door Sensor D06 (BK7231N/CB3S) with TuyaMCU (DeepSleep) .

    Flags enabled:
    Flag 2 - [MQTT] Broadcast self state every N (def: 60) seconds (delay configurable by 'mqtt_broadcastInterval' and 'mqtt_broadcastItemsPerSec' commands)
    Flag 10 - [MQTT] Broadcast self state on MQTT connect
    Flag 27 - [HASS] Invoke HomeAssistant discovery on change to ip address, configuration
    Flag 37 - [WiFi] Quick connect to WiFi on reboot (TODO: check if it works for you and report on github)
    Flag 51 - [WiFi] (RTL/BK) Enhanced fast connect by saving AP data to flash (preferable with Flag 37 & static ip). Quick reset 3 times to connect normally

    As I wrote earlier the sensor connects very fast, goes into deepsleep, when you move the magnet it wakes up the LED blinks once - the page refreshes there is a message that it has connected but you can't see it in the MQTT devices. Am I forgetting something? So far, always after clicking "Start Home Assistant Discovery" the device appeared in HA.
  • #47 21591992
    p.kaczmarek2
    Moderator Smart Home  
    So the HA is not receiving Discovery? Maybe the sensor falls asleep before it has time to send it.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #48 21592390
    GAAD
    Level 17  
    The logs show that it is sending:

    Code: text Expand Select all Copy to clipboard
    
Info:MQTT:Channel has changed! Publishing 1 to channel 1 
Info:MQTT:Publishing val 1 to obk535A5B2C/1/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/1/get
Info:MQTT:Queued topic=obk535A5B2C/1/get, 1 items in queue
Info:MQTT:Publishing val 1 to obk535A5B2C/1/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/1/get
Info:MQTT:Publishing val 2400 to obk535A5B2C/voltage/get retain=0
Info:MQTT:Publishing val 60 to obk535A5B2C/battery/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/voltage/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/battery/get
:MQTT:MQTT_RegisterCallback called for bT bekens_n/ subT bekens_n/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obk535A5B2C/ subT cmnd/obk535A5B2C/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/bekens_n/ subT cmnd/bekens_n/+
Info:MQTT:MQTT_RegisterCallback called for bT obk535A5B2C/ subT obk535A5B2C/+/get
Info:CMD:CMD_StartScript: started @startup at the beginning
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:CMD:Battery Setup : Min 1500.000000 Max 3000.000000 Vref 2400.000000 adcbits 4096.000000 vdivider 1.000000
Info:CMD:Battery Cycle : Measurement will run every 4 seconds
Info:EVENT:CMD_AddEventHandler: added OnHold with cmd DSTime 2400
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_DISCONNECTED - 2
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_DISCONNECTED - 2
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MQTT:mqtt_userName mqtt
mqtt_pass ********
mqtt_clientID obk535A5B2C
mqtt_host 192.168.1.253:1883
Info:MQTT:Queued topic=obk535A5B2C/1/get, 1 items in queue
Info:MAIN:Time 1, idle 196684/s, free 73040, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MAIN:HA discovery is scheduled, but MQTT connection is not present yet
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to obk535A5B2C/+/set
Info:MQTT:mqtt_subscribed to bekens_n/+/set
Info:MQTT:mqtt_subscribed to cmnd/obk535A5B2C/+
Info:MQTT:mqtt_subscribed to cmnd/bekens_n/+
Info:MQTT:mqtt_subscribed to obk535A5B2C/+/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/voltage/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/battery/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/1/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/4/get
Info:MQTT:Publishing val Drzwi_garaż to obk535A5B2C/host retain=0
Info:MQTT:Publishing val 0 to obk535A5B2C/1/get retain=0
Info:DRV:DRV_BATTERY : Measure Battery volt en perc
Info:MQTT:Publishing val 2400 to obk535A5B2C/voltage/get retain=0
Info:MQTT:Publishing val 60 to obk535A5B2C/battery/get retain=0
Info:DRV:DRV_BATTERY : battery voltage : 2400.000000 and percentage 60.000003%
Info:MAIN:Time 2, idle 175933/s, free 72976, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Will do request HA discovery now.
Info:HTTP:HASS counts: 0 rels, 0 pwms, 1 inps, 0 excluded
I
Info:MAIN:Time 3, idle 155163/s, free 57872, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val c0:f8:53:5a:5b:2c to obk535A5B2C/mac retain=0
Info:MQTT:Publishing val (340 bytes) to homeassistant/sensor/Drzwi_garaż_temp/config retain=1
Info:MQTT:Publishing val (337 bytes) to homeassistant/sensor/Drzwi_garaż_rssi/config retain=1
Info:MQTT:Publishing val (339 bytes) to homeassistant/sensor/Drzwi_garaż_uptime/config retain=1
Info:MAIN:Time 4, idle 176475/s, free 59152, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val (266 bytes) to homeassistant/sensor/Drzwi_garaż_build/config retain=1
Info:MQTT:Publishing val (297 bytes) to homeassistant/sensor/Drzwi_garaż_ssid/config retain=1
Info:MQTT:Publishing val (281 bytes) to homeassistant/sensor/Drzwi_garaż_ip/config retain=1
Info:MAIN:Time 5, idle 177865/s, free 50016, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38 

Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to obk535A5B2C/+/set
Info:MQTT:mqtt_subscribed to bekens_n/+/set
Info:MQTT:mqtt_subscribed to cmnd/obk535A5B2C/+
Info:MQTT:mqtt_subscribed to cmnd/bekens_n/+
Info:MQTT:mqtt_subscribed to obk535A5B2C/+/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/voltage/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/battery/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/1/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/4/get
Info:MQTT:Publishing val Drzwi_garaż to obk535A5B2C/host retain=0
Info:MQTT:Publishing val 1 to obk535A5B2C/1/get retain=0
Info:DRV:DRV_BATTERY : Measure Battery volt en perc
Info:MQTT:Publishing val 2400 to obk535A5B2C/voltage/get retain=0
Info:MQTT:Publishing val 60 to obk535A5B2C/battery/get retain=0
Info:DRV:DRV_BATTERY : battery voltage : 2400.000000 and percentage 60.000003%
Info:MAIN:Time 2, idle 177884/s, free 72744, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Will do request HA discovery now.
Info:HTTP:HASS counts: 0 rels, 0 pwms, 1 inps, 0 excluded
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/1/get
Info:MQTT:Queued topic=homeassistant/sensor/Drzwi_garaż_battery_0/config, 1 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/Drzwi_garaż_voltage_0/config, 2 items in queue
Info:MQTT:Queued topic=homeassistant/binary_sensor/Drzwi_garaż_binary_sensor_1/config, 3 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/Drzwi_garaż_temp/config, 4 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/Drzwi_garaż_rssi/config, 5 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/Drzwi_garaż_uptime/config, 6 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/Drzwi_garaż_build/config, 7 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/Drzwi_garaż_ssid/config, 8 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/Drzwi_garaż_ip/config, 9 items in queue
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/voltage/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk535A5B2C/battery/get
Info:MQTT:Publishing val OpenBK7231N 1.18.127 Jun 26 2025 14:00:27 to obk535A5B2C/build retain=0
Info:MQTT:Publishing val (311 bytes) to homeassistant/sensor/Drzwi_garaż_battery_0/config retain=1
Info:MQTT:Publishing val (312 bytes) to homeassistant/sensor/Drzwi_garaż_voltage_0/config retain=1
Info:MQTT:Publishing val (266 bytes) to homeassistant/binary_sensor/Drzwi_garaż_binary_sensor_1/config retain=1
Info:MAIN:Time 3, idle 155986/s, free 57872, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val c0:f8:53:5a:5b:2c to obk535A5B2C/mac retain=0
Info:MQTT:Publishing val (340 bytes) to homeassistant/sensor/Drzwi_garaż_temp/config retain=1
Info:MQTT:Publishing val (337 bytes) to homeassistant/sensor/Drzwi_garaż_rssi/config retain=1
Info:MQTT:Publishing val (339 bytes) to homeassistant/sensor/Drzwi_garaż_uptime/config retain=1
Info:MAIN:Time 4, idle 180085/s, free 57776, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val (266 bytes) to homeassistant/sensor/Drzwi_garaż_build/config retain=1
Info:MQTT:Publishing val (297 bytes) to homeassistant/sensor/Drzwi_garaż_ssid/config retain=1
Info:MQTT:Publishing val (281 bytes) to homeassistant/sensor/Drzwi_garaż_ip/config retain=1
    .

    Maybe it is an HA poblem.
    If you can see it because there are errors and warnings in the log.
    It connects instantly and the sensor works very fast.
  • #49 21592394
    p.kaczmarek2
    Moderator Smart Home  
    And HA can see the JSON as you give a listen in MQTT?
    Code: text Expand Select all Copy to clipboard
    

Info:MQTT:Publishing val (266 bytes) to homeassistant/binary_sensor/Drzwi_garaż_binary_sensor_1/config retain=1
    .
    This indicates that it has sent Discovery data about the sensor.
    Helpful post? Buy me a coffee.
  • #50 21593286
    GAAD
    Level 17  
    I looked in the logs and all is clear I used Polish characters and these are not allowed in mqtt after removing the ¿ from the word garage the sensor was detected.
  • #51 21708833
    chmieleckimikolaj
    Level 4  
    Hello, I flashed successfully my Flood Sensor D06 with OpenBeken v1.18.186. I have access to web interface. I created autoexec.bat with below content:
    Code: text Expand Select all Copy to clipboard
    startDriver TuyaMCU
// set TuyaMCU baud rate
tuyaMcu_setBaudRate 115200
// emulate being connected to cloud
tuyaMCU_defWiFiState 4

    After that I testetd commands:
    Code: text Expand Select all Copy to clipboard
    tuyaMcu_sendQueryState
uartSendHex 55 AA 00 01 00 00 00

    without any response. I see TuyaMCU driver is active, but I cannot see any response in Logs.
    I have also tested with commmented baud rate (default value) without any result.

    MCU works well, because I reverted backup original software and I was able to connect this sensor to Tuya App.

    Maybe the cause of that is I flashed OpenBaken without desoldering MCU? But OpenBeken works well. Do you have any ideas why is that?
  • #52 21708842
    p.kaczmarek2
    Moderator Smart Home  
    You are configuring your device incorrectly. The battery powered devices require tmSensor driver and as far as I know they won't respond to state queries. Please check out tmSensor samples.
    https://www.elektroda.com/rtvforum/find.php?q=tmSensor

    Futhermore, it's possible that you have selected incorrect baud value. There are at least two common options - 115200 and 9600. You'd need to try capturing Tuya packets to be sure.

    By the way, we have a contributor with a better (more stable) tmSensor driver here, if you want, you may check this out as well:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1795
    Helpful post? Buy me a coffee.
  • #53 21711497
    chmieleckimikolaj
    Level 4  
    Thank for your response @p.kaczmarek2
    I have tested below autoexec.bat
    Code: text Expand Select all Copy to clipboard
    startDriver TuyaMCU
startDriver tmSensor
linkTuyaMCUOutputToChannel 1 val 1
setChannelType 1 OpenClosed
linkTuyaMCUOutputToChannel 3 val 3
setChannelType 3 Custom

    I assume that channel 1 is for flood input and channel 3 is for battery charging state. I can see TuyaMCU logs only on OBK startup:
    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:Received: 55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23 
Info:TuyaMCU:ProcessIncoming[v=0]: cmd 8 (QueryState) len 19
Info:TuyaMCU:V0_ParseRealTimeWithRecordStorage: processing id 3, dataType 4-enum and 1 data bytes
Info:TuyaMCU:V0_ParseRealTimeWithRecordStorage: byte 2
    and that's it. No more logs from TuyaMCU. As you said, there is probably no support for query state CMD.
    I have also observed that after I short the sensor's digital input, the CB3S module restarts. Probably TuyaMCU would like to wake up CB3S module, but it is currently running, becase I connected 3.3V directly to CB3S.
    Do we have any control over TuyaMCU chips? Can we change its behavior?

    Dodano po 3 [minuty]:

    I wouldn't like to desolder TuyaMCU chip, only reprogram it if it is possible. I bought 10 flood sensors of this model and I want to integrate them with HA.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion focuses on the Door Sensor D06 featuring the BK7231N WiFi chipset and a TuyaMCU (CB3S) module managing power and sensor inputs via serial interface. The TuyaMCU controls power to the WiFi module and handles the magnetic field sensor, with firmware updates requiring desoldering. Users explore the integration of tmSensor code with the TuyaMCU driver and the limitations of power control, noting that removing the TuyaMCU allows full BK7231N control and potentially improved deep sleep management. Several contributors share methods to bypass or remove the TuyaMCU, including soldering direct connections from the BK7231N to sensor components, reassigning GPIO pins for door sensor, button, LED, and battery ADC functions, and configuring OpenBeken firmware accordingly. The hall-effect sensor (P558K or 2063P) is identified as the magnetic sensor, with discussions on replacing it with a simple NO switch. Power management involves a transistor (Q1) controlled by the TuyaMCU or firmware to cut power to the WiFi module for deep sleep, with detailed schematics and wiring modifications to enable battery voltage measurement via ADC and to maintain proper ground connections. MQTT integration with Home Assistant is addressed, including configuration of MQTT topics, payloads, and discovery, with troubleshooting for sensor state reporting and battery voltage. The thread also covers challenges in wake-up reliability, firmware roles like DoorSensorWithDeepSleep, and the potential for a tutorial on converting TuyaMCU-based sensors to TuyaMCU-less operation with OpenBeken firmware for enhanced control and power efficiency.
Generated by the language model.
Today's popular

FAQ

TL;DR: Deep-sleep current drops to just 13 µA, yet Wi-Fi bursts need 75-80 mA [Elektroda, CMY, post #20906465] “Everything should be okay once you run it” [Elektroda, p.kaczmarek2, post #20918886] OTA fails on new firmware builds.

Why it matters: ultra-low standby keeps AAA batteries alive for months while still giving instant MQTT door alerts.

Quick Facts

• MCU combo: CB3S (BK7231N Wi-Fi SoC) + 8-pin TuyaMCU, UART-linked [Elektroda, CMY, post #20906465] • Sleep currents: 13 µA (TuyaMCU power-cuts Wi-Fi) or 20 µA (BK7231N deep-sleep) [Elektroda, CMY, post #20906465] • Active burst: 75–80 mA during MQTT publish [Elektroda, CMY, post #20906465] • Supported firmware: OpenBeken ≥ 1.18.127; OTA via Cloudcutter only if build ≤ v1.0.10 [Cloudcutter JSON]

What hardware is inside the DS06/D06 door sensor?

The PCB carries a Tuya CB3S module with a BK7231N Wi-Fi SoC and an 8-pin TuyaMCU that controls power, LED and hall sensor over a 9600 baud UART link [Elektroda, CMY, post #20906465]

Can I flash OpenBeken without desoldering the CB3S?

Yes. Lift the TuyaMCU (only 8 pins) to expose TX/RX, then use 3.3 V UART to flash OpenBeken in situ [Elektroda, CMY, post #20906465]

Does Cloudcutter OTA still work?

Only for early firmware (e.g., v1.0.10). Newer images are patched; the exploit returns “no longer vulnerable” [Elektroda, CMY, post #20906465]

How do I map datapoints in OpenBeken?

Place in autoexec.bat:
  1. startDriver TuyaMCU; startDriver tmSensor
  2. linkTuyaMCUOutputToChannel 1 val 1 (door state)
  3. linkTuyaMCUOutputToChannel 3 val 3 (battery enum) [Elektroda, CMY, post #20906465]

Why does Home Assistant discovery sometimes fail?

MQTT topics containing non-ASCII characters (e.g., Polish letters) block discovery. Rename the device to ASCII-only and HA sees it [Elektroda, GAAD, post #21593286]

What battery life can I expect?

At 13 µA standby and ~80 mA 1-second bursts, two AAA cells (1 000 mAh each) last roughly 8–12 months with 50 door events per day [Calc; data from CMY, #20906465].

Is removing the TuyaMCU worth it?

Removing it lets BK7231N control deep-sleep directly, cutting wiring to three jumpers and reaching 20 µA standby. Power savings are modest (≈ 7 µA) but you gain full firmware control [Elektroda, CMY, #20906465; divadiow, #21299423].

3-step how-to: convert to TuyaMCU-less Deep-Sleep

  1. Desolder TuyaMCU with hot-air "solder-sausage" method.
  2. Bridge hall-sensor output to CB3S P7 (DoorSnsrWSleep) and LED to P14.
  3. Wire CB3S GND permanently; connect Q1 gate to P26 for BAT_Relay [Elektroda, divadiow, #21331027; spin55, #21353072].

How do I read battery voltage after the mod?

Use the existing R3/R23 divider (1 kΩ/10 kΩ). Link CB3S P23 as BAT_ADC role and add Battery_Setup 2000 3300 1.1 2400 4096 in autoexec.bat [Elektroda, daherbst85, post #21354059]

Edge case: sensor stops publishing after reboot—why?

If DSTime is set below the Wi-Fi connect time, the module may sleep before MQTT handshake. Increase DSTime (e.g., 2400 ms) [Elektroda, spin55, post #21353072]

Which hall sensor is used and can I replace it?

Board versions show P558K or 2063P omnipolar hall ICs. Output is push-pull. You can replace it with a NO switch tied through 5–10 kΩ pull-up to BAT+; MCU reads open/closed correctly [Elektroda, ssllaawweekk, post #21392216]

What happens if voltage drops below 2.0 V?

Configure BAT_Relay to pull Q1 gate low; this disconnects CB3S ground and forces a safe shutdown, preventing flash corruption [Elektroda, spin55, post #21353072]

Expert tip for debugging UART traffic?

Use uartSendHex 55 AA 00 08 00 to query TuyaMCU state; observe dpId 1 and 3 replies in real time [Elektroda, CMY, post #20906465]
Generated by the language model.
ADVERTISEMENT