The Radio Sensor Listener.

Pick your listener.

One sketch, four builds on this page. Which one you flash follows from what you own, because a radio hears one kind of signal at a time and the kind is fixed when the image is built. Choose, and the page shows that build alone. (Build 4, a CC1101 with our own AcuRite decoder, is still on the bench page.)

Not sure which yours is? Find your sensor below: type its name and the table answers with the build.

Find your sensor.

Type a make or a model. The answer is the build that hears it, the band to set, and how sure we are. Heard on our bench means exactly that. Decoder in the image means a decoder for that device (the rtl_433 project’s, or ours on Build 5) is in the image we ship and we have not yet heard one ourselves. No decoder means nothing open decodes it, and the note says what to do instead.

Your station or sensor

That table is the short list. The long one is not typed by anyone: it is generated from the two registration lists inside the decoder library our images are built against (rtl_433_ESP, commit 236c816, read 2026-09-18), so a device cannot appear under an image that does not link its decoder. The search box above filters these too. Many entries are not weather sensors at all: doorbells, tyre-pressure sensors, remotes. They arrive as raw values; nothing is dropped.

What it does.

Consumer weather stations are two parts: a sensor array outdoors and a display indoors, joined by a one-way radio link. The array does not know or care what receives it. This node is a second receiver. It hears the same broadcasts, decodes them, and harvests every value each device sends: temperature, humidity, wind speed, gust and direction, rainfall, UV and light, soil moisture, lightning strikes and distance, battery state. Each device becomes its own stream at your endpoint under its own broadcast id, and each reading arrives in canonical units, so a mile-per-hour station and a metre-per-second station look the same to whatever reads them.

Nothing about the station changes. The display keeps working. The station keeps its batteries. No pairing, no app, no account, and the station’s maker never knows. That is the Collect layer applied to hardware you already paid for, and it is the question the Home Assistant forums have asked for years: how do I get my cheap weather station’s data without the vendor’s cloud?

On the CC1101 builds the decoders are not ours, and that is the point. They are the rtl_433 project’s, built up over a decade, ported to the ESP32 as rtl_433_ESP. Our sketch wraps them as a driver on the shared OAT node core and maps what they decode onto the OAT vocabulary. A new station is a decoder upstream, not a sketch release. The bare-receiver build is the deliberate exception: those decoders need a radio that reports signal strength, a bare receiver has none, so that image carries a single hand-written decoder for the AcuRite 5-in-1. Build 5 is the other exception: the CC1101 frames the Ecowitt sensors’ messages itself, and our own decoders check and read them. What each build hears is stated inside that build, below, and nowhere else.

How it works.

1. The station broadcasts, the way it already does. AcuRite every 18 seconds; other makes every 30 to 60 depending on the model.
2. On a CC1101 build the radio watches the signal level on the band. When it jumps above the noise floor, the library captures the pulse train and hands it to the rtl_433 decoders, which try each protocol until one’s checksum passes. On the bare-receiver build there is no signal level to watch, so the sketch times every pulse itself and waits for the four-pulse sync an AcuRite 5-in-1 sends, then checks the frame’s checksum and parity. On Build 5 the CC1101 does the listening in hardware: it recovers the bits, waits for the Ecowitt sync word and stores the whole frame, and the sketch reads it and checks the sensor’s CRC and sum.
3. The decoded message names the model, the station’s id, and its readings. This sketch turns the model and id into a stream id, maps each reading onto the OAT vocabulary with the unit converted, and folds it into that stream’s window. A station repeats each message, three times back to back on an AcuRite, so an identical message from the same station within two seconds is counted as a repeat and not folded again; samples counts transmissions.
4. On a timer, the node core pushes one signed batch to your endpoint, or publishes to your broker, exactly as every OAT gateway does. Every 60 seconds it sends its own heartbeat.

Because a station’s two message types arrive at different moments, and because a windy minute produces more wind readings than a calm one, everything continuous is averaged over the push window and everything cumulative or directional keeps its latest value. Rain arrives as the station’s running total, never as a delta, so a missed broadcast loses nothing and rainfall per hour is a subtraction at your endpoint. Wind direction is never averaged, because the mean of north and north-north-west is not a direction.

One more honest detail. Neither radio is as sensitive as a software-defined-radio dongle with a proper antenna. The library’s authors report about half a dongle’s range for the CC1101; we have not measured it on our bench yet, and the comparison will carry the number when we have. The bare receiver heard our Iris across tens of metres with a poor antenna. For the far pasture, put the listener out there on a LoRa node.

Set it up.

The same one form as every OAT gateway, served by the device itself, plus two fields of its own. The steps are the same on every build.

