[BK7231N] [CB3S] [AHT20] TH01 Generic Temperature and Humidity Sensor Teardown

Question

Teardown of TH01 Generic Temperature and Humidity Sensor
Firmware dump attached.

Managed to flash OpenBK7231N firmware but I'm now stuck.
WiFi settings set. Running off 3V3 and bypassing the ground transistor I can access the WebUI to be able to setup.

Any ideas what needs adding to autoexec.bat other than?

startDriver TuyaMCU
startDriver tmSensor

Happy to try and dump other info if needed.

p.kaczmarek2 · Accepted Answer

I can see something strange on this graph, but what do you mean by "calculated down"? Is it just a "0" value sent or something else?

Btw you don't need thaT:


     value_template: "{{ (value | float * 0.1 | round(1)) }}"

if you set this flag:

You can use either one of this options, but not two at them together.

p.kaczmarek2 · Accepted Answer

The OBK battery powered devices driver (TuyaMCU) has been updated in a meantime, also a quick connect and static IP were introduces, the battery devices will last longer (much longer) with latest OBK builds.

p.kaczmarek2 · Answer

Hello,
doing a RX/TX communication of TuyaMCU dump with original firmware could help, but you can also use already OpenBeken and just check in Web App Logs to see what kind of dpIDs and values are sent to the WiFi module from MCU. Please disconnect 3.3V bypass, keep Web App log open and wait until WiFI module is powered on by the MCU and then copy logs content to see what is being reported over UART>

anthonythomas · Answer

Sorry, forgot to attach the firmware dump

anthonythomas · Answer

This is what I've got so far

Info:TuyaMCU:TUYAMCU received: 55 AA 00 01 00 24 7B 22 70 22 3A 22 6C 66 33 36 79 35 6E 77 62 38 6A 6B 78 77 67 67 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 99 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"lf36y5nwb8jkxwgg","v":"1.0.0"}
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:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0F 00 01 01 01 01 01 01 01 02 00 04 00 00 00 C8 EB 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 22 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 200
Info:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0F 00 01 01 01 01 01 01 02 02 00 04 00 00 00 49 6D 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 22 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 73
Info:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0C 00 03 03 03 03 03 03 03 04 00 01 00 2D 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 19 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 3, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 1 byte: 
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:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 16

[/code]

p.kaczmarek2 · Answer

Not bad. It seems that dpID 1 is a raw value 200, which is 20.0C (you have to divide it by 10) and that dpID 2 is 73 which is most likely 73% humidity.

I don't know what is dpID 3, which is an enum type.

Do you know how to write the autoexec.bat config needed to map those dpIDs to the OBK channels and later publish them via MQTT?

anthonythomas · Answer

And some more

Info:TuyaMCU:TUYAMCU received: 55 AA 00 01 00 24 7B 22 70 22 3A 22 6C 66 33 36 79 35 6E 77 62 38 6A 6B 78 77 67 67 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 99 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"lf36y5nwb8jkxwgg","v":"1.0.0"}
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:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0F 00 01 01 01 01 01 01 01 02 00 04 00 00 00 D5 F8 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 22 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 213
Info:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0F 00 01 01 01 01 01 01 02 02 00 04 00 00 00 4E 72 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 22 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 78
Info:TuyaMCU:TUYAMCU received: 55 AA 00 08 00 0C 00 03 03 03 03 03 03 03 04 00 01 01 2E 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 8 (QueryState) with 19 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 3, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 1 byte: 
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:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 16

Added after 16 [minutes]:

I have them mapped
Just need to figure out the MQTT part

startDriver TuyaMCU
startDriver tmSensor
setChannelType 1 temperature_div10
linkTuyaMCUOutputToChannel 1 val 1
setChannelType 2 Humidity
linkTuyaMCUOutputToChannel 2 val 2

p.kaczmarek2 · Answer

You might also want to select this flag: Then check in readme to see how are channel values published. Also check publish all mcu channels flag and maybe publish self state on connect.

anthonythomas · Answer

I've added the following to configuration.yaml but don't see the sensor in the MQTT devices.

mqtt:
 sensor:
   - unique_id: OpenBK7231N_1F70E60F_TH_1_T     
     name: "OpenBK7231N_1F70E60F_TH_1_T"
     state_topic: "obk1F70E60F/1/get"
     unit_of_measurement: 'C'
     value_template: "{{ (value | float * 0.1 | round(1)) }}"
     
   - unique_id: OpenBK7231N_1F70E60F_TH_1_H     
     name: "OpenBK7231N_1F70E60F_TH_1_H"
     state_topic: "obk1F70E60F/2/get"
     unit_of_measurement: '%'
     value_template: "{{ value }}"

Added after 39 [minutes]:

It works - I was expecting to see the device published in the MQTT integration menus but it isn't.
Searched for the entity and it is there. Just got an issue that since restart the published data is being calculated down!
Will adjust the MQTT template.

anthonythomas · Answer

The drop in the graph looks to be when I enabled Flag 33 - so that makes sense.
MQTT was working fine before that when I didn't realise.

I've removed the calculation from the MQTT template and it's correct again.

Added after 18 [minutes]:

I'm guessing dpID 3 is relating to the battery state/level.

I have another of the same sensor still running through Tuya and the diagnostics from Home Assistant gives the following details.
Obviously low/middle/high doesn't tell us much, but better than nothing.

      "battery_state": {
        "type": "Enum",
        "value": {
          "range": [
            "low",
            "middle",
            "high"
          ]
        }

p.kaczmarek2 · Answer

I think it matches what I said in the Door Sensor topic:

grericht · Answer

did you get it to work? have the same sensor and like to flash openbk

p.kaczmarek2 · Answer

Do you mean humidity sensor? Yes, here is description in polish (use google translate): Here will be soon english version:

grericht · Answer

but there is no tutorial for flashing? only configuration?!

p.kaczmarek2 · Answer

Well, you flash it as usual, it's the same for all devices... well, maybe except, in this case you also have to cut temporarily RX/TX traces because TuyaMCU may interfere with the procedure. Or desolder WiFi module, or desolder TuyaMCU.
Here is our flasher:
https://github.com/openshwprojects/BK7231GUIFlashTool
Here is a generic flashing guides playlist:
https://www.youtube.com/playlist?list=PLzbXEc2ebpH0CZDbczAXT94BuSGrd_GoM

anthonythomas · Answer

I used the standard flashing procedure.Unsurprisingly the battery life isn't great, which seems similar for other WiFi sensors where you've got more frequent updates.Much prefer zigbee for these.

anthonythomas · Answer

Thanks. I'll update and try

grericht · Answer

Hi,I try some options to flash the TH01. But nothing works. I don't get a connection for flashing with BK7231 GUI Flash Tool.Do I have to desolder or to bridge something?I try rx2 tx2 bat+ and - and bridged ground from chipand I try to connect tx rx + and - directly from the chipthe th01 every time goes in slow blinking mode.for tasmota I had to bridge pin g01 and reset for boot mode. I can't find something to do for boot mode. only switch power off and on during flash. I have a separate 3.3v power supply. I also try to get in flash mode by bridging cen pin. but never get it work.

p.kaczmarek2 · Answer

@gerricht, this is TuyaMCU device, the BK7231 module is connected on TX1 and RX1 to the microcontroller on the board. It's not possible to flash it in this configuration. You have to sever the connection. You have about 3 options:
- cut the traces and reconstruct them
- desolder BK7231 module for the time of flashing
- desolder microcontroller in SOIC case for the time of flashing.
Then you have to flash, reconnect them again, and configure tmSensor driver, but take care - that MCU has transistor and it controls power of WiFi module!
Read more: https://www.elektroda.com/rtvforum/topic3914412.html

grericht · Answer

Thank you. I don't understand everything.

1. Can I desolder the CB3's plate, flash it, and then reconnect it?

2. Do I need to desolder the marked microcontroller in SOIC case for the time of flashing and then reconnect it?

3. Can you tell me which traces to cut and then reconnect after flashing?

Anthonythomas did none of these options?! He only connected +, -, RX2, TX2, and GND pins: https://obrazki.elektroda.pl/4823984400_1680177825.png. Why does this work for him and not for me? What is the difference?

p.kaczmarek2 · Answer

I don't know this particular device, but usually TuyaMCU devices need to be disconnected from the MCU before flashing. I don't know what exactly the thread author did.

First of all, I would suggest you check if the TX2 and RX2 pads on the board are connected to RX1 and TX1 of the WiFi module. If so, then they are the UART port used for both flashing and TuyaMCU communication.

I am asking because there is also a UART2 port, also called TX2/RX2, on the WiFi module, but that's a separate thing. So the naming is confusing here.

Which traces to cut in option three, you ask? Well, the TuyaMCU traces. The UART port connection between the SOIC microcontroller and the TX1/RX1 of the WiFi module.

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.

grericht · Answer

Thank you.Red and green are connected. I think it is possible for me to cut and then reconnect at the yellow traces.Maybe it would be easier to desolder, for example, the orange part and do power supply at the pins of CB3's plate. But is this not possible?

p.kaczmarek2 · Answer

Why do you want to desolder the part in the orange circle, the Q1, the MOSFET that is controlled via MCU to turn on and off the CB3S power? It is not the problem.

Now I think that maybe your issue is that you didn't connect 3.3V directly to CB3S. I can see that in your picture. Maybe no desoldering is needed.

Please try connecting 3.3V directly to CB3S VDD pin. And then attempt flashing again. MAYBE it will work when the microcontroller in SOIC is sleeping. I am not sure. Attempt several times. If flashing still fails, you have to sever the UART connection.

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.

grericht · Answer

I also tried to connect 3.3V directly to CB3S, but same problem.
Now I cut the RX and TX traces and got connection, but it stops. Why? Not same time every try but nearly, and with all baud rates.

I tried 2 serial-USB adapters and 2 types of power supply. Every time same error.

Added after 3 [minutes]:

Now it goes to 100%.
"CRC matches 0xA4183270!
Writing file data to chip success."
Change was to unbridge GRD from USB-serial to ground from power supply. Or luck.

EDIT02: And now flashing stops again. Don't know what the problem is.

p.kaczmarek2 · Answer

Hmm, strange, just to be sure, can you also check with hid_download_py Python tool? Please see this video for a guide and console command:
https://www.youtube.com/watch?v=PKkiqDNFIx8
I am asking because there have been some rare reports regarding GUI flasher issues on certain environments.

grericht · Answer

I also have a thermo-hygrometer with a cbu chip. I tested flashing this chip and got the same problem: "The beginning of buffer in UART contains ... data."

I will test with Python maybe next week. Actually, I have no Linux.

p.kaczmarek2 · Answer

It can work on Windows. I have used it on Windows.

grericht · Answer

Ok. Will try this next.I now have reached 2 different Tuya thermo/hygrometers with Open Beken flashed.1 I have resoldered the cut traces and on the other I didn't up to now.When I power the devices there is the Open Beken net, but on both I only get a short connection and can't reach 192.168.4.1. Connection will be lost very shortly.Is this because of the energy-saving mode of these devices?Did I have to resolder both?How can I get the configuration on the devices?

p.kaczmarek2 · Answer

Well, @grericht, I think you would benefit a lot from reading related topics.
https://www.elektroda.com/rtvforum/topic3914412.html
Btw, in this topic, isn't it your device?
https://www.elektroda.pl/rtvforum/topic3975583.html
I was working on it remotely, with @DeDaMrAz

But again, yes, you are right, as I said, the MCU (in SOIC case) controls power of WiFi module via that tiny transistor on the board. You have to either connect power to CB3S directly for the time of the configuration or you can do a serious circuit modification, remove MCU permanently and connect AHT20 directly to WiFi module... and use our deep sleep feature.

Now I would recommend you to consult both topics linked above and then we can try to help you more, maybe @DeDaMrAz can also say something as he has this device, I never had it so far, I only helped him to get it running.

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.

[BK7231N] [CB3S] [AHT20] TH01 Generic Temperature and Humidity Sensor Teardown

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary