LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

When it comes to home automation, people often end up with devices supporting the Zigbee or Z-Wave protocols, but those devices are relatively expensive. When I was looking for a way to keep an eye on the temperature at home a few years ago, I bought a bunch of cheap temperature and humidity sensors emitting radio signals in the unlicensed ISM (Industrial, Scientific, and Medical) frequency bands instead. Thanks to rtl_433 and, more recently, rtl_433_ESP and OpenMQTTGateway, I was able to integrate their measurements easily into my home-automation system.

Unlicensed spectrum

Most of the radio spectrum is licensed by national regulators to specific users. This is why mobile operators or TV broadcasters have to pay a hefty licensing fee for the exclusive right to transmit on a specific frequency. The upside is that they can be relatively sure that no one else interferes with their transmissions.

However, there are also some frequency bands that are free to use by any transmitter: the ISM bands. That's why many manufacturers of doorbells, weather stations, and all sorts of wireless sensor devices choose to transmit in those bands. The specific frequencies depend on the region, as the radio regulations from the International Telecommunication Union (ITU) divide the world into three regions with their own frequency allocations.

Because devices don't have an exclusive right to transmit in the ISM band, there's much more potential for interference. However, manufacturers have to follow some rules, for instance about the permitted transmit power and the duty cycle (the maximal ratio of time transmitting over total time). That's why, in many situations, interference isn't that bad, for example when a lot of temperature sensors transmit every minute with a random start time.

To be able to read the sensor measurements, three things are needed: a receiver, an antenna, and a decoder. The first two are quite easy to find. A decoder is sometimes a bit more effort. Many of these sensors use a proprietary protocol, but luckily most don't use any encryption. There's a whole community of enthusiasts who try to reverse-engineer protocols of wireless sensors and implement decoders in open-source software.

A generic data receiver

The most well-known project to capture wireless sensor measurements is Benjamin Larsson's GPLv2-licensed rtl_433. It's a generic data receiver for the 433.92MHz, 868MHz, 315MHz, 345MHz, and 915MHz ISM bands. At the time of writing, the project's README on GitHub lists 234 supported device protocols, ranging from temperature sensors, soil-moisture sensors, wireless switches, and contact sensors to doorbells, tire-pressure monitoring systems, and energy monitors.

Rtl_433 is written in C99 and compiles on Linux, macOS, and Windows. Low resource consumption and few dependencies are two of its main design goals. This makes it possible to run rtl_433 on embedded hardware, like routers. The Raspberry Pi is also supported well.

The software supports various receivers using Osmocom's rtl-sdr or Pothosware's SoapySDR to interface with SDR (software-defined radio) devices. The rtl-sdr project builds on the discovery from more than a decade ago that a cheap DVB-T TV tuner dongle with the Realtek RTL2832U chipset can be used to build a wideband software-defined radio receiver. There are now even RTL-SDR dongles that are specifically designed for SDR purposes. So rtl-sdr talks to the RTL-SDR dongle, which returns the radio signal that is then decoded by rtl_433 and translated into sensor measurements from specific supported devices. In the same way, SoapySDR acts as a driver for other SDR devices, such as LimeSDR and HackRF One.

Using rtl_433

The cheapest way to start with rtl_433 would be to buy such an RTL-SDR dongle. This also requires an antenna, preferably one with a length that works well with the wavelength for the frequency of the target devices. Some RTL-SDR dongles come in a kit with a telescoping dipole antenna, dipole base, tripod mount, and other accessories. At RTL-SDR.com there's a thorough explanation of how to use the dipole antenna kit. Something to be mindful of: when plugging the RTL-SDR dongle directly into a USB port, it will pick up a lot of RF noise from the computer. Using a short USB extension cable avoids this.

After installing udev rules for the RTL-SDR and connecting a supported RTL-SDR dongle with its antenna, just running rtl_433 finds the dongle and configures it to start listening at 433.92MHz with a sample rate of 250,000 samples per second. The software immediately starts spitting out decoded sensor measurements for all devices transmitting in the neighborhood. Rtl_433 supports a lot of options to choose the frequency, sample rate, device decoders, and output format.

Integrating rtl_433 with a home-automation system

Rtl_433 can be run as a service, for instance using a systemd service unit. George Hertz has created a multi-architecture Docker image, hertzg/rtl_433, that also runs on the Raspberry Pi. For automated processing, rtl_433 supports publishing sensor measurements to an MQTT broker, an InfluxDB time series database, or a syslog server. The MQTT export is especially interesting: many home-automation controllers, including Home Assistant and openHAB, support MQTT.

