How to Build a Raspberry Pi Wildfire Smoke Detection Agent with OpenClaw

Public air quality stations are sparse. If you live more than a few miles from the nearest regulatory monitor, the number you see on a weather app is often interpolated from far away and lags the smoke plume that actually reaches your street. During a bad fire season, that lag is the difference between closing the windows in time and waking up to a house full of smoke.

A Raspberry Pi with a laser particulate sensor sits in your yard and reads the air you are actually breathing. Pair it with a small agent and you get two things a raw logger cannot offer. The agent can decide when a reading matters, and it can push that decision to the people who need to know.

The EPA classifies PM2.5 concentrations above 150 µg/m³ as unhealthy for all groups, and above 250 µg/m³ as hazardous. Those thresholds are the trigger points for the alerts this guide builds toward.

The agent framing matters here. A cron job that emails a CSV is a logger. An agent watches for threshold crossings, writes a short explanation of what it saw, and hands that writeup to a workspace where family members or neighbors can react. That is the gap most home air quality guides leave open: they stop at the sensor reading and never connect it to the people who need to act on it.

Helpful references: Fast.io Workspaces, Fast.io Collaboration, and Fast.io AI.

The build is modest. Most of the decisions come down to choosing a PM2.5 sensor that reads accurately in smoke conditions rather than just dust.

Core components

• Raspberry Pi 4 or Pi 5, or a Pi Zero 2 W if you want something discreet
• Laser PM2.5 sensor — the Plantower PMS5003 and PMS7003 are the common choices for DIY smoke monitoring, and Sensirion's SPS30 is a higher-end option with better long-term stability
• A weatherproof enclosure with a vented intake, ideally with a small fan so the sensor samples outdoor air rather than stagnant enclosure air
• MicroSD card, power supply, and either a short ethernet run or reliable Wi-Fi

The PMS5003 is inexpensive and widely used by the PurpleAir community, which makes its behavior well documented. The SPS30 costs more but drifts less over a fire season. Both speak serial, so the wiring is straightforward: power, ground, TX, RX.

If you are choosing between Pi models, lean toward the Pi 4 or Pi 5. Running a small agent loop alongside a web dashboard and occasional image uploads is comfortable on 2 GB of RAM and painful on 512 MB.

One practical note. Place the sensor where smoke will actually reach it before it reaches your windows. A north-facing eave on the upwind side of the house is a better location than a sheltered porch. The goal is early warning, not a pretty graph.

The sampling loop runs on the Pi and produces one structured reading per interval. Keep it simple: read the sensor, timestamp the reading, append it to a local log, and hand the same record to the agent layer.

A one-minute cadence is a reasonable default. Smoke plumes move in minutes, not seconds, and a faster cadence mostly generates data you will never look at. During active fire events, dropping to 30 seconds gives you a sharper picture of plume arrival.

A minimal loop looks like this conceptually:

while True:
    reading = sensor.read()       # PM2.5, PM10, timestamp
    log.append(reading)           # local CSV or SQLite
    if reading.pm25 > WARN:
        agent.notify(reading)     # hand off to the agent
    sleep(60)

Keep the local log even after the agent layer is working. If your network drops during a fire, you still want the raw record on disk. A rolling SQLite file on the SD card is easier to query later than a pile of CSVs, and the whole season fits in a few hundred megabytes.

Calibration is worth a paragraph. Consumer laser sensors tend to over-report PM2.5 in high humidity and under-report during extreme smoke. The EPA publishes a correction factor for PurpleAir PMS5003 data that many hobbyists apply to their own builds. If you want numbers that agree with your local AirNow station, apply a correction. If you just want to know when to close the windows, the raw reading is fine.

Give your smoke detection agent a workspace

Fast.io gives your Raspberry Pi agent a place to write readings, store event folders, and share alerts with family. 50 GB free, 5,000 credits per month, no credit card. Built for openclaw raspberry wildfire smoke particulate detection agent workflows.

Sign Up Free

OpenClaw is an open agent runtime that can run on a Raspberry Pi and drive actions on the device. The role of the agent in this build is narrow and useful: it watches the sampling loop, decides when a reading crosses a threshold, writes a short natural language summary of the event, and triggers downstream actions like uploads and notifications.

Keep OpenClaw-specific configuration grounded in the version of the project you are actually running. The OpenClaw project has moved quickly, and exact command names, config paths, and skill formats change between releases. Read the current docs for the release installed on your Pi rather than copying older tutorials. The general shape of the integration, though, is stable: a local agent process, a prompt or skill that describes the task, and a set of tools the agent can call.

For this build, the agent needs three capabilities.

First, it needs to read the latest sensor values. That can be a local file it tails, a small HTTP endpoint on localhost, or a direct import from the sampling script.

Second, it needs a way to write and store records somewhere durable. A local log is fine for debugging, but once the alerts matter to other people, you want the record in a shared place so everyone is looking at the same data.

Third, it needs a notification path. Email, SMS via a gateway, a push to a phone app, or a message in whatever group chat your household already uses.

The agent's prompt should be small. Something like: "You monitor a PM2.5 sensor. When a reading crosses a threshold, write a two-sentence summary of what happened, including the current value and the EPA category. Attach the summary and the last hour of readings to the shared workspace and send the notification." The agent does not need to be clever. It needs to be reliable and quiet until something actually happens.

This is the part most Raspberry Pi air quality guides skip. Raw CSVs on an SD card are useful for the person who built the rig. They are useless to a partner, a parent, or a neighbor who wants to know whether to cancel a run or bring the kids inside.

You have a few reasonable options for the shared layer.

Local only. Keep everything on the Pi and expose a small web page on the home network. Cheapest. Works only when everyone is home and the Pi is up.

Google Drive or Dropbox. Upload the log file and any alert PDFs to a shared folder. Easy to set up. Harder to search, and the folder becomes a pile quickly during a bad week.

S3 or a self-hosted bucket. Flexible and cheap. Requires you to build the search, sharing, and notification layer yourself.

A workspace built for agent output. This is where Fast.io fits. The agent writes readings, event summaries, and hourly rollups into a shared workspace. Intelligence Mode auto-indexes those files, so a family member can ask "what was the worst hour last night" in natural language and get an answer with citations pointing back to the underlying records. Branded share links let you send a single URL to neighbors or a block captain without handing over your whole log.

The free agent plan covers this use case comfortably: 50 GB of storage, 5,000 credits per month, five workspaces, and no credit card. A season of one-minute PM2.5 readings is a few hundred megabytes, even with generous margin for event PDFs and images.

One pattern that works well: one folder per fire event. When the agent detects a sustained threshold crossing, it opens a new folder named by date and plume, drops in the rolling log, a short writeup, and a link to the local dashboard. When the event ends, the folder becomes a self-contained record. You can share that one folder with a neighbor without exposing anything else.

The agent you built should outlive your attention span. Fire season is long, the novelty wears off, and at some point your partner or your parents need to use this thing without asking you to SSH into the Pi.

Two practical moves make the handoff easier.

Make the shared workspace the source of truth. If the dashboard, the alerts, and the history all live in one place, everyone goes to the same URL. The Pi becomes an appliance that feeds the workspace rather than a thing people need to log into.

Separate the "owner" role from the "reader" role. On Fast.io, the agent can create the workspace and set up the structure, then transfer ownership to a human while keeping admin access for itself. That lets a family member actually own the data and add readers, while the agent continues to write into the same folders. If you ever move, stop maintaining the rig, or hand it to someone else, the workspace goes with them.

The point is that the agent is not the product. The shared understanding of air quality is the product. The Pi and the sensor are just what generates the readings.