logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
UV printer on your desk?
UV printer on your desk? Discover eufyMake E1 »
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

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

morgan_flint 43893 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.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #121 20893731
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    Maybe wrong TuyaMCU baud rate?
    Are there ANY TuyaMCU packets in the Web App Log?
    Try adding:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_setBaudRate 115200

    If not, then maybe try:
    Code: text Expand Select all Copy to clipboard
    
// set TuyaMCU default wifi state 0x04, which means "paired",
// because some TuyaMCU MCUs will not report all data
// unless they think they are connected to cloud
tuyaMcu_defWiFiState 4
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #122 20893780
    vikicha
    Level 3  
    Posts: 4
    I try both settings but still no change.
    I can't see any TuyaMCU packet in WebApp Log.
    This is few secconds log after boot with both setting you sugest in autoexdec.bat

    Code: text Expand Select all Copy to clipboard
    o:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:Using SSID [Lazarovi1]
Info:MAIN:Using Pass [LazaroviDimitrovi]
Info:MQTT:MQTT_RegisterCallback called for bT obkB9F79399/ subT obkB9F79399/+/set
Info:MQTT:MQTT_RegisterCallback called for bT bekens_n/ subT bekens_n/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obkB9F79399/ subT cmnd/obkB9F79399/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/bekens_n/ subT cmnd/bekens_n/+
Info:MQTT:MQTT_RegisterCallback called for bT obkB9F79399/ subT obkB9F79399/+/get
Info:CMD:CMD TCP server started!
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:NTP:NTP driver initialized with server=162.159.200.1, offset=0
Info:MAIN:Started NTP.
Info:MAIN:Started TuyaMCU.
Info:MAIN:Started tmSensor.
Info:NTP:NTP server set to 162.159.200.1
Info:NTP:NTP offset set
Info:GEN:Channel 1 type changed to temperature_div10
Info:GEN:Channel 2 type changed to Humidity
Info:GEN:Channel 3 type changed to ReadOnlyLowMidHigh
Info:MAIN:Time 1, idle 264547/s, free 75792, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 2, idle 189916/s, free 75792, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 3, idle 190216/s, free 75792, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 4, idle 189001/s, free 75792, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 5, idle 190120/s, free 75792, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:ssid:Lazarovi1 key:LazaroviDimitrovi
Info:MAIN:Time 6, idle 182004/s, free 70496, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MAIN:Time 7, idle 181486/s, free 70504, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 8, idle 83108/s, free 70808, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 9, idle 0/s, free 70808, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 10, idle 0/s, free 70808, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:GEN:dhcp=0 ip=0.0.0.0 gate=0.0.0.0 mask=0.0.0.0 mac=50:8b:b9:f7:93:99
Info:GEN:sta: 0, softap: 0, b/g/n
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Time 11, idle 108972/s, free 69288, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_DISCONNECTED - 2
Info:MAIN:Time 12, idle 187107/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 13, idle 188629/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 14, idle 190005/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 15, idle 187268/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 16, idle 189962/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 17, idle 189981/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 18, idle 188855/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 19, idle 188751/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 20, idle 189956/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:GEN:dhcp=0 ip=0.0.0.0 gate=0.0.0.0 mask=0.0.0.0 mac=50:8b:b9:f7:93:99
Info:GEN:sta: 0, softap: 0, b/g/n
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_AUTH_FAILED - 3
Info:MAIN:Time 21, idle 191339/s, free 70424, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 22, idle 186418/s, free 69896, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Time 23, idle 185882/s, free 68672, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MAIN:Time 24, idle 176729/s, free 70808, MQTT 0(0), bWifi 1, secondsWithNoPing -1, socks 4/38 
Info:NTP:Seconds since Jan 1 1900 = 3913522337
Info:NTP:Unix time  : 1704537137
Info:NTP:Local Time : 2024/01/06 10:32:17
Info:MAIN:Time 25, idle 189705/s, free 71048, MQTT 0(0), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MQTT:mqtt_host empty, not starting mqtt
Info:MAIN:Time 26, idle 189168/s, free 71048, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 27, idle 188556/s, free 71048, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 28, idle 189802/s, free 71048, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 29, idle 192883/s, free 71048, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 30, idle 190922/s, free 71048, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:GEN:dhcp=0 ip=192.168.1.28 gate=192.168.1.1 mask=255.255.255.0 mac=50:8b:b9:f7:93:99
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-58,ssid=Lazarovi1,bssid=c0:c9:e3:1b:e8:9e,channel=6,cipher_type:Error
Info:MAIN:Time 31, idle 189374/s, free 70832, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 4/38 
Info:MAIN:Time 32, idle 190364/s, free 71048, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 33, idle 189787/s, free 71048, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Time 34, idle 191882/s, free 71048, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38
  • ADVERTISEMENT
  • #123 20893794
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    So you have no TuyaMCU packets with both:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_setBaudRate 115200

    present and with it removed? Make sure to save and reboot after each change.

    But wait, how are you powering your WiFi module? You will NOT get any packets if you artificially power the module.

    Can you do Tuya config extraction so we can check the baud (for the extraction time, please do power module externally)
    Helpful post? Buy me a coffee.
  • #124 20893860
    vikicha
    Level 3  
    Posts: 4
    Thanks a lot for your help and sugestions.
    What i had to do is to remove
    tuyaMcu_setBaudRate 115200
    and to add
    tuyaMcu_defWiFiState 4
    Also i forgot to remove artificial power from WiFi module, this was only way to force it to connect and make changes on configuration.
    Now it sends Temp and Humidity also gets correct Date and time.

    Is there a way to force WiFi not go in to sleep state and to be always powered on? I plan to use it with external adaptor so power consumption is not a problem.
  • #125 20893994
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    auntlydia wrote:
    The problem that a sensor shows zero values happened to me when I forced the device in keeping wifi connection by keeping the button pressed

    Same to me; maybe this "forced" state is only for FW updating and the TuyaMCU stops doing anything to avoid interfering. Also, as the wifi interface is off most of the time to save batteries, is difficult to consult the sensors through the OBK web page. But the reporting to Home Assistant works well always.

    This is a screenshot during "forced" mode:
    Screenshot of the OpenBK7231N interface in forced mode displaying data and options.

    This is my autoexec.bat:
    Code: Javascript
    Log in, to see the code

    vikicha wrote:
    Also i try to flash it on PCB directly but it did not work, i have to desolder it and then the flash is successful.

    I had to cut the RX and TX lines between module and MCU for flashing, and, if powering it from the battery terminals, also bypassing the transistor that controls the power of the module by cutting the GND (Q1). Probably it would be enough to cut/isolate RX. This was because, even feeding the module directly, the MCU would start working, as it received power from the RX/TX lines (see explanation here).

    As it seems like the TuyaMCU stops sending info in "forced" mode, this could be a possibility to avoid cutting RX and TX for flashing... I might give it a try but if someone else does, please report.

    vikicha wrote:
    Is there a way to force WiFi not go in to sleep state and to be always powered on? I plan to use it with external adaptor so power consumption is not a problem.

    Bypassing the aforementioned transistor would work (or simply connecting a wire from the module's GND to the main GND), but the TuyaMCU would still decide when to send the sensor's info (changing this would require modifying its FW, almost impossible to do as we don't even know which MCU is it).

    I'll take also the opportunity to say that the battery level is still medium after two months (although during "forced" mode it goes to "low" after a while, due to the module's power consumption), so pretty good performance in this sense.
  • #126 20918829
    spupetic
    Level 3  
    Posts: 6
    Hello everyone!

    Did you have success with the forced mode? Unfortunately, the Tuya MCU interferes with the CBU, and I cannot flash it with OpenBK, writing stops at approximately 70 percent, and pushing the button does not help either. The module is directly powered. I think this issue takes place when the first flash is unsuccessful somewhy (in my case, instable connection), and the device is not running the original firmware anymore.
  • #127 20918837
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    I am always just desoldering WiFi module or cutting trace to the MCU for the time of the flashing.
    Helpful post? Buy me a coffee.
  • #128 20918966
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    spupetic wrote:
    Did you have success with the forced mode? Unfortunately, the Tuya MCU interferes with the CBU, and I cannot flash it with OpenBK, writing stops at approximately 70 percent, and pushing the button does not help either

    Hello!
    I did some experiments yesterday, and it seems you have to cut also the CEN signal, as the TuyaMCU also controls it and puts it in a low state periodically. Probably, this is what makes flashing stop after some time, something that also happened to me.

    BTW, after these experiments, my module stopped connecting to WiFi :-(; maybe something got corrupted due to one of these interrupted flashings. Will "Erase all" and/or "Restore RF part" in advanced options of BK7231Flasher help with this? I see in the contextual help that "Restore RF part" flashes a random MAC. Is there an option to flash the original MAC again?

    Another last question: What is "Allow backup restore" advanced option for?
  • #129 20919020
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    morgan_flint wrote:

    I did some experiments yesterday, and it seems you have to cut also the CEN signal, as the TuyaMCU also controls it and puts it in a low state periodically. Probably, this is what makes flashing stop after some time, something that also happened to me

    That's a new to me, thank you for sharing it.


    morgan_flint wrote:

    BTW, after these experiments, my module stopped connecting to WiFi :-(; maybe something got corrupted due to one of these interrupted flashings. Will "Erase all" and/or "Restore RF part" in advanced options of BK7231Flasher help with this? I see in the contextual help that "Restore RF part" flashes a random MAC. Is there an option to flash the original MAC again?

    First try just Safe Mode (5 quick power off/on), then maybe try restore RF (you can change back MAC to original in the OBK UI), then erase all... but it's still strange, maybe first check TX2 output to see what crashes?

    morgan_flint wrote:

    Another last question: What is "Allow backup restore" advanced option for?

    Checking this option will show firmware backups in the combobox for selecting target firmware to flash, so you can, just as it says, restore the backup
    Helpful post? Buy me a coffee.
  • #130 20919613
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    p.kaczmarek2 wrote:
    First try just Safe Mode (5 quick power off/on)

    I had tried yesterday with no luck, but tried again today and could restore everything. Thanks!

    morgan_flint wrote:
    vikicha wrote:
    Is there a way to force WiFi not go in to sleep state and to be always powered on? I plan to use it with external adaptor so power consumption is not a problem.

    Bypassing the aforementioned transistor would work (or simply connecting a wire from the module's GND to the main GND)

    I tried this again and seems to work OK. The values of the sensors also show correct values in the OBK's main web page.

    I soldered a thin wire to the module's GND and brought it out through the same hole as the negative battery terminal, so I can connect or disconnect it to main GND without opening the case:
    View of the inside of a casing with an alkaline battery and a thin wire soldered to the module.
  • #131 20920621
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    I've just read this in the Tuya's developer website:
    Code: text Expand Select all Copy to clipboard
    For the MCU that can control the on/off of the module, its TX and RX are idle high in most hardware designs. Therefore, the TX and RX on the MCU are generally configured as push-pull output and input respectively. This will cause the TX and RX to output a low current. When the module is disconnected from the VCC, it cannot be powered off completely due to the low current from the TX and RX on the MCU. This might cause some problems with hardware operation. To resolve the current sink problem without modifying the circuit, in MCU programming, you can disable the serial port when the module is powered off. Configure the TX and RX either as an open-drain output in high impedance or as a low level. If the TX or RX is connected to a pull-up resistor, it must be configured as low level.

    As you can see, it addresses the problem of feeding something (the module in this case) through the serial port, a topic that I've seen commented on in other threads (and in this eevblog's video).

    This made me think of the way this device controls power to the module, with Q1 cutting GND, instead of Vcc, as per Tuya's recommended design (for example, here. Cutting GND instead of Vcc avoids the module being (partially) fed from the serial port, as GND is also the return path for this port, so disconnecting it seems a good idea, as it avoids the need of taking it into account in the software.

    What do you think?
  • #132 20927855
    spupetic
    Level 3  
    Posts: 6
    Can you show me where did you cut the traces, and how you connected them back after flashing?
  • #133 20929216
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    That's a good find, @morgan_flint
    @spupetic how does your PCB look like? You can connect them back by
    1. first, scrap the solder mask from both ends of the cut trace
    2. then, add some solder on it (tin it)
    3. then place a short cut lead of, for example, axial resistor, and solder it on trace
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #134 20929625
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    spupetic wrote:
    Can you show me where did you cut the traces, and how you connected them back after flashing?

    The TX and RX lines can be cut where I'm showing in this picture, anywherein the track connecting pins 9 and 10 to RX1 and TX1 test pads (where, by the way, I soldered the wires for flashing), leaving enough space between them and with the rest of components so it's easy to reconnect them with a thin wire after flashing in the way @p.kaczmarek2 said:
    Close-up of a circuit board with markings and TX and RX signal wires.

    I don't think it's necessary to cut the one that goes to TX1, as this is a signal that comes from the module to the MCU, so the MCU can't interfere.

    As for the CEN signal, it's connected to pin 8, and goes below the IC and probably through the other face of the PCB so, in this case, I preferred to lift slightly the pin and isolate it from the PCB, You can do this by heating it with the soldering iron and pushing it up carefully at the same time with a thin blade.
  • #135 20929671
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    I think there is also a possibility to cut the trace before the TX1/RX1 pad and then just reuse the pad to solder jumper wire directly to CBU. It may be easier to solder to the solder pad and CBU pad than to reconstruct the trace.
    Helpful post? Buy me a coffee.
  • #136 20945212
    spupetic
    Level 3  
    Posts: 6
    Thank you for the information. I have a newer board revision, the CEN, RX and TX are on the other side of the PCB. I did not managed to connect them back without shorting to ground (probably cut too deep and far from the trace), so I used wires to make it work again.

    Close-up of a green printed circuit board with visible traces and gold contacts on the left side. Close-up of a circuit board with attached red wires.
  • ADVERTISEMENT
  • #137 20947613
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Wow! Completely different board!

    They seem to have combined the functions of two ICs in the previous version (U3-MCU and U8-RTC) into one (U3, maybe MCU with RTC).

    U1 is also different between the two versions but seems to have the same function (LCD controller).

    They also seem to have included a switched mode regulator (L1 and surrounding components), while the previous version had only linear regulators, probably to extend battery life.

    Did it work well with OBK + configuration for the previous version?
  • #138 20947665
    spupetic
    Level 3  
    Posts: 6
    Yeah, the configuration seems to work fine. The MCU has no label sadly, so we don't know what it is. I have used it with NiMH batteries, they have lasted 1,5 week or so, now I am testing it with a different set of batteries. The CBU is in deep sleep. When I replaced the battery, OpenBeken was in safe mode, because it had like a 1000+ unsuccessful boot (probably when the battery voltage dropped to a certain level). I fixed it by connecting to the OpenBK AP and clicking exit safe mode, it is tricky because of the short period for Wi-Fi connection, but it can be done.
  • #139 20948309
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    Now that you mention deep sleep, I see that the transistor that cut the GND signal in my version (Q1 in the last photo I posted) has disappeared in this version and that there are two 2.8V test points, one labeled "MCU_2V8" and another one "CBU_2V8". CBU's GND seems to be directly connected to main GND and CBU's Vcc seems to come from the switched mode regulator:
    PCB with visible traces, components, and red wires with connections.

    I guess that MCU power control by the MCU (if it really exists now) is done by controlling the enable pin of the switched mode regulator. If you find some mode of pulling up (or down) this signal then you can force the CBU to be on more time so connecting to it's AP (or flashing OTA) is easier. But, previously, you'd have to confirm what I guessed from the photo.
  • #141 20961998
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    divadiow wrote:
    >>20723152
    https://github.com/OpenBekenIOT/webapp/pull/76

    TH08 should be in model field I guess:
    JSON code snippet describing an electronic product.
    Another little technical note (I know many people do that and I may done that in the past as well, but...):
    JSON code snippet with information about a door/window sensor.
    There is no need to repeat vendor from "vendor" field in the name, as the script will automatically display it anyway.
    Helpful post? Buy me a coffee.
  • #142 20962003
    divadiow
    Level 38  
    Posts: 5065
    Help: 438
    Rate: 893
    oops. will fix
  • #143 20988153
    fjcns
    Level 6  
    Posts: 9
    Close-up of the interior of an electronic device with connected wires.
    Hello. I have a 2022-12-06 version of this device connected directly to a USB charger.

    I was able to flash the device, set the date, time and connect it to the homeassistant via mqtt.
    The temperature and humidity values ​​that appear on the screen update normally but are only updated in the web interface and sent by mqtt only once, when I turn on the device.

    In the web interface the internal temperature and dBm wi-fi signal are updated but the ambient temperature and humidity never update, even waiting for several hours.

    I try
    mqtt_broadcastItemsPerSec 20
    Try add/ remove flags
    without changes

    Does anyone have an idea of what might be wrong?
  • #144 20988432
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    I think that it may not be possible to use battery powered Tuya device with a power connected constantly to the WiFi module because the MCU needs to be able to turn on and off the WiFi module and after each boot the MCU expects the WiFi module to begin the transaction. If the WiFi module is powered on all the time, then the WiFi module is not able to tell when to begin the transaction and the whole deal fails.

    Still, you can try to send the tuyaMcu_sendQueryState command.

    Or maybe you've got wrong dpID set? What does the log say?
    Helpful post? Buy me a coffee.
  • #145 20988482
    fjcns
    Level 6  
    Posts: 9
    with the original firmware the device was always powered by USB and worked normally.
    It was integrated into the Home Assistant with a some local Tuya integration that I'm not sure what it was anymore.

    try the command tuyaMcu_sendQueryState several times, results are

    Info:CMD:[WebApp Cmd 'tuyaMcu_sendQueryState' Result] OK

    one time report this error
    Error:CMD:cmd Info:CMD:[WebApp NOT found (args Cmd 'tuyaMcu_sendQueryState' Result] OK)
    Info:CMD:[WebApp Cmd 'Info:CMD:[WebApp Cmd 'tuyaMcu_sendQueryState' Result] OK' Result] Unknown command

    without change in update temperature


    log
    Attachments:
    • log.txt (9.25 KB) You must be logged in to download this attachment.
  • #146 20988986
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    Quote:
    In the web interface the internal temperature and dBm wi-fi signal are updated but the ambient temperature and humidity never update, even waiting for several hours.


    @fjcns I have different temp/humidity device, but I noticed channels are updated via mqqt only if there is a change.
    So, you can try to add to your autoexec.bat
    addRepeatingEvent sec -1 backlog publishChannel X; publishChannel Y

    sec - publishing interval in seconds
    X - channel number humidity
    Y - channel number temp
    This will force publishing of these channels each [sec] stated in autoexec.bat.

    Please send some feedback

    EDIT: By me it is from TUYA MCU (should not be mistaken with tuya MCU driver). Just MCU reports when there are changes, otherwise - no report

    EDIT1: @p.kaczmarek2 tuyaMcu_sendQueryState works (according to logs), but there is still no publishing of the channel via MQTT if there is no change. The only way I have done it, is due to publishchannel each X seconds.
  • #147 20989131
    fjcns
    Level 6  
    Posts: 9
    I was measuring and the CBU module is always powered on.
    I cut the trace for vcc to CBU and ad a switch to turn the CBU module on and off manually.
    The module worked as expected
    I must have burned the Q1 mosfet while trying to inject power just into the CBU to flash the firmware.

    Thank you for your help and for sharing your knowledge
  • #148 20992155
    bogovik
    Level 5  
    Posts: 8
    Tuya WiFi Temperature & Humidity Sensor TH08B

    Link

    This is the temperature and humidity sensor of the new version of TH08B. I'm going to install a new firmware on it. I think it is fully compatible with the TH08 sensor.
    TH08B-CBU-BL55072A_v1.2 2023-11-06

    Temperature and humidity sensor with display showing 27.9°C and 21% humidity. White temperature and humidity sensor on a gray background. Side view of a white temperature and humidity sensor. Open back of a sensor with three AA batteries. Back panel of TH08B sensor with open battery compartment Interior of the TH08B temperature and humidity sensor with visible electronic components and a circuit board. Close-up of the interior of the Tuya WiFi TH08B temperature and humidity sensor showing the circuit board. Close-up of electronic components on the circuit board of a sensor. Circuit board of Tuya WiFi temperature and humidity sensor TH08B Close-up of a circuit board with the CBU module of the TH08B sensor. Packaging and user manual of the TH08B temperature and humidity sensor.

    Original Firmware bin:
    Original_B...-16-27.bin (2 MB)You must be logged in to download this attachment.

    Added after 16 [minutes]:

    To control the burner of the gas boiler, I use the Sonoff TH Elite THR320D Wi-Fi relay. The entire logic of the relay operation is written in the Berry language built into Tasmota. I plan to install TH08B in the room and use this sensor to monitor the temperature change inside the house. The Sonoff TH Elite THR320D and TH08B must connect via WiFi, without using MQTT. What is the best way to implement this? Should I use Tasmota Device Groups?
  • #149 20992282
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14622
    Help: 655
    Rate: 12639
    I would consider using a SendGet command. OpenBeken can send a GET request to arbitrary IP with a custom payload, for example with the channel value. You use report any measurements that way. We have some samples for that in our docs page:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
    Helpful post? Buy me a coffee.
  • #150 21002026
    bogovik
    Level 5  
    Posts: 8
    I finally managed to flash TH08B. In order for the device firmware to be completed successfully, it was necessary to unsolder two RX and TX contacts on the MCU. Without unsoldering the two RX and TX pins of the MCU, the firmware of the device always failed. Reading the firmware could complete successfully, but writing the firmware always resulted in an error.

    Please help me set up channels. Temperature and humidity values always show 0.

    WiFi Temperature Sensor TH08B interface with temperature and humidity values at 0.0°C and 0.0%.

    My Autoexec.bat
    Code: text Expand Select all Copy to clipboard
    startDriver NTP
startDriver TuyaMCU
startDriver tmSensor
ntp_timeZoneOfs 3
setChannelType 1 temperature_div10
linkTuyaMCUOutputToChannel 1 val 1
setChannelType 2 Humidity
linkTuyaMCUOutputToChannel 2 val 2
linkTuyaMCUOutputToChannel 3 val 3
setChannelType 3 ReadOnlyLowMidHigh
setChannelLabel 3 "Battery Level"
mqtt_broadcastItemsPerSec 20 


    How can I find out the data that Tuya assigns to channels?
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.
Today's popular

FAQ

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

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

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

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

Quick Facts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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