DHT11 fractional temperature is ignored

[hydrogen18]

Describe the bug

I bought some Sonoff Basic from AliExpress along with DHT11 sensors. I got Tasmota installed and a DHT11 installed. I saw temperature readings immediately, but they have only 1 C resolution while the device is capable of higher.

I tracked this down in the code to this line https://github.com/arendst/Sonoff-Tasmota/blob/v6.1.0/sonoff/xsns_06_dht.ino#L161

t = dht_data[2];

So the conversion consists of promoting a uint8_t to a float and calling it done. As far as I can tell the internet believes these devices don't output anything but zero for the last byte. For example:
http://sheepdogguides.com/arduino/ar3ne1humDHT11.htm

But here are my log lines from that file I see in the web console.

18:03:53 DHT: Received 53, 00, 1B, 05, 73 =? 73
18:03:55 DHT: Received 56, 00, 1B, 06, 77 =? 77
18:03:59 DHT: Received 58, 00, 1B, 09, 7C =? 7C
18:04:02 DHT: Received 5B, 00, 1C, 03, 7A =? 7A
18:04:05 DHT: Received 4F, 00, 1C, 04, 6F =? 6F
18:04:09 DHT: Received 45, 00, 1C, 06, 67 =? 67

So obviously I am seeing non-zero for the last byte. It is 0x0 - 0x9 in value. So it's fractional decimal. I refactored the code to be the following

      t = dht_data[2];
      for(uint8_t i = dht_data[3]; i != 0; i--){
        t+= 0.1f;    
      }

And the readings I get now have tenth of a C resolution and make sense as well.

The DHT11s I got are nothing special, just the cheapest thing on AliExpress as of a week or two ago.

Here are images of my setup

If you will accept this change, I will submit a pull request

Also, make sure these boxes are checked [x] before submitting your issue - Thank you!

• [ x] Searched the problem in issues and in the wiki
• [ x] Hardware used : Sonoff Basic R2 V1.0 2017-10-11
• Provide the output of command status 0 :