1. Power the board from any USB charger. 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.
2. Sign in, fill in a name, your Farm ID, the location, your Wi-Fi, and where the readings should go. Press Save & Connect.
3. The Band. On Build 1 it is fixed at 433.92 by the receiver module. On Build 2 leave it at 433.92, where AcuRite, La Crosse TX141 and Oregon Scientific broadcast. On Builds 3 and 5 set your region’s band (915.00 is the default). On a CC1101 a change retunes the radio on the spot. The field’s own help text says what the image you flashed decodes.
4. Watch Stations heard on the same page. Your station appears on its next broadcast with its model, how long ago, and on a CC1101 its signal strength. Give it a minute; a station that only broadcasts every 60 seconds needs one. A station that goes quiet for ten minutes is marked silent and its stream released; it files straight back in when heard again. The table holds 32 rows, and a new station arriving when all are taken takes over the row that has been silent longest.
5. If the neighbours’ stations show up too, copy your station’s id into the allow-list and save. Only the listed ids are reported from then on; the match is exact, so acurite-5n1:748-A does not also admit acurite-5n1:7480-A.
6. Open the Status page and press Push now. A green “OK” means your station’s readings just reached your endpoint.

Ready to test it? Enter https://iot-test.openagriculturetechnology.com/ingest as the endpoint URL, then open the Open Agriculture Technology Test Endpoint and pick your farm. The listener appears as a gateway with your station and each sensor listed under it. It keeps about an hour of readings, enough to prove the chain before you point it at an endpoint you keep.

Setup card: Build 1, the receiver (PDF) Setup card: Build 2, CC1101 (PDF) Setup card: Build 5, Ecowitt (PDF)

A three-page field card per build, because what you need on hand and what can go wrong differ: what to have ready, the flash and setup steps, blanks for this node’s settings and ids, the console commands, and the fixes for the usual snags. Print one per node.

What it sends.

Ordinary oat-ods, tagged oat-weather-listener. Each station or sensor is one stream named by its broadcast id, and every quantity it sends is one observation in canonical units with the aggregation stated.

{
  "schema": "oat-ods/0.3",
  "msg_type": "batch",
  "sent_at": "2026-09-05T15:12:00Z",
  "seq": 2000018,
  "source": { "tier": "oat-weather-listener", "gateway_id": "barn-wx",
              "farm_id": "willow-oaks", "fw": "OAT-Weather-Listener/1.1.0" },
  "messages": [
    { "observed_at": "2026-09-05T15:12:00Z",
      "stream": { "id": "acurite-5n1:2716" },
      "measurement": "wind_speed", "value": 2.34, "unit": "m/s",
      "agg": { "window_s": 60, "samples": 3, "method": "mean" },
      "source": { "physical_id": "acurite-5n1:2716", "brand": "AcuRite", "model": "Acurite-5n1", "rssi": -63 } },
    { "observed_at": "2026-09-05T15:12:00Z",
      "stream": { "id": "acurite-5n1:2716" },
      "measurement": "wind_direction", "value": 225, "unit": "deg",
      "agg": { "window_s": 60, "samples": 3, "method": "last" } },
    { "observed_at": "2026-09-05T15:12:00Z",
      "stream": { "id": "acurite-5n1:2716" },
      "measurement": "rain_total", "value": 128.52, "unit": "mm",
      "agg": { "window_s": 60, "samples": 2, "method": "last" } },
    { "observed_at": "2026-09-05T15:12:00Z",
      "stream": { "id": "acurite-5n1:2716" },
      "measurement": "temperature", "value": 27.4, "unit": "Cel",
      "agg": { "window_s": 60, "samples": 1, "method": "mean" } },
    { "observed_at": "2026-09-05T15:12:00Z",
      "stream": { "id": "acurite-tower:11743-A" },
      "measurement": "humidity", "value": 58, "unit": "%RH",
      "agg": { "window_s": 60, "samples": 4, "method": "mean" },
      "source": { "physical_id": "acurite-tower:11743-A", "brand": "AcuRite", "model": "Acurite-Tower", "rssi": -71 } }
  ]
}

The whole format, every field and the full vocabulary are in the developer reference. If you write endpoints, the section on gateways that carry other sensors is the one that applies: a listener is a gateway pushing readings that are not its own, and the four rules there are all an endpoint needs.

Into Home Assistant.

Choose MQTT as the delivery method on the setup page and point it at the broker Home Assistant already uses (the Mosquitto add-on, usually). The listener then publishes one retained message per reading on a topic named for the listener and the station's own id, oat/<listener>/<station id>/<measurement>, and keeps oat/<listener>/status at online with a Last Will that flips it to offline if the board drops. Home Assistant reads those with its MQTT integration, one small YAML block per reading. The sketches do not send Home Assistant’s discovery announcements, so the entities are yours to declare, which also means you name them once and they never rename themselves.

