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

morgan_flint 45735 255

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.

AI summary based on the discussion. May contain errors.

Report a violation of the law

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI voice):

Unmarked U3 and U8 chips confirmed again
#61 20737720 18 Sep 2023 13:07

auntlydia auntlydia

Level 10

Posts: 70

Help: 2

Rate: 14
Helpful post? (+1)

Unmarked U3 and U8 chips confirmed again
Post #61 20737720 18 Sep 2023 13:07

Hi, just quick update @morgan_flint , I have checked another of my devices of the same model, and can confirm that also here, the MCU chips U3 and U8 have no markings. Also, the battery discharge happens faster than expected, however I haven't tried with 3 same-level fully charged batteries. At some point I will put 3x AAA fully charged rechargeable batteries with 1.2V, and try how long it lasts under daily normal conditions, and probably will test with fresh 1.5V non-rechargeable batteries too. In case I do an USB direct power mod, I'll post here too.
ADVERTISEMENT
Request to inspect U3-U8 communication and shutdown message
#62 20738650 19 Sep 2023 10:01

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

Request to inspect U3-U8 communication and shutdown message
Post #62 20738650 19 Sep 2023 10:01

Thanks for the information, it's a pity we can't identify those chips, specifically U8 (I'm intrigued about it). I finally could repair my scope yesterday, so I'll take a new look at the communication between U3 and U8.

Regarding battery discharging, let's see if @p.kaczmarek2 can take a look at the information in my previous post to see if the "closing message" that the WiFi module is sending to the MCU is adequate.

Tuya v00 polling command may differ from v03

#63 20739295 19 Sep 2023 18:15

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42

Tuya v00 polling command may differ from v03

Post #63 20739295 19 Sep 2023 18:15

morgan_flint wrote:
Is there any command in the Tuya protocol to change the polling time? If this is the case, we could try to see if it's implemented in the MCU's firmware

This link to the Tuya protocol is for version 03 (devices that connect to the electrical grid), but in this case version 00 must be taken as a reference (Wifi for Low Power) https://developer.tuya.com/en/docs/iot/tuyacl...niversalserialaccessprotocol?id=K95afs9h4tjjh

If you take a look at the two protocols you will see that they are different and, taking into account that p.kaczmarek2 has based its firmware on protocol 03, although it has adapted it when new battery-powered devices have emerged, it is not enough because some commands work differently in version 00. A Flag would be necessary for the firmware to know if it is a device with a battery or not, and based on that apply the correct command.

From the documentation it seems that command 09 can help you know if this device has the necessary DP implemented.

Send module command
Note:

“Send command” is an asynchronous processing protocol. When the MCU receives the control packet, it responds to the module about the reception and controls the device according to the command. The MCU status response is shown in the status reporting of the MCU.

For example, the module sends the following command:

Field	          Length (byte)	Description
Header	                2	        0x55aa
Version	                1	        0x00
Command word	        1	        0x09
Data length	        2	It depends on the type and number of the “command data unit”
Data	                N	See the “Status data unit” section
Checksum	        1	Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder

The module sends the control command: (The system switch corresponds to DP 3, uses Boolean data type, and the value of 1 indicates power-on)

55 aa 00 09 00 05 03 01 00 01 01 13

Response from the MCU:

Field	           Length (byte)	Description
Header	                2	          0x55aa
Version	                1	          0x00
Command word	        1	          0x09
Data length	        2	          0x0000
Data	                0	          None
Checksum	        1	Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder

ACK response form the MCU:

55 aa 03 09 00 00 0b

Unless there is an error, the command to send would be: 55aa00090008110200040000000524 for a reporting interval of 5 minutes.

And TuyaMCU should answer with: 55aa030900000b.

If the MCU does not respond, it is not implemented.

This can be tested with a USB adapter connected to the Tx and Rx lines of the WiFi module and monitored with Realterm if the module is already flashed with OpenBK. Do the test without the batteries.

Grettings

Wi-Fi module retries wrong 0B response three times
#64 20743320 22 Sep 2023 18:06

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (+1)

Wi-Fi module retries wrong 0B response three times
Post #64 20743320 22 Sep 2023 18:06

morgan_flint wrote:
Regarding battery discharging, let's see if @p.kaczmarek2 can take a look at the information in my previous post to see if the "closing message" that the WiFi module is sending to the MCU is adequate.

It seems that the WiFi module receives a request Query the signal strength of the currently connected router (0B) and tries to respond with an incorrect command (08). And he does it three times in accordance with what is expressed in the protocol information:

--------------------------------
Note:

All data greater than one byte shall be transmitted with big-endian mode.

All examples in the protocol use hexadecimal data.

The packets sent by Wi-Fi module time out after 1 second. The resend mechanism will resend three packets.

Generally, the same command word adopts synchronous sending and receiving mechanism. One party sends a command, and the other party responds. If the sender fails to receive the correct response packet within the stipulated period, the transmission times out.
--------------------------------

But that would only be 3 seconds.
Rechargeable AAA batteries cause rapid rebooting
#65 20743385 22 Sep 2023 18:50

auntlydia auntlydia

Level 10

Posts: 70

Help: 2

Rate: 14
Helpful post? (+1)

Rechargeable AAA batteries cause rapid rebooting
Post #65 20743385 22 Sep 2023 18:50

I have tested now with fully charged 1.2V AAA rechargeable batteries. After only 3 days the device was out of sufficient power and kept then rebooting every now and then, and in consequence lost its time setting. I suppose at some point the power is enough to supply the display and sensor, but not to establish a frequent WiFi connection. Have others similar results? I will test with the same batteries with original Tuya firmware and see if there is a difference. Compared to TH01 sensor, which lasts several weeks or even months with fresh batteries with openbk, this is a huge difference.
Battery drain from frequent WiFi reconnects on AAA cells
#66 20743433 22 Sep 2023 19:14

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

Battery drain from frequent WiFi reconnects on AAA cells
Post #66 20743433 22 Sep 2023 19:14

auntlydia wrote:
I have tested now with fully charged 1.2V AAA rechargeable batteries. After only 3 days the device was out of sufficient power and kept then rebooting every now and then, and in consequence lost its time setting. I suppose at some point the power is enough to supply the display and sensor, but not to establish a frequent WiFi connection. Have others similar results? I will test with the same batteries with original Tuya firmware and see if there is a difference. Compared to TH01 sensor, which lasts several weeks or even months with fresh batteries with openbk, this is a huge difference.

The problem of battery depletion seems to be related to the type of base technology, which is why Zigbee is much more efficient for battery-powered devices, because this type of module consumes much less in Tx mode than conventional WiFi.

For devices that are permanently connected to the electrical grid there is no problem with consumption, regardless of the type of technology.

Grettings
ADVERTISEMENT
Light_Signal carries a 16-byte serial frame
#67 20746960 25 Sep 2023 18:54

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

Light_Signal carries a 16-byte serial frame
Post #67 20746960 25 Sep 2023 18:54

morgan_flint wrote:
I finally could repair my scope yesterday, so I'll take a new look at the communication between U3 and U8.

Hello to all, after some time inactive, but I had been doing several experiments and suddenly the device stopped working... After reflashing OBK a couple of times with no success, I reflashed the original FW and all seems back to normal. I'll reflash OBK later again and see what happens.

Regarding communication between U3 and U8, my initial guess (pins 4 and 5 of U3 connected to pins 10 and 8 of U8 respectively being serial or I2C) proved incorrect. U3_5-U8_8 apparently never changed (always high) and U3_4-U8_10 was normally high and went low for about 20 mS repeating this every 2 seconds approximately. Of course, this didn't seem enough to program the (according to my guess) RTC from the MCU, so I decided to take a look at the pad labeled "Light_Signal" and, bingo! it looked like a serial communication.

The following images show U8 pin 10 (yellow trace) and Light_Signal (green one). As you can see, the yellow trace goes down coinciding with the first or second low to high transition of the green one (if it was first or second seemed random), and went high again a few ms after the end of activity in the green one.

I couldn't guess the utility of this signal (maybe an acknowledgment sent from U8 to U3 when it receives serial communication?) so I went on with the analysis of Light_Signal:

I wasn't very confident about the protocol decoding of the scope, so I connected Light_Signal to a serial to USB converter and got this (the hex file is also attached):

As you can see, it consists of a 16-byte array. The capture was done on power on, so the bunch of 00's at the beginning seem to be related to the period while the date and time hadn't yet been received from the NTP server. After some more captures and looking simultaneously at the display, I think:
- The 1st byte is a header (always FF)
- 2nd byte is related to the temperature
- 3rd is always 01 (?)
- 4th is related to the humidity
- 5th is always 01 (?)
- 6th to 11th to date-time, except for the 8th one that changed for a few seconds when the button was pressed (backlight)
- I couldn't guess the meaning of the rest of the bytes

It would be interesting to fully decode this protocol if we wanted to get rid of the Tuya MCU and control U8 directly from the module, but I don't think it's worth the effort...

Attachments:

TH08_Light_Data_capture.hex (416 Bytes) You must be logged in to download this attachment.
OBK keeps MCU connected longer than stock firmware
#68 20746981 25 Sep 2023 19:32

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

OBK keeps MCU connected longer than stock firmware
Post #68 20746981 25 Sep 2023 19:32

spin55 wrote:
Unless there is an error, the command to send would be: 55aa00090008110200040000000524 for a reporting interval of 5 minutes.

And TuyaMCU should answer with: 55aa030900000b.

Hello, Spin55

I tried this and, after a lot of trial and error, could send that stream with a tool called ComDebug and get the response from the MCU with Realterm. I had also tried sending it with realterm, but if I pasted 55AA00090008110200040000000524 to Realterm, it would change it to 35 35 41 41 30 30 30 39 30 30 30 38 31 31 30 32 30 30 30 34 30 30 30 30, and this was what was received in another terminal with its COM port's RX connected to the first one's TX. I tried several options in realterm but couldn't find any that permitted me to receive what I wanted to send, so I had to use ComDebug to send the sequence.

Anyway, the MCU just answered FF FF to that sequence, so I guess that DP is not implemented.

Added after 23 [minutes]:

spin55 wrote:
The problem of battery depletion seems to be related to the type of base technology, which is why Zigbee is much more efficient for battery-powered devices because this type of module consumes much less in Tx mode than conventional WiFi.

I agree Zigbee would be more efficient, but I also think there's a problem with the terminating sequence sent by OBK to the MCU, as I said here, because with OBK the module remains connected for a long time each time it's powered on by the MCU (more than a minute) while with the original FW it goes off just after the communication with the MCU ends (about 10 seconds).

I still have to test how long would a battery last with OBK and compare it to original FW, but measuring the consumption with the original FW it's about 0.03mA on standby, but it peaks to even more than 50 mA (25-30 mA on average) when the module is connected, so the difference of on-time between both FWs can make a significant difference on battery usage. Probably, it's due to the differences between version 03 and version 01 of the protocols as you said before.
#69 20747022 25 Sep 2023 19:44

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

Post #69
20747022 25 Sep 2023 19:44

morgan_flint wrote:
I had also tried sending it with realterm, but if I pasted 55AA00090008110200040000000524 to Realterm

Would you mind commenting on how you tried to send it with Realterm? If possible with Realterm images.
RealTerm pastes hex as ASCII by default
#70 20747067 25 Sep 2023 20:18

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

RealTerm pastes hex as ASCII by default
Post #70 20747067 25 Sep 2023 20:18

Copied the sequence from your post (55AA00090008110200040000000524) with Ctrl+C and pasted it into the realterm screen (Ctrl+Alt+v or right click + "paste to port").

The first image is selecting Hex in "Display as" and the second with Ascii. The receiving terminal (on the right) receives the same:

There must be an option to indicate that you are pasting Hex, not Ascii, but I couldn't find it
ADVERTISEMENT
Send the command from the Send tab, not paste mode
#71 20747082 25 Sep 2023 20:27

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (+1)

Send the command from the Send tab, not paste mode
Post #71 20747082 25 Sep 2023 20:27

I just confirmed the doubt I had. You have sent the command by doing a Copy/Paste in Send Number and you got what you see above. It is not correct, to send it you have to enter it by typing as seen in the image.

In any case, it is no longer important because you could have done it with the other program and there is no DP17 implemented as you suspected.

You have to send it from the Send tab.
OBK likely sends wrong terminating sequence to MCU
#72 20747094 25 Sep 2023 20:37

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

OBK likely sends wrong terminating sequence to MCU
Post #72 20747094 25 Sep 2023 20:37

morgan_flint wrote:
I agree Zigbee would be more efficient, but I also think there's a problem with the terminating sequence sent by OBK to the MCU, as I said here, because with OBK the module remains connected for a long time each time it's powered on by the MCU (more than a minute) while with the original FW it goes off just after the communication with the MCU ends (about 10 seconds).

I've updated the comparison between the captures adding the relative timestamp (time from the first message) and there's something curious: As you can see, with the original FW the module answers to the first message from the MCU within 1 second, while OBK takes 10 seconds to answer.

I also have looked WiFi for low power protocol for the last message sent to the module (55AA000B00000A) and it's response (55AA000B000201505D). The first one is "MCU obtains the strength of the connected router" (I understand the MCU asks the module for the signal strength) and the response from the module is "Module returns current value of strength (80)". None of these seem to have any meaning in the "normal" protocol, nor could I find the meaning of the last answer (repeated three times) of the module with the OBK FW (55AA000800010008), being this one the more similar one (55 aa 00 08 00 00 07, Query DP status).

So, probably, the MCU is waiting for the strength signal data and receives instead a query it doesn't understand, so remains a long time waiting for the answer without disconnecting the module, until it finally gives up

Attachments:

TH08_OBKvsOrigRAW_T.pdf (400.58 KB) You must be logged in to download this attachment.
#73 20747104 25 Sep 2023 20:44

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

Post #73
20747104 25 Sep 2023 20:44

>>20747082
I had tried also that, but if I hit "send numbers" nothing happens, and if I hit "send ascii" I get the same result as of pasting directly to the terminal...

I must have something wrong with my configuration
UART wiring via WiFi module pins preferred
#74 20747106 25 Sep 2023 20:50

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

UART wiring via WiFi module pins preferred
Post #74 20747106 25 Sep 2023 20:50

morgan_flint wrote:
I also have looked WiFi for low power protocol for the last message sent to the module (55AA000B00000A) and it's response (55AA000B000201505D). The first one is "MCU obtains the strength of the connected router" (I understand the MCU asks the module for the signal strength) and the response from the module is "Module returns current value of strength (80)". None of these seem to have any meaning in the "normal" protocol, nor could I find the meaning of the last answer (repeated three times) of the module with the OBK FW (55AA000800010008), being this one the more similar one (55 aa 00 08 00 00 07, Query DP status).

So, probably, the MCU is waiting for the strength signal data and receives instead a query it doesn't understand, so remains a long time waiting for the answer without disconnecting the module, until it finally gives up

Now you have understood it.

Added after 4 [minutes]:

morgan_flint wrote:
I had tried also that, but if I hit "send numbers" nothing happens, and if I hit "send ascii" I get the same result as of pasting directly to the terminal...

I must have something wrong with my configuration

Como conectas UART Usb con placa??

Conectas Tx y Rx de USB a Tx y Rx de módulo WiFi??.

Although it may seem strange, it is better to connect from the WiFi module than directly to the Tx and Rx pins of the TuyaMCU chip to take advantage of the resistances that should be between terminals to avoid possible short circuits.
#75 20747161 25 Sep 2023 21:17

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14750

Help: 659

Rate: 12866
Helpful post? (0)

Post #75
20747161 25 Sep 2023 21:17

So it seems that we have to send one extra packet to get sleep earlier?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Ground CEN to isolate WiFi module during USB testing
#76 20747474 26 Sep 2023 07:54

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

Ground CEN to isolate WiFi module during USB testing
Post #76 20747474 26 Sep 2023 07:54

@morgan_flint:

I forgot to tell you that to prevent the WiFi module from interfering with the USB connection when you want to carry out the test with batteries inserted, you have to set the CEN pin of the module to GND.

Back in the day I communicated with the TuyaMCU chip both without batteries and with them, as you can read in this link: https://www.elektroda.com/rtvforum/topic3937723-90.html
CEN pin must be grounded for UART tests
#77 20747640 26 Sep 2023 10:37

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

CEN pin must be grounded for UART tests
Post #77 20747640 26 Sep 2023 10:37

spin55 wrote:
Como conectas UART Usb con placa??

Conectas Tx y Rx de USB a Tx y Rx de módulo WiFi??.

For that test with Realterm I wasn't using the TH08, just two serial to USB with TX of one connected to RX of the other, just to check what I'm sending from the first one. When I saw I wasn't sending the correct sequence, then I switched to ComDebug to make the test sending the sequence to the MCU.

spin55 wrote:
I forgot to tell you that to prevent the WiFi module from interfering with the USB connection when you want to carry out the test with batteries inserted, you have to set the CEN pin of the module to GND.

To be sure, in my tests I fully isolated module and MCU, cutting RX, TX and CEN, but that is a simpler method, I'll use it in future tests

Added after 19 [minutes]:

p.kaczmarek2 wrote:
So it seems that we have to send one extra packet to get sleep earlier?

I think the best possibility would be to implement the correct response to the query from MCU to module 55AA000B00000A (MCU obtains the strength of the connected router) that the module should respond with 55AA000B000201505D (Module returns current value of strength (80)), ideally adapting the latter to the real signal strength, according to the protocol described here (55AA000B0002XXYYZZ, being XX failure/success, YY the strength in hex and zz the chechsum). If it's complicated to implement the real signal strength, just sending a fixed value is enough, probably the MCU just uses this info to show it in the WiFi symbol on the screen.

I haven't been able to find the meaning of the last three messages that the MCU is receiving (55AA000800010008 repeated three times), but the original FW doesn't send them so, if possible, they should be omitted.
Correct Realterm hex setup for TuyaMCU testing
#78 20749322 27 Sep 2023 16:19

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (+1)

Correct Realterm hex setup for TuyaMCU testing
Post #78 20749322 27 Sep 2023 16:19

@morgan_flint,

First of all, I apologize because the information I provided you about using Realterm is not correct, because a few months have passed since I used the program and I answered you based on what I remembered.

I reconnected the USB adapter to the pir motion NEO and realized the error.

This is how you have to configure Realterm:

Display tab:

Port tab:

Send tab:

As you can see, the data must be entered in hexadecimal format.
You add them one at a time and press Send Number. To enter the following ones you can edit the one you just entered and so on. When you connect the device you choose them from the drop-down tab.

On the screen you will see the commands you send in green and the responses from TuyaMCU in yellow.

As you can see, I sent commands 01 and 02 that were answered by MCU with the identification data (01), acknowledgment that there is already a connection to the cloud (02) and the status of the variables (05). In this case the detection values (00) and battery level (64) which in decimal is 100 as you already know.
And you can also see that I sent command 09 and it hasn't responded.

This test is done with the connections as I mentioned in a previous post and without battery or external power. Tx, Rx, GND from USB to Tx, Rx, GND from Wifi module and CEN to GND.
Reporting interval command not implemented in TuyaMCU
#79 20754625 01 Oct 2023 20:20

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

Reporting interval command not implemented in TuyaMCU
Post #79 20754625 01 Oct 2023 20:20

Thank you for the info, @spin55
I made the experiments again with this configuration and could effectively send the message by writing the hex numbers as 0xXX, so I made a first test sending from Realterm the first packet in the sniffed logs and obtaining the same answer from the MCU. Then tried sending the message from your post here:
spin55 wrote:
Unless there is an error, the command to send would be: 55aa00090008110200040000000524 for a reporting interval of 5 minutes.

And TuyaMCU should answer with: 55aa030900000b.

With no response from the MCU, so definitively this is not implemented.

So now let's see if @p.kaczmarek2 can implement the correct response to the last query from the MCU to the module MCU obtains the strength of the connected router (55AA000B00000A) and see if this abbreviates the time before the MCU powers off the module (details at the end of this post).

Another thing that would be interesting to investigate is why with the original FW the module answers to the first message from the MCU within 1 second, while OBK takes 10 seconds to answer, as I said at the beginning of this post. I'll try it again when I reflash OBK to confirm this delay.
#80 20791562 30 Oct 2023 01:46

stantonjody stantonjody

Level 1

Posts: 1
Helpful post? (0)

Post #80
20791562 30 Oct 2023 01:46

@auntlydia I was just wondering if you did try a USB power mod for this device?
I was thinking I may give one of mine 5v directly and see if it can work with it or fries it!
ADVERTISEMENT
USB-C supply mod with 4.2V buck regulator
#81 20791566 30 Oct 2023 02:24

auntlydia auntlydia

Level 10

Posts: 70

Help: 2

Rate: 14
Helpful post? (+1)

USB-C supply mod with 4.2V buck regulator
Post #81 20791566 30 Oct 2023 02:24

What a coincidence, I just did it today:

I used a USB-C female connector PCB soldered to a step-down DC voltage regulator adjusted to 4.2V output. That one I soldered to the battery pads on the motherboard. It works without any issues.

Another option would be a 3.7V LiPo battery with USB charging module.

Any voltage between 3.3V and 4.5V should be safe to use, personally I wouldn't want to go higher than that. It may be fine though, but who knows for how long. I prefer to be safe on this one.

I'll still cut the case to make it fit in nicely, so the USB can be plugged normally into it from the bottom. I'll post results when I have time to finish it.

FYI: the device has already lasted six weeks without replacing the batteries on the ORIGINAL Tuya Firmware!!! With OpenBK, I have to swap out my rechargeables every 3 days. I wonder if this could still be improved with further development of the MCU driver.
#82 20791751 30 Oct 2023 09:32

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14750

Help: 659

Rate: 12866
Helpful post? (0)

Post #82
20791751 30 Oct 2023 09:32

It seems I need to implement thing from this post:
https://www.elektroda.com/rtvforum/topic4000657-60.html#20754625
Remind me if i forget to do that this week, please. Can anyone help with testing?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#83 20791760 30 Oct 2023 09:39

auntlydia auntlydia

Level 10

Posts: 70

Help: 2

Rate: 14
Helpful post? (0)

Post #83
20791760 30 Oct 2023 09:39

that would be awesome! sure, I'm happy to help with testing, just let me know what to do. Cheers =)
#84 20792530 30 Oct 2023 19:00

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

Post #84
20792530 30 Oct 2023 19:00

>>20791751
Me too, of course!
Thanks!!
Self-test passes with hardcoded response values
#85 20794554 01 Nov 2023 08:03

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14750

Help: 659

Rate: 12866
Helpful post? (0)

Self-test passes with hardcoded response values
Post #85 20794554 01 Nov 2023 08:03

Ok I am looking into it, by the way I will update the analyzer

Added after 2 [minutes]:

I will also add a self test for that

Added after 15 [minutes]:

Ok, it passes the self test now:

but I didn't test it on physical device, do anyone here wants to try?

Currently response values are hardcoded.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#86 20796242 02 Nov 2023 12:21

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

Post #86
20796242 02 Nov 2023 12:21

p.kaczmarek2 wrote:
but I didn't test it on physical device, do anyone here wants to try?

I could try. Where can I download this version?
I see Github still has V0.5 as latest release
#87 20796258 02 Nov 2023 12:29

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14750

Help: 659

Rate: 12866
Helpful post? (0)

Post #87
20796258 02 Nov 2023 12:29

I am referring to the OBK firmware, the latest version available was published 3 hours ago, it's 1.17.302:

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#88 20796318 02 Nov 2023 16:30

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

Post #88
20796318 02 Nov 2023 16:30

Ok, I'll try

Added after 3 [hours] 6 [minutes]:

p.kaczmarek2 wrote:
it's 1.17.302

Where can I find it? I'm looking at https://github.com/openshwprojects/OpenBK7231T_App and this is what I get:
#89 20796636 02 Nov 2023 16:44

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14750

Help: 659

Rate: 12866
Helpful post? (0)

Post #89
20796636 02 Nov 2023 16:44

The 302 version is temporarily removed because we have detected an unexpected issue with JSON code. You need to wait some time for next public version to appear. Maybe today or tomorrow.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Bypassing Q1 to keep module powered for OTA and config
#90 20796796 02 Nov 2023 20:31

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 63
Topic author Helpful post? (0)

Bypassing Q1 to keep module powered for OTA and config
Post #90 20796796 02 Nov 2023 20:31

I've seen it's available again and have flashed it. Still have to connect UART and run the analyzer.

But I've seen a first difference in Home Assistant:

The RSSI sensor didn't appear in the previous version I tried (I don't remember which one it was).
I didn't change anything in the autoexec.bat
Its a pity that id doesn't show a meaningful value; maybe I have to change something in the configuration.

