How to Build an AWS IoT Greengrass Edge Agent with OpenClaw on Raspberry Pi

AWS IoT Greengrass extends AWS services to edge devices. It handles the infrastructure layer: provisioning devices, deploying software components, managing MQTT messaging, syncing device shadows, and streaming telemetry to the cloud. What it does not do is reason about the data flowing through it.

Most Greengrass tutorials stop at data collection. You get sensor readings in S3 or Kinesis, then build separate cloud-based processing to act on them. That round trip adds latency, costs bandwidth, and fails when connectivity drops.

OpenClaw fills the reasoning gap. It runs an AI agent directly on the Raspberry Pi, using the same sensor data that Greengrass collects. The agent interprets telemetry locally, decides whether to trigger alerts or actuators, and only escalates to cloud inference when the decision exceeds local model capabilities. Greengrass handles the plumbing; OpenClaw handles the thinking.

The combined architecture looks like this: sensors feed data through Greengrass components via local MQTT topics. An OpenClaw agent subscribes to those topics, processes readings through its tool pipeline, and publishes decisions back. Greengrass forwards relevant events to AWS IoT Core for fleet-wide visibility, while the agent stores its analysis and outputs in a persistent workspace for human review.

Global spending on edge computing is projected to reach $380 billion by 2028 according to IDC, driven largely by the need for real-time decision-making at the point of data generation. This architecture addresses that need without requiring custom firmware or cloud-dependent inference.

The system has three layers, each with a clear responsibility.

Device Layer (Greengrass Core)

The Greengrass nucleus runs on the Raspberry Pi as the base runtime. It manages component lifecycle, handles MQTT brokering between local devices and the cloud, and provides OTA updates for all deployed software. Client devices (sensors, actuators, cameras) connect to the Greengrass core via MQTT using the Moquette broker component.

Intelligence Layer (OpenClaw Agent)

OpenClaw runs alongside Greengrass as a separate process. It uses its Gateway + Node architecture where the Gateway handles task scheduling and LLM request routing, while the Node manages execution and sensor integration. The agent subscribes to local MQTT topics that Greengrass publishes sensor data to, processes readings through its skill pipeline, and publishes action commands back to actuator topics.

Cloud Layer (AWS IoT Core + Workspace)

Greengrass bridges selected local MQTT topics to AWS IoT Core using its MQTT bridge component. This gives you fleet-wide device telemetry in the cloud without routing all traffic through the internet. The OpenClaw agent pushes its analysis outputs, decision logs, and reports to a Fast.io workspace where team members can review edge decisions, query historical data through Intelligence Mode, and take over when human judgment is needed.

The data flow for a typical sensor event:

1. Temperature sensor publishes reading to local MQTT topic sensors/zone-1/temperature
2. Greengrass MQTT bridge forwards the reading to AWS IoT Core for fleet dashboards
3. OpenClaw agent receives the same reading via local subscription
4. Agent evaluates against thresholds and recent trends using its tool pipeline
5. If action needed: agent publishes command to actuators/zone-1/hvac and logs the decision
6. Decision log syncs to Fast.io workspace for human audit trail

AWS IoT Greengrass V2 installs directly on Raspberry Pi OS. The process takes 20-30 minutes and requires an AWS account with IoT permissions.

Prerequisites:

• Raspberry Pi 5 (8 GB) or Pi 4 (4+ GB) running 64-bit Raspberry Pi OS Lite (Bookworm)
• Java 11 or later (the Greengrass nucleus requires a JVM)
• Python 3.8+ for Lambda-based components
• AWS CLI configured with IAM credentials that have IoT and Greengrass permissions
• SSH enabled for remote access

Installation steps:

Install Java and verify:

sudo apt update && sudo apt install -y default-jdk
java --version

Download and run the Greengrass installer. The installer provisions the device as an AWS IoT thing, creates certificates, and starts the nucleus:

curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-nucleus-latest.zip > greengrass-nucleus-latest.zip
unzip greengrass-nucleus-latest.zip -d GreengrassInstaller

sudo -E java -Droot="/greengrass/v2" \
  -jar ./GreengrassInstaller/lib/Greengrass.jar \
  --aws-region us-east-1 \
  --thing-name EdgeAgent-Pi-01 \
  --thing-group-name EdgeAgentGroup \
  --component-default-user ggc_user:ggc_group \
  --provision true \
  --setup-system-service true

The --setup-system-service flag creates a systemd unit that starts Greengrass on boot and restarts it after crashes. Verify the service is running:

sudo systemctl status greengrass.service

Deploy the MQTT broker component so local devices can connect:

From the AWS IoT Greengrass console, create a deployment targeting your device. Add the aws.greengrass.clientdevices.mqtt.Moquette component. This gives you a local MQTT broker on port 8883 that client devices authenticate against using their IoT certificates.

Deploy the MQTT bridge to forward selected topics to AWS IoT Core:

Add aws.greengrass.clientdevices.mqtt.Bridge to the same deployment. Configure it to bridge sensors/# topics to IoT Core so fleet dashboards receive telemetry while local processing stays on-device.

Greengrass V1 reaches end of support in October 2026. All new deployments should use V2, which uses a modular component architecture instead of the older Lambda-centric model.

Persist your edge agent's intelligence where your team can find it

Fast.io gives your OpenClaw agent 50 GB of indexed storage, semantic search across every report it generates, and ownership transfer to hand results to your operations team. No credit card, no expiration.

Sign Up Free

With Greengrass handling device communication, OpenClaw adds the decision-making capability. OpenClaw uses a Gateway + Node architecture that maps well to this use case: the Gateway schedules tasks and routes LLM requests, while the Node executes tools and works alongside local hardware.

Install OpenClaw on the same Pi:

