logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

CMY 9942 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  
    Posts: 209
    Help: 17
    Rate: 42
    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  
    Posts: 8
    Rate: 3
    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.
  • ADVERTISEMENT
  • #33 21357822
    ghanatracking
    Level 2  
    Posts: 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.
  • #34 21358109
    daherbst85
    Level 4  
    Posts: 8
    Rate: 3
    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.
  • ADVERTISEMENT
  • #35 21361558
    plekke
    Level 4  
    Posts: 7
    Help: 1
    Rate: 1
    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  
    Posts: 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  
    Posts: 3
    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.
  • #38 21379680
    ssllaawweekk
    Level 20  
    Posts: 393
    Help: 30
    Rate: 87
    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  
    Posts: 393
    Help: 30
    Rate: 87
    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  
    Posts: 3
    So, is there a final working solution? That is the wiring solution? I'm confused.
  • #41 21453622
    ssllaawweekk
    Level 20  
    Posts: 393
    Help: 30
    Rate: 87
    I've been lacking the time to finish this project lately but I'll try this week.
  • #42 21474825
    ssllaawweekk
    Level 20  
    Posts: 393
    Help: 30
    Rate: 87
    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.
  • ADVERTISEMENT
  • #43 21476701
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    @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  
    Posts: 393
    Help: 30
    Rate: 87
    >>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  
    Posts: 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  
    Posts: 289
    Help: 3
    Rate: 19
    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  
    Posts: 14580
    Help: 654
    Rate: 12604
    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.
  • #48 21592390
    GAAD
    Level 17  
    Posts: 289
    Help: 3
    Rate: 19
    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  
    Posts: 14580
    Help: 654
    Rate: 12604
    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  
    Posts: 289
    Help: 3
    Rate: 19
    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 5  
    Posts: 9
    Rate: 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  
    Posts: 14580
    Help: 654
    Rate: 12604
    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 5  
    Posts: 9
    Rate: 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: 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.
ADVERTISEMENT