Sensors getting stuck at a certain value

Question

Sensors getting stuck at a certain value

Closed this issue 3 years ago · 37 comments

I have two AM2302s connected to pins 0 and 2 of an ESP32, after a while of working perfectly they only return a static value...

My loop looks like this:

AM2302s get read using .read();
Values get sent to InfluxDB using .getTemperature(); and .getHumidity();
10 second wait

I have tried adding .reset(); before the 10 second wait but that only made them return 0 or -999 instead of a static value.

Answer 1 · 2021-04-12T10:18:28.000Z

setSuppressError() is a way to suppress incidental errors, to keep a graph smooth.
It will not remove the cause of the error.

reset() resets the library to startup conditions, it does not reset the sensor.
I might need to explain that more explicitly in the readme.

The fact that it works for some time perfectly does strengthen the problem is not in the library.
The software of the library is quite repeatable in its behavior and bugs in software are pretty repeatable too.

I assume your question is "What happens, or Why?"

how often do you read the sensor? datasheet states max once per 2 seconds, otherwise one gets self heating and possibly other problems
how long are the wires used?
do you use pull up resistors? if yes which value, if not use one that matches the length of the wires.
have you tried other pins?
do you have 3.3V ? as that is at the edge of working voltage. You might consider a level convertor to get better signals.
do you see the effects when running the test sketches?
have you read the datasheet?

Answer 2 · 2021-04-12T10:53:07.000Z

Hi again, i read the sensor every 10 seconds as stated in the issue. The wires are about 23cm long and the AM2302 datasheet says it has a built-in pull up resistor. I have tried other pins but the issue persists. The sensors are running on 5V and this also happens with the example sketches. Also, yes I have read the datasheet for the AM2302s i bought.

Sent from my Redmi Note 7 using FastHub-Libre

Answer 3 · 2021-04-12T10:55:41.000Z

Note: I have not modified the wire-length. The wire-length is the one the manufacturer delivered.
I have also checked all solder joints and they have close to no resistance.

Answer 4 · 2021-04-12T10:57:41.000Z

