logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[BK7231N CBU] Tuya WiFi Temperature and Humidity Sensor (Blue PCB, no TuyaMCU)

dmcbeing 7593 16

TL;DR

  • The BK7231N CBU Tuya WiFi Temperature and Humidity Sensor with a blue PCB and no TuyaMCU was identified for OpenBeken/ESPHome support.
  • The board talks directly to the CHT8305 temperature-and-humidity sensor over I2C instead of using a TuyaMCU.
  • Battery operation depends on deep sleep, because the sensor lasts only a few days on batteries without it, and the ESPHome test used a bk72xx cbu setup.
  • ESPHome flashing worked, but I2C and deep-sleep support were still incomplete.
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • I recently bought a few of 'Tuya WiFi Temperature and Humidity Sensor'.

    I looked for an existing thread for this exact device but only found a few users posting pictures of this board.

    Here is a picture of the PCB: PCB board of Tuya WiFi sensor with highlighted components and connections.

    And here is the firmware from an unused device:
    tuya_r..zip (1002.72 kB)You must be logged in to download this attachment.
    Tuya JSON:
    Code: JSON
    Log in, to see the code

    It does not have a TuyaMCU and is using I2C to communicate with the Temp+Humidity sensor CHT8305.

    This device requires deep sleep to run on batteries longer than few days.
    Please see related topics for details:
    https://www.elektroda.com/rtvforum/topic4025593.html
    https://www.elektroda.com/rtvforum/topic3945688.html
    https://www.elektroda.com/rtvforum/find.php?q=CHT8305

    I have flashed esphome and aside from I2C, and deep-sleep, everything else works.
    Code: text Expand Select all Copy to clipboard
    
esphome:
  name: upk2esphome-bk7231n

bk72xx:
  board: cbu

logger:
  baud_rate: 0

# tuya:

web_server:

captive_portal:

mdns:

[inContentAd]

external_components:
  - source: /soft_i2c

#api:
#  password: ""
#  reboot_timeout: 0s

ota:
  password: ""

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  use_address: 192.168.1.32
  fast_connect: true
  ap:

mqtt:
  broker: mqtt.hlab.host

button:
  - platform: restart
    name: Restart

debug:
  update_interval: 30s

text_sensor:
  - platform: debug
    reset_reason:
      name: Reset Reason
  - platform: libretiny
    version:
      name: LibreTiny Version
sensor:
  - platform: uptime
    name: Uptime
    update_interval: 15s
    id: uptime_sensor
  - platform: adc
    pin: P23
    name: "Battery Level"
    update_interval: 15s
    on_value:
      then:
        - mqtt.publish_json:
            topic: temp_sensor
            payload: |-
              root["batt"] = x;
              root["uptime"] = id(uptime_sensor).state;
              root["alert"] = id(alert).state;

uart:
  rx_pin: RX1
  tx_pin: TX1
  baud_rate: 115200

light:
  - platform: binary
    name: "Status"
    output: status_output

output:
  - id: status_output
    platform: gpio
    pin: P16

binary_sensor:
  - platform: gpio
    pin: 
      number: P14
      inverted: true
    name: "Button"
  - platform: gpio
    id: alert
    pin: 
      number: P7
      inverted: true
    name: "Alert"


    I hope this information is sufficient to 'port'/support openbeken for this device.

    Let me know if i can help any other way.

    Cool? Ranking DIY
    About Author
    dmcbeing
    Level 3  
    Offline 
    dmcbeing wrote 5 posts with rating 4. Been with us since 2024 year.
  • ADVERTISEMENT
  • #2 20906573
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14573
    Help: 654
    Rate: 12595
    I will edit your first post to add more information, but first of all, your current config is incorrect.
    You can't just:
    Quote:

    I flashed and aside from I2C, and deep-sleep, everything else works.

    This device must have deep sleep, otherwise it will drain batteries really, really fast. I can help you step by step with configuration, flash OBK to get it running.
    Helpful post? Buy me a coffee.
  • #3 20907778
    johnypean
    Level 5  
    Posts: 4

    I have it working quite well. I have gathered information from multiple threads about these sensors here. Even the battery is working and showing up in HASS.

    Code: JSON
    Log in, to see the code


    autoexec.bat:

    Code: text Expand Select all Copy to clipboard
    // Initial led blink
SetChannel 1  1
// hold button to get into safe mode
// addEventHandler OnHold 20 SafeMode
PowerSave
mqtt_broadcastInterval 1
mqtt_broadcastItemsPerSec 5
Battery_Setup 2000 3000 1.87 2400 4096
Battery_Measure
startDriver CHT8305
// HADiscovery on every boot doesn't seem necessary
// scheduleHADiscovery
SetChannel 1  0
waitFor WiFiState 4
// go to deep sleep if mqtt can't connect
addRepeatingEventID 30 -1 1337 DeepSleep 120
waitFor MQTTState 1
cancelRepeatingEvent 1337
publishChannels
// Data sent led blink
SetChannel 1  1
delay_ms 100
SetChannel 1  0
// additional delay to get a chance to manually connect to device, everything else is already done
delay_s 10
// Deep sleep led blink
SetChannel 1  1
delay_ms 100
SetChannel 1  0
// Deep sleep for 30 mins
DeepSleep 1800


    Flags:
    2,10,27,35,37

    Flag 35- Deactivate avty_t solved the problem with HASS showing unavailable on the last collected values during sleep periods.

    Can't get the button to wake up the device. If there was a possibility to use DeepSleep and PinDeepSleep simultaneously, it could be used to wake up and leave the device online. Now, pulling and reinserting the battery gives 10s to edit the autoexec.bat and remove the DeepSleep line. The additional 10s delay probably halves battery life, since init, wifi, and mqtt take around 10s prior.
    I'm thinking if there is a way to read mqtt message and disable DeepSleep if a specific message is received on the next wakeup. Maybe checking the button on boot and disabling DeepSleep would be used to get rid of the 10s delay. Haven't found a way how to do that.
  • #4 20913628
    dmcbeing
    Level 3  
    Posts: 5
    Rate: 4
    Thanks for the replies @p.kaczmarek2 and @johnypean.

    I got stuck at flashing as the GUIFlashTool would not work in Linux ... it would freeze when writing the first page after erasing all flash blocks.
    Installing windows and flashing from there finally worked so I now have two sensors flashed with OpenBK.

    I took the configuration from @johnypean and it sort of works ...

    One of the nodes reports correct numbers (might need small offset/calibration but close enough)
    The other node however reports incorrect values, specifically negative values.

    Code: text Expand Select all Copy to clipboard
    
Good data:
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:21.812500C Humidity:56.141357%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:21.781250C Humidity:55.994873%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:21.875000C Humidity:56.187133%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:21.781250C Humidity:55.762939%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:21.781250C Humidity:55.936889%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:21.687500C Humidity:55.381469%
Bad data:
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:-26.251430C Humidity:53.827342%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:-26.231288C Humidity:31.952011%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:-26.231288C Humidity:31.952011%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:-26.191005C Humidity:88.202865%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:-26.170862C Humidity:66.327537%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:-26.150720C Humidity:69.452583%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:-26.130578C Humidity:31.170747%
Info:SENSOR:DRV_CHT8304_readEnv: Temperature:-26.090295C Humidity:24.920652%


    Funnily enough, the 'good' node also initially reported negative numbers but it then 'fixed' itself although I don't remember doing anything for it ...
  • #5 20913633
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14573
    Help: 654
    Rate: 12595
    Are the device configs the same? Is the device hardware the same for both devices?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #6 20913682
    dmcbeing
    Level 3  
    Posts: 5
    Rate: 4

    Yes, I copied and pasted all settings and autoexec.bat from the first device I flashed that reports correct values.
  • ADVERTISEMENT
  • #7 20918364
    dmcbeing
    Level 3  
    Posts: 5
    Rate: 4
    I played a bit with the sensors in the previous days and redid my configuration, and now all sensors return valid readings.
    I also started playing with the deepsleep as @p.kaczmarek2 recommended.
    However i no longer get Battery voltage from mqtt, even though the webui shows correct values and am not sure why that is.

    My flags are 1092 and this is my autoexec.bat:

    Code: text Expand Select all Copy to clipboard
    
addRepeatingEventID 100 -1 666 DeepSleep 80 // For testing, after testing i will increse DeepSleep to 15mins and decrease the interval to ~40s
mqtt_broadcastItemsPerSec 20
mqtt_broadcastInterval 1
// SetChannel 2 1
PowerSave 1

startDriver CHT8305
Battery_Cycle 1
Battery_Setup 1000 3300 2
delay_s 1

