AM2322 Humidity 99.9 Temp OK

[pacmac]

Hi;

Am testing this lib on the AM2322, I have a bunch of them and are testing on 2 of them, both give same results.

I have tried different pins (ESP32) but the results are the same on both devices and different pins.

Temperature reading is good, but humidity is always 99.9, if I introduce a negative offset then the values will always be 99.9 - that offset.

Have tried defining type as 22 or not defining type, result is the same, have also tried slowing down the reads to 5 seconds but no difference.

Humidity shown on other devices is around 75% currently.

It works with different lib on I2C but I am desperately short on pins :-)

EDIT

Just added a 4K7 resistor to pullup the data line, no difference.

07:45:01.770 -> BEFORE OFFSET
07:45:06.778 ->     29.2
07:45:06.975 -> 99.9
07:45:06.975 -> AFTER -10 HUMID OFFSET
07:45:09.081 -> 89.9    29.2
07:45:11.186 -> 89.9    29.2
07:45:13.293 -> 89.9    29.2
07:45:15.397 -> 89.9    29.2
07:45:17.505 -> 89.9    29.2

Any suggestions ?

[RobTillaart]

Thanks for the issue. Might take a few days to dive into it.

[RobTillaart]

If I recall correctly the device also supports I2C? Have you tried that interface to see if humidity sensor does work? See AM232X library.

[RobTillaart]

Can you run the sketch dhtnew_pulse_diag.ino and post its output?

[pacmac]

Thanks, could not figure out why I was getting no output, then realised had to Serial.begin before waiting for it:

void setup()
{

  Serial.begin(115200);
  while(!Serial);        //  MKR1010 needs this

  Serial.println("dhtnew_pulse_diag.ino");
  Serial.println();

  //  default should be HIGH
  pinMode(_dataPin, OUTPUT);
  digitalWrite(_dataPin, HIGH);
}

Here's the output:

15:17:57.499 -> awake 2 3 4 5 6 7 
15:17:57.540 -> 
15:17:57.540 -> RUN:    9
15:17:57.540 -> IDX:    89
15:17:57.540 -> WAKEUP
15:17:57.540 ->     1130    14  29  81  64  18
15:17:57.540 -> HUM
15:17:57.540 ->     37  25  54  26  54  25  55  25  55  25  55  25  55  73  54  72
15:17:57.540 ->     68  73  55  72  55  73  55  25  54  26  54  73  55  73  54  78
15:17:57.540 -> 
15:17:57.540 -> TEMP
15:17:57.540 ->     62  26  54  26  54  26  54  26  54  26  54  26  54  26  54  73
15:17:57.540 ->     66  27  53  26  54  26  55  73  54  26  54  26  54  26  54  73
15:17:57.540 -> 
15:17:57.540 -> CRC
15:17:57.540 ->     64  74  53  74  54  74  54  73
15:17:57.540 ->     55  73  54  74  54  26  54  42
15:17:57.540 -> 
15:17:57.540 -> BYE
15:17:57.540 ->     46  1
15:17:57.540 -> 

[RobTillaart]

Thanks for running the diag sketch

HUM
37  25  54  26  54  25  55  25  55  25  55  25  55  73  54  72
68  73  55  72  55  73  55  25  54  26  54  73  55  73  54  78

decoding every 2nd time =>   00000011 11100111  == 0x03E7 == 231  == 23.1 % RH

TEMP
62  26  54  26  54  26  54  26  54  26  54  26  54  26  54  73
66  27  53  26  54  26  55  73  54  26  54  26  54  26  54  73

decoding every 2nd time =>   00000001 00010001  == 0x0111 == 273  ==>  27.3 °C

So the sensor does provide good information, however the LOW period of 50 us is very variable.

The TLOW values 53, 54, 55 are good (spec states 50) The TLOW value of 37 is 25% too short The TLOW values 62, 66 and 68 are 25-40% too long. The TH0 and TH1 values are perfect within range.

So the sensor does not meet its specs (I only have Chinese datasheet)

[RobTillaart]

Also this section of the readme might be the cause.

Can you check your power supply?

Voltage AM2301 and ESP8266 In a test an AM2301 had problems giving no humidity (99.9% overflow) when the DHTStable library was used with an ESP8266. (Reported by mail, no GH issue). As this DHTStable library is strongly related to the DHTNew it is mentioned here too.

After days of testing and thinking and more testing the cause was found. The AM2301 was powered by a 5V3 power supply which was apparently too high while having the data handshakes at 3V3. When the VCC voltage was lowered to 5V1 it appeared to work as it should. (Kudos to Viktor for finding the cause)

[RobTillaart]

English datasheet - https://robu.in/wp-content/uploads/2022/06/1290199_AM2322-Datasheet.pdf

[pacmac]

I am running off 3V3 device is Adafruit QT PY S3.

I have added back the pullup as I had to switch device due to other one being on battery drain test.

18:45:38.999 -> awake 2 3 4 5 6 7 
18:45:39.032 -> 
18:45:39.032 -> RUN:    2
18:45:39.032 -> IDX:    89
18:45:39.032 -> WAKEUP
18:45:39.032 ->     1132    14  28  81  64  18
18:45:39.032 -> HUM
18:45:39.032 ->     35  27  53  26  54  26  54  26  54  26  54  26  54  73  54  73
18:45:39.032 ->     67  74  54  73  54  74  53  26  54  26  54  74  54  73  54  25
18:45:39.032 -> 
18:45:39.032 -> TEMP
18:45:39.032 ->     68  25  55  25  55  25  54  26  54  26  54  26  54  26  54  73
18:45:39.032 ->     66  27  53  27  53  74  54  26  54  73  54  26  54  74  53  74
18:45:39.032 -> 
18:45:39.032 -> CRC
18:45:39.032 ->     64  26  54  26  54  25  55  73
18:45:39.032 ->     54  26  53  75  53  26  54  90
18:45:39.032 -> 
18:45:39.032 -> BYE
18:45:39.032 ->     46  1
18:45:39.032 -> 

Strange that the temperature figures are good !

18:50:48.729 -> Started
18:50:48.729 -> BEFORE OFFSET
18:50:53.668 ->     29.4
18:50:53.866 -> 99.9
18:50:53.866 -> AFTER -10 HUMID OFFSET
18:50:55.972 -> 89.9    29.4
18:50:58.105 -> 89.9    29.3

[RobTillaart]

I am running off 3V3 device is Adafruit QT PY S3.

OK, so that cannot be the cause

Strange that the temperature figures are good !

No, that is what is expected, strange the humidity fails. However the first bit (35 27) is very short, that is the only clue so far. Need to dive into the code to see if that triggers something..

What value does the dht.read() function return, it might give another clue .

[pacmac]

result of read():

19:02:25.586 -> Started
19:02:25.586 -> BEFORE OFFSET
19:02:30.552 ->     29.3
19:02:30.750 -> 99.9
19:02:30.750 -> AFTER -10 HUMID OFFSET
19:02:30.750 -> read(): -8
19:02:32.857 -> 89.9    29.3
19:02:34.959 -> 89.9    29.3

[RobTillaart]

Can you add

Dht.setWaitForReading(true);

After dht.begin()

[RobTillaart]

Read does check if there are at least 2 seconds past since startup or last call to read.

[pacmac]

I dont have mySensor.begin();

void setup(){

  mySensor.setType(22);
  Serial.println("BEFORE OFFSET");
  delay(5000);
  mySensor.read();

  Serial.print("\t");
  Serial.println(mySensor.getTemperature(), 1);
  delay(200);
  Serial.println(mySensor.getHumidity(), 1);
  mySensor.setHumOffset(-10);
  // mySensor.setTempOffset(-3.5);

  Serial.println("AFTER -10 HUMID OFFSET");

  Serial.println("read(): " + String(mySensor.read()));
}

If I add it before setType I get:

mySensor.begin();
            ^~~~~

exit status 1

Compilation error: 'class DHTNEW' has no member named 'begin'

[RobTillaart]

Oops, mixed up with other library, sorry.

There should be a delay between the calls to read() of 2 seconds.

Your 2nd call is faster than that causing the -8 return value.

by setting Dht.setWaitForReading(true); the library will block the read for up to 2 seconds since last read().

[RobTillaart]

Could not find a cause in the code, so I reread this whole issue again for clues.

And yes, made a mistake with my hex math ==> should not do that from the head

HUM
37  25  54  26  54  25  55  25  55  25  55  25  55  73  54  72
68  73  55  72  55  73  55  25  54  26  54  73  55  73  54  78

decoding every 2nd time =>   00000011 11100111  == 0x03E7 == 999 ==> 99.9%

So the sensor itself did sent the 99.9, so that means scrutinizing the datasheet.

[RobTillaart]

It works with different lib on I2C but I am desperately short on pins :-)

Considered an I2C multiplexer? TCA9548?

[RobTillaart]

Found a note in the datasheet (which seems to be automated translated) how drifted humidity can be restored. (which is strange as I2C did work...)

2.2 Restoration processing

As mentioned above, readings can drift if the sensor is exposed to extreme operating conditions or chemical vapors. It can be brought back to calibration by the following treatments.Drying: 10 hours at 80-85°C and <5% RH humidity Re-hydration: 24 hours at 20-30°C and >75% RH.

[pacmac]

Hi Rob;

Thanks for all the help, the device works fine on I2C using for example the adafruit lib, both temperature and humidity are correct, I dont think the devices are defective.

[RobTillaart]

Ok, The I2C working means hat

• Temperature and Humidity works and
• I2C is implemented correctly...

That is good news and bad news.

Explaining the bad news:

My worries are that the one wire implementation is not within specs and after revisiting my hex math the device is sending an invalid value. Because I2C shows that the physics part for Humidity is working well, the one wire part of the device is suspect.

Note that the library does extract the sent percentage correctly even if the protocol is outside its specs.

(updated for readability)

[RobTillaart]

@pacmac Went through the datasheet again, to see if the I2C interface offers some reset or status but no such thing documented.

https://www.letscontrolit.com/forum/viewtopic.php?t=5707

offers a similar problem but except for "washing the sensor" (new to me) no real solutions.

Sorry, but I'm out of ideas how to solve this 99.9% problem.

[pacmac]

Rob, thanks for your help, I guess this one just wont work.

I will have to revert to using I2C, but thanks so much again

PeterC

[RobTillaart]

You're welcome. For now I close this issue, if new insights pop up feel free to reopen it or just add comments.

[pacmac]

Thanks again for trying.