Issues with widely out readings

[mitra42]

I'm seeing problems with consistently wrong readings and not sure if I'm doing something wrong or what.

My setup is a D1 mini (early version) connected to a KY-015 which is supposed to be a DHT11 https://arduinomodules.info/ky-015-temperature-humidity-sensor-module/ I've got it hooked to 5V but get the same results at 3.3V

I'm currently hooked up to pin D2 but I get the same results on pin D1

I couldn't find a canonical - simplest possible - example - so I'm using "array". The unconnected sensors just show 999's as I'd expect but the D2 is showing ... 20:48:04.094 -> 1, Waiting for read, 2048.5, 537.8, 4, 22 Which I take as a humidity of 2048% and temperature of 537C, and that the device is actually a DHT22

It seems consistent - I've tried some of the other examples and get similar results.

If I breath on the sensor, as expected temperature and humidity go up.

[mitra42]

Full disclosure .... at some point I had the pinout wrong (order is data; V; Gnd on the KY-015). Its possible I've damaged the sensor, but then I'd expect to get no readings rather than strange ones). Unfortunately I don't have another of these devices to swap with.

[RobTillaart]

Thanks for reporting this,

It might be that the KY-015 is not 100% compatible too. Did you compare the datasheets? Or do you have a link to the datasheet of the KY-015?

[RobTillaart]

The link shows some code which is very opportunistic in the timing. They hardcode delays where I know from experience that there is some spread in the timing if you compare actual sensors. That said the code looks indeed DHT11 alike.

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

[RobTillaart]

Its possible I've damaged the sensor, but then I'd expect to get no readings rather than strange ones).

mmm, anything is possible, the internal processor might still work but the "physics" part might be fried.

[mitra42]

Thanks Rob I couldn't see how I did something so stupid, but the problem was there are incorrect pinouts online https://www.thegeekpub.com/wiki/sensor-wiki-ky-015-dht11-combination-temperature-and-humidity-sensor for example has them wrong in first two images, correct in the bottom two - and since of the tutorial writers copy each other its not the only place.

https://oshwlab.com/adrirobot/ky-015-temperature-and-humidity-sensor-module has the correct circuit diagram - dead simple, just one pull-up on the data line.

The board comes from a cheap collection of all the Arduino sensors on AliExpress, no data sheet or confirmation - it is specified as being KY-015 but I can't see how to tell as visually the DHT11 and DHT22 look the same (mine is blue, but they both appear to come in both colors).

I thought it was a decimal point issue, but current figures from the DHT are 2407.1, 487.2, while my SHT is reporting 75% and 24C

Will add output of dhtnew_pulse_diag_ext.ino to next comment.

(Minor suggestion: rename one of the examples as something like dhtnew_simple, it was hard to figure out which was a standard example to copy from and which were, like this, your tests. )

[mitra42]

07:46:25.634 -> dhtnew_pulse_diag_ext.ino
07:46:25.634 -> 
07:46:25.634 -> 
07:46:25.634 -> ===================================
07:46:25.634 -> awake 2 3 4 11
07:46:25.685 -> 10
07:46:25.685 -> 9
07:46:25.685 -> 8
07:46:25.685 -> 7
07:46:25.685 -> 6
07:46:25.685 -> 5
07:46:25.685 -> 4
07:46:25.685 -> 3
07:46:25.685 -> 2
07:46:25.685 -> 1
07:46:25.685 -> 5 6 7 
07:46:25.685 -> 
07:46:25.685 -> RUN:    1
07:46:25.685 -> IDX:    89
07:46:25.685 -> WAKEUP
07:46:25.685 ->     1125    14  13  29  18  9
07:46:25.685 -> HUM
07:46:25.685 ->     47  27  48  27  52  26  53  75  52  79  54  25  52  27  52  26
07:46:25.685 ->     53  75  54  25  53  76  52  26  53  29  52  27  52  26  53  26
07:46:25.685 -> RAW H:  0b1100010100000 = 0x18A0 = 6304 = 630.4%
07:46:25.685 -> 
07:46:25.685 -> TEMP
07:46:25.685 ->     53  26  53  26  52  76  52  26  53  30  52  25  54  75  52  75
07:46:25.685 ->     54  75  53  26  52  75  54  75  53  25  53  7221    1   12  1   11
07:46:25.685 -> RAW T:  0b10001110110100 = 0x23B4 = 9140 = 914.0C
07:46:25.685 -> 
07:46:25.685 -> CRC
07:46:25.685 ->     1   10  1   11  1   10  1   11
07:46:25.685 ->     1   10  2   10  1   11  1   14
07:46:25.685 -> CRC:    0b0 = 0 <=> 143
07:46:25.685 -> 
07:46:25.685 -> 
07:46:25.685 -> BYE
07:46:25.685 ->     10  5
07:46:25.685 ->
07:46:30.669 -> 
07:46:30.669 -> ===================================
07:46:30.669 -> awake 2 3 4 5 6 7 
07:46:30.669 -> 
07:46:30.669 -> RUN:    2
07:46:30.669 -> IDX:    89
07:46:30.669 -> WAKEUP
07:46:30.669 ->     1113    2   19  81  84  5
07:46:30.669 -> HUM
07:46:30.669 ->     48  25  54  75  52  27  52  75  54  75  52  26  53  75  54  77
07:46:30.669 ->     54  25  54  25  52  27  52  27  52  26  53  26  53  75  53  78
07:46:30.669 -> RAW H:  0b101101100000011 = 0x5B03 = 23299 = 2329.9%
07:46:30.669 -> 
07:46:30.669 -> TEMP
07:46:30.669 ->     53  26  52  27  52  26  53  76  52  27  52  75  53  26  53  28
07:46:30.669 ->     54  25  54  25  53  26  52  27  52  26  53  75  54  25  53  30
07:46:30.669 -> RAW T:  0b1010000000100 = 0x1404 = 5124 = 512.4C
07:46:30.669 -> 
07:46:30.669 -> CRC
07:46:30.669 ->     52  25  54  75  52  75  54  75
07:46:30.669 ->     52  27  52  75  53  76  52  30
07:46:30.669 -> CRC:    0b1110110 = 118 <=> 118
07:46:30.669 -> 
07:46:30.669 -> 
07:46:30.669 -> BYE

