After searching the database, I think this is the first post for this device. It seems to be a newer version of others already described here. I like the display design, also with backlighting, and that it is battery powered (3xAAA - 4.5V, probably easy to convert to LiPo).
Aliexpress' ad capture (in case link becomes obsolete):
It's advertised for 11,79€ with free shipping, but I managed to get it for 4,49€ as a "Choice" offer:
External and teardown photos:
As you can see, the PCB silkscreen states "TH08-CBU-ATH20-V2 2023/07/22"
I understand:
- "TH08" is the model so it must be a newer version of TH06, covered here and here. It could be also a close relative of the item described here - "CBU" refers to the WiFi module, as it corresponds with the module's silkscreen (datasheet)
- "ATH20" is the temperature/humidity sensor (product page and datasheet)
There are also:
- A big IC labelled "BL 55070", which is an LCD driver (product page and datasheet)
- Two 16 pin ICs with the label erased: One of them (U8) has a quartz crystal connected (X1), and three pins are connected to pads labeled "BACK_LIGHT", "LCD_SDA" and "LCD_SCL", so it's clear it controls the display and its backlight, so I think this is a dedicated RTC. Some tracks connect this IC with the previous one (U3), which in turn has pins connected to pads labeled "RX1" and "TX1" (connected to the Wifi Module), "ATH20SDA" (sensor) and "LIGHT_SIGNAL", connected to U8. This one must be the Tuya MCU.
Among the other components, Q1 controls power to the WiFi module, similar to the other products mentioned above. It's an N-Channel Enhancement Mode MOSFET NP2302FVR-J (datasheet).
The full schematic and block diagram are included below and the analysis of traffic in RX1 and TX1 will be posted later (done, see post#33)
Tuya App screenshots:
The update interval for the graphics is very long (1 hour) and, apparently, can't be changed from the app (its an App related issue; the device updates more frequently, as you can see later in this thread). Related to this, the last screenshot shows an error when trying to connect to the device. I understand it's because the device only connects for a brief time between updates, so you should connect to it in that brief moment to get the info (I've tried just after inserting the batteries without success, so it must be the connection doesn't last enough). After powering the module directly to be able to read it with BK7231flasher, I could complete this screen, so it's attached after the one with the error.
Schematic:
Block Diagram:
After drawing this, it seems clear U3 is the main MCU, connected to CBU module via RX1 and TX1, to the key, to the sensor via I2C, to the LED, to a voltage divider from the battery, and to the other U8 with two wires (another I2C or RX-TX?) and another signal to start the backlight. There's also a mysterious pad (PB5) connected to it.
U8, with a 32.768 kHz oscillator, is probably an RTC, controls the LCD via I2C to U1 and also the duration of the backlight, and is programmed/read by U3 via a two-wire interface.
As stated above, Q1 is a mosfet controlling power to the WiFi module, switching on or off the connection to ground.
Finally, U4 is the main voltage regulator (2,8 volts) feeding all components except the backlight, which is fed by U6 (3 volts) that is turned on or off by pin 9 of the RTC.
NOTE: I've updated several times this post to include the information that we have been finding along the thread. Still pending to include the summary of the OBK flashing procedure and its configuration
This indeed looks like a new version of TH06, just as you said. Let me know when you've done the packets capture. I wonder how much of the protocol/dpIDs has changed.
Hi, I just happened to unpack, disassemble and flash the same device today! I was about to create a post for it, but then you have been already doing this job, thank you! Maybe we can work together to get this sensor working properly!
What I found so far is:
- OpenBK can be flashed without desoldering or cutting traces
- configuration of temperature and humidity can be used as with other known TuyaMCU sensors, the drivers work here for battery, humidity and temperature
- I used startup commands/autoexec.bat with following input:
startDriver TuyaMCU
startDriver tmSensor
startDriver NTP
ntp_setServer xxx.xxx.xxx.xxx // put the IP address of your preferred NTP server
ntp_timeZoneOfs 2
setChannelType 1 temperature_div10
linkTuyaMCUOutputToChannel 1 val 1
setChannelType 2 Humidity
linkTuyaMCUOutputToChannel 2 val 2
setChannelType 3 ReadOnly
linkTuyaMCUOutputToChannel 3 val 3
I get correct data for T/H values, battery value between 1 and 3, and also OpenBK pulls correct date/time from NTP server.
What doesn't work: get the correct date/time on the device's display
Yes, indeed, it would be good to find out how time is transferred from firmware to the module... is it requested? Or pushed through without request? How can we find out, is there anything I can contribute to acquire that information?
I am not sure if these log entries are connected to a possible date/time request:
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:NTP:Seconds since Jan 1 1900 = 3903028582
Info:NTP:Unix time : 1694046982
Info:NTP:Local Time : 2023/09/07 00:36:22
Info:MAIN:Time 12, idle 192663/s, free 71352, MQTT 0(0), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val 1694046987 to bksensor_THD00/datetime retain=0
As I understand it, command 2 is incoming and after that firmware reacts with publishing NTP information via MQTT? Is the order of processing chain just by accident here or are those two events actually connected to each other?
Info:TuyaMCU:TUYAMCU received: 55 AA 00 06 00 00 05
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 6 (SetDP) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 6
Info:MAIN:Time 19, idle 190450/s, free 71264, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val -70 to bksensor_THD00/rssi retain=0
As I understand it, the first one (command 16) is unknown and could be actually the one we are looking for, and the second one (command 6) seems to be about Wi-Fi signal strength?
As I understand it, command 2 is incoming and after that firmware reacts with publishing NTP information via MQTT? Is the order of processing chain just by accident here or are those two events actually connected to each other?
Interestingly enough there is a section called Obtain the local time:
It seems we have MCU sending 55 aa 00 06 00 00 05 here! So it's not SetDP but ObtainLocalTime.
I've just updated the first post with some corrections and more information (schematic), and I see you've been making making progress!!
Time to read them in detail and see if I can add something else...
Thank you!
Added after 10 [minutes]:
auntlydia wrote:
I can also try to work with MCU sniffing tool, but as you said you want to do it, I will wait first.
If you can do the sniffing and have the time to do it, please take the lead! I have serial to USB converters and a Scope with (supposedly not very good) bus decoding, but I'm not an expert on this and probably it's going to take a long time until I can get results.
auntlydia wrote:
It would be interesting to find out how the device pulls date/time from firmware and sends it to the display!
As I said in the comments to the schematic, I suspect U8 is a dedicated RTC that controls the display and the main MCU (U3) program/read it via a two wire interface (probably I2C, as it has pull-ups, but could be also serial).
From the photos, I'm afraid in TH06 the display was controlled directly from the MCU, but this does not necessarily have to affect the protocol between MCU and module.
The display is controlled via MCU, that's why it's hard to just remove MCU and do everything in OpenBeken, although IMHO it would be the preferred way. TuyaMCU complicates lots of things.
Info:TuyaMCU:TUYAMCU received: 55 AA 00 10 00 02 01 09 1B
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 16 (Unknown) with 9 bytes
Info:MAIN:Time 15, idle 189075/s, free 62400, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic bksensor_THD00/1/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic bksensor_THD00/2/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic bksensor_THD00/3/get
Info:MQTT:Publishing val 50:8b:b9:eb:f0:3b to bksensor_THD00/mac retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 06 00 00 05
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 6 (SetDP) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: received TUYA_V0_CMD_OBTAINLOCALTIME, so sending back time
Info:TuyaMCU:MCU time to set: 1694091630
Info:TuyaMCU:ptime ->gmtime => tm_hour: 13
Info:TuyaMCU:ptime ->gmtime => tm_min: 0
I ordered more of those and another new one with a different design and also USB option, will post soon.
I guess the major problems to set up this device successfully are solved!? Does it still make sense to sniff MCU data? I only have UART USB module, no other equipment like a oscilloscope, is that required? It is new to me and I have no experience, but sure am keen to dig a bit into that in the future.
Whoa, I didn't expect it to work at the first try! I haven't even compiled that code before pushing it.
Well, if everything really works as expected, then there is very little point to doing data capture. It still can be useful, even as a reference, and I still could add it to capture samples here:
https://github.com/openshwprojects/TuyaMCUAnalyzer but still, it's not necessary if everything is running now.
I was kinda worried that I may need to introduce some artificial delay to make sure that NTP responds, but maybe it's fast enough... otherwise I will add a fix to the codebase when it's required.
Please post any devices you can get, even ESP devices, all teardowns are welcome. Even non IoT ones - here
As you haven't changed anything in this sense, I imagine the report time is still one hour, which I find too long. In the Tuya App there's no option to reduce it (as, for example, this device has. Apparently, that device also stored intermediate measurements, which were reported to the App once every 120 min (which could be reduced), but this one doesn't seem to have this ability, just reports one value per hour...
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
I checked Home Assistant history and I get an update of sensor data every ~17 minutes as standard, even without change of temperature or humidty. As soon as there is a change in temperature or humidity, device "wakes up" and data is transfered. I think this is quite a good condition already.
I also enabled flags 10 and 19, but I don't think they affect these intervals.
Maybe you can try to flash OpenBK and set it up with the suggested commands in autoexec.bat and have a look how often your device updates the data? I assume it would show the same behaviour as mine, as we seem to have the same model.
If there is no dpID for that, and no option to set it in Tuya app, then it's most likely not possible on given device.
Ok, sorry to hear that. Anyway, I'm not sure if "polling time" was the correct term for my question, what I meant is if there was a command to set the period in which the MCU "wakes up" the CBU WiFi module to send information to the App.
Generic teardowns section is only for non-iot teardowns, and smart home is for IoT topics and teardowns.
As I said, check if there is an option to set that wake up period in Tuya app, and if it's available, then capture the UART data.
I've also read somewhere that on some devices you can short button so it's always pressed and it will report more often, but I think it was in regard to Aqara Zigbee products.
Alternative would be to figure out LCD driver protocol, remove the MCU and connect everything to BK7231, but that would be a very hard task.
Maybe you can try to flash OpenBK and set it up with the suggested commands in autoexec.bat and have a look how often your device updates the data? I assume it would show the same behaviour as mine, as we seem to have the same model.
Ok, thanks!, I'll try that and report back.
I think, apart from the original firmware's low reporting frequency, this version of the device has one of the best designs and, if the battery life is long enough, it's alright as it is with AAA batteries. Otherwise, it could be worth modding it for LiPo battery
haha, I have played with thought about Lipo-mod as well! And we could squeeze in a USB-charge module, but we would need to cut the battery plastic housing to make some space. Else I totally agree, I think compared to many other TH sensors with display it is a very fine one!
Let us know what update intervals you get, I am curious! It could even be that same models have slightly different internal programming.
As I said, check if there is an option to set that wake up period in Tuya app, and if it's available, then capture the UART data.
I already checked it, as you can see in the screenshots at the first post, it seems that option is not available, unfortunately.
p.kaczmarek2 wrote:
Alternative would be to figure out LCD driver protocol, remove the MCU and connect everything to BK7231, but that would be a very hard task.
Totally agree... such an effort is not worth it, and probably this design with a dedicated RTC (U8) is better in terms of low power consumption. Another possibility would be to reverse-engineer the communication protocol between MCU (U3) and RTC (U8), but again, complicated and worse in terms of power consumption, I think.
Added after 7 [minutes]:
auntlydia wrote:
And we could squeeze in a USB-charge module, but we would need to cut the battery plastic housing to make some space
I was considering using LiPo batteries recovered from electronic cigarettes, which are very similar in size to AAAs but, unfortunately, they are a bit thicker:
You can also get very cheap NiMH's from old laptop batteries and reuse them with cheap charger modules from China, however in this case they most likely won't fit the case...
I was considering using LiPo batteries recovered from electronic cigarettes, which are very similar in size to AAAs but, unfortunately, they are a bit thicker:
I had flat lipos in mind, such as this one, including China cheap charging module with USB-C port:
anyway, the AAA option works fine too, I use rechargeable 1,2V batteries and will see how long they last...
Edit: Actually, for this device it would be even worth to do a USB direct power mod, which could be done by simple USB-C female connector board and a 5V-->4.2V stepdown converter.. for long-term usage it might be annoying to swap batteries or charge.
I get an update of sensor data every ~17 minutes as standard, even without change of temperature or humidty. As soon as there is a change in temperature or humidity, device "wakes up" and data is transfered. I think this is quite a good condition already.
I've been doing some tests without flashing OBK yet, and mine doesn't seem to behave like this, as even if I heat the sensor on purpose, the display doesn't change unless I power cycle the device (!).
Can you still check your MCU's FW version? Mine is 1.0 and, as this product is so young (PCB silkscreen states 22/07/2023) it may well have had some teething problems, corrected with a new MCU FW version. If that is the case, I think I should update MCU's FW before flashing OBK, as I don't now if OBK allows updating MCU's FW.
Do you know a way in OpenBK to check MCU version? if there is, I'm happy to do it for you.
I have two of these sensors (one not yet flashed, MCU version=1.0, one setup with OpenBK) and have just double checked: Upon change of T/H, there is transmission of new data every ~2 mintues on both devices, even without wifi connection the change happens in this interval on the device's display. It looks like we have a cycle of 2 minutes if there is a change + 15 minutes if there is no change, maybe that's how we get the 17 minutes altogether!?
could you try to initiate extreme change of T/H by warming up the device your hand, or blowing warm humid air with your mouth to the small sensor opening? and then check if you have any change on the display after ~2 minutes, with and without tuya connection. for me, as soon as the values changed on the display, in tuya app it's also updated.
Do you know a way in OpenBK to check MCU version? if there is, I'm happy to do it for you.
No, I don't know how; I imagine if it exists p.kaczmarek2 will tell us (I see he already answered as I was writing this post), but since you have an unflashed unit and the FW is the same as mine, probably both are the same.
auntlydia wrote:
could you try to initiate extreme change of T/H by warming up the device your hand, or blowing warm humid air with your mouth to the small sensor opening? and then check if you have any change on the display, with and without tuya connection. for me, as soon as the values changed on the display, in tuya app it's also updated.
That's more or less what I had done before, and couldn't see changes in the display, probably because I didn't wait long enough. Now I tried again and could check that the values on the display and the app do effectively change every 2 minutes. Sometimes, it seems to take longer, but maybe there's not enough change in the values.
Until here, good news, as It's much better than I feared (although I would have preferred this interval to be user-programmable, as in this device). The problems with the graphics in the Tuya app (only one value per hour) must then be a (bad) characteristic of the Tuya App and not of the device.
But, during the tests I found what I think is an awkward behavior: If I hit the backlight button I would have expected the forced updating of the values (the device "knows" you must be watching in that case...). Also, I was expecting this because, when the button is pressed, apart from the backlight being switched on, the blue LED blinks twice and the WiFi module's GND is pulled down, switching it on (pin 7 of U3 MCU goes up, see the schematic at the first post).This suggests that the device connects to the network when the button is pressed to send updated values.
Well, this doesn't happen. Instead of that, the values stay fixed (even after a forced heating), and the update period seems to freeze, as no change happens until nearly 8 minutes after the button is pressed. After that "freeze", the update period returns to the usual 2 minutes. I think it's clearly a bug... I don't know if there's a way to report bugs to the manufacturer, nor if he would care.
If you have the time (and patience...) you could try to reproduce this behavior...
I also checked that a long press of the button forces the device into pairing mode and it gets eliminated in the App, so you need to find it again.
EDIT: I repeated the test of pressing the button and now the "freezing" seems to be only 3-4 minutes (it varies from time to time). Another thing I noticed is that the blue LED inside the case blinks during the update.
EDIT2: I've also observed that the 2 min update interval can be longer if here are no changes in temperature. I think something related to this is what you detected when you said:
auntlydia wrote:
I checked Home Assistant history and I get an update of sensor data every ~17 minutes as standard, even without change of temperature or humidty. As soon as there is a change in temperature or humidity, device "wakes up" and data is transfered. I think this is quite a good condition already
Really, I don't think it wakes up on changes; it's more like: the MCU polls the sensor every two minutes and, if the values have changed, it publishes them via WiFi, and waits for another two minutes, but if there are no changes, it waits for another minute and polls again until changes are detected. It's an intelligent approach to save battery!
I can confirm your Analysis, the intervals can be different and it seems always connected to changing conditions, which is indeed beneficial for our battery life.
In openbk, I found that button press results in connecting to WiFi and updating current value, regardless of changes or not. so it kinda does everything we need.
One thing is left though, and that is the change of temperature unit to °F , which is supported by the device and can be set in tuya app. Personally I don't need it, but for people who are used to this unit, it might be a crucial setting. As p.kaszmarek2 suggested, this data could be sniffed via UART during changing the setting in tuya app.
In openbk, I found that button press results in connecting to WiFi and updating current value, regardless of changes or not. so it kinda does everything we need.
That would be perfect but, as this behavior corresponds to MCU and not OBK, I've tried it again; it seemed to work just once but the following tries (heating and cooling the sensor in between) didn't seem to work, probably transmits data, but the same as in the display, that doesn't change... now I'm completely clueless.
I'll continue testing and I'll try to sniff data. In the worst case, we can always use a power cycle to force it to send current values. It would be still better if we could identify the reset pin of the MCU.
I've checked now that it has pin 8 pulled up by R10 and connected to the WiFi module's pin 18 (CEN or reset, I hadn't identified this before). So, thinking it could be a reset pin, I've tried pulling it down with a relatively low value resistor to see if it causes a reset, but pin voltage stays high, so it's clear it's not the reset pin, but an output pin meant to reset the module from the MCU.
I have also taken the opportunity to look again at PB5 and LIGHT_SIGNAL; I still can't find anything connected to the first one but found now that the second one is connected to U8/P3. Probably, it's an active low output signal from the MCU to the RTC to trigger the backlight (I think the RTC controls by itself the time the backlight is on).
I'll update the schematic in the first post with all this changes
So we only display hours and minutes. That would mean that we could only wake OBK every minute to update minutes counter or smth... I am not sure. Depending on BK wake up timer precision, we could wake up OBK for few seconds every minute just to update minutes counter and also keep it awake for a longer time every N minutes to report the data or resync with NTP...
I am not recommending it currently because there might be some problems with timing and increased power usage, but it's certainly a possibility.
I'm not sure about button forcing update, as @auntlydia and I are getting different results (and even myself, from time to time...)
No, no seconds timer in the display. I really don't think it's worth adding support for BL55070 just for this case. It's a pity U8 has its markings erased (BTW, @auntlydia, Are they also erased in your units?) because it must be an RTC controllable via I2C that would take a lot of hard work from the module, in case we wanted to leave out the Tuya MCU.
I wanted to connect the serial to USB converters to sniff the communication, but I have another question regarding this: Surprisingly to me, the voltage that feeds the MCU, the CBU, and U8 is not 3.3V as I expected (and even wrote it in the first version of the schematic). I thought it should be 3.3V as is the usual voltage in these devices and is what is specified in the CBU module datasheet.
But, when I measured it (two different multimeters), I saw it's only 2.8V. I have serial to USB converters both for 5V and 3.3V, but not for 2.8V.
Do you think it's going to be a problem to use 3.3V while sniffing and/or programming? Also, @auntlydia: Which voltage did you use when you flashed OBK?
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/3158715000_1693991800.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/3444661700_1693991556.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/6506610500_1693991689.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/2989380300_1693991809.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/7651043000_1693991838.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/1663648700_1693991838.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/1969697100_1693991838.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/7338055100_1693991840.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/3968158600_1693991840.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/6755395200_1694002260.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/3453251900_1694002262.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/2045945500_1694002267.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/4171822400_1694002269.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/2400179400_1694078146.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/9605540000_1694078212.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/7320532000_1694102743.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/7905759700_1694078276.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/3943416400_1694629869.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/1388380900_1694685813.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/6418726300_1694685856.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/3789925500_1694036263.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/9594592300_1694037873.png "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/6885502900_1694066322.png "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/9023240300_1694066511.png "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/5725728000_1694066526.png "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/5404196700_1694084370.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/5547948200_1694088832.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/4800164300_1694089260.jpg "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
![[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight](https://obrazki.elektroda.pl/6717493100_1694109681.png "[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight")
