[BK7231N/CBU] Tuya TH01? Generic Wi-Fi Temperature & Humidity Sensor [CHT8310]

Question

I see some variations of this around on the forums, but I don't think I see this one with a Sensylink CHT8310 humidity and temperature sensor. I'm new to flashing these devices so I've been on a bit of a buying spree, wanting to play with all the IoT variations. AliExpress has fuelled quite a...

p.kaczmarek2 · Accepted Answer

Thanks to the hard work of our contributor, we have now a CHT8310 support in CHT8305 driver.

You just need to enable CHT8305 driver, it should handle new kind of sensor as well.

Please update and try.

Also, when enabling, watch out for message in log:


Info:SENSOR:DRV_CHT8305_init: ID: 59 59 8215

Let me know what kind of ID do you have there.

p.kaczmarek2 · Answer

The CHT8310 datasheet link requires a login. Do you have an already downloaded pdf version of that datasheet?

divadiow · Answer

Ah, seems reg is free and that's all that's needed. Attached.

p.kaczmarek2 · Answer

Your datasheet is incomplete. It has no protocol details. Luckily it has turned out that I saw someone mentoning it on Github already, so I have a full datasheet. See attachment:
CHT8310.Ad...230407.pdf Download (3.98 MB)
I may try to add support for this chip, would you help with testing?

divadiow · Answer

Ah, OK, sure. I'm not sure I have the ability/understanding (yet) of what to do next with the datasheets. I'll review that GitHub to see if I can work it out.

Added after 3 [minutes]:

>>20851834

Sorry, yes. I will help with testing, of course!

kuncy7 · Answer

I have exactly the same sensor:

I tried using cloudcutter, but this is what I end up with:


Scanning for open Tuya SmartLife AP
.............................................
Found access point name: "SmartLife-13F8", trying to connect...
Device 'wlan0' successfully activated with '744f9eab-37e5-4ba0-8952-dd828cd704d7'.
Connected to access point.
Waiting 1 sec to allow device to set itself up...
Running initial exploit toolchain...
Exploit run, saved device config too!
output=/work/configured-devices/PuHhevM5TMz0.deviceconfig
Saved device config in /work/configured-devices/PuHhevM5TMz0.deviceconfig

================================================================================
Power cycle and place your device in AP (slow blink) mode again.  This can usually be accomplished by either:
Power cycling off/on - 3 times and wait for the device to fast-blink, then repeat 3 more times.  Some devices need 4 or 5 times on each side of the pause
Long press the power/reset button on the device until it starts fast-blinking, then releasing, and then holding the power/reset button again until the device starts slow-blinking.
See https://support.tuya.com/en/help/_detail/K9hut3w10nby8 for more information.
================================================================================

Scanning for open Tuya SmartLife AP
..............
Found access point name: "SmartLife-13F8", trying to connect...
Device 'wlan0' successfully activated with '744f9eab-37e5-4ba0-8952-dd828cd704d7'.
Connected to access point.
================================================================================
[!] The profile you selected did not result in a successful exploit.
================================================================================

Is there a chance for a profile for this sensor?

divadiow · Answer

I think that means it's running a patched firmware. I've got two mini 16a aubess switches that did that today with firmware 1.3.10, which is on the known patches firmware list. What firmware is your device?

kuncy7 · Answer

Exactly like yours:

kikokbg · Answer

Hi all, is there any update regarding flashing OpenBK firmware to this device? I have exactly the same sensor, so I can help with testing if needed.

Baustromverteiler · Answer

So I already flashed OpenBK successfully to the device and would be happy to help testing a cht8310 driver. If it helps, also see the discussion here on GitHub for further information:

kikokbg · Answer

Can you please share how you have flashed the OpenBK firmware?

Baustromverteiler · Answer

I used the GUI Flasher: Type is BK7231N, selected Download latest Firmware from Web connected the VCC, GND, TX, RX to a USB to Serial adapter (TX on the Sensor to RX on the USB-serial Interface, RX on the Sensor to TX on the serial interface) Then I clicked on Do Firmware write and shortly disconnected / reconnected the positive lead to the serial interface and it flashed just fine. If you have trouble flashing despite everything seems fine try another serial interface, I first tried it with a CH340 interface and the flash wouldn't start, tried another interface and it worked just fine with the same settings.

kikokbg · Answer

Thank you for your detailed explanation! 👍

divadiow · Answer

Yes. Excellent stuff. I will try again and report when I'm home on the 27th.

Baustromverteiler · Answer

Now that's great news, thanks a lot to artin961 :)Here's the Log with the Sensor-ID:Info: SENSOR: DRV_CHT8305_init: ID: 59 59 8215

p.kaczmarek2 · Answer

So, @Baustromverteiler , is the sensor working for you?

Baustromverteiler · Answer

Works just fine, need to calibrate it, temp is probably a degree too high

artin961 · Answer