[mitra42]

Only change I made to the sketch was to set the pin D2, and serial speed, and note that its a ESP8266, not an ESP32.

uint8_t   _dataPin = D2;

Serial.begin(460800); delay(5000);

[RobTillaart]

Thanks for the log data. Will look at it tomorrow as it is rather late here.

The DHT11 is often blue and the DHT22 light gray,

[mitra42]

Out of curiousity ..... I tried the simple sketch from here https://arduinomodules.info/ky-015-temperature-humidity-sensor-module/ on the same device. It reported Humdity = 94.4%; Temperature = 20.6C also interestingly - and repeatably - checksum readings were wrong on the first few readings, then switched to OK, though the output didn't change.

And my temp/humidity (cheap consumer) device is reporting 79% humidity 21C which is close to the SHT.

I've also tried switching voltage (3.3V vs 5V); switching to a newer version of the D1 Mini; and switching which data pin. Whichever sketch I'm using the results stay consistent with those changes.

[mitra42]

My DHT is blue.

[RobTillaart]

Had a quick look and the decoding could be...

Humidity is 5B03 that could be integer byte and a decimal byte. Makes 91.3% Hum.

Temperature is 0x1404 => 20.4C

To be continued...

[RobTillaart]

That matches the info in the link and gives something to work with.

[RobTillaart]

Can you add a line that states

Dht.setType(11);

In setup() at least before the first dht.read()

This should give better readings.

I'm thinking how to improve the auto detection to include KY-015. Fall back option is to add type param in constructor.

(Updated)

[RobTillaart]

Q: do you know if the KY015 can do negative temperatures (below 0 C or 32. F)

[mitra42]

I'm confused - or maybe you are :-) The KY015 is a board, not a chip - the chip is supposed to be the DHT11

[RobTillaart]

The library tries to recognize the type of the sensor. It uses the wakeuptime which is ~18 milliseconds for a DHT11 and ~1 ms for DHT22.

The KY015 (board) awakes as fast as the DHT22 that is why the library thinks it is a DHT22 and consequently fails to convert the bits properly to T and H.

The encoding of the bits is DHT11 alike. The DHT11 does not do negative temperatures, and I dont know if the KY015 does.

So my guess is that the KY015 uses actually a follow up chip of the DHT11 (lets name it DHT15) that uses the same code but has internally a faster processor or optimized code.

So far my confusion:)

Did you try adding the setType(11); line?

---

I will add examples as requested DHT_simple.ino DHT11_simple.ino forced type 11 DHT22_simple.ino forced type 22

[RobTillaart]

The library tries to recognize the type of the sensor. It uses the wakeuptime which is ~18 milliseconds for a DHT11 and ~1 ms for DHT22.

The KY015 awakes as fast as the DHT22 that is why the library thinks it is a DHT22 and consequently fails to convert the bits properly to T and H.

The encoding of the bits is DHT11 alike. The DHT11 does not do negative temperatures, and I dont know if the KY015 does.

So my guess is that the KY015 uses actually a follow up chip of the DHT11 (lets name it DHT15) that uses the same code but has internally a faster processor or optimized code.

So far my confusion:)

Did you try adding the setType(11); line?

---

I will add examples as requested DHT_simple.ino DHT11_simple.ino forced type 11 DHT22_simple.ino forced type 22

[RobTillaart]

I have to rethink the recognition algorithm to include the new Insights.

[mitra42]

OK interesting - KY-015 is supposed to be a DHT11 but its a china clone, so who knows what they used ! And maybe there is a clone of the DHT11 out there that wakes up faster.

I'm guessing the DHT22 and DHT11 use the same checksum algorithm so while the data is different you cant use a passed checksum as a way to know which type it is.

I added the setType(11) line, and that works to get good data now. Thanks

[RobTillaart]

@mitra42 Created a develop branch and pull request This already includes three new examples named dhtnew_dht11.ino, dhtnew_dht22.ino, dhtnew_simple.ino You might check if they are simple enough?

The recognition algorithm will take a few days. If you have time I would appreciate if you could help testing if it works.

[mitra42]

And my own code ... to read the sensor and send over MQTT at https://github.com/mitra42/frugal-iot/blob/main/sensor_dht.cpp is working as well thanks

[mitra42]

Sure - happy to help test, I've checked out the library, let me know when you want a test done

The examples look good - about the right level of complexity I think - at least if I was looking to understand how to use a library it would be about right.

[RobTillaart]

@mitra42

Add a first version of the recognition of the KY-015 as DHT11 to develop. (it was raining so I had some time) I have tested and a DHT22 and DHT11 are still recognized correctly.

If you have time please try the latest develop branch to see if it recognizes the KY015 as type 11 and still works for you.

---

In the end it is a simple test, In the DHT11 bits[0] is normally always above 3 as 3% is an extreme low humidity. For the DHT22 interpretation bits[0] never has a value above 3 as 100% is maximum (0x03E8) So testing that byte is a simple way to detect the type protocol used. This test will only fail if there is bad data, but that will be catched (255 in 256) by the CRC check. So not 100% but very close in practice.

Made a note in the readme that in the future I could read the bits and convert them to see which conversion is needed. We know that the humidity must be between 0 and 100 and temperature between -40 and 80. Assumption is that the bits come in correctly.

[mitra42]

Nice solution - and should be solid as it would take both bad data that successfully passed CRC to get the wrong result.

I ran the dhtnew_simple example and it worked first time - EXCEPT the very first result had a bad value ...

06:34:34.698 -> LIBRARY VERSION: 0.5.1
06:34:34.698 -> 
06:34:34.698 -> 
06:34:34.698 -> 1. Type detection test, first run might take longer to determine type
06:34:34.698 -> STAT    HUMI    TEMP    TYPE
06:34:35.619 -> OK, 2151.3, 487.1,  11
06:34:37.628 -> OK, 84.8,   19.0,   11
06:34:39.637 -> OK, 84.8,   19.0,   11

[mitra42]

Oh - and there was a warning on compilation

/Users/mitra/Documents/Arduino/libraries/DHTNew/dhtnew.cpp:217:32: warning: statement has no effect [-Wunused-value]
  217 |     if (_bits[3]) _temperature + _bits[3] * 0.1;
      |                   ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~

[RobTillaart]

Thanks for the feedback, need to look at that first read. Think that in case the ky015 is detected there must be another call to read with type 11 set.

Its too late to fix now (netherlands ~ 22:30) so an update will come tomorrow.

Thanks for testing!

[mitra42]

Happy to - and by the way, I wouldn't presume this is specific to a KY015. KY015 is a generic open-source board design for a peripheral (used in Arduino projects) - that supposedly uses a DHT11. I'm guessing this is a new chip (clone?) that this supplier is using, which means it will probably turn up elsewhere labeled DHT11.

I picked up one of these packs https://www.aliexpress.com/item/1005006222476183.html (45 sensors for USD18) just to have a range of sensors to experiment with, so I have no real visibility of the source of the components they used.

[RobTillaart]

Oh - and there was a warning on compilation

/Users/mitra/Documents/Arduino/libraries/DHTNew/dhtnew.cpp:217:32: warning: statement has no effect [-Wunused-value]
  217 |     if (_bits[3]) _temperature + _bits[3] * 0.1;
      |                   ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~

That is a bug, should be +=
Thanks!

[RobTillaart]

Did some background search to check the 3% humidity test in the code

Desert air still has about 20% humidity, so the 3% used in the code seems pretty safe. The North and South Poles can have an extreme low humidity however that is not a place to use a DHT11 which cannot do below freezing. So pretty safe.

Sahara https://www.rumerloudin.com/2013/12/10/how-low-humidity-affects-you-and-your-home/

Poles https://discoveringantarctica.org.uk/oceans-atmosphere-landscape/atmosphere-weather-and-climate/key-factors-behind-antarcticas-climate/

[RobTillaart]

@mitra42 Pushed a new version into develop branch, please verify

• that first read is correct now
• the warning has gone.

Thanks,

[mitra42]

Correct - output is now ...

19:16:59.234 -> 1. Type detection test, first run might take longer to determine type
19:16:59.234 -> STAT    HUMI    TEMP    TYPE
19:17:00.199 -> Sensor not ready,   -999.0, -999.0, 11
19:17:02.248 -> OK, 69.0,   23.8,   11
19:17:04.262 -> OK, 70.1,   23.8,   11

So first read is, in this case a fail - which is fine.

[RobTillaart]

Thanks for testing!

If there are no other issues, I will merge the develop branch later today.

[mitra42]

No issues from my side

[RobTillaart]

Released 0.5.1