How to Build a Solar Panel Monitoring Agent with OpenClaw on Raspberry Pi

Solar panels lose output gradually. According to the National Renewable Energy Laboratory's 2024 analysis of nearly 2,500 commercial and utility-scale installations, the median degradation rate is 0.75% per year. High-quality Tier-1 modules from manufacturers like Jinko, Trina, and LONGi degrade at 0.3% to 0.6% annually, with most of the power loss concentrated in the first year. Over a 25-year panel lifetime, that adds up to 15-20% total output loss even under ideal conditions.

Conditions are rarely ideal. Partial shading from a single tree branch can cut module power by 33% because shaded cells limit current through the entire series string. Dust and dirt accumulation reduces output proportionally over time, with studies measuring a 13% decline after just three months of soiling in dry climates. The problem is that these losses are invisible. A panel coated in a thin film of pollen looks fine from the ground but is producing measurably less power.

The standard Raspberry Pi solar monitoring project reads an INA219 current/voltage sensor, logs the data to a CSV or InfluxDB instance, and displays it on a Grafana chart. That tells you what your panels produced yesterday. It does not tell you whether yesterday's output was 8% below what it should have been given the available sunlight, whether the decline is a sudden drop (shading, debris) or a gradual trend (degradation, connector corrosion), or whether you should clean your panels or call an installer.

An OpenClaw agent running on the same Pi changes the monitoring system from a passive recorder to an active analyst. The agent reads the same sensor data, but it compares current output against historical baselines, correlates dips with weather data, and generates plain-language reports: "Panel 2 output dropped 12% over the past two weeks while Panel 1 remained stable. This pattern is consistent with localized shading or soiling rather than system-wide degradation." The hardware cost stays under $20. The intelligence layer is what makes the data actionable.

The core of solar panel monitoring is measuring voltage and current at the panel output. The INA219 from Texas Instruments is the standard sensor for this job. It measures high-side DC current and voltage over I2C with 1% precision, handles up to 26V (well above typical 12V or 18V panel outputs), and breakout boards cost between $1 and $10 depending on source.

INA219 breakout boards

The Adafruit INA219 breakout (product 904) includes a 0.1 ohm shunt resistor and handles up to 3.2A, which covers most residential panels under 80W. It communicates over I2C at 3.3V, so no level shifting is needed when connecting to a Raspberry Pi. Generic INA219 breakout boards from Amazon or AliExpress work identically for under $2 per unit, though build quality and shunt resistor tolerance vary.

For systems with multiple panels, you can run up to 16 INA219 sensors on the same I2C bus. Each board has A0 and A1 address pins that set its I2C address. With two pins and four possible states each (GND, VS, SDA, SCL), you get 16 unique addresses from 0x40 to 0x4F. In practice, most monitoring setups need 2-4 sensors: one per panel string or one at the panel output and one at the battery input.

For higher-current systems

If your panels produce more than 3.2A (typical for systems above 80W at 24V), the INA226 is the upgrade path. It handles the same 36V maximum but supports configurable shunt resistors for higher current ranges. The INA260 integrates a precision shunt resistor on-chip and handles up to 15A, but costs $10-15 per board.

Supplementary sensors

Temperature affects panel efficiency. A DS18B20 waterproof temperature probe ($3-5) mounted to the back of a panel measures cell temperature over the 1-Wire protocol on a single GPIO pin. Solar cell efficiency drops roughly 0.3-0.5% per degree Celsius above 25C for crystalline silicon panels, so temperature data helps the agent distinguish between thermal derating and actual degradation.

A BH1750 ambient light sensor ($2-3) on I2C provides lux readings that correlate with available irradiance. Comparing expected output (based on light level and temperature) against actual output is how the agent identifies shading, soiling, or component failure rather than just a cloudy day.

Recommended starter kit

• Raspberry Pi 4 or 5 (2GB RAM minimum, 4GB recommended for OpenClaw)
• 1-2 INA219 breakout boards ($2-10 each)
• DS18B20 waterproof temperature probe ($3-5)
• BH1750 light sensor ($2-3)
• Breadboard and jumper wires ($5)
• Total sensor cost: under $25 for a two-panel monitoring setup

The INA219, BH1750, and DS18B20 connect to different interfaces on the Pi. The I2C sensors share the same bus, while the DS18B20 uses the 1-Wire protocol on a dedicated GPIO pin.

I2C connections (INA219 and BH1750)

Both I2C sensors connect in parallel to the same pins:

• SDA to GPIO 2 (pin 3)
• SCL to GPIO 3 (pin 5)
• VCC to 3.3V (pin 1)
• GND to any ground pin (pin 6 or pin 9)

The INA219 defaults to I2C address 0x40. The BH1750 defaults to 0x23 (or 0x5C if the ADDR pin is pulled high). No address conflicts with this combination. If you add a second INA219 for a second panel, bridge the A0 pad on one board to shift it to 0x41.

After wiring, verify all devices appear by running i2cdetect -y 1 from the terminal. You should see entries at addresses 0x23 (BH1750), 0x40 (first INA219), and 0x41 (second INA219 if connected).

