The DS18B20 node.

What it does.

This node finds every DS18B20 on its wire at startup, reads them all on a cadence you choose, averages each probe's readings across the push window, and sends temperature per probe to an endpoint you own: your own webhook, an MQTT broker you run, Home Assistant, or Open Agriculture Technology.

Here is what the part is actually specified to do. These are the manufacturer's numbers, copied from the sheet rather than rounded off by us:

Two things to take from that table. It is a half-degree part, not a tenth-degree part. Twelve-bit resolution reports hundredths, but resolution is not accuracy: the number moves in steps of 0.0625 °C and is specified to within half a degree of the truth. For a freezer alarm or a compost curve that is plenty; for a calibration reference it is not. Away from the middle of its range it is looser still, ±2 °C at the extremes, which is worth knowing if you are measuring a blast freezer rather than a walk-in.

Read it yourself rather than taking our word for it: the DS18B20 datasheet puts the accuracy in its first paragraph and the resolution table in its Configuration Register section.

It reads the older DS18S20 too. A great many probes in the field are the earlier part, and plenty of multi-packs sold as DS18B20 contain them. They share the wire, the search and the checksum; they differ in that they report 9 bits in half-degree steps, with the finer detail recovered from a pair of count registers, and they have no resolution setting. The node tells them apart by their family code, decodes each correctly, and labels the reading with which one it came from. Nothing for you to set.

It reports what it measured and nothing more. That is the Collect layer at its plainest: a real number out of a real place, reliably, into somewhere that belongs to you.

See it in action: the Open Agriculture Technology Test Endpoint is live right now, our own gateways pushing readings, and yours can join them in minutes.

One wire, many probes.

Most sensors need a bus to themselves or an address you set with a solder blob. A DS18B20 does neither. Every one ever made carries a unique 64-bit address, burned in with a laser at the factory: a family code that says "I am a DS18B20", a 48-bit serial that is that chip alone, and a checksum over both. No two are the same, anywhere, ever.

That is what lets them share a wire. The node starts up and runs a search: it asks every device on the line to shout its address one bit at a time, and walks the tree of answers until it has enumerated all of them. Nothing to configure, nothing to count. Wire one probe or wire nine, and the node reports what it found.

So how many can you actually run? Honest answer: more than you probably need, and fewer than the marketing suggests. The protocol never runs out of addresses. What runs out is signal. Each probe and each metre of cable adds a little capacitance, and the bus talks in pulses about sixty microseconds long, so past a certain point the edges get too soft to read and you start seeing checksum failures rather than a clean stop. On a bench or a single cold room, on the standard resistor, eight to ten probes is comfortable. This node caps its list at ten and says so on the console when the list fills: a bound we chose, not one the chip imposes.

Beyond that, the fixes are the ones any 1-Wire network uses: a stiffer pull-up (2.2 k), a run that goes out and back as one line rather than branching like a star, and eventually an active pull-up chip. If you are wiring a barn rather than a room, that is real engineering rather than a jumper wire, and the manufacturer's application note on long 1-Wire networks is where to start.

Each probe reports under its own factory address, and that is what arrives at your endpoint: ds18b20:28f39296f0013cbd, not "sensor 1". The node names nothing, on purpose. Which probe sits on which shelf is a decision that belongs where it can be edited without a trip to the barn and where it survives a firmware update, and that is the endpoint. We collect and push; the endpoint maps the address to a place and shows you a name.

What you need.

Under fifteen dollars for a one-probe node, and a few dollars a probe after that. Nothing to solder if you buy probes on cable and a board with header pins:

The probe can sit in the cold, in the wet, in the tank. The board cannot: keep it somewhere dry on USB power, in a sealed box if the spot is damp or dusty, and run the cable to the sensor rather than the sensor to the board.

Wire it up.

Three wires and one resistor. Every probe on the run connects to the same three wires. Power off while you wire:

About those colors. They belong to the cable, not the chip. Nearly every sealed DS18B20 probe on the market uses red for power, black for ground and yellow for data, and that is what the photograph at the top of this page shows. A few use white or blue for the data wire instead; if yours does, the odd one out is the data line. A bare three-legged chip has no wires at all: with the flat face towards you and the legs down, the pins are ground, data, power, left to right.