There are some caveats to using rtl_433 for home automation. First, although many of these devices transmit an ID to be able to distinguish them, their ID changes after replacing the battery. So a rule such as "if the temperature of the sensor with ID 106 is above 8 degrees, send a warning" needs to be changed after replacing the device's battery. Luckily it's quite common to run these devices a year or longer on a battery. Another drawback is that most of these devices transmit their data unencrypted. So they're not recommended for critical purposes, as people can sniff or even spoof the transmissions.

Adding support for new devices

Rtl_433 is a collaborative effort, with many developers adding support for their wireless devices. The project has some documentation about supporting new devices. The endeavor always starts with recording test signals representing different conditions of the sensor, while taking note of what the device is showing on its display at the same time of the signal.

The project has extensive documentation about SDR concepts, I/Q (in-phase / quadrature) formats, and pulse formats. This is all necessary background information to be able to analyze the signals for adding support for a new device. There's also a step-by-step plan to analyze devices.

Rtl_433 also has a lot of supporting web-based tools to analyze signals. For instance, to visualize the I/Q spectrogram of test signals (seen above at left), to view and analyze pulses from test signals, and even to analyze bit strings to get an idea of what's in the data. All these are powerful tools that help with reverse-engineering the protocol and adding a decoder for the device to rtl_433.

Receiving sensors with a microcontroller

While rtl_433 is a powerful solution, the fact that it needs a computer with a full operating system can be a disadvantage. Some people prefer using a microcontroller, which runs more reliably and with lower power consumption. One of these solutions is Florian Robert's GPLv3-licensed OpenMQTTGateway. It not only supports receiving measurements from Bluetooth Low Energy devices, it also supports various RF devices using different receiver and decoder modules. The list of supported devices is big, but it depends on the microcontroller and receiver hardware you set up.

The results of the measurements are published to an MQTT broker, for instance for integration in Home Assistant or another home-automation gateway. OpenMQTTGateway even supports Home Assistant's autodiscovery protocol. So all sensors the device recognizes will automatically be added into Home Assistant's devices, ready to be shown on its web-based dashboard (seen above).

On boards with an ESP32 microcontroller, OpenMQTTGateway 1.0 introduced support for a subset of the rtl_433 decoders. It does this by using NorthernMan54's GPLv3-licensed Arduino library rtl_433_ESP. This is a port of rtl_433 to the ESP32 microcontroller, using a CC1101 or SX127X receiver chip. These two are popular chips built into boards combining a microcontroller and receiver module. While rtl_433 implements signal demodulation in software, rtl_433_ESP uses the receiver chipset to do this. This limits the available device decoders, but at this writing, 81 of the 234 decoders of rtl_433 will run on the ESP32.

Conclusion

Since the first time I bought 433MHz sensors, I have put one in every room at home, in my fridge, my freezer, and on my terrace outside. I have been running rtl_433 with an RTL-SDR dongle for years on a Raspberry Pi to receive all these sensor measurements. The data are sent to the Eclipse Mosquitto MQTT broker and then fed into the home-automation controller Home Assistant.

Recently I have been evaluating OpenMQTTGateway with rtl_433_ESP on a LILYGO LoRa32 V2.1_1.6.1 433MHz board (seen at right). Since it seems to support all of my 433MHz temperature sensors, I'm considering a switch to this lower-power solution, which will free up the RTL-SDR for other purposes. However, the rtl_433_ESP's README mentions that the CC1101 receiver module is not as sensitive as the RTL-SDR dongle, resulting in only half the range. I had the same experience with the SX127X receiver on the LILYGO board. But those boards are so cheap that I could easily place a couple in various places to receive all of my sensors. Since they all send their decoded sensor values to the same MQTT broker, the result should be the same as having a single receiver with a longer range.

With this setup, Home Assistant allows me to see the temperature and humidity around the house in a web-based dashboard; I even get warnings when the temperature of the fridge or freezer rises too much. Other people are using sensors to monitor their pool temperature, their oil tank's level, water leaks, or the wind speed measured by their weather station.

All in all, these tools are quite useful for receiving measurements from a wide range of cheap wireless sensors. For a better range, more decoders, or when preferring a computer over a microcontroller, rtl_433 is a good choice. In other cases, OpenMQTTGateway with rtl_433_ESP on an ESP32 microcontroller board is a welcome addition to the toolbox of the open-source home-automation enthusiast.

---

(Log in to post comments)