INA219 solar panel connection

The INA219 measures current through its shunt resistor, which sits in series with the positive lead from the solar panel. Connect the VIN+ terminal to the positive output of the panel and VIN- to the positive input of your charge controller or load. The sensor measures the voltage drop across the 0.1 ohm shunt to calculate current, and also reads the bus voltage (the voltage at VIN-) to calculate power.

Do not connect the INA219 between the negative terminal and ground. It is a high-side sensor designed to sit on the positive rail.

DS18B20 temperature probe (1-Wire)

The DS18B20 uses a single data pin:

• Data to GPIO 4 (pin 7)
• VCC to 3.3V (pin 1)
• GND to ground (pin 6)

A 4.7K ohm pull-up resistor between the data line and 3.3V is required. Enable the 1-Wire interface through raspi-config under Interface Options. The sensor appears as a file in /sys/bus/w1/devices/ after a reboot.

Software dependencies

Enable I2C and 1-Wire interfaces through raspi-config. Install the Pi INA219 Python library for sensor communication. The pi_ina219 library by Chris Sherlock provides a clean Python interface to the INA219's registers, including automatic bus voltage and shunt voltage readings with configurable gain and bus ADC resolution. For the BH1750, the smbus2 library handles raw I2C reads, or use the bh1750 Python package for a higher-level interface. The DS18B20 is read directly from the filesystem via the kernel's w1-therm driver without any additional library.

Store and Search Your Solar Monitoring Data

Upload sensor logs and agent reports to a Fast.io workspace. Intelligence Mode auto-indexes everything for semantic search, so you can query years of solar data in plain language. 50GB free, no credit card. Built for openclaw raspberry solar panel energy output monitoring agent workflows.

Sign Up Free

OpenClaw runs locally on the Raspberry Pi and sends reasoning tasks to a remote LLM (Claude, GPT-4, or other supported models). The agent's behavior is defined by a SKILL.md file that describes what tools are available and how to use them. For solar monitoring, the skill teaches the agent how to read sensor data, interpret it against baselines, and decide when to alert.

Setting up OpenClaw on the Pi

The Adafruit guide for OpenClaw on Raspberry Pi documents the base installation on a Pi 5 with 8GB RAM. A Pi 4 with 4GB works for monitoring workloads since the heavy computation happens on the remote LLM, not locally. The Pi handles sensor reads, data storage, and network communication. Install OpenClaw following the project's current documentation, then create a skill directory for the solar monitoring agent.

Defining the monitoring skill

The SKILL.md file for the solar agent should describe the sensor reading tools, the data storage location, the baseline comparison logic, and the alerting thresholds. Structure the skill to give the agent access to Python scripts that read the INA219, BH1750, and DS18B20 sensors, a local SQLite or CSV data store for historical readings, and a reporting function that can send alerts via Telegram, email, or webhook.

The agent does not need to run continuously. A cron job or systemd timer that triggers the agent every 5-15 minutes is sufficient for solar monitoring. Each invocation reads current sensor values, appends them to the data store, and asks the LLM to evaluate whether the readings indicate normal operation, expected variation (weather, time of day), or an anomaly worth reporting.

Baseline establishment

The first week of monitoring establishes baseline output curves. Solar panel output follows a predictable daily pattern: rising in the morning, peaking around solar noon, declining in the afternoon. The shape of this curve depends on panel orientation, tilt angle, and local shading patterns. After 7 days of clean data, the agent has enough history to identify deviations.

The agent compares each reading against the expected output for that time of day and light level. A reading that is 5% below expected on a clear afternoon is worth noting. A reading that is 20% below expected while the BH1750 shows full sunlight is an immediate alert. A gradual 1% per month decline across all panels points to system-wide soiling. A sudden 15% drop on one panel while others remain stable points to localized shading or a faulty connection.

Anomaly categories the agent can distinguish

• Sudden single-panel drops: shading from new obstruction, debris, bird droppings, broken bypass diode
• Gradual system-wide decline: soiling accumulation, seasonal angle mismatch
• Gradual single-panel decline: cell degradation, connector corrosion, junction box failure
• Intermittent dips: moving shadows (trees in wind), temporary cloud cover (correlates with BH1750 data)
• Temperature derating: high output loss on hot days (correlates with DS18B20 readings above 45C)

The LLM interprets these patterns based on the data context you provide in the skill. A traditional threshold-based alert triggers on any output drop. The agent considers whether the drop has a benign explanation before alerting, which reduces false positives .

Raw sensor readings become useful when stored with timestamps and metadata. The monitoring agent needs a lightweight data pipeline that captures readings, stores them for trend analysis, and generates periodic reports.

Local data storage

SQLite is the simplest option for a Pi-based monitoring system. A single table with columns for timestamp, panel ID, voltage, current, power (calculated), temperature, and ambient light level covers the core data. At one reading per panel every 5 minutes, a two-panel system generates roughly 210,000 rows per year, about 15MB of SQLite data. The Pi's SD card handles this easily, though backing up the database file regularly is important since SD cards can fail.

For more strong storage, InfluxDB runs well on a Pi 4 and provides built-in time-series functions like moving averages and downsampling. Grafana connects to InfluxDB for visualization. This stack is heavier than SQLite but gives you dashboards out of the box.

Agent-generated reports

The value OpenClaw adds over a standard data logger is natural language reporting. Instead of staring at a chart and trying to interpret whether a dip matters, the agent produces structured reports.

A daily summary might read: "Total generation today: 4.2 kWh across two panels. Panel 1 produced 2.3 kWh (within 3% of expected for today's conditions). Panel 2 produced 1.9 kWh (11% below expected). The gap between panels has widened from 4% to 11% over the past nine days. Panel 2's afternoon output is consistently lower than Panel 1's, suggesting a new shading source affecting Panel 2 after 2 PM."

A weekly report can track cleaning cycles: "System output averaged 7.1 kWh/day this week, down from 7.5 kWh/day last week. Both panels show proportional decline. Recommend cleaning. After the last cleaning on March 12, output recovered by 9%."

Archiving data to Fast.io

Local SD card storage works for short-term data, but solar monitoring generates years of readings that you want backed up somewhere more durable. Fast.io provides workspace storage where the agent can upload daily data exports and reports automatically.

The agent can push CSV exports or SQLite snapshots to a Fast.io workspace using the MCP server or REST API. With Intelligence Mode enabled on the workspace, those files are auto-indexed for semantic search. Six months later, you can ask the workspace "When did Panel 2 first show afternoon output drops?" and get an answer grounded in the actual logged data, not just a chart you have to interpret visually.

The free agent plan includes 50GB of storage, 5,000 monthly API credits, and 5 workspaces with no credit card required. That is enough to store decades of solar monitoring data. If you are managing monitoring for multiple sites or clients, the workspace permission model lets you grant access to specific installations without exposing everything.

For teams running multiple Pi-based monitors across different locations, Fast.io workspaces provide a centralized archive. Each site gets its own workspace. The agent at each site uploads its data and reports. A human reviewer opens the workspace, sees indexed reports, and can query across sites using the built-in AI chat. This is the handoff pattern that works well for agent-to-human workflows: the agent builds and maintains the data, the human reviews it when needed.

Running a solar monitoring agent on a Pi in an outdoor or semi-outdoor environment introduces challenges that indoor projects do not face. Plan for these from the start.

Power supply for the Pi itself

If you are monitoring an off-grid solar system, the Pi needs to run from that same system. A Raspberry Pi 4 draws 3-5W under load. A Pi 5 draws 5-8W. Budget your solar capacity accordingly. A dedicated 20W panel, charge controller, and small 12V battery (7Ah is sufficient) can keep a Pi 4 running through overnight hours and cloudy days. Use a buck converter to step 12V battery voltage down to 5V for the Pi's USB-C input.

For grid-tied systems, just plug the Pi into a wall outlet nearby. Do not run long USB cables outdoors. Use a weatherproof enclosure near the panels with a short power cable, and run the sensor wires to the panels.

Weatherproofing

The Pi and INA219 boards are not waterproof. Use an IP65-rated junction box ($10-15) large enough to hold the Pi, breadboard, and sensor boards. Route sensor wires through cable glands. The DS18B20 in its waterproof stainless steel probe housing can be mounted directly to the back of a panel with thermal adhesive or a cable tie through a mounting hole.

I2C cable length

I2C was designed for short-distance communication on a circuit board, not for running cables across a roof. At the standard 100 kHz bus speed, you can reliably run I2C over 1-2 meters of cable. Beyond that, signal integrity degrades. If your panels are far from the Pi enclosure, either mount the Pi close to the panels or use an I2C extender (the PCA9615 differential I2C bus extender handles up to 20 meters over Cat5 cable).

Sensor calibration

The INA219's accuracy depends on the shunt resistor value being correct. Generic breakout boards sometimes use shunt resistors with 5% tolerance instead of 1%. Calibrate by measuring a known load: connect a resistor across VIN+ and VIN- with a multimeter in series, compare the multimeter's current reading against the INA219's reading, and apply a correction factor in your Python code if they differ by more than 2%.

SD card longevity

Frequent writes to an SD card (every 5 minutes for years) will eventually wear out the flash cells. Use a high-endurance SD card rated for continuous write workloads (Samsung PRO Endurance, SanDisk Max Endurance). Alternatively, write to a USB SSD for the data store and keep the SD card for the OS only.

OpenClaw API costs

Each agent invocation sends sensor data and context to a remote LLM. At 5-minute intervals, that is 288 calls per day. Keep the prompt concise: send only the current readings and a summary of recent trends, not the entire historical dataset. Most LLM providers charge per token, so a well-structured 500-token prompt costs less than dumping 10,000 rows of CSV data into the context window. For routine readings within normal range, the agent can skip the LLM call entirely and only invoke reasoning when a reading exceeds a threshold.