library.properties, not the C++, is what a release is

Four files, and two layers inside them

The source tree is DHT.cpp and DHT.h for the sensor itself, and DHT_U.cpp and DHT_U.h for the wrapper. That pairing is the whole design and it is the reason the library has a dependency. The raw files talk to the DHT series directly, the low-cost temperature and humidity sensors the README describes, and the U pair adapts them to the Adafruit Unified Sensor base class, which the dependency list names as the Adafruit Unified Sensor Driver. The point of that base class is uniformity: a sketch that has several kinds of sensor can hold them in one collection and ask each one the same questions, without special-casing the temperature probe. If you are writing firmware where the temperature sensor is one of five, that is worth the extra dependency. If it is the only sensor, the raw pair is enough and the base class is ceremony. The two examples in the repository, DHTtester and DHT_Unified_Sensor, carry names that match those two layers exactly, so the intended usage modes are visible from the directory listing alone.

The manifest is the release

There is a file in the repository called library.properties, and it explains more about how this project ships than any other file in it. It is the Arduino library manifest, the metadata the Library Manager reads to know the library's name, version, author and compatibility, and it is the reason the release history reads the way it does. Version 1.4.6 is described in the release list as a version bump in library.properties, which means a release of this library can be nothing more than a number changing in that file. Version 1.4.5 is described as an update of the CI Actions versions, which is a maintenance release in the sense the Arduino community means, the build passing again against current tooling. Version 1.4.7 is dated 2026-03-03, which is also the date of the last push to master. So the release cadence is irregular by design, the artefact is a folder you install rather than a binary you download, and there is no changelog file in the tree to tell you what changed between 1.4.5 and 1.4.7.

Install it from the Library Manager, not from a clone

The installation instruction is one sentence: use the Arduino Library Manager, search for DHT sensor library, and install it. That is the supported path, and it exists because the Library Manager resolves the dependency as well, so a beginner does not have to know that the wrapper needs the Adafruit Unified Sensor Driver before the example sketch will compile. The dependency is stated explicitly in the README under a heading of its own, linked to the Adafruit_Sensor repository, which is the convention this project uses for anything a consumer must also install. The learning material is at the same level of specificity: the README points to DHT tutorials hosted on Adafruit's learn site, and that page rather than the repository is where the wiring, the pin requirements and the choice between sensor models are explained. The address it points at is:

https://learn.adafruit.com/dht

For a library this old and this widely copied, that is the arrangement you would expect. The code, the wiring and the timing knowledge live in three different places, and the repository is the smallest of them.

keywords.txt is a file about the person using the library

One entry in the file list deserves an explanation because it is specific to this ecosystem: keywords.txt. In the Arduino IDE, a library can ship a list of the names it defines so the editor highlights them as you type, the way an editor knows a function name from a variable name. Shipping that file is a small courtesy that makes a sketch that calls the library read as code rather than as a wall of grey identifiers, and its presence in this repository says the project cares about the experience of the person typing, not only the person compiling. The other non-code file, .clang-format, says something similar from the other direction, since it fixes the formatting of any contribution so a diff is about behaviour rather than about spaces. Both are tiny, and both are the kind of thing a small hardware library usually omits. The presence of a lower-case code-of-conduct.md alongside a capitalised CONTRIBUTING.md is a smaller inconsistency of the same family, and the README links the code of conduct as something to read before contributing.

Documentation is a contribution requirement here

The README has a section on documentation and doxygen, and its instruction to contributors is specific: documentation is produced by doxygen, and contributions should include documentation for any new code added. That is a stronger requirement than most libraries make, and it is the right one for a device driver, where the API is a set of calls a beginner copies from a tutorial and pastes into a sketch with no other reference. If the doc comment is wrong, the tutorial is wrong, and the failure is silent because the code compiles. The README then links two guides on using doxygen, one on the general practice and one with tips, both on Adafruit's learn site, which tells you the organisation treats documentation tooling as something a contributor needs to be taught rather than assumed. The broader statement in the README is that contributions are welcome and that you will also learn how to best use the library and probably some C++, which is a fair description of what happens when a hardware library has to be read closely to get the timing right.

The licence, and an attribution line worth reading

The licence is MIT, with the text in license.txt, and that is the easy half. The README adds a sentence that a redistributor should not skip: all the text above must be included in any redistribution. That is an attribution obligation attached to the README's own content, stated separately from the MIT grant, and it is a slightly unusual place to put one, since the MIT licence already requires retaining the copyright notice. In practice, if you vendor this library into a firmware image, a product, or a tutorial of your own, keep the README with it, and do not assume the MIT grant is the only thing being asked of you. The project also names a long list of contributors, introduced as work by around two dozen named people and written by Adafruit Industries, which is a useful signal about the shape of the project. It has been maintained by many hands over years rather than by one maintainer responding to issues, and the list includes both the original authors of the protocol work and the people who later fixed it for newer boards.

What the repository does not tell you

The honest limit of this documentation is that it is a pointer, not a manual. The README does not state the minimum interval between sensor reads, which for this family of parts is the single fact that most often causes a beginner's first readings to fail. It does not describe what the library returns when a read is corrupted, and whether that is a sentinel value, a retry or a failure code. It does not list which boards have been tested, beyond the CI badge in the README header. It does not say which sensor models in the DHT series the code covers, beyond the description naming the DHT11 and DHT22 and the rest as and so on. All of that is presumably in the linked tutorials, and for a library this widely used it is likely documented somewhere, but if you are evaluating it from the repository alone then the answer is that the repository does not tell you. For a decision about a library, that is fine. For a decision about how to use it, open the tutorial page first.

Against a bus-based sensor, and against writing the timing yourself

There are two other reasonable choices for a temperature and humidity reading on a microcontroller, and the difference is interface rather than accuracy. A sensor that reports over a digital bus, whether that is a two-wire or a four-wire protocol, gives you a library with a register map, a device address and a checksum, and none of the timing to learn, at the cost of more pins and a slightly higher price. Writing the read yourself, which is what a lot of DHT code in the wild amounts to, is a hundred lines of bit-banging and a second-hand timing constant, and it is a bad trade against a maintained library that already exists. The case for this particular library is that it is the reference implementation, that it is MIT, that it comes with the unified-sensor wrapper so it fits a mixed sensor array, and that Adafruit's tutorial material sits behind it. The case against is that a sensor with a digital interface removes the entire class of problem this library exists to manage.

Editorial conclusion

Adopt this library if you are wiring a DHT11 or DHT22 to an Arduino and want the Adafruit unified sensor pattern so a sketch can treat it like any other sensor. Do not adopt it on the strength of the repository README, which is deliberately short, so read the linked tutorial for the wiring and timing questions the code does not answer. Verify four things before you rely on it: that you install the Adafruit Unified Sensor dependency as well, since the wrapper needs it, which library version the Library Manager actually gave you, since the release history shows 1.4.5 from 2023-05-22, 1.4.6 from 2023-11-15 and 1.4.7 from 2026-03-03 with a gap of more than two years in between, that the attribution line the README requires is preserved if you redistribute, and what the library does when a sensor read fails, which the README does not document. The licence is MIT with the text in license.txt, and the last push to master was 2026-03-03.

Frequently asked questions

Official sources

1. adafruit/DHT-sensor-library on GitHub
2. License: MIT
3. Project website
4. README
5. Releases