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

morgan_flint 41307 254

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.

Report a violation of the law

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI):

#61 20737720 18 Sep 2023 13:07

auntlydia auntlydia

Level 10

Helpful post? (+1)

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
#62 20738650 19 Sep 2023 10:01

morgan_flint morgan_flint

Level 14

Topic author Helpful post? (0)

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.

#63 20739295 19 Sep 2023 18:15

spin55 spin55

Level 17

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

ADVERTISEMENT
#64 20743320 22 Sep 2023 18:06

spin55 spin55

Level 17

Helpful post? (+1)

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.
#65 20743385 22 Sep 2023 18:50

auntlydia auntlydia

Level 10

Helpful post? (+1)

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.
#66 20743433 22 Sep 2023 19:14

spin55 spin55

Level 17

Helpful post? (0)

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
#67 20746960 25 Sep 2023 18:54

morgan_flint morgan_flint

Level 14
Topic author Helpful post? (0)

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.
#68 20746981 25 Sep 2023 19:32

morgan_flint morgan_flint

Level 14

Topic author Helpful post? (0)

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

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.
ADVERTISEMENT
#70 20747067 25 Sep 2023 20:18

morgan_flint morgan_flint

Level 14

Topic author Helpful post? (0)

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
#71 20747082 25 Sep 2023 20:27

spin55 spin55

Level 17

Helpful post? (+1)

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.
#72 20747094 25 Sep 2023 20:37

morgan_flint morgan_flint

Level 14
Topic author Helpful post? (0)

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

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
ADVERTISEMENT
#74 20747106 25 Sep 2023 20:50

spin55 spin55

Level 17

Helpful post? (0)

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

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.
#76 20747474 26 Sep 2023 07:54

spin55 spin55

Level 17

Helpful post? (0)

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
#77 20747640 26 Sep 2023 10:37

morgan_flint morgan_flint

Level 14

Topic author Helpful post? (0)

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.
#78 20749322 27 Sep 2023 16:19

spin55 spin55

Level 17

Helpful post? (+1)

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.
#79 20754625 01 Oct 2023 20:20

morgan_flint morgan_flint

Level 14

Topic author Helpful post? (0)

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

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!
#81 20791566 30 Oct 2023 02:24

auntlydia auntlydia

Level 10

Helpful post? (+1)

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

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

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

Topic author Helpful post? (0)

Post #84
20792530 30 Oct 2023 19:00

>>20791751
Me too, of course!
Thanks!!
#85 20794554 01 Nov 2023 08:03

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

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

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

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

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

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.
#90 20796796 02 Nov 2023 20:31

morgan_flint morgan_flint

Level 14
Topic author Helpful post? (0)

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):

Report a violation of the law

Topic summary

✨ 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.

FAQ

TL;DR: “Flashing succeeds 100 % when CEN, RX and TX are isolated” and the Wi-Fi module stays powered just 18 s per cycle [Elektroda, spin55, post #20804765] Unit switch is dpID 9; send 55AA001000070101090400010026 to force °C [Elektroda, smoeller95s, post #21550660] Battery life rises from 3 days to 6 weeks after v1.17.302 fix [Elektroda, morgan_flint, post #20796796]

Why it matters: correct pinout, dpIDs and flags avoid soft-brick loops and halve power drain.

Quick Facts

• MCU board rev V3.7 (2023-11-06) uses step-down RT8008-like regulator, 2.3–3.6 V out [Elektroda, bogovik, post #21007162] • Default Tuya baud: 9 600 bps; do not force 115 200 on battery models [Elektroda, bogovik, post #21007162] • Wi-Fi on-time: 10–18 s (after dpCache fix) [Elektroda, p.kaczmarek2, post #20796796] • Battery thresholds: High ≥ 4 V, Medium 4–3.1 V, Low < 3.1 V [Elektroda, morgan_flint, post #20804228] • dpIDs: 1 Temp, 2 RH, 3 Batt-state, 4 Batt-%, 9 Unit, 10–13 limits, 14–15 alarms, 17–20 report/sensitivity [Elektroda, divadiow, post #21357234]

Which pads are Vcc, GND, TX, RX and CEN on TH08/TH08-B?

On CBx/CBU/CB3S modules the corner row is 1 GND, 2 3.3 V, 3 RX2, 4 TX2, 5 CEN (EN). Test pads marked RX1/TX1 belong to the Tuya-MCU and must be cut or unsoldered before flashing [Elektroda, morgan_flint, post #20929625]

How do I flash OpenBeken without desoldering?

Lift (or cut) MCU pins 8 (CEN) and 9/10 (RX/TX) or sever their traces. 2. Power the CBU with 3.3 V (battery V+ bypasses the regulator). 3. Run BK7231Flasher, back up, then write the QIO image at 921 600 bps. 4. Re-join the cuts with thin wire [Elektroda, spin55, post #21003945]

Device reboots endlessly after battery is flat – fix?

Safe-mode reset: toggle power 5 × within 5 s, connect to the OBK-AP, press “Exit safe-mode”, then set a working NTP server and MQTT host [Elektroda, morgan_flint, post #20919613]

Why does NTP show 1970 or 2070 date?

The LAN NTP IP must respond within the 18 s Wi-Fi window. Use e.g. ntp_setServer 217.147.223.78 and keep ntp_timeZoneOfs correct. Each failed packet logs NTP_SendRequest: Unable to send message [Elektroda, spin55, post #21074156]

How to switch the LCD from °F to °C?

Send the unit-convert dpID 9 packet once after boot:
delay_s 2
uartSendHex 55AA001000070101090400010026
Value 00 gives °C; 01 gives °F [Elektroda, smoeller95s, post #21550660]

MQTT values are 10× smaller – why?

Disable flag 33 (apply multiplier before publish). Otherwise temperature_div10 splits the MCU value and HA divides it again, giving 2.2 °C instead of 22 °C [Elektroda, p.kaczmarek2, post #21377733]

Can I map battery percentage to Home Assistant?

Yes.
setChannelType 4 BatteryLevelPercent
linkTuyaMCUOutputToChannel 4 val 4
After OBK 1.17.780 the HA discovery JSON includes this sensor automatically [Elektroda, p.kaczmarek2, post #21378297]

How to keep Wi-Fi on for configuration?

Hold the top button ≥ 3 s; Tuya-MCU holds CBU power high for ~90 s, enough for OTA or web-config [Elektroda, spin55, post #20804765]

What is dpCache and why use it?

Battery devices resend saved limits after every reboot. Mark a channel persistent with SetStartValue <ch> -1 and add 1 at the end of linkTuyaMCUOutputToChannel … to include it in the dpCache reply packet 0x10 [Elektroda, p.kaczmarek2, post #21385904]

Edge case – flashing stops at 70 % every time.

UM8005/UM805 (Tuya-MCU) toggles CEN mid-flash. Isolate CEN first or power the module through 3.3 V and ground while MCU ground is disconnected [Elektroda, spin55, post #21003945]

Generated by the language model.