OpenClaw requires Node.js 20+ and installs as a single binary. On a Pi 5 with 8 GB RAM, both Greengrass (JVM-based) and OpenClaw (Node.js-based) coexist comfortably. The Pi 4 with 4 GB works but benefits from a 2 GB swap file.

Configure the LLM backend:

OpenClaw supports multiple model providers. For edge IoT use cases, lightweight models like Claude Haiku or GPT-4o-mini handle sensor interpretation at roughly $0.001 per call. For image analysis from cameras, route to a larger model at $0.01-0.05 per call. The agent selects the appropriate model based on task complexity.

For fully offline operation, connect OpenClaw to a locally hosted model through Ollama or llama.cpp. A quantized 7B parameter model runs on Pi 5 with acceptable latency for simple classification tasks, though complex reasoning still benefits from cloud inference.

Connect to local MQTT:

The agent needs to subscribe to sensor topics and publish to actuator topics. A Python-based OpenClaw skill can use the Paho MQTT client library to connect to the local Moquette broker that Greengrass runs. The skill receives sensor readings as they arrive, parses the JSON payload, and passes structured data to the agent's reasoning loop.

Resource allocation:

On a Pi 5 (8 GB), allocate memory limits via systemd:

• Greengrass nucleus: 1 GB (MemoryMax in systemd unit)
• OpenClaw Gateway: 1 GB
• OpenClaw Node: 2 GB
• Remaining: OS, MQTT broker, and sensor processes

Set the OpenClaw Node.js heap limit to match: NODE_OPTIONS=--max-old-space-size=2048

Headless boot:

Both services should start automatically and recover from crashes. Greengrass already installs as a systemd service. OpenClaw needs its own unit files for the Gateway and Node, configured with Restart=always and appropriate memory limits. The Node service should depend on both the Gateway and Greengrass services to ensure MQTT is available before the agent starts subscribing.

The Greengrass + OpenClaw combination works best when you need both fleet management and local intelligence. Here are three patterns that show the division of labor.

Environmental Monitoring with Adaptive Thresholds

Static threshold alerts generate noise. A warehouse freezer that normally runs at -18C might spike to -15C during defrost cycles, which is expected. A traditional system either fires false alarms on every defrost or misses genuine failures because the threshold is set too loose.

The OpenClaw agent learns normal patterns from sensor history. It distinguishes scheduled defrost spikes from genuine cooling failures by correlating time-of-day, duration, and rate of temperature change. Greengrass handles the sensor connectivity and forwards aggregated data to AWS IoT Core for fleet-wide trend analysis. When the agent detects an anomaly that doesn't match known patterns, it triggers an alert via MQTT publish and logs the reasoning to the team workspace.

Predictive Maintenance on Industrial Equipment

Vibration sensors on motors publish frequency spectrum data every second. Greengrass collects and locally buffers this stream using its Stream Manager component, which handles temporary connectivity loss without data loss. The OpenClaw agent periodically analyzes buffered readings, looking for frequency shifts that indicate bearing wear or imbalance.

When the agent identifies a degradation trend, it estimates remaining useful life and creates a maintenance ticket in the team workspace. Greengrass forwards the diagnosis to IoT Core where fleet managers see maintenance predictions across all sites on a single dashboard.

Access Control with Context

A badge reader authenticates via Greengrass client device auth. The OpenClaw agent adds context: is this person normally here at this hour? Did they badge into the exterior door first? Is this area under restricted access today? The agent makes the admit/deny decision locally in milliseconds. Greengrass logs all events to IoT Core for compliance reporting.

Each scenario follows the same pattern: Greengrass handles connectivity, authentication, and fleet visibility. OpenClaw handles the reasoning that turns raw data into decisions. Neither system alone covers both needs.

Edge agents generate valuable outputs: anomaly reports, maintenance predictions, decision logs, processed sensor summaries. These need to persist beyond the Pi's local storage and reach the humans who act on them.

The storage problem on edge devices:

A Raspberry Pi with a 32 GB SD card has limited capacity and no redundancy. SD cards fail. Power losses corrupt filesystems. If the agent's analysis only lives on the Pi, one hardware failure erases months of operational intelligence.

Options for edge data persistence:

• AWS S3 via Greengrass Stream Manager: Works for raw telemetry. Uploads sensor data in batches. Good for compliance archiving, poor for collaborative review since S3 is not built for team access patterns.
• Local NAS or network share: Adds hardware complexity and doesn't solve remote access for distributed teams.
• Fast.io workspace: The agent pushes reports, logs, and processed data to a shared workspace via the Fast.io MCP server. Files are immediately indexed for semantic search through Intelligence Mode. Team members query edge data by asking questions in natural language rather than navigating folder structures.

Why a shared workspace fits edge deployments:

The OpenClaw agent on your Pi generates reports that a maintenance engineer in another city needs to review. A workspace handles that handoff naturally. The agent writes; the engineer reads and responds. Ownership transfer lets the agent build the workspace structure, then hand control to the operations team while retaining programmatic access for continued updates.

Intelligence Mode auto-indexes every file the agent uploads. When an engineer asks "what anomalies did the Zone 3 freezer agent flag last week?", the workspace returns relevant documents with citations. No manual tagging or folder organization required.

The free agent tier provides 50 GB storage, 5,000 credits per month, and 5 workspaces with no credit card and no expiration. For a single-site deployment with one Pi running edge inference, that covers months of operational data. Multi-site fleets can use separate workspaces per location or aggregate into a central workspace with folder-level permissions.

File versioning tracks how the agent's outputs change over time. Audit trails show exactly when each file was created or modified. Webhooks can notify downstream systems when the agent publishes new analysis, closing the loop between edge intelligence and team action.