Issues with widely out readings #102

mitra42 · 2024-11-23T09:58:11Z

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 · 2024-11-23T10:01:35Z

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 · 2024-11-23T10:30:25Z

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 · 2024-11-23T10:35:23Z

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 · 2024-11-23T11:07:24Z

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 · 2024-11-23T20:48:52Z

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 · 2024-11-23T20:53:03Z

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 · 2024-11-23T20:55:55Z

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 · 2024-11-23T21:09:12Z

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 · 2024-11-23T21:25:24Z

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 · 2024-11-23T21:25:48Z

My DHT is blue.

RobTillaart · 2024-11-23T21:46:58Z

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 · 2024-11-23T21:52:06Z

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

RobTillaart · 2024-11-24T03:34:08Z

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 · 2024-11-24T05:00:41Z

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

mitra42 · 2024-11-24T07:17:28Z

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

RobTillaart · 2024-11-24T07:37:38Z

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 · 2024-11-24T07:38:40Z

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 · 2024-11-24T07:40:00Z

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

mitra42 · 2024-11-24T07:52:38Z

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 · 2024-11-24T08:34:30Z

@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 · 2024-11-24T08:38:56Z

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 · 2024-11-24T08:46:04Z

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 · 2024-11-24T14:07:46Z

@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 · 2024-11-24T19:37:24Z

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 · 2024-11-24T19:39:09Z

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 · 2024-11-24T21:22:40Z

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 · 2024-11-24T21:58:25Z

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 · 2024-11-25T06:48:16Z

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 · 2024-11-25T07:20:11Z

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 · 2024-11-25T07:33:25Z

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

that first read is correct now
the warning has gone.

Thanks,

mitra42 · 2024-11-25T08:18:09Z

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 · 2024-11-25T09:06:12Z

Thanks for testing!

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

mitra42 · 2024-11-25T09:23:08Z

No issues from my side

RobTillaart · 2024-11-25T14:45:00Z

Released 0.5.1

mitra42 mentioned this issue Nov 23, 2024

Sensor: DHT11 mitra42/frugal-iot#64

Open

3 tasks

RobTillaart self-assigned this Nov 23, 2024

RobTillaart added the question Further information is requested label Nov 23, 2024

RobTillaart added a commit that referenced this issue Nov 24, 2024

fix #102, support for KY015

6d6a3aa

RobTillaart closed this as completed in 973e7c7 Nov 25, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issues with widely out readings #102

Issues with widely out readings #102

mitra42 commented Nov 23, 2024

mitra42 commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

mitra42 commented Nov 23, 2024

mitra42 commented Nov 23, 2024

mitra42 commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

mitra42 commented Nov 23, 2024

mitra42 commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

RobTillaart commented Nov 24, 2024 •

edited

Loading

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 24, 2024 •

edited

Loading

RobTillaart commented Nov 24, 2024

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 25, 2024

RobTillaart commented Nov 25, 2024

RobTillaart commented Nov 25, 2024

mitra42 commented Nov 25, 2024

RobTillaart commented Nov 25, 2024

mitra42 commented Nov 25, 2024

RobTillaart commented Nov 25, 2024

Issues with widely out readings #102

Issues with widely out readings #102

Comments

mitra42 commented Nov 23, 2024

mitra42 commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

mitra42 commented Nov 23, 2024

mitra42 commented Nov 23, 2024

mitra42 commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

mitra42 commented Nov 23, 2024

mitra42 commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

RobTillaart commented Nov 23, 2024

RobTillaart commented Nov 24, 2024 • edited Loading

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 24, 2024 • edited Loading

RobTillaart commented Nov 24, 2024

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 24, 2024

mitra42 commented Nov 24, 2024

RobTillaart commented Nov 25, 2024

RobTillaart commented Nov 25, 2024

RobTillaart commented Nov 25, 2024

mitra42 commented Nov 25, 2024

RobTillaart commented Nov 25, 2024

mitra42 commented Nov 25, 2024

RobTillaart commented Nov 25, 2024

RobTillaart commented Nov 24, 2024 •

edited

Loading

RobTillaart commented Nov 24, 2024 •

edited

Loading