Hello all,Just as a follow-up, this is the autoexec.bat I used to make it sleep and not drain the battery as fast. A delay of 50 seconds is enough to connect and send data to MQTT as well as to be able to debug after restarting it. 900 seconds can be increased to preserve the battery even more. It would be great if a timer sleep with button wakeup gets implemented in the future to be able to wake it manually from the button. As can be observed in the screenshots below, it wakes and sends data to HA just fine.Code: text Expand Select all Copy to clipboard PowerSave 1 delay_ms 50000 DeepSleep 900 Hope you find this post useful.Regards.

p.kaczmarek2 · Answer

@artin961 I would suggest to change this autoexec to respect variation in the MQTT connection time. Please consider something like this:


startDriver NTP
startDriver SSDP

// now wait for MQTT
waitFor MQTTState 1
// extra delay, to be sure
delay_s 1
publish myVariable 2022
// you can publish again just to be sure
// delay_s 1
// publish myVariable 2022

// if you have a battery powered device, you can now uncomment this line:
// Deep sleep (shut down everything) and reboot automatically after 600 seconds
//DeepSleep 600

Please see our autoexec.bat examples here:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
Search for "waitFor" to see more samples.

divadiow · Answer

Curious, mine has 8304 in the log, not 8305.

Info:SENSOR:DRV_CHT8304_readEnv: Temperature:125.000000C Humidity:100.000000%

Info:SENSOR:DRV_CHT8305_init: ID: FF FF FFFF
Error:CMD:command with name CHT_Calibrate already exists!
Error:CMD:command with name CHT_Cycle already exists!
Info:MAIN:Started cht8305.

My startup command is

backlog PowerSave 1; startDriver SSDP; startDriver Wemo; startDriver NTP; startDriver CHT8305

~~What flags have you set @Baustromverteiler and what channel/pin settings?~~

Added after 12 [minutes]:

Silly me https://github.com/openshwprojects/OpenBK7231T_App/issues/983#issue-1997790886

Info:SENSOR:DRV_CHT8305_init: ID: 59 59 8215

Added after 9 [hours] 48 [minutes]:

OBK template for this variant

Log in, to see the code

kikokbg · Answer

I have successfully flashed the OpenBK firmware, but I'm observing a strange behavior in the integration with Home Assistant via MQTT. In Home assistant the values of the [b]Temperature[/b] and the [b]Humidity[/b] keeps changing every second.

Here is one example:

I think that here the [b]Humidity[/b] show the correct value of the humidity in the room while the [b]Temperature[/b] show the value of the humidity in the room / 10.

after a second those values are changed to the following:

I think that here the [b]Temperature[/b] is showing the correct value of the temperature in the room while the [b]Humidity[/b] is showing the value of the temperature in the room * 10.

Here are my PIN settings:

The index page shows the correct values for [b]Temperature[/b] and [b]Humidity[/b] and there they are not changing like in HA.

Any suggestions where the problem might be?

And additionally - what should I do to solve the warning message, which is visible on the index page?

p.kaczmarek2 · Answer

This warning tells you what's wrong. You need to configure second channel for SDA/DAT pin to be other channel than first: That's done in Configure Module...

kikokbg · Answer

Thank you very much! The correct configuration has solved the issue.

hojnikb · Answer

Did anyone figure out which pins are used to measure battery level?

p.kaczmarek2 · Answer

Well, we need to figure BAT_Relay pin, because ADC is always on P23 so that we can already know without checking. PS: Search for BAT_ADC here: Maybe one of the templates can match?

hojnikb · Answer

Thank you!Guess it's a trial and error game then to find the correct one Is the channel selection on each the bat_adc and bat_relay pin also important?

p.kaczmarek2 · Answer

Just choose an unused one so it does not interfere with anything

artin961 · Answer

Hello,For me, I think the BAT_Relay was P8. But on different modules, it may be elsewhere. I used a multimeter to measure without the device being powered. Best to look for a group of 4 resistors and a MOSFET. The MOSFET has its gate pulled down to ground with the first resistor (10k typically). There should be another resistor from the gate to the pin, you need a smaller value like 1k or 4.7k. The last 2 resistors should be connected in series, their values should be the same. The midpoint goes to ADC pin 23, one side to the drain of the MOSFET and the other to 3v.The idea is to lower the voltage being measured to be in the range of the ADC and below the main power rail. This is accomplished using a voltage divider, making it half of the battery voltage. If you connect the divider permanently to the battery, it will take a small amount of current all the time, so the MOSFET is used to connect the divider just to take a measurement.On some devices, there is also a switching power supply, a boost converter that makes 3.3v from the batteries. If I remember correctly, on my sensor, it was always enabled, but on a door sensor, I saw it connected to a pin so the MCU can boost its voltage. I'm not sure how to properly handle that. I made it always high pin for now, hope it doesn't drain the battery much.

hojnikb · Answer

Does anyone else experience very poor precision on lower temps? I've noticed that when temps drop below 10°C, its accuracy drops off even further. While at ~20-25°C, it's usually around 2°C off (easily fixed by offsetting), by 10 or even 0°C, it's easily off by ~5°C or more (shows higher than it actually is).

Any way to calibrate or something? Or is CHT8310 just that inaccurate.

[BK7231N/CBU] Tuya TH01? Generic Wi-Fi Temperature & Humidity Sensor [CHT8310]

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