THR316 with THS-01 showing null temperature and humidity #17944
Comments
|
Can you open the sensor and check if there is still a SI7021 inside? |
|
I bought a set of 5 sensors, have tried multiple. None of them work. Here's a picture of its insides:
|
|
That is not an SI7021. Older Sonoff Sensor with an SI7021 |
|
The problem is the MCU in between the sensor and the protocol it implements (some kind of one wire as the si7021 is natively i2c) Whatever is the real sensor chip, the protocol could be using the same as the original Sonoff sensor, or not. If there is a doubt, Only solution to know is to spy the protocol with original Sonoff firmware and a logic analyser |
Jason2866
added
the
Requires more research (devs)
|
I have the same THS-01 and it used to work until I openend the unit to find out if it was the same unit. Now it occasionally reports Timing is critical and looking at the source I did some timing tweaking before. |
|
BTW you might want to try at a lower CPU frequency with command |
|
Technically, the sensor in the newer probe looks a lot like HDC1080, but that does not matter to Tasmota, due to that MCU transforming I2C to a special Sonoff one-wire protocol, which in Tasmota is configured as "SI7021". |
Did this, but it had no effect. |
|
Make sure the connector is inserted firmly. Try to measure resistance of the wires end to end for correct connection. Chk colors of wires in connector: red,white, empty,black |
- Change Dht driver from v6 to v7 - Add command ``DhtDelay<sensor> <high_delay>,<low_delay>`` to allow user control over high and low delay in microseconds (#17944)
|
Pls try latest driver (available as pre-compiled dev binary in an hour). It adds more debugging ( My THS-01 now runs fine on CPUFrequency 160MHz with non-persistent command |
Jason2866
added
awaiting feedback
|
Thanks for the update! I have installed it and issued the DhtDelay command. Here's the debug output: As for your earlier question about the wires in the connector, they match up with what you said:
Pressed the connector firmly, but to no avail it seems. I got a multi meter coming in later today then I can measure the wire resistance for you. |
|
The opportunity you get with the new |
|
Used the multimeter to measure connection between the VCC / DATA / GND pins on the THS-01 PCB and the THR316 PCB and they seem just fine (resistance drops to 0 when i push the multimeter on the connecting pins). I tried DhtDelay up to Do I need some kind of logic analyzer to snoop on what's going over the data wire to figure this out? I have an old DHT-11 sensor lying around, I could try connecting that to the RJ11 and see what happens? |
|
Extreme values like 10000 is a pretty bad starting point in case of trying to make tweaks, where you have a much better starting point in what arendst used. |
|
Okay, I have tried a lot of different settings close to the initial settings of arendst. Tested on CpuFrequency 80 and 160, High cycle timeout 300-700 in steps of 50 and low cycle timeout 20-70 in steps of 10 - and every possible combination therein. I made a small script to cycle through all the options to make sure I tested them all properly and captured the log for each. #!/bin/bash
CPUFREQ=(80 160)
DHTDELAYHIGH=(300 350 400 450 500 550 600 650 700 750)
DHTDELAYLOW=(20 30 40 50 60 70)
for freq in ${CPUFREQ[@]}; do
echo "CpuFrequency $freq"
curl "http://192.168.1.202/cm?cmnd=CpuFrequency%20$freq"
sleep 1
for high in ${DHTDELAYHIGH[@]}; do
for low in ${DHTDELAYLOW[@]}; do
echo "CpuFrequency $freq - DhtDelay $high,$low" | tee -a "DhtDelay.log"
curl "http://192.168.1.202/cm?cmnd=DhtDelay%20$high%2C$low"
sleep 12
curl -s http://192.168.1.202/cs?c2=0 | tail -n 30 | grep -A 900 "DhtDelay1\":\[$high,$low" | tee -a "DhtDelay.log"
done
done
doneThe fact that the cycles printout remains all zeroes on every setting makes me think that this sensor uses a different protocol all together? I ordered a very basic logic analyzer to try and make sense of what's going on. I have a couple more THR316s with the original firmware on it, so I'll try to capture what it is doing in the stock firmware when talking to the sensor. |
|
Let me chk your script against mine...... First part of the test (at 80MHz): So in my case on 80MHz DhtDelay 400,20 to DhtDelay 450,70 work fine. Continuing on 160MHz.... At 160MHz the values are different and the range is a lot smaller: So in my case at 160Hz DhtDelay 450,20 to DhtDelay 450,70 work fine. See final log. |
|
I wonder if you need a logic analyzer. Something is wrong hardware wise. What you could do is configure GPIO25 as a First measure the voltage on two of the four flash connector pins you'll see in your picture above on the left called J2. The top hole is Gnd. The bottom hole is 3V3. Then find a way to measure the signal on the white wire while toggling relay3. |
|
Okay, I measured using a multimeter between these points on the PCB (bottom view):
|
|
So obviously you're missing the power signal. Let's chk our templates. This is mine: Chk your GPIO27 in configure template menu option. It should be |
|
I have plugged the sensor into a THR316 running on stock firmware, it shows proper 3v3 between 1 and 2. I will check the template |
|
Template (from here ) : GPIO Template settings:
|
|
Ah. You're having a THR316 without the D(isplay). In that case the template looks fine as I expect they didn't change GPIO usage between THR316 and THR316D. |
|
When I apply your template, the voltage on the THS-01 also isn't 3V3. I'm going to try and flash the unit I confirmed 3V3 on the sensor with Tasmota to see if perhaps it's something faulty in the THR316 unit I have flashed with Tasmota? |
|
OK. But make a backup of the current firmware first so you can go back if neded. |
|
Made backup, flashed the other THR316. Now works with the latest dev firmware without any tweaks to the DhtDelay or CpuFreq. I will flash the other THR316s i have. Looks like the one unit I was testing with is defect then? |
|
I guess so. Do you hear the relay when you push the button on the device? |
Jason2866
added
good tip
|
I have a TH16 with a sensor that has a 4C TRRS Plug. I have not popped it open. I am wondering if it is a good idea to adapt it for a test to see if this clears up the timeout issue? Thoughts? is it worth trying or are we close to a resolution? Thx |
|
The latest fixes (dhtdelay) IS the solution. From three years experience we now know there is no final timing solution for these crappy sensors. The latest addition allows all users to tweak their sensors to make them functional. |
|
Closing since the issue is solved. |
|
That fixed my issue. Thank you very much!!!!!!!!! |
|
Is there a way to make dhtdelay persistent? After restarting HA several times while working on an unrelated sensor I realized that my thermostat stopped working. After some poking around I discovered that dhtdelay had reverted back to the original setting of 400,30. I had it set at 500,40 which was the only setting that would work. |
|
You can create a boot rule to set it back at each restart: |
|
Instead of a rule, it would be a bit simpler to include such commands in a file |
|
Wow, that is exactly what I needed @barbudor . Could not have been easier. Working better then ever. I really appreciate the help. Hopefully this will help somebody else that is a newbie like me. |
|
FWIW, just found this bug after having the same issue, on original versions (from years ago) 2xTH10 and 1xTH16, all 3 with SI7021 sensors. I'm getting both random NULL and random 100% Humidity along with roughly half temp, in 12.4.0. Is the script in the link below what I'm supposed to run from openhab, to find parameters? |
|
That bash script is just an example to try out various Defaults are |
|
Thanks for the quick reply - I got the DhtDelay script working ok the output seems indeterminate and sporadic. i.e. not always getting temp values (bad or good) back. |
|
And that bash script is not for getting a temperature, it is only for experimenting with |
|
Ahh got it. Thought it was strange. |
Did you manage to solve it. My devices was working fine on old v 11 till i updated to latest 12.5.0. Randomly 2 sensors i have will go to 100% and null. |
|
There is no script which you are "supposed to run", that is merely a helper script to zone in on what |
No sorry. I'm putting this on the back-burner as 12.3.1 works perfectly and never has these issues. I suggest the same for you unless you want to delve in to dark arts and have the time. It's an easy downgrade. |
FYI, V13.0.0 on one of my TH10's no longer has the issue. I can only assume the bug was fixed at some point. EDIT V13.1.0 has re-introduced the issue. Rolling back to 13.0.0 corrects it. |
|
Has anyone tried to dump the firmware from the Onbright microcontroller (8R08A1)? I have written a tool that uses Arduino to read/write to these chips: It works for me and others report it working but it can be a little finicky. I will also need to expand the sketch to make reading the entire fuse and flash range easier so feel free to open an issue on that project page. |
|
Hello, I flash with the last firmware version, but the wireless signal is not stable, do you recommend other version? Regards. |
PROBLEM DESCRIPTION
Flashed latest Tasmota32 onto THR316 with an attached THS01 sensor. Configured
GPIO25asSI7021.Temperature and humidity readings show
nullConsole keeps showing:
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
esptoolfirst and then OTABacklog Template; Module; GPIO 255:Backlog Rule1; Rule2; Rule3:Status 0:weblogto 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Steps to reproduce the behavior:
Set GPIO25 to SI7021, attach THS-01 sensor, restart.
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
Proper temperature values being shown
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: