Closed lmagyar closed 1 year ago
Please try the timing tweak option introduced lately. See issue #17944
OK, thank you, I will report a few days later the results.
TLDR:
In case of SI7021 DhtDelay 480,40
works much better than the default 500,30.
SI7021's initial LOW signal is only 60us wide instead of the 80us, and SI7021 is lazy to pull LOW the signal, and this 25us delay is part of the 60us, so there remains only 35us for the really LOW part of the LOW signal. With 40-42us delay we can target the middle of this really LOW signal.
Add rule to reinitialize these values after each restart (DhtDelay values are not stored in the configuration currently):
Rule1 ON System#Init DO DhtDelay 480,40 ENDON
Rule1 1
FYI:
In case of SI7021 the default 500us in DhtDelay 500,30 is too high, I experimented with it, and values 440..520 are OK, so 500us with some CPU delay maybe gets too long too often causing Pin14 timeout waiting for pulse 0
. Maybe 480 as middle ground will work better.
In case of SI7021 the default 30us in DhtDelay 500,30 is too low, sometimes the wire voltage level is not decreased fast enough to LOW again after the initial 500us LOW signal, and (DhtExpectPulse(LOW) != UINT32_MAX) && (DhtExpectPulse(HIGH) != UINT32_MAX)
returns (nearly) immediately and the read data is shifted with 1 bit, usually causing checksum failures, but it seems that sometimes the checksum can be OK, and it can explain why the invalid temperature values are approx. halved, because the bits are shifted.
In case of one of my SI7021 23us delay allways fails, 25us always works, 24us is sometimes works sometimes fails (additional spaces added by me):
DHT: Pin14 cycles (80/80) 58 27 58 32 58 33 58 32 58 33 58 32 58 32 58 110 58 101 58 102 ..
DHT: Pin14 read 01C300E6AA
DHT: Pin14 cycles (80/80) 49 105 58 32 58 33 58 32 59 32 58 32 59 32 58 32 58 109 59 101 ..
DHT: Pin14 checksum failure 80E1807355 =? 54
And why this happens even with the default 30us delay approx. once a day in burst, I don't know, maybe power issues caused by WiFi communication, I think we will never figure that out.
Tested AM2301 for reference: it works correctly, even DhtDelay 2000,5
works (instead of the default DhtDelay 2000,50)
I've added the cycle count of the 80us+80us LOW+HIGH init pulses to the log. commit
Tested 4 approx. 2 years old SI7021:
DhtDelay 480,10
18:04:13.404 DHT: Pin14 cycles (80/80) 0 12, 56 104 52 32 58 33 58 32 58 32 59 32 58 32 58 32 58 109 58 101 ..
18:04:13.406 DHT: Pin14 checksum failure 80E9007C65 =? E5
18:04:17.384 DHT: Pin14 cycles (80/80) 0 12, 56 104 52 32 59 32 58 32 58 33 58 32 58 32 59 31 58 109 59 101 ..
18:04:17.386 DHT: Pin14 checksum failure 80E9007C65 =? E5
18:04:21.371 DHT: Pin14 cycles (80/80) 0 13, 56 104 52 33 58 32 58 32 59 32 58 32 58 33 58 32 58 109 58 101 ..
18:04:21.373 DHT: Pin14 checksum failure 80E9007C65 =? E5
18:04:25.402 DHT: Pin14 cycles (80/80) 0 12, 56 105 52 32 58 32 58 33 58 32 58 32 59 32 58 32 58 109 58 101 ..
18:04:25.404 DHT: Pin14 checksum failure 80E9007C65 =? E5
DhtDelay 480,40
18:03:09.462 DHT: Pin14 cycles (80/80) 29 110, 58 27 52 32 58 32 58 33 58 32 58 32 59 31 59 108 59 101 58 102 ..
18:03:09.465 DHT: Pin14 read 01D200F8CB
18:03:10.391 WIF: Sending Gratuitous ARP
18:03:13.405 DHT: Pin14 cycles (80/80) 29 110, 59 26 52 32 58 32 59 32 58 32 58 33 58 32 58 109 58 101 58 102 ..
18:03:13.407 DHT: Pin14 read 01D200F8CB
18:03:13.649 WIF: Checking connection...
18:03:17.384 DHT: Pin14 cycles (80/80) 30 110, 59 26 52 32 58 32 59 32 58 32 58 33 58 31 59 109 58 101 58 102 ..
18:03:17.386 DHT: Pin14 read 01D200F8CB
Rule1 ON System#Init DO DhtDelay 480,40 ENDON
Rule1 1
I've set up SysLog 4, changed the config on 4 TH10/SI7021, and now I see Pin14 timeout waiting for pulse 0
approx. once in each hour, and Pin14 checksum failure ...
approx. once in each 4 hours. And the errors are not in burst. So this seems to be working.
I will close this issue a few days later if it works stable.
Downgrading to firmware v12.3.1 invalid sensor data issue disappeared but WiFi dropout issue re-emerged. So I think these 2 issues have some common root cause, the WiFi issue seems to be solved with some code change in some WiFi lib, and these default delay tweeks can solve the invalid sensor value issue.
Closing, since the sensor is working with the introduced command for tuning timing of the sensor.
Thank you for your work on this @lmagyar 🙂
I have been trying to get a Sonoff TH10 with SI7021 sensor working and have found it to be very unstable, particularly when trying to use a longer (5m) cable. I need to do some more testing and graphing but changing the timing setting to 480,40
does seem to have improved things.
Is there a reason to not update the default timing values for SI7021 to 480,40
?
https://github.com/arendst/Tasmota/blob/01bb287436d8c87bbeb54f30e48116fa8071d07e/tasmota/tasmota_xsns_sensor/xsns_06_dht_v7.ino#L44
Is the #else
case after #ifdef ESP8266
, for ESP32?
Why are the timings different? Because the code executes faster?
Not sure if someone will see this, but I have a similar issue with an AM2302 (AM2301) on V13.2.
When I soft restart the Tasmota, the AM2301 is timing out on Pin 2 (configured with GPIO2).
But when I remove the +5V pin to the sensor and reconnect, it works fine... until a soft restart. See the logs going from timeout to reading when I "reset" the +5V
19:55:32.488 DHT: Pin2 timeout waiting for pulse 0
19:55:36.455 DHT: Pin2 cycles (0/80) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ..
19:55:36.457 DHT: Pin2 timeout waiting for pulse 0
19:55:40.406 DHT: Pin2 cycles (80/80) 68 35 68 35 74 35 74 35 75 35 74 35 74 35 74 100 93 102 74 102 ..
19:55:40.408 DHT: Pin2 read 01E700CAB2
I have tried many dhtdelay. Unsure it's related.
Ideas?
I've restarted my Sonoff TH16 with AM2301, no problem.
The Pin2 cycles (0/80) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ..
means it wasn't able to read anything. In my case, when there were timing issues, it was able to read "something", so there were non-zero values, usually shifted with 1 bit (due to the bad timing). So my guess is that constant zero means there is no communication at all. I think the pin configuration gets wrong somehow after the soft reset.
What is your hardware? ESP8266? Can you plug this sensor on to another device with different CPU (eg. ESP8266 vs ESP32)? I'm just guessing here.
Yes, it's on an ESP8266EX. There's this old discussion : https://github.com/arendst/Tasmota/discussions/15631 It's a similar issue. I'm wondering now if GPIO2 is used somehow at boot time.
UPDATE: I think this is the issue, this GPIO2 on this board is connected to an ESP-12F which is used as UART1_TXD.
At power-on, the AM2301 works At soft restart, it does not Unsure if this is solvable by a new firmware or it's in the CORE?
UPDATE2: I tried to put the AM2301 on GPIO3 (RXT), same issue, does not work after reset but OK after a disconnect/reconnect of +5V.
There's also this discussion: https://github.com/arendst/Tasmota/discussions/17181 That talks about a similar issue.
I'm wondering if a new firmware that would simply delay for 1 sec the activation of the AM2301 code on the configured pin would solve the issue?
Yes, GPIO 0, 1, 2, 3, 15, 16 better to avoid, I use GPIO 4, 5, 12, 13, 14 until I run out of pins, then I start to read the specs.
UPDATE: some links: https://randomnerdtutorials.com/esp8266-pinout-reference-gpios https://rabbithole.wwwdotorg.org/2017/03/28/esp8266-gpio.html
Yesterday I tested the new Sonoff TH Origin THR316, which uses ESP32-D0WD-V3 chip and a modified SI7021 called THS01, and it is unstable with the default DhtDelay settings: after leaving it alone for 10-20 minutes (not using it's UI), it starts to read null temperature & humidity values intermittently.
Experimented with it, and the default DhtDelay 400, 30 values are wrong again.
The 400ms LOW pulse going out to the sensor is extremely low, with 390 it fails 100% of the time, with 395 fails 50%, with 400 fails after a few minutes, so I started to use my solution above, the 480. It works flawlessly in the past day.
Good news is that this THS01 is really fast to reply with a LOW signal, even with single digit or even 0 wait value instead of the default 30 works. It starts to fail with 80, so my previous solution for this (40) also works (at least do not break anything).
So in case of SI7021 or THS01 and ESP8266 or ESP32, the below values and workaround are still better than the current default:
Rule1 ON System#Init DO DhtDelay 480,40 ENDON
Rule1 1
With the default 400,30:
With 480, 40:
PROBLEM DESCRIPTION
After update to v12.4.0 Sonoff devices started to randomly report invalid values. This seems to me some communication failure with the sensor. With previous versions (v9.x .. v12.3.1) I saw some WiFi disconnect issues (approx. once a day, automatic restart, not a serious problem), though I don't see this WiFi disconnects now, but I see false temperature values, so my guess is that maybe some WiFi communication issues/delays causes now some sensor communication issues instead of drop of WiFi connection.
I've tried
reset 3
+ power cycle, unplug-plug the sensors, multiple builds, no help. Multiple devices have this issue, though not all of them (currently). I will downgrade to v12.3.1 to see if the issue disappears.This happens randomly, so I need help how to further investigate, eg. get Tasmota console log stored for 24h.
Strange, that the reported values (not the averaged values on the above charts) are approx. the half of the real temperature or approx. minus half of the temperature, see the reported values from the database:
REQUESTED INFORMATION
Backlog Template; Module; GPIO 255
:Backlog Rule1; Rule2; Rule3
:Status 0
:weblog
to 4 and then, when you experience your issue, provide the output of the Console log: