Espurna doesn't seem to recover from error in sensor DHT

[JavierAder]

Hi; my data

• build on commit cf3bd49 (2019-09-10)
• Sonoff Pow R2
• DHT22 in GPIO 4; added using custom.h
• Thingspeak enabled

Probably I have some problem in hardware, but I am not totally sure.
When I power my Sonoff, it reads the sensor correctly; some time later I get (via telnet) timeouts errors:

[306269] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[312277] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[318281] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[324532] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[330285] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[336293] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[342297] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[348305] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[354307] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)
[360564] [SENSOR] Error reading data from DHT22 @ GPIO4 (error: 3)

Then, if I reset Espurna via command "reset" in telnet, the error persists after the boot; but if power off and power on the sonoff, the problem disappears (at least for a time).

I suspect the following code in DHTSensor.h

// Send start signal to DHT sensor
        	if (++_errors > DHT_MAX_ERRORS) {
                     _errors = 0;
                    digitalWrite(_gpio, HIGH);
                    nice_delay(250);
               }

because digitalWrite is not preceded by "pinMode(_gpio, OUTPUT);". Is it possible that this is the reason why it does not seem to recover?

By the way; DHT_MIN_INTERVAL is set to 2000; it is not to low?

PD: I will try to force the error timeout disconnecting and connecting GPIO 4

[mcspr]

because digitalWrite is not preceded by "pinMode(_gpio, OUTPUT);". Is it possible that this is the reason why it does not seem to recover?
PD: I will try to force the error timeout disconnecting and connecting GPIO 4

Please do also try setting pinMode.

By the way; DHT_MIN_INTERVAL is set to 2000; it is not to low?

Do you mean that readings need more time? I think this value was taken from here:
https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf
http://image.dfrobot.com/image/data/SEN0137/AM2302_manual.pdf

Temperature and humidity values are each read out the results of the last measurement For real-time data that need continuous read twice, we recommend repeatedly to read sensors, and each read sensor interval is greater than 2 seconds to obtain accuratethe data.

[AlbertWeterings]

Check the wiki https://github.com/xoseperez/espurna/wiki/Sensors and my troubleshooting #1534 hope it helps you.

[JavierAder]

Hi and sorry, I've been very busy these days

Check the wiki https://github.com/xoseperez/espurna/wiki/Sensors and my troubleshooting #1534 hope it helps you.

could you give me a summary of what solution you found?

My current hypotheses are

1. There are some hardware problems, possibly due to:

• unnecessary pull ups (at least for some sensors)
• absence of capacitor between vcc and gnd close to the sensor
• power supply instability
• line interference due to the wifi signal in gnd, vcc or data (this could explain why certain gpios work better). Eg https://learn.sparkfun.com/tutorials/esp8266-wifi-shield-hookup-guide/all

2. And there are some software problems, possibly due to:

• absence of pinMode previous writes
• absence of initial raise of data line level; see https://github.com/adafruit/DHT-sensor-library/blob/master/DHT.cpp#L249
• incorrects delays in start signal (500 us vs 1100 us; my DHT22 says at least 1ms); see https://github.com/adafruit/DHT-sensor-library/blob/master/DHT.cpp#L258
• absence of initial 1 second delay after power on (this could explain, maybe, why the sensor recovers after power off/power on but not after sofware reset).

In summary; something in 1) brings the sensor to an error state and/or reset it, and something in 2) don't let it recover. My guess: inestabilty in vcc or wifi intereference resets (randomly) the sensor, and then espurna never waits 1 second.

I tried disconnect and connect data line, and espurna always recovered the sensor after some timeouts; I will try next disconnet and connect vcc line simulating inestability to force a sensor reset and see what happen.

[AlbertWeterings]

In the sensor code is a part that counts the sensor read errors and then reset the sensor over the data line. In my case with none of my sensors this worked. What I did is assign a second io pin as power supply for the sensor and upon 5 read errors I pull down the power for half a second and the sensor is working again. Already have this running for months now without a problem (and I don't know why with almost no sensor resets) so the problem is in the supply of the sensor and if my way is the best way I can't say but it works satisfying for me.

[icevoodoo]

I have also the same problem with the sensor readings on the new buil 1.14..0-dev, on a sonoff-th-10 device. I have reverted back to 1.13.6-dev and everithing is working normal.

1.14..0-dev
1.13.6-dev

[mcspr]

@icevoodoo bad2855 did the timing change break this? 500 -> 1100
edit: or is this the same problem with error recovery that was not fixed by the #1979? There are only two lines that trigger TIMEOUT(3) error, wonder which one fails:

espurna/code/espurna/sensors/DHTSensor.h

Line 175 in c96f2e4

_error = SENSOR_ERROR_TIMEOUT;

espurna/code/espurna/sensors/DHTSensor.h

Line 182 in c96f2e4

_error = SENSOR_ERROR_TIMEOUT;

[icevoodoo]

I have modified to 500 ms and uploaded to my device and seems to work now. The question is why you are not reverting back to 500 ms ?

1100 -> 500 is working

[mcspr]

I guess this is some kind of hardware difference, not all DHT made equal.
Check out this timing table from ESPeasy, my guess this is specific to the sonoff-th because it uses si7021?
https://github.com/letscontrolit/ESPEasy/blob/7fd0139641ab3d21db4c062c17ef50cd3d39b2c3/src/_P005_DHT.ino#L154-158

[JavierAder]

Hi...; I still can't test the code, I haven't had much time...
@icevoodoo just in case, are you sure that you have a DHT22 sensor? I ask this, because the original SonOff TH seems only supports sensors: Si7021, AM2301, DS18B20, DHT11; but not DHT22

https://www.itead.cc/wiki/Sonoff_TH_10/16

[icevoodoo]

Si7021

I can confirm that is SI7021. But till now it worked very fine. You can see in the picture bellow (sorry the site is not in english, but you can figure it out).

SI7021

[mcspr]

Ok, so the fix should probably be:

#define DHT_CHIP_SI7021 <some number>
...
             if ((_type == DHT_CHIP_DHT11) || (_type == DHT_CHIP_DHT12)) {
                 nice_delay(20);
+            } else if (_type == DHT_CHIP_SI7021) {
+                delayMicroseconds(500);
             } else {
                 delayMicroseconds(1100);
             }

And add #define DHT_TYPE DHT_CHIP_SI7021 to the TH settings in the hardware.h

[mcspr]

#2000 updated 1100 usec to be only used in case of DHT_TYPE == DHT_CHIP_DHT22, old default 500 from previous versions now checks for DHT_CHIP_SI7021
I do remember having DHT22 somewhere, but I still can't find it anywhere :/ Looking at other implementations, perhaps INPUT_PULLUP call could also help. Don't really want to blindly test again

[icevoodoo]

I have tested today with the new modifications approved and everithing seems ok.

[icevoodoo]

The single weird thing that I notice in the web interface, is the missing switches and schedule section. I don't know if it's related with the new modifications. Can someone help with this?

missing switches and schedule section from webui

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue will be auto-closed because there hasn't been any activity for two months. Feel free to open a new one if you still experience this problem.