The SHT-30 node.

What it does.

An SHT-30 is a small, honest air sensor, and a few dollars on a breakout board. This node reads it on a cadence you choose, averages the readings across the push window so one noisy sample never becomes the number of record, and pushes temperature and humidity 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:

Three things worth understanding before you quote those figures at anyone. Typical is not worst case: the datasheet also plots a maximal-tolerance curve, and it widens as you move toward 0 and 100 %RH, so a sensor sitting in a greenhouse that saturates overnight is working at the loose end of its own spec. The chip is not the product: a cabled probe is an assembly, and the people who build it rate the whole thing, which is why Adafruit publishes ±0.5 °C for its sealed versions rather than the chip's ±0.2 °C. Plan against the number on the thing you actually bought. Repeatability is the row that describes this node: the firmware asks for high-repeatability single-shot measurements, so 0.08 %RH and 0.04 °C is the sample-to-sample noise you should expect to see, before this node averages a window of them.

Read it yourself rather than taking our word for it: the datasheet is nine pages of specification before it gets technical, and Tables 1 and 2 are the two you want.

It does not calculate dewpoint or vapour-pressure deficit, and that is deliberate. The node reports what it measured; whatever reads the data derives the rest. A node that only ever tells the truth about its own observations is a node you can still trust in five years, whoever ends up consuming it.

That is the Collect layer at its plainest. Getting 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.

What you need.

Under fifteen dollars for the plain build, a little more if you want the sensor weatherproofed, and nothing you have to solder if you buy a breakout with header pins already on it:

The sensor wants a spot that sees the air you care about: shaded, out of a direct draft, not touching a warm surface, and not tucked inside the same box as the ESP32, which makes its own heat.

Wire it up.

Four wires, and the pin numbers are chosen for you. Power off while you wire:

About those colors. They belong to the cable, not to the chip, so read them as the common case rather than a law. On the two cabled Adafruit parts, red is power and black is ground on both, and yellow is always the clock. Data is the one that moves: green on the 4099 (sometimes blue on an older run), white on the 5064. Adafruit warns that a few cables leave the factory with data and clock swapped, so if the node finds nothing, swap the yellow and the data wire between pins 21 and 22 and try again. Nothing on this bus is damaged by having those two the wrong way round. A pin-header breakout has no wires at all: the pads are printed, so match VIN to 3V3, GND to GND, SDA to 21 and SCL to 22 by label.

Why 21 and 22, and not any other pair. Most of a classic ESP32's pins are already committed, and the wrong choice fails in ways that look exactly like a broken sensor. Pins 6 through 11 are wired to the flash chip the firmware itself runs from: touch them and the board will not start. Pins 0, 2, 12 and 15 are read at power-on to decide how the chip boots, and a sensor bus sits at a high voltage when it is idle, which is the same nudge that sends the board into the wrong mode. Pins 1 and 3 are the USB console, so using them silences the log you need when something goes wrong. Pins 34 to 39 can only listen, never speak, and this bus needs both. That leaves 21 and 22, which are free, are what the ESP32 expects for this kind of sensor out of the box, and are what the other wired sketches here already use. One wiring habit across the whole library, and both pins are changeable on the setup page if your board is laid out differently.

Flash it.

Plug the board in and press the button. The installer reads the chip on the wire and refuses to write if it isn't the board this 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. 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. Open the node's Status page. The current temperature and humidity are right there, in large type: that is your proof the wiring is right. Then press Send a test reading and look for the green confirmation that your endpoint received it.

The setup network stays on, so you can rejoin any time to change a setting, and your settings survive reboots. A fresh firmware flash wipes them clean, on purpose, so a re-used board never carries the last owner's Wi-Fi or endpoint.

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 are also offsets for temperature and humidity, added to every reading, for lining this node up against a reference you trust.

The two pin fields will refuse a pin that cannot work, and tell you why. That is deliberate: a pin setting is remembered and re-applied every time the board powers on, so a wrong one is not a mistake you get to notice and correct. Some of them would stop the board booting at all, taking the setup page with them.

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, and read.

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 sensors 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.

Two sensors, one node.

An SHT-30 answers to one of two addresses on the bus, decided by its ADDR pin, which means a single board can carry two of them on the same four wires. Leave the first sensor's ADDR pin alone and connect the second one's to 3V3. Wire both to the same SDA, SCL, 3V3 and GND.

Each sensor reports under its own serial, so you get two genuinely separate readings out of one node: inside and outside a hoop house, floor and canopy, the supply air and the room. The node finds whichever sensors are present when it starts, so there is no setting to get wrong, and the status page shows you both. Which serial is which place is recorded at your endpoint, not on the device.

Two is the limit, and it is the chip's limit rather than ours. A third SHT-30 has no address left to answer on.

One catch if you bought a cabled probe: four wires out means the address pin never leaves the sealed end, and it is fixed at the first address. So two probes cannot share a node, but a probe and a breakout can, with the breakout's ADDR pin tied to 3V3.

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. After several failures in a row the node rebuilds its connection to the sensor and resets it, which recovers a confused wire without anyone driving out to power-cycle a box. And if the sensor 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.

The status page and the console both show the running counts: readings good, readings failed, checksums failed, and how many times the connection had to be rebuilt. That is how you answer "is my wiring actually alright?" instead of guessing.

Meanwhile the node sends a small heartbeat every 60 seconds whatever else is happening. So when a sensor 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 and %RH) 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-sht30-node", "gateway_id": "gh2-north",
              "farm_id": "riverbend-farm",
              "fw": "OAT-SHT30-Node/2.0.4" },
  "messages": [
    { "observed_at": "2026-07-25T14:26:00Z",
      "stream": { "id": "sht30:0a1b2c3d",
                  "location": "Greenhouse 2 / North bench" },
      "measurement": "temperature", "value": 23.41, "unit": "Cel",
      "agg": { "window_s": 60, "samples": 6, "method": "mean" },
      "source": { "physical_id": "sht30:0a1b2c3d",
                  "brand": "Sensirion", "model": "SHT30" } },
    { "observed_at": "2026-07-25T14:26:00Z",
      "stream": { "id": "sht30:0a1b2c3d",
                  "location": "Greenhouse 2 / North bench" },
      "measurement": "humidity", "value": 58.7, "unit": "%RH",
      "agg": { "window_s": 60, "samples": 6, "method": "mean" },
      "source": { "physical_id": "sht30:0a1b2c3d",
                  "brand": "Sensirion", "model": "SHT30" } }
  ]
}

{
  "schema": "oat-ods/0.3",
  "msg_type": "status",
  "observed_at": "2026-07-25T14:26:00Z",
  "state": "online",
  "source": { "tier": "oat-sht30-node", "gateway_id": "gh2-north",
              "farm_id": "riverbend-farm",
              "device_id": "oat-3c8a1fa77d14",
              "fw": "OAT-SHT30-Node/2.0.4" },
  "health": {
    "uptime_s": 315, "boot_count": 2, "reset": "poweron",
    "free_heap": 214800, "min_free_heap": 203600, "largest_block": 110592,
    "rssi": -68, "wifi_reconnects": 0, "push_ok": 5, "push_fail": 0,
    "transport": "https", "tls_ok": true, "chip": "ESP32",
    "temp_c": 54.4, "loops_per_sec": 1120,
    "lan_ip": "192.168.1.37", "ssid": "BarnWiFi", "mdns": "oat-gh2-north.local"
  }
}

The physical_id is the sensor chip's own serial number, read off the part at startup. The stream.id is the name you gave the place. That split is the point: swap a failed sensor for a new one and the history of that spot carries straight on, with the change of hardware visible in the record.

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.