18:11:43 CMD: status 0
18:11:43 RSL: Group 0, Index 1, Command STATUS, Data 0
18:11:43 RSL: STATUS = {"Status":{"Module":1,"FriendlyName":"Sonoff","Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}}
18:11:43 RSL: STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://domus1:80/api/arduino/sonoff.ino.bin","Uptime":"0T00:00:17","Sleep":0,"BootCount":10,"SaveCount":18,"SaveAddress":"FA000"}}
18:11:43 RSL: STATUS2 = {"StatusFWR":{"Version":"5.12.0","BuildDateTime":"2018-07-08T11:44:03","Boot":6,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
18:11:43 RSL: STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":3,"SysLog":0,"LogHost":"domus1","LogPort":514,"SSId1":"*****","SSId2":"","TelePeriod":300,"SetOption":"00000001"}}
18:11:43 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":477,"Free":524,"Heap":23,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3}}
18:11:43 RSL: STATUS5 = {"StatusNET":{"Hostname":"sonoff-1429","IPAddress":"xxx","Gateway":"xxx","Subnetmask":"xxx","DNSServer":"xxx","Mac":"84:F3:EB:A8:65:95","Webserver":2,"WifiConfig":4}}
18:11:43 RSL: STATUS7 = {"StatusTIM":{"UTC":"Sun Jul 08 17:11:43 2018","Local":"Sun Jul 08 18:11:43 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":1}}
18:11:43 DHT: Received 2F, 00, 19, 02, 4A =? 4A
18:11:43 RSL: STATUS10 = {"StatusSNS":{"Time":"2018-07-08T18:11:43","DHT11":{"Temperature":25.20,"Humidity":47.0},"TempUnit":"C"}}
18:11:43 RSL: STATUS11 = {"StatusSTS":{"Time":"2018-07-08T18:11:43","Uptime":"0T00:00:17","Vcc":3.223,"POWER":"OFF","Wifi":{"AP":1,"SSId":"*****","RSSI":100,"APMac":"****"}}}

To Reproduce
Use a DHT11 sensor, observe you only get 1C resolution

Expected behavior
Use a DHT11 sensor, get the 0.1C resolution the sensor provides

[reloxx13]

read the wiki, read the user_config.h file, search for resolution.
TempRes 0..3
stop wasting your time, drink a beer 🍺

[hydrogen18]

All that does is become the "precision" that is passed into this function

https://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html#ga060c998e77fb5fc0d3168b3ce8771d42

That number could be 100, it'd just show 100 zero's after the decimal. You cannot create the fractional component of a temperature sensor with a library function.

[andrethomas]

I'm not sure fractional precision on a DHT11 is useful anyway - the value will just jump all over the place anyway... the DHT11 is about as stable as a donkey on steroids!

If you want precision rather use a BMPxxx/BMExxx sensor or even an LM75AD - they are fairly cheap and much more reliable in terms of accuracy and hysteria on temperature reporting.

[andrethomas]

@hydrogen18 Did you do some output logging to check the stability of results when adding 0.1-degree resolution?

[andrethomas]

Mine outputs 00's

[Frogmore42]

I don't have any DHT11s. I read about their accuracy (or rather lack there of) and decided there were better choices. Years ago, I got a really good deal (for the time) on SHT-15 sensors. I think I got them for $15/each when they were normally about $50/each. Today, I can get an HTU21 for about $8 with two day shipping and a BMP280 for a dollar or two more. They are all worth the extra money over the DHT11 or even DHT2x.

If you are interested in learning more about the accuracy of different sensors, I suggest looking here:
http://www.kandrsmith.org/RJS/Misc/hygrometers.html
Robert has done an excellent job of documenting his experience and experments with many different sensors.

If the sensors you have are repeatable and reasonably stable having greater resolution can be a good thing, even if absolute accuracy is not so good. As an example, the DS18B20 has an accuracy spec of about +/-1 deg F. Given that, one might think it would make no sense to see/use anything smaller than full degrees. But, I have found them to be very stable. So I use the full resolution and make heater control decisions based on the smallest difference from the set point. Since I am not using a large furnace for heated, I am not concerned about short cycling and prefer it. However, for my dehumidifier, it is most efficient when it runs for a long time. So, I make sure it has been running for at least 30 min. This means that the actual humidity differs from the set point most of the time, but average is close to it. Since it is for moisture control, this works well and saves money.

So, if I had a DHT11 and I found it had stable and repeatable readings, I would think your change makes sense.

[arendst]

@hydrogen18 nice write-up but...

• Your DHT11 has a resolution of +/- 2 degrees Centigrade which makes decimal values useless.
• You might have selected device AM2301 (=DHT22) using the same protocol to talk to the device and uses your "decimal" value out of the box.

[hydrogen18]

@arendst I haven't read the spec sheet for the DHT22 but the code used to compute its value is different. Here's the code for the DHT22

t = (((dht_data[2] & 0x7F) << 8 ) | dht_data[3]) * 0.1;
      if (dht_data[2] & 0x80) {
        t *= -1;
      }

This looks rather different, don't you agree? I'm not sure what they are trying to implement.

With respect to your comment about the sensor, I think you are confusing accuracy vs precision ( I don't know the Dutch words) . Here is a good example of the difference:

https://labwrite.ncsu.edu/Experimental%20Design/accuracyprecision.htm

I don't have any equipment other than a typical Type K thermocouple, so it'd be difficult for me to characterize one of these sensors. But my point is they can have very high precision while still having a poor accuracy of +/- 2 C.

[andrethomas]

@hydrogen18

t = (((dht_data[2] & 0x7F) << 8 ) | dht_data[3]) * 0.1; ** gets byte 2 and 3 to get 10th fractions as you would expect
      if (dht_data[2] & 0x80) { ** checks if the temperature is negative?
        t *= -1;
      }

Again, the results on the DHT11's I have appear to contain nothing in data[3] as quoted earlier up

[andrethomas]

@arendst @hydrogen18 I guess since there is contrast in information available on the DHT11 insofar that some of them provide data in data[3] and others provide a 0 in data[3] (such as the ones I have tested)

Knowing this, adding a PR or manual edit to add code of @hydrogen18 would not imact negatively on sensors which provide a 00 on data[3] anyway, so it will either have 10th temperatures, or not have them depending on whether the sensor sends datain [3]

The two lines suggested by @hydrogen18 will not negatively impact so either add it manually or @hydrogen18 must make a PR for it - Then its fixed at least for those people who are lucky enough to have sensors that provide data in data[3]

Suggestion is therefore to add the following code as it has no negative impact on sensors that do not produce data in data[3] but may have befits for those that do.

for(uint8_t i = dht_data[3]; i != 0; i--){
        t+= 0.1f;    
      }

[arendst]

Updated DHT driver.

Give it a try and let me know the results.

[andrethomas]

@hydrogen18

I think the original code was written with this one in mind:
https://osepp.com/wp-content/uploads/2015/04/DHT11-Technical-Data-Sheet-Translated-Version.pdf

In that, it only mentions 1degC

I think it may be possible that your DHT11 actually contains the same chipset as a DHT12, which has been referenced to provide 0.1 deg C resolution... e.g.

http://www.robototehnika.ru/file/DHT12.pdf

In either event, let us know what happens with the code change that was made.

[hydrogen18]

Hi, I have not had time to test your changes yet.

@andrethomas I agree this is probably a DHT12 labeled as a DHT11. No real reason for a factory to bother manufacturing both.

[ascillato2]

Hi,

If your question has been addressed, please close this issue. Thanks 👍