How to Build a Wireless Sensor Decoder Agent with RTL-433 and OpenClaw on Raspberry Pi
rtl_433 decodes signals from over 320 wireless device protocols using a cheap USB radio dongle. Pairing it with an OpenClaw AI agent on a Raspberry Pi gives you anomaly detection, cross-sensor correlation, and automated responses on top of the raw telemetry. This guide covers the full stack from hardware to working agent.
What rtl_433 Does and Why It Matters for IoT
rtl_433 is an open-source program that decodes radio transmissions from devices on the ISM bands. Plug in a $30 RTL-SDR USB dongle, run the software, and you immediately start receiving data from weather stations, tire pressure monitors, soil moisture sensors, door/window contacts, energy meters, and hundreds of other devices broadcasting in your vicinity.
The project supports 320 device protocols as of version 25.12 (released December 2025). It covers the 433.92 MHz, 868 MHz, 315 MHz, 345 MHz, and 915 MHz bands. Most consumer wireless sensors broadcast unencrypted on these frequencies, which means a single receiver picks up everything within range.
Output goes to stdout as JSON by default. You can also push directly to MQTT, InfluxDB, or HTTP endpoints. The default MQTT topic structure is rtl_433/<hostname>/devices/<type>/<subtype>/<channel>/<id>/, which gives you per-device topics without any custom parsing.
The gap in most rtl_433 setups: data gets collected but nobody watches it intelligently. You end up with thousands of JSON lines per hour and no system to flag when a temperature reading spikes outside normal range, when a sensor stops reporting, or when two sensors show contradictory data. That is where the AI agent layer comes in.
What Hardware Do You Need?
The bill of materials is short and inexpensive.
Raspberry Pi:
- Pi 5 with 8 GB RAM is ideal. Runs both rtl_433 and OpenClaw comfortably with headroom for MQTT and data logging.
- Pi 4 with 4 GB works. You will notice slower agent responses during complex multi-step reasoning, but the sensor decoding itself is unaffected since rtl_433 uses minimal CPU.
- Pi 4 with 2 GB is the absolute minimum. You need swap configured and should expect occasional slowdowns.
RTL-SDR Dongle:
- RTL-SDR Blog V4 ($30, USB-C, tunes 500 kHz to 1.7 GHz) is the current recommendation. The R828D tuner chip and TCXO give stable frequency accuracy without drift.
- Nooelec NESDR Mini 2+ ($25) is a solid alternative with a smaller form factor.
- Any RTL2832U-based dongle works. Avoid the cheapest generic units since they lack a TCXO and drift with temperature.
Antenna:
The stock whip antenna included with most dongles receives 433 MHz adequately within 30-50 meters. For better range, a quarter-wave ground plane antenna (a 17 cm wire soldered to an SMA connector with four radials) extends reception to 100+ meters and costs under $5 in parts.
Storage:
A 32 GB microSD card works for the OS and software. If you plan to log raw sensor data long-term, add a USB SSD. Sensor telemetry at one reading per sensor per minute from 10 sensors generates roughly 50 MB per month in JSON, so storage is rarely the bottleneck.
Installing rtl_433 on Raspberry Pi OS
Start with a fresh 64-bit Raspberry Pi OS Lite installation. The Lite (headless) edition uses less RAM, which matters since OpenClaw will claim a significant portion.
Install the build dependencies and compile from source to get the latest protocol support:
sudo apt update && sudo apt install -y \
build-essential cmake git libusb-1.0-0-dev \
librtlsdr-dev rtl-sdr pkg-config
git clone https://github.com/merbanan/rtl_433.git
cd rtl_433 && mkdir build && cd build
cmake ../ && make -j$(nproc)
sudo make install
Compilation takes 3-5 minutes on a Pi 5, closer to 10 minutes on a Pi 4. Once installed, plug in your RTL-SDR dongle and test:
rtl_433 -C si -F json
The -C si flag outputs temperatures in Celsius and distances in meters. You should see JSON lines appearing as nearby sensors transmit. Most 433 MHz sensors broadcast every 30-60 seconds, so wait at least a minute.
To blacklist the kernel DVB-T driver (which conflicts with SDR use), create a file:
echo 'blacklist dvb_usb_rtl28xxu' | sudo tee /etc/modprobe.d/blacklist-rtl.conf
Reboot once after this change.
Running as a Systemd Service
Create /etc/systemd/system/rtl433.service:
[Unit]
Description=RTL-433 Sensor Decoder
After=network.target
[Service]
ExecStart=/usr/local/bin/rtl_433 -C si -F "mqtt://localhost:1883,retain=1,devices=sensors/rtl_433/[/model][/id]" -F "json:/var/log/rtl433/sensors.json"
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
Enable and start it:
sudo mkdir -p /var/log/rtl433
sudo systemctl daemon-reload
sudo systemctl enable --now rtl433
Now rtl_433 publishes decoded sensor data to MQTT and logs JSON to disk continuously.
Setting Up OpenClaw as the Analysis Layer
With rtl_433 streaming data, you need something to watch it and act. OpenClaw fits this role because it can execute shell commands, read files, schedule recurring tasks, and reason about the data it receives.
Installing OpenClaw
OpenClaw requires Node.js 24+ and a 64-bit OS. Install on the same Pi:
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
During onboarding, choose a cloud-hosted model provider. Anthropic's Claude or OpenAI work well. Do not attempt to run local LLMs on the Pi since even small models are too slow to be useful for real-time sensor analysis.
Verify the installation:
openclaw status
systemctl --user status openclaw-gateway.service
Connecting OpenClaw to Sensor Data
The simplest integration pattern is file-based. rtl_433 already writes JSON to /var/log/rtl433/sensors.json. Create an OpenClaw skill that tails this file, parses new readings, and reasons about them.
The alternative is MQTT subscription. If you install an MQTT broker (Mosquitto is standard), OpenClaw can subscribe to topics and receive sensor updates in real time. The file-based approach keeps the agent and the decoder loosely coupled, which simplifies debugging.
Defining the Agent's Behavior
OpenClaw uses a SKILL.md file to define what tools are available and how the agent should behave. For a sensor monitoring agent, the skill definition describes the data sources, the thresholds that matter, and the actions to take when anomalies appear.
The agent can run shell commands to query the latest readings, parse JSON output, compare current values against historical baselines, and trigger notifications through configured channels like Telegram, Discord, or email.
Persist your sensor telemetry and agent reports across sessions
50 GB free workspace for your Raspberry Pi agent. Auto-indexed for search, shareable with your team, no credit card required. Connect via the Fast.io MCP server.
How to Build Anomaly Detection and Cross-Sensor Correlation
Raw sensor decoding is table stakes. The real value of adding an AI agent is pattern recognition across multiple data streams.
Anomaly Detection Patterns
Configure the agent to watch for conditions that simple threshold alerts miss:
- Rate-of-change spikes. A temperature sensor jumping 10 degrees in 5 minutes indicates a sensor failure or an actual emergency, not normal weather. The agent can distinguish between the two by checking whether neighboring sensors show similar movement.
- Silent sensors. When a device stops transmitting, rtl_433 stops producing output for that ID. The agent tracks expected reporting intervals and flags sensors that go silent, which often means dead batteries.
- Cross-sensor contradiction. If your indoor humidity sensor reads 20% while the outdoor sensor reads 95% and the window sensor shows "open," the agent can correlate these and alert you about potential moisture intrusion.
- Seasonal drift. The agent can track weekly averages and flag readings that deviate from the rolling baseline for that time of year.
Scheduling Regular Analysis OpenClaw's built-in cron scheduling runs analysis at specified intervals. A sensor monitoring agent might run every 5 minutes to check for anomalies, generate hourly summaries, and produce daily reports that highlight trends.
The agent reads the JSON log or queries MQTT retained messages, compares against thresholds defined in its skill configuration, and takes action only when something warrants attention. Most of the time, the agent runs, confirms everything is normal, and goes quiet.
Practical Trigger Actions
When the agent detects an anomaly, it can:
- Send a message through Telegram, Discord, or email with the specific sensor reading and why it is unusual
- Execute a shell command to trigger external systems (turn on a heater, close a valve, sound an alarm)
- Write a structured report to disk for later review
- Escalate to a human by sending a detailed summary with recommended actions
How to Store Telemetry and Share Reports with Fast.io
A Raspberry Pi running in a closet is not the best place to store long-term sensor archives or share reports with other people. The SD card can fail, the Pi can lose power, and nobody else can access the data without SSH.
Local storage options like writing to the SD card or a USB drive work for short-term buffering. Cloud options like S3 or Google Drive work but require custom scripts and credential management. Fast.io provides a middle path: a workspace that the agent can write to directly, with built-in search, versioning, and sharing.
The OpenClaw agent can upload daily sensor summaries, anomaly reports, or raw telemetry archives to a Fast.io workspace using shell commands or the Fast.io MCP server. Once files land in the workspace, Intelligence Mode auto-indexes them for semantic search, so you can later ask questions like "when did the basement humidity last exceed 70%?" and get answers with citations.
The free tier gives you 50 GB of storage, 5,000 AI credits per month, and 5 workspaces with no credit card required. That is enough for years of sensor data from a typical home setup.
For teams, the ownership transfer pattern works well: the agent creates and populates the workspace, then transfers ownership to a human who can share it with others, set permissions, and configure branded shares for external access. The agent retains admin access to keep uploading.
This separation, where the Pi handles real-time decoding and analysis while Fast.io handles persistence, search, and sharing, means you do not lose data when the Pi goes offline and you can query historical sensor readings from any device.
Sensor Types Worth Monitoring
rtl_433's 320 supported protocols cover a wide range of devices. Here are the categories most useful for an always-on monitoring agent:
Weather stations (Acurite, Oregon Scientific, LaCrosse, Fine Offset). Temperature, humidity, wind speed, rainfall. Most home weather stations transmit on 433 MHz and are decoded out of the box.
Soil moisture sensors (Bresser, Ecowitt). Useful for garden automation. The agent can correlate soil moisture with weather data to predict watering needs.
Tire pressure monitors (TPMS). Every car made after 2008 broadcasts tire pressure on 315 or 433 MHz. The agent can alert you to slow leaks before they become flats.
Door and window contacts. Cheap 433 MHz magnetic sensors for security monitoring. The agent can track open/close patterns and flag unusual activity.
Energy meters. Some smart meters and power monitors transmit consumption data on ISM bands. The agent can track usage patterns and alert on spikes.
Pool and spa thermometers. Floating sensors that report water temperature. The agent can notify you when the pool reaches target temperature.
Smoke and CO detectors. Some wireless alarm systems use 433 MHz. The agent provides an independent monitoring layer on top of the alarm panel.
Refrigerator and freezer sensors. Wireless temperature probes placed in cold storage. The agent flags temperature rises that indicate a door left open or a failing compressor.
Rain gauges. Tipping bucket sensors that report rainfall in real time. Combined with weather station data, the agent can estimate total accumulation.
Leak detectors. Water sensors placed near washing machines, water heaters, and under sinks. Immediate notification on detection prevents thousands in water damage.
You do not need to buy all of these. The receiver picks up whatever is broadcasting nearby. Many people discover sensors they did not know existed, such as their neighbor's weather station or a utility meter on the side of the building.
Frequently Asked Questions
What is rtl_433?
rtl_433 is an open-source command-line program that decodes radio transmissions from wireless devices on the ISM bands (433.92 MHz, 868 MHz, 315 MHz, 345 MHz, and 915 MHz). It works with inexpensive RTL-SDR USB dongles to receive and decode signals from weather stations, tire pressure sensors, doorbells, energy meters, and over 320 other device types. Output is available as JSON, CSV, MQTT, or HTTP, making it straightforward to works alongside other software.
Can Raspberry Pi decode 433MHz sensors?
Yes. A Raspberry Pi paired with an RTL-SDR USB dongle (around $30) can decode 433 MHz sensor transmissions using rtl_433. The Pi handles the signal processing and protocol decoding with minimal CPU usage. A Pi 4 or Pi 5 with at least 2 GB of RAM is sufficient for continuous sensor monitoring. The software compiles natively on ARM64 and runs as a lightweight systemd service.
How many devices does rtl_433 support?
As of version 25.12 (December 2025), rtl_433 supports 320 device protocols. These include temperature and humidity sensors, weather stations, TPMS (tire pressure) monitors, doorbells, PIR motion sensors, energy meters, door/window contacts, soil moisture probes, and remote switches. The protocol count grows with each release as contributors add new decoders.
How much does an RTL-SDR dongle cost?
RTL-SDR dongles range from $10 to $40. The RTL-SDR Blog V4 (the current recommended model) costs $30 for the dongle alone or $40 with an antenna kit. Budget alternatives like generic RTL2832U dongles start around $10-15 but lack temperature-compensated oscillators, which causes frequency drift over time. For reliable long-term sensor monitoring, spend the extra $15-20 on a unit with a TCXO.
Does OpenClaw work on Raspberry Pi 4?
Yes. OpenClaw runs on Raspberry Pi 4 with 4 GB RAM as the recommended minimum. It requires 64-bit Raspberry Pi OS and Node.js 24 or later. The Pi 4 handles agent tasks adequately, though complex multi-step reasoning is slower compared to a Pi 5. For a sensor monitoring agent that mostly runs scheduled checks and simple analysis, a Pi 4 performs well.
Can rtl_433 and OpenClaw run on the same Raspberry Pi?
Yes. rtl_433 uses minimal CPU and RAM (under 50 MB) since it is written in portable C. OpenClaw needs 1-2 GB of RAM for the Node.js runtime and agent processes. On a Pi 5 with 8 GB or a Pi 4 with 4 GB, both run comfortably alongside an MQTT broker and basic logging. The key constraint is RAM, not CPU.
Related Resources
Persist your sensor telemetry and agent reports across sessions
50 GB free workspace for your Raspberry Pi agent. Auto-indexed for search, shareable with your team, no credit card required. Connect via the Fast.io MCP server.