1. Install the Mosquitto broker add-on if you have not, and the MQTT integration. Note the broker’s address, user and password.
2. On the listener’s setup page choose MQTT, enter the broker, user and password, leave the topic prefix at oat. Save.
3. Add one mqtt: sensor: block per reading to configuration.yaml, using the topics you see under Stations heard. The value is value_json.value; the status topic gives availability. Reload the MQTT entities (or restart) and they appear.

   mqtt:
     sensor:
       - name: "Iris temperature"
         unique_id: barn_wx_acurite_5n1_748_a_temperature
         state_topic: "oat/barn-wx/acurite-5n1:748-A/temperature"
         value_template: "{{ value_json.value }}"
         unit_of_measurement: "°C"
         device_class: temperature
         state_class: measurement
         availability:
           - topic: "oat/barn-wx/status"
             value_template: "{{ value_json.state }}"
             payload_available: "online"
             payload_not_available: "offline"

4. Put the entities on a dashboard. The agricultural cards page has the wind rose and rain cards; the weather-station guide walks the whole thing with screenshots and the automations that make a station useful, frost warning first.

The same MQTT path feeds anything else that speaks MQTT: Node-RED, Grafana through Telegraf, a spreadsheet through a five-line script. And the webhook path feeds anything with a URL. The Home Assistant guide covers the other two ways a station reaches Home Assistant too, through an Ecowitt or Ambient hub or a Tempest hub, for people who already own one.

As a pod on a LoRa node.

The station is in the far field and there is no Wi-Fi there. Fine. This listener also prints every reading it hears on its USB serial port in the oat-line grammar, whether or not Wi-Fi is configured. Cable that port to the LoRa Field Node’s pod port with three wires, and every station this listener hears rides to the house over LoRa as a cluster of sensors on that node, under the same stream ids. Move the station to the barn later and the same board, with the Wi-Fi form filled in, pushes directly. Same firmware. The difference is configuration.

Why a second board rather than a decoder inside the field node? Because the decoders want a radio to themselves and a processor that is doing nothing else, and the field node is already reading probes and running its own radio. A pod does one job, and any board can be one.

Stations that talk to a hub instead.

Some stations cannot be heard by a build this page offers today: most of the Ecowitt family beyond the WH31, WH51 and WN34 until Build 3 has been benched, and a few models with no open decoder at all. Or you already own the vendor’s hub and it is sitting on your network. Those feeds are still yours, and they arrive at your endpoint through a different door: the gather bridge, a small Python program that runs on the same machine as your endpoint or Home Assistant and turns a hub’s feed into oat-ods. Three sources are built in:

A hub feed needs no ESP32 at all. It is the right choice when the hub is already there. The listener is the right choice when you want the readings without the hub, or the station has no hub, or the station is out of Wi-Fi range.

Honest limits.

• One kind of signal per image. AcuRite and its kin switch a carrier on and off. Ecowitt and its kin shift a carrier’s frequency. The radio chip demodulates one or the other, and which one is fixed when the image is built. A property with both needs two boards.
• One band at a time. A CC1101 tunes from 300 to 928 MHz but listens on one frequency. The band is a setting; changing it retunes on the spot.
• Two builds have been heard on our bench. Build 1, with an AcuRite Iris, and Build 5, with an Ecowitt WH31B, two WH51 and a WN34, both in Tennessee. Build 2 is offered as beta on the strength of the rtl_433 project’s decoders and has not run here yet. Build 3 has not heard a sensor, and its images sit on a separate bench page so nobody mistakes them for a proven build. Every row in the device table says which of those it is.
• Less range than an SDR dongle. The library’s authors report about half. We have not measured a CC1101 yet. Height and a wire antenna cut to the band buy more than anything in software.
• Some devices have no open decoder. Among Ecowitt’s: the WN30, the WN35 leaf-wetness sensor, the WN36, the older WH41 and the WFC01 water valve. The table names them so nobody buys one expecting this to hear it; the vendor’s hub through the bridge carries them.
• Stations that re-roll their id. A few models pick a new id every battery change. The history at your endpoint splits at that point; the endpoint’s map from id to place is where you reconnect it. The AcuRite Iris keeps its id.
• Davis is not on the list. Its frequency-hopping protocol is reverse-engineered and fragile. Use the WeatherLink Live hub through the bridge.
• Cloud-only stations. Netatmo and similar talk to their maker’s servers and nothing local. There is nothing here to hear.
• Near a LoRa node. Our own LoRa field nodes default to 915.0 MHz, the same frequency US Ecowitt sensors use. A listener on Build 3 or 5 beside busy LoRa nodes will lose some sensor frames to them; on our bench a LoRa node a few feet away cost 18 dB of signal until it was switched off. Keep the antennas apart, and move the LoRa plan off 915.0 on a site that runs both.

For makers & trainers.