Skip to main content

rtl_433

rtl_433 is a generic data receiver and decoder for the unlicensed ISM (Industrial, Scientific, Medical) and SRD (Short Range Device) bands. Despite the name, it is not limited to 433 MHz: it works mainly on the 433.92 MHz, 868 MHz, 315 MHz, 345 MHz, and 915 MHz bands. Point a cheap RTL-SDR dongle at the air and rtl_433 will demodulate and decode the chatter from the wireless sensors all around you — weather stations, indoor/outdoor thermometers, tire pressure monitoring systems (TPMS), energy and utility meters, soil-moisture probes, door/window contacts, and remote controls.

It is a portable C99 program that runs on Linux, macOS, Windows, and embedded boards such as the Raspberry Pi, and it requires very little in the way of resources.

At a glance
  • What it is: a command-line decoder for ISM/SRD-band wireless telemetry.
  • Hardware: RTL-SDR (Realtek RTL2832-based DVB dongles) and SoapySDR devices (LimeSDR, PlutoSDR, HackRF One, SoapyRemote).
  • Decoders: 320+ built-in device protocols.
  • Output: human-readable log, key-value, JSON, CSV, MQTT, InfluxDB, syslog, HTTP, and more.

What it does

Most consumer environmental and telemetry sensors broadcast small unencrypted packets on the ISM bands using simple OOK/ASK or FSK modulation. rtl_433 captures the raw IQ stream from the SDR, slices it into pulses, and runs those pulses through a library of device-specific decoders. When a decoder recognizes a packet, it emits a structured record describing the device and its readings.

This turns an inexpensive radio dongle into a passive receiver for a huge range of off-the-shelf sensors — without pairing, accounts, or vendor hubs.

Signal flow

The path from radio waves to a structured record looks like this:

  1. Antenna / RF — sensors transmit short bursts on an ISM band.
  2. SDR — the dongle tunes to a center frequency and streams IQ samples to the host.
  3. rtl_433 — pulse detection plus a matching device decoder produce a record.
  4. Output — the record is written in your chosen format, ready to log, publish, or store.

Quick start

With a supported dongle plugged in, the simplest invocation listens on the default 433.92 MHz band and prints decoded events:

rtl_433

Select a different band and sample rate:

rtl_433 -f 868M -s 1024k

Emit JSON and republish each line over MQTT with the standard Mosquitto client:

rtl_433 -F json -M utc | mosquitto_pub -t home/rtl_433 -l
Reduce CPU and noise

Enable only the decoders you actually use with -R (it can be given multiple times). Running every decoder all the time is convenient for discovery but wastes cycles and can produce spurious matches.

rtl_433 -R 1 -R 8 -R 43

Common command-line options

These are the options you will reach for most often. Values quoted from the manual page.

OptionMeaning
-f <frequency>Receive frequency(s) (default: 433920000 Hz). Repeat to poll several bands.
-s <sample rate>Set sample rate (default: 250000 Hz).
-d <device>RTL-SDR USB device index/serial, SoapySDR device query, rtl_tcp, or help.
-g <gain>Gain (default: auto); dB for RTL-SDR or gain elements for SoapySDR.
-R <device>Enable only the specified device decoding protocol (can be used multiple times).
-F <format>Produce decoded output in a given format; append :<filename> to write to a file.
-M <meta>Add metadata (e.g. time, protocol, level, stats) to each output record.
-C native|si|customaryConvert units in decoded output.
-H <seconds>Hop interval for polling of multiple frequencies (default: 600 seconds).
-APulse Analyzer: enable pulse analysis and a decode attempt (useful for unknown signals).

The -F flag accepts: log | kv | json | csv | mqtt | influx | syslog | trigger | rtl_tcp | http | null.

Configuration file

Most options can also be set in a configuration file so that a long command line does not have to be retyped. See the CONF documentation in the repository for the file format and search order.

Output records

Decoded events share a common set of field names regardless of device, which makes downstream parsing and storage straightforward. Some of the most common JSON fields:

FieldDescription
timeTimestamp of message reception.
modelHuman-readable string concisely describing the device (manufacturer/model).
idDevice identification, used to differentiate between devices of the same model.
channelSecondary identification for multi-sensor devices.
battery_okBattery status from 0 (empty) to 1 (full).
temperature_CTemperature measurement (also temperature_F).
humidityHumidity from a hygrometer sensor in % relative humidity.
wind_avg_m_sAverage wind speed.
rain_mmRainfall accumulation.
pressure_hPaAir or tire pressure measurement.
micIntegrity check method (CRC, CHECKSUM, or PARITY).

Illustrative example. The following shows the shape of a JSON line for a weather sensor. Exact fields vary by device — treat this as a sketch, not output captured from a specific decoder.

{
"time": "2026-05-31 12:00:00",
"model": "AmbientWeather-WH31E",
"id": 197,
"channel": 1,
"battery_ok": 1,
"temperature_C": 21.4,
"humidity": 48,
"mic": "CRC"
}

Installing

Pre-built packages exist for many platforms; building from source is straightforward with CMake.

On Debian/Ubuntu, install the dependencies and build:

sudo apt-get install libtool libusb-1.0-0-dev librtlsdr-dev rtl-sdr build-essential cmake pkg-config
git clone https://github.com/merbanan/rtl_433.git
cd rtl_433/
cmake -B build
cmake --build build --target install

On macOS with Homebrew:

brew install rtl-sdr cmake pkg-config

See the BUILDING documentation for Fedora/RHEL, MacPorts, Ninja builds, TLS support, and nightly package repositories.

Where to go next

  • Getting started — connect a dongle, scan the bands, and capture your first reading.
  • Decoders — browse the 320+ supported device protocols and learn to enable them selectively.
  • CLI reference — the full option set, metadata flags, and unit conversion.
  • Integrations — feed decoded data into MQTT, InfluxDB, Home Assistant, and other systems.

Sources