arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.19k stars 4.81k forks source link

v12.4.0 on Sonoff TH10 with SI7021 randomly reports false temperature and humidity values #17988

Closed lmagyar closed 1 year ago

lmagyar commented 1 year ago

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.

Tasmota_temp

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:

DB_temp_1 DB_temp_2

REQUESTED INFORMATION



### TO REPRODUCE
_Steps to reproduce the behavior:_

### EXPECTED BEHAVIOUR
_A clear and concise description of what you expected to happen._

### SCREENSHOTS

### ADDITIONAL CONTEXT
_Add any other context about the problem here._

**(Please, remember to close the issue when the problem has been addressed)**
Jason2866 commented 1 year ago

Please try the timing tweak option introduced lately. See issue #17944

lmagyar commented 1 year ago

OK, thank you, I will report a few days later the results.

lmagyar commented 1 year ago

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:

Identified problem 1

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.

Identified problem 2

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.

Deep dive into problem 2

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

DhtDelay 480,40

Solution

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.


On WiFi dropout

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.

Jason2866 commented 1 year ago

Closing, since the sensor is working with the introduced command for tuning timing of the sensor.

njh commented 1 year ago

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?

SimonFili commented 1 year ago

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?

lmagyar commented 1 year ago

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.

SimonFili commented 1 year ago

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: image 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.

SimonFili commented 1 year ago

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?

lmagyar commented 12 months ago

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

lmagyar commented 10 months ago

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: image

With 480, 40: image