// Schedule after deepsleep - Never
CHT_Cycle 100
Battery_Cycle 100

waitFor MQTTState 1
publishChannels
// SetChannel 2 0


    Before i would get battery values on the 'temp1/voltage/get' topic (temp1 was the node name), but now no messages get posted at that topic ...
  • #8 20922847
    johnypean
    Level 5  
    Posts: 4
    If you activated Flag 36 - "[DRV] Deactivate Autostart of all drivers", you have to add
    startDriver Battery
    to autoexec.bat
    Had the same happen.
  • #9 20925404
    dmcbeing
    Level 3  
    Posts: 5
    Rate: 4
    @johnypean Nope, i don't have that enabled

    I have the following enabled:

    Flag 2 - [MQTT] Broadcast self state every N (def: 60) seconds (delay configurable by 'mqtt_broadcastInterval' and 'mqtt_broadcastItemsPerSec' commands)
    Flag 6 - [BTN] Instant touch reaction instead of waiting for release (aka SetOption 13)
    Flag 10 - [MQTT] Broadcast self state on MQTT connect
    Flag 37 - [WiFi] Quick connect to WiFi on reboot (TODO: check if it works for you and report on github)

    The most relevant i think is flag 10, which i guess should send the battery status once mqtt works, bu in my case it does not seem to do so.

    Fun fact ... i tried to verify the flags value (1092) and did (1<<2)+(1<<6)+(1<<10)+(1<<37) and the result is different (137438954564), but this is simply because the (1<<37) is beyond the 32-bit limit, not sure if it counts as a bug :D
  • #10 20935068
    nacxoffw
    Level 5  
    Posts: 13
    Rate: 1
    Hi!
    Thanks a lot about this post and the information given.

    I have one of this PCB with CBU chip.

    Here a resume about my configuration:
    Screenshot of the OpenBK7231N_HumedadAle user interface showing temperature, humidity, battery level, and other details. Screenshot showing port configuration for a PCB board with CBU chip. Screenshot of script code with configuration information about sleep mode.
    Flags to 1092

    Logs about MQTT:
    Code: text Expand Select all Copy to clipboard
    