So the wire length is ~25 cm (10"),
Sample frequency is OK
Voltage is OK
Example sketches do also fail,

can you measure the built-in pull up resistor ?

for the moment I have no clue, it gives a constant value when it does not suppress errors

Can you print the return value of the read() command?
What value does it have, when failing?

Next step:
you could patch dhtnew.cpp so it prints the values it gets from the sensor.
look for // HEXDUMP DEBUG and uncomment that section.

Answer 5 · 2021-04-12T11:07:55.000Z

yep. i bought them from here (german site) but this one is the same one. (same part number and manufacturer)

Answer 6 · 2021-04-12T11:18:52.000Z

Do you have a scope to check the signal quality ?

I assume the humidity also fails ?

Answer 7 · 2021-04-12T11:23:50.000Z

i dont have a scope and i cant really check the resistor because the sensors are glued in a box.... the website says they are 5.1k ohm tho. Yes, the humidity also fails and as you can see after restarting the esp32 it works perfectly. (i disconnected it from wall power and connected it to my laptop so i can test the hexdump stuff you sent)

Answer 8 · 2021-04-12T11:27:37.000Z

BTW, the graphs look cool!

Answer 9 · 2021-04-12T11:28:59.000Z

Thanks! Im using Grafana with InfluxDB and an Ardunio InfluxDB Library. I can upload the code somewhere if you want to check it. maybe thats the issue....

Answer 10 · 2021-04-12T11:30:41.000Z

The test sketches do not use those libs and the sensor still fail so I doubt that.

Not familiar with Grafana/influxDB - a link is appreciated.

Answer 11 · 2021-04-12T11:33:05.000Z

Does your system generate a lot of interrupts?
these might corrupt communication, however not seen a failure for such a long time.

PS an update of the library in in progress (fixing #60 - which is not related to your problem)

Answer 12 · 2021-04-12T11:34:59.000Z

The test sketches do not use those libs and the sensor still fail so I doubt that.

Not familiar with Grafana/influxDB - a link is appreciated.

grafana is basically the web ui you see, here is their live demo: https://play.grafana.org/d/000000012/grafana-play-home
influixdb is the database that stores the values and is "easier" to use in grafana than a mysql database

Does your system generate a lot of interrupts?
these might corrupt communication, however not seen a failure for such a long time.

PS an update of the library in in progress (fixing #60 - which is not related to your problem)

i do also have a bme280 connected but other than that nothing else is connected that could cause interrupts

Answer 13 · 2021-04-12T11:44:02.000Z

i have uncommented the debug code and flashed the debug sketch, how long should i leave it running for? until it breaks?

Answer 14 · 2021-04-12T11:45:22.000Z

This is a mini scope that is affordable (< €50) - JYE Tech DSO150 - there is a faster 2 channel one that is still less than €100
It has saved me lot of time analyzing

Answer 15 · 2021-04-12T11:45:33.000Z

i have uncommented the debug code and flashed the debug sketch, how long should i leave it running for? until it breaks?

Yes, please

Answer 16 · 2021-04-12T11:47:40.000Z

for now it is looking okay... ill let it run and we will see...

F0    0064    10.0    028A    65.00

B0    0060    9.6    024E    9.80
10.00
65.00
9.60
9.80

F0    0064    10.0    028A    65.00

B0    0060    9.6    024E    9.80
10.00
65.00
9.60
9.80

F1    0064    10.0    028B    65.10

B0    0060    9.6    024E    9.80
10.00
65.10
9.60
9.80

F1    0064    10.0    028B    65.10

B0    0060    9.6    024E    9.80
10.00
65.10
9.60
9.80

im using slightly modified code:

//
//    FILE: dhtnew_debug.ino
//  AUTHOR: Rob Tillaart
// VERSION: 0.1.0
// PURPOSE: DHTNEW library debug sketch for Arduino
//     URL: https://github.com/RobTillaart/DHTNew
//
// HISTORY:
// 0.1.0    2020-12-15
//
// DHT PIN layout from left to right
// =================================
// FRONT : DESCRIPTION
// pin 1 : VCC
// pin 2 : DATA
// pin 3 : Not Connected
// pin 4 : GND

#include <dhtnew.h>

DHTNEW mySensorA(2);
DHTNEW mySensorB(0);

void setup()
{
  Serial.begin(115200);
  Serial.println("dhtnew_debug.ino");
  Serial.print("LIBRARY VERSION: ");
  Serial.println(DHTNEW_LIB_VERSION);
  Serial.println();
}

void loop()
{
  delay(2000);
  Serial.println(mySensorA.read());
  Serial.println(mySensorB.read());

  Serial.println(mySensorA.getTemperature());
  Serial.println(mySensorA.getHumidity());
  Serial.println(mySensorB.getTemperature());
  Serial.println(mySensorB.getHumidity());
}

// END OF FILE

Answer 17 · 2021-04-12T11:50:08.000Z

added cpp to your post above to get syntax highlighting (improves readability)

Answer 18 · 2021-04-12T11:56:13.000Z

(I have to get to work again - so I'll check this evening (now it is ~14:00 in the Netherlands)

Answer 19 · 2021-04-12T12:02:49.000Z

i am getting these weird -5s (sorry for screenshot but copy pasting is annoying as hell from the serial monitor)

Answer 20 · 2021-04-12T12:26:19.000Z

#define DHTLIB_ERROR_TIMEOUT_C -5

error in the handshake, to be continued tonight.

checksums + bit pattern seem ok,
actually I think there is nothing read at all.

Answer 21 · 2021-04-13T13:20:03.000Z

DHTLIB_ERROR_TIMEOUT_C => line 328 DHTnew.cpp

This error indicates that the process of reading the bits sent by the sensor is failing.
The sensor does not pull up within (average) 50 us. The code even waits for 70.

As you "read" exactly the same value over and over when the sensor locks we can conclude for sure that the failure is in the first 16 bits, and probably even the first bit. Unfortunately the library has no means (yet) to see which bit fails.

It is an strong indication the sensor is internally locked.

A pragmatic solution could be to put the powerline of the sensor under processor control.
If 3x same temp and hum is detected, restart the sensor.

Answer 22 · 2021-04-14T17:48:46.000Z

sorry for the late response, okay well... how do i "restart the sensor" ?

Answer 23 · 2021-04-14T17:53:42.000Z

disconnected the +5V pin , don't know if you can drive the DHT directly from an ESP IO pin, otherwise you need a transistor or mosfet to switch them indirectly (like how you connect a relay

Answer 24 · 2021-04-18T12:11:36.000Z

That's so annoying, why does nobody else have this problem... I think I'll just stop using the AM2302s since I also have one BMP280 connected...

Answer 25 · 2021-04-18T17:49:29.000Z

You can try to tune the line 328 in the .cpp file

if (_waitFor(HIGH, 70)) return DHTLIB_ERROR_TIMEOUT_C;

try a value of 80 or even 90 to give the handshake a bit more time.

Can you post a photo of your setup?

Answer 26 · 2021-04-25T11:38:50.000Z

Ant progress?

Answer 27 · 2021-04-25T11:45:50.000Z

Not really I can't get my hands on any repairs right now...

Answer 28 · 2021-05-11T17:59:40.000Z

Sorry about the long radio silence. I ordered some relais last week but the package got stolen after it was deliviered to my mailbox on friday. Im gonna order new ones new ones on friday.

Answer 29 · 2021-05-11T18:38:00.000Z

Sorry to hear, I hope the next delivery will arrive without problems.

Answer 30 · 2021-05-18T07:25:56.000Z

Welp, i ordered on the 12th and DHL's Tracking site still says they haven't received the package from the sender....

Answer 31 · 2021-05-18T08:10:10.000Z

That is more than a week! Did you contact the supplier? Did he inform you?

Answer 32 · 2021-05-18T08:38:21.000Z

They said they gave it to the DHL Shop near them and ive never had problems with these guys...

Answer 33 · 2021-05-19T07:27:50.000Z

Ok so apparently they just forgot to update the status on their Website..... I just got a mail saying it's gonna be delivered today....

Answer 34 · 2021-05-20T09:24:45.000Z

Okay! Relais are here, I changed this value to 90

You can try to tune the line 328 in the .cpp file
if (_waitFor(HIGH, 70)) return DHTLIB_ERROR_TIMEOUT_C;
try a value of 80 or even 90 to give the handshake a bit more time.

I also added a small array to keep track of past values and if the last three values are the same, the relais will dis and reconnect the sensor.

Currently i cant upload the code as im not Home, but i can do it later today

Answer 35 · 2021-06-07T15:34:57.000Z

@Aaron2550
Any progress?

Answer 36 · 2021-07-04T18:13:44.000Z

@Aaron2550
Any progress?

Answer 37 · 2021-07-12T16:52:14.000Z

Please reopen the issue if it still exists