[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight

morgan_flint 06 Sep 2023 14:11 254 43893 Cool? (+12)

📢 Listen (AI):

TL;DR

TH08-CBU-ATH20-V2 is a LCD calendar/clock/temperature/humidity unit with a BK7231N CBU module, BL55070 LCD driver, and ATH20 sensor.
U3 appears to be the Tuya MCU, while U8 with a 32.768 kHz crystal likely handles RTC and LCD/backlight control, and Q1 switches Wi‑Fi power.
It runs from 3xAAA cells at 4.5V and was bought for 4.49€ as a Choice offer.
The Tuya app shows a 1 hour update interval, and pairing can fail because the device connects only briefly between updates.

Generated by the language model.

Hello all,

After searching the database, I think this is the first post for this device. It seems to be a newer version of others already described here. I like the display design, also with backlighting, and that it is battery powered (3xAAA - 4.5V, probably easy to convert to LiPo).

Aliexpress's link: https://www.aliexpress.com/item/1005005644804864.html

Aliexpress' ad capture (in case link becomes obsolete):

It's advertised for 11,79€ with free shipping, but I managed to get it for 4,49€ as a "Choice" offer:

External and teardown photos:

As you can see, the PCB silkscreen states "TH08-CBU-ATH20-V2 2023/07/22"

I understand:
- "TH08" is the model so it must be a newer version of TH06, covered here and here. It could be also a close relative of the item described here
- "CBU" refers to the WiFi module, as it corresponds with the module's silkscreen (datasheet)
- "ATH20" is the temperature/humidity sensor (product page and datasheet)

There are also:
- A big IC labelled "BL 55070", which is an LCD driver (product page and datasheet)
- Two 16 pin ICs with the label erased: One of them (U8) has a quartz crystal connected (X1), and three pins are connected to pads labeled "BACK_LIGHT", "LCD_SDA" and "LCD_SCL", so it's clear it controls the display and its backlight, so I think this is a dedicated RTC. Some tracks connect this IC with the previous one (U3), which in turn has pins connected to pads labeled "RX1" and "TX1" (connected to the Wifi Module), "ATH20SDA" (sensor) and "LIGHT_SIGNAL", connected to U8. This one must be the Tuya MCU.

Among the other components, Q1 controls power to the WiFi module, similar to the other products mentioned above. It's an N-Channel Enhancement Mode MOSFET NP2302FVR-J (datasheet).

The full schematic and block diagram are included below and the analysis of traffic in RX1 and TX1 will be posted later (done, see post#33)

Tuya App screenshots:

The update interval for the graphics is very long (1 hour) and, apparently, can't be changed from the app (its an App related issue; the device updates more frequently, as you can see later in this thread). Related to this, the last screenshot shows an error when trying to connect to the device. I understand it's because the device only connects for a brief time between updates, so you should connect to it in that brief moment to get the info (I've tried just after inserting the batteries without success, so it must be the connection doesn't last enough). After powering the module directly to be able to read it with BK7231flasher, I could complete this screen, so it's attached after the one with the error.

Schematic:

Block Diagram:

After drawing this, it seems clear U3 is the main MCU, connected to CBU module via RX1 and TX1, to the key, to the sensor via I2C, to the LED, to a voltage divider from the battery, and to the other U8 with two wires (another I2C or RX-TX?) and another signal to start the backlight. There's also a mysterious pad (PB5) connected to it.

U8, with a 32.768 kHz oscillator, is probably an RTC, controls the LCD via I2C to U1 and also the duration of the backlight, and is programmed/read by U3 via a two-wire interface.

As stated above, Q1 is a mosfet controlling power to the WiFi module, switching on or off the connection to ground.

Finally, U4 is the main voltage regulator (2,8 volts) feeding all components except the backlight, which is fed by U6 (3 volts) that is turned on or off by pin 9 of the RTC.

NOTE: I've updated several times this post to include the information that we have been finding along the thread. Still pending to include the summary of the OBK flashing procedure and its configuration

About Author

morgan_flint wrote 251 posts with rating 60 , helped 4 times. Live in city Sevilla. Been with us since 2018 year.

Comments

Add a comment

p.kaczmarek2 06 Sep 2023 17:51

This indeed looks like a new version of TH06, just as you said. Let me know when you've done the packets capture. I wonder how much of the protocol/dpIDs has changed. [Read more]

auntlydia 06 Sep 2023 23:42

Hi, I just happened to unpack, disassemble and flash the same device today! I was about to create a post for it, but then you have been already doing this job, thank you! Maybe we can work together to... [Read more]

p.kaczmarek2 07 Sep 2023 00:05

OpenBeken sends time only when it's requested: https://obrazki.elektroda.pl/9594592300_1694037873_thumb.jpg I can't see : TuyaMCU_ProcessIncoming: received TUYA_CMD_SET_TIME, so sending back... [Read more]

auntlydia 07 Sep 2023 00:14

Yes, indeed, it would be good to find out how time is transferred from firmware to the module... is it requested? Or pushed through without request? How can we find out, is there anything I can contribute... [Read more]

p.kaczmarek2 07 Sep 2023 08:10

It's just accident. Those are not related. It seems that 0x10 (decimal 16) is ObtainDPCache: https://obrazki.elektroda.pl/6885502900_1694066322_thumb.jpg Here are the docs: https://developer.tuya.com/en/docs/iot/tuyacloudlowpoweruniversalserialaccessprotocol?id=K95afs9h4tjjh Interestingly... [Read more]

auntlydia 07 Sep 2023 09:20

Sweet! Thanks for your efforts! I'll test the updated version as soon as its possible and post results, let's see if there is a response. [Read more]

morgan_flint 07 Sep 2023 10:02

Hello again, I've just updated the first post with some corrections and more information (schematic), and I see you've been making making progress!! Time to read them in detail and see if I can add... [Read more]

p.kaczmarek2 07 Sep 2023 10:40

The display is controlled via MCU, that's why it's hard to just remove MCU and do everything in OpenBeken, although IMHO it would be the preferred way. TuyaMCU complicates lots of things. [Read more]

auntlydia 07 Sep 2023 13:03

Good news! It works with the new version! Good job, thank you so much! Look at the beautifully working sensor now: https://obrazki.elektroda.pl/5404196700_1694084370_thumb.jpg And here we... [Read more]

p.kaczmarek2 07 Sep 2023 13:31

Whoa, I didn't expect it to work at the first try! I haven't even compiled that code before pushing it. Well, if everything really works as expected, then there is very little point to doing data capture.... [Read more]

morgan_flint 07 Sep 2023 13:39

Congratulations!! I'll also give it a try. As you haven't changed anything in this sense, I imagine the report time is still one hour, which I find too long. In the Tuya App there's no option to reduce... [Read more]

p.kaczmarek2 07 Sep 2023 13:47

Polling time setting may be done via dpCache (ObtainDPCache), but you need to know the corresponding dpID. See this topic for example usage: https://www.elektroda.com/rtvforum/topic3975583.html If... [Read more]

morgan_flint 07 Sep 2023 13:49

Hello, p.kaczmarek2. I posted it here following the instructions here . Is it correct? Should I also post something (e.g, a link to this thread) also in the general Devices Teardown forum? [Read more]

auntlydia 07 Sep 2023 13:50

I checked Home Assistant history and I get an update of sensor data every ~17 minutes as standard, even without change of temperature or humidty. As soon as there is a change in temperature or humidity,... [Read more]

morgan_flint 07 Sep 2023 13:56

Ok, sorry to hear that. Anyway, I'm not sure if "polling time" was the correct term for my question, what I meant is if there was a command to set the period in which the MCU "wakes up" the CBU WiFi module... [Read more]

p.kaczmarek2 07 Sep 2023 14:00

Generic teardowns section is only for non-iot teardowns, and smart home is for IoT topics and teardowns. As I said, check if there is an option to set that wake up period in Tuya app, and if it's available,... [Read more]

morgan_flint 07 Sep 2023 14:01

Ok, thanks!, I'll try that and report back. I think, apart from the original firmware's low reporting frequency, this version of the device has one of the best designs and, if the battery life is long... [Read more]

auntlydia 07 Sep 2023 14:06

haha, I have played with thought about Lipo-mod as well! And we could squeeze in a USB-charge module, but we would need to cut the battery plastic housing to make some space. Else I totally agree, I think... [Read more]

morgan_flint 07 Sep 2023 14:14

I already checked it, as you can see in the screenshots at the first post, it seems that option is not available, unfortunately. Totally agree... such an effort is not worth it, and probably this... [Read more]

FAQ

TL;DR: For TH08/TH08B owners who want OpenBeken without killing battery life, the key fix is low-power Tuya handling: battery life improved from 3 days to nearly 2 months, and one contributor confirmed, "the MCU turns off the module as soon as the last packet from the module is received" after the protocol fix. [#20802807]

Why it matters: This FAQ turns a 9-page reverse-engineering thread into a practical flashing, recovery, and configuration reference for BK7231/BK7238-based TH08 sensors.

Option	Power behavior reported in thread	Typical result
Original Tuya firmware	about 6 weeks to nearly 2 months on batteries	Best battery life, cloud-dependent
Early OpenBeken builds	about 3 days on 3xAAA NiMH	Functional, but poor low-power handling
Updated OpenBeken after low-power packet fix	about 2 weeks on alkalines with level still high, or close to original behavior	Best cloud-free compromise

Key insight: The TH08 is not a simple Wi-Fi sensor. A separate TuyaMCU controls sensor reads, LCD updates, and power to the Wi-Fi module, so flashing and battery life both depend on handling that MCU correctly. [#20723152]

Quick Facts

The original TH08 teardown identified 3xAAA power, a 2.8 V main rail, BK7231N-based CBU Wi-Fi module, AHT20-class temperature/humidity sensing, and BL55070 LCD driving on PCB TH08-CBU-ATH20-V2 2023/07/22. [#20723152]
Measured battery-state thresholds on one TH08 were High→Medium at 4.0 V and Medium→Low at 3.1 V; below 3.0 V the 2.8 V regulator output started to drop and the LCD dimmed. [#20804228]
Reported prices were €11.79 advertised and €4.49 paid on AliExpress for the original TH08 listing. [#20723152]
A USB power mod worked with a USB-C socket + step-down regulator set to 4.2 V, and another user later confirmed operation even from 5 V without regulator overheating. [#20791566]
Home Assistant update behavior on original firmware was not hourly-only in practice: users observed about 2-minute updates on change and about 15–17 minutes when values stayed stable. [#20724719]

How do I flash OpenBeken on the TH08 or TH08B battery temperature and humidity sensor without bricking the CBU/BK7231 module?

Flash it as a TuyaMCU device, not as a standalone Wi-Fi sensor. 1. Back up the original firmware first. 2. Isolate the Wi-Fi module from the TuyaMCU or the MCU will fight the UART. 3. Power the CBU directly at 3.3 V for flashing, then restore the cut or lifted connections before normal use. Several users reported flashing failure around 70% unless RX/TX and sometimes CEN were isolated, while backup reads could still succeed. [#20918829]

Which traces or pins need to be cut, lifted, or isolated on the TH08 PCB so the TuyaMCU does not interfere with UART flashing?

On the original TH08, isolate at least the MCU-to-CBU UART path, and often CEN too. The proven methods were: cut the traces between the MCU and the RX1/TX1 pads, or lift the MCU pin tied to CEN so the TuyaMCU cannot reset the CBU during flashing. On later TH08B-style boards, users reported that lifting or isolating pin 8/CEN was often the decisive fix, while some revisions still needed RX/TX isolation as well. [#20929625]

What is TuyaMCU in the TH08 design, and how does it communicate with the CBU Wi-Fi module and the LCD controller?

"TuyaMCU" is a secondary microcontroller that manages the sensor, LCD logic, backlight, and low-power behavior, while the CBU handles Wi-Fi only. In the first TH08 teardown, the MCU talked to the CBU over RX1/TX1, read the sensor over I2C, and coordinated with a separate display/RTC-related IC. That split design is why OpenBeken must emulate the low-power serial protocol instead of driving the whole device directly. [#20723152]

What is a dpID in the Tuya protocol, and how do I find the correct dpIDs for temperature, humidity, battery, and unit conversion on TH08 variants?

"dpID" is a Tuya data-point identifier that names one device value or setting, such as temperature, humidity, or unit selection, and defines its type and range. On the original TH08, thread captures confirmed dpID 1 = temperature, 2 = humidity, 3 = battery state, and 9 = °C/°F unit. Users found them by UART sniffing with TuyaMCUAnalyzer, Tuya IoT developer pages, or firmware/config extraction from backups. [#20729519]

Why does the TH08 show temperature and humidity as zero in OpenBeken even though the LCD still displays valid readings?

That usually means OpenBeken is not receiving valid TuyaMCU packets, even though the standalone MCU still updates the LCD. The most common causes were wrong UART conditions, artificial CBU power during testing, wrong baud assumptions, or a bad RX solder joint. One user fixed zeros immediately after repairing the MCU RX connection and then saw normal Tuya packets such as dpID 1 = 264 and dpID 2 = 11 in the log. [#21002511]

How should autoexec.bat be configured for a TH08 or TH08B so OpenBeken reports temperature, humidity, battery state, and NTP time correctly?

Start NTP, TuyaMCU, and tmSensor, then map channels 1/2/3 to dpIDs 1/2/3 with temperature_div10, Humidity, and ReadOnlyLowMidHigh. A working baseline was: startDriver TuyaMCU, startDriver tmSensor, startDriver NTP, ntp_setServer ..., ntp_timeZoneOfs ..., setChannelType 1 temperature_div10, linkTuyaMCUOutputToChannel 1 val 1, setChannelType 2 Humidity, linkTuyaMCUOutputToChannel 2 val 2, setChannelType 3 ReadOnlyLowMidHigh, linkTuyaMCUOutputToChannel 3 val 3. For some variants, adding tuyaMcu_defWiFiState 4 solved missing reports. [#20893860]

Why does the TH08 keep losing Wi-Fi or become inaccessible after the batteries run down, and what reflashing or configuration steps recover it?

Low battery can leave the CBU in a bad state after repeated failed boots. Multiple users reported a pattern where the LCD still worked, the Wi-Fi icon flashed, but OpenBeken no longer brought up Wi-Fi or AP mode until the CBU was erased and reflashed. One later workaround was rebuilding with flash runtime variables disabled, because the suspected failure mode was repeated brownouts corrupting flash during boot-count or state writes. [#21745721]

What causes the TH08 battery life to drop from weeks on original Tuya firmware to only a few days on some OpenBeken builds?

Early OpenBeken builds did not finish the low-power Tuya handshake the way the MCU expected, so the Wi-Fi module stayed on far too long. Users measured the module staying awake for more than 1 minute on some OpenBeken builds instead of about 10 seconds on stock firmware, and battery life dropped to about 3 days on rechargeable AAA cells. That was traced to missing or wrong low-power protocol packets, not to the sensor itself. [#20746981]

How was the missing low-power Tuya packet handled so the MCU powers off the Wi-Fi module promptly and saves battery on TH08?

The fix was to implement the missing low-power reply that the MCU expected when it queried router signal strength near the end of the wake cycle. Before that fix, OpenBeken answered incorrectly and the MCU kept the CBU alive while waiting. After the new handling landed in later 1.17.30x builds, users confirmed the MCU now cut power to the Wi-Fi module immediately after the last packet, restoring near-stock low-power behavior. [#20796796]

How can I keep the TH08 Wi-Fi module awake long enough to access the OpenBeken web interface, run OTA updates, or change settings?

Use the device’s own wake behavior or temporarily bypass power control. A long button press can keep the module awake long enough for OTA and settings on many TH08 units, and some users also forced the CBU on by wiring the module ground or supply directly past the MCU-controlled switch. On one tested build, a long press held the module awake for about 92 seconds, which was enough for web access and changes. [#21072200]

Which dpID or raw Tuya command changes the TH08 display from °F to °C, and how do I send it from OpenBeken?

On TH08 variants discussed in the thread, dpID 9 is the temperature-unit selector. When normal state writes did not work, users succeeded by sending the raw packet 55AA001000070101090400010026 after a short delay, for example with delay_s 2 followed by uartSendHex ... in autoexec.bat. Another contributor confirmed that packet switched the display from °F to °C reliably on their unit. [#21550660]

What is dpCache in low-power Tuya devices, and when do I need it instead of a normal tuyaMcu_sendState command?

"dpCache" is a low-power Tuya startup cache that stores selected settings in the Wi-Fi module so the MCU can fetch them immediately after wake-up, before normal cloud traffic begins. You need it for battery-powered parameters that the MCU requests with packet 0x10, especially settings it expects at boot. In OpenBeken, that means marking a mapping as dpCache and storing the linked channel persistently, rather than only pushing the value with a normal runtime tuyaMcu_sendState. [#21385904]

How do I troubleshoot NTP time sync problems on the TH08 when the display stays at 1970 or 2070 and the log shows NTP receive errors?

First fix the NTP server and time zone, because the usual cause was a bad or unreachable server address. One user used a LAN IP as NTP and kept getting NTP_CheckForReceive: Error while receiving server's msg; switching to a valid reachable server resolved the wrong 1970/2070 display time. Also set the correct offset manually, because OpenBeken in this thread did not yet auto-handle DST, so Portugal needed 0 or 1, while Spain used 1 or 2 depending on season. [#21074347]

For battery-powered room sensors like the TH08, how does Zigbee compare with Wi-Fi in terms of power consumption and long-term usability?

Zigbee is markedly better for battery life in this use case. The thread’s direct comparison was practical rather than theoretical: users saw original Wi-Fi TH08 behavior lasting 6 weeks to nearly 2 months, but poorly tuned OpenBeken Wi-Fi builds could drop to 3 days. One contributor explicitly noted that Zigbee battery devices are much more efficient because transmit power cost is far lower than conventional Wi-Fi. [#20743433]

What are the battery level thresholds on the TH08, and how safe is it to power the device from USB, LiPo, or rechargeable AAA cells instead of the original 3xAAA setup?

Measured thresholds on one TH08 were 4.0 V for High→Medium and 3.1 V for Medium→Low, with the low-battery icon appearing below 3.1 V. The same user reported stable operation from 5 V USB, while another used a 4.2 V USB-C step-down mod successfully. Rechargeable 1.2 V AAA NiMH cells worked, but early OpenBeken power handling could drain them in about 3 days; after low-power fixes, battery life improved substantially. [#20804228]

Generated by the language model.