Sensors getting stuck at a certain value

[Aaron2550]

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:

1. AM2302s get read using .read();
2. Values get sent to InfluxDB using .getTemperature(); and .getHumidity();
3. 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.

[RobTillaart]

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?

[Aaron2550]

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

[Aaron2550]

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.

[RobTillaart]

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.

[Aaron2550]

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

[RobTillaart]

Do you have a scope to check the signal quality ?

I assume the humidity also fails ?

[Aaron2550]

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)

[RobTillaart]

BTW, the graphs look cool!

[Aaron2550]

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

[RobTillaart]

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.

[RobTillaart]

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)

[Aaron2550]

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

[Aaron2550]

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

[RobTillaart]

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

[RobTillaart]

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

Yes, please

[Aaron2550]

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

[RobTillaart]

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

[RobTillaart]

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

[Aaron2550]

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

[RobTillaart]

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.

[RobTillaart]

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.

[Aaron2550]

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

[RobTillaart]

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

[Aaron2550]

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

[RobTillaart]

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?

[RobTillaart]

Ant progress?

[Aaron2550]

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

[Aaron2550]

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.

[RobTillaart]

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

[Aaron2550]

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

[RobTillaart]

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

[Aaron2550]

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

[Aaron2550]

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

[Aaron2550]

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

[RobTillaart]

@Aaron2550 Any progress?

[RobTillaart]

@Aaron2550 Any progress?

[RobTillaart]

Please reopen the issue if it still exists