Info:MAIN:Time 97, idle 59042/s, free 75040, MQTT 1(1), bWifi 1, secondsWithNoPing 31, socks 2/38 POWERSAVE
Info:MQTT:Publishing val zzzzzz to homeassistant/humedadAle/ssid retain=0
Info:MQTT:Publishing val 2 to homeassistant/humedadAle/sockets retain=0
Info:MQTT:Publishing val -54 to homeassistant/humedadAle/rssi retain=0
Info:MQTT:Publishing val 97 to homeassistant/humedadAle/uptime retain=0
Info:MQTT:Publishing val 75040 to homeassistant/humedadAle/freeheap retain=0
Info:MQTT:Publishing val 192.168.zz.zz to homeassistant/humedadAle/ip retain=0
Info:MQTT:Channel has changed! Publishing 0 to channel 0 
Info:MQTT:Publishing val 0 to homeassistant/humedadAle/0/get retain=0
Info:MQTT:Channel has changed! Publishing 0 to channel 1 
Info:MQTT:Publishing val 0 to homeassistant/humedadAle/1/get retain=0
Info:MQTT:Channel has changed! Publishing 218 to channel 2 
Info:MQTT:Publishing val 218 to homeassistant/humedadAle/2/get retain=0
Info:MQTT:Channel has changed! Publishing 57 to channel 3 
Info:MQTT:Publishing val 57 to homeassistant/humedadAle/3/get retain=0
Info:MQTT:Channel has changed! Publishing 0 to channel 5 
Info:MQTT:Publishing val 0 to homeassistant/humedadAle/5/get retain=0
Info:MQTT:Channel has changed! Publishing 0 to channel 6 
Info:MQTT:Publishing val 0 to homeassistant/humedadAle/6/get retain=0
Info:MAIN:Time 98, idle 78157/s, free 75040, MQTT 1(1), bWifi 1, secondsWithNoPing 32, socks 2/38 POWERSAVE
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/humedadAle/0/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/humedadAle/1/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/humedadAle/2/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/humedadAle/3/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/humedadAle/5/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/humedadAle/6/get


    And a problem like you, the battery is nor publishing... have you solved it @dmcbeing?
    On the other hand... any chance to make phisical button decrease sleep time or stop it to TESTING?
  • ADVERTISEMENT
  • #11 20935801
    nacxoffw
    Level 5  
    Posts: 13
    Rate: 1
    Solved!!

    Setting Channel 4 for gpio of configured battery send MQTT data.
    View of the OpenBK7231N app screen displaying device information and sensor data.

    Data appear as unavailable in sleep time is solved after enable flag option 35 and remove MQTT item and reasync in HomeAssistant.

    Futhermore the physical button question left!!! Please help, think is a good idea to sabe battery.
  • #12 21015579
    crispybeken
    Level 2  
    Posts: 2
    Rate: 1
    I've got one of these devices, too. But I can't find a template in the WebApp. Could you please post your template here?
  • #13 21057398
    mcexmltv
    Level 2  
    Posts: 2
    Newbie here, anyone could be kind and post a how to, or at least post the files.
    Thanks in advance.
  • #14 21057906
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14573
    Help: 654
    Rate: 12595
    Hello @mcexmltv , what kind of information do you need exactly? Are you asking about device configuration, or about flashing?
    For flashing, please see:
    https://github.com/openshwprojects/BK7231GUIFlashTool
    You can also check our generic flashing guides on Youtube:
    https://www.youtube.com/playlist?list=PLzbXEc2ebpH0CZDbczAXT94BuSGrd_GoM
    Helpful post? Buy me a coffee.
  • #15 21066183
    mcexmltv
    Level 2  
    Posts: 2
    Thanks @p.kaczmarek2 ,
    finally had some time to do some research.
    Here is what I am looking for.
    I have ESPHome installed. How do I flash openBK OTA or do I have to use UART?
    If OTA is possible what are the steps?
    Thanks
  • #16 21066328
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14573
    Help: 654
    Rate: 12595
    They have OTA locked against flashing our/Tuya RBL format but someone has found a work around (converted files...):
    https://github.com/BenJamesAndo/OpenBeken_uf2_firmware

    Let me know how it works for you, I will be happy to help you futher.
    Helpful post? Buy me a coffee.
  • #17 21354384
    psyko_chewbacca
    Level 7  
    Posts: 9
    Rate: 2
    >>20904515

    Hi,

    where do I find this "soft_i2c" external component?
    I have an i2c device I'd like to interface to a bk7231n in ESPHome.

    Thanks!
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion centers on the Tuya WiFi Temperature and Humidity Sensor featuring a BK7231N CBU chip and a blue PCB without TuyaMCU. Users share experiences with flashing the device using OpenBK firmware, highlighting challenges such as GUIFlashTool freezing on Linux and successful flashing on Windows. Configuration details include pin assignments for battery relay, button, LED, and CHT8305 sensor lines, along with an autoexec.bat script implementing deep sleep to conserve battery life and MQTT communication for sensor data and battery voltage reporting. Issues with inconsistent sensor readings and missing battery voltage MQTT messages were resolved by adjusting device flags (notably flag 35 for MQTT data during sleep) and ensuring the Battery driver is started if autostart is disabled. Users also discuss MQTT broadcast intervals, power-saving modes, and calibration offsets. Additional inquiries address OTA flashing limitations due to locked firmware and references to alternative flashing methods using converted firmware files. The thread includes requests for device templates and guidance on interfacing I2C devices with BK7231N in ESPHome, with a mention of the "soft_i2c" external component. Overall, the conversation provides practical insights into firmware flashing, configuration, power management, and MQTT integration for this specific Tuya sensor hardware.
Generated by the language model.
Today's popular

FAQ

