For capturing communication I assume you connect only GND and RX so there should be totally no problem with that. Keep in mind that if you power WiFi module artificially for the time of the capture by connecting external 3.3V, the logic of Low Power TuyaMCU communication will break and you will not get meaningful results.
This is because the WiFi module is the one who starts the transaction after it's power on event.
correct, and also no weekday. we have only the date format: day/month/year, and hour format is 24 hours
Quote:
It's a pity U8 has its markings erased (BTW, @auntlydia, Are they also erased in your units?)
Do you mean that all the values are reset when the device uses power? Yes, with every loss of power, values are reset to factory then MCU pulls new data from firmware, the whole process takes only few seconds. If the battery is low, the device keeps losing power upon attempt to connect to wifi, if the voltage is too low to establish a connection.
Quote:
Also, @auntlydia: Which voltage did you use when you flashed OBK?
I used standard 3.3V from my UART USB module. From my experience, the modules with BK7231 chips function also with 3.0V or less, but I wouldn't go higher than 3.3V...
I just connected wires and flashed as usual, very easy, takes only few minutes
It's a pity U8 has its markings erased (BTW, @auntlydia, Are they also erased in your units?)
Do you mean that all the values are reset when the device uses power?
No, what I was asking is if you can read the physical markings on the ICs; as you can see in the following photo, I can't read anything on U3 and U8 while the marks on U1 are perfectly readable:
On the other hand, I've already prepared the setup for sniffing the traffic on TX1 and RX1:
This is what I got:
TH08_RX1_S...iffing.txt (7.07 kB)You must be logged in to download this attachment.TH08_TX1_S...iffing.txt (4.32 kB)You must be logged in to download this attachment.
I've tried to add all the relevant information shown in the display while reading the serial port although, in some of them, I couldn't take notes fast enough, hence the "?" in some information.
Anyway, in this screenshot you can see we have the same FW version:
Let's see if @p.kaczmarek2 can analyze the sniffings and obtain some helpful information... thanks in advance!
If you need some specific captures, please let me know.
BTW: do you know of an easy method to sniff the I2C bus using Arduino, for example? I'll Google for it, but it'd be better if you could give me some advice...
Sorry for the late response! I've been fighting against my scope... I hadn't used it for a long time and wanted to use it for this device, but I found it doesn't work well (if interested, lots of details here and following posts; strange failure, it worked well last time I used it...)
The details of the error are as follows (unfortunately, in Spanish, hope they're still meaningful):
Consulte el final de este mensaje para obtener más detalles sobre cómo invocar a la depuración
Just-In-Time (JIT) en lugar de a este cuadro de diálogo.
************** Texto de la excepción **************
System.ArgumentOutOfRangeException: El índice estaba fuera del intervalo. Debe ser un valor no negativo e inferior al tamaño de la colección.
Nombre del parámetro: index
en System.ThrowHelper.ThrowArgumentOutOfRangeException()
en System.Collections.Generic.List`1.get_Item(Int32 index)
en TuyaMCUAnalyzer.FormTuyaMCUAnalyzer.parseDPData(List`1 p, Int32 ofs)
en TuyaMCUAnalyzer.FormTuyaMCUAnalyzer.displayPacket(List`1 p)
en TuyaMCUAnalyzer.FormTuyaMCUAnalyzer.refresh()
en System.Windows.Forms.Control.OnTextChanged(EventArgs e)
en System.Windows.Forms.TextBoxBase.WmReflectCommand(Message& m)
en System.Windows.Forms.RichTextBox.WmReflectCommand(Message& m)
en System.Windows.Forms.RichTextBox.WndProc(Message& m)
en System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** Ensamblados cargados **************
mscorlib
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9174 (WinRelRS6.050727-9100)
Código base: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
TuyaMCUAnalyzer
Versión del ensamblado: 1.0.0.0
Versión Win32: 1.0.0.0
Código base: file:///D:/Archivos%20de%20programa%20(portable)/TuyaMCUAnalyzer-v0.4/TuyaMCUAnalyzer.exe
----------------------------------------
System.Windows.Forms
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9149 (WinRelRS6.050727-9100)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9171 (WinRelRS6.050727-9100)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9149 (WinRelRS6.050727-9100)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
mscorlib.resources
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9174 (WinRelRS6.050727-9100)
Código base: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
System.Windows.Forms.resources
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9149 (WinRelRS6.050727-9100)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_es_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------
************** Depuración JIT **************
Para habilitar la depuración Just In Time (JIT), el archivo de configuración de esta
aplicación o equipo (machine.config) debe tener el
valor jitDebugging establecido en la sección system.windows.forms.
La aplicación también se debe compilar con la depuración
habilitada
Por ejemplo:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
Cuando esté habilitada la depuración JIT, cualquier excepción no controlada
se enviará al depurador JIT registrado en el equipo
en lugar de controlarlo mediante el cuadro de diálogo.
If I copy-paste the hex codes from the first block of the TXT's of my previous post to TuyaMCU Analycer, the error appears sometimes
The messages on your screenshots seems to be normal.
On your capture, I can see:
- dpID 1 value 320, which is 32.0 temperature
- dpID 2 value 47, which is 47% humidity
- dpID 3 value 2, which is a battery state enumeration
The "invalid date" is normal, it's just that this protocol has few bytes reserved for date and first byte tells us whether date is included or not:
I see you have also attached files as well. I will check them out later today or tomorrow, as I am not on my main machine right now and the fixed TuyaMCU analyzer is on my main machine.
I also tried TuyaMCU Analyzer, but got some errors:
Hi, did you try https://github.com/MkMunich/SniffUART/tree/V1.0 ?
This smart tool allows you to sniff both USB serial ports in parallel, if you have 2 USB serial adapters.
I decoded the first txt file using this tool. Please find it attached.
You could do me a favour and use TuyaMCU Analyzer to record. Please let me know, if this works.
BR MK_Munich
Attachments:
230911 1113 Sniff.txt(21.22 KB)
You must be logged in to download this attachment.
Or... maybe C vs F setting? We could try changing that in the app.
I'm attaching the captures with your app. First two blocks are after power on and waiting 2 min. for the first update. Then, change ºC to F in the app and wait for the next update. Finally, changing again to ºC and wait for update.
BTW, using today's version (V0.5) and the error no longer appears!
Attachments:
C_F_RAW.txt(4.56 KB)
You must be logged in to download this attachment.
C_F_DECODED.txt(7.85 KB)
You must be logged in to download this attachment.
As menu item "Open Ports" is directly opening both serial ports configured in Settings, I would guess, that Port Settings->UART0 and UART1 need to be configured first.
With File->Import you could load the Sniff file, which I had attached above. So you can see, how the decoded messageg look like.
Ok, it's a pity... Once I flash OBK we could probe the commands for that in similar models; maybe it's programmed in Tuya MCU but the app doesn't use it. Is this possible?
mkmunichmk wrote:
morgan_flint wrote:
I hit "Open ports" it closes
As menu item "Open Ports" is directly opening both serial ports configured in Settings, I would guess, that Port Settings->UART0 and UART1 need to be configured first.
I did select the relevant ports in Port Settings->UART0 and UART1, Is there anything else to configure?
The file import works OK
EDIT: I made some new captures with TuyaMCU Explorer and could check:
- After 2 min it doesn't update if there's no change in temperature
- If I heat the sensor, it immediately reports a change (if the 2 min. have passed)
- If I heat again and press the button it reports the change inmediatelly.
I also disconnected the USB port with TuyaMCU Explorer opened and it forced the attached error. I understand it's not relevant, as you're not supposed to do that, but just in case it's interesting for @p.kaczmarek2
Attachments:
TuyaMCU Explorer Error.txt(3.28 KB)
You must be logged in to download this attachment.
Maybe, just maybe, executing a tuyaMcu_sendQueryState command may cause more dpIDs to be sent, but as far as I know, it would only work on non-battery powered models. So I wouldn't bet on that.
Maybe, just maybe, executing a tuyaMcu_sendQueryState command may cause more dpIDs to be sent, but as far as I know, it would only work on non-battery powered models. So I wouldn't bet on that.
Ok, I'll try that when I flash OBK; maybe I'll have to ask you how to do it...
I'll also extract a backup of the original FW, don't remember now if @auntlydia already sent it, but if it's not the case and you're interested I'll do so.
Please, look also at the edit of my previous message I did while you were sending yours, maybe you're interested in the reported "error"
Ok, finally today I soldered the additional wires and changed the connections to be able to use BK7231flasher and make a backup of the original FW.
In the beginning, I only used TX1, RX1 (both from the islands at the PCB) and GND (directly from the module, as module's GND is connected to the main GND via Mosfet Q1), and it seemed to work, even without connecting 3.3V or the battery, presumably taking power from the RX and TX lines (I've read this can happen in other threads here; seems like te developer didn't read this), but the reading halted before completing. So I also soldered a cable to the module's 3.3V pad and fed it from the USB to serial converter. This way, after rebooting the module with the CEN signal, I got a full backup. Curiously, and despite the Q1 thing, the full module got power, the display showed the correct time, etc, just the low battery icon was flashing and sending low battery alarms to Tuya App.
Considering this, I think it's, I think it's important to read/flash the module about 15-20 seconds after powering it, but not much later than that, to allow the TuyaMCU to start and end initial communication with the module, but not give enough time for the next cycle to happen (about 2 minutes after that). This way, the reading/flashing happens while the MCU thinks the module is sleeping.
At the end of the FW backup, BK7231flasher came up with the following screen:
The full content of the message in the left window is in the attached TH08_BackupMessage.txt and the full dialog in BK7231flasher main screen is at TH08_BackupDialog.txt, also attached. Finally, I'm also attaching lastRawDecryptedStrings.bin, generated at the end of the backup. I'm not very sure about how to interpret them, but maybe @p.kaczmarek2 can get some new information from them.
I'm not attaching the full FW as @auntlydia already did it at post #3, but if it's of any help I can also attach it. I masked some info as keys and MAC address for privacy, but if it's relevant I can send it privatelly
Attachments:
lastRawDecryptedStrings_.bin(71.86 KB)
You must be logged in to download this attachment.
TH08_BackupDialog_.txt(14.03 KB)
You must be logged in to download this attachment.
TH08_BackupMessage_.txt(1.58 KB)
You must be logged in to download this attachment.
The only thing more that we can try is the Tuya API approach, but I don't know much about it. I've seen that if you create Tuya developer account (or something like that), you can see some extra list of dpIDs available. Maybe @DeDaMrAz knows more about it.
I had already followed those steps (I think all of them) and I can see the device in HA. But still can't find there anything related to changing the update period.
This is the screenshot of Integrations:
This is the screenshot of "Devices" under the previous one:
The device of interest is the last one, and this is the screenshot of its page:
Curiously, the Google translation of the Chinese part of the name is "Old interface mass-produced".
If I hit "descargar diagnósticos" there (download diagnostics), I get the attached txt (sorry for the strange name, but I conserved the original in case it's meaningful). I can't find anything new for me there...
Does it reveal something to any of you? Is there anywhere else where I can look? (I tried on Tuya Developer's project page, but got lost very soon).
Thank you!
EDIT: I navigated a little more in the Tuya's website and found this:
Apparently, the only instruction that can be sent is related to the ºC - F conversion. Am I right?
Attachments:
tuya-fe3669277e6f6bf8e212c6c71f5c62c5-T & H Sensor-8501c81927835e153d7a9fea2cdaa9d1.json.txt(5.53 KB)
You must be logged in to download this attachment.
Hi @morgan_flint - unfortunately I don't have that device.
I was just giving out the links to help you create a Tuya IoT account and project
Ok, thanks!
I understood you didn't have it, but I thought that maybe you could guide me to where I can find more info about it in the Tuya place.
I've continued looking there and came to this point:
If I try to change to "DP Instruction" it gives a warning:
I changed it anyway, but couldn't see anything else:
And then I went to another device:
And could see that, in this one, there's effectively one more entry in the DP side, something that didn't happen with the sensor... So I'm afraid the sensor doesn't have any hidden feature, unless undocumented features don't appear here... What about sending something not listed from here to see what happens?
Added after 2 [minutes]:
DeDaMrAz wrote:
But if that setting is not available in the phone app it is unlikely that it is avaliable/active on that device.
Hello, DeDaMrAz. I hadn't seen your post as it came up while writing this one. Sorry!
Is it worth trying to send something from similar products as I said before, or could I brick the device?
Ok, most probably, that's the case, but I thought, maybe, as the developers of these products frequently copy each other, some features could exist in the MCU FW, although not used officially, if this FW was an evolution of a previous one...
Do you have the code of the instruction to change the update time in a similar product to give it a try?
EDIT: Tried instructions from here and here, but no luck:
With the standard one, no problem:
Just to check, also tried the non-standard function in the switch Values taken from here:
But gives "offline" and I can't bring it online as it's flashed with OBK now... So no conclusions from this
If you have flashed the device to OBK the Tuya IoT wont be able to send anything to the device.
You have to flash Tuya firmware back on it (from your backup if you have one) and then try. But even then I am not sure what these options will do as I have never tried them.
If you have flashed the device to OBK the Tuya IoT won't be able to send anything to the device
Yes, I expected that, the only objective of the attempt was to see if it gave the message "command or value not support", supposing this was checked by Tuya website instead of the device.
Changing the subject, I made several more measurements with the original FW: sniffing I2C to ATH20 and LCD, and trying to find out the traffic between U3 and U8.
From the I2C sniffing, I found that the sensor is polled quite often, every few seconds. This explains why it reacts to (significative?) changes in temperature, powering the module and sending the information even if the two-minute "standard" period hasn't passed. Also, the traffic in LCD_SDA and LCD_SCL has more or less the same frequency. I used rather crude tools for this (Arduino Nano and ESP32), so I don't know if the logs I obtained are useful, but if someone wants to analyze them, I'll post them here.
I've not been able to obtain any conclusions about the traffic between U3 and U8 (pins 4 and 5 to pins 8 and 10). I've tried supposing it was I2C or RX-TX, both with no results.
Then, after these experiments, I finally flashed OBK in the TH08. In the beginning, like @auntlydia , I tried to do it without interrupting TX1 and RX1 (I had been able to read a backup like this), and, apparently, the flashing went OK, but for some reason, the device didn't work. The next flash attempts failed so I ended up having to interrupt the connections between U3 and M1 (RX1, TX2, and CEN) to be able to flash it again. I think the first time it worked without interrupting as I managed to do it in the 2 min "refractory period" during which the Tuya MCU thinks the module is powered off (by disconnecting its GND from the main GND with Q1). But, once the original FW was lost, I found that the Tuya MCU insisted on talking with the module for a longer period, so it interfered with the flashing, not only at the RX and TX, but also resetting it (CEN is connected to pin 8 of U3). More on this later.
Finally, I managed to get it flashed well, connect it to the AP, and set SSID and password. Then, browsed to its IP, launched the web application, used the same autoexec.bat as @auntlydia at post #3, and got confirmation of connection to the NTP server and correct values for temperature and humidity at the initial screen. (IP/index). In the beginning, the device's display didn't show the date/time, but later it did; I'm not sure if this was after configuring MQTT or if this was just a coincidence.
Channels 1 and 2 are temperature (x10) and humidity, as stated in the autoexec, and Channel 3 (ReadOnly there) seems to be the battery status (1=ok 2=low).
So everything seems to go well, except for one detail: As I said before, once removed the original FW, the "on" cycle of M1 (the time Q1 is switched on) goes from about 10 seconds to more than one minute. I think this must be because the Tuya MCU is waiting for some kind of confirmation from M1 (something like "successfully connected to WiFi or to the cloud") that the original FW gave bot OBK doesn't, so it keeps activating the module for a longer time and/or resets it via CEN to try to get a connection. Then, after about 1 min, it gives up until the next reconnection time (after 2 min, a change on temp or when pressing the button).
Could it be like this? In this case, Is it possible to include that confirmation in OBK (Tuya MCU driver)? It would be good, as the longer the module is on, the higher the battery consumption.
EDIT: I've captured the traffic between the module and the MCU with TuyaMCUAnalyzer, with OBK flashed, and compared it with previous captures with the original FW. I'm attaching two files with the comparisons in RAW and decoded formats. You can see the original FW sent the following message after receiving each of the three messages with the measurements (temperature, humidity, and battery status) from the MCU
That OBK doesn't send. Also, the end of the traffic is different; the original FW sent to the MCU just one packet:
While OBK sends 3 packets instead:
Could this be the cause for the higher WiFi on time with OBK?
There are also two other differences (in orange in the attached documents), but as they are sent from the MCU, I don't think they are relevant. In case they are necessary, I have the captures in .txt and the comparisons in .xlsx formats.
Attachments:
TH08_OBKvsOrigRAW.pdf(398.75 KB)
You must be logged in to download this attachment.
TH08_OBKvsOrig.pdf(420.72 KB)
You must be logged in to download this attachment.
✨ The discussion centers on the teardown, firmware modification, and protocol analysis of the TH08 LCD calendar/clock/temperature/humidity sensor powered by 3xAAA batteries with backlight, based on the BK7231N chip. The device is identified as a newer version of the TH06 model, featuring a TuyaMCU module communicating via a low-power Tuya serial protocol (version 00). Users successfully flashed OpenBK firmware without desoldering, enabling temperature, humidity, and battery monitoring with MQTT integration and NTP time synchronization. Key challenges included understanding the MCU-module communication, especially time synchronization commands and power management to optimize battery life. The MCU sends commands such as ObtainDPCache and ObtainLocalTime, with the WiFi module responding accordingly. Firmware updates improved battery consumption by ensuring the WiFi module powers down promptly after data transmission. The device’s RTC (U8) communicates with the MCU (U3) over a serial or I2C-like interface, with ongoing efforts to decode this traffic. Users experimented with modifying battery power sources, including LiPo and USB power mods with step-down regulators, confirming device operation at voltages between 3.3V and 4.5V. The Tuya app lacks options to adjust sensor reporting intervals, and attempts to change polling times via Tuya protocol commands were unsuccessful, likely due to firmware limitations. Serial sniffing and analysis tools like TuyaMCU Analyzer and SniffUART were used to decode dpIDs, confirming dpID 1 as temperature, dpID 2 as humidity, dpID 3 as battery state, and dpID 9 as Celsius/Fahrenheit setting. Firmware versions and MCU versions were compared, revealing some early versions had display update issues. The community contributed to improving OpenBK firmware to handle specific Tuya commands, including proper responses to WiFi signal strength queries, enhancing power management. MQTT integration with Home Assistant was refined, including battery level display improvements using LowMidHigh channel types. OTA updates and configuration changes require keeping the WiFi module powered, achievable via long button presses or hardware modifications. Attempts to use Tuya-cloudcutter for remote flashing were unsuccessful due to lack of matching profiles. Some users reported issues with sensor readings showing zero after flashing, possibly due to hardware revisions or firmware mismatches. Overall, the device is well-supported by OpenBK firmware with active community development focusing on power optimization, protocol decoding, and integration with home automation platforms. Generated by the language model.
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]
