Temperature and humidity sensors compared: DHT22 vs SHT31 vs BME280

If you have searched for a temperature and humidity sensor for a project, these three part numbers came up. They measure the same two things and cost roughly the same order of money, and they behave quite differently once they are wired up. The right one depends on how you will read it, how fast conditions change, and how much you care about the second decimal place.

What the three sensors have in common

All three measure air temperature and relative humidity with a small capacitive humidity element and a temperature sensor on the same part, which puts them in the first two groups of the IoT sensors overview. All three are sold on inexpensive breakout boards that a development board can read directly. All three are widely supported, with libraries for the Arduino environment, MicroPython and the common no-code firmware projects. And all three are affected by the same things: where you put them, how much heat the board around them produces, and how much air moves past them.

They differ in how they talk to the microcontroller, in the class of accuracy the manufacturer specifies, in how quickly they follow a change, and in what else they measure.

DHT22: cheap, slow and single-wire

The DHT22 (also sold as the AM2302, and documented in the manufacturer Aosong’s AM2302 datasheet) is the oldest and cheapest of the three. It communicates over a single data wire using a timing-based protocol of its own, in which the microcontroller pulls the line low to request a reading and then measures the length of the pulses the sensor sends back. That protocol needs careful timing, and on a busy microcontroller, or one running a Wi-Fi stack that interrupts the program, reads occasionally fail and have to be retried. The libraries handle the retry, but it is a source of noise in logs.

The sensor can only be read every couple of seconds, which is fine for a room and too slow for anything that changes quickly. The manufacturer’s specified accuracy is looser than the other two, particularly for humidity at the extremes of the range, and units vary more from one to the next.

Its virtues are price and ubiquity. Almost every tutorial ever written about a humidity sensor uses one, so the wiring and the code are known to work. For a room monitor where a degree or two does not matter, it is adequate.

SHT31: an I2C sensor built for humidity

The SHT31 belongs to a family from Sensirion, a manufacturer that specializes in humidity sensing; the SHT3x datasheet on that site is the reference for its figures. It communicates over I2C, the standard two-wire bus that most digital sensors use (the I2C vs SPI guide explains both buses), which means reads are quick, reliable and easy to share with other sensors on the same two pins. The specified accuracy is tighter than the DHT22’s, especially for humidity, and units are consistent.

It responds to changes in humidity faster than the DHT22, which matters for anything that needs to catch a short event, such as a door opening in a cold store or a shower running. It includes a small heater that can be switched on briefly to drive off condensation after the sensor has been in a very humid environment, which the other two lack. Related parts in the same family trade accuracy for price in both directions, so if the SHT31 is too much or too little sensor, a sibling exists.

The SHT31 measures temperature and humidity only. For most projects that is the point.

BME280: temperature, humidity and pressure in one

The BME280 from Bosch Sensortec adds a barometric pressure sensor to temperature and humidity, over I2C or SPI. That third measurement is why it appears in weather station projects and in anything that needs altitude or pressure trends. The temperature and humidity accuracy class is broadly comparable with the SHT31 for most purposes, with humidity a little looser in the specification.

The BME280’s known weakness is self-heating. The sensor die warms slightly when it is running, and on a small breakout board with no airflow that warmth shows up as a temperature reading a little above ambient, which in turn pushes the relative humidity reading a little low. The effect depends on how often the sensor is sampled and on the board layout. It is manageable: sample infrequently, use the sensor’s low-power mode, keep it away from the microcontroller’s own heat, and apply a small offset if you have a reference to compare against.

Two related parts are easy to confuse with it. One sibling measures pressure and temperature but no humidity, and is often sold under a nearly identical name. Another adds a gas sensor. Check the part number on the chip, not just the listing.

Comparison table

The figures are deliberately qualitative. Each manufacturer publishes a datasheet with the specified accuracy bands, response times and operating ranges, and those numbers change between revisions of the part; read the datasheet for the exact part you buy rather than a number quoted second-hand.

Which sensor for which project

For a room or greenhouse monitor that reports every few minutes and where a degree of error is acceptable, the DHT22 is fine and the cheapest. If you are fighting failed reads on a Wi-Fi board, spend the little extra on an SHT31 and the problem goes away.

For anything where humidity is the point (a drying cabinet, a humidor, a cold store, a damp problem, an incubator), use the SHT31. The tighter humidity accuracy, the faster response and the condensation heater are all built for that job.

For a weather station, a barometer, or any project that wants pressure trends, use the BME280, and take care with placement and sampling to keep self-heating in check. If you do not need pressure, the SHT31 gives you cleaner temperature and humidity for similar money.

For a battery node, all three can be put to sleep between readings. The I2C sensors wake and respond quickly, which keeps the microcontroller’s awake time short and the battery budget small; the DHT22’s slow read cycle keeps the board awake longer. That is a small but real difference over a year on a battery.

Getting good readings from any of them

Placement first. A sensor reads the air around it, and the air around a development board is warmer than the room. Mount the sensor on a short lead away from the board, or on the far side of an enclosure with vents, and keep it out of direct sunlight and away from anything that warms or cools locally, such as a radiator, a window or the exhaust of a fan.

Airflow second. Still air around a sensor lags the room. A little movement, even from convection through a vented enclosure, brings the reading closer to reality and makes the response faster. A sensor sealed in a box with the electronics is measuring the box.

Sampling third. Read as often as the decision needs and no more. Frequent reads warm the sensor (the BME280 in particular), spend battery, and produce data nobody looks at. A room changes over minutes; a reading every minute or two is plenty.

Then check against something. None of these sensors is a reference instrument, and a cheap one can be a degree or two out. Comparing against a second sensor, or against a known condition such as a saturated salt solution for humidity, tells you the offset, and most firmware lets you apply one. Do the check once when the node is built and again if the readings ever look wrong.

With those four habits, all three parts give readings that are good enough for the jobs above. Without them, the most expensive sensor will still tell you the temperature of the board it is bolted to.