In therecent past I got to exchange some ideas and opinions on the reliability/accuracy of the DHTxx vs other sensors.
I know it is just a casuistic report but the picture below shows the results of a DHT11 and the BME280, that were 5 cm apart at the time of reading.
As can be seen, the results were as follows:
Temp BME 20.3 C
Temp DHT 21.0 C
Humidity BME 42%
Humidity DHT 43%
That’ s close enough for me
In therecent past I got to exchange some ideas and opinions on the reliability/accuracy of the DHTxx vs other sensors.
Netatmo Weather Station and Rain Detector
I wish I remembered where I heard this quote. “If you have one thermometer you know the temperature. If you have two or more all you have is confusion.”
Those two sets of readings are closer enough to be identical for most proposes. I’m a little surprised given three reputation of the dht11 even compared tother dht22s.
It would be interesting to track the readings over time you see if there is a trend such as they get farther apart at high or low temps or over time.
But for indoor use I think this shows the dhts are plenty accurate enough.
Thanks for posting
That quote is very true.I have an egg incubator that when I tried to trim it with 2 thermometers and a ds18b20, I got 3 readings that were degrees apart.
The DHT11 is not one of my newest, but I will follow that one and the BME for a while, but yes, for indoor use the DHT is good enough
Actually, the BME280 is not good at giving you the actual temperature. It’s really good at tracking changes in temperature. They don’t come calibrated from the factory and will usually give a higher temperature. The Bosch Sensortech BSEC library has the possibility to compensate for it.
I would actually trust more the temperature from the DHT11 as being accurate.
I’ve actually found the same with my DHT22 sensors (supposedly slightly better than DHT11s), they track just fine, but do seem to report higher than actual temperature…But then, my sensors are in an enclosed box with the NodeMCU running them (so the temperature offset may be caused by the MCU heat). I’ve built in calibration offsets into my sensor code, and I go over that in my video here. Spoiler alert: it’s a very linear offset, and I match it to my HVAC thermostat by putting the sensor in the same room as the thermostat for a few days and watching my temperature chart. For the purpose of tracking my temperature in other rooms of the house as it relates to the thermostat room, the sensors do an excellent job.
Also, @rlkoshak I’ve heard a variation of that quote (same general idea): “A man with two watches can’t tell the time”…
Fernando, I am not sure if they come calibrated from the factory, I have to take your word for it and its sensor surely isn’t ideal. I have noticed that in standard mode, i.e. when the BME280 continuously does its conversions, the chip heats up and that is shown by the temperature output. Ths is something that doesn’t happen in Forced mode.
Whether or not the DHT11 is more reliable I dare to doubt as I had various DHT11’ s that next to eachother didn’t even give the same temperature
When it comes to accuracy, I still favor the DS18B12.
Nevertheless, you bring up an interesting point.
@bartus You are right. Seems that they are accurately reporting the rising temperature in your box, caused by the NodeMCU’ s warmth.
As far as different temperature sensors go, in order to calibrate my incubator… I had a DS18B20 plus a digital fever thermomether, plus a classic mercury thermomether, plus the incubator’ s thermostat (an NTC I believe) that all gave different readings, that also didn’t have constant differences.
Also we must realise that there might not be one ubiquitous temperature in a room: I have a DHT22 that can give up to 2 degrees differenc depending whether I attach it to a wall, or say 1 cm away from it.
As far as the watch comparison goes, let me take that into another direction: " A watch that has stopped is more valuable than a watch that goes either too fast or too slow. The latter will never show accurate time while the watch that stopped at least will give you accurate time twice a day
Summarizing, I think the DHTxx’ s might be OK enough just to get a sense of how warm and moist it is in various rooms of my house. If I want to have it really accurate, say for an incubator or to set my heating, i’ d take a DS18B20, while the BME280 in forced mode is ideal for its stability and one chip solution
I’ve found this to be very true. Depending on the box size and materials the NodeMCU can add up to 5 degrees F.
I’ve not gone to the level of calibrating then yet. I just have the sensor hanging out if the box for now. Something I may try at some point. I have them out of the way places so having the sensor sticking it isn’t a problem.
Most likely, the DS18B20 is the most accurate of all sensors mentioned. The Bosch BME 280 is pretty good, too, but it needs compensation. As @fazambuja mentioned, you should integrate the BSEC library for better results. The Bosch BME 280 also needs calibration, which is basically an offset between the measured temperature and the real temperature. By the way, I am using a similar product, the BME 680, for an indoor climate monitor (refer to third section for details).
It is probably some kind of calibration. But let’s say that is not to give the precise temperature out of the box. Here is from their pdf about the BME680:
Looking at a reference thermometer, we can see that our temperature is indeed a few degrees to high. Does that mean the temperature sensor inside the BME680 is inaccurate?
Actually no, it very accurately measures the temperatue exactly where it is located on the board. But there also is the issue: our board as most devices contains some heat sources (e.g., MCU, WiFi chip, display, …). This means the temperature on our board is actually higher than the ambient temperature. Since the absolute amount of water in the air is approximately constant, this also causes the relative humidity to be lower on our board than elsewhere in the room.
As BSEC cannot know in which kind of device the sensor is integrated, we have provide some information to the algorithm to enable it to compensate this offset. In the simplest case, we have to deal with an embedded device with a constant workload and approximately constant self-heating. In such a case, we can simply supply a temperature offset to BSEC which will be subtracted from the temperature and will be used to correct the humidity reading as well.
This document is included here.
Note that is about the BME680 that is basically a BME280 + gas measurements. The BME680 needs to have the heating on for the gas measurements. Not sure if is needed on the BME280. Heating is usually to avoid condensation on sensors working on HVAC and other commercial devices that are more prone to that.
You can find some comparison results between sensors here:
The biggest problem is that the calibration equipment and techniques are usually not easily accessible for most of us. That’s why I kind of lean towards sensors that the manufacturer sells as factory calibrated.
I’m not sure about the DHT11 but:
As previously demonstrated for other sensors (DHT22, SHT71), driving this device too fast can lead to self-heating. Contrary to the other devices though, this can occur straight out of the box, in the factory default configuration.
I never try it. What is cool is that you can do some ice bath calibration since they offer a waterproof version.
Yes, I believe so. However, there is no Arduino documentation for it.
Are you using the BSEC library for Arduino? I have it working on booth pi and esp, but it needs the MQTT part…
Actually, I am using the BSEC library on an ESP8266 with an Arduino API. It was a little tricky to get it running on my SoC, as the BSEC library is quite memory hungry It might or might not be easier on an original Arduino, I can’t really tell.
BME sensors are very accurate. Dont buy pcb with voltage regulators on it!
If you do that you will get false temperatures values (too high)
I was referring to Arduino as ESPs. Would you mind sharing the code? I’m new to openHAB and how it does the mqtt part.
The BSEC Library is trickier, I felt that was easy to get it running on atom with plataformio IDE than the Arduino IDE.
The easiest place to get it running is actually on a Pi.
I believe that would be the Adafruit one that is 5V/3V3? Not sure if the other ones have. I never looked at their design suggestions.
Very valid arguments. as far as I know, the BSEC library allows for an offset. That ofcourse is also possible for any other library.
I run my BME280 away from any other hardware and am using i in Forced Mode so it is les likely to overheat. Ofcourse the BME680 needs to generate heat itself in order to work
Indeed, I think it is the most accurate. can indeed be calibrated in ice water, something that is also possible with the non waterproof version if you only stick the head in the water. Beware that the waterproof version tends to react a bit slower, they are not always solidly filled with resin and can have airpockets.
One of these days I have to o a test between the DS18b20, DHT22, DHT11, DHT21, BME280 and perhaps an NTC. See how that goes
Driving the device too fast
yes, that remark was about the BME280 in factory mode and i experienced that too. Need to drive it in Forced mode. Additionally, I use it outside on an ESP in sleepmode so the selfheating is as minimal as you can practically get.
As a side note, the BME280 and BMP280 have different libraries and the setting of the Forced mode is different
But indeed, the DHT22 should also not be driven too fast. I read it with a 30 or 60 seconds interval and that is uite OK
i will need to give that a look, but as far as the possibility for offset, that alone hardly justifies it. Will look into it
Recently I also got an AM2320, aka a DHT12, which is described as an ‘improved DHT11 with i2C’
I found it to be pretty good. Easy to setup and especially useful if you already are using I2C connections and can’ t spare another pin.
It is pretty accurate and stable. Where with the DHT11 I sometimes had a temporary odd reading, the DHT12 til now has proven to be rocksolid.
Other than with I2C it can also be used in its proprietary one wire connection, but that wasnt an interesting option for me (might as well get a DHT22 then).
next to a BME280 and a DS18B20, the readings pretty close
I am currently checking BME280’s in a 75% rel. humidity reference environment (NaCl salt method). What I found out is, that the sensor (in normal mode) gives 69,2% instead 75% rel.humidity output, but when I create an air flow, it goes up to 72,5 % within several seconds (which is within specs).
I suspected that the self heating of continuous operation of the sensor also generates internally a lower humidity due to the fact that rel. hum. is reduced when air is heated.
I then disconnected the sensor for 30 minutes and reconnected it to power, and it started with 72% and within 30 sec went back to 69,2 %, confirming the relation to self heating.
The conclusion is, if you have low or no air flow in the sensor’s environment, and use the continuous mode, you will have false readings also for humidity due to the self heating.
If you use it outside, the effect will be less due to air flow.
Best would be to use forced mode or even to use a GPIO pin to switch it on only for short time of measurement.
indeed, the continuous mode, that is more or less default does exactly that.
With regard to airflow. Outside I often use temperature and humidity sensors in a piece of vertical pipe. Lower half painted white, upperhalf painted black. Sensor resides in the lower half. The difference in color, in sunlight will create air to rise up in the pipe, even in a greenhouse where there is no wind
Does it work to put the sensor in areas with direct exposition to the sun? even inside a pipe with air flow, I imagine the air would be heated by the sunlight, giving higher temp readings and lower rh readings?
preferably in the shadow, but if I cant, I use the pipe as described and put the sensor in the part thats painted white. Most sun will be reflected while the black part will heat up and create a draft