TL;DR: If you own this BK7231N CBU battery sensor, OpenBeken works with 6 mapped pins and a 30-minute deep-sleep cycle; as one expert put it, "This device must have deep sleep." This FAQ shows the working pin map, MQTT battery fix, and practical flashing paths for the blue-PCB Tuya temperature and humidity sensor without TuyaMCU. [#20906573]

Why it matters: This device can go from useful battery sensor to fast battery drain or wrong readings if deep sleep, pin roles, or battery publishing are configured incorrectly.

Option What worked in the thread Main limitation
ESPHome Basic flashing and most functions worked I2C and deep sleep were the missing parts in the initial report
OpenBeken Working CHT8305, battery, MQTT, and deep sleep Needs correct channels, flags, and autoexec
Linux BK7231GUIFlashTool Reported to freeze after erase on first page write Not reliable for one user
Windows BK7231GUIFlashTool Successfully flashed two sensors Requires separate Windows setup
OTA from ESPHome Possible only through a workaround with converted files Native Tuya OTA was reported locked

Key insight: The breakthrough was not just flashing OpenBeken. The device became practical only after users combined the correct CHT8305 pin map, aggressive deep sleep, and Channel 4 battery publishing.

Quick Facts

  • The working OpenBeken pin map used GPIO 20 = CHT8305 SCK, GPIO 22 = CHT8305 SDA, GPIO 23 = battery ADC, GPIO 16 = LED, GPIO 14 = button, and GPIO 8 = battery relay. [#20907778]
  • A proven low-power script slept the sensor for 1800 seconds after a short online window and used a 10-second extra delay only to allow manual access for edits. [#20907778]
  • One tester used DeepSleep 80 for development, then planned 15-minute sleep with sensor and battery cycles near 40 seconds to reduce battery drain. [#20918364]
  • Wrong readings were dramatic: one unit showed normal values near 21.8°C and 56% RH, while another temporarily reported about -26.25°C with unstable humidity. [#20913628]
  • Battery MQTT publishing returned after assigning Channel 4 to the configured battery GPIO; Home Assistant sleep-state issues improved after enabling Flag 35 and re-syncing entities. [#20935801]

How do I configure OpenBeken for the BK7231N CBU Tuya WiFi temperature and humidity sensor with a CHT8305 and no TuyaMCU?

Use the reported CBU pin map, start the CHT8305 driver, enable MQTT broadcast, and add deep sleep in autoexec.bat. A working map used GPIO 20 for SCK, 22 for SDA, 23 for battery ADC, 16 for LED, 14 for button, and 8 for battery relay. A proven script also enabled PowerSave, started CHT8305, measured battery, published channels after MQTT connect, then entered sleep. [#20907778]

Why is deep sleep mandatory on this battery-powered Tuya WiFi temperature and humidity sensor, and how should it be set up to avoid draining the batteries in a few days?

Deep sleep is mandatory because the sensor otherwise drains batteries very quickly. One expert stated, "This device must have deep sleep, otherwise it will drain batteries really, really fast." A working setup connected to Wi-Fi and MQTT, published values, then slept for 120 to 1800 seconds. For testing, users shortened sleep to 80 seconds, but the stable low-power example used 30 minutes. [#20906573]

What is TuyaMCU, and what changes in flashing or configuration when this BK7231N sensor does not have one?

"TuyaMCU" is a secondary microcontroller that handles device logic and exchanges data with the Wi-Fi chip, usually over UART. This sensor does not have one, so configuration focuses on direct GPIO, ADC, and I2C mapping instead of Tuya serial datapoints. That simplifies hardware control, but you must configure the CHT8305 lines and power management yourself. [#20904515]

What is the CHT8305 sensor, and how is it connected and read over I2C on this blue-PCB Tuya device?

"CHT8305" is a temperature-and-humidity sensor that communicates over I2C, using separate SDA and SCL lines for digital readings. On this board, users mapped it to GPIO 22 as SDA and GPIO 20 as SCK/SCL, then started the CHT8305 driver in OpenBeken. The thread explicitly says the device uses I2C to talk to the CHT8305 and has no TuyaMCU in between. [#20904515]

Which GPIO pins and channels are used on this BK7231N CBU board for the button, LED, battery ADC, and CHT8305 SDA/SCL lines?

The shared working map used GPIO 14 for the button, GPIO 16 for the LED, GPIO 23 for battery ADC, GPIO 20 for CHT8305 clock, and GPIO 22 for CHT8305 data. In the same template, GPIO 8 was set as the battery relay. The reported channels published temperature and humidity on channels 2 and 3, while battery publishing later depended on Channel 4. [#20907778]

Why would one flashed OpenBeken sensor report correct temperature values while another identical-looking unit shows negative readings like -26°C?

Because matching-looking hardware can still behave differently during early configuration, startup, or sensor initialization. One user showed a "good" unit around 21.78°C to 21.88°C and 55.38% to 56.19% RH, while the "bad" unit reported about -26.25°C with wildly changing humidity. After redoing the configuration over several days, all sensors returned valid readings, so the issue was not confirmed as permanent hardware failure. [#20918364]

How do I make battery voltage publish correctly over MQTT in OpenBeken on this sensor when the Web UI shows valid battery data but no voltage topic is sent?

Make sure battery handling is actively configured and exposed to MQTT. One working test used Battery_Cycle 1, Battery_Setup 1000 3300 2, mqtt_broadcastItemsPerSec 20, mqtt_broadcastInterval 1, and publishChannels after waitFor MQTTState 1. If Flag 36 disables driver autostart, add startDriver Battery; otherwise the Web UI can show battery data while MQTT stays silent. [#20922847]

What does setting Channel 4 for the configured battery GPIO do in OpenBeken, and why did it fix missing battery MQTT messages for this device?

Setting Channel 4 bound the battery input to the channel OpenBeken was expected to publish, which restored battery MQTT messages. The user who solved it reported that battery data started appearing only after assigning Channel 4 to the configured battery GPIO. Before that change, MQTT published other channels but skipped the battery value despite valid Web UI readings. [#20935801]

How can I stop Home Assistant from showing this sleeping OpenBeken sensor as unavailable between wake cycles, and what does Flag 35 change?

Enable Flag 35 and re-sync the entity in Home Assistant. A user reported that Flag 35, described as deactivating avty_t, stopped Home Assistant from marking the last collected values as unavailable during sleep periods. Another user confirmed the fix by enabling Flag 35, removing the MQTT item, and adding it back so Home Assistant recreated it cleanly. [#20935801]

What is the best way to use the physical button on this BK7231N sensor to reduce deep sleep time or temporarily keep the device awake for testing?

The thread did not provide a finished button-based wake workflow. Users wanted the button to shorten sleep or keep the device online, but one report says they could not wake it reliably with the button and wished DeepSleep and PinDeepSleep could be combined. The practical workaround was adding about 10 seconds of delay before sleep, but that likely hurts battery life because Wi-Fi and MQTT already take around 10 seconds. [#20907778]

Where can I find a working OpenBeken template for the Tuya WiFi temperature and humidity sensor with BK7231N CBU and CHT8305?

Use the pin and script shared in the thread as the working template. The clearest posted map was GPIO 8 battery relay, 14 button, 16 LED, 20 CHT8305 SCK, 22 CHT8305 SDA, and 23 battery ADC, with flags 2, 10, 27, 35, and 37 plus an autoexec.bat that starts CHT8305, publishes MQTT, and sleeps. No separate WebApp template was posted there. [#20907778]

How do I flash OpenBeken on this sensor if BK7231GUIFlashTool freezes under Linux, and what are the practical alternatives?

If BK7231GUIFlashTool freezes under Linux, switch to Windows or use another supported flashing path. One user reported Linux froze while writing the first page after erase, then successfully flashed two sensors from Windows. Another practical path is standard flashing guidance plus UART if OTA is unsuitable for your firmware state. 1. Try Windows flashing. 2. If needed, use UART. 3. Verify boot and configuration before enabling deep sleep. [#20913628]

What is the difference between ESPHome and OpenBeken for this BK7231N battery sensor, especially for I2C support, MQTT, and deep sleep behavior?

OpenBeken was the thread’s practical solution for battery use, while ESPHome was only partly working in the initial report. The ESPHome user said everything except I2C and deep sleep worked, which makes battery operation unsuitable. OpenBeken examples then showed direct CHT8305 driver startup, MQTT publishing, battery handling, and timed deep sleep from 80 to 1800 seconds. [#20904515]

How can I flash OpenBeken OTA from an ESPHome-installed BK7231N device, and what is the workaround for Tuya OTA locks mentioned in the thread?

You cannot rely on normal Tuya OTA for this case, because the thread says it is locked against OpenBeken or Tuya RBL images. The reported workaround was using converted files from the referenced OpenBeken UF2 project. If that route fails, use direct flashing instead of OTA. The important limit is explicit: native Tuya OTA acceptance was reported blocked for these firmware formats. [#21066328]

Where do I get the soft_i2c external component used in the ESPHome example for BK7231N, and how do I add it to an ESPHome project?

The thread does not provide the soft_i2c files or a download location. It only shows the ESPHome line external_components: - source: /soft_i2c, which implies a local project path rather than a built-in package. So you cannot reproduce that part from the thread alone; you would need the missing component directory from the original project source. [#21354384]
Generated by the language model.
ADVERTISEMENT