Arduino Temperature Control Library: the DS18B20 and its relatives

The reference driver for Maxim's One Wire sensors

The library describes itself as a robust and feature-complete Arduino library for Maxim Temperature Integrated Circuits, and it is the library most people meet first when they wire a DS18B20 to an Arduino.

The reason it is so widely used is not the code, it is the accumulation. A One Wire sensor is a 1-Wire bus device with a 64-bit address, a conversion cycle that takes time, and a parasitic power mode where the sensor draws its energy from the data line. Each of those has a failure mode that produces a wrong reading rather than an error, and a library that has been used by a large community for years has had those failure modes found and handled.

The API shape is the familiar Arduino one. You create a OneWire object for the bus, hand it to a DallasTemperature object, call begin in setup, request temperatures in the loop, and read by index or by address. The example in the README is short enough to be read in one go:

#include <OneWire.h>
#include <DallasTemperature.h>

// Data wire is connected to GPIO 4
#define ONE_WIRE_BUS 4

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);

The library depends on the OneWire library by Paul Stoffregen, which the README asks you to install alongside it, and the examples directory includes a oneWireSearch example, which is the first thing to run when a new sensor does not answer.

Six sensors, and two voltage traps

The supported devices table is short, and the notes column is where the useful information is.

The DS18B20 is the reference device, running at 3 to 5 volts. The DS18S20 also runs at 3 to 5 volts but is 9 bit only, and the DS1820 is likewise 9 bit only and runs at 5 volts. The DS1822 runs at 3 to 5 volts. The MAX31820 runs at 3 volts, marked with a warning in the table, and the MAX31850 and MAX31851 are thermocouple parts running at 3 to 3.7 volts, also marked.

Those two warnings matter more than they look. A DS18B20 will happily run from a 5 volt rail, and a MAX31820 will not, and the failure mode of exceeding the supply is not a clean error on every part. If you are ordering a sensor for a project and the only spec you have is a temperature range, check the table.

The 9 bit only note is about resolution, and it interacts with the configurable resolution feature of the library. A 9 bit reading is eight times coarser than a 12 bit one, which for a DS18B20 means about 0.5 degrees of quantisation rather than about 0.0625. If your application needs fine resolution, that note tells you which parts to avoid.

The list is also a snapshot of the sensor family rather than a promise of new parts, and the library's own repository history shows that the same driver has been extended over years, with multiple sensor support, address-based reading and asynchronous mode arriving as separate contributions, which the credits section attributes by name.

The pull-up resistor, where most projects go wrong

The hardware setup section is short and it contains the single most common failure cause in this whole area.

Connect a 4k7 ohm pull-up resistor between the 1-Wire data line and 5 volt power. The README adds the caveat that this applies to the Arduino platform, and that for ESP32 and ESP8266 you will need to adjust the resistor value accordingly, which is the correct advice, since those boards run their I/O at 3.3 volts and a 4k7 resistor to a 5 volt rail will damage the pin.

The pinout note is also specific. For the DS18B20, ground pins 1 and 3, with the centre pin being the data line. The flat-face orientation is the usual way to find that, and getting it wrong is a classic cause of a sensor that never answers.

For reliable readings, the README points at the pull-up requirements in the DS18B20 datasheet, page 7. That pointer is worth taking, because the 4k7 value is a starting point rather than a rule. The bus has capacitance, the wire has length, and the number of devices on it changes the loading, and the datasheet explains the relationship.

The examples directory backs this up with dedicated examples for the cases that trip people up: ExternalPullup for a board with a resistor you cannot remove, and TwoPin_DS18B20 for a sensor wired to two pins instead of three, plus readPowerSupply for checking the power state of a sensor.

Address-based reads, async mode and resolution

The advanced features list is where the library earns its name.

Multiple sensors on the same bus is the first, and the reason the library exposes addresses at all. Temperature conversion by address, with getTempC(address) and getTempF(address), is what makes a multi-sensor setup manageable, because index-based reads depend on the order the bus enumerates in, and that order is not guaranteed to be stable across resets.

Asynchronous mode, added in v3.7.0, is the second. The normal flow is blocking: you request temperatures, wait for the conversion to complete, and then read. On a device with a 12 bit resolution the conversion takes close to a second, and the obvious implementation of the loop above wastes most of that time in a delay. Asynchronous mode lets the request and the read be separated, so the sketch can do other work while the sensor converts.

Configurable resolution is the third, and it interacts with the conversion time. Higher resolution means a longer conversion, so a project that reads every second and wants the finest resolution is asking for a trade the library will let it make but cannot make for it.

The examples directory shows the API in use rather than describing it, with SaveRecallScratchPad for the non-volatile memory in the sensor, SetUserData and UserDataWriteBatch for the per-device user bytes, and two examples, WaitForConversion and WaitForConversion2, that exist purely to show how the conversion wait should be handled.

Trimming the library for small builds

The configuration options section describes a compile-time trim, which matters on the smaller boards this library is often used on. You can slim down the code by defining two macros at the top of DallasTemperature.h:

#define REQUIRESNEW      // Use if you want to minimise code size
#define REQUIRESALARMS   // Use if you need alarm functionality

This is an old-fashioned mechanism, and a deliberate one. On a microcontroller, flash is the scarce resource, and a driver that supports alarms, scratchpad persistence, user data, blocking and asynchronous conversion, and address and index reads, is carrying code that a given sketch may never call. Two macros let the linker drop the parts you do not need.

The Alarm and AlarmHandler examples in the repository are the counterpart to the second macro, and they are the reason the macro exists as an option rather than a removal. A library that simply dropped alarm support would be smaller, and would break the projects that use it.

The other build-time knob is the language library itself. The repository carries a library.json and library.properties for the Arduino tooling, a keywords.txt for syntax highlighting, and a CMakeLists.txt at the root, which is how the same source is built outside the Arduino IDE.

Where this library is the wrong choice

The first wrong-tool case is a sensor that is not One Wire. The overwhelming majority of modern temperature sensors are I2C or SPI, and those need a different driver entirely. A library built around a 1-Wire bus cannot be adapted to a two-wire sensor, because the addressing model, the conversion cycle and the power strategy are all properties of the bus.

The second is a thermistor or a thermocouple front end. The MAX31850 and MAX31851 in the table are thermocouple amplifiers, which is the exception rather than the rule, and there is no support here for a bare thermocouple or for a resistive sensor divided down to a voltage.

The third is a design that needs better than 12 bit resolution, or a measurement that has to be traceable. These are cheap digital sensors with a fixed conversion pipeline, and while the resolution is configurable, the accuracy specification and the self-heating of the part on a breadboard are the limits. A thermistor with a good curve fit or a platinum sensor will beat a DS18B20 in a controlled environment.

The fourth is a battery-powered node where the bus matters. The One Wire bus has to be pulled high continuously, which is a permanent current draw, and the 1-Wire protocol has an idle state that is not free. A microcontroller that spends its life asleep on a coin cell is a different design problem from one that reads a temperature every few seconds.

MIT, version 4.0.6, and a library that outlived the sensors

The library is MIT licensed, with the LICENSE file at the repository root and the notice reading MIT License, Copyright (c) 2026 Miles Burton.

The release list shows v4.0.6 from 2026-02-13, v4.0.5 and v4.0.4 both from 2025-09-02. Patch releases on the same day, and a release in between, is the pattern of a mature library that gets small fixes rather than redesigns. The repository is not archived, and the last push was on 2026-04-12.

The continuity is credited by name. Original development by Miles Burton, multiple sensor support by Tim Newsome, address-based temperature reading by Guil Barros, and async mode by Rob Tillaart. Those four contributions map exactly onto the four advanced features, which is a good illustration of how a small library accumulates capability.

The tooling is what you would expect from a project with a long history and a modern maintenance setup. There is an.arduino-ci.yml and an.arduino_ci/ directory for the Arduino CI harness, a workflow for arduino-lint and one for a JSON check, a.devcontainer/ with a VS Code development container, an arduino-cli.yaml, a build.sh, a Gemfile, and a test/ directory.

The development container is the part worth reading, because it tells you how the library is verified. Inside it you run arduino-build to compile the library and the examples, arduino-test to run the test suite, and arduino-build-test for the whole process, and the note says that it currently compiles against the arduino:avr:uno environment. So the continuous integration proves the library builds and passes its tests for the AVR Uno, and nothing more.

Editorial conclusion

Adopt the Arduino Temperature Control Library if your project uses a Maxim One Wire temperature sensor and you want the well-trodden path, with address-based reads, multi-sensor support and regular patch releases. Do not adopt it for a modern I2C or SPI digital sensor, for a thermistor, or for a factory-fresh design where the One Wire bus and its pull-up resistor are a cost rather than a convenience. Before you wire anything, read the pull-up requirement in the DS18B20 datasheet, note that the 4k7 ohm value is for the Arduino platform and needs adjusting on ESP32 and ESP8266, and check the supported voltage for the part you actually bought, since two of them will not run at 5 volts.

Frequently asked questions

Official sources

1. License: MIT
2. milesburton/Arduino-Temperature-Control-Library on GitHub
3. Project website
4. README
5. Releases