Added after 1 [hours] 45 [minutes]:

Ok, I connected the serial to USB adapters and analyzed RX and TX with TuyaMCUAnalyzer-v0.5. I'm attaching the RAW and decoded outputs.

As with the original FW, now, as we wanted, the Tuya MCU disconnects the module as soon as it receives the last packet from the module, thus saving battery.

As the module is on only for a few seconds, it's almost impossible to connect to its web interface, so to make modifications in the configuration or make OTA updates it is necessary to bypass the transistor that disconnects it from GND (Q1). This can be easily done by soldering a cable to the module's GND and connecting it to the main GND (negative battery terminal, for example). If you know a more elegant way of doing it, please tell me (something via MQTT perhaps?).

Another comment: I'm using the same autoexec as auntlydia's (post #3) and, as we have the same timezone, I also have "ntp_timeZoneOfs 2". During the tests I made before, the time on the display was correct, but now it shows one hour later. I understand It must be because we changed to winter time last weekend. Is there a way to automatically adjust this?

Thank you very much to @p.kaczmarek2 for this new version!

Attachments:

OBK_RAW.txt (3.5 KB) You must be logged in to download this attachment.

OBK_decoded.txt (5.71 KB) You must be logged in to download this attachment.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI voice):

Report a violation of the law

Topic summary

✨ Discussion of a BK7231N-based TH08 LCD calendar/clock/temperature/humidity device with 3xAAA battery and backlight, identified as a newer TH06/TH08 variant. The thread covers teardown details, flashing OpenBK without desoldering, TuyaMCU protocol analysis, UART sniffing, and discovery that the device uses low-power Tuya protocol behavior with dpIDs for temperature, humidity, battery level, RSSI, and °C/°F selection. A missing MCU packet was added so OpenBK now powers down correctly and battery life matches the original firmware. The device reports sensor updates on change and periodically, supports battery-level mapping in Home Assistant, and can be powered from AAA cells, LiPo, or USB via a step-down converter. Further reverse engineering focused on the unknown U8 chip, LCD/backlight control, RTC behavior, and possible OTA/configuration wake-up handling.
AI summary based on the discussion. May contain errors.

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]

AI summary based on the discussion. May contain errors.