rtl_433_ESP: running rtl_433 device decoders on an ESP32 radio

Why a weather sensor needs a 433 MHz receiver at all

The project is an attempt at creating an Arduino library for use on ESP32 boards with a CC1101 transceiver or SX127X transceivers, carrying the device decoders from the rtl_433 package, and it is intended to be available for use with OpenMQTTGateway as an available module.

That is the whole idea in one paragraph. rtl_433 is the well known software that turns a cheap radio into a stream of decoded sensor readings, and it normally runs on a PC with a USB dongle. This port moves the decoding onto the microcontroller itself, on a board that already has a radio soldered next to it, and the result is a self-contained receiver that can sit next to the sensors and publish over the network.

The hardware reference in the readme is the LILYGO LoRa32 V2.1_1.6.1 433MHz board running OpenMQTTGateway, and the inspiration is credited to the ESPiLight effort.

The intended user is therefore a home automation builder, an IoT tinkerer or a facilities person with a house full of 433 MHz thermometers, rain gauges and door sensors, who wants the readings in Home Assistant or an MQTT broker without a Linux box and a USB stick. GPL-3.0 is the licence, and the project is not archived, with the last push on 2026-09-25.

A trial port with a subset of upstream, not a mirror of it

The honest framing is in the readme: the initial port implements only enables a subset of the available modulations and device decoders, and is limited to devices the author has access to and can test with.

That sentence matters more than any feature list. The rtl_433 upstream carries a large catalogue of device protocols, and this port ships a bundled subset of them, refreshed from a development snapshot. The most recent refresh was on August 14, 2026, from rtl_433 development snapshot 25.12-346-g91b2ebdb, commit 91b2ebdb, and the release notes for v0.6.0 describe refreshing the rtl_433 decoders from the rtl_433 August 2026 release.

The cadence is visible in the release history itself. v0.6.0 on 2026-08-16 was the upstream decoder refresh, v0.6.1 on 2026-08-28 added more regression testing, and v0.6.2 on 2026-09-09 improved CC1101 Vivint reception. That last one is instructive, because it is a change to the radio side rather than to the decoders, and it shows what happens when a decoder is ported but the hardware behaviour is not yet right.

The repository also documents where the boundaries are. Architecture, task ownership, callback context, lifecycle and resource notes are in docs/ARCHITECTURE.md, and the upstream refresh procedure is in docs/UPSTREAM.md. A reader who wants to know how to add a device or how to update the decoders has a documented path rather than guesswork.

Ook and FSK, and why you cannot run both at once

The demodulation side is the part with a hard physical constraint, and the readme is explicit about it: FSK or OOK demodulation mode can not be used simultaneously, due to the usage of the receiver chipset's signal demodulator.

This is a limitation of the radio, not of the software. The CC1101 contains one demodulator in the receiver chain, and the chip is configured into either an OOK mode or an FSK mode at a time. Asking for both at once is asking the hardware to do two different things, so the port exposes the choice as a configuration setting.

The OOK side covers a good spread of pulse encodings:

OOK_MC_ZEROBIT
OOK_PULSE_DMC
OOK_PULSE_MANCHESTER_ZEROBIT
OOK_PULSE_NRZS
OOK_PULSE_PCM
OOK_PULSE_PIWM_DC
OOK_PULSE_PPM
OOK_PULSE_PWM
OOK_PULSE_PWM_OSV1
OOK_PULSE_RZ

And the FSK side is smaller:

FSK_PULSE_MANCHESTER_ZEROBIT
FSK_PULSE_PCM
FSK_PULSE_PWM

OOK is what most cheap 433 MHz sensors and remotes use, which is why it gets the longer list, and the readme notes the practical consequence for anyone planning an installation: the receiver is not as sensitive as an rtl_sdr and the author gets about half the range or less, and having the antenna oriented into a vertical position does improve reception.

The bundled decoder list is long and the protocol numbers are fixed

The device decoders are listed in the readme as the same registration output upstream rtl_433 produces, which is a convenient way to see exactly what is compiled in. The entries start with a protocol number and a name:

Registering protocol [0] "Amazon Basics Meat Thermometer"
Registering protocol [1] "Acurite 896 Rain Gauge"
Registering protocol [2] "Acurite 609TXC Temperature and Humidity Sensor"
Registering protocol [3] "Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas"
Registering protocol [4] "Acurite 986 Refrigerator / Freezer Thermometer"

The catalogue that follows runs through Acurite and Auriol temperature and humidity sensors, Baldr pool and rain sensors, Bresser thermo-hygro sensors, Cotech anemometers and rain gauges, Fine Offset weather stations, the FS20 and FHT family, and continues into numbered protocol identifiers well past seventy in the visible portion of the list.

Two things to notice. The first is coverage: cheap consumer sensors from many brands are in there, which is the practical case for the port. The second is that the protocol number is part of the identity, and that is a numbering scheme inherited from upstream. If you compare the numbers here with the numbers in an upstream rtl_433 build, they are the same scheme, but the set of protocols actually present differs, because this port enables a subset. A decoder index from one build is not a stable identifier across builds, which matters if you plan to key anything on it.

Building it: the library layout and the compile examples

The repository is laid out as a C library with an Arduino flavour. There is a library.json and a library.properties at the root, which are the manifests the Arduino and PlatformIO ecosystems use, alongside include/, src/, signals/, a tools/ directory, a test/ directory, a contrib/ directory and a pyproject.toml that configures codespell and setuptools. The .clang-format and uncrustify.cfg files, together with the pre-commit configuration, tell you the project expects its own formatting to be applied before a commit.

The examples directory is where a first build would start, and its four entries are telling:

- examples/MinimalCompile/ is the smallest thing that compiles - examples/OOK_Receiver/ and examples/FSK_Transmitter/ are the two directions of use - examples/cc1101_tuning/ is for working out the radio settings

The readme itself does not give an install command, so the practical route is to add the repository as a library in the Arduino IDE or as a dependency in a PlatformIO project, using the manifests at the root, and then start from the examples. The compile example is the right first target, because it verifies the toolchain and the decoder set before any radio behaviour is involved.

The upstream decoders arrive as a git submodule, since the .gitmodules file is present at the root, which is how a large set of upstream sources is vendored without being duplicated in the history.

What a gateway integration actually gets you

The point of the port is not the decoding, it is the topology. OpenMQTTGateway is a firmware for ESP32 boards that bridges various radio protocols to MQTT, and rtl_433_ESP is offered as a module for it. Once the device decoders are running on the board, a 433 MHz thermometer becomes an MQTT topic, and everything downstream, Home Assistant, Node-RED, a database, is unchanged.

The advantage over a USB dongle is physical. A receiver on the same board as the gateway needs no USB port, no driver, no second machine and no USB extension cable, and it keeps working when the host is off. For a sensor network spread across a house, an ESP32 with a CC1101 mounted near the devices is a far neater installation than a Pi with a dongle in a cupboard.

The cost is the sensitivity the author describes, about half the range of an rtl_sdr, which is the price of moving from a dedicated USB receiver with a proper front end to a transceiver module designed for transmission as much as reception. The note about orienting the antenna vertically suggests the layout is not forgiving.

The scope limit is the other thing to weigh. A subset of modulations and decoders, limited to devices the author could test, means the library covers the common cases well and the unusual ones not at all. For a set of sensors you already own, check the list before anything else.

Editorial conclusion

Adopt rtl_433_ESP if you already run OpenMQTTGateway on an ESP32 and want cheap 433 MHz sensors decoded and published over MQTT without adding a USB receiver to the machine, because the library brings the rtl_433 device decoders to a board that already has a radio attached. Do not adopt it if you need to decode a protocol the upstream project handles with an FSK or OOK mode that the port leaves out, or if reception range matters more than cost, since the author reports roughly half the range of an rtl_sdr. Before you commit, check the enabled modulation list and the decoder list against the sensors you actually own, since the port covers only a subset of what upstream rtl_433 supports, and read docs/UPSTREAM.md, which describes how the bundled decoders are refreshed from upstream.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. NorthernMan54/rtl_433_ESP on GitHub
4. README
5. Releases