Which pin on the board. One data pin carries the whole bus, and the default differs by chip because the pins you must not use differ by chip:

That last row is the whole reason the defaults are not identical. A 1-Wire bus sits high when it is idle, held there by the resistor, and a strapping pin is read at power-on to decide how the chip boots. Put the bus on one and the board can come up in the wrong mode, which looks like a dead board rather than a wiring mistake. The setup page will refuse a pin that cannot work and tell you why: the flash pins the firmware itself runs from, the strapping pins, the USB pins, the console pins, and on a classic ESP32 the input-only pins that can never talk back. That refusal matters because a pin setting is remembered and re-applied at every boot, so a wrong one is not a mistake you get to notice and correct.

The resistor, and why it is not optional.

This is the one part people leave out, and the node cannot work without it.

A 1-Wire bus is what electronics calls open drain. Every device on the line, including the board, can only ever pull the wire down to ground. Nothing pushes it back up. The resistor is the thing that pulls it back up: a weak, constant tug towards 3.3 V that lets go the instant anything pulls down. That push-pull is how a single wire carries conversation in both directions.

Leave it out and there is no bus at all, only a floating pin picking up whatever is in the air. The node will report no sensor, or worse, it will read something and the checksum will throw it away, which looks exactly like a broken probe. Fitting a resistor is a two-minute job that saves an evening.

One more thing the resistor decides. A DS18B20 can be run on just two wires, stealing its power from the data line between conversations, a trick called parasite power. It works, but a conversion then needs the board to clamp the line high with a much stronger pull-up for the whole conversion, and a node that gets that wrong publishes a fixed 85 °C forever. This node powers its probes properly from 3V3 and does not do parasite mode. It does detect it: if you leave the red wire off, the status page says so plainly instead of pretending the readings are fine.

Flash it.

Plug the board in and press the button for your board. The installer reads the chip on the wire and refuses to write if it isn't the board that image is for, so there is nothing to get wrong.

You'll need a data USB cable (not charge-only) and Chrome or Edge on a computer. A classic ESP32 talks to your computer through a separate USB chip, so the first time you plug one in you may need to install its driver once: look for CP2102 or CH340 printed near the USB socket, then fetch that driver. The S3, C3 and C6 have USB built into the chip and need no driver at all. Once it's flashed, set it up from any phone or laptop.

Prefer the source? Browse it on GitHub: the full project, openly licensed, ready to build yourself.

Set it up.

All the setup happens on the device's own page. Nothing to install, and it works with no internet, which is what you want if you flashed a few at the extension office to take home.

1. Power the node from any USB charger or your computer.
2. On your phone or laptop, join the Wi-Fi network OAT-Setup-XXXXXX (open, no password). A setup page opens by itself; if not, visit http://192.168.4.1.
3. Sign in, then fill in the device name, your Farm ID, the location, your Wi-Fi, and where the readings should go. Press Save & Connect. It joins your Wi-Fi right away and shows you its new address, no reboot, no hunting for it.
4. Back on the setup page, every probe the node found is listed with its own address and its current reading. Note down which address is which place: pinch a probe in your fingers and watch its number climb, and that is the one you are holding. You will want that list when you set the node up at your endpoint.
5. Open the node's Status page, press Send a test reading, and look for the green confirmation that your endpoint received it.

That trick in step four is the whole answer to "which probe is which", and it is worth doing before you seal anything up. Warm one probe in your hand, refresh, and the one that moved is the one you are holding. Write the address down next to the place; that pairing is what you will type in at your endpoint once, and it is the only place it needs to live.

Add a probe later and nothing needs reflashing: wire it onto the same three wires and press re-scan for probes. It appears with its own address and starts reporting immediately. Probes are listed in address order, so the list does not shuffle when you add one.

Two knobs are worth understanding. Read the sensor every is how often it takes a reading; push interval is how often it sends. Every reading taken inside a push window is averaged into the number that gets sent, so reading every 10 seconds and pushing every minute gives you a steadier figure than reading once a minute, at no extra cost. There is also a resolution setting, 9 to 12 bits: twelve is the default and takes three quarters of a second per conversion, nine is coarse and nearly instant. On a cold room, twelve.

If the setup network is being fussy, everything above is also reachable over the USB console: type help for the list, or go straight to wifi, endpoint, name, read, bus and rescan.

Ready to test it? Enter https://iot-test.openagriculturetechnology.com/ingest as the endpoint URL on the setup page, then open the Open Agriculture Technology Test Endpoint and pick your farm, the gateway name you gave the node: your gateway and its probes show up live, readings, charts and heartbeat, no account needed. It keeps about an hour of readings, enough to prove the chain works before you point the node at an endpoint you keep. Prefer a message-by-message check? The conformance sandbox shows each POST checked against the standard.

Knowing you can trust it.

A wired sensor's real failure is almost never the sensor. It is the wire: a tug on the cable, damp in a connector, a run that got extended one too many times. That failure is worth designing for, because the dangerous version of it is not a node that goes silent, it is a node that keeps reporting numbers that happen to be wrong.

So every reading arrives with a checksum, and the node checks it and throws the reading away if it doesn't match. A gap in your data is honest. A plausible wrong number is not. The node also counts "no answer" separately from "bad checksum", because they are different faults: one is a probe that has been unplugged, the other is a bus that is marginal and wants a stiffer resistor or a shorter run.

After several failures in a row the node re-scans the wire, which recovers a probe that was unplugged and put back, or a line that glitched. A re-scan keeps each probe's counters rather than resetting them, because zeroing "reads failed" in the middle of the fault the re-scan exists to fix would hide the one thing worth seeing. And if a probe stops answering altogether, the status page stops showing its last reading and tells you when it was last heard from instead: a number from two hours ago, displayed as though it were current, is its own kind of lie.

Meanwhile the node sends a small heartbeat every 60 seconds whatever else is happening. So when a probe dies the heartbeats keep arriving while the readings stop, and your endpoint can tell the difference between alive but quiet and gone. That distinction is the reason the heartbeat is sent first, before the readings, every cycle.

One more piece of the same habit: each push says how long a stretch its average actually covers. The node keeps reading whether or not the network is up, so the first message after an outage can carry hours of readings, and it says hours rather than repeating the setting you typed.

What it sends.

Two kinds of message, both tiny, and both the same shape every other node in this library sends. Every cycle a batch of readings in canonical units (°C) so the receiver never has to guess; every 60 seconds a lean heartbeat about the node's own health. Both carry a schema tag (oat-ods/0.3) so you can route and version them:

{
  "schema": "oat-ods/0.3",
  "msg_type": "batch",
  "sent_at": "2026-07-25T14:26:00Z",
  "seq": 3000004,
  "source": { "tier": "oat-ds18b20-node", "gateway_id": "walkin-1",
              "farm_id": "riverbend-farm",
              "fw": "OAT-DS18B20-Node/2.0.4" },
  "messages": [
    { "observed_at": "2026-07-25T14:26:00Z",
      "stream": { "id": "ds18b20:28ff641f8c1a3b02",
                  "location": "Walk-in cooler" },
      "measurement": "temperature", "value": 3.44, "unit": "Cel",
      "agg": { "window_s": 60, "samples": 6, "method": "mean" },
      "source": { "physical_id": "ds18b20:28ff641f8c1a3b02",
                  "brand": "Analog Devices", "model": "DS18B20" } },
    { "observed_at": "2026-07-25T14:26:00Z",
      "stream": { "id": "ds18b20:28ff0c2b7d1e4a11",
                  "location": "Walk-in cooler" },
      "measurement": "temperature", "value": 2.19, "unit": "Cel",
      "agg": { "window_s": 60, "samples": 6, "method": "mean" },
      "source": { "physical_id": "ds18b20:28ff0c2b7d1e4a11",
                  "brand": "Analog Devices", "model": "DS18B20" } }
  ]
}

Both stream.id and physical_id are the probe's own factory address, read off the wire at startup, because the node names nothing. location is what you typed at setup, and it describes the node rather than an individual probe. Which probe sits on which shelf is recorded once at your endpoint, where it survives a firmware update and can be edited without a trip to the cold room, and where swapping a failed probe is one line changed rather than a device visit. The farm_id above it groups every node a grower owns.

Want the whole format, both message types, every field, and the full measurement vocabulary? See the developer reference, or read the machine-readable JSON Schema.

For makers & trainers.